How GPT-3.5 helps those who don't know how to code build working viruses.
Attackers are already trying to integrate artificial intelligence into malware, but so far the results have been very mixed. In some cases, the neural network is used merely for show, leaving behind only garish, useless logs. In other cases, it's already being trusted with a very specific task: deciding whether to launch a payload on a given machine or to play it safe. The analysis of Unit 42 clearly demonstrates both extremes at once.
Researchers searched open sources and their own telemetry for evidence that malware authors were already using large language models. They were interested in three scenarios. The first was when artificial intelligence helped write the malicious code itself. The second was when the model participated in remotely controlling the attack, essentially suggesting what to do next. The third, and most concerning, was when the malware began making decisions directly on the infected system, without an external operator. According to Unit 42, the first two scenarios had already been encountered in real samples, but analysts had not yet seen full-fledged local agent logic in the wild.
Their overall conclusion is quite straightforward. Artificial intelligence can already help attackers write working prototypes and generally lower the barrier to entry for those who simply lacked the skills. But it's still a long way from truly autonomous malware. Authors still struggle to embed a model within a prototype, deploy it to the target machine, and ensure that it actually controls the program's behavior, rather than simply creating the illusion of something intelligent.
The first case involved a .NET infostealer written in C# for the .NET Framework 4.0, which was additionally packed with ConfuserEx 2. This obfuscation should hinder analysis and detection, but the key detail here is different: the malware accesses OpenAI GPT-3.5-Turbo via an API over HTTP. On paper, the idea seems almost like the next stage of malware evolution. It seems as if the infected program would be able to independently understand the environment, develop methods to bypass protection, and communicate more intelligently with the command-and-control server. In practice, things turned out to be much more prosaic.
The infostealer itself is fully functional. It collects system information, extracts cookies from browsers, builds file lists, and prepares all of this for sending to the command-and-control server. The code also contains a set of functions intended to emulate AI -based logic : generating security bypass techniques, analyzing the environment, obscuring data exchange, and preparing plausible messages for command-and-control traffic. It was these components that the researchers analyzed step by step.
There are four such functions: GenerateEvasionTechnique(), AnalyzeTargetEnvironment(), GenerateObfuscatedCommunication(), and SendToC2ServerWithLLM(). Unit 42 assesses that none of them makes the sample significantly more dangerous or sophisticated. On the contrary, unnecessary calls to the model only add noise and can attract the attention of defenders. Calls are made, responses are received, but to little avail.
The first function, GenerateEvasionTechnique(), asks GPT-3.5 to come up with a simple evasion method for the data theft tool and return only a short name, no more than three words. Examples include Random Delay, Process Spoofing, and Memory Obfuscation. If the interface is unresponsive, the malware substitutes the default value, Random Delay. Then comes the most telling part: the result has no effect. The resulting string is simply written to victim_logs.txt on the victim's desktop, along with a timestamp. There is no actual implementation behind it.
This is where the superficiality of the entire scheme becomes clear. For such a response to actually work, the author would have to pre-program handlers for every possible technique or obtain data from the model that could be converted into executable logic on the fly. Theoretically, both approaches are possible. The samples found did neither. The function simply creates the appearance that the malware is choosing its own method of evading detection.
The second function, AnalyzeTargetEnvironment(), is a bit more practical, but it doesn't change much. The query to the model passes the operating system version, architecture, and username, after which GPT-3.5 should return a number between 1000 and 5000, representing the delay in milliseconds. This response is already being used: the program actually sleeps for one to five seconds. If the model is silent, a standard two-second pause is taken. This is technically a working behavior, but its purpose is highly questionable. The researchers explicitly state that this integration doesn't yield any meaningful effect and rather demonstrates the author's lack of practical experience in creating stealth tools.
The third function, GenerateObfuscatedCommunication(), asks the model to name a simple method for obfuscating data transfers. Examples include Base64 Encode, XOR Cipher, and JSON Minify. After responding, the malware generates a simple structure with the technique name, an obfuscated timestamp, and a flag indicating that the communication was supposedly enhanced using a large language model. At first glance, it might seem that the proposed method is actually being applied to the traffic. However, when analyzing the code, the researchers found no implementation that would confirm this. The technique name is simply written to the console and the JSON log, and the data transfer itself is not obfuscated as promised.
The logs are particularly revealing. The console displays messages about a successful connection to the OpenAI interface, GPT-3.5-turbo initialization, completion of crawl generation, environment analysis, communication obfuscation, social engineering, dynamic adaptation, intelligent obfuscation, machine learning, and a whole host of other supposedly active mechanisms. The final line indicates that the large language model integration is fully functional. However, most of these capabilities exist only in the text of the logs themselves; there is no actual code behind them.
The fourth function, SendToC2ServerWithLLM(), is already associated with sending the stolen data to the command-and-control server. Here, the malware asks the model to create a short, professional-sounding message to make the network exchange appear more legitimate. GPT-3.5 returns a neutral service phrase, which the program adds to the X-Message HTTP header and separately marks the request with the string X-LLM-Enhanced: true. The data itself is sent in JSON format to hxxp[:]//localhost:3002/crypto-data. The researchers note that this C2C address is also set as the default value, suggesting either local testing or an unfinished build that was never intended for real-world operations.
This function is closest to a real-world application of the model, as it actually involves action, not just logging. If you plug in a working server address, the sample can transmit data externally. But even in this case, the use of artificial intelligence offers almost no improvement. Additional HTTP headers don't make the communication channel more efficient or provide any tangible benefit. They merely emphasize the very fact that the model is being used. That's why researchers call this approach more of an AI show than a useful engineering finding.
Overall, the purpose of this .NET infostealer is quite standard: extract sensitive data from browsers and the system, then send it to the command-and-control server. The layer associated with the large language model should be responsible for dynamic adaptation, evasion, and more intelligent communication with the command-and-control server. Analysis reveals the opposite: almost the entire AI component functions as a decorative add-on, creating the appearance of complexity without adding any real functionality. Unit 42 admits that such samples could have been written using AI or assembled by inexperienced individuals who decided to add a trendy component to an already familiar framework.
The second example is much more interesting, as it uses the model not for fancy labels, but to decide an important question: whether to launch the payload or not. This is a Go loader that acts as a dropper for Sliver, an open-source framework for adversary emulation and red team operations. Before deploying the payload, the program collects information about the system, including the name of its own process and the parent process. After that, the dropper decrypts the Donut shellcode but doesn't rush to execute it. First, it tries to determine whether the current environment is too dangerous.
To perform this check, the malware generates a system overview. It collects the hostname, process list, network information, details of connected USB drives, and the machine's uptime. All this data is inserted into a request and sent to GPT-4 via an HTTP API. The model essentially delegates the decision making: it must evaluate the collected features and determine whether it is safe to drop and run Sliver on this host.
Typically, such checks within malware are much simpler and more stringent. The author pre-defines heuristics, compiles lists of undesirable and acceptable features, and adds logic for checking sandboxes, virtual machines, analysis tools, and other markers of a suspicious environment. This approach is well known from ransomware and many other families. In the case of this dropper, the logic is externalized: instead of a fixed set of rules, the verdict is given to a language model . This is an unpleasant development for defenders, as it makes it more difficult to understand what exactly the malware is hiding from and what combination of processes or settings will cause it to refuse to launch.
This particular example is what the researchers find truly intriguing. The model is hosted remotely, meaning it's too early to talk about full autonomy. But the idea itself is already clear: the malware authors don't simply want to receive text from a large language model, but rather task it with analyzing the environment and authorizing the next step. In a traditional approach, the same task is accomplished with hard-coded permission and restriction lists. Using a model potentially allows for linking more system features and making a more accurate verdict on the suitability of the environment for infection. The next step could very well be locally running a small language model or a compact machine learning classifier trained to determine whether an environment is safe or dangerous based on a set of host characteristics.
Against this backdrop, the entire current landscape of AI-powered malware appears to be a mixture of experiments, half-baked projects, and the first meaningful attempts. The .NET infostealer demonstrates a very superficial and ultimately useless use of a large language model. The Sliver dropper, on the other hand, demonstrates a more meaningful scenario, where the model is involved in deciding whether to carry out an attack. The researchers emphasize that it is not yet possible to definitively prove whether generative models were used in the writing of these samples. But even this possibility is alarming, as artificial intelligence could significantly lower the barrier to entry for less skilled attackers.
Unit 42 estimates that the situation will only become more complex. As local deployment of small models becomes easier, we can expect to see samples with embedded AI capabilities. This is particularly true for code generation and more flexible adaptation to a specific environment. Such malware will be able to more quickly change its behavior, better evade detection, and, in real time, select the most advantageous method for carrying out malicious actions.
The increased use of artificial intelligence in malware may manifest itself not only in more complex logic, but also in the more frequent introduction of new features and the increased reliability of the samples themselves. In other words, the problem isn't limited to a single buzzword in an attack description. The danger is that attackers' tools may begin updating faster, operating more reliably, and adapting better to the conditions on the victim's side. This is why such experiments now require special attention: even unsuccessful attempts indicate the direction of the next wave of threats.
Attackers are already trying to integrate artificial intelligence into malware, but so far the results have been very mixed. In some cases, the neural network is used merely for show, leaving behind only garish, useless logs. In other cases, it's already being trusted with a very specific task: deciding whether to launch a payload on a given machine or to play it safe. The analysis of Unit 42 clearly demonstrates both extremes at once.
Researchers searched open sources and their own telemetry for evidence that malware authors were already using large language models. They were interested in three scenarios. The first was when artificial intelligence helped write the malicious code itself. The second was when the model participated in remotely controlling the attack, essentially suggesting what to do next. The third, and most concerning, was when the malware began making decisions directly on the infected system, without an external operator. According to Unit 42, the first two scenarios had already been encountered in real samples, but analysts had not yet seen full-fledged local agent logic in the wild.
Their overall conclusion is quite straightforward. Artificial intelligence can already help attackers write working prototypes and generally lower the barrier to entry for those who simply lacked the skills. But it's still a long way from truly autonomous malware. Authors still struggle to embed a model within a prototype, deploy it to the target machine, and ensure that it actually controls the program's behavior, rather than simply creating the illusion of something intelligent.
The first case involved a .NET infostealer written in C# for the .NET Framework 4.0, which was additionally packed with ConfuserEx 2. This obfuscation should hinder analysis and detection, but the key detail here is different: the malware accesses OpenAI GPT-3.5-Turbo via an API over HTTP. On paper, the idea seems almost like the next stage of malware evolution. It seems as if the infected program would be able to independently understand the environment, develop methods to bypass protection, and communicate more intelligently with the command-and-control server. In practice, things turned out to be much more prosaic.
The infostealer itself is fully functional. It collects system information, extracts cookies from browsers, builds file lists, and prepares all of this for sending to the command-and-control server. The code also contains a set of functions intended to emulate AI -based logic : generating security bypass techniques, analyzing the environment, obscuring data exchange, and preparing plausible messages for command-and-control traffic. It was these components that the researchers analyzed step by step.
There are four such functions: GenerateEvasionTechnique(), AnalyzeTargetEnvironment(), GenerateObfuscatedCommunication(), and SendToC2ServerWithLLM(). Unit 42 assesses that none of them makes the sample significantly more dangerous or sophisticated. On the contrary, unnecessary calls to the model only add noise and can attract the attention of defenders. Calls are made, responses are received, but to little avail.
The first function, GenerateEvasionTechnique(), asks GPT-3.5 to come up with a simple evasion method for the data theft tool and return only a short name, no more than three words. Examples include Random Delay, Process Spoofing, and Memory Obfuscation. If the interface is unresponsive, the malware substitutes the default value, Random Delay. Then comes the most telling part: the result has no effect. The resulting string is simply written to victim_logs.txt on the victim's desktop, along with a timestamp. There is no actual implementation behind it.
This is where the superficiality of the entire scheme becomes clear. For such a response to actually work, the author would have to pre-program handlers for every possible technique or obtain data from the model that could be converted into executable logic on the fly. Theoretically, both approaches are possible. The samples found did neither. The function simply creates the appearance that the malware is choosing its own method of evading detection.
The second function, AnalyzeTargetEnvironment(), is a bit more practical, but it doesn't change much. The query to the model passes the operating system version, architecture, and username, after which GPT-3.5 should return a number between 1000 and 5000, representing the delay in milliseconds. This response is already being used: the program actually sleeps for one to five seconds. If the model is silent, a standard two-second pause is taken. This is technically a working behavior, but its purpose is highly questionable. The researchers explicitly state that this integration doesn't yield any meaningful effect and rather demonstrates the author's lack of practical experience in creating stealth tools.
The third function, GenerateObfuscatedCommunication(), asks the model to name a simple method for obfuscating data transfers. Examples include Base64 Encode, XOR Cipher, and JSON Minify. After responding, the malware generates a simple structure with the technique name, an obfuscated timestamp, and a flag indicating that the communication was supposedly enhanced using a large language model. At first glance, it might seem that the proposed method is actually being applied to the traffic. However, when analyzing the code, the researchers found no implementation that would confirm this. The technique name is simply written to the console and the JSON log, and the data transfer itself is not obfuscated as promised.
The logs are particularly revealing. The console displays messages about a successful connection to the OpenAI interface, GPT-3.5-turbo initialization, completion of crawl generation, environment analysis, communication obfuscation, social engineering, dynamic adaptation, intelligent obfuscation, machine learning, and a whole host of other supposedly active mechanisms. The final line indicates that the large language model integration is fully functional. However, most of these capabilities exist only in the text of the logs themselves; there is no actual code behind them.
The fourth function, SendToC2ServerWithLLM(), is already associated with sending the stolen data to the command-and-control server. Here, the malware asks the model to create a short, professional-sounding message to make the network exchange appear more legitimate. GPT-3.5 returns a neutral service phrase, which the program adds to the X-Message HTTP header and separately marks the request with the string X-LLM-Enhanced: true. The data itself is sent in JSON format to hxxp[:]//localhost:3002/crypto-data. The researchers note that this C2C address is also set as the default value, suggesting either local testing or an unfinished build that was never intended for real-world operations.
This function is closest to a real-world application of the model, as it actually involves action, not just logging. If you plug in a working server address, the sample can transmit data externally. But even in this case, the use of artificial intelligence offers almost no improvement. Additional HTTP headers don't make the communication channel more efficient or provide any tangible benefit. They merely emphasize the very fact that the model is being used. That's why researchers call this approach more of an AI show than a useful engineering finding.
Overall, the purpose of this .NET infostealer is quite standard: extract sensitive data from browsers and the system, then send it to the command-and-control server. The layer associated with the large language model should be responsible for dynamic adaptation, evasion, and more intelligent communication with the command-and-control server. Analysis reveals the opposite: almost the entire AI component functions as a decorative add-on, creating the appearance of complexity without adding any real functionality. Unit 42 admits that such samples could have been written using AI or assembled by inexperienced individuals who decided to add a trendy component to an already familiar framework.
The second example is much more interesting, as it uses the model not for fancy labels, but to decide an important question: whether to launch the payload or not. This is a Go loader that acts as a dropper for Sliver, an open-source framework for adversary emulation and red team operations. Before deploying the payload, the program collects information about the system, including the name of its own process and the parent process. After that, the dropper decrypts the Donut shellcode but doesn't rush to execute it. First, it tries to determine whether the current environment is too dangerous.
To perform this check, the malware generates a system overview. It collects the hostname, process list, network information, details of connected USB drives, and the machine's uptime. All this data is inserted into a request and sent to GPT-4 via an HTTP API. The model essentially delegates the decision making: it must evaluate the collected features and determine whether it is safe to drop and run Sliver on this host.
Typically, such checks within malware are much simpler and more stringent. The author pre-defines heuristics, compiles lists of undesirable and acceptable features, and adds logic for checking sandboxes, virtual machines, analysis tools, and other markers of a suspicious environment. This approach is well known from ransomware and many other families. In the case of this dropper, the logic is externalized: instead of a fixed set of rules, the verdict is given to a language model . This is an unpleasant development for defenders, as it makes it more difficult to understand what exactly the malware is hiding from and what combination of processes or settings will cause it to refuse to launch.
This particular example is what the researchers find truly intriguing. The model is hosted remotely, meaning it's too early to talk about full autonomy. But the idea itself is already clear: the malware authors don't simply want to receive text from a large language model, but rather task it with analyzing the environment and authorizing the next step. In a traditional approach, the same task is accomplished with hard-coded permission and restriction lists. Using a model potentially allows for linking more system features and making a more accurate verdict on the suitability of the environment for infection. The next step could very well be locally running a small language model or a compact machine learning classifier trained to determine whether an environment is safe or dangerous based on a set of host characteristics.
Against this backdrop, the entire current landscape of AI-powered malware appears to be a mixture of experiments, half-baked projects, and the first meaningful attempts. The .NET infostealer demonstrates a very superficial and ultimately useless use of a large language model. The Sliver dropper, on the other hand, demonstrates a more meaningful scenario, where the model is involved in deciding whether to carry out an attack. The researchers emphasize that it is not yet possible to definitively prove whether generative models were used in the writing of these samples. But even this possibility is alarming, as artificial intelligence could significantly lower the barrier to entry for less skilled attackers.
Unit 42 estimates that the situation will only become more complex. As local deployment of small models becomes easier, we can expect to see samples with embedded AI capabilities. This is particularly true for code generation and more flexible adaptation to a specific environment. Such malware will be able to more quickly change its behavior, better evade detection, and, in real time, select the most advantageous method for carrying out malicious actions.
The increased use of artificial intelligence in malware may manifest itself not only in more complex logic, but also in the more frequent introduction of new features and the increased reliability of the samples themselves. In other words, the problem isn't limited to a single buzzword in an attack description. The danger is that attackers' tools may begin updating faster, operating more reliably, and adapting better to the conditions on the victim's side. This is why such experiments now require special attention: even unsuccessful attempts indicate the direction of the next wave of threats.
