Analizar correctamente logs y servicios de Sophos Endpoint en Windows

En Windows, Sophos Endpoint consta de varios componentes de protección, actualización y comunicación. Por ello, un Health State rojo no significa automáticamente que todo el agente haya fallado. Para obtener un diagnóstico fiable, primero se asigna el síntoma a un componente y después se comprueba únicamente su log en el intervalo de tiempo correspondiente.

La mayoría de los logs operativos se encuentran en C:\ProgramData\Sophos. Los logs de instalación suelen estar en C:\Windows\Temp, C:\Windows\SystemTemp o en %TEMP% de la cuenta que inició el instalador. Desde versiones recientes de Core Agent, algunos logs de la interfaz de usuario se encuentran en %LOCALAPPDATA%.

Procedimiento rápido:

1. Anote la hora del incidente, la zona horaria y el síntoma visible.
2. En Sophos Endpoint Agent > About > Open Endpoint Self Help Tool, compruebe primero Services y Components.
3. Anote la plataforma, la versión de Core Agent y los componentes instalados; la licencia y Agent Mode determinan el estado esperado.
4. Seleccione el log pertinente de la lista siguiente y léalo desde el primer error relevante.
5. Tras una corrección, actualice Self Help y repita la misma prueba. Para una escalación, conserve también una SDU del mismo intervalo.

En Computer details > Status, Central separa el estado general en Communication, Operations, Services, System, Threat y Update. Los detalles Good, Warning, Bad e Info pueden variar según el sistema operativo y la versión del agente. Por tanto, correlacione siempre la categoría afectada con el componente exacto en Endpoint Self Help, en lugar de deducir que un servicio ha fallado únicamente por el color general.

Del síntoma al log correcto

Los nombres de archivo y las asignaciones de servicios pueden cambiar con la versión de Core Agent. Antes de evaluarlos, compare la versión del paquete instalado con el resumen de las actualizaciones de Sophos Endpoint y los cambios de componentes; para el diagnóstico en sí, utilice los componentes correspondientes a la versión instalada y los archivos realmente presentes en el dispositivo afectado.

Updates y AutoUpdate

SophosUpdate.log es el log principal del proceso de actualización. En versiones actuales y compatibles de Windows, sau-service.log muestra cuándo Central o un cambio en la política de Update o comunicación ha iniciado una actualización. SophosLaunchUpdate.log documenta el inicio del proceso.

Un error de actualización no se evalúa únicamente por la última línea de error. Primero se comprueba:

1. qué destino de actualización se utilizó realmente,
2. si intervino acceso directo, Proxy o Update Cache,
3. cuál fue el primer error HTTP o TLS,
4. si el mismo momento aparece en el log del firewall o Proxy.

Las entradas no válidas en el archivo Hosts de Windows pueden dirigir los destinos de Sophos a una dirección incorrecta. En errores reproducibles se comparan SophosUpdate.log, DNS, Proxy y una captura de paquetes realizada al mismo tiempo.

El clásico Sophos AutoUpdate Service ya no existe en Windows moderno. Si falta en una plataforma Legacy expresamente compatible, repare con derechos de administrador el MSI de AutoUpdate en caché y vuelva a ejecutar About > Update Now. Este procedimiento MSI antiguo no se usa en Windows 10 x64, Windows Server 2016 ni versiones posteriores.

Comunicación con Central y políticas

El Sophos MCS Client mantiene la conexión con Sophos Fusion (antes Sophos Central). McsClient.log indica si el Endpoint puede acceder a Central. Después, McsAgent.log muestra qué políticas y comandos se han procesado. Un valor reciente de Last Active en Central es un buen indicio de que MCS funciona, pero se actualiza como máximo aproximadamente una vez por hora.

Ante un error de comunicación se comprueban la dirección del Broker, DNS, Routing, Proxy y firewall. Después de una corrección puede reiniciarse el servicio Sophos MCS Client y actualizarse Endpoint Self Help. Tamper Protection solo se desactiva si la intervención concreta lo requiere.

Protección, bloqueos y Cleanup

sed.log es el log operativo central de Sophos Endpoint Defense. Contiene, entre otras cosas, accesos a Registry Keys, procesos y archivos protegidos, así como acciones bloqueadas. seds.log ayuda a determinar si los drivers y el servicio se han cargado.

Para una limpieza son relevantes SophosCleanup.log y los correspondientes Scan_*.log. Muestran la amenaza detectada, la acción ejecutada, la comprobación de Safestore y la duración. Antes de restaurar desde Safestore se aclara si el archivo es seguro y por qué fue detectado.

