Skip to content

SquidC5: Free Open Source Self-Hosted C5 Teamserver for Authorized Red Teams

SquidC5: Free Open Source Self-Hosted C5 Teamserver for Authorized Red Teams

Hey everyone, Mr. The Plague here from SquidSec.

Commercial C2 is expensive. A lot of “free” options still want your engagement data on someone else’s cloud, or they ship as a pile of containers you babysit all weekend. SquidSec wanted something different for authorized red team and pen test work: a teamserver you run yourself, on hardware you control, with source you can read.

Today SquidSec is announcing SquidC5.

Free. Open source. Self-hosted.

AI-native red teaming with a built-in MCP server.

Your lab. Your rules. Your data stays put.

GitHub: github.com/SquidSec/SquidC5
License: MIT
Price: $0. Forever. No “community tier” upsell.

SquidC5 is a security-first, AI-native C5 platform: Command, Control, Cognitive, Collaborative, Coordination. In plain English, it is the hub your operators use to task implants, run reverse shells, coordinate a team, and keep an audit trail that still makes sense after the engagement ends.

One of the big reasons SquidSec built it: AI should be a first-class citizen in red team operations, not a chatbot taped onto the side of a teamserver. SquidC5 ships with a built-in MCP server (Model Context Protocol) so external agents and operator tooling can talk to the C5 over allow-listed tools. On the inside, a sandboxed Admin AI helps with recon notes, shell triage, opsec review, payload guidance, and report drafts. Same teamserver. Same audit trail. Same scopes and policy engine.

The operator-facing name for that neural chat surface is INKO (Intelligent Neural Kinetic Operator). In the ops console, an INKO control in the top bar opens a right-side flyout (full screen on mobile) so you can talk to the C5, inspect live state, and run railed actions without leaving the engagement UI.

INKO Intelligent Neural Kinetic Operator chat flyout on the SquidC5 ops console
INKO in action: Intelligent Neural Kinetic Operator flyout on the ops console.

Authorized use only. If you do not have written permission to test a target, do not use this tool. Unauthorized access is illegal. Full stop.

SquidC5 ops console Listeners view with DNS HTTP SMTP and reverse shell acceptors running
Ops console: listeners, event stream, and session context on a live SquidC5 teamserver.

Why SquidSec built a self-hosted teamserver

If you have run real ops in the last few years, you already know the pain:

  • License math that turns a two-week external into a budget meeting
  • Fingerprints so well known that defenders signature the default profiles before lunch
  • Cloud-shaped tools that are fine until counsel asks where session output and client names lived
  • AI bolted on sideways, with no clear answer for who can call shell, what got logged, or how prompt injection from a hostile host gets contained

SquidSec builds and breaks systems for a living. That includes caring how the operator platform itself is secured. A teamserver is high-value infrastructure. It should not be a convenience default with public API docs hanging off the front door.

SquidC5 is the answer from SquidSec: 100% free, MIT open source, designed to self-host, with privacy-friendly defaults and AI that stays on rails.

What “C5” means (and why it is not just another C2 label)

PillarWhat you get
CommandTask shells, beacons, and native implants
ControlScoped API tokens, policy engine, human-in-the-loop gates, feature kill switches
CognitiveBuilt-in MCP server for AI agents + sandboxed Admin AI (first-class, policy-railed) + INKO (Intelligent Neural Kinetic Operator) for in-ops chat
CollaborativeSession claim/lock, handoff packs, spectator mode, presence, team chat
CoordinationMalleable C2 profiles, OAST collaborator, timeline, engagement reports

Most frameworks stop at “command and control.” SquidC5 treats multi-operator workflow, auditability, and AI as a real ops surface (MCP + Admin AI under the same policy and audit rails) as product requirements, not blog-post promises.

Privacy and self-hosting first

This is the part worth being loud about.

You run the server

SquidC5 is not a hosted SaaS C2. There is no SquidSec cloud that ingests your beacons for “analytics.”

You can stand it up:

  1. On a lab laptop with Docker Compose for training and internal drills
  2. On a VPS or bare metal you rent or own for an authorized engagement
  3. On air-gapped or tightly firewalled infrastructure when the ROE demands it

