5 Anzeichen dass Ihr Windows Server unter RDP-Brute-Force steht

Die meisten Administratoren entdecken einen RDP-Brute-Force-Angriff auf dieselbe Weise: Sie lesen am Montagmorgen die Ransomware-Notiz. Bis dahin ist der Angreifer schon Stunden oder Tage drin, und die Aufräumarbeiten kosten mehr als jede vorbeugende Maßnahme.

Laut dem Mandiant M-Trends 2026 Bericht ist der Median zwischen initialem Zugriff und aktiver Angreifertätigkeit von 8 Stunden im Jahr 2022 auf rund 22 Sekunden im Jahr 2025 gefallen. Sobald Anmeldedaten fallen, übernimmt Automatisierung fast sofort. Erkennung muss früher passieren und heute überprüfbar sein.

Dieser Leitfaden geht 5 konkrete Anzeichen durch, dass Ihr Windows Server gerade angegriffen wird, mit PowerShell-Checks und Event-Viewer-Pfaden, die Sie in den nächsten 10 Minuten ausführen können. Wenn zwei oder mehr davon zu Ihrer Lage passen, behandeln Sie es als aktiven Vorfall. Hintergrund liefert unser Einstieg Was ist ein RDP-Brute-Force-Angriff.

Sehen Sie tausende fehlgeschlagene Anmeldeereignisse?

Das deutlichste Signal ist eine Flut von Event ID 4625 (fehlgeschlagene Anmeldung) im Sicherheitsprotokoll. Auf einem gesunden internen Windows Server liegt die Baseline meist unter 50 pro Tag, meistens vergessene Passwörter oder veraltete Dienstkonten. Ein exponierter Server unter aktivem Brute Force liegt bei tausenden pro Tag oder mehr.

Zur Einordnung: Ein öffentliches Microsoft-Sentinel-Honeypot-Projekt des Forschers Jeffrey Appel zeichnete 209.335 fehlgeschlagene Anmeldungen in 7 Tagen auf einer einzelnen exponierten Testmaschine auf, etwa 30.000 pro Tag. Wenn Ihre Werte irgendwo in dieser Größenordnung liegen, handelt es sich nicht um Tippfehler von Benutzern.

Zum Prüfen Event Viewer öffnen, zu Windows Logs → Security wechseln und nach Event ID 4625 filtern. Oder dies aus einer erhöhten PowerShell ausführen:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddDays(-7)} | Measure-Object

Über 1.000 in den letzten 7 Tagen auf einem internen Server ist verdächtig. Über 1.000 pro Tag ist ein klares Angriffsmuster. Microsoft dokumentiert das vollständige Schema in der Event-4625-Referenz, und unser Event-ID-4625-Leitfaden erklärt jedes Feld.

Ist die RDP-Anmeldung langsam und LSASS frisst CPU?

Jede Anmeldedatenprüfung läuft im LSASS-Prozess (Local Security Authority Subsystem Service) und kostet CPU-Zyklen. Eine normale RDP-Anmeldung ist in 5 bis 10 Sekunden fertig. Wenn tausende Brute-Force-Versuche parallel ankommen, wird LSASS gesättigt, und echte Benutzer merken es.

Das Symptom sieht so aus: RDP braucht plötzlich 30 bis 60 Sekunden bis zum Desktop, der Anmeldedialog ruckelt, und der Task-Manager zeigt LSASS dauerhaft über 5% CPU auf einem ansonsten ruhigen Server. Auf einem Server ohne echte Last sollte LSASS normalerweise unter 1% liegen.

Task-Manager öffnen, auf den Tab Details wechseln und nach CPU sortieren. Wenn lsass.exe konstant oben steht, ist das eine vom Netzwerk getriebene Last, und auf einem exponierten Server ist das fast immer Authentifizierungsverkehr, den Sie nicht autorisiert haben.

Werden zufällige Benutzerkonten gesperrt?

Wenn Ihre Domäne eine Account Lockout Policy aktiviert hat, wird der Brute-Force-Angreifer mit echten Benutzernamen früher oder später die Schwelle reißen. Der Nebeneffekt: legitime Benutzer werden zu den schlechtesten Zeitpunkten aus ihren Konten geworfen, oft in Wellen.

Helpdesk-Teams sehen das als plötzlichen Anstieg von Sperr-Tickets, der nicht zu einem Deployment, einer Passwortänderung oder zu Urlaubszeiten passt. Im Sicherheitsprotokoll entspricht dem Event ID 4740 (Benutzerkonto wurde gesperrt). In gesunden Netzen sollten 4740-Ereignisse selten sein. Mehr als 10 pro Tag, vor allem über mehrere Konten verteilt, ist ein starkes Indiz für aktives Credential Spraying.

Die Event-4740-Dokumentation von Microsoft zeigt, wo der Source-Workstation-Name geloggt wird, was oft auf den angreifenden Host zeigt. Die Account-Lockout-Policy-Referenz erklärt, wie man Schwellen einstellt, ohne die ganze Organisation auszusperren.

Ist ein Admin- oder lokales Konto erschienen das Sie nicht angelegt haben?

Das ist das Anzeichen, das Sie nicht finden möchten. Wenn ein neues lokales Benutzerkonto oder, schlimmer, ein neues Mitglied in der lokalen Administratoren-Gruppe auftaucht, das Sie nicht angelegt haben, war der Angriff bereits erfolgreich. Die Brute-Force-Phase ist vorbei, der Angreifer baut Persistenz auf.

Aus PowerShell die aktuellen lokalen Administratoren auflisten:

net localgroup administrators

Dann das Sicherheitsprotokoll auf Event ID 4720 (Benutzerkonto erstellt) und Event ID 4732 (Mitglied einer sicherheitsaktivierten lokalen Gruppe hinzugefügt) prüfen. Microsoft dokumentiert beide Events im Detail: Event 4720 und Event 4732. Alles, was nicht zu einem Change-Ticket oder einer bekannten Admin-Aktion passt, ist ein bestätigter Kompromittierungsindikator.

Wenn Sie das sehen, fangen Sie nicht an, Passwörter auf der laufenden Maschine zu ändern. Den Server zuerst vom Netz isolieren (aus dem VLAN nehmen oder an der Firewall blockieren), Sicherheits- und Systemprotokolle sichern und es als Vorfall behandeln. Die Anmeldedaten, die sie hereingelassen haben, waren wahrscheinlich von vornherein erratbar — deshalb taucht unser Beitrag Wie lange braucht man um ein schwaches RDP-Passwort zu knacken immer wieder auf. Der Stop-Ransomware-Hub der CISA bietet ab hier praktische Post-Compromise-Empfehlungen.

Starten RDP-Sitzungen zu seltsamen Zeiten?

Angreifer melden sich selten während der Geschäftszeiten an. Der Sophos 2025 Active Adversary Report fand heraus, dass 83% der Ransomware außerhalb der Geschäftszeiten des Opfers eingesetzt wurde, mit Wochenenden und frühen Morgenstunden als klare Favoriten. Wenn Ihren Server nur Bürobenutzer nutzen, Event ID 4624 aber sonntags um 03:00 Uhr erfolgreiche Anmeldungen zeigt, stimmt etwas nicht.

Die Event-4624-Referenz von Microsoft beschreibt das Logon-Type-Feld, der nützlichste Filter. Logon Type 10 ist RemoteInteractive (RDP). Off-hours-RDP-Anmeldungen der letzten Woche auflisten:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.TimeCreated.Hour -ge 22 -or $_.TimeCreated.Hour -le 6 }

Ein paar abendliche Wartungsanmeldungen eines bekannten Admins sind in Ordnung. Ein Muster nächtlicher Anmeldungen von Konten, die RDP gar nicht nutzen sollten, ist es nicht.

