Analisar Logs e serviços Sophos Endpoint no Windows

No Windows, Sophos Endpoint é composto por vários componentes de proteção, Update e comunicação. Um Health State vermelho não significa automaticamente que todo o agente falhou. Para um diagnóstico fiável, associa-se primeiro o sintoma a um componente e só depois se analisa o respetivo Log no período correto.

A maioria dos Operating Logs encontra-se em C:\ProgramData\Sophos. Os Installation Logs estão normalmente em C:\Windows\Temp, C:\Windows\SystemTemp ou no %TEMP% da conta que iniciou o Installer. Em versões recentes do Core Agent, alguns User Interface Logs encontram-se em %LOCALAPPDATA%.

Procedimento rápido:

1. Registe a hora do incidente, o fuso horário e o sintoma visível.
2. Em Sophos Endpoint Agent > About > Open Endpoint Self Help Tool, verifique primeiro Services e Components.
3. Registe a plataforma, versão do Core Agent e componentes instalados; licença e Agent Mode determinam o estado esperado.
4. Selecione o Log relevante abaixo e leia a partir do primeiro erro pertinente.
5. Após uma correção, atualize o Self Help e repita o mesmo teste. Para escalada, guarde também uma SDU do mesmo período.

Em Computer details > Status, o Central separa o estado geral em Communication, Operations, Services, System, Threat e Update. Os detalhes Good, Warning, Bad e Info podem variar consoante o sistema operativo e a versão do agente. Por isso, relacione sempre a categoria afetada com o componente exato no Endpoint Self Help, em vez de concluir que um serviço falhou apenas com base na cor geral.

Do sintoma ao Log correto

Os nomes dos ficheiros e as associações de serviços podem mudar com a versão do Core Agent. Antes da avaliação, compare a versão do pacote instalado com a visão geral das atualizações do Sophos Endpoint e das alterações de componentes; para o diagnóstico propriamente dito, use os componentes correspondentes à versão instalada e os ficheiros efetivamente existentes no dispositivo afetado.

Updates e AutoUpdate

SophosUpdate.log é o Log principal para o processo de Update. Nas versões Windows atualmente suportadas, sau-service.log mostra quando o Central ou uma alteração à Update Policy ou Communication Policy iniciou um Update. SophosLaunchUpdate.log documenta o início do Update Workflow.

Um Update Error não é avaliado apenas pela última linha de erro. Verifica-se primeiro:

1. qual foi o Update Target efetivamente utilizado;
2. se estiveram envolvidos acesso direto, Proxy ou Update Cache;
3. qual foi o primeiro erro HTTP ou TLS;
4. se o mesmo momento aparece no Firewall Log ou Proxy Log.

Entradas inválidas no ficheiro Windows Hosts podem encaminhar Sophos Targets para um endereço incorreto. Em erros reproduzíveis, comparam-se SophosUpdate.log, DNS, Proxy e um Packet Capture simultâneo.

O clássico Sophos AutoUpdate Service já não existe no Windows moderno. Se faltar numa plataforma Legacy expressamente suportada, repare com direitos de administrador o AutoUpdate MSI em cache e volte a executar About > Update Now. Este procedimento MSI antigo não se aplica ao Windows 10 x64, Windows Server 2016 ou posteriores.

Comunicação com o Central e Policies

O Sophos MCS Client mantém a ligação ao Sophos Fusion (anteriormente Sophos Central). McsClient.log indica se o Endpoint consegue chegar ao Central. McsAgent.log mostra depois que Policies e comandos foram processados. Uma hora recente em Last Active no Central é um bom indicador de MCS funcional, mas é atualizada, no máximo, aproximadamente uma vez por hora.

Perante um Communication Error, verificam-se Broker Address, DNS, Routing, Proxy e Firewall. Após a correção, pode reiniciar-se o serviço Sophos MCS Client e atualizar Endpoint Self Help. Tamper Protection só é desativada se a intervenção concreta o exigir.

Proteção, bloqueios e Cleanup

sed.log é o Operating Log principal do Sophos Endpoint Defense. Inclui acessos a Registry Keys, Processes e Files protegidos, além de ações bloqueadas. seds.log ajuda a determinar se Drivers e Service foram carregados.

Para Cleanup, são relevantes SophosCleanup.log e os respetivos Scan_*.log. Mostram Threat detetada, ação executada, verificação do Safestore e duração. Antes de restaurar a partir do Safestore, esclarece-se se o ficheiro é seguro e porque foi detetado.