Recommended production path: pull the release binary from GitHub Releases, keep your data/ directory on disk you control, terminate TLS how your redirector design requires.

Your engagement data stays local

By default the teamserver keeps state in local SQLite under data/ on the host you chose. That includes sessions, tasks, audit rows, and operator configuration.

That matters when:

  • The client contract says engagement artifacts do not leave a region
  • You are testing from a restricted lab and SaaS is a non-starter
  • You simply do not want a third party holding shell output and target metadata

Tokens bootstrap onto disk with tight file modes. LLM API keys, if you configure any, are stored server-side and encrypted at rest. They are not shipped back to browsers in status calls.

No mandatory phone-home

You do not need a SquidSec account to start the server. You do not need a SquidSec cloud LLM. Admin AI can run in offline deterministic mode, or you can point it at your OpenAI-compatible endpoint, including a local Ollama instance on the same network.

The MCP server is built into SquidC5. You do not bolt on a side process to make agents useful. For production posture it stays off until you enable it, and every tool call is still allow-listed per token and audited. AI is first-class. Open-ended shell for a random model is not.

Secure defaults on a box that will get scanned

Internet-facing listeners attract garbage traffic. SquidC5 assumes that:

  • TLS on by default (unique self-signed cert on first start, or bring your own)
  • Public OpenAPI / Swagger off (hard-locked; the running C2 does not advertise a full API map)
  • Empty CORS by default (same-origin ops UI)
  • Scoped bearer tokens instead of one shared god password for every laptop
  • False-shell filtering and exec probes so random scanners do not become “sessions”
  • Immutable audit hash chain you can verify with sc5 audit-verify
  • Rate limits and body limits aimed at credential stuffing and abuse

Self-hosting only helps if the software respects the threat model. It is written like the teamserver will sit on a hostile network, because eventually it will.

What you can do with SquidC5 today

Operate how you already work

  • Ops UI at /ops in the browser
  • CLI via sc5 (login, sessions, shell, tasks, listeners, implants, AI, audit)
  • REST API with least-privilege scopes for automation
  • INKO top-bar flyout for neural operator chat (history kept in the browser; markdown replies)
  • Multi-page ops nav: Sessions, Listeners, Payloads, Post-Ex, Collab, INKO, Observe, Admin (plus mobile drawer)
  • Phone QR to open ops on a handset and auto-connect with the current server settings
SquidC5 sessions list showing active beacons and hosts
Sessions: beacons and reverse shells in one place. Claim before multi-op tasking.

Channels and implants

  • Reverse shell listeners with verification and optional stage-2 stabilize
  • HTTP, DNS, and WebSocket-oriented beacon paths
  • Deterministic payload templates you can review and archive for the engagement file
  • Native Go implant (sc5beacon) with AEAD check-ins (ChaCha20-Poly1305), sleep/jitter/kill date/working hours, file ops, jobs, and SOCKS reverse-dial; TLS verifies system CAs (no skip-verify flag in the native agent)
  • Implant factory: sc5 implants build or the build API
SquidC5 listeners panel with DNS, HTTP, SMTP, and reverse shell acceptors running
Listeners: bind reverse shells, HTTP/DNS beacons, and OAST acceptors on the ports you choose.
SquidC5 payload generator with implant and beacon templates
Payloads: deterministic templates for HTTP/WS beacons and reverse shells you can review before use.

Traffic shape

Malleable-style C2 profiles plus transforms (base64, prepend/append, xor, netbios) and profile push so generators and parsers stay aligned. Redirector helpers so the teamserver is not the only face on the internet.

Team play

Real engagements are not one person and one shell forever:

  • Claim and lock sessions so two operators do not stomp each other
  • Handoff packs for shift change
  • Spectator snapshots for leads
  • Presence and team chat
  • Per-operator audit views
SquidC5 collab panel with team chat, presence, and session handoff
Collab: team chat, presence, and session handoff for real multi-operator work.

Engagement governance

Banned commands, engagement end time, human-in-the-loop gates (server-side; client “approved” flags are ignored), backups, deep health checks. Built for people who have to answer for the op afterward.

