DoS mit Account Lockout

Die ganze Welt spricht von "Denial of Service"-Attacken (DoS) und auch über verteilte Angrifft durch BOT-Netze, bei denen mittlerweile sogar Mobiltelefone als kleine Rechner mit Internetzugang mitspielen. Auf der anderen Seite öffnen sich Firmen immer mehr, um Dienste ihren Mitarbeitern auch von unterwegs (z.B. Outlook über HTTP, Pushmail, OWA, Lync, Sharepoint ) erreichbar zu machen. Natürlich kommt dabei eine Firewall-Lösung zum Einsatz, damit der liebe IIS nicht ungesichert aus dem Internet erreichbar ist. Aber sind sie damit wirklich "sicher"? Beachten Sie dazu auch Account Lockout mit Docker und Account Lockout durch AzureVM.

Account Lockout Best Practices White Paper
http://www.microsoft.com/en-nz/download/details.aspx?id=6218

Das Problem

Natürlich kann man Webseiten durch Firewalls, Portfilter und Reverse Proxy-Systeme sicher. Auch starke Kennworte sind ein effektives Mittel, um den unerlaubten Zugriff zu erschweren. Aber ein Risiko ist bei den normalen Diensten immer vorhanden:

Eine Firma ist gut beraten, ein Konto bei zu vielen fehlerhaften Anmeldungen für einige Zeit auszusperren um weitere Anmeldeversuche zu unterbinden. Dies ist üblicherweise ein effektives Mittel, um Angriffe mit Wörterbüchern auf Kennwort zu verhindern. Sie können dies auch von ihrer SIM-Karte im Mobiltelefon oder der EC-Karte. Dreimal falsche PIN und die Karte ist gesperrt. Ohne diese Schutzfunktion wären die in der Regel 4-stelligen Zifferncodes (von denen es also 10.000 Varianten gibt) sehr schnell gehackt. mit 1:3333 ist die Wahrscheinlichkeit aber immer noch erschreckend gut und nahe an 4-Richtige beim Lotto (1:1082), wenn Allerdings muss hier der Angreifer Zugriff auf die Karte haben, so dass dies ein eher theoretischer Wert ist. Sie müssten also schon sehr viele SIM/EC-Karten stehlen und einige Zeit vor dem Automat verbringen.

Anders sieht es im Netzwerk aus. Ohne das Internet konnten Firmen ein Konto sogar gesperrt lassen, so dass der Anwender dies erst wieder frei schalten lassen musste. Über das Eventlog können Sie zudem ermitteln, wo der Versuch statt gefunden hat.

Selbst wenn nach z.B. drei Fehlerversuchen das Konto für ein paar Minuten gesperrt war, ist das aufgefallen aber war nicht allzu tragisch.

Einfallstore

Heute dies das aber schon deutlich anders aus, da immer mehr Dienste eine Anmeldung erfordern und nicht nur Benutzer, sondern auch Dienstkonten eingesetzt werden. Und immer mehr Tore zum großen anonymen Internet machen es Angreifern natürlich leicht, einen Zugang zu finden und mit Kombinationen aus Benutzername und Kennwort eine Anmeldung versuchen können. Es gibt nämlich sehr viele Dienste, welche einfach mit Benutzername und Kennwort arbeiten. Und das beschränkt sich nicht nur auf Exchange.

  • OWA und ActiveSync
    Den meisten Administratoren werden diese beiden Zugänge direkt als mögliche Angriffsziele einfallen. Oft ist es nicht allzu schwer den Hostnamen zu erraten.
  • Autodiscover und EWS
    Aber neben den für Anwender bekannte Zugänge gibt es mit Autodiscover und den Exchange Web Services weitere per HTTPS und Authentifizierung erreichbare Dienste. Gerade der Autodiscover-Zugang wird einem Angreifer über den DNS-Eintrag zur automatischen Konfiguration förmlich präsentiert. Und oft ist der gleiche Server dann ja auch OWA-Server.
  • RPC/HTTP (Outlook und Terminal Dienste)
    Outlook als auch MSTSC können ihre Daten mittlerweile auch in HTTPS-Pakete einpacken und damit durch viele Firewalls tunneln. Klar dass der RCPProxy, bei dem die Pakete landen, erst mal die Anmeldedaten des Benutzers einfordert. Schon wieder ein Tor um Kennworte zu erraten und aus versehen oder absichtlich das Konto zu sperren.
  • SMTP/POP3/IMAP4/LDAP
    Wer nun glaubt, dass durch "nicht Microsoft Produkte" alles besser wird, der irrt. Jede Plattform, die eine Anmeldung erfordert, ist potentiell gefährdet. Um bei Mail und Exchange zu bleiben sind diese Protokolle ebenfalls Angriffspunkte. Und ich hoffe nicht, das Sie ihren DC per LDAP aus dem Internet erreichbar machen, nur damit POP3/IMAP4-Clients ein Adressbuch nutzen können.
  • OCS/Lync Edge
    Der Edge-Server sichert zwar Lync und OCS gegen Protokollverletzungen ab, aber wenn Sie "Remote Access" zulassen, dann muss er erst mal den Anmeldversuch, wenn er logisch korrekt ist, an den Frontend Pool weiter geben, welcher dann die Anmeldedaten verifiziert. Falsche Daten unterbrechen die Verbindung aber verhindern nicht weitere Verbindungen.
  • Sharepoint, Intranet und andere Webseiten/Portale
    Natürlich sind alle Webseiten, die eine Anmeldung erfordern, ebenso mögliche Ziele.
  • VPN (PPTP, L2TP, HTTPS)
    Selbst der Versuch nun die "bösen" im Internet mit einem VPN außen vor zu halten, kann allein mit einem einfachen VPN nicht gelingen, da auch hier eine Anmeldung erforderlich ist.

