Saudações! Tendo visto interesse suficiente no que está acontecendo no The Standoff entre os defensores do PHDays 9, decidimos conversar sobre como a preparação e o “impasse” ocorreram através dos olhos do Jet CSIRT como parte da equipe de segurança do Jet.
Guo Standoff, eu criei
Algo assim, os colegas relataram que estamos novamente participando do The Standoff, e naturalmente concordamos.
Vale ressaltar imediatamente que para os defensores deste ano o formato da competição mudou um pouco. Todas as equipes receberam infra-estruturas de escritório muito semelhantes, e isso possibilitou aos organizadores inserir uma classificação de defensores em certos papagaios. E para a equipe de segurança do jato, esse foi o primeiro "confronto", onde o escritório foi defendido, e não a infraestrutura industrial.
Temos acesso à infraestrutura para nos preparar para a batalha cibernética no final de abril. Após a auditoria da infraestrutura, um conjunto de deficiências foi montado, aqui estão apenas algumas delas. Absolutamente em toda a infraestrutura, não havia patches reais. As senhas de todos os usuários podem ser obtidas através do Ntds.dit em texto não criptografado. Além disso, alguns usuários tinham senhas da lista TOP-500 ou senhas com um hash facilmente reversível. O endurecimento do sistema estava próximo de nada ou nada. Alguns hosts na DMZ tinham uma interface na sub-rede do servidor.
Com base nos resultados da auditoria, desenvolvemos certas medidas de segurança. Por sua vez, os organizadores, após aprovação preliminar, nos permitiram aplicar as políticas de que precisávamos e trazer todas as ferramentas e ferramentas de segurança que podem ser implantadas em um ambiente virtual. Devido aos prazos apertados, algumas idéias sobre medidas de proteção caíram no início. As principais configurações e perfis do SPI foram realizados durante as férias de maio (olá a todos que tiraram fotos dos piqueniques, também te amamos), e alguns equipamentos de proteção tiveram que ser ajustados logo antes do início no site. Além disso, vários serviços foram proibidos de corrigir e reconfigurar fortemente. Por exemplo, um deles era o Oracle Weblogic com CVE-2019-2725, que o PoC foi lançado nos primeiros dias de maio de 2019.
Bem, e uma lista do que trouxemos conosco:
- Firewall (fornecido pelos organizadores foi substituído);
- Solução antivírus;
- WAF;
- EDR
- Algumas soluções para enganar;
- Um par de scanners de vulnerabilidade;
- Pilha ELK para análise adicional do Netflow;
- SIEM.
Também devemos conversar sobre o que estava acontecendo no SIEM. Como fontes de eventos, tínhamos à disposição os logs do Windows, Sysmon, Auditd e, como você pode imaginar, eventos do próprio SZI. Se não houve problemas especiais com os dois primeiros, e concordamos rapidamente com as mudanças na política e na configuração do Sysmon, tivemos que lutar com os organizadores para a configuração do Auditd.
Paralelamente, identificamos os principais vetores de ataque e, com base nisso, selecionamos e adaptamos cenários e regras de correlação relevantes - um total de cerca de 160 regras de correlação. Além disso, um conjunto de painéis heterogêneos foi montado para nós críticos, SZI e o que exigia atenção especial na infraestrutura de jogos.
O impasse
No The Standoff, decidimos adotar o conceito de separar incidentes em externos e internos, pois havia um entendimento exato de que fora tentaríamos ativamente digitalizar e operar a web. Os incidentes relacionados à varredura e as tentativas de contornar o WAF foram monitorados separadamente, com uma prioridade mais baixa, o que nos permitiu focar em incidentes internos. Os painéis do SPI foram distribuídos entre os defensores nas áreas de responsabilidade, e pelo menos 2 pessoas foram designadas para cada ferramenta - para a possibilidade de rotação e descanso.
Tudo aconteceu, como esperávamos. O confronto começou por volta das 10 horas da manhã e, assim que o início foi iniciado, o sistema SIEM começou a emitir um monte de incidentes relacionados a uma verificação externa e a tentativas dos invasores de explorar a web. Em alguns casos, até o grupo não salvou. Junto com isso, os verificadores dos organizadores começaram a trabalhar, verificando o status de vários serviços no escritório, o que nos forçou a re-conduzir perfis até certo ponto para eliminar os falsos positivos associados a eles.
Nas primeiras horas do jogo, a equipe do Hack.ERS conseguiu encontrar as credenciais padrão do administrador (admin / admin) no CMS de um dos recursos e detectar uma possível vulnerabilidade de LFI. Essas tentativas não passaram despercebidas, nossos defensores deram uma resposta operacional e os atacantes no final não puderam avançar mais.
Até o final do primeiro dia de jogo, os métodos não foram alterados, o WAF ainda superava todas as tentativas de enviar algo interessante para os sites da empresa, e os mesmos "endereços externos", sem cessar, tentavam verificar nossos recursos.
No total, foram registrados 3.000 incidentes relacionados a tentativas de varredura, sem levar em conta o agrupamento de eventos em incidentes.
E cerca de 2500 incidentes com tentativas de contornar o WAF, também sem levar em conta o agrupamento de eventos em incidentes.
À noite, a intensidade de todas as atividades diminuiu - houve várias razões para isso. Parte dos defensores e atacantes não resistiu à passagem de som e ao ensaio do concerto, que deveria ser realizado no dia seguinte. Algumas equipes atacantes decidiram fazer uma pausa e continuar os ataques no final da manhã, na esperança de que os defensores e o monitoramento tivessem menos recursos de monitoramento e alguma fadiga.
Na manhã do segundo dia, os atacantes mudaram de tática. As informações de parte de seus funcionários foram publicadas em um dos sites da empresa. Os hackers aproveitaram essas informações e começaram a coletar ativamente contas de usuário por meio do Exchange (estatísticas de tentativas na captura de tela).
Um pouco mais tarde, foram feitas tentativas inseguras para selecionar uma senha no gateway da VPN; as contas que não estavam em nossa infraestrutura participaram da bruta. Com alta probabilidade, os atacantes tentaram usar contas da infraestrutura já hackeada na esperança de que os organizadores as deixassem iguais em todos os lugares. Como resultado, toda a situação com força bruta nos levou a criar um grupo de painéis sobre tendências em termos de autenticação do usuário. Além disso, reforçamos o monitoramento de incidentes relacionados a força bruta bem-sucedida, mas, felizmente, nenhum desses casos foi detectado.
Aproximadamente uma hora antes do final do jogo, as tendências viram tentativas únicas e bem-sucedidas de autenticar vários usuários, incluindo aqueles no Exchange; a análise operacional mostrou que as fontes eram máquinas dos usuários diretamente; a maioria dos eventos indicava que os organizadores efetuaram login no console da VMware Vcenter.
Ao mesmo tempo, gravamos uma verificação interna de um nó que foi conectado com êxito via VPN. Após uma análise operacional dos eventos relacionados ao incidente, ficou claro que os invasores conseguiram comprometer as credenciais de vários usuários e, a julgar pela ausência de tentativas de autenticação sem êxito, é provável que os dados do usuário tenham “vazado”.
As informações foram repassadas aos defensores. Durante todo o tempo de resposta nos computadores pessoais dos usuários comprometidos, a solução do terminal foi colocada em um modo de proteção preventiva para diminuir a capacidade de ganhar uma posição no sistema. As sessões de ataque no gateway da VPN foram eliminadas à força e os atacantes foram expulsos do perímetro protegido. No UZ comprometido, as senhas foram prontamente alteradas.
Nesse exato momento, os caras da equipe True0xA3 subiram ao palco e usaram com sucesso o OSINT e relataram o comprometimento do escritório da Behealthy, que está sob a proteção de outra equipe. Os invasores conseguiram comprometer o administrador do domínio. Os organizadores foram notificados do nosso incidente e foram fornecidas provas.
A última hora foi especialmente quente devido ao súbito OSINT, todo mundo estava esperando por mais alguns preparativos dos organizadores. A equipe de monitoramento, por sua vez, monitorou todas as anomalias e incidentes suspeitos, mas após uma tentativa malsucedida de penetrar em novas tentativas de invasão, ela não se seguiu. Portanto, os últimos minutos de jogo passaram e o sucesso do hacking do escritório protegido pela equipe de segurança da Jet não aconteceu.
E algumas estatísticas finais para dois dias de jogos:
- 1200 EPS em média e pouco menos de 3000 EPS no pico;
- Cerca de 7000 incidentes;
- Mais de 120 milhões de eventos.
Fatores que nos ajudaram a vencer
- Distribuição competente de papéis. Cada um montou e esteve envolvido na maior parte do que ele faz nos projetos diários. Ninguém precisou estudar materiais da categoria "firewall para manequins".
- Perfil operacional de regras de correlação. Todos os falsos positivos foram processados e efetuadas correções relacionadas aos recursos da infraestrutura de jogos.
- Resposta rápida. Devido ao fato de várias pessoas terem sido designadas para cada tipo de SZI e sistemas, não tivemos problemas com o fato de a pessoa responsável ter descansado ou simplesmente ter se afastado por alguns minutos. Todas as informações do monitoramento foram processadas o mais rápido possível.
- Experiência no fortalecimento e monitoramento de diversas infraestruturas.
PS Agradecimentos especiais a todos que vieram e fizeram perguntas, e pedimos desculpas àqueles que não foram capazes de dizer algo no processo - a equipe estava esperando por “cossacos maltratados” dos atacantes e não pôde divulgar todos os detalhes.
Dmitry Lifanov, especialista no Centro de Monitoramento e Resposta a Incidentes de Segurança da Informação Jet CSIRT