The Uncensored AI Underground: When Attackers Stop Jailbreaking Models and Start Owning Them

The next generation of offensive AI may not come from a criminal chatbot on the dark web. It may come from an ordinary open-weight model, a few changes to its safety alignment, and a researcher or attacker who knows how to connect it to the right tools.

For years, we have been discussing how artificial intelligence could change cyberattacks. We have seen AI-generated phishing campaigns, automated vulnerability discovery, synthetic identities, malware development assistance, and increasingly sophisticated social engineering.

Much of the conversation has focused on whether attackers can trick commercial AI systems into generating malicious content. We have spent considerable time researching jailbreaks, prompt injection, safety bypasses, and the reliability of model guardrails.

However, I think we may be asking the wrong question.

Why would a sophisticated attacker spend hours trying to convince a commercial model to ignore its safety policies when they can download an open-weight model, modify its alignment, and operate it on infrastructure they control?

And why stop at generating malicious code? Why not give the model tools, memory, feedback, and the ability to decide what to do next?

That is where things become considerably more interesting.

We are moving from AI-assisted cybercrime toward AI-enabled offensive infrastructure. The distinction matters because the model is no longer simply answering questions. It is becoming part of the operational architecture.

The security industry has spent years looking for malware that communicates with command-and-control infrastructure. Now we need to consider malware and offensive frameworks that communicate with inference engines, and eventually malware that may bring its own model along for the ride.

Apparently, giving malware a brain was not enough. We may also need to worry about it bringing its own hardware requirements.

1. The underground AI market is not what many people think

When WormGPT and FraudGPT began receiving attention, the narrative was fairly straightforward: cybercriminals were developing their own malicious versions of ChatGPT.

There is some truth to that. Underground AI services have been advertised for phishing, fraud, malware development, and other criminal activities.

But the marketing and the underlying technology are not necessarily the same thing.

A criminal service advertised as an unrestricted AI hacking assistant may be a fine-tuned open-weight model, a lightly modified model with safety restrictions removed, a wrapper around a commercial API, or simply a scam.

The last possibility should not surprise anyone who has spent time studying cybercriminal marketplaces. Apparently, even criminals have to worry about dishonest vendors. There really is no honor among thieves, especially when someone is selling a lifetime subscription to an AI model.

The more important development is that attackers do not need to purchase an underground AI service at all.

They can assemble their own.

A modern offensive AI stack might consist of an open-weight foundation model, a quantized deployment, a local inference server, an agent framework, a collection of security tools, and a feedback mechanism for evaluating results.

None of those components is inherently malicious. Most are useful in legitimate security research, software engineering, and defensive automation.

What changes the risk is how they are combined and what permissions they receive.

2. The models worth watching

Not all unrestricted models are created equal. Some are optimized for conversational compliance, others for reasoning, coding, long-context analysis, or specialized tasks.

The following are particularly relevant to understanding the evolving offensive AI ecosystem.

DeepSeek V4.1 Flash, abliterated and uncensored variants

Two particularly interesting distributions are the OrcaRouter abliterated GGUF and the AtomicChat GSQ-RCO release.

Their significance is the combination of a large mixture-of-experts architecture, modified refusal behavior, and low-bit deployment options. They illustrate how alignment changes and inference engineering can make capable models accessible outside traditional hosted environments.

Dolphin Mistral

Dolphin-family fine-tunes emphasize instruction following and generally more permissive interactions. Their relevance is not that they are inherently cybercriminal models, but that permissive local assistants can be incorporated into offensive research workflows without relying on a commercial provider's content filtering.

Mistral Large

A capable general-purpose model family relevant to code analysis, planning, and tool orchestration. Unlike a specific Dolphin fine-tune, ordinary Mistral Large deployments should not automatically be characterized as unrestricted. Hosted safeguards, model versions, and deployment policies matter.

Qwen, GLM, and other open-weight coding and reasoning models

These model families are relevant because capability, cost, and deployability may matter more to an attacker than the marketing label uncensored. A strong coding model with reliable tool use can be operationally valuable even without a special criminal fine-tune.

DeepSeek: what abliteration actually changes

