Alanna
River

NeedyMantis malware: How a modular toolkit supports targeted intrusions

Alanna River

Sep 29, 2026

6 min read

NeedyMantis malware

TL;DR

NeedyMantis malware is a modular toolkit deployed after attackers gain access to an environment. Observed targets include telecommunications organizations, universities, medical nonprofits, intergovernmental organizations, and government contractors. Its loaders, encrypted archives, DLL sideloading, and WebSockets communications support continued access and additional capabilities. Storm-3069 is one observed operator, but attribution remains incomplete. For defenders, the priority is finding suspicious behavior inside apparently legitimate software activity. Teams should examine unusual application launches, unexpected network connections, and unauthorized persistence. They should also restrict unnecessary software and prepare a tested containment workflow. Hexnode UEM can support application restrictions and compliance checks, while Hexnode XDR provides investigation and response controls. Neither replaces the work needed to establish an intrusion’s scope and remove the attacker’s access.

A familiar application name does not always mean familiar behavior. NeedyMantis malware uses legitimate software to launch malicious components after attackers have already entered an environment, with observed activity dating to at least October 2025.

The post-compromise malware combines several loading stages with encrypted archives and modular functionality. This gives defenders a practical challenge: investigating what trusted-looking programs actually load and do.

Who is Storm-3069?

Storm-3069 is a tracking designation used by Microsoft Threat Intelligence for activity associated with the DAEMON Tools supply-chain compromise. It is one observed operator of NeedyMantis. The activity is assessed as originating from China, but it has not been attributed to a Chinese nation-state actor.

The distinction matters: an assessed operating location does not establish government sponsorship. Additional NeedyMantis activity also leaves open the possibility of multiple operators. Defenders should therefore avoid treating the malware name as proof of a single group’s involvement. Use the designation to organize relevant intelligence, while grounding response decisions in evidence from affected systems. Public reporting does not establish a complete history of this operator’s targets or methods.

What happened?

The confirmed picture

Area Verified details
Timeline Observed activity dates to at least October 2025.
Affected sectors Telecommunications, universities, medical nonprofits, intergovernmental organizations, and government contractors.
Deployment DAEMON Tools was involved in the initial supply-chain compromise associated with Storm-3069. This does not establish direct supply-chain distribution of NeedyMantis itself. Attackers typically introduce the toolkit after obtaining access. A single initial-access method has not been established across intrusions.
Software abuse Poedit, curl, Vim, and TightVNC were legitimate binaries leveraged post-compromise for local DLL sideloading. Other components used DLL names or paths resembling established vendors’ software.
Loading sequence A sideloaded DLL extracts another loader from a custom archive. Subsequent stages decode and decompress executable components.
Operator communications WebSockets C2 supports communication with attacker infrastructure and commands for additional modules.
Persistence An older analyzed archive contained a module using Windows services.
Uncertainty Discovery through the DAEMON Tools investigation does not establish direct supply-chain distribution of NeedyMantis itself.

Why the loading chain matters

DLL sideloading involves a legitimate executable loading a malicious library. Investigators should therefore examine the relationship between the application, its loaded components, and their locations.

In this case, encrypted and compressed archives, obfuscated strings, and anti-debugging techniques complicate analysis. However, these features do not make the malware undetectable. They make it important to examine execution behavior alongside file indicators.

The main component also supports additional modules. Consequently, identifying the initial loader should begin a wider investigation into what else executed on the device.

What the evidence does not establish

The available findings do not establish a campaign-wide phishing method, MFA bypass, ransomware deployment, or extortion demand. They also do not establish which sensitive records, if any, were stolen from each affected organization.

Avoid turning potential access into a confirmed data-loss claim. Responders should determine affected accounts, accessible resources, and evidence of collection or transfer separately.

Why this matters

Security teams need to distinguish an approved application from an approved execution chain. A recognizable program can still warrant investigation when it loads unexpected files or contacts unfamiliar infrastructure.

For targeted intrusions, focus on relationships: which account launched the process, where its components came from, and what happened next. File hashes help, but they should complement behavioral investigation rather than define its entire scope.

Device, identity, and access controls also need to work together. Limit unnecessary software and privileges, review access from affected systems, and investigate suspicious sessions. MFA remains valuable, but teams should not treat a successful login as proof that the endpoint is safe.

Prepare containment procedures before an alert arrives, including who can isolate devices and preserve evidence.

cybersecurity-kit
Feature Resource

Cybersecurity kit

This resource kit will help your company adopt the right cybersecurity strategy to secure your business.

DOWNLOAD KIT

How Hexnode can help

Hexnode UEM: Restrict unnecessary applications and identify policy gaps

Hexnode UEM supports application blocklisting and allowlisting on supported Windows devices. Administrators can define executable rules using publisher or file-path conditions.

Use these controls to restrict unapproved remote access utilities and reduce unnecessary applications. Test policies against business requirements before wider deployment.

Application Compliance provides a separate assessment of installed software against configured lists. On supported Windows devices, it can identify application-related noncompliance, but it does not itself block execution or installation.

These controls support software governance. They should not be described as automatic detection of malicious DLLs loaded by an approved executable.

While allowlisting stops unauthorized binaries from executing, an allowlisted application can still run a sideloaded DLL in its execution path, highlighting the need to pair UEM application controls with XDR behavioral monitoring.

Hexnode XDR: Investigate endpoint activity and contain affected devices

Hexnode XDR provides endpoint investigation and response capabilities, including process analysis, process termination, kill process tree, file quarantine, and endpoint isolation. Isolation retains communication with the XDR console for continued response.

For suspected compromise, analysts can use these capabilities to investigate activity and contain affected endpoints while determining the wider scope.

This is a capability-based positioning, not a claim that Hexnode XDR has a verified NeedyMantis-specific detection. Teams should validate relevant detection coverage, agent deployment, and response permissions in their environment.

What security teams should do next

Treat a suspicious loader as a starting point for investigation. Establish when it appeared, which account introduced it, and which processes or connections followed.

Then search for related activity across other endpoints. Review unexpected services, unfamiliar application directories, and remote administration activity that lacks a business explanation. Preserve relevant evidence before deleting files or rebuilding systems.

Contain confirmed affected devices through your incident-response process. Investigate exposed accounts and sessions, and address the original entry point before returning systems to service. A removed file alone does not demonstrate that access has ended.

Hexnode UEM can support tighter application policies, while Hexnode XDR provides investigation and containment controls. Use those capabilities within a response process that assigns clear owners and recovery criteria.

Start by testing whether your team can trace an unusual application launch, isolate its endpoint, and verify recovery without losing the evidence needed to understand the intrusion.

Share

Alanna River

I’m a technical content writer at Hexnode who loves simplifying tech. I break down complex ideas, remove the fluff, and help readers clearly understand our product for what it actually is: simple, reliable, and built to solve real problems.