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.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

Introduction

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.

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)

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.

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.

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:

• To detect the execution of a malicious script via a remote scheduled task, you need to monitor the creation of the schtasks.exe process with the /s argument. EDR Expert detects this activity using the rules create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks, and scheduled_task_with_powershell_execution.
  
• 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.

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.”

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.

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.

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:

• R034_01_Multiple TGS ticket requests (Kerberoasting)
• R452_18_AS-REP Roasting

Dumping registry hives containing credentials using the reg.exe utility:

• R230_02_Copying data containing credentials from the Windows registry

Dumping the lsass.exe process using the MiniDump function of the comsvcs.dll library:

• R233_04_Process memory dump via comsvcs.dll
• R262_Suspicious access to the LSASS process

DCSync and Golden Ticket attacks using the renamed mimikatz utility:

• R073_DC Sync attack
• R450_41_Golden Ticket Attack
• R100_03_Traces of Mimikatz use via cmd

Lateral movement using WMIExec:

• R460_08_Lateral movement using WMIexec Impacket
• R460_09_Lateral movement using WMIExec and Impacket

For the rules to work, you must configure the SIEM system to receive the relevant events:

• Process launches (Windows security log – 4688, auditd – execve) and PowerShell commands (4104)
• User logins to the system (Windows security log – 4624, 4768, 4769)
• Various object manipulations (Windows security log – 4662, 4663, 4656; auditd – openat)
• Interaction with shared resources (Windows security log – 5145)

Indicators of compromise

File-based indicators:

CyberStrikeAI Windows Beacon
D726A8B4886C636F76CA6D30EF6A6FF4	c:\windows\temp\svchosts.exe
2770562d104391b92b42671c270079bb	c:\windows\temp\svcmon32.exe c:\programdata\svcmon32.exe
CyberStrikeAI Linux Beacon
09e1da2afa1216ecc55648ec8e122d2a
805B9E4AE74C903787416800999B8418
Tools & Scripts
29EFD64DD3C7FE1E2B022B7AD73A1BA5	C:\Windows\Temp\wdiag2.exe (mimikatz)
74F57B3E897A4960DCDD5B7E8A54F9DF	c:\rwx\RogueWinRM.exe
0BBD08AF95F877F1D568B03DE2EB76B4	c:\ProgramData\p1.ps1 (reverse shell PS script)

Network indicators:

185.186.245[.]144	C2 for Windows Beacon
fastcdn[.]bar	C2 for Windows Beacon
media.fastcdn[.]bar	C2 for Linux Beacon
104.234.26[.]163	C2 for Payload Delivery + Linux Beacon

Unit 42 details recent threat intelligence, highlighting cyberespionage, financial extortion, and the rapid adoption of AI across offensive workflows.

The post Unit 42 Threat Intelligence Highlights - Nov. 2, 2026 appeared first on Unit 42.

Unit 42 explores key peak shopping season retail cyber threats, from ransomware to AI attacks, and shares how to defend operations and customer trust.

The post Unwrapping Retail Peak Season Cyber Threats appeared first on Unit 42.

AI systems are much harder to protect than traditional IT — whether from operator mistakes, malicious interference, or just plain unstable behavior. There are two main reasons for this. First, AI outputs are probabilistic, so the same prompt can give different answers each time you run it. Second, today’s LLMs can’t reliably tell commands apart from data. Despite the demonstrated security issues of AI systems that we’ve covered many times, it’s impossible to ignore the potential economic payoff of adopting them. That’s why many companies are moving beyond simple AI assistants to AI agents. These agents carry out tasks on their own and have direct access to the same tools as humans — from reading databases to changing settings in production processes. Our experts, in their new study, examine how to clearly define and minimize the resulting risks to keep potential problems to a minimum. The approach borrows and adapts the principles of Cyber Immunity and Security by Design.

The basic principles of Security by Design

All the principles of this discipline are universally applicable to the design of any computer system — AI agents included. What differs is how deeply each principle needs to be adapted and reworked for AI scenarios.

