WS IT-Solutions

Eine wahre Bruteforce-Geschichte

Vorgeschichte

Die Netzwerksegmentierung

Meine Infrastruktur wurde im Laufe der Zeit immer komplexer. Anfangs standen alle Clients und Server direkt hinter dem Internetrouter. Später schaltete ich eine PFSense dazwischen, um die Datenströme zu filtern und somit die Sicherheit zu erhöhen:

Die PFSense-Firewall sollte kostengünstig und ausfallsicher sein. Also installierte ich sie in eine virtuelle Maschine auf meinem Hyper-V-FailoverCluster, der aus 2 Servern bestand. Sollte einer der Server ausfallen, dann würde die VM auf dem anderen weiterlaufen bzw. wieder gestartet werden.

Das Problem

Für die Administration und den Zugriff auf Daten von unterwegs setzte ich 2 VPN-Server ein. Dieser waren im Netz „LAN-Server“ angeschlossen – also hinter der Firewall. Im Normalbetrieb ist das kein Problem. Aber was wäre, wenn die PFSense nicht funktioniert? Richtig: Dann wäre auch kein VPN-Zugriff und damit kein TroubleShooting möglich!

Natürlich hätte ich auch die beiden VPN-Server in die „DMZ-aussen“ platzieren können. Aber die Verteilung der Verbindungen auf beide Server übernimmt ein HAProxy – ein Zusatzmodul in der PFSense, denn mein Router kann kein PortForwarding mit 1:n. Somit hätte ich nur einen VPN-Server einsetzen können. Und dann wäre das Problem mit der Verfügbarkeit nur verschoben.

So entschied ich mich, den beiden HyperV-Servern einen Zugang zum Netz „DMZ-aussen“ zu konfigurieren:

So konnte ich auf meinem Router direkt ein PortForwarding auf den RDP-Port 3389 einrichten (Hinweis: mach das blos nicht nach!). Damit es nach außen nicht so offensichtlich ist habe ich für extern einen anderen Port gewählt (Security by Obscurity == FacePalm):

So konnte ich von außen im Notfall direkt auf meine HyperV-Server zugreifen und die VM PFSense reparieren bzw. starten. Und wer scannt schon die higher Ports…

Mittlerweile verwende ich 2 PFSense-VMs, die als CARP-Cluster alle Funktionen für den Netzwerkschutz übernehmen. Je eine läuft auf einem HyperV-Server. Somit war kein Cluster mehr erforderlich. Nur was soll ich sagen … die beiden Portfreigaben für den RDP-Zugriff hatte ich einfach vergessen!

Der Angriff

Die Schwachstelle

Aber ich hatte ja eine Menge an Schutzvorkehrungen getroffen:

  • eine Netzwerksegmentierung mit der PFSense und ihrer sauber konfigurierten Firewall
  • ein Geoblocker, der Verbindungen nur aus bestimmten geographischen Regionen zulässt werkelt ebenfalls auf der PFSense
  • der Einsatz eines Snort IPS für die Analyse der erlaubten Verbindungen in der PFSense mit einem PowerShell-Monitoring/Alerting per Mail
  • eine Vielzahl an Richtlinien zur Absicherung meiner Systeme
  • sogar ein Microsoft ATA (Advanced Thread Analytics) war im Einsatz – es sollte Anomalien beim Anmelden und beim Ressourcenzugriff erkennen und melden
  • der Zugriff auf die beiden HyperV-Server war durch MFA abgesichert

Nur leider hatte die Konfiguration eine Schwachstelle: alle Netzwerkschutzkomponenten wurden von der PFSense ausgeführt. Und meine beiden HyperV-Hosts hatten einen Bypass!

Der Sicherheitsvorfall

Eines Tages – ich führte Routinearbeiten an meinen Servern durch – stieß ich dann in den Eventlogs meines DomainControllers auf Unregelmäßigkeiten:

Ich kenne meine Infrastruktur. Diese Anzahl an AuditFailures ist nicht normal. Also ging ich in die Analyse. Und wurde überrascht:

Und jeder Eintrag listete ein anderes Anmeldekonto. Ganz klar: hier versuchte jemand mit verschiedenen Benutzernamen (und Passwörtern) einen BruteForce-Angriff auf meine Infrastruktur!

