Diverse Benutzerkonten haben plötzlich einen Account Lockout

Zunächst einmal denkt dabei ja jeder an die Account Lockout-Policy und ggf. irgendwelche Services, die noch mit alten, abgelaufenen Passwörtern versuchen einen Zugriff zu bekommen. Wenn sich sowas allerdings häuft und nicht ein einzelner Account betroffen ist, sondern mehrere könnte es sich auch auf einen Angriff auf das Netzwerk handeln. Wenn z.B. ein Programm oder eine MalWare versucht Passwörter per BruteForce zu knacken. Wenn so ein Angriff programmgesteuert ist, dann wird natürlich auch schnell mal eine große Anzahl von Accounts nach mehreren fehlgeschlagenen Loginversuchen gesperrt.

Ein Beispiel, auf Basis der MalWare Win32/Conficker.B wie so etwas aussehen kann: (Nähere Infos zu dieser Malware findet man auch hier: https://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.B )

Die Verbreitungsroutine dieses Virus attackiert Systeme die den Patch MS08-067 nicht installiert haben. https://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx

Auf der infizierten Maschine startet ein Dienst mit einem zufälligen Namen, z.B. RANDOM_NAME und stoppt dann die Dienste „Automatic Updates“, „Background Intelligent Transfer Service“ und „Error Reporting Service“ und setzt diese auf „Disabled“. Im System Ereignisprotokoll ist dabei diese Sequenz zu sehen:

12/29/2008 16:00:04 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME RANDON_NAME start

12/29/2008 16:00:05 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Automatic Updates stop

12/29/2008 16:00:06 4 0 7036 Service Control Manager N/A CLIENTNAME Automatic Updates stopped

12/29/2008 16:00:10 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Automatic Updates auto start disabled

12/29/2008 16:00:10 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Background Intelligent Transfer Service demand start disabled

12/29/2008 16:00:10 4 0 7035 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Error Reporting Service stop

12/29/2008 16:00:10 4 0 7036 Service Control Manager N/A CLIENTNAME Error Reporting Service stopped

12/29/2008 16:00:14 4 0 7040 Service Control Manager NT AUTHORITY\SYSTEM CLIENTNAME Error Reporting Service auto start disabled

Im Service Manager ist der Dienst RANDON_NAME nicht zu sehen, er ist unsichtbar.

Die Schadroutine des Virus, dessen Dienst unter der SVCHOST läuft startet dann Brute Force Passwort Angriffe auf Benutzerkonten und sperrt diese dann abhängig von der Anzahl der definierten Sperrschwelle (Account Lockout Threshold). Im Prinzip ist das oberflächlich betrachtet nicht so schlecht, da die Bruteforce-Attake dann hier ein jähes Ende findet. Die Accounts sind zwar erstmal gesperrt, aber der Schaden wäre evtl. doch größer. Denn sollte die Schadroutine erfolgreich sein, infiziert diese weitere Systeme mit gültigen Accounts, selbst wenn diese MS08-067 installiert haben.

Wer jetzt keine Account-Lockout-Policy hat, mag nun vielleicht darüber nachdenken es als Automatismus gegen Brute-Force zu implementieren. Allerdings tauscht man hier ggf. einfach nur Pest gegen Cholera. Denn AL  ist in so einem Falle eine DoS Attack Surface, und das ist ein schönes Beispiel, warum Account Lockout Policies sehr genau geplant sein sollten. Denn bei *wirklich* sicheren Kennwörten wären - außer der erhöhten DC Last - keine Symptome zu spüren, allerdings könnte der Angriff dann weiterhin unbemerkt laufen. Mit Account Lockout Policy steht jedoch ggf. das Business vollständig, weil sich keiner mehr anmelden kann. Aber dafür findet man recht schnell raus, das etwas nicht stimmt, weil die Benutzer plötzlich gesperrt sind.

Daher ist es natürlich umso wichtiger immer kontinuierlich die Security-Logs zu prüfen. Hier können wir pauschal nur den gut geplanten Einsatz von SCOM 2007 mit ACS empfehlen. Hier was zum Einstieg dazu: https://blogs.technet.com/smsandmom/archive/2007/08/29/scom2007-audit-collection-services-acs-reports-installation-configuration.aspx

O.k. weiter mit unserem Problem… Im ALOCKOUT.TXT aus den Account Lockout Tools ist zu sehen, dass unter dem SVCHOST falsche Anmeldeinformationen gesendet werden:

Mon Dec 29 21:57:44 2008, PID: 812, Thread: 3524, Image C:\WINDOWS\System32\svchost.exe, ***********************************************************

Mon Dec 29 21:57:44 2008, PID: 812, Thread: 3524, Image C:\WINDOWS\System32\svchost.exe, * Service Failure - See System Log for Details (ID: 7000) *

Mon Dec 29 21:57:44 2008, PID: 812, Thread: 3524, Image C:\WINDOWS\System32\svchost.exe, ***********************************************************

Mon Dec 29 21:57:44 2008, PID: 812, Thread: 3524, Image C:\WINDOWS\System32\svchost.exe, ***WNetUseConnectionW Failed!*** (3), Local: , Remote: \\SERVER\IPC$ , Password: Password Present, Window Title: , RC was: Logon failure: unknown user name or bad password. (1326), GLE was: Logon failure: unknown user name or bad password. (1326)

Über eine Software Restriction Policy lässt sich die Ausführung der Malware-DLL, die der Dienst  RANDON_NAME benötigt auf den Maschinen im Netzwerk natürlich leicht blockieren. Dazu kann eine HASH Rule konfiguriert werden wie unter  https://technet.microsoft.com/en-us/library/cc781507.aspx beschrieben. Siehe auch: https://technet.microsoft.com/en-us/library/cc786154.aspx

Die DLL selbst kann z.B. mit einem Tool wie GMER (https://www.gmer.net) identifiziert werden. Der Hash-Wert der DLL kann sich natürlich mit anderen „Varianten“ wieder ändern. Daher lieber selber mit dem Tool eurer Wahl nachschauen…

Im oben gezeigten Fall ist eine Umgebung immun, wenn alle Maschinen MS08-067 implementiert haben. Ist nur eine Maschine im Netz vorhanden, die MS08-067 nicht installiert hat, kann sich diese die neue MalWare einfangen und auch auf Maschinen verteilen, die MS08-067 installiert haben. Hier hat man ja quasi einen Insider…

Daher ist es immer ratsam entsprechende AntiVirus-Software und natürlich die aktuellen Security-Fixes installiert zu haben und die AntiVirus-Definitionen aktuell zu halten.

Außerdem ist es natürlich sinnvoll hier entsprechende Sicherheitsstrategien zu haben, denn oft finden Angriffe auf Systeme in Zeiten statt in denn die Admins oder Entscheidungsträger der IT nicht im Hause sind. So z.B. an Wochenenden oder Feiertagen wie Weihnachten, Chanukka, Ramadan, Kwanzaa,  oder z.B. Agbogbo-Za Fest der Ewe in Togo usw. (Ihr versteht was ich meine… ;-)) In diesen Zeiträumen sollte man bei sensitiven Systemen besonders wachsam sein und ggf. ab und an auch mal von zu Hause die Eventlogs auf Ungewöhnliches prüfen. Menschen in anderen Teilen der Welt haben da evtl. Ihren “Arbeitstag”.

Im Zweifelsfall ist der Microsoft Support für Geschäftskunden weltweit ja auch über die Feiertage 24x7 verfügbar, wenn so ein Problem auftritt. Zumindest hier ist schon mal beruhigend zu wissen, dass noch “andere” Menschen Arbeitstag haben… ;-)

Viele Grüße,

Thomas