Security scare at home

I was driving home when I got the call. My daughter had downloaded what looked like a demo build of an indie game from a source she trusted. Within minutes she received an email from an unknown address containing a list of her passwords as proof of exfiltration. The attacker had already changed her Google password and enrolled her account under their own Family Link parental control. She disconnected the home network approximately five minutes after execution.

Five minutes is a short window. It turned out to be enough.

What actually happened

This is a textbook commodity credential-stealer, likely from the RedLine/Vidar/Raccoon class. The delivery mechanism is increasingly common: a "demo" or "early access" game from a trusted-looking source bundles a stealer payload. The payload executes, harvests browser-stored credentials and session tokens, exfiltrates over HTTPS, then self-deletes. The whole cycle takes under a minute.

The attacker proved access by emailing harvested credentials. That email is a tell. It's a social pressure move designed to cause panic and rushed decisions. They also added a parental account via Google Family Link, which locks the victim out of standard recovery paths. A clever second step that most people don't anticipate.

This wasn't a sophisticated breach. It was a social delivery attack, well-executed against a user who had no reason to be suspicious. That distinction matters for the response.

Incident timeline

• T+0mEXE executed. Payload runs, credentials harvested, exfiltration complete.
• T+~2mAttacker email received. Password list proves exfil. Family Link parental account added.
• T+~5mThe Call P1. I'm briefed while driving home. Advise: pull power to the internet, don't touch anything, start account recovery from a clean device.
• T+~10mAccount recovery starts. Google support contacted. Password changes initiated from a clean device. Bank notifications made.
• T+15mThe Call P2. My daughter dropped the network on all endpoints in the home.
• T+45mIR USB built. From a clean Ubuntu laptop over hotspot: Malwarebytes, Defender defs, ESET, Sysinternals Suite.
• T+90mEndpoints scanned. Three-tool pass, offline. No active persistence found, consistent with self-cleaning stealer.
• T+2hNetwork restored. Port forwarding removed, all inbound ports closed. Public ingress design and build started.
• T+3hGoogle escalation initiated. Live chat with Google support. After working through options, requested that all accounts associated with the attack be reported as malicious and disabled on their end.
• T+24hThe dust has settled. My kid had to create several new personal accounts. No critical systems were compromised. Lessons learned.

My environment's posture going in

A few things worked in my favor that I had built intentionally, not for this incident, but in general:

• A clean admin plane. My admin laptop is not domain-joined, has no inbound services, no browser password storage, no password reuse. It was safe to use as the IR workstation immediately.
• Server separation. Linux servers, no default credentials, no casual browsing or email use. Credential stealers don't laterally move into hardened Linux stacks, but having clear architectural separation meant I didn't have to guess.

The infrastructure wasn't breached. This was a user-endpoint compromise, contained to the endpoint. The five-minute disconnect and the platform separation did the job.

The Google Family Link wrinkle

This part is worth documenting because it's not well-covered anywhere. Once an attacker adds themselves as a Family Link parent, standard Google account recovery fails silently. The support documentation runs you in loops, and in my experience the Trust and Safety team never followed up. The accounts were unrecoverable. My daughter had to start fresh.

What the scans found

Three-tool offline scan pass: Malwarebytes (including rootkit scan), Microsoft Defender offline, ESET. All returned clean.

This is expected, not suspicious. Modern commodity stealers are designed to execute, exfil, and remove themselves from disk. Clean scans confirm the threat class. They do not mean the system is safe to keep. The OS was still burned. Wipe and rebuild is the correct outcome regardless of scan results, because the damage happened before any scanner ran.

What I changed after

• IR SOP formalized. This incident became the Home Lab IR SOP v1.0, written during the event and refined after.
• Family account 2FA baseline set. Authenticator app, not SMS. Recovery codes stored offline.
• Smart edge VM designed and built. This incident was the catalyst. Rather than relying on raw port forwarding, I built a dedicated edge VM to handle all public ingress, isolating exposure from the rest of the stack.
• Guest/kids network on the roadmap. Network-level separation is the right long-term answer.

Three takeaways

The five-minute disconnect mattered more than any tool. Isolation before investigation is the highest-leverage action in the first few minutes of a credential-stealer incident. A clean scan does not mean the system is safe to keep. The damage was done before the scanner ran. Treat the OS as burned and rebuild. And your clean workstation is your most valuable asset during IR. Having a machine I trusted completely meant I could act from a known-good baseline immediately. That's not luck. Build it on purpose.