Web UI Guide

Accessing the Web UI

#

Navigate to your teamserver’s web address. The default port is 8443:

1

https://teamserver.example.com:8443

Log in with your username and password. The session token is stored in your browser and refreshes automatically.

The active engagement is shown in the sidebar with a green indicator. All pages operate within the active engagement context. Switch engagements from the Engagements page.

Real-Time Updates

#

Most pages update automatically via WebSocket (Socket.IO). You do not need to refresh the browser. Key events that trigger live updates:

Toast Notifications

#

The web UI shows brief overlay notifications (toasts) for events that happen outside the currently viewed page:

• Agent registered — a new agent checks in for the first time
• Agent dormant — an agent missed 3 consecutive check-ins
• Agent dead — an agent missed 10 consecutive check-ins
• Agent disconnected — a session-mode agent’s TCP transport dropped; the agent is immediately marked dead

Toasts appear in the top-right corner and dismiss automatically.

Page Reference

#

Dashboard (/)

#

The entry point after login. Shows at a glance:

• Agent summary: Total agent count with breakdown by status (active, dormant, dead, killed)
• Sessions: Active session-mode agents
• P2P links: Active relay links between agents
• Relay agents: Agents currently serving as relays
• Active listeners: Running listeners with type and port
• Recent events: Live stream of agent check-ins, task results, and status changes

Use the Dashboard when you want a quick status overview or to monitor a live operation.

Agents (/agents)

#

Sortable, filterable table of all agents in the current engagement.

Columns: hostname:shortid, mode (beacon/session), user, OS, callback IP, relay (which agent it relays through), status, last seen, tags.

Filtering: Use the search box to filter by hostname, IP, OS, or user. Status badges (active, dormant, dead, killed) can be clicked to filter.

Click any row to navigate to that agent’s detail page.

Tip: An agent showing status dormant has missed 3 expected check-ins but may recover. Dead means it has missed 10+. Neither necessarily means the implant is gone — it may be on a slow network or sleeping.

Agent Groups (Web UI)

#

The Agents page supports named groups stored in browser localStorage. Groups let you save a selection of agents and reuse it for bulk operations without re-selecting them each visit.

Creating a group:

1. Check the checkbox in the header row to select all visible agents, or check individual agent rows
2. Click “Save as Group” in the bulk-action toolbar that appears
3. Enter a group name and confirm — the group is saved locally in the browser

Using a group:

1. Click the “Groups” dropdown in the Agents page header
2. Select a group name — all agents in that group are checked automatically (agents that no longer exist in the engagement are skipped silently)

Deleting a group:

Open the “Groups” dropdown and click the trash icon next to the group name. Group data is stored in localStorage and is per-browser — groups are not shared across team members or synchronized to the server.

Bulk Agent Operations

#

When one or more agents are selected (via checkboxes), the bulk-action toolbar appears above the agent table.

Available bulk operations:

After a bulk task is submitted, a results summary panel appears showing per-agent task status as results arrive via WebSocket. The summary lists each agent hostname, the task ID, and the result (pending, success, error) — you do not need to visit each agent’s detail page individually.

Note: Bulk operations are sent to all selected agents regardless of their current status. It is your responsibility to verify that the agents you intend to target are active before submitting bulk kill or task operations.

Agent Detail (/agents/:id)

#

Full information and interaction panel for one agent. Tabs:

Info tab (read-only)

• Hostname, OS, architecture, user, last seen, mode, beacon interval, internal IPs
• Capabilities: Supported module formats and built-in command list
• Tags editor: Pill-style tag badges. Click the + button to add a tag; click the × on any badge to remove it. Changes are saved immediately.
• Notes editor: Textarea showing current notes. Click the edit icon to enter edit mode, make changes, then click Save. All operators can see notes.
• File transfer history: Read-only log of all past uploads and downloads for this agent (direction, remote path, size, SHA-256 status, timestamp). Downloads are initiated from the Tasks tab.
• Kill button (sends kill task — agent terminates on next check-in)

The Info tab is intentionally read-only for most fields — it is the reference view for agent properties. Interactive operations (file transfers, task queuing) are on the Tasks tab.

Terminal tab

