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

« Persistence via Update Orchestrator Service Hijack 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

Identifies 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-*

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

Added (Elastic Stack release): 7.10.0

Rule authors: Elastic

Rule license: Elastic License

Investigation guide

edit

The Azure Filebeat module must be enabled to use this rule.
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.

Rule query

edit

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

Threat mapping

edit

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Spearphishing Link
- ID: T1192
- Reference URL: https://attack.mitre.org/techniques/T1192/
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/

« Persistence via Update Orchestrator Service Hijack Possible FIN7 DGA Command and Control Behavior »