Das Problem
Plötzlich begannen viele Benutzer der Systeme dieser Organisation zu berichten, dass sie aus ihren Active Directory-Konten ausgesperrt worden waren.
Die Umgebung
Das gesamte Netzwerk ist physisch und lokal. Es gibt keinen direkten Internetzugang. Es gibt eine Firewall, die das lokale Netzwerk über VPN mit einem größeren Unternehmensnetzwerk verbindet. Hier sind die Komponenten des lokalen Netzwerks:
NY
: Active Directory-Domäne.server1
: Windows Server 2008 R2; Active Directory-Domänencontroller fürNY
; Remotedesktop-Lizenzserver; HyperV-VM-Host; nur Administratoren dürfen eine Verbindung herstellen.server2
: Windows Server 2008 R2; Remotedesktop-Sitzungshost; Mitglied vonNY
; Benutzer stellen regelmäßig eine Verbindung zu diesem Computer her, um an Dokumenten zu arbeiten.NL
: Windows XP; VM läuft auf HyperV, gehostet aufserver1
; Mitglied vonNY
; wird nur von einigen ausgewählten Benutzern (vielleicht 3) zu regelmäßigen Zeiten jede Woche verwendet.FINXFER
: Windows XP; VM läuft auf HyperV, gehostet aufserver1
; Mitglied vonNY
; führt eine proprietäre Software aus, die in regelmäßigen Abständen Daten über das Netzwerk überträgt.- Auf verschiedenen anderen Windows XP-VMs
server1
werden hauptsächlich Hintergrunddienste ausgeführt, und normalerweise ist keine Verbindung über Remotedesktop hergestellt. - Verschiedene HP Thin Client-Maschinen, die für die Remotedesktopverbindung zum oben genannten verwendet werden.
Meine Untersuchung
Ich begann mit der Betrachtung des Ereignisprotokolls server1
(des Domänencontrollers). Ich filterte nach Ereignis4740 „Ein Benutzerkonto wurde gesperrt“und stellte fest, dass dieses Ereignis alle 2 bis 3 Minuten auftrat:
Jedes Vorkommen des Ereignisses sieht wie folgt aus:
A user account was locked out.
Subject:
Security ID: SYSTEM
Account Name: SERVER1$
Account Domain: NY
Logon ID: 0x3e7
Account That Was Locked Out:
Security ID: NY\JoeSmith
Account Name: JoeSmith
Additional Information:
Caller Computer Name: NL
Jedes Vorkommen hat einen anderen Active Directory-Benutzernamen, der Rest ist jedoch in allen Fällen gleich.
Dies ist für mich ein sofortiges Warnzeichen, da die Häufigkeit und Wiederholung der Sperrungen darauf schließen lassen, dass irgendjemand oder irgendetwas eine Liste von Benutzernamen durchgeht und versucht, Passwörter zu erraten, bis die betreffenden Benutzer gesperrt werden.
Ich stelle fest, dass jedes der Ereignisse die Zeile enthält Caller Computer Name: NL
, die Microsoft-Dokumentation für4740sagen, dass es enthält:
der Name des Computerkontos, von dem der Anmeldeversuch empfangen wurde und nach dem das Zielkonto gesperrt wurde.
Soweit ich das beurteilen kann, bedeutet dies, dass jemand oder etwas versucht, sich NL
mithilfe von NY
Anmeldeinformationen anzumelden, oder dass etwas auf dem NL
Computer selbst versucht, sich mithilfe NY
von Anmeldeinformationen zu authentifizieren.
Um zu versuchen, die Quelle zu finden, habe ich unter „Lokale Sicherheitsrichtlinien“ die folgenden Überwachungsrichtlinien aktiviert NL
:
Als vorübergehende Lösung haben wir damit begonnen, die NL
VM auszuschalten, wenn sie nicht verwendet wird. Die Sperren werden beendet, wenn die Maschine offline ist. Dies geht jetzt schon seit mehreren Wochen so.
Kürzlich habe ich die NL
VM über Nacht online gelassen, damit sich die Protokolle aufbauen konnten, und was ich fand, sah nicht gut aus. Ich habe festgestellt, dass die folgenden beiden Ereignisse NL
die ganze Nacht über mehrmals pro Sekunde auftraten:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 680
Date: 1/20/2020
Time: 8:31:24 PM
User: NT AUTHORITY\SYSTEM
Computer: NL
Description:
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: Finance
Source Workstation: FINXFER
Error Code: 0xC000006A
Gefolgt von:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 1/20/2020
Time: 8:31:24 PM
User: NT AUTHORITY\SYSTEM
Computer: NL
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: Finance
Domain: FINXFER
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NETWARE_AUTHENTICATION_PACKAGE_V1_0
Workstation Name: FINXFER
Nachdem dies mehrmals wiederholt wurde, trat schließlich dieses Ereignis auf:
Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 644
Date: 1/20/2020
Time: 8:31:29 PM
User: NT AUTHORITY\SYSTEM
Computer: NL
Description:
User Account Locked Out:
Target Account Name: Administrator
Target Account ID: NL\Administrator
Caller Machine Name: FINXFER
Caller User Name: NL$
Caller Domain: NY
Caller Logon ID: (0x0,0x3E7)
Das ist etwas anders als erwartet, da nur die Anmeldung als „Administrator“ versucht wird und nicht die von zufälligen Benutzern, wie ich es vorher gesehen habe. Natürlich kann das Administratorkonto nicht wirklich gesperrt werden, also ist es logisch, dass es versucht, diesen Benutzer zu erraten, wenn es sich um einen Angreifer handelt.
Nun FINXFER
überträgt die VM zwar Informationen über das Netzwerk, aber sie solltenichttunirgendetwasmit der NL
Maschine und auf keinen Fall mehrmals pro Sekunde.
Ideen?
Welche anderen Tools kann ich verwenden oder welche anderen Protokolle kann ich durchsuchen/aktivieren, um die Quelle dieser Anmeldeversuche zu ermitteln, die zu Kontosperrungen führen? Wie kann ich herausfinden, welches Programm FNIXFER
die Anmeldeversuche initiiert?
Antwort1
Sie sollten wirklich verwendenErweiterte Überwachungsrichtlinienjetzt und legen Sie sie für alle Computer über die Gruppenrichtlinie fest. Die erweiterten Richtlinien sind detaillierter und bieten spezifischere Informationen.
Der Artikel über dieKontosperrung prüfenDie Richtlinie beschreibt die empfohlenen GPO-Einstellungen – im Wesentlichen die Prüfung von Fehlern für alles, DCs, Mitgliedsserver, Arbeitsstationen. (Die Kategorien für „stärkerer Erfolg“ und „stärkerer Fehler“ gelten, wenn Ihre Umgebung eine strengere Prüfung erfordert – „allgemeiner Erfolg/Fehler“ sind Einstellungen, die überall angewendet werden sollten.
Ich empfehle, am Anfang des Abschnitts zu beginnen und alle Ihre Überwachungsrichtlinien gemäß den Empfehlungen zu überprüfen. Zumindest sollten Sie alle Anmelde-, Kerberos- oder Authentifizierungsüberwachungseinstellungen aktivieren.
Sehen Sie auf Ihrem Mitgliedsserver überhaupt Anmeldeereignisse für die spezifischen Benutzer? Und wenn ja, um welche Art von Anmeldungen handelt es sich? Interaktiv, Netzwerk...? Welche Anwendung(en) laufen auf der Box – ist es ein Webserver, Terminalserver usw.? Werden geplante Aufgaben im Kontext eines Domänenbenutzers ausgeführt? (anstatt SYSTEM) Oder welche, die AD abfragen könnten?
Antwort2
ich würde empfehlenPrüfer für Netwrix-KontosperrungenDa es Ihnen sagt, welche Richtlinien Sie einrichten müssen, und dann genau zeigt, woher die Sperrung kam.
Aus Erfahrung:
- Name eines PCs bedeutet ein falsches Passwort durch den Benutzer
- Name Ihres PDC bedeutet Sperrung von Office365 oder RADIUS-Server
- kein Computername bedeutet normalerweise einen Fehler bei der biometrischen Authentifizierung
Wenn der Verdacht besteht, dass sich jemand in Ihrem Netzwerk befindet (ziemlich wahrscheinlich, da XP seit einiger Zeit nicht mehr mit Sicherheitspatches unterstützt wird), überprüfen Sie Ihren XP-Rechner mit Malware Bytes oder einem Antivirus, der dies noch unterstützt. Wenn möglich, aktualisieren Sie ihn auf W10 (Microsoft bietet es immer noch kostenlos an).
Wenn Sie eine veraltete Software verwenden und diese nicht aktualisieren können, beschränken Sie die Anmeldung von Domänenadministratoren und verhindern Sie, dass Benutzer Administratorrechte erlangen oder auf das gesamte Netzwerk zugreifen können.