Inside Vidar 2026: From Infection to Memory Execution

Summary

The report examines how Vidar has evolved into a multi-stage, fileless attack framework that combines Go-based loaders, VBS, PowerShell, and living-off-the-land binaries to retrieve malicious content concealed inside JPEG and TXT files hosted on a remote IP address. The embedded payloads are extracted, decoded, and executed directly in memory through RegAsm.exe, avoiding disk-based detection. Initial access is delivered through social-engineering lures such as fake GitHub repositories, compromised WordPress sites, and fake CAPTCHA pages. The campaign also relies on Telegram and Cloudflare-fronted domains for command-and-control and data exfiltration.

Investigation

Point Wild researchers traced the full infection chain from the initial Go-compiled dropper to the final Vidar payload, documenting each layer of obfuscation along the way. Their analysis highlighted the use of custom Base64 markers, reversed strings, and reflective .NET assembly loading to conceal execution. The researchers also described how WScript, PowerShell, and RegAsm.exe were abused as execution proxies, enabling the malware to decode and launch a hidden DLL entirely in memory. Network traffic further confirmed HTTP-based retrieval of staged JPEG and TXT payloads from a hard-coded IP address.

Mitigation

Defenders should focus on detecting the early VBS and PowerShell stages of the infection chain, including suspicious use of RegAsm.exe, retrieval of JPEG or TXT files from the malicious IP, and recognizable Base64 marker patterns. Blocking known malicious domains and IP addresses, monitoring outbound traffic to Telegram, and applying execution controls to common LOLBin utilities can help reduce exposure. Behavior-based detection tuned for fileless execution and in-memory loading techniques is also strongly recommended.

Response

If indicators tied to the Vidar infection chain are identified, isolate the affected host immediately, terminate suspicious processes such as WScript, PowerShell, and RegAsm.exe, and collect memory images for forensic review. The identified IP address and related domains should be blocked, and any startup shortcuts or scheduled tasks used for persistence should be removed. Security teams should also conduct a full credential review focused on exposed browser data, extensions, and cryptocurrency wallets.

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:

  1. Initial Dropper (WScript): The attacker delivers a malicious JScript file (payload.js) that is launched via WScript.exe. The script downloads a base64‑encoded PowerShell payload from a C2 server and writes it to %TEMP%.
  2. PowerShell Stage: The downloaded payload is executed with -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden, performs reflective DLL loading (T1620) of a malicious .NET assembly (evil.dll) into memory, and drops the assembly to disk.
  3. RegAsm Proxy: To evade native PowerShell detection, the attacker invokes RegAsm.exe pointing at evil.dll with the /codebase switch, causing the .NET loader to execute the malicious entry point (T1574.014).

  The chain creates three distinct Sysmon events—each matching the rule’s Image|endswith selector—thereby firing the alert.

• Regression Test Script: The script below reproduces the above chain in a safe, sandboxed manner by using harmless echo commands and a dummy DLL (a simple text file) to avoid real malicious activity while still generating the same process‑creation events.

  <#  
  Vidar‑style multi‑stage execution simulation  
  - Stage 1: WScript launches a JScript that writes a PowerShell script to %TEMP%  
  - Stage 2: PowerShell runs the script, creates a dummy DLL, and launches RegAsm  
  #>
  
  # ---------- Stage 1: WScript ----------
  $jsPath = "$env:TEMPstage1.js"
  $psPayloadPath = "$env:TEMPstage2.ps1"
  $dummyDllPath = "$env:TEMPevil.dll"
  
  # JScript that writes a simple PowerShell payload to disk
  $jsContent = @"
  var fso = new ActiveXObject("Scripting.FileSystemObject");
  var ts = fso.OpenTextFile("$psPayloadPath", 2, true);
  ts.WriteLine('Write-Host "[Stage 2] PowerShell executed"');
  ts.WriteLine('Set-Content -Path "$dummyDllPath" -Value "This is a dummy DLL"');
  ts.WriteLine('Start-Process -FilePath "$env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" -ArgumentList "`"$dummyDllPath`" /codebase" -NoNewWindow');
  ts.Close();
  "@
  
  Set-Content -Path $jsPath -Value $jsContent -Encoding ASCII
  
  # Execute the JScript via WScript
  Write-Host "`n[Stage 1] Launching WScript..."
  & "$env:SystemRootSystem32WScript.exe" $jsPath
  
  # ---------- Stage 2: PowerShell ----------
  Write-Host "`n[Stage 2] Executing generated PowerShell payload..."
  & powershell.exe -NoProfile -ExecutionPolicy Bypass -File $psPayloadPath
  
  # ---------- Cleanup ----------
  Write-Host "`nCleaning up temporary files..."
  Remove-Item -Path $jsPath, $psPayloadPath, $dummyDllPath -Force -ErrorAction SilentlyContinue

• Cleanup Commands: In addition to the cleanup at the end of the script, run the following to ensure no lingering processes or files remain.

  # Force‑terminate any stray RegAsm or PowerShell instances spawned by the test
  Get-Process -Name regasm, powershell -ErrorAction SilentlyContinue | Stop-Process -Force
  
  # Remove any residual files in %TEMP% that match the test pattern
  Get-ChildItem -Path $env:TEMP -Filter "stage*.*" -File | Remove-Item -Force