AIdhirajSingh/clauderabbit
We ran AIdhirajSingh/clauderabbit, a node project, in an isolated sandbox. The project did not build to a runnable state. We caught it attempting to reach storage.googleapis.com. Every outbound attempt was intercepted by the sandbox and never reached its destination. Its score is held down by unrecognized install source.
Neutral
Provisioning script fetches and executes an install script from opencode.ai, which is not a standard, widely-vetted software distribution host.
The repository owner has a short account history (7 months) and no established community presence or stars, increasing the risk profile for a security-sensitive tool.
Multiple scripts perform network fetches during setup (deno.land, docker.com, github.com, nodesource.com). While these are common for infrastructure provisioning, they represent a supply-chain surface area.
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): The provided script `sandbox/cloudrun/forge/provision-forge-gateway.sh` is an infrastructure-provisioning script designed to configure a dedicated gateway VM for intercepting and analyzing network traffic from Cloud Run detonation environments. ### Analysis Summary * **Purpose:** The script sets up a transparent MITM (Man-in-the-Middle) proxy using `mitmproxy` and configures `iptables` to redirect all TCP traffic from the Cloud Run environment through this proxy. It also sets up a custom DNS server (`dnsmasq`) to control domain resolution and a forensics API for data collection. * **Lifecycle:** It installs system packages, creates a Python virtual environment, generates a CA certificate for TLS interception, and installs several `systemd` services to ensure the gateway remains active and the network rules are enforced (including a timer to periodically re-assert `iptables` rules). * **Security Context:** This script is part
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
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
Agent analysis (code read, not a runtime observation): Reviewed sandbox/microvm/forge/forge-down.sh; no model narrative.
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 T
The forge intercepted 2 outbound attempt(s) (storage.googleapis.com); 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.