Description

An adversary may create an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website.

After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization.
Source: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide

This rule identifies when a user grants permissions to an Azure-registered application or when an administrator grants tenant-wide permissions to an application.

The screenshot below shows what it looks like when an application requests permissions.

The screenshot below shows what it looks like when an application requests permissions for an organization.

Query

event.module:azure and event.dataset:azure.activitylogs and event.category:Administrative and azure.activitylogs.operation_name:"Consent to application"

Required Info

• Eventing Sources:

filebeat-*

• Target Operating Systems:

• Platforms

Azure

• Target ECS Version: 1.5.0
• New fields required in ECS for this? No
• Related issues or PRs None

Optional Info

• References:
  • https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide
  • https://adsecurity.org/wp-content/uploads/2019/08/2019-BlackHat-US-Metcalf-Morowczynski-AttackingAndDefendingTheMicrosoftCloud.pdf

Example Data