Sophos Endpoint Windows-Logs und Dienste richtig auswerten

Ein Sophos Endpoint besteht unter Windows aus mehreren Schutz-, Update- und Kommunikationskomponenten. Ein roter Health State bedeutet deshalb nicht automatisch, dass der gesamte Agent ausgefallen ist. Für eine belastbare Diagnose wird zuerst das Symptom einer Komponente zugeordnet und danach nur deren Log im passenden Zeitfenster geprüft.

Die meisten Betriebslogs liegen unter C:\ProgramData\Sophos. Installationslogs befinden sich dagegen typischerweise unter C:\Windows\Temp, C:\Windows\SystemTemp oder im %TEMP% des Kontos, das den Installer gestartet hat. Einige Benutzeroberflächen-Logs liegen seit neueren Core-Agent-Versionen unter %LOCALAPPDATA%.

Schnellablauf:

1. Fehlerzeit, Zeitzone und sichtbares Symptom notieren.
2. Unter Sophos Endpoint Agent > About > Open Endpoint Self Help Tool zuerst Services und Components prüfen.
3. Plattform, Core-Agent-Version und installierte Komponenten festhalten; Lizenz und Agent Mode bestimmen den Sollzustand.
4. Das passende Log aus der folgenden Zuordnung vom ersten relevanten Fehler an vorwärts lesen.
5. Nach einer Korrektur Self Help aktualisieren und denselben Test wiederholen. Für eine Eskalation zusätzlich eine SDU aus demselben Zeitfenster sichern.

Unter Computer details > Status trennt Central den Gesamtzustand nach Communication, Operations, Services, System, Threat und Update. Die Detailanzeigen Good, Warning, Bad und Info können je nach Betriebssystem und Agent-Version unterschiedlich ausfallen. Deshalb wird die auffällige Kategorie immer mit der exakt betroffenen Komponente in Endpoint Self Help abgeglichen, statt allein aus der Gesamtfarbe auf einen ausgefallenen Dienst zu schliessen.

Vom Symptom zum richtigen Log

Dateinamen und Dienstzuordnungen können sich mit einer Core-Agent-Version ändern. Vor der Bewertung wird die installierte Paketversion mit der Übersicht zu Sophos Endpoint Updates und Komponentenänderungen abgeglichen; für die eigentliche Diagnose sind die zur installierten Version passenden Komponenten und die tatsächlich vorhandenen Dateien auf dem betroffenen Gerät massgebend.

Updates und AutoUpdate

SophosUpdate.log ist das wichtigste Log für den eigentlichen Updateprozess. sau-service.log zeigt bei aktuellen unterstützten Windows-Versionen, wann Central oder eine geänderte Update- beziehungsweise Kommunikationspolicy ein Update ausgelöst hat. SophosLaunchUpdate.log dokumentiert den Start des Updatevorgangs.

Ein Updatefehler wird nicht nur anhand einer letzten Error-Zeile beurteilt. Geprüft werden zuerst:

1. welches Updateziel tatsächlich verwendet wurde,
2. ob direkter Zugriff, Proxy oder Update Cache beteiligt war,
3. welcher HTTP- oder TLS-Fehler zuerst auftrat,
4. ob derselbe Zeitpunkt im Firewall- oder Proxy-Log sichtbar ist.

Ungültige Einträge in der Windows-Hosts-Datei können Sophos-Ziele auf eine falsche Adresse lenken. Bei wiederholbaren Fehlern werden SophosUpdate.log, DNS, Proxy und eine zeitgleiche Paketaufzeichnung miteinander verglichen.

Auf modernen Windows-Plattformen existiert der klassische Sophos AutoUpdate Service nicht mehr. Fehlt er dagegen auf einer ausdrücklich unterstützten Legacy-Plattform, kann die dort gecachte AutoUpdate-MSI mit Administratorrechten repariert und danach über About > Update Now erneut angestossen werden. Dieser alte MSI-Weg wird nicht auf Windows 10 x64, Windows Server 2016 oder neueren Plattformen angewendet.

Central-Kommunikation und Policies

Der Sophos MCS Client hält die Verbindung zu Sophos Fusion (ehemals Sophos Central). McsClient.log beantwortet, ob der Endpoint Central erreicht. McsAgent.log zeigt anschliessend, welche Policies und Kommandos verarbeitet wurden. Ein aktueller Last Active-Zeitpunkt in Central ist ein guter Hinweis auf funktionierendes MCS, wird aber höchstens ungefähr stündlich aktualisiert.

Bei einem Kommunikationsfehler werden Brokeradresse, DNS, Routing, Proxy und Firewall geprüft. Nach einer Korrektur kann der Dienst Sophos MCS Client neu gestartet und Endpoint Self Help aktualisiert werden. Tamper Protection wird dafür nur deaktiviert, wenn der konkrete Eingriff es erfordert.

Schutz, Blockierungen und Cleanup

sed.log ist das zentrale Betriebslog von Sophos Endpoint Defense. Es enthält unter anderem Zugriffe auf geschützte Registry-Schlüssel, Prozesse und Dateien sowie blockierte Aktionen. seds.log hilft festzustellen, ob Treiber und Dienst geladen wurden.

Für eine Bereinigung sind SophosCleanup.log und die zugehörigen Scan_*.log relevant. Sie zeigen erkannte Bedrohung, ausgeführte Aktion, Safestore-Prüfung und Dauer. Vor einer Wiederherstellung aus Safestore wird geklärt, ob die Datei sicher ist und weshalb sie erkannt wurde.

Ein einzelner Logeintrag ist noch kein Freigabegrund. Eine Ausnahme wird erst erstellt, wenn Datei, Herausgeber, Hash, Reputation und geschäftlicher Bedarf geprüft sind.

Ein konkretes Beispiel ist Splashtop Streamer 3.5.6.0: Sehr viele schnell rotierende und umbenannte Logdateien können die Sophos-Scan-Queue füllen und dadurch CPU- sowie RAM-Verbrauch erhöhen. Die bevorzugte Korrektur ist das Update auf Splashtop Streamer 3.5.8.0 oder neuer und ein anschliessender Neustart. Nur wenn das Update vorübergehend unmöglich ist, wird der tatsächlich verwendete Logpfad als eng begrenzte Datei- oder Ordnerausnahme für die betroffene Gruppe geprüft. Eine globale Ausnahme des gesamten Splashtop-Verzeichnisses wäre zu breit.

Eine andere klar erkennbare Ursache für dauerhaft hohe CPU-Last von SEDService.exe ist eine Sysmon-Regel für File-Delete-Ereignisse, die auch .bin-Dateien unter C:\ProgramData\Sophos archivieren möchte. Sysmon und Endpoint Defense geraten dann bei komprimierten Event-Journal-Dateien in einen Zugriffskonflikt; sed.log enthält wiederholte Verweise auf den Sysmon-Archivpfad. In der aktiven Sysmon-Konfiguration wird die Sophos-ProgramData-Struktur gezielt von dieser FileDelete-Archivierung ausgeschlossen, nicht vom Sophos-Scan. Nach dem erneuten Laden der Sysmon-Konfiguration sollte SEDService.exe die offenen Journaldateien innerhalb weniger Minuten abarbeiten und die Last sinken.

Windows Security Audit Logging: Volumen und Rückbau

Enable additional audit policy logging ist mit Sophos Endpoint Core Agent 2026.1 und Sophos Server Core Agent 2026.1 standardmässig aktiviert. Die nicht einzeln konfigurierbare Liste zusätzlicher Windows-Audit-Ereignisse verbessert Daten für Erkennung und Threat Hunting. Diese Ereignisse stehen im Windows Security Event Log, nicht in einem Sophos-Textlog unter C:\ProgramData\Sophos. Die Zuordnung und der Rückbau hier gelten für Windows-Endpoints und Windows Server; sie beschreiben keine Linux-Funktion.

Die effektiv angewendete Policy wird beim Endpoint in Threat Protection und beim Server in Server Threat Protection verwaltet. Ein höheres Eventvolumen allein ist kein Schutzfehler. Vor einer Abschaltung werden Logaufbewahrung und SIEM-Verarbeitung geprüft, denn weniger Audit-Daten schränken die Untersuchung späterer Angriffe ein.

Ereignisse den Audit-Unterkategorien zuordnen

Die Tabelle nennt die englischen Windows-Unterkategorien. Auf einem deutschsprachigen Windows können die Namen anders lauten; für lokale Befehle wird die unten ermittelte GUID verwendet. Die IDs sind eine Zuordnung, kein Testplan: Nicht jede Serverrolle oder Aktivität erzeugt jedes Ereignis. Zum Prüfen vorhandene, autorisierte Betriebsaktivität verwenden, keine Konto-, Task- oder Dienständerungen allein für einen Test auslösen.

