Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia

Disclosure note: Hunt.io disclosed these findings under TLP:AMBER to the relevant national CERTs for the affected jurisdictions and, following responsible disclosure, held publication until September 3, 2026.

In July, we published research on a Chinese-speaking operator who embedded Claude Code and DeepSeek into intrusions across four countries. This is a second, separate campaign with different infrastructure, tooling, and targets, but the same pattern: commercial AI models used as operational components. Targets included Taiwan's Kuomintang Party History Archives, Indonesia's Ministry of Foreign Affairs, government and education systems in mainland China, and industrial hosts in Da Nang, Vietnam.

The most extensive compromise hit a Fengtai District government environment, where the operator achieved command execution, collected LSASS and registry hives, accessed government and health records, and deployed multiple Windows implants. Separate activity exposed a Chinese education AI platform and obtained root database access to a university campus-card system.

SecFlow coordinated reconnaissance, exploitation, and reporting across Claude, Qwen, and DeepSeek workers. We connected five exposed workspaces by pivoting on a shared SOCKS endpoint, which surfaced in 120 file-content matches alongside common SecFlow and GLUTTON artifacts, reused accounts, and a direct second-stage payload link.

Below are the key findings from this investigation.

• Five open directories, one campaign. The exposed directories map to an AI orchestration host, a Java/CAS exploitation workspace, a fake MySQL deserialization service, a Shellshock and credential-testing node, and a payload-distribution store.

• AI workers with swappable models. SecFlow split reconnaissance, exploitation, collection, and reporting among specialist workers. The runtime could switch between Claude, Qwen, and DeepSeek profiles without changing the task interface.

• Operator infrastructure under one handle. Private niestools.com endpoints proxied model traffic while target-facing requests used authenticated SOCKS relays. The username Nie appears across the model-service namespace and proxy accounts.

• Fake MySQL as an initial access vector. The service selected serialized Java objects from the connecting username and directed vulnerable clients to a Linux second stage on 129.211.184[.]149. Delivery logs tie the two workspaces directly.

• Eight CVEs in active workflows. Shellshock, Spring4Shell, Ghostcat, Shiro deserialization, Log4Shell, Grafana and Nexus path traversals, and a Nacos authentication bypass.

• AI amplified a false positive. An unsupported Shiro success claim carried into later tasks. More than 27 follow-up tests failed, yet workers continued receiving GLUTTON assignments based on the earlier claim.

• Confirmed compromises. Fengtai command execution and credential collection, education AI-platform data access, and root database plus Grafana admin access to a university campus-card environment.

Identifying the cluster

This campaign was discovered by inspecting the below open directory on 152.42.200[.]25, cloned on the 24th July 2026:

The Hunt.io Attack Report on the open directory 152.42.200[.]25:9999 assessed an actor primarily targeting Taiwanese and Indonesian government systems with multiple attempted initial access methods:

We observed a payload designed to target the KMT party archives with a Shellshock vulnerability. This script contained the SOCKS proxy IP address 103.45.65[.]93:35888:

An exact code and file-content search on our platform returned 120 matches across five indexed hosts:

Across these five workspaces, the campaign touched six countries and nearly a dozen sectors.

AI-powered intrusions

SecFlow connected short objectives to tool-using workers, a shared filesystem, target configuration, proxy routing, and a report pipeline. The AI component organized the work. The exploitation itself still depended on conventional scripts, public proof-of-concept code, leaked credentials, webshells, and custom implants.

The workspace on 81.70.240[.]170 preserved Claude, Qwen, and SecFlow state alongside target files, session history, generated evidence, and a versioned offensive skill. This gave later workers access to earlier discoveries and allowed one target to branch into several specialist tasks.

SecFlow workers and runtime wrappers

SecFlow, the operator's AI orchestration framework, converted campaign objectives into tasks for specialized AI agents and supplied them with tools, target information, shared storage, and network routes.

The runtime configuration exposed five model profiles. SecFlow launched either Claude ACP or Qwen Code, injected a model name and API route, and applied broad tool permissions. Private Claude and DeepSeek-compatible endpoints under niestools.com sat beside official provider routes.

Prompting, skills, and MCPs

The External Pentest Skill acted as a master workflow. Its central policy file, SKILL.md, moved each target through initialization, reconnaissance, exploitation, post-exploitation, and reporting. Reconnaissance established the technology stack, authentication boundaries, response baselines, exposed services, and a ranked queue of possible attack paths.

