Google Workspace Forensics – Insights from Real-World Hunts & IR

The speakers, both cloud researchers, open with why Google Workspace draws attackers: a collaboration suite used by millions of paying businesses, with logs split by service and typically kept for six months. They explain why the raw records are hard to work with. Each entry nests a list of events, and each event carries its own list of typed parameters. Useful fields are also absent, including user agent and file paths, and IP addresses can look inconsistent when a connected app acts on a user's behalf.

To make the data usable, they flatten nested events into one row each, strip the type annotations so only parameter names and values remain, and tag actions taken by third-party apps. A case then follows an external account that produced an unusual burst of Drive downloads at a single timestamp. The talk lists Drive event names that can signal exfiltration, such as viewing, emailing as an attachment, printing and copying, and shows how a visibility change to "anyone with a link" appears as paired events. Because the API needs permissions and reflects only current state, they rebuild historical file paths by chaining folder-creation records. The account turned out to belong to an admin who had been phished.

The final part covers a visibility gap: users without a paid license produce no private-drive log records, which would let an admin revoke a license, copy shared-drive files privately, download them, and restore the license with little trace. Hunters should look for license revoke and assign events close together, and for copy events lacking matching pairs. The advice is to learn the limits of the logs before an incident, make them readable, and then monitor proactively for exfiltration.