From QuickAssist to Demon: Fake IT Support Campaign Distributes Customized Havoc C2 Framework

In February 2026, Huntress identified a cluster of intrusions across five partner organizations sharing a common attack pattern: email spam bombardment as initial bait, followed by a vishing call from an actor posing as IT support, culminating in the deployment of a heavily modified Havoc C2 Demon agent. In one organization, the adversary moved from initial access to nine additional endpoints over eleven hours, deploying a mix of custom Havoc Demon payloads and legitimate RMM tools for persistence.The campaign’s tactics, techniques, and procedures (TTPs) overlap significantly with prior research by Sophos linking similar email bombing and vishing operations to Black Basta and FIN7. Black Basta is rumored to have gone dormant in late 2025 following internal chat leaks and coordinated law enforcement pressure from German and Ukrainian agencies, yet their signature playbook appears to remain active in the wild. This points to either former affiliates migrating to new operations, or rival actors co-opting the same playbook.

Phase 1: Social Engineering & Initial Access

The intrusion chain begins with a mass spam campaign targeting organizational inboxes. Account selection was deliberate — in at least one case, the actor sourced the victim’s personal cell phone number as the contact method.

Once users were overwhelmed by the spam, adversaries posing as fake IT support contacted them, falsely claiming the need for remote access to perform Outlook updates or other “remediations” to stop the spam. Users were then persuaded to approve a QuickAssist session or to install remote access applications like AnyDesk, granting the attacker hands-on access to the endpoint.

With remote access established, the actor navigated the victim’s browser to a fraudulent Microsoft “Outlook Antispam Control Panel” hosted on Amazon AWS. The fake panel prompted the user to enter their email address and click a button to “Update rules configuration,” which triggered a script that displayed a credential-harvesting overlay requesting the user’s password — simultaneously capturing credentials and maintaining the illusion of a legitimate remediation workflow.

Phase 2: Payload Delivery via DLL Sideloading

The “Antispam Patch” downloaded from the fake panel was a modified ZIP archive (titled patch<numbers>.1) that the actor reconstructed on-disk using a batch of commands:

Three legitimate, signed binaries were co-opted as sideloading hosts: DLPUserAgent.exe, ADNotificationManager.exe, and WerFault.exe. Maliciously crafted DLLs were dropped alongside each, with DLL forwarding/proxying used to co-locate a legitimate renamed version, preventing application errors from missing imports.

Loading Application	Malicious DLL	Legitimate (Forwarded) DLL
ADNotificationManager.exe	vcruntime140_1.dll	vcruntime140_2.dll
DLPUserAgent.exe	mpclient.dll	mpclient2.dll
WerFault.exe	faultrep.dll	mscvp.dll

Phase 3: Loader Analysis — Two Distinct Implementations

mpclient.dll / faultrep.dll (simpler variant)

These loaders are UPX-packed. The DLL entrypoint decrypts license.key from disk using ChaCha20 with the key 06 83 33 23 c5 e3 1a 82 73 be 47 b0 df 70 b9 4c c8 f3 8d 44 35 93 3b 91 81 1d 8b dd 95 26 8f 86 and a null nonce, with a registry fallback to HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\UXMP.

A separate code path installs two Detours-based ntdll hooks: a hook on ntdll!RtlExitUserProcess that enters an infinite Sleep(5000) loop to prevent process termination, and a hook on ntdll!LdrUnloadDll that returns 0 unconditionally, blocking DLL unloading by security tooling. The decrypted shellcode is then executed.

vcruntime140_1.dll (advanced variant)

This loader employs substantially more sophisticated evasion. It borrows a large portion of its codebase from legitimate ESET binaries and uses unique tight-looped timing delays — approximately 4 million iterations — to prevent or confuse emulation, particularly for emulators with weak SIMD support.

The payload resides in the .rsrc section, protected by a 26-byte XOR key (28 79 3f 78 41 79 38 3c 39 64 55 72 68 54 21 32 40 66 3e 42 44 54 37 78 70 00) stored beyond the .text section’s VirtualSize, making it inaccessible to conventional decompilers. Code execution to DllMain passes through a 29-stage trampoline chain that also implements anti-analysis by using arbitrary jumps to embed critical register state setup within the trampolines themselves, defeating disassembler control flow analysis.

