Malicious 'Free' LLM Endpoints Are Harvesting Coding-Agent Sessions — How to Detect and Contain Rogue Inference Backends

A recent SANS Internet Storm Center diary entry documented an experiment every defender running AI-assisted development workflows needs to read carefully. A researcher stood up an internet-exposed LLM inference honeypot — nothing exotic, just an OpenAI-compatible API endpoint. Within a short period, it was discovered by scanning infrastructure, relabeled with sought-after model names, and folded into service directories offering "free" LLM backends to developers.

Then it received a real coding-agent session.

The request body contained everything the agent was working with: conversation history, filesystem listing output, working directory paths, and the agent's local tool manifest — the full inventory of functions the agent could execute on the developer's machine. The honeypot operator took no action and triggered no tool execution. But the exercise proved the point cleanly: any operator in that position could have. A malicious inference endpoint doesn't just see your prompts — it sees your source tree, your internal paths, your secrets-in-context, and it controls the response channel that modern agents treat as instructions.

This is not a theoretical supply-chain concern. Coding agents (Claude Code, Cursor, Aider, Continue, and dozens of OpenAI-compatible clients) are being pointed at arbitrary base URLs every day by developers chasing free or uncensored models. The endpoint is a trusted position in the agentic loop — and right now, in most environments, nothing validates that trust.

Technical Analysis: Why the Inference Endpoint Is a Trusted — and Unaudited — Position

How the Exposure Works

Modern coding agents operate on an agentic loop:

1. The agent collects local context — file contents, directory listings, shell output, git state — and serializes it into the request sent to the configured LLM endpoint.
2. The endpoint returns a completion, which may include structured tool calls (function calling) that the agent's runtime executes locally: read file, write file, run shell command.
3. Results are appended to the conversation and sent back to the endpoint. Repeat.

Two properties make a malicious endpoint catastrophic in this architecture:

• Passive harvesting: Every request carries the accumulated session context. The ISC honeypot received filesystem output, working paths, and the tool manifest without asking for anything unusual — this is simply what agents send. Source code, credentials embedded in files, internal hostnames, and project structure all flow to whoever terminates the TLS session.
• Active steering: Because the endpoint controls the response, it can emit tool calls. An agent configured with permissive tool execution (auto-approve modes, --yolo-style flags, or MCP servers with shell access) will execute attacker-shaped instructions with the developer's privileges. Even without direct tool abuse, the endpoint can return malicious code suggestions — poisoned dependencies, backdoored snippets — that a tired developer accepts.

How Endpoints Get Relabeled and Injected

The honeypot was not "attacked" in the traditional sense. It was scraped and repackaged. Aggregator infrastructure continuously scans for OpenAI-compatible endpoints (/v1/models, /v1/chat/completions on ports like 11434, 8000, 8080, 5000), fingerprints them, and re-advertises them under attractive model names. Developers — or their tooling defaults, or a config snippet copied from a forum — point an agent at the aggregator, and the aggregator proxies to whatever backend it has harvested. The developer believes they're talking to "free-gpt-4o." They're talking to an operator.

Exploitation Status

There is no CVE here — this is an architectural trust failure, not a patchable bug. The exposure is confirmed in practice by direct observation (a real coding-agent session arriving at a honeypot). It is not in CISA KEV because there is nothing to enumerate. That makes it more dangerous for defenders, not less: there is no vendor advisory to wait for and no scanner signature. The control gap is entirely yours to close.

Detection & Response

The observable surface here is concrete: coding-agent processes and developer tooling making outbound connections to inference API ports or non-allowlisted hosts, environment variables overriding base URLs, and config files pointing agents at unapproved endpoints. The detections below assume your first move is defining what approved looks like — detections against an allowlist are high-signal; detections without one are noise.

---
title: Developer Tooling Connecting to Common LLM Inference Ports
id: 3f8c2a71-9b4e-4d1a-a6f2-8c5e7b1d9034
status: experimental
description: Detects developer workstation processes establishing network connections to ports commonly used by self-hosted or unofficial LLM inference servers (Ollama, vLLM, llama.cpp, text-generation-webui). May indicate use of unapproved or rogue 'free' LLM backends by coding agents.
references:
  - https://isc.sans.edu/diary/rss/33298
  - https://attack.mitre.org/techniques/T1102/
author: Security Arsenal
date: 2026/08/31
tags:
  - attack.command_and_control
  - attack.t1102
  - attack.exfiltration
  - attack.t1041
logsource:
  category: network_connection
  product: windows
