AWS IoT Core - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/aws-iot-core/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 20 Oct 2026 23:30:58 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgSuspicious Linux process connection to AWS IoT Core MQTThttps://feed.craftedsignal.io/briefs/2026-10-suspicious-linux-aws-iot-c2/Tue, 20 Oct 2026 23:30:58 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-suspicious-linux-aws-iot-c2/Adversaries may leverage AWS IoT Core as a command-and-control rendezvous point by deploying agents on Linux hosts that utilize MQTT over TLS to relay commands through cloud-based brokers.Adversaries are increasingly using AWS IoT Core as a covert command-and-control (C2) channel for compromised Linux hosts. By provisioning an attacker-controlled broker and deploying an agent - typically running from non-standard or writable directories such as /tmp, /dev/shm, or hidden user paths - the threat actor can communicate with the compromised asset via MQTT over TLS. This method allows for the relay of commands, execution results, and file transfers without requiring a direct connection to a dedicated operator backend server. Because AWS IoT endpoints are publicly resolvable and facilitate legitimate cloud traffic, this communication often blends in with standard business operations. The use of port 443 or 8883 for MQTT traffic further complicates network-based detection, necessitating focus on the correlation between endpoint behavior, specific process execution paths, and cloud-based infrastructure resolution.

Attack Chain

  1. The adversary gains initial access to the Linux host and executes a malicious binary or script from a high-entropy or writable path like /tmp or a hidden user directory.
  2. The malicious process retrieves the target AWS IoT Core data endpoint, which is uniquely formatted for the attacker's specific AWS account and region.
  3. The process initiates a DNS query to resolve the account-specific AWS IoT data endpoint (e.g., <prefix>-ats.iot.<region>.amazonaws.com).
  4. Upon receiving the resolved IP addresses from the DNS request, the process initiates an outbound TCP connection to one of these addresses.
  5. The connection is established over standard ports 443 or 8883, which are used for MQTT over TLS.
  6. The agent performs an MQTT handshake and subscribes to specific topics for C2 instruction and command execution.
  7. The attacker issues commands through the AWS IoT broker, which the agent executes, returning the output via the established MQTT channel.

Impact

Successful deployment of this C2 mechanism enables persistent, covert remote access to compromised infrastructure. Organizations targeted include those running Linux-based environments where unauthorized agents can be introduced via exploitation or credential compromise. If unchecked, this activity facilitates data exfiltration, lateral movement, and arbitrary command execution while bypassing traditional perimeter security controls that rely on blocking known malicious IP infrastructure.

Recommendation

Prioritized actions for detection engineering teams:

  • Deploy the provided Sigma-compatible detection logic to identify processes running from suspicious paths that resolve and connect to AWS IoT infrastructure.
  • Implement network monitoring to flag unexpected outbound connections to known AWS IoT data endpoint address patterns, especially when initiated by non-standard processes.
  • Enrich security event telemetry with packet-level inspection to identify the ALPN value "x-amzn-mqtt-ca" on port 443 connections, which indicates AWS IoT MQTT usage.
  • Review file system integrity and execution policies to prevent the execution of binaries from volatile or user-writable directories.
]]>highadvisorycommand-and-controllinuxawsc2