Hell’s Gate & Halo’s Gate: Rather than calling Win32 API functions directly (which EDR hooks), the loader resolves System Service Numbers (SSNs) from ntdll.dll’s in-memory Export Address Table by scanning each Nt* stub for the pattern 4C 8B D1 B8 (mov r10, rcx; mov eax, <SSN>). The SSN is loaded into EAX and the syscall instruction is issued directly, bypassing userland hooks entirely. If a stub’s expected pattern is overwritten by an EDR hook, the Halo’s Gate fallback walks neighboring Nt* stubs and derives the correct SSN by offset. This technique is used specifically to call NtAllocateVirtualMemory for shellcode allocation without EDR visibility.

Phase 4: The Havoc Demon Agent

The decrypted license.key shellcode is a modified Havoc Demon — an open-source post-exploitation C2 framework originally created by @C5pider. The shellcode loader (KaynLdr, unmodified from the Havoc source) bootstraps itself using the classic call $+5 trick to locate its own base address in memory, then walks the PEB’s InMemoryOrderModuleList using DJB2 hashing (seed 0x2673) to locate ntdll.dll and resolve three NTAPI functions: LdrLoadDll (0x14249D31), NtAllocateVirtualMemory (0x60B9BE9A), and NtProtectVirtualMemory (0xE77E3076), before reflectively loading the embedded Demon DLL.

The Demon itself uses a separate DJB2 seed (0x16AA) for all runtime API resolution, including the ~36 indirect Nt* syscalls. All syscalls share a single gadget address sourced from NtAddBootEntry within ntdll, ensuring that RIP points into legitimate ntdll memory at syscall execution — a known technique described in the Havoc documentation.

Registry-Based C2 Resilience (Non-Default Modification): A notable operator customization is a registry-based C2 fallback mechanism absent from stock Havoc. The Demon reads three registry values at runtime from HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\ (with an HKLM\SOFTWARE\Microsoft\SQMClient\ fallback). The UFID and UCID values work as a pair: after reading the registry data, the Demon sets up a ChaCha20 decryption using the UCID output as key material, with a hardcoded 12-byte nonce (41 98 B6 39 77 EA 2B F0 A4 2D 42 22), and the decrypted result is parsed as a list of C2 host:port entries for fallback communication. This allows the operator to push fresh C2 addresses to compromised hosts without redeployment, providing resilience against sinkholing.

Phase 5: Lateral Movement & Persistence

With the initial compromise occurring at 20:18 UTC on February 20, 2026, the adversary created scheduled tasks across four of nine compromised endpoints just 50 minutes later, at 21:08 UTC. Each task pointed to a batch script at C:\Windows\SoftwareDistribution\Download\go.bat — a directory normally used for Windows Update staging — which reconstructed and relaunched the Havoc Demon payload on every reboot. Scheduled task names were numeric strings corresponding to Unix epoch timestamps (e.g., 1771621617), likely generated at deployment time with small per-host offsets reflecting propagation delay. All four tasks were registered within a nine-minute window.

The lateral payload used WerFault.exe as a new sideloading host with faultrep.dll, functionally identical to mpclient.dll and using the same ChaCha20 key to decrypt license.key.

RMM Diversification: Rather than deploying Havoc everywhere, the actor diversified persistence across the nine endpoints:

No single endpoint received all three persistence mechanisms. The adversary distributed different tooling across different hosts, ensuring that discovery and remediation of one mechanism would not eliminate access to the entire environment.

What begins as a spam-flooded inbox and a convincing phone call ends with a fully instrumented network compromise — modified Havoc Demons burrowed across endpoints, legitimate RMM tools repurposed as silent backdoors, and a registry-based C2 fallback ready to recover even if primary infrastructure is sinkholed. The speed of the operation, initial access to nine endpoints inside eleven hours, leaves little ambiguity about the intended outcome: ransomware, data exfiltration, or both. The inconsistency between the two loader implementations hints at an operator still refining their toolset, but inconsistency does not mean ineffectiveness. Organizations that rely solely on endpoint detection to catch this class of attack are already a phone call behind. The defensive perimeter starts with the user, and it has to hold before the first remote session is ever approved.