Threat
How AI Agents Turned One Exposed Endpoint into a Server Takeover | Threat Spotlight
Publication date unknown · Discovered reliaquest.com
Page published · Page updated
Publication date unknown · First observed: 20 Oct 2026
Coverage timeline
Single-source incident — one report is available.
Why it matters
The reported agent-driven server compromise demonstrates how exposed job-management endpoints can enable sustained, adaptive intrusions, reinforcing the importance of authentication and retained job-history logs.
ReliaQuest reports that an attacker executed hundreds of commands through an exposed application feature, stole credentials, and gained administrative control of a server in under 24 hours. Investigators identified the legitimate open-source Cairn agent-orchestration platform on the attack-origin IP and assessed with high confidence that LLM-driven agents performed substantial portions of the intrusion, although the model and degree of human oversight remained unknown.
Summary
ReliaQuest reports a server compromise completed in under 24 hours through a single internet-facing job-submission feature that required no login. The attacker used the application's intended task-execution capabilities to run code, recover plaintext database credentials, and progress to SYSTEM-level access. The report attributes initial access to an exposed, misconfigured feature—not a zero-day or a newly identified software vulnerability—and identifies no named threat actor.[0]
The distinctive finding is ReliaQuest's high-confidence assessment that LLM-driven agents performed substantial portions of the operation. An identifiable Cairn orchestration dashboard was exposed on the same address that submitted the opening malicious jobs. That infrastructure evidence, combined with rapid submissions, machine-readable output, state tracking, and error-specific revisions, supports the assessment. It does not establish the underlying model, agent count, or degree of human approval; the report explicitly leaves those questions unresolved.[0]
The technical chain began in a Tomcat-hosted application using Spring Batch. Attacker-submitted jobs invoked Nashorn inside the application process and returned results through deliberately generated errors, with larger results retrieved in 1,800-byte chunks. Configuration-file credentials granted SQL Server sysadmin rights; enabling xp_cmdshell then exposed operating-system execution under the database service account. The attacker subsequently exploited an available impersonation privilege, saved credential-bearing registry hives, and created local administrator backdoors.[0]
The principal defensive lesson is the importance of application-layer containment and evidence. Early execution produced no child processes, while application job history survived the attacker's file cleanup. Submission and collection also used different addresses, limiting the value of blocking only the initial source. The supplied evidence consists of one incident report, so the incident details and AI assessment remain single-source rather than independently corroborated findings.[0]
Attack chain
- 1. Pre-incident scanning and preparation: The second infrastructure host, 204.194.54.240, contacted the environment before the incident and exposed an open directory containing escalation tools, source directories, and encoded delivery copies. The attack-origin host also held exploitation material matching the target's technology class before first contact. ReliaQuest interprets this as preparation preceding target selection.[0]
- 2. Unauthenticated job submission: The attacker submitted malicious tasks to an internet-facing application feature without logging in. Early probes confirmed file-write access within application folders, but the decisive capability was the ability to submit tasks that invoked code inside the application.[0]
- 3. In-process execution and result retrieval: Tasks invoked Nashorn JavaScript with the application's account privileges. Deliberately triggered errors returned command results, and sequential jobs retrieved larger output in fixed 1,800-byte slices. The report identifies 94.177.131.113 as a separate address that retrieved job output in bulk and sent requests to the upload endpoint.[0]
- 4. Credential recovery and database-to-OS execution: The attacker read application configuration files and recovered plaintext credentials with SQL Server sysadmin rights. They enabled xp_cmdshell to execute operating-system commands as the database service account, bridging database access to host execution.[0]
- 5. Privilege discovery and tool delivery: A privilege check identified SeImpersonatePrivilege. The attacker prepared both PrintSpoofer and GodPotato as escalation options, uploaded base64-encoded fragments through the command channel, and reassembled the tools on the host.[0]
- 6. SYSTEM escalation: Repeated file-permission errors affected placement of the first escalation tool. The attacker switched to the second prepared tool and obtained SYSTEM access, illustrating a fallback that had been staged before the initial attempt.[0]
- 7. Credential-material collection: With SYSTEM access, the attacker saved the SAM, SYSTEM, and SECURITY registry hives. These copies enabled offline extraction of local account password hashes and other stored credential material; the report does not establish that the offline extraction itself was observed.[0]
- 8. Backdoor accounts and incomplete cleanup: The attacker created two local administrator accounts, removed artifacts, and disabled xp_cmdshell. Only one backdoor account was deleted, leaving the other in place. The original application access path remained open, and application job records survived the file cleanup.[0]
Disclosure timeline
| Date | Event |
|---|---|
| 2026-10-07 | ReliaQuest published its incident analysis, including the AI-agent assessment, infrastructure roles, exploitation sequence, indicators, and defensive recommendations. The report does not disclose calendar dates for the intrusion or incident response.[0] |
How it works
The initial weakness was exposure of an execution-capable management feature without authentication. The application used Spring Batch task definitions to identify code to execute. That flexibility was intended functionality; allowing unauthenticated internet users to exercise it was the reported misconfiguration. The evidence does not establish a product-wide Tomcat or Spring Batch vulnerability.[0]
Nashorn supplied an in-process execution path. Attacker-controlled JavaScript ran inside the application's Java environment under the application account, without creating a child process during this initial activity. This explains why process-creation telemetry alone would have missed the early execution until a shell was later spawned.[0]
The application error channel doubled as a result-retrieval channel. The attacker deliberately generated exceptions containing output and used primary and fallback read methods. Fixed 1,800-byte reads, byte-offset job names, and sequential requests allowed larger results to be reconstructed despite the response-size constraint. ReliaQuest attributes the chunk size to channel limits rather than demonstrated evasion.[0]
Plaintext credentials in application configuration extended the compromise into SQL Server. Their sysadmin privileges allowed the attacker to enable xp_cmdshell, which executed operating-system commands as the database service account. Database administrative access and host execution were therefore separate steps connected by this feature.[0]
The database service account exposed SeImpersonatePrivilege. PrintSpoofer and GodPotato were selected because both abuse that privilege to reach SYSTEM. The attacker delivered encoded tool fragments through the existing application channel and used certutil to reconstruct executables, then changed tools after placement failures.[0]
The adaptive execution patterns are not a vulnerability or a reliable product fingerprint. ReliaQuest found that Cairn's source did not implement the observed wrappers, identifiers, or chunking conventions. Those could have originated in generated code, operator scripts, or another customization layer, so host artifacts alone cannot attribute execution to Cairn.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| Observed Tomcat-hosted application using Spring Batch and Nashorn | The incident deployment exposed a job-submission feature that accepted and executed task descriptions without authentication. The application product name and component version numbers are not supplied; the evidence does not establish a broader affected-version range. | No vendor patch or fixed version is identified. The reported corrective measures are to require authentication and appropriate authorization and restrict exposure of job-submission, batch-configuration, and administrative endpoints.[0] |
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| ip | 204.194.55.189 | Source of requests creating malicious application jobs. The address also exposed a Cairn orchestration interface and exploit-staging material. Service availability was observed at particular points in time and may have changed.[0] |
| ip | 204.194.54.240 | Sent traffic to the environment before the incident and exposed an open directory with escalation-tool filenames matching target activity. Other AI-related services were observed here, but their participation in the attack was not established.[0] |
| ip | 94.177.131.113 | Retrieved job output in bulk and sent POST requests to the upload endpoint. The report describes a possible relay role as unconfirmed.[0] |
| file-path | /var/tmp/.x/ | Reported dot-prefixed directory holding attacker shell scripts and a private runtime.[0] |
| file-path | /var/tmp/kvragent | Reported binary dropped on the server and used for scanning; no corresponding file hash is supplied.[0] |
| file-path | C:\Windows\Temp\ps.b64 | PrintSpoofer delivery artifact assembled from base64 fragments uploaded through the command channel.[0] |
| file-path | C:\Windows\Temp\ps.exe | Reported PrintSpoofer executable reconstructed from the encoded upload with certutil.[0] |
| file-path | C:\Windows\Temp\gp.b64 | GodPotato delivery artifact assembled from base64 fragments uploaded through the command channel.[0] |
| file-path | C:\Users\Public\g.exe | Reported GodPotato executable reconstructed from the encoded upload with certutil.[0] |
Key takeaways
- The exploited condition was an unauthenticated execution feature, not a demonstrated new vulnerability in Tomcat, Spring Batch, or Nashorn. Remediation should target endpoint access and service privileges rather than an unsupported affected-version assumption.[0]
- The AI-agent conclusion is a high-confidence assessment by the reporting organization, not independently established attribution. The orchestration panel strengthens the inference, but neither command timing nor generated-looking artifacts alone identifies an LLM, its vendor, or human oversight.[0]
- Application job history was both the attacker's execution substrate and the defender's most durable evidence. Treating it as security telemetry closes a visibility gap left by process- and file-centered detection.[0]
- The compromise chained ordinary capabilities: exposed job execution, readable credentials, SQL administrative rights, operating-system command execution, and an impersonation privilege. The reported novelty was sustained adaptive orchestration above those techniques, not a novel exploit primitive.[0]
Defensive actions
- Inventory internet-reachable job-submission, batch-configuration, and administrative endpoints; require authentication and appropriate authorization and restrict their exposure.: The entire incident depended on unauthenticated access to an execution-capable application feature. Closing that access addresses the reported initial weakness without assuming a software patch exists.[0]
- Retain job definitions, execution and step history, exceptions, and exit descriptions alongside web, database, and endpoint logs.: The attacker used job execution and error descriptions as the command channel. These application records survived deletion of file artifacts and were necessary to reconstruct activity that initially produced no child processes.[0]
- Hunt for unusual job volume and sequential identifiers in combination with unexpected Nashorn execution and output embedded in errors or exit descriptions.: The incident combined fixed-offset retrieval, ordered upload parts, and unusual script-engine errors. Timing is a supporting signal, not a standalone detector of compromise or AI involvement.[0]
- Automate isolation of an application server once unauthorized script-engine execution is confirmed, while preserving its job history.: The report describes extended periods of new attacker actions every few seconds and recommends isolation to cut the application command channel. Waiting for later file or process evidence would miss much of the initial activity.[0]
- Rotate exposed configuration-file credentials, then migrate them to a secrets store or managed identity and reduce excessive database privileges.: A single plaintext credential set granted SQL Server sysadmin access. Rotation alone leaves the replacement exposed to the same file-read capability, while excessive privilege enabled the transition to operating-system execution.[0]
- Review database and host telemetry for xp_cmdshell enablement, privilege enumeration, encoded escalation-tool delivery, certutil reconstruction, and registry-hive saves.: These activities formed the observed transition from database administration to SYSTEM access and credential-material collection. The report recommends monitoring escalation activity rather than depending only on signatures for widely known tools.[0]
- Block the reported attacker addresses where appropriate and investigate submission, staging, and collection traffic as separate roles.: The address retrieving output differed from the address submitting malicious jobs. Blocking only the exploitation source would not have stopped retrieval through the separate collection address.[0]
- Identify and remove unauthorized local administrator accounts, and verify that cleanup has not been mistaken for containment.: The attacker deleted only one of two created backdoor accounts, left the original application access path open, and disabled xp_cmdshell after completing other actions. Reduced visible activity therefore did not demonstrate removal of access.[0]