Collaboration, Guardian, MCP, and Community Extensions

Professional pentests are rarely solo efforts. KittySploit provides a real-time collaboration layer, a behavioral guardrail (Guardian), an MCP gateway for AI assistants, and extension mechanisms (plugins, IRC). This chapter covers the full advanced operational stack.

KittySploit collaboration architecture

KittySploit offers two complementary implementations:

• Simple server (core/collab_server_simple.py) --- started via collab_server, lightweight, ideal for isolated test environments and pairs.
• KittyCollab web (interfaces/kittycollab/) --- enriched web interface for remote teams (outside this console chapter scope, but compatible).

Typical flow:

1. The lead operator launches collab_server on a coordination machine.
2. Each member runs collab_connect to the host and shared workspace.
3. Chat (collab_chat) synchronizes messages and workspace state.
4. The lead shares a loaded module with collab_share_module.
5. Peers retrieve it with collab_sync_module.

Logical diagram

  [Operateur A]                    [Operateur B]
       |                                |
       |  collab_connect host:8080      |
       v                                v
  +--------------------------------------------------+
  |     collab_server (SimpleCollaborationServer)     |
  |     workspace: mission-2026 | password optional   |
  +--------------------------------------------------+
       |                                |
       +-------- collab_chat ------------+
       +-- collab_share_module / sync ---+

collab_server command

Startup

collab_server --host 0.0.0.0 -p 8080 -P "team-password" -w mission-2026 -v

• --host --- listen interface (default 127.0.0.1; use 0.0.0.0 behind a restricted firewall).
• -p / --port --- TCP port (default 8080).
• -P / --password --- optional authentication but strongly recommended.
• -w / --workspace --- collaborative workspace name (default default).
• -v / --verbose --- detailed logs.

The server registers as a background job via the job_manager. You can find it with jobs and stop it cleanly:

collab_server stop

Deployment best practices

1. Reserve a dedicated workspace per mission (-w client-acme-q2).
2. Document URL, port, and password in the official communication channel (not via unencrypted email).
3. Verify that each operator's local workspace is consistent before sharing modules (hosts, scope).
4. Stop the server at end of day (collab_server stop) to avoid ghost connections.

Troubleshooting

• Port in use --- change -p or identify the process with ss -tlnp | grep 8080.
• Connection refused --- host firewall or overly restrictive --host.
• Workspace out of sync --- reconnect with the same -w.

collab_connect command

Syntax and options

collab_connect 192.168.10.5 --port 8080 -P "team-password" \
  -u alice -w mission-2026 -v

• host (required) --- collaboration server address.
• --port --- port (default 8080).
• -P / --password --- password if the server requires it.
• -u / --username --- display nickname in chat (default Anonymous).
• -w / --workspace --- target workspace (must match the server).
• -v / --verbose --- connection traces.

After successful connection, the framework stores framework.collab_client and switches current_collab context. Collaborative commands fail without this step.

Disconnect

collab_disconnect

Releases the client and restores local workspace context.

Pair scenario

# Terminal Alice
workspace use dvwa-lab
collab_server -p 9090 -P "team2026" -w dvwa-lab

# Terminal Bob
collab_connect 10.0.0.10 --port 9090 -P "team2026" -u bob -w dvwa-lab
collab_chat

collab_chat command

collab_chat opens an interactive messaging interface linked to the collaborative workspace. It displays incoming messages in real time and accepts your contributions.

Usage

collab_chat

Prerequisite: connected via collab_connect. Typical internal commands (depending on version): help, user list, quit (/quit or equivalent shortcut).

Operational use cases

• Coordination --- announce ``I am launching an exploit on 10.0.0.42'' to avoid collisions.
• Context transfer --- share a session identifier or module path without leaving the console.
• Light logging --- chat is not a substitute for the report, but it documents decisions in real time.

Module sharing: collab_share_module and collab_sync_module

Share (collab_share_module)

The lead loads a module, configures options, then publishes to the collaborative workspace:

use auxiliary/scanner/http/xss_scanner
set rhost 10.0.0.20
set rport 443
set ssl true
collab_share_module

Data transmitted: module path, options, __info__ metadata, source code if new module, timestamp and author.

Synchronize (collab_sync_module)

Peers retrieve the shared module:

collab_sync_module
collab_sync_module --apply-code

• Without --apply-code --- loads the module and applies shared options.
• With --apply-code --- also writes source code to disk (custom modules or quick fixes).

Advanced collaborative editing

Associated commands (mentioned for completeness):

collab_edit_module start    # Start shared editing
collab_sync_edit            # View the current edit buffer
collab_sync_edit --apply    # Apply changes

Recommended workflow

1. Lead: use + set + check validation.
2. Lead: collab_share_module.
3. Team: collab_sync_module then run after scope verification.
4. Document in the report which operator ran which module.

Guardian: offensive behavioral protection

Guardian and honeypot / AD honeytoken detection are detailed in chapter § (threshold concepts, honeytoken_hunt, false positives). Below: operational recap and collaboration/MCP integration.

Activation and status

guardian enable
guardian enable --verbose --auto-action
guardian disable
guardian status
guardian config

• --verbose --- detailed logging of evaluations.
• --auto-action --- automatic protective actions (blacklist, critical alerts) without manual confirmation.

Baseline mode

guardian learn --operations 100

Analyzes operation history to refine thresholds (response time, honeypot signatures). Shows model precision evolution.

Host blacklist

guardian blacklist add 192.168.1.50 --reason "Honeypot Cowrie detecte"
guardian blacklist show
guardian blacklist remove 192.168.1.50

Blacklisted hosts are blocked or warned before module execution. Combine with guardian ack for false positives:

guardian ack 10.0.0.99 --note "Legitimate dev server, high latency"

Alerts

guardian alerts
guardian alerts --count 25

Each alert includes: severity, target, issue, confidence, evidence, recommendations, and possible automatic action.

Manual host test

guardian test 192.168.1.50
guardian test 192.168.1.50 --deep

Produces an investigation report: behavioral analysis, network context, verdict, and recommendation.

Active Directory honeytokens

Guardian tracks suspicious identities via the lastLogon oracle and LDAP signals.

use scanner/ldap/honeytoken_hunt
set rhost dc.corp.local
run

guardian identities show
guardian identities show --min-score 60 --count 50
guardian identities ack DOMAIN\_backup --note "Valid service account"

• identities show --- lists high-score accounts (never authenticated, deception signals).
• identities ack --- marks an account as safe after manual verification.

Integration into the run cycle

When a module targets an IP, Guardian displays a preview before execution: active monitoring, blacklist size, target evaluation. Enable Guardian before large-scale exploitation phases.

MCP: Model Context Protocol

KittySploit exposes the framework to AI assistants via MCP. Main components:

• interfaces/mcp_kittysploit_server.py --- MCP server (structured tools).
• interfaces/mcp_kittysploit_bridge.py --- command / NL planning bridge.
• kittymcp_client.py --- natural language client (without external MCP).
• kittymcp_server.py --- standalone server entry point.

MCP security principles

The MCP server enforces:

• Usage charter (--accept-charter or interactive acceptance).
• Encryption via KITTYSPLOIT_MASTER_KEY.
• Explicit consent for dangerous actions (--dangerous-consent).
• Audit log (ks_mcp_audit).

Typical exposed tools: ks_plan_natural_request, ks_prepare_module_run, ks_run_module, ks_execute_command, ks_execute_natural_request.

Starting the MCP server

python kittymcp_server.py --host 127.0.0.1 --port 8765 \
  --dangerous-consent

Useful environment variables:

export KITTYSPLOIT_MASTER_KEY="your-key"
export KITTYMCP_DANGEROUS_CONSENT=1
export KITTYMCP_OLLAMA_ENABLED=1
export KITTYMCP_OLLAMA_MODEL="llama3.2"

