1. The Alert That Requires Immediate Attention

Imagine a SOC analyst receives an alert showing that an account experienced 18 failed login attempts within five minutes, followed by a successful login from the same IP address.

At first, the activity might resemble an employee who repeatedly entered an incorrect password. However, the analyst notices that the successful login occurred from an unfamiliar location and was followed by access to sensitive resources.

The sequence raises an important question: did the legitimate user finally authenticate, or did an attacker eventually guess or obtain the correct credentials?

This is a common authentication investigation scenario in a Security Operations Centre (SOC).

Failed logins are normal in many environments. What matters is the pattern, the context, and the activity that follows.

2. Understanding the Attack Pattern

Multiple failed authentication attempts followed by a successful login can be associated with several different scenarios.

Brute-force attack

An attacker repeatedly tries different password combinations against an account or authentication service.

If one attempt succeeds, the attacker may have discovered a valid password. The risk increases when the account has excessive privileges or lacks appropriate authentication protections.

Password spraying

An attacker attempts a small number of commonly used passwords against many accounts to avoid triggering account-specific lockout thresholds.

Investigators may observe failures across multiple users, sometimes followed by a successful login for one account.

Credential stuffing

An attacker uses username-password combinations obtained from previous data breaches or other sources.

Because some users reuse passwords across services, previously exposed credentials may work against another account.

Legitimate user error

An employee may mistype a password several times before entering it correctly. Expired passwords, saved credentials, or an application repeatedly attempting authentication can also generate failures.

Compromised credentials

An attacker may already possess a valid password and use several failed attempts while testing access, followed by a successful authentication.

The distinction is important: the same alert pattern can represent different underlying causes. Analysts must use supporting evidence before classifying the incident.

3. What Happens During the Attack?

A suspicious authentication sequence can be understood through the following stages.

Stage 1: Repeated authentication failures

The account or service records multiple unsuccessful login attempts. These may originate from one IP address, several addresses, or different devices.

Stage 2: Pattern development

The analyst or detection rule identifies a concentration of failures within a defined time window.

Stage 3: Successful authentication

A subsequent login succeeds. This could be a legitimate user or an attacker using a valid password or another authentication method.

Stage 4: Post-authentication activity

The authenticated session may access email, applications, files, administrative tools, or other resources.

Stage 5: Impact assessment

The investigation determines whether the session was legitimate, whether an account was compromised, and whether any unauthorised activity occurred.

A successful login should therefore be treated as a point requiring further investigation, not automatic proof that an attack succeeded.

4. How SOC Analysts Investigate the Alert

A structured investigation should establish who authenticated, where the attempts originated, why they failed, and what happened after the successful login.

Step 1: Validate the alert

Review the detection details and establish:

• Username and account type.

• Number of failed attempts.

• Time between the first failure and successful login.

• Source IP addresses.

• Authentication protocol or application.

• Device and user-agent information, where available.

• Successful login timestamp.

• Any associated security alerts.

Check whether the alert was generated by a SIEM correlation rule, identity protection service, endpoint product, or cloud security platform.

Step 2: Examine the source IP address

Investigate the source IP using approved threat-intelligence and reputation tools.

Check whether it is associated with known malicious activity, hosting infrastructure, a VPN, a proxy, or a corporate network.

Consider whether the IP has attempted to authenticate against other accounts.

Important: A suspicious reputation score or a foreign IP address does not independently prove malicious activity. VPNs, mobile networks, shared corporate gateways, and legitimate travel can produce unfamiliar source locations.

Step 3: Analyse the failed login pattern

Determine whether the failures target a single account or multiple accounts.

Look for:

• A high volume of failures in a short period.

• Repeated attempts from one source.

• Attempts distributed across many IP addresses.

• Similar password-spray patterns against multiple users.

• Repeated failures against privileged accounts.

• Authentication attempts outside the user's normal activity window.

Compare the pattern with the organisation's authentication baseline and existing detection thresholds.

Step 4: Investigate the successful login

Examine the successful authentication event in detail.

Determine whether the source IP, device, user agent, authentication method, and location are consistent with the user's normal behaviour.

Review multifactor authentication results, conditional access decisions, and risk indicators where the identity platform provides them.

A successful password authentication does not necessarily mean multifactor authentication was completed, nor does it establish that the account owner initiated the session.

Step 5: Review post-login activity

This is one of the most important stages of the investigation.

Look for activity such as:

• Access to sensitive files or mailboxes.

• Unusual downloads or data access.

• New mailbox forwarding rules.

• Changes to authentication methods.

• Creation of new application consent grants.

• Privilege escalation or administrative changes.

• Additional failed and successful logins.

• Unexpected access to other systems.

Correlate timestamps across identity, endpoint, email, and cloud audit logs.

If no suspicious activity is identified, document the evidence and limitations rather than assuming the account is either compromised or completely safe.

Step 6: Determine whether the account is compromised

Use the combined evidence to classify the incident.

Likely legitimate activity: The user confirms the attempts, the device and location are expected, and the surrounding activity matches normal behaviour.

Suspicious authentication: The login pattern is unusual, but evidence is insufficient to establish whether the successful session was malicious.

Confirmed compromise: There is reliable evidence of unauthorised access, such as a confirmed attacker-controlled session, unauthorised account changes, or malicious post-login activity.

The classification should reflect the evidence available at the time and be updated as the investigation progresses.

Step 7: Contain and remediate

If compromise is confirmed or strongly suspected, follow the organisation's incident response procedures.

Actions may include:

• Revoking active sessions and refresh tokens where supported.

• Resetting compromised credentials.

• Reviewing and removing unauthorised authentication methods.

• Enforcing multifactor authentication.

• Blocking confirmed malicious infrastructure.

• Disabling or restricting the account when necessary.

• Investigating other accounts targeted by the same source.

Coordinate with the identity and infrastructure teams to ensure that containment does not unintentionally disrupt critical services.

5. Windows Security Event IDs to Check

For Windows environments, authentication investigations may involve several Security event IDs.

Event IDMeaningInvestigation value4624Successful logonIdentify the successful session and its logon details4625Failed logonInvestigate failed authentication attempts and failure reasons4648Logon using explicit credentialsInvestigate activity involving explicitly supplied credentials4672Special privileges assigned to a new logonIdentify sessions associated with special privileges4768Kerberos authentication ticket requestedInvestigate Kerberos authentication activity4769Kerberos service ticket requestedExamine service-ticket activity following authentication4771Kerberos pre-authentication failedInvestigate certain failed Kerberos authentication attempts4776NTLM credential validationInvestigate NTLM authentication validation activity

Event availability depends on the system, authentication method, audit policy, and log source.

These events provide evidence, but none independently confirms an account compromise. Correlate them with the relevant user, source, host, timestamps, and surrounding activity.

6. Example SIEM Investigation Queries

The following examples illustrate how an analyst could begin investigating the sequence. Field names and syntax may need to be adapted to the organisation's data model.

Splunk: Find failed and successful Windows logons

index=wineventlog (EventCode=4624 OR EventCode=4625) | eval Result=if(EventCode=4624,"Success","Failure") | table _time host user src_ip EventCode Result Logon_Type | sort 0 _time

This query provides a chronological view of Windows successful and failed logon events where the relevant fields are extracted.

Splunk: Investigate repeated failures by source IP

index=wineventlog EventCode=4625 | stats count as FailedAttempts dc(user) as TargetedUsers values(user) as Users by src_ip | sort - FailedAttempts

This helps identify sources associated with a high number of failed logons or attempts against multiple users.

A high count may indicate suspicious activity, but shared gateways, scanners, and misconfigured applications must also be considered.

Microsoft Sentinel: Review failed and successful sign-ins

For Microsoft Entra ID sign-in data available in the SigninLogs table:

