Azure AD Incident Response Life-Cycle & Tools

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.

Shared Responsibility Model & 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 data, client data, 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 powerful 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 Process

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, you will find a diagram with the five most common incident response scenarios and how to Protect, Detect, and Respond to each identity scenario.

Main Logs

Azure AD, Security Controls, and other third-party cloud provider provides many logs, data, and information. Therefore, the logs can be part of each situation’s basic and advanced licenses. 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 apps 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 is 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.

The ability to decrease these time-consuming actions decreases the meantime to resolve an incident, which improves overall security posture.

Audit Log

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: Don’t overlook this log if you suspect an administrator account was compromised.

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 high-level summary of various Office 365 applications, it won’t log comprehensive mailbox activity. Moreover, UAL has a few limitations, namely:

• Provide a 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

Identifying 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 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:

Containment Actions

• 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

IR Tools

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 identity and authentication-based attacks on Azure and Microsoft Office 365 detected in multiple sectors recently.

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 “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.

Reference

Star the Azure AD Incident Response on GitHub

More security posts of Elli Shlomo

Azure security logging and auditing | Microsoft Docs