Como (não) Perder um Domínio em um Fim de Semana

16K+ Alcance em 30 dias Empresa "Garda" Proteção de dados e segurança de rede 121,8 Classificação 105 Assinantes Assinar PRGarda 17 minutos atrás Como (não) perder um domínio em um fim de semana 6 min 607 Blog da empresa Empresa "Garda" Segurança da informação * Equipamentos de rede Sexta-feira, 18:00: os funcionários de uma empresa bastante grande terminam o trabalho calmamente. Segunda-feira, 08:00: todos os computadores de trabalho exibem a tela de recuperação do BitLocker, o controlador de domínio foi comprometido e as chaves estão com o invasor. Entre esses pontos, há quatro etapas, e nenhuma delas foi difícil.

Nenhuma das vulnerabilidades foi incomum. Você quase certamente viu cada uma delas em alguma infraestrutura. Mas aqui elas se combinaram em uma cadeia, e ninguém percebeu até que ela funcionasse até o fim.

Meu nome é Viktor Ievlev, sou o chefe do departamento de segurança da informação da empresa "Garda". Hoje, junto com você, vou investigar este incidente e compartilhar meus pensamentos sobre como a empresa poderia ter evitado um final triste.

Tudo começou com um MikroTik Na fronteira da rede estava um MikroTik. A administração foi deixada aberta na internet para que fosse possível entrar de fora sem VPN. Conveniente, sem dúvida, mas apenas até que alguém de fora se interesse por este dispositivo.

O invasor explorou a vulnerabilidade CVE-2024-54772 no RouterOS. O importante aqui não é nem a CVE específica, mas o próprio fato: a interface de gerenciamento do dispositivo na fronteira da rede estava exposta. Isso significa que, cedo ou tarde, uma vulnerabilidade adequada certamente seria encontrada.

Após a exploração, o atacante obteve controle sobre o roteador e o transformou em um ponto de apoio dentro do perímetro. Através do roteador, ele estabeleceu um túnel, e o tráfego subsequente passou como se fosse de dentro. Para os nós internos, a fonte parecia "própria". O invasor sentou-se virtualmente dentro do escritório e começou a reconhecimento.

Dentro da rede, ninguém o impediu O atacante percorreu a rede usando nmap e rapidamente montou um mapa básico: quais hosts estão ativos e quais serviços estão respondendo. Quase imediatamente, ele encontrou um alvo conveniente - um servidor Linux com SSH aberto.

Em infraestruturas corporativas, a principal atenção é quase sempre consumida pelo Windows: domínio, políticas, terminais, Exchange, servidores de arquivos, e os hosts Linux permanecem sem atenção. É neles que as versões antigas de software geralmente estão instaladas e não há EDR normal.

Aqui, tudo acabou sendo muito triste: root tinha uma senha fraca sem proteção contra força bruta. Assim, o invasor obteve um host interno completo, do qual pode trabalhar mais silenciosamente e sem ruído.

Se houvesse um antivírus no servidor, teoricamente ele poderia notar algo.

O invasor trouxe Impacket para o Linux, e Impacket é um conjunto de ferramentas Python bastante legítimas para trabalhar com SMB, NTLM, Kerberos e outros protocolos Windows. Para um antivírus baseado em assinatura, eles se parecem com scripts comuns. Ele não entende o contexto, o arquivo é como um arquivo.

O principal problema no AD CS Em seguida, o ataque passou para a fase mais interessante - para a infraestrutura de certificação da Microsoft. Muitas empresas usam AD CS - um centro de certificação que emite certificados digitais para usuários, servidores, serviços, às vezes controladores de domínio. Muito frequentemente, ele é configurado com base no princípio "foi instalado em algum momento, parece funcionar, é assustador tocar".

Em tais configurações, há uma coisa particularmente desagradável - Web Enrollment. Esta é uma interface web para solicitar certificados do navegador. Em si, não é um mal. O problema é que, em infraestruturas reais, nem todos sabem como configurá-lo corretamente: muitas vezes, ele é deixado ativado sem restrições e sem confirmação manual de emissão.