Vorzustand, Aufbewahrung und Beweissicherung

Vor einer geplanten Änderung pro Gerät Policy-Name und Zuweisung, Core-Agent-Version, Serverrolle, Änderungszeit mit Zeitzone und Verantwortliche dokumentieren. Für jede betroffene Unterkategorie die Erfolgs- und Fehlerüberwachung getrennt festhalten und klären, ob GPOs, eine Security-Baseline oder ein anderes Produkt sie verlangt. Ist die Funktion bereits aktiv, dokumentiert eine neue Sicherung nur den aktuellen Zustand, nicht automatisch den Zustand vor Sophos’ Änderung. Ohne ältere belastbare Konfiguration und Owner-Freigabe keine Unterkategorie auf Verdacht deaktivieren.

Die folgenden Befehle sind für eine als Administrator geöffnete Windows-Eingabeaufforderung vorgesehen. Sie lesen Konfigurationen beziehungsweise schreiben eine Sicherungsdatei; sie ändern keine Audit-Einstellungen. C:\Audit-Sicherung ist ein Beispiel für ein vorher anzulegendes, zugriffsgeschütztes Verzeichnis mit genügend freiem Speicher. Für jede Erfassung einen neuen Dateinamen verwenden, damit der Vorzustand erhalten bleibt.

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

Die CSV-Sicherung erfasst System- und benutzerbezogene Audit-Einstellungen sowie Audit-Optionen; sie ersetzt kein GPO-Backup. Die Ausgabe der Abfragen mit dem Änderungsnachweis sichern. Für den späteren Vergleich die GUID der konkreten Unterkategorie aus der Liste mit ihrem lokal angezeigten Namen festhalten.

wevtutil gl Security zeigt unter anderem maximale Grösse, Logpfad und Aufbewahrungsmodus; wevtutil gli Security zeigt den Logzustand. In der Windows-Ereignisanzeige das Security-Log prüfen: ältesten noch vorhandenen Zeitstempel, Ereignisse im festgelegten Vergleichsfenster und dominierende IDs festhalten. Vor und nach der Änderung unter vergleichbarer Last Eventanzahl pro Zeitfenster, verfügbaren lokalen Zeitraum, freien Speicher sowie SIEM-Eingangsrate, Verzögerung und verworfene Ereignisse vergleichen. Dateigrösse allein zeigt bei einem umlaufenden Log nicht, wie viel Historie noch vorhanden ist.

Bei retention:false überschreiben neue Ereignisse die ältesten, sobald die Maximalgrösse erreicht ist. Bei retention:true ohne automatische Sicherung werden dann neue Ereignisse verworfen. autoBackup:true setzt retention:true voraus; Archive benötigen weiterhin Speicher und eine kontrollierte Aufbewahrung. Die Loggrösse deshalb nicht pauschal reduzieren und «nicht überschreiben» nicht mit unbegrenzter Aufbewahrung verwechseln. Änderungen an Maximalgrösse, Aufbewahrungsmodus oder Archivierung mit den Windows-/SIEM-Verantwortlichen abstimmen und vorher alle drei Ausgangswerte dokumentieren. Beim Rückbau genau diese Werte im zuständigen lokalen oder GPO-Konfigurationsweg wiederherstellen und mit wevtutil gl Security kontrollieren. Bereits überschriebene oder verworfene Ereignisse kommen dadurch nicht zurück.

Vor einem Eingriff relevante Ereignisse exportieren, nicht das Security-Log leeren. Auch hierfür einen neuen Dateinamen und ein geschütztes Ziel mit genügend Speicher verwenden:

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

Die exportierte Datei in der Ereignisanzeige öffnen und den benötigten Zeitraum kontrollieren. Audit-Daten können Benutzer-, Konto- und Aktivitätsinformationen enthalten; Zugriff, Übertragung und Aufbewahrung entsprechend begrenzen.

Selektiver Rückbau nach Policy-Abschaltung

Zuerst Enable additional audit policy logging in der tatsächlich angewendeten Endpoint- oder Server-Threat-Protection-Policy ausschalten, speichern und den Policy-Empfang am Gerät prüfen. Bereits aktivierte Windows-Audit-Einstellungen bleiben bestehen und müssen bei Bedarf manuell zurückgebaut werden. Keine vollständige Audit-Policy löschen: Das würde auch unabhängig von Sophos benötigte Einstellungen betreffen. Ebenso keine ganze CSV-Sicherung blind wiederherstellen, da seit ihrer Erfassung berechtigte Änderungen erfolgt sein können.

