Azure Architecture: What Every Incident Responder Must Understand Before Touching a Case
- 6 minutes ago
- 8 min read
Azure incident response is not the same as endpoint IR. The telemetry is different, the artifacts are different, and if you approach it the same way, you will miss everything that matters.
Lets start with this series
Before you can investigate anything in Microsoft Azure, you need to speak the language. Not the marketing language — the actual structural language that determines who can see what, where logs live, and why you might be staring at a completely blind spot without even knowing it.
Azure is not just a place where virtual machines run. It is a layered ecosystem with a very specific hierarchy, and if you do not understand that hierarchy, you will waste hours chasing down logs that do not exist yet, or requesting permissions that will not actually give you what you need.
This article breaks down the Azure architecture the way an investigator needs to understand it — not as a cloud architect, but as someone who shows up mid-incident and needs to know what they are looking at, fast.
The Five-Layer Architecture: How Azure Is Structured
Azure organizes everything into five main components, stacked on top of each other. Think of it like a set of Russian nesting dolls — each layer lives inside the one above it, and permissions at the top flow downward to everything beneath them.
1. The Tenant
The tenant is the outermost container. It represents the organization itself — your client's company. Every tenant is tied to a dedicated identity service that controls who can log in and what they can do. When a company signs up for Azure, they get one tenant. Larger enterprises may have multiple tenants for different subsidiaries or regional entities.
From an investigation standpoint, the tenant boundary matters because logs, permissions, and identities are all scoped to it. If you are dealing with a multi-tenant environment, confirm which tenant holds the resources you are investigating — and make sure you have access to it before you start.
2. Management Groups
Management groups are optional containers that sit above subscriptions. Large enterprises use them to organize subscriptions into logical groupings — separating production environments from development, or grouping subscriptions by business unit.
What makes management groups significant for investigators: policies and permissions can be applied at this level and cascade downward to every subscription within the group. If someone set a logging policy at the management group level, it affects everything below it. If someone was granted access at the management group level, they have access to everywhere beneath it.
Not every company uses management groups. Smaller organizations often skip them entirely. Do not assume they exist — verify.
3. Subscriptions
A subscription is essentially a billing boundary and an agreement between the organization and Microsoft to use Azure services. Most organizations end up with multiple subscriptions to separate costs by department, project, or environment.
Here is why this matters to investigators: your permissions do not automatically span all subscriptions. If you are granted access to one subscription and the resources you need are in another, you are going to hit a wall. Before starting any investigation, enumerate all subscriptions in the tenant and confirm your access level to each one. It sounds obvious but it is easy to overlook, especially when a client says 'you have admin access' without specifying that means admin access to only one of their twelve subscriptions.
4. Resource Groups
Resource groups are containers for related resources. Think of them as project folders — a web application might have its own resource group containing the virtual machine, storage account, database, and networking components all in one place.
Resource groups matter to investigators because access control can be scoped at this level. A user might have read-only access at the entire subscription level but Owner permissions on a specific resource group. Conversely, you might be granted access only to one resource group — which severely limits your visibility. If this happens, push back and request subscription-level access. Investigating with resource group-level permissions only is like trying to find a needle in a haystack while only being allowed to look at one bale at a time.
5. Resources
Resources are the actual things — virtual machines, storage accounts, databases, network interfaces, IP addresses, and hundreds more. Each resource lives inside a resource group, which lives inside a subscription, which lives inside a tenant. Everything traces back up the chain.
Resource IDs: Azure's Internal Naming Convention
Every single resource in Azure — from a VM to a network interface to a snapshot — has a unique identifier called a Resource ID. It follows this predictable format:
/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/<ProviderName>/<ResourceType>/<ResourceName>Take a virtual machine as an example. It has one Resource ID for the VM itself, another for its OS disk, another for its network interface, and another for any public IP address assigned to it. Each component is individually addressable.
In practice, Resource IDs show up constantly in logs. When you see a long string starting with '/subscriptions/' in a log entry, that is your signpost telling you exactly which resource was touched — at which subscription, resource group, and service level. Learning to read them quickly saves real time during an investigation.
Azure Resource Manager: The Traffic Cop Behind Everything
Every action you take in Azure — whether through the web portal, a CLI command, a PowerShell script, or an API call — goes through one central layer called the Azure Resource Manager (ARM).
ARM is the management plane that handles creation, modification, and deletion of resources. It validates your permissions, applies your request, and logs what happened.
The key insight for investigators: regardless of how an action was taken, ARM processed it and ARM logged it. Whether an attacker used the Azure portal GUI or quietly ran scripts via the CLI at 3am, the record goes through the same place. There is no hidden channel that bypasses the audit trail.
ARM also supports JSON-based templates called ARM templates, which let organizations deploy consistent environments repeatably — often called infrastructure as code. If you encounter these templates during an investigation, they can reveal a lot about the intended architecture of an environment.
💡 Investigator Note: ARM is conceptually similar to AWS CloudFormation. If you have AWS investigation experience, the mental model transfers well.
Azure Role-Based Access Control (RBAC): Who Can Do What
Azure uses Role-Based Access Control (RBAC) to govern who can access resources and what they are allowed to do. Every time a request goes through ARM, RBAC is checked to determine if the requester has the necessary permissions.
Understanding RBAC matters for two reasons: it shapes what you as an investigator can actually see and do during your engagement, and it helps you identify how a threat actor may have obtained or escalated their access.
The Three Elements of a Role Assignment
Every access grant in Azure is built from three components:
Security Principal — The entity being given access. This could be a user account, a group, a service principal (think: an application's identity), or a managed identity.
Role Definition — The set of permissions being granted. The most common built-in roles are: Reader (read-only), Contributor (read and write, but cannot grant access to others), and Owner (full control, including the ability to grant access to others).
Scope — Where the permission applies. This can be set at the management group, subscription, resource group, or individual resource level.
When investigating an incident, you ideally want Owner-level access at the subscription level.
This gives you the widest view and the most flexibility. In practice, you will sometimes be handed Contributor or Reader access to a single resource group. Know what you have — and know what you are missing.
Enumerating What a User Can Access
One of the first things to do in an investigation is understand what a specific user or compromised account actually had access to. This is harder than it sounds because access can be granted at any level of the hierarchy, and a user might have no access at the subscription level yet have Owner permission on a critical resource group.
The most efficient way to enumerate this is via CLI. First, select the relevant subscription:
az account set --subscription "Production Environment"Then enumerate role assignments for the account under investigation:
az role assignment list --all --assignee compromised-user@company.comThe --all flag is essential. Without it, you only see top-level assignments and miss anything granted at the resource group or individual resource level. Repeat this process for every subscription in the tenant.
The PowerShell equivalent if you prefer that route:
Get-AzRoleAssignment -SignInName compromised-user@company.com
MITRE ATT&CK and Azure: Where Threat Actor Behavior Maps to the Cloud
MITRE ATT&CK includes specific matrices for cloud environments with dedicated coverage for Azure across multiple matrices: Office 365, Azure AD, SaaS, and IaaS. These give you a structured way to categorize attacker behavior during an investigation.
In practice, threat actors operating in Azure environments consistently focus on a predictable set of activities:
Credential theft and verification — Attackers frequently test stolen credentials using legacy authentication protocols such as IMAP, which can bypass MFA. Mitigations: disable legacy auth protocols and enforce multi-factor authentication.
Token theft — Rather than stealing user passwords, sophisticated attackers steal OAuth tokens that applications use to authenticate. These tokens can grant long-term access without triggering password-based alerts.
Data collection — OneDrive, SharePoint, and Exchange are common targets for bulk data collection before exfiltration.
Data exfiltration — Storage accounts are frequently used as staging grounds for data theft. The Graph API is another common exfiltration channel.
Resource abuse — Cryptocurrency mining using compromised Azure subscriptions is extremely common. If you see unexpected VM deployments, especially high-compute instances, check for this immediately.
💡 Investigator Note: Microsoft has published a mapping of its built-in Azure security controls against MITRE ATT&CK techniques covering 48 controls. It is a useful reference when scoping the defensive posture of a client environment.
Quick Reference: Azure Investigation Checklist
Before diving into any Azure investigation, run through this mental checklist:
Identify the tenant(s) involved — get the tenant ID and the associated domain
Enumerate all subscriptions — do not assume you have been granted access to all of them
Confirm your own permission level at each subscription — Owner is ideal
Check for management groups — if present, policies applied there affect everything below
Map out the resource groups — know which ones are relevant to the incident
For key accounts (compromised users, service principals), enumerate role assignments across all subscriptions
Old vs. New Terminology: What You Need to Know
Throughout Microsoft documentation you will still see the term Azure Active Directory (AAD) used extensively. In October 2023, Microsoft renamed Azure Active Directory to Microsoft Entra ID. The functionality is completely identical — only the name changed. In the Azure Portal, the service now appears as 'Microsoft Entra ID'. When searching for it or referencing it in KQL queries, be aware that log table names and field names may still use 'AAD' in some places depending on when they were created.
Understanding this architecture is not just background knowledge — it directly shapes where you look, what you ask for, and how you interpret what you find. In the next article, we will look at the four ways you can access Azure and, more importantly, what traces each access method leaves behind.
We will Continue in next article
--------------------------------------------------Dean----------------------------------------------------
Special Thanks
I would like to extend my heartfelt gratitude to one of my dearest friend, a Microsoft Certified Trainer, for her invaluable assistance in creating these articles. Without her support, this would not have been possible. Thank you so much for your time, expertise, and dedication!
-------------------------------------------------------------------------------------------------------------