The skill then routed each candidate to a vulnerability-specific playbook under references/vuln-types. These covered file upload, command execution and template injection, SQL injection, sensitive-data exposure, Java deserialization, SSRF and cloud metadata, unauthenticated services, IDOR and authentication bypass, known product vulnerabilities, supply-chain weaknesses, WAF bypass, source-code auditing, and advanced web attacks.

Each playbook defined how to test and validate its vulnerability class, while references/reporting/reflect-verify.md required control requests, reproducible results, impact evidence, and severity checks before a finding could be accepted.

Egress network routing was part of the skill's operating policy via references/tools/proxy-and-jumphost.md:

The recovered references/config/proxies.yaml designated 43.162.217.10:35888 as the primary SOCKS5 route and 103.45.65.93:35888 as the secondary route:

Webshell generation was handled by a dedicated GLUTTON capability described in references/tools/webshell.md. It could produce server components for Java, .NET Framework, .NET Core, and Node.js in formats including JSP, JSPX, ASPX, ASHX, ASMX, SOAP, Razor, and JavaScript-based loaders. Workers could select lightweight, compressed, or compatibility-focused variants and either use components stored under tools/webshell/glutton/ or request a customized payload through the GLUTTON MCP service.

GLUTTON provided traffic-concealment and code-obfuscation options. Its transport modes included XOR-encrypted data hidden inside PNG RGB channels, with the resulting image data carried as PNG, form, JSON, or XML traffic. Another mode combined XOR, compression, Base64, and JSON. Generated code could use Unicode or XML encoding, randomized identifiers, encoded strings, comment injection, invisible characters, and control-flow flattening to reduce static signatures and evade basic filtering.

The MCP integration, documented in references/tools/glutton-mcp.md, exposed payload generation and session operations to Claude while preserving the same routing policy for deployment and subsequent communication. Analysis of MCP binaries revealed functionality that was exposed to agents:

After a foothold was established, the skill shifted from vulnerability discovery to proving impact. GLUTTON could manage the remote session, execute commands, handle files, inspect memory, access application database connections, collect credentials, inject memory-resident components, and provide network forwarding. The post-exploitation workflow was defined in references/vuln-types/12-postexploit.md.

The final stages preserved requests, responses, screenshots, command output, and data samples according to references/reporting/evidence-capture.md, then converted that material into standardized reports using the rules in references/reporting/report-format.md.

With the orchestration framework, tooling, and network routing established, the following sections walk through what the operator actually achieved against specific targets, starting with the most extensive confirmed compromise.

Fengtai Government compromise

The open directory on 129.211.184[.]149:8081 contained evidence of an end-to-end compromise of a Fengtai government Office Automation (OA) environment. The intrusion progressed from public web access to Windows command execution, internal discovery, credential theft, application persistence, attempted lateral movement, data exfiltration, and remote implant deployment.

Webshells were not used only for initial command execution. They formed the operational backbone of the intrusion, giving the operator a persistent HTTP-based interface for running commands, querying databases, stealing credentials, transferring files, and launching malware.

What Was Targeted

The operator targeted a connected group of Fengtai District government systems:

• A staff-facing OA application used for administrative workflows and file management

• A related public-health application

• Internal Windows web and database servers

• Oracle and Microsoft SQL Server services

• Windows credential stores and registry hives

• The OA user-account database and attachment repository

• Government administrative records and patient-related health documents

Webshells Across the Intrusion Chain

Initial Access via Office Automation Web tier

The OA web tier was the internet-facing IIS application through which government employees accessed file-management and administrative functions.

The OA FileManage handler accepted uploaded ASPX files and returned web-accessible locations. This gave the operator a route for placing server-side tooling inside the application. Other retained pages wrote cmd.aspx into the related health-system application.

cmd.aspx accepted an HTTP parameter, passed it to cmd.exe /c, and returned the command output. Classic ASP variants used WScript.Shell.Exec for interactive output or WScript.Shell.Run for hidden execution.

Additional ASPX pages called CreateProcessW with CREATE_NO_WINDOW or invoked Win32_Process.Create through WMI.

Lateral movement from IIS to the database tier

The initial IIS server acted as a foothold for the agent to move laterally. The agent uploaded an ASPX webshell that would allow it to run SQL commands to internal Oracle or SQL services. These could be used for extraction of data, but also execution of commands.

A malicious Oracle Java class invoked the Windows command interpreter and returned both standard output and error output. A web-accessible SQL bridge forwarded encoded commands to the internal Oracle service.

Retained responses confirmed execution within a Windows Server 2012 R2-era database environment. The workspace also contained a Microsoft SQL Server route using xp_cmdshell, although the strongest command responses came from the IIS webshells and Oracle channel.

Discovery Conducted Through Webshell Access

Once the webshells produced stable command output, the operator issued a compact Windows discovery sequence:

whoami
whoami /all
echo %USERDOMAIN%\%USERNAME%
ver
hostname
tasklist
net use
sc query

                
Copy

These commands identified the operating-system version, execution identity, running processes, network mappings, services, and available staging locations.

Additional tooling enumerated scheduled tasks, startup locations, user profiles, temporary storage, and previous persistence activity. The webshells were then used to launch scripts that scanned the internal environment for SMB, WinRM, web, and database services.

Follow-up activity included DNS lookups, raw TCP probes, directory enumeration, virtual-host testing, and searches for writable webroots. This connected the public OA application to internal database servers, IIS application pools, VPN infrastructure, and other office systems.

Privilege-Escalation Attempts

The operator staged several ASPX implementations of Potato-style privilege-escalation techniques. These pages were designed to convert an IIS or service token with impersonation rights into SYSTEM-level execution.

The variants attempted coercion through Windows printing, EFSRPC, and LSARPC mechanisms. After obtaining an impersonated token, they attempted to duplicate it and launch a process using CreateProcessWithTokenW.

This demonstrates how the operator used webshells not only as command shells but also as delivery mechanisms for local privilege-escalation code.

Credential Theft Through Web-Accessible Handlers

The credential-theft evidence began in the open directory with an existing LSASS memory dump. The approximately 75.8 MB object appeared in the OA attachment repository under dump-like filenames.

The operator deployed down.aspx in a web-accessible attachment location. It accepted parameters controlling the source file, starting offset, and requested length, allowing an arbitrary file to be downloaded in sections.

A companion handler, downx.aspx, applied a bytewise XOR operation (key 0xAA) before returning the data. This provided a lightly obfuscated alternative if the direct transfer was blocked or inspected.

The operator divided the LSASS dump into 37 blocks, requested each block through an authenticated SOCKS route, verified the expected byte count, and reconstructed the complete file.

The operator also collected the SAM and SYSTEM registry hives. Another server-side page, extract.aspx, scanned sections of the memory dump for Windows password-hash material.

OA Account Access and Application Persistence

Credential collection was paired with direct access to the OA database.

sqldump.aspx queried the OA user table directly. sql6.aspx accepted encoded SQL statements and returned database rows in batches. Two retained result sets contained 500 and 322 records, producing a total of 822 OA account records.

The operator then inserted and verified a new active OA account with elevated application privileges. This created a persistence route at the application layer that was separate from the Windows webshells and implant.

Even if individual command shells were removed, the newly created OA account could potentially preserve access to administrative functions and stored information.

Data Collection and Exfiltration

The operator built several HTTP-based collection channels around the compromised OA application:

• sqldump.aspx and sql6.aspx streamed database records.

• doc_helper.aspx and doc_view_666b2dde.aspx read arbitrary files and returned Base64-encoded content.

• down.aspx supported resumable binary transfer.

• downx.aspx provided an XOR-obfuscated transfer option.

These web-accessible handlers turned the compromised OA application into an exfiltration platform. Data could be requested through ordinary HTTP traffic, returned in manageable sections, and reconstructed after transfer.

The OA inventory contained 949 attachments totaling approximately 1.28 GB.

Recovered material included:

• Government workflow and administrative information

• 822 OA account records

• Selected health-related documents

• A chronic-disease report containing patient information

• Windows credential material

Implant deployment via Webshells

The initial beachhead allowed the agent to gain command execution on the IIS server. This command-execution was used to download, stage and execute a Go-based implant we have called "SecBox":

• dl_icn.aspx - downloads hXXp://158.247.234[.]124:18000/c22.exe and writes to C:\Windows\Temp\fw.exe

• launchfw.aspx - downloads hXXp://158.247.234[.]124:18000/c22.exe and writes to C:\Windows\Temp\fw.exe then executes using Process.Start() and WMI Win32_Process.Create

Different SecBox binaries and other methods for staging were also used via various ASPX files, although we will not be covering these all for brevity.

The ASPX files were observed staging from the IP address 158.247.234[.]124. Our platform intelligence allowed us to enrich this indicator:

The "Code Search" tab revealed additional linked payloads, configurations and log files containing this IP:

SecBox implant analysis

SecBox is a privately built or customized Go remote-access and network-pivot framework. Named "SecBox" from binary strings, it was deployed via Webshells for an additional layer of endpoint control.

The Windows implants masquerade as Microsoft-style system components via the binary metadata:

C2 beaconing

On execution, SecBox selects an embedded or DDR-supplied endpoint and establishes a long-lived connection using TCP, TLS, WebSocket, KCP, or QUIC. Yamux multiplexing allows tasking, file transfer, and pivot traffic to share the same connection.

Initial registration includes a client identifier and basic host information such as operating system, architecture, and hostname. The controller can subsequently replace or clear the implant's active endpoints.

Capabilities

SecBox supports remote shell execution, task control, file upload and download, download-and-execute, process and token access, Windows service management, host discovery, TCP port scanning, SOCKS5 proxying, port forwarding, bind pivots, and self-removal. No automatic persistence mechanism was confirmed in the reviewed builds.

Dead Drop Resolver

SecBox has capabilities to leverage a Dead Drop Resolver mechanism via Pastebin or Github. It allows an implant to obtain replacement C2 routes without requiring a new binary.

The implant contains a build-specific AES key and can retrieve an encrypted routing value from a dead-drop service. The recovered DDR data uses:

Base64(nonce || AES-256-GCM ciphertext || authentication tag)

                
Copy

After authenticated decryption, the plaintext contains one or more comma-separated endpoints, for example TCP, WebSocket, or TryCloudflare routes. Different builds use different embedded DDR keys and can therefore receive separate infrastructure configurations.

The recovered ddr*.txt files are captured or test copies of hosted DDR responses. Pastebin and GitHub Gist retrieval templates are present within the SecBox binaries, but the campaign-specific public URLs were not recovered.

DDR supplied routes included:

tcp://imported-concerns-listening-typing.trycloudflare.com:443
tcp://158.247.234.124:18000
tcp://marriage-step-wave-heavy.trycloudflare.com:443
wss://wins-say-charm-social.trycloudflare.com/c2
ws://158.247.234.124:18000/

                
Copy

The Fengtai compromise was the deepest confirmed intrusion, but the campaign reached other targets through different entry points. The AI orchestrator host at 81.70.240[.]170 also contained evidence of a separate compromise.

Chinese education AI platform and related services

The open directory on 81.70.240[.]170, the AI orchestrator host, targeted a Chinese education AI platform's exposed systems enabling a confirmed compromise of its AI application-management and data layer. The exposed service was the management plane used to configure and operate production AI assistants. Its unauthenticated backend returned 23 agent configurations, 14 populated secret fields, internal service addresses and 104 complete AI dialogue records, including user prompts, model responses and execution metadata.

The exposed configurations disclosed multiple downstream AI-platform credentials, including Dify application keys, a Coze private key and platform AI credential material. The Dify credentials were then used successfully against the production Dify API. The retained collection contains 169 conversations and 339 message/query entries from topic-selection, study-partner, job-recommendation and résumé assistants. These records included educational and career-related prompts and, in 92 message entries, structured student-profile information covering two distinct students, including names, student numbers, advisers, departments, grades and majors.

The exposed credentials were also used to invoke a production model, consuming 631 tokens, and an evidence summary records a successful file upload. Separately, the unauthenticated platform backend accepted a request for a new agent configuration and returned a success response. This confirms a suspected unauthenticated configuration-write capability and creates a credible risk of AI-agent tampering, redirection of user requests, malicious downstream integrations and supply-chain abuse. However, the retained evidence does not show that the new configuration persisted or that its external URL was dereferenced; SSRF and backend code execution therefore remain unproven.

Overall, this should be described as a compromise of the platform's AI control and data plane, rather than a confirmed server takeover. Confidentiality was affected through disclosure of AI conversations, student information, application configuration and reusable credentials. Integrity was affected because the management service accepted an unauthenticated configuration write. Model invocation also demonstrates that the leaked credentials could be used to consume the organisation's AI resources.

Other exposed and targeted services

Other services on the same platform exposed substantial security-sensitive information without producing evidence of host-level execution. The portal disclosed CAS private-key material, client-side cryptographic material, test credentials and internal addresses. Retained Shiro, AJP and SSRF testing did not achieve code execution or authenticated access to protected data.

A separate Chinese online platform disclosed account-existence behaviour but did not accept a login. Huazhong Agricultural University's recruitment system appears only in logs showing proxy fallback and should not be described as compromised. Domains belonging to an English-language dating platform operator received DNS, ColdFusion, OAuth, CORS, host-header, cache and path testing. Client configuration was exposed, but the retained evidence contains no member-account access, session theft or private member data.

A separate workspace on 159.223.64[.]67 took a different approach to initial access.

Fake MySQL deserialization and Afghan enumeration

The open directory on 159.223.64[.]67 contained fakeserver_new.py which operated a malicious MySQL-compatible service on port 3306. When a vulnerable Java application connected, the service returned crafted data designed to trigger unsafe object processing within the client. In practice, this allowed the server to use an outbound database connection as an initial execution vector and launch a platform-aware downloader on the affected host.

Five payloads ran the same shell downloader. They selected a temporary path, detected Linux OS and architecture, fetched an implant from:

hxxp://129.211.184[.]149:8443/999b4e8c/public/dnc/a6d28ebe?os=<os>&arch=<arch>

                
Copy

The platform-aware downloader that queried the operator's staging endpoint using the victim's operating system and architecture. The recovered outputs associated with this infrastructure are statically linked Go Linux agents belonging to the SecBox-compatible/GO-SYSCFG family.

Separately this open-directory showed evidence of targeted enumeration of an Afghan telecommunications operator's corporate network ranges.

On the 3rd of August, the actor leveraged nmap to perform targeted scanning of whole /24 ranges and a specific IP address:

nmap -Pn -sT -T4 --max-retries 1 --host-timeout 12s -p 21,22,80,443,4899,5900,3389,8443,8990,2775,1401 -oN /tmp/svc_scan.txt <operator /24 range> <operator host>

                
Copy

The /24 range is linked to the operator's corporate network. Many IP addresses within this range resolve to subdomains used for services such as Jira, Helpdesk, VPN, and Outlook. An additional host in the same range was scanned that was linked to the operator's call-back ringtone management domain.

Notably, the nmap command specified scanning port 2775 (SMPP), a standard telecommunications protocol used to transfer SMS messages. Along with the exclusive scanning of the operator's IP ranges, this might suggest a strategic interest in Afghan telecommunications networks.

Across the campaign, SecFlow workers were directed to deploy GLUTTON webshells after gaining access. The recovered skill backup reveals how those payloads were built.

Steganographic GLUTTON webshells

The recovered skill backup contains ten server-side GLUTTON loader templates plus MethodInvoker.class. The templates cover JSPX, ASP.NET Web Forms, ASP.NET handlers, SOAP services, and .NET Core Razor. Raw variants expose the loading logic, confusion variants contain obfuscated versions, with code split across CDATA blocks and random fragments, and a Unicode JSPX variant further changes the on-disk representation to resist signature matching.

Each loader accepts a PNG in the request body, or as base64 data in the SOAP variant. It reads pixels in row-major order, concatenates the red, green, and blue channel bytes, XORs the stream with a repeating 16-byte ASCII key, and scans backward for the three-byte FF 88 00 terminator:

Across all variants, an identical XOR key "d0c41072a0dc784c" was used. Additionally, each variant would search for the byte sequence "FF 88 00" within the decoded bytes to specify where the payload ended.

Java variants define the recovered class through a new class loader. .NET variants use Assembly.Load. The loader then caches the resulting runtime object in application state, AppDomain data, or a static table.

The PNG is therefore a transport container for executable bytecode. The small web-facing page remains a generic decoder while the functional stage arrives inside image pixels and loads directly into memory. This separates the visible server file from the implant body and can bypass controls that permit image uploads or inspect only extensions and MIME types.

SecFlow assignments explicitly connected this tooling to exploitation. Workers were directed to load the GLUTTON guide, check the MCP wrapper, generate server components, and attempt memory-shell injection.

The remaining workspace on 152.42.200[.]25 contained the campaign's broadest geographic spread.

KMT, Indonesia, and the Da Nang business cluster

