T1572

Protocol Tunneling

Command and Control Last updated:

Detects adversaries tunneling network communications within a separate protocol to evade detection and bypass network filtering. This detection identifies common tunneling techniques including SSH port forwarding via Plink or OpenSSH (-L/-R/-D flags), dedicated tunneling utilities (Chisel, Iodine, ptunnel, dnscat2, socat), DNS-over-HTTPS (DoH) encapsulation for C2 traffic, and native Windows netsh portproxy tunneling. Protocol tunneling allows attackers to route blocked protocols (SMB, RDP) through permitted channels, establish covert C2 channels, and bypass network appliances — as observed in Magic Hound (Plink RDP tunneling), FIN6 (Plink SSH tunnels), and FIN13 (Java-based web shell tunneling).

What is T1572 Protocol Tunneling?

Protocol Tunneling (T1572) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Protocol Tunneling, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Command and Control
Technique
T1572 Protocol Tunneling
Canonical reference
https://attack.mitre.org/techniques/T1572/
Microsoft Sentinel / Defender
kusto 
let TunnelingTools = dynamic(["plink.exe", "plink", "chisel.exe", "chisel", "ligolo.exe", "ligolo", "iodine.exe", "iodine", "ptunnel.exe", "ptunnel", "dns2tcp", "dnscat", "dnscat2", "httptunnel", "htc", "hts", "socat"]);
let DoHProviders = dynamic(["cloudflare-dns.com", "dns.google", "doh.opendns.com", "dns.quad9.net", "mozilla.cloudflare-dns.com", "doh.dns.apple.com"]);
let BrowserProcesses = dynamic(["chrome.exe", "firefox.exe", "msedge.exe", "brave.exe", "opera.exe", "iexplore.exe", "safari", "vivaldi.exe", "chromium"]);
let SystemProcesses = dynamic(["svchost.exe", "MsMpEng.exe", "services.exe", "wininit.exe", "dnscrypt-proxy.exe", "stubby.exe"]);
// Branch 1: Known tunneling tool execution
let KnownTools = DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName in~ (TunnelingTools)
| extend DetectionBranch = "KnownTunnelingTool"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, DetectionBranch;
// Branch 2: SSH with port-forwarding flags (OpenSSH, Plink)
let SSHTunneling = DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName in~ ("ssh.exe", "ssh", "plink.exe", "plink")
    and (
        ProcessCommandLine has "-L " or
        ProcessCommandLine has "-R " or
        ProcessCommandLine has "-D " or
        ProcessCommandLine has "-w " or
        ProcessCommandLine has "LocalForward" or
        ProcessCommandLine has "RemoteForward"
    )
| extend DetectionBranch = "SSHPortForwarding"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, DetectionBranch;
// Branch 3: Netsh portproxy (native Windows tunneling)
let NetshProxy = DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName =~ "netsh.exe"
    and ProcessCommandLine has "portproxy"
    and ProcessCommandLine has "add"
| extend DetectionBranch = "NetshPortProxy"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, DetectionBranch;
// Branch 4: DoH from non-browser, non-system processes
let DoHConnections = DeviceNetworkEvents
| where TimeGenerated > ago(1d)
| where RemotePort == 443
    and RemoteUrl has_any (DoHProviders)
    and InitiatingProcessFileName !in~ (BrowserProcesses)
    and InitiatingProcessFileName !in~ (SystemProcesses)
| extend DetectionBranch = "DNSoverHTTPS", AccountName = InitiatingProcessAccountName, FileName = InitiatingProcessFileName, ProcessCommandLine = InitiatingProcessCommandLine, InitiatingProcessFileName = "", InitiatingProcessCommandLine = ""
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath = RemoteUrl, DetectionBranch;
union KnownTools, SSHTunneling, NetshProxy, DoHConnections
| sort by TimeGenerated desc

Detects protocol tunneling across four patterns: (1) known tunneling tool execution (Chisel, Plink, Iodine, ptunnel, dnscat2, socat), (2) SSH binaries invoked with port-forwarding flags (-L/-R/-D/-w), (3) Windows netsh portproxy rule creation, and (4) DNS-over-HTTPS connections from non-browser and non-OS processes. Each result includes a DetectionBranch field for triage prioritization.