Una única entrada de log todavía no justifica una autorización. Solo se crea una excepción después de comprobar archivo, editor, hash, reputación y necesidad empresarial.

Con Splashtop Streamer 3.5.6.0, numerosos logs que rotan y cambian de nombre rápidamente pueden llenar la cola de análisis de Sophos y aumentar CPU y RAM. Actualice preferentemente a 3.5.8.0 o posterior y reinicie. Solo si no es posible, evalúe la ruta de log utilizada como exclusión estrecha para el grupo afectado; excluir globalmente todo Splashtop sería excesivo.

Otra causa de CPU alta en SEDService.exe es una regla Sysmon File Delete que archiva archivos .bin bajo C:\ProgramData\Sophos. Sysmon y Endpoint Defense entran en conflicto al acceder a los archivos comprimidos de Event Journals; sed.log muestra referencias repetidas a la ruta de archivado de Sysmon. Excluya esa estructura de la archivación FileDelete de Sysmon, no del análisis Sophos. Tras recargar Sysmon, SEDService.exe debería procesar los journals abiertos y bajar la carga.

Windows Security Audit Logging: volumen y reversión

Enable additional audit policy logging está activado de forma predeterminada con Sophos Endpoint Core Agent 2026.1 y Sophos Server Core Agent 2026.1. La lista de eventos adicionales de auditoría de Windows, que no se puede configurar individualmente, mejora los datos para la detección y Threat Hunting. Estos eventos se encuentran en el Windows Security Event Log, no en un log de texto de Sophos bajo C:\ProgramData\Sophos. La correspondencia y la reversión descritas aquí se aplican a Endpoints Windows y Windows Server; no describen una función de Linux.

La política aplicada de forma efectiva se gestiona para Endpoint en Threat Protection y para Server en Server Threat Protection. Un mayor volumen de eventos no constituye por sí solo un fallo de protección. Antes de desactivar la función, se comprueban la retención de logs y el procesamiento en el SIEM, ya que disponer de menos datos de auditoría limita la investigación de ataques posteriores.

Asignar los eventos a las subcategorías de auditoría

La tabla indica las subcategorías de Windows en inglés. En un Windows en alemán, los nombres pueden ser distintos; para los comandos locales se utiliza el GUID obtenido más abajo. Los ID indican una correspondencia, no un plan de pruebas: no todas las funciones de servidor ni todas las actividades generan todos los eventos. Para las comprobaciones, utilice actividad operativa existente y autorizada; no realice cambios en cuentas, tareas o servicios únicamente para una prueba.

Estado previo, retención y conservación de evidencias

Antes de un cambio planificado, documente por dispositivo el nombre y la asignación de la política, la versión de Core Agent, la función del servidor, la hora del cambio con zona horaria y los responsables. Para cada subcategoría afectada, registre por separado la supervisión de aciertos y errores y determine si alguna GPO, una configuración de referencia de seguridad u otro producto la exige. Si la función ya está activa, una nueva copia de seguridad solo documenta el estado actual, no necesariamente el estado anterior al cambio de Sophos. Sin una configuración anterior fiable y la autorización del responsable, no desactive ninguna subcategoría por conjetura.

Los siguientes comandos están previstos para un símbolo del sistema de Windows abierto como administrador. Leen configuraciones o escriben un archivo de copia de seguridad; no modifican los ajustes de auditoría. C:\Audit-Sicherung es un ejemplo de directorio que debe crearse previamente, con acceso protegido y suficiente espacio libre. Utilice un nombre de archivo nuevo para cada captura, de modo que se conserve el estado previo.

auditpol /get /category:* /r
auditpol /list /subcategory:* /v
auditpol /backup /file:"C:\Audit-Sicherung\audit-vorher.csv"
wevtutil gl Security
wevtutil gli Security

La copia de seguridad CSV recoge los ajustes de auditoría del sistema y de los usuarios, así como las opciones de auditoría; no sustituye a una copia de seguridad de las GPO. Guarde la salida de las consultas junto con el registro del cambio. Para la comparación posterior, anote el GUID de la subcategoría concreta obtenido de la lista, junto con su nombre mostrado localmente.

wevtutil gl Security muestra, entre otros datos, el tamaño máximo, la ruta del log y el modo de retención; wevtutil gli Security muestra el estado del log. En el Visor de eventos de Windows, compruebe el log Security: anote la marca de tiempo más antigua que aún se conserva, los eventos del intervalo de comparación definido y los ID predominantes. Antes y después del cambio, bajo una carga comparable, compare el número de eventos por intervalo, el periodo disponible localmente, el espacio libre y la tasa de entrada, el retraso y los eventos descartados en el SIEM. En un log circular, el tamaño del archivo por sí solo no indica cuánto historial sigue disponible.

