SOC Prime Bias: Alto

13 Feb 2026 14:05 UTC

OysterLoader Revelado: Dentro de um Carregador de Evasão em Múltiplos Estágios

Author Photo
Ruslan Mikhalov Chief of Threat Research at SOC Prime linkedin icon Seguir
OysterLoader Revelado: Dentro de um Carregador de Evasão em Múltiplos Estágios
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Resumo

OysterLoader é um carregador de múltiplas etapas em C++ usado para implantar ransomware e malwares comuns como o Vidar. Ele se espalha por meio de sites comprometidos que imitam instaladores de software legítimos e é entregue como um Instalador da Microsoft (MSI). Para complicar a análise, ele usa inundação de chamadas de API, resolução dinâmica de API personalizada, verificações anti-debug e uma rotina de descompressão LZMA personalizada. O carregador se comunica com uma infraestrutura C2 HTTPS em camadas usando cabeçalhos HTTP ofuscados e uma codificação proprietária semelhante ao Base64.

Investigação

O relatório descreve quatro etapas: um ofuscador compactado (TextShell), uma camada de shellcode que infla o conteúdo com LZMA, um downloader que realiza verificações de ambiente e cria um mutex, e uma etapa final que solta uma DLL e instala uma tarefa agendada. O tráfego C2 depende de IPs/domínios codificados, agentes-usuário personalizados e entrega esteganográfica de payload por meio de ícones PNG. A persistência é mantida por uma tarefa agendada configurada para ser executada a cada 13 minutos.

Mitigação

Bloqueie instaladores MSI não assinados de fontes não confiáveis e monitore a criação de padrões de mutex conhecidos. Alerta sobre padrões de nomes de tarefa agendada e o uso de rundll32.exe para carregar DLLs de %APPDATA%. Quando viável, aplique inspeção TLS para identificar os cabeçalhos HTTP personalizados e agentes-usuário usados pelo carregador.

Resposta

Se detectado, isole o host, termine a tarefa agendada e remova o arquivo COPYING3.dll descartado. Caçar por cargas adicionais, enumerar processos que correspondam aos valores de mutex, bloquear os domínios/IPs de C2 listados e atualizar as detecções para o comportamento de inundação de API e a codificação Base64 personalizada.

Fluxo de Ataque

Execução de Simulação

Pré-requisito: A Verificação Prévia de Telemetria & 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 levarão a diagnósticos incorretos.

  • Narrativa & Comandos do Ataque:
    O adversário, tendo ganho uma posição inicial no endpoint, implanta a payload do OysterLoader.

    1. Registro de DLL via Rundll32 – O carregador copia uma DLL maliciosa (COPYING3.dll) no diretório temporário e a registra usando rundll32.exe com o DllRegisterServer ponto de entrada, produzindo uma linha de comando que corresponde a seleção1.
    2. Verificação Anti-Debug – Para evadir a análise, a payload carrega ntdll.dll e chama IsDebuggerPresent. Isso gera um registro de processo onde Imagem contém ntdll.dll e a linha de comando inclui IsDebuggerPresent, satisfazendo seleção2.
    3. Alocação de Memória – Para execução na memória, o carregador invoca NtAllocateVirtualMemory via ntdll.dll. O evento resultante de criação de processo contém NtAllocateVirtualMemory na linha de comando, satisfazendo seleção3.
  • Script de Teste de Regressão:

    # Script de validação de detecção do OysterLoader – PowerShell
    # ----------------------------------------------------
    # 1. Criar uma DLL maliciosa de teste (arquivo vazio para simulação)
    $dllPath = "$env:TEMPCOPYING3.dll"
    New-Item -Path $dllPath -ItemType File -Force | Out-Null
    
    # 2. Acionar seleção1 – rundll32 com DllRegisterServer
    Write-Host "Executando seleção1 (registro DLL com rundll32)..."
    Start-Process -FilePath "rundll32.exe" -ArgumentList "`"$dllPath`" DllRegisterServer" -NoNewWindow
    
    # 3. Acionar seleção2 – ntdll com IsDebuggerPresent
    Write-Host "Executando seleção2 (IsDebuggerPresent)..."
    $scriptBlock = {
        Add-Type -MemberDefinition @"
            [DllImport("ntdll.dll", SetLastError = true)]
            public static extern bool IsDebuggerPresent();
    "@ -Namespace WinAPI -Name NativeMethods
        [WinAPI.NativeMethods]::IsDebuggerPresent() | Out-Null
    }
    Start-Job -ScriptBlock $scriptBlock | Wait-Job | Receive-Job
    
    # 4. Acionar seleção3 – ntdll com NtAllocateVirtualMemory
    Write-Host "Executando seleção3 (NtAllocateVirtualMemory)..."
    $scriptBlock2 = {
        Add-Type -MemberDefinition @"
            [DllImport("ntdll.dll", SetLastError = true)]
            public static extern int NtAllocateVirtualMemory(
                IntPtr ProcessHandle,
                ref IntPtr BaseAddress,
                IntPtr ZeroBits,
                ref UIntPtr RegionSize,
                uint AllocationType,
                uint Protect);
    "@ -Namespace WinAPI -Name NativeMethods
        $process = [System.Diagnostics.Process]::GetCurrentProcess()
        $handle = $process.Handle
        $base = [IntPtr]::Zero
        $size = [UIntPtr]::Zero
        [WinAPI.NativeMethods]::NtAllocateVirtualMemory($handle, [ref]$base, [IntPtr]::Zero, [ref]$size, 0x1000, 0x04) | Out-Null
    }
    Start-Job -ScriptBlock $scriptBlock2 | Wait-Job | Receive-Job
    
    # Limpeza
    Remove-Item -Path $dllPath -Force
    Write-Host "Simulação concluída."
  • Comandos de Limpeza:

    # Garantir que quaisquer processos remanescentes de rundll32 ou tarefas sejam terminados
    Get-Process -Name "rundll32" -ErrorAction SilentlyContinue | Stop-Process -Force
    Get-Job | Remove-Job -Force
    # Excluir DLL temporária se ainda presente
    $tempDll = "$env:TEMPCOPYING3.dll"
    if (Test-Path $tempDll) { Remove-Item $tempDll -Force }