Nur nach Freigabe der Windows-/Security-Verantwortlichen die nachweislich betroffenen Unterkategorien einzeln auf ihre belegten vorherigen Werte setzen. Das folgende verändernde Beispiel gilt ausschliesslich, wenn vorher Erfolgsüberwachung aktiv und Fehlerüberwachung inaktiv war. <GUID> vollständig durch die ermittelte Unterkategorie-GUID einschliesslich {...} ersetzen; der Platzhalter ist nicht ausführbar. Vor dem Setzen nochmals lokal lesen:

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

Für andere belegte Vorzustände die beiden Werte unabhängig wählen: enable erhält beziehungsweise aktiviert den jeweiligen Zweig, disable deaktiviert ihn. Nur wenn beide Zweige zuvor aus waren und keine andere geltende Vorgabe sie benötigt, ist für genau diese Unterkategorie beides zu deaktivieren. Eine Unterkategorie kann mehr Ereignisse steuern als die hier aufgeführten IDs; die Änderung ist kein Filter für einzelne Event IDs.

Nach jeder Änderung Soll- und Istwerte vergleichen, später nach der regulären GPO-/Produktaktualisierung erneut lesen und den benötigten Ereignisfluss sowie Log-/SIEM-Volumen prüfen. Werden Werte wieder aktiviert, zuerst die steuernde GPO oder das andere Security-Produkt klären – nicht wiederholt lokal dagegenarbeiten. Bleiben Vorzustand, Zuständigkeit oder Empfang der Sophos-Policy unklar, Rückbau stoppen und Policy-, Agent-, Audit- und Volumenbefunde eskalieren. Soll die zusätzliche Sichtbarkeit wiederhergestellt werden, die Sophos-Option erneut aktivieren und nach Empfang Audit-Zustand und Ereignisfluss prüfen; eine zwischenzeitliche Datenlücke wird dadurch nicht aufgefüllt.

Dienste korrekt beurteilen

Self Help unterscheidet Windows SCM Services und Sophos SCM Services. Nur die erste Gruppe ist beim Windows Service Control Manager registriert und in services.msc sichtbar. Sophos SCM Services laufen als Prozesse, erscheinen dort aber nicht. Auf modernen Plattformen wechselten Sophos Live Query, Sophos Health Service und Sophos System Protection Service ab Core Agent 2025.2 in diese zweite Gruppe. Ein fehlender Eintrag in services.msc beweist deshalb allein keinen Installationsfehler.

Sophos beschreibt diese Konsolidierung für 2025.2.1 als Performance-Optimierung. Für die Diagnose sind dennoch die installierte Core-Agent-Version und die dazu passende Self-Help-Anleitung entscheidend: Die aktuelle Services-Anleitung ist ausdrücklich für Core Agent 2026.1 gekennzeichnet; ältere oder neuere Pakete können einen anderen Ablauf benötigen. Statuswerte werden zuerst in Self Help geprüft. Dort nennt Sophos auch, ob ein betroffener Dienst über Windows SCM oder über Sophos SCM behandelt wird. Die Reparaturschritte setzen Administratorrechte und deaktivierten Manipulationsschutz voraus; sie werden nicht nur aufgrund einer alten Diensteliste ausgeführt.

Bei Core Agent 2025.x kann ein seltenes Gegenbeispiel nach einem fehlgeschlagenen Windows-11-Feature-Update von 23H2 auf 24H2 oder 25H2 mit Rollback auftreten. Fällt der Rollback genau mit einem DecisionCache-Update zusammen, können Registry- und Dateisystemversion auseinanderlaufen. Der Endpoint wird rot, System Protection startet nicht und C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log meldet eine fehlende Rules-Version.

Nicht bis zu 96 Stunden auf eine mögliche automatische Reparatur warten, weil System Protection in dieser Zeit fehlt. Der bevorzugte Weg weist dem betroffenen Gerät vorübergehend eine Update-Management-Policy mit einem unterstützten FTS- oder LTS-Paket zu. Die dadurch ausgelöste Neuinstallation richtet die Referenzen neu aus. Erst nach grünem Health State, laufender Komponente und aktuellem SSP-Log wird das Gerät aus der Reparatur-Policy entfernt. Eine manuelle Registry-Angleichung erfolgt nur nach Tamper-Protection-Override, Backup und exakt passendem Rules-Verzeichnis.

