Full Report
In offensive security, the ability to blend seamlessly with legitimate traffic is vital to avoid detection. Establishing command-and-control (C2) communications can be challenging in environments fortified with security measures like perimeter firewalls and web proxies.
Analysis Summary
# Tool/Technique: Azure Service Bus WebSockets C2
## Overview
This technique involves using the **Azure Service Bus** messaging service as a covert Command-and-Control (C2) channel. By utilizing WebSockets over HTTPS, attackers can tunnel C2 traffic through a legitimate, trusted Microsoft cloud infrastructure. This allows the communication to blend with routine enterprise cloud traffic and bypass restrictive perimeter firewalls or web proxies that only allow outbound connections to known-good cloud service providers.
## Technical Details
- **Type**: Technique (C2 Infrastructure / Living-off-the-Cloud)
- **Platform**: Multi-platform (Windows, Linux, macOS via .NET/Python/Other SDKs)
- **Capabilities**: Bidirectional communication, firewall/proxy bypass, traffic obfuscation, and asynchronous task execution.
- **First Seen**: Research documented in late 2024.
## MITRE ATT&CK Mapping
- **TA0011 - Command and Control**
- **T1071.001 - Application Layer Protocol: Web Protocols** (Using HTTPS/WebSockets)
- **T1102.002 - Web Service: Bidirectional Communication** (Using Azure Service Bus)
- **T1573.002 - Encrypted Channel: Digital Certificates** (Leveraging Microsoft’s SSL/TLS certificates)
## Functionality
### Core Capabilities
- **Proxy/Firewall Evasion**: Connections are initiated outbound to `*.servicebus.windows.net` via Port 443, which is typically permitted in hardened environments.
- **Message Queuing**: The C2 server and the "beacon" interact with Azure Service Bus Queues or Topics. The server pushes commands to a queue, and the beacon polls/receives them.
- **Asynchronous Communication**: Commands can be stored in the queue while the beacon is offline, allowing for flexible "sleeping" intervals.
### Advanced Features
- **WebSocket Integration**: Utilizing WebSockets over HTTPS provides a persistent, full-duplex communication channel that appears to security tools as a standard, encrypted web session.
- **Shared Access Signatures (SAS)**: Authorization is handled via SAS tokens, meaning the malware does not need full Azure credentials, only a limited-scope connection string.
## Indicators of Compromise
- **File Hashes**: *Note: As this is a technique using legitimate SDKs, hashes will vary based on the specific implementation (e.g., a custom Python or C# script).*
- **File Names**: `Microsoft.Azure.ServiceBus.dll`, `Azure.Messaging.ServiceBus.dll` (legitimate libraries used maliciously).
- **Registry Keys**: N/A
- **Network Indicators**:
- `[namespace].servicebus.windows[.]net`
- Connections to Port 443 targeting Microsoft-owned IP ranges.
- **Behavioral Indicators**:
- A process (e.g., `powershell.exe`, `rundll32.exe`, or an unknown binary) maintaining a persistent connection to Azure Service Bus endpoints.
- Frequent HTTPS POST/GET or WebSocket upgrade requests to Azure messaging URLs.
## Associated Threat Actors
- While currently documented as a research-based offensive security technique, "Living-off-the-Cloud" (LotC) tactics are frequently used by:
- **APT29** (Cozy Bear)
- **UNC2452** (associated with SolarWinds/Nobelium)
## Detection Methods
- **Behavioral Detection**: Monitor for unusual processes initiating network connections to `servicebus.windows.net`. Legitimate use is typically restricted to specific server roles or cloud-native applications, not standard user workstations.
- **Azure Log Analytics**: Monitor Azure Service Bus logs for:
- Unusual queue/topic creation and deletion.
- High volume of `Receive` or `Send` operations from unexpected source IPs.
- Shared Access Policy (SAS) creation or modifications.
- **Traffic Analysis**: Inspect TLS SNI headers. While the traffic is encrypted, the target domain (Service Bus) is visible unless Encrypted Client Hello (ECH) is used.
## Mitigation Strategies
- **Network Filtering**: Implement strict egress filtering. Block access to Azure services that are not required for business operations.
- **Conditional Access**: If using Managed Identities, restrict access to the Service Bus namespace to specific authorized resources.
- **Namespace Hardening**: Use "Private Endpoints" for Azure Service Bus so it is not accessible over the public internet.
- **Endpoint Detection & Response (EDR)**: Configure EDR to alert on standard binaries (like PowerShell) loading Azure Messaging SDK libraries.
## Related Tools/Techniques
- **C2 via OneDrive/Google Drive**: Using cloud storage for command hosting.
- **Azure Functions C2**: Using serverless computing to relay C2 traffic.
- **Microsoft Graph API C2**: Leveraging Graph API (Outlook/Teams) for messaging.