Defending Azure Active Directory (Entra ID): Unveiling Threats through Hunting Techniques

Azure Active Directory (Entra ID) stands as one of the most popular and widely-used cloud-based identity and access management services provided by Microsoft. It serves as a comprehensive solution for managing user identities and controlling access to a diverse range of resources, both within the Microsoft Azure ecosystem and across other platforms. Azure AD offers crucial features like single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), and directory services. 

Understanding  Azure AD logs is essential for maintaining a robust security posture in a cloud-centric environment. These logs provide a comprehensive record of user activities, authentication attempts, and access permissions. By analyzing Azure AD logs, organizations can detect and respond to suspicious or unauthorized activities promptly, identify security threats, track user behavior, and ensure compliance with regulatory requirements. Understanding these logs is pivotal in proactively mitigating security risks, protecting sensitive data, and safeguarding the integrity of Azure-based services, making it a fundamental aspect of any effective cybersecurity strategy in the cloud.

Reading this blog will provide you with:

• Understanding of the logs that can be extracted from your Azure AD, and how.
• Knowledge about how to analyze these logs, and get the right information out of them.
• Learning about more than 10 Threat scenarios and corresponding hunting queries that you can run in your own environment to identify threats.
• Access to a tool Rezonate wrote to extract logs from AzureAD to any preferred analysis platform of your choice.

Azure Active Directory Log Sources

Azure Active Directory (Azure AD) offers two log sources that capture different types of events and activities within the Azure AD environment. These logs provide valuable insights for monitoring, security, and compliance purposes:

1. Sign-in Logs: capture information about user sign-ins, including successful and failed attempts, sign-in locations, device details, and authentication methods used.
2. Directory Audit Logs: capture information about various administrative activities, such as changes to user accounts, group memberships, application access, role assignments, and permission modifications.

Data retention settings for the different licensing levels can be found here.

Azure AD Sign-in Logs

Azure AD sign-in logs are records that capture information about user sign-in activities within the Azure Active Directory (Azure AD) environment. These logs provide insights into the authentication and access activities of users as they interact with Azure AD-integrated applications and services. Sign-in logs are a crucial component of monitoring and maintaining the security of an organization’s identity and access management infrastructure. The full structure of the sign-in logs can be found on Microsoft’s official reference page. Every data-point  in the log record could be useful in certain use cases, but we highlighted some of them  that you should focus on for most investigations and hunting scenarios:

Sign-in logs are separated into four groups:

• Interactive sign-in: Interactive sign-ins occur when a user logs in using a web browser, a mobile app, or another client application, and the user directly interacts with the authentication prompts. 
• Non-interactive sign-ins: These logs typically involve automated processes, such as service accounts, background tasks, or system-to-system interactions, where user intervention is not necessary for authentication to occur.
• Service principal sign-ins:  A service principal is a security identity used by applications, services, or automation tasks to access Azure resources and perform specific actions. Service principal sign-ins occur when these identities are used to authenticate and access resources or services.
• Managed identity sign-ins: A managed identity is a feature in Azure that provides an identity for resources like virtual machines, Azure services, and applications. This identity can be used to authenticate with various Azure services without requiring explicit credential management.

Managed identity sign-ins occur when resources or applications use their managed identity to authenticate and access other Azure services, APIs, or resources.

Azure AD Directory Audit Logs

Azure AD directory audit logs are records that capture details about administrative activities and changes within an Azure Active Directory (Azure AD) environment. These logs provide insights into actions taken by administrators or privileged users that impact user identities, groups, roles, and directory settings.

Directory audit logs are essential for maintaining security, compliance, and accountability within an organization’s identity and access management infrastructure. These logs help track changes, monitor user activities, and investigate potential security incidents.

The structure of the audit logs can be found on Microsoft’s official reference page.

Each data point in this log could be useful but we highlighted some of them that you should focus on for most investigations and hunting scenarios:

Exporting Azure AD Logs