1. Security is a separate and important factor right from the design stage. Security goals and assumptions are set on day one and followed throughout every stage of development. For AI agents, these assumptions should include three key points: (i) the language model is treated as untrusted, (ii) external data of any kind is considered potentially malicious, and (iii) irreversible actions can’t be performed autonomously without mandatory human approval.
2. The system is designed on the assumption that it will be attacked.
3. The trusted computing base and attack surface are kept to a minimum. Agents get only the tools they actually need, limited permissions, and the smallest amount of context possible. Security policy enforcement is handled entirely by deterministic components: the policy monitor, the agent harness, and isolation mechanisms (sandboxes).
4. The principle of least privilege applies. Each agent has its own set of credentials and access privileges (identity), limited to the bare minimum it needs to do its job. If an agent temporarily needs elevated privileges, it gets them only after external approval, and they last exactly as long as the task that requires them.
5. Components are isolated. In agent-based systems, this is one of the most complex and multi-layered architecture problems. The agent harness should run in an isolated environment (sandbox or virtual machine), and agents should be kept as isolated from each other as possible. Data processing in trusted and untrusted contexts is also kept separate. For example, one agent reads a pull request and writes a draft of the code, while another reviews that work without ever seeing the potentially malicious text of the request.
6. Default deny is the rule. Security policies follow the rule: anything not explicitly allowed is forbidden. This includes tool calls, interactions between agents, and network traffic.
7. Defense in depth is in place. Different measures should work at the same time and reinforce each other. Probabilistic defenses — like AI guardrails (a “firewall” for language models) or alignment (the model’s own sense of what’s acceptable and what isn’t) — can’t offer any formal security guarantees. Nevertheless, they make the system more secure overall and serve as a valuable source of telemetry.
8. The supply chain is protected. Some agents can install skills, libraries, and other software components on their own, so these abilities need strict rules. Either block them completely, or limit them to a closed, pre-approved list of specific versions of specific components. Systems built on cloud LLMs face an extra risk: model updates. One day, the same API request might be answered by a different language model with different security properties.

Pitfalls of AI security

The general principles of Security by Design are well known and look simple on paper. But applying them to AI systems is tricky because agents are incredibly flexible. For example, a security team might believe that an agent on a developer’s computer runs in a sandbox and can’t change anything outside it. But an attacker, or even the agent itself, can come up with dozens of ways around this seemingly solid protection: from running commands through a local MCP server that the sandbox doesn’t restrict, to reconfiguring another AI agent installed on the system. To make things even harder, the range of attack vectors is huge: from arbitrary fields in the agent’s configuration to innocent-looking text strings in a skill file.

One serious problem that designers often underestimate is user fatigue. A busy agent can throw up dozens of requests every minute, asking the user to confirm potentially dangerous actions. Within an hour, the person is clicking Approve on autopilot without reading what they’re approving. That’s why it’s important to carefully tune both how often these requests appear and how they’re worded. Nobody will read a request description that’s too long. And one that’s too short can hide the key details the user needs in order to make the right call.

Vulnerabilities in agents and related tools are a pressing problem — and it’s made worse by how quickly these categories of software evolve and receive updates. Industry-standard platforms and apps — such as LangGraph, MS Semantic Kernel, and Claude Code — have had critical vulnerabilities patched more than once. Architects should always consider swapping a large, do-it-all framework for a compact, stripped-down system that has only the features a specific agent actually needs.

On top of that, carefully implementing standard, long-established security measures in the available tools greatly reduces the damage if an agent is attacked or behaves unexpectedly. One example is a strict allowlist of domains that the web fetch tool can open when asked by the agent. But designers rarely account for the hidden problems and overhead associated with maintaining the list. As a result, it slowly goes out of date and leaves loopholes for attackers. The most striking example is the EchoLeak attack. Microsoft 365 Copilot had a properly implemented and fairly effective allowlist for accessing external sites, but attackers circumvented it through a feature in a secondary tool and the MS Teams domain.

Practical tips for architects and security teams

AI system architects and heads of engineering and security teams should build in agent security from the design stage. They should rely primarily on verifiable, deterministic mechanisms: isolating components, controlling interactions, and keeping the trusted computing base to a minimum.

Key architectural decisions include defining acceptable autonomy for the agents, limiting access to confidential data and dangerous combinations of capabilities, and using sandboxes, separate roles for different models, and access control gateways. Restrictions added as an afterthought reduce risks, but they’re no substitute for secure architecture.

At the organizational and operational levels, companies need to keep an inventory of their agents, coordinate the efforts of security and deployment teams, protect container environments, manage the supply chain (AIBOM), and integrate multi-layered defense.