Es ist also weit mehr als "nur" ein bisschen Outlook WebApp, was ihr Netzwerk öffnet und eine Kennwortattacke ermöglicht. Ich sage nicht, dass Angriffe nicht auch von innen erfolgen können. Mit einer guten Überwachen können Sie aber sehr schnell solche Angriffe erkennen, auf einen IP-Adresse oder einen Client zurückführen und mit der MAC-Adressen und dem Port bis zu Dose an der Wand gelangen. Wenn ihr Wachschutz schnell ist oder eine Zugangskontrolle erfolgt, muss jemand schon recht unerfahren sein, um von intern solche Dinge zu starten.

Sonderfall "Administrator"

Unter allen Benutzern gibt es immer einen, der "besonders" ist. Der eingebaute "Administrator" der Domäne kann nicht gesperrt werden. Damit ist natürlich dieses Konto prädestiniert für einen Angriff, da immer wieder neue Kennworte versucht werden können. Versucht sich ein Administrator auf dem PC oder per RDP anzumelden, dann können mehrere Fehlerversuche durchaus durchgeführt werden aber die Anmeldung wird dann immer länger verzögert. Die fehlerhaften Anmeldungen werden natürlich auch im Eventlog verzeichnet:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          9/8/2014 12:19:17 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure User:          N/A
Computer:      dc1.msxfaq.net
Description:
An account failed to log on.

Subject:
        Security ID:		SYSTEM
        Account Name:		DC1$
        Account Domain:		MSXFAQ
        Logon ID:		0x3e7

Logon Type:			7

Account für Which Logon Failed:
        Security ID:		NuLL SID
        Account Name:		Administrator
        Account Domain:		MSXFAQ

Failure Information:
        Failure Reason: unknown User name or bad password.
        Status:			0xc000006d
        Sub Status:		0xc000006a

Process Information:
        Caller Process ID:	0x1d0
        Caller Process Name:	C:\Windows\System32\winlogon.exe

Network Information:
        Workstation Name:	DC1
        Source Network Address:	127.0.0.1
        Source Port:		0

Detailed Authentication Information:
        Logon Process: User32 
        Authentication Package:	Negotiate
        Transited Services:	-
        Package Name (NTLM only):	-
        Key Length:		0

This event is generated when a logon request fails. It is generated on the computer 
where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. 
This is most commonly a service such as the Server service, or a local process 
such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common 
types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system 
requested the logon.

The Network Information fields indicate where a remote logon request originated. 
Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this
 specific logon request.
  - Transited services indicate which intermediate services have participated in this logon request.
  - Package name indicates which sub-protocol was used among the NTLM protocols.
  - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4625</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2014-09-07T22:19:17.884750000Z" />
    <EventRecordID>21678</EventRecordID>
    <Correlation />
    <Execution ProcessID="524" ThreadID="3640" />
    <Channel>Security</Channel>
    <Computer>dc1.msxfaq.net</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">DC1$</Data>
    <Data Name="SubjectDomainName">MSXFAQ</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">Administrator</Data>
    <Data Name="TargetDomainName">MSXFAQ</Data>
    <Data Name="Status">0xc000006d</Data>
    <Data Name="FailureReason">%%2313</Data>
    <Data Name="SubStatus">0xc000006a</Data>
    <Data Name="LogonType">7</Data>
    <Data Name="LogonProcessName">User32 </Data>
    <Data Name="AuthenticationPackageName">Negotiate</Data>
    <Data Name="WorkstationName">DC1</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x1d0</Data>
    <Data Name="ProcessName">C:\Windows\System32\winlogon.exe</Data>
    <Data Name="IpAddress">127.0.0.1</Data>
    <Data Name="IpPort">0</Data>
  </EventData>