high severity medium confidence

Data Sources

Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceNetworkEvents

False Positives

  • Legitimate SSH tunneling by system administrators for database access, jump-host traversal, or remote maintenance tasks
  • IT automation tools (Ansible, Puppet, SaltStack) that use SSH tunnels for agent communication and configuration management
  • Developers using SSH port forwarding to reach internal services, Kubernetes API servers, or staging databases
  • Corporate DNS-over-HTTPS policy enforcement by approved endpoint agents or custom DNS clients
  • VPN clients or network monitoring agents that legitimately encapsulate traffic within other protocols

Sigma rule & cross-platform mapping

The detection logic for Protocol Tunneling (T1572) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1572 Sigma rules on detection.fyi

Platform-specific guides for T1572

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-03-19 Research depth: deep
References (7)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1SSH Local Port Forwarding via OpenSSH

    Expected signal: Sysmon Event ID 1 (process create): Image=ssh, CommandLine contains '-N -L 8443:localhost:443'; Sysmon Event ID 3 (network): DestinationPort=22, Image=ssh

  2. Test 2Plink SSH RDP Tunnel (Windows)

    Expected signal: Sysmon Event ID 1 or Windows Security 4688: Image=plink.exe, CommandLine contains '-ssh -N -L 13389:127.0.0.1:3389'; Sysmon Event ID 3: outbound TCP to port 22

  3. Test 3Windows Netsh Portproxy Rule Creation

    Expected signal: Sysmon Event ID 1: Image=netsh.exe, CommandLine contains 'portproxy add v4tov4'; Sysmon Event ID 12/13: registry key creation under HKLM\SYSTEM\CurrentControlSet\Services\PortProxy

  4. Test 4Chisel Reverse Tunnel Server Startup (Linux)

    Expected signal: Sysmon/auditd process create: process name 'chisel' with '--reverse --socks5 --port 8443' in command line; network bind event on port 8443

Response Playbook

Triage

  1. Step 1: Identify the tunneling method from the DetectionBranch or score breakdown — SSH port forwarding, known tool binary, netsh portproxy, or DoH. Each requires different follow-up actions and has different false positive rates (netsh portproxy is highest fidelity; DoH requires more context).
  2. Step 2: Examine the full process command line for tunnel parameters. For SSH tunneling, extract the local port, remote host, and remote port from -L/-R flags. For Plink, identify if RDP (port 3389) or SMB (port 445) is being tunneled, which significantly elevates severity.
  3. Step 3: Investigate the parent process — legitimate admin tunneling spawns from interactive shells (cmd.exe, PowerShell) with human logon types (type 2 or 10). Tunneling tools spawned by web server processes (w3wp.exe, httpd, nginx, php-cgi), scheduled tasks, or WMI are strongly indicative of post-exploitation activity.
  4. Step 4: Check the tunnel destination IP and hostname against threat intelligence. Query VirusTotal and Shodan for the remote IP. Flag connections to residential ISP ranges, cloud VPS providers (DigitalOcean, Vultr, Linode, OVH) with no business justification, or any IP matching known APT infrastructure.
  5. Step 5: Determine if the user account is expected to use tunneling tools. Service accounts, standard end-user accounts, or accounts not in a defined admin group using SSH tunneling tools should be treated as high priority. Query Active Directory group membership and recent logon history.
  6. Step 6: Analyze network data volume transferred through the connection via DeviceNetworkEvents (SentBytes/ReceivedBytes). Tunnels actively exfiltrating data will show asymmetric high egress volume. C2 beaconing shows regular small packets; interactive sessions show irregular bursts.
  7. Step 7: For DoH detections, identify what domain queries the process was attempting to resolve. If the non-browser process is resolving domains not associated with its function (e.g., a service binary resolving random-looking domains over DoH), this is strong C2 indicator. Cross-reference resolved domains against threat intel feeds.

Containment

  1. Isolate the affected endpoint using EDR containment or VLAN isolation to stop active tunneling while preserving forensic state. Do not reboot — active memory contains tunnel session keys and C2 artifacts.
  2. Terminate the tunneling process: use EDR remote process kill or run 'taskkill /F /IM plink.exe' (substitute appropriate process name). For Linux: 'pkill -f chisel' or 'kill -9 <PID>'.
  3. Block the tunnel destination IP at the perimeter firewall, internal network ACLs, and any inline IDS/IPS. Add to threat intelligence blocklist for automatic future blocking. If destination is a cloud provider IP, consider blocking the entire /24 if no business justification exists.
  4. For netsh portproxy tunnels: enumerate all rules immediately with 'netsh interface portproxy show all', then remove each malicious rule with 'netsh interface portproxy delete v4tov4 listenport=<PORT> listenaddress=<ADDR>'. Reboot may be required to fully clear kernel-level port proxy state.
  5. Disable or lock the associated user account pending investigation. For service accounts, immediately rotate credentials and audit all systems where that service account has access.
  6. If the tunnel was routing lateral movement traffic (RDP, SMB, WinRM), identify all internal systems accessible from the tunnel endpoint and initiate parallel investigation of those hosts.
  7. Review and remove any firewall rule exceptions, NAT rules, or proxy bypass rules that were created to enable the tunnel, as adversaries often create these to ensure tunnel persistence across reboots.

Evidence Collection

  1. Capture full process memory of the tunneling process before termination: 'procdump -ma <PID> tunnel_memdump.dmp'. Memory may contain plaintext C2 server addresses, session keys, and encoded payloads that are not visible in network traffic.
  2. Export Windows Security Event Log (4688) and Sysmon logs (Event IDs 1, 3, 8, 22) for the affected host covering 72 hours before and after the alert timestamp.
  3. Collect prefetch evidence from C:\Windows\Prefetch\ — tunneling binaries leave prefetch files (PLINK.EXE-*.pf, CHISEL.EXE-*.pf) with first/last execution timestamps and file access lists.
  4. Run 'netstat -anob > active_connections.txt' and 'netsh interface portproxy show all > portproxy_rules.txt' immediately on the affected host to capture current network state.
  5. Collect SSH artifacts: C:\Users\<user>\.ssh\config (may contain pre-configured tunnel destinations, ProxyJump chains), C:\Users\<user>\.ssh\known_hosts (documents all SSH servers contacted), and ~/.ssh/ on Linux.
  6. Collect shell history: PowerShell transcript logs at %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt; Linux bash history at ~/.bash_history or ~/.zsh_history. Tunneling commands typed interactively will appear here.
  7. For netsh portproxy: export registry key HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\ which persists proxy rules across reboots.
  8. Perform packet capture on the host NIC or upstream network tap if possible. Even encrypted SSH traffic metadata (timing patterns, packet sizes) enables C2 beacon analysis and session reconstruction.

Escalation Criteria

  • ! Escalate immediately if the tunnel destination IP matches active threat intelligence IOCs (known APT infrastructure, active C2 servers, or previously seen malicious hosting providers).
  • ! Escalate if lateral movement was detected through the tunnel — evidence includes RDP (3389), SMB (445), or WinRM (5985/5986) connections originating from the tunnel endpoint to internal systems after the tunnel was established.
  • ! Escalate if data exfiltration volume through the tunnel exceeds 50MB, or if the tunneled traffic originated from directories containing sensitive data (financial records, PII, source code repositories, credential stores).
  • ! Escalate if the tunneling tool was deployed to three or more systems simultaneously or within a short time window — this indicates automated deployment from a foothold, suggesting a persistent, capable threat actor.
  • ! Escalate if the compromised account holds privileged access (Domain Admin, local administrator on multiple systems, service account with broad permissions), as the tunnel likely enables credential harvesting or domain compromise.
  • ! Escalate if the technique matches known active campaigns: Plink used for RDP tunneling (Magic Hound/APT35), Java-based web shell tunneling (FIN13/Elephant Beetle), or DNS-based bidirectional tunneling (Heyoka Backdoor/Aoqin Dragon).

Investigation Guide

