Bruteforce-Angriffserkennung durch NTLM mit Varonis



Wir werden heute den tatsächlichen Arbeitsablauf beschreiben, den das Varonis Incident Response Team zur Untersuchung von Brute-Force-Angriffen (im Folgenden als Brute-Force-Angriffe bezeichnet) über NTLM verwendet. Diese Angriffe sind weit verbreitet und werden von unserem Team häufig mit Kunden auf der ganzen Welt in Kontakt gebracht.

Entdeckung


Wenn Sie eine dieser Warnungen im Varonis-Dashboard sehen, sind Sie möglicherweise einem Brute-Force-Angriff über NTLM ausgesetzt:

  • Passwortspray aus einer Hand
  • Kontoaufzählung über NTLM
  • Mehrere Kontosperrungen



Sie können auch im Varonis-Dashboard nach allen fehlgeschlagenen Authentifizierungsversuchen suchen, um verdächtige Aktivitäten zu finden, die untersucht werden müssen.

1. Erste Untersuchung in der Varonis-Oberfläche


Klicken Sie im Varonis-Dashboard auf Analytics.
Wählen Sie in der Dropdown-Liste Server die Option DirectoryServices aus.

Wählen Sie für den Filtertyp nach Ereignistyp "Kontoauthentifizierung" aus. Als Ergebnis erhalten Sie eine Auswahl von Ereignissen, die sich auf Anmeldeversuche für einen bestimmten Zeitraum beziehen.



Suchen Sie nach erfolglosen Anmeldeversuchen für unbekannte Benutzer, die möglicherweise auf einen Wörterbuchangriff durch allgemeine Kontonamen wie "Administrator" oder "Dienst" hinweisen. Varonis zeigt Konten wie "Abstrakt / Niemand" (im markierten Feld Benutzername (Ereignis von)) an, da sie in Active Directory nicht vorhanden sind und nicht abgeglichen werden können.

In der Spalte „Gerätename“ wird höchstwahrscheinlich der verschleierte Name des Computers angezeigt, der für Authentifizierungsanforderungen verwendet wird. Wahrscheinlich kennen Sie diesen Computer nicht und sein Name entspricht nicht der Namensrichtlinie für Unternehmensgeräte. Angreifer verwenden häufig Gerätenamen wie „Workstation“ oder „mstsc“, um ihre Aktivitäten zu verbergen. Manchmal lassen sie den Gerätenamen komplett leer.



Wenn Sie festgestellt haben, dass ein Brute-Force-Angriff über NTLM wirklich ein Muss ist, müssen Sie sich eingehender mit den Protokollen befassen.

Suchen Sie mit den folgenden Filtern nach allen fehlgeschlagenen Anmeldeversuchen über NTLM:

  • Ereignisbeschreibung 'enthält' NTLM
  • Ereignisstatus = Fehlgeschlagen
  • Ereignistyp = TGT-Authentifizierung

Suchen Sie nach allen erfolgreichen Authentifizierungen anhand von Gerätenamen, die von Cyberkriminellen verwendet werden, um sicherzustellen, dass derzeit keine unmittelbaren Anzeichen für eine erfolgreiche Kontokompromittierung vorliegen. Notieren Sie den Wert des Felds "Hostname des Erfassungsgeräts" für die zu analysierenden Ereignisse. Dies ist der Name des Domänencontrollers, von dem aus die nächste Phase der Untersuchung gestartet werden soll.

2. Vorbereiten eines NTLM-Audits


Markieren Sie Standarddomänenrichtlinie, damit wir später Ereignisse von allen Domänencontrollern empfangen können.



Klicken Sie mit der rechten Maustaste auf Standarddomänenrichtlinie und wählen Sie Bearbeiten.



Das Fenster Gruppenrichtlinienverwaltungs-Editor wird geöffnet. Erweitern Sie die Hierarchie, und wählen Sie Sicherheitsoptionen aus.
Ändern Sie die folgenden Werte:



  • Netzwerksicherheit: NTLM einschränken: Eingehenden Datenverkehr überwachen = Überwachung für alle Konten aktivieren
  • Netzwerksicherheit: NTLM einschränken: NTLM-Authentifizierung in dieser Domäne überwachen = Alle aktivieren
  • Netzwerksicherheit: NTLM einschränken: Ausgehender NTLM-Verkehr zu Remoteservern = Alle überwachen

Führen Sie den Befehl gpupdate / force aus, um die Änderungen zu übernehmen.

3. NTLM-Protokolluntersuchung


Wechseln Sie zu dem Domänencontroller, der in Schritt 1 in der Spalte "Hostname des Erfassungsgeräts" angegeben ist.

Führen Sie die Ereignisanzeige aus (Befehl eventvwr in cmd) und erweitern Sie die Hierarchie auf Anwendungs- und Dienstprotokolle> Microsoft> Windows> NTLM> Operational. Klicken Sie mit der rechten Maustaste auf das angegebene Protokoll, wählen Sie Eigenschaften und erhöhen Sie die Protokollgröße auf mindestens 20 MB (Standardgröße ist 1 MB).

Ereignisse mit der Ereignis-ID 8004 werden zum größten Teil mit böswilligen Authentifizierungsversuchen in Verbindung gebracht.

Sehen Sie sich das Protokoll mit den Namen der Geräte oder Benutzer an, die wir in Schritt 1 gesehen haben. Achten Sie bei den gefundenen Ereignissen auf das Feld „Secure Channel Name“. Dies ist der Name des angegriffenen Geräts.

Wichtiger Hinweis
Im NTLM-Ereignisprotokoll werden nur neue Ereignisse angezeigt, die ab dem Zeitpunkt eintraten, an dem die Überwachung in Absatz 2 aktiviert wurde

4. Abhilfe schaffen


Sobald wir den Namen des angegriffenen Geräts identifiziert haben, können wir herausfinden, wie der Angreifer diese Authentifizierungsversuche sendet. Überprüfen Sie in den Firewall-Protokollen, ob bei böswilligen Authentifizierungsversuchen Verbindungen bestehen. Auf dem Zielgerät können Sie den Befehl netstat oder das Dienstprogramm Wireshark verwenden. Daher suchen wir nach der IP-Adresse und dem Port, über die der Angreifer Authentifizierungsanforderungen sendet.
Sobald wir diese Informationen erhalten, können wir Maßnahmen ergreifen, um feindliche Aktivitäten zu verhindern - blockieren Sie die IP-Adresse oder schließen Sie den Port.

Wichtiger Hinweis
Es besteht die Möglichkeit einer Infektion des angegriffenen Geräts. Sei vorsichtig!

Um die Untersuchung abzuschließen, müssen wir schließlich alle Aktionen zur Authentifizierung von Benutzerkonten auf dem angegriffenen Gerät sowie die Aktivitäten auf den beobachteten Datenquellen des angegriffenen Geräts und alle anderen Warnungen des angegriffenen Geräts überprüfen. Wir müssen uns die Varonis- und NTLM-Protokolle ansehen, um sicherzustellen, dass die Authentifizierungsversuche gestoppt werden, und die neue Aktivität weiterhin überwachen.

Das Varonis-Team in Russland führt eine kostenlose Cybersicherheitsanalyse und Risikoüberprüfung der IT-Infrastruktur durch. Lassen Sie dazu eine Anfrage auf der Website oder kontaktieren Sie uns auf bequeme Weise.

Source: https://habr.com/ru/post/de477356/


All Articles