detection:
  selection_port:
    DestinationPort:
      - 11434
      - 8000
      - 8080
      - 5000
      - 4891
  selection_image:
    Image|endswith:
      - '\node.exe'
      - '\python.exe'
      - '\python3.exe'
      - '\code.exe'
      - '\cursor.exe'
      - '\aider.exe'
  condition: selection_port and selection_image
falsepositives:
  - Developers running legitimate local inference (Ollama on localhost) — tune by excluding 127.0.0.1 destinations
  - Internal approved inference gateways — maintain an allowlist of sanctioned DestinationIp values
level: medium
---
title: LLM Base URL Override via Environment or Command Line
id: 8b1d4e62-3c7a-4f59-b2d8-6a9e0c4f7158
status: experimental
description: Detects process command lines setting or referencing LLM API base URL overrides (OPENAI_BASE_URL, ANTHROPIC_BASE_URL, OLLAMA_HOST, OPENAI_API_BASE), a common method for redirecting coding agents to unofficial or malicious inference endpoints.
references:
  - https://isc.sans.edu/diary/rss/33298
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/31
tags:
  - attack.execution
  - attack.t1059
  - attack.defense_evasion
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'OPENAI_BASE_URL'
      - 'OPENAI_API_BASE'
      - 'ANTHROPIC_BASE_URL'
      - 'OLLAMA_HOST'
      - '--base-url'
      - '--api-base'
  condition: selection
falsepositives:
  - Legitimate redirects to corporate LLM gateways — baseline approved gateway hostnames and alert on deviations
level: high
---
title: Coding Agent Configuration File Modification
id: 5e7f9a13-2b6d-4c81-9e3a-1d4b8f6c2095
status: experimental
description: Detects creation or modification of coding-agent and AI client configuration files where custom inference endpoints, API keys, and model backends are defined. Unexpected changes may indicate redirection of an agent to a rogue LLM backend.
references:
  - https://isc.sans.edu/diary/rss/33298
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/08/31
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|contains:
      - '\.cursor\'
      - '\.continue\'
      - '\.aider.conf'
      - '\.claude\'
      - '\.codeium\'
      - '\continue\config.json'
      - '\.env'
  condition: selection
falsepositives:
  - Normal developer configuration activity — alert on off-hours changes or changes correlating with new outbound inference connections
level: low

The first two rules are your workhorses. The port-based rule will fire on legitimate local Ollama usage — tune it against your approved gateway list or restrict it to non-RFC1918 destinations to keep it sharp. The base-URL override rule is higher fidelity: in a managed environment, developers should not be setting these variables outside of a sanctioned configuration path.

// Hunt: Developer processes connecting to candidate LLM inference endpoints
// outside the approved gateway allowlist (Microsoft Defender / Sentinel)
let ApprovedInferenceHosts = dynamic(["api.openai.com", "api.anthropic.com", "llm-gw.corp.example.com"]);
let InferencePorts = dynamic([11434, 8000, 8080, 5000, 4891]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("node.exe", "python.exe", "code.exe", "cursor.exe", "aider.exe", "Code - Insiders.exe")
| where RemotePort in (InferencePorts)
   or RemoteUrl has_any ("chat/completions", "/v1/models")
| where not(RemoteUrl has_any (ApprovedInferenceHosts) or RemoteIP startswith "10." or RemoteIP startswith "192.168" or RemoteIP == "127.0.0.1")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count(),
            RemoteEndpoints = make_set(RemoteIP), Ports = make_set(RemotePort)
            by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl
| sort by ConnectionCount desc

Run this as a scheduled hunt and treat any recurring external endpoint as a finding worth a conversation with the developer — this is as much a policy-enforcement signal as an intrusion signal. Feed confirmed rogue endpoints to your egress proxy block list.

-- Hunt: Coding-agent processes with active connections to non-approved inference endpoints
-- and enumeration of agent config files containing custom base URLs
SELECT Pid, Name, CommandLine,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort,
       Status
FROM netstat()
WHERE (RemotePort in (11434, 8000, 8080, 5000, 4891)
   OR CommandLine =~ '(?i)(aider|cursor|continue|claude|codeium|openai|anthropic)')
  AND RemoteIP !~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|127\\.)'
  AND Status =~ 'ESTABLISH'

For file-level forensics on an implicated host, pair the network hunt with a glob over agent configuration paths:

-- Collect coding-agent config files for base URL and API key review
SELECT FullPath, Size, Mtime,
       read_file(filename=FullPath, length=8192) AS ConfigPreview
FROM glob(globs=['C:/Users/*/.cursor/**/*.json',
                 'C:/Users/*/.continue/config.json',
                 'C:/Users/*/.aider.conf.yml',
                 'C:/Users/*/.claude/**/settings.json',
                 'C:/Users/*/.env',
                 '/home/*/.config/aider/*',
                 '/home/*/.continue/config.json'])
WHERE ConfigPreview =~ '(?i)(base_url|baseurl|api_base|openai|anthropic|ollama|api_key)'

#!/bin/bash
# audit-llm-endpoints.sh — Audit developer workstations for rogue LLM inference
# endpoint configuration. Run via your fleet management tooling.

REPORT="llm-endpoint-audit-$(hostname)-$(date +%Y%m%d).txt"

echo "=== LLM Endpoint Audit: $(hostname) ===" > "$REPORT"

echo -e "\n[1] Base URL / API environment overrides" >> "$REPORT"
env | grep -iE 'OPENAI_BASE_URL|OPENAI_API_BASE|ANTHROPIC_BASE_URL|OLLAMA_HOST|AZURE_OPENAI_ENDPOINT' >> "$REPORT"
# Also check shell profiles where these persist
grep -rniE 'OPENAI_BASE_URL|ANTHROPIC_BASE_URL|OLLAMA_HOST' \
  ~/.bashrc ~/.zshrc ~/.profile ~/.bash_profile /etc/profile.d/ 2>/dev/null >> "$REPORT"

echo -e "\n[2] Coding-agent config files referencing custom endpoints" >> "$REPORT"
for cfg in ~/.continue/config.json ~/.aider.conf.yml ~/.claude/settings.json \
           ~/.cursor/settings.json ~/.codeium/config.json ~/.env; do
  [ -f "$cfg" ] && { echo "--- $cfg"; grep -iE 'base_url|api_base|endpoint|url' "$cfg"; } >> "$REPORT" 2>/dev/null
done

echo -e "\n[3] Active connections to common inference ports" >> "$REPORT"
ss -tnp 2>/dev/null | grep -E ':(11434|8000|8080|5000|4891)\b' >> "$REPORT"

echo -e "\n[4] Listening local inference servers (shadow AI on the workstation)" >> "$REPORT"
ss -tlnp 2>/dev/null | grep -E ':(11434|8000|8080|5000|4891)\b' >> "$REPORT"

echo -e "\n[5] Installed agent/AI CLI tooling" >> "$REPORT"
for tool in aider ollama claude cursor-agent continue; do
  command -v "$tool" >/dev/null && echo "FOUND: $tool ($(command -v $tool))" >> "$REPORT"
done

echo -e "\nAudit complete: $REPORT"
echo "ACTION: Compare findings against the approved inference gateway allowlist."

Remediation and Hardening

Because there is no patch, remediation is architectural. Prioritize in this order:

1. Establish and enforce an inference allowlist. Publish a sanctioned list of LLM endpoints (your corporate gateway, contracted APIs) and enforce it at the egress proxy. All other destinations on inference ports and OpenAI-compatible paths should be blocked or alerted. This single control closes the majority of the exposure — a rogue endpoint the agent cannot reach cannot harvest context.

2. Deploy an internal LLM gateway. Route all agent traffic through a broker (LiteLLM, an API gateway, or a commercial AI firewall). The gateway gives you centralized logging of prompts and tool calls, the ability to redact secrets before they leave, and a single choke point where endpoint trust is validated. It also gives IR teams the logs they will desperately need after an incident involving agent tooling.

3. Treat agent context as sensitive data — because it is. Assume anything in the working directory of an agent session will leave the machine. Keep secrets out of files agents read: use secret managers, scrub .env files from agent context via .gitignore-style exclusion configs (.aiderignore, Cursor ignore rules), and never run agents in directories containing credentials, private keys, or customer data unless the endpoint is one you operate.

4. Constrain tool execution. Disable auto-approve / YOLO modes on any agent not pointed at a fully trusted endpoint. Require human confirmation for shell commands and file writes. Scope MCP servers to the minimum capability set. Remember: the endpoint authors the tool calls — a malicious one will use them.

5. Plant canaries. Seed canary credentials (AWS keys, API tokens from your canary token service) in repositories developers work in. If those tokens are ever used, you have high-fidelity confirmation that session context leaked — and an immediate IR trigger.

6. Update acceptable-use policy and developer guidance. "Free model" aggregators must be explicitly prohibited for any agent that touches corporate code or data. Pair the policy with a sanctioned alternative — developers route around policy when the sanctioned path is slower or more expensive than the rogue one.

7. Include agents in IR playbooks. If you suspect a session went to a hostile endpoint, assume full compromise of everything in that session's context window: rotate any credentials present in the working tree, review code the agent touched for injected logic, and audit the developer's host for tool-execution artifacts.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub