How Do You Detect Phishing Exposure? Seven Signals to Look for in Your Own Logs, Drawn From Three Recent Campaigns That Beat the Password and the MFA Code
To find out whether a phishing campaign has already worked on you, look in your sign-in and control-plane logs for seven signals, starting with device-code sign-ins from devices you do not recognize. This matters because the campaigns researchers reported in October and November 2026 get past the password and the one-time code, so a user who "did everything right" can still be compromised. The FBI's 2025 Internet Crime Report lists phishing and spoofing at 191,561 complaints and $215,843,126 in reported losses, about three times the 2024 figure by our arithmetic. This page turns three recent campaigns into things you can check.
Three campaigns, three ways around the code
Fake event pages and device codes. Push Security reported on November 5 that fake OpenAI, SpaceX and Anthropic event pages take Microsoft and Google work sessions. On the Microsoft side, a page fetches a device code, shows it in a "Confirm access" box and opens Microsoft's real login. The person pastes the code and approves, and Microsoft issues tokens to the attacker's session. On the Google side, a reverse proxy relays the real sign-in and captures the password, the MFA response and the session cookie. Push says the operator rotates domains every few weeks.
A fake Google sign-in reached through paid search. Wiz reported on October 20 that attackers bought search ads on the words a cloud administrator types, and sent clicks through a redirect to a fake Google sign-in. The page captured the password and the MFA code, logged in at once from 212.73.134.136, then passed the person on to the real login. Later activity came from addresses in the victim's own headquarters country, so a location alert would not fire.
A page that asks you to paste a token. Google's report on LLMjacking, published November 2, describes pages posing as application portals that ask the victim to paste a raw JSON payload containing an active access token. That skips the password and the MFA prompt.
Seven signals to check
Device-code sign-ins from unfamiliar devices or places. Push's guidance is to look for device-code authentications since October 20. If you find one, revoke the user's sessions and refresh tokens and reset the password, because a stolen session outlives a password change unless it is revoked.
A sign-in within moments of a click. Wiz saw the attacker log in at once. If you can line up a user's link click, from a mail or proxy log, with a sign-in from a new place seconds later, treat it as suspect.
A new device that passed multi-factor sign-in. Passing the code proves little against a relay, because the attacker relays the code too. A first-time device or browser that completed MFA is worth a look.
Control-plane edits. In the Wiz cases the attackers deleted an organization policy that limits who can be added, made outside accounts billing administrators, demoted the real administrators to read-only, created service accounts and keys, enabled a model service on a quiet project and linked their own projects to the victim's billing account. Each of those is an audit-log event you can alert on.
New mailbox rules and forwarding. This one is our suggestion and is not from those reports. A stolen mailbox session is one route to business email compromise, and a rule that hides replies or forwards mail outside is a common way to stay unseen.
Bursts of tiny test requests. Google says stolen keys are checked with single-token requests, with max_tokens set to 1, to stay under alert thresholds. A run of them from one key is a sign it has leaked.
Lookups of known phishing domains. Check DNS and proxy logs against current indicator lists, and expect them to go stale. Push lists 22 registrable domains and one collection address, and says the domains rotate every few weeks. A hit means someone on your network reached the page, not that they were fooled, so follow it with the sign-in logs.
What cannot be detected this way
A user who is phished on a personal phone, or a session stolen from a compromised device, may leave nothing in your logs. Signals 1 to 4 depend on your sign-in and audit logs being on and retained long enough. And signals alone do not stop the attack: phishing-resistant sign-in, such as a hardware key or passkey, is what makes a look-alike page fail. We wrote more on that in "What Is Account Takeover?"
Indicators
We added Push's 22 registrable domains and one collection address to the feed on November 7, cited to Push Security and not our sighting. We did not add the shared services or legitimate sites the flow abuses. The Wiz address 212.73.134.136 is in the post that covered that report, cited to Wiz.
Limits
The campaign details are the researchers' own, as we covered them in earlier posts, and we did not reproduce any of them. The FBI figures are complaints people filed, and the three-times figure is our arithmetic. Signals 2, 3 and 5 are our suggestions, not findings from those reports. Detection depends on your logging, and none of this guarantees you will catch a compromise.
Five percent of this is wrong somewhere. It always is. By the time you read this, some of the domains will be gone and others will have replaced them.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments