Das Problem

Das Problem

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ür NY; Remotedesktop-Lizenzserver; HyperV-VM-Host; nur Administratoren dürfen eine Verbindung herstellen.
  • server2: Windows Server 2008 R2; Remotedesktop-Sitzungshost; Mitglied von NY; Benutzer stellen regelmäßig eine Verbindung zu diesem Computer her, um an Dokumenten zu arbeiten.
  • NL: Windows XP; VM läuft auf HyperV, gehostet auf server1; Mitglied von NY; 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 auf server1; Mitglied von NY; 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 server1werden 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:

Häufige Kontosperrungen

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 NLmithilfe von NYAnmeldeinformationen anzumelden, oder dass etwas auf dem NLComputer selbst versucht, sich mithilfe NYvon Anmeldeinformationen zu authentifizieren.

Um zu versuchen, die Quelle zu finden, habe ich unter „Lokale Sicherheitsrichtlinien“ die folgenden Überwachungsrichtlinien aktiviert NL:

Neu aktivierte Sicherheitsüberwachungsrichtlinien

Als vorübergehende Lösung haben wir damit begonnen, die NLVM 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 NLVM ü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 NLdie 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 NLMaschine 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 FNIXFERdie 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.

verwandte Informationen