Get best of the week

Uma vez em um pentest, ou Como quebrar tudo com a ajuda de um urologista e Roskomnadzor


Este artigo é baseado em um testemunho de muito sucesso, realizado por especialistas do Grupo-IB há alguns anos: aconteceu uma história que afirma ser uma adaptação cinematográfica em Bollywood. Agora, provavelmente, a reação do leitor se seguirá: "Ah, outro artigo de RP, mais uma vez, eles são desenhados, quão bons são, não se esqueça de comprar um penteado". Bem, por um lado, é. No entanto, existem várias razões pelas quais este artigo apareceu. Eu queria mostrar o que exatamente os pentesters estão fazendo, o quão interessante e não trivial esse trabalho pode ser, quais circunstâncias divertidas podem se desenvolver nos projetos e, o mais importante, mostrar o material ao vivo com exemplos reais.

Para restaurar o equilíbrio da modéstia no mundo, depois de um tempo escreveremos sobre o pentest, que não foi. Mostramos como processos bem estabelecidos em uma empresa podem proteger contra toda uma gama de ataques, mesmo que bem preparados, simplesmente porque esses processos existem e realmente funcionam.

O cliente deste artigo também estava bem em geral, pelo menos melhor que 95% do mercado na Federação Russa, de acordo com nossos sentimentos, mas havia várias nuances menores que formaram uma longa cadeia de eventos, o que levou a um longo relatório sobre o trabalho. e depois para este artigo.

Então, estoca pipoca e bem-vindo ao detetive. Estou dando a palavra a Pavel Suprunyuk , Diretor Técnico do Grupo de Auditoria e Consultoria-IB.

Parte 1. Médico de Pochkin


2018 ano. Existe um cliente - uma empresa de TI de alta tecnologia, que por si só atende muitos clientes. Ele deseja obter uma resposta para a pergunta: é possível, sem nenhum conhecimento e acesso inicial, trabalhando através da Internet, obter direitos de administrador para um domínio do Active Directory? Nenhuma engenharia social é de interesse ( eh, mas em vão ), elas não interferem especificamente no trabalho, mas podem recarregar acidentalmente um servidor de trabalho estranho, por exemplo. Uma tarefa adicional é identificar o maior número possível de vetores de ataque em relação ao perímetro externo. A empresa realiza regularmente esses testes, e agora o prazo para um novo teste. As condições são quase típicas, adequadas, compreensíveis. Descer.

Existe um nome de cliente - seja "Empresa", com o site principal www.company.ru. Obviamente, o cliente é chamado de maneira diferente, mas neste artigo tudo será despersonalizado.
Conduzo inteligência de rede - descubro quais endereços e domínios estão listados pelo cliente, desenho um diagrama de rede, como os serviços são distribuídos para esses endereços. Eu recebo o resultado: mais de 4000 endereços IP ao vivo. Examino os domínios nessas redes: felizmente, a grande maioria são redes destinadas a clientes, e elas não nos interessam formalmente. O cliente acredita no mesmo.

Resta uma rede com 256 endereços, para a qual, neste momento, já existe um entendimento da distribuição de domínios e subdomínios por endereços IP, há informações sobre as portas digitalizadas, o que significa que você pode procurar os serviços por outros interessantes com seus olhos. Paralelamente, todos os tipos de scanners são lançados em endereços IP acessíveis e separadamente - em sites.

Existem muitos serviços. Isso geralmente é uma alegria para o pentester e a antecipação de uma vitória rápida, pois quanto mais serviços, maior o campo de ataque e mais fácil é encontrar um artefato. Uma rápida olhada nos sites mostrou que a maioria deles são interfaces da web dos produtos conhecidos de grandes empresas do mundo que afirmam que não estão felizes com você. Eles solicitam um nome de usuário e senha; no limite, eles agitam o campo para inserir o segundo fator, solicitam um certificado de cliente TLS ou os enviam para o Microsoft ADFS. Alguns simplesmente não estão disponíveis na Internet. Para alguns, você obviamente precisa ter um cliente pago especial por três salários ou saber o URL exato para inserir. Omitiremos mais uma semana de desânimo gradual no processo de tentar "romper" o software por versão em busca de vulnerabilidades conhecidas, procurar conteúdo oculto nos caminhos da Web e contas vazadas de serviços de terceiros, como o LinkedIn,tenta selecionar senhas para eles, bem como escavar vulnerabilidades em sites auto-descritos - a propósito, segundo as estatísticas, esse é o vetor mais promissor de um ataque externo até hoje. Imediatamente noto a arma do cinema, que subseqüentemente disparou.