Uma entrada de Log isolada não justifica uma autorização. Só se cria uma Exception depois de verificar File, Publisher, Hash, Reputation e Business Need.

No Splashtop Streamer 3.5.6.0, muitos logs que rodam e mudam rapidamente de nome podem encher a fila de análise Sophos e aumentar CPU e RAM. Atualize preferencialmente para 3.5.8.0 ou posterior e reinicie. Apenas se isso for impossível, avalie o caminho de log realmente usado como exceção restrita para o grupo; excluir todo o Splashtop seria demasiado amplo.

Outra causa de CPU elevada em SEDService.exe é uma regra Sysmon File Delete que arquiva ficheiros .bin em C:\ProgramData\Sophos. sed.log referencia então repetidamente o arquivo Sysmon. Exclua essa estrutura da arquivação FileDelete do Sysmon, não da análise Sophos. Após recarregar o Sysmon, SEDService.exe deve processar os journals abertos e reduzir a carga.

Windows Security Audit Logging: volume e reversão

Enable additional audit policy logging está ativado por predefinição com Sophos Endpoint Core Agent 2026.1 e Sophos Server Core Agent 2026.1. A lista de eventos adicionais de auditoria do Windows, que não pode ser configurada individualmente, melhora os dados disponíveis para deteção e Threat Hunting. Estes eventos encontram-se no Windows Security Event Log, não num Log de texto Sophos em C:\ProgramData\Sophos. O mapeamento e a reversão aqui descritos aplicam-se a Endpoints Windows e a Windows Server; não descrevem uma funcionalidade Linux.

A Policy efetivamente aplicada é gerida em Threat Protection para Endpoint e em Server Threat Protection para servidores. Um volume superior de eventos, por si só, não constitui uma falha de proteção. Antes de desativar a funcionalidade, verifique a retenção dos Logs e o processamento no SIEM, pois menos dados de auditoria limitam a investigação de ataques posteriores.

Associar eventos às subcategorias de auditoria

A tabela apresenta as subcategorias Windows em inglês. Num Windows em alemão, os nomes podem ser diferentes; para os comandos locais, utilize a GUID identificada abaixo. As IDs constituem um mapeamento, não um plano de testes: nem todas as funções de servidor ou atividades geram todos os eventos. Para verificar, utilize atividade operacional existente e autorizada; não efetue alterações a contas, tarefas ou serviços apenas para um teste.

Estado anterior, retenção e preservação de provas

Antes de uma alteração planeada, documente, por dispositivo, o nome e a atribuição da Policy, a versão do Core Agent, a função do servidor, a hora da alteração com o fuso horário e os responsáveis. Para cada subcategoria afetada, registe separadamente a monitorização de sucessos e falhas e esclareça se é exigida por GPOs, por uma configuração de base de segurança ou por outro produto. Se a funcionalidade já estiver ativa, uma nova cópia de segurança documenta apenas o estado atual, não necessariamente o estado anterior à alteração da Sophos. Sem uma configuração anterior fiável e a autorização do responsável, não desative nenhuma subcategoria com base em suspeitas.

Os comandos seguintes destinam-se a uma Linha de Comandos do Windows aberta como administrador. Leem configurações ou gravam um ficheiro de cópia de segurança; não alteram definições de auditoria. C:\Audit-Sicherung é um exemplo de diretório a criar previamente, com acesso protegido e espaço livre suficiente. Utilize um novo nome de ficheiro para cada recolha, para preservar o estado anterior.

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

A cópia de segurança CSV inclui as definições de auditoria do sistema e específicas dos utilizadores, bem como as opções de auditoria; não substitui uma cópia de segurança das GPOs. Guarde a saída das consultas juntamente com o registo da alteração. Para comparação posterior, registe a GUID da subcategoria concreta apresentada na lista, juntamente com o nome exibido localmente.

wevtutil gl Security mostra, entre outros dados, o tamanho máximo, o caminho do Log e o modo de retenção; wevtutil gli Security mostra o estado do Log. No Visualizador de Eventos do Windows, verifique o Log Security: registe a data e hora mais antigas ainda presentes, os eventos na janela de comparação definida e as IDs predominantes. Antes e depois da alteração, sob uma carga comparável, compare o número de eventos por janela temporal, o período disponível localmente, o espaço livre e a taxa de entrada, o atraso e os eventos descartados no SIEM. Num Log circular, o tamanho do ficheiro, por si só, não indica quanto histórico ainda está disponível.

