T1671 Google Chronicle · YARA-L

Detect Cloud Application Integration in Google Chronicle

This detection identifies adversaries achieving persistence in SaaS environments by abusing OAuth application integrations. Attackers register malicious applications, hijack existing integrations, or consent to adversary-controlled apps from high-privileged accounts to maintain access even after account compromise or password resets. Detection focuses on anomalous OAuth consent grants, new application registrations, service principal creation, and permission escalation events in Microsoft 365, Azure AD/Entra ID, and Google Workspace environments. Particular attention is paid to admin consent grants for high-privilege scopes, application registrations from non-admin users, and OAuth grants that occur outside normal business workflows.

MITRE ATT&CK

Tactic
Persistence
Technique
T1671 Cloud Application Integration
Canonical reference
https://attack.mitre.org/techniques/T1671/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule detection_t1671 {
  meta:
    author = "Argus Detection Platform"
    description = "Detects Cloud Application Integration cloud activity - T1671"
    severity = "HIGH"
    mitre_attack = "T1671"
    reference = "https://attack.mitre.org/techniques/T1671/"

  events:
    $e.metadata.event_type = "USER_CHANGE"
    $e.principal.user.userid = $user
    $e.principal.ip = $source_ip
    $e.target.resource.name = $resource
    (
      re.regex($e.metadata.product_event_type, `(?i)(add|delete|consent|update|create)`) and
      not re.regex($e.principal.user.userid, `(?i)(service-|automation-|pipeline-)`)
    )

  condition:
    $e
}
high severity high confidence

Google Chronicle YARA-L 2.0 rule for detecting Cloud Application Integration (T1671). Uses Chronicle UDM event model to identify cloud application integration behaviors across endpoint and cloud telemetry.

Data Sources

Azure ADMicrosoft 365

Required Tables

USER_CHANGERESOURCE_CREATION

False Positives & Tuning

  • Legitimate IT administrators deploying enterprise applications that require admin consent for business-critical permissions
  • Productivity application onboarding during organizational rollouts (e.g., deploying a new CRM, ITSM, or HR integration)
  • Third-party security vendors requiring Mail.Read or Directory.Read.All for legitimate CASB, DLP, or threat protection services
Download portable Sigma rule (.yml)

Other platforms for T1671


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Register Malicious OAuth Application in Azure AD

    Expected signal: AuditLogs entries: OperationName='Add application' and OperationName='Add service principal' with the new App ID in TargetResources. OperationName='Add delegated permission grant' showing Graph API permission additions.

  2. Test 2Grant Admin Consent to Existing Application via PowerShell

    Expected signal: AuditLogs: OperationName='Add OAuth2PermissionGrant' with ConsentType='AllPrincipals' and Scope containing 'Mail.Read'. InitiatedBy will show the Global Administrator account. ResultType should be 'Success'.

  3. Test 3Add Client Secret to Existing Service Principal for Persistent API Access

    Expected signal: AuditLogs: OperationName='Add password to service principal' with the target App ID in TargetResources and the credential display name 'AtomicTest-PersistentSecret'. AADSignInLogs: Service principal sign-in using client_credentials grant type showing the App ID authenticating to Microsoft Graph.

Unlock Pro Content

Get the full detection package for T1671 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections