AccountDumpling: Weaponizing Google AppSheet for Phishing Relays

This is exactly why I've been pushing for a CASB solution. Reputation filtering is dead when the attackers are living inside the perimeter. We actually saw something similar with Microsoft Forms a few months back.

Instead of just counting requests, look at the User-Agent strings. AppSheet traffic usually identifies itself specifically. If you see a standard Chrome User-Agent hitting an AppSheet API endpoint without the AppSheet client context, that's a massive red flag.

Also, check the referer headers on your proxy logs; these phishing relays often mess up the referer chain when redirecting.

Solid query. I'd add a filter for InitiationProcess. In many cases, the phishing link is clicked from a mail client (Outlook, Thunderbird), so seeing an unexpected POST to an AppSheet API immediately following an email link is a strong indicator.

Get-NetTCPConnection -RemotePort 443 | Select-Object RemoteAddress, State, OwningProcess | Where-Object {$_.OwningProcess -eq "outlook"}

While that PowerShell snippet is a bit manual, it illustrates the correlation we need in the SIEM. If Outlook is spawning connections to AppSheet, audit it immediately.

The 'AccountDumpling' name is a bit on the nose, but the storefront aspect is concerning. If they are selling the accounts, we need to worry about credential stuffing next.

We deployed a Yara rule for internal network scanning to catch the HTML response body of the phishing page itself. AppSheet serves dynamic content, but the phishing kit often has static strings (like 'Facebook Security Check') that don't belong there. Analyzing the SSL/TLS payload for specific keywords (DPI) has been our last line of defense here.

Spotting these in the noise is tricky. Beyond CASB, we've had success hunting for the specific API parameters the kit uses—often AppName or TableName in the URL. If you see a surge in traffic to appsheet.googleusercontent.com where the URL length exceeds standard thresholds (likely containing encoded credentials), that's a strong indicator. We run this KQL query to hunt for the outliers:

DeviceNetworkEvents
| where RemoteUrl contains "appsheet.googleusercontent.com"
| extend UrlLength = strlen(RequestUrl)
| where UrlLength > 500
| project Timestamp, DeviceName, RequestUrl

Validating the User-Agent string is another strong signal here. Legitimate AppSheet traffic usually comes from the dedicated mobile client or standard browsers, whereas phishing kits often execute from automated scripts or headless browsers.

You can hunt for these anomalies in your proxy logs with a regex query to flag non-standard UAs accessing AppSheet domains:

regex (?i)appsheet.*((bot|curl|wget|python|headless)/)

If you see hits matching this pattern targeting Google's subdomains, it's highly suspicious and warrants immediate blocking.

Validating User-Agents is smart, SecArch_Diana, but I’d also recommend inspecting the payload sizes. Legitimate AppSheet workflows usually transmit structured JSON; phishing kits often trigger on credential submissions with consistent, smaller POSTs. If you see a single source IP spiking requests to appsheet.googleusercontent.com with minimal SentBytes, that’s a red flag.

Here’s a basic KQL query to hunt for volume anomalies:

DeviceNetworkEvents
| where RemoteUrl contains "appsheet.googleusercontent.com"
| summarize RequestCount=count(), TotalBytes=sum(SentBytes) by DeviceName, bin(Timestamp, 1h)
| where RequestCount > 100