Account compromise and identity-based attacks
Why this matters
Account compromise is the most common intrusion an analyst will actually work, and the hardest to triage, because every individual event looks legitimate. The attacker authenticated successfully. The token is valid. The requests are well-formed.
Earlier you learned how identity works and which events are worth alerting on. This lesson is the analytical half: given those alerts, how do you decide whether this is a compromise or a person having an unusual day? That judgement, made under time pressure and with incomplete information, is what the job mostly consists of.
The lesson
Impossible travel, and why it is noisy
The detection is arithmetic: two authentications from locations far enough apart that no aircraft could cover the distance in the elapsed time.
It is genuinely useful and it generates a great deal of noise, for reasons worth knowing because the exam likes them:
- VPNs. A user connecting through a corporate or commercial VPN appears wherever the exit node is. Switching it on mid-session produces a perfect impossible-travel alert.
- Mobile networks can present addresses registered in another city or country, and carrier-grade NAT aggregates many users behind one address.
- Cloud-hosted clients. A remote desktop or cloud workstation authenticates from the data centre's location, not the user's.
- Geolocation databases are approximate, sometimes wildly so, especially for corporate ranges.
- Stale sessions. A device waking up and refreshing a token can produce an event timestamped oddly relative to the user's actual movement.
How to make it useful rather than noisy:
- Correlate with the second event's characteristics, not just its location. A new country and a new user agent and an unfamiliar device is a very different picture from a new country alone.
- Check whether both sessions are concurrently active. Two simultaneous sessions from different continents is much stronger than sequential ones.
- Build a per-user baseline. Frequent travellers and remote workers have genuinely mobile patterns; most people do not.
- Weight by account value. The same alert on a privileged account deserves more of your time.
Treat it as a prompt to look, never as a finding on its own. The exam will happily offer "disable the account immediately" as a plausible-looking wrong answer to a single unexplained geography alert.
MFA fatigue, push bombing and token theft
Multi-factor authentication moved attackers' effort from stealing passwords to defeating the second factor, and three techniques dominate.
MFA fatigue, or push bombing. The attacker already has a valid password and triggers push notifications repeatedly, at night or during a meeting, until the user approves one to make it stop. Sometimes the attacker phones the user pretending to be IT and asks them to approve.
The log signature is distinctive: many MFA challenges for one account in a short window, mostly denied or expired, ending in one approval. That final approval is what makes it an incident, and the burst of denials before it is the thing you can alert on. Number matching and additional context in the prompt are the standard mitigations.
Adversary-in-the-middle phishing. The victim visits a proxy that relays the real login page, so the credentials and the MFA challenge are genuine and succeed — and the proxy captures the resulting session cookie. MFA is not bypassed; it is completed and then stolen. The indicators are session-based, as covered in the identity lesson: the session appearing from a new address, a new user agent, or an automation client shortly after a successful login.
Token and cookie theft by malware. Same effect, different delivery — an infostealer takes browser cookies directly from the endpoint. Here the endpoint telemetry from lesson 7 is your evidence, and the identity logs show the consequence.
The containment lesson carries across all three: revoke sessions and tokens, not just passwords. A reset alone leaves stolen tokens valid until they expire.
Privilege escalation inside the directory
Once inside, an attacker wants more rights, and directory environments offer well-trodden paths. You do not need to execute these, but you should recognise them in a scenario.
On Active Directory:
- Kerberoasting: requesting service tickets for accounts with service principal names, then cracking them offline. The signature is a burst of ticket requests, particularly with weaker encryption types, from one account.
- AS-REP roasting, targeting accounts that do not require pre-authentication.
- DCSync: a non-domain-controller asking to replicate directory data, effectively requesting every password hash. Replication requests from anything that is not a domain controller is a high-fidelity detection.
- Golden and silver tickets: forged Kerberos tickets. Extremely hard to spot in use, which is why the goal is to detect the theft of the key material that makes them possible.
- Delegation abuse, where a misconfigured trust lets one account act as another.
- ACL abuse: rights granted over an object that allow a reset or a group addition, which look like ordinary administration.
In cloud directories, escalation is usually permissions-based: attaching a policy, assuming a role with more rights, or exploiting a role that can modify its own permissions.
The common thread — and the thing to say in an exam answer — is that escalation usually looks like administration performed by the wrong account, from the wrong place, at the wrong time. The action itself is ordinary.
New device, new location, new consent grant
Three "new" events carry disproportionate weight, and they are worth treating as a set:
New device registration. An attacker registering their own device gives durable access and often satisfies device-compliance policies afterwards. Rare per user, easy to alert on.
New MFA method. Adding a phone number or authenticator keeps access after a password reset. This is one of the most valuable single detections in identity security, because it is both rare and almost always significant when it follows a suspicious login.
New OAuth consent grant. The user approves an application's access to their data. Illicit consent phishing asks for exactly this, and the resulting access:
- persists through password resets,
- often survives MFA re-enrolment,
- can read mail or files continuously through an API,
- and generates no further logins at all, because the application holds its own token.
Watch for: consent to applications not in your catalogue, consent granted by many users in a short window (the phishing campaign landing), and permissions that are broad relative to what the application plausibly needs.
The ordering matters when you triage. A suspicious sign-in followed within minutes by a new MFA method or a consent grant is not a probable false positive any more — it is an attacker establishing persistence, and it should move straight to incident handling.
Distinguishing compromise from a user having a bad day
Most identity alerts resolve as benign, and resolving them well is a skill.
Questions that separate the two quickly:
- Did anything change, or only the access pattern? A login from a new country is ambiguous. A login from a new country plus a new MFA method is not.
- Is the activity consistent with the person's job? Someone in finance reading finance files at an odd hour is odd. Someone in finance enumerating the directory is not a bad day.
- What happened immediately before? A password reset by the help desk, a new phone, a trip, an onboarding — mundane explanations are common and are discoverable in minutes.
- Is the tooling human? Browsers behave differently from scripts. A session suddenly using an API client is a strong signal.
- Is there a second, independent indicator? One anomaly is a prompt; two unrelated anomalies on the same account is a finding.
- Ask the user. Out of band — a phone call, not an email to the account in question. This is fast, decisive, and skipped far too often out of a vague sense that it is not real analysis. It is.
When you close one as benign, record why, in the closure code sense from lesson 1. "Confirmed with user — travelling" is data that tunes the detection. "Closed, no action" is not.
And when the evidence is genuinely ambiguous, the proportionate move is usually containment that is cheap and reversible — revoke sessions and require re-authentication — rather than either ignoring it or disabling the account of someone in the middle of their working day. Choosing that middle option correctly is very often what the exam is testing.
Topics this lesson owns
- [x] Impossible travel, and why it is noisy
- [x] MFA fatigue, push bombing and token theft
- [x] Privilege escalation inside the directory
- [x] New device, new location, new consent grant
- [x] Distinguishing compromise from a user having a bad day
Practise what you just read
1. Which authentication pattern is most consistent with credential stuffing rather than password spraying?
Select one
Show answer
D. Stuffing replays credential pairs obtained elsewhere, so each account is tried with its own specific password, usually once. Spraying uses one common password across many accounts, and brute force concentrates many guesses on one account.
2. An account authenticates successfully from an unfamiliar country and then immediately enrols a new authentication device. What is the most likely explanation?
Select one
Show answer
A. The sequence matters more than either event alone. Enrolling an authenticator immediately after an anomalous logon is how an attacker converts a stolen password into durable access, and it is the event that makes a later password reset insufficient.
3. Why is a burst of multi-factor prompts sent to a user who is not attempting to log in significant?
Select one
Show answer
C. Prompt bombing only reaches the second factor once the first has succeeded, so the volume of prompts is itself evidence that the password is compromised. The user approving one out of fatigue is the outcome the technique is designed to produce.
8 more questions on this objective are part of the full course.
Hands-on labs
Part of the free CompTIA CySA+ CS0-004 course — 40 lessons and 56 hands-on labs.
This is an independent study companion for CompTIA CySA+ CS0-004 and is not produced by or endorsed by CompTIA.