A suspicious login alert is the beginning of an investigation, not a conclusion. Access outside normal hours can be legitimate; apparently ordinary authentication can be part of an intrusion. Triage must gather enough context to distinguish the two scenarios.
This article presents a triage sequence — from the fields you need to a documented decision.
Start with the original event
Record the time with its time zone, account, source, destination, authentication result, and method used. A useful authentication event contains, at a minimum:
| Field | Why it matters |
|---|---|
| Time with time zone | Correlation across systems depends on it |
| Account identifier | The subject of the investigation |
| Source address and ASN | ASN says more than IP — cloud, carrier, VPN |
| Agent/device | A device change is a signal, not proof |
| Result | Success, failure, and the reason for failure |
| Authentication method | Password, MFA, token, key — and which factor was used |
| Session identifier | Connects the login to what followed |
| Destination application or service | Not all access carries the same weight |
Missing fields limit the analysis and must appear in the conclusion. If the system does not record the device, write that down — it is different from “the device was known”.
The reason for failure deserves emphasis. “Incorrect password” and “correct password, MFA denied” tell opposite stories: the second indicates that the credential is already compromised and the second factor is holding back access. Many platforms distinguish these codes, and that distinction often goes unnoticed.
Avoid assessing an isolated event. Look for earlier and later attempts from the same account, source, or device. A sequence of failures followed by success may indicate password guessing — but could also be a user correcting an old credential.
Distinguish attempt patterns
Three patterns may look similar in volume, but differ in intent:
| Pattern | Signature | What it suggests |
|---|---|---|
| Brute force | Many passwords against one account | A specific target |
| Password spraying | One common password against many accounts | Broad, quiet scanning |
| Credential stuffing | Username/password pairs from breaches | Password reuse across services |
Spraying is the easiest to miss: each account records one or two failures without triggering attempt-based lockout. It only appears when viewing the whole — many accounts failing from the same source in a short window. If your detection works per account, it is blind to this case.
Compare with expected behavior
Ask whether the account normally accesses that service, whether there was a recent device change, and whether the source fits the person’s work.
IP addresses and approximate locations are imperfect signals. Corporate VPNs, mobile networks, cloud services, and travel change how access looks. IP geolocation is often wrong, and treating “different country” as compromise creates many false positives.
The “impossible travel” signal — two accesses whose geographic separation is incompatible with the elapsed time — is stronger than location alone, but still breaks with a VPN: someone disconnects it and appears in another country within seconds.
Look for signals independent of the login itself:
- a new session created in an unusual service;
- changes to authentication factors or recovery methods;
- creation of an email forwarding rule;
- access to an unusual volume of data;
- administrative actions immediately after login;
- permission granted to an application.
The second item is the most valuable in the list. Registering a new MFA method is one of the most consistent actions of someone who has just gained access — it maintains access after a password change. A strange login followed by registration of a new factor is a much stronger signal than either alone.
Form testable hypotheses
Write hypotheses that can be confirmed or refuted, with an explicit test:
| Hypothesis | Would support it | Would weaken it |
|---|---|---|
| Owner on a new device | Person confirms; MFA approved first try; normal usage follows | No subsequent work-related activity |
| Credential obtained by a third party | New MFA factor; forwarding created; atypical access | Activity identical to account history |
| Stolen session | Active session with no corresponding authentication event | Normal login recorded before the session |
The third deserves attention: when an attacker imports a valid session cookie, there is no login event — they are already authenticated. An investigation looking only at authentication events misses this case. The signal is a session without a login explaining it.
This prevents the investigation from becoming a mere collection of indicators. If risk is high and evidence sufficient, follow the organization’s response procedure — preserving relevant records before actions that change session state.
A caution about user confirmation: asking “was that you?” is useful, but the answer alone does not close the case. Someone may have approved MFA under social engineering and honestly answer yes.
Not every strange login is an attack
Before escalating, learn the benign explanations that produce exactly the same signals. They account for most cases:
| Observed signal | Common benign explanation |
|---|---|
| Source in a datacenter or cloud | Corporate VPN, iCloud Relay, company proxy |
| Multiple countries in one day | VPN toggling, carrier roaming |
| Burst of identical authentications | Email client reconnecting after an outage |
| Login outside normal hours | Traveler’s time zone, asynchronous work, on-call duty |
| Unknown device | System update, new browser, replacement device |
| Repeated failures followed by success | Old password saved on a second device |
The second-to-last row creates considerable noise: an operating system update can change the device identifier, making a familiar device appear new.
The last deserves a specific test. If failures come from a device that also has active legitimate sessions, the most likely hypothesis is an outdated credential in a client — not an intrusion attempt. Checking whether failures stop after the person changes the password usually resolves the case.
Knowing these explanations is no reason to dismiss alerts. It enables evidence-based dismissal, recording which benign hypothesis was checked and how — the difference between closing a case and ignoring it.
A simple triage sequence
Before going deeper, answer in order:
- Did the event actually happen? Collection errors and duplication exist.
- Do the identity and asset make sense in that context?
- Are there signs of continued activity or impact?
- Which action reduces risk now?
The sequence separates validation, analysis, and decision — so an unusual observation does not automatically become “compromise”. The order also prevents the costliest triage mistake: escalating based on an event recorded incorrectly by collection.
End with a documented decision
Record the timeline, consulted sources, confidence level, and action taken. A useful record contains the observed fact, hypothesis, missing evidence, owner, and next review time. If uncertainty remains, write it down.
Investigation quality improves when another person can understand why a session was retained, ended, or escalated — including you, three months later, when the same pattern returns.
If data was missing, indicate which logs or correlations would improve the next investigation. This note turns triage into process improvement: a list of missing fields, accumulated over several cases, is the most concrete argument for improving telemetry.
Next step
Take the last authentication alert you investigated and check how many fields from the first table your environment actually records. The answer defines the ceiling of your investigative capability — and is usually lower than expected before checking.
Investigate only systems under your responsibility or with explicit authorization.
