30
Fehlgeschlagene RDP Anmeldungen bei einem DC loggen
Moin,
ich würde gerne in einer AD umgebung die fehlgeschlagenen RDP anmeldeversuche an einem DC aus dem win eventlog ziehen.
Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
Versuch 1:
Scheinbar kann ich das nicht im RDP Log direkt sehen da vorher der Request via NLA abgewiesen wird (NLA ist auf dem zu überwachenden DC aktiv).
Versuch 2:
Okay, dann schaue ich mal nach ID 4625 + Typ 3 - hier gibts aber "alles mögliche" an fehlgeschlagenen Logins bei einem größeren Netzwerk geloggt, d.h. da müsste man sehr mühselig die false-positives aussortieren
Was ist denn der einfachste Weg sowas zu finden? Es gäbe wohl noch die ID 529, aber die wird hier scheinbar nicht geloggt, was müsste man im audit anmachen damit die 529 kommt
MFG
N-Dude
ich würde gerne in einer AD umgebung die fehlgeschlagenen RDP anmeldeversuche an einem DC aus dem win eventlog ziehen.
Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
Versuch 1:
Scheinbar kann ich das nicht im RDP Log direkt sehen da vorher der Request via NLA abgewiesen wird (NLA ist auf dem zu überwachenden DC aktiv).
Versuch 2:
Okay, dann schaue ich mal nach ID 4625 + Typ 3 - hier gibts aber "alles mögliche" an fehlgeschlagenen Logins bei einem größeren Netzwerk geloggt, d.h. da müsste man sehr mühselig die false-positives aussortieren
Was ist denn der einfachste Weg sowas zu finden? Es gäbe wohl noch die ID 529, aber die wird hier scheinbar nicht geloggt, was müsste man im audit anmachen damit die 529 kommt
MFG
N-Dude
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1684982301
Url: https://administrator.de/contentid/1684982301
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
30 Kommentare
Neuester Kommentar
Moin.
Was möchtest Du damit erreichen? Vielleicht gibt es dafür bessere Wege.
Was möchtest Du damit erreichen? Vielleicht gibt es dafür bessere Wege.
Sehr gute Frage
Es lässt sich vielleicht Beschreiben mit "soll die Zeit bis zu einem echten SIEM überbrücken"
Ok, was würde das SIEM hier für dich leisten, was kommt dabei rum?
Wie meinst du die Frage?
Das SIEM würde viel mehr sehen, man könnte z.B. die Events korrelieren und ein ein größeres Bild bekommen von dem "was eigentlich vorgeht"
Hier gehts aber nur erstmal darum einen sehr spezifischen use case abzubilden und eben fehlgeschlagene RDP Login Versuche zu protokollieren
Ich hoffte auf eine Antwort "wir wollen das loggen, um..."
Gut, was ich tun würde, hat mir Logging nur am Rande zu tun.
Ich würde auf den DCs Firewallregeln erlassen, die IPSec benutzen, um RDP nicht nur auf IPs, sondern auf Computer- bzw. Benutzeridentitäten zu beschränken. Somit könntest Du den RDP-Login auf Domänenadmins beschränken, anderen steht nicht einmal mehr der port offen. Natürlich bedeutet das nicht, das versuchte Anmeldungen auch auffallen - vermutlich ist es das, was du willst, darum fragte ich.
Gut, was ich tun würde, hat mir Logging nur am Rande zu tun.
Ich würde auf den DCs Firewallregeln erlassen, die IPSec benutzen, um RDP nicht nur auf IPs, sondern auf Computer- bzw. Benutzeridentitäten zu beschränken. Somit könntest Du den RDP-Login auf Domänenadmins beschränken, anderen steht nicht einmal mehr der port offen. Natürlich bedeutet das nicht, das versuchte Anmeldungen auch auffallen - vermutlich ist es das, was du willst, darum fragte ich.
Servus,
Grüße Uwe
ich würde gerne in einer AD umgebung die fehlgeschlagenen RDP anmeldeversuche an einem DC aus dem win eventlog ziehen.
Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
nimm doch das Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational Log, da steht dann auch von welcher Station aus der fehlerhafte Login stattgefunden hat.Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" -FilterXPath 'Event[System[EventID=140 and Task=4]]' Zitat von @DerWoWusste:
Ich hoffte auf eine Antwort "wir wollen das loggen, um..."
Gut, was ich tun würde, hat mir Logging nur am Rande zu tun.
Ich würde auf den DCs Firewallregeln erlassen, die IPSec benutzen, um RDP nicht nur auf IPs, sondern auf Computer- bzw. Benutzeridentitäten zu beschränken. Somit könntest Du den RDP-Login auf Domänenadmins beschränken, anderen steht nicht einmal mehr der port offen. Natürlich bedeutet das nicht, das versuchte Anmeldungen auch auffallen - vermutlich ist es das, was du willst, darum fragte ich.
Ich hoffte auf eine Antwort "wir wollen das loggen, um..."
Gut, was ich tun würde, hat mir Logging nur am Rande zu tun.
Ich würde auf den DCs Firewallregeln erlassen, die IPSec benutzen, um RDP nicht nur auf IPs, sondern auf Computer- bzw. Benutzeridentitäten zu beschränken. Somit könntest Du den RDP-Login auf Domänenadmins beschränken, anderen steht nicht einmal mehr der port offen. Natürlich bedeutet das nicht, das versuchte Anmeldungen auch auffallen - vermutlich ist es das, was du willst, darum fragte ich.
Verstehe jetzt die Frage
Also das Setup sieht etwas anders auf, aber ja es gibt schon eine runde "passive sicherheit" durch firewallrules - aber danke für den Input das auch auf Host-level zumachen.Das Logging soll zusätzlich dazu kommen
Zitat von @colinardo:
Servus,
Grüße Uwe
Servus,
ich würde gerne in einer AD umgebung die fehlgeschlagenen RDP anmeldeversuche an einem DC aus dem win eventlog ziehen.
Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
nimm doch das Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational Log, da steht dann auch von welcher Station aus der fehlerhafte Login stattgefunden hat.Es geht tatsächlich nur um RDP Anmeldeversuche, sonst nichts.
Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" -FilterXPath 'Event[System[EventID=140 and Task=4]]' Ich kann leider keine EventIDs 140 generieren (durch falsches passwort tippen), muss man einen Audit Policy erstmal einschalten um das zu bekommen?
Oder hängt das wieder mit der NLA Thema zusammen?
Musst du auch nicht generieren, die System-Events werden automatisch in den oben genannten Application-Log erzeugt, auch bei aktiver NLA!
Hier der Auszug aus einem Windows Server 2022 und dem genannten Log bei aktiver NLA und einem testweise forciertem Login mit fehlerhaften Credentials
muss man einen Audit Policy erstmal einschalten um das zu bekommen?
Nein.Hier der Auszug aus einem Windows Server 2022 und dem genannten Log bei aktiver NLA und einem testweise forciertem Login mit fehlerhaften Credentials
Oder hängt das wieder mit der NLA Thema zusammen?
Vermutlich. Ändere mal die NLA auf deaktiviert temporär. Danach muss der Remotedesktopdienst neu gestartet werden, damit das wirkt (bestehende Verbindungen brechen ab).
Hi,
als Zusatzinfo: habe hier einen Server 2012 R2 als DC
Und wenn ich absichtlich falsche creds in dem RDP Client eingebe wird es nicht geloggt (damit meinte ich "wird nicht generiert" weiter oben)
als Zusatzinfo: habe hier einen Server 2012 R2 als DC
Und wenn ich absichtlich falsche creds in dem RDP Client eingebe wird es nicht geloggt (damit meinte ich "wird nicht generiert" weiter oben)
Macht keinen Unterschied, auch hier das selbe Spiel auf einem Server 2012R2 mit aktiver NLA und einem fehlerhaften Login:
Also entweder das Log ist bei dir deaktiviert (mal Kontextmenü auf Betriebsbereit öffnen und schauen ob es dort einen Eintrag "aktivieren" gibt), oder du schaust an der falschen Stelle, oder beschreibst dein RDP-Login Szenario missverständlich. Zur Info: Das ist nicht das Security Eventlog!
Wie findet der Login statt? Auf dem DC selbst oder auf einem anderen TS, über Remote-Desktop Gateway, usw. ? Das alles schreibst du hier nicht, ist aber essentiell.
Also entweder das Log ist bei dir deaktiviert (mal Kontextmenü auf Betriebsbereit öffnen und schauen ob es dort einen Eintrag "aktivieren" gibt), oder du schaust an der falschen Stelle, oder beschreibst dein RDP-Login Szenario missverständlich. Zur Info: Das ist nicht das Security Eventlog!
Wie findet der Login statt? Auf dem DC selbst oder auf einem anderen TS, über Remote-Desktop Gateway, usw. ? Das alles schreibst du hier nicht, ist aber essentiell.
Hi,
mache morgen weiter, die Infos reiche ich nach
mache morgen weiter, die Infos reiche ich nach
Moin Uwe,
also wenn ich den Log ohne Event- und TypID abfrage:
kommen etliche Ereignisse:
d.h. das Protokoll ist aktiviert und logg aktuelle Ereignisse
Nach ID 140 gefiltert kommt jedoch nichts.
Nun nehme ich den WIndows RDP Client auf meinem Client PC zur hand, will mich zu diesem DC verbinden und gebe falsche Creds ein, und bekomme im Client ein "Der Anmeldeversuch ist fehgeschlagen" (also das ganz normale verhalten bei einem falschen PW).
Jetzt sollte ja theoretisch was mit 140 gelogt werden? Leider nein
Es ist aber eine ID 131 zu finden mit "Vom Server wurde eine neue Verbindung "TCP" mit Client "<IP>:54009" akzeptiert." ?!
also wenn ich den Log ohne Event- und TypID abfrage:
Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" Nach ID 140 gefiltert kommt jedoch nichts.
Nun nehme ich den WIndows RDP Client auf meinem Client PC zur hand, will mich zu diesem DC verbinden und gebe falsche Creds ein, und bekomme im Client ein "Der Anmeldeversuch ist fehgeschlagen" (also das ganz normale verhalten bei einem falschen PW).
Jetzt sollte ja theoretisch was mit 140 gelogt werden? Leider nein
Es ist aber eine ID 131 zu finden mit "Vom Server wurde eine neue Verbindung "TCP" mit Client "<IP>:54009" akzeptiert." ?!
Also der Typ hier meint man solle auch eher auf 4625 im Securitylog schauen:
https://ponderthebits.com/2018/02/windows-rdp-related-event-logs-identif ...
Was mich zurück zum NLA bringt: Wann würde denn der NLA eigentlich blocken? Weil selbst mit einem linux rdesktop (ohne vorher geladenes krbtgt oder serviceticket) ist es ein successfull mit ID 131?
Was aber scheinbar "By Design" ist, lt. dem link oben:
"1) When NLA is enabled, a failed RDP logon (due to wrong username, password, etc.) will result in a 4625 Type 3 failure. When NLA is not enabled, you *should* see a 4625 Type 10 failure."
Hinweis: Es ist hier eine legacy produktionsumgebung, keine laborumgebung, kann sein das vor 10 Jahren jemand irgendwas irgendwo geschraubt hat und ich sehe es nicht - die möglichkeit bitte im Hinterkopf behalten
https://ponderthebits.com/2018/02/windows-rdp-related-event-logs-identif ...
Was mich zurück zum NLA bringt: Wann würde denn der NLA eigentlich blocken? Weil selbst mit einem linux rdesktop (ohne vorher geladenes krbtgt oder serviceticket) ist es ein successfull mit ID 131?
Was aber scheinbar "By Design" ist, lt. dem link oben:
"1) When NLA is enabled, a failed RDP logon (due to wrong username, password, etc.) will result in a 4625 Type 3 failure. When NLA is not enabled, you *should* see a 4625 Type 10 failure."
Hinweis: Es ist hier eine legacy produktionsumgebung, keine laborumgebung, kann sein das vor 10 Jahren jemand irgendwas irgendwo geschraubt hat und ich sehe es nicht - die möglichkeit bitte im Hinterkopf behalten
Es liegt wohl daran das Event 140 nur geloggt wird wenn auch der Benutzername falsch ist.
https://purerds.org/remote-desktop-security/auditing-remote-desktop-serv ...
In dem Fall musst du eben das Event 131 (bedeutet nicht unbedingt Success!) im RDP Log zusätzlich zeitlich mit dem Security-Eventlog (4625) und der geloggten IP abgleichen, findet sich dort ein Denied Eintrag mit der gleichen IP zur selben Zeit hast du deinen Login-Error.
https://purerds.org/remote-desktop-security/auditing-remote-desktop-serv ...
In dem Fall musst du eben das Event 131 (bedeutet nicht unbedingt Success!) im RDP Log zusätzlich zeitlich mit dem Security-Eventlog (4625) und der geloggten IP abgleichen, findet sich dort ein Denied Eintrag mit der gleichen IP zur selben Zeit hast du deinen Login-Error.
Zitat von @colinardo:
Es liegt wohl daran das Event 140 nur geloggt wird wenn auch der Benutzername falsch ist.
https://purerds.org/remote-desktop-security/auditing-remote-desktop-serv ...
In dem Fall musst du eben das Event 131 (bedeutet nicht unbedingt Success!) im RDP Log zusätzlich zeitlich mit dem Security-Eventlog (4625) und der geloggten IP abgleichen, findet sich dort ein Denied Eintrag mit der gleichen IP zur selben Zeit hast du deinen Login-Error.
Es liegt wohl daran das Event 140 nur geloggt wird wenn auch der Benutzername falsch ist.
https://purerds.org/remote-desktop-security/auditing-remote-desktop-serv ...
In dem Fall musst du eben das Event 131 (bedeutet nicht unbedingt Success!) im RDP Log zusätzlich zeitlich mit dem Security-Eventlog (4625) und der geloggten IP abgleichen, findet sich dort ein Denied Eintrag mit der gleichen IP zur selben Zeit hast du deinen Login-Error.
Habe das hier nochmal auf einem Server 2012R2 überprüft, entgegen der Aussage aus dem oben verlinkten Artikel wird hier egal ob der Benutzername im AD existiert oder nicht bei falschen Credentials immer das Event 140 geloggt! Konnte das auf einem weiteren DC einer anderen Domäne ebenfalls verifizieren, dort ist das Verhalten gleich. Vermutlich wurde das Verhalten mit einem Update mittlerweile gepatcht.
Was da auf deinem System verändert wurde oder ob da Patches fehlen kann ich zur Zeit leider nicht sagen.
Die Patches sind aktuell, kann nur die Config sein - ich wühle noch etwas rum, und lasse den Thread hier mal offen, wem was einfällt, gerne was dazuschreiben
Noch ein Hinweis: Interessant das der verlinkte Typ ein Szenario beschreibt "140 nur bei unbekannten usernames", du ein anderes "140 immer, egal ob bekannter name oder nicht" und ich wiederrum was anderes sehe mit "nie 140, sondern immer 131+success"
Zitat von @NetzwerkDude:
Noch ein Hinweis: Interessant das der verlinkte Typ ein Szenario beschreibt "140 nur bei unbekannten usernames", du ein anderes "140 immer, egal ob bekannter name oder nicht" und ich wiederrum was anderes sehe mit "nie 140, sondern immer 131+success"
Noch ein Hinweis: Interessant das der verlinkte Typ ein Szenario beschreibt "140 nur bei unbekannten usernames", du ein anderes "140 immer, egal ob bekannter name oder nicht" und ich wiederrum was anderes sehe mit "nie 140, sondern immer 131+success"
Im Artikel steht das, konnte das hier aber hier nicht bestätigen das ID 140 nur geloggt wird wenn ein falscher Benutzername verwendet wird.
Ich könnte dir zwar ein Skript schreiben was die 131 Einträge vom RDP Log und 4625 Security-Eventlog korreliert, aber das wird einige Zeit laufen denn die Abfragen in den Eventlogs sind nicht gerade schnell.
Das die Einträge bei dir nicht erscheinen ist kurios, habe aber momentan keinen Ansatz warum das bei dir so ist. Irgendeine GPO bezüglich RDP/RemoteFX-Modul, mal schauen ...
Hi Uwe,
das Skript würde ich im Zweifel selber hacken, dennoch vielen dank für das Angebot.
Aber vielleicht eine Frage zu Design Pattern vom Skript:
Wie würdest du die die Logs korrelieren?
Ich dachte zuerst die RDP Log ID 131 (und 140, falls die jemals kommen sollten ) tracken, und dannach mit der gewonnenen IP + Zeit in dem Security Log nach 4625 von der gleichen IP suchen?
Bin mir gerade nur nich sicher wie groß das Zeitfenster sein sollte.
Wenn ich das live teste bekomme ich:
- RDP 131 um 11:47:01
- Security 4625 um 11:47:18
also 17 sekunden apart - nun könnte man das fenster mit etwas reserse z.B. 30 sekunden groß machen - die Frage ist wie "robust" das dann ist bei einem real-world pw-try ist.
Mich würde aber dein Ansatz für das korrelieren interessieren
das Skript würde ich im Zweifel selber hacken, dennoch vielen dank für das Angebot.
Aber vielleicht eine Frage zu Design Pattern vom Skript:
Wie würdest du die die Logs korrelieren?
Ich dachte zuerst die RDP Log ID 131 (und 140, falls die jemals kommen sollten
) tracken, und dannach mit der gewonnenen IP + Zeit in dem Security Log nach 4625 von der gleichen IP suchen?Bin mir gerade nur nich sicher wie groß das Zeitfenster sein sollte.
Wenn ich das live teste bekomme ich:
- RDP 131 um 11:47:01
- Security 4625 um 11:47:18
also 17 sekunden apart - nun könnte man das fenster mit etwas reserse z.B. 30 sekunden groß machen - die Frage ist wie "robust" das dann ist bei einem real-world pw-try ist.
Mich würde aber dein Ansatz für das korrelieren interessieren
Wg. der nicht erscheinenden ID 140:
habe gerade mühselig per hand via gpreport alle angewandten computerpolicies vom DC angeschaut, konnte nichts ungewöhnliches finden ¯\_(ツ)_/¯
habe gerade mühselig per hand via gpreport alle angewandten computerpolicies vom DC angeschaut, konnte nichts ungewöhnliches finden ¯\_(ツ)_/¯
Ja hätte ich ähnlich gemacht, ein Zeitfenster definieren und auf diese Events filtern, da ja keine wirklich identischen Merkmale in beiden Logs vorhanden sind. Selbst die ProcessID und ThreadID aus den XML-Daten kann man hier ebenfalls nicht heranziehen da die Daten zwei getrennte Prozesse ins Log schreiben.
Aber mal ehrlich, ich würde Port 3389 auf dem DC schon auf Transport-Ebene mit IPSec absichern (lässt sich in der erweiterten Firewall schon so angeben (Verbindungssicherheitsregeln)) so kommen die Bösewichte im internen Netz erst gar nicht an den Port.
Ich hoffe ja auch ebenfalls nicht das du den Port auf einen DC direkt aus dem Internet verfügbar machst
.
die Frage ist wie "robust" das dann ist bei einem real-world pw-try ist.
Die Frage ist ob es was ausmacht, ein Angreifer wird es wohl selten nur einmal probieren.Aber mal ehrlich, ich würde Port 3389 auf dem DC schon auf Transport-Ebene mit IPSec absichern (lässt sich in der erweiterten Firewall schon so angeben (Verbindungssicherheitsregeln)) so kommen die Bösewichte im internen Netz erst gar nicht an den Port.
Ich hoffe ja auch ebenfalls nicht das du den Port auf einen DC direkt aus dem Internet verfügbar machst
.
Der Port 3389 ist wie irgendwo oben geschrieben bereits zu, das logging soll on-top für eben dieses spezielle Szenario.
Wie dem auch sei, Danke dir und DerWoWusste, ich schreibe die Tage dannmal das Tool.
Thread Closed
(Es sei denn jemand kommt mit einer trivialsolution noch an )
Wie dem auch sei, Danke dir und DerWoWusste, ich schreibe die Tage dannmal das Tool.
Thread Closed
(Es sei denn jemand kommt mit einer trivialsolution noch an
)Zitat von @colinardo:
Ich hoffe ja auch ebenfalls nicht das du den Port auf einen DC direkt aus dem Internet verfügbar machst.
Ich hoffe ja auch ebenfalls nicht das du den Port auf einen DC direkt aus dem Internet verfügbar machst
.Och, wenn das erkennungsskript steht, muss man es ja irgendwie real-world testen
Der Port 3389 ist wie irgendwo oben geschrieben bereits zu, das logging soll on-top für eben dieses spezielle Szenario.
Der Port ist zu... ah ja. Und du meinst, die Anmeldeversuche kommen an?Zitat von @DerWoWusste:
Der Port 3389 ist wie irgendwo oben geschrieben bereits zu, das logging soll on-top für eben dieses spezielle Szenario.
Der Port ist zu... ah ja. Und du meinst, die Anmeldeversuche kommen an?Sieh es doch mal so: Konfigurieren ist das eine, aber nur das Log kann einem sicher sagen das es nicht ein übersehendes Edge-Szanario gibt ;)
Also wenn du der Meinung bist das das der Normalzustand ist das ein DC mit nacktem A. im Internet steht will ich den Rest des Netzes nicht sehen ... 
.
Am besten gleich noch als Terminalserver missbrauchen und die Fibu und Datenbank drauf laufen lassen so das der Angreifer gleich alles an einer Stelle an die Hand bekommt.
.Am besten gleich noch als Terminalserver missbrauchen und die Fibu und Datenbank drauf laufen lassen so das der Angreifer gleich alles an einer Stelle an die Hand bekommt
.
Da kommen keine Anmeldeversuche an bei geschlossenem Port. Wenn da was geloggt wird, ist der Port nicht geschlossen.
Herrgott, im Thread gings um ein Thema - das wurde besprochen und teilweise gelöst.
Der Rest ist irrelevant
Der Rest ist irrelevant
