SOC Prime Bias: High

01 Jul 2026 06:50 UTC

LokiBot Depois de uma Década: Análise de uma Campanha Recente

Author Photo
SOC Prime Team linkedin icon Seguir
LokiBot Depois de uma Década: Análise de uma Campanha Recente
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Resumo

LokiBot é um infostealer de longa data construído para coletar credenciais de navegadores, carteiras de criptomoedas e outras aplicações sensíveis. Esta campanha recente baseia-se em uma cadeia de execução em várias etapas que começa com um anexo JScript ofuscado entregue através de malspam. O malware utiliza injeção de processo e hashing de API para reduzir a visibilidade enquanto envia os dados roubados para sua infraestrutura de comando e controle.

Investigação

A investigação examinou uma amostra de LokiBot em várias etapas e rastreou sua progressão de um anexo JScript para um carregador PowerShell, depois para um injetor .NET, e finalmente para o payload de LokiBot. Os analistas identificaram o uso de proteção ConfuserEx, descriptografia baseada em XOR e técnicas de carregamento reflexivo ao longo da cadeia. O estudo também descreveu a abordagem personalizada de hashing de API do malware e um método falho de persistência baseado em registro.

Mitigação

As organizações devem implementar um forte filtro de e-mails para bloquear anexos JScript maliciosos e malspam antes da entrega. Monitorar processos filhos suspeitos gerados pelo wscript.exe and powershell.exe também é essencial. Além disso, restringir a execução de assemblies .NET não confiáveis e observar alterações incomuns nas chaves de execução do Windows pode ajudar a reduzir a exposição.

Resposta

Se LokiBot for detectado, isole imediatamente o endpoint afetado para interromper o roubo de dados e a comunicação de comando e controle. Os investigadores devem realizar uma análise forense para determinar o ponto de entrada original e avaliar o alcance da violação de credenciais. Todas as contas acessadas a partir do host infectado devem passar por uma redefinição completa de senha, e o ambiente deve ser verificado para arquivos JScript e PowerShell relacionados.

Fluxo de Ataque

Detecções

Possíveis Pontos de Persistência [ASEPs – Software/NTUSER Hive] (via evento de registro)

Equipe SOC Prime
26 de jun de 2026

A Possibilidade de Execução Através de Linhas de Comando PowerShell Ocultas (via cmdline)

Equipe SOC Prime
26 de jun de 2026

LOLBAS WScript / CScript (via criação de processo)

Equipe SOC Prime
26 de jun de 2026

Strings PowerShell Suspeitas (via powershell)

Equipe SOC Prime
26 de jun de 2026

Comunicação LokiBot C2 via Requisição HTTP [Conexão de Rede do Windows]

Regras de IA SOC Prime
26 de jun de 2026

Detecção de Injeção de Processo LokiBot via aspnet_compiler.exe [Criação de Processo do Windows]

Regras de IA SOC Prime
26 de jun de 2026

Detectar Execução LokiBot via Script PowerShell Base64 e Carregamento de Assembly .NET [PowerShell do Windows]

Regras de IA SOC Prime
26 de jun de 2026

Execução de Simulação

Pré-requisito: O Check de Pré-voo de Telemetria e Linha de Base deve ter passado.

Justificativa: Esta seção detalha a execução precisa da técnica do adversário (TTP) projetada para acionar a regra de detecção. Os comandos e a narrativa DEVEM refletir diretamente os TTPs identificados e visam gerar a telemetria exata esperada pela lógica de detecção. Exemplos abstratos ou não relacionados resultarão em diagnóstico incorreto.

  • Narrativa de Ataque & Comandos: O adversário obteve acesso inicial com sucesso via arquivo JScript. Para evitar a liberação de um .dll detectável no disco, eles executam um comando PowerShell que contém uma string codificada em Base64. Este script, uma vez decodificado, utiliza a .NET Reflection capacidade de chamar [System.Reflection.Assembly]::Load para puxar um payload malicioso diretamente para a memória do processo atual. Esta abordagem “sem arquivo” é uma característica marcante do LokiBot.

  • Script de Teste de Regressão:

    # Script de Simulação LokiBot
    # Este script é projetado para corresponder exatamente às strings definidas na regra de detecção.
    
    # 1. Simular o componente Base64
    $encodedCommand = "Script PowerShell codificado em Base64"
    $dummyPayload = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("DummyPayload"))
    
    # 2. Simular o componente de Carregamento de Assembly usando a string exata da regra de detecção
    # Usamos um try/catch porque isso é uma simulação e o "payload" não é um assembly real.
    try {
        Write-Host "Executando estágio codificado..."
        Write-Output $encodedCommand
    
        # Esta linha é o principal gatilho para a regra de detecção
        $trigger = "[System.Reflection.Assembly]::Load"
        Write-Host "Tentando carregar assembly via: $trigger"
    
        # Chamamos isso via Invoke-Expression para garantir que apareça no ScriptBlockText
        Invoke-Expression "Write-Host 'Acionando: $trigger'"
    }
    catch {
        Write-Error "Falha na simulação ao executar a string de gatilho."
    }
  • Comandos de Limpeza:

    # Nenhuma alteração permanente é feita pelo script de simulação.
    # Simplesmente limpando o console e garantindo que não existam processos remanescentes.
    Clear-Host
    Write-Host "Limpeza da simulação completa. Nenhum arquivo foi liberado."