AI-Agent-Driven Offensive Operation : Exposed Adversary Open Directory Reveals Autonomous Crypto-Theft Campaign Leading to Mass Wallet and Credential Compromise

Executive Summary

CloudSEK's Global Threat Intelligence team identified an exposed open directory belonging to a financially motivated, Chinese-speaking offensive operator who has industrialised intrusion by running a fleet of commercial and open-source AI coding agents as an autonomous hacking crew. The directory served the operator's full working home folder to the public internet, exposing the tooling, methodology, credentials, and stolen data behind two parallel campaigns: internet-wide opportunistic exploitation and targeted theft against crypto and DeFi organisations.

• Autonomous AI attack fleet: The operator drives multiple AI coding agents (Claude Code, Codex, and the open-source Hermes and pi agents) in full-auto mode with every safety approval disabled, tasking and monitoring them entirely over Telegram. Human-typed prompts recovered from the agents' own session transcripts show a reusable Chinese "authorized pentest" template used purely as a jailbreak wrapper, with no real authorization.
• Confirmed mass compromise: Working files contain over 12,000 real WordPress backdoor records (each a unique attacker-created admin account), a separate set of 66 genuinely harvested (non-backdoor) database admin credentials, and a 3.4 million host reconnaissance corpus, produced by an automated WordPress-to-webshell exploitation pipeline.
• Direct wallet-key and seed-phrase holding: The operator holds private keys, seed phrases, and live balances for hundreds of end-user cryptocurrency wallets. The bulk of this material was scraped with zero authentication from one phishing clone network's misconfigured cloud database (the users are victims of that phishing operation), while a smaller set of key material was retrieved directly from his own targets. He separately holds numerous validated live API keys and admin tokens for crypto exchanges, DeFi protocols, and blockchain infrastructure providers.
• Blockchain C2 and cryptojacking: The operator was developing an EtherHiding-style, takedown-resistant command-and-control system that hides commands on a public blockchain, and separately deploys a disguised Monero miner onto compromised hosts for ongoing illicit revenue.

Analysis

Reconstructed from file modification times, shell history, and agent session transcripts, the observed activity window runs from 10 July 2026 to 28 July 2026, peaking around 12 to 13 July.

A compressed view of the roughly three-week active window, from bulk crypto and DeFi sweeps through wallet-key consolidation to blockchain-C2 development.

• 10 to 13 July, bulk targeting: Heaviest phase of automated report generation, dozens of targeted crypto and DeFi sweeps per day, and the earliest recovered agent tasking against named targets.
• Around 13 July, mining setup: Build and test of the Monero miner, followed by pushing binaries to worker hosts.
• 16 to 20 July, mass campaign matures: The WordPress mass-exploitation pipeline scales up, alongside the strongest wallet-theft evidence from targeted trading-bot ecosystems and open cloud databases.
• 20 to 23 July, loot consolidation: Wallet private keys and seed phrases are consolidated into combined datasets, with sensitive-data scan reports produced.
• 25 to 28 July, C2 development: The blockchain command-and-control research paper and project are written, the miner is deployed, and WordPress monitoring continues. The last shell-history write is 28 July.

Discovery: An exposed operator staging host

The investigation began with an open directory served on a non-standard port of a single staging host. Directory listing was enabled and the root of the operator's home folder was browsable without authentication. Mapping the listing recovered a working environment of tens of thousands of directories and well over a hundred thousand files, including AI-agent session transcripts, configuration files, reconnaissance corpora, per-target engagement folders, and per-finding evidence with harvested credentials and stolen data.

The nature of the host was unambiguous from its contents: a blockchain-C2 development project, an autonomous-agent orchestration stack, a WordPress mass-exploitation toolkit, a deserialization RCE kit, a cryptocurrency miner, and harvested credentials from a large number of victims. Targeting skewed heavily toward crypto and DeFi organisations.

Note: All findings in this report are grounded in artifacts the operator left in his own working directory: saved API responses, exported databases, agent session transcripts, and shell history. No attacker code was executed and no outbound connection was made to attacker or victim infrastructure during analysis. Everything substantive was extracted from the static local capture.

