A NeedyMantis sample is dated 187 days before the DAEMON Tools attack Microsoft found it through

The malware came first, the supply chain attack later

Microsoft's indicator table for NeedyMantis dates its earliest sample, a file archive named libcurl, to 3 October 2025. Kaspersky says DAEMON Tools installers were trojanised from 8 April 2026. Count the days between them and you get 187. Microsoft found NeedyMantis by pivoting from Kaspersky's DAEMON Tools indicators, so the malware predates, by six months, the incident it was discovered through.

That matters for one practical reason. Kaspersky's advice to DAEMON Tools users was to examine machines for abnormal activity "on or after April 8". That is the right advice for the supply chain compromise. It is the wrong window for NeedyMantis, which Microsoft's post of 28 September 2026 says has activity dating back "to at least October 2025".

Here is what the 187 days do not establish. A first-seen date is when a sample first reached Microsoft's view, not when it was built or first used, so the true start may be earlier still. It does not show that the October 2025 sample was used by the same operator as the DAEMON Tools campaign: Microsoft says it has not determined whether all NeedyMantis activity belongs to one actor. It does not say who that earlier sample was used against, or where. And Microsoft says it has not seen NeedyMantis itself delivered through the DAEMON Tools compromise. The link between the two is the investigation that found the malware, not a delivery chain anyone has shown.

What Microsoft published

Microsoft Threat Intelligence describes NeedyMantis as a modular post-compromise malware family: in one line, it is used to keep long-term access to a network an attacker is already inside, and it can load further modules whose capabilities, Microsoft says, "remain unconfirmed". It has been seen in a limited number of targeted operations against telecommunications organisations, universities, medical nonprofits, intergovernmental organisations and government contractors.

Microsoft names one operator, Storm-3069, its designator for activity associated with the DAEMON Tools supply chain compromise. It assesses that the activity originates from China but says it has not attributed Storm-3069 to a Chinese nation-state actor. It has also seen NeedyMantis activity beyond Storm-3069's DAEMON Tools campaign, which it reads as a sign that more than one operator may use the malware.

In one incident Microsoft describes, the operator used the Impacket toolkit during hands-on-keyboard activity to copy the software, the malicious DLL and the archive from a network share onto the target. That is the only delivery route the post documents, and it happens after access has already been gained.

The DAEMON Tools side comes from Kaspersky's report, which Microsoft cites. Kaspersky found signed installers for DAEMON Tools versions 12.5.0.2421 to 12.5.0.2434 trojanised from 8 April 2026, published on 5 May, and recorded on 6 May that the vendor had released 12.6.0.2445 without the malicious behaviour. It saw several thousand infection attempts in more than 100 countries and territories, but the more complex backdoor on only about a dozen machines, in Russia, Belarus and Thailand. We have not covered the DAEMON Tools compromise before on this site.

What the dates establish, and what they do not

Dates from Microsoft's indicator table and post, and Kaspersky's report. Arithmetic ours.

Date on the record	What it establishes	What it does not establish
3 Oct 2025: libcurl archive first seen (Microsoft)	A NeedyMantis sample existed 187 days before the first trojanised DAEMON Tools installer	Who used it, against whom, or whether it was the same operator
8 Apr 2026: installers trojanised from this date (Kaspersky)	Start of the DAEMON Tools compromise window	That NeedyMantis was ever delivered by it; Microsoft says it has not seen that
5 May 2026: Kaspersky publishes	Discovery about four weeks after the first bad installer (27 days)	Anything about NeedyMantis, which Kaspersky's report does not name
21 and 23 May 2026: WinSparkle loader and archive first seen	The analysed sample surfaced 16 days after Kaspersky's report, 43 and 45 days after 8 April	Whether it was used in the DAEMON Tools campaign or another operation
28 Sep 2026: Microsoft publishes	360 days after the earliest dated sample, 128 days after the latest	How long Microsoft has been tracking it before publication

Two readings follow, and only the first is established. The first: a hunt for NeedyMantis that starts on 8 April 2026 starts at least six months late. The second, which is inference: if the same operator had NeedyMantis in October 2025, the DAEMON Tools compromise was a later access method for an actor already running post-compromise tooling elsewhere, not the start of its operation. Microsoft does not say that, and its own caveat about multiple operators is a reason not to say it either.

A Windows name is not a Windows file

The analysed WinSparkle archive held 11 files. Microsoft lists seven as legitimate: four 7-Zip components, two Sysinternals components (Disk2vhd, and Ctrl2Cap stored as main.dll) and a genuine kernel32.dll. The other four carry the malware. Three of them wear Windows library names, dnsapi.dll, ws2_32.dll and msvcrt140.dll, and Microsoft's own descriptions begin "Not a dnsapi.dll", "Not a ws2_32.dll", "Not a msvcrt140.dll". The fourth, encryptbase64.ps1, has a PowerShell extension but contains shellcode.

This is the friendly-name fallacy in file form. A name a host already expects is not evidence of what the file is. The loader itself is WinSparkle.dll, the update component of the Poedit translation tool, and Microsoft lists other paths the malware has used, including dbghelp.dll under folders named office and broadcom in ProgramData, jli.dll under an Intel folder and nvml.dll, an NVIDIA name. A control that asks "is this a known library name?" passes all of them. A control that asks "is this file signed by the vendor whose name it borrows, and does it belong in this folder?" does not.

The label "post-compromise" deserves the same scrutiny. It is accurate, and Microsoft uses it precisely: the malware arrives after the attacker is in. It is not a reason to rank it lower. It means the thing to find is the intrusion that preceded it, which your controls have already missed once.

A browser nobody has shipped since 2013

The cheapest detection in the post is a string. Microsoft says the NeedyMantis communications DLL "has a hard-coded user-agent of firefox/21.0". Mozilla's release notes show Firefox 21 was first offered to release users on 14 May 2013, 13 years and four months before Microsoft published. Microsoft publishes hunting queries for the string in Defender XDR and Sentinel, the Sentinel one looking in CommonSecurityLog, which is where proxy and firewall logs usually land.

Four points decide whether that hunt works in your estate.

The same logic applies beyond this one string. An outbound HTTPS client that claims to be a browser released more than a decade ago is a hunting lead whatever malware is behind it, and it is one of the few signals here that does not depend on file names or hashes an operator can change.

The indicators Microsoft publishes

From the indicators of compromise table and hunting section in Microsoft's NeedyMantis post, 28 September 2026.

Indicator	What it is	First seen
e842dd7642c8e04b5ec20b6393848a9c904e4832930950c16664fe7800ba382e	SHA-256, first-stage loader WinSparkle.dll	21 May 2026
9cb68f986043a576e19d32184c583b7d8f571c7219d8dc0065dced1c13f077ef	SHA-256, WinSparkle file archive	23 May 2026
c82520eb03c084226be4eafbff46f56dca0aa8804a2a7f23a085a96afe71ef77	SHA-256, older libcurl file archive	3 Oct 2025
corp.tripswithengine[.]com	Command and control host	Not stated
Firefox/21.0	Hard-coded user agent string	Not stated

Three cautions. The C2 host has no first-seen or last-seen date in Microsoft's table, so a zero result says nothing about whether it was active in your look-back window. Microsoft says the archive's internal layout changes from sample to sample, so exact hashes will age quickly; treat them as confirmation, not coverage. And Microsoft's file-path hunting query looks for the known malicious DLL names inside specific application folders: useful, but only for the paths it lists.

What the post does not establish

Microsoft's NeedyMantis post and Kaspersky's DAEMON Tools report, read in full.

Question	Stated on the record	Not stated
Who operates it	Storm-3069 for the DAEMON Tools activity; assessed as originating from China	A nation-state attribution; Microsoft says it has not made one
One actor or several	Activity seen beyond Storm-3069's campaign	Whether all NeedyMantis activity is one operator
How many victims	A limited number of targeted operations, five sector types	Any count of victims or intrusions
UK exposure	Nothing; Microsoft names no countries	Any UK victim or UK sector
Use of the October 2025 sample	Activity dates back to at least October 2025	Against whom, where, or by whom
Initial access	One case of Impacket copying files from a share after access	How access was gained in any case
Module capabilities	Modules can be loaded and unloaded	What the modules do; Microsoft says unconfirmed

Kaspersky's geography is for the DAEMON Tools compromise, not for NeedyMantis: most infection attempts it saw were in Russia, Brazil, Turkey, Spain, Germany, France, Italy and China, and it does not list the UK. That is one vendor's telemetry, shaped by where its products are installed. It is not evidence either way about UK exposure to NeedyMantis.

Microsoft sells the products its post recommends, and much of the mitigation section is Defender configuration: cloud-delivered protection, EDR in block mode, attack surface reduction rules, Security Copilot. That is a commercial interest and worth naming. It does not weaken the parts a defender can use in any stack: the dates, the hashes, the C2 host, the file paths and the user agent string. Separate method from accusation here as well: Microsoft's China assessment and Kaspersky's note of Chinese-language strings are each vendor's reading of its own evidence, and neither vendor claims a named state actor.

What to do, in order

The question that matters

Every supply chain compromise arrives with a start date, and every incident response plan is tempted to hunt from it. NeedyMantis was on Microsoft's record 187 days before the compromise that led Microsoft to it. So the question for any security lead is not whether you checked your DAEMON Tools hosts from 8 April. It is this: when a vendor tells you the malware predates the incident, do your logs reach back far enough to look?

Key facts