Was sollten Sie jetzt sofort tun?

Fünf Event-IDs decken den Großteil ab: 4625 (fehlgeschlagene Anmeldung), 4624 (erfolgreiche Anmeldung), 4740 (Kontosperre), 4720 (Konto angelegt), 4732 (Admin-Gruppe geändert). Wenn Ihr Monitoring diese fünf abdeckt, wird die meiste Brute-Force-Aktivität sichtbar, lange bevor sie erfolgreich ist.

Der folgende Aktionsplan ist nach Dringlichkeit gestaffelt. Von oben nach unten arbeiten; die 5-Minuten-Fixes nicht überspringen, um zu den langfristigen zu eilen.

Sofort (5 Minuten):

1. Account Lockout Policy in der Group Policy aktivieren, falls nicht schon an. Die offizielle Policy-Referenz liefert sichere Schwellenwerte.
2. Network Level Authentication (NLA) auf dem RDP-Host aktivieren. Das blockiert Pre-Auth-Brute-Force vollständig.
3. Das Standard-Administrator-Konto umbenennen. Das nimmt den meistgeratenen Benutzernamen aus der Gleichung.

Heute (1 Stunde):

4. RDP in der Windows Firewall auf bekannte IP-Bereiche beschränken (Büro, VPN-Gateway, Jump-Host).
5. Starke, eindeutige Passwörter auf jedem Admin-Konto. Unsere Auswertung Wie lange schwache Passwörter bei RDP-Brute-Force halten zeigt, warum Länge wichtiger ist als Komplexität.
6. MFA hinzufügen, wo die Umgebung das unterstützt (Duo, Microsoft Authenticator oder RD Gateway mit Conditional Access).

Diese Woche:

7. Ein automatisches IP-Blocking-Tool einsetzen, das Event 4625 beobachtet und Wiederholungstäter sperrt. Unser Leitfaden zum RDP-Brute-Force-Schutz 2026 geht die Kategorie durch. BruteFence ist eine Option in diesem Bereich und bietet eine 7-tägige kostenlose Testphase, die in etwa 5 Minuten installiert ist.
8. Eine geschichtete Verteidigung jenseits eines einzelnen Tools planen. Die vollständige Liste steht in unserer Windows-Server-Sicherheits-Checkliste 2026.

Wie können Sie schnell verifizieren wie schlimm es schon ist?

Wenn PowerShell gegen das Sicherheitsprotokoll an einem Montagmorgen zu viel ist, erledigt das kostenlose Werkzeug BruteFence Checker auf GitHub denselben Audit in etwa 30 Sekunden. Es liest das lokale Sicherheitsprotokoll, schaut 30 Tage zurück und gibt die Gesamtzahl fehlgeschlagener Versuche, die Top-10-Angreifer-IPs und eine tägliche Aufschlüsselung aus.

Einmal ausführen, die täglichen Zahlen ansehen und entscheiden. Zeigt der Checker unter 50 fehlgeschlagene Versuche pro Tag, sind Sie auf einer normalen Baseline. Zeigt er über 1.000 pro Tag, läuft eine aktive Kampagne gegen den Server, und der manuelle Sperr-Listen-Ansatz wird nicht mithalten. Die 7-tägige BruteFence-Testphase automatisiert das Blockieren und ist in etwa 5 Minuten installiert, aber die Checker-Ausgabe ist auch ohne BruteFence-Installation nützlich.

Die ehrliche Version: Die meisten Windows Server hinter Firewall und VPN sehen keines dieser Anzeichen. Die, die sie sehen, sind meist direkt auf Port 3389 exponiert, oft versehentlich, oft seit Jahren. Wenn auch nur eines der fünf Anzeichen oben heute zu Ihrer Lage passt, zählen die nächsten 24 Stunden mehr als die Roadmap des nächsten Quartals.