Azure AD Incident Response Life Cycle and Process
The Azure AD Incident Response methodology is a critical life-cycle, process, and tool that anyone using identities on Azure, Office 365, and third-party clouds can count on. The Azure AD Incident Response explores how Azure AD investigates, manages, and responds to security breaches. It involves skill, knowledge, and experience to protect Azure AD. The five-stage process presented has evolved over the years and continues to do so.
This blog post is part of cloud incident response and brings helpful insight, tips, and experience from the field on my day-to-day IR.
Many organizations rely on the SaaS delivery model for cloud applications to manage essential business functions, including their Web App, OAuth apps, Communication, etc. Those apps are considered high-value targets by threat actors, as they can contain valuable data such as employee PII, supplier, client, and financial and business data.
Understanding the shared responsibility model for cloud apps is critical for organizations to develop an efficient strategy to respond to security incidents affecting their SaaS apps in the cloud. A significant platform is an identity.
For the SaaS delivery model, the customer is responsible for the security of the data, endpoint, account, access, and identity, while the other components are in the scope of the cloud service provider.
That means from an incident response perspective. You should plan a process to detect, monitor, and respond to security incidents affecting the app’s architecture components under their responsibility. You should also create a strategy to evaluate cloud service providers and ensure they can manage cyber security incidents in the scope of their responsibilities.
Azure AD IR Life Cycle
The diagram starts on the left with the beginning of the incident response, Prepare. The Prepare phase includes setting controls to prevent incidents on your Azure AD and connect apps and third-party cloud providers.
Next is Detect & Identify. The Discover, Determine, Decision, Actions loop begins during this time. Just because this cycle is only on this diagram once does not mean it will only be completed once during the detection phase of Incident Response. Every incident is different, meaning each incident should be treated independently.
Then, Contain and Eradicate. These phases of the life cycle usually take longer than expected. If one thing can be learned from Incident Response, setting a timeline or time limit on the amount of work put into these two phases is unpredictable.
Then, Recovery is next. Recovery is the process of implementing mitigations against the incident that has taken place and making sure that the threat is entirely eradicated.
Lessons Learned is the final step in the incident response Life Cycle, but this does not mean the tasks and findings end there. Be sure all individuals know where the cloud and identity environment made improvements and why those improvements will help protect in the future.
Notice how Lessons Learned links to the beginning of the Life Cycle diagram. There should be continuous feedback between the end of one incident and the possible start of another.
Now that the Azure AD Incident Response Life Cycle process has been reviewed, below you will find a diagram with the five most common incident response scenarios and how to Protect, Detect, and Respond to each identity scenario.
Azure AD, Security Controls, and other third-party cloud provider provides many logs, data, and information. Therefore, the logs can be part of the basic and advanced licenses in each situation. We can pull out the relevant findings from the logs and find the patient zero. The following logs are just the main logs for Microsoft 365.
Azure AD Logs
Azure AD logs can be accessed from the Azure portal under the Azure AD service. Azure AD Sign-in logs contain detailed information about how authentications occur and Microsoft 365 app usage. Azure AD audit logs are also a valuable source of information, including records of password resets, account creations, role modifications, OAuth grants, and more that could indicate suspicious activity.
Cloud App Security
Cloud App Security can be used to cover three core stages of the NIST 800-61 Incident Response Lifecycle and Detection, Analysis, and Containment when responding to unauthorized access activity. This allows improved performance by decreasing the time it takes to detect potential risk events, the time to analyze and classify security incidents, and the time to contain threats and prevent further damage.
Decreasing these time-consuming actions decreases the mean time to resolve an incident, improving overall security posture.
If the Audit Log Search feature is enabled, this supplemental data source logs all PowerShell administrative cmdlets executed by administrators. The PowerShell cmdlet Search-AdminAuditLog is used to query these logs, but note that the Audit Log Search feature must be enabled, and the same 90-day retention limit will be in place.
The audit logs provide you with records of system activities for compliance. This data enables you to address common scenarios such as:
- Someone in my tenant got access to an admin group. Who gave them access?
- Can you provide the list of users signing into a specific app since I recently onboarded it and see if it’s doing well?
- I want to know how many password resets are happening in my tenant.
TIP: If you suspect an administrator account was compromised, don’t overlook this log.
Office 365 Logs
This section will discuss a few logs containing forensic data relevant to an Office 365 investigation.
Before we can begin investigating an Office 365 case, we’ll work with an “Investigator” account provisioned with the roles required to obtain the forensic data we need. Still, during an active Managed Defense investigation.
Unified Audit Log – the Unified Audit Log (UAL) records activity from various applications within the Office 365 suite and can be considered Office 365 primary log source. To leverage this log source, ensure that the Audit Log Search feature is enabled. Entries in the UAL are stored in JSON format. It’s better to use the PowerShell cmdlet Search-UnifiedAuditLog to query the UAL.
UAL has a few nuances that are important to consider. While it provides a good high-level summary of activity across various Office 365 applications, it won’t log comprehensive mailbox activity. Moreover, UAL has a few limitations, namely:
- Provide 90-day log with activities
- Results to a single query are limited to 5000 results
- Events may take up to 24 hours before they are searchable
Mailbox Audit Log – The Mailbox Audit Log (MAL), part of Exchange Online, will capture additional actions performed against objects within a mailbox. As such, it’s a good idea to acquire and analyze the MAL for each affected user account with the PowerShell cmdlet Search-MailboxAuditLog.
Detect & Identify
Recognizing anomalies in your environment is key to effective incident response. A specific example may be detecting activity from abnormal geographic locations. If users in the US are logging in from China, you need to detect this anomaly and respond quickly.
Microsoft Cloud App Security improves detection by providing the following: Once audit logging is enabled, Cloud App Security offers deep visibility into your Office 365 activity and allows for comprehensive policy creation.
- Insight into all user activity
- Recognize third-party app usage
- Understanding of who has access to files/folders
- Recognize where sensitive data lives
- Out-of-the-box policies to recognize anomalous and suspicious activity
Once anomalies are detected, an assessment must occur to manage potential risks and plan your strategy for containment. You may also search for other activities from the suspicious source IP to check for abnormal behavior patterns, such as a high volume of downloads or creating an inbox rule to forward mail externally.
Cloud App Security provides all activity data and allows you to query further information about potential incidents for quick but in-depth analysis. You can easily view all activity performed by the compromised account during the breach and distinguish the authorized and unauthorized. This tool provides the following functionality to improve the estimation of security events:
- Easily create queries to search the activity log.
- Interactive Graphical User Interface to pivot and analyze
- Rich, valuable data included in alerts
- Check user access to recognize sensitive data at risk
- IP address information embedded in activity logs
Contain, Eradicate & Recover Actions
Once you have detected identity issues, you must respond immediately with the tools you’ve got and additional tools by the actions below:
- Audit service principal credentials, permissions, and reply URLs
- Audit conditional access rules
- Hunt for suspicious AD Sync account logins
- Hunt for modifications to conditional access rules
- Hunt for suspicious sign-ins by service principals
- Hunt for service principals accessing users’ mailboxes
Recover a compromised Azure AD Environment
- Reset all privileged accounts in Azure AD
- Reset all system accounts in Azure AD
- Reset all service endpoints in Azure AD
- Rotate all Apps Registration keys
- Rotate Azure Key Vaults
- Revoke refresh tokens issues for users
- Audit service principal credentials, principal permissions, and reply URLs
- Restricting access based on IP address ranges or type of user devices
With Hybrid Identity (Hybrid AD Scenario)
- AZUREADSSOACC account
- On-premises AD DS connector account
- Azure AD connector account
- On-premises ADSync Service Account
- Reset local accounts on DCs
- Kerberos ticket-granting ticket account twice
- Reset all service accounts
- Rotating secrets associated with remote access MFA token generation
The IR tools below are free and do not depend on the license you’ve got on your Microsoft 365 environment. The IR tools below are essential, and more IR tools can be used for cloud incident response and cloud forensics.
Sparrow – Azure/Microsoft 365 incident response tool
Sparrow is a PowerShell tool developed by CISA’s Cloud Forensics team to detect malicious activities, such as possibly compromised accounts and applications in the Azure or Microsoft Office 365 environment. The tool was developed due to the increased number of recent identity and authentication-based attacks on Azure and Microsoft Office 365 detected in multiple sectors.
The tool can be used by network security analysts and incident responders and focuses on modules specific to recent attacks on federated identity sources and applications. It works by identifying indicators of compromise (IoCs) associated with the recent attacks.
AzureHound uses the “Az” Azure PowerShell module and “The azure AD” PowerShell module for gathering data within Azure and Azure AD. If the modules are not installed, you can use the “-Install” switch to install them. The modules require PowerShell version 5.1 and are more significant. To check your PowerShell version, use “$PSVersionTable.PSVersion”.
The Hawk PowerShell module scans the Office 365 audit log, gathers all the information, and exports the audit log from Office 365. The main goal of Hawk is to retrieve data needed to review and analyze various logs quickly. With Hawk, you can export Office 365 audit logs, search Office 365 audit logs and parse whatever you need from the Office 365 administrator audit log.
The CRT is a free community tool that will help organizations quickly and easily review excessive permissions in their Azure AD environments to help determine configuration weaknesses and provide advice to mitigate this risk.
This tool queries the following configurations in the Azure AD, which can drop light on hard-to-find permissions and configuration settings to assist organizations in securing these environments.
The AzureADIncidentResponse uses Graph API under the hood to access data, so it starts with obtaining an API access token. Once the token has been received, we can call a resource, returning the data.
Azure Hacktive Directory blog posts – will be available soon