Was veranlasst meinen Domänencontroller, Dutzende erfolgreicher Authentifizierungsversuche pro Sekunde zu protokollieren?

7

Wir haben eine Domain mit ca. 15 Servern und ca. 30 Workstations. Server sind meistens 2008r2 und Workstations sind meistens Windows 7. Die beiden DCs sind 2012r2. Alle paar Wochen wird eines unserer Administratorkonten gesperrt. Ich versuche die Ursache einzugrenzen und habe eine Sackgasse erreicht.

Folgendes habe ich.

Das Ereignisprotokoll auf dem PDC zeigt Ereignis 4776 - Überwachungserfolg:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Alle für denselben Benutzernamen und mehrmals pro Sekunde.

Basierend auf den Ereignis-IDs handelt es sich eher um NTLM-Anmeldungen als um Kerberos. Obwohl die Art der verwendeten Authentifizierung für mich weniger besorgniserregend ist als die Schermenge. Dies geschieht mehrmals pro Sekunde und wiederholt sich alle paar Sekunden ad infinitum, alle Stunden Tag oder Nacht oder Wochenende.

Das Ereignisprotokoll zeigt auch die Überwachungserfolgsereignis-ID 4624 (Anmeldung) und 4634 (Abmeldung) für diesen Benutzernamen an, aber wie im obigen Ereignis ist das Feld "Arbeitsstation" leer.

Ich habe die ausführliche Netlogon-Protokollierung aktiviert und das netlogon.log wird angezeigt 

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

Und so weiter und so fort. Die offensichtliche Quelle dieser Anmeldungen (über XYZ) können Workstations und Server aus dem gesamten Netzwerk sein.

Dies sieht eindeutig wie eine Automatisierung oder ein Skript aus. Da die Anmeldungen im Allgemeinen alle erfolgreich sind, glaube ich nicht, dass es sich um einen Angriffsversuch handelt. Einige der Anmeldungen schlagen jedoch von Zeit zu Zeit fehl, aber ich habe kein Muster für den Fehler identifiziert und sie treten so selten auf, dass sie (an den meisten Tagen) das Konto nicht sperren. Der Fehlercode, falls vorhanden, lautet normalerweise 0xc0000022 (Zugriff verweigert).

Ich habe unseren Fernüberwachungsagenten (derzeit Kaseya, aber wir wechseln endlich zu LabTech) von einem der Server deaktiviert und deinstalliert, aber immer noch neue Ereignisse von diesem Server gesehen, sodass Automatisierungsaufgaben ausgeschlossen sind. Ich habe auch den Taskplaner auf einigen Servern überprüft und nichts Außergewöhnliches gefunden. Ich habe Dienste überprüft, um Anmeldekonten zu überprüfen, und dieses Konto wird in keinem Dienst verwendet.

Ich habe Netstat lange Zeit ausgeführt und hauptsächlich Verbindungen zum PDC von "System" und "System Idle Process" gesehen. Ich habe gelegentlich Verbindungen von spoolsrv und lsass und ismserv gesehen (der Server, auf dem ich teste, ist ein Citrix XenApp-Server, aber andere "Quell" -Server befinden sich nicht in der XenApp-Farm, und natürlich auch keine "Quell" -Workstationen). Ich habe den Druckspooler-Dienst nur zum Testen gestoppt und er hatte keine Auswirkungen auf die Anmeldeereignisse.

Ich arbeite bei einem MSP und dies ist unser Hauptadministratorkonto für Techniker. Daher ist es von hoher Priorität, dass es funktioniert und sicher ist. Die letzte Idee, die ich noch habe, ist, das Passwort zu ändern und zu sehen, was kaputt geht, aber ohne zu wissen, wofür das Konto verwendet wird, könnte dies möglicherweise katastrophale Folgen haben. Mein Verdacht ist jedoch, dass dies möglicherweise nur eine falsch konfigurierte AD ist.

Hat jemand so etwas schon einmal erlebt und konnte die Quelle identifizieren?

