Microsoft Azure is a vast ecosystem of cloud-based services and tools, offering almost limitless possibilities for building, managing, and scaling applications. But when it comes to incident response or forensic investigation, the Azure landscape can feel overwhelming. To make things clearer, let's focus on the essential elements you're most likely to encounter during such operations.
Understanding Azure's Structure: The Building Blocks
Think of Azure as a layered architecture, with each layer adding a distinct function that contributes to how an organization manages and controls its cloud resources. Here are the key components:
1. **Azure Tenant**
Picture the tenant as the foundation of a house—the basis for everything else. It represents the entire organization and is associated with an **Azure Active Directory (AAD)(Entra ID)** instance, which handles identity and access management. If you're responding to a security breach, this is where you'll likely start your investigation—analyzing user and group permissions in AAD to find any clues about unauthorized access.
2. **Management Groups**
In larger enterprises, it's common to have many different projects running across Azure, each with its own budget, team, and purpose. To keep things tidy, **management groups** help organize multiple subscriptions under a single umbrella.
For example, a company could have different management groups for its production and development environments. This setup lets administrators apply policies across all relevant subscriptions in one go—a time-saving feature that also helps standardize security practices.
**For Example**: Imagine you're investigating a security incident in a multinational corporation. You may find that production environments are more tightly controlled compared to development, thanks to separate management groups. This organization helps you narrow down where a misconfiguration or security hole might exist.
3. **Subscriptions**
Subscriptions are like folders within the cloud that help organize resources and manage billing. Each subscription can contain a collection of resources such as virtual machines, storage accounts, and databases. In a forensic investigation, this is where things get interesting because every subscription can have different access permissions.
**Key Point**: If you're investigating a security breach, ensure you have access to all relevant subscriptions because the compromised resource could be hidden within a subscription you're not initially granted access to.
4. **Resource Groups**
Moving deeper into Azure's structure, resource groups act as containers that hold related resources, such as virtual machines or storage accounts. For example, a company might group all resources related to a specific app in one resource group.
**Investigative Tip**: Sometimes, you’ll only get access to a single resource group rather than an entire subscription. In that case, your view of the infrastructure will be narrow, limiting your ability to see the bigger picture. Whenever possible, push for subscription-level access.
5. **Resources**
Finally, resources are the individual services and assets—virtual machines, networking components, storage accounts, and so on. They are the nuts and bolts of Azure, and they are also the focus of most investigations.
For example, if a virtual machine has been compromised, you'll need to scrutinize the VM, its associated storage, and network configurations to understand the breach.
-------------------------------------------------------------------------------------------------------------
### Subscriptions: The Power Behind Azure's Flexibility
Once your tenant is up and running, you’ll need to define one or more **subscriptions**. Each subscription is essentially a contract with Microsoft for cloud services, with charges accumulating based on usage. Large companies often set up multiple subscriptions to track different projects, which also helps them monitor costs across various departments or teams.
During an investigation, gaining access to the right subscription is crucial because that's where the resources live. Permissions at this level can make or break your ability to fully explore and analyze cloud infrastructure. It’s also worth noting that subscriptions come with limits—for example, the number of virtual CPUs (vCPUs) might be capped. If a breach involves a resource-heavy virtual machine, you may need to request a limit increase from Microsoft.
-------------------------------------------------------------------------------------------------------------
### Azure Resource Manager: The Conductor of the Cloud
Before diving into specifics like virtual networks or storage, it's essential to understand **Azure Resource Manager (ARM)**. Think of ARM as the brain behind all deployments in Azure. It provides a management layer, handling the creation, updating, and deletion of resources.
One of ARM's strengths is that it takes input from various interfaces—Azure Portal, PowerShell, CLI, or even REST APIs—and ensures consistency across them. It’s especially useful during a forensic investigation because you can use any of these tools to explore resource configurations or query logs.
ARM also supports templates, written in JSON, that allow resources to be deployed consistently. These templates serve as a record of how resources were deployed and configured, offering valuable information during an investigation.
For example, if a misconfigured virtual machine was deployed using an ARM template, you could identify that exact misconfiguration and track how it might have contributed to a breach.
-------------------------------------------------------------------------------------------------------------
Why Resource Groups Matter for Incident Response
From an incident response and forensic investigation perspective, understanding resource groups is essential. Often, the resources involved in an attack or breach will be grouped together under a specific resource group, allowing you to track and manage them collectively.
For example:
Ease of Management: If an attacker compromises several virtual machines within a resource group, you can manage, update, or even delete all the compromised resources in one go by targeting the resource group.
Access Control: Role-based access control (RBAC) can be set at the resource group level. This means that permissions for an entire group of resources can be managed centrally, making it easier to ensure that only authorized users have access.
However, one potential challenge is that during investigations, you might only be granted access to a specific resource group rather than the entire subscription. While this can be helpful for isolating resources, it limits your view of the full Azure environment. If you're only granted permissions for one resource group, you could miss key elements or additional compromised resources in other parts of the subscription. Always aim to request higher-level permissions for a complete view during an investigation.
-------------------------------------------------------------------------------------------------------------
Azure Resource Providers: The Backend Support
Each resource in Azure is managed by a resource provider, which is a service responsible for provisioning, managing, and configuring the resources. For example:
To deploy a virtual machine, Azure uses the Microsoft.Compute resource provider.
For a storage account, the Microsoft.Storage resource provider is used.
When performing investigations or responding to incidents, you won't directly interact with resource providers most of the time. However, understanding that they operate in the background helps you track what services are involved when examining Azure Resource Manager (ARM) templates or logs.
-------------------------------------------------------------------------------------------------------------
Key Azure Services for Incident Response and Forensics
For forensic investigations and incident response, there are certain Azure products you’re likely to interact with the most:
Identity and Access Management:
Azure Active Directory (AAD)/Entra ID: Controls identity and access management, a key area to investigate when tracking how a threat actor gained access to a compromised account or service.
Networking:
Virtual Networks (VNet): Helps isolate resources and control network traffic.
Network Security Groups (NSGs): Filters network traffic, which can help track network traffic anomalies during an incident.
Compute:
Virtual Machines (VMs): Key investigation targets in cases of compromised systems. Both Linux and Windows VMs are supported.
Azure Functions: Provides compute-on-demand and could be abused by attackers for running scripts in a serverless environment.
Storage:
Disk Storage: Persistent storage for VMs. Investigators might need to examine disk snapshots or backups to analyze compromised systems.
Blob Storage: REST-based object storage for storing unstructured data, which can be a target for data exfiltration.
Storage Explorer: A graphical tool for viewing and interacting with Azure storage resources, useful for accessing storage data during investigations.
Analytics:
Log Analytics: Allows you to collect and search through logs, essential for tracking suspicious activity across resources.
Azure Sentinel: A cloud-native SIEM (Security Information and Event Management) platform, which aggregates data from across the environment and uses intelligent analytics to identify and respond to potential threats.
-------------------------------------------------------------------------------------------------------------
Resource Identification in Azure: Understanding Resource IDs
Azure resources are uniquely identified using a Universal Resource Identifier (URI). This format helps trace individual resources and track their relationships within the Azure environment, which is critical during incident response.
A typical resource URI follows this structure:
/subscription/<SubscriptionId>/resourceGroups/<resourceGroupName>/providers/<providerName>/<resourceType>/<resourceName>
SubscriptionId: The globally unique identifier for the subscription.
resourceGroups: The user-generated name of the resource group.
providerName: The resource provider responsible for managing that resource (e.g., Microsoft.Compute for VMs).
resourceType: The type of resource (e.g., virtualMachines).
resourceName: The specific name of the resource.
For example, in the case of a virtual machine named "MiningVM":
The resource ID might include URIs for the VM itself, the operating system (OS) disk, the network interface, and even a public IP address (if assigned). Investigators can use these URIs to track and manage each component of a compromised resoure
-------------------------------------------------------------------------------------------------------------
### Investigating Identity and Access: Role-Based Access Control (RBAC)
Azure’s **Role-Based Access Control (RBAC)** is like a security guard at the gates of every resource. It defines who has access to what and what they can do with it—read, write, or delete. During an investigation, understanding RBAC is critical because you’ll need to know who had access to a compromised resource and whether their access was appropriate.
For instance, each resource in Azure has a **scope**, which could be at the level of a management group, subscription, or resource group. A role assignment defines who (user or service account) can do what (role definition) within that scope. The most common roles are **Owner**, **Contributor**, and **Reader**, but custom roles can be created as well.
Imagine you’re looking into an incident where sensitive data was leaked from a storage account.
By examining RBAC, you might discover that a developer had unnecessary write access to the account, or that a third-party contractor was given too much control over key resources.
-------------------------------------------------------------------------------------------------------------
### Real-World Example: Tracing an Azure Security Breach
Let’s put it all together with a simple example. Suppose a virtual machine (VM) in your Azure environment was hacked. You start your investigation by looking into the **subscription** where the VM resides. First, you check **Azure Resource Manager** to view the deployment history of the VM. By examining the **ARM template**, you see that the VM was configured with an outdated operating system, which may have been the entry point for the attacker.
Next, you use **RBAC** to review who had access to the resource group containing the VM. You discover that a former employee still had **Owner** access, which allowed them to modify settings and potentially introduce vulnerabilities.
Finally, you dive into **Log Analytics** to trace the attacker’s movements through the VM’s logs, giving you a clear picture of how the breach occurred.
-------------------------------------------------------------------------------------------------------------
When it comes to managing user access in Microsoft Azure, especially during investigations, things can get complicated quickly. Azure uses Role-Based Access Control (RBAC), which defines who has access to what resources and what they can do with those resources. The challenge comes when a user’s permissions are scattered across multiple subscriptions and resource groups. Administrators often need to enumerate role assignments to fully understand a user’s level of access. Here’s how that can be achieved using Azure's tools.
Listing User Role Assignments: Azure CLI and PowerShell
The Azure CLI and PowerShell provide the most efficient ways to list user role assignments across different levels of Azure resources.
Using Azure CLI to List Role Assignments
The Azure CLI allows you to enumerate role assignments by issuing a command to list all the roles a user has across resources. The steps are:
Select the appropriate subscription:
First, make sure you’ve selected the subscription that holds the resources you're investigating:
az account set --subscription "subscription_name_or_id"List role assignments:
Use the az role assignment list command to list all role assignments for a specific user within that subscription. The key parameters here are --all to search recursively and --assignee to specify the user.
az role assignment list --all --assignee "user_email_or_id"This will list the user’s roles at both the subscription and resource group levels. If they have owner-level access to a specific resource group but no broader subscription access, this command will reveal that.
Using PowerShell to List Role Assignments
Similarly, you can achieve the same results using PowerShell with the
Get-AzRoleAssignment command.
Install and set up Azure PowerShell:If you haven't already, install the Azure PowerShell module
Install-Module -Name Az -AllowClobberAuthenticate and select the subscription:
Authenticate with your Azure account and choose the correct subscription.
Connect-AzAccountSelect-AzSubscription -SubscriptionId "subscription_id"List role assignments for the user:
Use the following command to list role assignments:
Get-AzRoleAssignment -ObjectId (Get-AzADUser -UserPrincipalName "user_email").IdThis will return all roles assigned to the user, including those at the subscription or resource group level.
Why This Matters for Investigations
In cases where a security incident or breach is being investigated, it’s critical to understand who had access to what. For example, a user might not have direct access to a subscription but could hold Owner permissions at a specific resource group or even an individual resource level, which could lead to security loopholes.
If the user has elevated permissions—such as Owner or Contributor—on critical resources, this could be an entry point for an attacker to escalate their control over the environment. Listing all role assignments helps pinpoint misconfigurations or excessive access that might have been leveraged during an attack.
-------------------------------------------------------------------------------------------------------------
MITRE ATT&CK® and Azure: Understanding Threat Actor Behavior
The MITRE ATT&CK® framework provides an extensive matrix of tactics and techniques that threat actors commonly use when attacking cloud platforms like Azure. For instance, attackers frequently aim to:
Obtain and verify credentials: Attackers often exploit legacy protocols like IMAP, which lack strong security measures. Enforcing multi-factor authentication (MFA) and disabling legacy protocols are essential to mitigate these risks.
Exfiltrate data via storage accounts: Attackers might abuse Azure’s Blob Storage or use the Microsoft Graph API to access and extract sensitive information.
The MITRE ATT&CK framework has detailed mappings for Office 365, Azure AD, and other Azure services, which makes it easier to correlate specific threat tactics with your security controls. Microsoft has even mapped its built-in Azure security controls against MITRE ATT&CK to create a library of 48 potential defenses.
You can explore Azure security mappings here:
-------------------------------------------------------------------------------------------------------------
Accessing Azure: CLI, Portal, PowerShell, and Graph API
There are four primary ways to interact with Azure during your investigation or daily operations:
Azure Portal: The graphical interface for viewing and managing Azure resources.
Azure CLI: A command-line interface for automating resource management.
PowerShell: Ideal for Windows users who prefer scripting in PowerShell to manage Azure.
Microsoft Graph API: A RESTful API that allows programmatic access to Azure services, providing deep integration into apps and custom tools.
The Azure CLI and PowerShell options are especially important for large-scale environments where running commands on the fly is necessary to quickly retrieve information. Cloud Shell—a terminal within the Azure Portal—also provides
access to these tools without needing local installations.
Investigating Cloud Shell: Bash vs PowerShell Artifacts
An interesting point to consider during an investigation is whether the attacker used Cloud Shell for their activities. When a user initiates a Cloud Shell session, a storage account is automatically created to store the environment.
If Bash was used, traditional Linux forensics can be applied, such as analyzing the .bash_history file to see the commands issued by the user.
However, there’s a limitation: PowerShell Cloud Shell leaves fewer artifacts. While the underlying actions will still be logged (e.g., through Azure Audit Logs), direct forensics from PowerShell Cloud Shell is limited.
Conclusion
Effectively managing and investigating user access in Azure requires understanding the nuances of role assignments across different subscriptions and resources. Tools like Azure CLI and PowerShell make it easier to enumerate these roles, while frameworks like MITRE ATT&CK® provide insight into threat actor behavior in cloud environments. The right combination of access control, security controls, and investigative tools can significantly enhance your incident response capabilities in Azure.
Akash Patel
Comments