If you’re a developer or engineer working with LLMs in production, you need to read this. The era of treating AI security as a theoretical, far-off problem is officially over.
Between October 2025 and January 2026, the security firm GreyNoise, known for tracking internet-wide scanning activity, captured a staggering 91,403 attack sessions specifically targeting LLM endpoints. This isn't just background noise. It’s a clear signal that professional threat actors have moved LLM infrastructure to the top of their target list.
They are systematically mapping the expanding attack surface of enterprise AI to build target lists for future, high-impact exploitation. Let's dive into the two major campaigns they uncovered and what you can do to protect your stack.
Campaign 1: The "Model Pull" Trap and SSRF
The first major campaign focuses on a classic web vulnerability: Server-Side Request Forgery (SSRF). Attackers are exploiting the functionality that allows an LLM or its surrounding infrastructure to fetch external resources, often referred to as a "model pull" or "tool use" capability.
The core idea is to trick the server into making an outbound connection to an attacker-controlled endpoint. GreyNoise observed two primary vectors:
- Ollama Model Pulls: When running local model infrastructure like Ollama, the system often needs to pull models from a registry. Attackers inject malicious registry URLs designed to force the server to initiate an outbound HTTP request.
- Twilio Webhooks: In systems integrating LLMs with communication platforms, manipulating parameters like
MediaUrlcan force the LLM agent to fetch a malicious resource.
The OAST Callback: How Attackers Confirm Success
What makes this campaign sophisticated is the use of Out-of-band Application Security Testing (OAST) infrastructure, such as ProjectDiscovery.
Here’s the flow:
- Attacker injects a payload (e.g., a malicious URL pointing to their OAST server).
- The vulnerable LLM server attempts to "pull" the resource, making an outbound request to the OAST server.
- The OAST server logs the incoming request, confirming the vulnerability and the server's internal IP/metadata.
This activity saw a dramatic spike, over 1,600 sessions in just 48 hours, during the Christmas holiday. This timing is a classic hallmark of professional operations, designed to exploit reduced monitoring capacity.
Campaign 2: The LLM Enumeration Game
While the SSRF campaign is about exploitation, the second campaign is about strategic reconnaissance.
Starting in late December, two specific IP addresses launched a methodical probe that generated over 80,000 sessions in eleven days. This was a systematic inventory hunt for misconfigured API gateways and proxy servers—the "front doors" that manage access to commercial LLM APIs.
The "Strawberry" Test and Model Fingerprinting
The attackers tested every major model family, using innocuous queries to stay under the radar. They weren't asking for secrets; they were asking simple, non-threatening questions:
- "How many states are there in the United States?"
- The "strawberry" test (a known prompt used to check for specific model behaviors or guardrails).
By analyzing the response format, latency, and content, they can fingerprint the underlying model (e.g., "This is GPT-4o," "This is Claude 3 Haiku").
| Model Family | Target | Fingerprinting Goal |
|---|---|---|
| OpenAI | GPT-4o, GPT-4, etc. | Response format, specific refusal patterns. |
| Anthropic | Claude Sonnet, Opus, Haiku | Length of response, unique stylistic elements. |
| Gemini-based APIs | API format compliance, specific knowledge cutoffs. | |
| Open Source | Llama 3.x, Mistral, Qwen, Grok | Known model biases, response length limits. |
Why is this strategic? Once an attacker knows the exact model and version you are running, they can craft highly targeted prompt injection attacks that are known to bypass the guardrails of that specific model. It turns a generic attack into a precision strike.
The Shift: LLMs are Now "Legacy" Targets
The GreyNoise data signals a fundamental shift: attackers are treating LLM infrastructure with the same systematic approach they used for traditional network targets like VPNs, Elasticsearch clusters, and CI/CD servers.
This transition from "experimental" to "production" creates a dangerous security gap because:
- Exposed Proxies: Organizations often expose model routes for convenience or testing, creating easy targets for enumeration.
- Blind Spots: Traditional Web Application Firewalls (WAFs) and security tools are often blind to the subtle differences between a legitimate developer query and a malicious fingerprinting attempt.
- High-Value Gateway: An exposed LLM API proxy is not just a text generator. It's a gateway to the data, tools, and actions those models are authorized to perform.
Beyond Reconnaissance: The Agentic Threat
The enumeration and SSRF findings are just "Phase 0" of a much more dangerous attack lifecycle, especially for those building autonomous AI agents.
Once a threat actor successfully fingerprints an LLM endpoint, the next step is to exploit the agentic workflows built on top of it. The risk moves from simple data exposure to functional compromise:
- Subverted Actions: Agents could be tricked via prompt injection into executing unauthorized tools (e.g., running a shell command, accessing a database, sending an email).
- Protocol Abuse: If your agents use protocols like the Model Context Protocol (MCP) to connect to internal services, an attacker could hijack these connections to exfiltrate sensitive data or maintain persistence.
- Persistence: Identified endpoints can be used to maintain long-term control over autonomous workflows, turning your agent into a mole.
Your Action Plan: Hardening Your AI Perimeter
The good news is that the GreyNoise findings provide a clear roadmap for defense. Here are the immediate, actionable steps every developer and security engineer should take:
1. Lock Down Outbound Traffic (Egress Filtering)
This is your most immediate defense against the SSRF campaign.
- Restrict Outbound Connections: Configure your firewalls, security groups, or Kubernetes network policies to only allow outbound connections to known, trusted IPs and ports.
- Block OAST Callbacks: Prevent your server from "phoning home" to untrusted external domains. If you're running local models (like Ollama), ensure they are configured to only pull from your internal or trusted registries.
2. Implement Behavioral Monitoring
Traditional security tools look for malicious strings. You need tools that understand behavior.
- Alert on Fingerprinting: Monitor for rapid-fire requests across multiple endpoints or repeated use of known fingerprinting queries (like the "strawberry" test).
- Rate Limiting: Implement aggressive rate limiting and throttling on your LLM endpoints to slow down or block systematic enumeration attempts.
3. Proactive Vulnerability Discovery
Don't wait for the attackers to find your flaws.
- AI Red Teaming: Systematically simulate adversaries and stress-test your defenses. This involves crafting targeted prompt injections and testing the security of your tool-use capabilities.
- Protocol Security Scanning: If you are using advanced agent protocols (like MCP), deploy a specialized scanner to ensure your data connections and agent code are secure before deployment.
4. Treat LLM Endpoints as High-Value Assets
Your LLM API gateway is now as critical as your primary database server.
- Zero Trust: Apply Zero Trust principles to all components of your AI stack. Every connection, every tool use, and every data access must be explicitly verified.
- Runtime Protection: Deploy specialized runtime protection to monitor and moderate GenAI behavior in real-time, distinguishing between legitimate developer queries and malicious activity.
Final Reflections
The security landscape for AI has matured overnight. The systematic mapping of nearly 100,000 sessions proves that professional threat actors are already building the maps they need to exploit the next generation of enterprise software.
Building a resilient AI strategy requires a shift from reactive patching to a foundation of continuous security and governance. If you’re building with LLMs, your job now includes being an LLM Security Engineer.
Top comments (0)