One of the more interesting developments is the growing popularity of abliteration, a technique intended to suppress learned refusal behavior by modifying selected directions in a model's internal representations.

This is different from writing a clever jailbreak prompt.

A jailbreak attempts to influence the behavior of an existing model at inference time. Abliteration modifies the model itself.

The OrcaRouter DeepSeek V4.1 Flash model card reports a substantial reduction in refusal behavior compared with its base checkpoint: 87.4 percent of 500 harmful prompts refused by the base model, versus 7.4 percent after abliteration. The only capability check on the card is a 300-question MMLU sample.

That is a dramatic behavioral difference.

However, a lower refusal rate is not the same as greater offensive capability.

A model may be more willing to generate an exploit while being no better at understanding the vulnerable code, identifying environmental constraints, producing a working proof of concept, or recovering from a failed attempt.

For an attacker, the real question is not whether the model says yes.

It is whether the model gets the job done.

The AtomicChat distribution adds another interesting dimension. Its publisher describes a refusal-direction edit applied to selected dense residual-writing tensors while preserving the quantized routed experts. The model card reports minimal changes on selected general reasoning benchmarks, although those tests do not establish equivalent cybersecurity performance.

This raises an important research question: can safety-related behavior be substantially changed without materially reducing the model's useful technical reasoning?

The early publisher results suggest this is possible for some measured tasks. Whether that extends to reliable multistage offensive operations remains an open question.

The hardware story is just as important

The DeepSeek variants also demonstrate why parameter count alone is becoming a misleading indicator of deployment feasibility.

The AtomicChat GSQ-RCO release describes low-bit variants that can use a 12 GB GPU, with the main backbone residing in system memory and a large Engram lookup table (about 110 GB) streamed from SSD storage.

That does not mean a model of this size (the card says 763B parameters in its introduction and 552B in its metadata) suddenly occupies only 12 GB of total system resources.

It means the deployment architecture separates GPU memory requirements from system memory and storage requirements. The published IQ2_XXS configuration is still about 138 GB of model data, or roughly 250 GB once the SSD-backed Engram table is included.

OrcaRouter takes a different quantization approach. Its Mix-256G build is a 346.5 GB download that needs about 236 GB of memory, while its smaller Mix-128G option trades substantial model fidelity for reduced memory requirements. The card itself calls the smaller build heavily degraded and not a substitute.

This is relevant to attackers because they can increasingly choose among speed, cost, model quality, and operational independence.

A cloud-hosted model may be fast and convenient. A local model may be slower but provides greater control over the inference environment. (We walked through what that local hardware actually looks like, and what fits on it, in our piece on the 512 GB M5 Ultra Mac Studio.)

For a criminal operation that runs for weeks or months, those tradeoffs can be more important than the latest benchmark leaderboard.

3. Dark-web AI versus self-hosted AI versus commercial AI

There are three broad deployment models to consider, with a fourth emerging around specialized cybersecurity services.

Deployment model	Operational attraction	Main limitations
Underground AI service	Low setup effort, marketed for prohibited tasks	Scams, logging, unreliable claims, vendor control
Self-hosted unrestricted model	Control over weights, prompts, telemetry, and tooling	Hardware, power, inference performance, maintenance
Commercial frontier API	High capability, convenient scaling, mature tool support	Policy enforcement, monitoring, rate limits, revocation
Specialized cyber AI service	Domain-specific training or evaluation, security workflow integration	Provider trust, cost, authorization, benchmark validity

An attacker who needs a one-off phishing message may not care about model hosting.

An attacker attempting to automate reconnaissance, vulnerability assessment, and post-compromise decision-making has a very different set of requirements.

They may value deterministic interfaces, structured outputs, context persistence, and reliable tool calls over conversational personality.

This is also why I think some of the excitement around dark-web AI services is misplaced.

The underground marketplace is interesting as an intelligence collection target. But technically, the more consequential trend is the commoditization of private inference.

A criminal does not need to purchase something called DarkGPT when they can operate an ordinary model without provider oversight.

Of course, self-hosting is not synonymous with anonymity. Infrastructure, payment records, model downloads, exposed services, and operational mistakes can still create investigative opportunities.

What about hosted unrestricted models?

