Maneuver Through Azure Service Firewalls

What this lab covers

You work against several Azure services protected by network rules, including PostgreSQL, SQL, storage accounts, Cosmos DB and Key Vault, and establish what those rules actually restrict.

The lab exists to correct a common assumption. Teams treat a service firewall as though it were an access control decision, when it is a network reachability decision that sits in front of one.

It is rated intermediate and suits cloud architects and defenders as much as testers. If your data protection story depends on network rules, this is the lab that tests that assumption.

How Azure service firewalls actually work

Azure PaaS services have public endpoints by default. A service firewall restricts which source addresses or virtual networks may reach that endpoint, allowing specific ranges, specific subnets through service endpoints, or nothing at all.

Two exceptions widen this more than most teams realise. Trusted Microsoft services can be permitted to bypass the rules, which is often necessary for platform features to work and means the origin check is satisfied by services rather than by your network. Selected networks also frequently include the office range or a jump host, so reaching either is enough.

Crucially the firewall says nothing about authorisation. Once a request arrives from an allowed origin, access is decided by keys, connection strings, role assignments or access policies. A compromised workload inside the allowed network faces only that second layer, which is why network rules are a reduction in exposure rather than a boundary.

How to detect this in your own environment

Enable diagnostic logging on the data plane for these services. Control plane operations are logged by default in the activity log, but reads and writes to storage, Key Vault and databases require explicit configuration, and that is where use of the access is visible.

Key Vault deserves particular attention because access to secrets is exactly what an attacker wants and the log tells you which secret was read by which identity. Alert on secret reads by identities outside the expected set.

Alert on firewall rule changes. Adding an address range or enabling public access is a control plane event, is rare, and is a common step during an intrusion when the attacker's current origin is not permitted.

How to prevent it

Use private endpoints rather than service firewalls where the data genuinely must not be reachable from the internet. A private endpoint removes the public route entirely instead of filtering it.

Treat the data plane permission model as the real control. Role assignments and access policies decide what an authenticated caller can do, and they should be correct even if you assume the network layer is satisfied.

Review trusted service exceptions specifically. They are enabled to make features work and then forgotten, and they mean the network condition is satisfied by something outside your control.

Real-world context

Network-based restrictions on cloud data services are frequently presented as compensating controls in audits, and the gap between what they restrict and what they are believed to restrict is a recurring finding in cloud assessments.

The practical consequence appears whenever a workload inside the permitted network is compromised. At that point the firewall contributes nothing, and everything depends on whether the workload's identity was scoped tightly, which is the same lesson as instance metadata abuse in other providers.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts and T1530 Data from Cloud Storage Object.

Applying this at work

• Inventory which of your PaaS services rely on firewall rules rather than private endpoints, and move the sensitive ones to private endpoints.
• Review trusted service exceptions and confirm each is still required.
• Enable data plane diagnostic logging on storage, Key Vault and databases, which is off by default.
• Check the data plane permissions on services you consider protected by network rules, on the assumption that the network condition will be met.
• Alert on service firewall rule changes, particularly the enabling of public access.

Frequently asked questions

Do Azure service firewalls control authorisation?

No. They control which network origins can reach the endpoint. Authorisation is decided separately by keys, role assignments or access policies, so a request from an allowed origin still faces only that second layer.

What are trusted Microsoft services exceptions?

A setting permitting certain Azure platform services to bypass the firewall, often required for features to function. It means the origin condition can be satisfied by services rather than by your own network, which widens the effective boundary.

When should I use a private endpoint instead?

Whenever the data genuinely should not be reachable from the internet. A private endpoint removes the public route rather than filtering it, which is a stronger guarantee than any allow list.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.