Phishing Worked — Now What? Tracing Account Takeover Through Your Logs
Phishing doesn't end at the click. Learn which Account Takeover signals your logs capture, how to read zcrLog's Threat Incidents and how to respond in time.
An employee opens an email, sees the logo of a system they use every day, clicks the link, and types in their password without noticing the URL is off by one character. That's it — phishing just worked. But the question most organizations don't ask next is "so what happens after that?" A leaked password doesn't just sit in an attacker's inbox — it gets tried against real login pages. And that's exactly where security teams need to start looking: not at the phishing email itself, which is genuinely hard to catch, but at the Account Takeover signals that follow it — signals that actually show up in your logs.
"Phishing" Isn't an Incident Type Your Log Actually Sees
A typical SIEM doesn't have a "Phishing Detected" button, because the deception itself happens outside the system — in the victim's mail client or browser — before it ever becomes a log event you can inspect. What the log actually sees is the behavior that comes after the password leaks: repeated password guessing (brute force), escalating privileges once inside (privilege escalation), moving across machines (lateral movement), and pulling data out (data exfiltration).
I went through the Threat Incidents and Detection Rules screens in zcrLog's demo environment to see how these stages show up there. Nothing below is a real customer incident: where I walk through an example, it's a hypothetical one, so what you get is how to read the screens and what each signal means. (See zcrLog — the live demo needs the demo login, demo / demo.)
How to Read the Threat Incidents Table
Threat Analysis > Threat Incidents lists incidents one per row, and a few columns do most of the work when you're looking for signs of a takeover:
- Type — the kind of incident, for example
brute_force, privilege_escalation, lateral_movement or data_exfiltration.
- Status — where the incident stands, for example open or closed.
- Threats — how many sub-signals the incident bundles together.
- Username — the account involved, where the log carries one. The same account turning up on several incidents is the thread to pull.
- Source IP and Destination IP — where the activity came from and where it landed. More on that below.
Here is how those columns read together in a hypothetical case. Suppose a brute_force incident names one account, with a source outside the company and a destination inside it: that's the guessing stage. If the same username then turns up on a privilege_escalation incident, the guessing may have worked, and someone is now trying to get more rights than the account should have. A lateral_movement incident on that account after that would mean they're reaching for other machines. Any one of those on its own proves little. The same account climbing through the types in that order is a pattern worth treating as a takeover until someone rules it out.
Incidents in the table can also carry MITRE ATT&CK tags. In MITRE's framework, T1110 (Brute Force) is password guessing, filed under the TA0006 (Credential Access) tactic, and T1021 (Remote Services) is a way of spreading, filed under TA0008 (Lateral Movement). The technique that most directly describes account takeover itself is T1078 (Valid Accounts): the attacker isn't breaking in, they're logging in with a real credential. An ATT&CK tag names a tactic or technique; it doesn't prove that it happened, so check the events behind an incident before relying on the tag.
Reading Source IP → Destination IP the Right Way
Read Source IP and Destination IP as a pair, not either address alone. The pattern to look for is a source that looks like an external public address paired with a destination inside the corporate network (the RFC1918 ranges: 10.x.x.x, 172.16–172.31.x.x, 192.168.x.x). It lines up with how a real takeover typically plays out: whoever's holding a password leaked from phishing logs in from outside the organization, then goes straight for internal resources the moment they're in.
Two cautions. An external source address is also what an employee working from home or traveling looks like, so the address alone can't tell you who is logging in; you need more than the pair to go on, such as the account and the incident type. And a pair where both addresses are internal can mean someone is already inside and moving around rather than coming in from outside, though a login that came in through a VPN can look internal too, so it isn't proof either way.
Seeing the pair on the same row as the account and the incident type tells a different story than scrolling through logs line by line. That's what zcrLog is built to do automatically: collect the logs and correlate this behavior into a single view in one table, so your SOC team isn't stuck manually correlating file by file.
The Rules That Cover What Happens After Phishing Succeeds
The Detection Rules Management > Rule Templates page in zcrLog lists ready-made detection rules, such as Brute Force (SSH), Privilege Escalation and Anomalous Login Location.
Of those, the one most directly relevant to account takeover is Anomalous Login Location — a rule that flags when the same account logs in from a location that's unusual compared to that account's normal behavior, which is a classic sign of a session hijacked after a successful phishing attempt. Brute Force (SSH) fits the guessing stage when the guessing is aimed at SSH, and Privilege Escalation fits what comes after a login gets through. Whichever rules you rely on, check that they're switched on (Active) — a rule that isn't running catches nothing.
Why MFA Alone Isn't Enough
MFA does cut out a lot of straightforward password-leak problems. But a lot of today's phishing kits run Adversary-in-the-Middle: they proxy the real login page and steal the session token right after MFA passes. That means MFA alone isn't a complete shield — you need a layer that detects abnormal behavior after a successful login too, like the Anomalous Login Location rule mentioned above.
Passwords leaked through phishing also frequently get tried against an organization's public login pages, not just internal systems — this is covered in detail in our article on credential stuffing after phishing, which explains why blocking at the public-facing entry point matters, rather than just waiting to catch it internally.
Automating the Response Once a Signal Fires
Once a rule triggers, the next question is who clicks what — not just "the system sent an alert" and calling it done. We cover how to lay out an automated response flow with human approval built in at the right points in our playbook for handling phishing without doing every step by hand. And if you want to know what tactics/techniques like TA0006 or T1110 mentioned above actually mean, there's a primer at What Is MITRE ATT&CK?
Summary: Signals to Watch For After Phishing
| Behavioral Signal | Incident Type in Log | What It Tells You |
|---|
| Repeated password guessing | brute_force | Someone is trying passwords against an account, possibly one leaked in the phish |
| Escalating privileges after getting in | privilege_escalation | Someone who has gotten in is reaching for more rights than the account should have |
| Moving across machines/systems | lateral_movement | The account is being used to reach other machines or systems |
| Pulling data out of the system | data_exfiltration | A late stage: data is leaving the system |
Organizations without a log system that correlates these signals into one view usually realize they've had an account taken over when it's already too late — they catch it once data is already going out (data_exfiltration), not back when it was still just password guessing (brute_force), a stage that's far easier to catch and fix in time.
See all zcrLog packages and pricing →
Sources
- Microsoft Security Blog — From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud — confirms the Adversary-in-the-Middle phishing mechanism that steals a session cookie after MFA succeeds, letting an attacker bypass MFA entirely
- MITRE ATT&CK — T1078 Valid Accounts, T1110 Brute Force, and T1021 Remote Services — technique definitions referenced throughout the article
Want to know how fast your organization would actually catch these signals?
Talk to our team — the consultation is free.