ArachneC2 ships implants, so use it only where you have written permission

The disclaimer is the first requirement, not a footnote

The document carries its own limit in a section titled Disclaimer: the software is provided for educational and authorized security testing purposes only, it must only be used on systems you own or have explicit written permission to test, and unauthorized access to computer systems is illegal. That sentence is the entry condition for everything else here, and the reason is visible in the feature list rather than hidden in it. The implants can daemonize on Linux and macOS and hide their console on Windows, they can be compiled with function names, package paths and literal strings stripped, they can run 65 or more virtual machine detection techniques, and the design goal is stated as having no servers, no domains and no IP addresses to block, so that no single VPS can be taken down. A beaconing implant with cover traffic that masks its own timing and a quiet mode that survives a logout is a remote access tool in the plainest sense, and the authorization line is what separates an engagement from an intrusion.

What follows describes the architecture and the repository. It does not walk through generating, deploying or operating an implant.

The transport is TCP and WebSocket, and that choice is the whole design constraint

Peer discovery uses a GossipSub publish and subscribe layer and a Kademlia DHT over the public IPFS peer to peer network, with the implant fleet and the operator sitting as equal peers rather than as clients of a server. The transport underneath is TCP and WebSocket, and the feature list names the reason directly: UDP and multicast free, for sandbox compatibility.

That single constraint explains a lot of the rest. DHT and GossipSub discovery conventionally lean on UDP, and a sandboxed environment frequently blocks both UDP and multicast outright. Choosing relay circuits carried over TCP and WebSocket trades raw efficiency for reachability, and it brings the keepalive requirement with it, since a stream keepalive exists to stop the relay circuit from hitting its idle timeout. It also brings a third party into the path. The security section claims relay nodes see only encrypted bytes and cannot read or modify traffic, which is a statement about message level confidentiality, not about the fact that traffic is relayed through infrastructure the operator does not control and cannot audit. The IPFS framing is backed by indirect requirements in the manifest, including `github.com/ipfs/boxo v0.10.0` along with the go-cid and go-datastore modules, so the peer to peer network is the real one rather than a libp2p network standing in for it.

Identity is pinned to one operator key, and rotating it silently orphans the fleet

The identity model has three moving parts. The operator generates a keypair on first run, keeping the private key at `~/.arachne/operator.key` and exporting the public key to `~/.arachne/operator.pub`. Every implant build embeds a unique keypair of its own, so the PeerID stays the same across restarts on that machine. And each implant embeds the operator's public key, so it accepts commands from that operator and no other.

Messages are signed with Ed25519 and encrypted with NaCl box, peer identity is checked on every message through envelope signatures, and commands travel on per implant topics so a command reaches only the implant it was addressed to.

The tension is in the first two parts together. A PeerID that survives restarts is what makes an implant persistent, and it is also what makes one machine identifiable across every session it ever has. The design takes that trade knowingly, since the stability is the point. The sharper edge is the `regenerate` command: it produces a new operator keypair, and the command table states plainly that old implants are orphaned by it. One console command ends every existing session with no error on the implant side, because the implants still trust a key nobody is presenting any more.

A requirements.txt in a Go repository that omits the module the design runs on

The root of a Go project carries a Python style dependency file. Its five lines are Go module paths with versions, not pip requirement syntax:

github.com/libp2p/go-libp2p v0.36.5
github.com/libp2p/go-libp2p-pubsub v0.12.0
github.com/multiformats/go-multiaddr v0.13.0
google.golang.org/protobuf v1.34.2
google.golang.org/grpc v1.67.0

A space separated name and version is not a valid pip requirement, so the file will not do what its name implies. It is also an incomplete copy of the real manifest, which declares six direct requirements:

github.com/libp2p/go-libp2p v0.36.5
github.com/libp2p/go-libp2p-kad-dht v0.24.4
github.com/libp2p/go-libp2p-pubsub v0.12.0
github.com/multiformats/go-multiaddr v0.13.0
google.golang.org/grpc v1.67.0
google.golang.org/protobuf v1.34.2

The one line missing from the shorter file is `go-libp2p-kad-dht`, the Kademlia DHT that the peer discovery design is built on. Anyone who installs from requirements.txt, or reads it as the dependency list, is missing the module the architecture depends on most.

Advertised transports and the PTY shell are satisfied by indirect requirements