Portanto, havia dois sites que se destacam em centenas de serviços. Esses sites tinham uma coisa em comum: se você não se envolver em um reconhecimento meticuloso da rede por domínio, mas procurar "de frente" por portas abertas ou envenenar o scanner de vulnerabilidades em um intervalo de IP conhecido, esses sites sairão da verificação, eles simplesmente não serão visíveis sem saber o nome DNS. Talvez eles tenham sido perdidos mais cedo, pelo menos, e nossas ferramentas automáticas não tenham encontrado problemas, mesmo que tenham sido definidas diretamente no recurso.

A propósito, sobre o fato de que scanners lançados anteriormente foram geralmente encontrados. Deixe-me lembrá-lo: para algumas pessoas, “pentest” é equivalente a “varredura automatizada”. E os scanners deste projeto não disseram nada. Bem, as vulnerabilidades médias mostraram o máximo (3 em 5 em termos de perigo): alguns serviços têm um certificado TLS ruim ou algoritmos de criptografia desatualizados, e a maioria dos sites possui Clickjacking. Mas com isso você não chegará à meta. Provavelmente, os scanners seriam mais úteis aqui, mas deixe-me lembrá-lo: o próprio cliente pode comprar esses programas e testar-se com eles, e, a julgar pelos resultados sem graça, ele já verificou.

Voltar para os sites "anormais". O primeiro é algo como um Wiki local em um endereço não padrão, mas deixe wiki.company [.] Ru estar neste artigo. Ela também solicitou imediatamente um nome de usuário e senha, mas já através do NTLM no navegador. Para o usuário, isso parece uma janela ascética solicitando um nome de usuário e senha. E isso é uma prática ruim.

. NTLM - . — Active Directory. company.ru, «» DNS-. , - , , - . — NTLM (, ?), «» , . , . — , . — . — , , . — pass-the-hash-. ADFS .

Há um recurso ruim dos produtos da Microsoft: mesmo que você não tenha publicado especificamente esse NTLM, ele estará na instalação padrão no OWA e no Lync, pelo menos.

A propósito, o autor deste artigo bloqueou acidentalmente aproximadamente 1000 contas de funcionários de um grande banco em apenas uma hora e depois teve uma aparência um tanto pálida. Os serviços de TI do banco também estavam fracos, mas tudo terminou bem e adequadamente, até fomos elogiados por termos sido os primeiros a encontrar esse problema e provocamos uma correção rápida e decisiva.
O segundo site tinha o endereço "obviamente algum sobrenome.company.ru". Encontrado no Google, algo parecido com isto na página 10. O design está começando em meados de 2000, e uma pessoa respeitável olhou da página principal, algo como isto:


Então ele tirou uma moldura do "Coração de cachorro", mas acredite, era remotamente semelhante, até o esquema de cores em cores semelhantes. Deixe o site ser chamado preobrazhensky.company.ru .

Era um site pessoal ... de um urologista. Tornou-se interessante o que o site do urologista faz no subdomínio de uma empresa de alta tecnologia. Uma rápida pesquisa no Google mostrou que esse médico era co-fundador de uma das entidades legais de nosso cliente e até contribuiu com cerca de 1000 rublos de capital registrado. Provavelmente, o site foi criado há muitos anos e os recursos do servidor do cliente foram usados ​​como hospedagem. O site perdeu a relevância há muito tempo, mas, por algum motivo, ficou trabalhando por um longo tempo.

Em termos de vulnerabilidades, o site em si era seguro. Olhando para o futuro, direi que era um conjunto de estática - páginas html simples com inserções de ilustrações na forma de rins e bexigas. "Quebrar" esse site é inútil.

