NinjaMare and the enterprise security epidemic hiding behind a harmless label

Intezer's research team has now published two pieces of original research into a category of software the security industry files under "potentially unwanted application", or PUA.

The PUA label means nuisance. Adware, toolbars, things that change your settings without asking.

Our findings say the label is wrong, and that the gap between what these applications are labelled and what they can actually do is one of the more serious unaddressed risks in enterprise environments today.

We think this constitutes an epidemic but instead it is being treated as a hygiene issue.

What we found: Beachheads, skimmers and puppeteers

Our previous investigation

In July we published research into two previously undocumented families, SilentMare and HollowMare, both delivered through paid search advertisements for everyday tasks like merging PDFs. HollowMare hijacks the browser to skim advertising revenue. SilentMare quietly asks its operator once a day whether there is anything to run, a beachhead of the kind access brokers sell to ransomware crews. Same advertisement, same download page, same PUA label, yet one costs you a browser setting while the other may already be listed for sale.

Our latest investigation

Recently we published a second piece on a family we named NinjaMare, and it is the more alarming of the two. A mistyped web address led an employee to a paid advertisement and a fake privacy browser, which the endpoint tooling never opened because the file was too large. Inside is a capability to remotely open any program and type into it, essentially a USB Rubber Ducky delivered over the internet, and it works only while the machine has been idle, hiding its window off screen. What we observed it doing is small. What it can do is unbounded, since its instructions live on the operator's server and can be rewritten at any moment. Fragments of the developer's own machine shipped inside the installer traced the operation back to January 2016.

Why we are calling this an epidemic

The following four measurements, none of them from our own customer telemetry, led us to this conclusion.

1. ‍The scale of the product catalogue. Across the two investigations we counted more than forty distinct branded applications from these operations. Not forty copies of one thing. Forty separately named, separately marketed products with their own websites and their own advertising. NinjaMare alone has appeared under names including PrivacyBrowse, SafeScan, StealthGuard, NetGuard, HushBrowse, GPTBrowser, CoolPDF and dozens more. This is being run as a business with a product line.‍
2. The massive traffic. Cisco publishes a daily list of the million most-visited domains on the internet. The server that NinjaMare contacts every time it runs has been appearing on that list, dropping off, and reappearing since December 2025. To come anywhere near a global top million, an enormous number of machines have to be contacting it. That is the closest thing to an install count that exists, and it is very large.‍
3. The persistent and clearly widespread curiosity. The installer is uploaded to VirusTotal, the industry's public multi-engine scanning service, every single day. Somebody, somewhere, keeps encountering this file and wondering about it. Every day it comes back clean.‍
4. A decade of zero detection. Ten years of continuous operation. This was not a sophisticated adversary evading a determined hunt. Their operational security was poor enough that they leaked their own laptop into their own product. They lasted ten years because nobody was looking.

Why PUA flies under the radar

This is the part worth a leadership team's attention, because none of it is an accident and none of it is easily fixed by buying another product.

The label describes the past, not the capability

"Potentially unwanted application" is a verdict on observed behaviour. It records what a piece of software has been seen doing.

Everything downstream treats it as a statement about capability. The endpoint product decides how loudly to alarm. The queue assigns a priority. The analyst decides whether it is worth an hour of their day. All of it flows from a word that only ever summarised history.

NinjaMare was seen changing search engines, so it earned nuisance-grade handling. What it possesses is a remote keyboard. Finding out which of those two things you actually have on a laptop requires somebody to sit down and take the software apart, which is precisely the work nobody has capacity for. So the label sticks, and the label determines the response.

Clean scan results are weaker evidence than the arithmetic suggests

The reason a clean result on VirusTotal carries so much weight is an assumption about independence. Around seventy vendors, seventy separate teams, seventy sets of tooling. Seventy independent experts cannot all be wrong at once.

They are not independent. Every vendor can see what every other vendor said about the same file, and each one faces an uncomfortable asymmetry when they disagree with the room.

Being the only engine flagging a widely used file is expensive if you turn out to be wrong. You have blocked legitimate software for a customer and you look careless. Being the last engine still calling something clean after a respected vendor has flagged it is worse. If it turns out to be malware, you look asleep. Being wrong alone costs far more than being wrong alongside everyone else.

