How to investigate a suspicious login

Updated October 2026 · About 7 minutes to read

“Suspicious sign-in” and “impossible travel” alerts are among the most common identity alerts in any SOC. Many are false positives caused by VPNs or travel — but some are the first sign of an account takeover. This guide walks through a structured investigation using a Microsoft 365 example.

The scenario

An alert fires for a user, Sarah, who normally signs in from Manila. The sign-in log shows:

You can practice incidents like this in the Cyber Career Lab SOC Analyst simulator. Here is how to approach it.

Step 1: Build the timeline

Put every sign-in event in order and note the gaps. Two locations thousands of kilometres apart within minutes cannot both be the user physically. Failed attempts followed by a success from the new location is a classic pattern of an attacker trying, then succeeding with, a valid password.

Step 2: Check the source IP

• Look up the IP’s reputation, owner and whether it belongs to a VPN, proxy, Tor exit node or hosting provider.
• Check whether other accounts in your organization saw sign-in attempts from the same IP — that suggests password spraying.
• Remember geolocation is approximate; the owner of the IP is often more useful than the city.

Step 3: Compare with normal behavior

Review the user’s sign-in history over the past weeks. Do they ever use a VPN? Do they travel? Is the device, browser and operating system familiar? A brand-new device and user agent from an unusual network raises suspicion significantly.

Step 4: Review MFA and authentication details

• Was MFA required, and was it satisfied? By which method?
• Were there many MFA prompts in a short time? That may be an MFA fatigue attack.
• Was a legacy protocol used that bypasses MFA?
• Did conditional access policies apply, or were they skipped?

Step 5: Check what happened after the sign-in

A successful malicious sign-in is only the start. Look at the session’s activity: new inbox rules (attackers often hide replies), mail forwarding, mass downloads from file storage, new MFA methods registered, OAuth app consents and emails sent to internal or external contacts.

Step 6: Decide and respond

If the evidence points to compromise:

1. Revoke the user’s active sessions and reset the password.
2. Remove any malicious inbox rules, forwarding or MFA methods.
3. Block the malicious IP where appropriate.
4. Check whether the same IP targeted other accounts.
5. Find out how the password was obtained — a recent phishing email is a common source (see phishing email analysis).
6. Document and escalate according to your process.

If the evidence shows a benign cause, close the alert as a false or benign positive and record why, so the next analyst does not repeat the work.

Common false positives

• Corporate or personal VPNs that exit in another country.
• Mobile networks that geolocate inaccurately.
• Users genuinely traveling.
• Cloud services or applications signing in on the user’s behalf.

The skill is not memorising which alerts are bad — it is gathering enough evidence to be confident either way.