Com retention:false, os novos eventos substituem os mais antigos quando o tamanho máximo é atingido. Com retention:true sem cópia de segurança automática, os novos eventos são então descartados. autoBackup:true exige retention:true; os arquivos continuam a necessitar de espaço e de uma retenção controlada. Por isso, não reduza indiscriminadamente o tamanho do Log nem confunda «não substituir» com retenção ilimitada. Coordene as alterações ao tamanho máximo, ao modo de retenção ou à criação de arquivos com os responsáveis de Windows/SIEM e documente previamente os três valores iniciais. Na reversão, reponha exatamente esses valores através do mecanismo de configuração local ou de GPO responsável e confirme-os com wevtutil gl Security. Os eventos já substituídos ou descartados não são recuperados desta forma.

Antes de uma intervenção, exporte os eventos relevantes; não limpe o Security Log. Também aqui, utilize um novo nome de ficheiro e um destino protegido com espaço suficiente:

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

Abra o ficheiro exportado no Visualizador de Eventos e confirme o período necessário. Os dados de auditoria podem conter informações sobre utilizadores, contas e atividades; limite o acesso, a transferência e a retenção em conformidade.

Reversão seletiva após a desativação da Policy

Primeiro, desative Enable additional audit policy logging na Endpoint ou Server Threat Protection Policy efetivamente aplicada, guarde e confirme a receção da Policy no dispositivo. As definições de auditoria do Windows já ativadas permanecem em vigor e, se necessário, têm de ser revertidas manualmente. Não elimine toda a política de auditoria: isso também afetaria definições necessárias independentemente da Sophos. Do mesmo modo, não restaure cegamente uma cópia de segurança CSV completa, pois podem ter ocorrido alterações legítimas desde a sua recolha.

Só após autorização dos responsáveis de Windows/segurança, reponha individualmente as subcategorias comprovadamente afetadas nos respetivos valores anteriores documentados. O seguinte exemplo que altera definições aplica-se exclusivamente quando a monitorização de sucessos estava anteriormente ativa e a monitorização de falhas estava inativa. Substitua integralmente <GUID> pela GUID da subcategoria identificada, incluindo {...}; o marcador não é executável. Antes de definir os valores, consulte-os novamente localmente:

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

Para outros estados anteriores comprovados, escolha os dois valores de forma independente: enable mantém ou ativa a vertente correspondente, enquanto disable a desativa. Só se ambas as vertentes estavam anteriormente desativadas e nenhuma outra exigência em vigor as requer é que ambas devem ser desativadas nessa subcategoria concreta. Uma subcategoria pode controlar mais eventos do que as IDs aqui indicadas; a alteração não é um filtro para Event IDs individuais.

Após cada alteração, compare os valores esperados e efetivos; mais tarde, após a atualização regular das GPOs ou dos produtos, volte a consultá-los e verifique o fluxo de eventos necessário e o volume dos Logs e do SIEM. Se os valores voltarem a ser ativados, esclareça primeiro qual é a GPO ou o outro produto de segurança que os controla — não contrarie repetidamente essa configuração a nível local. Se o estado anterior, a responsabilidade ou a receção da Sophos Policy continuarem por esclarecer, pare a reversão e escale os resultados relativos à Policy, ao agente, à auditoria e ao volume. Para restabelecer a visibilidade adicional, volte a ativar a opção Sophos e, após a receção, verifique o estado da auditoria e o fluxo de eventos; isto não preenche uma lacuna de dados ocorrida entretanto.

Avaliar corretamente os serviços

O Self Help distingue Windows SCM Services e Sophos SCM Services. Apenas o primeiro grupo está registado no Windows Service Control Manager e aparece em services.msc. Os Sophos SCM Services funcionam como processos, mas não aparecem nessa consola. Em plataformas modernas, Sophos Live Query, Sophos Health Service e Sophos System Protection Service passaram para o segundo grupo a partir do Core Agent 2025.2. A ausência de uma entrada em services.msc não prova, por si só, um erro de instalação.