So verdicts cluster. One influential vendor changes position and detection counts climb across the industry over the following days, sometimes with no new analysis behind the movement. It runs in the other direction just as often. A vendor calls something correctly, watches nobody follow, and quietly retracts. It is Pascal's Wager applied to malware classification, and the safe bet is always to agree with the consensus.

Nobody involved is being dishonest. This is a rational response to how the industry keeps score. But it means a file scoring zero out of seventy may reflect one original judgment that everyone else settled behind rather than seventy people independently reaching the same conclusion. Consensus feels like corroboration. Sometimes it is an echo.

We should be clear about where we sit in this, because the argument is worthless if we exempt ourselves. We here at Intezer run close to 200 million analyses a year, we are the most accurate file classification vendor in the world, and things still get past us. Volume is a large part of why. Nobody in this industry can hand-examine every file crossing their sensors, and the volume keeps climbing as attackers use AI tooling to produce more of them faster. Our research on how attackers are gaining access to LLM inference covers that pressure directly. It only moves in one direction.

A registered company proves almost nothing

There is a strong instinct to treat a real, registered company behind a piece of software as reassurance. It should be the opposite.

Registering a company is cheap and involves almost no verification of intent. What it buys you is access to every other trust mechanism. A registered company can obtain a code signing certificate, which is the digital seal telling Windows who produced a file. It can register as a Microsoft Store developer. It can open an advertising account. It can purchase commercial software protection tooling. It can pass the vendor due diligence checks that other organisations run.

In the first investigation we found signing certificates issued to companies with near-identical naming patterns, all registered in neighbouring cities. That pattern does not read as coincidence. It reads as a supplier, incorporating entities so that operators can buy legitimacy off the shelf. Some of those certificates were extended validation certificates, the tier specifically marketed as representing the highest level of vetting.

Registering a company also does the opposite of what most due diligence assumes. With the right corporate structuring, it obscures who is actually behind the operation rather than revealing them.

Trusted marketplaces are a distribution channel for this

NinjaMare is delivered using Microsoft's modern installation format. It installs through Microsoft's own installer interface, with clean publisher branding, and packages distributed through the Microsoft Store are signed by Microsoft's own infrastructure. When a machine checks the signature and follows the chain of trust upward, it arrives at a Microsoft root certificate.

Nothing malfunctioned. The signature proves the package came from the registered developer, which is exactly what it was built to prove. It was never designed to certify that the developer is honest.

This is not fixable and it is not new. It happens on mobile app stores, on desktop marketplaces, on package registries. A trusted distribution channel verifies identity and process. It does not verify intent, and there is a limit to how much of the latter any marketplace at scale can do.

Software protection tooling makes this harder to investigate

There is a legitimate industry selling products that stop competitors from copying or reverse engineering your software. Those products work by making programs difficult to inspect.

Malware packing works by making programs difficult to inspect.

At a technical level the overlap is substantial, because both are solving the same problem. What differs is intent, governance and how the product is sold. A commercial protection vendor may vet its customers, investigate abuse reports and remove bad actors, though there is an obvious commercial incentive against controls strict enough to put off legitimate buyers. With free and open source tooling that control may not exist at all.

The term "IP protection" describes an intended use. It does not describe a capability, and it says nothing about how the technology will actually be used. We encounter this constantly, and it slows down exactly the analysis that would separate the nuisance from the beachhead.

When people lack the right tools, they go and find their own

Every application in both investigations targets someone trying to finish a small, ordinary task. Merge two PDFs. Unzip a file. Convert a document.

The familiar version of this problem is that when an organisation does not provide the tools people need, they download their own, and what they download is disproportionately risky.

The version we find more interesting is the inverse. People frequently already have the capability, buried inside an enormous suite nobody has time to learn. They need one small function, cannot locate it, and go looking for a tool that does only that one thing. The free single-purpose utility that solves one problem in one click is precisely the category these operators have colonised, and that is why the advertisements are all for PDF mergers, file converters and zip tools.

That reframes the problem. Shadow IT reads as a discipline failure. Most of it is a usability failure, and it is one that can be influenced by asking people what they are downloading and why, rather than only blocking it after the fact.

General suggestions for improving things

• ‍Control how modern Windows packages get installed. NinjaMare arrives as an MSIX package, and most organisations have no policy on that format at all. Restricting sideloading and the App Installer protocol handler through Intune, AppLocker or WDAC closes the specific door this walked through.‍
• Block search advertising at the network or browser layer. Every infection chain in both investigations begins with an advertisement somebody bought. This is one of the few controls that breaks the attack before anything is downloaded, and almost nobody frames ad blocking as a security control.‍
• Stop treating the PUA category as a severity. It is a description of observed behaviour and it should not be driving triage priority on its own. The question worth asking of any flagged application is what it is capable of, not what it has been seen doing.‍
• Assume trust signals are purchasable. A valid signature, a registered company and a clean multi-engine scan are all inputs. None of them is a conclusion, and all of them have a price.‍
• Hunt the effects rather than the file. Default search engine changes, unexpected browser extensions, and any application that fetches its own interface from a remote server. Because NinjaMare's instructions never touch disk, memory analysis is the only place they can be observed.‍
• Get visibility into what people are installing, and why. The why matters as much as the what. A pattern of employees downloading single-purpose file utilities is a procurement and enablement signal, not only a policy violation.‍
• Look at what you are closing without reading. The investigation that produced all of this started with an alert that reported nothing was found. It became a ten-year campaign because one researcher refused to leave a file unclassified. Most organizations do not have that person available, which is an argument for making the depth of that examination automatic rather than exceptional.‍
• None of these applications belong in an enterprise environment. That was our conclusion in July and the September research strengthened it. Even the ones that function do their work on somebody else's server.

How Intezer helps with PUA alerts

Everything above describes a gap between what these applications are labelled and what they can actually do. Closing that gap means someone has to examine the software itself, and the reason nobody does is capacity. This is the problem Intezer AI SOC was built around.

Investigating the alerts nobody opens. PUA detections arrive as low or informational severity, which is the queue that never gets read. Part of that is time and part of it is money. Most AI security platforms charge per alert, so customers submit only their high-severity traffic and leave everything else dark. We charge per endpoint, which removes the reason to be selective. Every alert gets investigated regardless of severity, and the low-severity queue stops being a place things go to be forgotten.

Judging the code rather than its paperwork. We contend that signatures, company registrations and clean scan results are purchasable and that consensus verdicts are weaker evidence than they appear. Our core analysis method takes none of that as input. It compares every piece of code in a file or in a machine's memory against a large database of known trusted and known malicious code, and reports what the code is related to. A Microsoft signature does not make it quieter and forty other vendors calling something clean does not make it agree. The question it answers is what this software is built to do, which is the question the PUA label fails to answer.

Looking in memory, where this particular trick lives. NinjaMare's harmful instructions are never saved to the machine. They are downloaded fresh from the operator's server each time the application runs and exist only in the computer's memory. That is the single reason the detection count sits at zero. Nothing is scanning what is not on disk.

Our endpoint scanner examines machine memory directly, looking for code that has been injected, hidden or is running without ever having been written to a file. It runs automatically when an alert comes back without enough evidence to reach a conclusion, which is exactly what happened in this case. The alert reported that nothing was found because the file was too large to open. An empty result becomes a reason to go and look at the machine rather than a reason to close the ticket.

Automated hunt. Research like ours produces long lists of application names and server addresses. Turning that into an answer about your own environment normally means someone running searches by hand. We run an automated hunt across historical endpoint and SIEM data every week for newly published families and indicators, and it opens a case on any match. When forty branded applications get named, you find out whether any of them ever touched your estate.

Clustering events until the picture becomes clear. A questionable install today and unusual browser behaviour three weeks later are two alerts nobody connects. Our platform groups alerts that share a user, a device or an artifact into a single case, and that grouping stays open for as long as the case does rather than expiring after a fixed window.

Acting on the verdict. Once a verdict exists, response runs automatically according to your own rules. Close it in the source console, isolate the machine, block the domain, raise the ticket, notify the owner. No separate automation platform and no engineering project.

Learn more about Intezer AI SOC.

The research

• Two Trojan Families Trotting in Through Google Search Ads, July 2026
• Rubber Ducky in the Sky, September 2026