netzwerkdude
Goto Top

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

Content-Key: 1684982301

Url: https://administrator.de/contentid/1684982301

Printed on: February 6, 2023 at 17:02 o'clock

Member: DerWoWusste
DerWoWusste Jan 03, 2022 at 13:06:58 (UTC)
Goto Top
Moin.

Was möchtest Du damit erreichen? Vielleicht gibt es dafür bessere Wege.
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 updated at 13:16:17 (UTC)
Goto Top
Zitat von @DerWoWusste:

Moin.

Was möchtest Du damit erreichen? Vielleicht gibt es dafür bessere Wege.

Sehr gute Frage face-smile
Es lässt sich vielleicht Beschreiben mit "soll die Zeit bis zu einem echten SIEM überbrücken"
Member: DerWoWusste
DerWoWusste Jan 03, 2022 at 13:21:24 (UTC)
Goto Top
Ok, was würde das SIEM hier für dich leisten, was kommt dabei rum?
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 at 13:27:29 (UTC)
Goto Top
Zitat von @DerWoWusste:

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
Member: DerWoWusste
DerWoWusste Jan 03, 2022 at 13:38:06 (UTC)
Goto Top
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.
Member: colinardo
colinardo Jan 03, 2022 updated at 13:57:47 (UTC)
Goto Top
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.
Grüße Uwe
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 at 14:01:47 (UTC)
Goto Top
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.

Verstehe jetzt die Frage face-smile 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
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 updated at 14:03:14 (UTC)
Goto Top
Zitat von @colinardo:

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.
Grüße Uwe

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?
Member: colinardo
colinardo Jan 03, 2022 updated at 14:11:35 (UTC)
Goto Top
Zitat von @NetzwerkDude:
Ich kann leider keine EventIDs 140 generieren
Musst du auch nicht generieren, die System-Events werden automatisch in den oben genannten Application-Log erzeugt, auch bei aktiver NLA!
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

screenshot
Member: DerWoWusste
DerWoWusste Jan 03, 2022 at 14:06:39 (UTC)
Goto Top
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).
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 at 14:37:27 (UTC)
Goto Top
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)
Member: colinardo
colinardo Jan 03, 2022 updated at 15:05:24 (UTC)
Goto Top
Zitat von @NetzwerkDude:
als Zusatzinfo: habe hier einen Server 2012 R2 als DC
Macht keinen Unterschied, auch hier das selbe Spiel auf einem Server 2012R2 mit aktiver NLA und einem fehlerhaften Login:

screenshot

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.
Member: NetzwerkDude
NetzwerkDude Jan 03, 2022 at 15:44:59 (UTC)
Goto Top
Hi,

mache morgen weiter, die Infos reiche ich nach
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 06:41:18 (UTC)
Goto Top
Moin Uwe,

also wenn ich den Log ohne Event- und TypID abfrage:
kommen etliche Ereignisse:
bildschirmfoto von 2022-01-04 07-28-34
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 ace-sad"
Es ist aber eine ID 131 zu finden mit "Vom Server wurde eine neue Verbindung "TCP" mit Client "<IP>:54009" akzeptiert." ?!
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 updated at 07:11:39 (UTC)
Goto Top
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 face-smile
Member: colinardo
colinardo Jan 04, 2022 updated at 07:25:00 (UTC)
Goto Top
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.
Member: colinardo
colinardo Jan 04, 2022 updated at 09:28:25 (UTC)
Goto Top
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.

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.
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 10:13:57 (UTC)
Goto Top
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
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 10:24:24 (UTC)
Goto Top
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"
Member: colinardo
colinardo Jan 04, 2022 updated at 10:38:43 (UTC)
Goto Top
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"

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 ...
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 10:53:55 (UTC)
Goto Top
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 face-smile ) 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 face-smile
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 10:58:25 (UTC)
Goto Top
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 ¯\_(ツ)_/¯
Member: colinardo
colinardo Jan 04, 2022 updated at 11:05:33 (UTC)
Goto Top
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.
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 face-wink.
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 11:05:37 (UTC)
Goto Top
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 face-smile )
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 11:07:29 (UTC)
Goto Top
Zitat von @colinardo:
Ich hoffe ja auch ebenfalls nicht das du den Port auf einen DC direkt aus dem Internet verfügbar machst face-wink.

Och, wenn das erkennungsskript steht, muss man es ja irgendwie real-world testen face-smile
Member: DerWoWusste
DerWoWusste Jan 04, 2022 at 11:08:13 (UTC)
Goto Top
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?
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 11:10:47 (UTC)
Goto Top
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 ;)
Member: colinardo
colinardo Jan 04, 2022 updated at 11:18:26 (UTC)
Goto Top
Zitat von @NetzwerkDude:
muss man es ja irgendwie real-world testen face-smile
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 ... face-big-smile.
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 face-smile.
Member: DerWoWusste
DerWoWusste Jan 04, 2022 at 11:32:20 (UTC)
Goto Top
Da kommen keine Anmeldeversuche an bei geschlossenem Port. Wenn da was geloggt wird, ist der Port nicht geschlossen.
Member: NetzwerkDude
NetzwerkDude Jan 04, 2022 at 11:41:03 (UTC)
Goto Top
Herrgott, im Thread gings um ein Thema - das wurde besprochen und teilweise gelöst.

Der Rest ist irrelevant