Observability requires special attention. For AI systems, this should include logging the LLM’s requests, responses, and reasoning, as well as detailed telemetry from the hosts and cloud environments where the agent harness runs.

The hardest part of designing agents is balancing security, performance, and usefulness. To learn how to strike that balance with threat modeling and clearly defined security goals, read the full version of the study.

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.

Bianco Research president Jim Bianco raised the question during Unchained’s Bits + Bips livestream on October 26:

“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. 

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.

You can find an explanation of the version numbering system and step-by-step instructions in our guide: How to update Chrome on every operating system.

How to update Firefox

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.

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 → 

Launching the expanded AI Classroom Toolkit with Cyberlite during Global Media and Information Literacy Week 

AI is opening new pathways to information, giving people faster access to answers, ideas, and knowledge. At the same time, it’s making it harder to know whether the content we see is authentic. 

Companies that build AI have a responsibility to make it reliable and trustworthy, and that responsibility doesn’t shift to the people who use it. But AI is already shaping how people search, learn, and encounter information. Helping people navigate that reality means building media and AI literacy (MAIL): the judgment to decide whether and how to use AI and what information to trust. These skills are as foundational as AI safety, and educators are asking for help teaching them. 

That’s why, during Global Media and Information Literacy Week, we’re launching the expanded AI Classroom Toolkit: Unlocking Generative AI Safely and Responsibly, created with the online safety organization Cyberlite. It’s part of Microsoft’s broader commitment to make sure AI strengthens human thinking rather than replaces it. It also reflects Microsoft’s focus on education and empowerment, a core pillar of our Safe Participation Framework. 

What’s new in the AI Classroom Toolkit

The expanded toolkit adds a deeper focus on critical thinking, verification, and media and AI literacy, helping students judge AI outputs and make informed decisions about what to trust online. Together with the original modules, it’s now a single, classroom-ready resource that covers the core of AI safety and literacy. Realistic, scenario-based lessons and activities help students practice these skills in situations they may encounter online: 

• The Climate Campaign: Gina enters an online challenge to make a campaign for a cause she cares about and finds that some winning entries use AI to show events that never happened. Students sort a feed of real and AI-made posts and practice lateral reading. The lesson: whether a post was made with AI doesn’t decide whether it’s trustworthy. What it claims, and who is behind it, does. 

• The Helpful Bot: Alex creates an AI help bot inside his online game, then catches it inventing details and collecting players’ personal information. Students learn why AI can get things wrong, how to trace claims to reliable sources, and why they’re responsible for AI-generated content they act on or share. 

• What Kind of AI User Are You?: An interactive quiz, hosted by Cyberlite, helps students identify their AI habits, strengths, and potential blind spots, and gives them an AI Type to reflect on and discuss. 

“When we created the first Classroom Toolkit: Unlocking Generative AI Safely and Responsibly with Microsoft in 2023, most of the conversation was about using AI safely. Today, the questions young people ask about AI have grown sharper and more personal, like what to believe online or how far to trust a chatbot’s answer,” said Michelle Yao, cofounder of Cyberlite. 

The toolkit also reflects what young people in our co-design sessions with Cyberlite told us: they want to learn by doing, through games, real-life scenarios, and peer discussion. Teachers don’t need to be AI experts, and students don’t need an AI tool in hand to start. 

That approach builds on the reach and results of the original toolkit. Since 2023, the first version has reached educators in 10 countries and 11 languages, including through government and partner learning platforms. In South Korea, 93% of participating educators reported improved knowledge and understanding of ethical issues, privacy, and bias related to AI. 

“Our hope is that every student leaves a little surer of their own judgment, and that everyone feels more confident deciding how AI fits into their lives,” said Yao. 

Literacy works alongside product design and policy

Education is one part of the equation. Our commitment to media and AI literacy also shows up in how we design products and the policies we support.  

Last month, we set out five principles for AI in education, including “AI designed to support students’ learning, not replace their thinking.” We also committed to enforceable privacy, safety, and transparency protections for qualifying educational AI products in US school districts. These protections help schools and families understand how these tools work and the controls available to them. 

Media and AI literacy is now a global priority

