When reporting tied the 0ktapus crew to roughly 130 victim firms, most public write-ups focused on the SMS lure and the fake login page. Inside those tenants, the durable signal lived elsewhere: identity provider audit trails, MFA decision records, and application access logs that kept recording stolen sessions long after users changed passwords. For cybersecurity teams and IT administrators, that campaign is a working template for how log analysis turns a phishing headline into a hunt you can finish the same week.
0ktapus-style operations push employees to a lookalike portal, capture username and password, and often harvest the session cookie or MFA context that follows. Password resets close the credential half of the problem. Session tokens, device trust marks, and already-issued OAuth grants keep working until you revoke them from evidence in the logs.
Start the timeline at the first impossible factor
Treat the first suspicious authentication as a timeline anchor, not a single alert. Pull IdP system logs for that user across a 72-hour window centered on the phishing click time if you have it, or on the first impossible MFA success if you do not.
Prioritize these fields in Okta, Entra ID, Ping, or equivalent IdP exports:
- client.device or device fingerprint and trust state
- client.ipAddress plus ASN and geolocation at auth time
- authenticationContext or MFA factor type and result
- session.id / refresh token identifiers
- outcome.reason for success, challenge, or deny
- target application or resource identifier
In practice, the phishing session often shows a new browser family, a consumer VPN ASN, and an MFA factor that succeeded within seconds of the password prompt. The legitimate user session minutes later shows the corporate managed device and the usual office or home ASN. Both can succeed. Your correlation job is to mark every session.id minted between those two events as hostile until proven otherwise.
Concrete query pattern
Export authentication events for the user, sort by timestamp, and flag any success where device trust flips from managed to unmanaged inside one hour, or where the MFA factor changes from hardware key or number matching to SMS OTP right before a burst of SaaS app launches. Join those session IDs to application access logs for mail, file storage, VPN, and admin consoles. Anything accessed under a flagged session becomes scope for containment.
What the telemetry actually shows during an AiTM hand-off
Adversary-in-the-middle kits used in campaigns adjacent to 0ktapus reverse-proxy the real login flow. From the IdP’s point of view, the password and MFA challenge look valid because they are. The giveaway sits in the combination of signals rather than any single deny.
Watch for this sequence in order:
- Password success from an unfamiliar IP with no prior history for that user.
- MFA success using a phishable factor (SMS, voice, or push without number matching).
- Immediate creation of a new remembered device or persistent cookie.
- Rapid enumeration of applications the user rarely opens (admin portals, payroll, code hosts).
- A second, quieter login from the user’s normal device that fails or never appears because the attacker already holds the session.
Endpoint telemetry fills gaps the IdP cannot see. EDR process logs that show a browser launching a one-time domain from an SMS link, DNS logs resolving lookalike hostnames, and email gateway clicks on the same short links close the loop. When those sources timestamp within a few minutes of the IdP success, you have a high-confidence incident even if reputation feeds still score the phishing IP as clean.
Widen the hunt beyond the named victim user
0ktapus and similar crews spray thousands of numbers. After you confirm one compromised session, search IdP logs for the same source IP, ASN, user-agent string, and device fingerprint across the whole tenant for the prior 14 days. Parallel search MFA enrollment and factor reset events; attackers who land a session sometimes enroll a new factor to survive password changes.
Also pull privileged application audit logs. A stolen help-desk or cloud-admin session shows up as configuration reads, API token creation, or mailbox rule changes under a session that never touched the user’s normal workstation. Microsoft’s recent wave of nearly 1,000 patched holes raises the stakes here: once inside with a valid session, attackers shift toward exploitation of exposed management paths, and your earliest detection still comes from identity and access logs rather than vulnerability scanners alone.
Immediate controls that map to what the logs prove
Convert each confirmed log finding into a control the same day:
- Revoke sessions and refresh tokens for every flagged session.id, not only the user’s current browser.
- Disable phishable MFA factors for privileged roles; prefer FIDO2 or hardware-backed authenticators and number matching for everyone else.
- Require re-authentication on high-risk apps when device trust or IP reputation changes mid-session.
- Alert on new factor enrollment and new trusted devices within 24 hours of any impossible travel or new-ASN login.
- Pipe IdP, EDR, DNS, and SaaS audit logs into one correlation view with shared user and session keys so analysts stop pivoting manually.
For IT administrators without a full SIEM, start with scheduled exports: daily dumps of authentication successes with new devices, MFA failures followed by success within five minutes, and application grants created outside business hours. Those three reports catch a large share of session-theft tradecraft before extortion or data staging begins.
When AI platforms enter the same log picture
Separate reporting this week covers threat actors abusing trusted AI platforms as an attack surface and AI-assisted OSINT feeding fraud. From a logging standpoint, treat outbound calls to AI SaaS APIs like any other high-privilege egress. Corporate proxy and CASB logs that show sudden spikes in prompt-sized POST bodies to AI endpoints from service accounts, or from users who never used those tools, deserve the same session-correlation treatment you apply after a 0ktapus-style phish. Pair those egress records with IdP tokens issued to the calling identity so you can revoke access before harvested data leaves through a second channel.
Operational takeaways for the next hunt
Build a short runbook titled around session survival, not password hygiene. When a smishing or AiTM alert fires, analysts should open IdP auth logs first, extract session and device identifiers, fan out to application access and factor-change events, then revoke and re-enroll before touching endpoint reimaging. Keep at least 30 days of identity and SaaS audit logs online; 0ktapus-scale campaigns often leave secondary victims whose first suspicious success sits days before the news cycle names the group.
Measure detection quality by time from first impossible MFA success to full session revocation across the tenant. Teams that wire that metric to automated revocation for high-risk apps shrink the window attackers use to turn one phished employee into lasting tenant access. Log analysis earns its keep when it shortens that window with fields you already collect.