active-directory windows-server-2008-r2 windows-server-2012-r2 Thomas
quelle
Für alle, die neugierig auf die hohe Anzahl von Servern sind, gibt es XenApp-Server mit öffentlich zugänglichem SharePoint für eine hochmobile Belegschaft mit BYOD. Sie hatten auch frühere IT-Mitarbeiter, die ihre Infrastruktur für die Größe ihres Unternehmens ein wenig über Bord gingen. Seit sie uns unter Vertrag genommen haben, haben wir versucht, sie ein wenig auf etwas zu reduzieren, das ihren Bedürfnissen besser entspricht.
Thomas
Sie können versuchen, Microsoft Network Monitor auf einem der Server zu installieren, eine Erfassung zu starten, auf einen Eintrag vom Server zu warten, um im Netlogon-Protokoll protokolliert zu werden, und dann die Erfassung zu überprüfen, um festzustellen, ob Sie die Konversation in Network Monitor finden können . Der Netzwerkmonitor sollte Ihnen den für die Konversation verantwortlichen Prozess anzeigen. Wenn dies nicht ausreichend einschränkt, können Sie Network Monitor in Verbindung mit Process Monitor verwenden, um den verantwortlichen Prozess zu identifizieren.
Joeqwerty
Microsoft Network Monitor ist veraltet und wird durch Microsoft Message Analyzer ersetzt. Gleiches Angebot wie Wireshark. Ich habe eine Paketerfassung durchgeführt und fand absolut nichts hilfreich. Die einzigen Ereignisse, die eng mit NetLogon-Ereignissen korrelieren, sind WMI- und RPC-Verbindungen.
Thomas
Richtig, NetMon ist veraltet, aber es ist immer noch ein gutes Werkzeug. Wenn Sie Message Analyzer noch nicht verwendet haben, kann dies etwas überwältigend sein. NetMon ist ziemlich einfach und intuitiv. Ich benutze es normalerweise vor allem anderen. - In Bezug auf Ihre Erfassung enthält der RPC-Verkehr möglicherweise einige Hinweise.
Joeqwerty
Ja, nichts. Es wird eine MSRPC-Bindung gesendet und Ack empfangen, um eine verschlüsselte Sitzung zu erstellen, gefolgt von einem gesendeten und empfangenen NRPC-Paket, das eine NetrLogonSamLogonEx-Anforderung und -Antwort enthält, wobei die beiden letzteren verschlüsselt werden. Der aufrufende Prozess auf dem Quellcomputer ist LSASS, der den Netlogon-Dienst ausführt. Es gibt überhaupt keine nützlichen Details in den Paketdaten des Bindungsverkehrs und natürlich sind die verschlüsselten Pakete für mich nutzlos.
Thomas

Antworten:

1

Ich empfehle, die NTLM-Überwachung auf Ihren DCs weiter zu aktivieren. Aktivieren Sie mithilfe der Standarddomänencontrollerrichtlinie die folgenden Richtlinieneinstellungen:

Netzwerksicherheit: NTLM einschränken: Eingehenden Datenverkehr prüfen = Überwachung für alle Konten aktivieren Netzwerksicherheit: NTLM einschränken: NTLM-Authentifizierung in dieser Domäne prüfen = Alle Netzwerksicherheit aktivieren: NTLM einschränken: Ausgehender NTLM-Verkehr auf Remoteserver einschränken = Alle prüfen

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Navigieren Sie nach der Aktivierung in Ihrer Ereignisanzeige zu: Anwendungs- und Dienstprotokolle> Microsoft> Windows> NTLM> Operational

Es gibt Ereignisse mit Zeitstempeln, die Ihren Zeitstempeln für Netlogon-Ereignisse entsprechen. In diesem Protokoll wird der tatsächliche Name der Arbeitsstation angezeigt.

Der Name des sicheren Kanals in diesem Protokoll hilft Ihnen dabei, die Entstehung des Prozesses einzugrenzen, damit Sie die Quelle besser identifizieren können.

Homebrew Hopfen
quelle
Danke für die Antwort. Leider ist dieser bestimmte Kunde nicht länger ein Kunde von uns, so dass ich Ihre Anweisungen nicht ausprobieren kann. Ich habe Ihre Antwort akzeptiert, obwohl mein eigenes Verständnis von AD mir sagt, dass ich die Details erhalten sollte, die ich brauche. (Ich bin mir nicht sicher, warum ich nicht daran gedacht habe, die Prüfungsrichtlinien anzupassen, aber Sie rocken, weil Sie sie vorgeschlagen haben.)
Thomas