The open directory on 152.42.200.25 contained artefacts relating to targeting of the KMT party, Taiwanese government, Indonesian Foreign Ministry and Vietnamese organisations.

Shellshock payloads were used against the Taiwan KMT party archives domain, against the exact /gs32/kmt/index.htm path. They sent the Shellshock function prefix in the User-Agent header and tried to execute /bin/bash -c:

User-Agent: () { :;}; /bin/bash -c '<command>'

                
Copy

The script used had hardcoded post-exploitation commands designed to perform enumeration:

The script xor_bd.py acted as a webshell client, with a hardcoded URI to an Indonesian Foreign Ministry domain. This would allow the threat actor to interact with a webshell /webservice/sync_data.php, sending commands XOR encoded:

The script deploy_all.sh was designed to run on a compromised web-hosting server. It would write PHP webshells masqueraded as Wordpress files to the below URIs:

wp-content/plugins/class-wp-settings.php
wp-content/cache/cache-main.php
wp-content/uploads/maintenance-check.php
wp-includes/class-wp-l10n.php

                
Copy

All 20 deployments contained the identical webshell. Once decoded, the PHP read an encrypted command from the raw HTTP request body, decrypted it with AES-256-CBC, passed the plaintext to shell_exec() and returned encrypted command output:

Across all five workspaces, the operator tested or deployed eight named CVEs alongside several application-specific techniques.

Vulnerabilities exploited or staged

8 named CVEs were used in active workflows. The table records how the operator used each active workflow and separates a successful access path from a probe or prepared payload.

Beyond the CVEs and tooling, a recurring handle tied the campaign's infrastructure together.

Nie's infrastructure

Across the campaign, the handle "Nie" kept recurring. We discovered this cluster of open-directories as they all used a SOCKS proxy IP address 103.45.65[.]93, often with the credential Nie as the username.

From the recovered initial AI agent skills, we observed explicit tasking that would leverage this IP and credentials. The "GLUTTON" webshell MCP binaries were also hardcoded with build paths linked to this handle:

C:\Users\nie\.cargo\...
/Users/nie/Project/glutton/...

                
Copy

All "GLUTTON" MCP binaries also hardcode the domain https://glutton.niestools.com for authorization.

Furthermore, SecFlow was configured to route requests through claude.niestools[.]com and deepseek.niestools[.]com. Using our platform, we can pivot on the initial domain to discover further relevant subdomains:

We can see multiple domains, including proxy.niestools[.]com:

This is a Chinese proxy-pool management console for collecting, monitoring, filtering, and exporting HTTP and SOCKS5 IP proxies.

The domain chatgpt.niestools[.]com returns a 401 Unauthorized. We can observe from the HTTP response that this domain is running the Sub2API AI gateway:

Sub2API is an open-source AI API gateway that pools multiple upstream subscriptions or API keys and redistributes their capacity through a single endpoint. It handles authentication, billing, load balancing, rate limits, and request forwarding to providers such as OpenAI, Anthropic, and Google. Although it can be used legitimately, operators may use it to resell subscription access, conceal account sharing, or bypass regional restrictions.

With knowledge of this response, we can use HuntSQL to uncover additional IP addresses running Sub2API AI gateways:

SELECT
  ip
FROM
  httpv2
WHERE
  http.headers.bytes.content LIKE '%Sub2API Admin%'
GROUP BY
  ip

                
Copy

This specific query returned two additional IP addresses: 82.156.42[.]112 and 47.253.191[.]55. These are unrelated to this specific campaign.

MITRE ATT&CK mapping

Indicators and observables

Table 1: operator and support infrastructure

Table 2: Victim-executed file and payload indicators

Conclusion

A single SOCKS pivot expanded into five exposed open directories spanning six countries and nearly a dozen sectors. The underlying activity was connected through recurring infrastructure, shared tooling, reused accounts, and the Nie handle across proxy credentials, build paths, and the niestools.com domain family.

SecFlow made the campaign faster and broader by splitting work across specialist AI workers and carrying context between them. But that same shared context amplified a false premise when an unsupported Shiro claim persisted and drove follow-on GLUTTON assignments that never should have happened. The confirmed compromises still came down to familiar weaknesses: exposed services, unpatched applications, stolen credentials, and conventional post-exploitation tooling.

The open directories, attacker tooling, and infrastructure pivots covered in this research were discovered through our AttackCapture and Code Search capabilities. To see how these workflows apply to your own investigations, book a demo.