Expanding Horizons: The Rising Threat of AI-Focused Reconnaissance
In the ever-evolving landscape of internet security, reconnaissance activities are increasingly shifting from traditional application targets to more complex and nuanced areas, particularly focused on Model Context Protocol (MCP) services, AI assistant configuration files, and locally exposed large language model (LLM) endpoints. This worrying trend highlights the necessity of proactive security measures as malicious actors adapt to new technologies.
Recently, a meticulous 14-day examination of Apache and ModSecurity logs from a small, low-traffic shared hosting service unveiled approximately 200 suspicious requests linked to AI-agent reconnaissance. Alongside this atypical traffic, routine probing for vulnerabilities in platforms like WordPress, .env files, Git repositories, and Spring Boot Actuator continued unabated, illuminating the diverse spectrum of threats currently challenging cybersecurity.
What is especially concerning about this activity is that it was not merely the result of haphazard scanning efforts. Attackers were observed sending valid JSON-RPC MCP initialization requests directed at the /mcp endpoint. They also showed clear intent to locate sensitive configuration files from various sources, including Claude, Cursor, and Visual Studio Code, probing OpenAI-compatible and Ollama API endpoints in the process. This determined approach underscores a strategic shift in attackers’ tactics, as they zero in on increasingly complex infrastructures.
Adding another layer of concern to this AI-driven reconnaissance was the concurrent generation of server-side request forgery (SSRF) attempts aimed at exploiting Google Cloud’s metadata service. Such activities present valuable pathways for malicious entities, potentially allowing them access to service account tokens—a highly coveted prize in the cybercriminal world.
Among the alarming findings were POST /mcp probes that transmitted well-structured MCP initialization calls, employing JSON-RPC 2.0 and the protocol version dated 2025-03-26. This initialization lifecycle is particularly significant as it facilitates a negotiation of capabilities between client and server. The implications of successful responses are broad: a discerning attacker may well discover that a host runs an MCP server, thereby enabling the enumeration of available tools, resources, prompts, or back-end services accessible to the AI client.
Given that MCP is fundamentally designed to connect LLM applications to various external tools and data sources, an exposed server can inadvertently evolve into a machine-readable entry point into databases, file systems, internal APIs, ticketing platforms, and assorted cloud services. Surveillance of this developing traffic patterns revealed that the /mcp probes originated from 49 distinct source IP addresses, suggesting a spread-out and organized effort rather than isolated or opportunistic attacks.
In light of these revelations, defenders in the cybersecurity arena are urged to regard unsolicited MCP initialization traffic as a high-confidence discovery signal. This is particularly pertinent for organizations that do not intentionally operate a public MCP service.
The reconnaissance campaign did not merely stop at probing for MCP endpoints; it sought out AI assistant artifacts, specifically targeting files such as /.claude/mcp.json, /.cursor/mcp.json, and /.vscode/mcp.json. Such requests reveal a troubling insight: attackers are beginning to view developer-centric AI configurations as potential reservoirs for connection details, API keys, and sensitive credentials.
A notable tactic employed was the use of HEAD requests against these credential filenames, allowing attackers to determine whether sensitive objects exist without actually retrieving their contents. This method conserves bandwidth and proves advantageous in a large-target scanning operation. Experts from ISC have articulated that these AI-specific paths are appearing alongside traditional cloud credential filenames, Kubernetes secrets, and application configuration files—indicating that AI tooling is now integrated into standard secret-harvesting strategies.
To mitigate these emerging threats, organizations must ensure that sensitive configuration paths such as .claude, .cursor, .vscode, and .mcp are never inadvertently deployed into production artifacts or accessible within web document roots. It is imperative for web servers to explicitly deny access to hidden configuration directories and sensitive JSON files, rather than relying solely on proper deployment hygiene.
Furthermore, attackers were consistently probing for the /v1/models endpoint, a common means to verify OpenAI-compatible models, and /api/tags utilized by Ollama for enumerating installed models. An unauthenticated response from these endpoints can lead to the exploitation of inference infrastructure, allowing malicious actors to gain insights into models in use and execute follow-on attacks.
Of particular concern were the SSRF payloads directed at metadata.google.internal, where parameters such as URL, URI, path, and destination were commonly sought. This tactic exposes the risk that a vulnerable fetch, proxy, webhook, or agent tool could potentially facilitate credential exfiltration. The risks are particularly elevated in MCP deployments due to the prevalence of URL-retrieval tools, creating a very real chance for attackers to exploit an MCP server with unrestricted "fetch URL" capabilities.
To protect against these threats, thorough searches of access logs should include POST /mcp, /sse, AI configuration filenames, /v1/models, /api/tags, and the metadata services’ addresses. Organizations are advised to block unauthenticated public MCP access, implement strict authorization protocols for each tool, and limit the egress of tools through allowlists. Any URL-fetching features must have defenses in place to reject link-local, loopback, private, and cloud-metadata destinations following DNS resolutions and upon all redirects.
Finally, establishing practices of least-privilege service accounts within cloud workloads can substantially limit the potential impact should a token be compromised. For example, enforcing IMDSv2 in AWS can add a layer of complexity with a session-token requirement, reducing susceptibility to common SSRF patterns.
In conclusion, as the online landscape continues to rapidly evolve, it is incumbent upon organizations to adapt by fortifying their security measures against the sophisticated reconnaissance tactics employed by today’s cyber adversaries. The integration of AI into their security frameworks will be a game-changer, but proactive measures must be taken to safeguard these very tools from exploitation.