Forensic Artifacts

  • > Windows Prefetch files: C:\Windows\Prefetch\PLINK.EXE-*.pf, CHISEL.EXE-*.pf, IODINE.EXE-*.pf — contain first/last run timestamps and loaded file paths
  • > Registry key for netsh portproxy persistence: HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\ — survives reboots
  • > SSH known_hosts file: C:\Users\<user>\.ssh\known_hosts and ~/.ssh/known_hosts — documents all SSH servers the user has connected to, including tunnel destinations
  • > SSH config file: ~/.ssh/config — may contain preconfigured LocalForward, RemoteForward, ProxyJump, and DynamicForward directives for automated tunneling
  • > PowerShell ConsoleHost history: %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt — captures interactively typed tunnel commands
  • > Sysmon Event ID 1 logs: full command line of tunneling process including all flags, ports, and destination addresses
  • > Sysmon Event ID 3 logs: source/destination IP, port, and process for all network connections established through the tunnel
  • > Windows Security Event 4688 (process creation with command line auditing enabled): audit-trail for tunneling tool execution
  • > Network flow logs (NetFlow/IPFIX): high byte-count flows on port 22 or unusual ports between internal host and external IP
  • > DNS cache on affected host ('ipconfig /displaydns' or 'Get-DnsClientCache'): may reveal DoH provider queries or C2 domain resolutions

Tuning Guidance

Begin by inventorying legitimate SSH tunnel users: create an allowlist of specific user+source host+destination combinations for known admin workflows. The netsh portproxy detection has very low false positive rates and should be treated as high priority. For DoH detections, enumerate which corporate applications legitimately use DNS-over-HTTPS (some endpoint security agents, privacy tools) and add them to the exclusion list. For Chisel and Iodine detections, treat as high fidelity — these tools have no legitimate production use in most environments. The SSH port-forwarding detection will generate noise from DevOps teams; consider scoping to non-developer machines or requiring the additional context of unusual parent processes or off-hours execution. Enrich all alerts with GeoIP and ASN data on the tunnel destination to quickly differentiate admin connecting to corporate infrastructure from adversary connecting to a cloud VPS.

Hunting Queries

Hunts for non-SSH processes making outbound connections on port 22, which may indicate custom tunneling utilities or malware using SSH protocol from unexpected binaries. Excludes known legitimate SSH clients.

Hunting — KQL
kql 
// Hunt: Non-SSH processes making outbound connections on port 22
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where RemotePort == 22
| where InitiatingProcessFileName !in~ ("ssh.exe", "ssh", "scp.exe", "scp", "sftp", "sftp.exe", "git.exe", "git", "winscp.exe", "filezilla.exe", "putty.exe", "psftp.exe", "rsync")
| summarize ConnectionCount=count(), RemoteIPs=make_set(RemoteIP, 15), BytesOut=sum(SentBytes), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where ConnectionCount >= 2
| extend TunnelRisk = iff(BytesOut > 10000000, "HighVolume", "LowVolume")
| sort by ConnectionCount desc
Hunting — SPL
spl 
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 DestinationPort=22
| eval image=lower(coalesce(Image, ""))
| where NOT match(image, "(ssh|scp|sftp|putty|winscp|filezilla|git|rsync|psftp)")
| stats count as conn_count, values(DestinationIp) as dest_ips, min(_time) as first_seen, max(_time) as last_seen by host, Image, CommandLine
| where conn_count >= 2
| sort - conn_count

Hunts for any process invoked with SSH port-forwarding argument syntax across all binaries over 30 days, enabling analysts to baseline legitimate admin SSH tunneling patterns and surface anomalous or low-frequency occurrences.

Hunting — KQL
kql 
// Hunt: Processes with SSH port-forwarding syntax across all binaries (baseline and anomaly detection)
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where ProcessCommandLine matches regex @"-[LRD]\s+\d{1,5}:" 
    or ProcessCommandLine matches regex @"-[LRD]\s+[\w.]+:\d{1,5}:\d{1,5}"
    or ProcessCommandLine has_any ("-LocalForward", "-RemoteForward", "-DynamicForward")
| summarize Count=count(), Devices=make_set(DeviceName, 10), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by FileName, ProcessCommandLine
| extend DaysActive = datetime_diff('day', LastSeen, FirstSeen)
| sort by Count asc
Hunting — SPL
spl 
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| rex field=CommandLine "(?<forward_flag>-[LRD]\s+[\d]+:)"
| where isnotnull(forward_flag)
| stats count as use_count, values(host) as hosts, dc(host) as host_count, min(_time) as first_seen, max(_time) as last_seen by Image, CommandLine, forward_flag
| sort use_count

