Microsoft’s NeedyMantis Report Turns Legitimate Filenames Into a Detection Problem

Microsoft Threat Intelligence published a technical analysis on September 28 of NeedyMantis, which it describes as “a modular post-compromise malware family observed in a limited number of targeted operations.” The origin story is what drew the headlines: Microsoft found the family while pivoting from Kaspersky’s research into the DAEMON Tools supply chain compromise, and one of the operators using it is Storm-3069, Microsoft’s designator for that campaign. SecurityWeek headlined its coverage “Daemon Tools Hackers’ NeedyMantis Malware Dissected by Microsoft.”

That shortcut hides something that matters. In its Microsoft Security Blog post, the company says it “has not observed NeedyMantis itself being distributed through a supply chain compromise.” What the report documents instead is malware built to sit inside copies of legitimate programs, to name its parts after ordinary libraries, and to reach its operators over HTTPS on port 443 and WebSockets. That makes the story less about one poisoned installer and more about how defenders recognize an implant when every file it uses looks familiar.

What Microsoft Published, and What It Left Open

Microsoft says NeedyMantis has appeared in intrusions affecting telecommunications organizations, universities, medical nonprofits, intergovernmental organizations, and government contractors, and that its activity “dates back to at least October 2025.” Combined with the malware’s limited observed deployment and its alignment with activity Microsoft associates with China-based actors, that victim mix “suggests NeedyMantis is deployed selectively rather than broadly.”

On attribution, Microsoft is careful. It calls Storm-3069 its “designator for activity associated with the DAEMON Tools supply chain compromise,” says it assesses the activity “originates from China,” and says it “has not attributed Storm-3069 to a Chinese nation-state actor.” It has also seen NeedyMantis activity beyond Storm-3069’s, “indicating that the malware might be used by more than one operator,” and says it “has not determined whether all observed activity is attributable to the same threat actor or whether multiple actors have access to the malware.” One of the Defender for Endpoint alerts in its detection table for Storm-3069 tradecraft reads “Suspicious activity linked to an emerging threat actor has been detected.”

The DAEMON Tools campaign has now been described by three vendors in three vocabularies, and it is easy to conflate them:

Neither Kaspersky’s report nor the Google post cited here mentions NeedyMantis, and Microsoft’s post does not map the family onto either vendor’s payload names. Kaspersky’s write-up covers the trojanized installers and what they pulled down. Microsoft’s covers what it found by following Kaspersky’s indicators outward.

The Supply Chain Compromise Is Not How NeedyMantis Arrives

Kaspersky’s account of the DAEMON Tools compromise is the backdrop. It found that installers on the developer’s legitimate website, “signed with digital certificates belonging to DAEMON Tools developers,” had been “trojanized starting on April 8, 2026,” affecting versions 12.5.0.2421 to 12.5.0.2434. It counted several thousand infection attempts across more than 100 countries but saw further-stage payloads on only about a dozen machines, at retail, scientific, government, and manufacturing organizations, which it took as a sign the operation was targeted. Detection took about a month, and the developer’s release 12.6.0.2445 no longer includes the malicious behavior.

Google’s threat intelligence group put such cases in perspective in a July 30 post, assessing “with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare,” and describing the few 2025 and early 2026 cases as “predominantly cyber espionage incidents with intentionally limited targeting scopes.” Its list of examples includes the DAEMON Tools installers.

Microsoft’s framing of NeedyMantis fits that picture of scarce, deliberate access. The malware “is typically deployed after a threat actor has already established access to a target environment,” it says, so “the methods used to gain access before NeedyMantis is deployed may vary across intrusions.” It adds that “supply chain activity remains one possible means by which an actor could gain the access necessary to deploy the malware.”

The dates are worth lining up. Microsoft’s indicator table lists first-seen dates of October 3, 2025 for the older archive named libcurl, and May 21 and May 23, 2026 for the loader and archive from the analyzed WinSparkle sample. The trojanized installers began on April 8, 2026, about six months after the earliest indicator. Microsoft does not say which operator used the October 2025 sample, so this is not evidence that Storm-3069 held the toolkit before the supply chain attack. It does show that the family predates the incident that led researchers to it.

For anyone who ran an affected DAEMON Tools build, the practical reading is narrow but real. Nothing Microsoft published says NeedyMantis was present on machines that received the poisoned installers. But Kaspersky’s advice was to examine machines with DAEMON Tools installed “for abnormal cybersecurity-related activities that occurred on or after April 8,” which points at follow-on activity rather than at the installer alone, and NeedyMantis is an example of follow-on tooling engineered to look like ordinary software.

How the Infection Chain Works

Microsoft describes four steps: a sideloaded first-stage loader, an encrypted file archive, a shellcode second stage, and a main component that handles command and control (C2) and extra modules. The components are “written in C++ and x64 shellcode.”

A Copy of a Real Program Brings the Loader Along

Microsoft says the malware starts with a first-stage loader and a file archive that “have been found packaged alongside legitimate software,” with the loader posing as a DLL the program needs and getting loaded through DLL sideloading. It names Poedit (translation), curl (data transfer), Vim (a text editor), and TightVNC (remote access) among the programs abused, and has also seen NeedyMantis masquerading as Microsoft Office, Broadcom, Intel, and NVIDIA DLL components. In the analyzed sample, the malicious file replaced WinSparkle.dll, the software update component of Poedit. The archive is named after the loader DLL without its extension, such as WinSparkle or libcurl.

The delivery step Microsoft observed is mundane. In one incident, an operator who already had access used the Impacket toolkit during hands-on-keyboard activity “to copy the legitimate software, malicious DLL, and file archive from a network share and execute it on a targeted device.” The operator brought the whole bundle, including the real program that would do the loading.

Microsoft lists “some of the DLL path names used by the malware”:

As I read the list, the pattern is a plausible-looking folder paired with a DLL name that some program might really load, which is why a directory listing on an infected host does not look alarming by itself.

An Archive Where Seven of Eleven Entries Are Real

NeedyMantis’ archives use “an encrypted and compressed custom file format.” The outer layer is XOR-decoded and decompressed with the Windows RtlDecompressBuffer function, and each entry’s name is XOR-decoded as well. Microsoft notes that “the file format’s offsets, XOR keys, and values change from sample to sample,” which limits how long a signature for the format can stay useful.

The analyzed WinSparkle archive held 11 entries:

Seven of the eleven entries are real software: four 7-Zip components, two Sysinternals utilities, and a genuine kernel32.dll. Only four do the malware’s work, and three of those are named for libraries they are not. Microsoft does not say why the real components are packed in. My reading is that one effect is that anyone listing the archive’s contents sees mostly names they recognize.

An older archive, named libcurl, held only four files: a configuration (300.c), a WebSockets-based communications DLL (300.s), a persistence module that uses Windows Services (is), and the main component (m.l). Between the two versions the names moved from opaque to imitative. Microsoft does not comment on the change; my reading is that it is the direction you would expect if the authors anticipated reviewers reading file listings.

A Second Stage With the Wrong File Extension

In the analyzed sample, the second-stage loader was encryptbase64.ps1. “Despite its .ps1 PowerShell extension, the file contains x64 shellcode,” Microsoft writes. Its job is to decode and decompress an embedded binary that becomes the main component. It finds its encoded data and XOR key “at calculated offsets, which change from sample to sample,” resolves Windows APIs from hashes using a rotate-right (ROR) algorithm with a configurable rotation value (11 in the analyzed sample), and produces a DLL in “a custom executable file format,” which Microsoft describes as “a minimized version of a PE file.”

The first-stage loader and the main component hide their strings as what Microsoft calls “obfuscated stack strings,” and the first-stage loader adds two anti-debugger checks, one based on ProcessDebugFlags and one using ThreadHideFromDebugger. The .ps1 extension is a label rather than a format, so reasoning about the file by its name would point the wrong way.

