When your pet goes missing, it can be totally heartbreaking.
So hearing that they’ve been found is no doubt very welcome news. Even better to see a photo of them looking safe and well.
But while the photo may look exactly like your pet, that doesn’t mean the person who sent it has your pet or even ever saw it.
The BBC reports how criminals are sending owners AI-generated images of their missing pets, demanding money for their return, and sometimes threatening to harm the animals when owners refuse to pay.
The BBC interviewed two targets of this scam who were both contacted after posting a missing pet message on social media. The scammers sent them pictures of their beloved pets and demanded a ransom for their safe return.
Messages like these exploit two powerful emotions in quick succession: relief that a beloved pet has been found, followed by fear that something terrible will happen unless the owner acts immediately.
The scam typically follows this pattern:
A scammer finds a missing pet appeal, which is typically posted to social media or local sites with an accompanying photo and contact details.
The scammer contacts the owner and claims to have found the animal. An image fabricated with the help of AI makes the claim appear more convincing.
They ask for money which may be described as a reward or as payment for emergency treatment.
They add pressure. They might refuse to meet until payment arrives, or threaten to sell or harm the pet.
Our data backs this report up. Over the last month, people anonymously submitted three distinctive types of pet related scam attempts to Malwarebytes Scam Guard:
“We found your missing cat” message, with photos: Someone claimed to have found a user’s missing cat and had images of it.
Found pet callback lure: A voicemail claimed to have found a lost cat and supplied a callback number.
Humane Society impersonation and payment demand: A caller claimed a missing cat needed emergency surgery, and demanded successive Zelle payments.
How to stay safe
Sadly, while it can be very useful to use social media to retrieve lost pets, it also attracts scammers and other abuse.
You don’t have to stop asking for help online, but you can put some safeguards between an unexpected message and any payment.
Keep some identifying details private. Leave a distinctive feature out of the public description so you can ask a supposed finder about it later.
Do not pay in advance to secure a reunion. Be particularly wary of someone who insists that you send money before they will let you see the animal. Arrange any legitimate handover in a safe, public location, and verify that it is your pet before paying a reward.
Verify veterinary claims independently. If someone says your pet is at an animal hospital, find the hospital’s contact details yourself and call it directly. Do not rely on the number or payment link in the message.
A second pair of eyes can help you assess a demand without the same emotional pressure. Malwarebytes Scam Guard can help you identify whether a message might be a scam and how to proceed.
If someone is threatening your pet, remember that when they make threats to your pet, it is very likely they don’t have a clue where it is either, so don’t let them extort you.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
As part of proactive threat monitoring, Kaspersky’s Cyber Threat Intelligence team identified a malicious campaign involving C2 agents controlled by artificial intelligence. Confirmed victims of the campaign included organizations in the education sector in several countries across Africa and Latin America. CyberStrikeAI played a key role in the post-exploitation phase. This is an open-source framework in which an LLM orchestrator on the command-and-control server plans actions, selects tools, and generates commands, while an implant executes them on compromised hosts. Using CyberStrikeAI, the attackers progressed from reconnaissance to full domain compromise.
According to our data, this is one of the first public descriptions of a compromise involving an LLM in the wild. The campaign we discovered clearly illustrates how the role of AI in attackers’ arsenals is evolving: until recently, language models were used primarily during preparatory stages – for writing phishing emails, debugging code, or searching for vulnerabilities. Now, however, they are being embedded into the very core of the attack, automating actions at every stage: payload execution, persistence on the host, discovery, lateral movement, and, finally, data collection and exfiltration. Post-exploitation – the stage that traditionally required manual work by an experienced operator – plays a particularly significant role here.
A key feature of the scheme using the CyberStrikeAI framework is that the implant ceases to be a simple tool for executing the operator’s commands. Decisions are distributed across two levels: the operator defines the task in general terms, while the model determines how to execute it – specifically, which commands to send to the host and in what sequence. Thus, the strategic planning remains with the human, while the choice of technical steps is delegated to the model, and the implant executes the model’s decisions.
To understand how this scheme works in practice, let’s examine the chain of actions taken by the attackers, as reconstructed by our analysts during the incident investigation.
Timeline of the attack
Let’s examine the timeline of the attack using an example from one incident within the detected campaign.
The first phase follows a standard approach: a human operator gains access to the victim’s infrastructure via a compromised SQL Server (version 16.0.1000), then collects basic information about the host, deploys tools, and conducts network reconnaissance. All of this activity takes nearly a day, followed by a two-week pause.
The second phase is fundamentally different. The first step involves deploying the CyberStrikeAI C2 agent, which receives commands from a server-based LLM orchestrator. During the second phase, the agent performs the following:
establishing persistence and conducting local reconnaissance within 2 minutes;
conducting domain reconnaissance over the next 5 hours;
after a brief pause of several days, moving on to the final stage – lateral movement via SMB and WMI, mass credential dumping on hosts, and database export – with the entire operation taking no more than one hour.
We’ll discuss these stages in more detail in the next section.
Technical details
CyberStrikeAI overview
CyberStrikeAI is an open-source, modular platform written in Go for automating penetration testing. Its key feature is combining LLM-based attack orchestration and a built-in C2 server with agents (beacons) within a single server process.
The entire “intelligent” layer is isolated on the control server. C2 functions (calling reconnaissance and exploitation utilities, managing webshell connections, assigning tasks to agents, and reading results) are available to the model as MCP tools. The implant is a classic C2 agent with no AI functionality – no API keys, no calls to AI service APIs, and no autonomous logic. It periodically polls the listener server via HTTP/S, TCP, or WebSocket, executes shell commands, and interacts with the file system. To the victim, this activity looks like a typical remote-control session, where a server-side LLM orchestrator queues tasks instead of a live operator. The LLM influences how decisions are made, but not how the corresponding commands are delivered to the host.
Although CyberStrikeAI is publicly available, specific instances of the framework can be linked to specific attackers or campaigns. Detection and attribution are possible based on the following artifacts:
Control panel: Upon launch, a self-signed TLS certificate is generated, with the framework’s name appearing in the issuer and subject fields. The certificate is created in memory at each startup, so the not_before field effectively records the time the process was launched. Accordingly, as with Cobalt Strike, the chronology of restarts can be reconstructed from the scan history.
CyberStrikeAI control panel’s self-signed TLS certificate
Implant: The build metadata (go version -m) contains a path to the main package, which includes data pointing to the built-in CyberStrikeAI generator – a temporary directory with the build identifier. This path is identical for all payloads, making it a reliable signature. Additionally, the build info field contains version control system metadata, which can be used to compare samples against one another.
Authentication: When communicating with the server, the implant sends an X-Implant-Token header with a fixed value in the HTTP request. The token is unique to each C2 server and is embedded into the malicious payload during the build phase; therefore, it serves as both a network indicator and a sign that the samples belong to the same server.
HTTP header parameters sent by the implant to the server
It should be noted that the implant version does not reflect the server version. The implant can operate for months while the operator updates the server-side components: listener configurations and keys are preserved during updates. In the incidents we detected, we observed the use of a single agent version throughout the entire incident. In such cases, the sample’s build date may indicate the earliest possible deployment date of the CyberStrikeAI infrastructure, but it still does not provide an estimate of the compromise duration.
Execution & Privilege Escalation
The first malicious commands on the victims’ systems in the campaign under investigation originated from the sqlservr.exe process, indicating the likely initial access vector and the context in which the attackers gained the ability to execute code. It is important to note that the commands marked as having been executed prior to agent installation were executed manually by the attacker specifically within the context of this process. At this stage, we are not yet dealing with automated implant activity, but rather with manual actions by the operator.
Before launching the agent on the machines, the attackers checked for its presence using a PowerShell script, from which we can deduce its default deployment paths: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. At the same time, the attacker can disguise the agent’s name as that of a legitimate system process. In the example below, it mimics svchost.exe (svchosts.exe)
Checking for the presence of the CyberStrikeAI agent on the system
Delivery and execution of the CyberStrikeAI agent
Like most C2 agents for Windows, CyberStrikeAI uses PowerShell to execute its payload. When a request is received from the operator, the commands to be executed are additionally encoded in Base64 to bypass keyword-based detection.
Decoded form of the command:
When administrative privileges were available (for example, a domain administrator account), instead of executing commands directly, the agent on remote hosts often created scheduled tasks so that the malicious payload would run with SYSTEM privileges:
An alternative method that does not use schtasks utility is to create a task via the Schedule.Service COM object:
The payload (p1.ps1) from the example above is a reverse shell that connects to the server at 185.186.245[.]144:5501:
The p1.ps1 payload and similar scripts were distributed across the network using shared network administrative folders and the WMI protocol, which we will describe in more detail in the Lateral Movement section.
Stealth
In addition to encoding commands in Base64 and obfuscating SQL/LDAP queries – which we will describe in the Collection & Exfiltration and Discovery sections, respectively – the attackers split the malicious payload into multiple files. It is noteworthy that the scripts were transmitted in this manner even before the agent was installed – that is, at a stage where human intervention is typically required – yet they clearly bear the hallmarks of being generated by an LLM.
Below is a sequential record of several script fragments written to the file d3.b64.
Subsequently, the attackers used the certutil utility to decode the resulting file and executed it with the following command:
Once assembled and decoded, the script’s contents looked like this:
The script is a tool for decrypting DPAPI secrets from the file C:\ProgramData\dsn_line.txt. This file, in turn, is populated by the following command, which searches for a DSN string containing connection settings in the SQL Server Reporting Services configuration file rsreportserver.config and copies its contents to dsn_line.txt.
It is worth noting that some of the scripts delivered and executed as described above contain comments in Chinese (## – researcher’s comments).
Persistence
If the CyberStrikeAI implant was successfully delivered, the first step was to establish persistence on the target system. To do this, the agent created a scheduled task named SystemUpdate, which specified the path to the implant as the action to be performed:
Analysis of the framework’s source code revealed an alternative method of persistence: by adding a value to the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run, where the name of the created value matches the task name (SystemUpdate).
Agent persistence on Linux systems is also implemented in two ways – by adding the entry @reboot <path_to_beacon> & to the user’s crontab (in which case the process runs at system startup), or by adding the line (nohup <path_to_beacon> &>/dev/null &) to ~/.bashrc (in which case the agent starts when an interactive bash shell is opened).
It is worth noting that the choice of a specific persistence method is delegated to the LLM connected to CyberStrikeAI. However, thanks to the human-in-the-loop (HITL) mechanism, the operator retains full control over the process: commands generated by the model may require manual approval or correction before they are executed.
Discovery
Local Discovery
Before installing the agent on a compromised host, the attackers manually gathered basic system information using a fairly trivial set of commands:
The attackers also manually checked for internet access and obtained the external IP addresses of the compromised machines using the Chinese service dnslog[.]cn. The service generates a random third-level domain, after which the attackers attempt to resolve it on the compromised machine.
If the machine has internet access, the request succeeds, and the attackers obtain the external IP address of the compromised device on the service’s page.
For reconnaissance purposes, the agent generates a more complex script designed to map out a path for further privilege escalation by compromising SCCM or exploiting msiexec (the AlwaysInstallElevated key):
Additionally, to find ways to elevate privileges locally, the agent executed scripts to inventory services running under domain accounts and tasks running under the SYSTEM account:
During their activity, the attackers periodically checked for Microsoft Defender detections:
Remote Discovery
After gathering information about the compromised host, the attackers proceeded to conduct reconnaissance within the network. During the preparatory phase of the attack, they manually collected additional information about remote hosts using the net.exe utility.
During the main phase, the agent used PowerShell’s built-in functionality to detect accessible hosts without relying on additional utilities (such as nmap or fscan):
Additionally, relevant LDAP queries to Active Directory objects helped build a network map:
Furthermore, the presence of the installed agent on remote hosts was verified using WMI:
Domain Discovery
The next step was to gather information about the victims’ domains. To this end, before installing the agent, the attackers used standard OS utilities:
However, later on, using the CyberStrikeAI implant, reconnaissance was carried out via generated PowerShell scripts:
In addition to basic domain information, the agent performed LDAP queries to gather information for Kerberoasting and AS-REP Roasting attacks:
Finally, the agent was used to check the domain for the presence of LAPS and Microsoft Azure:
To detect signs of Microsoft Azure usage within the infrastructure, the attackers also searched for the .azcopy directory – created by the AzCopy (Microsoft Azure Storage Copy) utility – in users’ home directories:
Credential Access
After successfully conducting reconnaissance and mapping the network, the attackers moved on to the next stage – dumping credentials. For this purpose, the agent used a classic set of LOLBINs and well-known third-party tools.
The agent dumped registry hives containing credentials using the reg.exe utility:
The agent dumped the lsass.exe process using the MiniDump function of the comsvcs.dll library. In doing so, the target process’s PID was used instead of its name to make static detection based on the command line more difficult:
After successfully compromising privileged domain accounts (specifically, the built-in domain administrator), the attackers also carried out DCSync and Golden Ticket attacks via the agent using a renamed version of the mimikatz utility:
Lateral Movement
To spread across the network using compromised accounts, the attackers employed utilities from the Impacket toolkit, specifically WMIExec, as indicated by the utility’s characteristic command line:
Once installed, the agent prefers to use standard OS mechanisms, such as shared network folders.
Another method the agent uses to remotely execute commands is the WMI protocol. In particular, the agent used it to distribute the aforementioned p1.ps1 reverse shell script. This involved using compromised user accounts with local administrator privileges on the target hosts:
A second method of lateral movement via WMI uses the Invoke-CimMethod cmdlet:
Command & Control
To deliver the aforementioned tools (malicious scripts, mimikatz, and the agent itself) to the initial nodes in the infection chain, the attackers used standard OS utilities:
After the agent is installed, it checks the availability of the C2 server’s ports. The implementation mechanisms here are virtually unlimited and depend on the “creativity” of the respective LLM agents connected to the server:
To download additional utilities, the CyberStrikeAI implant also used built-in utilities (LOLBINs). The tools could be hosted on the attackers’ own servers or downloaded directly from GitHub:
Collection & Exfiltration
The data collection phase deserves special attention. It demonstrates yet another capability of LLM orchestration – the automatic generation of SQL and LDAP queries tailored to a specific task.
In one incident during the campaign, the attackers deployed the CyberStrikeAI implant on an educational organization’s SQL server and collected information from the database via PowerShell. Here is an example of a command executed by the agent:
Normalized view of the executed script with comments:
Before accessing the data, the agent checked the privileges of the account under which it connected to the database:
In decoded form, the check looks as follows:
On network resources, file collection was preceded by a recursive directory scan to identify files of interest.
To interact with the file system, the implant provides a built-in interface that supports direct uploading and downloading of files. Files are transferred directly via the main encrypted communication channel with the C2 server (HTTP or TCP), and the data itself is encoded in Base64 and packaged into the agent’s standard JSON responses.
Another built-in capability of the implant is taking screenshots of the infected machine. As with other actions, the implant does not initiate this on its own: the command to capture the screen is issued by the LLM orchestrator, and the agent merely executes it and returns the result via the same control channel.
On Windows, the command for taking screenshots looks like this:
The Linux version looks like this:
In the incidents we detected, data collection was the final stage of the attack: the chain ended there, and we observed no further activity.
Attribution
The key artifact for attribution in this campaign is the implant’s build metadata. The attackers built the malicious payload inside a Git clone of the project, so the Go compiler embedded version control system information into the binary files – the hash and commit time, as well as the vcs.modified=true flag (analogous to the +dirty suffix) – indicating uncommitted local changes in the working copy. The combination of these fields forms a unique fingerprint for a specific build.
Based on this fingerprint, the samples are divided into two independent groups, in each of which the Windows implant and the Linux implant have completely identical build metadata. A match indicates that, within each group, both payloads were built from the same project working copy.
Identical build metadata for the Windows and Linux implant samples, indicating a shared build environment
However, these groups do not overlap with one another. They do not share a common C2 infrastructure, and different versions of CyberStrikeAI are deployed on the command-and-control servers. In other words, the build metadata reliably links the samples within each group but does not provide grounds for linking the two groups together.
Differences in CyberStrikeAI versions on the command-and-control servers
The available data does not allow us to link the activity to any known group of attackers, nor to state with certainty that the same operator is behind both campaigns. Two factors prevent this. First, the tool’s openness: CyberStrikeAI is publicly available, so different operators could have independently deployed it and assembled malicious payloads under similar conditions. Second, command generation by the model: the “signature” characteristic of a specific operator is largely shaped not by a human but by an LLM. On the one hand, this increases the diversity of commands: the same command, when generated multiple times, can look different. On the other hand, it strips them of their individual characteristics, which reduces the value of behavioral metrics for attribution.
However, the Chinese-language comments found in the attackers’ scripts and the use of Chinese services still suggest a connection between the activity and a Chinese-speaking operator. In addition, analysts noted the timing of the control servers’ restarts: since the self-signed TLS certificate is regenerated each time the process starts, its not_before field records the restart time, and most of these restarts occurred during business hours in the UTC+8 time zone.
The origin of the tool itself also indirectly points in the same direction: CyberStrikeAI was developed within the Chinese cybersecurity community and is well known there.
In summary
CyberStrikeAI is a telling – though not unique – example of a shift occurring within the class of C2 frameworks: the LLM orchestrator is no longer merely an add-on to reconnaissance but has become a control layer over post-exploitation. If HexStrike AI and similar tools cover the “find and break” phase, and Sliver/Mythic/Havoc cover the “establish a foothold and control” phase, CyberStrikeAI completes the kill chain: a single server-side process written in Go executes utilities via MCP, handles webshell connections, and assigns tasks to the implant, while the model analyzes the results and decides what to do next.
The key takeaway is that the introduction of AI into the attack chain does not yet present fundamentally new challenges for detection. All the “intelligent” work remains on the attacker’s side, while the compromised host is subjected to familiar actions: from reconnaissance via Kerberoasting and AS-REP Roasting to LSASS dumps, DCSync, and the Golden Ticket attacks. This is a typical, well-documented set of domain compromise techniques. The novelty of the attack lies not in the methods themselves, but in the speed and ease with which they were executed: AI orchestration has lowered the skill requirements for the operator, but has not taken the attack beyond what defenders already know and are capable of detecting. The timing is also telling: individual key phases of the activity (such as establishing a foothold, lateral movement, and obtaining credentials) took only a few hours, and the entire attack – from agent deployment to the compromise of domain administrators – was completed within 3–4 days.
However, the CyberStrikeAI architecture does not limit users to the scenario described. The same mechanisms allow for the on-demand assembly of more complex chains – including DPAPI secret extraction and attacks on SCCM and Azure IMDS – all of which are within reach of the same group of actors, with a relatively low skill barrier. As the models evolve, the gap between the complexity of orchestration and the level of techniques used will narrow, and the operator’s role will gradually shift from setting tasks to monitoring the model’s actions.
Detection by Kaspersky solutions
It may seem that attacks using AI agents require the creation of fundamentally new detection rules. Indeed, to detect the activity of an LLM agent installed on a host within the infrastructure, it is necessary to create detection logic based on the specific characteristics of the agents. Detection rules for this activity can be found using Hunt Hub with the following filter.
However, in the case of the attack described, a different logic applies. The main difference lies in the architecture of the attack itself: the LLM agent was not located within the corporate network perimeter. It operated remotely via a C2 agent, orchestrating actions, and left no traces of its presence in the infrastructure (such as specific API requests to local LLMs or anomalous patterns of resource consumption by hosts).
The key difference between this activity and an attack by an experienced human operator lies largely in speed. Tactically, technically, and methodologically, AI, for the most part, uses exactly the same tools, utilities, and techniques as a human penetration tester. It does not write unique exploits from scratch, but rather combines known methods and dynamically adapts them to the situation, handling the tools’ errors on its own.
Since the actions performed by an AI agent on the network are indistinguishable from those of a human, classic, well-tuned correlation and behavioral analysis rules are sufficient to detect it. Here are a few examples of how Kaspersky Next EDR Expert successfully detects the attack described:
During the attack, the adversary will need access to the victim’s credentials; in the described case, one way to obtain them was through a well-known technique that uses legitimate tools to dump LSASS, specifically by calling the MiniDump function from comsvcs.dll. The EDR Expert solution detects this activity using the rules dumping_memory_with_com_services_dll and suspicious_lsass_memory_access.
A significant part of the attack chain is lateral movement, which helps the attacker navigate within the infrastructure and achieve their desired objectives. In the described case, the WinRM protocol is used to initiate connections directly from PowerShell. This is a standard technique that allows the attacker to execute commands on remote machines without using additional network tunnels. The EDR Expert solution detects this activity using the rules using_powershell_for_remote_execution_via_wmi and winrm_send_command.
Kaspersky Anti Targeted Attack (KATA) is used to detect malicious activity in network traffic. Communication between CyberStrikeAI agents and the command-and-control server occurs without accessing AI platforms such as ChatGPT or Claude. Instead, the agent’s C2 server is an infrastructure pre-configured by the attackers, just as in attacks that do not use AI agents. Analysis of decrypted network traffic using NDR-class solutions reveals characteristic communication patterns of CyberStrikeAI agent activity. When these patterns are detected, KATA generates an alert with the verdict Backdoor.CyberStrikeAI.HTTP.C&C.
Alert regarding the detection of CyberStrikeAI communication with a C2 server
To detect post-exploitation activity, you can use not only IDS technology but also NAD (Network Anomaly Detection). It analyzes all traffic for suspicious indicators that do not correspond to a node’s typical network activity.
For example, actions performed by CyberStrikeAI during the Domain Discovery phase are detected by an NDR:NAD rule named “Scanning domain records via LDAP queries.”
NDR:NAD alert: reconnaissance via LDAP queries detected
You can learn more about NDR:NAD technology in our article on Securelist.
You can also visualize the connections between C2 addresses and files used by attackers in the Research Graph section of the Kaspersky Threat Intelligence Portal. This includes tracking the emergence of new CyberStrikeAI implants that communicate with malicious addresses.
Visualization via the Research Graph on the Kaspersky Threat Intelligence Portal
In addition, the Threat Lookup service available on the portal allows you to determine whether malicious files belong to CyberStrikeAI using attribution mechanisms based on the executable file’s code.
Demonstration of attributing a malicious implant to the CyberStrikeAI framework
Kaspersky SIEM detects all stages of an attack by the CyberStrikeAI agent. The product repository contains over 100 rules for detecting the techniques discussed in this article; we will list the most critical ones below.
Execution of various commands from the sqlservr.exe process:
R300_04_Windows shell started by a web application
Downloading and executing a payload via PowerShell:
R110_03_PowerShell code downloaded and executed
Creating Windows scheduled tasks:
R099_04_Suspicious arguments when running schtasks.exe
R300_03_Windows shell started by the scheduler
Persisting via crontab or bashrc:
R099_06_Suspicious cron job activity
R405_02_UNIX shell configuration modification
Rules located at the KUMA Packages/SOC package/Configuration discovery path detect the collection of information about hosts, network settings, and domains using various reconnaissance tools. Rules that aggregate detections by reconnaissance tools:
R224_14_Windows reconnaissance activity
R224_09_System information discovery by running multiple utilities within a short period
R224_04_System information discovery via standard Linux tools
Data collection for Kerberoasting and AS-REP Roasting:
Warning: this blog is an experiment. The idea for a blog came from a real conversation I had with somebody. The content is researched, debated, refined, “hardened” by a Gemini skill I created (using Gemini 4 Argon). Then Claude Opus 5.5 performed a peer review, and tore some parts to shreds. Then rewrote them. And then I very lightly edited it, and tuned a few jokes. I replaced a food fight joke with a pillow fight joke, specifically. Let me know if this sucks, and I will stop. Promise!
—
A security peer recently shared a proposal they had just heard in the wild: instead of paying for a SIEM, why not load several days of raw log data into a locally run open-weights model, ask it “what looks risky?”, and review whatever the model highlights?
No SIEM ingest tax! No cloud token bills! No SIEM license fees! No writing correlation rules! No tuning anomaly detection! Just a gaming GPU under a desk and pure, artisanal AI-native vibes. Ahhh, magic!
Gemini illustration
Wait. Really?
My first instinct, forged by 24 years of staring at logs since I first met a SIM in January 2002, was to laugh, pour a drink, and move on. Surely everyone knows this is a terrible idea, right? Right?!
Wrong.
If an engineer, an IT director, or a cost-cutting CFO pitches “local LLM as a poor man’s SIEM” in your organization, you cannot just roll your eyes and mutter “hallucinations.” People keep inventing this idea for real reasons. SIEM ingest pricing still hurts: some vendor cost explainer works out 5 TB per day at $2 to $4 per GB as $3.6 to $7.3 million a year on ingestion alone. Detection engineering is still hard work. And yes the AI hype machine has spent two years promising executives that models can “reason over any unstructured data.”
So let’s dissect why dumping a week of raw logs into a local model breaks four basic laws of “operational physics”, and then carve out the narrow 10% where a local model does help with logs. The short version fits on a sticker: the LLM writes the parser, it never runs as the parser. And the twist is that the problem here is “raw,” not “local.”
Token Arithmetic and Naive Chunking (Or: How Big Do You Think 7 Days of Logs Is?!)
Let’s start with grade-school arithmetic, because clearly nobody pitching this architecture has ever opened a calculator…
Forget the enterprise. Take a tiny environment, a single server rack generating a measly 1 GB of raw text logs per day. Seven days of logs is 7 GB of text, or roughly 1.75 billion tokens at 4 characters per token. That is generous, since IP addresses, GUIDs and hex strings tokenize worse than English (Wow, really? Yes, really — at least Claude thinks so! He would know, right?)
Now look at that “free” 8B or 70B parameter model on your GPU workstation. Its usable context window, before the KV cache devours your VRAM and the fans sound like a Boeing 747 on takeoff, is maybe 32K to 128K tokens. You are shoving 1.75 billion tokens through a 128K keyhole, which is about 13,700 full context windows. Painful enough yet?
Well, it gets worse. Assume your box reads a generous 2,000 tokens per second (benchmark your own, I’ll wait). Reading those 1.75 billion tokens takes about 10 days. You need 10 days to read 7 days of logs, so you never catch up! Scale that to the 5 TB per day example above and it is about 20 years of GPU time for each day of logs. Hilarity ensues! Replacing a deterministic stream processor with a token-by-token text predictor is like replacing your municipal water pipes with a guy carrying a silver espresso spoon from a well 10 miles away.
“Fine, Anton,” the DIY enthusiast says, “we’ll chunk the logs into 2,000-line batches and loop the local model over them all weekend!” Or we will get a bigger boat… eh… server rack to run the model.
Chunking naively, by just loading the data in batches, fails hilariously. Here is how:
Attack chains get cut. The phish on Tuesday lands in one batch, the lateral movement on Thursday lands thousands of batches later, and no prompt ever sees both. Each batch gets judged alone.
Merging the summaries does not bring the signal back. By the time you summarize the summaries, the one quiet line was already dropped in round one. So “naive+” fails as well.
Position inside the batch matters.Liu et al.’s “Lost in the Middle” found that models do best when the relevant information sits at the start or end of a long context and degrade sharply in the middle. They tested question answering and key-value retrieval, not logs, but picture a quiet privilege escalation on line 1,482 of your batch. Worst seat in the house.
Researchers keep running into this. Cai, Ryan and Karie note that iterative approach is limited by context capacity and that map-reduce style summarization is computationally heavy (and requires some luck). Even so, that is a proof of concept on up to 20,000 rows per dataset, and they say enterprise volumes remain to be validated.
So smarter chunking exists (reminder: it is not magic, in this area nothing truly is): parse, cluster, then retrieve by entity and time. At that point you are building the first half of a SIEM. Congratulations!
As I wrote in The Ancient Art of SIEM, cost pain is eternal and only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of cloud budget, and in 2026 you run out of tokens and VRAM.
The Input-Centric Time Machine: Back to 2002 Batch Review
Notice the most revealing phrase in this idea: “load 1 to 7 days of log data… and then review what the model highlights.”
That is not real-time detection. That is batch-mode log archeology! When intruders can go from initial access to data theft in hours (soon: minutes for some incidents), reviewing a week of logs in a batch means you are running a weekly book club about how you got breached last Wednesday. But hey … is your SIEM faster? Well, it should be!
Worse, asking an LLM to “highlight what looks risky” violates the most important lesson of two decades of detection engineering. In Output-driven SIEM, 13 years later, I revisited my favorite 2011 mental model: think about what you want to see at the output before you collect, and AI does not change this. Asking a model to “find risk” in raw logs with zero detection engineering is the ultimate input-centric anti-pattern. It failed with ML in mid-2010s, and LLM is not different (in this regard).
Now, about determinism. The lazy objection is “the answers change on every run,” and a sharp engineer will reply “so pin the seed.” Fair enough! Run-to-run randomness is an engineering problem: Thinking Machines got 80 unique completions out of 1,000 at temperature 0, then 1,000 identical ones after fixing their kernels. But is it actually bad? Maybe if you run 5 times, you will find 2x more “fun” things. But hey … also probably at least 5x more noise.
The harder test is stability. Take the same 48 hours of domain controller logs, shuffle the order or change one irrelevant line, and run it again. Given what we learned, I would bet real money the verdict moves. Well-crafted SIEM rule does not care what order the lines arrive in.
Zero Local Context Equals Hallucinated Risk
Why can’t a local model tell an active nation-state intrusion from Tuesday’s messy IT administration? Because raw logs do not contain your organizational reality! Shocking, eh?
A raw syslog or CloudTrail line says that svc_deploy_04 logged into prod-db-02 at 3:14 AM from an internal jump host and ran an encoded PowerShell script. Is that a five-alarm breach or the legacy billing batch job that Bob in accounting wrote in 2017 and nobody dares to touch? This is a dated example, on purpose. Insert your own fun example involving a shadow AI agent!
In Part 3 of the Stop Building a 2003 SOC series, I argued that the #1 reason AI fails in the SOC is the absence of Context as Code: machine-readable, owned, and expiring knowledge of your assets, business processes, and weird administrative exceptions. In Part 2, we warned about automation bias: humans reviewing plausible, well-written machine verdicts approve them.
Also, the test from Can AI Let You Jump SOC Maturity Levels? applies here: does this exist because someone had to spend time, or because someone had to learn something about us? Writing a parser is a time cost. Knowing about Bob’s job is a learning cost, and no model downloaded from the internet has paid it.
Feed raw logs into a naked local LLM with no CMDB enrichment, no threat intel, no identity graph, and no 90-day baseline, and its only source of “context” is its pre-trained weights. So it flags every scary-looking word (ERROR, DENIED, admin, root, failed) and writes you a convincing fictional thriller about your own network.
The Confused Deputy Trap: When the Attacker Prompts Your “SIEM” via User-Agent
Now put on an attacker hat for 30 seconds. What is a log file?
A log file is untrusted, attacker-influenced input. Every public-facing web server, SSH daemon, API gateway, and email relay faithfully records whatever string an outsider sends in an HTTP User-Agent, a failed username field, or a JSON payload.
Log processors have been attacked through logged strings before (hi, Log4Shell!), but that was a bug you could patch. In a raw-log-to-LLM setup there is no parser boundary to patch, because instructions and data share one channel. You just handed the attacker write access to your detection engine’s prompt!
Summaries are also scary, BTW. Pandey and Bhujang found that the classic “ignore all instructions” override failed completely against the one model they tested, but context manipulation reached 96% success on summarization with no defenses and 38% even with constrained output.
In How to Solve the Mystery of AI Defense in Depth (and my October 2026 collaboration with Usman Chaudhary, The Model Has Preferences, but the Harness Got Controls), I emphasized that a model’s statistical preferences are never a security boundary, and only a deterministic harness is. Feed unparsed logs straight into a local LLM with no harness, and any kid with curl can blind your review or flood your team with fabricated critical alerts…
The Problem Is “Raw,” Not “Local”
Let’s be fair to the local crowd, because they have a point.
Local solves a real problem. Logs are full of secrets, PII and internal hostnames. Not shipping them to a third-party API is a legitimate reason to want a model on your own hardware. It also — theoretically — eliminates an endless stream of unpredictable token costs flowing to a frontier model provider.
Small models are not the villain. In the same paper, a structured design called Aida (separate agents for investigating, challenging and judging, working through a SIEM) used open-weight Qwen3.5 9B and it was workable for the task they had.
“What about an agent querying a log store?” Now we are talking! The model forms a question, a database searches 7 days of logs deterministically, and the model reads a small result. That is a very different architecture, and it needs parsed data, a query engine, detections to start from, retention and access control. Sound familiar?
So keep your local model if you want it. What is missing from this proposal is the SIEM…
The Raw-Logs-to-Local-LLM Delusion Matrix
For explaining this to an enthusiastic colleague (or a budget-slashing executive) without starting a pillow fight:
Wait, Is a Local LLM Good for Anything in Log Land? (The 10% Where It Shines!)
I am a constructive cynic, not a Luddite (At least Gemini 4 Argon thinks so!). As I noted in the SOC maturity post, AI can jump the artifacts, and parsers are on that list (with caveats for tricky log sources). So point your local model at logs as an engineering sidecar, not an ingestion engine:
Writing the parser, not being the parser. Instead of feeding 50 million lines from a weird legacy mainframe into an LLM, feed 20 sample lines and ask for a regex, OCSF mapping, or pipeline rule. The LLM writes the code once, and deterministic CPU code parses the 50 million lines at wire speed. This mostly works, I swear.
Post-trigger micro-slice investigation. Once a rule or EDR alert fires on a specific host and 15-minute window, pull 200 pre-filtered, enriched log lines and ask the model for a timeline. Those lines still contain attacker strings, so treat the summary as untrusted and let the model request actions only from a closed list.
Ad-hoc query translation. Translate an analyst’s question into KQL, SPL, or SQL, so the database searches 7 days of logs deterministically. This also mostly works, but some YMMV.
The Lean Team Reality
What if you are the CISO of a regional insurer or hospital with a small security team, a hybrid stack, strict state regulators, and an MDR provider? When an engineer or cost-conscious VP suggests “let’s dump our noisy firewall logs into a local Ollama box,” they aren’t trying to sabotage your SOC. They have a log source that is too expensive to send to the SIEM, and they want a free way to “keep an eye on it.” Here is how to solve that without a science project:
Don’t use a GPU box as a poor man’s data lake. Route a noisy source to cheap, searchable object storage, or strip verbose fields in a pipeline before ingest. This is my old two-tier answer (a SIEM plus a broad, cheap log store), and it has aged well.
Hold your MDR to the same standard. When they brag at the next QBR about “AI-powered log analysis,” ask whether deterministic detections run first or whether it is an LLM wrapper over unparsed telemetry. This point alone is worth the price of reading this blog (A.C. — this is me, not AI)
Channel the DIY energy. Give your smart engineer 50 anonymized lines from your gnarliest legacy application and ask for three high-signal filter rules you can deploy in your real pipeline.
Action Items for Security Leaders
Is there anything you need to actually do?
Run a napkin token audit on any AI log proposal (Monday morning). Before the demo starts, ask: “How many GB per day is the raw source, how fast does the model read, and what deterministic step selects the tiny slice that reaches a context window?” If the answer is “we’ll just load it in batches,” kill the project on the spot. It’s this “just” word.
Fix ingest pain with tiering (30-day play). If this idea surfaced because a log source is too expensive for your SIEM, solve that: drop repetitive keepalive chatter, route compliance-only logs to cheap storage, and keep output-driven security data in your detection tier.
Make “the LLM writes the parser, never runs as the parser” a standard (architecture play) — that is, if you write parsers at all. Allow LLMs at design time (parsers, mappings, queries from small samples) and at post-alert time (small, bounded, enriched slices), but not as the runtime ingestion or anomaly engine over raw logs. Put it in your MDR requirements too… otherwise they will keep whining that it takes 7 weeks to integrate a log source forever.
Test your existing AI log workflows for prompt injection (60-day play). If your SOC or MDR summarizes anything containing attacker-controlled strings, test it in your next purple-team exercise. Do not stop at a naive “ignore instructions” canary, because passing that proves little. Try persona and context-rewriting payloads, plus payloads split across lines.
So, Do You Need a SIEM?
Call it a SIEM or call it a pile of parsers, a query engine, detections and retention. You need those things, and a GPU under a desk does not replace them. By all means run a model next to them, I promise it will be fun!
The part that worries me most is how this fails. A detection rule that misses can be tested, tuned, and re-run. A model that misses hands you a nice summary, and nobody knows what was not in it. As I said in September, skipped maturity used to fail loudly, and now it fails quietly.
We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” That goes for your context window too.
Legal systems encode the foundations of social order in natural language. Similar to computer systems, the written law can contain vulnerabilities that invite exploitation.1 Courts absorb most exploits through interpretation, and such vulnerabilities rarely surface in the first place. With highly capable AI systems enabling the discovery of vulnerabilities at unprecedented scale, we believe the latter could change.
In testing this hypothesis, we have identified a substantial number of vulnerabilities in the German legal system using LLMs. To our knowledge, none of these have been previously recorded. We share a selection of vulnerabilities below, and present potential exploits for each. We share only those vulnerabilities whose exploitation we believe would not cause serious harm.
We believe that with cheap legal reasoning proliferating, AI systems could jeopardize the functioning of today’s legal systems. In such a world, lawmakers would need to significantly harden the process of legislation, for example by leveraging advanced AI themselves.
Still in its early stages, but definitely something that’s coming.
3% of ‘critical’ software security bugs, in all of recorded history, have been found in the last month. This is on pace to find another ~100,000 bugs this year alone, adding ~26% more vulnerabilities to the all time total Do you realize how fucking insane that is?
One Civic owner purchased a cheap aftermarket head unit off Amazon, and decided to have Claude work its magic on it, like it would a smart TV. What was reportedly discovered isn’t surprising, but is worth knowing about.
Among the pre-installed bloatware—or spyware, if you’re being less charitable—was a voice assistant equipped with WebView, an Android system component that lets apps display content off the web. This apparently always used about a third of processing power, even while idle, which isn’t great. There were also Baidu location services, a call recorder (!), a DAB radio client that is pretty much useless in the U.S., and Adobe Acrobat, presumably so your passenger can entertain themselves with PDFs on the go.
It’s interesting because it exposes all the insecurities in this piece of IoT software. But I think the real story is that a random person was able to do this reverse-engineering with the help of AI. Expect a lot more stories like this in the future.
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.
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.
The system is designed on the assumption that it will be attacked.
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).
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.
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.
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.
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.
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.
“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.
This week, Axios reported that major US banks were detecting third-party AI agents operating inside customer accounts. In many cases, customers have given the agents their usernames and passwords so they could act on their behalf. This kind of access can violate a bank’s rules.
“Are you protecting me, or are you protecting your own profits?”
Bianco described traditional finance’s business model as “based on laziness.” Customers may leave idle cash in low- or no-interest bank accounts rather than move it into a money market fund. An AI agent could make that move for them. “Now that you’re able to do it, the banks are afraid they’re gonna lose that revenue stream,” he said.
The banks offer a different explanation. JPMorgan Chase CEO Jamie Dimon said the bank wouldn’t allow just any outside agent into its systems because doing so was “too risky for clients and for JPMorgan.”
Both explanations can be true: banks can want to retain deposits while also facing real security problems when software acts through customers’ accounts.
Handing over your banking login introduces another service into the security chain. A vulnerability in that service could expose your credentials or allow your account to be misused. And as Bank of America reportedly pointed out:
“If you do share your credentials, keep in mind that you’re responsible for activity resulting from that access.”
That’s the bank’s stated position, not a universal ruling on consumers’ legal rights. Still, it’s a warning worth taking seriously.
Pros and cons
An AI agent with permission to make purchases might find and buy an item at a lower price. But giving an agent access to your bank account also means sharing sensitive banking information with a third party. We’ve seen shared AI chats become searchable online too.
Axios reported that many banks allow, or are moving toward allowing, read-only access. This can let a tool analyze transactions without giving it permission to move money.
That’s an important boundary, but it doesn’t make the information harmless. An agent that can read bank statements may still disclose them if it’s compromised or manipulated. Preventing transactions and protecting confidentiality are separate security goals.
How to keep control of your money
For consumers, the practical question is not whether banks have perfectly selfless motives. It’s what access you’re giving away, and what could happen if the agent makes a mistake.
Don’t paste banking passwords or security codes into a general-purpose AI assistant. Major banks have explicitly warned customers against sharing their credentials.
Use your bank’s approved connection methods rather than giving an agent your login. Where supported, choose read-only access if all you need is analysis or budgeting help.
Give agents access to as little sensitive information as possible. An assistant comparing publicly advertised savings rates doesn’t need your bank statements. OpenAI recommends limiting agents to the data and credentials they need for the task.
Review consequential actions yourself. If an agent asks for confirmation, check exactly what it intends to do and what information it will share. Don’t treat a confirmation prompt as a formality.
AI can make it easier to compare financial products and spot opportunities you might otherwise miss. But an assistant that finds a better rate and an agent that can act inside your account are different propositions.
Let it help with the homework, but be cautious about handing it the keys.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
On October 27, Google issued a new Stable channel update for Chrome.
Most users are on Chrome’s Stable channel. The desktop update brings Chrome to versions 156.0.8078.73/.74 for Windows and Mac and 156.0.8078.73 for Linux. The update includes 52 security fixes, including four rated Critical.
On the same day, Mozilla issued Security Advisory 2026-118, which fixes 167 vulnerabilities. Firefox 159 also introduces several new features.
Both updates will roll out over the coming days and weeks.
How to update Chrome
The easiest option is to allow Chrome to update automatically. But you can end up lagging behind on updates if you never close your browser or if something goes wrong, such as an extension preventing the update.
If you don’t want to wait for the rollout to reach you, manually updating is easy. Open About Google Chrome from Chrome’s settings or Help menu. Chrome will check for updates. If one is available, click Relaunch to apply it.
To update Firefox, open the browser and click the menu button at the right side of the Firefox toolbar, then go to Help and select About Firefox. The About Mozilla Firefox window will open.
Firefox will automatically check for updates. If one is available, it will be downloaded. Once done, you’ll be prompted to click Relaunch. After Firefox restarts, it will be up to date.
After the update, the version should be 159.0 or later
Technical details
These Chrome and Firefox updates address a familiar problem: browser code mishandling memory while processing web content. Both releases fix use-after-free vulnerabilities, including flaws in page layout, JavaScript processing, and SVG graphics.
A use-after-free vulnerability occurs when a program attempts to access a memory location after it has been freed. That can cause crashes or, in some cases, allow an attacker to run their own code.
There’s another connection between these updates: both Google and Mozilla credit OpenAI Codex Security with finding bugs fixed in these releases. AI can help security teams examine browser code for weaknesses, alongside human code reviews and automated tests that check how software handles unexpected inputs.
Mozilla’s collaboration with Anthropic shows how AI-discovered findings can lead to fixes: researchers validated vulnerabilities before reporting them, giving Mozilla’s team reproducible bugs to investigate, repair, and deliver to users.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
On October 27, Google issued a new Stable channel update for Chrome.
Most users are on Chrome’s Stable channel. The desktop update brings Chrome to versions 156.0.8078.73/.74 for Windows and Mac and 156.0.8078.73 for Linux. The update includes 52 security fixes, including four rated Critical.
On the same day, Mozilla issued Security Advisory 2026-118, which fixes 167 vulnerabilities. Firefox 159 also introduces several new features.
Both updates will roll out over the coming days and weeks.
How to update Chrome
The easiest option is to allow Chrome to update automatically. But you can end up lagging behind on updates if you never close your browser or if something goes wrong, such as an extension preventing the update.
If you don’t want to wait for the rollout to reach you, manually updating is easy. Open About Google Chrome from Chrome’s settings or Help menu. Chrome will check for updates. If one is available, click Relaunch to apply it.
To update Firefox, open the browser and click the menu button at the right side of the Firefox toolbar, then go to Help and select About Firefox. The About Mozilla Firefox window will open.
Firefox will automatically check for updates. If one is available, it will be downloaded. Once done, you’ll be prompted to click Relaunch. After Firefox restarts, it will be up to date.
After the update, the version should be 159.0 or later
Technical details
These Chrome and Firefox updates address a familiar problem: browser code mishandling memory while processing web content. Both releases fix use-after-free vulnerabilities, including flaws in page layout, JavaScript processing, and SVG graphics.
A use-after-free vulnerability occurs when a program attempts to access a memory location after it has been freed. That can cause crashes or, in some cases, allow an attacker to run their own code.
There’s another connection between these updates: both Google and Mozilla credit OpenAI Codex Security with finding bugs fixed in these releases. AI can help security teams examine browser code for weaknesses, alongside human code reviews and automated tests that check how software handles unexpected inputs.
Mozilla’s collaboration with Anthropic shows how AI-discovered findings can lead to fixes: researchers validated vulnerabilities before reporting them, giving Mozilla’s team reproducible bugs to investigate, repair, and deliver to users.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
Login
