Deadbugz Beyond MCP: Extortion Artifacts in Exposed Ollama Models
On August 12, Pillar Security published research on a Deadbugz-linked MCP supply-chain campaign. Their report described a malicious MCP server that initially looked harmless, then changed the metadata it returned to an AI agent after several normal tool calls.
This post is being published on the same day, August 12, as Pillar’s disclosure. The overlap is timing and the Deadbugz marker; the research focus is different. Pillar documented MCP supply-chain delivery. This post documents Deadbugz-linked artifacts observed in exposed Ollama model metadata.
While reviewing exposed AI infrastructure, we found a different Deadbugz-linked pattern.
This threat intelligence research was conducted by Karacena in collaboration with Redpoint Cyber, a cybersecurity firm specializing in incident response, digital forensics, threat hunting, and managed detection and response.
This finding was not about MCP configuration pull requests. It was about exposed Ollama servers carrying attacker-created model artifacts. The same Deadbugz marker and Bitcoin wallet appeared inside model metadata, but the delivery surface was different: unauthenticated Ollama APIs and locally created model definitions.
We are not publishing victim IP addresses, providers, hostnames, usernames, or raw host evidence. The purpose of this post is to document attacker tradecraft and help defenders recognize the pattern without identifying affected systems.
We did not modify, delete, upload, or execute anything on third-party systems. No authentication was bypassed, no credentials were used, and no private user data is included here. The findings are based on limited, non-destructive review of metadata exposed by unauthenticated endpoints, with victim-identifying details removed.
What We Observed
The exposed Ollama instances contained suspicious models with names that imitate premium commercial AI models:
gpt-4o:latest
gpt-4:latest
claude-3-opus:latest The names are the first trick. To an operator quickly looking at a model list, they can look like valuable models someone installed. They are not. In the observed artifacts, those names pointed to the same underlying extortion model.
The campaign also used:
- tinyllama:latest as the base model
- verif_sys:latest as a staging or verification model
- a recurring Deadbugz extortion message
- the same Bitcoin wallet also listed in public Deadbugz reporting
That matters for a different reason. Not just that someone left a ransom message, but that the attacker used the model layer itself as the delivery mechanism.
The Model Was the Message
The malicious model definition contained an extortion instruction in the system prompt and reinforced it through conversation history. In plain language: the model was configured to keep repeating the attacker’s message.
The extortion message itself was short and blunt:
Unfortunately, we've discovered a flaw in your system & found our way in
Make a donation to our BTC wallet we're a small business & we employ
many engineers to make your software safer and bugless!
-deadbugz
BTC: bc1q5xpazlg7q6ph2r6s7tzumd5zyjdet6vjzvsqln
In the model metadata, this message appeared as a system-level instruction and was reinforced through conversation history so the model would keep repeating it.
If the owner later tries to use the fake `gpt-4o` or `claude-3-opus` model, the model itself becomes the ransom note.
Why the Fake Model Names Matter
The model names are social engineering.
The attacker did not call the models `ransom-note` or `infected-model`. They used names that look familiar and valuable. That creates ambiguity for the system owner:
- “Why is GPT-4o on my Ollama server?”
- “Did someone install Claude locally?”
- “Is this a cloud model?”
That confusion buys the attacker time. It also makes the compromise look less obvious in a long model list.
This is one of the more important lessons from the case: in AI infrastructure, names and metadata are part of the attack surface.
The Staging Model
The recurring staging artifact was:
verif_sys:latest
Its observed role was simple: confirm that the attacker-controlled model creation worked.
The associated instruction was effectively:
Reply with a fixed verification string.
We are deliberately not publishing live host validation output. The relevant defensive point is enough: if `verif_sys:latest` appears next to `tinyllama:latest`, especially on an exposed Ollama instance, treat it as suspicious.
In the dataset we reviewed, some systems showed only the staging pattern. Others had the full extortion model set. That supports a two-stage workflow:
- Prepare the host with a base model and verification artifact.
- Later create the fake premium model names carrying the extortion prompt.
The Strongest Technical Finding: Local Model Creation
The strongest update in the research is about the attack path.
At first, it was tempting to think the attacker pushed ready-made models from somewhere else. The metadata does not support that.
In hundreds of model artifacts, the `FROM` path reflected the victim system’s local filesystem layout. The paths varied by operating system and installation style:
/root/.ollama/models/blobs/...
/usr/share/ollama/.ollama/models/blobs/...
C:\Users\\.ollama\models\blobs\...
/Users//.ollama/models/blobs/...
custom mounted model paths
We are redacting usernames and host-specific paths, but the pattern matters.
If the attacker had pushed a prebuilt model from one external machine, the source path would be consistent. It was not. The source path changed with the local environment.
That points to model creation happening on the exposed Ollama server itself, using the server’s local base model blob.
In other words: the exposed model-management API was enough.
Scale Observed
In one large scan window, 2,403 candidate services were checked and 1,861 responded. Within that dataset, 257 matched the full Deadbugz extortion profile and 374 matched the staging-only profile.
Across all reviewed datasets, we observed 266 full-profile matches and 381 staging-only matches.
These numbers reflect what we observed in specific scan windows. The actual scale may be larger, because this was a time-bounded review rather than a continuous global census.
We are not publishing country breakdowns, IP addresses, providers, hostnames, or victim-specific notes. Those details are not needed for defenders to understand the threat.
The important point is that this was not a single misconfigured server. The same pattern appeared repeatedly.
Timing Clues
The metadata timestamps also showed a consistent order:
- `tinyllama:latest` appeared before the extortion models
- the fake premium model names appeared later
- some systems had a short gap between the base model and the extortion models
- some systems had a much longer gap, suggesting the attacker returned later
In a subset of cases, the delay between base model availability and extortion model creation clustered around roughly 30 seconds. We would not overstate this as definitive source-code proof, but it is consistent with an automated tool that waits briefly after preparing the base model.
How This Relates to Pillar’s Deadbugz MCP Report
Pillar’s report describes Deadbugz activity in the MCP ecosystem: malicious tool metadata returned to AI agents after a runtime trigger.
This post describes a different surface: exposed Ollama model metadata and locally created model definitions.
The overlap is the Deadbugz marker and Bitcoin wallet. The delivery mechanism is different.
The safest conclusion is:
Deadbugz-linked activity appears across more than one AI-native attack surface.
Not just MCP.
Not just model hosting.
The common theme is attacker control over AI metadata that downstream users or agents may trust.
What Defenders Should Look For
Check exposed or internally reachable Ollama instances for unexpected model names, especially:
gpt-4o:latest
gpt-4:latest
claude-3-opus:latest
verif_sys:latest
The names alone are not proof of compromise in every possible environment, but in Ollama they should raise immediate questions.
Also look for this combination:
tinyllama:latest
verif_sys:latest
one or more fake premium model names
Review model metadata for:
- unexpected system prompts
- extortion language
- repeated assistant messages forcing a fixed response
- identical digests reused under different model names
- local `FROM` paths that do not match expected administrative activity
- model creation timestamps that do not match deployment history
Public IoCs
Actor marker:
deadbugz
Bitcoin wallet:
bc1q5xpazlg7q6ph2r6s7tzumd5zyjdet6vjzvsqln
Suspicious Ollama model names:
gpt-4o:latest
gpt-4:latest
claude-3-opus:latest
verif_sys:latest
Base model commonly used:
tinyllama:latest
Base blob observed:
sha256-2af3b81862c6be03c769683af18efdadb2c33f60ff32ab6f83e42c043d6c7816
Extortion model digest observed across fake premium names:
4a930c1ab184426363dd329cd5d0fb27a2c28c4465a2be4c82031b5e7fd6bd26
Related MCP-side public indicator from Pillar reporting, not an Ollama artifact:
~/.config/.cache/.sys/.deadbug-mcp.py
We are intentionally not publishing endpoint domains, GitHub usernames, victim IP addresses, hostnames, provider names, local usernames, or raw host-level artifacts.
Remediation
If you operate Ollama, the immediate defensive steps are simple:
- Do not expose Ollama directly to the public internet.
- Bind Ollama to localhost unless remote access is explicitly required.
- Put authentication and network access control in front of any remote access.
- Restrict access with firewall rules, VPN, or private networking.
- Review the local model catalog for unexpected models.
- Remove suspicious models only after preserving evidence if this is an incident.
- Rotate credentials if the system also exposed other services or logs.
- Do not run Ollama as root unless you have a very specific reason and compensating controls.
- Monitor model creation events and model metadata changes.
- Treat model definitions, tool descriptions, and AI metadata as security-sensitive configuration.
For many teams, the uncomfortable lesson is this: an unauthenticated AI service is not just an inference endpoint. It can become a writable control plane.
Why This Matters
Traditional security teams already know that exposed Redis, Docker API, Kubernetes API, Elasticsearch, and database ports are dangerous.
Ollama belongs in that same mental bucket when it is exposed without authentication.
The difference is that the artifacts look AI-native:
- model names
- system prompts
- tool metadata
- assistant messages
- local model blobs
That can make the compromise feel less familiar, even when the underlying mistake is old. The old mistake is still the same: a management surface was reachable without authentication. The new part is what attackers can now store there.
Attackers are adapting to the AI stack quickly. Not only stealing API keys or abusing cloud inference. They are learning where AI systems store trust.
Sometimes that trust is in a model name.
Sometimes it is in a tool description.
Sometimes it is in metadata nobody thought to monitor.