• xterm.js-based interactive terminal for the agent
• Backed by a server-side Python agent shell connected via WebSocket
• Submit tasks and see results inline, same as the CLI agent shell
• Supports all built-in commands with dynamic help and human-readable output formatting
• Tab completion for command names
• Inline result display — results appear in the terminal stream as they arrive
• Command validation — unknown commands show an error before being sent

Tasks tab

• Dedicated task creation interface without the terminal
• Command selector: pick the task type from a dropdown (built-in commands and loaded modules)
• Schema-driven forms: the web UI fetches the agent’s command schemas from the capabilities endpoint and renders a typed input form for each command — no raw JSON required. Fields are labelled with descriptions, required fields are marked, and dropdowns appear for arguments with static or dynamic choices.
• Upload: Browse and select a local file using a native file picker; set the remote destination path. The file is read from your browser and streamed to the agent.
• Download: Enter the remote path to retrieve. Completed downloads appear in the transfer list below with a “Save to disk” button.
• Submitted tasks appear in the task history below with status and result previews
• Useful for queuing tasks without occupying the terminal

Modules tab

• List of currently loaded modules (name, status, loaded time)
• Module execution UI: Run module commands with a form-based input; results appear inline in the tab
• Load new module: pick from compatible modules, select format, optional daemonize mode
• Unload: click the unload button on any loaded module

Relay tab

• Shows the agent’s current relay configuration (which agent it relays through, if any)
• Set relay: enter the relay agent ID
• Remove relay: clear the relay assignment

Agent Modules (/agent-modules)

#

Catalog of all agent-loadable modules registered with the teamserver.

Filters: Format (bof, shellcode, dll, py, etc.), platform (windows, linux, darwin), architecture.

Refresh: Click “Refresh Modules” to reload from the plugin directory without restarting the server.

Load into Agent: Click the “Load” button on any module, pick an agent from the dropdown, choose managed or daemonized mode, and submit.

Use modules compatible <agent-id> in the CLI to filter by a specific agent’s capabilities.

Listeners (/listeners)

#

Create, start, stop, and manage listeners.

Create: Click “Create Listener”. Select the transport type (populated dynamically from installed transport plugins). Fill in name, host (leave as 0.0.0.0 to bind on all interfaces), and port.

For external (redirector) listeners, the form shows a parent listener selector instead of a protocol dropdown. Select the real listener that the redirector fronts — the protocol for agent callbacks is derived automatically from the parent’s transport type. Fill in the external hostname and port.

Start / Stop: Use the toggle on each listener row.

Status: running (accepting connections), stopped (created but not started), error (check server logs).

Detail view: Click the expand arrow on any listener row to see full listener details inline:

• Bind address and port
• External host and parent listener (external listeners only)
• IPs reported to the teamserver (used by agent builds for the callback address)
• Creation timestamp and current status
• Active agents: List of agents currently checking in through this listener

Warning on remove: If a listener has active agents checking in, the web UI displays a warning before allowing removal.

This is the same information as listeners info <name> in the CLI.

Builds (/builds)

#

Generate agent builds and download binaries.

The Builds page uses a two-stage flow:

Stage 1 — Package browser: The page opens with a card grid of available agent packages. Each card shows the package name, description, and supported platforms. Click a card to enter the build form for that package.

Stage 2 — Build form: Fill in the build configuration for the selected package:

1. Select platform and architecture (auto-filled when unambiguous for the package).
2. Select a listener. Valid build modes are determined by the intersection of the package’s template modes and the listener transport’s supported_modes() (e.g., HTTP supports beacon; TCP supports session). Mode is auto-selected when only one option is valid.
3. Optionally override the mode (beacon or session) when more than one mode is available.
4. If the listener is bound to 0.0.0.0, enter the callback IP.
5. Set kill date (or kill days from today).
6. Set beacon interval and jitter (for beacon-mode builds).
7. Optionally set a build name.
8. Click “Create Build”.

A build job is queued. The Builds table updates via WebSocket when it completes.

Download: Click the download icon on any completed build row.

Build history: Shows name, ID, package, platform, kill date, and creation time. Sorted by creation time, newest first. Click the expand arrow on any row to see full build details including callbacks, template, and binary hash.

Warning: If the selected listener is not currently running, a warning banner appears in the build form. You can still create the build, but agents built against a stopped listener will not be able to check in until the listener is started.

Credentials (/credentials)

#

Store and manage captured credentials.

Add: Click “Add Credential”. Fill in type, username, secret, domain (optional), and notes (optional). The type dropdown is populated from the server and always reflects the current supported types.

Inline editing: Credentials support inline field editing directly in the table. Click the edit icon on any row to open an inline editor for:

• Notes — free-text annotation field
• Domain — update or correct the domain association
• Tags — add or remove tags; displayed as pill badges

Click Save to apply changes or Cancel to discard.

Search and filter: Use the text search (searches username, domain, source, notes) and the type dropdown to filter results.

View secret: Secrets are hidden by default. Click the eye icon to fetch and display the plaintext (requires a server round-trip — the secret is not stored in the browser).

Delete: Click the delete icon on a credential row.

Export: Click the export dropdown in the page header. Options:

• JSON: Full credential data as JSON
• CSV: Spreadsheet-friendly format
• Hashcat: NT hash lines in user:hash format (only applicable to hash-type credentials)

Tools (/tools)

#

Execute agentless operations (SSH, SMB, etc.) without deploying an agent.

The Tools page uses a two-stage flow:

Stage 1 — Module browser: The page opens with a card grid of available tool modules. Each card shows the module name, description, and supported operations. Click a card to open the execution interface for that module.

Stage 2 — Execution interface:

Configure targets: Enter one or more host:port targets.

Set credentials: Select a credential from the store. The teamserver decrypts and passes it to the tool automatically.

Set proxy (optional): Select a configured proxy for routing traffic.

Configure options: The web UI fetches the module’s command schemas and renders a typed form for each operation — required fields are marked, descriptions appear as labels, and dropdowns replace free-text fields when the argument has a fixed set of choices.

Run: Click the operation button (e.g., “exec”, “upload”, “download”). Results appear in the execution history below.

Execution history: Expandable rows show per-target results, stdout/stderr, exit codes, and timing.

Interactive shell: When a module supports interactive sessions, an additional “shell” operation button appears. Clicking it opens an xterm.js terminal connected to the remote host, backed by a server-side shell session over WebSocket. The session remains active until you close the terminal or the connection drops. See Interactive Tools Shell below.

Proxy CRUD: The Tools page also manages proxy configurations. Click “Add Proxy” to add a SOCKS5 or HTTP proxy. Proxy entries show name, type, and host:port; click the expand arrow for full details.

Refresh: Click “Refresh Modules” to reload tool modules from the plugin directory.

Interactive Tools Shell

#

Tool modules that support interactive sessions (e.g., SSH) offer a persistent shell in addition to one-shot command execution.

1. Select the module and configure the target, credential, and optional proxy
2. Click the “shell” operation button
3. An xterm.js terminal opens — this is a live PTY session backed by the server-side tools shell via WebSocket
4. The terminal prompt shows host:port$ (e.g., 10.0.0.5:22$) to identify the connected target
5. Type commands and see output in real time
6. Close the terminal tab or click “Disconnect” to end the session

The session is managed server-side via the shell sessions API (/api/v1/shell/tools). If you navigate away from the page the session remains running on the server; returning to the Tools page reconnects to any active session.

Topology (/topology)

#

Visual tree of the P2P relay hierarchy for the current engagement.

• Teamserver is the root
• Direct-link agents are first-level children
• Relayed agents are children of their relay agent
• Click any node to navigate to that agent’s detail page

Relay chain labels: Each edge in the topology shows the port and protocol used for that relay hop (e.g., tcp/4444). This makes it easy to see exactly how traffic flows through the chain.

Status colors: Agent nodes are color-coded by status — active (green), dormant (yellow), dead/disconnected (red), killed (grey). Session agents that have lost their TCP connection show immediately as dead (red) rather than waiting for the dormant threshold.

Useful for understanding your relay chain before targeting interior agents.

Engagements (/engagements)

#

List and manage engagements. Admin-only for create/archive/import.

Create: Admin only. Enter a name, an optional description, and a passphrase.

Activate: Click an engagement to make it active. The sidebar indicator updates.

Archive: Click the archive icon, enter the passphrase. The engagement data is exported to an encrypted archive file on the server.

