Vidar Stealer Detection 2026: YARA Rules, C2 Signatures, and Post-Compromise Credential Checklist

Vidar Stealer 2.0, released on October 6, 2025 by the developer known as “Loadbaks,” has re-emerged as one of the four dominant infostealer families following the May 2025 disruption of Lumma Stealer and the takedown of Rhadamanthys. Security teams relying on pre-2025 Vidar signatures are exposed: the 2.0 release is a near-complete rewrite in C with a polymorphic build system, Dead Drop Resolver C2 infrastructure, and expanded targeting that now includes Azure MSAL token caches and over 200 browser extensions. This guide covers current YARA rules, network-level detection signatures, and the exact credential rotation checklist to execute after a confirmed infection.

Background: Vidar’s Position After the 2025 Takedowns

The May 2025 Lumma Stealer disruption and Rhadamanthys takedown created a vacuum that Vidar moved quickly to fill. By early 2026, four families share the active infostealer market: LummaC2 (which recovered to operational capacity), ACRStealer, StealC, and Vidar. Flare Research’s February 2026 report found that 1 in 5 infostealer infections now yield enterprise credentials — up from roughly 1 in 10 in 2024. IBM X-Force tracked over 16 million infected devices across infostealer families during 2025, with enterprise identity exposure doubling from approximately 6% to 14% in 12 months.

Vidar is no longer a consumer-only commodity tool. Recent campaigns explicitly target VPN credentials, Azure service principal tokens, and corporate SaaS accounts, making it a direct precursor to ransomware deployment and business email compromise. Each compromised device yielded an average of 87 stolen credentials in 2025 campaigns; 31% of those included active session cookies that bypass MFA until explicitly revoked.

How Vidar 2.0 Works

The original Vidar was written in C++. Vidar 2.0 is a full rewrite in C, eliminating the C++ runtime artifacts that many signature-based tools targeted. The polymorphic builder generates a structurally distinct code layout for every compiled sample — the developers claim this defeats static signature detection automatically across all 274 internal functions.

C2 Infrastructure: Dead Drop Resolver

Rather than hardcoding C2 addresses, Vidar 2.0 uses a Dead Drop Resolver (DDR) pattern:

1. The binary embeds a reference to a Steam community profile (e.g., steamcommunity[.]com/profiles/76561199686524322) or a Telegram channel (e.g., t[.]me/k0mono).
2. On execution, the malware fetches the profile page and parses the description field for the active C2 address.
3. The operator updates the Steam or Telegram content to rotate C2 IPs without recompiling the binary.

One analyzed sample resolved through a Steam DDR to the subdomain gz.technicalprorj[.]xyz, then to the actual C2 at gpu.orca-trade[.]com. Known Vidar infrastructure includes: vidars[.]su, true-v[.]top, v-new[.]cloud, my-vidar[.]ru, and vidmn[.]top.

Execution Chain

Current campaigns deliver Vidar via three primary vectors:

• Fake software downloads: YouTube and Reddit lures pushing trojanized NeoHub installers, cracked tools, and game cheats hosted on GitHub.
• Compromised WordPress ClickFix pages: Fake CAPTCHA prompts trigger mshta.exe or powershell.exe execution chains delivering the payload (documented by Malwarebytes in March 2026).
• JPEG/TXT payload staging: A first-stage loader retrieves a payload hidden inside a JPEG or TXT file hosted on an IP-only server, then reverses it, Base64-decodes it, and executes it entirely in memory.

Once running, Vidar modifies Windows Defender exclusion list entries via registry write, then waits on a named mutex before launching powershell.exe -Verb RunAs to escalate privileges. Process injection targets dllhost.exe (created suspended via NtCreateSection, NtMapViewOfSection, NtQueueApcThread syscalls), RegAsm.exe, and MSBuild.exe. Browser credentials are extracted by spawning the browser with remote debugging enabled and injecting shellcode or a reflective DLL into the running process.

Anti-Analysis Checks

Vidar 2.0 terminates immediately on detecting any of the following conditions:

• IsDebuggerPresent() or CheckRemoteDebuggerPresent() returns true
• NtQueryInformationProcess(ProcessDebugPort) returns value 7
• System uptime falls below sandbox thresholds
• Virtualization or hardware profiling indicates an analysis environment

