IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Port Forwarding Rule Addition Possible FIN7 DGA Command and Control Behavior »

› › ›

Possible Consent Grant Attack via Azure-Registered Application

edit

Possible Consent Grant Attack via Azure-Registered Application

edit

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

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide

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

edit

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

edit

Framework: MITRE ATT&CK^TM

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

« Port Forwarding Rule Addition Possible FIN7 DGA Command and Control Behavior »