TA416 (RedDelta) Returns to EU: PlugX Persistence & OAuth Consent Phishing
Has anyone else been tracking the latest TA416 activity popping up in European telemetry? It looks like the group (also tracked as RedDelta or Vertigo Panda) is ramping up operations against diplomatic entities again after a relative lull.
What's interesting is the shift in their TTPs. While they are still deploying the PlugX RAT, the delivery mechanism is leaning heavily into OAuth-based phishing rather than standard credential harvesters. This is problematic because standard MFA doesn't necessarily block it if the user consents to a malicious app.
For those hunting PlugX, keep an eye on suspicious registry persistence in the HKCU\Software hive. Here is a quick PowerShell snippet to check for common PlugX registry keys often used for DLL loading via rundll32:
Get-ChildItem -Path "HKCU:\Software" -Recurse -ErrorAction SilentlyContinue |
Where-Object {
$_.PSChildName -match '^[a-f0-9]{32}$' -or
$_.GetValue('DllPath') -ne $null -or
$_.GetValue('ServiceDll') -ne $null
} | Select-Object PSParentPath, PSChildName, Property
On the identity side, we need to tighten up Conditional Access policies. Specifically, we should be blocking OAuth consent for apps not published by your own organization or verified publishers.
Is anyone seeing specific ISO lures in this campaign, or are they moving strictly to HTML attachments for the OAuth redirects?
We caught a few of these OAuth attempts last week. The attackers are impersonating legitimate logistics and trade organizations to solicit the consent grants. Our saving grace was a 'Block' policy on user consent for third-party apps.
For anyone using Sentinel, this KQL helped us identify the spike in anomalous consent grants:
AuditLog
| where OperationName == "Consent to application"
| where Result == "success"
| project TimeGenerated, UserId, AppId, ConsentType
| summarize count() by AppId, bin(TimeGenerated, 1h)
I'm more concerned about the PlugX variant they're using. It's heavily obfuscated this time around. We saw instances where the malicious payload was loaded via a signed binary to bypass application whitelisting (LOLBin usage).
Make sure you're monitoring for rundll32.exe spawning from excel.exe or winword.exe. The command line arguments usually look innocent but contain a base64 encoded blob.
Validating OAuth permissions is critical as these attacks often bypass standard MFA. Since blocking specific domains isn't foolproof, try hunting for high-privilege scopes requested during consent events. This KQL query helps detect risky grants like RoleManagement.ReadWrite.Directory:
kusto
AuditLogs
| where OperationName == "Consent to application"
| where TargetResources[0].ModifiedProperties contains "RoleManagement"
| project TimeGenerated, UserId, AppDisplayName
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access