Zum Inhalt springen
Avanet

Sophos Endpoint Threat Cleanup und Malware-Bereinigung

Threat Cleanup bezeichnet die technische Bereinigung einer erkannten Bedrohung. Das Acknowledge, Resolve oder Schliessen eines Alerts ist dagegen nur eine Workflow-Aktion. Ein Vorfall ist erst beendet, wenn Bedrohung, Persistenz, Eintrittsweg und betroffene Systeme geprüft wurden.

Sofortige Triage

Bei einer aktiven oder hochriskanten Erkennung gilt:

  1. Gerät identifizieren und letzte Kommunikation prüfen.
  2. Detection Name, Zeit, Benutzer, Prozess, Pfad, Hash und Sophos-Aktion sichern.
  3. Gerät isolieren, wenn weitere Ausführung oder Ausbreitung möglich ist.
  4. Threat Graph beziehungsweise Prozesskette untersuchen.
  5. Automatische Bereinigung und verbleibende Artefakte prüfen.
  6. Eintrittsweg, Persistenz und ähnliche Events auf anderen Geräten suchen.
  7. Erst nach technischer Abnahme Alert und Health State bereinigen.

Bei einem geschäftskritischen System wird die Isolation mit dem Incident-Prozess koordiniert. Bequemlichkeit ist aber kein Grund, ein mutmasslich aktives System unisoliert weiterzubetreiben.

Malware nicht bereinigt

Malware not cleaned up bedeutet, dass die Erkennung nicht vollständig entfernt wurde. Gründe können gesperrte Dateien, Netzwerkfreigaben, fehlende Rechte, beschädigte Agent-Komponenten oder ein nicht mehr erreichbarer Speicherort sein.

Der nächste Schritt richtet sich nach Pfad und Zustand:

  • lokalen Sophos Scan erneut ausführen,
  • Datei und zugehörige Prozesse kontrollieren,
  • Netzwerkfreigabe auf dem zuständigen System bereinigen,
  • Endpoint Self Help und SDU bei Agentfehlern verwenden,
  • Support einschalten, wenn Cleanup reproduzierbar scheitert.

Running malware not cleaned up wird als möglicher aktiver Incident behandelt. Ein Neustart allein ist keine Ursachenanalyse.

Ransomware und remote ausgeführte Ransomware

Bei Ransomware werden betroffene Dateien, Ausgangsprozess, Benutzerkonto, Freigaben und benachbarte Geräte untersucht. Eine Meldung zu remote ausgeführter Ransomware kann auf einen anderen kompromittierten Computer hinweisen, der über das Netzwerk verschlüsselt.

Das gemeldete Schutzgerät ist deshalb nicht zwingend der Ursprung. SMB-Verbindungen, Anmeldeereignisse, Admin-Tools und weitere Geräte werden in die Untersuchung einbezogen. Zugangsdaten betroffener Konten werden kontrolliert zurückgesetzt.

Bei einer lokalen CryptoGuard-Erkennung kann Sophos dem auslösenden Prozess den Schreibzugriff auf Dateisysteme entziehen. Diese Sperre bleibt bestehen, bis die Erkennung lokal oder in Central als technisch behoben markiert oder das System neu gestartet wurde. Das reine Schliessen erfolgt daher erst nach der Ursachenprüfung; ein Neustart darf die Untersuchung nicht ersetzen.

Die Ransomware-Policy kennt Terminate Process als Standard und Isolate Process als Alternative. Terminate beendet den auslösenden Prozess, Isolate entzieht ihm Schreibzugriff auf Dateisysteme. Ein Ransomware-Simulator kann deshalb absichtlich abstürzen. Der Modus wird nicht für einen Test global abgeschwächt; Simulator, Pilotgruppe, erwartetes Event und anschliessender Schutzstatus werden vorab definiert.

Bei einer Remote-Erkennung wird die gemeldete IP-Adresse mit DHCP-, NAT-, SMB- und Anmeldedaten korreliert. Eine später neu vergebene Adresse kann sonst das falsche Gerät als Ursprung erscheinen lassen. Eine IP-basierte CryptoGuard-Ausnahme bietet Sophos bewusst nicht an, weil sie zu weitreichend wäre.

C2/Generic-B und C2/Generic-C unterscheiden

C2/Generic-B wird vom Endpoint ausgelöst, wenn Network Threat Protection verdächtige Kommunikation zu einer Command-and-Control-Infrastruktur erkennt. Dieser High-Severity-Alert braucht eine manuelle Untersuchung im Threat Case. Prozesskette, URL-Knoten, Benutzer und Technical Support reference werden gesichert. Die Referenz steht für ein von Sophos verborgenes schädliches Ziel; sie wird bei einer Sample- oder Supporteskalation angegeben.

Ein scheinbar legitimer Prozess wie svchost.exe oder wscript.exe ist keine Entwarnung. Schadcode kann sich in einen legitimen Prozess injiziert haben oder von diesem gestartet worden sein. Bei unklarer Persistenz gehören SDU und ein kontrollierter Autoruns-Export zum Untersuchungsmaterial.

C2/Generic-C hat eine andere Herkunft: Hier hat eine Sophos Firewall die Verbindung erkannt und über Security Heartbeat an den Endpoint gemeldet. Der Endpoint-Event enthält deshalb oft nicht den auslösenden Prozess oder das ursprüngliche Ziel. Die primäre Spur liegt im Security-Heartbeat- beziehungsweise Threat-Report der Firewall. Diese Trennung verhindert, dass erfolglos nur Endpoint-Logs durchsucht werden.

Exploit-, Browser- und IPS-Erkennungen

Eine blockierte Exploit- oder Browser-Aktion kann eine Angriffskette verhindert haben, beweist aber nicht, dass keine weiteren Schritte stattfanden. Prozessbaum, Browser-Erweiterungen, Downloadquelle, Ziel-URL und Folgeprozesse werden geprüft.

Bei Safe Browsing detected browser has been compromised werden im Geräte-Event Details > Show Raw data und die geladenen Module geprüft. Unter Windows enthält zusätzlich das Application Event Log mit Event ID 911 dieselben zentralen Hinweise. Ein Druckertreiber, der beim Anzeigen oder Drucken eines PDFs in den Browser injiziert wird, kann ein legitimer Auslöser sein; diese Erklärung wird jedoch erst nach Prüfung von Hersteller, Signatur, Version, Benutzeraktion und ähnlichen Alerts akzeptiert.

Fehlt die Detailansicht, kann bereits eine Ausnahme für diese Detection bestehen. Das ist kein Beweis für einen False Positive, sondern ein zusätzlicher Konfigurationspunkt, der vor der weiteren Bewertung kontrolliert wird.

BrowserCookie bedeutet, dass ein Prozess auf Browser-Cookies zugreifen wollte. Weil damit Sitzungen und Identitäten übernommen werden können, werden Prozesspfad, Signatur, Benutzer, Zielbrowser und Prozesskette geprüft. Ein legitimes Passwort-, Profil- oder Supportwerkzeug wird nicht allein aufgrund seines Produktnamens autorisiert; zuerst muss geklärt sein, warum es Cookie-Daten benötigt und ob der Hersteller eine kompatible Version anbietet.

IPS-Erkennungen werden mit Quell- und Zielsystem, Port, Richtung und wiederholten Verbindungen korreliert. Ein pauschales Erlauben der Anwendung oder Website ist keine geeignete Reaktion.

Das auslösende Paket wird von Endpoint IPS unmittelbar verworfen. Eine einzelne bereinigte IPS-Erkennung erfordert deshalb nicht automatisch Cleanup, wohl aber eine Bewertung von Regel, Richtung und Wiederholung. Greift eine Ausnahme nicht, wird besonders kontrolliert, ob Quell- und Zielport für inbound beziehungsweise outbound vertauscht wurden. Eine Freigabe erfolgt anhand der konkreten Regel und des notwendigen Verkehrs, nicht anhand eines beliebigen Prozessnamens.

Malicious Traffic Detection beziehungsweise Network Threat Protection prüft auf Windows nicht browsergebundenen HTTP-Verkehr auf Command-and-Control-Ziele; Browsertraffic wird durch die Webschutzkomponenten behandelt. Die Funktion arbeitet nur in Echtzeit, nicht in Scheduled Scans, und authentifizierte Proxies werden für diesen Pfad nicht unterstützt. Für die Diagnose werden Policy, installierte Komponente und C:\ProgramData\Sophos\Sophos Network Threat Protection\Logs\SophosIPS.log gemeinsam geprüft.

AMSI-Erkennungen

AMSI prüft Skript- und Speicherinhalte, die eine integrierte Windows-Anwendung an die Antimalware-Schnittstelle übergibt. Dazu gehören unter anderem PowerShell, Windows Script Host, JavaScript/VBScript und Office-VBA; Interpreter wie Python oder Perl sind nicht automatisch durch Windows AMSI abgedeckt. Auch verschleierter oder erst zur Laufzeit zusammengesetzter Code kann vor der Ausführung bewertet werden.

