The Ransomware Had an AI Copilot. The Human Still Hit Approve.

Ransomware operators are using AI to help plan intrusions, troubleshoot attacks, steal data, and prepare extortion campaigns. New research into the INC and The Gentlemen ransomware operations reveals something more practical than an autonomous hacking apocalypse: criminals using AI to make familiar attacks easier to execute, while humans remain firmly in charge.

The machines aren’t running the ransomware operation. They’re helping the humans run it.

Remember when ransomware required criminals who actually knew how to hack things?

Those were simpler times.

You needed someone who understood networks, Windows internals, Active Directory, vulnerabilities, privilege escalation, and how to move around an environment without immediately announcing their presence to the entire SOC.

Now some of that knowledge can be supplemented by AI.

And no, that doesn’t mean ChatGPT has decided it wants a career in organized crime.

It means criminals have discovered the same thing the rest of us have.

AI is a pretty damn useful assistant.

The difference is what they’re asking it to assist with.

On October 20, 2026, SOCRadar published research, updated October 23, describing a ransomware operation associated with affiliates of INC Ransomware and The Gentlemen.

Researchers found exposed attacker infrastructure containing source code, stolen credentials, command-and-control tools, victim records, and an extensive history of conversations with AI models.

The recovered material included 8,257 AI messages across 133 sessions.

And this wasn’t somebody asking an LLM to explain what ransomware means.

These operators were using AI to help plan reconnaissance, generate commands, troubleshoot techniques, organize stolen information, and prepare extortion operations. SOCRadar

The interesting part?

The humans still approved the actions.

This wasn’t Skynet.

It was ransomware with a copilot.

And that may be considerably more practical for criminals.

So What Actually Happened?

SOCRadar’s Threat Research Unit discovered an exposed command-and-control server in late September 2026.

The researchers found that someone had left parts of a ransomware operation accessible from the internet.

Not the usual ransom note.

The actual working environment.

Source code.

AI conversation histories.

Credentials.

Tools.

Victim tracking information.

And a framework called Phantom.

The investigation eventually led to seven attacker-controlled servers.

Phantom was designed to coordinate the different stages of an intrusion, from identifying targets to preparing ransomware deployment.

Its operators used OpenCode, an open-source coding-agent interface, with commercial AI models accessed through OpenRouter.

The models included Anthropic’s Claude Opus 4.6 and Moonshot AI’s Kimi K3.

There was even tooling labeled “WormGPT.”

Which sounds wonderfully sinister until you discover that, according to SOCRadar, it was essentially a persona prompt layered over commercial models, not some independently developed evil superintelligence. SOCRadar

We’ve reached the stage where criminals can give ordinary software an intimidating name and call it innovation.

Cybersecurity marketing has taught them well.

The AI Wasn’t in Charge

This distinction matters enormously.

The attacker didn’t simply tell an AI:

Go find some companies and ransom them.

Then disappear for the weekend.

According to SOCRadar’s recovered sessions, operators created instructions for individual targets and required the AI to wait for approval before proceeding.

The AI could recommend a technique, generate a command, troubleshoot a failure, or organize information.

The human decided whether to move forward.

The Cloud Security Alliance’s October 24 review independently examined the published findings and emphasized the same distinction: this was AI-executed, human-approved activity, not evidence of a fully autonomous system choosing and attacking all the organizations on its own. Cloud Security Alliance

Why would criminals want to keep a human in the loop?

For the same reasons legitimate organizations do.

AI makes mistakes.

It can misunderstand an environment.

It can invent commands.

It can break things too early.

And when you’re attempting to steal someone’s data without getting caught, an AI hallucination is considerably less amusing than when it invents a restaurant recommendation.

The human approval process lets attackers benefit from AI’s speed and assistance while retaining control over consequential decisions.

Human-in-the-loop doesn’t automatically mean safe.

It depends rather heavily on what the human is approving.

About Those 62 Organizations

This is where we need to be careful with the headlines.