Mas o servidor da web era mais interessante. A julgar pelo cabeçalho do servidor HTTP, havia o IIS 6.0, o que significa que o Windows 2003 foi usado como sistema operacional. O scanner revelou anteriormente que esse site específico do urologista, ao contrário de outros hosts virtuais no mesmo servidor da web, respondia ao comando PROPFIND, ou seja, o WebDAV trabalhava lá. A propósito, o scanner emitiu essas informações com a marca Info (no idioma dos relatórios do scanner, esse é o menor perigo) - essas coisas geralmente são simplesmente ignoradas. Em conjunto, isso deu um efeito interessante, que foi revelado apenas após outra pesquisa no Google: uma rara vulnerabilidade de estouro de buffer associada a um conjunto de Shadow Brokers, a saber, o CVE-2017-7269, que já tinha uma exploração pronta. Em outras palavras, será um desastre se você tiver o Windows 2003 e o WebDAV em execução no IIS.Embora trabalhe na produção do Windows 2003 em 2018, isso é um desastre.

A exploração terminou no Metasploit e foi imediatamente testada com uma carga que enviou uma consulta DNS para um serviço controlado - o Burp Collaborator é tradicionalmente usado para interceptar consultas DNS. Surpreendentemente, funcionou pela primeira vez: um idiota foi recebido no DNS. Houve uma tentativa de criar uma conexão de back-end através da porta 80 (ou seja, uma conexão de rede do servidor para o invasor, com acesso ao cmd.exe no host da vítima), mas ocorreu um fiasco. A conexão não chegou e, após a terceira tentativa de operação, o site, juntamente com todas as imagens divertidas, desapareceu completamente.

Normalmente, isso é seguido por uma carta no estilo de "cliente, acorde, deixamos cair tudo". Mas fomos informados de que o site não tem nada a ver com processos de negócios e funciona lá em geral, não está claro por que, como todo o servidor, e que podemos usar esse recurso como quisermos.
Após cerca de um dia, o site começou a funcionar de repente por conta própria. Depois de criar um suporte a partir do WebDAV no IIS 6.0, descobri que a configuração padrão é reiniciar os fluxos de trabalho do IIS a cada 30 horas. Ou seja, quando o controle saiu do código do shell, o fluxo de trabalho do IIS foi encerrado, ele foi reiniciado algumas vezes e depois foi interrompido por 30 horas.

Desde a primeira vez que o bekconnect no tcp falhou, escrevi esse problema para uma porta fechada. Ou seja, ele sugeriu a presença de algum firewall que não permitia a saída de conexões de saída. Comecei a executar códigos de shell que classificavam muitas portas TCP e UDP, não havia efeito. A conexão reversa carrega através de http (s) do Metasploit - meterpreter / reverse_http (s) não funcionou. De repente, a conexão com a mesma porta 80 foi estabelecida, mas imediatamente quebrou. Ele escreveu isso para a ação do IPS ainda imaginário, que não gostava de tráfego com menos metros. Considerando que a conexão do tcp puro à porta 80 falhou, mas o http falhou, concluí que o proxy http estava de alguma forma configurado no sistema.

Tentei até meterpreter através do DNS (obrigadod00kiepor seus esforços, salvou muitos projetos), lembrando o primeiro sucesso, mas ele nem trabalhou no estande - o código do shell era muito volumoso para esta vulnerabilidade.

Na realidade, ficou assim: 3-4 tenta atacar em 5 minutos e aguarda 30 horas. E assim por três semanas seguidas. Eu até configurei um lembrete para não perder tempo. Além disso, havia uma diferença no comportamento dos ambientes de teste e combate: para essa vulnerabilidade, havia duas explorações semelhantes, uma do Metasploit, a segunda da Internet, refeita na versão do Shadow Brokers. Assim, no combate apenas o Metasploit funcionou, no estande - apenas o segundo, o que complicou ainda mais a depuração e quebrou o cérebro.

No final, o código do shell provou ser eficaz, que baixou um arquivo exe de um determinado servidor via http e o executou no sistema de destino. O código da shell era pequeno o suficiente para caber e, pelo menos, funcionava. Como o servidor TCP não gostou muito do tráfego e o http (s) foi inspecionado quanto ao meterpreter, decidi que a maneira mais rápida era fazer o download do arquivo exe que continha o DNS-meterpreter por esse código de shell.

