Full Report
On a recent assessment we came across the following scenario: 1) We have command execution through a web command interpreter script (cmd.jsp) on a remote Linux webserver 2) The box is firewalled only allowing 53 UDP ingress and egress 3) The box is sitting on the network perimeter, with one public IP and one internal IP, and not in a DMZ So we want to tunnel from the SensePost offices to Target Company’s internal machines, with this pretty restrictive setup. How did we accomplish this?
Analysis Summary
# Tool/Technique: dns2tcp
## Overview
dns2tcp is a tool designed to create tunnels over the DNS protocol. It allows attackers to encapsulate TCP/IP traffic within DNS queries and responses, enabling communication and data exfiltration even when firewalls strictly limit outbound connections to only standard protocols, such as allowing only DNS (port 53 UDP) traffic. In the context described, it was used to establish a command channel from the compromised Linux webserver to an external control server (`_SPDNSTUNNEL_`).
## Technical Details
- Type: Tool
- Platform: Linux (Target server)
- Capabilities: Tunneling TCP traffic over DNS (port 53 UDP), supporting services like SSH or proxies within the tunnel.
- First Seen: The article referencing this tool/technique is from February 2008, suggesting the tool or concept predates this period.
## MITRE ATT&CK Mapping
- T1071 - Application Layer Protocol
- T1071.004 - DNS
- T1105 - Ingress Tool Transfer (Implied, as the tool had to be uploaded/compiled)
## Functionality
### Core Capabilities
- Establishing a bidirectional tunnel between a client (compromised host) and a server (`_SPDNSTUNNEL_`) using DNS queries and responses for encapsulation.
- Allowing the encapsulation of TCP connection data (e.g., SSH traffic) within the DNS channel.
### Advanced Features
- **Service Portability:** The dns2tcp server was configured to offer multiple encapsulated services, specifically SSH and proxy services, over the DNS tunnel connection.
- **Chaining for Internal Access:** Enabled the establishment of subsequent tunnels (SSH tunnels) through the compromised host to reach internal network resources, bypassing perimeter firewalls designed to block general outbound connections.
## Indicators of Compromise
- File Hashes: Not provided in the article.
- File Names: `dns2tcpc` (client)
- Network Indicators:
- DNS queries directed to the attacker-controlled domain (`mooo.mooo.moooo` or `_SPDNSTUNNEL_.sensepost[.]com`).
- UDP/53 traffic to/from the target's public IP corresponding to the tunnel establishment.
- Behavioral Indicators:
- Presence of the compiled `dns2tcp` executable on the target system.
- High volume of DNS query/response traffic originating from the compromised web server to an external, known domain.
## Associated Threat Actors
- The article attributes this specific use case to an assessment by SensePost, but the technique itself is widely applicable and used by various threat actors seeking covert C2 channels.
## Detection Methods
- Signature-based detection: Signatures for the `dns2tcp` executable files.
- Behavioral detection: Monitoring large volumes of non-standard or unusually large DNS requests/responses, or seeing DNS traffic directed to external domains known to host exfiltration channels.
## Mitigation Strategies
- **Firewall Policy:** Restrict DNS (UDP/53) egress only to known, approved recursive DNS servers if possible, blocking queries to external, non-corporate authoritative domains.
- **DNS Traffic Analysis:** Employ Deep Packet Inspection (DPI) or DNS anomaly detection systems to flag oversized DNS requests/responses or data patterns indicative of tunneling.
- **Principle of Least Privilege:** Limit command execution capabilities on perimeter web servers, preventing the ability to upload and compile tools like `dns2tcp`.
## Related Tools/Techniques
- Iodine (DNS tunneling tool)
- dnscat2
- ICMP Tunnels
***
# Technique: Multi-Stage Tunneling via DNS and SSH
## Overview
This summarizes the multi-layered tunneling strategy used to pivot from a perimeter web server with restricted outbound connectivity (only port 53 UDP allowed) to clients on the internal network. It involves setting up a DNS tunnel to establish an initial command channel, followed by an SSH tunnel transmitted *over* that DNS tunnel to create a SOCKS/port forward to the internal network.
## Technical Details
- Type: Technique (Combining DNS Tunneling and SSH Port Forwarding)
- Platform: Linux (Target server) and external control systems.
- Capabilities: Bypassing Layer 3/4 egress filtering, gaining arbitrary TCP access to an internal network segment from an external location.
- First Seen: Relies on established techniques known prior to 2008.
## MITRE ATT&CK Mapping
- T1105 - Ingress Tool Transfer (Initial access via `cmd.jsp`)
- T1090 - Proxy
- T1090.002 - External Proxy
- *Mapping Note: DNS Tunneling acts as the initial external proxy/C2 channel.*
- T1090.003 - Multi-hop Proxy (The entire chain acts as a multi-hop proxy)
## Functionality
### Core Capabilities
1. **Initial Access/Execution:** Gaining command execution via a web command interpreter (`cmd.jsp`).
2. **Establish Layer 1 Tunnel (C2):** Using `dns2tcp` client on the target to send traffic over UDP/53 to the external `dns2tcp` server (`_SPDNSTUNNEL_`). This creates a secure (or semi-secure) pipe for executing commands.
3. **Establish Layer 2 Tunnel (Internal Pivot):** Executing an SSH client command on the compromised host *through* the Layer 1 DNS tunnel. This SSH connection forwards traffic ($R$) from the external server (`_SPDNSTUNNEL_`) back toward an internal machine (`intranetserver.target.com:80`).
4. **External Access:** The assessment laptop connects to the external server (`_SPDNSTUNNEL_`) to reach the internal network service via a final local SSH port forward ($L$) created from the assessment laptop, through `_SPDNSTUNNEL_`, through the DNS tunnel, and landing on the internal target.
### Advanced Features
- **Non-Interactive SSH Setup:** Use of SSH keys (`-i /tmp/key`) and setting `stricthostkeychecking=no` allowed the creation of the critical Layer 2 SSH pivot command to run non-interactively via the limited shell access provided over the DNS tunnel.
- **Dynamic Pivoting:** The ability to tear down and redeploy the Layer 2 SSH tunnel (the internal pivot) by modifying only the final remote destination, while keeping the initial Layer 1 DNS tunnel active, allowing for rapid pivoting to different internal systems (e.g., pivoting from port 80 to port 139/Samba).
## Indicators of Compromise
- File Hashes: Not provided.
- File Names: Uploaded bash scripts used to execute the initial tunneling commands.
- Network Indicators:
- DNS traffic patterns matching DNS tunneling activity directed at the attacker's known infrastructure domain.
- SSH connections observed on the external server (`_SPDNSTUNNEL_`) arriving via non-standard ports (e.g., the SSH port used by dns2tcp, if exposed).
- Behavioral Indicators:
- Execution of SSH commands containing remote forwarding syntax (`-R`) originating from execution channels likely associated with web application activity (if monitoring process lineage).
- Emergence of outbound connections from the internal network segment that resolve back through the initial perimeter host.
## Associated Threat Actors
This complex, multi-layered technique is characteristic of sophisticated penetration testing engagements or advanced persistent threats (APTs) that must maintain C2 connectivity despite severe network segmentation and egress filtering.
## Detection Methods
- Behavioral detection: Identifying sequential command executions where a remote shell utility (like SSH) is executed using input sourced from a non-interactive environment (the DNS tunnel handler).
- Network Flow Analysis: Monitoring for DNS traffic patterns that deviate significantly from normal query sizes and frequencies, indicative of data encapsulation.
## Mitigation Strategies
- **Strict Egress Control:** Enforce egress filtering based on destination, not just protocol. Only allow DNS queries to organizational forwarders.
- **Network Segmentation Review:** Ensure hosts on the network perimeter do not possess routing capabilities that would allow them to directly access valuable internal subnets without intermediate security controls.
- **SSH Hardening:** Disable password authentication and strictly enforce host key checking on all infrastructure devices to prevent the use of pre-staged keys for non-interactive tunneling operations.
## Related Tools/Techniques
- SSH Remote Port Forwarding (`-R`)
- Socks Proxification (The final step of the tunnel chain often results in a SOCKS proxy capability for the analyst).