Azure Blob Storage exceptions can become covert C2 channels

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SpecterOps's blog post: Azure Blob Storage wildcard exceptions can be repurposed into a covert C2 transport, exposing how trusted cloud allowlists can become an attacker path.

Why it matters: IAM, PAM, and cloud security teams need to treat egress exceptions as governed exposure, because trusted service allowlists can also create hidden communications paths for tooling and abuse.

Context

Enterprise egress control often fails at the exception layer rather than the baseline policy. Teams may build a default-deny posture, then widen it for cloud services, collaboration platforms, or deployment dependencies that appear operationally necessary.

In Azure environments, that trust boundary matters because storage endpoints can be reachable through broadly scoped outbound rules or proxy allowlists. When a service is approved by pattern instead of by narrowly defined purpose, the resulting exception can be used for more than the workflow it was meant to support.

Key questions

Q: Why can trusted cloud services become covert channels after a breach?

A: Trusted cloud services become covert channels after a breach because attackers can route command, data theft or staging through services that look legitimate to security controls. The trust-boundary failure is that outbound traffic to approved SaaS or storage endpoints may bypass inspection, so detection needs content controls, identity-based telemetry and unusual use monitoring.

Q: How do container-scoped tokens limit the impact of compromised credentials?

A: Container-scoped tokens limit the impact of compromised credentials by binding access to one container, one workload or one narrow runtime role instead of a broader account. If the token is exposed, the attacker only gets the permissions and lifetime attached to that container, which reduces the blast radius after token exposure.

Q: How do attack teams hide command and control in cloud storage traffic?

A: Attack teams hide command and control in cloud storage traffic by embedding instructions or exfiltrated data in ordinary uploads and downloads to storage services that blend into normal business use. The channel can ride on HTTPS, standard API calls and common file operations, which makes content inspection, egress controls and anomaly detection harder.

Technical breakdown

How Azure Blob Storage can carry C2 traffic

Azure Blob Storage is object storage, but from a transport perspective it is still an HTTP endpoint that can move data in both directions. If a client can PUT and GET blobs, it can exchange tasking and responses through ordinary request semantics, especially when payloads are wrapped in simple file-like objects. The security difference is not in the protocol itself, but in whether outbound access is narrowly constrained to the expected application flow or broadly permitted to any process that can reach the storage endpoint. See the Azure Storage Security Guide.

Practical implication: Review storage allowlists as transport paths, not just as application dependencies.

Why scoped SAS tokens reduce blast radius

A shared access signature token grants time-bound and scope-bound access to Azure Storage resources, which is safer than embedding an account-wide key in every endpoint. The key distinction is scope: a container-scoped token limits what one compromised client can touch, while an account-wide token can expose all containers, metadata, and related data paths if it is reused or recovered. For covert channels, that scoping is the difference between one compromised workload and an entire storage estate. See the Microsoft Azure Security Guide.

Practical implication: Use the narrowest token scope that still supports the workflow, and avoid account-wide secrets in distributed agents.

Why deployment guides become offensive intelligence

Deployment documentation often reveals the exact outbound exceptions vendors expect customers to make, and those exceptions can be broad enough to outlive the installation phase. That creates a governance gap: operational guidance for getting software working may quietly define the same network paths an attacker would later exploit. In practice, the issue is not that documentation is wrong, but that exception management often treats temporary onboarding rules as durable trust decisions. See the Firewall Management Guide.

Practical implication: Inventory vendor-driven allowlists separately from core policy and force expiry, ownership, and review on every exception.

Threat narrative

Attacker objective: The objective is to maintain reliable covert command and control inside a network that otherwise blocks conventional callback traffic.

1. Entry begins when an operator abuses a broadly trusted outbound exception to reach Azure Blob Storage endpoints from a target environment.
2. Credential access is achieved through scoped storage tokens or related secret material that authorize blob reads and writes within the chosen container.
3. Escalation occurs when the transport is wired into C2 tasking so the endpoint can exchange commands and responses through legitimate-looking storage operations.
4. Impact is covert command and control that blends into approved cloud traffic and can persist until the exception or token scope is removed.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted cloud exceptions are a hidden transport control, not a harmless convenience. Egress programs often focus on blocking obvious malicious destinations while leaving broad service wildcards untouched. That creates an attacker-friendly corridor whenever a cloud endpoint can carry bidirectional traffic. Practitioners should treat every allowlist exception as a governed communications path, not a generic dependency.