Exporting  Azure AD  logs requires one of the following roles:

• Reports Reader
• Security Reader
• Security Administrator
• Global Reader
• Global Administrator

There are two primary approaches to accessing Azure AD logs.

1. Azure AD Console:

In the monitoring section, you will find both “Sign-in Logs” and “Audit logs”.

1. Login to Azure Portal
2. From the Azure Services, select Azure Active Directory
3. From the left pane, navigate to the “Monitoring” section

Each sign-in event, of an interactive user, is displayed as a single event and can be expanded to view more detailed information:

The tree remaining sign-in log groups are displayed differently. Instead of showing each sign-in attempt in a single event, the sign-in events are grouped by the target application that the user signed into:

2. Exporting The Logs To CSV\JSON

While accessing the Azure AD logs from the Azure portal is easy, it is recommended to export the logs out of  Azure AD  so you will be able to cross reference Azure AD activity with other data sources and perform advanced queries and analyze it in scale.

To export logs from Azure AD, we recommend using an Azure AD application and Microsoft Graph API. Follow the instructions below to create a new application for logs export in your tenant:

1. Sign in to the Azure portal using your administrator account.
2. From the Azure services, choose Azure Active Directory.
3. From the left pane, choose App Registrations
4. Click on “New Registration”.
5. Name it as you wish.
6. In “Supported account types” select  “Accounts in this organizational directory only (Default Directory only – Single tenant)”.
7. Click Register.
8. In the newly created application page, from the left pane, choose API Permissions.
9. Click on Add permission.
10. Click on Microsoft Graph – Application Permissions.
11. Type “AuditLog” in the search box.
12. Click on “AuditLog.Read.All”, and then “Add permissions”.
13. Grant admin consent for the default directory – In other words, allow the application to use the assigned privileges.
14. From the left pane, choose “Certificates and Secrets”
15. Click on “New client secret”
16. Choose your desired expiration date.
17. Use the new secret to authenticate to Azure AD and query your logs.

Let the Hunt Begin

In this section, we will guide you through some of the top-relevant threat scenarios to look out for, explain them, mark the Relevant Azure AD Event Sources, align to the specific MITRE ATT&CK technique, and include our own queries in Postgres query syntax.

Scenario 1 – Brute Force on an Azure AD User

A brute force attack on an Azure AD user involves an attacker repeatedly trying different passwords to guess correctly and eventually gaining unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than X failed login attempts on at least Y target user, failing or ending up with a successful login. In cases of failure, the activity may result in a user’s lockage. (Read more about Microsoft’s Smart Lockout protection mechanism)

Relevant Azure AD Event Source

• Azure AD Sign-In Logs

Query

-- Get users who failed to login from the same IP address at least 5 times
SELECT "userPrincipalName", "ipAddress" , "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event"
FROM sign_in_activity_azure_ad_entity siaaae
WHERE "errorCode" = 50126 -- Error code for invalid credentials
AND "createdDateTime" > now() - interval 'X hours'
GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent"
having count(id) >= 5
ORDER BY "eventCount" desc

MITRE Technique

• Credential Access | Brute Force | ATT&CK T1110 

Attention: The user-agent field in authentication logs indicates the client application employed for the authentication process. To bypass modern authentication requirements like Multi-Factor Authentication (MFA), threat actors might exploit legacy authentication protocols such as SMTP. In cases where a legacy protocol is utilized for authentication, the user agent in the logs will be identified as ‘BAV2ROPC’.

In case you encounter a brute force attempt with the user agent set to ‘BAV2ROPC’, it is crucial to consider it as malicious unless proven otherwise.

Scenario 2 – Password Spray on an Azure AD Account

A password spray attack on an Azure AD account involves an attacker repeatedly submitting different usernames with the same password (a small set of passwords) to eventually manage to log in and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than 1 failed login attempt on at least Y unique target user, from the same IP address.

Relevant Azure AD Event Source

• Azure AD Sign-In Logs

Query

-- Get users who failed to login from the same IP address to at least 5 unique users
SELECT "ipAddress", "appDisplayName", "userAgent", count(distinct "userPrincipalName") as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event"
FROM sign_in_activity_azure_ad_entity siaaae
WHERE "errorCode" = 50126 -- Error code for invalid credentials
AND "createdDateTime" > now() - interval '1000 hours'
GROUP BY "ipAddress", "appDisplayName", "userAgent"
having count(id) >= 5
ORDER BY "eventCount" desc

-- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time

MITRE Technique

• Credential Access | Brute Force | ATT&CK T1110

Scenario 3 – Multiple User Lockouts

In certain instances of brute force attacks, the malicious actor may lock out the targeted users during their unauthorized access attempts. To identify such scenarios, we can employ a detection method that involves searching for multiple user lockouts originating from a single IP address.

Relevant Azure AD Event Source

• Azure AD Sign-In Logs

Query

-- Search for login attempts to disabled users
SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event"
FROM sign_in_activity_azure_ad_entity 
WHERE "errorCode" = 50053 -- Error code for user locked out
AND "createdDateTime" > now() - interval 'X hours'
GROUP BY "ipAddress", "appDisplayName", "userAgent"
having count(distinct "userPrincipalName")  >= 5
ORDER BY "userCount" desc

MITRE Technique

• Credential Access | Brute Force | ATT&CK T1110 

Scenario 4 – Multiple Authentication Failures During MFA Challenge

An attacker that managed to compromise a credential set of an AzureAD user that is protected by MFA, upon authentication, will generate a specific sign-in log with the error code 500121 which correlates with the following message: “The user didn’t complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or have an issue with their authentication setup.”

We can highlight suspicious IP addresses that generated multiple events with the mentioned error code. 

Relevant Azure AD Event Source

• Azure AD Sign-In Logs

Query

-- Search for failed authentication attempts during MFA challenges 
SELECT "userPrincipalName", "ipAddress", "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event"
FROM sign_in_activity_azure_ad_entity siaaae
WHERE "errorCode" in 500121 -- Error code for no MFA response
AND "createdDateTime" > now() - interval '2000 hours'
GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent"
having count(id) > 1
ORDER BY "eventCount" desc

MITRE Technique

• Credential Access | Brute Force | ATT&CK T1110 

Scenario 5 – Authentication Attempt to a Disabled User

 In some cases, Azure AD user accounts might have been disabled due to security concerns, or maybe even as part of employee off-boarding. Monitoring login attempts to disabled users can help you detect unauthorized activities.

Relevant Azure AD Event Source

• Azure AD Sign-In Logs

Query

-- Search for login attempts to disabled users
SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event"
FROM sign_in_activity_azure_ad_entity 
WHERE "errorCode" = 50057 -- Error code for user disabled
--AND "createdDateTime" > now() - interval 'X hours' - optional filter
GROUP BY "ipAddress", "appDisplayName", "userAgent"
ORDER BY "userCount" desc

MITRE Technique

• Credential Access | Brute Force | ATT&CK T1110 

Scenario 6 – Suspicious User Consent to Application

When an attacker gains access to an Azure AD Tenant, they can create a new multi-tenant application equipped with specific API permissions such as Mail.Read, Mail.Send, Mailboxsettings.ReadWrite, Files.ReadWrite.All and User.ReadBasic.All, of which do not require administrative consent.

Next, the attacker invites external users (potential victims) to use this application. Upon the first login by a new user to the attacker’s application, a “Consent” prompt appears. If the user grants consent to the application, it enables the application to perform actions on behalf of the user, potentially leading to unauthorized access and misuse of the user’s data and resources.

We can utilize non-administrative consents to detect privileged applications that have access to user data.

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Search for non-administrative application consent 
select id,dn,"newValue" 
from (select id, jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' as "dn", 	  jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newValue"
	  from directory_audit_activity_azure_ad_entity daaaae 
	  where "activityDisplayName"='Consent to application') as subsearch 
where dn='ConsentContext.IsAdminConsent' and "newValue"='"False"'

MITRE Technique

• Initial Access | User Consent | ATT&CK T1204 

Scenario 7 – Persistence Via Service Principal Credentials

An attacker could establish a persistence mechanism by adding new credentials to an already existing Azure AD application if one of the following applies to them:

1. Application Administrator
2.  Global Administrator (GA) 
3. microsoft.directory/applications/credentials/update

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Search new application credentials events
SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", count("oldVals") AS "oldValsCount", count("newVals") AS "newValsCount" 
FROM (
	SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", jsonb_array_elements("oldVal"::jsonb) AS "oldVals",jsonb_array_elements("newVal"::jsonb) AS "newVals" 
	FROM (
		SELECT "id", "initiatedBy"->'user'->>'ipAddress' AS "ip", "initiatedBy"->'user'->>'userPrincipalName' AS "user", "activityDateTime", "activityDisplayName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' AS "property", 
jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' AS "oldVal", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' AS "newVal"
		FROM directory_audit_activity_azure_ad_entity 
		WHERE "activityDisplayName" = 'Update application – Certificates AND secrets management ' 
	) AS subquery
	WHERE "oldVal"!='[]' and "oldVal" is not null) AS query
GROUP BY "id","user","ip", "activityDateTime", "activityDisplayName", "property"
HAVING count("newVals")> count("oldVals")

MITRE Technique

• Persistence | Additional Credentials | ATT&CK T1098

Scenario 8 – Admin Privileges Assignments Not Via PIM

Azure AD PIM (Azure Active Directory Privileged Identity Management) is a Microsoft Azure service that helps organizations manage, control, and monitor access to privileged roles and resources in their Azure environment. It allows administrators to grant just-in-time privileged access, enforce approval workflows, and provide auditing and reporting for enhanced security and compliance.
It is important to monitor Azure AD admin privileges assignments, not through PIM, since this behavior should not be common, and might suggest that an admin account is compromised.

Relevant Azure AD Event Source 

• Azure AD Directory Audit Logs

Query

-- Search AAD administrative privileges assignment not via PIM
select "ipAddress", "initiatedUser",category,"operationType", "targetResourceType", coalesce("targetUser","targetApp") as "targetDisplayName", ass3."value" as "newRoleName"
from (select "id","ipAddress","userPrincipalName" as "initiatedUser",category,"operationType","TR"->'type' as "targetResourceType",
          nullif("TR"->'userPrincipalName', 'null') as "targetUser", nullif("TR"->'displayName', 'null') as "targetApp"
          from directory_audit_activity_azure_ad_entity daaaae , jsonb_array_elements("targetResources") as "TR"
          where category='RoleManagement' and "operationType" ='Assign'
          and "targetResources"::text like '%dmin%'
          and ("initiatedBy"->'app'->>'displayName' != 'MS-PIM' or "initiatedBy"->'user' is not null)) bq,
          (select * from (select "id",jsonb_array_elements("sub")->>'newValue' as "value", jsonb_array_elements("sub")->>'displayName' as "valueName" from (select "id",jsonb_array_elements("targetResources")->'modifiedProperties' as "sub" from directory_audit_activity_azure_ad_entity
                                where category='RoleManagement' and "operationType" ='Assign') base1) base2
          where "valueName" = 'Role.DisplayName') as base3
where bq."id" = ass3."id" and "targetResourceType"!='"Role"'

MITRE Technique

• Privilege Escalation | Privilege Assignment via Valid Account | ATT&CK T1078

Scenario 9 – Account Hijacking

Social engineering for initial access is on the rise. These techniques are simple in most cases and do not require much technical knowledge. Attacks such as phishing, MFA relay, or even buying credentials online may help attackers compromise user accounts.
Usually, when an adversary compromises a user, gaining persistent access to that account is important. To do so, the adversary might change the user’s password and enroll a new MFA device. In some cases maybe even delete the original user’s factors.
The following query identifies user accounts that performed a series of actions from an IP address that is not being used often by the organization, and during a short period of time – which might suggest that these accounts are compromised. The actions that this query searches for are:

