Skip to content
AI Security Wire

Published

- 5 min read

By

Threat Actors Are Systematically Scanning Enterprise LLM Deployments

img of Threat Actors Are Systematically Scanning Enterprise LLM Deployments

GreyNoise honeypots captured 91,403 attack sessions targeting enterprise LLM infrastructure between October 2025 and January 2026, across two operationally distinct campaigns. The scale alone is notable. But what makes this intelligence significant is the specificity of the targeting: attackers methodically enumerated 73 distinct model endpoint variants across every major AI provider, using innocuous test prompts designed to avoid detection while confirming whether a live model was listening. This was not opportunistic scanning. It was a systematic inventory operation.

Two Campaigns, One Expanding Attack Surface

GreyNoise’s honeypot network identified two campaigns running in overlapping timeframes, using different techniques against different parts of the LLM deployment stack.

The first, which GreyNoise calls the SSRF campaign, ran from October 2025 through January 2026. It targeted outbound request mechanisms in two specific products: the model pull functionality in Ollama, and Twilio webhook integrations via the MediaUrl parameter. The attack technique is straightforward. By supplying a malicious URL to a system that makes outbound HTTP requests, an attacker forces the server to connect to attacker-controlled infrastructure. GreyNoise observed the campaign using ProjectDiscovery’s OAST infrastructure for callback validation, which is a common technique in automated vulnerability scanning. The SSRF campaign originated from 62 IPs across 27 countries and produced a distinctive JA4H fingerprint (po11nn060000…) in 99% of requests, consistent with shared Nuclei automation tooling. Peak activity hit 1,688 sessions in a 48-hour period over Christmas.

The second campaign, running December 28 through January 8, was different in character. Two IP addresses generated 80,469 enumeration sessions in 11 days. That is not scanning noise. That is a deliberate, sustained operation.

The Enumeration Campaign: 80K Requests, Two Addresses

The two IPs at the center of the enumeration campaign are 45.88.186.70, operating from AS210558 (1337 Services GmbH), and 204.76.203.125, operating from AS51396 (Pfcloud UG). Together they generated 49,955 and 30,514 sessions respectively. GreyNoise’s sensor network has logged over 4 million hits from these addresses across broader internet scanning activity, and both have histories of CVE exploitation, including recent activity tied to CVE-2025-55182 and CVE-2023-1389 among more than 200 others on record.

The enumeration campaign tested both OpenAI-compatible and Google Gemini-compatible API formats, covering 73 model endpoint variants across all major families: GPT-4o variants, Claude Sonnet, Opus, and Haiku, Llama 3.x, DeepSeek, Gemini, Mistral, Alibaba Qwen, and xAI Grok. The goal was to identify which commercial AI APIs, if any, were exposed without authentication behind misconfigured proxy servers.

What the attackers were hunting: enterprises that route internal access to commercial AI APIs through a reverse proxy but fail to enforce authentication at that proxy layer. The proxy is exposed to the internet for convenience; the authentication sits only at the application level. Any gap in that architecture lets an attacker reach a live, paid API endpoint and use it without credentials.

Fingerprinting Through Innocuous Prompts

The enumeration campaign’s technique for confirming a live model was clever. Rather than sending probes that might trigger content filters or alerting, the campaign used a rotating set of deliberately innocuous test queries. The top five, by session count across all 80,469 requests:

  • “hi” (32,716 sessions)
  • “How many states are there in the United States?” (27,778 sessions)
  • A multi-part version requesting model identification (17,979 sessions)
  • An empty string (8,073 sessions)
  • “How many letter r are in the word strawberry?” (2,024 sessions)

The strawberry prompt is recognisable to anyone following LLM research. It gained notoriety as a test case for reasoning failures in early frontier models. Here it serves a different purpose: it is a prompt that any aligned language model will answer, is completely benign to content filters, and returns a distinctive enough response to confirm which model is running and roughly which version.

The empty string probes are also telling. Different API implementations handle empty prompts differently. A 400 error tells you one thing about the backend; a 200 with a clarification response tells you another. The probe is mapping implementation signatures, not just checking for presence.

What the Attackers Are Building

GreyNoise’s assessment: “Eighty thousand enumeration requests represent investment. Threat actors don’t map infrastructure at this scale without plans to use that map.”

The most likely use cases for a comprehensive map of exposed, unauthenticated LLM proxy endpoints are LLMjacking (using the access for free compute at the victim’s expense), staging infrastructure for subsequent prompt injection or data exfiltration campaigns, or targeting the same organizations through other attack vectors now that their AI deployment footprint is documented.

The SSRF campaign’s targets, Ollama and Twilio integrations, point to different downstream intent. Successful SSRF exploitation against Ollama can exfiltrate models, expose internal network topology via DNS rebinding, or reach internal services through the compromised server’s network position. SSRF via Twilio webhook manipulation targets the integration layer between AI services and communication infrastructure, a vector with growing relevance as voice AI and SMS-based AI workflows expand.

Detection and Response

The JA4H signature (po11nn060000…) in the SSRF campaign is directly actionable for security teams with NDR tools or WAFs that support JA4H fingerprinting. This signature appeared in 99% of SSRF probes, making it a reliable detection signal for this specific tooling.

For the enumeration campaign, the two primary IPs (45.88.186.70 and 204.76.203.125) should be added to perimeter blocklists now. Both have extensive, documented histories of malicious scanning across internet-exposed services. GreyNoise classifies both as confirmed malicious.

More fundamentally, the correct response to this research is to conduct an inventory of your LLM-adjacent attack surface. Ask the questions the attackers are asking: Is any Ollama instance accessible from outside your network perimeter? Are any proxies fronting commercial AI APIs exposed without authentication? Are AI integration endpoints (Twilio, Zapier, n8n) configured to make outbound requests to arbitrary URLs?

Ollama was designed as a local tool. It ships with no authentication by default. Thousands of Ollama instances are exposed to the public internet today. GreyNoise’s honeypot data quantifies how many attackers already know this.

References

Frequently Asked Questions

What types of LLM deployments are being targeted in these campaigns?
Both campaigns focused on internet-exposed LLM infrastructure: misconfigured proxy servers that front commercial AI APIs, self-hosted Ollama instances accessible from the public internet, and any endpoint exposing OpenAI-compatible or Google Gemini-compatible API interfaces. The enumeration campaign tested 73 distinct model endpoint variants, covering all major providers including OpenAI, Anthropic, Meta, DeepSeek, Mistral, Alibaba, and xAI.
How does the JA4H fingerprint help defenders detect the SSRF campaign?
The SSRF campaign used a consistent JA4H fingerprint (po11nn060000...) in 99% of its requests, which GreyNoise assessed as shared automation tooling, likely Nuclei. This signature appears in SSRF probes targeting Ollama model pull functionality and Twilio MediaUrl parameters. Organizations running WAFs or NDR tools with JA4H support can create detection rules for this fingerprint, though attackers can rotate it if they become aware of signature-based blocking.
What should security teams do with exposed LLM infrastructure discovered in their environment?
Immediate priority: remove Ollama and any other self-hosted LLM endpoints from public internet exposure entirely. If a proxy fronting commercial APIs must be internet-accessible, enforce authentication at the proxy layer and apply rate limiting. Rotate any API keys associated with endpoints that may have been probed. Review logs for the specific IPs identified in GreyNoise's report: 45.88.186.70 (AS210558, 1337 Services GmbH) and 204.76.203.125 (AS51396, Pfcloud UG), both of which have extensive histories of CVE exploitation across other targets.