Scoped credentials matter more than the transport technology. The article's design choice to confine access to a single container illustrates the right instinct: reduce what any one credential can touch. If a token is reusable across containers or tied to an entire storage account, the blast radius becomes governance debt rather than an implementation detail. Azure Storage security is relevant here because storage hardening has to include token scope, not just network rules.

Deployment guidance can become an adversary reference library. Vendor installation instructions often expose the exact patterns defenders approve by default, which makes documentation review a legitimate security control. That is a supply-side governance problem as much as a network one, because the exception gets normalized before anyone asks who owns it, how long it lasts, or what it can reach. Practitioners should review onboarding rules as part of continuous control validation.

Covert C2 in trusted cloud services is really a trust-boundary failure. The operational question is not whether Blob Storage can be used for callbacks, but whether your network design allows any sufficiently trusted destination to become a generic relay. That matters across cloud, SOC, and identity teams because the same weak boundary can enable exfiltration, tasking, or post-compromise persistence. Security teams should align transport trust with explicit business purpose, not vendor reputation.

What this signals

Allowlist governance is now a transport-security problem. When approved cloud services become generic outbound exceptions, the boundary between application dependency and attacker infrastructure collapses. Security programmes should classify these paths as monitored communication channels, not passive network hygiene.

The named concept here is exception-to-transport drift: a temporary or narrowly justified allowlist expands into a standing communication path that outlives its original purpose. Once that happens, the security model no longer matches how the traffic is actually used, and defenders lose the ability to distinguish legitimate service use from covert relay activity. Practitioners should audit for this drift wherever cloud services are granted broad outbound reach.

The practical signal for defenders is simple: if a storage endpoint is allowed because it is trusted, but not because the business process is explicitly described and owned, the exception is too broad. Align firewall, proxy, and token governance so that every permitted cloud relay has a named system, a bounded purpose, and a reviewable lifecycle.

For practitioners

• Tighten outbound rules around cloud storage endpoints Replace wildcard allowances such as broad blob endpoint access with service-specific, purpose-bound rules that are tied to known workloads and owners.
• Separate onboarding exceptions from steady-state policy Track installation-time firewall and proxy exceptions as temporary assets with expiry dates, explicit approval, and recurring review.
• Scope storage credentials to a single workload or container Avoid account-wide secrets in distributed tools and prefer container-scoped access tokens that cannot read or list unrelated storage objects.
• Monitor blob-oriented traffic for tasking patterns Look for repeated small PUT and GET operations, predictable polling intervals, and delete-after-read behaviour against storage paths that are not part of an approved application.

Key takeaways

• Broad cloud allowlists can create covert communications paths when trusted storage services are reachable from restricted environments.
• Scoped tokens and container-level isolation materially reduce the blast radius if a storage-based channel is abused.
• Exception management is the control that matters most here, because deployment-time trust often outlives its original purpose.

Related NHI Mgmt Group resources: Azure Storage Security Guide · Firewall Management Guide · Microsoft Azure Security Guide · Command and Control (C2) Guide

Key terms

• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
• Azure Blob Storage: Azure Blob Storage is Microsoft’s object storage service for holding unstructured data such as code, backups, configuration files, and exported records. In security work, it matters because these containers often accumulate sensitive material, including credentials and API keys, that can be exposed if access controls, scanning, or retention practices are weak.
• Shared Access Signature: Shared Access Signature is the Azure authorization pattern behind SAS tokens. It uses signed parameters to define what action is allowed, where it applies, and how long it remains valid. The model supports controlled delegation, but it only stays safe when permissions are minimal and expiries are tightly managed.
• Egress Allow-List: An egress allow-list is a controlled list of destinations that systems are permitted to contact when sending outbound traffic. In identity and security operations, it restricts network egress to approved IPs, domains, ports, or services, reducing data exfiltration risk, limiting malware callback paths, and enforcing policy for applications, workloads, and non-human identities.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security programme that depends on them.