SOCRadar found 62 named organizations in the attackers’ records, including 36 in the United States.

But that does not mean 62 confirmed ransomware victims.

The researchers classified the organizations according to the depth of activity observed.

Source: SOCRadar Threat Research Unit, October 2026. Classification reflects evidence found in attacker records; not every named organization was independently confirmed as compromised.

Here’s the breakdown:

12 organizations were reconnaissance-only cases.
28 had evidence of a foothold or access.
14 reached domain-level compromise.
4 reached an encryption or extortion stage.
4 were publicly listed for extortion.

That’s a very different story from saying 62 organizations were successfully ransomed.

SOCRadar also recovered 46 customized INC ransomware encryptor builds prepared for six organizations.

Some were staged for an October 1 deployment.

A screenshot showed encryption operating on a victim workstation, but the researchers could not confirm that every planned deployment actually happened. SOCRadar

Those distinctions matter.

Threat intelligence gets much less useful when we turn every target into a confirmed breach and every staged payload into a successful ransomware deployment.

The real evidence is already concerning enough.

We don’t need to inflate it.

The Attacks Themselves Were Remarkably Familiar

Here’s what caught my attention.

For all the sophisticated language about autonomous frameworks, AI agents, and MCP servers, the actual entry points weren’t some revolutionary new form of cyberattack.

They were familiar vulnerabilities and access problems.

The attacker records described activity involving:

FortiClient EMS: A critical improper-access-control vulnerability tracked as CVE-2026-35616.
SimpleHelp: Remote-management vulnerabilities including CVE-2024-57727.
cPanel/WHM: An authentication-bypass vulnerability tracked as CVE-2026-41940.
Stolen or reused credentials: Access to VPNs, management systems, servers, and backup infrastructure.

Those vulnerabilities are real. The Canadian Centre for Cyber Security issued an alert concerning FortiClient EMS, and Australia’s cyber agency documented active exploitation of the cPanel issue. Canadian Centre for Cyber Security Australian Cyber Security Centre

SOCRadar’s detailed counts of accounts created, systems accessed, and organizations affected still come from attacker-held records and have not all been independently verified.

But the methodology is familiar.

Find an exposed management system.

Exploit it.

Create or steal privileged access.

Move through the environment.

Disable security controls if possible.

Steal data.

Prepare ransomware.

Demand money.

The AI didn’t invent the playbook.

It helped the attackers work through it.

Which brings us to the part I think organizations should be paying the most attention to.

The MSP Problem Is Bigger Than the AI Problem

Imagine your company uses a managed service provider.

Perfectly normal.

The MSP handles your servers, endpoints, patching, remote support, backups, or security systems.

Your MSP has technicians.

Those technicians have administrative access to customer environments.

Sometimes dozens of them.

Now imagine an attacker compromises one technician account.

What can that account actually do?

Can it access one customer?

Ten customers?

Fifty?

Can it run scripts?

Install software?

Modify endpoint configurations?

Disable security tools?

Access backups?

Push an executable to every machine a customer owns?

What stops someone from using that same legitimate management system to distribute ransomware?

That’s the question.

And it isn’t hypothetical.

We’ve Already Seen MSP Tools Used This Way

In 2025, Sophos investigated an attack involving the SimpleHelp remote-management platform.

Attackers compromised an MSP environment and used its legitimate management capabilities to deploy DragonForce ransomware across multiple endpoints.

Sophos assessed that vulnerabilities in SimpleHelp were likely involved.

It also documented another campaign in which Qilin ransomware affiliates phished a ScreenConnect administrator, obtained access, and used that legitimate remote-management relationship to attack the MSP’s customers. Sophos: DragonForce Sophos: Qilin

Those cases were not presented as the same Phantom operation.

They are independent examples showing why compromising an MSP’s management tools is such an attractive strategy.

One compromised management platform can provide access to multiple organizations.

An attacker doesn’t necessarily need to break into every customer separately.

The trusted relationship has already done some of the work.

And trusted relationships are wonderful.

Right up until someone else starts using them.