A mecânica de exploração da vulnerabilidade é a seguinte.

O invasor, já sentado no host Linux interno, executa ntlmrelayx.py do Impacket e se prepara para capturar a autenticação NTLM. Em seguida, provoca o controlador de domínio a se autenticar em seu host.

O controlador de domínio envia sua resposta ao desafio NTLM, mas o invasor não quebra nem escolhe essa resposta. Ele faz pior: ele a encaminha instantaneamente para o Web Enrollment do centro de certificação. E ele olha para a solicitação e diz: "Oh, este é o controlador de domínio. Entre" - e emite um certificado para a conta de máquina do controlador, o DomainControllerName$ condicional.

Por que isso aconteceu? A opção CA certificate manager approval não foi ativada. Sem ela, a CA carimba o certificado automaticamente. Para o atacante - o cenário ideal: nenhuma ação manual do administrador, nenhum ponto onde ele pudesse ser parado.

Após o certificado, o domínio já estava quase perdido Assim que o invasor tem em mãos o certificado do controlador de domínio, o trabalho quase legítimo em nome de um nó confiável começa. O próximo passo é DCSync.

O significado do DCSync é que o atacante imita o comportamento normal do controlador de domínio, que solicita dados de replicação de outro controlador. O Active Directory considera que ele tem um próprio e entrega os hashes das contas, incluindo as privilegiadas.

Depois disso, a pergunta "o invasor tem um administrador de domínio?" desapareceu.

E então - a etapa final, a mais ofensiva. Sem criptografadores espetaculares, sem frameworks de malware exóticos. Tendo direitos de administrador de domínio, o atacante usa o mecanismo padrão regular - Group Policy Object. Através do GPO, o comando para criptografar com o BitLocker é distribuído pela rede.

De manhã, os funcionários ligam os computadores e as máquinas, de forma legítima, de acordo com a política de domínio, começam a se criptografar. Nesta fase, apenas as consequências permanecem.

Por que a ameaça não foi notada antes Porque não havia nada para notar. A rede era plana - depois de entrar, o invasor não encontrou nenhum segmento claro. O tráfego East-West não foi controlado, o nmap interno passou como ruído de fundo. O host Linux com uma senha simples vivia uma vida silenciosa separada - não um nó chave, mas um serviço esquecido. O antivírus estava instalado, mas não sabia como reagir ao que estava acontecendo. Não havia armadilhas de Deception, não havia NDR, não havia regras para movimento anômalo dentro da rede também.

Não se trata de um único alerta perdido. Este é um teatro de segurança : alguns meios parecem estar lá, mas eles não param a atividade maliciosa e nem mesmo a veem direito.

Qual foi a causa raiz da perda do domínio Culpar tudo em um Web Enrollment e se acalmar é tentador, mas errado. Sim, o AD CS desempenhou um papel fundamental no clímax. Mas a comprometimento se tornou possível porque várias violações grosseiras coincidiram.

Perímetro. A interface de gerenciamento do MikroTik estava exposta, a vulnerabilidade não foi fechada a tempo.

Higiene interna. Servidor Linux com senha root simples, rede plana sem segmentação, firewall não restringiu o acesso a portas críticas (22, 135, 139, 445, 3389, 5985, 5986) por listas brancas, PKI configurada sem restrições rígidas, NTLM vivia muito livremente.

Monitoramento praticamente ausente.

O efeito clássico do queijo suíço: cada buraco individual é desagradável, mas não fatal. Quando eles se alinham - você perde o domínio em um fim de semana.

Onde o ataque poderia ter sido interrompido Cada etapa desta cadeia foi evitável. Não teoricamente, mas por uma medida específica que poderia ter sido implementada antes do ataque.

Etapa do ataque O que estava errado Como proteger Entrada via MikroTik A administração está aberta na internet, firmware com uma vulnerabilidade conhecida VPN ou jump-host para gerenciamento, gerenciamento de patches no perímetro Reconhecimento e movimento na rede Rede plana, tráfego east-west sem controle Segmentação, ACLs em portas críticas (22, 135, 445, 3389, 5985) por listas brancas Captura do host Linux Senha root simples, sem proteção contra força bruta, sem EDR Política de senha, fail2ban/análogo, EDR em todos os hosts, incluindo "auxiliares" NTLM Relay no AD CS (ESC8) Web Enrollment sem restrições, emissão automática de certificados, NTLM permitido na CA Desativar Web Enrollment ou ativar a aprovação do gerenciador da CA, Deny All no NTLM, monitoramento 4624 na CA DCSync e GPO Consequência das etapas anteriores - a essa altura já é tarde demais — A última linha está intencionalmente vazia. Se o ataque chegou ao DCSync, não há mais medidas técnicas. Resta a restauração de backups e a análise das consequências.

Algumas explicações para a tabela, porque o diabo está nos detalhes.

Vamos começar com o AD CS. As contas de máquina do domínio solicitam certificados por RPC, a interface web não é necessária em princípio. Mas se o Web Enrollment ainda for usado, sem a opção CA certificate manager approval ativada, o centro de certificação carimba os certificados automaticamente. Portanto, o ESC8 conseguiu funcionar sem nenhuma ação manual do administrador.

Com o NTLM, a história é semelhante em espírito: uma configuração poderia ter fechado toda a mecânica. A política "Network security: Restrict NTLM: Incoming NTLM traffic" no valor Deny All Accounts remove a própria possibilidade de um ataque de retransmissão - o atacante não tem nada para interceptar e nenhum lugar para encaminhar.

Vale a pena dizer separadamente sobre monitoramento. Event ID 4624 no centro de certificação - não é o lugar mais óbvio para alertas, mas foi lá que a primeira pista apareceria. Quando a conta da máquina se autentica de uma forma atípica - esta já é uma razão para descobrir.

É embaraçoso falar sobre hosts Linux: senha simples em root em 2026 - não é uma dívida técnica, mas uma porta aberta. Política de senha, fail2ban, atualizações, EDR - o mínimo básico, que regularmente está ausente nos servidores "auxiliares", aos quais todos não chegam.

E finalmente, segmentação . Se o SSH naquele host Linux estivesse aberto apenas a partir de nós administrativos específicos, o invasor do roteador capturado não teria chegado lá e todo o cenário posterior simplesmente não teria acontecido.

A maioria das medidas listadas não requer produtos comerciais. Assim, um IDPS baseado em snort e Suricata no perímetro destacaria o túnel. A propósito, eles podem ser instalados como módulos no firewall OPNsense ou pfSense CE (Community Edition).

Como SIEM ou XDR com um módulo EDR embutido, você pode olhar para Wazuh. Instalado no host Linux, ele imediatamente indicaria ao IB a força bruta SSH e o aparecimento do Impacket, e as regras configuradas no SIEM - para autenticação atípica na CA.

Mas Open Source não significa "funcionará sozinho": sem um engenheiro que entenda o que está pegando, esta é outra camada de teatro de segurança.

Infelizmente, administrações abertas, hosts Linux esquecidos, PKI (Public Key Infrastructure) em padrões, rede plana são encontrados em qualquer lugar. A questão não é se essa cadeia é possível para você. A questão é em qual linha desta tabela você a interromperá. Garda t.me/garda_ai — criamos soluções para proteger dados corporativos e segurança de rede Tags: CVE-2024-54772 mikrotik Web Enrollment investigação de incidentes cibersegurança vulnerabilidades e sua exploração vulnerabilidades de equipamentos de rede ransomware Hubs: Blog da empresa Empresa "Garda" Segurança da informação Equipamentos de rede +1 1 0 16K+ Alcance em 30 dias Empresa "Garda" Proteção de dados e segurança de rede Site 8K+ Alcance em 30 dias 13 Karma PR @PRGarda Usuário Assinar O fluxo de segurança da informação está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Habr Cursos para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo de segurança da informação Comentar Melhor do dia Semelhante