Sophos sendet bei einer Erkennung Kontext an Central. Welche Inhalte enthalten sind, hängt von der aufrufenden Anwendung ab und kann Skripttext, Befehlsargumente oder andere sensible Daten umfassen. Events und Supportexporte werden daher wie potenziell vertrauliche Inhalte behandelt. Eine AMSI-Ausnahme wird nur für den exakt geprüften Inhalt beziehungsweise Prozess und bevorzugt in einer engen Policy gesetzt.

Erkennungsnamen mit CX oder Low reputation bewerten zusätzlich Dateireputation, Speicherort, Herkunft und Verhalten. CXmal steht für neue Varianten bekannter Malware, CXmail für E-Mail-Kontext, CXweb für einen durch Web Protection abgefangenen Download und CXrep für ein bösartiges Profil mit niedriger Reputation. Eine Low-Reputation-PUA kann dagegen legitime, aber unerwünschte Software betreffen. Der Präfix erklärt damit den Erkennungskontext, ersetzt aber weder Datei- noch Prozessanalyse.

Mal/Generic-R bedeutet ebenfalls niedrige Dateireputation. Die Bewertung basiert nicht einfach auf der Verbreitung: Auch eine häufig vorkommende Datei kann eine schlechte Reputation besitzen, beispielsweise wegen eines missbrauchten Signaturzertifikats. Meist wurde die Datei bereits bereinigt. Bei Intercept X wird der Ablauf im Threat Graph geprüft; ein fachlich begründeter Fehlalarm wird über den Sophos-Sample-Prozess gemeldet, nicht vorschnell durch eine globale Ausnahme umgangen.

PUA und Application Lockdown

Potentially Unwanted Applications können legitime, aber unerwünschte Programme sein. Vor dem Erlauben werden Hersteller, Signatur, Hash, Einsatzgrund und Verteilung geprüft.

Authorize PUA aus der Alert-Ansicht kann global wirken. Für einen begrenzten Bedarf ist eine gezielte Policy-Ausnahme mit Owner und Ablaufdatum sicherer.

Bei RMM-Werkzeugen ist der Kontext entscheidend. Sophos erkennt beispielsweise Datto RMM als PUA, wenn Komponenten unter unerwarteten Pfaden oder Namen auftauchen, weil Angreifer legitime Remote-Tools für Zugriff und Persistenz missbrauchen. Vor einer Freigabe werden deshalb nicht nur Hersteller und Hash, sondern auch erwarteter Installationspfad, Dateiname, zuständiger Betreiber, Deploymentauftrag und aktive Remote-Sitzungen geprüft.

Application Lockdown kann Dateien blockieren, die mit einer erkannten Anwendung verbunden sind. Erst wird geklärt, ob die zugrunde liegende Anwendung legitim und unverändert ist; danach erfolgt eine kontrollierte Freigabe.

ML/PE-A bezeichnet eine vom Deep-Learning-Modell als schädlich bewertete PE-Datei, Generic ML PUA eine als potenziell unerwünscht bewertete Datei. Beide sind Vor-Ausführungs-Erkennungen: Die betroffene Datei wurde blockiert, bevor sie laufen konnte. Das senkt das unmittelbare Risiko, ersetzt aber nicht die Prüfung von Downloadquelle, Verteilung und ähnlichen Dateien. HPmal/ und HPsus/ sind dagegen verhaltensbasierte Laufzeiterkennungen; bei ihnen ist die Prozess- und Ereigniskette besonders wichtig.

Auch legitime Diagnose- und Administrationswerkzeuge können absichtlich als PUA oder Verhaltensmissbrauch erkannt werden. GMER ist ein Beispiel, weil Angreifer es zum Umgehen von Sicherheitsprodukten einsetzen können. Eine Freigabe setzt deshalb einen autorisierten Auftrag, Originalquelle, Signatur, kontrollierten Pfad und ein begrenztes Wartungsfenster voraus.

False Positive und Sample Submission

Eine Erkennung wird nicht allein wegen einer Benutzeraussage freigegeben. Digitale Signatur, SHA-256, Bezugsquelle, Verhalten und Prozesskette müssen plausibel sein. Verdächtige oder neue Fehlalarme werden mit den geforderten Daten an SophosLabs beziehungsweise Sophos Support übermittelt.

Ein VirusTotal-Ergebnis ist nur ein Indikator. Viele Treffer sprechen stark für Schadcode, wenige Treffer können frühe Erkennung oder False Positives bedeuten und kein Treffer schliesst einen Zero Day nicht aus. Zuerst wird nach dem SHA-256 gesucht. Eine interne oder vertrauliche Datei wird nicht ohne Datenfreigabe an einen öffentlichen Analysedienst hochgeladen.

