LLMjacking: what these attacks are, and how to protect AI servers

LLMjacking: what these attacks are, and how to protect AI servers

/in

AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

  • A well-structured attempt to parse technical documentation for a microprocessor
  • A prompt to write an erotic novel
  • Requests to parse and structure social media text data regarding new vulnerabilities
  • An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

  • For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
  • For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
  • Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
  • Ensure that all client-server connections are secured with a current version of TLS.
  • Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
  • Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
  • Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
  • Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

Kaspersky official blog – ​Read More