Spotting TA416: OAuth Consent Phishing & PlugX Registry Keys
It looks like TA416 (aka RedDelta) is back targeting European diplomatic entities after a relatively quiet couple of years. The latest report from The Hacker News highlights a renewed push using PlugX and, more concerningly, OAuth-based phishing vectors.
The OAuth angle is particularly tricky. Instead of harvesting credentials, they're tricking users into granting permissions to malicious apps. This bypasses standard MFA protections because the user is the MFA factor authorizing the app.
On the PlugX side, we often see registry persistence. Here is a quick PowerShell snippet to hunt for suspicious Run keys often associated with their variants:
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run\*", "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\*" | Where-Object { $_.PSObject.Properties.Name -match '^[a-f0-9]{32}$' -or $_.PSObject.Properties.Value -match 'rundll32.exe.*\.dll' }
For the OAuth side, visibility on Audit Logs is critical. We need to catch 'Consent to application' events from app IDs we don't recognize. This KQL query works well for Sentinel/Defender:
AuditLogs
| where OperationName == "Consent to application"
| extend AppId = tostring(TargetResources[0].ID)
| where AppId !in ("00000003-0000-0000-c000-000000000000") // Exclude standard Office
| project TimeGenerated, InitiatedBy, AppId, Result
How are you guys handling 'legitimate' OAuth requests in your environments? Are you blocking app registration entirely, or do you rely on audit alerts?
Solid KQL query. We've actually moved to a 'Zero Trust' model for OAuth by default. We require admin consent for any application registration unless the user is in a specific 'App Developer' security group. It broke some internal workflows initially, but it stopped the consent phishing dead in its tracks.
Don't forget that PlugX has been evolving beyond simple Run keys. In the last campaign I analyzed, they were using COM hijacking via the TreatAs registry key to maintain persistence under a signed binary context. You might want to expand your hunt to HKCR\CLSID as well.
Since OAuth phishing targets the user directly, local browser forensics can be your fastest indicator on compromised workstations before cloud logs ingest. Check Chrome or Edge history for recent login.microsoftonline.com/consent activity. You can automate this locally to catch users who approved malicious apps.
Here’s a quick PowerShell snippet to scan Chrome history for consent prompts:
Get-Content "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\History" -ErrorAction SilentlyContinue | Select-String "login.microsoftonline.com/consent"
Great insights on persistence. On the OAuth side, don't just rely on browser history; you need to catch the consent event in the cloud. Watching for high-risk permissions during the Consent to application operation is critical. This KQL query filters for dangerous grants like 'Directory.ReadWrite.All' or roles:
AuditLogs
| where OperationName == "Consent to application"
| extend Permissions = tostring(TargetResources[0].ModifiedProperties[3].NewValue)
| where Permissions contains "Role" or Permissions contains "Directory.Read"
Building on the OAuth risks, once access is granted, TA416 often uses the Microsoft Graph API to bypass traditional DLP controls. I recommend monitoring for anomalous volume in read operations like ListMessages or GetAttachment.
CloudAppEvents
| where ActionType in ("ListMessages", "GetAttachment")
| summarize Count=count() by Application, AccountObjectId
| where Count > 1000
Detecting the data movement phase is crucial if the initial consent event slips past your policies.
Great point on the Graph API abuse. To catch them immediately after the consent phase, you need to correlate the consent event with the automatic creation of a Service Principal. This happens milliseconds after the user clicks 'Accept'. I've been running this to cross-reference the initiator with the app publisher:
k union AuditLogs where OperationName in ("Consent to application", "Add service principal")
| extend AppName = TargetResources[0].displayName
| project TimeGenerated, OperationName, InitiatedBy, AppName, Result
It’s crucial to check if the InitiatedBy user matches the expected risk profile for that app.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access