The Fight

This is Part 3 of Eight Minutes. Part 1 — The Trap is the call and the tap; Part 2 — The Fall is the eight minutes the tap bought. This is the fight back.

Capture first, panic later

The realisation arrived mid-attack, not after it. Partway through the call I pasted the pattern into an AI session I had open, watched it name the scam back at me, and said so out loud to the man on the phone — which is when he hung up. So I had a strange and valuable thing most victims never get: minutes of overlap where I knew, and the attack was still running.

The instinct under adrenaline is to slam everything shut. I did something that felt almost irresponsible instead: I recorded it. A full network capture of the live phishing session — 880 requests, the fake pages, the relay backend, the operator’s responses steering my screen — taken while the operator was still on shift inside my account.

That choice is the reason this series exists in this detail, and the reason the worst part of the attack was ever discovered at all. The capture is how the Binance pivot came to light. If I’d simply reset my password and walked away, I would have spent that evening feeling lucky while knowing almost nothing about what had actually happened.

If you remember one operational thing from this series: contain fast, but capture first where you safely can. You can’t investigate evidence you never preserved.

Recovering the deleted warnings

Part 2 ends with the attacker binning Google’s security alerts so I wouldn’t see them. The Trash, it turns out, is not the void — every one of the four deleted warnings came back out of it, timestamps intact, and they now read as a minute-by-minute narration of the attack written by Google in real time.

One alert needed no recovering, because the attacker could never reach it: the critical “someone tried to change how you sign in” warning had also gone to my recovery address — a second mailbox the attacker never controlled. That’s worth a hardening note all by itself: a recovery account isn’t just for resets; it’s an off-site copy of your security mail that an attacker inside your main account cannot blind.

The arithmetic of it is chilling in a quiet way. They had delete-level access to my mailbox for the fourteen and a half minutes the session lived, and the first thing they spent it on was my situational awareness.

Asking Google what Google saw

Alert emails and a packet capture gave me my side of the story. I wanted the server’s side. So I pulled the Google Workspace audit logs — the authoritative, server-side record of every login and account action — and let Google’s own evidence grade my reconstruction.

It confirmed everything, and sharpened it:

• The attacker’s login, to the second, from the VPS address — with Google’s own is_suspicious=True flag sitting right there in the log line.
• Not one blocked persistence attempt but four. The single “Google stopped this attempt” email I’d received had understated it; the operator went back to the locked door four times in under four minutes.
• And the line that let me finally exhale: the password-change log held exactly three entries, all mine. No recovery email added, no phone swapped, no rogue passkey, no backup codes. The blocks had truly held.

That last check upgraded the whole investigation. The reconstruction stopped resting on alert emails and a capture and became first-party logs at both ends — Google’s audit log and Binance’s own security emails name the same attacker IP (as of June 2026; it’s a rented VPS address, and these get reassigned).

Mapping the kit without touching it

I never sent a single packet to the attacker’s infrastructure. Everything I learned about it came from public registries and scan databases — certificate transparency logs, urlscan, RDAP. Passive only: when the kit is already fully captured, active probing buys you nothing and tips your hand.

The passive picture was damning enough. The phishing domain was registered a month before my phone rang, wildcard certificate and all, and a public scanner had captured the live kit the same day it was stood up. Then the find that reframed everything: the lure page had been publicly scanned six days before my call.

I wasn’t a target. I was a Wednesday. This was a production line — provisioned, tested, and already running before it got to me. Somewhere behind that six-day-old scan is an earlier recipient, or a mail gateway doing its job — someone or something that met this page before my turn came. And somewhere after me, the next name on the list.

Eight reports

A production line is infrastructure, and infrastructure has landlords. Every piece of the kit exists at someone’s commercial pleasure — a host, a registrar, a DNS provider — and every one of them has an abuse desk. So the counter-attack was paperwork, dispatched in impact order:

1. The origin host — the company whose server actually serves the phishing site. The fastest kill: suspend the box, the site dies regardless of the domain.
2. The registrar — the domain itself.
3. Cloudflare — the DNS record in front of it.
4. The host renting the attacker their VPS — the report carrying the strongest single fact: first-party logs at both ends put the same address inside my Google account and behind the Binance reset.
5. Google Safe Browsing — the browser-level block that warns every future victim mid-click.
6. Google’s own Sites and Support-Cases teams — the lure prop and the auto-responder abuse that made the lure authentic. Two separate teams; two separate abuses.
7. The blocklists — propagation to every feed that consumes them.
8. ReportCyber, Australia’s national cybercrime reporting channel — which creates the law-enforcement record. That report is filed.

None of these requires a badge or a subpoena. They require knowing who the landlords are — which the passive recon had already established — and writing clearly, with evidence.

What happened next

All eight reports went out within thirty hours of the call — the last two on the morning of June 11. As of June 11, the day after: no confirmed takedowns yet. view-support[.]com still resolves; the origin host hasn’t replied. The systems that could act mid-attack already had — Google’s risk engine, Binance’s freeze. The infrastructure itself dies on abuse-desk time, not mine. I’ll add a follow-up note here as outcomes land; the landlords who never reply don’t get to hold the story hostage.

Update — June 11, afternoon. The first responses are in, and they’re a genre study in themselves. Cloudflare’s Trust & Safety replied within hours: the reported content is no longer being served by Cloudflare — technically true, because on a DNS-only configuration it never was; their nameservers still resolve the domain as I write this. Tasmania Police assessed the report, thanked me, attached generic phishing-hygiene advice and two mental-health hotlines, and filed it for intelligence purposes. The relay VPS’s network owner opened a ticket, asked me for logs I’d already sent, auto-closed it, re-opened it when I pushed back, and has now forwarded the complaint to the customer running the box. The registrar sent an auto-acknowledgement and went quiet; the domain is still marked ACTIVE. Nothing has come down. Abuse-desk time, as promised.

The ending

The story ends where the advice should have started: passkeys.

Everything else in this series is, in the end, a story about a human being asked to make a perfect judgement call under pressure, in real time, against a professional — and losing. The fixes that ask the human to try harder (check the sender, check the number, be more suspicious at 2pm on a busy afternoon) put the same human back in the same losing position with higher stakes of shame.

A passkey removes the human from the decision. The credential is bound to the real domain; it never passes through me; there is no number to match, no code to read out, nothing for an operator to relay. It isn’t hygiene theatre or one more thing to be vigilant about. It’s the one fix that moves the decision off the person the attack is designed to beat.

That’s where this ends: passkeys on the accounts that matter, starting with email — because email, as Part 2 showed, is the master key to everything else.

And so the closing line of my own notes becomes the closing line of the series: go enrol a passkey on your email account right now. It takes two minutes. I’ll wait.

---

Eight Minutes is a three-part series — a true first-party account; the evidence behind every timestamp is preserved. Part 1: The Trap · Part 2: The Fall · Part 3: The Fight (you are here).