Claude Code in the hands of a ransomware operator

The CyberSecurityNews headline leaves little room for interpretation: a ransomware operator used Claude Code to steal LDAP passwords, backdoor VPNs and exfiltrate SQL databases. The piece was published on 18 August and can be read at CyberSecurityNews.

It is worth translating the headline into what it technically means, because the easy reading (the tool is dangerous) falls short, and the defensive one (it was only a matter of time) does not help anyone who has to decide something on Monday. We are working from the headline and the source summary here, so the finer details, group, sector and timeline, we leave to whoever can verify them.

What exactly is being used

Claude Code is a CLI. It runs on the user's machine, with their permissions, their environment variables, their SSH keys and their network access. It can execute commands, read and write files, chain external tools over MCP and delegate to subagents. All of that is why an engineering team installs it, and it is exactly the same reason it shows up in a threat report.

The three actions in the headline fit that profile without assuming anything exotic. Enumerating an LDAP directory, touching the configuration of a VPN concentrator and dumping a database are systems administration tasks: tedious and well documented. In other words, exactly the kind of work where an agent with shell access performs well. The tool does not add a new offensive capability; it adds speed and lowers the skill level needed to chain steps that used to require an experienced operator.

Anthropic had already described that dynamic in its threat intelligence report last year, documenting an extortion campaign that leaned on Claude Code for much of the work. The recurring pattern is not an exploit, it is the automation of the whole process: reconnaissance, lateral movement, picking which data hurts most and drafting the ransom note.

What changes for a normal team

Little on the surface and quite a lot in practice. If your threat model assumed an attacker needs time and knowledge to move across a heterogeneous network, that assumption ages fast.

What is actionable, in order of payoff:

1. The machine running the agent is the perimeter. An agent with shell access inherits everything that account holds. Dedicated container, unprivileged account and credentials kept out of environment variables.
2. Hooks as a control, not as decoration. A PreToolUse hook can block commands by pattern before they run. It is the natural place to veto sensitive paths or network binaries.
3. Logging of what the agent does. A PostToolUse that records what ran and with what result turns a black box into something auditable.
4. An inventory of MCP servers. Every connected server is another surface. If nobody knows which ones are active on the team's laptops, there is a problem that predates AI.
5. Watch legitimate use too. The telemetry of an agent that suddenly enumerates directories or touches network configuration looks a lot like the telemetry of one that should not be there.

Who this is useful for

For anyone running security at a company that has already adopted agentic tooling, which by now is almost every company with a technical team. Also for anyone in the opposite position, using headlines like this to block adoption: blocking does not work, what works is letting the tool run in an environment where the worst possible command never reaches production.

Our take

A development CLI showing up in a ransomware report was predictable from the day it was given shell access, and it is not an argument against the tool. What does look like an avoidable failure is still installing agents with administrator permissions and not a single hook that knows how to say no.