‍

‍

The operator tasks an AI-agent fleet over Telegram, which runs the full intrusion lifecycle unattended against opportunistic and targeted victims, feeding stolen credentials, wallet keys, and mining revenue back to the operator.

Threat Actor Infrastructure

Primary Staging Host

The primary staging infrastructure consisted of an unauthenticated Python http.server instance (SimpleHTTP/0.6 Python/3.11.15) exposed on the non-standard port 18080. The server exposed the operator's complete home directory via open directory listing and served as the primary source for all evidence presented in this report, including:

• Agent session transcripts
• Shell history
• Engagement folders
• Evidence files
• Offensive tooling

CloudSEK researchers directly enumerated the exposed directory structure using a directory-listing crawler, cataloguing 21,442 directories and 142,262 files, which were subsequently mirrored for offline forensic analysis. At the time of writing, the host is no longer reachable; therefore, all findings presented in this report are derived from the archived mirror rather than a live connection.

‍

Sister Host

IP Address: 103.236.54.207 (formerly exposing ports 18080 and 7070)

A second server under the same operator's control was identified, configured with an identical open-directory setup on port 18080. Attribution is based on three independent artifacts recovered from the primary staging host rather than direct interaction with the secondary server:

An ED25519 SSH host key for 103.236.54.207 present in the operator's .ssh/known_hosts file.

A self-initiated Nikto scan targeting the host, recovered from the operator's files.

Approximately 800 lines of gateway logs demonstrating the host brokering LLM API requests during at least one live intrusion session, operating a self-hosted Zhipu GLM (zai-glm5.2) proxy via LiteLLM/llmio on port 7070.

As of 30 July 2026, Shodan identified the system as a Windows Server (WIN-QGQL8EFDVAN) exposing SMB, RPC, NetBIOS, and WinRM services, while ports 18080 and 7070 were no longer visible. This change is consistent with either the operator removing the exposed services following discovery or the IP address subsequently being reassigned.

Independent TCP connectivity testing from the analysis environment resulted in timeouts across all tested ports. This observation is inconclusive and is presented solely as a limitation of the analysis rather than evidence supporting either scenario.

Pivot / Worker Hosts

These systems appear to have functioned as temporary pivot or worker infrastructure used during cryptomining deployments. At the time of the last verification they remained online, but no operator-specific content was observed beyond miner staging activity.

Compromised Third-Party Infrastructure (Victim-Owned)

The following systems were compromised by the operator but are assessed to be victim-owned infrastructure rather than operator-controlled assets:

• 47[.]237[.]180[.]26
• 47[.]238[.]153[.]99
• 47[.]76[.]207[.]116
• 47[.]83[.]188[.]230

Access to these hosts was enabled through a single recovered ED25519 private key (recovered_key.txt) found within the operator's files. The systems were determined to belong to unrelated third parties based on the legitimate production services operating on them, including:

• Ant Design Pro administrative interfaces
• cashup.vip / GetRupee deployments
• TalkWorld instances exposing SMB, RPC, and NetBIOS services

These hosts are included solely to distinguish infrastructure compromised by the operator from infrastructure operated by the operator. They should therefore be treated as victim systems and not as components of the threat actor's command-and-control or operational infrastructure.

The autonomous AI-agent attack fleet

The core of the operation is a set of AI coding agents wired to run offensive tasks end to end without human approval. The operator defeated the two safeguards that normally constrain such agents.

Two moves convert a safety-constrained commercial coding agent into an autonomous offensive worker: disabling all approval prompts (brakes off) and wrapping every task in a fake "authorized target" consent role-play.

Turning off the safety brakes

Configuration recovered from the operator's shell history shows approval prompts globally disabled, sub-agent auto-approval enabled, and full-auto execution with high concurrency set across every agent profile. Recovered human-typed messages to the agents show him repeatedly fighting the remaining confirmation prompts so the agents would run unattended.

He also launched agents directly with the permission-bypass flag and ran the built-in permission-reduction helper to auto-allowlist his tool calls.

The jailbreak template (consent role-play)

Every engagement opens with the same reusable Chinese prompt that frames the job as an authorized penetration test. It is a costume placed on the AI so it will comply. The same template was observed verbatim across multiple sessions against different targets, with only the target domain swapped. Translated extract:

A more aggressive variant explicitly instructs the agent to operate with an "automated hacker" mindset, to never wait for human confirmation, to auto-fuzz every input point, to try default credentials, and to auto-match and fire proof-of-concept exploits for known component CVEs.

Telegram command-and-control

The agents are bridged to Telegram so the operator can task them from a phone and collect results in a group chat. A single operator account is allow-listed across every agent bridge; all bots refuse to talk to anyone else. During bridge setup the operator leaked his own live bot token straight into a session transcript. Live checks of the operator's public bot pages showed the infrastructure still running, with one bot self-described, in Chinese, as a "social-engineering bot".

Campaign 1: internet-wide opportunistic exploitation

The operation splits into a high-volume opportunistic campaign (mass WordPress compromise, cryptojacking) and a high-value targeted campaign (crypto and DeFi theft), with headline figures for each.

Mass WordPress compromise

An automated WordPress-to-webshell pipeline produced a large inventory of confirmed compromises. The final, deduplicated evidence file contains 12,048 real compromise records across 8,996 unique sites, each carrying a unique attacker-created backdoor admin account and the victim site's database table prefix, with a subset also capturing harvested server environment data. These backdoor accounts are attacker-created, not stolen from the victim, so they are a distinct category from genuinely harvested credentials: a separate, smaller set of database dumps holds 66 sets of real harvested (non-backdoor) site admin credentials, pulled directly out of victim databases.

Geographic distribution of compromised WordPress hosts

Enriching the 12,048 compromise records (8,996 unique sites) against the operator's own reconnaissance corpus, which carries a server-country field for every host, yields a full geographic picture of the victims. The campaign is overwhelmingly Western: the United States alone accounts for over a quarter, and the top three countries (United States, Germany, France) make up just over half of all compromised hosts.

Server-country distribution of the 12,048 confirmed WordPress compromise records, geolocated via the operator's own reconnaissance corpus. This is opportunistic, geography-agnostic mass exploitation, so the distribution tracks WordPress hosting density rather than any deliberate country targeting.

Deserialization RCE and reconnaissance tooling

The host also carried a fastjson2 deserialization RCE kit and a full ProjectDiscovery-style reconnaissance suite driven from a multi-million-host FOFA corpus. The fastjson2 activity was reconnaissance only: across a 6,326-target sweep, 3 unrelated hosts were rated confirmed-high-risk for processing the @type field, but the operator's own testing recorded no successful out-of-band callback against them, and a further 22 were WAF-blocked (mostly Chinese automotive-group and education domains) with 16 more suspected timeouts. No case escalated to code execution, so unlike the WordPress campaign this activity produced no confirmed compromises. FOFA API keys, used to build the corpus, were present in configuration and have been redacted.

Cryptojacking

The operator drops a Monero miner onto compromised hosts, renamed to an innocuous filename and relaunched from a hidden path in the background, staged through a public file-sharing service to evade notice. Two Monero payout wallet addresses were recovered from shell history and have been redacted.

Campaign 2: Targeted crypto and DeFi theft

The high-value campaign targets crypto exchanges, DeFi protocols, blockchain infrastructure, and especially cryptocurrency trading bots, which are attractive because they guard users' wallet keys. A strict, evidence-based review of the operator's own engagement and evidence files classified each named target by whether the files contained actually retrieved secrets or data rather than the operator's own success claims.

Demonstrated fund-theft capability against his own targets

In at least one case the operator did more than read data: a blockchain project's testnet faucet returned real wallet private keys, and a captcha-bypass drain was executed that produced two confirmed on-chain transactions. In another, an auth bypass against a trading bot's backend returned real encrypted wallet private keys and balances. These are genuine key-material retrievals by the operator against the targets he chose.

The mass wallet-key and seed-phrase holding came from one third-party phishing network's open database, not from a compromise