kittymcp_client client

Interactive mode or single query:

python kittymcp_client.py --master-key "KITTYSPLOIT_MASTER_KEY" \
  --accept-charter

python kittymcp_client.py "scan ports on 10.0.0.0/24" \
  --master-key "KITTYSPLOIT_MASTER_KEY" --run --allow-dangerous

Key options:

• --ollama / --no-ollama --- local assisted planning.
• --run --- executes the first recommended command.
• --allow-dangerous --- authorizes risky commands.
• --max-candidates --- limits candidate modules (default 6).

Recommended MCP flow for an AI assistant

1. ks_plan_natural_request --- interpret intent and target.
2. ks_prepare_module_run --- resolve options and profile (discreet).
3. Human operator confirmation.
4. ks_run_module --- execution with client_id for logs.
5. ks_mcp_audit --- verify the trace.

Cursor / IDE integration

Configure the KittySploit MCP server in your IDE settings (stdio or SSE). Refer to project documentation for the exact path and arguments. Test first in planning mode without dangerous-consent.

plugin command

Plugins extend KittySploit without modifying the framework core. They reside in plugins/ and are managed by plugin_manager.

Subcommands

plugin list
plugin search tunnel
plugin load ngrok
plugin info ngrok
plugin run ngrok -c 8080
plugin unload ngrok
plugin reload ngrok
plugin create myplugin "Plugin description"
plugin help

Lifecycle

1. plugin create generates a Python skeleton inheriting from Plugin.
2. Implement __info__ (name, version, author, dependencies).
3. plugin load then plugin run to test.
4. plugin reload after file modification.

Example: ngrok tunnel

plugin load ngrok
plugin run ngrok -c 8080

Useful for exposing a reverse shell in the isolated test environment or receiving callbacks on an engagement with explicit egress rules.

Best practices

• Audit source code before load (no unreviewed arbitrary exec).
• Version your custom plugins in a separate repository.
• Document pip dependencies in the plugin README.

irc command: KittySploit community

Connection

irc -u operator_nick
irc --username operator_nick

Connection to the Libera Chat network, channel #KittySploit. Interactive chat interface with internal commands (help, user list, quit).

Professional use

• Ask questions about modules and workflows.
• Share experience feedback (without client data).
• Follow version announcements and community best practices.

Integrated scenario: remote team with Guardian and MCP

# Lead
workspace create corp-internal-q2
scope add 10.20.0.0/24
guardian enable --verbose
collab_server --host 10.0.0.1 -p 8080 -P "team-secret" -w corp-internal-q2

use auxiliary/scanner/portscan/tcp
set rhosts 10.20.0.0/24
collab_share_module

# Remote consultant
collab_connect vpn.lead.local --port 8080 -P "team-secret" -u remote1 \
  -w corp-internal-q2
collab_sync_module
collab_chat

# After scan
guardian alerts
campaign --preview

# AI assistant on lead workstation, valid mandate
python kittymcp_client.py "export the workspace ATT&CK map" \
  --master-key "$KITTYSPLOIT_MASTER_KEY"

Command summary table

Advanced troubleshooting

Collaboration

• Not connected to collaboration server --- run collab_connect.
• No module has been shared --- lead must run collab_share_module.
• Option desync --- re-share after final set.

Guardian

• Too many alerts on a known isolated test environment --- guardian ack or learn.
• Honeytokens not listed --- run scanner/ldap/honeytoken_hunt then guardian identities show.

MCP

• Charter not accepted --- --accept-charter or launch kittysploit interactively once.
• Encryption not initialized --- provide --master-key.
• Blocked actions --- enable KITTYMCP_DANGEROUS_CONSENT.

Toward outputs

Collaboration produces a team trace; Guardian reduces honeypot false positives; MCP accelerates preparation. Campaign and reporting commands turn this data into campaign graphs, ATT&CK exports, and PDF reports via kittyreport.