IMPORTANT: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
current release documentation.
Possible Consent Grant Attack via Azure-Registered Application
editPossible Consent Grant Attack via Azure-Registered Application
editDetects when a user grants permissions to an Azure-registered application or when an administrator grants tenant-wide permissions to an application. An adversary may create an Azure-registered application that requests access to data such as contact information, email, or documents.
Rule type: query
Rule indices:
- filebeat-*
- logs-azure*
Severity: medium
Risk score: 47
Runs every: 5 minutes
Searches indices from: now-25m (Date Math format, see also Additional look-back time
)
Maximum alerts per execution: 100
References:
Tags:
- Elastic
- Cloud
- Azure
- Continuous Monitoring
- SecOps
- Identity and Access
Version: 5 (version history)
Added (Elastic Stack release): 7.10.0
Last modified (Elastic Stack release): 7.13.0
Rule authors: Elastic
Rule license: Elastic License v2
Investigation guide
edit## Triage and analysis - In a consent grant attack, an attacker tricks an end user into granting a malicious application consent to access their data, usually via a phishing attack. After the malicious 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. - Security analysts should review the list of trusted applications for any suspicious items. ## Config The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
Rule query
editevent.dataset:(azure.activitylogs or azure.auditlogs or o365.audit) and ( azure.activitylogs.operation_name:"Consent to application" or azure.auditlogs.operation_name:"Consent to application" or o365.audit.Operation:"Consent to application." ) and event.outcome:(Success or success)
Threat mapping
editFramework: MITRE ATT&CKTM
-
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
-
Technique:
- Name: Phishing
- ID: T1566
- Reference URL: https://attack.mitre.org/techniques/T1566/
-
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
-
Technique:
- Name: Steal Application Access Token
- ID: T1528
- Reference URL: https://attack.mitre.org/techniques/T1528/
Rule version history
edit- Version 5 (7.13.0 release)
-
- Formatting only
- Version 4 (7.12.0 release)
-
- Formatting only
- Version 3 (7.11.2 release)
-
- Formatting only
- Version 2 (7.11.0 release)
-
-
Updated query, changed from:
event.dataset:(azure.activitylogs or azure.auditlogs) and ( azure.activitylogs.operation_name:"Consent to application" or azure.auditlogs.operation_name:"Consent to application" ) and event.outcome:success
-