The bulk of the wallet key material in the dump, hundreds of Solana wallets with addresses, private keys, and mnemonics plus their live balances, and hundreds of captured recovery passphrases and keyphrases, all originates from a single family of phishing clone sites, not from breaching a legitimate trading-bot provider. 

These four clone sites are unrelated, unauthorised white-label copies of a legitimate Solana sniping-bot product; they are run by a separate, unconnected phishing operator, not this report's operator, and it is that clone operator's own botched deployment that left the underlying data exposed. This operator independently found and exploited that exposure himself: he pulled the Firebase config out of the clone sites' frontend JavaScript, confirmed their Firestore databases had no security rules, and read every record straight from the public Firestore REST API with zero authentication. The one site running the legitimate, unmodified codebase returned 403 and leaked nothing. The consolidated wallet export he built is sourced entirely from these clone sites.

Critically, these clone sites are themselves phishing sites: they trick end users into entering their 12 or 24 word recovery phrase, which is written into the open database. The seed phrases were therefore harvested by the phishing operators, and this actor scraped them out of the phishers' misconfigured database. The affected wallets belong to end users who are victims of that phishing operation, a live ongoing third-party exposure rather than one of this operator's own targeted breaches.

Disclaimer: The wallet key material and recovery phrases described above belong to real end users who were phished by a third party and whose data this operator then scraped from an open database. All such values are redacted in this report. Affected wallets must be treated as fully compromised and swept to fresh keys immediately.

Validated live keys and admin access (aggregated, victims anonymized)

Across roughly 34 confirmed-breach entries the operator's files contained live, validated secrets and data rather than mere vulnerability descriptions. Representative categories, with company names withheld:

• A privacy-messaging network with an on-chain token's content-management token was used to pull its full CMS dataset including unpublished entries and staff emails.
• A DePIN vehicle-data network's GraphQL indexer was queried without authentication to return roughly 199,000 real records (158,281 vehicle records plus 40,622 device identifiers).
• A blockchain compute platform yielded a scripted extraction of 2,250 real user wallet addresses (EVM and Solana) with derivation paths.
• Multiple providers' live paid RPC and analytics API keys (Helius, QuickNode, and similar) were extracted from client-side bundles and confirmed working against production.
• A blockchain node's public object storage exposed roughly 746 gigabytes of prover and node data, including a genesis configuration that itself contained a live root key value.
• A real-money gaming and payments platform's admin bearer token was captured and used to read a live withdrawal ledger containing victim names, bank details, and payout amounts.

TTPs mapped to MITRE ATT&CK

The following techniques were reconstructed from the operator's tooling, configuration, evidence files, and shell history. Evidence references are kept generic; no victim identifiers or live secrets are included.

The blockchain command-and-control project

Encrypted commands are written to a smart contract as transaction calldata and read back by implants via read-only calls, so control survives server seizure. Analysis confirms this system was only ever run locally and never deployed to mainnet.

The operator was developing an EtherHiding-style command-and-control system, internally named DeadDropC2, whose commands are hidden on a public blockchain, so that even if defenders seize his servers, implants can still receive orders from a source that cannot be taken down. The project is a self-contained kit: a Solidity dead-drop smart contract (DeadDropC2.sol), a Python operator console, a Python implant, and a wallet-key store, backed by a local web3.py test harness. A companion Chinese-language research paper frames it as a hands-on implementation of the "Mode 1" EtherHiding design he had written up separately.

Architecture. The operator console publishes commands as ordinary blockchain transactions whose payload rides in the transaction calldata; the smart contract acts purely as the dead-drop mailbox, emitting the payload as an event rather than writing it to contract storage. Implants never receive an inbound connection: they poll the contract with read-only view calls (no transaction, no gas, no on-chain trace of the read, and no exposure via eth_getStorageAt) and pull down any command addressed to them. Because reads leave no footprint and the mailbox is a public contract, there is no operator server for a defender to block or seize, which is the whole point of the design.

Contract interface. DeadDropC2.sol exposes operator-only functions to broadcast to all nodes (broadcastGlobal), to a named group (broadcastGroup), or to a single wallet (sendTargeted), plus an operator-only kill switch (setEmergency) and ownership transfer (transferOperator). A public registerNode function lets an implant self-enrol into a group on first run, and public view functions (getStatus, getNodeGroup) let implants poll state at zero cost. Control is single-operator: one EOA holds all privileged access, with no multisig and no upgrade proxy, so compromise or seizure of that one key would fully compromise the channel.

Note: Commands stored as EVENTS, not contract storage. Gas cost 80% lower, and events don't appear in eth_getStorageAt (anti-forensics).

Event-based delivery and anti-detection polling. Commands are emitted as GlobalCommand, GroupCommand, and TargetedCommand events, each carrying a version counter; implants cache the last-seen version and only pull full event logs when it changes, rather than polling logs on every cycle. The implant polls on a jittered 30±15 second interval and rotates across three hardcoded BSC-testnet RPC endpoints (bsc-testnet-rpc.publicnode.com, bsc-testnet.drpc.org, bsc-testnet.bnbchain.org) for redundancy — the kit is wired to a test chain, not mainnet. Source documentation explicitly frames this timing design as evading beacon-interval detection.

Command set. The implant-side parser recognizes shell:<cmd> (shell execution), download:<url>, update:<url> (self-update), exfil:<path>, sleep:<seconds>, beacon, and die. As built, all four action verbs — shell, download, update, and exfil — are logged stub branches only, each carrying a comment showing what the real implementation would do; none of them is wired to actually execute a command, fetch a payload, self-update, or exfiltrate a file. Only sleep, beacon, and die are live in the captured code.

Note: shell/download/update/exfil are SIMULATION STUBS. They log but don't execute. Only sleep/beacon/die are live.

Kill switch and hibernation. A single operator transaction to setEmergency reaches every implant on its next poll: flag 1 instructs nodes to log a "clear traces" message and terminate, flag 2 puts nodes to sleep for 300 seconds without polling. This gives the operator a centralized, one-transaction shutdown or pause across the entire implant fleet.

Cryptography. Every command is encrypted with AES-256-GCM before being placed in calldata, with the key derived through PBKDF2-HMAC-SHA256 (100,000 iterations) from a shared secret and static salt hardcoded in both the operator and implant source. The on-chain payload is therefore opaque to any observer without the source-embedded passphrase. The passphrase, salt, and the two wallet private keys shipped in the project are redacted from this report and preserved for law enforcement.

Key Design: The encryption key NEVER touches the blockchain. Only encrypted payloads appear on-chain. A defender who finds the contract cannot decrypt without the source-embedded passphrase

Never operationalised (verified). Despite the complete build, several independent artifacts confirm the system was only ever exercised locally against a web3.py in-memory test EVM and was never deployed for live use: there is no runtime config.json, there is not a single invocation of the operator console anywhere in the shell history, the only execution evidence is the local simulated test run, and both wallet addresses shipped with the project — the operator EOA (0x399E...bCE7c) and a test-node address (0x5eA7...ed2B80) — were checked against a public block explorer and show zero funding and zero transactions on mainnet. The contract was never targeted at a production chain. The capability is therefore best read as a developed-but-unlaunched escalation of tradecraft rather than an active C2 channel.

Defender detection guidance, if activated. Should this or a derivative kit be deployed, the clearest signals are: a funding or contract-interaction transaction touching either of the two known wallet addresses; a contract deployment whose bytecode matches DeadDropC2.bin (compiler version and optimisation settings are deterministic from source); event logs bearing the GlobalCommand / GroupCommand / TargetedCommand / NodeRegistered signatures; and, at the network layer, periodic getStatus() view calls on a 30±15 second jitter rotating across the three hardcoded BSC-testnet RPC endpoints named above — a shift from those testnet subdomains to mainnet-facing endpoints would itself be a strong signal of an operationalisation attempt.

Operator Usage Examples

Disclaimer: All analysis was performed offline against a static capture of the exposed directory. No attacker binaries were executed, no attacker or victim infrastructure was contacted, and no attacker credentials (bot tokens, API keys, private keys, or proxy keys) were used. All such secrets are redacted from this report.

Attribution

Attribution rests entirely on artifacts the operator left in his own directory, not on any external interaction with his accounts.

• Language and workflow: Every note the operator wrote to himself is in native Chinese: to-do lists, methodology documents (asset register, lead queue, hypothesis ledger, coverage matrix), shell-history comments, and agent tasking prompts. A weather query for a specific Chinese city appears in his test chatter.
• Telegram identity cluster: A single long-lived operator account (registered roughly 2017 by ID range) is allow-listed across every agent bridge, presenting a consistent display name. One of his live bots is self-described in Chinese as a "social-engineering bot". Operator ID, bot tokens, and handles are redacted here and reserved for lawful referral.
• LLM backend: Rather than the official model providers, the operator routes all agent traffic through a self-hosted proxy to a Chinese large language model (Zhipu GLM) on a second server he controls, both to cut cost and to stay off the major providers' abuse radar.
• On-chain: The blockchain-C2 operator address showed zero transactions on mainnet, indicating the C2 was a testnet proof of concept, never operationalised, so there is no on-chain cash-out trail to cluster from it. Monero payout addresses are private by design and cannot be clustered from open sources.

Impact

Direct theft of end-user funds: The operator holds usable private keys and seed phrases for hundreds of cryptocurrency wallets, with live balances enumerated. Most of this material belongs to victims of a third-party phishing network whose open database he scraped, but the drain capability over those real user funds is immediate and irreversible regardless of how he obtained it, and he has separately demonstrated an actual on-chain drain against one of his own targets.

Large-scale persistent website compromise: Over 12,000 confirmed WordPress backdoors, plus a separate 66 genuinely harvested database admin credential sets, give the operator durable footholds across thousands of unrelated small-business sites, usable for resale, redirection, further malware staging, or cryptojacking.

Compromise of crypto and DeFi service providers: Validated live API keys, admin tokens, and open databases across roughly 34 confirmed-breach entries expose customer data, financial records, and in at least one case a real-money payments platform's withdrawal ledger with victim banking details.

Force-multiplied, low-cost operations: By coercing autonomous AI agents to run the full intrusion lifecycle unattended, and routing them through a low-cost self-hosted model proxy, the operator scales offensive activity far beyond what a single human could perform manually, while reducing his exposure to provider-side abuse controls.

Takedown-resistant C2 on the horizon: The blockchain-based C2 under development, though not yet deployed, signals intent to build infrastructure resilient to server seizure, which would materially raise the cost of future disruption.

Mitigation

Rotate all potentially exposed secrets immediately: Any organisation whose credentials, API keys, tokens, or SSH keys could plausibly be in a harvested corpus of this scale should rotate them now, invalidate captured admin and session tokens, and force re-authentication. This includes RPC and analytics API keys embedded in client-side bundles, which should be moved server-side and scoped.

Treat affected wallets as fully compromised: Every wallet whose key material or seed phrase may have been harvested must be swept to freshly generated keys immediately. Users of the affected trading-bot ecosystems should assume total compromise.

Lock down data stores and remove open directories: Disable directory listing on all internet-facing hosts, require authentication on cloud databases and object storage, and audit for publicly readable Firestore, S3, and equivalent buckets. The operator's own exposure, an open directory serving his home folder, is the same class of misconfiguration he exploited in victims.

Harden autonomous AI-agent deployments: Organisations running AI coding or operations agents should keep human-in-the-loop approvals enabled, avoid blanket permission-bypass flags, constrain sub-agent auto-approval, and monitor for the "authorized target" jailbreak pattern and full-auto configurations that indicate an agent has been repurposed for offensive use.

Report and refer for lawful action: File abuse reports against the live Telegram bots and operator account and preserve the full evidence set with cryptographic hashes. Refer the operator identifiers, recovered credentials, wallet lists, and rooted-host details to law enforcement so a lawful process can compel the identity mapping that open sources cannot provide.