AI Across the Intrusion Lifecycle

Case 1: A suspected ransomware operator using Claude Code

In late June 2026, we observed a suspected ransomware operator using Claude Code across intrusions into six organizations. We also linked the actor to two earlier compromises.

The victims include an energy utility in Australia, a financial services firm in Mauritius, a food service company in South Africa, a manufacturer in Thailand, an IT services company in Malaysia, and a property manager, a manufacturer, and a distributor in the United States.

We attribute this activity with medium confidence to a threat actor using The Gentlemen ransomware-as-a-service (RaaS). This assessment is based on one victim appearing on The Gentlemen leak site a month after the compromise, overlap with a /24 IP range attributed by Hunt.io, and the actor’s interest in the victims’ backup infrastructure.

The attacker used Claude Code to generate and execute reconnaissance and exploitation commands, write malicious scripts, modify firewall policies, and analyze business systems to identify those most relevant to the operation.

The attacker used Claude Sonnet 4.6 rather than a frontier model. Likely because frontier models are more constrained by safety guardrails. Regardless, an open-weight model could replace Sonnet with comparable or better results, as we have observed in similar operations.

We recovered the conversations below from the attacker’s server. They were originally in Russian and have been translated into English in the images below.

Intrusion playbook

The intrusions we observed mostly followed the steps below, though not every step appeared in every case:

1. VPN appliance admin access. The operator told Claude Code to check connectivity to the appliance’s management interface, exposed to the internet, using credentials obtained earlier. Claude then built curl calls, authenticated against /logincheck, and fixed its own errors as it went. When a login returned 0 (wrong password), it retried other credential variants and URL-encoded the secret. When an endpoint returned a 404/405, it probed alternative API paths until one worked.

Sometimes Claude refused. Below, after the appliance’s response showed a live production system belonging to an organization, Claude declined to continue the intrusion without confirmed authorization.

The attacker started a new session, told Claude it was authorized to test the target for vulnerabilities, and re-issued the task. This time Claude complied.

2. LDAP pass-back attack. The operator asked Claude to steal the firewall’s stored LDAP service account. Claude edited the VPN settings so that the firewall would check logins against the operator’s machine instead of the company’s domain controllers. It wrote a Python LDAP listener on the fly and ran it on port 389 of the attacker machine. It then tried several methods to force the firewall to bind: FSSO group refresh, SSL-VPN login attempt, diagnose test authserver. The last one made the FortiGate connect to the listener and send its service-account password in cleartext. Claude then restored the original LDAP address.

3. VPN backdoor. The operator had Claude create a VPN user named test with the same fixed password as in all the other incidents. Claude enabled SSL-VPN where it was disabled, and on some targets added firewall policies to expose additional internal subnets to the VPN.

4. Reconnaissance and lateral movement. With domain credentials and VPN access, the operator had Claude run crackmapexec or nxc across the internal subnets to map hosts, test the stolen credentials, and enumerate shares and local accounts. Usually the operator pasted a command or described the task and asked for a “short report”. Claude ran the command, read the raw output, and produced a recommendation: which hosts the credential gave admin on, and which machines – domain controllers, file servers, backup servers – to pivot to next.

5. Application and backup analysis. In several intrusions, the operator had Claude map the victim’s application databases and backups.

For the backups, Claude first searched the server’s Program Files directories for the names of backup products. On one victim’s domain controller this returned Windows Server Backup. Claude then pulled the backup scheduled task, read the backup policy from the registry, looked for where the backup images were written, read the backup logs, and ran wbadmin get versions to list the backups and their target.

On another victim, the operator told Claude to map the databases behind a financial services platform. Claude listed the SQL backup files and the live database files on two SQL servers, and when the operator asked which mattered most, ranked them and pointed to the live production database and the client document store.

Below is a snippet of the analysis.

On request, Claude ran the SQL Server BACKUP DATABASE command on both servers and staged two compressed dumps for exfiltration.

6. Exfiltration. The attacker exfiltrated one of the staged dumps. Claude mounted the C$ share, copied the .bak to the operator’s machine, and then deleted it from the server.

Firewall outage

At the utility, Claude tried to change its portal settings through the API. Those calls failed, so it downloaded the device’s configuration, edited it locally, and uploaded it back through /api/v2/monitor/system/config/restore. The device returned success, then went unreachable on all ports. Claude’s account of it, once the operator noticed the web interface was down: “a partial restore couldn’t change the portal settings, so I tried restoring the entire VDOM config with edits.” An hour later, the firewall was still down: “Yeah, I screwed up – I shouldn’t have done a full config restore.”

External scans show that the device was indeed last seen on June 23 (presumably taken down first by the malfunction the config restore caused, and kept off the internet afterward by removing the management port from public exposure).

Indicators of compromise

Case 2: Zerofot - Internet wide credential harvesting and cloud lateral movement

A Chinese-speaking operator runs a credential harvester against unintentionally exposed sensitive files and open directories across the internet, collecting keys and tokens for AI providers, cloud services, servers, and SaaS platforms. Valid AI keys feed an API-reselling gateway, and stolen cloud keys drive lateral movement into victim environments.

auto_scan - a bespoke scanner-harvester

The operation’s main tool is auto_scan, a scanner and credential harvester. The scanner queries FOFA (an internet scanner similar to Shodan and Censys) using hardcoded queries that identify potentially sensitive files exposed on the internet. It can also ingest a list of IP and port targets produced by masscan scans run by the attacker’s worker servers.

For each host it reaches, the scanner probes a fixed list of paths for config files and other files that may hold secrets. Where a host returns a directory listing, it also crawls the directory tree and downloads available files.

The operator’s guidance file to the assistant lists example searches, later hardcoded into the scanner:

After collection, the scanner searches downloaded content with a regex and validates candidates live against the matching provider: AI vendors (Anthropic, AWS Bedrock, Azure OpenAI, Google Gemini, Vertex AI, OpenAI, OpenRouter, HuggingFace, Replicate) and non-AI services (AWS, GitHub, GitLab, Stripe, Slack, Sentry, Docker Hub), along with SSH private keys. For each live key it records the usage tier and, for AWS, the account and IAM user it belongs to.

The operator built auto_scan with OpenAI Codex and Claude Code. Below is an excerpt of the instruction files given to Codex, tasking it with adding a masscan targeting mode. The brief describes the work as “for an authorized CTF sandbox” so the model does not refuse the task.

In the final stage, valid keys are uploaded to llde[.]tech, an AI API gateway that resells access to AI models. The website was taken offline during the writing of this report.

Claude Code and OMC for DevOps and IT

The operator ran Claude Code with oh-my-claudecode (OMC), a public multi-agent orchestration framework installed as a Claude Code plugin. Claude Code was configured to route through the operator’s own llde[.]tech gateway rather than Anthropic (via ANTHROPIC_BASE_URL), the same gateway the operation stocks with stolen keys, so the model answering behind the CLI may or may not have been operated by Anthropic.

Through OMC, Claude Code handled the operation’s IT and DevOps work: standing up and restarting the scanner and its proxy stack, wiring up outbound proxies, and monitoring and debugging the live harvester.

For example, OMC was tasked with bringing up the scanner-and-proxy stack, and stopping it when the scanner risked leaking its real IP. Other jobs included refreshing the pool of proxy exit nodes it pulled from a Chinese commercial proxy service (赔钱[.]com, Punycode xn--cp3a081l[.]com), checking that traffic still egressed through the proxy and logging the current exit IP and route, managing the host firewall so certain ports bypassed the proxy tunnel, and vetting a candidate proxy project to serve as the scanner’s outbound exit.

Exploitation scripts

deep_lateral2.py is a single-use, poorly written script for AWS discovery and privilege escalation. It has hardcoded AWS access keys for accounts the operator had already compromised, and uses them to look through managed services – CI/CD pipelines, batch and machine-learning jobs, EC2 instance user-data, and configuration stores – for more embedded keys. It also attempts cross-account role assumption and access-key creation, but the logic and implementation are crude and unreliable.

Notably, and as we often see when AI is tricked into writing malicious code under the guise of red teaming or penetration testing, the AssumeRole call names its session recon, a label that gives the attack away.

jenkins_scanner.py targets internet-exposed Jenkins servers. It takes a list of IPs, confirms each runs Jenkins, and tries anonymous access or a list of weak username and password pairs. On an authenticated session it uses Jenkins’ Script Console to run a Groovy payload that harvests cloud and AI credentials from the host and validates the AWS keys it finds. When the login attempts fail, it falls back to file read through CVE-2024-23897 against hardcoded paths, though a bug in that branch of the recovered version stops it from running.

Sliver C2

Occasionally the operator deployed Sliver C2 implants on compromised hosts. On them, the operator ran commands to look for application config files and stored credentials, and connected to databases reachable from the host.

For example, on the compromised host cPanel-External-Backups-01, the operator tried the AWS instance metadata endpoint (which would have returned nothing useful, since the host is a DigitalOcean droplet, not an EC2 instance). The operator then searched for wp-config.php, .env, and config.php in the home directory, and for .conf and .cfg files in /var/cpanel, grepped for credentials and keys in environment variables, searched for a file called stealer_logs.rar (we do not know the origin of this file), and listed the /backup folder and the mounted volume at /mnt/volume_lon1_03/.

On another host, kafka-1, the operator read the kafka.properties file from within a Docker container and on the host, and checked connectivity to hosts on two internal subnets for Postgres and MySQL.

On a third host, running as root, the attacker used mysql with a username and password obtained earlier to connect to AWS RDS databases and list the available tables.

Breakdown of the harvested credentials

Between April 5 and May 23, 2026, the operation collected 2,975 validated keys and credentials from 1,742 victim hosts (3,528 keys across 1,956 hosts counting the ones that were invalid, expired, or out of quota when the scanner checked them):

The chart shows valid keys collected per day, by provider.

Victim notification

We have shared the information with the Shadowserver Foundation, and we thank them for their help with victim notification. We also disclosed affected keys to the most affected cloud and SaaS providers for revocation and customer notification.

Indicators of compromise

Case 3: RAGE - exploitation framework for cryptominer deployment

RAGE is a custom Python framework designed to scan exposed internet services, exploit vulnerable deployments, harvest credentials, and deploy cryptocurrency miners. While the operators appeared primarily focused on deploying cryptominers, we also observed dedicated modules and one-off scripts used for cloud environment exploitation after initial access.

AI-assisted development

RAGE and many of the accompanying scripts appear to have been generated with AI. Many preserve the model’s own first-person, self-correcting reasoning inside comments and docstrings, with lines such as “Wait, we already know this host can’t write…” or headings that evolve from “THE BREAKTHROUGH” into “REAL BREAKTHROUGH” a few lines later.

Separately, the framework integrates an LLM at runtime. The operator dashboard embeds a DeepSeek-backed “AI Orchestrator” that advises on running the mining botnet.

Modules

The framework supports scanning, exploitation, brute-force authentication, cloud metadata access, host-level privilege escalation, miner deployment, monitoring, and HVNC orchestration, and includes a web dashboard.

RAGE includes the following exploitation modules:

• Redis - targets unauthenticated instances exposed on port 6379. It attempts remote code execution by injecting a cron job through CONFIG SET, writing an attacker-controlled SSH key to authorized_keys, or loading a malicious module through rogue-replica replication. Before deploying XMRig, it searches the Redis keyspace for AWS credentials and other secrets.
• Elasticsearch - targets unauthenticated instances and recursively queries indexed documents for AWS keys, secrets, database URLs, and API tokens. Against legacy versions, it attempts remote code execution through a Groovy scripting sandbox bypass.
• Docker - targets unauthenticated Docker APIs exposed on port 2375. It attempts remote code execution by launching a new alpine container that downloads and runs XMRig or, when container creation is blocked, by executing the same miner-download command inside the first few containers already running on the host. It also scans containers for secrets and mounts the host filesystem to obtain host-level access.
• Tomcat - brute-forces weak or default credentials for exposed Manager applications. After a successful login, it deploys a malicious WAR file hosted on attacker infrastructure to run XMRig on the host.
• Additional services - other modules target Jenkins, Hadoop YARN, Confluence, and Supervisord.

Cloud exploitation

In one case, the actor recovered an AWS access key ID and secret from an exposed Redis instance belonging to a SaaS provider. Although the key appeared to be associated with an S3-backed application, it granted administrative access to the AWS account, allowing the actor to enumerate IAM identities and cloud resources across the control plane.

The actor generated a post-exploitation script, aws_deep_hunter.py, with the harvested AWS credentials hardcoded. The script enumerates IAM users, retrieves their inline and attached policies, and generates a new access key for each user. It then lists IAM roles and attempts to assume them. As with the Zerofot campaign, the hardcoded STS session name is overly descriptive: where Zerofot named its session recon, RAGE uses rage-session.

The script then enumerates S3 buckets and their contents, filtering for objects between 10 bytes and 1 MB whose extensions suggest configuration, source code, or credential material: .env, .json, .sql, .pem, and .key. Matching objects are downloaded and searched for credentials and cryptographic keys.

Then, it uses all available credentials to query the following services: S3, Secrets Manager, SSM Parameter Store, IAM, CloudFormation, Lambda, ECS, RDS, and DynamoDB (CodeBuild and CodeCommit are referenced in the script header but are never implemented), as can be seen below:

Where permissions allow, the script retrieves Secrets Manager values, decrypts SSM parameters, and collects Lambda environment variables, ECS task-definition values, CloudFormation parameters and outputs, RDS snapshot metadata, and DynamoDB items.

Finally, any access keys it created through iam.create_access_key() feed back into the workflow, so each newly minted key becomes another starting point for IAM enumeration and S3 collection.

Recovered log output confirms the actor had live access to the SaaS provider’s AWS account. Although the log appears to originate from a previously executed script that we did not recover, it recorded the enumeration of eight IAM users and their attached policies. Four users held AdministratorAccess. The same execution enumerated 196 S3 buckets along with several additional AWS resources that were empty or inactive.

Indicators of compromise