Two more load bearing pieces of the feature list are not in the direct requirement block. The WebSocket transport, which the sandbox compatibility argument rests on, is served by `github.com/gorilla/websocket v1.5.3`, marked indirect. The interactive shell, documented as a PTY on Linux and macOS and a hidden ConPTY on Windows, depends on `github.com/creack/pty v1.1.24`, also marked indirect.

Neither of those is wrong. Indirect is the normal label for a module that arrives through another dependency rather than being imported directly by the project's own code, and a library that wraps a WebSocket implementation or a PTY helper can legitimately never import it by name. The point is narrower: the two features most often described as the reasons to reach for this kind of framework are the two the manifest does not claim, so the visible dependency list is thinner than the capability list. The same is true of the gRPC dependency, which is direct while the document never describes a gRPC surface, and of `github.com/google/gopacket v1.1.19` sitting indirect for a project whose stated transport is TCP and WebSocket.

The virtual machine detection claim is carried the same way, and more completely. The feature list names CPUID signatures, MAC prefixes, DMI and SMBIOS data, PCI vendor IDs, process enumeration, registry keys and container detection. The manifest that backs those techniques is entirely indirect: `github.com/elastic/gosigar v0.14.3` for host metrics, `github.com/coreos/go-systemd/v22 v22.5.0` for service enumeration, and `github.com/containerd/cgroups v1.1.0` for container awareness. The single most defensive feature in the readme is also the one with no line of its own in the dependency list.

The manifest targets Go 1.22 and builds with setuptools nowhere in sight, which is the one place the two ecosystems are cleanly separated.

The structure map omits a top level server directory

The map at the top of the readme is short and mostly annotated, and it stops early:

arachne-c2/
├── build.sh                # Build script (auto-installs Go if missing)
├── bin/                    # Compiled binaries
├── cmd/
│   └── arachne/            # Single entry point (serve + generate)
├── docs/                   # Design documentation
├── implant/                # Implant agent code
│   └── core/               # Agent runtime, command handlers, shell, portfwd
├── pkg/
│   ├── config/             # Shared config types
│   ├── cryptography/       # Ed25519 + NaCl key management
│   └── transport/          # libp2p node, messenger, PubSub helpers
├── protobuf/

The last line has no comment while every other line does, and the map is narrower than the repository. The root also carries `go.mod`, `go.sum`, `requirements.txt`, `.gitignore` and a top level `server/` directory that appears nowhere in the map. That last one is worth a second look, because the project's central claim is that it replaces a central server with a peer to peer network. A directory named `server/` at the root of a decentralized C2 is either a leftover from the centralized design this was modelled on, a test harness, or a component the documentation has not caught up with, and nothing in the repository says which. The single entry point is described as covering both serving and generating, which leaves the question open as well.

One release, named for a feature the readme does not mention

The repository has a single published release, v0.2.7, dated 2026-06-11 and titled v0.2.7 with the name SOCKS5 proxy. The current readme never mentions a SOCKS5 proxy. What it documents instead is port forwarding through an implant over a direct libp2p stream, exposed in the command table as forwarding a local port to a host and port pair.

Those are different mechanisms with different failure modes, so the release history and the documentation are describing two different products. Either the feature was renamed or replaced after the tag, in which case v0.2.7 is the artifact anyone pinned to a proxy is actually running, or the readme was rewritten for a later design and the release note was never revisited. Nothing in the repository resolves it: there is no changelog at the root, and `docs/` is described only as design documentation without listing what is in it.

The naming is inconsistent in the same way. The go.mod module path is CamelCase, the structure map calls the directory `arachne-c2/`, compiled binaries are written as `arachne-{os}-{arch}` with an `.exe` suffix on Windows, and the tag is lowercase `v0.2.7`. Four conventions for one project, and the default branch is `master` rather than `main`.

Editorial conclusion

ArachneC2 is defensible as red team tooling for engagements where a written scope exists, and indefensible as anything else, because the same build switches that make it useful in an authorized exercise, quiet mode, garble obfuscation and VM detection, are what make it malware when pointed at a machine nobody authorized you to touch. Before anyone runs it, settle three questions the repository leaves open. There is no LICENSE file at the root, the repository's license metadata is empty, and only the readme asserts GPLv3, so the licensing is prose rather than a fact you can point at. The single published release, v0.2.7, is named for a SOCKS5 proxy that the current feature list does not mention, so the release history describes a different product than the documentation. And the last push to the master branch is dated 2026-06-16, which is the date to weigh before planning around it.

Frequently asked questions

Official sources

1. Issues
2. portbuster1337/ArachneC2 on GitHub
3. README
4. Releases