AI-native red teaming with built-in MCP

This is a core storyline for SquidC5, not a sidebar feature.

Most C2 stacks treat AI like an afterthought: paste output into a chat app, hope nothing sensitive leaks, and pray the model does not invent a command path you never approved. SquidC5 flips that. AI is designed into the teamserver the same way listeners, sessions, and audit are.

Built-in MCP server

SquidC5 includes an MCP server in the C5 process. External AI agents and operator tooling can connect with scoped tokens and call allow-listed tools against live engagement state: sessions, tasks, metrics, and more as you open them up.

That means your agent stack talks to the same authority rails humans use:

  • Bearer tokens with least-privilege scopes
  • Per-token MCP tool allow-lists (not “the model can do anything the admin can”)
  • Policy limits such as short chain length by default
  • Full audit on tool calls
  • Feature flag so you enable MCP when the engagement needs it

If you are wiring Claude, custom orchestrators, lab automation, or other MCP-capable agents into a red team workflow, you should not need a sketchy glue service. The teamserver is the MCP endpoint.

MCP is the bridge for external agents. INKO is the in-console operator chat. Both sit on the same deny-by-default rails; they are complementary, not duplicates.

Admin AI on the rails

Alongside MCP, SquidC5 runs a sandboxed Admin AI for operators on the server itself. Capabilities are fixed functions, not an unsupervised loop with root on every session:

  • recon assist
  • shell classify
  • opsec review
  • payload / implant guidance
  • report and doc drafts
  • session triage, task suggest, HITL briefs, and more on the allow-list

Untrusted session text goes through sanitization before it hits a prompt. You can BYO an OpenAI-compatible endpoint (including local Ollama), or run offline deterministic fallbacks when no model is configured. Keys stay server-side.

SquidC5 Configure LLM BYO panel with xAI Grok OpenAI Groq OpenRouter and local Ollama providers
BYO LLM: OpenAI-compatible providers (xAI Grok, OpenAI, OpenRouter, Ollama, and more). Keys encrypted at rest and never returned by the API.

INKO (Intelligent Neural Kinetic Operator)

INKO is the branded neural operator on top of the sandboxed Admin AI stack. It is how operators chat the teamserver during an engagement.

  • Top-bar control: open INKO from the ops header (not a floating FAB)
  • Desktop: right-side flyout panel roughly the width of the chat surface you already saw in ops
  • Mobile: flyout takes the full window
  • Chat tools: inspect sessions, listeners, events, and run allow-listed actions under the same scopes and HITL policy as human operators
  • UX details: chat history persists in the browser, input clears on send, pending indicator while waiting, send blocked until the reply finishes, assistant replies render markdown safely
  • API: POST /api/v1/ai/chat and GET /api/v1/ai/tools for the railed tool surface

First-class does not mean unrestricted

First-class AI means the platform expects models in the workflow and gives them a real interface. It does not mean a model inherits admin and skips HITL. Deny by default. Scope everything. Audit everything. That is how you run AI on authorized ops without turning the C5 into someone else’s autonomous breach box.

Free and open source means free and open source

QuestionAnswer
Cost$0
LicenseMIT
SourcePublic on GitHub under SquidSec
SaaS requirementNone
Telemetry requirementNone from SquidSec to use the core product
Who can fork itYou, your company lab, your nonprofit training range

Releases ship CI-built Linux/Windows server and CLI binaries, native agent artifacts, checksums, and SBOM. Sister project SquidGate gates PRs on the security side because the teamserver is the product.

If you want to pay SquidSec for something, hire us to pentest or use SquidScanner for agentic recon. SquidC5 itself is not a freemium funnel.

How it sits next to tools you already know

Fair comparison, not a dunk contest:

  • Cobalt Strike remains the commercial benchmark for many red teams. SquidC5 is free, self-hosted, open source, and AI-native with built-in MCP. It is not claiming twenty years of Beacon ecosystem overnight.
  • Sliver is excellent open adversary emulation with mature implants. SquidC5 pushes harder on built-in MCP, Admin AI, teamserver privacy defaults, and lightweight single-node self-host (Python service + SQLite) while still shipping a native Go beacon.
  • Mythic is outstanding multiplayer and data modeling, usually as a multi-container stack. SquidC5 aims at operators who want collab and audit without a small Kubernetes hobby.
  • Havoc raised the bar on modern UX and malleable agents; upstream archival is a reminder that your ops stack should be something you can own and keep running.