Command and Control That Leans on Ordinary Protocols

One Configuration File and a Hard-Coded Browser String

The configuration lives in a file named dnsapi.dll that is not a Windows library but a 3,448-byte binary structure. It names the communications component (ws2_32.dll), the C2 port (443), the C2 host (corp.tripswithengine[.]com), the C2 URI (/library/zip/), and sleep-time values.

The communications DLL has one export, SystemInfo, which “exposes 10 functions for the main component to initiate and maintain a WebSockets connection with the C2.” It uses WinINet APIs and has “a hard-coded user-agent of firefox/21.0.” A second version of the DLL, spotted in another archive, implements the same API with Libwebsockets instead of WinINet.

Firefox 21 is not a recent browser. Mozilla’s release notes say it was first offered to release-channel users on May 14, 2013, so the browser the string claims to be is more than thirteen years old. It is one of the two network artifacts in Microsoft’s hunting queries, alongside the C2 domain. Microsoft states the hard-coded string only for the WinINet-based version and says nothing about whether the Libwebsockets variant sends the same one, so a search on that string may miss variants.

A Beacon in a Cookie Header, Then WebSockets

The first contact is an HTTPS GET request. System information rides in the Set-Cookie header as Base64-encoded, compressed JSON: Microsoft lists the computer name, the username, and encoded fields for the process name, parent process, files in the ProgramFiles directory, and a process list. The connection then converts to WebSockets and continues with a binary protocol whose 44-byte header carries a 16-byte XOR key, a command number, and data lengths. Data is compressed and optionally encrypted with RC4.

The opening messages are a key exchange. The client sends an RC4-encrypted 256-byte buffer that starts with the text google.com, and Microsoft says the C2 server “presumably checks the RC4 encrypted google.com buffer.” The client also picks a random command number between 1 and 45, which the server sends back as an acknowledgement.

A Handful of Commands and a Plug-In Slot

The main component recognizes only a few commands. It sends the computer name and username (1110), a hard-coded identifier such as 20001 (1112), and keep-alives (1150). From the server it accepts commands to load a module (1020), unload a module (1030), dispatch data to a module (1050 or 1150), and turn off active flags (1070). Microsoft says those commands “show that NeedyMantis can extend its functionality through additional modules, but the capabilities of those modules remain unconfirmed.”

That is the largest gap in the public record. The main component is a thin door, and what matters to a victim is what comes through it.

Why Filenames Are the Wrong Thing to Trust

DLL sideloading works because of how Windows finds libraries. Microsoft’s documentation says that when an unpackaged app loads a module without specifying a full path, “the system searches for the DLL at load time” in a defined order. With safe DLL search mode enabled, which is the default, that order starts with DLL redirection, API sets, manifest redirection, the list of DLLs already loaded, and the Known DLLs list, and continues with “the folder from which the application loaded” ahead of the system folder. The page carries its own warning: “If an attacker gains control of one of the directories that’s searched, then it can place a malicious copy of the DLL in that folder.”

NeedyMantis does not need a vulnerable program to exploit, because it brings its own. The operator puts a complete, legitimate application next to the malicious DLL, and the application does the loading. That has three consequences for defenders.

• The executable is a genuine program. Anything that judges the process by its identity has little to object to. The malicious content is the DLL, and the tell is that a program loaded a library it should not have.
• Name-based rules need a location to go with the name. That is how Microsoft’s first hunting query is built: a list of folder and filename pairs. It can also match a genuine Poedit installation, so a hit is a lead rather than a verdict, a point The Hacker News also makes: WinSparkle.dll is a normal part of Poedit, so a file found there should be compared with the published hash.
• The format is built to drift. Offsets, XOR keys, and values change from sample to sample, and archives differ between versions. Behavior is more stable than file contents, and Microsoft’s own alert names describe behavior: “Suspicious DLL loaded,” “An executable file loaded an unexpected DLL file,” and “Suspicious decode command.”

