SOC Prime Bias: Alto

13 Feb 2026 14:05 UTC

Desentrañando OysterLoader: Dentro de un Cargador de Evasión en Múltiples Etapas

Author Photo
Ruslan Mikhalov Chief of Threat Research at SOC Prime linkedin icon Seguir
Desentrañando OysterLoader: Dentro de un Cargador de Evasión en Múltiples Etapas
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Resumen

OysterLoader es un cargador de etapas múltiples en C++ utilizado para desplegar ransomware y malware común como Vidar. Se propaga a través de sitios comprometidos que imitan instaladores de software legítimos y se entrega como un Instalador de Microsoft (MSI). Para complicar el análisis, utiliza inundación de llamadas API, resolución de API dinámica personalizada, comprobaciones anti-depuración y una rutina de descompresión personalizada LZMA. El cargador se comunica con una infraestructura C2 HTTPS jerarquizada usando encabezados HTTP ofuscados y una codificación propia similar a Base64.

Investigación

El informe describe cuatro etapas: un ofuscador empaquetado (TextShell), una capa de shellcode que infla el contenido con LZMA, un descargador que realiza chequeos de entorno y crea un mutex, y una etapa final que suelta un DLL e instala una tarea programada. El tráfico C2 depende de IPs/dominios codificados, user-agents personalizados y entrega de cargas útiles esteganográficas a través de iconos PNG. La persistencia se mantiene mediante una tarea programada configurada para ejecutarse cada 13 minutos.

Mitigación

Bloquee los instaladores MSI no firmados de fuentes no confiables y monitoree la creación de patrones de mutex conocidos. Alerta sobre patrones de nombres de tareas programadas y el uso de rundll32.exe para cargar DLLs desde %APPDATA%. Donde sea posible, aplique inspección de TLS para identificar los encabezados HTTP personalizados y user-agents utilizados por el cargador.

Respuesta

Si se detecta, aisle el host, termine la tarea programada y elimine el archivo COPYING3.dll soltado. Busque cargas útiles adicionales, enumere procesos que coincidan con los valores de mutex, bloquee los dominios/IPs C2 listados y actualice las detecciones para el comportamiento de inundación de API y la codificación Base64 personalizada.

Flujo de Ataque

Ejecución de Simulación

Prerrequisito: El Chequeo de Telemetría y Línea Base debe haber sido aprobado.

Justificación: Esta sección detalla la ejecución precisa de la técnica adversario (TTP) diseñada para activar la regla de detección. Los comandos y la narrativa DEBEN reflejar directamente los TTPs identificados y apuntar a generar la telemetría exacta esperada por la lógica de detección. Ejemplos abstractos o no relacionados llevarán a un diagnóstico erróneo.

  • Narrativa del Ataque y Comandos:
    El adversario, habiendo ganado acceso inicial en el punto final, despliega la carga útil OysterLoader.

    1. Registro de DLL vía Rundll32 – El cargador copia un DLL malicioso (COPYING3.dll) en el directorio temporal y lo registra usando rundll32.exe con el DllRegisterServer punto de entrada, produciendo una línea de comandos que coincide con selección1.
    2. Chequeo Anti‑Debug – Para evadir análisis, la carga utiliza ntdll.dll y llama a IsDebuggerPresent. Esto genera un registro de proceso donde Imagen contiene ntdll.dll y la línea de comandos incluye IsDebuggerPresent, satisfaciendo selección2.
    3. Asignación de Memoria – Para ejecución en memoria, el cargador invoca NtAllocateVirtualMemory via ntdll.dll. El evento de creación de proceso resultante contiene NtAllocateVirtualMemory en la línea de comandos, satisfaciendo selección3.
  • Script de Prueba de Regresión:

    # Script de validación de detección de OysterLoader – PowerShell
    # ----------------------------------------------------
    # 1. Crear un DLL malicioso ficticio (archivo vacío para simulación)
    $dllPath = "$env:TEMPCOPYING3.dll"
    New-Item -Path $dllPath -ItemType File -Force | Out-Null
    
    # 2. Activar selección1 – rundll32 con DllRegisterServer
    Write-Host "Ejecutando selección1 (registro de DLL de rundll32)..."
    Start-Process -FilePath "rundll32.exe" -ArgumentList "`"$dllPath`" DllRegisterServer" -NoNewWindow
    
    # 3. Activar selección2 – ntdll con IsDebuggerPresent
    Write-Host "Ejecutando selección2 (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. Activar selección3 – ntdll con NtAllocateVirtualMemory
    Write-Host "Ejecutando selección3 (NtAllocateVirtualMemory)..."
    $scriptBlock2 = {
        Add-Type -MemberDefinition @"
            [DllImport("ntdll.dll", SetLastError = true)]
            public static extern int NtAllocateVirtualMemory(
                IntPtr HandleProceso,
                ref IntPtr DirecciónBase,
                IntPtr ZeroBits,
                ref UIntPtr TamañoRegión,
                uint TipoAsignación,
                uint Proteger);
    "@ -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
    
    # Limpieza
    Remove-Item -Path $dllPath -Force
    Write-Host "Simulación completada."
  • Comandos de Limpieza:

    # Asegúrese de que cualquier proceso rundll32 o trabajo persistente se termine
    Get-Process -Name "rundll32" -ErrorAction SilentlyContinue | Stop-Process -Force
    Get-Job | Remove-Job -Force
    # Eliminar el DLL temporal si aún está presente
    $tempDll = "$env:TEMPCOPYING3.dll"
    if (Test-Path $tempDll) { Remove-Item $tempDll -Force }