Hello World! Faz muito tempo que não posto no meu blog. Desde meados de 2022, tenho dedicado meu tempo e energia a pesquisar a técnica Red Teaming e ainda explorar o vasto oceano. Durante meu treinamento, pratiquei com ambientes vulneráveis (hacking HackTheBox e outros do gênero). Com base em toda a minha experiência, diria que esta área está evoluindo rapidamente, com muitos novos vetores de ataque e formas de mitigá-los no dia a dia. Este campo não para, e vai desenvolver-se a um ritmo competitivo para a Equipa Vermelha e para a Equipa Azul.
Com meus melhores esforços, comecei a entender como as redes corporativas funcionam e como sua arquitetura típica é configurada. Recentemente, participei do time vermelho pela primeira vez. O cliente deste evento foi uma grande fintech com uma extensa rede. A abordagem de interação é executar uma simulação de um adversário com o cenário de violação pretendido. Este blog apenas descreve a metodologia de interação que eu mesmo aderi, pode mudar dependendo do ponto de vista de outros membros do Red Team.
A empresa-alvo tinha muitos domínios da Internet hospedando vários aplicativos para seus funcionários e clientes. Qualquer informação no site é importante para o time vermelho. O pentesting de aplicativos da Web desempenha um papel importante na conclusão da tarefa. Após coletar informações pela internet pública, ficamos sabendo de vários outros domínios utilizados pela empresa. Algumas táticas de enumeração importantes que você precisa executar antes de realmente explorar a rede interna de uma empresa são as seguintes:
- Enumeração de subdomínio
- GitHub Dorking
- Shodan Dorking
- Google Dorking
- Teste de aplicação externa
- Familiarização com a arquitetura corporativa
Podemos enumerar os vários aplicativos (externos e internos) usados por uma empresa fazendo uma enumeração em escala de subdomínios. A escala da área de destino é simplesmente expandida aleatoriamente dependendo da organização ao enumerar subdomínios.
O código:Copiar para área de transferência
cat targetDomains.txt | while read -r domain; do
( echo $domain | subfinder -silent >>subdomains.txt );
done
Para listar subdomínios, eu pessoalmente uso o subfinder, que é integrado a muitas chaves de API. É sempre uma boa ideia pesquisar e verificar os subdomínios, sejam eles acessíveis pela Internet pública ou não. httpx faz todo o trabalho para mim.
cat subdomains.txt | httpx -silent -sc
Aqui encontrei muitos subdomínios nomeados para aplicativos da Web internos que não são acessíveis pela Internet pública. Mas a maioria deles está disponível. Então é hora de testar esses aplicativos.
Foi um trabalho tedioso testar aplicativos, a maioria deles eram estáticos para fins de marketing comercial. Quanto mais dinâmica a função, mais interessante ela se torna para nós. Nossa equipe descobriu muitas vulnerabilidades de aplicativos da Web em uma ampla área de destino. Pessoalmente, adoro testar SQLi, XML External Entity e Open Redirection para red team jobs.
Bem, há uma boa razão para procurar por esses bugs, porque a injeção SQL e a entidade externa XML são ataques baseados em injeção que ajudam um invasor a extrair informações confidenciais de um back-end/servidor que acessa dados em tempo real e é usado pela empresa. agora mesmo. Isso pode ser usado ainda mais para o movimento lateral na próxima fase. E no mundo da segurança cibernética de hoje, um redirecionamento aberto pode ser visto como um bug comum onde caçadores de bugs e plataformas o normalizaram. Mas as equipes vermelhas sabem o preço, porque pode ser usado para atrair a vítima para fora da empresa. As vítimas são facilmente levadas a essa ilusão porque o redirecionamento para nossa URL maliciosa vem de seu nome de domínio corporativo. A maioria dos funcionários não técnicos são passíveis de esta técnica. Existem muitas vulnerabilidades conhecidas na natureza, mas essas são as minhas favoritas a serem observadas e podem ser facilmente exploradas para maior interação.
Ao procurar por vulnerabilidades da Web, os membros de nossa equipe encontraram muitas injeções de SQL na área de destino. Comecei a agregar domínios e fuzzing manualmente para determinar qual banco de dados este servidor estava usando.
Quando se trata de injeção de SQL, sempre uso a folha de referência como referência - ` `https://portswigger.net/web-security/sql-injection/cheat-sheet
Alguns grupos específicos de sites usaram a mesma pilha de tecnologia para seus aplicativos da web. Eles usaram .NET para front-end, servidor IIS para hospedagem e MSSQL para back-end.
O código:Copiar para área de transferência
# Typical Enterprise Web Application Stack
Front End (.NET) <---> Server (IIS) <---> Back End (MSSQL)
Além disso, eles usaram aplicativos Wordpress e aplicativos PHP + MySQL que se comportam de maneira semelhante ao Wordpress, mas não são Wordpress.
Usei o sqlmap para despejar um banco de dados MySQL inteiro, e outros sites (incluindo o MSSQL, onde eles tinham um banco de dados compartilhado em sincronia com muitos aplicativos da web) tinham o Blind SQLi, que demorava mais para força bruta e despejo. Quando vi os nomes dos bancos de dados e tabelas, tive uma boa ideia de seus domínios internos e aplicativos da web internos.
O código:Copiar para área de transferência
#Fuzz for SQL Injection
sqlmap -r request.txt
#Specifying Database
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3
#Fuzzing Vulnerable Param
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -p <PARAM_NAME_VULNERABLE_TO_SQLi>
#Dump database names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --dbs
#Dump table names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --tables
#Dump all data from the given database & table
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -D <DB_NAME> -T <TABLE_NAME> --dump
O despejo do banco de dados era uma mina de ouro porque armazenava muitos IDs de e-mail e suas senhas (salvos em texto simples, o que é uma prática ruim).
Além de testar aplicativos da web, consegui muitos domínios internos públicos com seus endereços IP graças ao certificado SSL, que foi obtido com a ajuda de Shodan Dorking. Shodan também forneceu a porta RDP 3389 para sua empresa.
Por último, mas não menos importante, recebi algumas credenciais do GiHub Dorking, onde seus desenvolvedores internos escreveram alguns scripts para testar alguns dos recursos da API e os deixaram sem removê-los de seu git commit. Também recebi vários IDs de e-mail internos para os negócios deles.
Depois de usar alguns comandos grep e automação bash, escrevi essas credenciais do dump SQL e todos os dados que obtive usando dorks em um arquivo, agora havia 340 credenciais neste arquivo. Este é um número enorme e mostra que a instalação não está seguindo rígidos requisitos de segurança e medidas de mitigação. Então o que vem depois?
Antes de começar a usar essas credenciais, eu só queria tentar explorar outros subdomínios para outras possibilidades. Neste ponto, me deparei com o servidor MS Exchange de seu domínio. A página de login do OWA Portal (Outlook Web App Portal) estava lá e, quando a vi, fiquei muito intrigado. Como li muitos dos estudos de segurança que assino no Twitter, sei que um exploit chamado ProxyShell pode ser usado neste servidor. Existe um bom artigo da Orange Tsai sobre esta vulnerabilidade - ` https ://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part- 1.html`. Iniciei imediatamente o aplicativo OWA com Burpsuite e nossa versão do servidor Exchange no cabeçalho de resposta. Eu executei explorações públicas para esta versão, em particular esta (`https://github.com/horizon3ai/proxyshell `), um dos meus amigos que reproduziu esse exploit, me ajudou com sua opinião sobre o ataque. Mesmo que isso tenha me dado um shell, não consegui executar os comandos com sucesso. Eu sabia que algo estava errado e comecei a reproduzir o exploit manualmente usando Burp e meus próprios scripts Python. A partir disso, percebi que os IDs de e-mail no servidor Exchange eram uma toca de coelho para mim. O FQDN e os IDs de e-mail foram deliberadamente colocados dentro do servidor para atrair o jogador do Red Team (esta é a primeira vez que encontro a tática do Blue Team). Passei quase 4 dias testando esse exploit sozinho e finalmente a fé foi conquistada.
Eu me levanto depois de uma tentativa fracassada de cortar uma fruta que estava pendurada. Comecei a procurar outros subdomínios. Alguns sites me redirecionaram para a página de login SSO (logon único).
https://login.microsoftonline.com/getus … domain.com
Consultando o link acima, verifiquei que os domínios estão funcionando como um serviço felerativo para AD. Isso significa que eles estão conectados ao Microsoft Cloud (O365).
Agora é hora de usar as credenciais que preparei anteriormente. Comecei a pulverizar essas credenciais com o O365 Sprayer no domínio de destino. Apenas uma dessas credenciais funcionou. Foi um ponto de viragem para toda a interação da equipa vermelha. A senha usada para credenciais válidas é uma combinação simples usada pelo domínio.
É hora de franzir a testa. Usando essas credenciais, entrei como usuário em seu domínio usando o módulo Azure AD PowerShell. Para se conectar à nuvem do Azure, precisamos de uma ID de locatário de domínio.
https://login.microsoftonline.com/<T … figuration
Ao solicitar o link acima, obtemos a ID do locatário do domínio de destino como resposta. Usando essa ID de locatário para se conectar ao Azure AD.
Connect-AzureAD -TenantId <TENANT_ID>
Uma vez conectado ao Azure AD em nosso PowerShell, a enumeração se torna muito mais fácil com o módulo Azure AD PS. Liste usuários, grupos e dispositivos do Azure AD com `Get-AzureADUser -All $true` , `Get-AzureADGroup -All $true` , `Get-AzureADDevice -All $true` e muito mais. Get-AzureADDomain, podemos verificar o tipo de autenticação dos domínios conectados a ele.
Agora posso obter facilmente todos os IDs de e-mail usados no domínio dos usuários listados. Pensei em fazer um ataque de falsificação de senha de domínio devido à política de bloqueio de conta e ao período de recuperação. Depois de executar a pulverização de senha, quase 60 contas foram comprometidas devido a suas senhas fracas e previsíveis.
Usando essas credenciais, entrei no computador com o privilégio de usuário AD padrão. A máquina funcionou em modo limitado com alguns bugs (não avaliados) e produtos AV para um redtimer novato que sou. Comecei listando os processos e descobri que os seguintes produtos estavam rodando na máquina. Quando tentei assistir a alguns scripts ofensivos do PowerSHell no navegador, eles foram sinalizados como sites maliciosos. Percebi minha situação no momento em que percebi que estava prestes a pisar em uma mina.
Eu sabia que se colocasse algum executável no disco, isso me marcaria. E configurar o mesmo script EDR em minha máquina local e compilar esses binários levaria muito tempo, o que é um pesadelo para mim. Portanto, a memória do PowerShell é a única esperança para mim. Quando começo a baixar os scripts, extraio via PowerShell usando scripts do GitHub, ele marca esse arquivo. Mas se eu codificá-lo em Base64 e carregá-lo na memória do PowerShell, ele não será marcado.
O código:Copiar para área de transferência
# Store the Base64 encoded file
$file = <BASE64_ENCODED_CONTENT_FILE>
$data = Get-Content $file
[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($data)) | IEX
# Delete the Base64 encoded file
É isso, os scripts necessários foram carregados na memória do PowerShell sem serem interceptados (surpreendente para mim 🤪 ). Tentei elevar os privilégios locais, mas, para minha consternação, não havia nada para elevar.
Iniciei o Sharp Hound e transferi os dados resultantes para o meu computador local para visualização no BloodHound. Depois de carregar os dados recebidos (levou mais tempo para milhares de anúncios), comecei a revisá-los e analisá-los cuidadosamente. Sempre procure ACLs de saída porque elas são um link oculto entre dois objetos do AD. Alguns dos usuários comprometidos tiveram uma sessão PS em algumas máquinas. Usei suas contas para obter a sessão PS e comecei a listar os privilégios.
Surpreendentemente, alguns usuários tinham privilégios totais em seus respectivos computadores. Aproveitei esse privilégio para despejar LSASS.exe de procdump.exe . Esta é uma maneira oculta de redefinir o LSASS.exe , pois o procdump.exe é um binário assinado pela Microsoft e não está marcado com AV/EDRs.
Depois de mover esse arquivo .dmp para minha máquina local, executei o Mimikatz para analisar o arquivo de despejo e obtive um hash NTLM para um usuário que é membro de um grupo privilegiado. Não tenho direitos de administrador local em minha máquina monitorada. Como resultado, só preciso "Passar hash" pela sessão PS. Um colega meu me ajudou a escrever um invólucro reverso indetectável em Go. Copiamos esse binário para um computador remoto com uma sessão PS e tentamos PTH com Invoke-Mimikatz para executar um shell reverso com PowerCat. Obviamente começou e obtivemos direitos de usuário de grupo privilegiado, mas paramos devido a um problema. Estávamos dentro de um firewall, então não podíamos solicitar diretamente a um controlador de domínio para seguir em frente. Coitada, eu não sabia que eu tenho uma senha de texto simples para o mesmo usuário no dump. Vendo como fiquei animado depois de experimentar o invólucro reverso PTH.
Além disso, para o usuário ao qual tive meu acesso inicial, consegui alterar a senha de uma conta com direitos ACL. Consegui visualizar a senha do LAPS por meio de AllExtendedRights no computador depois de usar a conta alterada de senha. Infelizmente, trabalhar com esta máquina era uma perda de tempo.
O BloodHound mostrou que o usuário comprometido do despejo LSASS tinha uma sessão em um computador onde um dos administradores de domínio também tinha uma sessão. Usando essa senha de texto simples, fiz um movimento lateral com propriedade e despejei LSASS com procdump.exe novamente. Desta vez, recebi uma senha de texto simples para o administrador do domínio. Depois de fazer login no DC, redefino o arquivo NTDS.dit e as seções do registro.
É isso, o confronto final. Adicionei minhas contas de salvamento necessárias e despejei todos os hashes da empresa de destino usando secretsdump.
O código:Copiar para área de transferência
aidenpearce369@jackdaw:~/DC5-LSASSDump$ ls
RegHive allHashes.txt log.dmp ntds.dit
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep -v "$:" | wc -l
43856
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep "$:" | wc -l
48587
aidenpearce369@jackdaw:~/DC5-LSASSDump$
Do despejo, obtive 43.856 hashes de conta de usuário e 48.587 hashes de conta de computador da empresa. Durante essas reuniões, também aprendi algumas técnicas de enumeração e travessia de EDR com um colega. Foi meu primeiro time vermelho e foi muito legal para mim. Porque durante esses muitos dias tentei operar em um ambiente deliberadamente vulnerável, mas nesta missão tive a oportunidade de simular uma ameaça ofensiva invadindo uma empresa que era completamente nova para mim. Para minhas atribuições futuras, pretendo escrever meu próprio trabalho em C# e Go para evitar a detecção e aprender mais sobre os componentes internos do Windows para contornar o EDR e explorar o desenvolvimento. Sou grato àqueles que me ajudaram durante minhas dificuldades e me ajudaram a subir um degrau mais alto em meu aprendizado. Gostaria de encerrar esta postagem no blog dizendo que 2022 foi um ótimo ano para mim em termos de realização e auto-satisfação. E para quem leu este post:nunca pare de explorar.