Cloud relay services are the perfect C2 infrastructure, and most organizations cannot block them without breaking legitimate business operations.

This talk presents a comprehensive offensive analysis of three abuse vectors across Microsoft Azure and Amazon Web Services, weaponizing cloud services that enterprises depend on daily for command and control, lateral movement, and persistent access. We target Azure Relay Bridge, AWS IoT Secure Tunneling, and AWS IoT Core MQTT, services whose endpoint domains (*.servicebus.windows.net, *.iot.amazonaws.com) enterprises cannot blocklist without crippling legitimate business operations.

I'll demonstrate that these are not isolated findings but instances of a repeatable pattern: cloud relay weaponization. Any cloud service that brokers connections through trusted infrastructure, requires only outbound HTTPS, and shares domains with business critical services is a candidate for C2 abuse. I'll present the methodology for identifying these services and validated attack chains for each.

For Azure Relay Bridge, the attacker deploys azbridge, a legitimate Microsoft-authored, open-source tool, to tunnel arbitrary TCP traffic through Azure's relay infrastructure, appearing as standard HTTPS to *.servicebus.windows.net. It installs as a persistent system service across Windows, Linux, and macOS. The abuse here is trust in Microsoft's infrastructure and shared service domains, not a pre-existing binary on the host.

For AWS IoT, I'll present two complementary techniques. First, Secure Tunneling: the attacker uses their own AWS account to create encrypted WebSocket tunnels via the officially published localproxy binary, generating no control plane API activity in the target's CloudTrail. I validated this with Sliver C2 across three protocols (mTLS, HTTPS, HTTP), but discovered operational limitations including 12 hour tunnel maximums, token rotation complexity, and IoT optimized bandwidth caps that constrain persistent C2 use. These limitations led to the second technique: weaponizing AWS IoT Core MQTT as a full C2 transport channel using X.509 mutual TLS authentication, which eliminates the tunnel lifetime and bandwidth constraints entirely.

I'll also present custom Mythic C2 agents (Poseidon for Linux/macOS, Apollo for Windows) with transport profiles for both Azure Relay and AWS IoT MQTT, all end to end validated on AMD64 and ARM64. Live demonstrations showcase complete attack chains: Mythic beaconing through Azure Relay, lateral movement via IoT Secure Tunneling, and persistent C2 over IoT Core MQTT, all through traffic indistinguishable from legitimate cloud service usage.

Attendees leave with released Mythic C2 agents and profiles for Azure and AWS, a framework for identifying additional cloud relay services, detection engineering guidance mapped to the Pyramid of Pain, and actionable defensive hardening for both cloud providers.

The Cloud Relay Pattern (~5 min)
Core thesis: cloud relay services are the ideal C2 infrastructure: outbound-only HTTPS, cloud brokered connectivity, and domains enterprises can't blocklist without breaking business essentials. I walk through the methodology I used to systematically identify relay capable services across cloud provider catalogs and why Azure Relay Bridge and AWS IoT stood out. Prior acknowledgment to Ruben Boonen (@fuzzysecurity) whose SAFACON 2024 framework on laundering C2 through high reputation services laid the groundwork, my research takes that from theory to validated, weaponized tooling.

Azure Relay Bridge (~9 min)
I break down Azure Relay Bridge (azbridge). Microsoft-maintained, MIT-licensed, open-source, as an offensive transport. Service architecture, the full attack chain from relay namespace creation to C2 agent check in, and the LOLBin angle: this is a Microsoft-signed binary with native service persistence on Windows, Linux, and macOS. I demo (likely recorded) my custom Mythic C2 profile over Azure Relay transport: agent tasking, post-exploitation, all traffic showing up as HTTPS to *.servicebus.windows.net. Wireshark evidence woven into the demo, not a separate section.

AWS IoT Two Complementary Techniques (~10 min)
Two techniques presented as a natural progression. Starting with Secure Tunneling: tunnels created from the attacker's own AWS account, zero CloudTrail entries in the target environment, strongest audit evasion property I found across either provider. I show lateral movement with Sliver C2 integration, then get into the operational limits I hit during extended testing (12 hour tunnel lifetime, distinctive 20 second keep-alive, ~1 Mbps ceiling), so great for pivoting, not ideal for persistent C2.

Those limits led me to technique two: IoT Core MQTT as a persistent C2 channel. X.509 mTLS auth, MQTT pub/sub, no tunnel lifetime restrictions. I built custom Mythic agents (Poseidon fork in Go, Apollo fork in C#) that beacon indefinitely through *.iot.amazonaws.com. Full end to end demo. The two techniques are complementary. Secure Tunneling for initial pivot, MQTT for persistence.

Detection Engineering and the Defender's Dilemma (~4 min)
I lay out the defender's problem straight: these are legitimate services, valid certs, unblockable domains, traditional controls all pass. Then I get into what actually works, organized around the Pyramid of Pain. Key detection anchors: AWS IoT's 20-second keep-alive interval, anomalous long-duration WebSocket connections to *.servicebus.windows.net, and denying iot:OpenTunnel via SCPs in accounts that don't use IoT. I flag the CloudTrail blind spot as somewhere AWS should improve visibility.

Future Work (~2 min)
Full open source release of the Mythic agents for both transports (AMD64 and ARM64 validated), translation containers, infra automation, and a complete detection rule package (Suricata, Zeek, Splunk). The cloud relay pattern extends beyond two providers, I'll close with a call to action for the community to find and document more.