Incident response for a suspected compromise of a personal @gmail.com
account used for practice business. Written for the consumer-account
reality: no Admin console, no Admin SDK, no audit-log export, no vendor
phone support — every recovery path is Google's automated self-service
flow.
Initial vector assumed to be an AiTM credential phishing kit (blob: URI
rendering a spoofed sign-in page locally, relaying to an attacker
session), with an endpoint infostealer as an unruled-out alternative.
Both steal a post-authentication session cookie, so 2FA does not prevent
it and a password reset alone does not evict it. That drives the whole
ordering: revoke sessions, then OAuth grants, then app passwords, THEN
reset the password, then enroll phishing-resistant 2FA, then sweep Gmail
persistence. Rationale is inline so it doesn't get optimized away
mid-incident.
Phases 0-5 with durations and exit criteria: evidence preservation,
access triage (live-session branch vs. account recovery), containment,
blast radius (registrar first, then financial/vendor/licensing),
endpoint investigation (GravityZone history before scanning, policy and
exclusion audit, Autoruns/Process Explorer, RMM hunt, UniFi logs), and
documentation/handoff. Appendices for decision log and contacts.
Google UI paths verified against Google's help docs at time of writing;
deep links used over menu wording, with an appendix on their volatility.
Kaspersky tooling deliberately excluded (US distribution restrictions).
Makes no compliance determination by design — legal calls route to
counsel/compliance contact. Placeholders only; work the filled-in copy
in the private tier.
New sec- prefix for security/IR runbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