• Self-password reset
• MFA enrollment
• MFA deletion 

Relevant Azure AD Event Source 

• Azure AD Directory Audit Logs
• Azure AD Sign-In Logs

Query

-- Search multiple security information changes from a rare location in a short timeframe
select * from(with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion"
                                FROM (
                                        SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount",  "ipAddress","countryOrRegion"
                                        FROM sign_in_activity_azure_ad_entity
                                        WHERE "errorCode" = 0
                                        AND "createdDateTime" > now() -interval '1 week'
                                        GROUP BY TimeBucket, "ipAddress", "countryOrRegion"
                                        HAVING COUNT(distinct "userPrincipalName") > 1
                                        ) subquery
                                GROUP BY "ipAddress","countryOrRegion"
                                HAVING count("timebucket") > 1)
select count(distinct "activityDisplayName") as distinct_event_count, min("activityDateTime") as first_event, max("activityDateTime") as last_event, daaaae."ipAddress",
"userPrincipalName",array_agg(distinct "activityDisplayName") as events, "result",
age(max("activityDateTime"),min("activityDateTime")) as duration,
extract(EPOCH FROM max("activityDateTime")) - extract(epoch from min("activityDateTime")) as duration_epoch
from directory_audit_activity_azure_ad_entity daaaae , org_ips
where "activityDisplayName" in ('Reset password (self-service)', 
'Self-service password reset flow activity progress', 
'User deleted security info', 'User registered security info', 
'User started security info registration') 
and daaaae."ipAddress" not in (select distinct org_ips."ipAddress" from org_ips)
and "result"='success'
group by "userPrincipalName",daaaae."ipAddress", "result") base
where distinct_event_count = 5 and duration_epoch <= 604800 

MITRE Technique

• Initial Access | Social Engineering and Phishing | ATT&CK T1566

Scenario 10 – Abusing Third-Party Users (Supply Chain Attack)

Many Azure AD tenants are trusted by third-party accounts – IT providers, security tools, or maybe trusted partners. Third-party accounts should perform directory changes only if the activity is authorized by the tenant administrator. Use the following query to detect changes performed by guest accounts in your organization. Unauthorized activities may suggest that the third-party account is compromised 

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Guest directory changes
select daaaae."activityDateTime", daaaae."ipAddress", daaaae."userPrincipalName", daaaae."activityDisplayName", daaaae."result", jsonb_array_elements(daaaae."targetResources")->>'userPrincipalName' as "external_user_name", siaaae."homeTenantId", siaaae."resourceTenantId" 
from directory_audit_activity_azure_ad_entity daaaae, sign_in_activity_azure_ad_entity siaaae  
where "result" ='success'
and daaaae."correlationId" = siaaae."correlationId"
and siaaae."homeTenantId" is not null
and siaaae."homeTenantId"!=siaaae."resourceTenantId" 

MITRE Technique

• Execution | Trust Relationships | ATT&CK T1566

Scenario 11 – Abusing Single Password Authentication

Single-factor authentication is a security risk that is best avoided by enforcing MFA, but it is not always possible to do so. Adversaries will often try to abuse users that are not protected by MFA. Use the following query to monitor single-factor authentication from non-organizational IP addresses.

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Guest invites
with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion"
                                FROM (
                                        SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount",  "ipAddress","countryOrRegion"
                                        FROM sign_in_activity_azure_ad_entity
                                        WHERE "errorCode" = 0
                                        AND "createdDateTime" > now() -interval '1 week'
                                        GROUP BY TimeBucket, "ipAddress", "countryOrRegion"
                                        HAVING COUNT(distinct "userPrincipalName") > 1
                                        ) subquery
                                GROUP BY "ipAddress","countryOrRegion"
                                HAVING count("timebucket") > 1)
select "createdDateTime", "ipAddress", "autonomousSystemNumber", "countryOrRegion", "userPrincipalName" , "appDisplayName", "conditionalAccessStatus" from sign_in_activity_azure_ad_entity siaaae 
where "authenticationRequirement" ='singleFactorAuthentication' 
and "errorCode" = 0 
and "isInteractive" = true
and "ipAddress" not in (select distinct "ipAddress" from org_ips)
and "countryOrRegion" not in (select distinct "countryOrRegion" from org_ips)

MITRE Technique

• Initial Access | Valid Cloud Account | ATT&CK T1078.004

Scenario 12 – Azure AD Sync Abuse

Azure AD Connect is a Microsoft tool that enables synchronization and integration between on-premises Active Directory (AD) and Azure Active Directory (Azure AD). It allows organizations to extend their on-premises identity infrastructure to the cloud, providing users with a seamless single sign-on experience across both environments. 

AAD Connect synchronizes user accounts between on-premises domain controllers and AAD tenants, utilizing a privileged user account authorized to update to the AAD directory.

A compromised domain controller could allow an attacker to move laterally to Azure AD by extracting the login credentials of an AAD Connect user. 

Relevant Azure AD Event Source 

• Azure AD Directory Sign-In Logs

Query

-- Search AAD Connect user abuse
select "createdDateTime", "ipAddress", "countryOrRegion", "userPrincipalName", "appId","appDisplayName", "errorCode"  from sign_in_activity_azure_ad_entity siaaae where "userPrincipalName" ilike 'Sync_%'
and "appDisplayName" not in ('Microsoft Azure Active Directory Connect','')

MITRE Technique

• Initial Access | Valid Cloud Account | ATT&CK T1078.004

3 Additional Queries For Azure AD Access Governance

On top of the scenarios mentioned above, there are additional relevant queries that can be used to hunt for threats in an Azure AD tenant. Their results are harder to rely on since they require having a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of an actual threat.

For example, a user was assigned an administrative role. It could be malicious or legitimate, and requires triage for a verdict: 

• Who performed the action?
• Is this the first time this actor assigns privileges? 
• Are there any client characteristics that do not make sense coming from that actor?

Query 1 – New Application Creation

Malicious applications can serve adversaries to get their first foothold in an Azure AD tenant. Review the installed applications that were installed by administrators.

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Search for new AAD applications
select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'displayName' as "appName"  from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Add application'

MITRE Technique

• https://attack.mitre.org/techniques/T1204/

Query 2 – A Guest Was Invited to the Organization

Guest users can be invited to an Azure AD tenant – This means that users from different Azure AD tenants can access your tenant. It’s important to review these invites to make sure that only authorized third-party users will be invited.

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Guest invites
select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'userPrincipalName' as "external_user_name"  
from directory_audit_activity_azure_ad_entity daaaae 
where "activityDisplayName" ='Invite external user'

MITRE Technique

• https://attack.mitre.org/techniques/T1199/

Query 3 – New Authentication Policy Exclusion

Azure AD Conditional Access Policy is a powerful feature that controls access to the organization based on specific criteria. If a user or a group of users are excluded from a conditional policy, they might put the organization at risk.

Relevant Azure AD Event Source

• Azure AD Directory Audit Logs

Query

-- Policy Exclusions
select "activityDateTime", "userPrincipalName", category, "activityDisplayName", "operationType",jsonb_array_elements("targetResources")->>'displayName' as "policyName",
jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newConditions",
jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' as "oldConditions"
from directory_audit_activity_azure_ad_entity daaaae 
where "activityDisplayName"='Update conditional access policy'

MITRE Technique

• https://attack.mitre.org/techniques/T1556/

Rezonate Tool For Exporting Azure AD Logs

As promised, we have included 2 tools that can be used to accelerate the application creation and the log extraction process. They are both available in our GitHub repository.