High

LLM API Endpoint Redirection via Base URL or Proxy Override

This rule catches attempts to hijack an AI agent's connection to its LLM provider (like OpenAI or Anthropic) and reroute it to a server controlled by an attacker. Once redirected, the attacker can see everything the agent sends, including API keys and any sensitive data in the conversation.

How the attack works

An attacker changes a configuration setting the agent uses to know where to send its API requests, such as ANTHROPIC_BASE_URL, OPENAI_BASE_URL, or a proxy environment variable like HTTPS_PROXY. On its own, this could be legitimate, so the rule only flags it when a second suspicious signal appears in the same action: the new destination looks like it is impersonating a real provider domain (for example api.anthropic.com.evil.tld or a punycode lookalike), TLS certificate checking has been turned off, or a real provider API key is present alongside the redirect. Together, these signs indicate traffic is being pointed at a lookalike endpoint that can capture credentials and data in transit.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
7b3f1c9e-2d64-4a58-b1e7-6c9f0a4d83b2
Severity
High

Why it matters

If successful, an attacker can intercept API keys and any data the agent sends to the LLM, including proprietary prompts, customer data, or internal documents — a full compromise of confidentiality for that agent's traffic.

What you can do

  • Lock down which base-URL and proxy environment variables your agent processes are allowed to read, and monitor for changes to them.
  • Pin or allowlist the exact provider hostnames your agents may contact, and alert on any lookup pattern that embeds a provider name as a subdomain, prefix, or userinfo field.
  • Never disable TLS certificate verification for LLM API connections in production; treat any such change as a high-priority review item.
  • When rolling out internal LLM gateways or TLS-inspecting proxies, use hostnames and certificates that do not resemble provider impersonation patterns, and document these exceptions so they are not repeatedly flagged.

Known benign look-alikes

  • Enterprise rollout of an internal OpenAI-compatible gateway whose hostname embeds a provider token (e.g. an internal host named openai-api.<corp>.<tld>) configured with a self-signed certificate, so base_url and rejectUnauthorized/verify=false appear in the same file or command.
  • Corporate MITM/TLS-inspection bootstrap scripts that export HTTPS_PROXY together with certificate-bundle or verification settings in a shell that also carries ANTHROPIC_API_KEY / OPENAI_API_KEY.
  • Local development against a mock or record-replay LLM server (verify=False, NODE_TLS_REJECT_UNAUTHORIZED=0) combined with a base_url override.
  • Security training material, detection-engineering content, phishing-awareness docs or threat reports that quote look-alike provider domains; partially suppressed by filter_security_doc.
  • Tool output (tool_response / llm_tool_result) from a fetched web page or issue tracker that reproduces this attack as an example.

References

Related threats