SigninLogs | where TimeGenerated > ago(24h) | project TimeGenerated, UserPrincipalName, IPAddress, ResultType, AppDisplayName, Location, UserAgent | order by TimeGenerated desc

This provides a starting point for reviewing recent sign-in events. In this table, successful and failed outcomes can be distinguished using ResultType; confirm the schema and outcome conventions in your environment.

To investigate a particular account, add a filter for its UserPrincipalName and correlate the relevant events around the alert time.

Investigation tip: Start with the alert's exact time window, then expand the search to earlier and later activity. The objective is to reconstruct the sequence rather than simply count failures.

7. Indicators and Evidence to Look For

Evidence sourceWhat to investigateAuthentication logsRepeated failures followed by a successful loginSource IP informationReputation, network ownership, VPN or proxy context, and other targeted accountsDevice informationUnfamiliar devices, operating systems, and user agentsIdentity protectionRisk detections and unusual sign-in indicatorsMultifactor authentication logsUnexpected approvals, failed challenges, or changes to authentication methodsCloud audit logsUnusual access, mailbox changes, and application permissionsEndpoint telemetrySuspicious activity following the successful authentication

The strongest evidence comes from correlating several sources. A successful login following repeated failures is an important signal, but context determines whether it represents an attack.

8. MITRE ATT&CK Mapping

The following techniques may be relevant when supported by the investigation evidence.

TechniqueIDRelevanceBrute ForceT1110Repeated password attempts against an account or servicePassword GuessingT1110.001Attempts using guessed passwordsPassword SprayingT1110.003A small set of passwords attempted against multiple accountsCredential StuffingT1110.004Testing previously exposed username-password combinationsValid AccountsT1078Use of legitimate credentials to access systemsExternal Remote ServicesT1133Relevant when compromised credentials are used through external remote-access services

Do not assign all these techniques to every incident. Select the techniques that match the observed behaviour and available evidence.

9. How Organisations Can Prevent These Attacks

Enable multifactor authentication. Use phishing-resistant methods where feasible, particularly for privileged and high-risk accounts.

Apply intelligent lockout and rate-limiting controls. Reduce repeated password attempts without creating unnecessary disruption for legitimate users.

Monitor authentication patterns. Detect concentrated failures, password spraying, unusual successful logins, and attempts against privileged accounts.

Use conditional access. Apply risk-based access controls where supported, taking account of device compliance, authentication strength, and sign-in risk.

Protect privileged accounts. Separate administrative accounts from everyday accounts and enforce strong authentication requirements.

Block legacy authentication where possible. Older authentication methods may not support modern protections and can increase exposure.

Investigate successful logins after suspicious failures. Correlate the authentication sequence with subsequent account activity instead of treating the successful event as an isolated log entry.

Improve user reporting. Encourage employees to report unexpected authentication prompts and repeated login notifications.

10. Lessons for Modern SOC Teams

Authentication logs are most useful when they are analysed as a sequence of events rather than individual records.

A failed login may be harmless. A successful login may also be legitimate. But a pattern of repeated failures followed by an unexpected success deserves investigation because it may indicate that an attacker obtained valid access.

SOC analysts should combine identity telemetry, source reputation, user context, multifactor authentication records, and post-login activity to determine what happened.

Detection engineering should also account for attacks distributed across multiple IP addresses and accounts, not just a high number of failures from a single source.

Conclusion

Multiple failed logins followed by a successful login can indicate brute-force activity, password spraying, credential stuffing, or legitimate user error. The successful event makes the sequence important, but it does not independently prove compromise.

A reliable investigation establishes the authentication pattern, validates the source, examines the successful session, checks for post-login activity, and applies proportionate containment where necessary.

The key lesson: Do not stop investigating when the login succeeds. Determine who gained access, whether the session was legitimate, and what happened next.

Further Reading

• Microsoft Learn — Windows logon auditing and Microsoft Entra sign-in logs.

• MITRE ATT&CK — Brute Force and Valid Accounts techniques.

• CISA — Identity security and multifactor authentication guidance.