</Event>

Auf der einen Seite kann das natürlich als "Lücke" gewertet werden. Auf der anderen Seite könnte ja niemand den Administrator wieder entsperren, wenn es nicht noch weitere funktionsfähige Administrator-Konten gäbe. Als Schutz könnten Sie aber den Administrator "umbenennen". Allerdings sollten Sie dies am besten per Gruppenrichtlinie machen, damit es wirklich auch auf allen Systemen erfolgt.

Lösungen

Es ist gar nicht so einfach, für die verschiedenen Dienste und Wege eine passende Lösung zu finden. Zugänge, die einen Browser verwenden, können vom Anwender zusätzliche Daten oder Informationen erfordern (/z.B. Tokens, Captchas etc.). Das geht aber nicht für Protokolle, die für den Anwender gar keine GuI anbieten. Entsprechend sind die Möglichkeiten eingeschränkt. Hier ein paar Optionen

  • Schlecht erratbare Benutzernamen
    Die meisten Firmen nutzen eine Bildungsregel, um die Anmeldenamen zu definieren. Hier stellt sich die Frage, wie einfach jemand aus dem natürlichen Namen einer Person auf das Anmeldekonto zurückschießen kann. Die meisten Firmen nutzen eine Kombination aus Vorname und Nachname zur Bildung des SAM-Accountname (15 Stellen). Seit Windows 2000 kann ein Anwender sich aber auch mit User Principal Name (UPN) anmelden und der ist meist mit der Mailadresse oder SIP-Adresse identisch.
    Sicher können Sie den Namen nun kryptisch machen, aber damit ärgern sie viel mehr die Anwender und den Support. Es reicht nur eine interne Person, die eine Liste der Benutzer per CSVDE exportiert und publiziert. Viele Mailserver schreiben z.B. auch die Kontendaten mit in den Header etc. Der Schutz wäre also nur schwach mit einem hohen Aufwand.
  • Eigene Accounts
    Sie könnten natürlich nun anfangen und doppelte Konten zu pflegen, d.h. für den Zugang aus dem Internet werden einfach andere Anmeldedaten eingesetzt, welche dann nur die erforderlichen Daten erreichbar machen. Die primären internen Anmeldedaten würden damit nicht benötigt und könnten intern weiter genutzt werden.
  • Tokens oder Captcha
    Die Einführung von Tokens oder Captchas als zusätzliches Kriterium bei einer Anmeldung erschwert natürlich automatische Angriffe auf Konten. Das Problem dabei ist natürlich, dass der Zugang für den Anwender auch die Anforderung dieser Daten bereit stellt. Das wird z.B. bei automatischen Zugriffen auf Autodiscover, EWS und natürlich ActiveSync schwer. Aber selbst wenn sie z.B. OWA per Token absichern, so kann ein Angreifer auch hier einfach mehrfach eine Anmeldung versuchen, was letztlich nicht das interne Konto aber dennoch das Token sperren sollte.
  • Zertifikate
    Anstelle von Benutzername und Kennwort lassen verschiedene Dienste auch eine Authentifizierung per Clientzertifikat zu. Das ist durchaus ein interessanter Weg, um Anwendungen sicher bereitzustellen ohne mit Benutzername und Kennwort zu arbeiten. Ein Angreifer müsste schon ein genau passendes Zertifikat mitbringen. Ohne Zertifikat kommt die Verbindung gar nicht erst zustande und mit jedem anderen Zertifikat gibt es keine Übereinstimmung mit einem AD-Konto, welches gesperrt werden könnte. Interessant ist, dass z.B. ActiveSync per Zertifikat gesichert werden können und Lync ebenfalls ein Zertifikat ausstellt.
  • VPN/Direct Access
    Viele Angriffsflächen ersparen Sie sich allein dadurch vermeiden, indem diese gar nicht zum Internet geöffnet werden. Es ist durchaus eine Überlegung wert, ob Clients ein VPN aufbauen, und damit schon "authentifiziert" sind. Das hält schon einmal anonyme Zugriffe ab. So nutzt z.B. der Mobile Device Manager 2008) diesen Weg. Gemanagte Clients nutzen ein permanentes IPSEC-VPN. Mit Windows 7 ist natürlich Direct Access eine elegante Möglichkeit. Das funktioniert aber nicht mehr, wenn Sie einen wirklich universellen Zugriff von allen PCs der Welt bereitstellen wollen.
  • Firewall/Application Filter
    Es gibt Firewalls, die etwas mehr "Grips" bei der Analyse der Protokolle an den Tag legen. Gerade wenn die Firewall auch die Authentifizierung durchführt, kann Sie versuchen, solche "Versuche" zu erkennen und z.B. nach einigen Fehlversuchen die IP-Adresse oder Anmeldeversuche für diesen Benutzer zu verhindern. So könnte zumindest eine Sperrung durch externe Zugriffe verhindert werden.
    Siehe dazu auch Abschnitt "TMG" auf dieser Seite
  • Keine Vorsorge
    Zuletzt können Sie natürlich bei der Risikoabschätzung auch darauf kommen, dass der ganze Aufwand für die eventuell mögliche Attacke in keinem Verhältnis zu Aufwand und Mühen bedeutet und einfach weiter mit Benutzername und Kennwort arbeiten. Übrigens basieren die allermeisten Dienste im Internet, angefangen bei Freemailern über Webspace Provider bis zu Cloud-Angeboten wie Office365 über diesen einfachen Mechanismus. Ein Konto wird nach zu vielen Fehlerversuchen für einige Zeit gesperrt.