A Sophos descreve esta consolidação em 2025.2.1 como otimização de desempenho. O diagnóstico deve, ainda assim, seguir a versão instalada do Core Agent e o artigo Self Help correspondente: o artigo Services atual está explicitamente marcado para Core Agent 2026.1 e outros pacotes podem exigir outro procedimento. Verifique primeiro o estado no Self Help, que também indica se o serviço é gerido por Windows SCM ou Sophos SCM. Os procedimentos de reparação exigem direitos de administrador e Tamper Protection desativada; não os execute apenas porque uma lista antiga de serviços é diferente.

No Core Agent 2025.x, este caso raro pode ocorrer após um Windows 11 feature update de 23H2 para 24H2 ou 25H2 falhado com rollback. Um update simultâneo do DecisionCache pode desalinhar o registo e os ficheiros. O Endpoint fica vermelho, System Protection não arranca e C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log indica uma versão de regras em falta.

Não aguarde até 96 horas sem System Protection. Atribua temporariamente uma Update Management Policy com pacote FTS ou LTS suportado. Remova o dispositivo da Policy de reparação apenas depois de confirmar Health verde, o componente ativo e um registo SSP atual. A correção manual do registo exige Tamper Protection Override, backup e o diretório de regras exatamente correspondente.

A lista oficial de componentes e serviços inclui as associações seguintes. A tabela é uma ajuda ao diagnóstico, não uma lista completa do estado esperado em todos os dispositivos:

Os componentes que têm de estar presentes dependem da plataforma, Agent Mode e licença. Um XDR Sensor instala, por exemplo, componentes de Telemetry, mas não proteção Sophos completa contra malware. O estado esperado é primeiro determinado no Central e só depois comparado com Services e Processes.

Proteção de rede e Web

SophosNetFilter.log contém Website Connections e ações de Web Control e Internet Real-Time Scanning. SophosIPS.log mostra a configuração e o Detection Content da Network Threat Protection. SntpService.log inclui informação sobre Isolation e outras Network Functions.

Numa Website bloqueada, comparam-se hora, URL, Process e Effective Policy. O Log nem sempre permite determinar se Endpoint Web Control, DNS Protection ou uma Firewall a montante bloqueou primeiro. Estes pontos de controlo são verificados separadamente.

User Interface e Self Help

Em versões atuais do Core Agent, SophosUI.Net.log e SophosUITray.log encontram-se em:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

Documentam ações na interface local e no Taskbar Icon. Desde o Core Agent 2026.1, os Self Help Logs também podem estar associados ao utilizador em %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. Consoante o componente, o diretório do computador em C:\ProgramData\Sophos\Endpoint Self Help\Logs também continua relevante.

Analisar corretamente um Log

Antes de abrir o Log, define-se um intervalo de erro restrito com Time Zone. Depois, lê-se para a frente a partir do primeiro erro relevante. Erros subsequentes como service unavailable, timeout ou component unhealthy são frequentemente apenas consequências.

Uma nota fiável contém:

• sintoma visível e teste reproduzível;
• nome do Log, Timestamp e primeira mensagem relevante;
• percurso Endpoint, Proxy, Cache ou Relay envolvido;
• comparação com um dispositivo funcional;
• alteração testada e resultado mensurável.

O Log Level não é aumentado preventivamente de forma permanente. O MCS Logging detalhado pode conter dados de comunicação sensíveis e ocupar espaço adicional. Só é ativado durante um período definido segundo as instruções atuais da Sophos e depois reposto.

O Sophos Support pode pedir um diagnostic message trail para MCS. No Windows 10 x64 ou Server 2016 e posteriores está ativo por predefinição desde Core Agent 2023.2; os passos XML para o ativar e depois desativar aplicam-se apenas a plataformas Legacy. Os ficheiros do trail podem conter Policies e dados de comunicação e devem ser transferidos de forma protegida com a SDU. Desative uma recolha Legacy depois da captura, pois, caso contrário, pode encher o disco.

Guardar Logs para o suporte

Logs individuais ajudam no diagnóstico local. Para uma escalada, cria-se também uma recolha SDU do mesmo período. O pacote pode conter Hostnames, Users, Paths, IP Addresses e Configuration Data e deve ser transmitido com a proteção adequada.

A recolha completa é explicada em Diagnosticar Sophos Endpoint com Self Help e SDU. Os Installation Errors são tratados separadamente em Resolver sistematicamente a instalação do Sophos Endpoint no Windows.

Perguntas frequentes