Home Blog From Malspam to Fileless .NET Loader Published: June 3, 2026 From Malspam to Fileless .NET Loader By: Anna Pham Adam Mooney Key Takeaways What makes the malspam kit clever is that it doesn't need to be customized for each target. It reads the victim's email from the URL, rebuilds the page on the fly, and pulls in the company logo live, no org-specific content hardcoded anywhere. Before the malspam link gets close to a malicious domain, it routes through ad.doubleclick[.]net , a legitimate, high-reputation Google-owned domain that most email gateways won't blink at. A gateway that inspects attachments before delivery has an opportunity to stop the chain before it starts. The attack never really touches the disk in any meaningful way. It's a five-stage chain. HTML, JScript, PowerShell, .NET loader, then the loader, leaning heavily on in-memory execution and .NET reflection to stay under the radar. If the loader detects a sandbox or analysis tool, it quits and reboots the machine. That's a deliberate move to complicate triage. Once it lands, the loader actively patches AMSI and ETW at the native API level, effectively blinding Windows telemetry before it even sets up persistence. Rather than dropping its own unsigned binary, the loader hides inside legitimate Microsoft-signed processes. InstallUtil.exe and MSBuild.exe are both hardcoded injection targets, giving it cover under trusted system tools. The loader phones home to DDNS domains on a non-standard port, keeping infrastructure cheap and easy to rotate. Blocking an IP gets you nowhere when the operator can swap it out in minutes. Update - June 5 @ 3:00 PM ET: This blog originally attributed activity to DesckVB RAT. After it was brought to our attention and we conducted a follow-up review, we concluded that attribution was incorrect. We have updated the original post to reflect our current assessment that the malware is an unidentified .NET loader, and corrected the related references. Thank you to the community members who prompted us to take another look. Background In May 2026, the Huntress SOC responded to a .NET loader infection that began with a malspam . Short for “malicious spam,” malspam is email crafted to deliver malware or trick a user into taking an action that starts the infection chain, whether that is opening a booby-trapped attachment, clicking a malicious link, or handing over credentials on a fake login page. Still to this day, malspam remains one of the most prolific initial access vectors for attackers. At first glance, this case could be mistaken for just another malspam infection, but the delivery chain tells a more interesting story. Before the victim ever reaches attacker-controlled infrastructure, the lure routes through DoubleClick, a legitimate Google-owned domain that many security tools are less likely to treat as suspicious. From there, the victim is passed into a malspam kit that personalizes itself on the fly using the victim’s email address, dynamically pulling in company branding and location details to make the page feel convincing without requiring the operators to handcraft a lure for each target. That matters because it shows how malspam operations are becoming more scalable without becoming less believable. The attackers do not need a bespoke kit for every organization. They can reuse the same infrastructure and still give each victim a page that looks specific to them, which lowers the cost of the campaign while increasing the odds that someone clicks. Once the victim interacts with the lure, the operation shifts from social engineering to layered malware staging. At its core, it’s a JavaScript-based Trojan, but what makes it nasty is the chain it kicks off once it lands on a machine. Rather than dropping one obvious payload, the chain moves through JScript, PowerShell, and .NET components that work together to retrieve, assemble, and run the final malware largely in memory. From there, the loader phones home to a C2 server, handing the attacker full remote control of the box. At that point, the attacker can pull data, run commands, or use the foothold however they see fit, all while keeping a minimal detection footprint. The loader enumerates installed AV products via WMI on the first beacon, which is standard profiling before deciding what to drop next. It also goes out of its way to specifically detect NVIDIA (GTX/RTX) and AMD (Radeon) GPUs through both WMI and direct registry reads. That level of GPU-specific interest could point toward crypto mining as a follow-on goal, or it may be used for masquerading purposes. For defenders, that is what makes this worth paying attention to: the malspam is only the opening move, and everything behind it is built to land quietly, stay hidden, and give the attacker room to operate. Timeline Figure 1: Diagram showing attack path Initial discovery Our investigation began with a process execution signal indicating the execution of a suspicious JavaScript file via WScript.exe. Figure 2: Initial detections for WScript The next clue was heavily encoded, obfuscated PowerShell code that, when decoded and deobfuscated, revealed it to be a PowerShell dropper. Figure 3: Encoded and obfuscated PowerShell Malspam analysis Initial access occurred via a malspam email containing a malicious HTML attachment, Bestellung_2026.html (“Bestellung” = German for “order/purchase order”). The attachment is a minimal HTML file whose entire content is a zero-second meta-refresh redirect. The meta-refresh sends the browser to a Google DoubleClick Campaign Manager click-tracking URL ( ad.doubleclick[.]net/ddm/trackclk/N4892.5020.4774291382421/B23999293.271539123 ), bearing campaign and creative identifiers ( dc_trk_aid=466016770, dc_trk_cid=131101292 ). The next destination is appended after the ? , with the recipient's email base64-encoded in that destination's URL fragment. Why do threat actors route through DoubleClick? The likely rationale is filter and reputation evasion. ad.doubleclick[.]net is a high-reputation Google-owned domain that is rarely blocklisted and is frequently allowlisted by email security gateways, web proxies, and URL-reputation services - so the only domain visible in the email body and at the front of the chain is one defenders are unlikely to flag, deny, or sandbox. Figure 4: Malicious HTML attachment DoubleClick forwards to fostercareintheus.optimizationprime[.]com/b#<base64-email> . This host does not serve the kit, it is a redirector stage. It decodes the base64 email and forwards the browser to the kit host, carrying the email as a plaintext fragment. This stage adds a domain layer between the trusted DoubleClick front and the actual kit host. The chain lands on the delivery kit at hxxps://bth.startthewave[.]org/a/#<plaintext-email> (e.g. bth.startthewave[.]org/a/#<email_address> ). Clicking “PDF herunterladen” (“Download PDF”) triggers downloadFile() , which builds a hidden HTML form and POSTs email=<address> to hxxps://pengajian.muliastudy[.]com/images/edu/u.php . The server responds with a ZIP archive ( A021185521S210008-11521.zip ) as the response body. The lure page (served from bth.startthewave[.]org/a/ ) is a single self-contained HTML file. setupEmailAndUI() reads the recipient's email from the URL fragment (window.location.hash), extracts the domain, and rewrites the page title, header logo text, and footer to impersonate the recipient's employer. The company logo is fetched live at runtime via a fallback chain - Clearbit, logo.dev, Google favicons, favicone, DuckDuckGo, then the company's own /favicon.ico . The kit contains no organization-specific content; swapping the email rebrands it instantly. fetchLocationAndTime() calls ipapi[.]co/json/ and prints the viewer's city, region, country, and local time into the header - social engineering to make the page feel personalized and “secure”. The kit only renders if a #email URL fragment is present; setupEmailAndUI() builds the entire page from it. With no fragment, the page shows “E-Mail nicht gefunden. Weiterleitung…” (”Email not found. Redirecting…”) and redirects to bing[.]com after two seconds. JScript multi-stage loader The ZIP archive delivered by u.php contains a JScript file named A021185521S210008-11521.js . It is not the final malware itself but a multi-stage loader whose job is to retrieve and execute a .NET loader while evading analysis. The file is heavily padded with junk—hundreds of repeated dead functions, garbage Unicode strings, ;;;;; filler, and Portuguese-language comments. Figure 5: Contents of A021185521S210008-11521.js On execution, the script checks its own path via WScript.ScriptFullName . If it is running from a Temp or Downloads folder - i.e. it has just been extracted from the ZIP by the victim—it copies itself to C:\Users\Public\ktncm.js , relaunches that copy with wscript.exe //nologo , and exits the current instance. If it is running from anywhere else, the relocation is skipped (the else branch is empty) and execution proceeds directly to the payload-staging logic. The net effect is that the first run relocates the script to a stable, world-writable directory, and the relocated copy, no longer in a Temp / Downloads path, falls through on its second run and proceeds to detonate. The script holds a large base64 blob mangled with literal A characters and the token 9999 inserted throughout to defeat static detection. The function vjwNvhDoHz() repairs the blob with string replacements, base64-decodes it into a PowerShell script, writes it to C:\Users\Public\nlbzl.ps1 , and executes it hidden with powershell -ExecutionPolicy Bypass -file . The dropped PowerShell performs, in order: a connectivity check ( Test-Connection to www.google.com )—if offline, it does not simply exit but invokes a function that runs Restart-Computer -Force , rebooting the machine; an anti-analysis sweep that enumerates running processes against a blocklist of debugging and sandbox tooling (Dbgview, tcpvcon, tc