Die Reaktion auf den Angriff

Wie reagiert man in einem solchen Fall richtig? Durchschlägt man mit der Axt alle Verkabelungen? Oder rennt man wild mit den Armen wedelnd schreiend auf dem Gang umher? Spass beiseite: überlegt euch bitte VOR einem Sicherheitsvorfall, wie man am besten reagieren kann!

In meinem Fall wusste ich sehr schnell, dass es sich um eine Bruteforce-Attacke handelte. Dabei werden Benutzernamen und Passwörter durchprobiert, bis es einen Treffer gibt. Mir konnte also nichts passieren, denn:

  • mit dem falschen Benutzernamen gibt es keinen Zutritt
  • mit dem richtigen Benutzernamen greift die Lockout-Policy nach x fehlerhaften Anmeldungen

Und dann kommen meine zusätzlichen Schutzmaßnahmen.

Ich hatte also Zeit und vor allem die Gelegenheit, mir den Angriff mal etwas näher anzusehen. Zunächst wollte ich herausfinden, welcher Service auf welchem Server für das bruteforcen mißbraucht wurde – der Patient Null. Nur leider findet man in dem Eventlog auf dem DomainController keinen Hinweis ab den „Auftraggeber“ der Anmeldeüberprüfung. Aber ich habe ein anderes Script, das mir jeden Tag über alle Server eine Zusammenfassung der letzten 24 Stunden liefert. Und darunter befinden sich auch die kumulierten Eventlogs je Server:

2 Treffer sind erkennbar: WS-HV1 und WS-HV2 – meine beiden HyperV-Hosts. Auf diesen fand ich die Eventlogs:

Und in den Details gab es die Antwort auf den Ursprung:

Die Frage „Wurden auch andere Quell-IP-Adressen verwendet?“ konnten ein paar Zeilen PowerShell-Code beantworten:

Und wer ist der Angreifer?

Sieht nicht sehr vielversprechend aus: außer einem russischen Namen gibt es keinen Hinweis. Manch einer würde sagen: die Russen waren es. Das würde ich nicht empfehlen. Wir fahren einen Nissan, sind aber keine Asiaten. Und eigentlich spielt es auch keine Rolle, da es sich an der Vorgehensweise bewertet nach einem gestreuten Angriff aussieht. Das wird auch deutlich, wenn man sich die verwendeten Benutzernamen anschaut:

Spannend finde ich die Tatsache, dass hier zwischen einigen krypischen Namen auch deutsche Namen verwendet wurden. Ebenso die typischen Servicenamen „datev“ und „sap“, aber auch „support“ und „admin“ kommen nicht zu kurz. Und die Gemeinde Parsdorf ist auch nicht so weit weg. Ganz offensichtlich versuchen die Angreifer durch zielorientierte Benutzernamen ihre Chancen zu erhöhen!

Ein Blick zurück

Zuletzt wage ich noch einen kleinen Blick auf den Angreifer mit nmap (ich sollte mal wieder aktualisieren):

Hier zeigt sich, dass die Maschine auf der anderen Seite mal so richtig viele offene Ports hat. Und alleine die Ports 135, 3389, 445 (Zeile 17,18,19) genügen mir für eine Vermutung: das ist ein Windows Rechner (Zeile 82), der direkt am Internet hängt. Und dieser wurde wahrscheinlich über SMB (445) oder RDP (3389) kompromittiert und soll mich nun als Bot weiter infizieren.

Die Gegenmaßnahme

Somit werde ich gar nicht direkt angegriffen und eine weitergehende Forensik oder gar eine Anzeige gegen unbekannt erscheint sinnfrei. Also beende ich den Angriff durch eine hübsche GPO:

Ein gpupdate später war Ruhe.

Möglichkeiten der Erkennung

Das Versagen von Microsoft ATA

Was mich neben der Tatsache, dass ich mit der Freigabe des Ports für RDP eine fehlerhafte Konfiguration vorgenommen hatte, besonders nerfte: Ich hätte den Angriff eigentlich durch Microsoft ATA mitbekommen sollen. Denn dieses Tool hat sich an alle meine DomainController angeschlossen und sollte die „Unregelmäßigkeit“ der Anmeldungen erkennen und melden. Doch ich bekam keine Warnung. Und im offiziellen ATA-Handbuch von Microsoft fand ich dann die Erklärung dazu:

Ich kanns nicht fassen! Eine Woche würde ATA einfach schweigen. Bei der Angriffswelle wurde im Schnitt eine Anmeldung pro Sekunde versucht. Das macht dann 604.800 Anmeldeversuche, bevor eine Warnung aufploppt!!!

Hinweis: die Software des Hackers war nicht besonders clever, denn man kann an den Antwortzeiten einer Anmeldung erkennen, ob der Benutzername existiert oder nicht. Somit könnte in einer ersten Welle ein gültiger Anmeldename gesucht werden und in einer zweiten würde man dann alle möglichen Passwörter versuchen – natürlich vorsortiert nach deren Häufigkeit für eine bestimmte Zielgruppe. Und nun überlegen wir mal, an welcher Stelle in dieser Liste die Passwörter der Benutzer stehen. Vielleicht vor Nummer 604.800? …

Meine PFSense konnte mir nicht helfen, denn diese hatte ich ja selber umgangen. Was kann also helfen?

Lockout Policy

Ganz klar: fehlgeschlagene Anmeldungen von gültigen Benutzerkonten müssen nach dem Überschreiten einer Mindestanzahl zu einer Kontosperrung führen. Dieses Lockout-Feature ist fester Bestandteil der Kennwortrichtlinie in einer AD-Infrastruktur. Man muss es nur sinnvoll konfigurieren. Traditionell gibt es die Variante mit der Gruppenrichtlinie:

Seit Windows Server 2008 gibt es aber auch die Password Setting Objects (PSO) oder auch Finegrained Password Policies:

In meinem Fall wird ein Standardkonto nach 10 Fehlversuchen für 5 Minuten gesperrt. Damit ist kein Bruteforce-Angriff möglich.

Eventlog-Analyse - das PowerShell Script SecEv-Monitor

Viel eleganter ist es aber, wenn man den Angriff aktiv gemeldet bekommt. Dazu habe ich mir ein PowerShell-Script geschrieben. Dieses überwacht die Security-Eventlogs aller meiner DomainController auf bestimmte fehlgeschlagene Audits und trägt die Informationen in CSV-Dateien zusammen. Aus diesen Informationen kann das Script Anomalien ableiten und dann per Mail Alarm schlagen.

Allein an den CSV-Dateien kann man schon Angriffe erkennen:

Besonders spannend ist aber die Darstellung und die Interpretation mit der PowerShell:

Die gelben Stapel repräsentieren die Anzahl der Events einer bestimmten Kategorie je Stunde. Die geschwungene Linie ist der Mittelwert der Events der gleichen Kategorie aus den letzten 4 Wochen – natürlich nur vom gleichen Wochentag (das musste einfach sein). Und die rote horizontale Linie ist mein persönlicher Schwellwert für den Alarm. Und dieser ging dann per Mail auch ein. Hier ein Beispiel vom 17.07.2019. Der Angriff startete 20:03 und die erste Mail kam 20:06:

Das Monitoring kann die Angriffsversuche nicht aktiv verhindern – aber der Mailempfänger (also der admin == ich) kann zeitnah reagieren!

Zusammenfassung

Angriffe gehören in unserer vernetzten Welt zum Alltag. Es geht zu bestimmt 99% nicht um euch oder eure Firma. Fast immer sind es automatisierte und gestreute Angriffe. Wählt also aus der breiten Palette von Schutzmaßnahmen großzügig aus. Testet und schult euch und eure Kollegen. Baut euch ein Monitoring auf. Und ganz wichtig: überlegt euch schon heute eine Antwort auf die Frage „Wie reagiere ich richtig?“

Stay tuned!

PS: Den Artikel gibt es hier auch als PDF.
PPS: Das Script „SecEv-Monitor“ hat noch ein paar kleine Kinderkrankheiten. Daher möchte ich es jetzt noch nicht veröffentlichen. Ich nehme aber gerne Voranmeldungen entgegen. 🙂