The Organisation for Economic Co-operation and Development has released a framework for a MAIL assessment beginning in 2029. As part of its Programme for International Student Assessment (PISA), it will examine how students reflect on, analyze, and evaluate information, including AI-generated information. This week in New Delhi, UNESCO is also launching an AI extension of its “Think Critically, Click Wisely” global curriculum, which Microsoft advised on. 

This growing global focus makes the need for support urgent—educators want help, and many aren’t getting it. In Microsoft’s 2026 AI in Education report, 53% of educators and 77% of students say they haven’t had AI training.  

Closing this skills gap matters beyond the classroom. Healthy societies depend on a shared basis of facts, informed public debate, and confident civic participation. As authenticity gets harder to judge, there’s a risk that people start doubting everything, creating what the Digital Inquiry Group calls a “dangerous declaration of permanent uncertainty.” MAIL offers a way through. It builds the confidence to decide what to trust. 

Media and AI literacy for every age

Across Microsoft, we’re helping people build these skills wherever they learn and find information: 

• In classrooms: Students debate whether to accept, question, or rework an AI tool’s answers in an AI and Critical Thinking lesson from The Economist Educational Foundation, supported by Microsoft. Available alongside other media literacy lessons in Microsoft Learning Zone, the lesson has reached students in 116 countries. 

• Through play: Millions of players have checked sources, spotted bias, and cracked cases of AI misuse in Minecraft Education’s The Investigators and Reed Smart: AI Detective. 

• For content creators: UNESCO, with Microsoft’s support, is developing resources to help creator associations train their members in MAIL and is testing them with creators in Nairobi this week.  

• For voters: Check. Recheck. Vote. helps people apply AI literacy to election information. 

• In our products: Search Progress, built with input from the Digital Inquiry Group, turns research assignments into source-checking practice in Microsoft Teams for Education. 

What’s next 

Through Microsoft Elevate for Educators and local partners, we’ll bring the AI Classroom Toolkit to new audiences, with more languages and localized content rolling out through 2027. We’ll keep evolving it as technology and educators’ needs change. 

Explore the toolkit and supporting resources for educators today.  

AI will keep changing how people find information and the content they encounter. Our goal is to help people meet that change with confident, informed judgment about the AI they use and the information they trust so they can fully take part in civic and democratic life. 

The post In an age of AI, deciding what to trust is a foundational skill. Here’s how we’re helping educators teach it. appeared first on Microsoft On the Issues.

The post Ransomware in the Age of AI: How Defenders Can Break the Attack Chain appeared first on Flashpoint.

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.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

The rapid diffusion of AI globally and the pace at which AI is developing put us at a societal crossroads. The choices we’re making now will determine who has access to AI and the opportunity it affords. There is perhaps no more important tool than our education systems for addressing the uneven diffusion of AI we’re seeing currently: national adoption runs above 70% in countries such as the United Arab Emirates and falls to low single digits across much of sub-Saharan Africa, close to a tenfold difference. 

The way we teach AI and learn with it will have long-lasting impacts on jobs, the workforce, and our broader economy. Learning Curves: Rethinking Education from Classrooms to Careers in an AI-Driven World is a collection of research-driven essays that can help guide those choices. This book brings together the body of work from the second cohort of Senior Fellows from the Microsoft AI Economy Institute (AIEI), a flagship think tank that produces research and convenes experts to generate insights into how AI is reshaping work, education, and the broader economy. 

In Learning Curves, researchers consider how AI is reshaping the earliest stages of learning and work, from K–12 classrooms and community and technical colleges to college‑to‑work transitions and entry‑level jobs, and what it will take for that transformation to widen opportunity rather than deepen divides across institutions, communities, and countries.  

Below, I share a few of my own reflections that informed my contributions to Learning Curves, a collaborative effort that wouldn’t have been possible without the truly talented, diverse cohort of researchers who contributed to this book.  

The good, the bad, and the ugly: Laying the foundation for AI in K–12 classrooms

Before delving into the specifics of how to incorporate AI in classrooms, we need to ask ourselves whether we’re teaching for knowledge, or for learning.  

The book, the calculator, the personal computer, the internet, the search engine, and the smartphone all arrived in classrooms carrying real promise alongside the worry that they would hollow out young minds. Usually the truth landed somewhere in between, and where it landed depended less on the tool than on the choices the adults made about how to use it. 

