Abuse of AWS IoT Secure Tunneling Localproxy for Post-Exploitation C2
Adversaries are abusing the legitimate AWS IoT Secure Tunneling localproxy binary in destination mode to establish unauthorized remote access tunnels through AWS-managed infrastructure.
Adversaries are leveraging the legitimate, signed AWS IoT Secure Tunneling localproxy binary for post-exploitation command-and-control (C2) and persistent remote access. This technique involves executing the binary on a compromised host in 'destination' mode, which instructs the proxy to establish an outbound connection to the AWS IoT Secure Tunneling data plane (data.tunneling.iot.<region>.amazonaws.com) via port 443. Once connected, the proxy relays traffic from the attacker's workstation to local services on the victim host, such as SSH on localhost:22. Because this tool is a documented, signed AWS component often used for legitimate device management, its execution can easily blend into authorized administrative activity. Notably, the C2 channel is established using the attacker's own AWS account credentials, leaving no OpenTunnel events in the victim's CloudTrail logs, making detection dependent on endpoint-level process and network behavior monitoring.
Attack Chain
- Attacker achieves initial access to a target host and identifies it as a candidate for persistent remote access.
- Attacker drops the legitimate
localproxybinary onto the target filesystem or uses an existing copy if available. - Attacker executes
localproxywith destination-mode flags (e.g.,-d,--destination-app, or-m dst) to prepare the host to receive tunnel traffic. - The
localproxyprocess initiates a DNS lookup for the AWS Secure Tunneling data plane endpoint (data.tunneling.iot.<region>.amazonaws.com). - The process establishes an outbound TCP/443 connection to the resolved AWS endpoint to register the destination.
- Attacker initiates a connection from their own infrastructure through the Secure Tunneling service.
localproxyreceives the traffic from the tunnel and forwards it to the specified local service (e.g., TCP 127.0.0.1:22).- Attacker gains interactive access to the victim host through the established relay.
Impact
Successful abuse of this technique provides adversaries with a stealthy, persistent, and authorized-looking C2 channel that bypasses many traditional perimeter defenses. It enables unauthorized remote access to internal services, potential data exfiltration, and lateral movement from the compromised host, all while utilizing AWS-managed infrastructure that is often implicitly trusted by corporate security policies.
Recommendation
Prioritize the implementation of process and network correlation rules to detect unauthorized execution of the localproxy binary.
- Deploy the provided EQL detection rule to your SIEM and tune against known-legitimate administrative device-management activity.
- Monitor for and alert on DNS queries to
*.tunneling.iot.*.amazonaws.comoriginating from endpoints not explicitly authorized for AWS IoT device management. - Isolate hosts where
localproxyis identified without a corresponding business justification and block the C2 domain at the DNS or egress firewall level. - Investigate any local connections from the
localproxyprocess to sensitive local services like SSH (22) or RDP (3389) during the process execution window.
Immediate actions
Deploy EQL detection for localproxy destination mode behavior.
Threat Hunt
Process executions of 'localproxy' or 'localproxy.exe' with -d or --destination-app flags.
Data: Process creation logs
Enrichment needed
- Authorized IoT asset list (IT Operations) To reduce false positives for legitimate administrative tools.
Mitigations
Implement egress filtering on endpoints to prevent unauthorized access to tunneling data plane domains.
C2 activity
Gaps
- None.
Indicators of compromise
1
domain
| Type | Value |
|---|---|
| domain | *.tunneling.iot.*.amazonaws.com |