Aws-Iot - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/aws-iot/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 29 Sep 2026 04:12:21 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgAbuse of AWS IoT Secure Tunneling Localproxy for Post-Exploitation C2https://feed.craftedsignal.io/briefs/2026-09-aws-iot-tunneling-abuse/Tue, 29 Sep 2026 04:12:21 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-aws-iot-tunneling-abuse/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

  1. Attacker achieves initial access to a target host and identifies it as a candidate for persistent remote access.
  2. Attacker drops the legitimate localproxy binary onto the target filesystem or uses an existing copy if available.
  3. Attacker executes localproxy with destination-mode flags (e.g., -d, --destination-app, or -m dst) to prepare the host to receive tunnel traffic.
  4. The localproxy process initiates a DNS lookup for the AWS Secure Tunneling data plane endpoint (data.tunneling.iot.<region>.amazonaws.com).
  5. The process establishes an outbound TCP/443 connection to the resolved AWS endpoint to register the destination.
  6. Attacker initiates a connection from their own infrastructure through the Secure Tunneling service.
  7. localproxy receives the traffic from the tunnel and forwards it to the specified local service (e.g., TCP 127.0.0.1:22).
  8. 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.com originating from endpoints not explicitly authorized for AWS IoT device management.
  • Isolate hosts where localproxy is identified without a corresponding business justification and block the C2 domain at the DNS or egress firewall level.
  • Investigate any local connections from the localproxy process to sensitive local services like SSH (22) or RDP (3389) during the process execution window.
]]>highadvisoryaws-iotcommand-and-controltunnelingpost-exploitation