How the attack works
A user or automated process installs dazzle-claude-config (or a variant spelling using underscores, dots, or mixed separators for the same name) via pip or a similar tool. Once installed, the package harvests the local Claude Code configuration file. It rewrites that configuration and then fetches and runs a second-stage payload from a GitHub repository controlled by the attacker. The detection watches for commands that install, fetch, clone, or run this package, and for outbound web requests that reference the package name — whether hitting the PyPI index, downloading the package file, or reaching the GitHub payload repo.
Why it matters
An organisation loses control of its Claude Code configuration, which can expose API keys, tokens, or other sensitive settings, and gets arbitrary second-stage code executed on the affected machine.
What you can do
- Block installation of the package dazzle-claude-config and its name variants (underscore/dot/mixed separator forms) at the package-manager or proxy level.
- Search existing systems for the package name in installed dependencies, pip caches, and command history.
- If found, treat local Claude Code configuration as compromised: rotate any keys or tokens it contained and inspect for unexpected outbound connections to GitHub.
- Review egress logs for requests referencing the package name on PyPI's simple index or GitHub, since this indicates install or payload-fetch activity.
Known benign look-alikes
- Incident responder or malware analyst deliberately installing the package inside a sandbox to reproduce the behaviour - this is a true positive of the behaviour and an intentional analyst action; triage by operator identity.
- Detection engineering work that names the package in a command line (writing a blocklist, an allow/deny policy, or a YARA/Sigma rule) - Tier 2 only, and suppressed when the command uses grep/find/rg or an SCA scanner.
- Remediation - pip/pipx/poetry uninstall or removal of the package directory during cleanup; suppressed by filter_inspect_*.
- Software-composition-analysis or vulnerability scanners (pip-audit, safety, snyk, osv-scanner, trivy, grype) emitting the package name on their command line; suppressed by filter_inspect_*.
- An internal PyPI mirror or artifact cache performing a scheduled upstream sync that pulls the artifact URL - this fires on the http_request branch and is a genuine supply-chain event worth reviewing even when the sync itself is automated.
- Browsing the PyPI project page or a GitHub advisory page for the package via the agent's HTTP fetch - not suppressed (no host/path is trusted), reported at level high for analyst review.