Services advertising unrestricted inference occupy an interesting middle ground.

They offer many of the convenience benefits of an API without requiring the customer to maintain expensive inference infrastructure.

For attackers, that reduces deployment complexity. But it introduces another party that may log requests, impose restrictions, terminate service, or cooperate with investigations.

The word uncensored describes an advertised model behavior. It does not establish that a provider offers anonymous, unmonitored, or legally unconstrained access.

That distinction is particularly important when evaluating providers such as OrcaRouter. A Hugging Face repository published by an organization does not, by itself, establish what safeguards apply to every hosted service operated by that organization.

4. What makes a model effective at offensive security?

I would evaluate offensive AI capability across six dimensions rather than relying on general benchmarks or refusal rates.

A model can score well on coding benchmarks and still fail badly when faced with unfamiliar infrastructure.

Likewise, a permissive model may generate a plausible vulnerability explanation that is technically incorrect.

For threat hunting and adversarial simulation, the most interesting question is whether a model can operate inside a closed feedback loop.

Consider a controlled security research environment with intentionally vulnerable applications, synthetic identities, and isolated infrastructure.

An agent might examine application metadata, identify a potential weakness, request a permitted test, analyze the results, and update its assessment.

The important development is that the workflow no longer depends on a human manually interpreting every intermediate output.

The model becomes a reasoning component in a repeatable operational system.

That is a substantially more meaningful capability than simply asking a chatbot to write malware.

5. What real-world attacks are telling us

The strongest evidence that offensive AI is changing cyber operations does not come from unrestricted model download statistics.

It comes from incident investigations showing how models are being incorporated into actual intrusion workflows.

The ten-hour intrusion

In September 2026, Palo Alto Networks Unit 42 documented an incident involving an attacker who used frontier AI and specialized agent frameworks during an enterprise intrusion.

The investigation described an operation that compressed an estimated two weeks of human-led activity into less than ten hours, spanning more than 50 MITRE ATT&CK techniques.

The attacker used agents to examine internal services, identify exposed credentials, analyze repositories, interact with cloud infrastructure, and coordinate subsequent actions.

What interests me is not simply the reported speed.

It is the division of labor.

The human operator established objectives and controlled the operation. Specialized agents handled tactical activities and exchanged information through structured files and tool outputs.

This is similar to the architectural direction we see in legitimate agentic security systems: one component handles reconnaissance, another evaluates findings, another performs permitted validation, and another manages results.

The technology is not inherently offensive or defensive.

The difference is authorization, objective, and control.

There is another important lesson here. The attacker did not need an entirely new exploitation technique. Much of the advantage came from automating established tradecraft.

That may be more concerning than a hypothetical AI discovering a spectacular zero-day vulnerability.

Organizations already struggle to respond quickly to familiar attacks. Compressing the timeline from days into hours makes that problem considerably worse.

Claude was already being misused in real operations

Anthropic's September 2026 threat intelligence reporting described misuse involving suspected state-sponsored actors, financially motivated criminals, and other threat groups.

Its investigations included examples of malicious operators using Claude as an orchestrator rather than simply as a source of technical answers.

Earlier reporting on the GTG-1002 espionage campaign described a coordinated operation targeting approximately 30 organizations, with AI conducting a substantial portion of tactical activity under human direction.

This is an important counterpoint to the assumption that attackers must use unrestricted models.

They do not.

Some attackers are willing to exploit the capabilities of guarded commercial models and work around their restrictions.

Others may prefer self-hosted models because they eliminate dependence on a commercial provider.

The two approaches are not mutually exclusive. A sophisticated operation could use different models for different tasks, depending on their capabilities, cost, and availability.

The evidence supports AI-assisted and AI-orchestrated intrusion activity. It does not yet establish that the specific AtomicChat and OrcaRouter DeepSeek variants discussed here have been deployed in those campaigns.

That is an intelligence gap worth investigating, not a conclusion worth inventing.

6. CLOSEDQUORUM: malware that asks AI what to do next

One of the most interesting examples of this architectural transition is CLOSEDQUORUM, analyzed by Cisco Talos in September 2026.

The malware does not carry a local language model.

