Skip to content

Back to the catalog

dfir.chwriteup

tmate - Instant Terminal Sharing (or How To Backdoor a Linux Server)

A DFIR.ch blog post examining how the threat actor TeamTNT abuses tmate (instant terminal sharing tool) as a Linux backdoor after compromising servers, referencing prior TeamTNT reporting from Intezer, ASEC, and Aqua. The author demonstrates tmate installation/usage and walks through forensic artifacts left behind — process listings, apt logs, unattended-upgrades-dpkg.log, /proc/net/unix socket entries, and lsof output showing outgoing SSH connections to tmate's infrastructure — to help defenders and threat hunters detect active or past tmate-based backdoors.

TL;DR Walkthrough of TeamTNT's tmate-as-backdoor technique on Linux, with the exact log files, socket paths, and lsof/ps traces defenders can hunt for.
Open original ↗
Document

What it is

A DFIR walkthrough (dfir.ch) of detecting tmate 2.4.0 used as a post-compromise backdoor on Linux, as attributed to TeamTNT across reports from Intezer (2021), ASEC (2022), and Aqua (2023). The Aqua-referenced installer tmate.sh is noted as available on VirusTotal. The value beyond the summary is the specifics: the exact process signature, the socket-naming scheme, and why standard auth logs stay empty.

How it works

tmate is started server-side with -F (log to stdout, no interactive shell — easy to run under systemd/kubernetes, and it respawns the shell on exit so the session never dies), -k <api-key>, and -n <session-name>. It dials out to ssh.tmate.io / regional nodes (e.g. lon1.tmate.io) and tunnels all commands back through that connection. Because the operator connects via tmate's infrastructure rather than logging in directly, no successful login is recorded in the host's auth logs — a key blind spot. Per the tmate paper, a 25-char alphanumeric session token (and read-only token) is generated from /dev/urandom; the tmux server binds a socket at /tmp/tmate/<token>.sock with a symlink /tmp/tmate-<token>.sock.

What to do

Concrete detections the post gives:

Process listing — the API key and session name are visible on the command line:

# ps aux | grep tmate
root 1981 ... tmate -F -k tmk-... -n dfir.ch

Package-manager traces (only if installed via apt, not the standalone binary TeamTNT actually used) in /var/log/apt/history.log and /var/log/apt/term.log.

Edge case: long-running sessions surface in /var/log/unattended-upgrades/unattended-upgrades-dpkg.log under "User sessions running outdated binaries":

root @ session #1: tmate[1981]

Socket artifact in /proc/net/unix (and under /tmp):

... /tmp/tmate-0/FJbmgn

Outbound connection — the strongest signal. An outgoing SSH session from a server to a VPS-hosted IP should alert:

# lsof -p <pid>

shows the established outbound SSH to tmate infrastructure.

Caveats

  • The apt-log artifacts do not apply to the documented TeamTNT intrusions, which dropped standalone binaries and bypassed the package manager.
  • The author notes the tmate process can be hidden from ps, and defers techniques for finding hidden processes to a future post — so process listing alone is not reliable.
  • The unattended-upgrades-dpkg.log mention is described as an incidental edge case observed only after leaving a session running for an extended period, not a guaranteed artifact.

Technologies named here

Techniques named here

  • Backdooring via remote terminal sharing tool
  • Process hiding evasion
  • Detection via process listing
  • Detection via package manager logs
  • Detection via unattended-upgrades log anomaly
  • Detection via /proc/net/unix socket inspection
  • Detection via lsof on suspicious process
  • Detection via outbound SSH connection monitoring

Threat actors named here

  • TeamTNT

Related in Blue Team & Detection