All 274 functions use state machine obfuscation with computed jumps gated by magic numbers. Key values:

What Vidar Steals

Vidar 2.0 targets a broader credential surface than its predecessor:

• Browser credentials: Chrome, Edge, Firefox, Opera, Vivaldi, Waterfox, Pale Moon. Chrome v20+ data is decrypted using BCryptOpenAlgorithmProvider with AES-256-GCM (ChainingModeGCM).
• Cryptocurrency wallets: 50+ targets including IndexedDB-based wallets (0.indexeddb.leveldb) and Monero wallet files.
• Azure MSAL token cache: A dedicated function at offset 0x14003fa19 reads %LOCALAPPDATA%\.IdentityService\msal.cache — this grants access to Azure resources without a password and persists until the token is explicitly revoked.
• Azure CLI config: %USERPROFILE%\.azure via function at offset 0x14003eaf4.
• AWS authentication caches
• 2FA applications: Authy, Google Authenticator, EOS Authenticator
• 200+ browser extensions (data beyond stored passwords)
• Email clients: Outlook (via the HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\... registry path), The Bat!
• Session cookies: Because these remain valid until server-side revocation, a stolen cookie grants access to authenticated sessions regardless of any subsequent password change.

Vidar Stealer Detection: YARA Rules and Host Indicators

YARA Rules

The following rules cover current Vidar 2.0 samples. Vidar_MSEdgeDLL_Oct2025 targets the specific loader artifact from the fake NeoHub campaign identified in October 2025:

rule Vidar_Stealer_2026 {
    meta:
        description = "Detects Vidar Stealer 2.0 via library imports and target string patterns"
        author      = "CiphersSecurity"
        date        = "2026-04-30"
        reference   = "https://github.com/Fmk0/yara/blob/master/Vidar.yar"

    strings:
        $lib1 = "nss3.dll"        ascii
        $lib2 = "msvcp140.dll"    ascii
        $lib3 = "mozglue.dll"     ascii
        $lib4 = "freebl3.dll"     ascii
        $lib5 = "vcruntime140.dll" ascii
        $lib6 = "softokn3.dll"   ascii
        $s1   = "Versions: %s"   ascii
        $s2   = "files\\Soft\\Authy" ascii
        $s3   = "The Bat!"        ascii
        $mz   = { 4D 5A }

    condition:
        $mz at 0 and 4 of ($lib*) and 2 of ($s*)
}

rule Vidar_MSEdgeDLL_Oct2025 {
    meta:
        description = "Detects msedge_elf.dll loader used in Vidar 2.0 fake NeoHub campaign"
        date        = "2026-04-30"

    strings:
        $dll  = "msedge_elf.dll"              ascii
        $path = "C:\\ProgramData\\HJJDGHCBGDHI\\" ascii

    condition:
        all of them
}

For ongoing coverage, VMRay released 300+ fresh YARA rules for Vidar throughout 2025–2026 targeting implementation patterns — multithreading, DPAPI call sequences, deobfuscation routines — that persist across polymorphic builds. Check the ThreatFox IOC feed for current sample hashes.

Host-Based Indicators

File system:
– C:\ProgramData\HJJDGHCBGDHI\ — staging folder with randomized filenames; presence of this directory is high-confidence
– msedge_elf.dll loaded from outside a browser installation directory

Registry:
– Read access to C:\Windows\System32\config\SOFTWARE
– Outlook profile export key: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\
– Defender exclusion write: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\

Process behavior:
– RegAsm.exe or MSBuild.exe spawned outside of a Visual Studio or CI build context
– dllhost.exe created in a suspended state and then resuming with injected memory sections
– powershell.exe -Verb RunAs launched from a non-administrative, non-interactive parent

Network-Level Detection

Dead Drop Resolver Traffic

A non-browser process making HTTPS requests to steamcommunity.com/profiles/ is anomalous. Any process in %TEMP%, %APPDATA%, or C:\ProgramData\ fetching Steam profile pages or Telegram channel content should trigger an immediate alert. The same applies to outbound requests to Telegram’s API (api.telegram.org) from processes that are not a recognized Telegram client.

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Vidar DDR - Non-browser Steam profile fetch";
    http.uri; content:"/profiles/"; startswith;
    http.host; content:"steamcommunity.com";
    sid:9100001; rev:1;
)

alert http $HOME_NET any -> $EXTERNAL_NET 9000 (
    msg:"Vidar C2 - Direct-IP POST on port 9000";
    http.method; content:"POST";
    sid:9100002; rev:1;
)

C2 Communication Signatures

Vidar sends TLS-encrypted HTTP POST requests using multipart/form-data with three fields present in every request: token (bot identifier), build_id (campaign identifier), and mode (operation stage). The WinINet API call sequence is:

InternetCrackUrlA
→ InternetConnectA
→ HttpOpenRequestA
→ InternetSetOptionA  (×3, with 120-second timeouts)
→ HttpAddRequestHeadersA
→ HttpSendRequestA
→ HttpQueryInfoA
→ InternetReadFile    (1 KB chunks)
→ InternetCloseHandle

Detecting this exact WinINet sequence from a non-browser process — particularly with 120-second timeout values — is a reliable behavioral indicator.

Known IOCs (April 2026)

Post-Compromise Credential Checklist

The window between credential exfiltration and active exploitation is typically 24–72 hours. Credentials are sold to initial access brokers within hours of collection. Execute this checklist in order.

Immediate (0–4 hours):

1. Isolate the infected host from the network before beginning any cleanup — lateral movement may already be underway.
2. Acquire a full memory dump and disk image for forensic analysis before wiping. Preserve C:\ProgramData\HJJDGHCBGDHI\, registry hive exports, browser database files, and Windows Event, PowerShell, and Sysmon logs.
3. Revoke active sessions in your identity provider (Okta, Azure AD, Entra ID, Google Workspace) before resetting passwords. Session cookies stolen by Vidar remain valid until explicitly invalidated server-side — a password reset alone does not invalidate them.
4. Force sign-out of all active sessions for the affected user across Microsoft 365, AWS console, GitHub, and every SaaS platform for which browser-saved credentials existed.

Credentials and tokens to rotate:
– All browser-saved passwords (treat every stored credential as compromised — do not attempt to triage which passwords “might” have been accessed)
– OAuth refresh tokens and access tokens for all connected applications
– Azure service principal secrets; manually delete and reissue the MSAL cache at %LOCALAPPDATA%\.IdentityService\msal.cache
– AWS access keys and session tokens; rotate IAM credentials and audit CloudTrail for anomalous API calls
– SSH private keys accessible from the infected host
– VPN client certificates or pre-shared keys
– 2FA backup codes — revoke and re-enroll all TOTP and hardware tokens
– Cryptocurrency wallet seed phrases — assume immediate fund transfer risk; move assets before rotating if possible

Detection and monitoring (4–48 hours):

1. Create SIEM detection rules for RegAsm.exe and MSBuild.exe spawned outside build pipeline context, and for dllhost.exe process injection patterns.
2. Search endpoint telemetry for writes to HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\ from non-administrative management tooling.
3. Enable dark web monitoring for the affected user’s email address and corporate domain.
4. Review Azure sign-in logs and Entra ID audit logs for token replay attempts — look for sign-ins from IPs not associated with the user’s normal locations within the 72-hour post-infection window.

Extended (48 hours+):

1. Audit browser extension permissions across the same network segment — Vidar targets 200+ extensions and an infected host may have harvested extension data usable for pivoting.
2. Update conditional access policies: block legacy authentication endpoints and enforce phishing-resistant MFA (FIDO2/WebAuthn) for all privileged accounts.
3. Brief affected users: credential stuffing and targeted BEC attempts typically follow within two weeks of a confirmed infostealer infection. Advise them to report unexpected MFA prompts or account recovery emails immediately.

Conclusion

Vidar 2.0’s rewrite in C, polymorphic build infrastructure, and Dead Drop Resolver C2 pattern make it meaningfully harder to detect than earlier versions. The YARA rules and behavioral signatures above target implementation patterns — WinINet call sequences, staging directory artifacts, Defender exclusion writes — that persist across polymorphic builds. Treat any confirmed Vidar infection as a full enterprise credential breach, not a single-machine cleanup event, and prioritize session revocation before password resets.

See our coverage of LummaC2 exfiltration tactics for comparable post-disruption recovery context, and our threat actor OPSEC playbook breakdown for the structured evasion frameworks defenders are increasingly up against →