AIdhirajSingh/clauderabbit
We ran AIdhirajSingh/clauderabbit, a node project, in an isolated sandbox. It built and ran cleanly. We observed no malicious behavior, credential access, or outbound exfiltration. Its install reaches telemetry.nextjs.org for dependencies — a supply-chain note, not an attack. Its score is held down by provisioning network activity.
Neutral
The repository contains multiple scripts that fetch dependencies (Node.js, Deno, Docker, Kata Containers) from recognized software-distribution hosts. This is consistent with the project's intent to build complex, isolated analysis environments.
Scripts communicate with 127.0.0.1 and metadata.google.internal. These are standard patterns for local service health checks and cloud-native environment provisioning within a sandbox.
The owner account is relatively new (8 months) with limited public repository history and low star count, which is common for niche security tooling.
Three agents — install-time, runtime, and payload — read the source in parallel and cross-verified. These are their inferences from reading the code; the runtime facts below are what actually happened when we ran it.
Agent analysis (code read, not a runtime observation): This script, `provision-forge-gateway.sh`, is an infrastructure-provisioning script designed to configure a dedicated network gateway (NVA) for a sandbox environment. Its primary purpose is to intercept, inspect, and potentially forge network traffic from untrusted Cloud Run containers using `mitmproxy` and `iptables`. ### Analysis of Intent The script is clearly documented as part of a security-detonation architecture. It performs the following high-privilege operations: 1. **Network Redirection**: Configures `iptables` to force all TCP traffic from the sandbox subnet through a local `mitmproxy` instance (transparent mode) and drops forwarded traffic. 2. **DNS Forgery**: Replaces the system resolver with `dnsmasq` to sinkhole non-whitelisted domains to the gateway's own IP, preventing malware from reaching external C2s that do not exist in public DNS. 3. **Service Deployment**: Installs and enables systemd services for `mitmproxy` (using a custom addon `forge_addon.py`) and a forensics API (`forensics_api.py`). 4. **Persistence**: Sets up systemd timers to continuously re-assert `iptables` rules to prevent configuration drift. ### Security Observations * **Privilege Level**: The script runs as `root` and modifies core system networking (`iptables`, `dnsmasq`, `resolv.conf`). This is expected for a gateway appliance but represents a high-impact target if the script itself were compromised. * **Credential Handling**: It references `CR_FORGE_CONTROL_KEY`, which is intended to authenticate the forensics API. The script correctly notes that the security of this gateway depends on this key being properly managed via Secret Manager. * **Dependency Management**: It creates a Python virtual environment and installs `mitmproxy` via `pip`. This is a standard practice for isolated service deployment. ### Detonation Recommendation While the script is infrastructure code rather than a package to be installed in a target environment, it is the **control plane** for the entire detonation architecture. **I recommend detonating this script in a test environment** to verify: 1. **Correctness of Containment**: Confirm that `iptables` rules correctly redirect traffic and that `dnsmasq` successfully sinkholes non-whitelisted domains. 2. **Service Integrity**: Ensure the systemd units start correctly and that the `mitmproxy` addon (`forge_addon.py`) and forensics API (`forensics_api.py`) are functional. 3. **Drift Protection**: Verify that the `cr-forge-iptables.timer` successfully re-applies rules if they are manually flushed. This script is not "malware" in the traditional sense, but it is a powerful tool that, if misconfigured or tampered with, could bypass the very security controls it is intended to enforce. *Note: I have not yet reviewed `forge_addon.py` or `forensics_api.py`. These are critical components that define the actual "forgery" logic and should be analyzed next.*
Agent analysis (code read, not a runtime observation): This file, `sandbox/analysis/run-analysis.sh`, is a utility script designed to orchestrate the analysis of captured data (logs and behavior reports) from a detonation. It is part of the infrastructure, not the target repository being analyzed for malware. ### Analysis of `run-analysis.sh` * **Purpose**: It provides a mechanism to run `analyze-payload.py` in an isolated environment (either a local temporary directory or a dedicated, ephemeral GCP VM). * **Functionality**: * It takes inert data (`capture.jsonl`, `behavior.json`) as input. * It ensures that the analysis process is isolated from the detonation environment. * It includes cleanup mechanisms (`trap` for local, `--max-run-duration` and `trap` for VM) to ensure resources are disposed of after use. * It uses `gcloud` commands to manage the lifecycle of the analysis VM. * **Security Context**: This script is intended to handle *inert* data. It does not execute the untrusted payloads themselves; it executes the analysis tool (`analyze-payload.py`) against the logs generated by the sandbox. ### Verdict on Detonation **Do not detonate.** This file is part of the analysis harness itself. Detonating it would be inappropriate as it is a control script for the analysis pipeline, not a target for malware analysis. It is designed to be run by the orchestrator to process data *after* a detonation has occurred. ### Observations * The script follows secure practices by isolating the analysis environment from the detonation environment. * It includes robust cleanup logic to prevent resource leakage. * It correctly distinguishes between "local" and "vm" modes for flexibility in the analysis pipeline. * No malicious patterns (e.g., credential harvesting, persistence, or unauthorized network activity) were observed in the script's logic. It is a standard infrastructure utility.
Agent analysis (code read, not a runtime observation): This file is a `Dockerfile` for the Claude Rabbit sandbox environment itself. It defines the infrastructure used to perform the analysis, rather than being a target repository to be analyzed. ### Analysis of `sandbox/cloudrun/harness/Dockerfile` * **Purpose:** This image serves as the execution environment for the sandbox. It installs necessary runtimes (Node.js 22, Python 3, Deno, OpenCode) and copies the analysis harness scripts (`entrypoint.sh`, `detonate.py`, etc.) into the container. * **Security Posture:** * **Base Image:** Uses `node:22-slim`, a standard, minimal base. * **Tooling:** Installs standard utilities (`strace`, `curl`, `git`) required for the analysis workflow. * **Hardening:** * Uses `corepack` to manage package managers, which is noted to be configured to fetch through a gateway's registry fast-path. * Downloads installation scripts for Deno and OpenCode to `/tmp` and executes them locally, rather than piping directly into a shell, which is a standard security practice. * Pins versions for Deno (`v2.9.1`) and OpenCode (`1.17.13`) to ensure consistency and prevent "latest" tag poisoning. * Sets `COREPACK_ENABLE_DOWNLOAD_PROMPT=0` to prevent the container from hanging during unattended execution. * **Egress:** The comments explicitly state that egress containment is handled by an external gateway VM (`10.200.0.10`) via custom routing, which is consistent with the design of a hermetic sandbox. ### Conclusion This file is part of the **analysis infrastructure**, not a target repository. It is designed to be the secure, controlled environment in which other, untrusted repositories are detonated. **Detonation Decision:** No detonation required. This is a configuration file for the sandbox environment itself. It does not contain malicious logic; rather, it implements the security controls (like pinning versions and using a gateway for egress) required to safely analyze other repositories.
Agent analysis (code read, not a runtime observation): Reviewed sandbox/microvm/forge/forge-down.sh: the model took tool action but attached no narrative to this turn.
Agent analysis (code read, not a runtime observation): This file, `sandbox/microvm/forge/forge-up.sh`, is a **foundational infrastructure script** for the sandbox environment itself, not a target repository to be analyzed for malware. ### Analysis * **Purpose:** It sets up a network namespace (`cr-forge-<id>`) to act as a transparent proxy (using `mitmproxy`) and a second namespace (`cr-run-<id>`) for the actual detonation of a target repository. * **Functionality:** It configures `iptables` to redirect all TCP traffic from the detonation namespace through the proxy, sets up a `dnsmasq` instance to intercept DNS queries, and establishes a NATed uplink for legitimate registry traffic (e.g., `npmjs.org`, `pypi.org`). * **Security Context:** This script is part of the **hermetic sandbox harness**. It is designed to enforce containment by ensuring that no traffic from the detonation environment can reach the real internet unless it passes through the controlled proxy. ### Verdict This file is **benign infrastructure code**. It is the mechanism that allows the sandbox to safely observe and sinkhole network activity from untrusted repositories. It does not require detonation as a target; rather, it is the tool used *to* detonate other targets. No malicious behavior was observed. This script is a critical component of the sandbox's containment strategy.
The forge intercepted 6 outbound attempt(s) (telemetry.nextjs.org); each was answered by the forge and no real packet reached its destination. A control probe confirmed the interception and a direct UDP query was dropped (non-TCP egress contained), and the in-VM trace corroborated the egress.