How to check for suspicious logins

Topic: Security basics

Review auth logs for failed logins, logins from unexpected IPs or times, and new device or location. Use centralized logs and alerts to detect takeover or abuse. Use this when investigating a reported incident or building detection.

Intent: How-to

Quick answer

  • Search auth logs for the user: last, lastlog (Linux); cloud IdP sign-in logs; application login logs. Look for IPs or locations the user does not recognize, or logins at unusual times.
  • Many failed logins then success may indicate password guessing. Logins from a new country or ASN, or impossible travel (two locations in short time), warrant verification with the user.
  • Alert on patterns: many failures, success after failures, admin login from new IP. Tune to reduce false positives; have a runbook to revoke or challenge the session when suspicious.

Prerequisites

Steps

  1. Gather auth logs

    Collect login events from OS (last, lastlog, auth.log), IdP (Azure AD, Okta, GSuite sign-in), and application logs. Ensure logs include user, IP, time, success or failure, and optionally device or location.

  2. Search for anomalies

    Filter by user or time range. Look for failed then successful logins, logins from unknown IPs or countries, or logins at unusual hours. Compare to the user normal pattern if available.

  3. Correlate and verify

    If a session looks suspicious, contact the user to confirm (out-of-band). If not the user, revoke the session and password; force MFA re-enrollment; investigate how the account was compromised.

  4. Automate detection

    Create alerts for many failures, success after failures, admin from new IP, or impossible travel. Runbook: notify user or security, revoke session, rotate credentials, investigate.

Summary

Use auth logs to find failed logins, unknown IPs, and unusual times. Verify with the user; revoke and rotate if compromised. Use alerts and a runbook for consistent response.

Prerequisites

Steps

Step 1: Gather auth logs

Collect login events from OS, IdP, and apps. Include user, IP, time, success/failure.

Step 2: Search for anomalies

Look for failures then success, unknown IPs or locations, unusual times. Compare to normal behavior.

Step 3: Correlate and verify

Contact the user out-of-band. If not them, revoke session and password; force MFA; investigate.

Step 4: Automate detection

Alert on failure spikes, success after failures, admin from new IP. Runbook: notify, revoke, rotate, investigate.

Verification

You can find login events by user and time; anomalies are identified and verified; revoke and rotation are documented and tested.

Troubleshooting

Too many false positives — Tune thresholds; allowlist known VPNs or offices; focus on high-value accounts first. No centralized logs — Start with critical systems and IdP; add app logs over time.

Next steps

Continue to