Aqui, novamente, surgiu o problema: ao baixar o arquivo exe e, como as tentativas mostraram, não importa como, o download foi interrompido. Mais uma vez, algum tipo de dispositivo de proteção entre o meu servidor e o urologista não gostou do tráfego http com exe dentro. Parecia uma solução "rápida" alterar o código de shell para ofuscar o tráfego http em tempo real, para que dados binários abstratos fossem transferidos em vez de exe. Finalmente, o ataque foi bem-sucedido, o controle veio através do canal DNS fino:


Imediatamente ficou claro que eu tinha os direitos mais simples do fluxo de trabalho do IIS que me permitiam fazer nada. É assim que parecia no console do Metasploit:


Todas as metodologias pentest sugerem fortemente que você precisa aumentar os direitos ao obter acesso. Normalmente, eu não faço isso localmente, pois o primeiro acesso é considerado simplesmente como um ponto de entrada na rede, e geralmente é mais fácil e rápido comprometer outra máquina na mesma rede do que aumentar os privilégios em um host existente. Mas esse não é o caso, já que o canal DNS é muito estreito e não permitirá que o tráfego circule.

Supondo que este servidor com Windows 2003 não tenha sido reparado a partir da conhecida vulnerabilidade MS17-010, estou encapsulando o tráfego para a porta 445 / TCP através do túnel DNS meterpreter para localhost (sim, isso também é possível) e tentando executar um exe baixado anteriormente através da vulnerabilidade. O ataque funciona, eu recebo uma segunda conexão, mas com privilégios de SISTEMA.


Curiosamente, o servidor ainda estava tentando se proteger do MS17-010 - desativou os serviços de rede vulneráveis ​​na interface externa. Isso realmente protege contra ataques pela rede, mas o ataque de dentro do host local funcionou, pois você não pode simplesmente pegar e desligar rapidamente o SMB no host local.
Em seguida, novos detalhes interessantes são revelados:

  1. Com permissões de sistema, você pode instalar facilmente a conexão traseira via TCP. Obviamente, a proibição do TCP direto é exclusivamente um problema de usuário limitado do IIS. Desmancha prazeres: o tráfego de usuários do IIS foi de alguma forma envolvido no ISA Proxy local em ambas as direções. Como exatamente isso funciona não é reproduzido.
  2. Estou em uma certa "DMZ" (e este não é um domínio do Active Directory, mas um GRUPO DE TRABALHO) - parece lógico. Mas, em vez do endereço IP privado ("cinza") esperado, sou bastante "branco", exatamente o mesmo que ataquei anteriormente. Isso significa que a empresa é tão antiga para o mundo do endereçamento IPv4 que pode manter a zona DMZ em 128 endereços "brancos" sem NAT, conforme o esquema, conforme ilustrado nos manuais da Cisco de 2005.

Como o servidor é antigo, é garantido que o Mimikatz funcione diretamente da memória:


Recebo a senha do administrador local, encapsulo o tráfego RDP através do TCP e entro em uma área de trabalho aconchegante. Como você pode fazer qualquer coisa com o servidor, excluo o antivírus, acho que o servidor só pode ser acessado pela Internet nas portas TCP 80 e 443 e 443 não estava ocupado. Eu elevo o servidor OpenVPN para 443, adiciono as funções NAT ao meu tráfego VPN e obtenho acesso direto à rede DMZ de forma ilimitada através do meu OpenVPN. Vale ressaltar que o ISA, com alguns recursos IPS não desativados, bloqueou meu tráfego com a varredura de portas, pela qual teve que ser substituído por um RRAS mais simples e flexível. Então, os padres ainda precisam administrar tudo.


Um leitor atento perguntará: "E qual é o segundo site - um wiki com autenticação NTLM, sobre o qual tanto foi escrito?" Sobre isso mais.

Parte 2. Você ainda não está criptografado? Então vamos até você já aqui


