A Kill Chain Worth Understanding
In May 2026, Zscaler ThreatLabz identified a new malware family they're calling MLTBackdoor, delivered through a multi-stage infection chain that starts with something almost mundane: a ClickFix lure on an automotive-related web page. The visitor copies a block of text, pastes it into a Windows run prompt, and runs it without knowing what it does.
From there, the chain runs on its own: a hidden command creates a temp folder, downloads a compressed archive from that day's domain, extracts two files, decrypts the second-stage payload using a key stored in its own header, and sideloads the result through mpextms.exe, a legitimate, signed Microsoft Defender binary. Within moments, MLTBackdoor is running under the name of a Defender component, talking to its operators over what looks like routine Windows telemetry.
Zscaler assesses the malware is likely used by an initial access broker to establish a foothold ahead of ransomware deployment. What makes this kill chain worth understanding isn't any single exotic technique. At almost every stage, the attack doesn't get past a control. It passes through one.
Where the Stack Failed: Common Vulnerable Points
The infection starts with the user running the command, so there's no malicious attachment for a gateway to catch and no exploit for a scanner to flag in advance. The command is just shell utilities: create a folder, download a file, extract it, delete it, load a DLL, things an endpoint does all day. Security awareness training teaches users to spot a bad link or attachment. ClickFix delivers neither.
Once the archive lands, MLTBackdoor reuses the filename endpointdlp.dll and loads itself through mpextms.exe. Application allowlisting and code-signing checks verify that the binary doing the loading is trustworthy, and mpextms.exe passes honestly: it's a real, signed Microsoft component. Those checks were never built to verify whether the DLL it loads next is the one it's supposed to load.
From there, obfuscation does the rest. About 95% of MLTBackdoor's code consists of mixed boolean-arithmetic operations that compute nothing, and its functions are flattened into state-machine loops with no resemblance to their original structure, defeating static signatures and behavioral matching alike. Most EDR platforms watch process behavior by hooking Windows API calls between application and kernel. MLTBackdoor builds its own syscall table and jumps straight to the kernel boundary, bypassing those hooks. The EDR doesn't fail to respond. It never receives the call.
Once established, MLTBackdoor talks to its C2 server over TLS on port 443, using a Microsoft-Delivery-Optimization user-agent and a telemetry-style path, each session encrypted under its own key exchange. To a SIEM, that's HTTPS on a standard port that looks like Windows Update. Even where hardcoded C2 domains exist, the malware also generates a new one daily, so a blocklist updated yesterday is already behind today's infrastructure.
Why Detection Can’t Close This Gap
Detection-based security works by recognizing what's bad: known-malicious hashes, known-bad domains, suspicious call sequences, network signatures that don't belong. At every stage above, nothing meets that bar. A signed Microsoft binary loading a DLL isn't bad. An HTTPS connection on port 443 isn't bad. A few shell commands extracting an archive isn't bad. A direct system call instead of a hooked one isn't even visible to most tools, let alone flaggable.
That's the structural problem. Detection requires the malicious action to look different from a legitimate one at some identifiable point, different enough for a rule, model, or analyst to draw a line. MLTBackdoor's obfuscation, sideloading, and traffic shaping are built to ensure that point never arrives. By the time the backdoor is established, with C2 access and the ability to load new capability into memory on demand, every step that got it there still looks routine. Nothing along the way was ever distinguishable from normal.
A Different Question: What If the Change Could Not Execute
Every stage above looks different under a different question: not “does this look malicious,” but “was this specific change authorized to happen.”
The ClickFix command sequence: a process spawned this way, performing this sequence of file and process operations, either matches what's authorized on this host or it doesn't, regardless of how the user was talked into starting it. The user's mistake stops mattering if the resulting actions were never approved.
The DLL sideload: the question isn't whether mpextms.exe is signed. It is. The real question is whether this specific DLL, by content rather than filename, is the one mpextms.exe is authorized to load here. A substituted file with a familiar name fails that check no matter which legitimate binary loads it.
The syscall-level evasion: if authorization is checked at the kernel layer, below where indirect syscalls land, it doesn't matter whether the request arrived through a hooked API or a raw syscall gadget. The kernel evaluates the operation against the baseline either way.
The disguised C2 traffic: the relevant question is whether this process is authorized to make outbound connections at all, a question answered before its user-agent, path, or encryption ever become relevant.
What This Means for the Stack Going Forward
None of MLTBackdoor's individual techniques are new. LLVM-based obfuscation, Hell's Gate-style syscall evasion, Cobalt Strike-compatible BOF loaders, and daily-rotating DGA infrastructure are documented and increasingly available off the shelf. What MLTBackdoor represents is how these techniques are now combined by default in tooling built for initial access brokers, built to be unremarkable across the stack at once.
Each technique here targets a specific assumption: that a signed binary's behavior is trustworthy, that usermode hooks see everything a process does, that port 443 traffic resembling Windows telemetry is background noise, and that today's threat intelligence covers tomorrow's infrastructure. None of those assumptions are unreasonable on their own. A kill chain engineered to satisfy all of them at once isn't an edge case. It's close to a template.
A Shift Worth Making
Every stage of this kill chain succeeded by looking like something the environment already permits: a signed binary loading a DLL, an HTTPS connection on a standard port, a process doing what processes do all day. The defenses in place weren't absent, and they weren't slow. They were answering a question this kill chain had already made irrelevant. The one that remains is whether any of these actions, however legitimate they appeared, were ever authorized to happen in the first place.
Sources
Dutta, Tushar Subhra. “Hackers Deploy MLTBackdoor Malware via Multi-Stage ClickFix Infection Chain.” Cyber Security News, June 10, 2026.
https://cybersecuritynews.com/hackers-deploy-mltbackdoor-malware/
Zscaler ThreatLabz. “Technical Analysis of MLTBackdoor.” Zscaler Blog, June 9, 2026.
https://www.zscaler.com/blogs/security-research/technical-analysis-mltbackdoor
