Incident Response (IR) ist ein Wettlauf gegen die Zeit. Man engagiert sein internes oder externes Team, weil es ausreichende Beweise dafür gibt, dass etwas Schlimmes passiert, aber man ist immer noch blind in Bezug auf den Umfang, die Auswirkungen und die Ursache. Die gängigen IR-Tools und -Praktiken ermöglichen es den IR-Teams, schädliche Dateien und ausgehende Netzwerkverbindungen zu entdecken. Der Aspekt der Identität, nämlich die Identifizierung der kompromittierten Benutzerkonten, die zur Verbreitung im Netzwerk verwendet wurden, bleibt jedoch leider unbeachtet. Diese Aufgabe erweist sich als die zeitaufwendigste für IR-Teams und ist zu einer herausfordernden Hürde geworden, die es Angreifern ermöglicht, wertvolle Zeit zu gewinnen, in der sie noch Schaden anrichten können.
In diesem Artikel analysieren wir die Wurzelursache für die Identitätsblindstellen in der IR und stellen Beispiele für IR-Szenarien vor, in denen sie den schnellen und effizienten Prozess behindern. Wir stellen dann Silverforts Unified Identity Protection Platform vor und zeigen, wie ihre Echtzeit-Mehrfaktorauthentifizierung und Identitätssegmentierung diese Blindstelle überwinden kann und den Unterschied zwischen einem begrenzten Vorfall und einem kostspieligen Verstoß ausmachen kann.
IR 101: Wissen ist Macht. Zeit ist alles.
Der Auslöser eines IR-Prozesses kann in einer Million Formen auftreten. Sie alle haben gemeinsam, dass man denkt – oder sogar sicher ist -, dass etwas nicht in Ordnung ist, aber man weiß nicht genau, was, wo und wie. Wenn man Glück hat, hat das Team die Bedrohung erkannt, als sie noch in ihrer Kraft steckt, aber ihr bösartiges Ziel noch nicht erreicht hat. Wenn man weniger Glück hat, wird man erst dann auf die Anwesenheit des Gegners aufmerksam, nachdem der Schaden bereits angerichtet wurde – verschlüsselte Rechner, fehlende Daten und andere Formen von bösartigen Aktivitäten.
So oder so ist die dringendste Aufgabe, sobald der IR-Prozess anläuft, die Dunkelheit aufzulösen und klare Erkenntnisse über die kompromittierten Einheiten in der eigenen Umgebung zu gewinnen. Sobald diese lokalisiert und validiert sind, können Maßnahmen ergriffen werden, um die Angriffe einzudämmen, indem man die Rechner in Quarantäne steckt, den ausgehenden Verkehr blockiert, schädliche Dateien entfernt und Benutzerkonten zurücksetzt.
Wie sich herausstellt, ist die letzte Aufgabe bei der Bewältigung kompromittierter Benutzerkonten bei weitem nicht trivial und stellt eine bisher ungelöste Herausforderung dar. Lassen Sie uns verstehen, warum das so ist.
Identitäts-IR-Lücke Nr. 1: Keine Playbook-Bewegung zur Erkennung kompromittierter Konten
Anders als bösartige Dateien oder bösartige ausgehende Netzwerkverbindungen tut ein kompromittiertes Konto nichts, was im Wesentlichen bösartig ist – es meldet sich lediglich in Ressourcen an, auf die ein normales Konto genauso zugreifen würde. Wenn es sich um ein Admin-Konto handelt, das täglich auf mehreren Workstations und Servern zugreift – wie es in vielen Angriffen der Fall ist -, wird sein lateraler Bewegungsverlauf nicht einmal anomalous erscheinen.
Das Ergebnis ist, dass die Entdeckung des kompromittierten Kontos erst nach der Lokalisierung und Quarantäne der kompromittierten Rechner stattfindet und selbst dann eine manuelle Überprüfung aller dort angemeldeten Konten umfasst. Und wieder einmal – wenn man gegen die Zeit kämpft, führt die Abhängigkeit von manuellen und fehleranfälligen Untersuchungen zu einer kritischen Verzögerung.
Identitäts-IR-Lücke Nr. 2: Keine Playbook-Bewegung zur sofortigen Eindämmung des Angriffs und zur Verhinderung weiterer Ausbreitung
Wie im wirklichen Leben gibt es eine Phase der sofortigen Erste Hilfe, die der vollen Behandlung vorausgeht. Das Äquivalent in der IR-Welt besteht darin, den Angriff innerhalb seiner aktuellen Grenzen einzudämmen und sicherzustellen, dass er sich nicht weiter ausbreitet, auch bevor seine aktiven Komponenten entdeckt werden. Auf der Netzwerkebene geschieht dies durch vorübergehendes Isolieren von Segmenten, in denen potenziell bösartige Aktivitäten stattfinden, von denen, die noch nicht kompromittiert sind. Auf der Endpunkt-Ebene geschieht dies durch Quarantäne von Rechnern, auf denen Malware gefunden wird.
Auch hier muss der Aspekt der Identität aufholen. Die einzige verfügbare Eindämmung besteht darin, das Benutzerkonto in der AD zu deaktivieren oder sein Passwort zurückzusetzen. Die erste Option ist aufgrund der damit verbundenen Betriebsstörungen nicht akzeptabel, insbesondere im Falle von Fehlalarmen. Die zweite Option ist auch nicht gut; wenn das verdächtige Konto ein maschinell-zu-maschinell Servicekonto ist, wird das Zurücksetzen seines Passworts wahrscheinlich die kritischen Prozesse, die es verwaltet, unterbrechen und zusätzlichen Schaden verursachen, der sich auf den durch den Angriff verursachten Schaden hinauswirkt. Wenn es dem Angreifer gelungen ist, die Identitätsinfrastruktur selbst zu kompromittieren, wird das Zurücksetzen des Passworts sofort behandelt, indem auf ein anderes Konto umgeschaltet wird.
Identitäts-IR-Lücke Nr. 3: Keine Playbook-Bewegung zur Verringerung exponierter Identitätsangriffsflächen, die Angreifer innerhalb des Angriffs zum Ziel haben
Die Schwachstellen, die die Identitätsangriffsfläche für den bösartigen Zugriff auf Berechtigungen und laterale Bewegungen freigeben, sind für die Posture- und Hygieneprodukte im Sicherheitsstack blinde Flecken. Dies beraubt das IR-Team kritischer Hinweise auf Kompromittierungen, die den Prozess erheblich beschleunigt hätten.
Nennenswerte Beispiele sind anfällige Authentifizierungsprotokolle wie NTLM (oder noch schlimmer, NTLMv1), Fehlkonfigurationen wie Konten, die mit uneingeschränkter Delegierung festgelegt sind, Schattenadministratoren, altmodische Benutzer und vieles mehr. Angreifer bedienen sich dieser Schwachstellen, da sie ihren Living Off The Land-Routenplaner machen. Die Unfähigkeit, Konten und Maschinen zu lokalisieren, um sie neu zu konfigurieren oder zu schützen, die diese Schwachstellen aufweisen, verwandelt das IR in eine Katzenherde, bei der der Analyst damit beschäftigt ist, zu analysieren, ob Konto A kompromittiert ist, während die Angreifer bereits kompromittiertes Konto B nutzen.
Das Fazit lautet: Keine Werkzeuge. Keine Abkürzungen. Einfach langsame und manuelle Protokollanalyse, während der Angriff in vollem Gange ist.
Das ist also der Status quo: Wenn das IR-Team endlich herausfinden muss, welche kompromittierten Benutzerkonten der Angreifer verwendet, um sich in der eigenen Umgebung zu verbreiten. Dies ist ein Geheimnis, über das niemand spricht, und die eigentliche Ursache dafür, dass laterale Bewegungsangriffe so erfolgreich sind und so schwer einzugrenzen sind, auch wenn der IR-Prozess stattfindet.
Diese Herausforderung löst Silverfort.
Silverforts Unified Identity Protection für IR-Operationen
Die Unified Identity Protection Plattform von Silverfort integriert sich mit der Identitätsinfrastruktur vor Ort und in der Cloud (Active Directory, Entra ID, Okta, Ping, etc.). Diese Integration ermöglicht es Silverfort, vollständige Transparenz über jede Authentifizierung und jeden Zugriffsversuch zu haben, eine Echtzeit-Zugriffsüberwachung, um bösartigen Zugriff mit MFA oder Zugriffsblockierung zu verhindern, und automatische Erkennung und Schutz von Servicekonten.
Schauen wir uns an, wie diese Funktionen den Identitäts-IR-Prozess beschleunigen und optimieren:
Erkennung von kompromittierten Konten mit MFA ohne operationale Unterbrechung
Silverfort ist die einzige Lösung, die MFA-Schutz für alle AD-Authentifizierungen, einschließlich Befehlszeilentools wie PsExec und PowerShell, durchsetzen kann. Mit dieser Fähigkeit kann ein