SOCRadar says an extortion operator called n0n used the open-source OpenCode coding agent to write and debug hundreds of attack scripts, then left its own workspace on a public file server. The Register reports the crew tried to break into 23 organizations across 14 countries and spent more than $7,216 on AI services by October 22. None of the intrusions SOCRadar examined used a software vulnerability: every one began with weak or stolen credentials.
For people who run coding agents, this is a story about the other side of the tool. The same class of agent that edits your repo can, in an attacker's hands, turn a leaked AWS key or a VPN password into a scripted breach. It also shows where defense still works: the entry points are old and well understood.
TL;DR
| Question | Answer |
|---|---|
| Who is n0n? | A data-theft and extortion group that emerged in September 2026 and has claimed 108 victims; believed to be Russia-based, though SOCRadar says the server gave no definitive attribution |
| Which agent was used? | OpenCode, configured with 154 model entries across seven providers |
| Was a vulnerability exploited? | No; SOCRadar found no evidence of vulnerability exploitation in the cases examined |
| Was it autonomous? | No fully autonomous attack system was found; AI wrote and debugged scripts |
| Am I affected? | Only if you are a listed victim, or if you expose RDP, FortiGate SSL-VPN or long-lived cloud keys |
| Is there a patch? | No software fix applies; the fixes are credentials, MFA, key scoping and backups |
| Does data leave my machine because of this? | Not from your agent. The agent ran on the attacker's side |
What SOCRadar found
SOCRadar's threat hunters found the operator's workspace, a publicly accessible Python HTTP file server in Sweden on port 8877, last month. They documented the exposed directory in snapshots on September 25 and 26. According to The Register's report, the snapshots held 1,719 files: attack scripts, ransomware source code, extortion infrastructure and an AI coding agent environment. SOCRadar published its own write-up, n0n Ransomware: Inside an AI-Assisted Extortion Operation. Our fetch of that page was refused with a 403, so the details here come from The Register's account of it and from a SOC Prime summary of the research. Check the original for the full indicator list.
The group itself is new. The Register says it has claimed 108 victims since it emerged last month. On October 12 it added 38 maritime, port and logistics organizations across 18 countries to its leak site in one batch. Researchers have linked at least 21 of them to customers of the South Korean maritime software provider CyberLogitec, which has not confirmed an intrusion.
SOCRadar rates the group 10 out of 10 for aggressiveness and zero out of 10 for lethality. That rating reflects what it could verify: loud, destructive behaviour, but few confirmed payments.
The AI setup: OpenCode and 154 model entries
The most relevant detail for this blog is the agent environment. SOCRadar found OpenCode configured with 154 model entries across seven providers. The models named in the report include Gemini, Mistral, Nemotron, Llama, Claude, GPT-5.x, Grok, Kimi, GLM, DeepSeek, MiniMax and Qwen. Some had their safety training removed, and others were marketed as "uncensored".
That configuration says something practical. The operator was not relying on one provider's guardrails. When a hosted model refuses, a coding agent that can switch to an uncensored or self-hosted model keeps working. A provider-side refusal is therefore a speed bump for this kind of operator, not a control.
SOCRadar's Ensar Seker put the usage this way: "The operator used AI to write and debug hundreds of scripts. That shows how AI can help an attacker turn basic access into a broader, tailored operation." Spend passed $7,216 by October 22. That is a cost figure for the AI services the operator paid for, not a measure of the damage.
SOC Prime's summary describes what some of those scripts did. One was a regression-test script for AWS S3: it uploads a dummy file, lists buckets, downloads the object to mimic exfiltration, deletes it, and points the operator to the CloudTrail events it generated. A companion script cleans up the test bucket. In plain terms, the operator used a coding agent the way a developer would, writing a test harness for the attack so each step behaved before it ran against a victim. SOC Prime itself sells detection content, so treat its framing with that in mind.
The attack chain, step by step
The Register says every case on the exposed server followed the same lifecycle.
- Initial access through credentials. The crew scanned for exposed Remote Desktop Protocol and ran automated FortiGate SSL-VPN credential stuffing. For a US managed services provider, ChiBiTek, it used a 15-thread residential SOCKS5 proxy pool to test
ip:port:user:passwordcombinations against FortiGate portals (GET /remote/login). Other entries came from exposed cloud credentials and reused hosting-portal sessions. - Persistence and credential collection. Hidden admin accounts disguised as services, covert proxies, credential and session-token theft, mailbox access and emailed multi-factor codes.
- Collection. Sensitive data was copied to the operator's central storage.
- Impact, tailored per victim. Depending on the target, that meant data theft, encryption, destruction or network disruption. In some cases the group deleted data and backups, and in one case it changed firewall policies to block traffic.
- Pressure. Ransom notes, a countdown clock on the leak site, negotiation rooms and email addresses for victims, then publication of stolen files or destroyed backups. The group also sent automated countdown warnings to victims' service providers, clients and media outlets.
The cloud-key case
One case SOCRadar linked to the e-commerce site Fanatics shows how little the AI part mattered at the start. n0n used an exposed AWS access key with permission to list, read and delete objects in S3 buckets. It pulled data from 40 buckets, with up to 110 GB per bucket, then deleted data, including bank-transaction archives, and purged keys across 12 sensitive buckets. The Register's account does not describe how the key was exposed.
The pattern is the same one behind many incidents we have covered: a long-lived credential with write and delete rights. If you want the cleanup playbook for that case, see our first 24 hours after a vendor breach runbook and the Railway breach rotation guide.
The knock-on mistake
After breaking into Transcom, a Netherlands-based financial services provider, the crew sent a secondary ransom alert directly to PayPal's security team, even though the compromised data was only on Transcom's network. It is a reminder that leak-site claims and pressure tactics are not evidence of what was actually taken.
What is claimed and what is verified
| Claim | Status | Basis |
|---|---|---|
| Exposed server with 1,719 files | Reported by SOCRadar | Snapshots of September 25 and 26 |
| OpenCode with 154 model entries, seven providers | Reported by SOCRadar | Agent environment on the server |
| More than $7,216 AI spend by October 22 | Reported by SOCRadar | AI usage costs, not damage |
| 23 organizations targeted in 14 countries | Reported | The Register, citing the workspace |
| Entry via weak or stolen credentials only | Reported by SOCRadar | No vulnerability exploitation found in cases examined |
| 38 maritime victims, ransoms $400,000 to $28 million | Group's claim | No listing marked "settled"; no transactions seen on payment addresses |
| CyberLogitec customers affected | Partly linked | At least 21 victims linked by researchers; the vendor has not confirmed an intrusion |
| Russia-based | Believed | The server gave no definitive attribution |
We did not inspect the exposed server or its files ourselves, and we have not independently confirmed any victim. Everything above rests on SOCRadar's research as reported.
What this means if you run AI coding agents
Nothing here is a flaw in OpenCode or in any model provider, and there is nothing to patch. OpenCode is a legitimate tool, and we have written about real OpenCode security issues separately: see the OpenCode console breach claims and the OpenCode MCP OAuth RCE on Windows and WSL. What this incident adds is a clear picture of what a coding agent gives an attacker and which controls still stop it.
Credentials are the choke point. The report says no vulnerability was exploited. If an attacker cannot log in, the agent has little to script. Concretely:
- Find long-lived cloud keys. Search your repos,
.envfiles and shell history for AWS access keys (AKIA...) and other static credentials, and replace them with short-lived role credentials. Our guide to how API keys leak from logs and environment variables lists where to look. - Scope keys for delete. The Fanatics-linked case worked because one key could list, read and delete in S3. Remove
s3:DeleteObjectfrom anything that does not need it, and turn on versioning or Object Lock for important buckets. - Close the entry points. Do not expose RDP to the internet. Put FortiGate SSL-VPN behind phishing-resistant MFA and rate limiting, and review logs for repeated
GET /remote/loginattempts from many residential IPs. - Keep backups the attacker cannot delete. The most damaging detail in the report is deleted backups. As Seker put it, "That creates a recovery problem that a decryption key alone cannot solve." Immutable or air-gapped copies address exactly this.
- Watch for destruction signals. Alert on mass
DeleteObjectscalls, purged keys, new hidden service-like admin accounts and firewall policy changes.
Your own agents are the other half. An agent with a shell and a credential can chain steps quickly, which is why the same defender advice applies to your laptop. Give agents least-privilege, short-lived credentials, keep production keys out of the directories they can read, and review what they ran. Related cases show the same dynamic from other angles: a ransomware crew that used Cursor agents to reach domain admin, a bank breach traced to an open directory with Claude Code artifacts, and Symantec's report on LLMjacking and exposed AI endpoints. For this month's wider list, see the October 2026 attacks timeline.
What Beam can and cannot do here
Beam runs on your machine and watches what your own coding agents do, so it does not see n0n's server or its agent. What it can help with is the credential side of your own setup:
- It flags risky actions proposed by agents, including credential exposure and destructive commands, from hook events (how it works).
- With a workspace policy in enforce mode, Claude Code and Codex PreToolUse hooks can receive a deny before a command runs. Other agents get a stderr note rather than a verified block.
- Secrets are redacted before storage, and everything stays on-device (local-first design).
The limits are plain. Deny is hook-based, not a kernel sandbox. A missing or expired cached policy allows the action (fail-open). A PreToolUse event records a proposed action, not proof that it ran. Beam does nothing about an attacker's infrastructure or about keys that are already exposed elsewhere; rotating them is your job.
Why the exposed server matters
The operational mistake is the reason we know any of this. Seker described "a striking gap between operational ambition and security discipline": thousands of dollars on AI services, while the workspace sat on a public file server and the ransomware held hardcoded encryption keys, with evidence suggesting the keys were reused across victims. If that reuse holds, victims of the same build may share a recovery path, but that is SOCRadar's inference and it is not a promise of a decryptor.
It is also a reminder for defenders: an attacker's agent workspace leaves records. The session history, scripts and configuration are exactly what threat researchers read. The same is true of your own agents, whose logs and transcripts hold prompts, file paths and sometimes secrets. Where those logs are stored and who can reach them is worth a look; see our write-up on OpenTelemetry and prompt capture for agents for the tradeoffs.
What to watch next
SOCRadar's analysis is the primary source and may be updated with indicators. Watch for confirmation or denial from CyberLogitec, for any decryptor if the hardcoded-key reuse is borne out, and for further victims on the leak site. We will add an update here if the picture changes.
Frequently asked questions
What did SOCRadar find about n0n ransomware?
SOCRadar found a publicly accessible Python HTTP file server, hosted in Sweden on port 8877, that held the n0n operator's workspace. Across snapshots taken on September 25 and 26 it held 1,719 files, including attack scripts, ransomware source code, extortion infrastructure and an AI coding agent environment. The Register reports the group tried to break into 23 organizations across 14 countries.
Which AI coding agent did the n0n operator use?
The Register, citing SOCRadar, says the operator used OpenCode, an open-source AI coding agent, configured with 154 model entries across seven providers. The list included mainstream models and some with safety training removed or marketed as uncensored. AI usage costs passed $7,216 by October 22.
Did n0n exploit any vulnerabilities?
No, according to SOCRadar's Ensar Seker, who told The Register that access in every documented compromise relied on weak or stolen credentials and that no evidence of vulnerability exploitation was found. Entry came from RDP scanning, FortiGate SSL-VPN credential stuffing, exposed cloud credentials and reused hosting portal sessions.
Was this a fully autonomous AI attack?
SOCRadar did not find evidence of a fully autonomous attack system. The AI was used to write and debug hundreds of scripts while a human operator ran the campaign, which is a different and more common pattern than an agent that attacks on its own.
Are the victim and ransom claims verified?
Only partly. The attack scripts and server contents come from SOCRadar's own snapshots. Ransom demands of $400,000 to $28 million and the leak-site claims are the group's statements: SOCRadar has not validated any payment on-chain, and the software vendor linked to 21 maritime victims has not confirmed an intrusion.
What should developers who run coding agents take from this?
Treat an exposed cloud key, VPN password or session token as the real risk: an agent can turn one into a scripted breach quickly. Remove long-lived keys from environments and repos, give agents least-privilege credentials, keep immutable backups, and review what your own agents read and run.
Related reading
- Aur0ra ransomware operators used Cursor agents to reach domain admin
- South Korea bank hack: Claude Code artifacts in an open directory
- October 2026 attacks timeline
- How API keys leak in logs and environment variables
Details are accurate as of October 30, 2026, based on The Register's report of SOCRadar's research; SOCRadar's original page could not be fetched when this was written. Beam is a local prototype and its hook-based deny covers Claude Code and Codex.