Legitimate Software Can Deliver Illegitimate Actions

This is the part that makes modern ransomware detection difficult.

Remote-management tools are supposed to execute commands.

They’re supposed to install software.

They’re supposed to modify configurations.

They’re supposed to connect to endpoints.

So when a compromised technician account pushes a script through an approved RMM platform, the technical activity may look remarkably similar to legitimate administration.

The account exists.

The tool is approved.

The connection is allowed.

The software deployment succeeds.

Nothing necessarily looks malicious if your security model stops at:

Was this an authorized management tool?

The better question is:

Was this particular action appropriate, expected, and authorized for this customer at this time?

That’s a completely different level of visibility.

And the AI Makes It Easier to Scale

This is where the AI element becomes meaningful.

Imagine an attacker working through a compromised environment manually.

They need to enumerate systems.

Understand the environment.

Identify management tools.

Review permissions.

Figure out which accounts are useful.

Troubleshoot failed commands.

Organize stolen credentials.

Keep track of multiple targets.

Now give that person an AI assistant that can help perform all those tasks.

Suddenly the operator may spend less time writing commands and organizing notes and more time deciding what to do next.

Anthropic’s September 2026 threat-intelligence report describes a similar broader trend.

The company observed malicious actors using agent frameworks to automate reconnaissance, exploitation, tool development, credential collection, and exfiltration. It emphasized that many attacks still relied on conventional weaknesses such as stolen credentials and unpatched systems. Anthropic

That’s the important shift.

AI doesn’t have to invent a new vulnerability to make ransomware more dangerous.

It only has to make existing attacks easier to organize and execute.

And if one operator can effectively supervise several operations, the economics start becoming more favorable for criminals.

Less manual effort.

More concurrent targets.

More opportunities to profit.

Cybercrime gets a productivity improvement.

Humanity remains deeply committed to using every technological advancement for something disappointing.

The Credentials Were Still the Crown Jewels

One detail in the SOCRadar investigation deserves particular attention.

Researchers found a case where a single reused password reportedly provided access across multiple systems, including VPN, servers, RMM, backups, and security management.

One password.

Multiple administrative platforms.

That’s not an AI problem.

That’s an identity-management problem wearing a very expensive AI jacket.

And it’s exactly why privileged access needs to be separated.

A technician’s remote-support credentials should not automatically grant administrative access to backup systems, security infrastructure, and every customer environment.

The same administrative identity shouldn’t have unrestricted reach simply because it’s convenient.

Convenience is wonderful.

Until the attacker enjoys it too.

So What Should Organizations Actually Do?

This is where the story becomes useful.

The solution isn’t buying a product with “AI Ransomware Defense” printed in enormous letters on the dashboard.

The fundamental controls are things security teams already understand.

1. Restrict technician access by customer

An MSP technician should only have access to the customers and systems required for their job.

Not every customer.

Not every endpoint.

Not every management platform.

If a technician primarily supports three organizations, why does that account have permission to push software to thirty?

Separate customer access wherever the management platform permits it.

Use individual identities.

Require strong, preferably phishing-resistant MFA.

Avoid shared administrative accounts.

And use time-limited privileged access where practical.

The Australian Cyber Security Centre specifically recommends limiting MSP access through dedicated workstations, least privilege, MFA, and approved access windows. Australian Cyber Security Centre

2. Put controls around mass software deployment

This one is enormous.

A technician installing a printer driver on one computer is normal.

A technician suddenly pushing an executable to 700 endpoints across eight customers deserves attention.

Organizations should consider requiring additional approval for high-impact actions such as:

Organization-wide software deployments
Cross-customer script execution
Changes to security-agent settings
Mass endpoint reconfiguration
Changes to backup policies
Creation of highly privileged management accounts

Where possible, use independent approval and allowlisted or signed software packages.

If a compromised technician account can perform all those actions without another independent control, the attacker may already have much of what they need.

3. Monitor management-system changes