Import: Upload a previously archived engagement (requires the original passphrase).

File Explorer (/files)

#

Browse the agent’s filesystem as a tree. The tree is built from cached ls results — no implicit C2 traffic unless you expand a directory that has not been listed yet.

Expand a directory: Click the arrow to expand. If the directory has not been listed yet:

• An ls task is queued to the agent automatically (if Auto-ls is enabled)
• A fetch status indicator shows the pending/loading/error state
• The tree populates when the result arrives via WebSocket

Auto-ls toggle: A toggle in the page header controls whether expanding an unlisted directory automatically queues an ls task. Disable it if you want to browse the cached tree without generating new C2 traffic.

Fetch status indicators: Each node shows a small icon indicating its listing state: unlisted (grey), pending (spinner), loaded (none), or error (red).

Search/filter: Filter the visible tree by filename or path prefix.

Collection request: Right-click a file (or use the context menu icon) to create a collection request for that file. The request goes to the Collection Requests queue for operator review.

Collection Requests (/requests)

#

Review and process file collection requests from collectors.

Filter: Use the status dropdown to filter by pending, approved, or denied.

Approve: Click “Approve” on a pending request. The file content becomes downloadable by the requesting collector.

Deny: Click “Deny”. Enter an optional reason. The collector sees the denial in their request list.

Download (collector view): Approved requests have a download button that fetches the file content from the teamserver.

Real-time updates via WebSocket — pending request counts appear in the sidebar.

Audit Log (/audit)

#

Filterable table of all actions performed within an engagement.

Filters:

• Principal — filter by operator username
• Action — filter by action type (e.g., login, create_task, export_credentials)
• Date range — Since and Until date pickers
• Security only — toggle to show only security-flagged events (authentication failures, permission changes, forced logouts)

Pagination: Use the page controls at the bottom to step through results. The total count is shown in the header.

Security events (authentication failures, permission denials, password changes) are highlighted in a distinct color.

Use case: Post-engagement review, investigating unexpected agent activity, team coordination audit.

Admin (/admin)

#

Operator management. Admin only.

Create operator: Enter username, password, and role.

Change role: Use the inline role dropdown on any operator row.

Activate/deactivate: Use the toggle. Deactivated operators cannot log in but their data is preserved.

Reset password: Click the password icon and enter a new password.

Delete: Removes the operator and their engagement access grants. Cannot delete or demote the last admin.

Engagement access: Click any operator to see their engagement access grants. Add or revoke access.

Plugins (/plugins)

#

Manage installed plugins (transports, tools, agent packages).

List: View all registered plugins grouped by category (Agent Packages, Transports, Tools, Agent Modules, Server Modules, Crypto Providers, Protocol Codecs). Each entry shows name, type, and description.

The Agent Modules section lists all agent-loadable module packages installed as plugins (wheel packages registered under the tantoc2.agent_modules entry point group). Each entry shows the module name, format, platforms, and description. This section is separate from the Agent Modules page (/agent-modules), which shows individual loadable modules — the Plugins page shows the installed packages that provide them.

Refresh: Reload plugins from the server’s plugin directory without restarting the server.

Load from server path: Opens a file browser rooted at the server’s plugin inbox directory. Navigate directories and click any .whl file to install it. The browser uses the server filesystem browser API (GET /api/v1/plugins/browse) — you browse the server’s disk, not your local machine.

Upload: Upload a .whl file directly from your browser. Click “Upload Plugin”, select a .whl from your local filesystem, and the file is transmitted to the server, installed with pip, and the registries are refreshed automatically.

After any load or upload operation, the plugin list refreshes automatically.

User Options (/account)

#

Available to any authenticated operator.

Change Password: Enter your current password and a new password to change your credentials. This does not require admin privileges — any operator can change their own password.

Use this page for routine password rotation after engagement completion or if you suspect your credentials have been compromised. To change another operator’s password, use the Admin page (admin only).

Role-Aware UI

#

The web UI adapts based on your role:

• Spectator: Action buttons (create, start, stop, kill, execute) are hidden or disabled. View-only.
• Collector: Same as spectator. Collection requests show a download button on approved items.
• Operator: Full action controls for all granted engagements.
• Admin: Everything, including Admin and Engagements management pages.

Quick Navigation

#