Analyser les Logs et services Sophos Endpoint Windows

Sous Windows, Sophos Endpoint se compose de plusieurs éléments de protection, d’Update et de communication. Un Health State rouge ne signifie pas automatiquement que tout l’agent est en panne. Pour obtenir un diagnostic fiable, le symptôme est d’abord associé à un composant, puis seul son Log est analysé dans la période appropriée.

La plupart des Logs d’exploitation se trouvent sous C:\ProgramData\Sophos. Les Logs d’installation se trouvent généralement sous C:\Windows\Temp, C:\Windows\SystemTemp ou dans le %TEMP% du compte qui a lancé l’Installer. Depuis les versions récentes du Core Agent, certains Logs de l’interface utilisateur se trouvent sous %LOCALAPPDATA%.

Procédure rapide :

1. Noter l’heure de l’incident, le fuseau horaire et le symptôme visible.
2. Dans Sophos Endpoint Agent > About > Open Endpoint Self Help Tool, contrôler d’abord Services et Components.
3. Noter la plateforme, la version du Core Agent et les composants installés ; la licence et l’Agent Mode déterminent l’état attendu.
4. Sélectionner le Log approprié ci-dessous et le lire à partir de la première erreur pertinente.
5. Après correction, actualiser Self Help et répéter le même test. Pour une escalade, conserver aussi une SDU de la même période.

Sous Computer details > Status, Central répartit l’état général entre Communication, Operations, Services, System, Threat et Update. Les détails Good, Warning, Bad et Info peuvent varier selon le système d’exploitation et la version de l’agent. Il faut donc toujours corréler la catégorie concernée avec le composant exact dans Endpoint Self Help, plutôt que de conclure à la défaillance d’un service sur la seule base de la couleur générale.

Du symptôme au Log approprié

Les noms de fichiers et l’affectation des services peuvent changer selon la version du Core Agent. Avant de les évaluer, comparez la version du package installé à la présentation des mises à jour de Sophos Endpoint et des changements de composants ; pour le diagnostic proprement dit, référez-vous aux composants correspondant à la version installée et aux fichiers réellement présents sur l’appareil concerné.

Updates et AutoUpdate

SophosUpdate.log est le Log principal du processus d’Update. Sur les versions Windows actuellement prises en charge, sau-service.log indique quand Central ou une modification de l’Update Policy ou de la Communication Policy a déclenché une mise à jour. SophosLaunchUpdate.log documente le début de l’Update Workflow.

Une Update Error n’est pas évaluée uniquement à partir de la dernière ligne d’erreur. Il faut d’abord vérifier :

1. quel Update Target a réellement été utilisé,
2. si l’accès direct, un Proxy ou un Update Cache était impliqué,
3. quelle a été la première erreur HTTP ou TLS,
4. si la même heure apparaît dans le Firewall Log ou le Proxy Log.

Des entrées non valides dans le fichier Hosts de Windows peuvent diriger les cibles Sophos vers une mauvaise adresse. Pour les erreurs reproductibles, SophosUpdate.log, le DNS, le Proxy et un Packet Capture simultané sont comparés.

Le classique Sophos AutoUpdate Service n’existe plus sous Windows moderne. S’il manque sur une plateforme Legacy explicitement prise en charge, réparez avec des droits administrateur le MSI AutoUpdate en cache, puis relancez About > Update Now. Cette ancienne procédure MSI ne s’applique pas à Windows 10 x64, Windows Server 2016 ou versions ultérieures.

Communication avec Central et Policies

Le Sophos MCS Client maintient la connexion à Sophos Fusion (anciennement Sophos Central). McsClient.log indique si l’Endpoint peut atteindre Central. McsAgent.log montre ensuite quelles Policies et commandes ont été traitées. Une heure récente sous Last Active dans Central est un bon indicateur du fonctionnement de MCS, mais elle n’est actualisée qu’environ une fois par heure au maximum.

En cas de Communication Error, le Broker Address, le DNS, le Routing, le Proxy et la Firewall sont vérifiés. Après correction, le service Sophos MCS Client peut être redémarré et Endpoint Self Help actualisé. Tamper Protection n’est désactivée que si l’intervention concrète l’exige.

Protection, blocages et Cleanup

sed.log est le principal Log d’exploitation de Sophos Endpoint Defense. Il contient les accès aux clés de registre, processus et fichiers protégés ainsi que les actions bloquées. seds.log aide à déterminer si les Drivers et le Service ont été chargés.

Pour le Cleanup, SophosCleanup.log et les fichiers Scan_*.log associés sont pertinents. Ils montrent la Threat détectée, l’action exécutée, la vérification du Safestore et la durée. Avant une restauration depuis le Safestore, il faut déterminer si le fichier est sûr et pourquoi il a été détecté.

Une entrée de Log isolée ne justifie pas une autorisation. Une Exception n’est créée qu’après vérification du fichier, de l’éditeur, du hachage, de la réputation et du besoin métier.

Avec Splashtop Streamer 3.5.6.0, de nombreux logs rapidement renouvelés et renommés peuvent remplir la file d’analyse Sophos et accroître CPU et RAM. Passez de préférence à 3.5.8.0 ou version ultérieure, puis redémarrez. Seulement si cela est impossible, évaluez le chemin de log utilisé comme exception étroite pour le groupe concerné ; exclure tout Splashtop serait trop large.

Une autre cause de CPU élevée de SEDService.exe est une règle Sysmon File Delete archivant les fichiers .bin sous C:\ProgramData\Sophos. sed.log fait alors référence à plusieurs reprises à l’archive Sysmon. Excluez cette structure de l’archivage FileDelete Sysmon, et non de l’analyse Sophos. Après rechargement de Sysmon, SEDService.exe doit traiter les journaux ouverts et la charge diminuer.

Windows Security Audit Logging : volume et retour arrière

Enable additional audit policy logging est activé par défaut avec Sophos Endpoint Core Agent 2026.1 et Sophos Server Core Agent 2026.1. La liste des événements d’audit Windows supplémentaires, qui ne sont pas configurables individuellement, enrichit les données utiles à la détection et au Threat Hunting. Ces événements figurent dans le Windows Security Event Log, et non dans un Log texte Sophos sous C:\ProgramData\Sophos. Les correspondances et la procédure de retour arrière décrites ici s’appliquent aux Endpoints Windows et à Windows Server ; elles ne concernent pas une fonction Linux.

La stratégie effectivement appliquée se gère dans Threat Protection pour l’Endpoint et dans Server Threat Protection pour le serveur. Un volume d’événements plus élevé ne constitue pas, à lui seul, une défaillance de protection. Avant toute désactivation, vérifier la conservation des Logs et le traitement SIEM, car une réduction des données d’audit limite l’analyse des attaques ultérieures.

Associer les événements aux sous-catégories d’audit

Le tableau utilise les noms anglais des sous-catégories Windows. Sur un Windows en allemand, les noms peuvent être différents ; pour les commandes locales, utiliser le GUID déterminé ci-dessous. Les IDs établissent des correspondances, pas un plan de test : chaque rôle de serveur ou activité ne génère pas nécessairement tous les événements. Pour les vérifications, utiliser l’activité opérationnelle existante et autorisée, sans déclencher de modifications de comptes, de tâches ou de services uniquement à des fins de test.

État antérieur, conservation et préservation des preuves

Avant une modification planifiée, documenter pour chaque appareil le nom et l’affectation de la stratégie, la version du Core Agent, le rôle du serveur, l’heure de la modification avec le fuseau horaire et les responsables. Pour chaque sous-catégorie concernée, consigner séparément la surveillance des réussites et celle des échecs et déterminer si des GPO, une configuration de sécurité de référence ou un autre produit l’exigent. Si la fonction est déjà active, une nouvelle sauvegarde documente uniquement l’état actuel, pas nécessairement l’état antérieur à la modification de Sophos. Sans configuration antérieure fiable et sans accord du responsable, ne désactiver aucune sous-catégorie sur la base d’un simple soupçon.

Les commandes suivantes sont destinées à une invite de commandes Windows ouverte en tant qu’administrateur. Elles lisent des configurations ou écrivent un fichier de sauvegarde ; elles ne modifient aucun paramètre d’audit. C:\Audit-Sicherung est un exemple de répertoire à créer au préalable, dont l’accès est protégé et qui dispose de suffisamment d’espace libre. Utiliser un nouveau nom de fichier pour chaque collecte afin de préserver l’état antérieur.

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

La sauvegarde CSV contient les paramètres d’audit système et utilisateur ainsi que les options d’audit ; elle ne remplace pas une sauvegarde des GPO. Conserver les résultats des requêtes avec la documentation du changement. Pour les comparaisons ultérieures, relever dans la liste le GUID de la sous-catégorie concernée ainsi que son nom affiché localement.

wevtutil gl Security affiche notamment la taille maximale, le chemin du Log et le mode de conservation ; wevtutil gli Security affiche l’état du Log. Dans l’Observateur d’événements Windows, examiner le Log Security : relever le plus ancien horodatage encore présent, les événements de la période de comparaison définie et les IDs prédominants. Avant et après la modification, sous une charge comparable, comparer le nombre d’événements par période, la période disponible localement, l’espace libre ainsi que le débit d’entrée SIEM, le délai et les événements rejetés. La seule taille du fichier ne permet pas de savoir quelle quantité d’historique subsiste dans un Log circulaire.

