Umbrij Malware: ToddyCat's OAuth Play for Gmail API Access
Hey folks,
Just reviewed the Kaspersky report on Umbrij, the new malware attributed to ToddyCat. It’s an interesting evolution in how they handle email exfiltration. Instead of stealing credentials for IMAP/SMTP, they are abusing OAuth tokens to interact directly with the Google Gmail API.
This is significant because it bypasses traditional heuristics that look for suspicious login events. If the OAuth token is valid, Google sees it as a "legitimate" application session.
From a defensive standpoint, we need to look beyond just login failures. Watch for unusual API patterns or new OAuth grants to suspicious client IDs.
Here is a basic Python snippet to check if a specific token has excessive read scopes (conceptual):
import
# Example scopes to flag
suspicious_scopes = [
"https://www.googleapis.com/auth/gmail.readonly",
"https://www.googleapis.com/auth/gmail.modify"
]
def check_oauth_grant(scopes_list):
return any(scope in suspicious_scopes for scope in scopes_list)
# Simulated token info response
token_info = {"scopes": suspicious_scopes}
if check_oauth_grant(token_info["scopes"]):
print("Alert: High-risk OAuth scope detected!")
Has anyone implemented automated OAuth consent revocation for unused applications in their environment?
Good spot on the API usage. We've been using a Sentinel rule to catch high-frequency gmail.users.messages.get calls. It's a pain to tune because legitimate mail clients hammer the API too, but setting a threshold on readonly scope usage helped filter out the noise.
OAuth abuse is becoming the standard for persistence. Users are conditioned to click 'Sign in with Google' without checking the scopes. In our red team engagements, we often drop a malicious Chrome extension or a fake app just to harvest that initial token. Once you have the refresh token, you have the mailbox until it's revoked.
We've enforced 'Block all third-party API access' for Google Workspace unless the app is explicitly whitelisted in the Admin Console. It breaks some productivity tools, but it kills this attack vector dead. If the app isn't verified by Google, it shouldn't be touching corporate data.
Since Diana mentioned blocking, if you need more granular detection, focus on the OAuth consent logs. You can set up alerts for specific risky scopes like https://www.googleapis.com/auth/gmail.readonly being granted to high-risk client IDs.
Here’s a quick Python snippet to scan recent audit logs for these grants using the Google Admin SDK:
# Example to find OAuth token grants with Gmail scopes
service.activities().list(userKey='all',
applicati,
eventName='grant',
filters='scope:https://www.googleapis.com/auth/gmail.*').execute()
It’s usually cleaner than trying to spot the traffic patterns later.
Excellent insights. Just a reminder that resetting a user's password often fails to immediately kill active OAuth refresh tokens. If you detect this malware, you must explicitly revoke the application's session. For those using GAM, this command is effective for bulk remediation:
gam all users delete token appname="Suspicious_App"
This ensures API access is cut off immediately.
Building on Diana's point, enforcement is key, but visibility into the specific data transfer is where DLP comes in. Since standard proxies miss API calls, we rely on gsuite logs in our SIEM to flag unusual read volumes.
To hunt for this specific campaign, grab the Client IDs from the threat intel and run this KQL query:
GWorkspaceActivity
| where EventName contains "read" or EventName contains "get"
| extend AppId = tostring(Applications[0].id)
| where AppId == ""
| project TimeGenerated, User, AppId, EventName
This helps pinpoint exactly who is impacted immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access