AI Malware: 97% of Samples Never Reached Production

A new analysis of 405 AI-related malware samples found a much smaller real-world footprint than the volume of public samples suggests. Unit 42, Palo Alto Networks' threat research team, found only 12 of the samples on protected production endpoints, while roughly 97% appeared only in research repositories, sandboxes, or security-testing environments.

That does not make AI malware harmless. It points to a more useful distinction: artificial intelligence is already helping attackers create and package malicious software, but the available evidence does not yet show that AI has made those programs unusually difficult for established security controls to detect.

The 405 samples tell a different story from the headlines

Unit 42 built its dataset from 405 unique SHA-256 hashes gathered from WildFire analysis reports, VirusTotal Intelligence, and published open-source research. The researchers deliberately used a broad definition of AI-related malware, including samples where artificial intelligence was part of the malware itself, its delivery mechanism, or simply its branding. That means the dataset includes genuine malicious code alongside proof-of-concept research and conventional malware disguised as AI software.

When the researchers checked those samples against Palo Alto Networks telemetry, only 12 appeared on non-test Cortex XDR-protected endpoints. That represents 3% of the dataset. Another roughly 15 to 20 unique samples appeared in WildFire network sessions, but the researchers found no evidence that the remaining samples reached customer endpoints or crossed customer firewalls.

There is an important limitation here: this is not a measurement of every AI malware sample circulating on the internet. The endpoint and network telemetry covered activity from December 2024 through June 2025 and came from Palo Alto Networks' own visibility. The 97% figure therefore describes this selected dataset and this telemetry, not the percentage of all AI malware worldwide that is harmless or inactive.

Why so much AI malware never reaches a real victim

Unit 42 found three broad reasons for the large gap between public samples and production activity. The first was proof-of-concept code created to demonstrate an attack technique rather than compromise a real organization. Some samples targeted local systems, contained obvious debugging information, or used test parameters that would make little sense in an actual criminal operation.

The second group came from security validation. Companies and security teams deliberately submit malware samples to testing platforms to check whether their defenses can identify them. A file can therefore appear repeatedly in VirusTotal or sandbox telemetry without ever being deployed by an attacker against a victim.

The third group is more immediately relevant to ordinary users: malware that uses the popularity of artificial intelligence as a lure. An installer can advertise itself as an AI application while delivering conventional malware underneath. In these cases, the AI connection is primarily social engineering rather than a new technical capability.

AI malware is real, but AI is not automatically an evasion tool

The production samples provide a useful test of what AI actually changes inside an attack. Unit 42 says the samples that reached protected environments were detected using familiar mechanisms such as behavioral analysis, sandboxing, code-signing anomaly detection, and file entropy analysis. In other words, the security software did not need a completely new detection category simply because some of the code had been created or packaged with AI assistance.

This matters because malware ultimately has to perform actions on a computer. It may be generated faster, written by a less experienced attacker, or modified repeatedly with the help of a large language model, but it still has to create processes, access files, modify settings, communicate with other systems, establish persistence, or perform other observable operations. Those behaviors give defensive systems signals to analyze.

The research therefore separates two questions that are often combined. AI can change how quickly malicious code is produced, but faster development is not the same thing as successful intrusion. The evidence in this dataset suggests that the second problem remains difficult when the target has layered endpoint and network defenses.

FunkSec shows where AI can make attackers faster

FunkSec ransomware provides the clearest example of AI's potential effect on development speed. Unit 42 identified seven FunkSec variants on production endpoints, with the builds compiled between January 1 and January 6, 2025. The variants shared a Rust codebase and included project paths such as Dev.pdb, Funksec.pdb, Darkzone.pdb, and Darkfunk.pdb, suggesting rapid iteration around the same underlying project.

Unit 42 considers the seven builds appearing within six days consistent with large language model-assisted development. That is an assessment, not proof that an AI model wrote every part of FunkSec. The more defensible observation is that AI-assisted programming could reduce the time needed to modify an existing malware codebase, allowing attackers to produce variations faster than a traditional manual workflow.

The ransomware still behaved like ransomware. Its observed techniques included attempting to disable Windows Defender, deleting volume shadow copies, and changing the desktop wallpaper to display a ransom message. All seven variants were classified as malicious by WildFire, and Cortex XDR generated alerts for every variant that executed on a protected endpoint.

An AI-themed application reached more than 50 organizations

The most widely encountered sample in the dataset was not a sophisticated autonomous malware agent. It was an NSIS installer masquerading as a recipe application called Recipe Lister. The file used a code-signing certificate issued to Global Tech Allies Ltd., although that certificate has since been revoked, and the installer extracted a JavaScript backdoor from a temporary directory when executed.

Unit 42 observed the sample across more than 50 organizations and recorded more than 6,500 endpoint profile records and 9,600 XDR alerts during its observation window. The large number is significant because it shows that AI-themed branding can be an effective lure even when the malware itself does not depend on AI to operate.

The defense also illustrates why a single security control is not enough. The legitimate-looking signature could make simple static checks less useful, while behavioral analytics noticed that the signer was unusual within the organization and that the file had extremely high entropy, a characteristic often associated with packed or encrypted content. Cloud sandbox analysis then supplied another layer of evidence, and Unit 42 says the protected environments blocked the binary rather than allowing successful execution.

Attackers are also abusing trusted software names

Another production sample demonstrated a different problem: trust can be forged before the malware even starts running. Unit 42 found an installer masquerading as Dropbox software and carrying an Authenticode signature whose subject identified Dropbox, Inc. The file was not genuine Dropbox software; it dropped an AutoIt loader that side-loaded the Oyster, also known as CleanBoost, backdoor.

This is significant for defenders because a valid-looking publisher identity is not enough to establish that a program is safe. Organizations need to consider where software came from, whether its signer is expected, what the program does after launch, and whether its behavior matches the application it claims to be. AI can make malicious development faster, but the delivery problem still depends heavily on deception and abuse of user trust.

What security teams should take from the research

The practical lesson is not to create a separate defensive strategy for every program described as AI-powered. Existing layers remain valuable: endpoint monitoring can examine process behavior, network controls can inspect suspicious connections, sandboxes can execute unknown files in isolation, and application controls can restrict unapproved software. These controls address what malicious software actually does rather than relying only on how the attacker created it.

Organizations should also be careful about measuring risk from public malware repositories. A large number of files carrying AI-related labels can represent research projects, security testing, repeated submissions, ordinary malware using AI branding, or genuine criminal tools. Counting all of them as active threats can make the threat appear larger than the available operational evidence supports.

At the same time, dismissing the category would be a mistake. The FunkSec examples suggest that AI-assisted development can shorten iteration cycles, while the Recipe Lister campaign shows that AI branding itself can help persuade users to install malicious software. The security problem is therefore likely to grow first through scale and speed rather than through a magical ability to bypass every existing defense.

The next warning sign is not more AI malware samples

The more important metric to watch is whether AI-assisted malware begins succeeding against defenses that already stop conventional threats. That would be a meaningful change from simply seeing more proof-of-concept code, more VirusTotal submissions, or more malware using AI names in its filenames.

For now, the evidence points to a narrower conclusion. AI is lowering some of the barriers to malware development and helping attackers iterate quickly, but the 405-sample study did not find evidence that these AI-related samples required a new detection model to stop them. Security teams should therefore keep strengthening behavioral detection, application controls, sandboxing, identity protections, and monitoring while treating claims of autonomous or unstoppable AI malware with the same skepticism applied to any other security claim.