AI-Enabled Malware: What Defenders Need to Know

Artificial intelligence is changing how malicious software is produced, but research from Palo Alto Networks’ Unit 42 indicates that it has not yet fundamentally changed how that software behaves once it reaches a system.

In its analysis of AI-enabled malware, Unit 42 examined 405 unique samples associated with AI in some way. The dataset included code that used AI as a functional component, malware whose delivery mechanism involved AI, and conventional threats that merely adopted AI-related branding.

The organization’s central finding is a useful corrective to both alarmism and complacency: AI-enabled malware is real, but most samples in public repositories do not appear to represent active, production campaigns. Unit 42 found that 12 of the 405 samples appeared on Cortex XDR-protected endpoints, while approximately 97% were observed only in research repositories, sandboxes, or security-validation environments.

That distinction matters for defenders. The immediate challenge is not necessarily a wholly new malware execution model. Instead, AI appears to be lowering the effort required to create variants, assemble delivery components, and experiment with malicious functionality. The resulting files still expose many of the behavioral, structural, and delivery signals that established security controls are designed to identify.

What Unit 42 examined

Unit 42 assembled its dataset from WildFire analysis reports, VirusTotal Intelligence, and publicly available research. The collection criteria were intentionally broad. A sample could qualify because AI was part of its malware functionality, because it was used in delivery, or simply because AI branding appeared in its filename or installer.

This approach produced a mixed population rather than a list of confirmed operational threats. The research identified three broad groups:

• Proof-of-concept and research code: Demonstrations of AI-assisted ransomware, reconnaissance, or modular attack concepts. Unit 42 noted that some samples used test parameters, targeted localhost or private address ranges, included extensive debugging information, or appeared in research-oriented file paths.
• Security testing material: Samples submitted by breach-and-attack simulation platforms and internal security teams testing defenses against publicly discussed AI malware.
• AI-themed brand abuse: Conventional malware packaged to resemble popular AI software. In these cases, the AI reference functioned as a social-engineering lure rather than evidence of AI-assisted execution.

Telemetry provided by Unit 42 showed a substantial gap between public availability and production prevalence. The 405 samples were queried against Cortex XDR endpoint data from December 2024 through June 2025, WildFire session data from June 2024 through June 2025, and related alert and sandbox records. Twelve samples appeared on protected endpoints, and roughly 15 to 20 unique hashes appeared in WildFire sessions. Unit 42 reported that every sample that attempted to reach a customer environment was detected and blocked by Palo Alto Networks products.

These figures describe the visibility available to Unit 42’s telemetry and should not be interpreted as a measurement of all AI-enabled malware activity worldwide. They do, however, support the organization’s assessment that much of the current public sample volume reflects experimentation, testing, or research rather than confirmed deployment against defended production environments.

The production-observed samples

The 12 samples found on protected endpoints represented five malware families or delivery patterns. Together, they illustrate how AI can be associated with different stages of an attack without necessarily introducing a new execution primitive.

FunkSec ransomware

FunkSec was the most represented family in Unit 42’s endpoint data, with seven variants compiled between January 1 and January 6, 2025. Unit 42 reported that the samples shared a Rust codebase and used techniques including disabling Windows Defender through PowerShell and registry modifications, deleting volume shadow copies, and changing the desktop wallpaper to display a ransom note.

The binaries contained PDB paths using project names such as Dev.pdb, Funksec.pdb, Darkzone.pdb, and Darkfunk.pdb. Unit 42 assessed that the rapid appearance of multiple builds was consistent with LLM-assisted development. This is an assessment, not a direct attribution of every development step to an identified AI system or actor.

WildFire classified all seven variants as malware, and Cortex XDR generated alerts for each variant that executed on an endpoint. For defenders, the important signals are the ransomware behaviors themselves: security-tool interference, shadow-copy deletion, and visible ransom-note activity.

A trojanized recipe application

The most frequently encountered sample was an NSIS installer masquerading as a recipe-finding application named Recipe Lister. Unit 42 reported that the executable carried a code-signing certificate issued to Global Tech Allies Ltd., which had since been revoked. After execution, the installer extracted and ran a JavaScript backdoor from a temporary directory.

The sample appeared across more than 50 organizations and generated more than 6,500 endpoint profile records and 9,600 XDR alerts during the observation period. Unit 42 reported that no execution succeeded on a protected endpoint. The detection sequence is particularly instructive because the file’s signature initially made static classification less straightforward. Behavioral controls identified the uncommon signer and near-maximum file entropy, a characteristic associated with packed or encrypted content in this case. A WildFire verdict then provided additional classification and supported the block action.

This episode shows why code signing should be treated as one input to trust decisions, not as proof that an installer is safe. An uncommon publisher, unusual packaging, unexpected temporary-directory activity, and a mismatch between the claimed application and observed behavior should all increase scrutiny.

Oyster, or CleanBoost

Another sample posed as a Dropbox installer and used an Authenticode signature whose subject identity read Dropbox, Inc. Unit 42 reported that the installer was not genuine Dropbox software. Instead, it dropped an AutoIt loader that side-loaded the Oyster backdoor, also known as CleanBoost.

Unit 42 assessed that AI tools could help attackers generate the malicious code used in initial access and delivery, reducing the effort needed to deploy loaders. The research does not establish that AI was responsible for every component of this sample or identify a specific threat actor behind it. The confirmed finding is the delivery pattern: a signed installer impersonating trusted software and using a loader to bring in a backdoor.

Rhadamanthys stealer

A .NET executable named redist.exe delivered the Rhadamanthys information stealer and showed active command-and-control communication. Unit 42 stated that earlier reporting had associated this sample with an AI-enabled infection chain. The supplied research does not provide the command-and-control address, protocol, stolen-data details, or a complete sequence of the earlier chain, so those details remain unconfirmed here.

COM-hijacking DLL

The dataset also included a DLL named 360Util.dll that masqueraded as a component of 360 Total Security. Unit 42 reported that it implemented persistence through COM object hijacking and used metadata impersonating the Chinese-language product. The sample was included because it was delivered alongside AI-branded lures in campaigns observed by the researchers.

These cases cover ransomware, backdoor delivery, information stealing, persistence, and brand impersonation. None required a detection model designed specifically for “AI malware,” according to Unit 42. The relevant indicators were behaviors and artifacts already associated with malicious activity.

Why the AI distinction still matters

Unit 42’s conclusion is not that AI-enabled malware can be ignored. Rather, the organization assessed that AI currently affects the development process more clearly than the execution process. Faster code generation can make variant production and experimentation cheaper. The FunkSec build sequence is one example that Unit 42 viewed as consistent with accelerated iteration.

AI branding also creates a practical social-engineering opportunity. Users may be more willing to install an application presented as an AI tool, particularly when the package appears signed. The Recipe Lister and Dropbox-themed samples show how trusted-product impersonation can be combined with installers, loaders, and backdoors.

At the same time, Unit 42 reported no statistically significant targeting pattern across the samples. Encounters spanned three countries and multiple industries, without concentration in one sector or geography. The organization assessed this distribution as consistent with opportunistic activity rather than a campaign focused on a particular vertical. That assessment does not rule out targeted use in other environments; it describes the patterns visible in this dataset.

What organizations should do now

Keep behavior at the center of detection. Monitor for attempts to disable endpoint protection, modify security-related registry settings, delete shadow copies, execute scripts from temporary directories, load unexpected DLLs, and establish persistence through COM hijacking. These behaviors are useful regardless of whether the code was written by a person, generated by an LLM, or assembled from existing components.

Do not over-trust code signatures. Validate publisher identity, certificate reputation, file prevalence, installation context, and runtime behavior. A signed file from an uncommon publisher, especially one with high entropy or an unexpected child process, deserves investigation. Certificate revocation status should be incorporated into software trust workflows where practical.

Strengthen application and script controls. Restrict installation of software outside approved sources, limit user execution from temporary and download directories, and apply suitable controls to script interpreters and scripting engines. These measures can reduce the impact of installers that extract JavaScript or other loader components.

Hunt for persistence and recovery inhibition. Review endpoint telemetry for newly registered COM objects, suspicious DLL placement, unusual side-loading relationships, shadow-copy deletion, and changes to security settings. Correlate these events with the original installer, user, parent process, and network activity.

Use layered analysis. Endpoint analytics, cloud sandboxing, network inspection, and threat intelligence provide complementary views. Unit 42’s findings show that a file that evades one static signal may still be exposed by entropy analysis, behavioral detection, or sandbox classification.

Prioritize the supplied hashes for retrospective review. Organizations can search the following SHA-256 values in their own telemetry and threat-intelligence systems. A match should be investigated in context; a hash match alone does not establish successful execution or compromise.

• 1619bcad3785be31ac2fdee0ab91392d08d9392032246e42673c3cb8964d4cb7 — Recipe Lister trojanized application
• 5226ea8e0f516565ba825a1bbed10020982c16414750237068b602c5b4ac6abd, dcf536edd67a98868759f4e72bcbd1f4404c70048a2a3257e77d8af06cb036ac, 66dbf939c00b09d8d22c692864b68c4a602e7a59c4b925b2e2bef57b1ad047bd, c233aec7917cf34294c19dd60ff79a6e0fac5ed6f0cb57af98013c08201a7a1c, e622f3b743c7fc0a011b07a2e656aa2b5e50a4876721bcf1f405d582ca4cda22, b1ef7b267d887e34bf0242a94b38e7dc9fd5e6f8b2c5c440ce4ec98cc74642fb, 20ed21bfdb7aa970b12e7368eba8e26a711752f1cc5416b6fd6629d0e2a44e5d — FunkSec ransomware
• dd15ce869aa79884753e3baad19b0437075202be86268b84f3ec2303e1ecd966 — FunkSec ransomware
• c398b3e06ef860670b9597daed85632834fa961aea87164b8ba8bb2f094a14ef — COM-hijacking DLL
• bb932056cae8940742e50b4f2b994a802e703f7bc235e7dd647d085ae2b2baf7 — Oyster backdoor/CleanBoost
• 4fb58687a364c3f6d6f7e0ca03654f9dec0f8832a499d61d40b0d424db1b1b14 — Rhadamanthys stealer

Organizations should avoid treating the absence of these hashes as evidence that they are unaffected. AI-assisted malware can be modified quickly, and the source research emphasizes the importance of behavior-based coverage over narrow sample matching.

Conclusion

Unit 42’s research presents AI-enabled malware as an evolving operational concern, not yet as a separate class that defeats established defenses. AI can accelerate development, increase variant volume, and strengthen social-engineering lures. However, the samples that reached the organization’s production telemetry continued to exhibit recognizable behaviors, from ransomware recovery inhibition to suspicious loaders and persistence mechanisms.

For security teams, the practical response is disciplined defense in depth: monitor execution behavior, scrutinize signed installers, restrict unapproved software, investigate persistence changes, and use endpoint, network, and sandbox telemetry together. The technology used to write malware may change rapidly; the need to detect what that malware does remains constant.

Sources

Palo Alto Networks Unit 42: The State of AI-Enabled Malware — From Brand Abuse to Agentic Execution