Threat Research Center Threat Research Malware Malware Analyzing the Current State of AI Use in Malware 11 min read Related Products Advanced Threat Prevention Advanced URL Filtering Advanced WildFire Cloud-Delivered Security Services Cortex Cortex XDR Cortex XSIAM Unit 42 AI Security Assessment Unit 42 Incident Response By: Unit 42 Published: March 19, 2026 Categories: Malware Threat Research Tags: .NET ChatGPT GenAI Infostealer LLM Sliver Share Executive Summary Unit 42 researchers searched through open-source intelligence (OSINT) and our internal telemetry for potential signs of malware made to any degree with large language models (LLMs). This includes either using LLMs to create the malware entirely or to assist with their functionality. This article examines two samples, both of which originated from our OSINT hunts. The rise of AI has sparked considerable interest in its potential applications within cybersecurity, both from the defender and attacker perspectives. We currently consider three primary use cases for AI as applied by the creators of malware: Leveraging AI to write malware Leveraging AI for remote decision making (e.g. augment or replace a command-and-control operator) Leveraging AI for local decision making (e.g. locally executed agentic attack flows) Unit 42 has analyzed malware that fits the first two categories: AI-written malware and malware controlled by an AI command-and-control (C2) for remote decision making. We are not aware of any examples in the wild of the third category: locally executed agentic attack flows. We believe that threat actors are leveraging AI to help write malware, and that AI enables lower-skilled threat actors to create functional malware. However, we still see attackers having significant challenges in deploying local models to a target environment for malicious use or embedding them directly into a malware sample for local decision making and execution. This article focuses on our analysis of samples that leverage AI for remote decision making. We’ll discuss the following two cases that represent the current state of AI in malware: AI Theater: An Infostealer’s Illusory LLM Features A trio of highly similar .NET information stealer samples that incorporate the OpenAI GPT-3.5-Turbo model via HTTP API. We will explore the implementation and assess the practical impact of its AI integration. AI-Gated Execution: Malware Dropper's LLM-Based Environment Assessment A malware dropper written in Golang that leverages an LLM to evaluate a system and provide a decision on whether to proceed with an infection. The sample was initially highlighted on X as a dropper for Sliver malware. Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services: Advanced Threat Prevention Advanced WildFire Cortex XDR and XSIAM The Unit 42 AI Security Assessment can help empower safe AI use and development. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team . Related Unit 42 Topics AI , LLM , Malware , Infostealer , ChatGPT AI Theater: A .NET Infostealer’s Illusory LLM Features The first sample we’ll discuss is an information stealer that integrates its functionality with OpenAI's GPT-3.5-Turbo via HTTP API. Encountering .NET malware packed with ConfuserEx 2 and observing calls to OpenAI was certainly exciting for a researcher, as it likely indicates a malware sample using an AI integration for remote C2. This integration with OpenAI indicates the malware may enable a lower skilled threat actor to interact with an infected environment without having to learn lateral movement, data collection and persistence techniques themselves. However, as we discuss later in this post, the integration with OpenAI is poorly implemented and not fully functional for some of the API calls that are available to the malware. This may indicate early testing or a low skilled actor. Artifacts such as the console log generated by the malware suggest that it may have the following capabilities: Dynamically generating a scare message without supporting functionality Analyzing target environments Creating host endpoint detection and response (EDR)/antivirus (AV) evasion content Examining the sample will reveal if these capabilities align with the sample's actual functionality. The malware is written in C# (.NET Framework 4.0) and has been obfuscated with ConfuserEx 2. The obfuscation allows the malware author to potentially hinder both analysis and detection efforts. This sample is a functional information stealer and begins by collecting and saving data to disk, like system information, browser cookies and file listings. This data is then exfiltrated to a C2 server. We found two similar samples of this malware, both with the same functionality. Both samples feature the same type of LLM use. LLM Use Represented Through Four Function Calls References and requests to the OpenAI LLM API are contained in four function calls. None of these calls positively impact the malware’s operation. In fact, these calls add noise, which defenders are likely to notice. This specific implementation of these requests and references is a nonsensical use of an LLM in malware. These four function calls are: GenerateEvasionTechnique() AnalyzeTargetEnvironment() SendToC2ServerWithLLM() GenerateObfuscatedCommunication() Method One of Four: GenerateEvasionTechnique() This method sends the following prompt to the OpenAI GPT-3.5-Turbo model using the standard API: Generate a simple evasion technique for a data extraction tool. Return only the technique name (max 3 words) that would help avoid detection. Examples: 'Random Delay', 'Process Spoofing', 'Memory Obfuscation 1 Generate a simple evasion technique for a data extraction tool . Return only the technique name ( max 3 words ) that would help avoid detection . Examples : 'Random Delay' , 'Process Spoofing' , ' Memory Obfuscation As instructed, the LLM returns a technique name (e.g., Random Delay, Process Spoofing). The malware author set a default technique name of Random Delay in case this API call fails. The technique name returned from the LLM is simply written to victim_logs.txt on the victim's desktop directory. An example of content from one of the victim_logs.txt files is: [2025-11-10 08:28:23] [EVASION] Technique generated: Random Delay 1 [ 2025 - 11 - 10 08 : 28 : 23 ] [ EVASION ] Technique generated : Random Delay It is important to note that technique names returned from the LLM are not actually implemented. They appear to be for logging purposes only. Realistically, the LLM could return any three words for an evasion technique name, so implementing this technique correctly would require one of two options to succeed: The malware would require handler code to execute based on the string returned from the LLM. The LLM would have to send data back that could be converted to executable code at runtime. These are both feasible options, but the malware samples we've discovered using this API call do not implement either option. Method Two of Four: AnalyzeTargetEnvironment() This method sends the following prompt to the OpenAI GPT-3.5-Turbo model using the standard API: Analyze this system environment and suggest a delay in milliseconds (1000-5000): OS: {os_version} Architecture: {architecture} Username: {username} Return only a number between 1000 and 5000. 1 2 3 Analyze this system environment and suggest a delay in milliseconds ( 1000 - 5000 ) : OS : { os_version } Architecture : { architecture } Username : { username } Return only a number between 1000 and 5000. The LLM response from this prompt is different from the GenerateEvasionTechnique() method, because the malware actually implements the result and sleeps for anywhere between 1-5 seconds (1,000-5,000 milliseconds). If the LLM fails to respond, the malware samples use a default value of 2 seconds for the sleep duration. From a malware reverse engineering perspective, this is a nonsensical use of an LLM because the response has no practical impact. The author (human or otherwise) of this malware sample does not appear to have any tangible experience in the design of tooling evasion to draw from, nor the knowledge to reasonably speculate on evasions. Method Three of Four: GenerateObfuscatedCommunication() This method sends the following prompt to the OpenAI GPT-3.5-Turbo model using the standard API: Generate a simple obfuscation technique for data communication. Return only the technique name (max 2 words) like 'Base64 Encode', 'XOR Cipher', 'JSON Minify' 1 Generate a simple obfuscation technique for data communication . Return only the technique name ( max 2 words ) like 'Base64 Encode' , 'XOR Cipher' , 'JSON Minify' Similar to GenerateEvasionTechnique() , the LLM returns an obfuscation technique name, which is ultimately written to a log file. The malware creates a simple structure as shown below. The timestamp is randomly generated before it is encoded as a Base64 string. "obfuscation_technique":"Base64 Encode", "timestamp_obfuscated":"MTEvMTAvMjAyNSAxMDowNDowNCBQTQ==", "llm_enhanced":true 1 2 3 4 5 "obfuscation_technique" : "Base64 Encode" , "timestamp_obfuscated" : "MTEvMTAvMjAyNSAxMDowNDowNCBQTQ==" , "llm_enhanced" : true It may be tempting to consider that perhaps the timestamp was Base64 encoded, as the LLM suggested in the above example. However, we could not find any implementation of Base64 that the malware leverages. The technique name is simply copied to the console output and a JSON log file. An example of the console output from this technique is: [2025-11-10 08:28:26] [OBFUSCATION] Communication protocol: Base64 Encode [2025-11-10 08:28:26] === LLM INTEGRATION VERIFICATION === [2025-11-10 08:28:26] ✓ OpenAI API: Successfully connected [2025-11-10 08:28:26] ✓ GPT-3.5-turbo: Successfully initialized [2025-11-10 08:28:26] ✓ Evasion Generation: Successfully completed [2025-11-10 0