Use the right tool for the ROE. Fork SquidC5 when you need a private, free, self-hosted C5 with AI and MCP designed in, and source you can read line by line.

Quick start (lab)

Docker lab:

git clone https://github.com/SquidSec/SquidC5.git
cd SquidC5
docker compose up --build -d
curl -sk https://127.0.0.1:8443/api/v1/health
docker compose exec squidc5 cat /data/admin_token.txt
# Ops UI: https://127.0.0.1:8443/ops

Local Python:

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements-dev.txt && pip install -e .
squidc5
# token: data/admin_token.txt

CLI:

sc5 login --url https://HOST:8443 --token sc5_... --insecure
sc5 sessions list
sc5 implants build --os linux --arch amd64 --host C2_HOST --port 8443
sc5 audit-verify

Docs live in the repo (user guide, operator runbook, threat model, deployment). They are not exposed on the running C2 process. That is intentional.

Production path: ship the CI-built teamserver binary from GitHub Releases (not ad-hoc source rsync). Keep the host data/ directory intact across upgrades. Optional SBOM and checksums ship with release assets. Sister project SquidGate gates PRs on the security side before merge.

Who SquidC5 is for

  • Red team and pen test shops that need a private, AI-native teamserver
  • Teams wiring MCP-capable agents into authorized ops without a sketchy glue box
  • Operators who want INKO in the console for railed neural chat during the engagement
  • Purple teams and detection engineers building labs they fully control
  • Solo operators tired of license keys for basic beaconing in a home lab
  • Organizations with data residency / privacy constraints that block SaaS C2
  • People who want first-class AI with scopes, allow-lists, and audit, not unrestricted model shell

Who should not use it

  • Anyone without authorization
  • Anyone expecting a finished, audited, “never detect me” commercial implant suite on day one

SquidC5 is under active development (alpha 0.1.x line). Native implant, multi-op collab, malleable transforms, SOCKS duplex, audit verify, and the AI capability pack are real and landing fast. Full Windows COFF mapped execute, richer P2P channels, and an external security audit are still on the climb. Better to say that up front than market vapor.

Get the code

Repository: https://github.com/SquidSec/SquidC5
Releases: https://github.com/SquidSec/SquidC5/releases/latest
SquidSec: https://squidoffense.com

Star it if it is useful. Open issues when something is wrong. Send PRs if you want a feature enough to help maintain it. That is how open source teamservers stay honest.

Self-host your C5. Keep the engagement on your disk. Run AI as a first-class operator surface over built-in MCP, Admin AI, and INKO. Spend the license budget on coffee and better redirectors.

Mr. The Plague / SquidSec
U.S. Veteran-Owned

FAQ

Is SquidC5 really free?

Yes. MIT licensed open source. No paid core tier required to self-host.

Is SquidC5 a cloud service?

No. You host the teamserver. SquidSec does not need to receive your session data for the product to function.

Can I run SquidC5 fully offline?

Yes for core C2. Optional Admin AI works offline with deterministic fallbacks, or against a local Ollama-compatible endpoint you run yourself.

Does SquidC5 replace Cobalt Strike?

It is an alternative for authorized teams that want free, open, self-hosted C5 with strong defaults. Feature ecosystems differ. Choose based on engagement needs.

What is INKO?

INKO stands for Intelligent Neural Kinetic Operator. It is SquidC5’s in-ops neural operator chat: top-bar flyout on desktop, full screen on mobile, railed tools, audited actions, BYO or local LLM.

Does SquidC5 include an MCP server?

Yes. MCP is built into the teamserver. Enable it when you need external agents, mint a scoped token with an explicit tool allow-list, and keep every call on the audit trail. Off by default for safe posture. First-class when you turn it on.

Only for authorized security testing and education. You are responsible for scope and ROE.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.