Default Outbound Allow Rule in Azure NSGs Leaves Compromised Workloads Free to Exfiltrate Data

Symptom

A workload protected by an Azure Network Security Group with tightly restricted inbound rules can still send data outbound to arbitrary internet destinations without triggering any alert. Engineers reviewing the NSG in the Azure portal see only explicit inbound allow rules for known administrative ranges and an inbound deny for everything else, which reads as a fully locked-down boundary. When outbound flow logs or a compromised-host investigation are checked later, the same workload is found to have open outbound connectivity to internet hosts that were never approved, with no NSG rule blocking or logging that traffic.

False Assumption

The team reviewing the NSG assumes that restricting inbound access is equivalent to securing the whole network boundary, and that anything not explicitly allowed inbound is also blocked outbound. This treats the rule set as symmetrical, when it is not. Reviewers sign off the NSG as hardened after checking only the inbound rule list, without separately checking the outbound rule set or the platform’s default outbound behaviour.

Root Cause

Azure Network Security Groups apply a fixed set of default rules in each direction that remain active unless a lower-priority user-defined rule explicitly overrides them. On the outbound side, the default set includes a broad allow rule for internet-bound traffic, evaluated ahead of the final default deny. If no custom outbound rule is added, that default allow rule remains the effective outbound policy, regardless of how restrictive the inbound rule set is. Because the portal and CLI list custom rules separately from default rules, a reviewer who checks only the custom rule list never sees the default outbound allow rule doing the real work. This article treats the existence and general behaviour of that default outbound allow rule as established Azure NSG architecture; the exact current priority number should be reconfirmed against Microsoft Learn’s Network Security Groups documentation for the freshness date below, because it was not independently reconfirmed against a primary source captured specifically for this piece (see the human-review notes attached to this draft).

Impact

A compromised workload behind this NSG configuration retains an unmonitored, unrestricted path to exfiltrate data or reach command-and-control infrastructure over the internet, even though the NSG appears hardened on inbound inspection alone. The exposure does not depend on any inbound misconfiguration; it persists purely because outbound traffic was never independently reviewed, so the blast radius extends to every workload on the affected subnet or network interface that inherits the same default outbound posture.

Diagnosis

Confirm the gap by listing the effective security rules applied to the affected network interface, not just the custom rules configured on the NSG object, since the effective list includes the platform defaults that a casual review misses.

• List the effective rules on the NIC to see every rule actually being evaluated, including default rules.
• Separately list the custom rules on both the subnet-level and NIC-level NSGs, where both exist, to check whether an outbound restriction exists anywhere in the chain.
• Record the full effective-rules output before making any change; this becomes the rollback baseline.

Correction

Close the gap by adding an explicit, higher-priority outbound rule that denies unrestricted internet-bound traffic from the affected subnet or interface, then layering a specific allow-list for destinations the workload genuinely needs.

Build the destination allow-list first wherever possible, covering required package repositories, telemetry endpoints, update services and partner APIs, before applying the deny rule, so the correction does not convert a silent security gap into a silent outage.

Validation

Validation succeeds only when the effective rule list shows the new deny rule evaluated ahead of the default outbound allow rule and every required application dependency still functions.

Re-run the effective-rules command against the same NIC used for diagnosis and confirm the new rule appears above the default tier in evaluation order. Exercise the workload’s known outbound dependencies and confirm they still succeed, while a connection attempt to an arbitrary, non-allow-listed external endpoint from the same host is refused or times out.

Rollback

Rollback removes only the specific deny rule that this correction added, restoring the pre-change effective rule set captured during diagnosis.

If the new rule blocks a legitimate dependency missed during allow-list preparation, delete the named rule immediately, re-run the effective-rules command to confirm the environment matches the saved pre-change baseline, and re-test the previously failing dependency before treating the rollback as complete. Do not leave the workload in a partially-rolled-back state.

Prevention

Treat outbound rule review as a mandatory part of every NSG hardening exercise, not an optional follow-up to inbound restrictions. Build an explicit outbound rule set into subnet and NIC-level NSG templates from the start, so new workloads never rely on the platform default outbound allow rule by omission. Include an effective-rules check, covering both inbound and outbound and both subnet and NIC levels where applicable, in any change or audit process that claims a workload’s network boundary has been hardened.