SOCRadar documented attackers creating privileged management accounts and manipulating FortiClient EMS-related configurations, including VPN connection scripts.

Those activities are especially worth monitoring.

Look for:

New EMS or RMM administrator accounts
Unexpected privilege elevations
VPN profile and connection-script changes
New management integrations or API credentials
Unexpected changes to security policies
Missing or disabled audit logging
Administrative activity from unfamiliar locations or devices

A VPN configuration change might be completely legitimate.

A VPN configuration change followed by unusual endpoint script execution across hundreds of devices?

That’s worth investigating.

4. Correlate actions across customers

This may be the most important improvement for MSP security operations.

If a technician logs into one customer and runs a script, that might be routine.

If the same technician account executes similar scripts across twenty customer environments in a few minutes, the context changes.

Security platforms need visibility across the management plane.

Not just individual endpoints.

That means correlating:

Technician identity
Source device
Customer or tenant
RMM session
Script or software package
Approval or change ticket
Execution time
Endpoint results

Because a compromised RMM system can make a malicious deployment look like legitimate IT work.

The difference is often in the surrounding behavior.

5. Protect backups and security infrastructure separately

Ransomware actors frequently try to interfere with recovery and detection.

SOCRadar found tooling intended to impair security products, alongside interest in backup and administrative infrastructure.

CISA’s ransomware guidance recommends network segmentation, monitoring misuse of RMM tools, controlling privileged access, and maintaining protected backups. CISA

An MSP technician who supports desktops should not necessarily have the authority to delete backup repositories.

And the same account used for ordinary endpoint support shouldn’t be able to disable security controls across an entire customer estate.

That’s not Zero Trust marketing.

That’s basic separation of duties.

Detection Needs to Look Beyond the Malware

Here’s another important lesson.

If we wait until the ransomware executable starts encrypting files, we’ve waited far too long.

The better opportunities often come earlier.

A suspicious administrator appears.

A management script changes.

An RMM session starts outside its normal window.

The same account accesses multiple customers.

An endpoint begins unusual outbound transfers.

A security product is disabled.

Backup configurations change.

Any one of those activities might be legitimate.

Together, they can tell a much more interesting story.

SOCRadar’s detection guidance specifically highlights management-account creation, VPN script changes, unauthorized RMM activity, credential abuse, security-service impairment, and unusual data transfers. SOCRadar

That is where behavioral analytics and proper log correlation matter.

Not because the attack uses AI.

Because the attacker is abusing administrative trust.

This Is Also a Third-Party Risk Problem

Companies that outsource IT often assume the provider is handling security.

That’s understandable.

It’s also incomplete.

You can outsource operations.

You cannot completely outsource accountability for your own systems and data.

If an MSP manages your endpoints, your organization should understand:

Which technicians can access your environment
Whether privileged access requires MFA
Whether administrative identities are customer-specific
Who can deploy software
Whether mass deployments require approval
How administrative activity is logged
Whether your own security team can independently review those logs
What happens when an MSP account is compromised

The Australian government’s September 2026 security guidance goes further, recommending that service-provider access be restricted to approved tools, source networks, and time windows, with independent logging that the provider cannot modify or delete. Australian Cyber Security Centre

That’s a useful standard.

Because if your only evidence of what the MSP did lives inside the MSP’s compromised system, incident response gets considerably more entertaining.

And not in the good way.

What About the AI Providers?

There’s another piece of this discussion worth acknowledging.

The operators used commercial AI models.

That doesn’t mean those model providers knowingly participated in a ransomware operation.

SOCRadar observed operators reframing malicious requests as authorized security assessments when they encountered model refusals.

Anthropic has independently documented malicious actors using similar deception techniques and says it has disrupted abusive accounts and strengthened defenses. Anthropic

Model-provider safeguards matter.

But those safeguards cannot be the sole protection for enterprise infrastructure.

Even if one model refuses a request, attackers can still use other tools, other models, or traditional scripts.

The responsible strategy is to improve AI safeguards while also securing the networks, identities, and management platforms that criminals are trying to abuse.

The Most Interesting Part Wasn’t the AI

For all the sophistication in this ransomware operation, the attackers made a remarkably ordinary mistake.

They exposed their own infrastructure.

SOCRadar found the working environment because portions of it were publicly accessible.

That exposure gave researchers access to tooling, configuration records, and the AI session history.

The criminals built an elaborate AI-assisted intrusion operation and left enough of the machinery exposed for researchers to examine.

There’s a certain symmetry there.

Attackers exploiting misconfigured infrastructure got caught because of misconfigured infrastructure.

Cybersecurity really does come full circle.

But I wouldn’t count on attackers making the same mistake next time.

The Question I’d Ask Every MSP

If I were sitting across from a managed service provider discussing this research, I wouldn’t start by asking which AI security product they use.

I’d start with something simpler.

If an attacker gets one of your technician accounts, what stops them from pushing software across your customers?

Not:

Do you use MFA?

Not:

Do you have an EDR?

Not:

Are your technicians trained?

Those things matter.

But I want to understand the actual boundary.

Can one technician deploy to every customer?

Can an account operate outside approved maintenance windows?

Can one compromised session modify security controls?

Can the same identity access both endpoint management and backups?

Would the customer know?

Would the SOC notice?

Would the platform stop it?

And if the attacker tried to push the same malicious software across 30 companies, would anything force a second, independent authorization?

Those are the questions that determine the blast radius.

AI Didn’t Reinvent Ransomware. It Changed the Economics.

This is where I land on the SOCRadar research.

I don’t think this is evidence that autonomous AI has taken over cybercrime.

Humans were selecting targets.

Humans were approving actions.

Humans were preparing extortion.

The AI assisted with the work.

But that’s not a comforting distinction for defenders.

Because human-directed AI can still make criminals more productive.

It can help them troubleshoot faster.

Organize more information.

Work across more targets.

Reuse techniques.

And reduce how much specialist knowledge is needed for certain tasks.

That’s meaningful.

But the ways into the environment remain recognizable.

Exposed management systems.

Known vulnerabilities.

Stolen credentials.

Reused passwords.

Excessive administrative privileges.

Unrestricted remote-management capabilities.

Weak customer isolation.

AI may make the attacker faster. It doesn’t make the firewall, the identity system, or the RMM permissions irrelevant.

We still have ways to prevent and detect these attacks.

And many of them are things we should have been doing long before somebody gave ransomware an AI assistant.

So rather than worrying about whether Skynet is going to encrypt the network, I’d spend a little more time asking why one technician account can reach the entire customer base.

Because if the answer is:

That’s just how our management platform works.

Then AI isn’t your biggest problem.

Your trust model is.

Sources & Further Reading

SOCRadar’s October 20 research, updated October 23, provides the recovered attacker records, AI sessions, ransomware staging evidence, victim classifications, and detection guidance. SOCRadar
The Cloud Security Alliance’s October 24 analysis examines the human-approved AI operating model, threat attribution, evidence limitations, and security implications. Cloud Security Alliance
Anthropic’s September 2026 threat-intelligence report documents other cases of AI-enabled cybercrime and explains how agentic frameworks reduce the effort needed for familiar attacks. Anthropic
Sophos documents how DragonForce actors compromised SimpleHelp at an MSP and used legitimate remote-management capabilities against customer endpoints. Sophos
Sophos separately documents Qilin ransomware affiliates compromising ScreenConnect administrator access and targeting MSP customers. Sophos
The Canadian Centre for Cyber Security documents CVE-2026-35616 in FortiClient EMS, while Australia’s cyber agency documents active exploitation of CVE-2026-41940 in cPanel/WHM. Canadian Cyber Centre · Australian Cyber Security Centre
CISA’s ransomware guidance covers malicious RMM use, segmentation, privileged-access protections, and recovery controls. CISA
Australia’s Information Security Manual includes specific requirements for restricting third-party administrative access and independently auditing provider activity. Australian Cyber Security Centre