Hackers Launch Over 91,000 Attacks on AI Systems Using Fake Ollama Servers

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
920
4,327
2,168
Germany
A new investigation by GreyNoise reveals a massive wave of over 90,000 attacks targeting AI tools like Ollama and OpenAI. Experts warn that hackers are conducting “reconnaissance” to map out vulnerabilities in enterprise AI systems.
In a recent discovery, researchers have found that cybercriminals are turning their focus toward the systems that power modern artificial intelligence (AI). Between October 2025 and January 2026, a specialized honeypot (a trap set by security experts to catch hackers) recorded 91,403 attack sessions.

This investigation was conducted by the research firm GreyNoise, which set up fake installations of a popular AI tool called Ollama to act as bait. The research reveals that there isn’t just one group at work, but two separate campaigns are active, each trying to find a different way to exploit the growing world of AI.
Full Article here:
 
Full Article here:
What you quoted lines up with GreyNoise’s own write-up (dated January 8, 2026) and it’s best understood as “mass-scale reconnaissance and validation against exposed/self-hosted LLM infrastructure,” not “OpenAI the service is being directly hacked.”

What GreyNoise actually observed (high level)
  • GreyNoise ran an Ollama honeypot and recorded 91,403 attack sessions between October 2025 and January 2026.
  • They describe two distinct activity clusters:
    • An SSRF-style “make the server phone home” campaign (forcing outbound callbacks to attacker-controlled/OAST infrastructure) aimed at things like Ollama model-pull behavior and also Twilio webhook patterns seen alongside it.
    • A larger “enumeration” campaign starting December 28, 2025, where a small set of IPs methodically probed many LLM-related endpoints to fingerprint exposed deployments and misconfigured proxies (i.e., building target lists).

Key clarification: “targeting OpenAI” often means proxies/keys, not OpenAI’s cloud
A lot of enterprises put LLM access behind:
  • reverse proxies (NGINX/Traefik), “AI gateways,” or internal portals
  • self-hosted frontends (e.g., Open WebUI) talking to Ollama or to OpenAI-compatible APIs
  • API keys stored server-side and forwarded upstream
If those layers are exposed or misconfigured, attackers can enumerate capabilities, abuse the service, or potentially pivot to something worse. That’s materially different from compromising OpenAI’s own infrastructure.

Why this matters for defenders
Even “benign-looking prompts” can be useful to attackers because they reveal:
  • which model families/endpoints are reachable
  • whether auth is enforced
  • whether the system will fetch remote resources (SSRF risk)
  • version/bannering and other fingerprinting signals

Practical hardening steps if you run Ollama / OpenAI-compatible endpoints / LLM gateways
  • Do not expose Ollama/LLM APIs directly to the internet unless you have a strong reason. Bind to localhost/VPN-only; allowlist source IPs at the firewall.
  • Require authentication (and don’t rely on “security by obscurity” ports/paths).
  • Add rate limiting + abuse controls (requests/minute, concurrency caps) to reduce “cheap” enumeration and DoS.
  • Constrain outbound egress from the LLM/gateway host (SSRF mitigation): only allow necessary destinations; block link-local/metadata IP ranges; log denied egress.
  • Disable or strictly control remote fetch/pull features (anything that lets a user influence URLs the server will request—model registries, webhooks, tool-calling that fetches URLs, etc.).
  • Log and alert on suspicious patterns: high-volume 401/404s, unusual User-Agents, repeated model listing probes, and any unexpected outbound callbacks (OAST-style).

If someone is running these stacks at home or in a lab, the simplest safe takeaway is: keep Ollama/Open WebUI and any “OpenAI-compatible” endpoints off the public internet, or put them behind VPN + auth + firewall allowlisting.

Sources
 
Indicators of Compromise (IOCs)

Source IPs (Reconnaissance & Probing)


45.88.186.70

204.76.203.125

Behavioral Indicators
Rapid-fire outbound connection attempts to unknown external registries.

Repeated inbound API requests containing the "How many states..." prompt from a single source.

Logs showing unauthorized docker pull or model fetch requests.

Mitigation & Remediation
Enforce Registry Allow-Listing

Configure Ollama and similar AI middleware to only allow downloads from trusted, internal, or official registries (e.g., ollama.com). Block all other outbound HTTP/HTTPS requests from the AI server.

Network Segmentation (Critical)

Isolate AI Agents

Do not allow AI servers to sit on the same network segment as sensitive corporate databases or internal management interfaces. The "Phone Home" trick relies on the server having unrestricted outbound access.

Block Inbound
Ensure API ports (typically 11434 for Ollama) are not exposed to the public internet. Use a reverse proxy (Nginx/Apache) with authentication if remote access is required.

Input/Output Monitoring
Monitor logs for the specific IOC IPs listed above.

Implement rate limiting on API endpoints to block the rapid enumeration attempts described in Campaign 2.

Vulnerability Management
Ensure Ollama and Twilio integrations are patched to the latest versions to mitigate known SSRF vectors.

Analyst Note
As noted by Chris Hughes, the danger shifts rapidly from "probing models" to "exploiting agents" once they have access. Treat these probes as a precursor to a more damaging intrusion.
 
  • Like
Reactions: Zero Knowledge