SaaS Abuse Update: AccountDumpling and Google AppSheet Relays
Saw the new Guardio report on AccountDumpling. It’s another prime example of how "Living off the Land" has moved from binary LOLBins to trusted SaaS infrastructure.
The campaign is using Google AppSheet as a phishing relay. Basically, the threat actors host the phishing link logic within AppSheet scripts. When a victim clicks, they hit appsheet.com first, which then redirects them to the credential harvesting page. Since appsheet.com is a high-reputation domain, standard email filters and basic proxy lists usually let it right through.
The report indicates about 30,000 Facebook accounts have been swept up and sold on their storefront. The scale suggests this isn't just manual work; they are automating the distribution.
From a detection standpoint, we can't just wildcard block Google. I'm looking at the redirect chains. If you are using Sentinel or a similar SIEM, hunting for appsheet.com requests containing login-related keywords in the URL parameters might catch it.
Here is a basic KQL hunting query I’m using to flag potential relay behavior:
let suspicious_targets = dynamic(["facebook.com", "fb.com", "login"]);
DeviceNetworkEvents
| where RemoteUrl contains "appsheet.com"
| where RemoteUrl has_any (suspicious_targets)
| summarize Count = count() by DeviceName, RemoteUrl, InitiatingProcessFileName
| where Count > 2
| project-reorder Count, DeviceName, RemoteUrl
I'm assuming the storefront is just the tip of the iceberg for this technique. How is everyone else handling "trusted domain" abuse in your secure web gateways? Are you inspecting deep SSL traffic to catch the final destination, or is this purely a user-awareness fight for now?
We've started implementing Remote Browser Isolation (RBI) for uncategorized sites, but the problem with AppSheet is it's categorized as 'Technology'. We are currently looking at configuring our proxy to parse query parameters. If a legitimate domain has a redirect_url or dest param pointing to facebook.com, we trigger a block. It’s noisy, but it’s better than the alternative right now.
This is the natural evolution of the "Open Redirect" vulnerability. Instead of finding a vulnerable example.com?redirect=evil, they just spin up a legit automation tool to do the redirecting. It bypasses reputation checks entirely. The fact that they are selling the accounts implies the phishing pages are high quality. I'd be curious to see the HTML templates they are using to see if they are bypassing MFA prompts.
Good query, thanks for sharing. I'd add InitiatingProcessCommandLine to that project list to distinguish between clicks coming from a mail client (Outlook/Thunderbird) versus a browser. We saw a similar spike with Notion pages being used for C2 last month, and filtering by process helped cut down on false positives from internal devs testing automation scripts.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access