What Defenders Can Do Now

Microsoft’s Guidance

Microsoft’s recommendations are to:

• look for outbound connections in network egress traffic to corp.tripswithengine[.]com, a step that does not depend on any Microsoft product;
• turn on cloud-delivered protection and block at first sight;
• run endpoint detection and response (EDR) in block mode;
• enable network protection in Microsoft Defender for Endpoint;
• configure automatic attack disruption in Microsoft Defender XDR; and
• turn on two attack surface reduction rules: “Block executable files from running unless they meet a prevalence, age, or trusted list criterion” and “Block execution of potentially obfuscated scripts.”

Microsoft Defender Antivirus detects the malware as TrojanDropper:Win64/NeedyMantis and Behavior:Win64/NeedyMantis, and flags the toolkit used to copy it as HackTool:Win32/Impacket. The report also publishes three Defender XDR advanced hunting queries (folder and filename pairs, the C2 domain, and the user agent) plus two Microsoft Sentinel queries for the domain and user agent.

Four Adjustments Worth Making

These are my suggestions, not Microsoft’s.

1. Widen the lookback. All five published queries use a seven-day window, while the indicators Microsoft lists were first seen on October 3, 2025 and May 21 and 23, 2026. Microsoft’s documentation says advanced hunting explores up to 30 days of raw Defender XDR data, and that longer history requires a Sentinel workspace with longer retention or streaming the data elsewhere. Change the window to the longest your data allows:

// The published Defender XDR queries include:
| where Timestamp > ago(7d)

// Widen it to what your data retains, for example:
| where Timestamp > ago(30d)

Then run the domain and user-agent searches against whatever longer history you keep in proxy, DNS, and firewall logs.

2. Treat path hits as leads. Compare any WinSparkle.dll (or other listed DLL) with the published SHA-256 values, and look for a sibling file with the same name and no extension. Microsoft says the archive is named after the loader DLL without the extension, so an extensionless WinSparkle beside WinSparkle.dll is a further lead.

3. Hunt the pattern, not only the names. The list of nine paths will age faster than the behaviors it stands for: an executable loading a DLL from an unexpected folder, a decode step inside that process, and Impacket-driven copying from a network share.

4. If you ran an affected DAEMON Tools build, update to the fixed release (12.6.0.2445, per Kaspersky) and follow its advice to examine those machines for abnormal activity since April 8.

What Is Still Unknown

• What the modules do. Microsoft says their capabilities “remain unconfirmed.”
• Who else uses it. Microsoft says the malware “might be used by more than one operator” and has not determined whether all activity comes from one actor.
• How the newer version persists. Microsoft describes a persistence module, is, which uses Windows Services, only in the older libcurl archive. It does not say how the analyzed WinSparkle sample stays on a machine, a gap The Hacker News also notes.
• Whether it is still in use. The indicator table lists identical first-seen and last-seen dates for each file, and the report does not say whether the malware remains active.
• What links Storm-3069 to NeedyMantis beyond the pivot. Microsoft describes the discovery as follow-on analysis of indicators associated with Kaspersky’s investigation, and says at least one threat actor using the malware is Storm-3069.

The Host Does the Work

A cuckoo does not build a nest. It lays an egg in one that already exists and lets the host do the work. NeedyMantis borrows a trusted program the same way, and the operator’s skill lies in choosing hosts and names that no one thinks to question.

The same instinct shows up in other ecosystems this site has covered. ChainDrop rewrote the published tarballs of npm packages while leaving their source code clean, a separate npm campaign put its loader in runtime code instead of install scripts, and a WordPress backdoor installed itself as a must-use plugin disguised as a health-check tool. None of those uses NeedyMantis’ techniques, but the defensive lesson rhymes. Asking whether a file looks legitimate is the wrong test when the attacker has spent the effort to make it look legitimate. The better question is whether it belongs where it is.