Beam Me Up, Luke: A Review of Teleport Attack Scenarios - Adam Chester | Black Hat USA 2026
Adam Chester, Senior Offensive Security Consultant (SpecterOps) — 40 min, Oceanside D









A post-compromise tour of Teleport. Chester’s framing is that you have already landed on a host somewhere in the estate, and the question is what the access proxy hands you next. The answer, repeatedly, is more than it should.
Reconstructed from slide photos. The room recording transcribed poorly, so the write-up below sticks to what the slides state directly.
The Shape of a Teleport Cluster

Teleport brokers access to SSH servers, Kubernetes clusters, databases and Windows desktops, and records the sessions while it does it. Users authenticate to a proxy server, the auth server issues short-lived certificates, and agents on the target hosts expose the backend services.
Research was done against v18.6.1, covering both the open source and enterprise builds.
Everything Rides on ALPN

The proxy exposes a single TCP port and routes everything behind it using application layer protocol negotiation. The ALPN value you present decides which internal service you reach — teleport-auth for the auth server, teleport-mysql for a MySQL backend, teleport-reversetunnel for the tunnels agents dial out on, teleport-mcp for an MCP server.
Teleport calls this multiplexing and it is the default routing method. Chester’s point is that it makes the whole surface awkward to poke at by hand, which is why the research needed custom tunnelling tooling before it could start.
The Certificate Is the Authorization

The proxy server can be stateless because every fact needed to approve or deny a connection travels inside the certificate. The subject field carries the username, the target resource, and the restrictions that apply.
That is an elegant design, and it cuts both ways. Anyone who obtains a certificate can read off exactly what access it grants without touching the auth server. Worse, a compromised certificate does not have to expire on schedule — the GenerateUserCerts API can be used to periodically extend it.
The same pattern shows up one layer down. Backend service agents enrol with the auth server and are then trusted to mint certificates on the fly for the databases they front. Because the auth server cannot know in advance which databases a service will be configured with, compromising a single database agent lets an attacker request certificates for other users and other databases in the cluster.
Node Hijacking

The sharpest result in the talk. Credentials lifted from any node in the cluster also carry permission to update other node objects on the auth server. Three steps follow:
- Call
UpsertNodeto rename the victim node out of the way. - Call
GenerateHostCertsto craft and sign new certificates using the victim’s hostname. - Run a reverse-tunnel tool to receive the connections that were meant for the victim.

Users connecting to what they believe is a known host land on the attacker instead. From there the session can be replayed convincingly enough to prompt for credentials, or the forwarded SSH agent can be borrowed mid-connection.
The same over-provisioning applies to session recordings. Node credentials are not scoped to the node’s own sessions, so a single compromised agent can enumerate and play back recorded sessions from across the cluster — the audit trail becomes an intelligence source.
Smartcards Without the PIN
Teleport’s Windows desktop access uses IronRDP with a virtual smartcard holding the user’s certificate. Chester found the PIN check and the cryptographic operation are not bound together: the general authenticate step does not verify that PIN validation actually succeeded. Patching the Windows smartcard API in-process so PIN verification always returns success is enough to skip it, which turns LDAP-level access into use of a logged-on user’s smartcard.
Disclosure and Fixes

Chester opened this section by thanking Teleport for triaging and prioritising immediately on disclosure. Status at the time of the talk:
| Issue | Status |
|---|---|
| Node system role recording access | Fixed in 18.7.4 and 17.7.26 |
| Node/App/DB system role permissions | Queued for release |
| SSH agent forwarding | No fix |
| IronRDP smartcard PIN bypass | Fixed in 18.9.0 and 17.7.25 |
Tooling
The tunnelling, certificate, node-hijack and reverse-tunnel tools built for the research were released as the Teleport Attack Kit at github.com/xpn/TAK.
Frequently Asked Questions
What Teleport version was this research done on?
Teleport v18.6.1. Fixes landed across several releases: the node system role recording access issue in 18.7.4 and 17.7.26, and the IronRDP smartcard PIN bypass in 18.9.0 and 17.7.25.
What is node hijacking in Teleport?
Compromised node credentials also carry permission to update other node objects on the Auth Server. An attacker can call UpsertNode to rename a victim node, call GenerateHostCerts to sign new certificates using the victim’s hostname, then run a reverse-tunnel tool to receive connections intended for that node.
Why can the Teleport proxy server be stateless?
Every piece of information needed to approve or deny a connection is encoded in the certificate itself, including the target resource and restrictions in the subject field. That design also means anyone holding a certificate can read exactly what access it grants.
Were these issues fixed?
Mostly. Node system role recording access and the IronRDP smartcard PIN bypass shipped fixes. Node/App/DB system role permissions were queued for release at the time of the talk. SSH agent forwarding was marked as no fix.