In April 2026, Unit 42 researchers identified a financially motivated campaign delivering Vidar stealer and the XMRig cryptocurrency miner to consumer and small- and medium-sized business victims worldwide.
Attackers lure victims via malvertising to pages for downloading files that impersonate cracked versions of copyright-protected software. Upon execution, the loader drops and runs both Vidar stealer and XMRig. Vidar stealer targets information like browser credentials, cookies and crypto wallets. XMRig mines Monero cryptocurrency.
We assess the operator of the campaign to be a Vidar stealer malware-as-a-service (MaaS) affiliate involved in operations targeting victims in the U.S. and European Union. This article provides a technical analysis of the campaign.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Since its emergence, attackers have used Vidar stealer in multiple large-scale campaigns. We identified a notable spike in activity from mid-late April 2026, primarily targeting organizations in the U.S. and the EU.
Figure 1 illustrates the timeline of the April 2026 campaign, which shows the number of Vidar stealer samples discovered each day.
Our investigation of this activity led to the discovery of loader binaries distributing both Vidar stealer and XMRig.
This group behind this campaign distributes loader binaries through malvertising, targeting victims who search for pirated or cracked versions of copyright-protected software. The filenames used in this campaign mimic cracked versions of popular copyright-protected programs as well as generic installers.
The campaign delivers the malware in password-protected archives with a .bin extension in the filenames. This appears to be a deliberate choice to bypass email gateway scanning and to prevent automated sandbox detonation without the password.
We initially discovered 43 of these loader binaries that deliver Vidar stealer and XMRig. Upon extraction and execution, the loader binary is signed with a certificate (subject CN=justwatch[.]com), creating a false sense of legitimacy before any malicious activity begins.
Our analysis of these loader samples indicates they use the Factory-v3 framework.
Factory-v3 has been described as a MaaS builder used for different families of stealer malware. All 43 samples we discovered from this campaign contain embedded Go build metadata identifying the Factory-v3 framework.
The Factory-v3 builder's internal name of UpdateFactor is revealed in a developer/build machine path shown in the programming database (PDB) strings of the loader DLL files:
C:\Users\Administrator\Desktop\UpdateFactory\compiler\1.25.9\go\src\runtime\cgo
Figure 2 shows a diagram of information from the build machine metadata.
The builder generates a unique binary per build. For example, we observed 27 unique build UUIDs across 43 samples, defeating hash-based detection. The builder uses Go version 1.25.9, a custom pre-release of tools for the Go programming language.
Anti-forensic measures are consistent across all samples:
The same builder, toolchain and Authenticode certificate infrastructure underpin a concurrent Lumma stealer campaign. This indicates Factory-v3 is used as a service for multiple stealer affiliates.
All 43 loader samples carry an Authenticode signature fabricated to impersonate JustWatch GmbH, a legitimate German streaming guide service. JustWatch has not been compromised. The certificate is entirely fabricated using a self-signed root certificate authority (CA) that is not present in any public trust store, as shown below in Figure 3.
Because the certificate is not chained to a Microsoft-trusted root, Windows SmartScreen and Authenticode validation will flag the binary as untrusted. However, the visual presence of a recognizable brand name in the signature dialog is sufficient to deceive many victims into proceeding.
The 43 loader samples fall into four clusters, as Table 1 below shows.
| Cluster | CPU Architecture | File Type | Frequency Count | Role |
| A | x64 | EXE | 26 | Go loader (file-inflated EXE) |
| B | x64 | DLL | 13 | Fake MpClient.dll sideload |
| C | x86 | EXE | 3 | Go loader 32-bit (shared with Lumma Stealer campaign) |
| D | x64 | EXE | 1 | Vidar core payload |
Table 1. Sample clusters with filetype.
Cluster B DLL variants export Windows Defender MpClient.dll API functions to enable DLL search-order hijacking (MITRE ATT&CK® T1574.002). When a legitimate Windows Defender binary attempts to load MpClient.dll, the operating system locates the malicious copy first if it is placed in a higher-priority search path. The exported function names mimicked include MpAllocMemory, MpClientUtilExportFunctions, MpConfigOpen, MpFreeMemory and nine others.
Loaders in Clusters A and C append hundreds of megabytes of null bytes after the last PE section, pushing the total file size to as high as 491 MB. Most automated sandbox environments enforce an upper file-size limit of 50-100 MB and silently skip oversized submissions, meaning the malware never executes in the analysis environment.
The real malicious content in the largest observed sample is only 2.3 MB, and the remaining 489 MB is null byte padding. Defenders should ensure security tooling removes null byte padding before applying size limits, since the same sample compresses to approximately 2.4 MB.
Static disassembly of the Vidar core payload sample (SHA256 hash: 7ed4a256e1d281cb4f194d13ff554fb280dafde0a67a18115ea038ea6c87d) reveals an in-memory Antimalware Scan Interface (AMSI) bypass that executes before any stealer logic runs. The routine loads amsi.dll, resolves the AmsiScanBuffer variable and overwrites its first six bytes with a patch. This patch forces the function to return E_INVALIDARG, which might disable Windows AMSI for all subsequent script and code execution on the victim machine.
Both the DLL name and function name are XOR-obfuscated with single-byte key 0x05 to evade static string scanning. Table 2 shows the encoded and decoded strings for these names.
| Encoded String | XOR Key | Decoded String |
| dhvl+aii | 0x05 | amsi.dll |
| DhvlVfdkGpcc\`w | 0x05 | AmsiScanBuffer |
Table 2. Encoded and decoded strings from the sample.
Figure 4 below shows patched bytes written to the AmsiScanBuffer location (0x80070057).
The binary uses a second, longer obfuscation layer for larger data blobs. This layer is obfuscated by a 32-byte rotating XOR with the key 69946018ddda1058ce5c2a556c78a747838865c47074dcb165effb0840cb1cf5 applied to the Telegram bot token, Monero wallet address and mining pool hostname for the XMRig payload.
Figure 5 shows that the attack chain begins with malvertising, luring victims into downloading a password-protected .bin archive disguised as a cracked version of a legitimate program.
The loader extracted from the .bin archive exhibits the following features:
The malware employs anti-analysis techniques such as process enumeration, alongside an AMSI bypass where the AmsiScanBuffer function is patched to prevent detection by some types of security software.
Subsequently, the malware drops multiple payloads including Vidar stealer and the XMRig cryptocurrency miner, while establishing persistence mechanisms through registry modifications and scheduled tasks.
The next stage involves reconnaissance, as the malware gathers information about files, hardware IDs (HWID) and bypasses proxies. Vidar stealer then exfiltrates sensitive data such as credentials and cryptocurrency wallets, communicating with a command-and-control (C2) server at 136.243.203[.]109.
Simultaneously, XMRig begins mining Monero using the mining pool at pool.supportxmr[.]com. Finally, the attacker is notified of new activity via Telegram, with messages labeled "X3D MINER • NEW LOG," ensuring the operator stays informed about successful infections and stolen data. This means the threat actor behind Vidar is deploying the X3D MINER XMRig package.
Dynamic analysis of the Vidar core payload confirmed the following execution sequence:
The payload establishes persistence through three parallel mechanisms:
Registry Run key:
Startup folder batch script:
All three mechanisms point to the malware file named NisSrv.exe. Attackers chose this filename to blend in with legitimate Windows Defender components, since the real NisSrv.exe is the Network Inspection Service binary.
The tag X3D MINER appears in Telegram operator notifications sent for every new victim infection. This moniker is used by a group associated with XMRig and binding XMRig with other programs.
The operator behind this campaign runs a dual-monetization scheme. Criminals sell credentials and session cookies stolen by Vidar stealer on criminal log markets, while XMRig provides passive income from hijacked victim CPU cycles. The Factory-v3 builder is assessed to be a separate upstream service used by at least two distinct stealer affiliates.
Pivoting on information from the initial 43 loader samples, we identified 56 additional samples of a subsequent variant on April 24, 2026. This variant retains the same builder, delivery and C2 infrastructure.
The operating characteristics, Go loader, Factory-v3 builder, Telegram dead-drop and payload delivery are identical to the original campaign. The single differentiating factor is the Authenticode certificate.
The operator transitioned from using a self-signed certificate mimicking JustWatch to another unauthorized certificate designed to resemble the BleacherReport[.]com certificate. This technique is known as Code Signing Impersonation.
Attackers craft certificates to mimic legitimate, trusted publishers (e.g., Microsoft or Google) by cloning their metadata as Table 3 below shows. It is important to note that Bleacher Report has not been compromised.
| Variant A | Variant B | |
| Subject | CN=justwatch[.]com | CN=\\*.bleacherreport[.]com |
| Issuer | CN=WR3 (rogue self-signed CA) | CN=GlobalSign Atlas R3 DV TLS CA 2026 Q1 (Cloned issuer name) |
| Chain is trusted? | No | No |
| Certificate type | Fake Authenticode (CA:TRUE) | Certificate chain could not be built to a trusted root authority (fake certification) |
Table 3. Certificate data from the old and new variants of Vidar stealer.
We observed these samples contacting the Telegram channel ci0iiif. New C2 servers in this cluster include 138.199.246[.]13, 116.203.243[.]208 and 136.243.203[.]111.
This campaign demonstrated a multi-layer evasion approach. This approach combined the following characteristics:
Loader samples sharing these characteristics were all delivered via a MaaS platform that also serves other malware stealer families.
The operator's shift from using a self-signed certificate to leveraging an unauthorized certificate in Variant B demonstrates the actor's ability to adapt rapidly.
We recommend that organizations enforce strong Authenticode chain validation and supplement it with:
Defenders should also:
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
(Read: Field - Value)
(Read: File path - Description)
Table 4 shows the imphashes with the associated sample clusters and the role of those clusters in this activity.
| Imphash | Cluster | Role |
| d42595b695fc008ef2c56aabd8efd68e | A - x64 EXE (26 samples) | Go loader EXE |
| d8b31f8c03e0c76ff245ed05a15ffe6c | B - x64 DLL (13 samples) | Fake MpClient.dll |
| 1aae8bf580c846f39c71c05898e57e88 | C - x86 EXE (three samples) | Go loader x86 |
| c10333c92889b65c3590ef2b3819b420 | D - Vidar core (one sample) | Vidar core payload |
Table 4. Imphash information associated with this activity.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。