The Demon Arrives Later: A Havoc Stager Hides Behind Microsoft Defender DLP

In Brazil, Nota Fiscal eletrônica (NF-e) is the everyday name for an official electronic invoice. Real ones often arrive as a ZIP whose long number looks like paperwork. Criminals reused that habit: their email attachment can look boring and “normal,” like another vendor bill. Behind that disguise, they install Havoc. Havoc began as free software for penetration tests; in the wild, attackers bend it into a tool that lets them watch the screen, run commands, or attempt to compromise other PCs in the network.

The malicious samples surfaced in the first half of May 2026, as Brazil wraps up another heavy tax-declaration stretch for households and employers. Accountants routinely open genuine NF-e-linked mail and ZIPs in that period, which makes spoofed invoice mail easier to open without hesitation.

In this post, LevelBlue SpiderLabs walks through how the bait was built, how the package fakes Microsoft Defender branding, and why nine variants look like the output of a single builder. We also share what we recovered from Havoc’s settings that the attacker leaves on disk (server addresses, sleep timers, anti-forensic toggles), the persistence trick that survives a reboot, and a YARA rule to flag the stager before the demon ever lands.

This is not an isolated case. Trend Micro recently summarized Banana RAT, a separate Brazilian operation that leans on the same kind of invoice-shaped mail to deliver an unrelated banking trojan. Our post looks at a different malware: the piece of software that the attackers drop on the victim’s machine, which pretends to be Microsoft Defender DLP and downloads Havoc when triggered. The Brazilian invoice email is one route into the victim, but the same malware turns up behind other delivery methods, too. Packetwatch recently described one of those, through compromised websites, and is a useful complement on the delivery side.

Key Points

• Invoice-shaped bait, not a real NF-e. The ZIP mimics how Brazilian businesses receive electronic invoices, but it holds only a short script and an installer. There are no PDF and no signed XML. We tied one upload to Brazil in early May 2026.
• Surfaced during Brazil’s tax season. Samples appeared in the first half of May 2026, when households and employers routinely open genuine invoice mail, which makes spoofed NF-e attachments easier to trust.
• Fake Microsoft Defender DLP on disk, Havoc fetched at runtime. The installer drops a Havoc stager (endpointdlp.dll) beside a genuine signed mpextms.exe. The stager reaches out to attacker infrastructure and pulls demon shellcode.
• One builder, many builds. Nine stager variants share the same template. Persistence uses a logon-script registry value (UserInitMprLogonScript).
• Two HTTP profiles to hunt. Standalone Havoc demons in the beacon with a Chrome-style user-agent. The stager uses Microsoft-themed delivery headers (Microsoft-Delivery-Optimization/10.1 user-agent).
• YARA for early detection. We publish a rule that flags the stager template useful to catch the first downloader before the demon lands.

Figure 1. End-to-end delivery and execution chain.

The Lure: A Nota Fiscal That Isn’t One

The lure archive we analyzed arrived as:

NFE-43250902055205000108550010000269881023835318-1.zip

The long number in the name is Brazil’s standard invoice access key: one 44-digit ID per authorized NF-e. Accounting teams see ZIP attachments named NFE-{key}-1.zip every day. The threat actor picked a key that looks real (state code UF 43, Rio Grande do Sul, plus a believable company tax ID) so a busy recipient may treat it as another supplier bill, especially during tax season. The name is there to trick people; it is not what you should alert on by itself.

However, a legitimate NF-e package would contain different files:

Figure 2. Lure ZIP listing.

The VBS hides its intent behind string splitting. Deobfuscated, the VBS launches a hidden cmd that downloads the MSI from Google Cloud Storage with curl, runs it with msiexec /quiet /norestart, and deletes the file:

Figure 3. VBS dropper and reassembled URL.

hxxps://storage[.]googleapis[.]com/nodesdownload/update.msi

VirusTotal recorded two independent sightings of this ZIP. On May 2, 2026, someone in São Paulo uploaded it by hand through the web interface. On May 7, 2026, a URL crawler found hxxps://tr[.]ee/lAZ5yi serving the same file. The lure is unambiguously Brazilian, even though the same stager DLL also turns up behind a completely different delivery chain on Malaysia-registered domains (see below).

Installer Theatre: MSI, Signed Host, Malicious Neighbor