The fact is that the AI-native generation is already here, and its members are in classrooms around the world. More than half of US teenagers already use AI chatbots for schoolwork. I’ve personally seen the promise of AI as a force for good in education up close in my own classroom, where I teach a computer science class to elementary school students.  

But of course, the good is only part of the story. We can’t shy away from the downsides of incorporating AI into classrooms. While AI can help with accessibility and individualized learning, it can also create over–reliance, contribute to student cheating, or prevent students from recognizing when information may be false. 

The rapid deployment of AI in K–12 classrooms needs to come with a sober assessment of how that technology impacts all students. This assessment must go beyond the technology itself to encompass how students, teachers, parents, and society use AI.   

AI literacy is only part of the solution

If classrooms are where students learn how to think, teachers are the conduit through which this learning happens. In Learning Curves, Joseph Orero, Senior Researcher in AI at Strathmore University’s School of Computing and Engineering Science, posits that teachers aren’t resistant to AI in classrooms; they just need proper training to help them adequately adapt and teach their students critical skills. His research contribution explores game-based learning with AI-enabled African languages. 

AI usage and adoption worldwide are also dependent on accessibility. Another chapter of the book looks at barriers and opportunities in Arabic education and finds that the primary barrier teachers encountered when introducing AI writing assistants into classrooms was Arabic digital literacy, particularly students’ typing ability.  

Researchers often circled around a similar theme: there is no one-size-fits-all approach to developing AI competency; instead, such an approach must be sensitive to local knowledge and contextualized teaching and learning practices. This means that teachers, in turn, must have training that makes sense for the unique contexts in which their students are learning.  

Frank Nagle, now Microsoft’s Chief AI Economist, Sarah Rodriguez, Associate Professor of Engineering Education at Virginia Tech, and other researchers in Learning Curves make the case that, in many ways, nontraditional pathways such as apprenticeships and two-year-degree programs, particularly those that are virtual, are more nimble and thus better able to adapt their curricula to the rapidly changing field of AI.  

AI Is taught in the classroom, but then what?

Education has never been about simply preparing people for the future of work so they can thrive in the labor market. When considered holistically, it is about teaching students not what to think but how to think. In our AI era, education is one of the core institutions through which the future of work will be built, distributed, and made more (or less) equitable. Successful AI integration remains human-centered by focusing on organizational change, durable human skills like empathy and judgment, strong employer partnerships, and learner needs. 

As research from Laura Nuriski, Head of Program on the Future of Work at the Centre for European Policy Studies (CEPS), highlights, access to AI alone does not ensure successful integration. Technology transfer, data infrastructure, organizational readiness, and a human-centered approach to building and deploying AI are also key indicators of success.  

Whether we’re talking about the classroom or the boardroom, it’s worth keeping in mind that AI tends to do the most good when it strengthens human capability and the most harm when it substitutes for it. That holds as true in a fourth- grade reading lesson as in a software team or a hospital ward. 

The children in our schools deserve tools that serve their learning rather than stand in for it, and that is within our power to provide. Our most successful future with AI will be one that is human-centered, inclusive, and designed to help people thrive. 

The post Learning Curves: The future of education, from classrooms to careers, in an AI-driven world appeared first on Microsoft On the Issues.

.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;}}

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?

In September, we wrote about more than 100 subscription sites built from the same cheap website kit. With Halloween approaching, we’ve found the same approach being used to sell AI Halloween videos.

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.

How Malwarebytes can help

If you have concerns about a website, Malwarebytes Scam Guard can help you assess it. Malwarebytes Browser Guard helps block known scam and malicious sites.

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.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

Introduction

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:

#	AI service
1	ChatGPT
2	Google Gemini
3	Claude
4	Grammarly
5	DeepSeek

While analyzing the most popular and widely used apps, our experts also noticed a sharp rise in vulnerable versions of AI-related software and services. From 2025 to date, more than 2500 vulnerabilities have been published:

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:

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.

For more on how to configure Application Control in KES, follow this link. Our public portal also lets you explore information on KL categories and the applications that fall under them, in particular details on how AI agents are categorized and how popular they are.

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.

When configuring access, the administrator can block websites that provide AI as a service.

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.

Kaspersky Threat Intelligence Portal

AI agent profiles

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:

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.

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.

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.

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

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.

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.

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.