When malware calls home, it often does not call home directly. MITRE ATT&CK describes the use of intermediaries as Proxy (T1090), a command and control technique. It applies to ESXi, Linux, macOS, Network Devices and Windows. The technique has four sub-techniques: internal proxy, external proxy, multi-hop proxy and domain fronting.
How attackers use it
MITRE says adversaries may use a connection proxy to direct traffic between systems, or as an intermediary to a command and control (C2) server, so that they avoid direct connections to their own infrastructure. Many tools exist for traffic redirection and port redirection. MITRE names HTRAN, ZXProxy and ZXPortMap as examples.
The reasons MITRE gives:
- to manage C2 communications,
- to reduce the number of simultaneous outbound network connections,
- to stay resilient when a connection is lost,
- to ride over existing trusted communication paths between victims, which avoids suspicion.
Adversaries may also chain several proxies together to hide the source of malicious traffic, and may use the routing schemes of Content Delivery Networks to proxy C2 traffic.
How to detect it
MITRE's detection strategy (DET0445) is about the odd process and the odd connection. Its analytics, by platform:
- Windows: a suspicious process such as rundll32, svchost, powershell or netsh, followed by a new network connection to internal hosts or uncommon external endpoints on high or non-standard ports.
- Linux: user space tools such as socat, ncat, iptables or ssh used in non-standard ways to set up reverse shells, port forwarding or connections between hosts, often combined with uncommon outbound destinations or SSH tunnels.
- macOS: AppleScript, LaunchAgents or remote login services such as ssh and networksetup establishing proxy tunnels or dynamic port forwards.
- ESXi: direct use of nc, socat or reverse tunnel scripts by abnormal user contexts, or unauthorized VIBs starting connections from the hypervisor to external systems.
- Network devices: port forwarding rules added to route traffic through an internal host, or proxy and firewall rule changes that do not match baselined policy.
Two data sources carry most of the value. Process creation logs with command lines show which tool started the tunnel. Network flow or firewall logs show where it went. Putting them side by side is what turns two ordinary facts into a detection.
How to reduce the risk
MITRE lists three mitigations:
- Filter Network Traffic. Block traffic to known anonymity networks and C2 infrastructure using allow and block lists. MITRE warns that this can be circumvented by other techniques such as domain fronting.
- Network Intrusion Prevention. Use network intrusion detection and prevention systems with signatures for specific adversary malware. MITRE cautions that signatures are often specific to one tool or protocol, and adversaries will change C2 signatures over time to avoid detection.
- SSL/TLS Inspection. Where HTTPS can be inspected, analyze captures for connections that look like domain fronting.
Beyond those, keep egress narrow. A workstation that can reach only an approved proxy, and a server that can reach only the few destinations it needs, make an unexpected relay stand out.
Check your own environment
- Can servers connect to arbitrary internet hosts, or only to allow listed ones?
- Which hosts are allowed to run SSH port forwarding, and is it logged?
- Do you log firewall rule and NAT changes on network devices?
- Can you see TLS server names in your egress logs?
On a Linux host, a read-only look at established outbound connections and the process behind each:
ss -tnp state established
You may need elevated rights to see process names for other users.
Quick check
Why do adversaries chain proxies?
To disguise the source of the traffic. Defenders can usually see the last proxy but not the earlier ones.
What limit does MITRE state for blocking known C2 infrastructure?
It may be circumvented by techniques such as domain fronting.
Sources
- MITRE ATT&CK, T1090 Proxy: https://attack.mitre.org/techniques/T1090/