Con retention:false, los eventos nuevos sobrescriben los más antiguos cuando se alcanza el tamaño máximo. Con retention:true sin copia de seguridad automática, al alcanzar ese límite se descartan los eventos nuevos. autoBackup:true requiere retention:true; los archivos históricos siguen necesitando espacio y una retención controlada. Por tanto, no reduzca el tamaño del log de forma indiscriminada ni confunda «no sobrescribir» con una retención ilimitada. Coordine los cambios de tamaño máximo, modo de retención o archivado con los responsables de Windows y del SIEM, y documente previamente los tres valores iniciales. Durante la reversión, restaure exactamente esos valores mediante la configuración local o de GPO que los controla y compruébelos con wevtutil gl Security. Esto no recupera los eventos que ya se hayan sobrescrito o descartado.

Antes de una intervención, exporte los eventos relevantes; no vacíe el log Security. Utilice también para ello un nombre de archivo nuevo y un destino protegido con espacio suficiente:

wevtutil epl Security "C:\Audit-Sicherung\Security-vorher.evtx"

Abra el archivo exportado en el Visor de eventos y compruebe el periodo requerido. Los datos de auditoría pueden contener información de usuarios, cuentas y actividades; limite en consecuencia el acceso, la transferencia y la retención.

Reversión selectiva tras desactivar la política

Primero desactive Enable additional audit policy logging en la política Endpoint o Server Threat Protection realmente aplicada, guarde y compruebe la recepción de la política en el dispositivo. Los ajustes de auditoría de Windows ya activados se mantienen y, si es necesario, deben revertirse manualmente. No elimine toda la política de auditoría: eso también afectaría a ajustes necesarios con independencia de Sophos. Tampoco restaure a ciegas una copia de seguridad CSV completa, ya que pueden haberse realizado cambios legítimos desde su captura.

Solo con la autorización de los responsables de Windows y de seguridad, restablezca individualmente las subcategorías cuya afectación esté demostrada a sus valores previos acreditados. El siguiente ejemplo modifica la configuración y solo es aplicable si antes la supervisión de aciertos estaba activa y la de errores estaba inactiva. Sustituya <GUID> por el GUID completo de la subcategoría obtenido anteriormente, incluidos los caracteres {...}; el marcador de posición no es ejecutable. Antes de establecer los valores, vuelva a consultar el estado local:

auditpol /get /subcategory:"<GUID>"
auditpol /set /subcategory:"<GUID>" /success:enable /failure:disable
auditpol /get /subcategory:"<GUID>"

Para otros estados previos acreditados, seleccione ambos valores de forma independiente: enable mantiene o activa la rama correspondiente y disable la desactiva. Solo si ambas ramas estaban desactivadas previamente y ninguna otra directriz vigente las requiere, deben desactivarse las dos para esa subcategoría concreta. Una subcategoría puede controlar más eventos que los ID indicados aquí; el cambio no es un filtro para Event IDs individuales.

Después de cada cambio, compare los valores esperados y reales; más adelante, tras la actualización habitual de las GPO o de los productos, vuelva a consultarlos y compruebe el flujo de eventos necesario y el volumen de logs y del SIEM. Si los valores vuelven a activarse, determine primero qué GPO u otro producto de seguridad los controla; no intente contrarrestarlo repetidamente de forma local. Si siguen sin estar claros el estado previo, la responsabilidad o la recepción de la política de Sophos, detenga la reversión y escale los hallazgos sobre la política, el agente, la auditoría y el volumen. Si se desea restablecer la visibilidad adicional, vuelva a activar la opción de Sophos y, tras su recepción, compruebe el estado de auditoría y el flujo de eventos; esto no rellena las lagunas de datos producidas durante ese intervalo.

Evaluar correctamente los servicios

Self Help distingue entre Windows SCM Services y Sophos SCM Services. Solo el primer grupo está registrado en Windows Service Control Manager y aparece en services.msc. Los Sophos SCM Services se ejecutan como procesos, pero no aparecen allí. En plataformas modernas, Sophos Live Query, Sophos Health Service y Sophos System Protection Service pasaron al segundo grupo desde Core Agent 2025.2. Por tanto, la ausencia de una entrada en services.msc no demuestra por sí sola un error de instalación.