Auch hier ist es also wieder eine Risikoanalyse, die letztlich den Ausschlag geben wird. Dazu gehört natürlich auch die angewendete Kennwortrichtlinien zu überprüfen. Vielleicht ist es auch tolerierbar, dass das Konto nicht allzu lange ausgesperrt bleibt oder ein paar Versuche mehr erforderlich sind. ehe das Konto gesperrt wird. Beachten Sie dabei auch, das diverse Dienste immer zwei Anmeldungen versuchen, z.B. die Anmeldung per Kerberos und wenn dies nicht funktioniert, dann auf NTLM zurück schwenkt. So können auch in der GPO eingestellten drei Versuche schon beim zweiten Versuch das Konto sperren.

DoS Schutz in Produkten

Auch wenn Windows selbst im Active Directory Konten als Schutz aussperren kann, so wissen Sie nun um das Problem, dass sich externe Dienste darauf besser nicht verlassen und vielleicht schon vorher bei einer Anzahl Fehlversuchen diesen Weg blockieren und so der globalen Sperre des Benutzers zuvor kommen.

TMG

Seit dem TMG 2010 SP2 gibt es "endlich" auch eine Lösung für die veröffentlichten Webseiten, zumindest solange TMG per Formular die Anmeldedaten vorab einholt.

ADFS 2012R2

TMG ist abgekündigt und Microsoft platziert den WAP - Web Application Proxy hier als neuen Reverse Proxy. WAP als auch andere Dienste erwarten häufig nicht mehr die direkte Anmeldung des Anwenders per Username/Kennwort sondern unterstützen eine Anmeldung mit SAML-Tokens, die ein ADFS-Server ausstell. Seit ADFS 2012R2 gibt es auch hier die Funktion, eine DoS-Attacke gegen Anmeldedaten zu verhindern. Ein ADFS-2012R2-Server erlaubt nur eine bestimmte Anzahl an Fehlversuchen zur Authentifizierung und blockiert dann weitere Anmeldungen bis zum Ablauf einer Sperrzeit. Siehe auch ADFS Extranet Lockout.

In Verbindung mit einer etwas höheren Fehlversuchsrate im Active Directory und einer kürzeren Sperrzeit dort, kann eine Sperrung eines internen Kontos von Extern verhindert werden. Das ist allerdings nur bedingt ein Schutz, wenn der Anwender selbst auch von außen oder intern arbeitet und ADFS-Tokens beziehen möchte. Daher ist es immer noch ratsam, intern vielleicht auf ADFS zu verzichten und nur externe Zugriffe mit ADFS abzusichern. Die Konfiguration erfolgt per PowerShell auf dem ADFS-Server:

# Abrufen der aktuellen Einstellungen
Get-AdfsProperties | Format-List *extranet* 

