Summary
On or around January 20, 2026, attackers who had broken into a regional update server for eScan, the antivirus product made by India's MicroWorld Technologies, pushed a trojanized Reload.exe through the legitimate update channel during a window of roughly two hours. The security software itself became the delivery vehicle for malware. The malicious binary carried eScan's code-signing identity, but its signature was actually invalid; it ran anyway because the updater trusted the channel rather than rigorously validating the signature. Once on a host, the malware rewrote the Windows HOSTS file to cut eScan off from its own update servers, blinded script scanning, and reached out to takedown-resistant command-and-control hosted on blockchain naming systems. Morphisec disclosed the campaign, with Kaspersky and Darktrace corroborating it independently.
How to fix it
- Enforce cryptographic signature verification on every update artifact on the client and fail closed on an invalid or missing signature; channel trust is not integrity.
- Protect the updater's own self-defense surface so freshly delivered code cannot silently disable updates via HOSTS or registry edits, and alert on tampering with your update domains.
- Harden and isolate the distribution servers as tier-0 assets (MFA, network isolation, file-integrity monitoring) so an "incorrect file" cannot be served.
- Because the malware blocks the update channel, ship an out-of-band removal tool; impacted users cannot be auto-remediated and must be reached directly.
How to avoid it in your code
- Treat security-tool update channels as high-value supply-chain risk and monitor outbound traffic even from trusted antivirus processes.
- Alert on HOSTS-file changes, especially entries that point your own security vendor's update domains at null or garbage addresses.
- Detect and block resolution of decentralized-naming proxies (.hns and .sol resolvers) and treat blockchain dead-drop and code-hosting "download" URLs as command-and-control indicators.
- Keep an out-of-band recovery path; never rely on an antivirus to remediate a compromise of that same antivirus.
Advisory details
How it happened
eScan's updater pulls components from regional distribution servers. Attackers compromised one such server and placed a malicious 32-bit Reload.exe into the distribution path, so only clients pulling from that cluster during the roughly two-hour window received it. This was a server-side breach, not a network man-in-the-middle. The crucial weakness is the same class that has burned other auto-updaters: the client trusted the origin instead of cryptographically enforcing a valid signature, so a binary that merely looked like it came from eScan (and in fact carried an invalid signature) was accepted and executed. It is a textbook supply-chain attack through the update mechanism, and it is the second time eScan's update channel has been abused (see the separate 2024 GuptiMiner campaign noted below).
The payload
Reload.exe kicked off three Base64-encoded PowerShell stages. The first dismantled eScan's defenses: it rewrote the HOSTS file to blackhole eScan's own update domains (for example pointing update1.mwti.net at a dead address), deleted remote-support tools, and added registry exceptions, so the antivirus could neither update nor self-heal. The second patched AmsiScanBuffer to blind Windows script scanning. The third validated the victim, checking installed software (notably for Kaspersky products) before deploying persistence. A 64-bit second stage, CONSCTLX.exe, acted as a backdoor and downloader, held persistence through a scheduled task disguised under the Windows Defrag path, and pulled further payloads. The most distinctive part was the command-and-control: rather than ordinary domains, the malware used decentralized, blockchain-based naming. It resolved Handshake (.hns) names through a proxy and used Solana (.sol) as a dead-drop, reading its current C2 address out of public Solana blockchain transactions. Because there is no registrar to serve a takedown, that infrastructure is far harder to seize; ironically, Solana's public ledger is what let Darktrace watch the attackers rotate their C2 on January 28.
Who was hit
No threat actor has been publicly named for the January 2026 event. Telemetry varied by vendor, since each only sees its own customers: Kaspersky reported hundreds of machines concentrated in South Asia (India, Bangladesh, Sri Lanka, the Philippines), while Darktrace's affected customers were in EMEA. eScan characterized it as a small subset of users and disputed the researchers' framing, calling the file a "corrupt update" and saying it found no evidence of additional payloads or data theft. Three independent research teams contradict that, documenting a working multi-stage downloader with live command-and-control. Where the vendor and the researchers disagree on severity, the documented C2 and persistence weigh toward the researchers.
Why it still matters
The irony is the point: software whose entire job is to protect the endpoint became the attacker's trusted delivery vehicle, the same dynamic seen in the Notepad++ update hijack and, years earlier, in ASUS ShadowHammer and SolarWinds. It also rhymes with eScan's own history: in 2024 the GuptiMiner campaign, disclosed by Avast, abused the same product's update mechanism, which at the time downloaded over plain HTTP with no signature verification, to deliver backdoors and a coin-miner; that flaw had reportedly existed for years before eScan fixed it. A 2026 server breach and a 2024 man-in-the-middle are different vectors, but the root failure is identical: an updater that does not fail closed on a missing or invalid signature. A valid signature, strictly verified on the client, is the one control that would have stopped both.
References
- https://www.morphisec.com/blog/critical-escan-threat-bulletin/
- https://www.bleepingcomputer.com/news/security/escan-confirms-update-server-breached-to-push-malicious-update/
- https://www.securityweek.com/escan-antivirus-delivers-malware-in-supply-chain-attack/
- https://www.darktrace.com/blog/how-a-compromised-escan-update-enabled-multi-stage-malware-and-blockchain-c2
- https://www.helpnetsecurity.com/2026/01/29/escan-antivirus-update-supply-chain-compromised/
Related vulnerabilities
All Supply chain →- HIGHSC-NOTEPADPP-CHRYSALIS-2025
In 2025, a Chinese state-linked espionage group hijacked the update channel of Notepad++, one of the most widely installed Windows text editors, to plant a custom backdoor on a handful of carefully chosen targets. The attackers never touched Notepad++'s source code or its signing keys. Instead they compromised the third-party shared-hosting server that delivered updates, and abused the fact that the WinGUp updater shipped without any integrity check on what it downloaded (tracked as CVE-2025-15556). For machines on their target list, WinGUp was silently redirected to attacker-controlled servers that served a trojanized installer; everyone else kept receiving the genuine update. The campaign ran from roughly June to December 2025 and was only made public in February 2026 by Rapid7, with Kaspersky and Broadcom/Symantec corroborating it independently.
- CRITICALCVE-2019-15107
Disclosed in August 2019, CVE-2019-15107 was an unauthenticated remote code execution backdoor in Webmin, a widely deployed web-based system administration tool that runs with root privileges. The backdoor existed in the password_change.cgi feature: a Perl qx() statement passed the unsanitized old (and in some versions expired) parameter from the password-change request straight to a shell, letting an unauthenticated attacker run arbitrary commands as root, with version 1.890 exploitable in its default configuration and 1.900 through 1.920 exploitable when password expiry was enabled. Critically, the malicious code was never present in Webmin's GitHub source, which remained clean; it was inserted directly into the build infrastructure that produced the official SourceForge release packages, so users who installed signed official builds were backdoored while anyone auditing the public Git source saw nothing wrong. Webmin later confirmed the code was added on its build server on two separate occasions, in April 2018 producing the 1.890 release and again in July 2018 reintroducing it into 1.900 through 1.920, meaning backdoored builds were distributed for over a year. The project released 1.930 on August 17, 2019 to remove the backdoor.
- HIGHSC-CCLEANER-2017
In September 2017, Cisco Talos revealed that CCleaner, a hugely popular Windows cleanup tool from Piriform (newly acquired by Avast), had been shipping a backdoor. Attackers had compromised Piriform's build environment and inserted malicious code into the official, validly code-signed installer, so version 5.33 distributed through Piriform's own channels carried the malware to about 2.27 million users for roughly a month before anyone noticed. The first stage merely profiled machines, but it was a sniper rather than a shotgun: from the millions of installs it served a second stage to only a few dozen selected computers at companies like Google, Microsoft, Cisco, Intel, and Samsung, and a still deeper espionage tool (the ShadowPad backdoor) was later found planted on Piriform's own internal machines. The attack is linked to the China-nexus group tracked as APT17 / Axiom. It is the lesson that a trusted update channel and a valid signature are not the same as trustworthy code, and that build pipelines are prime targets.
- CRITICALGHSA-93qj-5q5v-3c2h
Trojanized pantheon-agents 0.6.1 and 0.6.2 on PyPI ship a credential stealer (supply-chain account compromise)
- HIGHGHSA-xhcr-cqfr-m3hv
atomic-agents-stack: HTTP MCP catalog accepts cleartext http and spawns catalog-supplied commands (MITM to RCE)
- CRITICALNPM-REDHAT-MIASMA-2026
In June 2026 the npm supply-chain worm finally produced something genuinely new and frightening: malicious packages that were signed and carried valid build provenance. Attackers used a compromised GitHub account inside Red Hat's own organisation to publish trojanised versions of 31 packages in the @redhat-cloud-services namespace through Red Hat's legitimate CI pipeline, so the poisoned releases arrived with authentic attestations proving they were built by the real build system. The payload, nicknamed Miasma, was a lightly re-skinned copy of Mini Shai-Hulud, a worm that a group called TeamPCP had open-sourced for anyone to reuse weeks earlier. No Red Hat customers were harmed, because Red Hat strips install scripts before deployment, but the permanent lesson is uncomfortable: a signature proves where a package was built, not that the build was clean.