The next step is an MSI that pretends to be a Microsoft update. If you open the installer’s Properties in Windows, the text already says Microsoft Endpoint DLP Module, author Microsoft Corporation, with the same product name repeated in the comments. That does not mean Microsoft built it. It is there so someone who glances at Properties before clicking Install feels safe.

What helps defenders is where the file came from, not the label on it. The MSI was built with WiX Toolset 3.14.1.8722 (a common tool for making installers). That fits an attacker-built package, not a real Microsoft installer that was edited. The MSI also has no digital signature.

Inside the installer are two programs:

• mpextms.exe: a real Microsoft-signed file (sha256 a3ff17daf900…).
• endpointdlp.dll: the attacker’s stager (7d4fb94f6b46…).

The DLL copies the same fake labels in its version info (description, product name, company, and a version number that matches recent Defender builds). Side by side, the MSI and DLL look like one Microsoft bundle. Onlympextms.exe is signed. The stager DLL is not.

Figure 4. VERSIONINFO spoof: legitimate (left) vs operator (right).

The Stager: Defender Branding on the Outside, Havoc Fetched on the Wire

Most public Havoc write-ups describe the demon as embedded inside the loader, decrypted at runtime. This operator does something different. The DLL we recovered is just a stager: its only job is to reach out to the C2 server and download the demon over the network. The demon never exists on disk.

The DLL exports thirteen functions, but only one does real work (DlpInitialize, which writes the persistence key). The other twelve immediately return zero. By comparison, the genuine Microsoft endpointdlp.dll exports around 100 functions. The fake ships thirteen names and implements one.

What the DLL does carry is a cleartext configuration block starting at file offset 0x11dec0. It holds the C2 address, URI paths, HTTP methods, and user-agent the stager needs at runtime. The interesting fields (stored as UTF-16LE wide strings) are as follows:

/stage/
GET
/api/v2/telemetry/diag
POST
Microsoft-Delivery-Optimization/10.1
194.59.31.192
winhttp.dll
Global\{7f3a9c2e-4b1d-8e5f-a6d0-3c9b2e1f7a4d}

ASCII in the same .rdata cluster (not wchar-encoded):

phantom.local
0123456789abcdef

The block holds the production C2 host, staging path, post-handshake path, HTTP methods, user-agent, and a named mutex. The ASCII string phantom.local nearby is likely a builder placeholder the operator forgot to remove. The hex alphabet (0123456789abcdef) that generates the /stage/<hex32> token sits as a separate ASCII literal.

When we ran the DLL in a sandbox with internet access, the behavior matched exactly: it issued GET /stage/<32-hex> and then POST /api/v2/telemetry/diag against 194[.]59[.]31[.]192:8443, using the Microsoft-Delivery-Optimization/10.1 user-agent. Havoc-family YARA matched the code loaded in memory. The file on disk was still just the stager; the demon arrived over the wire.

One Builder, Two Distribution Fronts

We started with four stager samples. A YARA retrohunt across a full year of VirusTotal expanded that to nine. The nine split into two groups by import-hash, and at first glance, the two groups look only loosely related. Six shared traits say otherwise.

1. Same VERSIONINFO masquerade. Eight of the nine stagers carry the exact strings Microsoft Defender Endpoint DLP / Microsoft Corporation / FileVersion 4.18.26100.1 lifted verbatim from the Windows legitimate DLL. The ninth (00d9) just swaps to Dragon Data Protection / Nuance Communications.
2. Stable subset of core DLP exports. All nine stagers expose the same twelve core Dlp* and AuditBrowser* function names, in the same alphabetical order.
3. Identical wrapper imports. Every stager imports the same 26 functions from the same four DLLs (KERNEL32, USER32, ADVAPI32, ole32).
4. Two near-identical pairs. 1d09 vs d2c6 (1.2 MB each) differ in only 69 bytes: a per-build seed and a session-key slot. 7d4f vs 1fc5 (1.18 MB each) differ in one byte: an ASLR flag toggled off in the later build. These are the same builder run twice, not two separate tools.

Figure 5. Stager byte-diff: 69 bytes across 23 regions.

1. Same drop naming convention. Where retrohunt observations include filenames, the stagers consistently land at C:\Windows\<random_lowercase>.exe: ll7lgb3i.exe, pob2zp3d.exe, bwurp.exe, m9jehl07u.exe.
2. Same runtime user-agent. The two stagers we ran with internet enabled both beacon with Microsoft-Delivery-Optimization/10.1 user-agent.

Any single trait on this list is common across unrelated malware. It is the convergence of all six that binds the nine stagers to one builder, producing two output branches in parallel.

The same stager DLL reaches victims through at least two separate campaigns. The first is the NF-e/Brazil chain detailed here. The second is a parallel update.zip download served from three Malaysia-registered domains (e4wxbrg5277[.]com, 49xb5hoiqsr[.]com, jh038x18gy9[.]com), each URL carrying a per-victim tracking token (?tk=<hex32>). That ZIP bundles stager afd5f1ed45a9… with the same mpextms.exe and beacons to a different C2: hxxps://thomphon[.]com/api/v1/telemetry.

A third front shows up in someone else’s reporting. Packetwatch’s KongTuke write-up documents an endpointdlp.dll that matches one of our cluster samples at the byte level. The packaging around it is different (a TAR with the demon pre-bundled, instead of fetched at runtime), but the stager DLL is the same. The simplest reading: one builder supplies the same wrapper to multiple distribution layers, rather than one actor running every campaign end to end.

The Demons: What the Stager is Fetching

Beyond the stager family, we found a separate set of seven Havoc demon executables. These are not alternate builds of the stager DLL. They are full Havoc agents: the implants that run on the victim after the stager finishes its handshake. Their configuration block sits at a fixed offset in the binary (.data/0x17de0) and follows the standard Havoc layout.

Because Havoc is open-source, we wrote a small parser against its source code that reads the config directly from the binary on disk. We recovered seven of the nine demon configs.

The strongest fingerprint: two of those demons (each 102,400 bytes) differ in exactly sixteen bytes. Seven of those bytes are the C2 address swapped in place: 143[.]198[.]183[.]46 in one, 192[.]168[.]12[.]228 (a private-network test address) in the other. The remaining nine are just the PE checksum and timestamp updating to reflect the change. Over a hundred kilobytes of code are identical. Same builder, one production build and one test build shipped side by side.

Figure 6. Demon byte-diff: 16 bytes, C2 IP swap.

The recovered configs cluster into three presets:

• Lab clean — private-network C2, no jitter, no sleep mask, all protections off. The operator’s test builds.
• Standard — live C2 (143[.]198[.]183[.]46), 15% jitter, Ekko sleep mask on, most protections still off. The everyday distribution build.
• Live target — C2 at 194[.]62[.]55[.]81:80 with TLS off, every anti-forensic flag enabled (stack spoofing, indirect syscalls, AMSI/ETW patching, proxy loading), and spawn target changed from notepad.exe to RuntimeBroker.exe. The actual victim-deploy build.

All demons beacon with the same HTTP profile:

POST / (one sample uses /api)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
fallback: System32\notepad.exe + SysWOW64\notepad.exe

We have not matched a specific demon binary to a specific /stage/<hex32> download. That would require capturing the payload in transit. The template overlap between stagers and demons points strongly at the same operator, but we are honest about where the chain has a gap.

What the Demon Can Do Once It Lands

Once the stager hands off, the demon enters Havoc’s tasking loop and waits for commands. The configs we recovered show which defenses this operator turns on. Every feature below is a built-in Havoc toggle; the operator just picks the combination:

• Encrypted C2 traffic. A fresh AES key is negotiated at first contact; all later traffic is encrypted.
• Sleep + jitter. Two-second base interval between beacons, with 15% randomness. Fast enough for interactive control, noisy enough that NetFlow analysis can spot it.
• Ekko sleep mask. Between beacons the implant encrypts itself in memory. A memory scanner that fires mid-sleep sees only random bytes; the real code is only exposed for the instant the beacon runs.
• Stack-frame spoofing. Hides the true call origin so that stack-walk forensics cannot tell where the demon lives in memory.
• Indirect syscalls. Calls to the Windows kernel bypass the user-mode hooks that EDR products install.
• AMSI / ETW patch. Disables Windows’ built-in malware-scanning and event-tracing interfaces so the OS itself stops reporting what the process does.
• Proxy loading. Outbound traffic can route through a proxy chain configured by the operator.

The demon never touches disk. Every login re-downloads it from C2. If the server goes offline, the attacker loses the host on next reboot. The upside for the attacker: disk forensics on a compromised machine only finds the stager and the signed Microsoft binary, never the implant that actually ran the operator’s commands.

Persistence: a Logon Script Many Tools Ignore ( T1037.001)

At first execution, the stager writes:

HKCU\Environment\UserInitMprLogonScript = <path to mpextms.exe>

Windows reads that value at logon, before the desktop appears, and runs whatever it points at. The signed mpextms.exe starts, loads endpointdlp.dll again, and the cycle repeats. No scheduled task, no Run key. Any non-empty UserInitMprLogonScriptdeserves investigation; legitimate use is essentially nonexistent, and most detection stacks do not monitor it as aggressively as the usual autorun locations.

LevelBlue USM customers are covered against this persistence technique through the SpiderLabs-maintained correlation-rule set, which alerts on UserInitMprLogonScript writes regardless of the binary they point to.

Conclusion

Two things come together here that usually get triaged separately: an NF-e-themed lure designed to disappear into normal Brazilian invoice traffic, and an execution path where the MSI only drops a stager, and the actual Havoc implant arrives over the network after a separate handshake. The lure exploits a workflow that recipients are trained to trust; the execution exploits the assumption that whatever lands on disk is the final payload.

What pulled the cluster together was not the lure but the byte-level overlap across stagers: nine builds sharing one wrapper, two pairs that are nearly byte-identical, and a single-byte recompile that gives away an active builder running in the background. Havoc itself brings the post-exploitation features (encryption, sleep masking, anti-forensic toggles); the threat actor just picks the combination.

The byte overlap with Packetwatch’s KongTuke TAR suggests a possible shared builder upstream of multiple distribution fronts. If that reading is correct, blocking any single lure only stops one front; detecting the wrapper itself (VERSIONINFO masquerade + zero Authenticode + cluster imphash, see YARA below) would cover all of them.

Post-exploitation frameworks wrapped in region-specific social engineering (invoice scams in Brazil, parcel scams in Europe, tax scams in the US) are a pattern across mid-2026 reporting. This campaign is a concrete example of what that pattern looks like in production. For defenders, the takeaway is: do not stop at the file on disk. Hunt the handshake traffic, treat any non-empty UserInitMprLogonScript as suspect, and verify Authenticode on every Microsoft-named binary that arrives in a downloaded archive.

What to Hunt

• Brazil channel: NFE-{44-digit-chave}-1.zip without PDF/XML; 503-byte VBS; MSI fetched from hxxps://storage[.]googleapis[.]com/nodesdownload/update.msi; ITW URL hxxps://tr[.]ee/lAZ5yi observed for the lure ZIP.
• Malaysia /update.zip channel: update.zip from e4wxbrg5277[.]com / 49xb5hoiqsr[.]com / jh038x18gy9[.]com (Malaysia WHOIS, per-victim ?tk=<hex32>); sibling stager beacons to hxxps://thomphon[.]com/api/v1/telemetry.
• Stager (any channel): GET /stage/<32-hex> request with Microsoft-Delivery-Optimization/10.1 user-agent from a non-update process, especially co-located with mpextms.exe.
• Disk (any channel): any unsigned endpointdlp.dll bearing Microsoft Defender Endpoint DLP or Dragon Data Protection VERSIONINFO, or a DLL with imphash 07d0d4c580ac76ac3ffb63353c9b6b85 / 7d384886720c8e576c3ca9d68cb5f08b, regardless of the file name on disk.
• Registry: any non-empty HKCU\Environment\UserInitMprLogonScript value.
• Host: mutex Global\{7f3a9c2e-4b1d-8e5f-a6d0-3c9b2e1f7a4d} (observed in the 7d4f/1fc5 byte-identical pair only).

YARA: Stager Template

import "pe"

rule Havoc_endpointdlp_Stager_2026
{
     meta:
          description = "Havoc stager: fake Defender DLP VERSIONINFO, zero sig,      operator imphash or /stage/ + /api/v2/telemetry/diag strings."
          author = "LevelBlue SpiderLabs"
          date = "2026-05-18"
strings:
    $ms_dlp = "Microsoft Defender Endpoint DLP" wide
    $dragon = "Dragon Data Protection" wide
    $msver = "4.18.26100.1" wide
    $stage_path = "/stage/" wide
    $diag_path = "/api/v2/telemetry/diag" wide
    $msdo_ua = "Microsoft-Delivery-Optimization" wide
condition:
    (uint16(0) == 0x5A4D) and pe.number_of_signatures == 0
    and (
           (1 of ($ms_dlp, $dragon) and $msver
           and (pe.imphash() == "07d0d4c580ac76ac3ffb63353c9b6b85"
                or pe.imphash() == "7d384886720c8e576c3ca9d68cb5f08b"))
     or all of ($stage_path, $diag_path, $msdo_ua)
         )
}

Indicators of Compromise

# Delivery — NF-e channel
3578e1588846a805ee806fa6151b5801d0acb88879a93d378300e2ee7665736e NF-e ZIP
f2357e70f359803d42298d016c7e1631e9fba6c7e01e5df1eb8fb9ff7eb3df4e VBS
d24216d0b82747e9406a696da76960183926145f9621947e34a772137f5e22a6 MSI
7d4fb94f6b4623690daea67ed52e97705cb102f443988ff605f2a9c4898244dc endpointdlp.dll (from MSI)

# Delivery — KongTuke channel (per Packetwatch, 2026-05-05)
0743154262c5ccf24794168ee331feeefc6539386715307ee44d5d9b6b321077 TAR (KongTuke distribution package)
eca5c297008e7c07a5c6fc9070c03121d702ef093b4a8e508b712040d87fed36 data.bin (encrypted demon, adjacent to DLL inside the TAR)

# Stagers (family)
1d09357b6a096fdc35cd5c873eed15665d6b3c879d20c8cf01e6bca0005512cf
d2c637235d62ad766f961f9b8563f6a0e6db2ec0a343470385991b4df826afbc
1fc515870c681bf3e1b7947e2248bbcfe9918db2978117e91134de20bd42fd6a
ced6b0f4441085bb9c54a32da9ab4ba14c6e21daf6e34fd61d54923f87baacd0
afd5f1ed45a9867daf3bc64152cef460a06b164c8183e490db39146d4749a82c
2cd88d5280a61714836f5f07a16df190911c5b952af2998dbbcda910b3b1c494
fb3630822b70bacb56aa4cec29b5a0e3e9acb3920809e70310a4003385a6d34a
00d979bdb1b29b2859f2120580f101f40e8e13de0b3b7bc29675e2c31098a03c

# Standalone demons
ae8cded2822c56dd85f52bba09d9285cb2db3e6317227530b848ea143afb067c
9eefc66d1fca7f18a91f49affb569b41bcde043f91567e7f5cc9f2016aeddf8c
c958de72460256c9c1cceef527d880862e8bc29e3ae4e2d478af97dcafd41180
6dc41555455860b8584d761303a7ae5487117944e2a24d74fa3e91ad8f840077
6b22df0de0a40ff372973639c8a1974cfb75084b8e3b85f9ab9038e0acce43c0
31f27fdc14505e0cebe360579e1ba0326762cbe0948e50b5f920da51fdef1b51
389a6a2007e4f06d16beac0ec2cb01391f80ad5e392343386cae3ceb82ec1502

# Network / host
hxxps://tr[.]ee/lAZ5yi
hxxps://storage[.]googleapis[.]com/nodesdownload/update.msi
hxxps://e4wxbrg5277[.]com/dl/update.zip?tk=<hex32> # Linked to Kongtuke's campaign
hxxps://49xb5hoiqsr[.]com/dl/update.zip?tk=<hex32>
hxxps://jh038x18gy9[.]com/dl/update.zip?tk=<hex32>
194[.]59[.]31[.]192:8443 stager (`7d4f`); GET /stage/<hex32>, POST /api/v2/telemetry/diag (embedded wchar config)
thomphon[.]com sibling stager (`afd5`); /api/v1/telemetry; POST per VT sandbox; path in Joe 2026-05-18 memory only
143[.]198[.]183[.]46 demon C2 (plaintext in samples)
194[.]62[.]55[.]81 demon C2 in live target build (Bursa, TR)
HKCU\Environment\UserInitMprLogonScript -> mpextms.exe

MITRE ATT&CK