Avec retention:false, les nouveaux événements écrasent les plus anciens dès que la taille maximale est atteinte. Avec retention:true sans sauvegarde automatique, les nouveaux événements sont alors rejetés. autoBackup:true exige retention:true ; les archives nécessitent toujours de l’espace et une conservation maîtrisée. Ne pas réduire systématiquement la taille du Log et ne pas confondre « ne pas écraser » avec une conservation illimitée. Coordonner les modifications de la taille maximale, du mode de conservation ou de l’archivage avec les responsables Windows/SIEM et documenter au préalable les trois valeurs initiales. Lors du retour arrière, rétablir exactement ces valeurs par le mécanisme de configuration local ou GPO qui les régit, puis contrôler avec wevtutil gl Security. Les événements déjà écrasés ou rejetés ne sont pas récupérés par cette opération.

Avant toute intervention, exporter les événements pertinents, sans vider le Log Security. Utiliser là aussi un nouveau nom de fichier et une destination protégée disposant de suffisamment d’espace :

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

Ouvrir le fichier exporté dans l’Observateur d’événements et vérifier la période requise. Les données d’audit peuvent contenir des informations sur les utilisateurs, les comptes et les activités ; limiter en conséquence l’accès, le transfert et la conservation.

Retour arrière sélectif après désactivation de la stratégie

Commencer par désactiver Enable additional audit policy logging dans la stratégie Endpoint ou Server Threat Protection réellement appliquée, enregistrer, puis vérifier la réception de la stratégie sur l’appareil. Les paramètres d’audit Windows déjà activés restent en place et doivent, si nécessaire, être rétablis manuellement à leur état antérieur. Ne pas supprimer une stratégie d’audit complète : cela affecterait aussi des paramètres nécessaires indépendamment de Sophos. De même, ne pas restaurer aveuglément une sauvegarde CSV entière, car des modifications légitimes peuvent avoir été apportées depuis sa création.

Uniquement après accord des responsables Windows/sécurité, rétablir individuellement les sous-catégories dont l’impact est démontré à leurs valeurs antérieures attestées. L’exemple suivant modifie la configuration et s’applique exclusivement si la surveillance des réussites était auparavant active et celle des échecs inactive. Remplacer entièrement <GUID> par le GUID de la sous-catégorie déterminé précédemment, y compris {...} ; l’espace réservé n’est pas exécutable. Relire la configuration locale avant de définir les valeurs :

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

Pour d’autres états antérieurs attestés, choisir les deux valeurs indépendamment : enable conserve ou active la surveillance correspondante, disable la désactive. Désactiver les deux uniquement pour cette sous-catégorie si les deux étaient auparavant désactivées et qu’aucune autre exigence applicable ne les impose. Une sous-catégorie peut régir davantage d’événements que les IDs indiqués ici ; la modification n’est pas un filtre ciblant des Event IDs individuels.

Après chaque modification, comparer les valeurs attendues et réelles, les relire ultérieurement après l’actualisation normale des GPO/produits, puis vérifier le flux d’événements requis ainsi que le volume des Logs et du SIEM. Si des valeurs sont réactivées, identifier d’abord la GPO qui les régit ou l’autre produit de sécurité concerné, plutôt que de tenter à répétition de les contrer localement. Si l’état antérieur, la responsabilité ou la réception de la stratégie Sophos restent incertains, arrêter le retour arrière et transmettre pour escalade les constats relatifs à la stratégie, à l’agent, à l’audit et au volume. Pour rétablir la visibilité supplémentaire, réactiver l’option Sophos et, après sa réception, vérifier l’état de l’audit et le flux d’événements ; cela ne comble pas une lacune de données survenue entre-temps.

Évaluer correctement les services

Self Help distingue les Windows SCM Services des Sophos SCM Services. Seul le premier groupe est enregistré dans Windows Service Control Manager et visible dans services.msc. Les Sophos SCM Services s’exécutent comme Processes, mais n’y apparaissent pas. Sur les plateformes modernes, Sophos Live Query, Sophos Health Service et Sophos System Protection Service sont passés dans ce second groupe à partir du Core Agent 2025.2. L’absence d’une entrée dans services.msc ne prouve donc pas à elle seule une erreur d’installation.

Sophos présente cette consolidation de 2025.2.1 comme une optimisation des performances. Le diagnostic doit néanmoins suivre la version installée du Core Agent et l’article Self Help correspondant : l’article Services actuel est explicitement destiné au Core Agent 2026.1, et d’autres packages peuvent nécessiter une autre procédure. Contrôler d’abord l’état dans Self Help, qui indique aussi si le service relève de Windows SCM ou de Sophos SCM. Les procédures de réparation exigent des droits administrateur et la désactivation de Tamper Protection ; ne pas les lancer sur la seule base d’une ancienne liste de services.

Avec le Core Agent 2025.x, ce cas rare peut survenir après l’échec d’un feature update Windows 11 de 23H2 vers 24H2 ou 25H2 avec rollback. Une mise à jour DecisionCache simultanée peut désaligner le registre et les fichiers. L’Endpoint devient rouge, System Protection ne démarre pas et C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log signale une Rules-Version absente.

N’attendez pas jusqu’à 96 heures sans System Protection. Attribuez temporairement une Update Management Policy avec un package FTS ou LTS pris en charge. Retirez la Policy uniquement après un Health vert, un composant actif et un SSP log actuel. Une correction manuelle du registre exige Tamper Protection Override, une sauvegarde et le répertoire de règles exactement correspondant.

La liste officielle des composants et services comprend notamment les correspondances suivantes. Ce tableau facilite le diagnostic, mais ne constitue pas la liste complète attendue sur chaque appareil :

Les composants attendus dépendent de la plateforme, de l’Agent Mode et de la licence. Un XDR Sensor installe par exemple des composants de Telemetry, mais pas une protection Sophos complète contre les logiciels malveillants. L’état attendu est d’abord déterminé dans Central, puis seulement comparé aux Services et Processes.

Protection du réseau et du Web

SophosNetFilter.log contient les connexions aux sites web et les actions de Web Control et d’Internet Real-Time Scanning. SophosIPS.log affiche la configuration et le Detection Content de Network Threat Protection. SntpService.log fournit des informations sur l’Isolation et d’autres Network Functions.

Pour un site web bloqué, l’heure, l’URL, le Process et l’Effective Policy sont comparés. Le Log ne permet pas toujours de déterminer si Endpoint Web Control, DNS Protection ou une Firewall en amont a bloqué en premier. Ces points de contrôle sont vérifiés séparément.

Interface utilisateur et Self Help

Dans les versions actuelles du Core Agent, SophosUI.Net.log et SophosUITray.log se trouvent sous :

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

Ils documentent les actions dans l’interface locale et sur l’icône de la barre des tâches. Depuis le Core Agent 2026.1, les Self Help Logs peuvent aussi être associés à l’utilisateur sous %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. Selon le composant, le répertoire de l’ordinateur sous C:\ProgramData\Sophos\Endpoint Self Help\Logs reste également pertinent.

Analyser correctement un Log

Avant d’ouvrir le Log, une courte période d’erreur avec son fuseau horaire est définie. La lecture se poursuit ensuite à partir de la première erreur pertinente. Les erreurs suivantes comme service unavailable, timeout ou component unhealthy ne sont souvent que des conséquences.

Une note fiable contient :

• le symptôme visible et le test reproductible,
• le nom du Log, le Timestamp et le premier message pertinent,
• le chemin Endpoint, Proxy, Cache ou Relay concerné,
• la comparaison avec un appareil fonctionnel,
• la modification testée et le résultat mesurable.

Le Log Level n’est pas augmenté préventivement de manière permanente. Le logging MCS détaillé peut contenir des données de communication sensibles et occuper de l’espace supplémentaire. Il n’est activé que pendant une période définie selon les instructions Sophos actuelles, puis réinitialisé.

Sophos Support peut demander un diagnostic message trail pour MCS. Sous Windows 10 x64 ou Server 2016 et versions ultérieures, il est actif par défaut depuis Core Agent 2023.2 ; les étapes XML d’activation puis de désactivation concernent uniquement les plateformes Legacy. Les fichiers du trail peuvent contenir des Policies et des données de communication et doivent être transmis de manière protégée avec la SDU. Désactiver une capture Legacy après la collecte, car elle peut sinon remplir le disque.

Conserver les Logs pour le support

Des Logs individuels facilitent le diagnostic local. Pour une escalade, une collecte SDU de la même période est également créée. Le package peut contenir des noms d’hôte, utilisateurs, chemins, adresses IP et données de configuration. Il doit être transmis avec une protection adaptée.

La collecte complète est expliquée dans Diagnostiquer Sophos Endpoint avec Self Help et SDU. Les Installation Errors sont traitées séparément dans Résoudre systématiquement les problèmes d’installation de Sophos Endpoint sous Windows.

Questions fréquentes