Die offizielle Komponenten- und Diensteliste ordnet unter anderem folgende Namen zu. Die Tabelle ist eine Diagnosehilfe, keine vollständige Soll-Liste für jedes Gerät:

Welche Komponenten vorhanden sein müssen, hängt von Plattform, Agent Mode und Lizenz ab. Ein XDR Sensor installiert beispielsweise Telemetriekomponenten, aber keinen vollständigen Sophos-Malware-Schutz. Der erwartete Sollzustand wird daher zuerst in Central ermittelt und erst danach mit Diensten und Prozessen verglichen.

Netzwerk- und Webschutz

SophosNetFilter.log enthält Website-Verbindungen und Aktionen von Web Control sowie der Internet-Echtzeitprüfung. SophosIPS.log zeigt Konfiguration und Erkennungsinhalte der Netzwerkbedrohungsabwehr. SntpService.log enthält unter anderem Informationen zu Isolation und weiteren Netzwerkfunktionen.

Bei einer blockierten Website werden Zeitpunkt, URL, Prozess und wirksame Policy verglichen. Aus dem Log allein ist nicht immer ersichtlich, ob Endpoint Web Control, DNS Protection oder eine vorgelagerte Firewall zuerst blockiert hat. Diese Kontrollpunkte werden getrennt geprüft.

Benutzeroberfläche und Self Help

Bei aktuellen Core-Agent-Versionen liegen SophosUI.Net.log und SophosUITray.log unter:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

Sie dokumentieren Aktionen in der lokalen Oberfläche beziehungsweise am Taskbar-Symbol. Seit Core Agent 2026.1 können auch Self-Help-Logs zusätzlich benutzerbezogen unter %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs liegen. Das maschinenweite Verzeichnis unter C:\ProgramData\Sophos\Endpoint Self Help\Logs bleibt je nach Komponente ebenfalls relevant.

Ein Log sauber auswerten

Vor dem Öffnen wird ein enger Fehlerzeitraum mit Zeitzone festgelegt. Danach wird vom ersten relevanten Fehler vorwärts gelesen. Spätere Folgefehler wie service unavailable, timeout oder component unhealthy sind häufig nur Konsequenzen.

Eine belastbare Notiz enthält:

• sichtbares Symptom und reproduzierbaren Test,
• Logname, Zeitstempel und erste relevante Meldung,
• beteiligten Endpoint-, Proxy-, Cache- oder Relay-Pfad,
• Vergleich mit einem funktionierenden Gerät,
• getestete Änderung und messbares Ergebnis.

Loglevel werden nicht vorsorglich dauerhaft erhöht. Detailliertes MCS-Logging kann sensible Kommunikationsdaten enthalten und zusätzlichen Speicher belegen. Es wird nur für ein definiertes Zeitfenster nach aktueller Sophos-Anleitung aktiviert und danach zurückgesetzt.

Für eine MCS-Kommunikationsanalyse kann Sophos Support zusätzlich einen diagnostic message trail verlangen. Auf Windows 10 x64 beziehungsweise Windows Server 2016 und neuer ist er seit Core Agent 2023.2 standardmässig aktiv; die XML-Schritte zum Aktivieren und späteren Deaktivieren betreffen nur Legacy-Plattformen. Die Trail-Dateien können Richtlinien- und Kommunikationsdaten enthalten und werden geschützt zusammen mit der SDU übertragen. Eine Legacy-Aufzeichnung wird nach der Erfassung wieder deaktiviert, da sie sonst den Datenträger füllen kann.

Logs für den Support sichern

Einzelne Logs helfen bei der lokalen Eingrenzung. Für eine Eskalation wird zusätzlich eine SDU-Sammlung aus demselben Fehlerzeitraum erstellt. Das Paket kann Hostnamen, Benutzer, Pfade, IP-Adressen und Konfigurationsdaten enthalten und wird entsprechend geschützt übertragen.

Die vollständige Sammlung erklärt Sophos Endpoint mit Self Help und SDU diagnostizieren. Installationsfehler werden separat unter Sophos Endpoint Installation unter Windows systematisch beheben behandelt.

Häufige Fragen