Unter Profile > Account Preferences > Privacy steuert Central die automatische Sample Submission. Sophos fordert dabei eine Kopie an, wenn eine potenziell schädliche Datei nicht allein anhand ihrer Eigenschaften eingestuft werden kann und Sophos noch kein Sample besitzt. Das Limit beträgt 10 MB pro Sample, der Upload-Timeout 30 Sekunden.

Samples können Dateien, E-Mails oder URLs und damit sensible Inhalte enthalten. Sophos empfiehlt die Funktion für besseren Schutz aktiviert zu lassen; Datenschutz, Rechtsgrundlage und besonders vertrauliche Datenbestände werden dennoch vorab bewertet. Ein Abschalten kann Analyse und False-Positive-Korrektur einschränken und wird nicht als pauschaler Datenschutzschalter verwendet.

Ausnahmen werden möglichst eng als Zertifikat oder Hash gesetzt. Pfadausnahmen in beschreibbaren Verzeichnissen sind besonders riskant. Details stehen unter Sophos Central Endpoint-Ausnahmen sicher konfigurieren.

Machine-Learning-Erkennungen in temporären Verzeichnissen benötigen besondere Vorsicht. Solche Dateien sind oft unsigniert, kurzlebig und besitzen bei jedem Lauf einen neuen Hash. Eine Hash- oder breite %TEMP%-Ausnahme ist daher entweder wirkungslos oder gefährlich. Für die Analyse wird nur eine kleine Gerätegruppe einer temporären Policy zugewiesen, die Datei kontrolliert vor dem Löschen gesichert und an Sophos übermittelt. Nach der Sammlung werden veränderte Ordnerrechte, Policy und Ausnahmen vollständig zurückgesetzt.

Nicht bereinigbare Systemdateien und fehlgeschlagene Wiederherstellung

Eine Erkennung in pagefile.sys, hiberfil.sys oder einer Volume Shadow Copy wird nicht durch eine Dateiausnahme gelöst. Zuerst läuft ein vollständiger Scan, damit der ursprüngliche Prozess oder die Quelldatei gefunden wird. Shadow Copies sind schreibgeschützt; ihre Entfernung verwirft ganze Wiederherstellungspunkte und wird deshalb mit Backup- und Recovery-Verantwortlichen abgestimmt. Pagefile beziehungsweise Hibernation werden nur nach gesicherter Incidentlage über die dokumentierten Windows-Mechanismen geleert und danach wieder in den vorgesehenen Betriebszustand versetzt.

Scheitert die Wiederherstellung einer von Sophos bereinigten Anwendung, werden SophosCleanup.log beziehungsweise Clean.log und SafeStore.log anhand derselben Threat ID korreliert. Fehler SafeStore_RestoreObjectById ... error 18 wird nicht mit wiederholtem Freigeben übergangen. Nach Prüfung von False Positive, Signatur und Geschäftsbedarf wird Sophos System Protection neu gestartet beziehungsweise SDU gesammelt und der Fall mit Threat ID und Zeitstempel eskaliert.

Dateilose oder WMI-basierte Malware verlangt eine Persistenzprüfung ausserhalb normaler Dateipfade. Bei einem JavaScript-CoinMiner werden insbesondere WMI Event Filter, Event Consumer und Bindings unter root\subscription gesichert und auf unbekannte Skripte oder Namen geprüft. Nur die bestätigten schädlichen Objekte werden entfernt; anschliessend folgen vollständiger Scan, Suche nach dem Eintrittsweg und Kontrolle weiterer Geräte. Ein bereinigter sichtbarer Prozess beweist nicht, dass der WMI-Trigger verschwunden ist.

Abschlusskriterien

Der Incident wird erst geschlossen, wenn:

  • kein aktiver Prozess oder Persistenzmechanismus verbleibt,
  • Cleanup oder manueller Rückbau bestätigt ist,
  • ähnliche Geräte und Benutzer geprüft sind,
  • Eintrittsweg und Schwachstelle behandelt sind,
  • Schutz und Agent-Kommunikation wieder gesund sind,
  • Beweisdaten und Entscheidungen dokumentiert sind.

Häufige Fragen

Ist ein Alert nach Mark As Resolved technisch bereinigt?

Nein. Diese Aktion ändert die Anzeige beziehungsweise den Workflow. Die Ursache muss vorher auf dem Gerät oder im Incident-Prozess behoben worden sein.

Ist bei Remote-Ransomware das meldende Gerät immer der Ursprung?

Nein. Die Verschlüsselung kann von einem anderen kompromittierten Gerät über eine Freigabe erfolgt sein. Ursprung, Konten und Netzwerkverbindungen müssen untersucht werden.