# Setzen der Einstellungen auf 5 Fehlerversuche in 15 Min
Set-AdfsProperties `
   -EnableExtranetLockout $true `
   -ExtranetLockoutThreshold 5 `
   -ExtranetObservationWindow (New-Timespan -Minutes 15)

Damit wird auch diese Tür etwas sicherer.

Office 365 / Azure

Wenn Sie sich an Office 365 oder Azure mit Konten in der Cloud anmelden und Kennworte in der Cloud oder Password Hash Sync (PHS) nutzen, kann können Sie in Azure auch einen Schutz aktivieren.

Wenn sie hingegen Pass-Through Authentifizierung (PTA) oder eben ADFS nutzen, dann müssen Sie die Funktion On-Premises umsetzen, da hier die Anmeldung erfolgt.

Lync

Das Lync Team hat sich dieser Problematik schon mal für den Edge-Server angenommen, welcher als Einfallstor denkbar ist.

Aus meiner Sicht greift dies aber zu kurz, da auch Lync andere Dienste wie Autodiscover, EWS nutzt und auch die Lync Webservices per HTTPS mit Authentifizierung angesprochen werden. Eigentlich wäre es an der Zeit, dass die Domaincontroller, welche letztlich die fehlerhaften Anmeldungen protokollieren und das Konto sperren, dies etwas feiner Abstufen und erst mal Fehlversuche von den Clients bzw. Servern blocken und bei wiederholten Fehlversuchen das Konto dann doch sperren.

  • LyncShield
    http://lyncshield.com/
    Inwieweit eine kommerzielle Erweiterung mit Zwei-Faktor-Authentifizierung hier hilft, müssen Sie selbst beantworten

Diagnose

Ob ihr Netzwerk "under Fire" ist, können Sie ohne Überwachung in der Regel an den Symptomen erkennen.

  • Benutzer beschwert sich
    weil sie sich nicht mehr anmelden können oder zwar noch angemeldet sind, aber nicht mehr auf Ressourcen zugreifen können. Sehr perfide, wenn jemand gerade in Word ein Dokument geöffnet hat und nicht mehr speichern kann. Leider kann er dann auch in der Regel den Helpdesk nicht mehr per Mail oder Webseite informieren und beim Einsatz von VoIP könnte es je nach Applikation auch schwierig werden.
  • PCs sind nicht mehr in der Domain
    Das passiert, wenn jemand versucht die Computerkonten zu erraten und damit das Computerkonto "sperrt". Wenn dann der PC die Identität eines Benutzers prüfen möchte, gelingt ihm das natürlich nicht mehr.
  • Eventlogeinträge und AD-Einträge (Siehe auch TrackLoginEvents)
    Windows protokolliert jeden "Lockout-Vorgang", im Eventlog. Zudem könnten Sie im Active Directory die Änderung ebenfalls sehen und überwachen. Es ist dann natürlich aber schon passiert.

    Das Tool EventCombMT hilft bei der Suche durch viele DCs, wenn man die richtigen Nummern der Events kennt

    Bei Windows 2008 ist es der Event 4740, während Windows 2003 noch den Event 675 genutzt hat.
  • AD-Feldänderungen überwachen (z.B. GET-ADChanges oder Get-USNChanges)
    Wer mit einem Skript oder Tool Änderungen im Active Directory überwacht, kann anhand des Felds "lockouttime" erkennen, dass ein Konto gesperrt wurde:

    Entsprechend können Sie natürlich auch direkt darauf reagieren.

Dennoch bleibt die Sperrung von Konten durch unerlaubte externe Zugriffe eine latente Gefahr für Netzwerke. Auch wenn dadurch zwar keine Daten veruntreut werden, kann eine gezielte Sperrung von Konten mehr als nur etwas Verdruss erzeugen.

Auflisten der gesperrten Benutzer

Über die PowerShell können Sie natürlch auch schnell ermitteln, welche Benutzer aktuell ausgesperrt sind:

Get-ADUser `
   -Filter * `
   -Properties sAMAccountName,DisplayName,LockedOut,LockoutTime,Enabled,AccountExpirationDate `
| where { `
        $_.lockedout -eq "True" `
   -and $_.enabled -eq "True" `
   -and (($_.AccountExpirationDate -gt (Get-Date) -or ($_.AccountExpirationDate -eq $null)))`
  }


AccountExpirationDate :
DisplayName           : User1
DistinguishedName     : CN=User1,OU=Anwender,DC=msxfaq,DC=de
Enabled               : True
GivenName             : Frank
LockedOut             : True
LockoutTime           : 132034221885300179
Name                  : User1
ObjectClass           : user
ObjectGUID            : 123456-1234-1234-1234-1234567890
SamAccountName        : fcarius2
SID                   : S-1-5-21-2213-30417519-71842111-7911
Surname               : User1

Über das Feld "Lockout-Time" können Sie auch ermitteln, wie lange das Konto schon gesperrt ist. Sie können auch relativ leicht per "Convertto-HTML" eine WebSeite daraus erstellen und für den Support bereit stellen oder den Anwender informiereren.

Für Nagios, PRTG etc. können Sie natürlich auch einfach die Anzahl der Elemente als Counter in ein Monitoring übertragen

Wer das ohne AD-PowerShell machen will, kann die Abfragen natürlich auch direkt per ADSI absetzen.

Hinweis
Diese Abfragen kann "jeder DomainUser" machen. Sie müssen dazu nicht Administrator sein

Meldung bei Lockout

Wäre es nicht genial, wenn ein Anwender per Mail informiert wird, wenn ein Konto gesperrt wurde? Vielleicht sagen Sie nun, dass es dem Anwender ja nichts mehr hilft, da er sich ja nicht mehr anmelden kann. Er kann sich aber nicht mehr "neu" anmelden aber bestehende Anmeldungen bleiben noch gültig solange die Verbindung besteht und das Kerberos-Ticket gültig ist. Es besteht also durchaus eine Chance, dass der Anwender die Meldung noch bekommt.

Wenn die Meldung aussagekräftig ist und dem Anwender möglichst verständlich mitteilt, wo die Sperrung erfolgt, dann kann es vielleicht schon selbst ermitteln, wo ein Konto noch aktiv ist. Meist passiert so ein Lockout nämlich derart, dass der Anwender an einer Stelle sein Kennwort ändert aber ein anderer Prozess immer noch das alte Kennwort nutzt.

Es bietet sich also an, die entsprechenden Events auf dem Domain Controller als Trigger nutzen, um den Anwender aber vielleicht auch den Helpdesk zu informieren. Jeder "Lockout" kann als Incident oder Angriff gewertet werden, zumindest wenn es regelmäßig oder öfters passiert und sollte damit gemeldet werden. So eine Meldung können verschiedene Tools liefern. Allein mit Bordmitteln können Sie aber z.B. per Taskmanager ein Skript starten, welches einfach den letzten Eventlogeintrag sucht:

Get-EventLog -LogName Security -InstanceId 4740 -Newest 1 | fl

Index              : 940870830
EntryType          : SuccessAudit
InstanceId         : 4740
Message            : A User account was locked out.

                     Subject:
                         Security ID:        S-1-5-18
                         Account Name:        DC01$
                         Account Domain:        MSXFAQ
                         Logon ID:        0x3e7

                     Account That Was Locked Out:
                         Security ID:        S-1-5-21-11949449-30417519-71842111-2583
                         Account Name:        support

                     Additional Information:
                         Caller Computer Name:
Category           : (13824)
CategoryNumber     : 13824
ReplacementStrings : {support, , S-1-5-21-11949449-30417519-71842111-2583, S-1-5-18...}
Source             : Microsoft-Windows-Security-Auditing
TimeGenerated      : 11.08.2017 14:31:46
TimeWritten        : 11.08.2017 14:31:46 UserName           :

Allerdings müsste man so den Trigger auf jedem Domain Controller einrichten. Alternativ können Sie auch einfach per Monitoring einfach die DCs entsprechend regelmäßig durchsuchen. Das kann speziell auf Core-Servern einfacher sein. Dazu sollte man sich dann aber merken, welche Events man schon abgelesen hat. Wenn man sich stumpf auf die letzten 5 Minuten beschränken will, dann geht das auch so:

Get-EventLog `
   -LogName Security `
   -InstanceId 4740 `
   -Newest 1 `
   -After (get-date).addminutes(-5)

Besser ist es aber den aktuellen Zeitpunkt zum Beginn der Abfrage zu ermitteln und zu "sichern" und den vorherigen Wert für die Abfrage als "After"-Wert zu nutzen. Leider habe ich noch nicht rausgefunden, wie ich genau beim Eventlog dort aufsetzen, wo ich vorher geendet habe. Es könnte also passieren, dass Alarme zweimal kommen oder übersehen werden.

Wer ein SIEM hat, wird natürlich solche Logs von allen Domain Controllern an einer zentralen Stelle sammeln und dort eine Weiterverarbeitung durchführen.

Hier ein paar Links:

Weitere Links