Sophos describe esta consolidación de 2025.2.1 como una optimización del rendimiento. Aun así, el diagnóstico debe seguir la versión instalada de Core Agent y el artículo de Self Help correspondiente: el artículo Services actual está indicado expresamente para Core Agent 2026.1 y otros paquetes pueden requerir otro procedimiento. Compruebe primero el estado en Self Help, que también indica si el servicio se gestiona mediante Windows SCM o Sophos SCM. Sus procedimientos de reparación requieren derechos de administrador y Tamper Protection desactivado; no los ejecute únicamente porque una lista antigua de servicios sea distinta.

En Core Agent 2025.x, este caso excepcional puede aparecer tras un feature update de Windows 11 de 23H2 a 24H2 o 25H2 fallido con rollback. Una actualización simultánea de DecisionCache puede desalinear registro y archivos. El Endpoint pasa a rojo, System Protection no arranca y C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log informa de una Rules-Version ausente.

No espere hasta 96 horas sin System Protection. Asigne temporalmente una Update Management Policy con un paquete FTS o LTS compatible. La reinstalación que esto desencadena vuelve a alinear las referencias. Retire la Policy solo con Health verde, componente activo y SSP log actual. Una corrección manual del registro exige Tamper Protection Override, backup y el directorio de reglas exactamente correspondiente.

La lista oficial de componentes y servicios incluye las asociaciones siguientes. La tabla sirve de ayuda para el diagnóstico, no es una lista completa del estado esperado en todos los dispositivos:

Los componentes que deben estar presentes dependen de la plataforma, Agent Mode y licencia. Por ejemplo, un XDR Sensor instala componentes de telemetría, pero no una protección completa contra malware de Sophos. Primero se determina el estado esperado en Central y solo después se compara con servicios y procesos.

Protección de red y web

SophosNetFilter.log contiene conexiones web y acciones de Web Control y de la comprobación web en tiempo real. SophosIPS.log muestra la configuración y los contenidos de detección de la protección frente a amenazas de red. SntpService.log incluye información sobre Isolation y otras funciones de red.

Ante una página web bloqueada se comparan momento, URL, proceso y política efectiva. El log no siempre indica si Endpoint Web Control, DNS Protection o un firewall anterior bloquearon primero. Estos puntos de control se comprueban por separado.

Interfaz de usuario y Self Help

En versiones actuales de Core Agent, SophosUI.Net.log y SophosUITray.log se encuentran en:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

Documentan acciones en la interfaz local o en el icono de la barra de tareas. Desde Core Agent 2026.1, algunos logs de Self Help también pueden encontrarse por usuario en %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. El directorio global del equipo en C:\ProgramData\Sophos\Endpoint Self Help\Logs sigue siendo relevante según el componente.

Analizar correctamente un log

Antes de abrirlo se define un intervalo de error limitado con zona horaria. Después se lee desde el primer error relevante hacia adelante. Los errores posteriores como service unavailable, timeout o component unhealthy suelen ser solo consecuencias.

Una nota fiable incluye:

• síntoma visible y prueba reproducible,
• nombre del log, timestamp y primer mensaje relevante,
• ruta de Endpoint, Proxy, Cache o Relay implicada,
• comparación con un dispositivo funcional,
• cambio probado y resultado medible.

El nivel de logging no se eleva de forma preventiva y permanente. El logging detallado de MCS puede contener datos de comunicación sensibles y consumir almacenamiento adicional. Solo se activa durante un intervalo definido según la documentación actual de Sophos y después se restablece.

Sophos Support puede solicitar un diagnostic message trail para MCS. En Windows 10 x64 o Server 2016 y posteriores está activo por defecto desde Core Agent 2023.2; los pasos XML para activarlo y después desactivarlo solo corresponden a plataformas Legacy. Los archivos del trail pueden contener políticas y datos de comunicación y deben transferirse protegidos junto con la SDU. Desactive una captura Legacy al terminar, ya que de lo contrario puede llenar el disco.

Guardar logs para soporte

Los logs individuales ayudan a delimitar el problema localmente. Para una escalación también se crea una recopilación SDU del mismo intervalo de error. El paquete puede contener nombres de host, usuarios, rutas, direcciones IP y datos de configuración, por lo que se transmite de forma protegida.

La recopilación completa se explica en Diagnosticar Sophos Endpoint con Self Help y SDU. Los errores de instalación se tratan por separado en Solucionar sistemáticamente errores de instalación de Sophos Endpoint en Windows.

Preguntas frecuentes