Grüße! Nachdem wir bei PHDays 9 genügend Interesse an den Ereignissen bei The Standoff in den Reihen der Verteidiger gesehen hatten, beschlossen wir, darüber zu sprechen, wie die Vorbereitung und die „Pattsituation“ mit den Augen des Jet CSIRT als Teil des Jet Security Teams stattfanden.
Guo Standoff habe ich erstellt
So etwas berichteten die Kollegen, dass wir wieder an The Standoff teilnahmen, und wir waren uns natürlich einig.
Es ist sofort erwähnenswert, dass sich für die Verteidiger in diesem Jahr das Format des Wettbewerbs etwas geändert hat. Alle Teams erhielten sehr ähnliche Büroinfrastrukturen, und dies ermöglichte es den Organisatoren, bei bestimmten Papageien eine Bewertung der Verteidiger einzugeben. Für das Jet Security Team war dies die erste "Konfrontation", bei der das Büro verteidigt wurde und nicht die industrielle Infrastruktur.
Wir haben Zugang zur Infrastruktur, um uns auf den Cyberkampf Ende April vorzubereiten. Nach der Prüfung der Infrastruktur wurde eine ganze Reihe von Mängeln zusammengestellt, hier nur einige davon. Absolut in der gesamten Infrastruktur gab es keine tatsächlichen Patches. Die Passwörter aller Benutzer können über Ntds.dit im Klartext abgerufen werden. Darüber hinaus hatten einige Benutzer Passwörter aus der TOP-500-Liste oder Passwörter mit einem leicht umkehrbaren Hash. Die Systemhärtung war nahezu nichts oder gar nichts. Einige Hosts in der DMZ hatten eine Schnittstelle im Server-Subnetz.
Basierend auf den Ergebnissen des Audits haben wir bestimmte Sicherheitsmaßnahmen entwickelt, und die Organisatoren haben uns nach vorheriger Genehmigung gestattet, die erforderlichen Richtlinien anzuwenden und alle Sicherheitstools und Tools mitzubringen, die in einer virtuellen Umgebung bereitgestellt werden können. Aufgrund der engen Fristen fielen zu Beginn einige Ideen zu Schutzmaßnahmen aus. Die Haupteinstellungen und die Profilerstellung des SPI wurden in den Maiferien durchgeführt (Hallo an alle, die Bilder von den Picknicks geworfen haben, wir lieben Sie auch), und einige der Schutzausrüstungen mussten direkt vor dem Start direkt vor Ort abgestimmt werden. Außerdem war es einigen Diensten verboten, Patches zu erstellen und stark neu zu konfigurieren. Eines davon war beispielsweise Oracle Weblogic mit CVE-2019-2725, das PoC Anfang Mai 2019 veröffentlicht wurde.
Nun, und eine Liste von dem, was wir mitgebracht haben:
- Firewall (vom Veranstalter bereitgestellt wurde ersetzt);
- Antivirus-Lösung;
- WAF;
- EDR
- Ein paar Täuschungslösungen;
- Ein Paar Schwachstellenscanner;
- ELK-Stack für zusätzliche Netflow-Analyse;
- SIEM.
Wir sollten auch darüber sprechen, was zu SIEM gehen würde. Als Ereignisquellen standen uns die Windows-Protokolle, Sysmon-, Auditd-Protokolle und, wie Sie sich vorstellen können, Ereignisse aus dem SZI selbst zur Verfügung. Wenn es bei den ersten beiden keine besonderen Probleme gab und wir uns schnell auf Änderungen in der Sysmon-Richtlinie und -Konfiguration einigten, mussten wir uns mit den Organisatoren für die Auditd-Konfiguration auseinandersetzen.
Parallel dazu haben wir die Hauptangriffsvektoren identifiziert und darauf basierend relevante Szenarien und Korrelationsregeln ausgewählt und angepasst - insgesamt etwa 160 Korrelationsregeln. Außerdem wurde eine Reihe bunter Dashboards für kritische Knoten, SZI und das, was besondere Aufmerksamkeit in der Gaming-Infrastruktur erfordert, zusammengestellt.
Die Pattsituation
Für The Standoff haben wir uns entschlossen, das Konzept der Trennung von Vorfällen in externe und interne Vorfälle beizubehalten, da genau bekannt war, dass wir außerhalb aktiv versuchen würden, das Web zu scannen und zu betreiben. Vorfälle im Zusammenhang mit dem Scannen und Versuchen, WAF zu umgehen, wurden separat überwacht. Mit einer niedrigeren Priorität konnten wir uns auf interne Vorfälle konzentrieren. Dashboards für SPI wurden zwischen Verteidigern in Verantwortungsbereichen verteilt, und jedem Tool wurden mindestens 2 Personen zugewiesen - für die Möglichkeit der Rotation und Ruhe.
Alles passierte wie erwartet. Die Konfrontation begann gegen 10 Uhr morgens, und sobald der Start erfolgte, gab das SIEM-System eine Reihe von Vorfällen im Zusammenhang mit einem externen Scan und Versuchen von Angreifern aus, das Web auszunutzen. In einigen Fällen hat sogar die Gruppe nicht gespeichert. Gleichzeitig begannen die Prüfer der Organisatoren zu arbeiten und überprüften den Status verschiedener Dienste im Büro, was uns dazu zwang, die Profilerstellung in gewissem Maße neu durchzuführen, um die damit verbundenen Fehlalarme auszuschließen.
In den ersten Stunden des Spiels gelang es dem Hack.ERS-Team, die Standardanmeldeinformationen des Administrators (admin / admin) auf dem CMS einer der Ressourcen zu finden und eine potenzielle LFI-Sicherheitsanfälligkeit zu erkennen. Diese Versuche blieben nicht unbemerkt, unsere Verteidiger führten eine operative Reaktion durch und die Angreifer konnten am Ende nicht weiter vorrücken.
Bis zum Ende des ersten Spieltages änderten sich die Methoden nicht, WAF schlug immer noch alle Versuche ab, etwas Interessantes auf die Websites des Unternehmens hochzuladen, und dieselben „externen Adressen“ versuchten ohne Unterlass, unsere Ressourcen zu scannen.
Insgesamt wurden für das gesamte Ereignis 3000 Vorfälle im Zusammenhang mit Scanversuchen aufgezeichnet, ohne die Gruppierung von Ereignissen in Vorfällen zu berücksichtigen.
Und ungefähr 2500 Vorfälle mit Versuchen, WAF zu umgehen, auch ohne die Gruppierung von Ereignissen in Vorfällen zu berücksichtigen.
Gegen Abend nahm die Intensität aller Aktivitäten ab - dafür gab es mehrere Gründe. Ein Teil der Verteidiger und Angreifer konnte dem Soundcheck und der Probe des Konzerts, das am nächsten Tag stattfinden sollte, nicht widerstehen. Einige angreifende Teams beschlossen, eine Pause einzulegen und die Angriffe gegen Ende des Vormittags fortzusetzen, in der Hoffnung, dass die Verteidiger und die Überwachung weniger Überwachungsressourcen und etwas Müdigkeit haben würden.
Am Morgen des zweiten Tages änderten die Angreifer ihre Taktik. Informationen über einen Teil seiner Mitarbeiter wurden auf einer der Websites des Unternehmens veröffentlicht. Hacker nutzten diese Informationen und sammelten aktiv Benutzerkonten über Exchange (Statistik der Versuche im Screenshot).
Wenig später wurden unsichere Versuche unternommen, ein Passwort auf dem VPN-Gateway auszuwählen. Konten, die sich nicht in unserer Infrastruktur befanden, nahmen am Brute teil. Mit hoher Wahrscheinlichkeit versuchten die Angreifer, Konten aus der bereits gehackten Infrastruktur zu verwenden, in der Hoffnung, dass die Organisatoren sie überall gleich ließen. Infolgedessen hat uns die gesamte Situation mit brutaler Gewalt dazu veranlasst, eine Gruppe von Dashboards zu Trends in Bezug auf die Benutzerauthentifizierung zu erstellen. Außerdem haben wir die Überwachung von Vorfällen im Zusammenhang mit erfolgreicher Brute Force verschärft, aber glücklicherweise wurden solche Fälle nicht festgestellt.
Ungefähr eine Stunde vor dem Ende des Spiels erlebten die Trends einzelne erfolgreiche Versuche, mehrere Benutzer zu authentifizieren, einschließlich derer in Exchange. Die Betriebsanalyse ergab, dass die Quellen direkt Benutzercomputer waren. Die meisten Ereignisse zeigten, dass sich die Organisatoren über die VMware-Konsole angemeldet hatten Vcenter.
Gleichzeitig haben wir einen internen Scan von einem Knoten aufgezeichnet, der erfolgreich eine Verbindung über VPN hergestellt hat. Nach einer operativen Analyse der Ereignisse im Zusammenhang mit dem Vorfall wurde klar, dass die Angreifer die Anmeldeinformationen mehrerer Benutzer gefährden konnten. Aufgrund des Fehlens erfolgloser Authentifizierungsversuche ist es wahrscheinlich, dass die Benutzerdaten „durchgesickert“ sind.
Informationen wurden an die Verteidiger weitergegeben. Während der gesamten Reaktionszeit auf den PCs gefährdeter Benutzer wurde die Endpunktlösung in einen vorbeugenden Schutzmodus versetzt, um die Fähigkeit zu verlangsamen, im System Fuß zu fassen. Angriffssitzungen auf dem VPN-Gateway wurden gewaltsam abgebrochen und die Angreifer aus dem geschützten Bereich geworfen. In kompromittierten UZ wurden Passwörter sofort geändert.
In diesem Moment betraten die Jungs vom True0xA3-Team die Bühne und nutzten OSINT erfolgreich und berichteten über den Kompromiss des Behealthy-Büros, das unter dem Schutz eines anderen Teams steht. Angreifer konnten den Domänenadministrator gefährden. Die Organisatoren wurden über unseren Vorfall informiert und es wurden Beweise vorgelegt.
Die letzte Stunde war aufgrund des plötzlichen OSINT besonders heiß, alle warteten auf weitere Vorbereitungen der Organisatoren. Das Überwachungsteam wiederum überwachte alle verdächtigen Anomalien und Vorfälle, aber nach einem erfolglosen Versuch, in neue Hacking-Versuche einzudringen, folgte dies nicht. Die letzten Minuten der Spielzeit vergingen, und das erfolgreiche Hacken des vom Jet Security Team geschützten Büros fand nicht statt.
Und eine kleine abschließende Statistik für zwei Spieltage:
- Durchschnittlich 1200 EPS und in der Spitze etwas weniger als 3000 EPS;
- Über 7000 Vorfälle;
- Über 120 Millionen Veranstaltungen.
Faktoren, die uns geholfen haben zu gewinnen
- Kompetente Rollenverteilung. Jeder hat das meiste, was er in alltäglichen Projekten tut, eingerichtet und war damit beschäftigt. Niemand musste Materialien aus der Kategorie "Firewall für Dummies" studieren.
- Operatives Profiling von Korrelationsregeln. Alle Fehlalarme wurden verarbeitet und Korrekturen in Bezug auf die Funktionen der Spielinfrastruktur vorgenommen.
- Sofortige Antwort. Aufgrund der Tatsache, dass jedem Typ von SZI und Systemen mehrere Personen zugeordnet waren, hatten wir keine Probleme damit, dass sich die verantwortliche Person ausruhte oder nur ein paar Minuten wegging. Alle Informationen aus der Überwachung wurden so schnell wie möglich verarbeitet.
- Erfahrung im Härten und Überwachen verschiedener Infrastrukturen.
PS Besonderer Dank geht an alle, die gekommen sind und Fragen gestellt haben, und wir entschuldigen uns bei denen, die dabei nichts sagen konnten - das Team wartete auf „misshandelte Kosaken“ der Angreifer und konnte nicht alle Details preisgeben.
Dmitry Lifanov, Experte im Zentrum für Überwachung und Reaktion auf Informationssicherheitsvorfälle Jet CSIRT