kamalx06 / TornadoC2

# TornadoC2
A pull-based C2 with ten native transports, concurrent
multi-profile handlers, and an honest threat model. The agent is a
single Go binary with every behavioural property baked in at build
time — no runtime config file, no environment variable, no
command-line arguments. Tasks and results are ECDSA-signed end to
end. The transports are HTTPS, QUIC/HTTP/3, WebSocket, DNS TXT,
DNS-over-HTTPS, ICMP, WireGuard, SMB-pivot, TCP-bind, and
TCP-reverse.
---
## Legal Notice
Use this software only on systems you own or on systems where you
hold **explicit written authorization**. You are solely responsible
for compliance with applicable laws and organizational policies.
The authors and contributors accept no liability for misuse, data
loss, or legal consequences arising from the use of this project.
---
 Table of Contents 
- Introduction
- Why TornadoC2 Exists
 - What that shaped
 - What it is not
 - What comes next
- Capability summary
- Key Features
- Design Philosophy
 - Compile-time configuration
 - Startup-time configuration
 - Queue-based execution
 - Artifact discipline on the target
 - Graceful degradation
 - Encryption without loss of auditability
 - Contribution paths with no core coupling
 - Concurrent multi-profile handlers
 - Profile paths as first-class routing
- Operational Security
- Threat Model
- Architecture
- Transports
- Pivot Transports
- Requirements & Installation
 - Go build bootstrap
 - Dependency installers
- Quick Start
- Deployment Playbook
- Build Config File
- Staged Payloads
- Remote Build
- Operator Reference
- GUI Operator Console
- In-Memory Execution
- BOF Registry
- C2 Profile Catalogue
- SOCKS5 Pivoting
- Migration
- Scheduled Tasks
- Task Queue Introspection
- Bulk Operations
- Beacon Aliases and Tags
- Beacon Viewers
- Credential Vault
- Engagement and Per-Beacon Notes
- Webhook Notifications
- Session Graph
- Desktop Notifications
- Wire Protocol
- Native Commands
- Cryptography
- Key Management
- Backup and Recovery
- Self-Update
- OPSEC Profiles
- C2 Profiles
 - Concurrent multi-profile handlers
 - Placeholders
 - Encoding
 - Placement
 - Status codes
 - Cookie name
 - Response headers
 - DNS label shaping
 - Stager path
- Extending TornadoC2
 - Adding a transport
 - Adding a C2 profile
 - Adding a WASM extension
 - The contribution-path summary
- Beacon Extensions
- Server Hardening
- Team Chat
- Loot Store
- Dead-man's Switch
- Session Logging
- Troubleshooting
- TLS & mTLS Configuration
- License
---
## Introduction
TornadoC2 is a **pull-based C2**. The agent does not hold a live
socket; it wakes on its own schedule, checks in with the server,
retrieves queued work, executes it, and goes back to sleep. The
operator queues commands; the beacon picks them up on its next
check-in.
This design trades immediacy for resilience. A live shell dies when
the network flaps; a beacon reconnects on its next wake-up and
resumes. A live shell leaves a persistent footprint on the wire; a
beacon's traffic pattern is