I run a fake Ollama server on a Contabo box as part of an LLMjacking honeypot. The idea is simple: advertise port 11434 to the internet, serve fake model tags, capture every request, alert on anything that walks the hunt path to a planted API key. Most of the traffic is scanners poking /api/tags and leaving. One source IP did not leave.
Over seven days, 138.201.134.111 sent 250,669 connections to the Ollama endpoint. Not scanning. Sending full inference requests. Structured, batched, same template every time, requesting llama3.1:70b-instruct-q4_0 with stream: false and temperature: 0.1. I pulled the captures and found a pipeline.
The prompt
Every request follows the same template. The system instruction opens with:
You are an elite cyber threat intelligence analyst and native {language} copywriter. Your mission is to COMPOSE a highly natural, factual, and flawless cybersecurity threat report directly in the target language {language} from scratch.
Then a <domain_metadata> block with the target domain, registrar, IP address and ASN, VirusTotal detection count, blocklist hits, impersonated brand, drainer type, and scam classification. Then a reference English report, several hundred words of analysis including Gridinsoft trust scores, SSL cert details, hosting tech, and blocklist membership. The instruction: rewrite it natively in the target language, not translate, as three XML elements: <title>, <description>, <summary>.
Each domain gets the same prompt in ten languages: French, Spanish, German, Russian, Chinese, Hindi, Japanese, Portuguese (Brazil), Arabic, Turkish. Ten requests per domain, fired in about thirty seconds, then the pipeline moves to the next domain.
The volume
| Date | Captures |
|---|---|
| Sep 5 | 1,550 |
| Sep 6 | 940 |
| Sep 7 | 2,815 |
| Sep 8 | 40,670 |
| Sep 9 | 184,045 |
| Sep 10 | 8,857 |
| Sep 11 | 11,435 |
| Sep 12 | 5,448 (partial day) |
The Sep 9 spike is roughly 18,000 domains processed through unauthorized compute in a single day. Total captures in seven days: 254,900.
The scam types being catalogued read like a phishing-intel feed: credential phishing, crypto scam, gaming scam, brand impersonation, investment scam, crypto drainer, fake exchange. Top impersonated brands: Steam, Facebook, Coinbase, Raydium, Solana. The domains are real and current, many of them flagged on VirusTotal with double-digit detections.
Who
The source IP is a Hetzner box. Nmap shows nginx on 80 and 443, nothing else open. The TLS certificate on 443 has CN botadmin.destroy.tools and organization PhishDestroy.
PhishDestroy is a volunteer-run anti-phishing operation, active since 2019. Legitimate, effective, and well-connected: their blocklist feeds go to Cloudflare, Google Safe Browsing, VirusTotal, and about fifty other vendors. They've coordinated over 152,000 takedowns. Their own about page describes "automated classifiers" and "a strong AI layer."
Port 11434 is filtered on the box, though that tells us nothing about what runs behind the firewall.
The self-reference
Here's the part that made me put my coffee down.
One of the captured prompts analyzes somosqualidade.com.br, a Facebook phishing domain. The reference summary in the prompt, the English text the model is told to rewrite, includes this line:
the site is listed on two public phishing blocklists (PhishDestroy and PhishingDB)
PhishDestroy is cited in their own prompt as one of the blocklists that flagged the domain they're asking someone else's compute to write a report about. I checked the public report on phishdestroy.io/domain/somosqualidade.com.br: VirusTotal 15/91, targeted brand Facebook, IP 50.116.87.104. The values in the captured prompt match exactly.
The public domain reports show a subset of the fields in the captured prompts. The extra fields (registrar, ASN, scam type, drainer type, Gridinsoft trust score) come from their internal analysis pipeline, the same analyze.destroy.tools backend. No third party has access to this enriched dataset. The prompts are generated from PhishDestroy's own database.
What the output looks like
I fed the same prompt template to a locally-served open model to see what the pipeline produces. The English output:
<title>Apple Impersonation Scam Runs on Cloudflare</title>
<description>The domain spacexshipbob.com impersonates Apple to harvest
user credentials. Registered through NameSilo, LLC, the site resolves to
188.114.97.3 on AS13335 Cloudflare, Inc. VirusTotal detections stand at
2 out of 91, with a single blocklist hit recorded.</description>
<summary>The domain spacexshipbob.com targets Apple users through brand
impersonation, presenting a fake interface designed to capture login
credentials. The site is hosted behind Cloudflare's network at IP
188.114.97.3 and was registered via NameSilo, LLC. With only 2 detections
from 91 VirusTotal engines and a single blocklist flag, the threat remains
under-reported. Organizations should proactively block this domain and
monitor for related infrastructure on the same nameservers.</summary>
Clean, structured, publication-ready. The prompt does all the work. Any open model with decent instruction-following produces usable output, which is exactly why scanning for exposed Ollama instances and firing requests at whatever model is loaded is a viable strategy.
The request metadata
The HTTP headers are deliberately clean. User-Agent is Python-urllib/3.12, no custom headers, no API keys, no referrer, no X-Forwarded-For. The source IP is the only fingerprint, and the only reason it ties to PhishDestroy is the TLS certificate on a different port of the same box. If they'd proxied through a clean IP, there'd be nothing to connect.
The bigger picture
Sysdig reported a 376% rise in credential theft targeting AI services between Q4 2025 and Q1 2026. Researchers have catalogued 175,000 exposed Ollama instances across 130+ countries, all listening on 11434 with no authentication by default. Every reported case so far has been criminal: stolen API keys resold, or autonomous exploit frameworks running on jacked boxes.
PhishDestroy has coordinated 152,000 phishing takedowns and feeds blocklists to vendors that protect millions of users. They're funding their multilingual report pipeline with unauthorized inference cycles from exposed Ollama servers.
None of the ten languages appear anywhere on their public channels.
Their Telegram alert channel (@destroy_phish) posts structured English-only alerts: emoji headers, domain, registrar, host IP, VirusTotal link. The format is similar in shape to the XML output but much simpler and never multilingual. Their HuggingFace dataset (phishdestroy/destroylist) is a bare domain list with four fields: domain, source, status, first_seen. No title, no description, no summary. Their AlienVault OTX pulse has 324,702 indicators, updated hourly, and every single description is the string "PhishDestroy detection". No prose, no translations, no rich metadata.
So where do ten languages of native-quality threat prose go if not to any public feed?
The most plausible answer is their abuse-reporting pipeline. PhishDestroy's documentation emphasizes automated complaints to registrars and hosting providers as a core function. They've filed 50,000+ abuse reports. Their own escalation documentation lists "AI-analyzed threat summaries" as a component of follow-up reports sent to unresponsive registrars. A rigid English complaint sent to a German registrar, a Turkish hosting provider, or a Brazilian domain authority gets deprioritized or filtered. A complaint written in fluent native prose, structured as a formal threat report with specific technical indicators, gets read. Ten languages maps well to the registrar landscape they'd be working at scale: French (OVH, Gandi), German (Hetzner, DENIC), Spanish (Latin American registrars), Russian, Chinese, Japanese, Arabic, Turkish, Hindi, Portuguese. Each one is a jurisdiction where English-language abuse reports hit a wall.
The XML structure supports this too. The <title>, <description>, <summary> format is built for machine parsing, not human reading. Their botadmin backend likely strips the tags and routes the content into templates, ticketing systems, or internal dashboards where regional operators handle specific geographies. The prose never surfaces publicly because it was never meant to. It's operational tooling for takedown velocity.
Whatever the destination, the compute isn't theirs.
What I can't tell you
Attribution in this case is circumstantial, not confessed. The chain is: source IP's TLS cert names botadmin.destroy.tools with organization PhishDestroy, the prompt content matches their database field-for-field, references their own platform by name, and uses enriched data only available from their internal analysis pipeline. Someone else could theoretically be using PhishDestroy's botadmin server as a relay. I think that's unlikely given the data match, but I'm not going to pretend it's impossible.
I also can't prove the abuse-mailbox theory. It's the explanation that best fits the evidence: ten languages of formal prose, no public output, an organization that files thousands of abuse reports to international registrars. But I don't have a captured abuse email to confirm it.
If you run an exposed Ollama instance
You probably already know, but: Ollama ships with no authentication on port 11434. If it's reachable from the internet, anyone can send inference requests and you're paying the compute bill. Bind it to localhost or put it behind authentication. The 175,000 exposed instances aren't all being used for this specific campaign, but they're all available to it.
IOCs
| Indicator | Value |
|---|---|
| Primary source IP | 138.201.134.111 (Hetzner, NL) |
| TLS cert CN | botadmin.destroy.tools |
| TLS cert Org | PhishDestroy |
| Secondary IP (email infra) | 140.233.190.111 (mail.navi.land) |
| User-Agent | Python-urllib/3.12 |
| Requested model | llama3.1:70b-instruct-q4_0 |
| API endpoint | /api/generate (Ollama native) |
| Peak volume | 184,045 requests / day (Sep 9, 2026) |
| Languages | FR, ES, DE, RU, ZH, HI, JA, PT-BR, AR, TR |
Captured on infrastructure I own and operate as a research honeypot. The bait server never returned real inference results. No attacker systems were accessed, modified, or disrupted. The Ollama endpoint is an advertise-don't-serve trap: it hands back model tags and captures requests, nothing more.