how to investigate a suspicious login alert

how to investigate a suspicious login alert

TL;DR

Verify the login details first, then check what the session did. Start with time, IP, location, and device, then look for post-login damage like password resets, new MFA methods, or mail forwarding. Talk to the user out of band before you touch anything, so you dont tip off an attacker or lock out a legit employee on a trip.

how to investigate a suspicious login alert

Use this when

• your SIEM or identity provider flags a login as suspicious
• a user reports "I got a login notification I dont recognize"
• an impossible travel alert survived tuning and needs a human look
• you need a repeatable triage process instead of winging it each time

Not for this skill when

• the account takeover is already confirmed (move to the containment skill)
• the suspicious activity is API key usage, not an interactive login
• you are doing a routine access review with no alert behind it
• the alert is about impossible travel noise in general (that is a tuning problem)

Steps

1. Pull the full login record. Time in UTC, source IP, geo, user agent, device ID, whether MFA passed and which method:

index=auth user=[username] action=login
| table _time, src_ip, city, user_agent, mfa_result, device_id

Expected: one row per login attempt. Flag any IP, city, or device you have never seen for this user.

1. Reputation-check the IP. Look it up in your threat intel feed or abuse database. A residential ISP in the user's home city is a very different story from a datacenter range in another country.

1. Check what happened after the login. In the two hours after it, look for password changes, MFA enrollments, mail forwarding rules, OAuth app grants, and large file downloads:

index=auth user=[username] earliest=-2h
| search action IN (password_change, mfa_enroll, mail_rule_create, oauth_grant)
| table _time, action, details

Expected: empty is good news. Any row here is bad news and moves the case to containment.

1. Check the same credential elsewhere. If the user reuses passwords across systems, search your other auth logs for the same username from the same IP. One bad login often means several.

1. Contact the user out of band. Call or message them on a known-good number, not email, since their email may be compromised. Ask plainly: were you logging in from [city] at [time]?

1. Decide: legit, suspicious, or confirmed bad. Legit gets documented and closed. Suspicious gets a forced password reset plus session revocation. Confirmed bad moves to the compromised-account containment skill immediately.

Variant: investigating when the user is unreachable

If the user is on a plane or on leave, dont wait. Treat it as suspicious by default: force the password reset, revoke sessions, and leave a note for the user to contact security when they are back. You can always apologize; you cant un-exfiltrate.

Variant: investigating a service account login

There is no human to ask, so compare against the account's known behavior instead: expected source IPs, expected times, expected actions. Anything outside the baseline is suspicious until the owning team explains it.

Variant: investigating an admin or privileged login

Same steps, faster clock, wider blast radius check. For admins, also review what commands or config changes ran in the session, and consider whether other admins' credentials need rotation.

Why this happens

Stolen credentials are the most common way attackers get in, and login alerts are noisy by nature. Without a consistent triage process, teams either ignore the alerts or overreact to every one. The process above turns "suspicious login" into a decision in about 20 minutes.

Edge cases and pitfalls

• The user is on vacation or traveling. Check their calendar or ask their manager before you conclude anything.
• Corporate VPN exits can look foreign. Know your egress geography or you will chase your own infra.
• Session token replay shows no new login at all. If the user swears they werent active but data moved, check for stolen sessions, not just logins.
• Dont reset the password before talking to the user unless damage is actively happening. A surprise lockout at 2am makes enemies of the people you need cooperating.
• Log every step with timestamps. If this becomes a real incident, your triage notes are the first page of the report.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstxzN47csAqNxZgUn12PJoA