Spot privilege changes and access that could outlast a task. Teleport links classifier
findings to the recorded activity, so you can see what changed and why it was flagged.
Example shown: a recorded SSH session in Teleport.
A persistence finding, with the behavior and reason for review.
Follow the privilege change.
This SSH session copied the id binary, made it root-owned and set its
setuid permission. The session summary reports execution with effective UID 0.
0:10
Ownership changes to root
The copied executable becomes owned by root:root.
0:12
Setuid permission is added
Mode 4755 allows the executable to run with its owner's privileges.
0:17
The executable runs
The finding reports effective UID 0 while the real UID remained 1000.
The session registered an EXIT cleanup trap. Check whether cleanup completed and
whether this was an approved test before deciding how to respond.
The session record gives the finding its context.
View the full SSH session screenshot
The original session view, including the terminal and matched classifiers.
See what the classifier looks for.
The built-in persistence classifier checks SSH and Kubernetes sessions for access that
could survive outside Teleport. Duplicate it to adapt the criteria and choose what
happens on a match.
Session kinds, criteria and match actions in one configuration.
Scroll the screenshot horizontally to inspect it.
Privilege escalation
SSH, Kubernetes and databases
Looks for a successful gain in privilege: elevated identities, higher-privilege roles
or permission grants. Denied attempts without a privilege gain are excluded.
View detailed criteria
Identify sessions where the actor gains more privilege than they held at the start.
Successful sudo or su elevation, or a switch to a higher-privilege identity.
Kubernetes impersonation or privileged RBAC grants; database role or privilege
grants.
Persistence
SSH and Kubernetes
Looks for a way to retain or regain access, including setuid executables, added keys
and persistent workloads. Routine deployments and scoped application RBAC are
excluded.
View detailed criteria
Identify durable access mechanisms that could survive outside Teleport control.
Changes to access keys, local accounts, privileged groups, setuid bits, startup
files or scheduled execution that create a return path.
Long-lived Kubernetes credentials, elevated bindings or workloads configured to
re-establish access.
Exclude routine deployments, scoped application RBAC, standard CronJobs, package
installs and dotfile edits for aliases or prompts.
View classifier activity and recent matchesRecent matches link back to the recordings that need review.
Turn the match into a review.
Open the original recording, establish the context and document the outcome.
01
Compare access before and after
Identify the starting account, the resulting permissions and whether the elevation
actually succeeded.
02
Check what remains
Check the executable's final ownership and permissions, and verify that cleanup
removed it. Establish whether any durable access remains outside Teleport.
03
Confirm ownership and disposition
Match changes to an approved task and owner. Record legitimate maintenance or route
unexpected access through your response process.
Explore session capture, classification and evidence review for your environment. Contact
us about classifier availability and deployment requirements.
Launching November 9. Join the waitlist for launch updates.
Join the waitlist
Get early access updates and launch announcements for Teleport Beams.