Instead, it delegates decisions to external LLM services.

Talos identified integrations for DeepSeek, Qwen, Mistral, and Gemini. The implant queries the available models, collects their decisions, and selects an action through a voting mechanism.

This is not traditional command and control.

The LLM services are providing tactical decision support, while the implant already contains the capabilities needed to execute those decisions.

The interesting part is that the attacker can reduce the need for continuous human interaction.

But we should be precise about the evidence. Talos did not confirm deployment in the wild, and the publicly distributed binary contained placeholder credentials. Its static analysis and development artifacts nevertheless established the underlying design.

The distinction matters. We have a documented autonomous C2 architecture, not proof of a widespread operational campaign.

And the architecture has weaknesses.

It depends on external services. Those services can refuse requests, become unavailable, impose limits, or generate malformed responses. The implant also creates potentially identifiable network activity.

That leads to the next logical development.

What happens when the attacker removes the external providers entirely?

7. The next evolution: malware that carries its own model

For years, the practical objection to embedding language models in malware was straightforward.

The models were too large, the hardware requirements were unreasonable, and the inference overhead would make the payload difficult to conceal.

Those objections are becoming less absolute.

In October 2026, Anthropic researchers William Zhou and Daniel Freeman published experiments examining autonomous replication using smaller models on inexpensive hardware.

Their research demonstrated that small models could establish inference across a variety of unfamiliar devices, although reliably completing an entire autonomous replication chain remained a significant challenge.

Meanwhile, the Colibri inference project demonstrates an approach to running large mixture-of-experts models using hierarchical storage and compute.

Its architecture can place frequently used components on GPU, other components in system memory, and less frequently accessed model data on NVMe storage. The project supports CPU inference and GPU acceleration through different backends.

This does not mean a frontier model can run efficiently on every compromised endpoint.

Inference throughput, memory pressure, storage bandwidth, and power consumption remain important constraints.

But the architectural barrier is changing.

Instead of asking whether a victim machine has enough GPU memory to hold an entire model, we can ask whether a smaller or quantized model can execute useful decisions using the resources available.

And an attacker does not necessarily need a model capable of solving every problem.

A model that performs one constrained task reliably may be sufficient.

Why model weights change the detection problem

There is another technical distinction that I think deserves attention.

Traditional process-injection detection frequently examines executable memory regions, suspicious allocation permissions, thread behavior, and evidence of code executing outside expected modules.

Model weights are different.

They are data, not executable instructions.

An inference runtime may load them through ordinary file mappings, including read-only mapped pages. The presence of those mappings does not inherently resemble classic shellcode injection.

This creates an interesting defensive challenge.

A large mapped model file is not necessarily suspicious in a browser, development workstation, AI application, or research server.

However, unexpected model artifacts and inference activity on an endpoint can be highly informative.

The important signals may include unusual model-file provenance, changes in mapped-file behavior, unexpected inference libraries, sustained CPU or GPU activity, and suspicious interactions between the inference process and other system capabilities.

There are limits to this hypothesis. File-backed model weights still have storage and mapping artifacts, and an inference runtime still requires executable code. Mapping weights into an unrelated process does not magically make that process capable of running inference.

The more plausible risk is misuse of legitimate inference infrastructure or an unauthorized inference runtime operating where one is not expected.

In other words, we should stop assuming that every malicious AI workload will look like a suspicious executable contacting a recognizable AI API.

Some may look like ordinary local computation.

And that is a substantially more difficult problem.

8. OpenAI Daybreak, Claude, and the trusted-access dilemma

There is an important policy and operational distinction between an unrestricted open-weight model and a frontier model made available to vetted security researchers.

OpenAI and Anthropic have both introduced programs intended to give authorized security practitioners access to more capable cyber functionality without eliminating provider oversight.

OpenAI Daybreak, Trusted Access for Cyber

Daybreak Blue is intended for approved defensive cybersecurity workflows with reduced refusals. Daybreak Red provides separately approved access to specialist cyber models. Identity, workspace, model access, and authorized scope remain controlled (OpenAI).

Anthropic Claude, Cyber Verification Program

Anthropic's October 2026 expansion includes Defense Access, Red Team Access, and Specialized Access. These tiers provide different levels of cybersecurity functionality and safeguard reduction, with additional verification for higher-risk activities and environments.

This creates an interesting asymmetry.

Legitimate security researchers often operate within enterprise policies, legal authorization requirements, data-handling rules, and vendor restrictions.

Criminal operators do not generally worry about obtaining written authorization before attacking someone.

A researcher may need approval to evaluate a model against an exploit-development benchmark. An attacker may simply download a permissive model and start experimenting.

But it would be a mistake to conclude that removing restrictions automatically gives attackers better technology.

Frontier commercial models may offer superior reasoning, debugging, context management, and tool integration compared with many unrestricted alternatives.

That is why vetted access matters.

The goal should not be to eliminate safety controls indiscriminately. It should be to provide qualified defenders with the capabilities needed to investigate realistic threats while maintaining meaningful authorization and accountability.

A defensive researcher who cannot evaluate offensive techniques is working with an incomplete threat model.

At the same time, unrestricted agentic execution without appropriate boundaries creates serious operational risk, even in an otherwise legitimate environment.

The problem is not simply whether a model refuses.

It is whether the organization can control what the model is permitted to do.

9. Building an adversarial AI hunting laboratory

One of the research directions I find particularly interesting is using multiple models in a coordinated environment to understand how AI-assisted attacks develop and how defenders can identify them.

Rather than evaluating a model exclusively through prompts, I would build an isolated research environment with several specialized agents.

The objective would be to measure what the models can accomplish against authorized targets, how reliably they operate, and what observable evidence they produce.

The research becomes much more useful when models are evaluated against the same workloads.

For example, I would compare a conventional Mistral deployment, a Dolphin fine-tune, an abliterated DeepSeek variant, and an appropriately authorized frontier cyber model.

The evaluation should include both benign and adversarial tasks.

A model should be able to explain a vulnerability, identify the relevant code path, evaluate a patch, interpret scanner results, and distinguish a real weakness from a false positive.

It should also demonstrate whether it can preserve context across multiple tasks, correctly interpret failed tests, and avoid inventing successful results.

One of the most dangerous behaviors in agentic security is not necessarily maliciousness.

It is confidence.

A model that incorrectly declares an exploit successful can send an entire automated workflow down the wrong path. An agent that hallucinates a vulnerability can waste hours of compute and analyst time.

The same failure modes that frustrate defenders can also limit attackers.

Proposed research projects

I would prioritize four experiments.

Project 1: Abliteration versus actual cyber capability. Compare base and refusal-modified models on the same controlled vulnerability-analysis and patch-validation tasks. Measure not only willingness to respond but technical correctness, repeatability, and successful validation.

Project 2: Local versus hosted inference. Evaluate throughput, cost, model quality, telemetry, and operational overhead across self-hosted and API-based deployments. Include the effect of quantization and SSD-backed inference on performance.

Project 3: Agentic attack-chain emulation. Use intentionally vulnerable environments to measure how reliably different models can complete authorized multistage tasks. Record every decision, tool invocation, failure, and recovery attempt.

Project 4: Unauthorized inference detection. Develop detection hypotheses for model files, inference runtimes, unusual resource consumption, unexpected AI API access, and agentic tool-use patterns on enterprise endpoints.

These experiments would provide something more valuable than another list of dangerous models.

They would tell us which capabilities actually matter.

10. How defenders should hunt for offensive AI

I do not think defenders should focus exclusively on identifying the model used by an attacker.

The same model may be used by a university researcher, a software engineer, a legitimate penetration tester, and a criminal operation.

The model name is useful context, not proof of malicious activity.

A better hunting strategy examines the relationship between model execution and security-relevant behavior.

Hunting hypothesis	Potential evidence	Investigation priority
Unauthorized local inference	Unexpected GGUF files, inference libraries, large mapped regions	Model provenance and execution context
AI-driven tool orchestration	Repeated structured tool calls, rapid analysis-execution cycles	Correlation with privileged operations
Commercial API misuse	AI API traffic from unusual processes or identities	Endpoint-to-network correlation
Compromised AI infrastructure	Unexpected inference consumption, unfamiliar API keys, new workloads	Identity and cloud audit trails
Agentic intrusion behavior	Rapid sequential discovery, authentication, repository access, and infrastructure changes	Cross-domain behavioral analytics

The critical point is correlation.

A developer downloading a GGUF file is not inherently suspicious.

An application invoking a commercial AI API is not inherently suspicious.

A process using several gigabytes of memory is not inherently suspicious.

But an unauthorized process loading model weights, initiating unusual service discovery, and subsequently interacting with sensitive enterprise resources deserves attention.

Defenders should also recognize that some future attacks may not expose any external inference traffic.

That makes endpoint visibility, application provenance, identity monitoring, and behavioral analytics increasingly important.

It also creates opportunities for deception.

Controlled environments containing synthetic credentials, instrumented repositories, and decoy services may help identify automated agents that indiscriminately process and act upon discovered information.

For defenders, the objective is not simply to detect AI.

It is to detect unauthorized behavior, whether the decision came from a human, a script, or a language model.

11. The real danger is not an uncensored chatbot

I suspect the next significant development in offensive AI will not be a revolutionary underground chatbot.

It will be an improvement in orchestration.

We already have models that can reason about vulnerabilities, analyze code, interpret tool output, and recommend technical actions.

We have frameworks that coordinate specialized agents.

We have local inference engines that reduce dependence on commercial infrastructure.

And we have quantization techniques that make increasingly large models usable on more accessible hardware.

What remains difficult is getting these components to work reliably together over long periods, especially when they encounter unfamiliar environments and unexpected failures.

That difficulty should not be underestimated.

But it should not be mistaken for a permanent barrier either.

The historical evolution of offensive tooling has repeatedly followed a familiar pattern: a capability begins as specialized research, becomes packaged into reusable frameworks, and eventually becomes accessible to operators who do not fully understand the underlying technology.

Artificial intelligence is unlikely to be an exception.

The real concern is not that every cybercriminal will suddenly become an expert exploit developer.

It is that increasingly capable systems may allow operators to accomplish more with less expertise, less time, and fewer people.

For defenders, that means the window between initial compromise and significant impact may continue to shrink.

For researchers, it means we need to stop measuring offensive AI exclusively by whether a model answers prohibited questions.

We need to measure what it can actually accomplish, how consistently it accomplishes it, and what evidence it leaves behind.

And for the organizations developing these models, it means finding ways to give legitimate security researchers meaningful access to advanced capabilities without simply abandoning the safeguards that make widespread deployment possible.

The security community has a tendency to become fascinated with the latest tool.

WormGPT. FraudGPT. Dolphin. DeepSeek. The next abliterated model with an increasingly ridiculous name.

But the model is only one part of the equation.

The real change happens when an AI system stops being a source of answers and starts becoming an operator.

That is the development I think deserves our attention.

Because the next generation of attackers may not need to be better hackers.

They may simply need to be better managers of machines that can hack.

And apparently, even cybercrime is getting middle management.

Sources and further reading

• OrcaRouter, DeepSeek V4.1 Flash 1017 abliterated GGUF model card
• AtomicChat, DeepSeek V4.1 Flash 1017 Uncensored GSQ-RCO GGUF model card
• Palo Alto Networks Unit 42, AI-assisted cyber attack: inside a Unit 42 investigation (Sept 2, 2026)
• Anthropic, Detecting and countering misuse of AI: September 2026
• Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign (Nov 13, 2025)
• Cisco Talos, The closed quorum: inside the first reported autonomous AI C2 implant (Sept 22, 2026)
• Anthropic, AI models may be capable of self-replicating without access to a datacenter (Oct 12, 2026)
• Colibri on GitHub
• OpenAI, Models and Trusted Access (Daybreak)
• Anthropic, Expanding the Cyber Verification Program (Oct 6, 2026)
• Maxime Labonne, Uncensor any LLM with abliteration
• The Record, WormGPT coverage (July 2023), and Netenrich, FraudGPT (July 2023)
• Earlier on this site, Half a Terabyte on Your Desk: the 512 GB M5 Ultra Mac Studio, Open weights, Mistral Large 4, and Dolphin, and ATT&CK v20 and prompt injection