Potential Tunneling via Tailscaled
editPotential Tunneling via Tailscaled
editIdentifies the use of Tailscaled to potentially tunnel network traffic. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination, or to bypass network restrictions and/or hide traffic from network monitoring.
Rule type: eql
Rule indices:
- endgame-*
- logs-crowdstrike.fdr*
- logs-endpoint.events.process-*
- logs-m365_defender.event-*
- logs-sentinel_one_cloud_funnel.*
- logs-system.security*
- logs-windows.sysmon_operational-*
- winlogbeat-*
- auditbeat-*
Severity: medium
Risk score: 47
Runs every: 5m
Searches indices from: now-9m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Domain: Endpoint
- OS: Windows
- OS: Linux
- OS: macOS
- Use Case: Threat Detection
- Tactic: Command and Control
- Data Source: Elastic Endgame
- Data Source: Elastic Defend
- Data Source: Sysmon
- Data Source: SentinelOne
- Data Source: Microsoft Defender XDR
- Data Source: Windows Security Event Logs
- Data Source: Crowdstrike
- Resources: Investigation Guide
Version: 1
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
edit## Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Potential Tunneling via Tailscaled
This rule flags Tailscaled starting with proxy or SOCKS tunneling options, which can turn an endpoint into a covert relay for traffic that bypasses segmentation, egress controls, and normal monitoring. An attacker with access to a Windows, Linux, or macOS host can launch tailscaled.exe with a local SOCKS5 listener, then route remote administration, reconnaissance, or data-transfer traffic through the encrypted overlay to reach systems that were not directly accessible.
Possible investigation steps
- Determine whether the host is approved to run Tailscale by validating the user, device owner, recent change tickets, and any sanctioned remote-access or VPN use case.
- Review the execution chain and security context, including the parent process, command lineage, account privileges, logon session, and whether a service, scheduled task, or startup item was created to keep the tunnel available.
- Identify what the tunnel exposed by enumerating local listening ports, recent inbound and outbound connections, and any access to unusual internal subnets, administrative services, or blocked destinations after the process started.
- Correlate Tailscale-specific artifacts such as the logged-in tailnet, device registration or approval events, peer list, and advertised routes or exit-node settings to determine whether the node was joined to an unauthorized overlay.
- Hunt across the environment for the same user, tailnet, binary path, hash, or command pattern and review adjacent activity on the host for follow-on actions like remote administration, lateral movement, credential access, or data staging.
False positive analysis
-
An administrator or engineer may legitimately start tailscaled with
--socks5-serveror--outbound-http-proxy-listenon an approved remote-access, lab, or jump system for maintenance, so verify the user and host are authorized for Tailscale and that the command line, install path, and start time match a documented change or normal operating pattern. - A developer or IT user may temporarily enable these proxy options to troubleshoot connectivity between managed Windows, Linux, or macOS hosts, so confirm the activity with the asset owner and review resulting connections to ensure they were limited to expected internal destinations and business-related use.
Response and remediation
-
Isolate the affected host from the network, terminate the running
tailscaledprocess, and block the observed local proxy listener and any active Tailscale peer connections to stop the tunnel. - Remove attacker persistence by uninstalling unauthorized Tailscale components and deleting related services, scheduled tasks, LaunchDaemons, systemd units, startup items, auth keys, and Tailscale state/config files left on the host.
- Revoke the enrolled device from the tailnet, invalidate any Tailscale auth keys or SSO sessions used to register it, and reset passwords or tokens for accounts that logged on while the tunnel was active.
-
Restore the system to a known-good state by reimaging or recovering from a trusted backup if you cannot fully verify what the tunnel exposed or what changes were made after
tailscaledwas launched with proxy options. - Escalate to incident response immediately if the tunnel reached domain controllers, administrative jump hosts, sensitive data repositories, or if you identify the same tailnet, binary, or proxy command line on multiple endpoints.
-
Harden the environment by restricting Tailscale installation to approved systems, enforcing application control for
tailscaled, limiting outbound access to Tailscale coordination or relay infrastructure where not required, and alerting on new proxy listeners or unauthorized tailnet enrollments.
Rule query
editprocess where event.type == "start" and
process.name like~ ("tailscaled", "tailscaled.exe") and
process.args like~ ("*--socks5-server*", "*--outbound-http-proxy-listen*")
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Command and Control
- ID: TA0011
- Reference URL: https://attack.mitre.org/tactics/TA0011/
-
Technique:
- Name: Proxy
- ID: T1090
- Reference URL: https://attack.mitre.org/techniques/T1090/
-
Technique:
- Name: Remote Access Tools
- ID: T1219
- Reference URL: https://attack.mitre.org/techniques/T1219/
-
Technique:
- Name: Protocol Tunneling
- ID: T1572
- Reference URL: https://attack.mitre.org/techniques/T1572/