Web App Owners – You’re on Notice. Your Low-Hanging Fruit Just Got Lower
Web App Owners – You’re on Notice. Your Low-Hanging Fruit Just Got Lower
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
About Author
