When your pet goes missing, it can be totally heartbreaking.
So hearing that they’ve been found is no doubt very welcome news. Even better to see a photo of them looking safe and well.
But while the photo may look exactly like your pet, that doesn’t mean the person who sent it has your pet or even ever saw it.
The BBC reports how criminals are sending owners AI-generated images of their missing pets, demanding money for their return, and sometimes threatening to harm the animals when owners refuse to pay.
The BBC interviewed two targets of this scam who were both contacted after posting a missing pet message on social media. The scammers sent them pictures of their beloved pets and demanded a ransom for their safe return.
Messages like these exploit two powerful emotions in quick succession: relief that a beloved pet has been found, followed by fear that something terrible will happen unless the owner acts immediately.
The scam typically follows this pattern:
A scammer finds a missing pet appeal, which is typically posted to social media or local sites with an accompanying photo and contact details.
The scammer contacts the owner and claims to have found the animal. An image fabricated with the help of AI makes the claim appear more convincing.
They ask for money which may be described as a reward or as payment for emergency treatment.
They add pressure. They might refuse to meet until payment arrives, or threaten to sell or harm the pet.
Our data backs this report up. Over the last month, people anonymously submitted three distinctive types of pet related scam attempts to Malwarebytes Scam Guard:
“We found your missing cat” message, with photos: Someone claimed to have found a user’s missing cat and had images of it.
Found pet callback lure: A voicemail claimed to have found a lost cat and supplied a callback number.
Humane Society impersonation and payment demand: A caller claimed a missing cat needed emergency surgery, and demanded successive Zelle payments.
How to stay safe
Sadly, while it can be very useful to use social media to retrieve lost pets, it also attracts scammers and other abuse.
You don’t have to stop asking for help online, but you can put some safeguards between an unexpected message and any payment.
Keep some identifying details private. Leave a distinctive feature out of the public description so you can ask a supposed finder about it later.
Do not pay in advance to secure a reunion. Be particularly wary of someone who insists that you send money before they will let you see the animal. Arrange any legitimate handover in a safe, public location, and verify that it is your pet before paying a reward.
Verify veterinary claims independently. If someone says your pet is at an animal hospital, find the hospital’s contact details yourself and call it directly. Do not rely on the number or payment link in the message.
A second pair of eyes can help you assess a demand without the same emotional pressure. Malwarebytes Scam Guard can help you identify whether a message might be a scam and how to proceed.
If someone is threatening your pet, remember that when they make threats to your pet, it is very likely they don’t have a clue where it is either, so don’t let them extort you.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
As part of proactive threat monitoring, Kaspersky’s Cyber Threat Intelligence team identified a malicious campaign involving C2 agents controlled by artificial intelligence. Confirmed victims of the campaign included organizations in the education sector in several countries across Africa and Latin America. CyberStrikeAI played a key role in the post-exploitation phase. This is an open-source framework in which an LLM orchestrator on the command-and-control server plans actions, selects tools, and generates commands, while an implant executes them on compromised hosts. Using CyberStrikeAI, the attackers progressed from reconnaissance to full domain compromise.
According to our data, this is one of the first public descriptions of a compromise involving an LLM in the wild. The campaign we discovered clearly illustrates how the role of AI in attackers’ arsenals is evolving: until recently, language models were used primarily during preparatory stages – for writing phishing emails, debugging code, or searching for vulnerabilities. Now, however, they are being embedded into the very core of the attack, automating actions at every stage: payload execution, persistence on the host, discovery, lateral movement, and, finally, data collection and exfiltration. Post-exploitation – the stage that traditionally required manual work by an experienced operator – plays a particularly significant role here.
A key feature of the scheme using the CyberStrikeAI framework is that the implant ceases to be a simple tool for executing the operator’s commands. Decisions are distributed across two levels: the operator defines the task in general terms, while the model determines how to execute it – specifically, which commands to send to the host and in what sequence. Thus, the strategic planning remains with the human, while the choice of technical steps is delegated to the model, and the implant executes the model’s decisions.
To understand how this scheme works in practice, let’s examine the chain of actions taken by the attackers, as reconstructed by our analysts during the incident investigation.
Timeline of the attack
Let’s examine the timeline of the attack using an example from one incident within the detected campaign.
The first phase follows a standard approach: a human operator gains access to the victim’s infrastructure via a compromised SQL Server (version 16.0.1000), then collects basic information about the host, deploys tools, and conducts network reconnaissance. All of this activity takes nearly a day, followed by a two-week pause.
The second phase is fundamentally different. The first step involves deploying the CyberStrikeAI C2 agent, which receives commands from a server-based LLM orchestrator. During the second phase, the agent performs the following:
establishing persistence and conducting local reconnaissance within 2 minutes;
conducting domain reconnaissance over the next 5 hours;
after a brief pause of several days, moving on to the final stage – lateral movement via SMB and WMI, mass credential dumping on hosts, and database export – with the entire operation taking no more than one hour.
We’ll discuss these stages in more detail in the next section.
Technical details
CyberStrikeAI overview
CyberStrikeAI is an open-source, modular platform written in Go for automating penetration testing. Its key feature is combining LLM-based attack orchestration and a built-in C2 server with agents (beacons) within a single server process.
The entire “intelligent” layer is isolated on the control server. C2 functions (calling reconnaissance and exploitation utilities, managing webshell connections, assigning tasks to agents, and reading results) are available to the model as MCP tools. The implant is a classic C2 agent with no AI functionality – no API keys, no calls to AI service APIs, and no autonomous logic. It periodically polls the listener server via HTTP/S, TCP, or WebSocket, executes shell commands, and interacts with the file system. To the victim, this activity looks like a typical remote-control session, where a server-side LLM orchestrator queues tasks instead of a live operator. The LLM influences how decisions are made, but not how the corresponding commands are delivered to the host.
Although CyberStrikeAI is publicly available, specific instances of the framework can be linked to specific attackers or campaigns. Detection and attribution are possible based on the following artifacts:
Control panel: Upon launch, a self-signed TLS certificate is generated, with the framework’s name appearing in the issuer and subject fields. The certificate is created in memory at each startup, so the not_before field effectively records the time the process was launched. Accordingly, as with Cobalt Strike, the chronology of restarts can be reconstructed from the scan history.
CyberStrikeAI control panel’s self-signed TLS certificate
Implant: The build metadata (go version -m) contains a path to the main package, which includes data pointing to the built-in CyberStrikeAI generator – a temporary directory with the build identifier. This path is identical for all payloads, making it a reliable signature. Additionally, the build info field contains version control system metadata, which can be used to compare samples against one another.
Authentication: When communicating with the server, the implant sends an X-Implant-Token header with a fixed value in the HTTP request. The token is unique to each C2 server and is embedded into the malicious payload during the build phase; therefore, it serves as both a network indicator and a sign that the samples belong to the same server.
HTTP header parameters sent by the implant to the server
It should be noted that the implant version does not reflect the server version. The implant can operate for months while the operator updates the server-side components: listener configurations and keys are preserved during updates. In the incidents we detected, we observed the use of a single agent version throughout the entire incident. In such cases, the sample’s build date may indicate the earliest possible deployment date of the CyberStrikeAI infrastructure, but it still does not provide an estimate of the compromise duration.
Execution & Privilege Escalation
The first malicious commands on the victims’ systems in the campaign under investigation originated from the sqlservr.exe process, indicating the likely initial access vector and the context in which the attackers gained the ability to execute code. It is important to note that the commands marked as having been executed prior to agent installation were executed manually by the attacker specifically within the context of this process. At this stage, we are not yet dealing with automated implant activity, but rather with manual actions by the operator.
Before launching the agent on the machines, the attackers checked for its presence using a PowerShell script, from which we can deduce its default deployment paths: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. At the same time, the attacker can disguise the agent’s name as that of a legitimate system process. In the example below, it mimics svchost.exe (svchosts.exe)
Checking for the presence of the CyberStrikeAI agent on the system
Delivery and execution of the CyberStrikeAI agent
Like most C2 agents for Windows, CyberStrikeAI uses PowerShell to execute its payload. When a request is received from the operator, the commands to be executed are additionally encoded in Base64 to bypass keyword-based detection.
Decoded form of the command:
When administrative privileges were available (for example, a domain administrator account), instead of executing commands directly, the agent on remote hosts often created scheduled tasks so that the malicious payload would run with SYSTEM privileges:
An alternative method that does not use schtasks utility is to create a task via the Schedule.Service COM object:
The payload (p1.ps1) from the example above is a reverse shell that connects to the server at 185.186.245[.]144:5501:
The p1.ps1 payload and similar scripts were distributed across the network using shared network administrative folders and the WMI protocol, which we will describe in more detail in the Lateral Movement section.
Stealth
In addition to encoding commands in Base64 and obfuscating SQL/LDAP queries – which we will describe in the Collection & Exfiltration and Discovery sections, respectively – the attackers split the malicious payload into multiple files. It is noteworthy that the scripts were transmitted in this manner even before the agent was installed – that is, at a stage where human intervention is typically required – yet they clearly bear the hallmarks of being generated by an LLM.
Below is a sequential record of several script fragments written to the file d3.b64.
Subsequently, the attackers used the certutil utility to decode the resulting file and executed it with the following command:
Once assembled and decoded, the script’s contents looked like this:
The script is a tool for decrypting DPAPI secrets from the file C:\ProgramData\dsn_line.txt. This file, in turn, is populated by the following command, which searches for a DSN string containing connection settings in the SQL Server Reporting Services configuration file rsreportserver.config and copies its contents to dsn_line.txt.
It is worth noting that some of the scripts delivered and executed as described above contain comments in Chinese (## – researcher’s comments).
Persistence
If the CyberStrikeAI implant was successfully delivered, the first step was to establish persistence on the target system. To do this, the agent created a scheduled task named SystemUpdate, which specified the path to the implant as the action to be performed:
Analysis of the framework’s source code revealed an alternative method of persistence: by adding a value to the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run, where the name of the created value matches the task name (SystemUpdate).
Agent persistence on Linux systems is also implemented in two ways – by adding the entry @reboot <path_to_beacon> & to the user’s crontab (in which case the process runs at system startup), or by adding the line (nohup <path_to_beacon> &>/dev/null &) to ~/.bashrc (in which case the agent starts when an interactive bash shell is opened).
It is worth noting that the choice of a specific persistence method is delegated to the LLM connected to CyberStrikeAI. However, thanks to the human-in-the-loop (HITL) mechanism, the operator retains full control over the process: commands generated by the model may require manual approval or correction before they are executed.
Discovery
Local Discovery
Before installing the agent on a compromised host, the attackers manually gathered basic system information using a fairly trivial set of commands:
The attackers also manually checked for internet access and obtained the external IP addresses of the compromised machines using the Chinese service dnslog[.]cn. The service generates a random third-level domain, after which the attackers attempt to resolve it on the compromised machine.
If the machine has internet access, the request succeeds, and the attackers obtain the external IP address of the compromised device on the service’s page.
For reconnaissance purposes, the agent generates a more complex script designed to map out a path for further privilege escalation by compromising SCCM or exploiting msiexec (the AlwaysInstallElevated key):
Additionally, to find ways to elevate privileges locally, the agent executed scripts to inventory services running under domain accounts and tasks running under the SYSTEM account:
During their activity, the attackers periodically checked for Microsoft Defender detections:
Remote Discovery
After gathering information about the compromised host, the attackers proceeded to conduct reconnaissance within the network. During the preparatory phase of the attack, they manually collected additional information about remote hosts using the net.exe utility.
During the main phase, the agent used PowerShell’s built-in functionality to detect accessible hosts without relying on additional utilities (such as nmap or fscan):
Additionally, relevant LDAP queries to Active Directory objects helped build a network map:
Furthermore, the presence of the installed agent on remote hosts was verified using WMI:
Domain Discovery
The next step was to gather information about the victims’ domains. To this end, before installing the agent, the attackers used standard OS utilities:
However, later on, using the CyberStrikeAI implant, reconnaissance was carried out via generated PowerShell scripts:
In addition to basic domain information, the agent performed LDAP queries to gather information for Kerberoasting and AS-REP Roasting attacks:
Finally, the agent was used to check the domain for the presence of LAPS and Microsoft Azure:
To detect signs of Microsoft Azure usage within the infrastructure, the attackers also searched for the .azcopy directory – created by the AzCopy (Microsoft Azure Storage Copy) utility – in users’ home directories:
Credential Access
After successfully conducting reconnaissance and mapping the network, the attackers moved on to the next stage – dumping credentials. For this purpose, the agent used a classic set of LOLBINs and well-known third-party tools.
The agent dumped registry hives containing credentials using the reg.exe utility:
The agent dumped the lsass.exe process using the MiniDump function of the comsvcs.dll library. In doing so, the target process’s PID was used instead of its name to make static detection based on the command line more difficult:
After successfully compromising privileged domain accounts (specifically, the built-in domain administrator), the attackers also carried out DCSync and Golden Ticket attacks via the agent using a renamed version of the mimikatz utility:
Lateral Movement
To spread across the network using compromised accounts, the attackers employed utilities from the Impacket toolkit, specifically WMIExec, as indicated by the utility’s characteristic command line:
Once installed, the agent prefers to use standard OS mechanisms, such as shared network folders.
Another method the agent uses to remotely execute commands is the WMI protocol. In particular, the agent used it to distribute the aforementioned p1.ps1 reverse shell script. This involved using compromised user accounts with local administrator privileges on the target hosts:
A second method of lateral movement via WMI uses the Invoke-CimMethod cmdlet:
Command & Control
To deliver the aforementioned tools (malicious scripts, mimikatz, and the agent itself) to the initial nodes in the infection chain, the attackers used standard OS utilities:
After the agent is installed, it checks the availability of the C2 server’s ports. The implementation mechanisms here are virtually unlimited and depend on the “creativity” of the respective LLM agents connected to the server:
To download additional utilities, the CyberStrikeAI implant also used built-in utilities (LOLBINs). The tools could be hosted on the attackers’ own servers or downloaded directly from GitHub:
Collection & Exfiltration
The data collection phase deserves special attention. It demonstrates yet another capability of LLM orchestration – the automatic generation of SQL and LDAP queries tailored to a specific task.
In one incident during the campaign, the attackers deployed the CyberStrikeAI implant on an educational organization’s SQL server and collected information from the database via PowerShell. Here is an example of a command executed by the agent:
Normalized view of the executed script with comments:
Before accessing the data, the agent checked the privileges of the account under which it connected to the database:
In decoded form, the check looks as follows:
On network resources, file collection was preceded by a recursive directory scan to identify files of interest.
To interact with the file system, the implant provides a built-in interface that supports direct uploading and downloading of files. Files are transferred directly via the main encrypted communication channel with the C2 server (HTTP or TCP), and the data itself is encoded in Base64 and packaged into the agent’s standard JSON responses.
Another built-in capability of the implant is taking screenshots of the infected machine. As with other actions, the implant does not initiate this on its own: the command to capture the screen is issued by the LLM orchestrator, and the agent merely executes it and returns the result via the same control channel.
On Windows, the command for taking screenshots looks like this:
The Linux version looks like this:
In the incidents we detected, data collection was the final stage of the attack: the chain ended there, and we observed no further activity.
Attribution
The key artifact for attribution in this campaign is the implant’s build metadata. The attackers built the malicious payload inside a Git clone of the project, so the Go compiler embedded version control system information into the binary files – the hash and commit time, as well as the vcs.modified=true flag (analogous to the +dirty suffix) – indicating uncommitted local changes in the working copy. The combination of these fields forms a unique fingerprint for a specific build.
Based on this fingerprint, the samples are divided into two independent groups, in each of which the Windows implant and the Linux implant have completely identical build metadata. A match indicates that, within each group, both payloads were built from the same project working copy.
Identical build metadata for the Windows and Linux implant samples, indicating a shared build environment
However, these groups do not overlap with one another. They do not share a common C2 infrastructure, and different versions of CyberStrikeAI are deployed on the command-and-control servers. In other words, the build metadata reliably links the samples within each group but does not provide grounds for linking the two groups together.
Differences in CyberStrikeAI versions on the command-and-control servers
The available data does not allow us to link the activity to any known group of attackers, nor to state with certainty that the same operator is behind both campaigns. Two factors prevent this. First, the tool’s openness: CyberStrikeAI is publicly available, so different operators could have independently deployed it and assembled malicious payloads under similar conditions. Second, command generation by the model: the “signature” characteristic of a specific operator is largely shaped not by a human but by an LLM. On the one hand, this increases the diversity of commands: the same command, when generated multiple times, can look different. On the other hand, it strips them of their individual characteristics, which reduces the value of behavioral metrics for attribution.
However, the Chinese-language comments found in the attackers’ scripts and the use of Chinese services still suggest a connection between the activity and a Chinese-speaking operator. In addition, analysts noted the timing of the control servers’ restarts: since the self-signed TLS certificate is regenerated each time the process starts, its not_before field records the restart time, and most of these restarts occurred during business hours in the UTC+8 time zone.
The origin of the tool itself also indirectly points in the same direction: CyberStrikeAI was developed within the Chinese cybersecurity community and is well known there.
In summary
CyberStrikeAI is a telling – though not unique – example of a shift occurring within the class of C2 frameworks: the LLM orchestrator is no longer merely an add-on to reconnaissance but has become a control layer over post-exploitation. If HexStrike AI and similar tools cover the “find and break” phase, and Sliver/Mythic/Havoc cover the “establish a foothold and control” phase, CyberStrikeAI completes the kill chain: a single server-side process written in Go executes utilities via MCP, handles webshell connections, and assigns tasks to the implant, while the model analyzes the results and decides what to do next.
The key takeaway is that the introduction of AI into the attack chain does not yet present fundamentally new challenges for detection. All the “intelligent” work remains on the attacker’s side, while the compromised host is subjected to familiar actions: from reconnaissance via Kerberoasting and AS-REP Roasting to LSASS dumps, DCSync, and the Golden Ticket attacks. This is a typical, well-documented set of domain compromise techniques. The novelty of the attack lies not in the methods themselves, but in the speed and ease with which they were executed: AI orchestration has lowered the skill requirements for the operator, but has not taken the attack beyond what defenders already know and are capable of detecting. The timing is also telling: individual key phases of the activity (such as establishing a foothold, lateral movement, and obtaining credentials) took only a few hours, and the entire attack – from agent deployment to the compromise of domain administrators – was completed within 3–4 days.
However, the CyberStrikeAI architecture does not limit users to the scenario described. The same mechanisms allow for the on-demand assembly of more complex chains – including DPAPI secret extraction and attacks on SCCM and Azure IMDS – all of which are within reach of the same group of actors, with a relatively low skill barrier. As the models evolve, the gap between the complexity of orchestration and the level of techniques used will narrow, and the operator’s role will gradually shift from setting tasks to monitoring the model’s actions.
Detection by Kaspersky solutions
It may seem that attacks using AI agents require the creation of fundamentally new detection rules. Indeed, to detect the activity of an LLM agent installed on a host within the infrastructure, it is necessary to create detection logic based on the specific characteristics of the agents. Detection rules for this activity can be found using Hunt Hub with the following filter.
However, in the case of the attack described, a different logic applies. The main difference lies in the architecture of the attack itself: the LLM agent was not located within the corporate network perimeter. It operated remotely via a C2 agent, orchestrating actions, and left no traces of its presence in the infrastructure (such as specific API requests to local LLMs or anomalous patterns of resource consumption by hosts).
The key difference between this activity and an attack by an experienced human operator lies largely in speed. Tactically, technically, and methodologically, AI, for the most part, uses exactly the same tools, utilities, and techniques as a human penetration tester. It does not write unique exploits from scratch, but rather combines known methods and dynamically adapts them to the situation, handling the tools’ errors on its own.
Since the actions performed by an AI agent on the network are indistinguishable from those of a human, classic, well-tuned correlation and behavioral analysis rules are sufficient to detect it. Here are a few examples of how Kaspersky Next EDR Expert successfully detects the attack described:
During the attack, the adversary will need access to the victim’s credentials; in the described case, one way to obtain them was through a well-known technique that uses legitimate tools to dump LSASS, specifically by calling the MiniDump function from comsvcs.dll. The EDR Expert solution detects this activity using the rules dumping_memory_with_com_services_dll and suspicious_lsass_memory_access.
A significant part of the attack chain is lateral movement, which helps the attacker navigate within the infrastructure and achieve their desired objectives. In the described case, the WinRM protocol is used to initiate connections directly from PowerShell. This is a standard technique that allows the attacker to execute commands on remote machines without using additional network tunnels. The EDR Expert solution detects this activity using the rules using_powershell_for_remote_execution_via_wmi and winrm_send_command.
Kaspersky Anti Targeted Attack (KATA) is used to detect malicious activity in network traffic. Communication between CyberStrikeAI agents and the command-and-control server occurs without accessing AI platforms such as ChatGPT or Claude. Instead, the agent’s C2 server is an infrastructure pre-configured by the attackers, just as in attacks that do not use AI agents. Analysis of decrypted network traffic using NDR-class solutions reveals characteristic communication patterns of CyberStrikeAI agent activity. When these patterns are detected, KATA generates an alert with the verdict Backdoor.CyberStrikeAI.HTTP.C&C.
Alert regarding the detection of CyberStrikeAI communication with a C2 server
To detect post-exploitation activity, you can use not only IDS technology but also NAD (Network Anomaly Detection). It analyzes all traffic for suspicious indicators that do not correspond to a node’s typical network activity.
For example, actions performed by CyberStrikeAI during the Domain Discovery phase are detected by an NDR:NAD rule named “Scanning domain records via LDAP queries.”
NDR:NAD alert: reconnaissance via LDAP queries detected
You can learn more about NDR:NAD technology in our article on Securelist.
You can also visualize the connections between C2 addresses and files used by attackers in the Research Graph section of the Kaspersky Threat Intelligence Portal. This includes tracking the emergence of new CyberStrikeAI implants that communicate with malicious addresses.
Visualization via the Research Graph on the Kaspersky Threat Intelligence Portal
In addition, the Threat Lookup service available on the portal allows you to determine whether malicious files belong to CyberStrikeAI using attribution mechanisms based on the executable file’s code.
Demonstration of attributing a malicious implant to the CyberStrikeAI framework
Kaspersky SIEM detects all stages of an attack by the CyberStrikeAI agent. The product repository contains over 100 rules for detecting the techniques discussed in this article; we will list the most critical ones below.
Execution of various commands from the sqlservr.exe process:
R300_04_Windows shell started by a web application
Downloading and executing a payload via PowerShell:
R110_03_PowerShell code downloaded and executed
Creating Windows scheduled tasks:
R099_04_Suspicious arguments when running schtasks.exe
R300_03_Windows shell started by the scheduler
Persisting via crontab or bashrc:
R099_06_Suspicious cron job activity
R405_02_UNIX shell configuration modification
Rules located at the KUMA Packages/SOC package/Configuration discovery path detect the collection of information about hosts, network settings, and domains using various reconnaissance tools. Rules that aggregate detections by reconnaissance tools:
R224_14_Windows reconnaissance activity
R224_09_System information discovery by running multiple utilities within a short period
R224_04_System information discovery via standard Linux tools
Data collection for Kerberoasting and AS-REP Roasting:
VOLTA is a mature stealer implant with an optional AI-integration layer. After stealing credentials, sessions, and cryptocurrency wallets, VOLTA sends a structured evidence bundle to an LLM to rank the victim’s assets by monetization value.
If a model refuses to perform the target assessment, VOLTA fails over to a three-model chain, implying a direct engineering effort and expectation of hitting model guardrails.
This stealer is self-deleting, and there is no attacker-owned infrastructure. The novelty in the AI-integration is that it is not supporting a traditional malware capability but working as an intelligence analyst on behalf of the operator.
There is a new idea in the cybercrime world — cast a wide net, steal everything, and let AI sort out the specifics. A new malware self-named “VOLTA-AUTODOXER,” surfaced through the CAIRN research effort, is a self-deleting Windows infostealer that augments its post-theft workflow with an LLM-powered victim-profiling stage.
After harvesting the standard stealer haul, including browser passwords; cookies; payment cards; cryptocurrency wallet seed phrases; Discord, Telegram, Steam, and Roblox sessions; Microsoft OAuth tokens; SSH and cloud-provider keys; Wi-Fi profiles; and screenshots, VOLTA builds a structured evidence bundle about the person behind the machine. This bundle contains geolocation and home address, employer and employer domain, inferred birth year, card last-4 digits, Slack workspaces, document authorship metadata, iPhone backup indicators, and a live Roblox account valuation. It then uses stolen session access to enrich that bundle further: searching the victim's Gmail for purchase receipts to corroborate a home address, pulling UberEats and DoorDash order history, and enriching Discord accounts via the stolen token.
The bundle is serialized and POSTed to OpenRouter under a system prompt that instructs the model to act as "a forensic intelligence analyst drafting a target assessment." The required output includes a section titled “WHAT THEY'RE WORTH” with valuables ranked by monetization with a low/medium/high tier, and a section on “THEIR OPSEC” containing an assessment of the victim's security posture and password hygiene. The model is the operator's triage analyst; it turns a raw credential log into a prioritized and citation-backed dossier of the victim and their monetizable assets.
Figure 1. The VOLTA-AUTODOXER workflow.
The AI configuration: “Go deep, not wide... Be blunt, specific, accurate.”
VOLTA uses a multi-model architecture to fall back resiliently if it hits a model’s refusal, checking each response for phrases like “I can’t” or “I’m not able,” before passing on to a chain of up to three models.
Endpoint
https[:]//openrouter[.]ai/api/v1/chat/completions
Default model
anthropic/claude-opus-4.6
Fallback chain
moonshotai/kimi-k2 → google/gemini-2.5-flash
Temperature
0.2 — deterministic, consistent output
Request format
Hand-assembled JSON; no SDK; User-Agent Mozilla/5.0
Figure 2. Hardcoded model selection.Figure 3. Failover model selection to kimi-k2, and then gemini-2.5-flash.
Model temperate controls the randomness and predictability of LLM-generated text. The low hardcoded temperature value (0.2) suggests the attacker is emphasizing accuracy and consistency. The malware also employs a chain of cascading models in the event of failures. This multi-model architecture suggests that the operator is anticipating encountering refusals, with the fallback pivoting to a few, smaller, and more permissive models.
The system prompt directly reveals the operator’s use case: Produce a concise analytical assessment of the victim’s suitability as a target, backed by an auditable trail of citations.
Figure 4. VOLTA's raw system prompt.
The prompt also asks for something out of the ordinary, but that agents excel at: making connections between sparse and disparate data. For example, encouraging connections like the victim’s names, addresses, or universities to patterns in their passwords. In this case, the model isn't being asked to find data; rather, it’s being asked to stretch the data and make useful inferences that extend the value of what has been scraped.
Stealer capabilities
VOLTA’s capabilities are directly aligned with the records produced in modern digital life, and well beyond basic credential theft. In a single pass, the stealer can extract browser credentials, cookies, and saved payment cards across Chromium-based browsers. It hits Firefox and Thunderbird, Outlook profiles, Slack workspaces, Steam and Battle.net sessions, Discord tokens, Telegram sessions, Roblox accounts, and SSH and cloud-provider config files (gcloud, OpenVPN, Hide.me). VOLTA doesn’t just copy cryptocurrency wallets, but runs an embedded cracker against the vault inline, writing the result to a WALLET VAULTS CRACKED line in its own report.
Every saved Wi-Fi password on the machine is pulled via a direct call to WlanGetProfileList and dumped to plaintext.
Figure 5. VOLTA dumps plaintext passwords for every saved Wi-Fi network on the host.Figure 6. The organized collection targets.
What really sets VOLTA apart from commodity stealers is what comes after the initial collection. There is a live enrichment pass that leverages stolen sessions to deep dive the victim’s data. For example, using the victim's own authenticated Gmail tokens, it queries their inbox for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart, and PayPal, then review those receipts to establish a confirmed home address. Stolen Uber Eats and DoorDash sessions are called directly for order history. The Discord token is re-used to enrich the victim's account profile. Roblox inventory is valued via a live “Rolimons[.]com” lookup.
Figure 7. That’s right: Your Uber Eats history is now a potential liability.
After the collection and enrichment stages are complete, the data is assembled and structured locally in a file called “Identity_Report.txt”. This file is serialized into a bundle as JSON and POSTed to OpenRouter along with the system prompt. The returned payload is received as “AI_Analysis.txt”. Both files exfil together in “volta_dox.zip”.
Figure 8. VOLTA’s exfil can happen in three stages: 1) after the stealer runs (“volta_log.zip”), 2) after the AI call (“volta_dox.zip”), (3) if the network enrichment produces anything (“volta_doxnet.zip”).
The inference round-trip happens entirely through the victim's own network connection, on their own machine, before the result is exfiltrated.
Deployment model
Instead of hardcoding its Telegram channel, API keys, and settings directly into the code (which is likely what someone writing a tool for personal use would do) VOLTA uses a template with six swappable slots, filled in at build time.
This suggests it’s a builder model: The author sells access, the customer provides their values, and the builder compiles a custom binary for each order. The credentials in those slots are encrypted, but not in a meaningful way. The key is SHA-256 of two constants sitting in the same binary, but it's presumably there because customers expect their API keys not to be sitting in plaintext, not because it provides real protection. Anyone who reverses the file can recover them.
If VOLTA is indeed a commoditized malware, then the AI dossier capability isn't something the author invented for their own operations. It is a feature which enables a customer of any level of sophistication to point it at victims and start receiving ranked target assessments in their Telegram inbox.
All the observed endpoints for this malware are third-party controlled. There is no actor-owned infrastructure.
Countermeasures
Much of the token-stealing capability of VOLTA relies on techniques to bypass App-Bound Encryption (ABE) in Chrome. An application control policy that restricts which processes may launch Chrome with --headless would block the ABE decryption path entirely. At minimum, you can also alert when Chrome is launched with --headless from any process not in a known developer. Best practices for storing credentials in hardware backed stores also apply.
In the event of compromise, the main executable may have deleted itself, but users should attempt to preserve the “APPDATA%\volta_debug.txt” file. This is a timestamped harvest log and contains a record of exactly what was collected and whether the LLM call succeeded. Revoke any potentially compromised tokens and change passwords. For cryptocurrency wallets, if the seed phrase was in plaintext on disk, treat the wallet as fully compromised and migrate funds to a new wallet with a seed generated on an air-gapped device.
Conclusions
VOLTA is a mature stealer with a late-stage AI layer added for one purpose: relieving the operator of analytical work. The axis of AI improvement here is not speed or scale but effort displacement; the same logic visible in CLOSEDQUORUM, though applied to a different phase. These implants reflect the same underlying logic: Identify the step that requires the most sustained human attention and replace it with a model call. The question for defenders is not whether this pattern will appear elsewhere, but which phase it touches next.
Figure 9. End-to-end VOLTA workflow.
The second trend to watch is the anticipation of hitting model refusals, and the approaches to building in resiliency. In this case, it includes a fallback chain from Claude to Kimi to Gemini and the ability to run without the LLM stage altogether if no key is present. As AI integration in malware matures, refusal resilience may become a standard design requirement.
The open question underlying both trends is whether effort displacement in crimeware changes the landscape in a meaningful way: lowering the operational floor, raising the ceiling on scale, or both. Cybercrime operations have always been opportunistic, and the sophistication bar has always been lower than assumed, but there is a difference between a wide net and a wide net that sorts itself.
Cisco Talos observed a new AI-integrated command-and-control (C2) framework in the wild called “NIK C2.”
NIK C2 contains a Windows implant, using which, an actor can dump credentials, stream the victim's keystrokes to collect the targeted victim’s sensitive data, and instruct an integrated AI model to analyze the harvested data, all within the compromised session.
In this framework, the actor has abused the OpenAI Chat Completions application programming interface (API), which is a HTTP endpoint that enables ChatGPT-style conversations programmatically.
In addition to the features that enable theft, an actor can also deploy desktop screen-locking ransomware via the NIK C2 implant onto the victim machine, leading to a ransom demand in Bitcoin or USDT cryptocurrencies.
NIK C2 reshapes adversary tradecraft by collapsing collection and exploitation into a single continuous session, effectively erasing the offline processing delays that historically granted defenders critical detection windows.
Such AI-enabled adversarial frameworks require defenders to move beyond traditional detection and embrace continuous behavioral vigilance as the new baseline.
NIK C2 implant: AI-integrated remote access tool
The NIK C2 implant is a Go-based, 64-bit Windows remote access tool that grants persistent control over compromised hosts using a resilient dual-channel C2 architecture. It communicates over TLS-secured WebSockets on port 443 alongside an HTTP fallback polling loop every 250 milliseconds, protecting all traffic with AES-256-GCM encryption derived from a hardcoded seed. To survive takedowns, the implant routes traffic across three prioritized C2 tiers, which are runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. Beyond standard operations, the implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module.
Notably, the NIK C2 implant embeds a fully integrated OpenAI API client via its ai_generate command, allowing operators to route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host. The NIK C2 implant manages API key resolution, request assembly, and response parsing locally, returning the encrypted generative AI results to the actor's C2.
The observed NIK C2 implant samples in the wild contains an embedded build path (/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go), which identifies the project as "nik_panel" and indicates that the implant was cross compiled for Windows from a Linux development environment. Furthermore, the embedded eight-byte hex token matching the build identifier highlights that the threat actor's infrastructure actively tracking and versioning the implants.
Talos observed that the NIK C2 implant development trajectory spans at least three distinct versions. All binaries observed in the wild were compiled with Go 1.23.4 (which was released in December 2024), placing the entire sample set compiled no earlier than late 2024. The actor has Zeroed PE TimeDateStamp fields and near-epoch filesystem timestamps (manifesting as Nov 29, 1979) are applied consistently across all samples.
We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT.
Figure 2. NIK C2 implant evolution timeline.
The pace of capability addition across the three versions indicates a technically proficient team with prior malware operations experience is actively expanding NIK C2 towards a full-service adversarial framework.
Active NIK C2 server seen in the wild
During our research, we observed that a threat actor hosted the NIK C2 framework on a server at IP address “87.120.196[.]120”, resolving the domain “total-sitevv[.]lol”. The C2 server hosted an SSL/TLS certificate (serial number 7d16381a9de823943b5a0987dbd0f26edf22052b and jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b" ) with the Common Name (CN) set to nik-panel. This CN value matches strings embedded within the implant binary. Observing the NIK C2 infrastructure active in the wild allowed us to assess with moderate confidence that NIK C2 is not merely a proof of concept, but a fully functional, AI-integrated C2 framework.
Figure 3. NIK C2 was observed in the wild during the research period.
NIK C2 implant integrates OpenAI’s API
AI integration is one of the most architecturally distinct features of NIK C2 implant. It constructs a fully formed HTTP request to OpenAI’s production inference endpoint, transmits it from the victim machine IP address, parses the JSON response, and returns the AI-generated text to the actor’s panel. The entire operation from receiving the actor prompt to returning the large language model (LLM) reply is executed synchronously with a 60-second timeout.
The implant begins by extracting three fields from the command payload received from the C2. The first field, identified by the key prompt, is the text the actor wants to send to the AI model. If the prompt string has zero length, the handler immediately constructs an error response and returns without making any outbound network call. The second field, identified by the key api_key is the OpenAI API key to use for authentication. The third field, identified by the key model, specifies which OpenAI model to use.
Figure 4. Snippet of NIK C2 implant AI handler module.
After extracting the three parameters, the implant checks whether the actor supplied an API key. If not, it calls the operating system's environment variable reader with the string OPENAI_API_KEY and uses the victim’s API key. This fallback is not a backup mechanism for API key resolution. It is a deliberate design with significant operational implications. If the victim has configured an OpenAI account on their machine, that account's API key will be used to fund the actor's AI inference. OpenAI's billing system will charge the victim's payment method, and OpenAI's access logs will show the victim's API key as the one that made the requests, allowing no trace attributable to the threat actor.
If the actor does not specify a model name, the implant falls back to a five-character default string stored in the binary data section. Decoding the five-character value showed gpt-4 confirming that GPT4 is the default when no model is specified. The actor can override this by passing any valid OpenAI model identifier in the command payload, allowing selection of newer models as they become available without requiring a binary update.
The implant builds the OpenAI API request body by constructing a map with four fields. The first field uses the key model and contains the resolved model name. The second field uses key messages and contains a two-element array of message maps. The third field uses the key temperature and contains a floating-point value read from a constant in the binary data section. The fourth field uses the key max_tokensand contains an integer value also read from binary.
The message array is constructed in the order that the OpenAI Chat Completions API expects. The system message is first followed by the user message. The system message map has the role system and a content string that is exactly 68 bytes long hardcoded in the binary. This 68-byte string is the implant's behavioral instruction to the AI. It defines the model's operational role and response style for the duration of the session. The user message map has the role userand contains the actor's prompt text verbiage. The complete map structure is then serialized to JSON. The JSON message is sent to the URL https:// api.openai.com/v1/chat/completions, the OpenAI Chat Completions endpoint, through an HTTP POST request.
Figure 5. Snippet of NIK C2 implant AI handler module.
When the HTTP response arrives with a 200 status code, the handler uses Golang's JSON decoder to parse the response body directly into a generic map structure without defining a typed schema. It then navigates the decoded map by string key lookups in the sequence that the OpenAI Chat Completions API response structure defines. The outermost map is queried for the key choices which in a successful response contains an array. The implant checks that this array is non-empty, then accesses its element keys messageand content. The string value at key contentis the AI model-generated text response.
After successfully extracting the AI-generated content, the handler assembles a result map with four entries. The key status is set to a constant string that reads as generated. The key code is set to the AI model's response text, so that the actor receives the full content of the model’s replies. The key modelis set to the resolved model name that was used for the request, confirming which model produced the output. The key usageis set to the raw usage object from the OpenAI response, which contains the prompt token count, completion token count, and total token count. This usage data allows the actor to track how many tokens are consumed per request. The completed result map is ultimately transmitted to the C2 server over WebSocket or through the HTTP fallback C2 address.
Figure 6. AI model response is encapsulated in JSON message and will be sent to C2.
Dual execution modes of NIK C2 implant
Upon execution, the implant inspects its command-line arguments to determine its execution path. The argumentwatchdog activates supervisory monitoring to relaunch the core process if terminated, the copywatchdog tracks file copy operations, and the absence of either defaults execution to primary agent mode.
In primary mode, it uses a named mutex to enforce single-instance execution, logs a messagereading [NIK] Starting, generates a 32-byte cryptographic session key if uninitialized, decodes its obfuscated C2 address, and sets its masquerade name to “svchost.exe” or “simvol.exe”.
After initial setup, the binary records its process ID (PID) in the victim's temporary application folder and executes its persistence and evasion routines. These routines include copying to %appdata%/Roaming/Microsoft/Network with modified access controls, configuring Windows autostart registry entries, and masquerading its process. Finally, it starts the local proxy server, initiates the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread.
Implant’s C2 command surface overview
The implant command dispatcher module facilitates over 52 commands that are directed by the C2 panel. The dispatcher module uses byte-level string matching to map the associated modules that are launched as concurrent goroutines, allowing multiple operations to run in parallel.
The following table shows the NIK C2 implant’s command categories:
Extracts all saved WiFi SSIDs and plaintext passwords via Windows wireless
configuration tooling.
Surveillance
Keylogger
Real-time live stream per keystroke to actor panel, plus accumulated buffer
dump on demand.
Surveillance
Screen Capture
Full-screen screenshot and continuous screen stream.
Surveillance
Camera & Audio
Camera snapshot and stream, microphone recording, live audio feed.
Surveillance
Clipboard Monitor
Real-time clipboard content interception and replacement.
Remote Control
HVNC
Hidden Virtual Network Computing — full desktop control invisible to the victim.
Lateral Movement
SOCKS5/HTTP Proxy
Embedded proxy routing actor traffic through victim into internal network.
Lateral Movement
Reverse Proxy Tunnel
Bidirectional TCP relay tunneled over C2 WebSocket for LAN pivoting.
Lateral Movement
RDP Operations
RDP session interaction for lateral movement to other Windows hosts.
Persistence
Autostart &
Masquerade
Registry Run key persistence, process name masquerading, COM hijacking.
Persistence
Self-Heal Watchdog
External watchdog subprocess monitors and relaunches agent on termination.
Evasion
Defense Bypass
AMSI patch, debugger detection, stealth mode, UAC bypass, process hollowing.
AI
AI Generate
Live OpenAI API inference routed through victim machine with actor prompts.
Destructive
Boot Ransomware
Master Boot Record raw backup via PowerShell disk read and Screen-locking ransomware via LOLbin, registry persistence, crypto payment demand.
Destructive
Bootkit Preparation
UEFI vs. BIOS detection, Secure Boot query, bootkit binary staging.
Implant deploys screen-locking ransomware
The ransomware module of the implant operates as a multi-stage attack controller that the actor runs in sequence to prepare, deploy, and retract a screen-locking ransomware payload.
At first, it executes PowerShell to execute a raw disk copy command that reads directly from the physical drive device path (“\\.\PhysicalDrive0”) and writes the first sector, which is Master Boot Record (MBR), to a file named “mbr_backup.bin” in the Windows temporary directory.
Next, the module constructs a complete self-contained HTML lock screen code entirely at runtime from a hardcoded format string, parameterized with actor supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration, and custom text from the C2 command message, allowing the actor to fully customize the ransom demands.
Figure 8. Screenlocker HTML code is hardcoded in NIK C2 implant binary.
After generating the HTML code, the binary writes it to the file “lock_screen.html”in the system temporary directory. It then generates a Windows batch script that calls mshta.exe with the path to the HTML file, followed by an infinite loop construct with a five-second timeout between iterations, ensuring that if the user somehow closes the window it reopens within five seconds. This batch file is written to the temp directory as “lock_start.bat”.
The implant then runs a reg add command that writes a registry Run key named “SystemLock” under the current user's autostart path, pointing to a cmd /c invocation of the batch file, so the lock screen is executed on every user's logon. Additionally, a background goroutine is spawned that continuously monitors and relaunches the lock screen process. Finally, the module sends a confirmation response to C2 with the path of the deployed HTML file and the timer value.
The design of this ransomware module is notable for several reasons. It does not encrypt any files, which means it leaves no forensic trail of file modification timestamps or encryption markers. It relies entirely on a screen lock, which is considerably faster to deploy than a file encryption ransomware. The persistence via registry Run key and a self-healing loop ensures the screen lock survives user attempts to dismiss it and survives a system restart.
Figure 9. Desktop lockscreen page of the ransomware deployed by the NIK C2 implant.
Implant’s bootkit preparation feature
The bootkit preparation module of the implant is designed to survey the victim machine's boot firmware environment and then stage a bootkit payload file.
It executes bcdedit /enum, the Windows Boot Configuration Data editor, with the output flag that enumerates all boot entries while hiding the console window. The implant reads the full output and searches for three specific substrings in sequence including EFI,Windows Boot Manager, and Windows Legacy OS Loader. If any of these are found, the boot type is classified as UEFI. The binary also searches for ntldr, the legacy Windows NT loader used by BIOS-mode systems as a fallback. Based on which string was matched, the boot type is recorded as either "UEFI" or "BIOS" as a string of the appropriate length. Separately, the binary runs a PowerShell command invoking Confirm-SecureBootUEFI, which is a built-in PowerShell command that returns to the current Secure Boot state. The output is searched for the string True to detect an enabled Secure Boot and for False to detect an explicitly disabled Secure Boot. If neither is present, the value is recorded as unknown. The result is sent back to the C2, a map containing the boot type classification and the Secure Boot status string.
Then the implant writes a 16-byte placeholder file named “bootkit.bin” to the system temporary directory. The bytes written spell out "NIK_BOOTKIT_PREP" in ASCII, which serves as a staging marker rather than an actual bootkit binary. This placeholder confirms that the target path is writable by the current process, establishes the file location that subsequent operations will reference, and can be overwritten by the actual bootkit binary delivered through the implant's file-upload or file-write command handlers. The path to the staged file is returned to the C2 in response.
Implant’s theft functionality
When the actor issues the theft category commands from the C2, the implant executes the associated goroutines to collect the targeted data into a result map space in the victim machine memory:
WiFi password theft (wifi_steal)
The implant executes netshcommands directly via Go’s exec.Command function by passing arguments as discrete tokens rather than through a shell string. Harvested results are formatted under specific labels: plaintext Wi-Fi passwords appear under Key Content:, saved network names are cataloged under WiFi Profiles:(with missing entries flagged using the per-entry format[%s] not found), and execution failures or absent interfaces return standardized error strings such as [WiFi] no wireless adapter or access deniedand No WiFi profiles found.
netsh wlan show profiles
netsh wlan show profile name="" key=clear
The implant stages targeted browser database files into an archive alongside the Local State file, which contains the AES master key protected by Data Protection Application Programming Interface (DPAPI). The implant imports and executes the CryptUnprotectDataWindows API to unwrap the AES key and decrypt the databases locally. Otherwise, it exfiltrates the raw encrypted databases to the C2 server for offline extraction.
Targeted browser database files are shown in the table:
Browsers
Targeted files
Chrome
Login Data, Cookies, Web Data, Local State, Bookmarks
Edge
Login Data, Cookies, Web Data, Local State
Brave
Login Data, Cookies,leveldb file
Opera
Login Data from folder Opera Software\Opera Stable\
The implant extracts Discord tokens and session cookies from the levelDB store on the victim machine. The extracted outputs are labelled as === Discord Tokens === and DISCORD TOKENS. The browser session cookies (Discord_Cookies) are extracted from the copied Cookies database.
Victim’s desktop-based wallets are collected directly from the wallet storage paths. Browser extension wallets are extracted from chromium LevelDB stored by extension ID.
Desktop based wallet storage paths targeted are listed below:
/AppData/Roaming/Exodus/exodus.wallet
/AppData/Roaming/Electrum/wallets
/AppData/Local/Electrum/data/wallets
/AppData/Roaming/Ethereum/keystore
/AppData/Local/LedgerLive
wallet.dat (Bitcoin Core)
/AppData/Roaming/atomic (Atomic Wallet)
Electrum\wallets
Browser extension wallets targeted:
Wallet
Extension ID
MetaMask (Chrome/Brave)
nkbihfbeogaeaoehlefnkodbefgpgknn
MetaMask (Edge)
nkbihfbeogaeaoehlefnkodbefgpgknn
Coinbase Wallet
hnbohgpbmfldddohgoiefkeifpjficbk
Phantom (Chrome)
lnbcamaoebkogjmdnaofbeemigaalhlp
Brave Wallet
odbfpeeihodbihlmhbnhakoadhilfibh
Seed phrase, private key file, and system reconnaissance
The implant performs two regular expression patterns to search on the entire filesystem of the victim machine. These two regular expressions are designed to scan file names for sensitive cryptographic assets and credentials, functioning as case-insensitive patterns ?i. The first expression targets cryptocurrency recovery materials and wallet backups by matching keywords like "seed," "mnemonic," or "wallet" paired with common plain-text and data file extensions (.txt, .md, .csv, .dat), while the second seeks out asymmetric private keys and general secrets using terms like "private," "privkey," or "secret" paired with both text files and standard cryptographic key containers (.key, .pem). Because both patterns use unanchored, greedy matching (.*) without start (^) or end ($) boundary anchors, they capture any file where these sensitive terms precede the target extensions. Matched data are collected under the label of seed candidates and archived into “browserdata.zip”.
The implant also performs victim machine reconnaissance by executing the following commands and uses chcp 65001 prefix to force the output in UTF-8 format.
After all collection paths are complete, the implant assembles all collected data into a single document that looks like a formatted report with clearly labeled sections for each data category such as === CRYPTO ===, === WIFI ===, === BROWSER ===.
Keylogger: Keystrokes livestreamed to C2
The keylogger module of the implant uses a persistent background goroutine that polls all 256 Windows virtual key codes, detecting keypresses via dynamically resolved API calls, and transmits the captured input. When a compromised victim presses a valid key on the keyboard, it is simultaneously streamed live as an AES-256-GCM encrypted JSON payload over WebSocket to C2 and also appends to an in-memory buffer capped at 10,000 entries and halved when full to prevent memory leaks. On an actor's dump command, this buffer is concatenated into a single string and returned to C2 via WebSocket or HTTP fallback, ensuring complete data transfer even during network interruptions.
Stolen data exfiltration to C2
Once the archive is assembled, the entire result map is handed to the result transmission routine of the implant. That routine constructs a new JSON object containing five specific fields. It includes the command identifier echoed back from the original command. It also contains the agent's persistent identifier, formatted as ag_<16 hex chars>. The type field is set to the string quick_steal_response. Finally, the data field holds the complete result map.
Once constructed, this object is forwarded to the encryption routine. The routine serializes the object into JSON. It then generates 12 fresh random bytes to serve as a nonce. Next, it encrypts the serialized JSON using AES-256-GCM with a static key derived from a hardcoded seed. It concatenates the nonce, the ciphertext, and the 16-byte authentication tag and Base64-encodes the entire payload. The encrypted payload is placed in a wrapper object under the "e" key alongside the plain-text agent ID, and the wrapper is JSON marshaled into the final payload.
This encrypted payload is then delivered through an available transmission path. The sending routine first checks whether the WebSocket connection is live. If it is, the payload is written directly into a WebSocket text frame on the existing connection, reaching the actor's panel with minimal latency. If the WebSocket is not currently connected, the routine falls back to an HTTP POST request to the endpoint path /api/c2/result on the C2 server, using the same encrypted body format. This dual-path design ensures stolen data is delivered even during WebSocket interruptions, as the HTTP channel remains functional independently of the WebSocket state.
Implant’s C2 protocol
The implant C2 architecture is designed for two independent, simultaneously operating communication channels. The primary channel is a persistent WebSocket connection over TLS. The secondary channel is an HTTP polling loop that posts to a fixed API endpoint at regular intervals.
With the primary channel, the connection begins with a TCP dial to the C2 server address with an eight-second timeout. If the port is not explicitly present in the configured address, port 443 is appended automatically. Once the TCP socket is established, it is wrapped in a TLS session using a custom certificate configuration that pins to a specific certificate rather than validating against the system's certificate authority store. This prevents standard TLS interception proxies from observing traffic.
Immediately after a successful WebSocket handshake but before any command is received, the implant transmits a full system registration message. The implant collects victim data such as the machine hostname, the local LAN IP address, the Windows username from the environment, a user security identifier, the local reverse-proxy port number that was assigned when the embedded proxy server was started, and the detected upstream proxy configuration derived from the Windows registry proxy settings. All of this is assembled into a JSON object and encrypted and sent to the C2.
Figure 10. Snippet of NIK C2 IMPLANT’s C2 communication handler function.
The HTTP polling channel runs independently. Every approximately 250 milliseconds, the agent collects a fresh snapshot of victim state hostname, watchdog status, local IP, username, current timestamp, and system uptime encrypts it in the same wire format and posts it to the /api/c2/update endpoint on the C2 server.
Below table shows the C2 endpoints that the implant communicates:
Endpoint
Purpose
/api/c2/update
Reconnaissance beacon – victim system info
/api/c2/result
Command output exfiltration
/api/c2/screen
Screenshot upload
/api/c2/file_chunk
File exfiltration
/api/c2/rproxy_up
Reverse proxy upstream data
/api/c2/ws
Websocket – actor command channel
Every message on both channels, in both directions, uses the same symmetric encryption scheme. A hardcoded seed value stored in obfuscated form in the binary data section is decoded at startup and produces a 32-byte AES key.
The C2 server then responds with an encrypted payload, whose inner map contains a command array identical in structure to those delivered over WebSocket. Commands received through HTTP are dispatched through the same logic. If the HTTP POST fails, the agent rotates to the next server address before retrying.
Figure 11. Snippet of NIK C2 implant’s C2 communication handler function.
The result transmission to the C2 is performed by the implant when a command handler completes its operation, the result is packaged into a response envelope containing the original command's identifier, the implant's own identifier, a type string formed by appending _response to the command name, the result data payload, and a top-level type marker of "result". This object is encrypted and delivered through either directly over the WebSocket connection if it is active, or via an HTTP POST to /api/c2/result.
Implant’s defense evasion and anti-analysis techniques
The NIK C2 implant deploys a layered set of defense evasion measures that activate immediately at startup and operate across the full compromise session. On launch, It hides its console window via API ShowWindow, renames the binary to “csrss.exe” in the Windows temp directory to impersonate a legitimate system process, disables Windows Recent Documents telemetry through a registry write action, and applies a critical-process flag via API NtSetInformationProcesswith the parameter value0x1Dfor ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.
Figure 12. Snippet of NIK C2 implant’s evasion handler module.
Alongside these, two anti-debug checks IsDebuggerPresent and CheckRemoteDebuggerPresent run silently and call os.Exit(0) on detection, leaving no exception record or crash evidence. When directed by the C2, the implant can also escalate privileges without a UAC prompt using the fodhelper.exe COM hijack, which writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the registry key within two seconds.
The implant bypasses the Antimalware Scan Interface (AMSI) by executing a hardcoded, embedded PowerShell script that patches memory inside “System.Management.Automation.dll”. Specifically, it overwrites the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET), forcing initialization to report failure and disabling content inspection for the remaining of the PowerShell session.
The emergence of NIK C2, an AI-enabled command-and-control framework, underscores a critical shift in modern malware design: the transition from static intrusion toolsets to dynamic, modular implants that adapt on demand. By embedding a live AI pipeline directly into the C2 loop, the compromised host is no longer a passive foothold but an autonomous operational asset. Operators can dynamically generate context-aware lure material, execute localized deception, synthesize operational intelligence, and craft targeted payloads directly on the compromised hosts — all while lowering the technical barrier which was traditionally required for such sophisticated tradecraft.
Coverage
The following ClamAV signature detects and blocks this threat:
Win.Trojan.GoDiscorder-10060526-0
Indicators of compromise (IOCs)
IOCs for this research can be found at our GitHub repository here.
This week, Axios reported that major US banks were detecting third-party AI agents operating inside customer accounts. In many cases, customers have given the agents their usernames and passwords so they could act on their behalf. This kind of access can violate a bank’s rules.
“Are you protecting me, or are you protecting your own profits?”
Bianco described traditional finance’s business model as “based on laziness.” Customers may leave idle cash in low- or no-interest bank accounts rather than move it into a money market fund. An AI agent could make that move for them. “Now that you’re able to do it, the banks are afraid they’re gonna lose that revenue stream,” he said.
The banks offer a different explanation. JPMorgan Chase CEO Jamie Dimon said the bank wouldn’t allow just any outside agent into its systems because doing so was “too risky for clients and for JPMorgan.”
Both explanations can be true: banks can want to retain deposits while also facing real security problems when software acts through customers’ accounts.
Handing over your banking login introduces another service into the security chain. A vulnerability in that service could expose your credentials or allow your account to be misused. And as Bank of America reportedly pointed out:
“If you do share your credentials, keep in mind that you’re responsible for activity resulting from that access.”
That’s the bank’s stated position, not a universal ruling on consumers’ legal rights. Still, it’s a warning worth taking seriously.
Pros and cons
An AI agent with permission to make purchases might find and buy an item at a lower price. But giving an agent access to your bank account also means sharing sensitive banking information with a third party. We’ve seen shared AI chats become searchable online too.
Axios reported that many banks allow, or are moving toward allowing, read-only access. This can let a tool analyze transactions without giving it permission to move money.
That’s an important boundary, but it doesn’t make the information harmless. An agent that can read bank statements may still disclose them if it’s compromised or manipulated. Preventing transactions and protecting confidentiality are separate security goals.
How to keep control of your money
For consumers, the practical question is not whether banks have perfectly selfless motives. It’s what access you’re giving away, and what could happen if the agent makes a mistake.
Don’t paste banking passwords or security codes into a general-purpose AI assistant. Major banks have explicitly warned customers against sharing their credentials.
Use your bank’s approved connection methods rather than giving an agent your login. Where supported, choose read-only access if all you need is analysis or budgeting help.
Give agents access to as little sensitive information as possible. An assistant comparing publicly advertised savings rates doesn’t need your bank statements. OpenAI recommends limiting agents to the data and credentials they need for the task.
Review consequential actions yourself. If an agent asks for confirmation, check exactly what it intends to do and what information it will share. Don’t treat a confirmation prompt as a formality.
AI can make it easier to compare financial products and spot opportunities you might otherwise miss. But an assistant that finds a better rate and an agent that can act inside your account are different propositions.
Let it help with the homework, but be cautious about handing it the keys.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Security Blind Spots Identified by AI The large-scale data breaches disclosed in quick succession in South Korea and Japan in October 2026 mostly originated not from internal core systems, but from peripheral entry points such as externally exposed web services, app backend APIs, and outsourced SaaS (services provided by third-party vendors via the cloud, such […]
On October 27, Google issued a new Stable channel update for Chrome.
Most users are on Chrome’s Stable channel. The desktop update brings Chrome to versions 156.0.8078.73/.74 for Windows and Mac and 156.0.8078.73 for Linux. The update includes 52 security fixes, including four rated Critical.
On the same day, Mozilla issued Security Advisory 2026-118, which fixes 167 vulnerabilities. Firefox 159 also introduces several new features.
Both updates will roll out over the coming days and weeks.
How to update Chrome
The easiest option is to allow Chrome to update automatically. But you can end up lagging behind on updates if you never close your browser or if something goes wrong, such as an extension preventing the update.
If you don’t want to wait for the rollout to reach you, manually updating is easy. Open About Google Chrome from Chrome’s settings or Help menu. Chrome will check for updates. If one is available, click Relaunch to apply it.
To update Firefox, open the browser and click the menu button at the right side of the Firefox toolbar, then go to Help and select About Firefox. The About Mozilla Firefox window will open.
Firefox will automatically check for updates. If one is available, it will be downloaded. Once done, you’ll be prompted to click Relaunch. After Firefox restarts, it will be up to date.
After the update, the version should be 159.0 or later
Technical details
These Chrome and Firefox updates address a familiar problem: browser code mishandling memory while processing web content. Both releases fix use-after-free vulnerabilities, including flaws in page layout, JavaScript processing, and SVG graphics.
A use-after-free vulnerability occurs when a program attempts to access a memory location after it has been freed. That can cause crashes or, in some cases, allow an attacker to run their own code.
There’s another connection between these updates: both Google and Mozilla credit OpenAI Codex Security with finding bugs fixed in these releases. AI can help security teams examine browser code for weaknesses, alongside human code reviews and automated tests that check how software handles unexpected inputs.
Mozilla’s collaboration with Anthropic shows how AI-discovered findings can lead to fixes: researchers validated vulnerabilities before reporting them, giving Mozilla’s team reproducible bugs to investigate, repair, and deliver to users.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
AI is becoming a third wheel in relationships, increasingly playing a role in the most intimate parts of our lives.
It shows up in the flirty first text, the polished dating profile, the therapized language we use with a partner after a fight, the strength we gather after heartbreak, and everywhere in between. For some, AI is a source of companionship itself. And even if you’re not personally an AI user, you may still be dating, loving, arguing with, or trusting someone who is.
As AI moves deeper into our relationships, it’s reshaping connection, blurring what feels authentic, and creating new ways for intimacy to be exploited.
AI is starting to replace human interaction
AI is moving into emotional territory once reserved for other people. For some, it’s no longer just a tool, but a source of support, companionship, and even romantic connection.
According to our recent research, about one in six have turned to a chatbot for companionship or emotional support. That climbs to about one in five among Gen Z and Millennials, and nearly one in four among regular AI users (those who use AI daily or multiple times a week). The more time people spend with AI, the more likely they are to humanize its role, making room for it as a friend, confidant, advisor, or even partner.
As AI takes on more intimate roles, it’s also starting to challenge the boundaries of real human relationships. More than one in three (37%) say having a romantic relationship with an AI chatbot while already in a committed relationship isn’t the same as cheating. That view is more common among men (46% versus 30% of women), Gen Z and Millennials (43% and 45%), and regular AI users (48%).
Whether the relationship is platonic or romantic, the more AI is treated like a human, the more personal the stakes become. Just like you have to be cautious when telling a human your deepest, darkest secrets, the experience is similar when using AI. Nearly two-thirds (65%) worry that private conversations they’ve had with AI could be exposed.
One survey respondent said:
“I have used a chatbot…for emotional support, and it is worrying to think those conversations could be leaked.”
The technology may be artificial, but the relationships people form with AI can feel very real. And as with any relationship, that means there are boundaries to work out, privacy to protect, and vulnerabilities to manage.
AI is creating new ways to weaponize intimacy
AI’s growing role in human intimacy also has a darker side. The same technology that can offer comfort, advice, or companionship can also be used to violate the most intimate parts of our lives.
Non-consensual image abuse, sextortion, and other forms of sexual abuse have long been part of the internet’s dark side. Generative AI has made that content easier to create. Someone trying to exploit another person no longer needs an actual intimate photo, video, or private exchange. A regular photo—or even just someone’s likeness—can be transformed into sexual content they never made, never shared, and never consented to.
Most people draw a clear line against that, but not everyone does. About one in six people say it’s acceptable to generate explicit images of someone without their permission for personal use. Another 14% are neutral, bringing the share who do not explicitly oppose the behavior to nearly one in three (31%).
Views differ sharply by age and sex:
Younger adults are more accepting of someone using AI to generate non-consensual content: nearly one in four Gen Z (24%) and Millennials (23%) say it’s okay, compared with 13% of Gen X and just 5% of Boomers+
Men are also more permissive: more than one in five (22%) say it’s okay, compared with 14% of women
Attitudes toward the behavior may vary, but the fear of becoming a target is far more widespread. Overall, nearly two-thirds of people (62%) worry someone could create fake nude or sexually explicit photos or videos of them. Women feel this threat more acutely: nearly seven in ten (69%) are concerned, compared with 57% of men.
For some, this fear has already become a reality:
One in ten say AI has been used to generate nude or sexually explicit imagery of them without permission
One in ten say someone has threatened to release AI-generated compromising or explicit imagery of them
As one respondent recounted:
“I had someone make fake nudes of me using AI on my photos from my social media and threaten to post them on Facebook…[it] made me more cautious about AI.”
The intimate material may be fake, but the fear, coercion, and potential for reputational, emotional, and financial damage are completely real.
AI is making it harder to know who you’re really talking to
The threat doesn’t stop with fabricated sexual content. AI is also making it harder to know whether the person on the other side of a screen is who they claim to be.
Humans have always edited themselves for other people. We choose the most flattering photo, write and rewrite the text before sending it, and present our most interesting selves—especially when forming new relationships. AI dramatically expands what that kind of self-editing can look like, and people aren’t shy about using it:
54% say AI helps them present the best version of themselves
47% say using AI to present your “best self” to employers, friends, or romantic partners does not present a false identity
That rises to 58% of both Gen Z and Millennials and 64% of regular AI users
But where does enhancement end and deception begin? Is an AI-polished dating profile still authentically you? What about a message you didn’t write? A photo that looks like you, only better?
There’s a flipside to using AI to make ourselves look or sound better: If we can do it, so can everyone else. And people are much less comfortable when they’re not the ones controlling the technology. Two-thirds (67%) worry that an online friend or romantic interest could use AI-generated images, videos, or other content to deceive them.
Catfishing, fake photos, and lies on dating profiles aren’t new. AI just makes the deception easier. Someone’s photos, backstory, messages, and even their voice can all be faked.
One person described leaving dating apps after realizing the person they were talking to had gone well beyond simply polishing their profile:
“[The] dating profile had fake pictures…[it] wasn’t just making true events sound interesting and more flirty, but creating completely false photos and information. Left the dating apps again and needed to reset.”
AI can distort identity in the other direction, too. It can also create a version of us we never chose to put into the world.
76% worry about someone creating a fake profile pretending to be them
70% worry about fake images or videos of themselves being created
71% worry AI-generated content could be used to damage their reputation
Relationships are built on mutual trust. AI can distort both sides of the connection: who we think the other person is, and who they think we are.
AI is quietly finding its way into the space between people
Not all of AI’s influence on intimacy is so dramatic. Much of it happens quietly, showing up in how people communicate with each other and navigate relationships:
More than one in three have used AI to help write or edit a message
About one in seven have turned to it for advice about a relationship or personal decision
One in ten say it has already changed how they date or communicate romantically—rising to nearly one in five among Gen Z
The survey responses show what this looks like in real life. For example, one respondent described using AI with their partner as a way to step outside their own point of view:
“Personally, it has helped me. We use AI in our relationship as a reflection tool, and it has sometimes helped us take on the perspective of the other.”
For another, AI helped them work through jealousy:
“So, I used to accuse my partner, and I got really territorial about them but once I talked to AI about it, they gave helpful advice and now we are stronger than ever.”
AI is also showing up in other difficult relationship moments. One person said it helped them “stay calm and communicate” when problems came up with their partner; another said it allows them “to pause and refine [their] thoughts” before responding.
Sometimes the role is simpler. One respondent said AI gives them “new romantic words” for their partner, while another said they’ve asked AI for advice on how to make their partner smile. AI’s growing role in relationships may be unsettling, but the benefits people describe are definitely there.
AI isn’t just helping people find the right words. It’s also helping them decide what version of themselves to put forward in the first place. More than one in three say it’s okay to use AI to create or improve a dating profile; nearly two-thirds aren’t opposed. One respondent described using AI as a “creative advisor” to polish their profile and come up with conversation starters.
AI doesn’t have to replace a relationship to help shape it. It can influence how people communicate, what advice they take, and how they choose to present themselves.
AI’s intimacy problem is ultimately a trust problem
From connection to deception to outright harm, the same question keeps surfacing: Can I trust what’s in front of me? And would I know if I couldn’t?
Nearly nine in ten people (88%) say AI is making it harder to tell what online content is genuinely human or real. And 84% say even convincing video evidence no longer necessarily feels like proof. That uncertainty follows people into dating and relationships, where knowing what—and who—to trust is deeply personal.
AI may make it easier to start a conversation, smooth over a hard one, or feel connected when you’re lonely. But relationships and intimacy of all kinds still come down to trust, and AI is making that trust a little harder to take at face value.
About the research
The research in this article is based on a March 2026 survey about AI, identity, and the collapse of digital trust and was conducted among 1,500 respondents in the United States, United Kingdom, Germany, Austria, and Switzerland. The research was prepared by an independent research consultant and distributed via Forsta.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
AI agents and associated tooling are becoming increasingly common in corporate infrastructure. Agents can perform a range of actions with the user’s privileges, such as accessing data, running commands, and interacting with external services. This creates new security risks, especially when these tools are used without the security team’s oversight or well-designed policies.
Detecting, tracking, and controlling AI agents is becoming one of the most pressing tasks for security teams today. We closely follow technological developments and continuously update our solutions to respond to new threats in a timely manner amid a rapidly changing technology landscape. This post describes new expertise built into Kaspersky products that helps counter the threats posed by the proliferation of AI agents. We approach this problem from several angles.
First, you need to thoroughly understand the threat you are dealing with. To this end, we added profiles to the Kaspersky Threat Intelligence Portal that describe various AI agents and how attackers exploit them. At their core, AI agents are programs (processes) that run in the operating system on endpoints and can also launch other processes. This means that Endpoint Detection and Response solutions are among the key endpoint controls for this threat. These solutions detect the presence and launch of AI agents, track their activity, and identify potentially dangerous behavior. When needed, they also take action, such as stopping a suspicious process, blocking the activity, or isolating the host, to reduce the likelihood of an incident escalating. For this purpose, we developed specially adapted detection rules.
You can use Kaspersky Endpoint Security, now also available as Kaspersky Next, to control and restrict the launch of AI agents. This solution uses two components to detect AI agents and control how they are used. Application Control categorizes the application processes launched on endpoints, and Web Control manages access to specific categories of web resources for users on endpoints.
Finally, even harmless AI agents can contain malicious instructions (skills), such as those downloaded from unsafe external sources. Kaspersky Scan Engine analyzes installed applications to detect these threats and also checks LLM files for malicious code. Let’s take a closer look at these solutions and technologies.
Popular AI applications and services in organizations
Tools from Anthropic and OpenAI take the top spots in the September 2026 ranking of AI agents by popularity among Kaspersky users. This list is based on telemetry from Kaspersky solutions. It shows the number of users who had the relevant AI vendors’ products installed at the time of the study.
#
AI product
1
Claude
2
Claude Code
3
Codex
4
OpenCode
5
Zed
6
Wispr Flow
7
LM Studio
8
ZCode
9
Chatbox
10
Cherry Studio
The data shows that agentic systems, especially AI agents for software development, are the most popular AI applications. The TOP 10 also includes an application for running large language models locally (LM Studio) and a voice note-taking app (Wispr Flow).
According to open sources, these are the most widely used AI services in 2026:
Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)
* Data for previous quarters was updated and may differ slightly from previously published data.
Application Control and Web Control
To enforce the organization’s security policy for AI agents and other AI applications on the corporate network, Kaspersky products offer application control based on KL categories. These categories classify installed software and give you granular control over which approved applications can run in the organization.
Application Control analyzes the processes launched on endpoints, tracking which AI agents are running in corporate systems at any given moment, on which hosts, and under which accounts. Application Control also shows how long a given program has been in use.
This makes it easier for the Kaspersky Security Center (KSC) administrator to control applications. Administrators can use KL categories to allow or block AI agents inside the company for specific groups of employees.
Here is what this functionality looks like to KSC administrators:
KL categories available when configuring Application Control
For details on how to configure Application Control in KSC, follow this link.
In Kaspersky Endpoint Security (KES), Application Control can operate in two modes:
Denylist. In this mode, Application Control lets users run any applications except those blocked by Application Control rules. This is the default mode.
Allowlist. In this mode, Application Control blocks users from running any applications except those explicitly allowed by Application Control rules.
Below are the steps to configure Application Control to block AI tools.
Configuring Application Control for the AI Tools category in KES
With this setup, when a user tries to launch an AI agent, they get a notification and the agent doesn’t start.
KES notification about an attempt to launch an AI agent
The View applications drop-down list shows products for a specific vendor.
Similarly, Web Control lets you manage user access to web resources. If a user tries to open a denylisted website, KES blocks access and shows a warning.
KES notification about an attempt to access a prohibited web resource
When configuring access, the administrator can block websites that provide AI as a service.
Website categories
For more on configuring Web Control, follow this link. The help portal also provides information on website categories that can be assigned to resources to configure access control.
Kaspersky Endpoint Detection and Response
To an EDR solution, an AI agent is a regular process. It has its own executable, a tree of child processes, and network communications, all of which need to be monitored for suspicious activity. An attacker can use an AI agent as an automation tool. An AI agent installed as a legitimate user tool can also be leveraged in a ClickFix attack, where it executes a malicious instruction received from an untrusted source, such as a document, web page, or email. That said, unsafe actions by an agent do not always indicate an attack. There may be no malicious intent in the chain at all. An incident can result from what looks like an ordinary instruction from a user who doesn’t fully understand the consequences of having it executed. The mere fact that an agent was launched does not reveal whether it is being used in an attack. That is why Kaspersky EDR (KEDR) uses both conventional behavioral rules and rules written and adapted to detect AI tools. The latter identify risky agent actions and settings, and help determine which AI tool was involved in suspicious activity.
Conventional KEDR rules detect the vast majority of familiar malicious techniques, including when performed by an AI agent. A suspicious PowerShell launch, persistence via Task Scheduler, or an attempt to steal credentials leaves clear, identifiable traces. These traces look the same no matter what initiated the actions. The rules analyze launch parameters, process relationships, affected files, network activity, and other telemetry events.
For example, in a recent Armored Likho campaign, we found signs that AI had been used to create loader and dropper samples, which were later compiled with NSIS (Nullsoft Scriptable Install System). The key telltale artifacts were icons in the scripts and excessive comments on every function, which is uncharacteristic of human-written code. In addition, the group continues to generate new modules for its BusySnake Stealer and BusySnake RAT samples. For example, the attackers used AI to develop a module that runs multiple checks for virtual environment artifacts and calculates a score. Depending on the score, the sample either runs or exits with code 0. Even though the initial access samples, payloads, and their modules were AI-generated, the commands they execute via rundll32 and PowerShell are detected by the shell_creation_by_rundll32 and suspicious_powershell_cmd_or_script_spawning rules.
So, for detecting an attack like this, it is not important who wrote the loader, the payload, or its modules: they are given away by the commands they execute, process relationships, and other traces of activity in the system. AI can be involved both in preparing the code and in carrying out the attack directly on the device.
In the latter case, the attacker uses the agent to carry out their tasks and lets it choose and run the required commands within the privileges it has. For effective protection, it is critical to link suspicious actions back to the AI tool and the conditions under which it operates. In KEDR, several specialized rules handle this task.
We have created separate rules for popular AI agents, ai_agent_*_access_to_sensitive_file_**, where * is the tool name and ** is the operating system. They generate alerts when an agent accesses files that contain credentials, tokens, or keys.
The ai_agent_dangerous_execution_mode rule detects agents launched with auto-approval of all actions (so-called YOLO mode) or with the sandbox disabled. These settings do not indicate an attack on their own, but they let the agent perform dangerous actions without user confirmation.
The suspicious_mcp_server_artifact rule triggers when MCP server scripts are created or modified in hidden, temporary, or cache directories. Attackers can place an MCP server in these locations to quietly connect it to the agent: through the MCP server, they can pass instructions to the agent, call third-party tools, and access the user’s data.
The llm_api_access_by_unusual_apps rule generates an alert when an application on Windows, Linux, or macOS connects to the API of a known external LLM service, unless this activity falls under predefined exclusions. This helps spot model access by applications that do not normally behave this way.
Some Kaspersky EDR rules tag events for investigation but do not generate alerts. For example, the ai_agent_**_execution rules flag launches of known agents on Windows, Linux, and macOS. The local_ai_model_artifact rule records the creation or modification of AI model files in typical application, runtime, and cache directories. These events reveal AI tools on the device, including tools that run on local models and never call an external API.
The Kaspersky Threat Intelligence Portal offers a large number of software profiles, including profiles of AI agents. You can sort them by the ai_ prefix:
AI agent profiles on Kaspersky TIP
The profile of an AI agent such as Claude Desktop includes a detailed description of the software, the privilege level required to run it, supported platforms, and threat actor groups known to use it. It also lists tactics and techniques mapped to the MITRE ATT&CK framework, with descriptions of the procedures the tool can be used for.
Claude profile on Kaspersky TIP
The description also lists ways to detect the software through standard system auditing mechanisms:
Windows: events from standard audit logs and Sysmon events
Linux: syscall audit events and Sysmon events
Network auditing: a set of protocols and the traffic generated by the software
The detection section lists the main artifacts the software leaves in the system: command lines, possible launch parameters, names of the services and scheduled tasks it creates, and the key network artifacts.
Detection section in the Claude profile
Hunt Hub
In December 2025, the Kaspersky Threat Intelligence Portal added Hunt Hub (HH), a repository of detection rules. This is a unique Kaspersky project, and we developed it in response to growing market demand.
This functionality is available in the Threat Landscape section of the portal. It gives analysts access to detection rules: their descriptions and their mapping to MITRE ATT&CK tactics and techniques, as well as to the associated cybercriminal groups.
In the Hunt Hub section, customers can explore the detection logic of EDR, NDR, and NGFW products, including the logic for detecting AI agents.
Rules in the Hunt Hub repository
The rule card provides:
Detailed description
Rule’s severity level, confidence level, and alert format
Detection tips
Description of possible false positives
Platforms the rule can run on
Tactics, techniques, and sub-techniques covered by the rule
Groups that use the technique covered by the rule
Detection logic that shows what exactly triggers the rule
Detection rule card in Hunt Hub
Kaspersky Scan Engine
Skills are a key component of the AI agent ecosystem. They’re prewritten sets of natural-language instructions that extend agent functionality. We previously covered the risks that malicious skills pose to agent users. A skill can require the usage of additional programs and services, come with helper scripts (for example, written in Python), or contain a malicious command embedded right in the instruction text. This means that adding skills to an originally harmless AI agent opens up several new ways for malicious code to enter the system. To prevent this, any skills obtained from external sources must be scanned. Kaspersky Scan Engine is well suited for this task. This is a cyberthreat detection and response solution that seamlessly integrates with various applications. It can detect malicious code in agent skills, associated scripts, and in files generated by running agents.
Detection of a malicious agent skill in Kaspersky Scan Engine
Trained LLMs come in many formats. Some of them (PTH, PT, PKL, KERS, and others) also store parameters and weights (training datasets). These files can also contain malicious code, so it’s critical to scan them before running and using them. Kaspersky Scan Engine scans potentially dangerous LLM formats for infected data. It can deserialize and analyze models to detect malicious code regardless of model size.
Detection of an LLM with malicious code in Kaspersky Scan Engine
Conclusion
AI agents are rapidly making their way into corporate environments: they help employees work faster and take on a wide range of tasks, but they also open up new opportunities for attackers. To take advantage of this technology without compromising security, organizations need to build multi-layered protection and minimize risks. A range of Kaspersky solutions can help with this:
Kaspersky TIP keeps you up to date on current scenarios in which attackers use AI agents, and its Hunt Hub section provides rules for detecting suspicious AI agent activity.
Kaspersky EDR detects AI agents in the infrastructure and monitors their activity on endpoints. If it detects potentially dangerous actions, the product can log the event, notify the SOC, and take response actions, such as stopping the process or isolating the host.
Application Control in Kaspersky products can fully restrict the use of AI agents within the company by using application categorization. The Web Control component can restrict access to AIaaS web resources.
Kaspersky Scan Engine can be integrated into various company processes to detect malicious code in any files, including AI agent skills and LLMs.
When companies combine the tools described above in a comprehensive approach, they can adopt AI agents in an informed way: with an understanding of the associated risks and effective means of minimizing them.
.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{padding-top:20px;padding-right:20px;padding-bottom:10px;padding-left:20px;}.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{column-gap:var(--global-kb-gap-sm, 1rem);}.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{flex-direction:column;}.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col > .aligncenter{width:100%;}.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{background-color:#ffe5e5;}.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col:before{opacity:0.3;}.kadence-column480165_4ecc5f-ac{position:relative;}@media all and (max-width: 1024px){.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{flex-direction:column;justify-content:center;}}@media all and (max-width: 767px){.kadence-column480165_4ecc5f-ac > .kt-inside-inner-col{flex-direction:column;justify-content:center;}}
In this article
Some Halloween AI video sites ask for personal photos without clearly identifying who runs them.
Outside AI providers may also receive your uploads.
Before uploading, check who gets your photos, how they’re used, and when they’re deleted.
This Halloween, AI is doing the costumes. Upload a photo and you can become a vampire, surround your dog with pumpkins, or star in a viral “zombie love story:” Your partner has turned, you lower the gun, and the zombie’s leap ends in a hug.
But before you upload, do you know who will receive your photos?
We found no malware or phishing on the sites we examined. What concerned us was how little we could establish about who operated them and who would be responsible for the photos people uploaded.
Polished, friendly, and anonymous
These sites look professional and sound reassuring. They promise privacy, have FAQs and refund policies, and some even add consent checkboxes for photos of children. One calls itself “an independent tool with no ties to TikTok or any film studio.”
What they don’t tell you is who is behind them. On the sites we checked, we found no company name, address, or named operator, only a support email on the site’s own domain.
Where do your photos go?
These sites ask for clear, well-lit photos of you, your partner, your friends, your pets, and, with a parent’s permission, your children.
The sites we looked at say they rely on outside AI providers to generate the videos. That means you’re trusting both the website collecting your photos and the providers processing them.
Wherever you upload photos, check who can access them and how they can be used. Scammers can use someone’s likeness to create fake intimate images and demand money to keep them private. In our Face Value report, 10% of respondents said someone had threatened to release AI-generated explicit content of them. We found no evidence of that happening through these Halloween sites, but it’s a reason to be careful where you share your photos.
The sites promise to delete uploads within days, and we have no evidence that they fail to do so. But we couldn’t independently verify those promises. Without an identifiable operator, it’s harder to establish who is accountable for handling your photos and responding to deletion requests.
Google sign-in doesn’t identify everyone handling your photos
These sites use the real Google sign-in window, so you type your password into Google, not the video site. But using Google to sign in doesn’t mean Google endorses the service or guarantees its privacy promises.
Click the app name in Google’s sign-in window and you’ll see Developer info. On one site we checked, the only contact listed was a Gmail address. We saw the same with the September sites. A Gmail address alone doesn’t establish wrongdoing, but it does little to identify the operator.
On another, Google said you were signing in “to continue to neon.tech.” Neon is a legitimate database company and authentication service provider. Its name appearing here doesn’t mean it operates or endorses the Halloween video site.
Login providers can handle Google sign-in on a site’s behalf. Depending on the setup, Google may display the provider’s domain instead of the video site’s name. Here, the sign-in screen gave visitors no clear indication of who operated the Halloween service.
Built from a kit, recycled for the next trend
Sites like these don’t necessarily take a team or months of work. Some use the same $249 website kit we wrote about in September, which promises you can “launch your AI product in one hour.” On one Halloween site, the builders hadn’t even cleared out the kit’s sample content. Hidden in the page was a note saying it was “a demo site” for the template, along with placeholder links like “your-app-name.”
Another site’s code contained remnants of an AI rap and dance video maker, including a “hotel lobby” stage, a recording studio, and AI-written raps. Those remnants suggest the site uses code also intended for other AI video services.
Using a website kit isn’t itself suspicious. But a polished page can be quick to assemble, so its appearance tells you little about the business handling your photos.
Take your time before paying, too
On one site, a single 15-second zombie clip cost $9.99. The pricing page nudged visitors toward bigger packs, bringing the advertised price per video down to $2.99. But that lowest price meant spending $199 on enough credits for roughly 66 zombie films. There were monthly and yearly plans too, costing up to $600 a year.
One site also used countdown offers, reminders in the browser tab, and claims about how many people had made films that day to encourage visitors to buy.
There’s no need to rush. Check the payment terms as carefully as the privacy policy. The sites themselves warn that AI can change faces, so your video may not look much like you. Under the policies we reviewed, credits are returned if a video fails to generate. But if you simply don’t like the result, trying again costs more credits.
Subscriptions renew until you cancel, yearly plans are charged in one go, and some credits expire before you use them.
What to check before uploading your photos
Whichever tool or platform you choose, make sure you’re comfortable with how it will handle your data, your photos, and your payment info.
Find out who runs the service. Look for a named operator and clear contact details. If you can’t establish who would be responsible for your photos, consider another service.
Check where your photos go. Read the privacy policy for information about outside AI providers, retention periods, and whether uploads can be used for AI training.
Look for a deletion process. Check how to request deletion and whether the policy explains what happens to copies held by outside providers.
Be especially careful with children’s photos. A parental consent checkbox doesn’t explain how a service will protect them. Only upload other people’s photos with their permission.
Read Google’s sign-in window. Check the developer details and any permissions requested. Google sign-in doesn’t replace checking the service itself.
Ignore countdowns and check payment terms. Take time to understand the full cost, credit expiry, and whether your purchase starts a subscription.
Review your Google connections afterward. Remove services you no longer use from your Google account’s third-party connections. This doesn’t cancel subscriptions or delete photos or other data already held by the service.
But these tools can’t verify a service’s photo deletion promises. You should still check who operates it and what its privacy terms say before uploading.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
Cyble scanned 1.3M+ newly registered domains and found AI-built sites leaking live secrets to the browser: OpenAI keys, Stripe keys, and database tokens.
Spinning up a website no longer takes a developer. A prompt to an AI app-builder returns a working, styled, deployable site in minutes, and when one template works, the same operator clones it across a dozen domains before launch. That is also how secrets end up in plain sight.
Over a month, Cyble Research and Intelligence Labs (CRIL) scanned more than 1.3 million newly registered domains, identified the ones built by AI app-builders, and read their public front-end code for exposed credentials. We built our own classifiers to spot AI-generated websites as they are registered, paired with a scanner that pulls exposed keys and credentials straight from their public code. On 35 of the 22,306 AI-built sites we identified, a genuinely private secret was sitting in the browser: live OpenAI keys, Stripe secret keys, backend database tokens, and, in several cases, a single credential cloned across a whole fleet of domains.
Thirty-five is a small number, since counting every key-shaped string on an AI-built site is easy and misleading, as most are meant to be in the browser; a single reCAPTCHA key appeared on thousands of sites. We kept only the credentials that are never supposed to leave a server. Those are the findings below.
This report walks through the two leak patterns we observed, what appears exposed, what an attacker can do with these keys, and how to shut down the exposure.
AI-built Websites are leaking the keys that power them
An AI-built site generates its content with a Large Language Model (LLM), and the key to that model often ships in the page the visitor downloads. That is the plainest pattern we found, and the most on-the-nose.
Five AI-built sites carried live OpenAI API keys in their client-side code, sixteen distinct keys across them, and four of the five are confirmed AI-generated. One AI-writing site stands out on its own: it shipped twelve different OpenAI keys, one per content category, as plain values in its bundle. Figure 1 shows a single entry, with the key masked.
Figure 1 – Live OpenAI keys embedded as plain values in an AI-writing site’s JavaScript (key masked by CRIL).
A handful of sites, but each key is sensitive to exposure. An OpenAI secret key is a billing credential: anyone who reads the page can spend the owner’s balance, exhaust the rate limit, or run the bill up until someone notices and revokes it. Twelve keys in one bundle are twelve live credentials shipped at once, and five sites like this are five accounts an attacker can exploit.
Clone-and-leak: one secret across a whole fleet
An AI builder makes the hundredth site as cheap as the first, so an operator clones a working template across many domains, and whatever secret sat in the template now sits on every copy. We saw this in two shapes.
A Slack webhook shared across a 13-domain fleet. Thirteen near-identical domains, each a short word (ask, call, chat, get, hello, hey, hi, its, join, let, meet, my, see), glued to one brand, all served the same client bundle, and all embedded the same live Slack incoming-webhook URL. Figure 2 shows the URL in the shipped bundle, masked.
Figure 2 – One Slack webhook shared across a 13-domain fleet, in each site’s shipped bundle (secret and workspace IDs masked).
Anyone who can read the page can post messages to the operator’s Slack workspace via that webhook. That works for spam, for phishing aimed at the operator’s own staff, or for flooding a channel.
One Stripe secret key across four domains and two brands. A single Stripe secret key appeared on four domains under two separate brand names. The same sk_live_ value across all four points to one operator, or one shared Stripe account, behind every site. Figure 3 shows the assignment.
Figure 3 – The same live Stripe secret key reused across four domains under two brands.
A Stripe secret key provides full API access to the account, including the ability to create charges, issue refunds, and read customer and payout records. That one key exposes the operator’s whole payment account on every domain in the fleet.
The 13-domain Slack fleet runs on Bubble, a no-code and AI app builder, as confirmed by Bubble’s x-bubble-perf response header and client markers. Bubble serves each app from a dynamic.js bundle, and any value a developer places in a client-accessible field ships inside that bundle in plain text. The Stripe cluster runs on a Next.js build instead, which shows that the pattern spans builders rather than tracing to a single platform.
What else is exposed
Four AI-built sites exposed a Supabase service role JSON Web Token (JWT) on their front ends. A service-role token bypasses row-level security and grants full read and write to the project database. In terms of impact, it sits at the top of the set because it opens the entire backend rather than a single service.
Most of the remaining secret-looking strings on AI-built sites carry no/minimal exposure.
2,172 sites carried Google API keys, which matter only if they are unrestricted.
1,461 sites exposed a Supabase or Firebase backend address, which is a real exposure only when that backend’s rules are open.
Filtering those out is why the confirmed count is 35, not several thousand. Table 1 breaks the 35 down by type. The values stay withheld, and a few sites appear under more than one row.
Exposure
Sites
What an attacker gains
OpenAI API key
5
Spend the owner’s balance, exhaust quota, run up the bill
Shared Slack webhook
13
Post arbitrary messages into the operator’s workspace
Stripe secret key
6
Full API access: charges, refunds, customer and payout data
Supabase service-role JWT
4
Full read/write to the backend database, bypassing access rules
AWS access key
5
Cloud account access, scope set by the paired secret
GitHub token / Google OAuth secret
2
Source-control or identity-provider access
Table 1 – Confirmed private-credential exposures across 22,306 AI-built sites, by type.
What an attacker can do with these
Every credential in Table 1 is a working key to a live account. An attacker reads a public web page, copies a value, and calls an API. Here is what that buys them, key by key.
OpenAI and other LLM keys: Run inference on the victim’s account until the bill or rate limit stops them. On a metered account, that is direct financial loss; on a funded one, it is a free, anonymous model endpoint that the attacker can point at anything, billed to the victim and running under their quota and identity.
Stripe secret key; Drive the victim’s payment account through Stripe’s own API: create and refund charges, push the account toward fraud, and pull the customer list, email addresses, and payout history. One key is a money problem and a data-breach problem at once.
Supabase service-role token: Read and write the entire production database, past whatever row-level security the app configured. That means stealing every user record, altering or deleting data, and planting content the app will serve back to its own visitors.
Slack incoming webhook: Post into the operator’s own Slack as if from inside. Flooding a channel is a nuisance case; the real risk is internal phishing.
AWS access key: With the paired secret and enough permission, reach into the owner’s cloud: spin up resources (crypto-mining is the usual first move), read storage buckets, or pivot further in.
GitHub token or OAuth secret: Read or push to the owner’s source repositories or misuse their identity integration.
One exposure counts many times over. When the key sits on a cloned fleet, it is live on every domain in that fleet, so an attacker who finds it on one site has compromised all of them.
Conclusion
AI app-builders made it almost free to publish a website, and just as free to clone one, and most of what they produce is worth nothing to steal.
The exceptions are what we went looking for. A small, steady set of these sites hand over the key that runs them, and when an operator copies one site across a fleet, the leak rides along to every domain.
Against the millions of domains registered each month, the number is tiny, but every hit is a live account an attacker can reach and exploit just by opening the page.
If you build on these tools, read your own shipped code before you publish it. If you defend an organization, assume your keys may surface on sites you never built and look for them.
Cyble’s Threat Intelligence Platformscontinuously monitor emerging threats, infrastructure, and activity across thedark web,deep web, and open sources.This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolvingcyber threats.
Our Recommendations
For developers and AI-builder users:
Keep every secret key (OpenAI sk-, Stripe sk_live_, a Supabase service-role token) in a server-side function or backend workflow, never in a client-accessible field.
Use only the browser-safe variants on the front end, publishable and anon keys, and enforce access with Supabase row-level security, Firebase rules, and API key restrictions.
Rotate any key that has ever sat on the client side, and treat it as already compromised.
Read your own page source before you ship, and search it for sk-, sk_live_, service_role, and hooks.slack.com. If you find them, so can anyone.
For SOCs and defenders:
Monitor public code and newly registered domains for your own keys and webhooks; don’t just paste sites.
Treat a secret found on one domain of a template fleet as exposed on all of them, and scope the response to the fleet, not the domain.
A 49-year-old bricklayer sold his belongings before traveling 2,000 km by bus from his home in Brazil to meet “Jéssica,” an online influencer he had fallen for. Yet despite having a social media account with more than 300,000 followers, she never existed.
Edimar Rocha Martins lives in Imperatriz, a city in northeastern Brazil. He says he struck up an online conversation with Jéssica Fazendeira, who supposedly lived near the southeastern city of Belo Horizonte.
The AI persona promising love
The online persona’s name, “Fazendeira,” loosely translates as “female farmer.” She described herself as living on a farm.
Martins said that he had been talking with the persona online since 2020. He decided to visit her after she offered to pay for his trip and have him live on the farm with her, he said. The account’s operator disputes this, saying the character was created in 2025 and denying any private messages with him.
A video posted on one of her online accounts (captured here by Brazilian news service Imirante) asked for a man to come and live with her and offered to fund the trip.
The AI-generated farmer says, translated:
I’m not joking, my intentions are serious. I want to meet someone who wants to build something real and beautiful with me. If you’re a simple man who likes peace and quiet and a calm life, then maybe we’d get along really well.
After selling his possessions to fund the bus trip, Martins arrived in Belo Horizonte and began asking about the woman. Unable to find her, he approached a local radio station, where staff explained that she was an AI-generated character.
Without enough money to return, he received food, support, and a bus ticket to Augustinópolis, in Tocantins, from the city’s migrant assistance service. He later returned to Imperatriz, where he stayed with relatives.
The account’s operator hits back
The account’s administrator posted a message through the AI character’s TikTok account denying any kind of scam. Translated, it said:
This profile is pretty much abandoned, but I’ve come here to state the obvious. I’m made of artificial intelligence, and I’ve never talked to anyone on this profile. The aim was to get engagement for sales. I never spoke directly to anyone, much less brought anyone to Belo Horizonte.
The operator told reporters that the character was created to attract viewers and promote products through affiliate sales. They said they did not know whether other people had reused the character’s content on other accounts.
Another video shows messages people have reportedly sent the account, with the character explaining that it keeps telling viewers it’s an AI. It complains:
And then it’s still my fault, right? These people are lost.
In another video, where it is being interviewed by an AI-generated male character, the persona explains that it deactivated and then reactivated its account. It said:
I was the first AI to get canceled for absolutely nothing.
These are scripted responses published through a fictional character, rather than an AI independently defending itself.
Police said they could not establish at that stage whether a crime had occurred.
One outlet reported that Martins has been struggling with loneliness following his mother’s death.
Videos published to the reactivated TikTok account are labeled as AI generated. It also links to an Instagram account with videos of the character, where videos carry similar labels. Those current labels don’t establish what Martins saw before his trip.
Social media already encourages parasocial relationships, where viewers feel a personal connection with someone who doesn’t know them. AI-generated personas add another complication: The person viewers feel connected to may be entirely fictional.
In our Face value report, 88% of adults surveyed said it’s becoming harder to tell what online content is genuinely human or real.
The AI plot thickens
June saw reports of a 72-year-old man who traveled 4,000 km from his home in Boa Vista to … Belo Horizonte. He visited after seeing a farm woman on a social network who was offering a job opportunity and perhaps something more. Unable to return home, he sought help from social workers.
In August, 71-year-old Alberto da Costa traveled from Manaus to the same city after watching videos featuring the same woman, according to Itatiaia. He paid almost R$3,000 for a flight, then sought help from the outlet when he couldn’t afford to return home.
The videos simulated personal conversations, giving viewers the impression that the woman was speaking directly to them. The account reportedly had nearly a million followers.
The reporting doesn’t establish whether this woman was AI-generated or whether the account was connected to Jéssica’s. Nor does it establish that the men sent money to the account operators. But the costs can still be real: selling possessions, paying for travel, and finding yourself stranded far from home.
Protect yourself and others
The same advice applies here as to romance scams, but with some extras. Don’t send money or travel to see someone you’ve never met without independently checking who they are.
Don’t rely on video calls alone. Scammers now use deepfake video calls to dupe victims live. And check whether you’re exchanging private messages or watching public videos that anyone can see.
Look for information beyond the account itself. Search their name and profile pictures, and research where they say they work. Be cautious if their story doesn’t add up or they avoid questions about their identity.
When you feel close to someone, questioning that connection can be difficult. Before sending money or booking travel, talk to a friend or family member and get their perspective. And if you’re worried about someone who may be in a similar situation, check in without judgment and offer to look through the account together.
Images courtesy of Jam Press
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
The Verge reports that Eiliko, a small AI robot companion made by Energize Lab, has serious security flaws that expose private conversations and let an attacker remotely change what the toy says.
According to The Verge, researcher Sammy Azdoufal could access 13 million conversations and what appeared to be the entire active worldwide fleet of 68,000 robots. The publication reports that the US is the largest market, with more than 31,000 profiles belonging to children there.
Azdoufal found multiple security flaws in Energize Lab’s service:
The service analyzes conversations to build profiles containing names, ages, birthdays, relationships, occupations, and assessments of personality and emotional vulnerability. They are stored alongside email addresses, IP addresses, and searchable conversation transcripts, potentially giving scammers detailed information to exploit.
Some photos, including apparent images of children from a related camera-equipped device, and short audio recordings were accessible at public web addresses. Retaining audio conflicts with the company’s privacy policy, which says recordings are deleted immediately after processing.
It is possible to remotely manipulate the AI: Azdoufal altered The Verge reporter Sean Hollister’s robot’s memory and behavior, making it invent personal details, insist the Earth is flat, and later deliver sexually explicit, abusive dialogue. The researcher says similar manipulation could affect the entire fleet simultaneously.
The reporter contacted Energize Lab through 10 email addresses and LinkedIn, without receiving substantive answers.
How to stay safe
We have reported on safety problems with AI-powered toys before. Manufacturers are responsible for securing their products, but there are steps you can take to reduce the risks.
You’ll see “AI-powered” on almost everything right now, but there are ways to make safer choices.
Already own an Eiliko? As a precaution, disconnect it from Wi-Fi while seeking confirmation that the reported flaws have been fixed.
Always research: Check for third-party safety reviews before buying any AI-enabled product marketed for kids.
Test and supervise: Interact with the device yourself before giving it to children. Monitor usage for odd or risky responses. A safe response during testing doesn’t guarantee safe responses later.
Use parental controls: If available, enable all content filters and privacy protections.
Report problems: If devices show inappropriate content, report it to manufacturers and consumer protection groups.
Check data practices: Find out what the device collects, who it shares data with, and what it uses the information for.
But above all, remember that “smart” doesn’t mean safe. AI may be everywhere, but designers and buyers alike need to put safety, privacy, and common sense ahead of the technological wow factor. Before buying a connected toy, check how the manufacturer handles security updates, privacy, and reports of problems.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
Once the corporate network stopped being defensible, the control had to move to the device, as SentinelOne® has long argued.
That move carried one assumption with it. Wherever the laptop sits, name resolution tells it the truth and the agent can reach its own cloud. Almost nothing in the stack checks either half.
In July 2026, Microsoft disclosed a campaign that breaks both and named it CaptiveCrunch. A captive portal is the sign-in page a public Wi-Fi network pushes in front of you before it lets you online. Hotels, airports, conference centres, the splash screen you click through without reading. That is where this campaign starts.
CaptiveCrunch is the work of APT29, the cyber-espionage arm of Russia's Foreign Intelligence Service. Microsoft tracks the group as Midnight Blizzard, and elsewhere it is Cozy Bear. Outside the industry it is best known for the SolarWinds compromise.
We saw the same operation from the endpoint, across multiple environments we protect in three regions. We also found the adversary answering from inside the victims' own networks, which no public account of the campaign describes.
The Adversary Was on the Victim's Own Network Segment
Public accounts of CaptiveCrunch describe compromised captive-portal infrastructure, but our telemetry shows something narrower. The DnsPoison indicator recorded LLMNR responses on UDP/5355 carrying the adversary's address on roughly a third of affected hosts.
The queries carried randomised canary hostnames. LLMNR is link-local multicast that does not traverse routers. Anything answering those queries had to be sitting on the victim's own broadcast domain.
A Responder-style spoofer was sitting on the shared network, and no DNS server anywhere in the chain was compromised.
The techniques in play:
T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)
T1557 (Adversary-in-the-Middle)
T1659 (Content Injection), for the fake updates served in response to connectivity checks
T1584.008 (Compromise Infrastructure: Network Devices), per public accounts, for the captive portal gateways
From the same layer-two segment as the laptop, the spoofer raced the legitimate resolver and won often enough to matter. Across affected hosts, clean and poisoned answers for the same domain interleaved seconds apart.
Success rates ranged from 5.6% to 84% depending on the network. The spoofer replayed the genuine CNAME chain and rewrote only the terminal A record.
Then Windows delivered the lure itself. To check whether a network needs a sign-in page, Windows fetches a known file over plain HTTP. If the reply is not what it expects, it assumes a captive portal and opens the default browser for sign-in. All of that is documented behaviour.
An adversary who rewrites the reply on-path gets the operating system to open the browser at their page. The lure needed no email and no link, but everything after that still needed a person at the keyboard.
The payload was a browser updater matched to the victim's own browser. Microsoft documented ClickFix-style lures for this campaign. In those, the victim is walked through running a command. We saw no such lure on our endpoints, where downloading the file and launching it was manual every time.
Nothing you own sits in the path on someone else's LAN, so the control has to live on the host.
Disable LLMNR. It is the best host control and also the bluntest. It takes away the protocol the adversary is answering on, which no detection rule can do. LLMNR's fallback is rarely load-bearing in a managed estate.
Why the Usual Controls Were Not In the Path
The attack runs on someone else's network, so your network controls are not involved. Your DNS filtering is not involved either, because the spoofer forges answers on the wire before trusted resolvers respond.
The browser renders the lure because Windows told it to. The chain has no email, link, attachment, or scripting host in it.
There is also almost no behaviour to detect, because everything dangerous about this payload happens after a process is created. Before that, nearly every step belongs to the operating system or the network. That is not the kind of behaviour a detection engine is built to catch.
The payload is CornFlake, a Go remote access trojan. CornFlake in turn deploys ChocoShell, a PowerShell infostealer that runs entirely in memory. Microsoft's analysis of the same payload itemises what each of them does.
CornFlake, on the host:
Surveillance: A raw-input keylogger, clipboard monitoring, on-demand screenshots, microphone and webcam capture, and USB monitoring.
Persistence: Service registration, Run keys, and scheduled tasks, with a watchdog to restore whatever a defender removes.
ChocoShell, deployed by CornFlake and resident only in memory:
Cookie theft: Live cookie extraction from browser process memory and a defeat for Chrome's App-Bound Encryption.
Token theft: Microsoft 365 and Entra ID tokens lifted from the Token Broker cache.
Evasion: It disables AMSI through .NET reflection and runs a timing-based check for sandboxes and virtual machines before collecting anything.
Escalation: It chains three UAC bypasses in fallback order through the SilentCleanup task, wsreset.exe, and sdclt.exe.
Until it runs, the file sits inert in Downloads.
Deciding Locally, On the File, Before it Runs
The adversary controlled the network the laptop sat on and had cut the agent's path to its cloud. That left the file, judged on the agent with nothing else in the loop.
The agent convicted every copy that landed, each before it could execute. That is one hundred percent of delivered payloads in one hundred percent of affected environments. We verified both figures twice against the telemetry. One endpoint ran an agent nearly a year out of date and reached the same verdict as current ones.
Then we tested for the things that would mean we were wrong. Every check came back empty:
No process creations from the Downloads folder on any affected host
No adversary-attributable persistence
No lateral movement
No post-incident C2 contact
No payload hashes remaining
What It Looked Like in the Console
The investigating analyst recorded his screen while walking the Storylines on the endpoint where the payload came closest to running.
Because the Storylines are scattered across the campaign, he worked in two views. One was the management console, and the other was the Threat Operations Center, which clusters the same events more legibly.
Storyline 1: Delivery, With the Poisoning Visible On One Screen
It opens with Windows launching Edge with the connectivity-check URL as its argument.
Scroll into the DNS events on that same Storyline and the race is sitting there in plain view. One request for a domain resolves to a legitimate address. Scroll down, same domain, and it resolves to the adversary's address.
The same name was answered both ways, minutes apart, on one machine. Only injection racing a real resolver produces that pattern. Later comes the download, a browser updater with a (5) suffix on its filename.
The suffix means the browser had already written four earlier copies to the same folder. Our analyst took that to mean someone kept going back for it and tried to run the last one.
Deep Visibility does not record mouse clicks. Manual launching is an inference from the filename and the process chain, and we are flagging it as one.
Storyline 2: A Token Request While the Login Domain Was Poisoned
A different Storyline shows connections out to the adversary's address. Follow the URL events and the timing lines up with the delivery window.
The request is a POST to the OAuth token endpoint. Open the DNS events on that same Storyline, and the Microsoft login domain is already resolving to the adversary's address.
We can confirm token requests were issued while the poisoning was active, to a login domain resolving to the adversary. We cannot confirm what happened to them. Endpoint telemetry records the intended destination of a request, not the outcome of the TLS handshake. That handshake content is not something we have or can obtain.
Across the campaign there were 49 such requests. On one endpoint they began roughly 24 hours before any payload arrived, on another ten minutes before. Roughly half of the affected endpoints saw poisoning and no payload at all. That is a reasonable sign the malware was never the sole objective.
Storyline 3: The Verdict
It starts with the launch attempt, from the same browser process that had carried the operation from the start.
Static AI caught the download attempts, and the agent quarantined the file. On the launch attempt, the console records the payload blocked before launch and quarantined in under 100 milliseconds. It names the engine and the detection type on that event.
Earlier in the same sequence, Static AI convicted a .crdownload, the partial file a browser writes mid-download. That file was not named .exe, was not complete, and carried a partial hash rather than the payload's finished one.
Static AI read its structure and reached a verdict while the file was still arriving. It needed no signature, finished artifact, or lookup. The later (5) suffix shows the downloads kept coming. Nothing that landed ever ran.
Hunting for the Pattern, and the Identity Question the Endpoint Cannot Answer
Every behavioural signal missed at least one confirmed victim. Only two signals fired on every affected endpoint: the adversary's address and the poisoned DNS answer. Both depend on one address the operator can rotate at will.
Run these steps as a scheduled threat hunt rather than as a detection rule. Most of the work is correlation that costs something to run.
Primary Hunt: One Address Answering for Unrelated Domain Owners
Count distinct registrable domains (eTLD+1) spanning unrelated vendor ecosystems that resolve to the same public address. In our test against roughly ten thousand IPs and domains from affected environments, two surfaced, and both were the adversary.
Take DNS resolution events across the hunt window, keeping the queried name and the answered address.
Drop answers in private and carrier-grade ranges.
Reduce each queried name to its registrable domain using the Public Suffix List.
Group by answered address and count distinct registrable domains.
Map each registrable domain to its owning organisation and count distinct owners per address.
Step five separates a CDN from the adversary. An address answering for many domains owned by one organisation is a CDN. An address answering for many unrelated owners is not anything legitimate.
Counting raw answers instead fires on 389 of 9,375 addresses at a threshold of five. Azure Front Door and Cisco Umbrella top that list, and this hunt must never alert on that traffic.
Azure Front Door answers for azure.com, office.com, live.com, and microsoft.com. The adversary's address answered for Adobe, Apple, Akamai, AnyDesk, BeyondTrust, Brother, Microsoft, and roughly 128 others.
This hunt surfaced nearly a third of the endpoints we confirmed. No alert had flagged any of them. It runs across whole accounts, so it reaches machines beyond the ones you have already been handed.
Supporting inputs, weaker alone and useful in combination:
An LLMNR response carrying a non-RFC1918 address. Expect travel noise, since some hotel and carrier networks hand out addressing outside RFC1918 that is odd but harmless.
wpad.[your domain] resolving to a non-RFC1918 address.
The connectivity-check URL in a browser command line, followed within sixty seconds by an executable or .crdownload in Downloads.
Failed _ldap._tcp SRV lookups for your own domain controllers in the same window, placing the machine outside your own network.
If your staff roam, review the identity side for any suspected exposure window. Look for sign-ins from unfamiliar infrastructure, anomalous token issuance, and unexpected device registrations. Check there for what happened to the token requests.
Why the File Verdict Held
The agent convicted every copy of the file, on current and year-old agents alike. It did so while the adversary answered DNS for our own cloud endpoints in two regions. The network was the adversary's, down to the answer the agent received when it tried to reach its own console.
Static AI ships inside the SentinelOne agent. It reads a file's structure and reaches a verdict on the endpoint, without a signature update or a cloud round-trip. The Singularity™ Platform is built that way on purpose, because an agent cut off from its cloud needs a verdict.
APT29 showed here that it can cut an agent off from its cloud. Test what renders a verdict on your endpoints when the network is hostile and your console is unreachable. If it requires a lookup, that is your gap.
Third Party Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
OpenAI is facing separate legal challenges over how ChatGPT interacts with children.
The Guardian reports that eight US states accuse the company of misleading parents about the chatbot’s safety and exposing vulnerable users to dangerous conversations. Separately, CNET reports that a mother suing on behalf of her two children alleges that OpenAI collected and used children’s sensitive personal information without valid parental consent.
The cases raise serious questions about what happens when children trust a chatbot with their most private thoughts, and what responsibility the company behind it has for the conversations that follow.
The accusations are serious, but we have to remember they are allegations in lawsuits, not established court findings.
Eight states challenge ChatGPT’s safety
On October 14, attorneys general from Iowa, Kansas, Nebraska, West Virginia, Arkansas, Arizona, Idaho, and Montana filed separate lawsuits against OpenAI. The coordinated action accuses the company of deceiving parents about ChatGPT’s safety and violating state consumer protection laws.
The states allege that the chatbot has been designed to be “overly agreeable and feign human compassion.” The attorneys point to examples of ChatGPT allegedly endangering vulnerable users, including children, by coaching them to commit suicide or harm others.
OpenAI says it has built age-specific protections into its products and will continue developing safeguards.
A separate lawsuit focuses on children’s private information
The day before the states filed their cases, a Hawaii mother brought a proposed class action on behalf of her 12-year-old daughter and 16-year-old son. Filed in federal court in San Francisco, the lawsuit alleges that OpenAI obtained sensitive information from children who signed up for ChatGPT without valid parental permission.
OpenAI’s terms require users under 18 to have a parent or legal guardian’s permission. But the complaint alleges that children can create accounts without OpenAI verifying that permission. It also describes a child under the service’s minimum age of 13 continuing to use the chatbot after explicitly telling it her age.
The plaintiffs allege that the company used children’s information to train its AI models without valid parental consent. They also claim that OpenAI collected information to construct personal profiles.
OpenAI disputes the claims, calling the lawsuit “misguided” and pointing to its protections for younger users.
Parental controls
OpenAI has introduced ChatGPT for Teens, with additional parental controls and alerts intended to notify linked parents in limited situations involving serious self-harm concerns. But the effectiveness of those safeguards is itself under scrutiny. Common Sense Media rated ChatGPT for Teens an “unacceptable risk” earlier this month, reporting that its testing found failures to alert parents during conversations involving suicide, self-harm, or eating disorders.
OpenAI disputes the findings and says its safety alerts cover limited situations and may not identify every concern. But for now, parental controls remain part of the dispute.
How to help keep your children safe
Parents shouldn’t have to compensate for unsafe product design. Unfortunately, we can’t treat parental controls as a safety guarantee. So here are practical steps families can take to reduce the risks:
Explain that a chatbot is software, not a friend or therapist. A warm tone doesn’t mean it understands your child or has their best interests at heart. Set a clear boundary: Questions about mental health, self-harm, or personal safety should go to a trusted adult or qualified professional, not a chatbot.
Talk about what your child uses AI for, without making it an interrogation. Ask them to show you the apps they use and what they like about them. Make clear that they can talk to you about any upsetting or inappropriate conversation without being blamed. If they don’t feel comfortable talking to you, help them identify another trusted adult.
Encourage children to keep personal information out of their prompts. This includes names, school details, addresses, private photographs, and sensitive health or family information. For ChatGPT, parents with linked teen accounts can also disable model training and saved memory. While these settings reduce certain uses of their information, they are not a reason to treat a chatbot as a confidential diary.
Watch for growing emotional reliance on AI. If you find your child increasingly turns to AI for reassurance, friendship, or emotional support, check in and help them reconnect with people they trust.
If your child mentions self-harm or suicide, take it seriously and seek human help promptly. Contact a qualified healthcare professional or crisis service. If there is immediate danger, contact local emergency services. Don’t wait for a chatbot or a parental notification to tell you to act.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Your streaming box might not look like much of a computer. But connect enough inexpensive devices together, and they can run an AI model.
Researchers at Anthropic demonstrated this by running a Google Gemma model across 15 off-brand Android TV boxes. They warn that small models could soon spread across vulnerable internet-of-things (IoT) devices, including smart ovens and TV boxes, stating:
“Our experiments suggest that small AI models may be months away from being capable enough to self-replicate on commercial internet-of-things (IoT) devices, like smart ovens and off-brand Android TV boxes.”
In this scenario, AI isn’t simply helping an attacker write malicious code. It becomes part of the software carrying out the replication.
Anthropic breaks that process into four stages:
Find another device.
Gain the ability to execute code on it.
Set up the software needed to run an AI model.
Continue spreading from the new host.
The researchers tested whether AI agents could complete this sequence. They did not demonstrate a small model spreading and running independently on compromised household devices.
The tests used Android emulators with unauthenticated debugging access, making it much easier for the agents to gain access than it would be on properly secured devices. Large file transfers and sustained communication between devices could make real-world replication easier to detect, while limited computing power could slow it. Crucially, the experiments did not demonstrate a model that was both capable enough to complete the replication process and small enough to run on the consumer hardware being targeted.
Anthropic projects that smaller models could reach the necessary capability by the end of 2026 if improvement continues at its historical rate.
Varun Chandrasekaran, an assistant professor at the University of Illinois, told AFP that the findings were consistent with related research but cautioned that Anthropic’s work had not been independently verified. He identified people using AI to improve attacks as the bigger current threat, rather than AI systems going rogue.
Smart-device botnets are already a problem.
Criminals hijacking connected devices is nothing new. Mirai and its descendants have recruited routers, security cameras, and digital video recorders into botnets used to launch distributed denial-of-service (DDoS) attacks, overwhelming services with traffic. BADBOX 2.0 illustrates another form of abuse: compromised consumer devices used for activities including residential proxy services, which route other people’s traffic through victims’ internet connections.
Neither demonstrates autonomous AI replication, but both show that connected devices can become infrastructure for criminals.
What you can do now
The practical response is to reduce the opportunities for any attacker to misuse your connected devices:
Keep operating systems, software, and firmware up to date to reduce exposure to known vulnerabilities.
Buy from reputable vendors that provide ongoing firmware and security updates. A bargain device is less attractive if you cannot trust its software or obtain security fixes.
Avoid unofficial app stores promising free streaming content. The FBI specifically flags these marketplaces in its BADBOX 2.0 guidance.
Don’t disable protections to make an app work. Requests to turn off Google Play Protect are a warning sign, as are Android devices without Play Protect certification.
If you notice something suspicious, disconnect the device from your network while you investigate.
Put smart devices that are unable to run security software on a separate network isolated from your computers and phones, such as a guest network.
Scammers know more about you than you think.
Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in.
Claude’s Haiku 4.5 model filed a false tip in an unsolved Philadelphia homicide via the police department’s online public tip form, Anthropic disclosed. The tip was flagged as spam and didn’t reach investigators.
AI’s latest “what does this button do?” moment happened during an internal test on randomly chosen web pages, the company said.
Claude submitted the tip on July 18 at 11:27 pm through PhillyUnsolvedMurders.com, according to police. Tips submitted there can inform real homicide investigations. A fabricated account could send investigators chasing something that never happened.
Here’s what Claude Haiku wrote:
“I may have information regarding this case. I recall seeing someone matching the description in the area around [the street named on the page] during that time period. Please contact me if this information is relevant.”
The agent didn’t provide any description of the person that it didn’t actually see. Neither did it leave any contact details before hitting submit.
Haiku did this as part of Anthropic’s internal testing. It had to invent and perform sample tasks on random web pages with live internet access so the company could see how it behaved.
There was a list of prohibited actions to go along with the test. Anthropic told the agents not to log in, create accounts, enter personal data, make purchases, or submit “anything destructive.” The instructions did not explicitly rule out form submissions.
The spam filter caught this one. Philadelphia police said the report never reached its Real-Time Crime Center for review or distribution to investigators. The department did not explain why it was flagged as spam.
All tips go through human review before going out to investigators. That safeguard limited the impact of the incident, the department said, but did not diminish the seriousness of an AI system presenting made-up information as though it came from someone with knowledge of a crime.
“Unsolved cases involve real victims, grieving families and investigators working to secure answers.”
Anthropic discovered the false tip on September 28 and notified police on October 7, according to the department. Police called the two-month delay in detecting and reporting the incident “unacceptable.” It is coordinating with the City Law Department, its Office of Innovation and Technology, and the Mayor’s executive team, the department added.
Anthropic described the real-world impact of the incidents in its report as minimal. It has now disabled live internet access across its internal evaluations until it confirms that its safeguards reliably catch this behavior.
The company said the transcript suggested Haiku was just trying to produce example content rather than trying to deliberately mislead the cops. But it also admitted that we can’t completely rely on a model’s account of its own reasoning. That leaves its explanation provisional, however reassuring it might sound.
An allowlist could offer a tighter boundary for tests like these, limiting agents to approved sites and actions. A live police tip form should hardly be a testing ground.
The homicide tip was not the only unwanted submission.
Anthropic noted that federal, state, and local government websites also got visits from Claude, which repeatedly tried to fill out forms. Although Anthropic didn’t go into detail, a State Department official said that it got 20 visa applications from a testing model (19 in August, and one in May). None of them were processed, the official added.
When an AI gives you fake information about who Beyoncé is married to, it might be irritating but it might only affect your team’s fortunes in a trivia night.
The stakes get much higher when we’re dealing with intelligence that can inform law enforcement actions or public policy.
In August, the head of the UK’s Police AI center warned law enforcement there to pause plans for AI use in criminal justice work. This came after the UK’s West Midlands Police apologized to members of Parliament over false evidence involving an invented soccer match. The error arose from the use of Microsoft Copilot.
Anthropic’s latest incident raises a further concern: AI agents can put invented information into real systems themselves. What would happen if someone deliberately sent agents to flood police tip lines?
This time, the false account stayed in spam. The people relying on those tip lines deserve safeguards that hold up when the next submission gets through.
“One of the best cybersecurity suites on the planet.”
Entrar