Hunts for DNS-over-HTTPS queries originating from non-browser processes. Malware and tunneling tools that use DoH to encapsulate C2 traffic will appear here. The RequestsPerHour field in the KQL query helps identify beaconing patterns.

Hunting — KQL
kql 
// Hunt: DNS-over-HTTPS requests from unexpected processes (potential C2 via DoH)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 443
| where RemoteUrl has_any ("cloudflare-dns.com", "dns.google", "doh.opendns.com", "dns.quad9.net", "mozilla.cloudflare-dns.com", "doh.dns.apple.com")
| where InitiatingProcessFileName !in~ ("chrome.exe", "chromium", "firefox.exe", "msedge.exe", "brave.exe", "opera.exe", "iexplore.exe", "safari", "vivaldi.exe", "svchost.exe", "MsMpEng.exe", "dnscrypt-proxy.exe", "stubby.exe")
| summarize RequestCount=count(), UniqueURLs=dcount(RemoteUrl), BytesOut=sum(SentBytes), BytesIn=sum(ReceivedBytes), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName
| extend RequestsPerHour = round(todouble(RequestCount) / datetime_diff('hour', LastSeen, FirstSeen + 1h), 2)
| sort by RequestCount desc
Hunting — SPL
spl 
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| eval query_lower=lower(coalesce(QueryName, ""))
| where match(query_lower, "(cloudflare-dns\.com|dns\.google|doh\.opendns|quad9\.net|mozilla\.cloudflare)")
| eval image_lower=lower(coalesce(Image, ""))
| where NOT match(image_lower, "(chrome|firefox|msedge|brave|opera|iexplore|safari|svchost|dnscrypt|stubby)")
| stats count as req_count, values(QueryName) as queries, dc(QueryName) as unique_queries, min(_time) as first_seen, max(_time) as last_seen by host, Image, User
| sort - req_count

Atomic Red Team Tests

Test 1 SSH Local Port Forwarding via OpenSSH
linux

Creates an SSH local port forward tunnel (-L flag), simulating the technique used by Magic Hound and FIN6 to route internal service traffic (RDP, SMB) through SSH to an external server.

Command

bash 
# Requires: SSH installed, access to a test SSH server (substitute TARGET_HOST)
# Simulates: 'ssh -N -L 8443:localhost:443 user@TARGET_HOST' used in tunneling campaigns
TARGET_HOST="test.example.internal"
ssh -N -L 8443:localhost:443 -o StrictHostKeyChecking=no -o ConnectTimeout=5 -o BatchMode=yes user@${TARGET_HOST} &
SSH_PID=$!
echo "[*] SSH tunnel PID: ${SSH_PID}"
sleep 3
ss -tlnp | grep 8443 || netstat -tlnp | grep 8443
echo "[*] Active tunnel check complete"

Cleanup

bash 
kill $(pgrep -f 'ssh -N -L 8443') 2>/dev/null; true

Expected Telemetry

Sysmon Event ID 1 (process create): Image=ssh, CommandLine contains '-N -L 8443:localhost:443'; Sysmon Event ID 3 (network): DestinationPort=22, Image=ssh

Expected Detection

KQL SSHPortForwarding branch alert on ssh process with -L flag; SPL score >= 60 for SSH port-forwarding pattern

Test 2 Plink SSH RDP Tunnel (Windows)
windows

Downloads Plink and simulates tunneling RDP (port 3389) over SSH, replicating the exact technique used by Magic Hound (APT35) for persistent remote access and FIN6 for C2 channel establishment.

Command

powershell 
# Download Plink from official PuTTY source
$plinkPath = "$env:TEMP\plink.exe"
if (-not (Test-Path $plinkPath)) {
    Invoke-WebRequest -Uri "https://the.earth.li/~sgtatham/putty/latest/w64/plink.exe" -OutFile $plinkPath -UseBasicParsing
}
# Simulate RDP tunnel command (connection will fail but generates process telemetry)
# Pattern: tunnel local 13389 -> remote 3389 through SSH (Magic Hound TTP)
$tunnelArgs = "-ssh -N -L 13389:127.0.0.1:3389 -batch -pw FakePassword [email protected]"
Write-Host "[*] Launching plink with args: $tunnelArgs"
Start-Process -FilePath $plinkPath -ArgumentList $tunnelArgs -NoNewWindow -PassThru | Select-Object Id, ProcessName
Start-Sleep -Seconds 5
Get-Process plink -ErrorAction SilentlyContinue | Select-Object Id, Name, Path, StartTime

Cleanup

powershell 
Stop-Process -Name plink -Force -ErrorAction SilentlyContinue; Remove-Item "$env:TEMP\plink.exe" -Force -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1 or Windows Security 4688: Image=plink.exe, CommandLine contains '-ssh -N -L 13389:127.0.0.1:3389'; Sysmon Event ID 3: outbound TCP to port 22

Expected Detection

KQL KnownTunnelingTool and SSHPortForwarding branches alert; SPL score >= 70 (plink tool name match) + 60 (SSH forwarding flag) = 130

Test 3 Windows Netsh Portproxy Rule Creation
windows

Creates a netsh portproxy rule to forward traffic using a built-in Windows mechanism, simulating adversary use of living-off-the-land techniques to establish tunnels without dropping external binaries.

Command

powershell 
# Requires: Administrator privileges
# Create portproxy rule forwarding local port 8080 to simulated internal target
Write-Host "[*] Creating netsh portproxy rule"
netsh interface portproxy add v4tov4 listenport=8080 listenaddress=127.0.0.1 connectport=80 connectaddress=10.0.0.1
Write-Host "[*] Current portproxy rules:"
netsh interface portproxy show all
Write-Host "[*] Registry persistence:"
reg query "HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp" 2>$null

Cleanup

powershell 
netsh interface portproxy delete v4tov4 listenport=8080 listenaddress=127.0.0.1

Expected Telemetry

Sysmon Event ID 1: Image=netsh.exe, CommandLine contains 'portproxy add v4tov4'; Sysmon Event ID 12/13: registry key creation under HKLM\SYSTEM\CurrentControlSet\Services\PortProxy

Expected Detection

KQL NetshPortProxy branch alert; SPL score = 55 (netsh portproxy match)

Test 4 Chisel Reverse Tunnel Server Startup (Linux)
linux

Deploys and starts Chisel in reverse tunnel server mode, simulating the tool's use by red teams and threat actors for bypassing egress filtering and establishing SOCKS5 proxy tunnels through firewalls.

Command

bash 
# Download Chisel binary
CHISEL_URL="https://github.com/jpillora/chisel/releases/latest/download/chisel_linux_amd64.gz"
wget -q "${CHISEL_URL}" -O /tmp/chisel.gz 2>/dev/null || curl -sL "${CHISEL_URL}" -o /tmp/chisel.gz
cd /tmp && gunzip -f chisel.gz
chmod +x /tmp/chisel
echo "[*] Chisel version:"
/tmp/chisel --version 2>&1 | head -1
# Start chisel server with reverse tunnel and SOCKS5 enabled (key attacker TTP)
echo "[*] Starting chisel server in reverse+socks5 mode"
/tmp/chisel server --port 8443 --reverse --socks5 &
CHISEL_PID=$!
echo "[*] Chisel PID: ${CHISEL_PID}"
sleep 5
ps aux | grep '[c]hisel'
ss -tlnp | grep 8443 2>/dev/null || netstat -tlnp | grep 8443 2>/dev/null

Cleanup

bash 
kill $(pgrep -f '/tmp/chisel') 2>/dev/null; rm -f /tmp/chisel /tmp/chisel.gz

Expected Telemetry

Sysmon/auditd process create: process name 'chisel' with '--reverse --socks5 --port 8443' in command line; network bind event on port 8443

Expected Detection

KQL KnownTunnelingTool branch alert on chisel binary; SPL score = 70 (known tool) + 85 (--reverse --socks5 flags) = 155

Related Detections

Tactic Hub

TA0011Command and Control

Related Techniques

T1090ProxyT1071Application Layer ProtocolT1573.001Symmetric CryptographyT1568.002Domain Generation AlgorithmsT1219Remote Access ToolsT1021.001Remote Desktop ProtocolT1001.003Protocol or Service Impersonation

Same Tactic: Command and Control

Popular Detections