Master authentication log analysis — distinguishing credential stuffing, password spraying, and brute force by their log signatures, identifying impossible travel and MFA fatigue attacks, understanding what attackers do in the 90 seconds after gaining access, and executing the complete account compromise response playbook.
Suspicious Login Triage
Unauthorised account access is one of the most common incidents a SOC handles. Attackers use credential stuffing, password spraying, or brute force to compromise corporate accounts. When authentication logs show unusual patterns, a SOC analyst must investigate quickly — the window between a successful login and an attacker establishing persistence or exfiltrating data is often measured in minutes, not hours.
Why Authentication Anomalies Demand Rapid Response
The 90-second post-login activity in Example 04 is not an exaggeration — it reflects the real operational pace of sophisticated attackers who have automated their post-compromise actions. Mail forwarding rules, SharePoint downloads, and admin privilege grants are all achievable through web interfaces with pre-scripted actions. An analyst who receives a suspicious login alert and takes 30 minutes to investigate may be investigating an account that has already been fully weaponised.
Imagine a building with 500 employees, each with a different keycard PIN. Credential stuffing is like having a stolen list of 10,000 PINs leaked from another building and trying every PIN from the list against every door — you're betting that some employees reused their old PIN. Password spraying is like trying one very common PIN (1234) against every door — staying under the lockout limit by spreading attempts across accounts rather than hammering one. Brute force is like sitting at one door and trying every possible combination — inevitably triggering the lockout mechanism. All three leave very different patterns in the access log, and each requires a different response.
Authentication Log Analysis
Timestamp When did it happen? Time zone matters for impossible travel calculation. Username Which account was targeted? Is it a privileged account? Source IP Where from? Geolocation? VPN or Tor exit node? ASN reputation? Result Successful login or failure? Failure reason code? MFA Was MFA challenged? What method? Did the user actually approve? User Agent Browser and OS — consistent with the user's normal device profile? Session What did the account do after logging in? Mail rules? Downloads? Admin changes?
Suspicious Login Patterns
Stuffing attempts many accounts from one IP in rapid succession — the distribution across accounts is the signature. One or more successes in a fast-moving list confirms a breach database match.
09:14:22 [email protected] 45.33.32.156 FAIL 09:14:23 [email protected] 45.33.32.156 FAIL 09:14:24 [email protected] 45.33.32.156 SUCCESS 09:14:25 [email protected] 45.33.32.156 FAIL # Same IP, many different accounts, 1 second apart = credential stuffing # Breach list being tested at automated speed against this environment
Two successful logins from geographically distant locations within a timeframe that makes physical travel impossible — one of the highest-confidence account compromise indicators available.
08:45:12 j.smith SUCCESS 82.45.12.33 (London, UK) 09:12:44 j.smith SUCCESS 104.28.17.91 (Chicago, IL) # 27 minutes between London and Chicago -- physically impossible # The 09:12 login is the attacker. Disable account, contact user immediately, # review all session activity in the 09:12 window
Attacker spams push notifications until a frustrated user approves to make them stop — exploiting notification fatigue rather than any technical vulnerability in MFA itself.
14:22:01 MFA push to j.smith DENIED 14:22:08 MFA push to j.smith DENIED 14:22:15 MFA push to j.smith DENIED 14:22:31 MFA push to j.smith APPROVED # 30 seconds, 4 pushes -- attacker gains immediate access after frustration-approval # Mitigated entirely by number matching (user must enter code shown on screen)
After confirming a suspicious login, the post-login session is the most operationally critical evidence — it shows what the attacker achieved with the access before containment.
09:12:44 Login from Chicago IP (confirmed attacker) 09:13:02 Exchange: mail forwarding rule created → all mail to [email protected] 09:13:45 SharePoint: downloaded Q3_Financials.xlsx 09:14:12 Azure AD: added [email protected] as Global Admin # Persistence (mail forward) + exfiltration (financials) + privilege escalation # (Global Admin) in 90 seconds. Account was fully weaponised before containment.
What You Need to Know
Credential Attack Types — Signatures and Responses
The three primary credential attack types each produce distinctly different patterns in authentication logs. Correctly identifying which type is underway in the first 2 minutes of triage determines the entire response path — including which accounts to prioritise, whether to block IPs or reset passwords, and whether the attack is likely over or still in progress.
| Attack Type | Log Pattern | Scale | Primary Response |
|---|---|---|---|
| Credential Stuffing | Many different usernames, same IP or small IP range, rapid succession (sub-second). One or more successes in the list. | Hundreds to thousands of accounts tested from breach database. | Block source IPs. Identify all successes — force password reset on each. Check if successful accounts have MFA enrolled. |
| Password Spraying | One or a few passwords tried against many accounts, distributed across many IPs, slow rate (one attempt per account per hour to stay under lockout threshold). | Typically targets entire org with 2–3 common passwords: "Company2024!", "Welcome1", "Password1". | Very hard to detect at the per-account level — requires aggregate view across all accounts. Implement lockout thresholds that count distributed attempts. Deploy CAPTCHA or smart lockout. |
| Brute Force | Many passwords, one account, typically one or a few IPs. Account lockout fires quickly. Often targeting a service account without lockout policy. | Single account targeted. Generates high volume of Event 4625 against one username. | Block attacking IPs. Review why target account has no lockout — service accounts should have lockout or IP-restricted access. Check if attack succeeded before lockout. |
| MFA Fatigue | Multiple rapid MFA push challenges to same user, then a single approval. Often preceded by a successful password authentication from an unusual IP. | Typically targeted — attacker already has the password and is overcoming the MFA factor. | Disable account immediately. Deploy number matching for all push-based MFA. Alert on 3+ MFA push denials from same user in 5 minutes. |
What Attackers Do Immediately After Login — The 90-Second Window
The post-login session audit is the most operationally critical step in suspicious login investigation. It answers whether the attacker achieved their objective before containment and determines the true scope of the incident. Understanding the specific actions attackers take — and the log sources that record them — allows analysts to check methodically rather than searching blindly.
The Standard Post-Compromise Action Sequence
- Mail forwarding rule: Creates a rule in Exchange/Microsoft 365 to forward all incoming mail to an external attacker-controlled address. Provides ongoing intelligence about the target's communications after the account is locked. Check: Exchange admin centre or
Get-InboxRulein Exchange PowerShell. Alert on any forwarding rule created from an unusual IP or outside business hours. - Data exfiltration: Downloads high-value files from SharePoint, OneDrive, or file shares. Often guided by the content of recently received email (e.g., downloading the financial report mentioned in an email just received). Check: SharePoint audit logs, OneDrive activity logs, unified audit log in Microsoft 365.
- Privilege escalation: If the compromised account has any admin rights, adds an attacker-controlled account as Global Admin, adds the attacker's external email to a privileged group, or grants the compromised account additional permissions. Check: Azure AD audit log for role assignment events, group membership changes.
- New OAuth app consent: Tricks the user (or exploits existing permissions) into consenting to a malicious OAuth app that provides persistent API-level access to the account even after the password is reset. Check: Azure AD enterprise applications for new or suspicious consented apps.
- MFA modification: Registers a new MFA device (phone number, authenticator app) under the attacker's control, ensuring they can re-authenticate even after the victim's password is changed. Check: Azure AD authentication methods audit log for new device registrations.
Systematically auditing every post-login action category to establish the full scope of what an attacker achieved in a 6-minute access window before the account was locked.
--- Suspicious login confirmed: j.smith, Chicago IP at 09:12:44 --- # Check 1: Mail forwarding rules Get-InboxRule -Mailbox j.smith | Select Name,ForwardTo,ForwardAsAttachmentTo AllMail ForwardTo: [email protected] (created 09:13:02) # Check 2: SharePoint/OneDrive downloads in session window Unified Audit Log query: j.smith, 09:12-09:19, FileDownloaded Q3_Financials.xlsx (SharePoint, 09:13:45) BD_Strategy_2026.pptx (OneDrive, 09:14:33) # Check 3: Azure AD role changes 09:14:12 Add member to Global Administrators New member: [email protected] # Check 4: New MFA device registrations 09:15:03 Authentication method added Type: Microsoft Authenticator Phone: +1-555-0193 (NOT j.smith's registered number) # Check 5: OAuth app consents No new OAuth consents in window. # Scope summary: Mail forwarding active, 2 files exfiltrated, # Global Admin added, new MFA device registered. # Incident severity: CRITICAL. All 4 actions must be reversed.
Account Compromise Response — The Complete Checklist
Account compromise response has a specific ordering requirement: some actions taken out of sequence can alert the attacker, destroy evidence, or fail to stop ongoing harm. The checklist below follows the correct operational sequence.
- Disable the account immediately — not password reset, but account disable. Password reset alone doesn't terminate active sessions; disabling the account does. In Azure AD:
Set-AzureADUser -AccountEnabled $false. This is the first action regardless of any other investigation step. - Revoke all active sessions — expired the session tokens so any active authenticated sessions from the attacker's browser or API client are terminated. In Azure AD:
Revoke-AzureADUserAllRefreshToken. Password reset alone doesn't revoke existing session tokens in most platforms. - Remove attacker-created persistence — in order: delete any mail forwarding rules, remove attacker-added accounts from privileged groups, remove attacker-registered MFA devices, revoke attacker-consented OAuth app permissions. Remove Global Admin grant before re-enabling the account.
- Reset the password — only after session revocation and persistence removal. Set a new, random password. Do not restore the user's previous password.
- Re-enrol MFA with the user present — if an attacker registered a new MFA device, that device is now associated with the account. Clear all MFA registrations and have the user re-enrol through a verified channel with the help desk present.
- Re-enable the account — only after all above steps are confirmed complete.
- Notify the user — inform them of what happened, what was accessed, and what they need to do (verify no personal accounts were compromised, check their phone for new MFA apps they didn't install).
- Review and preserve evidence — export the full audit log for the session window before any retention policy purges it. Document the timeline, attacker IP, actions taken, and files accessed for the incident record.
14:22 — Alert: SIEM fires "Multiple MFA push denials — same user" for j.smith (3 denials in 30 seconds). Analyst pulls the authentication log. j.smith's password was successfully validated at 14:21:58 from an IP in Romania. This is not a push notification error — it's a real attacker with the correct password.
14:23 — Containment race: At 14:22:31, j.smith approved the 4th push notification. The analyst is 52 seconds behind. Immediate action: disable the account in Azure AD. Session revocation issued simultaneously.
14:24 — Scope check: Post-login audit of the 2-minute window (14:22:31–14:24:00 when account was disabled): mail forwarding rule to gmail.com created at 14:22:48. No file downloads. Azure AD: Global Admin granted to [email protected] at 14:23:33. New MFA authenticator app registered at 14:23:41.
14:26 — Persistence removal: Mail forwarding rule deleted. [email protected] removed from Global Administrators. MFA devices cleared for j.smith account. The attacker's Global Admin account ([email protected]) is a guest account — disabled and flagged for investigation.
14:30 — Re-enable: Password reset to random 24-character string. j.smith called directly to verify identity and begin MFA re-enrolment on help desk call. Account re-enabled after MFA confirmed.
14:34 — Root cause: j.smith's password was in a breach database (Collection #1). Credential stuffing campaign tested it earlier in the week and noted it was valid. MFA fatigue attack launched with the valid password. Recommendation: deploy number matching for all Microsoft Authenticator push approvals, eliminating blind-approval fatigue attacks.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — IR03 Suspicious Login→← Return to all labs