Portanto, há acesso ao segmento de rede DMZ. Você precisa ir ao administrador do domínio. A primeira coisa que vem à mente é verificar automaticamente a segurança dos serviços dentro do segmento DMZ, ainda mais porque agora eles estão muito mais abertos para pesquisas. Uma imagem típica de um teste de penetração: o perímetro externo é mais protegido do que os serviços internos e, quando você obtém acesso a uma grande infraestrutura, é muito mais fácil obter direitos estendidos em um domínio apenas porque esse domínio começa a ser acessível para ferramentas e, em segundo lugar, sempre há algumas questões críticas na infraestrutura para vários milhares de hosts.

Carrego scanners na DMZ através do túnel OpenVPN, espero. Abro o relatório - novamente nada sério, aparentemente alguém andou da mesma maneira para mim. O próximo passo é examinar como os hosts se comunicam na rede DMZ. Para fazer isso, para iniciantes, um Wireshark regular é iniciado com a escuta de solicitações de transmissão, principalmente ARP. Os pacotes ARP foram coletados o dia todo. Acontece que vários gateways são usados ​​nesse segmento. Isso será útil mais tarde. Ao colar dados nos dados de resposta a solicitações e de varredura de porta do ARP, encontrei os pontos de saída do tráfego do usuário na rede local, além dos serviços que eram conhecidos anteriormente, como Web e correio.

Como no momento eu não tinha acesso a outros sistemas e não havia uma única conta para serviços corporativos, foi decidido buscar pelo menos alguma conta do tráfego usando o ARP Spoofing.

Cain & Abel foi lançado no servidor do urologista. Levando em consideração os fluxos de tráfego identificados, os pares mais promissores foram selecionados para o ataque "homem no meio" e, em seguida, por um lançamento de curto prazo por 5 a 10 minutos, com um temporizador para reiniciar o servidor em caso de "congelamento", algum tráfego de rede foi recebido. Como na piada, havia duas notícias:

  1. Bom: muitas credenciais foram capturadas e o ataque como um todo funcionou.
  2. Ruim: todas as credenciais eram de clientes do próprio cliente. Fornecendo serviços de suporte, os especialistas do cliente estão conectados aos serviços ao cliente que nem sempre têm a criptografia de tráfego configurada.

Como resultado, obtive muitas credenciais que eram inúteis no contexto do projeto, mas definitivamente interessantes como uma demonstração do perigo de um ataque. Roteadores de fronteira de grandes empresas com telnet, encaminharam a depuração de portas http para o CRM interno com todos os dados, acesso direto ao RDP do Windows XP na rede local e outros obscurantismos. O resultado foi uma espécie de compromisso da cadeia de suprimentos, de acordo com a matriz do MITRE .

Também encontrou uma oportunidade divertida de coletar e-mails do tráfego, algo assim. Este é um exemplo de uma carta finalizada que foi do nosso cliente para a porta SMTP do cliente, novamente, sem criptografia. Um certo Andrei pede que seu homônimo reenvie a documentação, que é apresentada em um disco na nuvem com um nome de usuário, senha e link em uma carta de resposta:


Esse é outro lembrete de que você precisa criptografar todos os serviços. Não se sabe quem e quando lerá e aplicará especificamente seus dados - um provedor, um administrador de sistemas de outra empresa ou um fornecedor desse tipo. Fico calado ao saber que muitos podem simplesmente interceptar tráfego não criptografado.

Apesar do aparente sucesso, isso não foi aproximado da meta. Era possível, é claro, ficar sentado por um longo tempo e obter informações valiosas, mas não o fato de que elas apareceriam lá, e o ataque em si é muito arriscado em termos de integridade da rede.

Depois de mais uma escavação nos serviços, uma ideia interessante veio à minha mente. Existe um utilitário chamado Respondente (é fácil encontrar exemplos de aplicativos com esse nome) que, por "envenenar" solicitações de transmissão, provoca conexões através de uma variedade de protocolos como SMB, HTTP, LDAP, etc. de maneiras diferentes, cada pessoa que se conectar é solicitada a autenticar e ajustar, para que a autenticação passe pelo NTLM e em um modo transparente para a vítima. Na maioria das vezes, um invasor coleta os apertos de mão NetNTLMv2 e deles, de acordo com o dicionário, recupera rapidamente as senhas de domínio do usuário. Eu queria algo semelhante aqui, mas os usuários estavam sentados "atrás do muro", ou melhor, eles foram separados por um firewall e, na WEB, passaram pelo cluster de proxy do Blue Coat.

Lembre-se, especifiquei que o nome de domínio do Active Directory coincidia com o domínio "externo", ou seja, era company.ru? Portanto, o Windows, mais precisamente o Internet Explorer (e Edge e Chrome), permite que o usuário se autentique de forma transparente no HTTP via NTLM, se considerar que o site está em alguma "Zona da Intranet". Um dos sinais de "Intranet" é uma chamada para um endereço IP "cinza" ou um nome DNS curto, ou seja, sem pontos. Como um servidor com um nome IP e DNS “branco” preobrazhensky.company.ru estava à sua disposição e as máquinas de domínio geralmente obtêm o sufixo de domínio do Active Directory via DHCP para entrada simplificada de nomes, eles apenas precisavam escrever um URL preobrazhensky na barra de endereçospara que eles encontrem o caminho certo para um servidor de urologista comprometido, sem esquecer que agora é chamado de "Intranet". Ou seja, ao mesmo tempo, fornece-me o usuário NTLM-handshake sem o seu conhecimento. Resta fazer os navegadores clientes pensarem na necessidade urgente de acessar este servidor.

O maravilhoso utilitário Intercepter-NG veio em socorro (obrigadoInterceptador) Permitia alterar o tráfego em movimento e funcionava perfeitamente no Windows 2003. Havia até uma funcionalidade separada para modificar apenas arquivos JavaScript no fluxo de tráfego. Foi planejado uma espécie de script entre sites massivo.

Proxies do Blue Coat por meio dos quais os usuários acessavam o conteúdo estático em cache da WEB global periodicamente. Ao interceptar o tráfego, ficou claro que eles trabalham 24 horas por dia, solicitando incessantemente as estatísticas frequentemente usadas para acelerar a exibição do conteúdo durante o horário de pico. Além disso, a BlueCoat tinha um User-Agent específico, que o distinguia claramente de um usuário vivo.

O Javascript foi preparado, que com a ajuda do Intercepter-NG durante a noite passou uma hora inteira implementando cada resposta com arquivos JS do Blue Coat. O script fez o seguinte:

  • Detectou o navegador atual pelo User-Agent. Se fosse o Internet Explorer, Edge ou Chrome - funcionou.
  • Aguarde até que o DOM da página seja formado.
  • Inseri uma imagem invisível com o atributo src do tipo preobrazhensky no DOM : 8080 / NNNNNNN.png, em que NNN são dígitos arbitrários para que o BlueCoat não faça cache.
  • Defina uma variável de flag global que a injeção foi feita e que você não precisa mais inserir imagens.

O navegador tentou carregar esta imagem, na porta 8080 do servidor comprometido, aguardava o túnel TCP no meu laptop, onde o mesmo Respondente foi iniciado, o que requer login NTLM no navegador.


A julgar pelos logs do Respondente, pela manhã as pessoas começaram a trabalhar, ligaram as estações de trabalho e começaram a visitar o servidor do urologista em massa e imperceptivelmente, sem esquecer de "mesclar" os handshakes NTLM. Os handshakes choveram o dia todo e claramente acumularam material para um ataque de recuperação de senha notoriamente bem-sucedido. É assim que os logs do Respondente eram:

Visitas secretas maciças ao servidor do urologista por usuários

Você provavelmente já percebeu que toda essa história se baseia no princípio "tudo estava bem, mas havia uma chatice, depois houve superação e tudo deu certo". Então, houve uma chatice. Dos quinhentos apertos de mão únicos, nenhum foi revelado. E isso leva em consideração o fato de que, mesmo em um laptop com um processador inoperante, esses handshakes NTLMv2 superam a velocidade de várias centenas de milhões de tentativas por segundo.

Eu tive que me armar com técnicas de mutação de senha, uma placa gráfica, um dicionário mais grosso e esperar. Depois de muito tempo, várias contas com senhas no formato "Q11111111 ... .1111111q" foram abertas, o que sugere que todos os usuários foram forçados a criar uma senha muito longa com um caso diferente de caracteres, que deveria ser complicado. Mas você não pode simplesmente deixar um usuário experiente e, dessa maneira, ele facilitou a lembrança. No total, foram abertas cerca de 5 peças, e apenas uma delas tinha direitos valiosos sobre os serviços.

Parte 3. Roskomnadzor revida


Portanto, as primeiras contas de domínio foram recebidas. Se nesse momento você não adormeceu após uma longa leitura, provavelmente se lembrará de que mencionei um serviço que não exigia um segundo fator de autenticação: este é um wiki com autenticação NTLM. Claro, a primeira coisa que eles fizeram foi entrar. Entrar na base de conhecimento interna rapidamente trouxe resultados:

  • A empresa possui uma rede Wi-Fi com autenticação de conta de domínio com acesso a uma rede local. Com o conjunto de dados atual, esse já é um vetor de ataque ativo, mas você precisa ir ao escritório com os pés e se colocar em algum lugar no escritório do cliente.
  • , , … « » , . «» «» . , DMZ.

Obviamente, o "segundo fator" foi imediatamente adicionado à conta comprometida como um aplicativo no meu telefone. Havia um programa que pode enviar em voz alta uma solicitação push para o telefone com os botões "aprovar" / "desaprovar" ou mostrar silenciosamente o código OTP na tela para uma entrada independente adicional. Além disso, o primeiro método deveria ser a única instrução correta, mas não funcionou, diferentemente do método OTP.

Com o "segundo fator" quebrado, consegui acessar o correio do Outlook Web Access e acessar remotamente o Citrix Netscaler Gateway. No Outlook, uma surpresa estava esperando pelo correio:


Nesta cena rara, você pode ver como Roskomnadzor ajuda os pentesters:

estes foram os primeiros meses após o famoso bloqueio do ventilador do Telegram, quando redes inteiras com milhares de endereços desapareceram inexoravelmente do acesso. Ficou claro por que o push não funcionou imediatamente e por que minha "vítima" não tocou o alarme porque eles começaram a usar a conta dela em horário aberto.

Aqueles que estão familiarizados com o Citrix Netscaler imaginam que geralmente é implementado de tal maneira que é possível transmitir ao usuário apenas uma interface de imagem, tentando não fornecer as ferramentas para iniciar aplicativos de terceiros e transferir dados, restringindo de maneira alguma as ações por meio de shells de controle padrão. Pela minha ocupação, eu só tenho 1C:


Tendo andado um pouco na interface 1C, descobri que existem módulos de processamento externos lá. Eles podem ser carregados a partir da interface e serão executados no cliente ou servidor, dependendo dos direitos e configurações.

Pedi aos programadores 1C dos amigos que criassem esse processamento que pegaria uma string e a executasse. Em 1C, o lançamento do processo é mais ou menos assim (retirado da Internet). Concordo, a sintaxe da linguagem 1C atinge uma pessoa de língua russa com seu imediatismo?



O processamento foi perfeitamente executado, resultando no que os Pentesters chamam de "shell" - o Internet Explorer foi lançado por meio dele.


Anteriormente, o endereço do sistema foi encontrado no correio, o que permite solicitar passes para o território. Eu pedi um passe para o caso de precisar usar o vetor de ataque via WiFi.


Na Internet, eles dizem que no escritório do cliente ainda havia um saboroso serviço de catering gratuito, mas eu ainda preferia desenvolver um ataque através de um site remoto, é mais calmo.

O AppLocker foi ativado no servidor de aplicativos com o Citrix, mas foi ignorado. O mesmo Meterpreter foi carregado e iniciado via DNS, porque as versões http (s) não desejavam se conectar e, então, eu não sabia o endereço proxy interno. Aliás, a partir deste momento, o pentesto externo se transformou essencialmente no interno.

Parte 4. Direitos de administrador para usuários - isso é ruim, p-nyatnenko?


A primeira coisa que um Pentester faz quando assume o controle da sessão de um usuário do domínio é coletar todas as informações sobre os direitos no domínio. Existe um utilitário BloodHound, que permite baixar automaticamente informações sobre usuários, computadores, grupos de segurança através do protocolo LDAP do controlador de domínio e informações sobre qual usuário efetuou login recentemente e quem é o administrador local através do SMB.

Uma técnica típica para capturar privilégios de administrador de domínio parece simplificada como um ciclo de ações monótonas:

  • Vamos para computadores de domínio, onde existem direitos de administrador local, com base em contas de domínio já capturadas.
  • Mimikatz , Kerberos NTLM , . lsass.exe . Windows 2012R2/Windows 8.1 .
  • , . . - .

"Fim do ciclo"; como os programadores da 1C escreveriam aqui.

Portanto, nosso usuário acabou sendo um administrador local em apenas um host com o Windows 7, cujo nome era a palavra "VDI" ou "Virtual Desktop Infrastructure", máquinas virtuais pessoais. Provavelmente, o projetista do serviço VDI sugeriu que, como o VDI é o sistema operacional pessoal do usuário, permita que o usuário altere o ambiente de software, como desejar, de qualquer maneira que o host possa ser "recarregado". Eu também pensei que, em geral, a idéia é boa, fui a esse host pessoal de VDI e fiz um soquete lá:

  • Eu instalei o cliente OpenVPN lá, que fez um túnel através da Internet para o meu servidor. O cliente teve que passar pelo próprio Blue Coat com autenticação de domínio, mas o OpenVPN lidou, como eles dizem, fora da caixa.
  • Instalado no VDI OpenSSH. Bem, realmente, o que é esse Windows 7 sem SSH?

É assim que parecia vivo. Lembro que tudo isso deve ser feito através do Citrix e 1C:


Uma das técnicas para promover o acesso a computadores vizinhos é verificar as senhas dos administradores locais em busca de uma correspondência. Aqui a sorte estava esperando imediatamente: o hash NTLM do administrador local padrão (que de repente se chamava Administrator) aproximou-se dos hosts VDI vizinhos, dos quais havia várias centenas, através do ataque do tipo passe-a-hash. Claro, o ataque imediatamente os atacou.
Em seguida, os administradores da VDI deram um tiro no pé duas vezes:
  • A primeira vez que máquinas VDI não foram acionadas pelo LAPS, salvando essencialmente a mesma senha de administrador local de uma imagem que foi implantada em massa no VDI.
  • — , pass-the-hash . , , — .
Por que o serviço SSH nesse Windows? Muito simples: agora o servidor OpenSSH não apenas forneceu um shell de comando interativo conveniente, sem interferir no trabalho do usuário, mas também um proxy socks5 no VDI. Com essas meias, eu me conectei via SMB e coletei contas em cache de todas essas centenas de máquinas VDI, depois procurei o caminho para o administrador do domínio nos gráficos do BloodHound. Com centenas de hosts à minha disposição, encontrei esse caminho rapidamente. Direitos de administrador de domínio foram obtidos.

Aqui está uma foto da Internet, mostrando uma pesquisa semelhante. Os links mostram quem é o administrador e quem entrou onde.


A propósito, lembre-se da condição desde o início do projeto - "não aplique engenharia social". Então, proponho ponderar quanto esse Bollywood inteiro seria cortado com efeitos especiais, se fosse possível aplicar phishing banal. Mas, pessoalmente, eu estava muito interessado em fazer tudo isso. Espero que você esteja interessado em ler isso. Obviamente, nem todo projeto parece tão intrigante, mas o trabalho como um todo é muito intrigante e não fica estagnado.

Provavelmente, alguém terá uma pergunta: como se proteger? Mesmo neste artigo, muitas técnicas são descritas, os administradores do Windows nem conhecem muitas delas. No entanto, proponho olhar para eles da perspectiva de princípios e medidas de segurança da informação:

  • não use software desatualizado (lembra do Windows 2003 no início?)
  • não mantenha sistemas desnecessários ligados (por que o site do urologista?)
  • verifique as senhas dos usuários para se fortalecer (caso contrário, soldados ... pentesters farão isso )
  • Não possui as mesmas senhas para contas diferentes (comprometimento da VDI)
  • e outro

Obviamente, é muito difícil de implementar, mas no próximo artigo mostraremos na prática que isso é bem possível.

More articles:


All Articles