Roles and Collection

The Four Roles

#

Admin

#

Admins have unrestricted access to the entire system.

• Create and manage user accounts (all roles)
• Create, archive, and import engagements
• Grant and revoke operator access to engagements
• Issue and revoke collector grants
• All operator capabilities

There must always be at least one admin. The system prevents you from demoting, deactivating, or deleting the last admin.

Operator

#

Operators run engagements. They need explicit access grants per engagement (admins grant this).

Operators can:

• Deploy and task agents
• Create and manage listeners
• Build agents
• Load and unload modules
• Manage credentials
• Upload and download files
• Issue collector grants (scoped to specific agents, time-limited)

Operators cannot manage user accounts or create engagements — those are admin-only.

Spectator

#

Spectators have read-only access to the engagements they are granted access to.

Spectators can:

• View agents, task results, listeners, credentials, builds
• View the audit log
• View file transfer records

Spectators cannot execute any actions — no tasks, no module loads, no file transfers.

Collector

#

Collectors start with the same baseline as spectators (read-only). The difference is that operators can issue dynamic grants that temporarily elevate a collector’s permissions for specific operations on specific agents.

This role is designed for personnel who need to retrieve data from targets (files, credentials) but should not have the ability to issue arbitrary commands.

Permissions Matrix

#

“Grant only” means the action is permitted only when an admin or operator has issued an explicit dynamic grant for that action scoped to specific agents.

Engagement Access

#

Non-admin users must be explicitly granted access to each engagement. Without a grant, they cannot see the engagement’s objects.

Grant Access (admin)

#

1

tantoc2> operators grant <username> <engagement-name-or-id>

Web UI: Admin page > click an operator > click “Grant Access” > select engagement.

Revoke Access

#

1

tantoc2> operators revoke <username> <engagement-name-or-id>

Revoking access does not delete the operator or their data — they just lose the ability to see that engagement.

Collector Dynamic Grants

#

Operators and admins can issue temporary, scoped grants to collectors. This is the primary mechanism for giving a collector access to specific operations.

Issue a Grant via API

#

1
2
3
4
5
6
7
8
9

curl -X POST https://teamserver:8443/api/v1/collectors/grants \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "collector_id": "<collector-user-id>",
    "permission": "manage_agents",
    "agent_ids": ["<agent-id-1>", "<agent-id-2>"],
    "expires_at": "2026-04-01T00:00:00Z"
  }'

Parameters:

Revoke a Grant

#

1
2

curl -X DELETE https://teamserver:8443/api/v1/collectors/grants/<grant-id> \
  -H "Authorization: Bearer $TOKEN"

Grant Best Practices

#

• Scope to specific agents. Do not use "agent_ids": null unless the collector legitimately needs all agents.
• Set an expiry. Even short-lived grants should expire. Match the expiry to the collection window.
• Revoke promptly. If a collector finishes their work early, revoke the grant immediately.
• Minimum necessary permission. Start with read-only and only issue grants when collection is actively happening.

Collection Workflow

#

When a collector downloads a file from an agent, TantoC2 creates a collection request rather than delivering the file immediately. An operator or admin must review and approve the request.

Step 1: Collector Initiates a Download

#

The collector enters the agent shell and downloads a file:

1

WORKSTATION-01:a1b2c3d4> download C:\Users\alice\Documents\report.docx

The file is transferred to the teamserver. A collection request is created with status pending.

Web UI: The collector can also create requests from the File Explorer page by right-clicking a file.

Step 2: Operator Receives Notification

#

The teamserver sends a real-time notification to connected operators and admins. The Web UI sidebar shows the pending count update.

1
2

tantoc2[eng]> requests count
Pending requests: 3

Step 3: Operator Reviews the Request

#

1
2

tantoc2[eng]> requests list --status pending
tantoc2[eng]> requests info <request-id>

The info view shows: which agent the file came from, the remote path, file size, SHA-256 hash, who requested it, and when.

Web UI: Collection Requests page — filter to “pending”, expand each request to see details.

Step 4: Approve or Deny

#

Approve:

1

tantoc2[eng]> requests approve <request-id>

Deny:

1

tantoc2[eng]> requests deny <request-id> --reason "file is out of scope"

Web UI: Click “Approve” or “Deny” buttons on the request row.

Step 5: Collector Retrieves the File

#

After approval, the collector can retrieve the file content:

1

tantoc2[eng]> files fetch WORKSTATION-01 <transfer-id> /local/output/report.docx

Web UI: The approved request shows a download button. Click it to download the file to the browser.

If denied, the collector sees the denial reason in their request list.

Role Best Practices

#

During Engagement Setup

#

• Admin: Set up the engagement, create user accounts, grant access.
• Operators: Connect and start working after access is granted.
• Collectors: Connect after operators grant engagement access. Issue dynamic grants only when collection is about to begin.
• Spectators: Grant access for supervisors or observers who need visibility without operational access.

During Active Operations

#

• Keep collector grants scoped to agents that are actively being worked.
• Revoke grants when a collection window closes.
• The audit log captures every action with the exact principal — use it to track what each user did.

Multi-Operator Coordination

#

• All operators must run engagements use <name> to activate the shared engagement.
• Tasks, file transfers, and credential additions from all operators appear in the same shared view.
• The audit log attributes every action to the individual user, even in a shared session.

Web UI Role Behaviour

#

The web UI hides or disables controls based on your role:

• Spectators: Create buttons, execute buttons, start/stop/kill controls are hidden.
• Collectors: Same as spectators. Collection requests show a download button for approved items.
• Operators: Full controls for all granted engagements.
• Admins: Admin and Engagements pages are visible. Full controls everywhere.

Role-restricted API calls return 403 Forbidden with a descriptive message. The CLI surfaces this as an error.

Related Pages

#

• Credential Management — credentials are also access-controlled
• Agent Management — file download workflow
• RBAC Architecture — technical design and implementation details