Lab 03 Suspicious Authentication Investigation

Mission Overview

Welcome to Lab 03 — Suspicious Authentication Investigation.

In Lab 02, you learned how to triage alerts, add asset and identity context, identify duplicates, assign priority, and decide whether an alert should be closed, investigated, or escalated.

Now you will take one suspicious authentication alert and investigate it in depth.

Authentication alerts are among the most common SOC events because failed or unusual logins can be caused by many different things:

user error
expired passwords
stale credentials
service-account issues
password spraying
brute-force attempts
compromised accounts
unexpected administrative activity
access from unfamiliar systems
legitimate remote work
scheduled automation

The goal is not to assume compromise.

The goal is to determine what the evidence actually supports.

Mission Goal: Investigate suspicious authentication activity by correlating user, host, source IP, timestamps, account privilege, baseline behavior, and related telemetry to determine whether the activity represents expected behavior, an operational issue, or a potential account compromise.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	120–150 minutes
Primary Skill	Authentication Investigation
Secondary Skill	Identity & Access Analysis
Environment	GoHackersCloud SOC Analyst Lab
Input	Authentication alert + Windows/Linux/SIEM evidence
Primary Outcome	Authentication Investigation Report
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

investigate failed authentication
analyze successful logins following failures
assess source IP addresses
correlate usernames with expected systems
identify privileged accounts
identify service-account activity
assess login timing
distinguish user error from suspicious behavior
understand account lockout events
recognize password-spray patterns
recognize brute-force patterns conceptually
correlate authentication events across hosts
compare observed behavior with a user baseline
identify related endpoint and network activity
reconstruct an authentication timeline
determine potential account-compromise scope
assign severity and confidence
define escalation and containment recommendations
write a defensible authentication investigation report

Investigation Methodology

Use:

Identity → Authentication Event → Source → Timeline → Baseline → Correlate → Scope → Conclusion

Conceptually:

Authentication Alert
        │
        ▼
Identify Account
        │
        ▼
Identify Source
        │
        ▼
Review Success / Failure
        │
        ▼
Build Timeline
        │
        ▼
Compare with Baseline
        │
        ▼
Correlate Other Evidence
        │
        ▼
Determine Scope
        │
        ▼
Disposition / Escalation

The core principle is:

Authentication events show access attempts. They do not, by themselves, prove account compromise.

Part 1 — Create the Case Workspace

Create:

SOC-Labs/
└── Lab-03/
    ├── 01-Scope/
    ├── 02-Alert/
    ├── 03-Authentication-Logs/
    │   ├── Windows/
    │   ├── Linux/
    │   └── Identity/
    ├── 04-Asset-Context/
    ├── 05-Identity-Context/
    ├── 06-Network-Context/
    ├── 07-Endpoint-Context/
    ├── 08-Correlation/
    ├── 09-Timeline/
    ├── 10-Evidence/
    ├── 11-Screenshots/
    ├── 12-Findings/
    └── 13-Report/

Create:

Lab-03-Suspicious-Authentication-Investigation.md

Part 2 — Open the Investigation Case

Use:

CASE ID:
GHC-SOC-2026-003

CASE TITLE:
Suspicious Authentication Investigation

STATUS:
Investigating

INITIAL PRIORITY:
P2 / P3

ALERT SOURCE:
Training SIEM

ANALYST:

DATE:

Part 3 — Review the Initial Alert

Assume the following simulated alert:

ALERT ID:
ALT-AUTH-001

ALERT:
Multiple Failed Authentication Attempts Followed by Successful Login

USER:
jdoe

TARGET:
WIN01

SOURCE IP:
10.10.20.55

FAILURES:
12

SUCCESSFUL LOGIN:
Yes

TIME WINDOW:
10 minutes

INITIAL SEVERITY:
High

Do not immediately conclude:

Account compromised.

Your first question should be:

Does the source, timing, user, host, and sequence match expected behavior?

Part 4 — Record the Alert Metadata

Create:

ALERT METADATA

Alert ID:

Alert Name:

Detection Time:

Event Start:

Event End:

User:

Target Host:

Source IP:

Authentication Type:

Failed Attempts:

Successful Authentication:

Initial Severity:

Detection Source:

Raw Evidence Reference:

Part 5 — Identify the Account

Consult the Identity Register from Lab 01.

Example:

USER:
jdoe

ACCOUNT TYPE:
Human User

ROLE:
Finance Analyst

PRIVILEGED:
No

EXPECTED WORKSTATION:
WIN01

NORMAL WORK HOURS:
09:00–18:00

REMOTE ACCESS:
Occasional

DEPARTMENT:
Finance

Part 6 — Determine Whether the Account Is Privileged

Privileged accounts may include:

domain administrators
server administrators
database administrators
cloud administrators
security administrators
service accounts with elevated access

Record:

Privileged:
Yes / No

If Yes:
Privilege Type:

Critical Systems Accessible:

Additional Escalation Required:
Yes / No

Part 7 — Identify the Target Asset

Example:

HOST:
WIN01

ROLE:
Finance Workstation

OWNER:
jdoe

CRITICALITY:
Medium

EXPECTED USER:
jdoe

EXPECTED LOGIN SOURCES:
Local / Corporate VPN

If the user normally accesses WIN01, that matters.

If they normally never access it, that matters too.

Part 8 — Investigate the Source IP

Record:

SOURCE IP:
10.10.20.55

KNOWN DEVICE:
Yes / No

HOSTNAME:

NETWORK SEGMENT:

VPN:
Yes / No

USER'S NORMAL SOURCE:
Yes / No

ASSET OWNER:

EXPECTED:
Yes / No / Unknown

Do not interpret a new IP address automatically as malicious.

Part 9 — Understand Possible Source-IP Explanations

A source IP may represent:

user’s workstation
VPN gateway
jump host
proxy
administrator workstation
service
mobile connection
shared terminal
unexpected host

Always interpret the IP in architecture context.

Part 10 — Build the Initial Authentication Timeline

Create:

Time UTC	Event	User	Source	Target
10:02	Failed Login	jdoe	10.10.20.55	WIN01
10:03	Failed Login	jdoe	10.10.20.55	WIN01
10:05	Failed Login	jdoe	10.10.20.55	WIN01
10:10	Successful Login	jdoe	10.10.20.55	WIN01

Populate with actual training evidence.

Part 11 — Analyze Failure Count

Ask:

How many failures?

Over what period?

Same user?

Same source?

Same target?

Same authentication method?

Was there a successful login afterward?

Patterns matter more than raw count.

Part 12 — User Error Pattern

A pattern such as:

jdoe
same workstation
same target
5 failures
success shortly after
normal business hours

may indicate:

User entered an incorrect password repeatedly.

This is a hypothesis, not a final conclusion.

Part 13 — Brute-Force Pattern Concept

A possible brute-force pattern may look like:

Same user
Same source
Many failures
High frequency
Extended duration

Do not simulate brute force in this lab.

You are analyzing supplied evidence only.

Part 14 — Password-Spray Pattern Concept

A possible spray pattern may look like:

One source
      ↓
User A — few failures
User B — few failures
User C — few failures
User D — few failures

The attacker may attempt a small number of passwords across many accounts.

Remember:

Many Users + Few Attempts Each

can be more important than:

One User + Many Attempts

depending on context.

Part 15 — Create the Authentication Pattern Register

Pattern	Observed	Evidence
One user, one source
One user, multiple sources
Multiple users, one source
Repeated failures
Success after failures
Account lockout
Privileged account involved

Part 16 — Check for Successful Authentication

A successful login following failures is important.

But always distinguish:

Failure → Success

from:

Attack → Compromise

Possible explanations include:

user finally typed the correct password
cached password corrected
legitimate administrator action
attacker obtained the correct credential

You need context.

Record:

SUCCESS EVENT

Time:

User:

Source:

Target:

Authentication Method:

Interactive / Remote / Service:

Session Type:

MFA:
Yes / No / Unknown

Privilege:

Expected:
Yes / No / Unknown

Part 18 — Review Windows Authentication Events

Where the lab uses Windows logs, investigate relevant successful and failed authentication events.

Focus on:

timestamp
account
source
target
logon type
status
related event sequence

Do not memorize event IDs as the primary skill.

Use the event meaning and context.

Part 19 — Understand Logon Types Conceptually

Different login types may represent:

local interactive login
network login
remote interactive login
service login
batch job
cached login

The security significance depends on the expected use.

Part 20 — Review Linux Authentication Where Applicable

If the account or source interacts with Linux systems, review:

/var/log/auth.log

or:

/var/log/secure

or:

journalctl

Look for:

failed SSH login
successful SSH login
sudo events
user switching
account activity

Use read-only investigation.

Part 21 — Check Whether Other Accounts Were Targeted

This is critical.

Search the same source IP for activity involving other accounts.

Create:

User	Failures	Success	Target
jdoe	12	Yes	WIN01
alice	2	No	WIN02
bob	2	No	WIN03

If many accounts are involved, your investigation may move toward password spraying.

Part 22 — Create the Source-IP Authentication Profile

SOURCE IP PROFILE

IP:

Known Host:

Associated User:

Network Zone:

Authentication Events:

Unique Users:

Successful Logins:

Failed Logins:

Privileged Accounts Targeted:

Expected Activity:

Risk Assessment:

Part 23 — Check Whether the Same Account Appears from Multiple Sources

Create:

Source	Failures	Success	Time
10.10.20.55	12	Yes	10:00
10.10.50.10	3	Yes	10:05

This could indicate:

VPN transition
user moving networks
multiple devices
shared account
account misuse

Do not assume compromise without context.

Part 24 — Check for Geographic Impossibility Conceptually

If your lab supplies geographic context, compare:

09:50 — Login from Location A
10:00 — Login from Location B

If travel between them is impossible, the event deserves review.

But remember:

VPN
proxy
cloud gateway
mobile network

may alter apparent location.

Part 25 — Compare Against the User Baseline

Create:

USER BASELINE

User:

Normal Workstation:

Normal Source Network:

Normal Login Hours:

Normal Applications:

Normal Remote Access:

Normal Privileged Access:

Known Recent Changes:

Current Event Matches Baseline:
Yes / Partially / No

Part 26 — Build the Baseline Deviation Matrix

Characteristic	Normal	Observed	Deviation
Time	09:00–18:00	10:05	No
Source	WIN01	WIN01	No
Target	WIN01	WIN01	No
Location	Corporate	Corporate	No
Failures	Rare	12	Yes

A single deviation may not mean compromise.

Part 27 — Review Account Lockout Activity

If the account was locked:

Record:

ACCOUNT LOCKOUT

User:

Time:

Source:

Failures Before Lockout:

Other Users Locked:

Expected:
Yes / No

Impact:

Account lockout can indicate:

repeated user mistakes
stale password in application
scripted login
malicious attempts

Part 28 — Investigate Stale Credentials

A common SOC case involves a user’s password changing while another application keeps using the old password.

Pattern:

Password Changed
       ↓
Old Credential Stored in App
       ↓
Repeated Failures
       ↓
Account Lockout

Check supplied operational evidence before declaring an attack.

Part 29 — Check Service Accounts

Service accounts may authenticate frequently.

Questions:

Is this a service identity?

What host should use it?

What service uses it?

Is the source expected?

Was the password recently changed?

Are failures occurring repeatedly?

Service-account failures often indicate configuration issues.

Part 30 — Create the Service Account Profile

SERVICE ACCOUNT:

Purpose:

Expected Hosts:

Expected Authentication Frequency:

Privileged:
Yes / No

Observed Source:

Observed Target:

Expected:
Yes / No

Failures:

Potential Cause:

Part 31 — Correlate Endpoint Telemetry

If a suspicious successful login occurred, check the target endpoint around the login time.

Look for:

new processes
administrative tools
script execution
unusual child processes
security alerts
new network connections

Do not assume the login was malicious merely because PowerShell appears.

Part 32 — Build the Endpoint Correlation Register

Time	Process/Event	User	Relevant
10:11	Browser launched	jdoe	Normal
10:13	PowerShell	jdoe	Review
10:15	EDR alert	jdoe	High

Part 33 — Correlate Network Evidence

Review:

DNS
firewall
proxy
VPN
remote access

for the affected user and host around the authentication event.

Example:

Authentication Success
        ↓
DNS Query
        ↓
External Connection

This may deserve deeper investigation.

Part 34 — Build the Network Correlation Register

Time	Source	Destination	Protocol	Assessment

Part 35 — Correlate VPN Evidence

If authentication came through remote access, assess:

VPN LOGIN

User:

Source IP:

VPN Gateway:

MFA Result:

Device:

Timestamp:

Session Duration:

Expected:

A VPN gateway IP may appear as the authentication source rather than the user’s actual endpoint.

Part 36 — Check MFA Evidence

If MFA is part of the lab:

Record:

MFA CHALLENGE:

MFA SUCCESS:

MFA FAILURE:

MFA METHOD:

Expected Device:

Unusual Prompts:

Assessment:

Do not interpret:

MFA success

as proof the user personally authorized it.

But it is significant evidence.

Part 37 — Correlate Privileged Activity

If a privileged account is involved, immediately assess:

source
target
maintenance window
ticket/change reference
MFA
administrative actions after login

Raise priority if activity is unexpected.

Part 38 — Build the Privileged Authentication Register

User	Source	Target	Expected	Change Ticket
admin01

Find:

same user
same source
same host
same time range

Possible related alerts:

Failed Authentication

Account Lockout

Successful Login

Privileged Login

Impossible Travel

New Device

MFA Failure

Part 40 — Build the Alert Correlation Matrix

Alert	User	Source	Target	Time	Related

Part 41 — Build the Master Authentication Timeline

Example:

09:58
First failed authentication

10:00
Additional failures

10:03
Account lockout threshold approached

10:05
Successful authentication

10:07
Endpoint session begins

10:08
DNS query

10:09
Normal application activity

10:20
User logs out

Use one master timezone.

Part 42 — Separate Event Time from Ingestion Time

For important events record:

Event Time	Ingestion Time	Delay
10:05:00	10:05:30	30 sec

This prevents SIEM arrival order from being mistaken for actual sequence.

Part 43 — Build Initial Hypotheses

Example:

Hypothesis 1 — User Error

The user repeatedly entered an incorrect password and then
successfully authenticated.

Hypothesis 2 — Stale Credentials

An application or service is repeatedly attempting an old password.

Hypothesis 3 — Credential Attack

An unauthorized system attempted to obtain access to the account.

Hypothesis 4 — Account Misuse

A valid credential may have been used from an unexpected system.

Part 44 — Create the Hypothesis Matrix

Hypothesis	Supporting Evidence	Contradicting Evidence	Confidence
User error	Same source	High failure count	Medium
Spray	Other users targeted	None
Compromise	Unusual source	Normal host

Part 45 — Avoid Confirmation Bias

Do not decide:

Compromise

and then look only for evidence supporting compromise.

For every hypothesis collect:

Evidence For

Evidence Against

Evidence Missing

Part 46 — Determine Account Scope

Ask:

Was one account affected?

Multiple accounts?

One host?

Multiple hosts?

Privileged identities?

Service accounts?

Remote access accounts?

Create:

ACCOUNT SCOPE

Affected Accounts:

Privileged Accounts:

Service Accounts:

Successful Suspicious Logins:

Failed-Only Accounts:

Known Compromise:
Yes / No / Unconfirmed

Part 47 — Determine Host Scope

Create:

Host	Related Authentication	Other Suspicious Activity
WIN01	Yes
WIN02

A suspicious account may have authenticated to more than one system.

Part 48 — Build the Scope Matrix

Entity	Known	Suspected	Unaffected
Users
Hosts
Privileged accounts
Services

Part 49 — Evaluate Indicators of Account Misuse

Potential indicators include:

unfamiliar source
unfamiliar device
unexpected time
unexpected target
unexpected privilege usage
multiple unrelated systems
successful authentication following distributed failures
suspicious endpoint activity after login
unusual external communication

No single indicator is definitive.

Part 50 — Identify Positive Controls

Examples:

MFA challenge rejected.

Account lockout stopped repeated attempts.

Authentication restricted by source.

EDR found no suspicious post-login activity.

Privileged login limited to management workstation.

Suspicious authentication blocked.

Positive controls should be included in the investigation.

Part 51 — Build the Authentication Control Matrix

Control	Status	Evidence
MFA
Lockout
Source restriction
Privileged separation
Logging
Alerting

Part 52 — Determine the Disposition

Use:

Expected Activity

Evidence confirms legitimate authentication.

Operational Issue

Example:

stale credentials

Suspicious — Investigate Further

Evidence is unusual but incomplete.

Potential Account Compromise

Multiple indicators support unauthorized use.

Confirmed Account Compromise

Use only when evidence clearly demonstrates unauthorized account use.

Inconclusive

Evidence is insufficient.

Part 53 — Example — User Error

DISPOSITION:
Expected User Authentication Failure

EVIDENCE:
All failed and successful logins originated from the user's normal
workstation during normal business hours.

No other accounts were targeted.

No abnormal endpoint or network activity followed authentication.

CONCLUSION:
Evidence is consistent with the user entering an incorrect password
multiple times before successfully authenticating.

CONFIDENCE:
High

Part 54 — Example — Stale Credential

DISPOSITION:
Operational Authentication Issue

EVIDENCE:
Repeated failures occur at fixed intervals from an approved
application server using a service account.

Successful interactive logins for the same account are not present.

The service credential was recently changed.

CONCLUSION:
Evidence is consistent with an application continuing to use a
stale credential.

SECURITY IMPACT:
Account lockout / monitoring noise.

ESCALATION:
Application owner.

Part 55 — Example — Potential Password Spray

DISPOSITION:
Potential Security Incident

EVIDENCE:
A single unfamiliar source generated a small number of failed
authentication attempts against multiple unrelated user accounts.

Several targeted accounts had no normal relationship with the
source system.

SUCCESSFUL LOGINS:
Not confirmed.

CONFIDENCE:
Medium

RECOMMENDED NEXT STEP:
Expand identity and source-host investigation and determine whether
any targeted account later authenticated successfully.

Part 56 — Example — Potential Account Compromise

DISPOSITION:
Potential Account Compromise

USER:
jdoe

EVIDENCE:
Successful authentication originated from an unrecognized system
outside the user's normal login baseline.

Related endpoint activity occurred shortly after authentication and
requires further review.

SCOPE:
One account currently identified.

KNOWN IMPACT:
No confirmed privilege escalation or data access.

SEVERITY:
High

CONFIDENCE:
Medium

ESCALATION:
Required.

Part 57 — Assign Severity

Consider:

Account Privilege

Asset Criticality

Successful Authentication

Number of Systems

Number of Accounts

Evidence of Post-Login Activity

Data Exposure

Persistence

Security-Control Outcome

Part 58 — Assign Confidence Separately

Use:

High
Medium
Low

Example:

Severity:
High

Confidence:
Medium

This may mean:

If the activity is malicious, impact could be significant, but malicious intent is not yet fully confirmed.

Part 59 — Build the Risk Assessment

Factor	Assessment
Account privilege	Standard
Successful login	Yes
Source expected	No
Target criticality	Medium
Multiple accounts	No
Post-login activity	Suspicious
MFA	Unknown
Final priority	P2

Part 60 — Determine Escalation

Escalate when:

privileged account involved unexpectedly
successful authentication from clearly abnormal source
multiple accounts targeted
password spraying suspected
suspicious post-login activity
malware/endpoint alert correlated
sensitive systems accessed
containment may be required

Part 61 — Create the Escalation Package

Use:

ESCALATION SUMMARY

Case ID:

User:

Account Type:

Priority:

Source:

Target:

First Observed:

Last Observed:

Successful Authentication:
Yes / No

Reason for Escalation:

Confirmed Evidence:

Unconfirmed Concerns:

Affected Accounts:

Affected Hosts:

Recommended Next Actions:

Evidence References:

Part 62 — Consider Containment Recommendations

Do not automatically disable an account.

Potential recommendations:

Reset account credential

Revoke active sessions

Require MFA re-authentication

Temporarily disable account

Isolate affected endpoint

Restrict suspicious source

Increase monitoring

Containment should consider business impact and approval.

Part 63 — Build the Containment Decision Matrix

Action	Required	Business Impact	Approval
Password reset
Session revocation
Account disable
Endpoint isolation

Part 64 — Preserve Evidence Before Containment

Where practical:

Preserve → Contain → Continue Investigation

Examples of evidence to preserve:

auth events
SIEM alerts
VPN logs
endpoint events
relevant network evidence
case timeline

Part 65 — Build the Authentication Evidence Register

Evidence ID	Source	Description
EV-AUTH-01	SIEM	Original alert
EV-AUTH-02	Windows	Failed login events
EV-AUTH-03	Windows	Successful login
EV-AUTH-04	Asset DB	Source host
EV-AUTH-05	Endpoint	Post-login activity

Part 66 — Create the Final Authentication Timeline

Use:

UTC Time	Source	Event	User	Host	Evidence

Highlight:

first observed activity
successful authentication
important post-login events
final known activity

Part 67 — Create the Authentication Investigation Register

CASE ID:

USER:

ACCOUNT TYPE:

PRIVILEGED:
Yes / No

TARGET ASSET:

SOURCE:

EXPECTED SOURCE:
Yes / No

FAILURES:

SUCCESS:
Yes / No

ACCOUNT LOCKOUT:
Yes / No

MFA:

OTHER ACCOUNTS TARGETED:

OTHER HOSTS ACCESSED:

ENDPOINT CORRELATION:

NETWORK CORRELATION:

BASELINE DEVIATION:

DISPOSITION:

SEVERITY:

CONFIDENCE:

SCOPE:

ESCALATION:

CONTAINMENT:

EVIDENCE:

REMAINING QUESTIONS:

Part 68 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Suspicious Authentication Investigation

Case ID:

Analyst:

Date:


INITIAL ALERT

Alert ID:

Alert Name:

Severity:

User:

Source:

Target:

Failed Attempts:

Successful Login:

Time Window:


IDENTITY CONTEXT

User:

Account Type:

Department:

Privilege:

Expected Host:

Normal Login Hours:

Remote Access Expected:


ASSET CONTEXT

Target:

Role:

Criticality:

Owner:

Expected User:


SOURCE ANALYSIS

Source IP:

Hostname:

Network:

Known Asset:

Associated User:

Expected Source:

Other Accounts Targeted:


AUTHENTICATION ANALYSIS

First Failure:

Last Failure:

Failure Count:

Success Time:

Logon Method:

MFA:

Lockout:

Successful Session:


PATTERN ANALYSIS

Single User / Single Source:

Single User / Multiple Sources:

Multiple Users / Single Source:

Spray Pattern:

Brute-Force Pattern:

User Error Pattern:

Service Account Pattern:


BASELINE

Normal Time:

Observed Time:

Normal Source:

Observed Source:

Normal Target:

Observed Target:

Baseline Deviation:


CORRELATION

Endpoint Activity:

Network Activity:

DNS Activity:

VPN Activity:

Related Alerts:

Privileged Activity:


SCOPE

Affected Users:

Affected Hosts:

Privileged Accounts:

Successful Suspicious Logins:

Known Impact:


HYPOTHESES

Hypothesis 01:

Supporting Evidence:

Contradicting Evidence:


Hypothesis 02:

Supporting Evidence:

Contradicting Evidence:


FINAL ASSESSMENT

Disposition:

Severity:

Confidence:

Priority:

Escalation:
Yes / No

Containment Recommended:
Yes / No

Remaining Questions:

Ready for Windows Security Event Investigation:
Yes / No

Part 69 — What Not to Do

Do not:

Assume failed authentication means attack

Assume success after failures means compromise

Assume unknown IP means malicious

Ignore VPN/proxy architecture

Ignore service accounts

Ignore maintenance windows

Guess user passwords

Perform password spraying

Perform brute-force authentication

Attempt credential stuffing

Use leaked credentials

Attempt account takeover

Trigger lockouts intentionally

Disable accounts without authorization

Reset passwords without authorization

Ignore timestamp differences

Ignore failed MFA events

Ignore endpoint activity after login

Declare account compromise without supporting evidence

Close alerts only because the user says activity was normal

The professional rule is:

User confirmation is context. Telemetry is evidence. Use both.

Troubleshooting

Source IP Is a VPN Gateway

Do not treat the gateway as the user’s endpoint.

Find the original client IP where logs provide it.

Mark:

Source Attribution:
Incomplete

and lower confidence where necessary.

Account Shows Many Failures at Exact Intervals

Consider:

service
scheduled task
cached credential
automation

before assuming brute force.

Increase priority, but continue evidence correlation.

User denial is important context—not absolute proof.

Logs Show Success but Endpoint Has No Session

Possible causes:

network authentication
service logon
short-lived session
telemetry gap

Check authentication type.

MFA Succeeded but User Denies It

Escalate.

Possible explanations require further investigation, but do not assume MFA bypass automatically.

Authentication Events Are Missing

Document:

Telemetry Gap

Do not infer missing events.

Evidence Requirements

Capture:

Evidence 01

Original authentication alert.

Evidence 02

Case scope.

Evidence 03

Identity profile.

Evidence 04

Asset profile.

Evidence 05

Source-IP profile.

Evidence 06

Failed authentication events.

Evidence 07

Successful authentication event.

Evidence 08

Authentication Pattern Register.

Evidence 09

Other-account search.

Evidence 10

Other-source search.

Evidence 11

Account lockout evidence.

Evidence 12

Service-account analysis where relevant.

Evidence 13

User Baseline.

Evidence 14

Baseline Deviation Matrix.

Evidence 15

Endpoint Correlation Register.

Evidence 16

Network Correlation Register.

Evidence 17

VPN evidence where applicable.

Evidence 18

MFA evidence where applicable.

Evidence 19

Privileged Authentication Register.

Evidence 20

Alert Correlation Matrix.

Evidence 21

Master Authentication Timeline.

Evidence 22

Hypothesis Matrix.

Evidence 23

Scope Matrix.

Evidence 24

Authentication Control Matrix.

Evidence 25

Risk Assessment.

Evidence 26

Escalation Package.

Evidence 27

Containment Decision Matrix.

Evidence 28

Authentication Investigation Register.

Evidence 29

Mission Challenge worksheet.

Mission Deliverables

Complete:

authentication case opened
alert metadata documented
user identity enriched
account privilege determined
target asset enriched
source IP investigated
failed events analyzed
successful authentication analyzed
authentication type reviewed
other accounts searched
other sources searched
account lockout assessed
service-account scenario considered
user baseline established
baseline deviations documented
endpoint evidence correlated
network evidence correlated
VPN evidence reviewed where applicable
MFA evidence reviewed where applicable
privileged activity assessed
related alerts correlated
authentication timeline completed
multiple hypotheses evaluated
account scope determined
host scope determined
positive controls documented
disposition assigned
severity assigned
confidence assigned separately
escalation decision documented
containment recommendation documented
evidence register completed
final Authentication Investigation Report completed

Lab Report Template

# Lab 03 — Suspicious Authentication Investigation

## Executive Summary

## Mission Objective

## Case Information

## Initial Alert

## Investigation Methodology

## Identity Context

## Asset Context

## Source-IP Analysis

## Authentication Event Analysis

### Failed Authentication
### Successful Authentication
### Authentication Method
### Account Lockout

## Authentication Pattern Analysis

## User Baseline

## Baseline Deviations

## Related Account Activity

## Related Host Activity

## Endpoint Correlation

## Network Correlation

## VPN / Remote Access Analysis

## MFA Analysis

## Privileged Authentication Analysis

## Alert Correlation

## Master Timeline

## Hypothesis Analysis

## Investigation Scope

## Positive Security Controls

## Final Disposition

## Severity

## Confidence

## Escalation Decision

## Containment Recommendations

## Remaining Questions

## Evidence Register

## Limitations

## Conclusion

Knowledge Check

Question 1 — Does multiple failed authentication prove a brute-force attack?

No.

It may also indicate user error, cached credentials, automation, or a service-account problem.

Because it may indicate either legitimate eventual authentication or unauthorized credential use and therefore requires context.

Question 3 — What pattern may suggest password spraying?

A single source generating a small number of failed attempts against many accounts.

Question 4 — Why is the source IP important?

It helps determine which device, network, gateway, or service initiated the authentication activity.

Question 5 — Why compare authentication to a user baseline?

Because unusual behavior is meaningful only when compared with the user’s expected systems, times, networks, and access patterns.

No.

It is strong evidence but still requires context.

To determine whether unusual processes, network connections, or security alerts followed the authentication.

No.

It is valuable context, but supporting telemetry should still be reviewed.

Question 9 — What is the difference between severity and confidence?

Severity reflects potential impact. Confidence reflects certainty in the investigation conclusion.

Question 10 — What is the central question of this lab?

“Does the suspicious authentication activity represent normal user behavior, an operational authentication issue, or evidence that an account may have been misused?”

Skills Achieved

After completing this lab, you should understand:

authentication-alert investigation
failed-login analysis
successful-login analysis
source-IP investigation
user and asset context
account privilege analysis
authentication pattern recognition
password-spray concepts
brute-force pattern concepts
user-error identification
stale-credential investigation
account-lockout analysis
service-account investigation
user baselining
endpoint correlation
network correlation
VPN context
MFA evidence analysis
authentication timeline reconstruction
account-scope analysis
hypothesis-driven investigation
severity and confidence assignment
authentication escalation
containment recommendations

Professional Takeaway

A weak authentication investigation looks like:

Failed Logins
     ↓
Successful Login
     ↓
Account Compromised

A professional investigation looks like:

Authentication Alert
        ↓
Identify User
        ↓
Identify Source
        ↓
Identify Target
        ↓
Review Authentication Pattern
        ↓
Compare with Baseline
        ↓
Search Other Users / Hosts
        ↓
Correlate Endpoint + Network Evidence
        ↓
Build Timeline
        ↓
Evaluate Hypotheses
        ↓
Determine Scope
        ↓
Disposition + Escalation

Always distinguish:

Failed Login
    ≠
Attack

Successful Login
    ≠
Compromise

New Source IP
    ≠
Malicious Source

Many Failures
    ≠
Brute Force Automatically

Account Lockout
    ≠
Credential Attack

MFA Success
    ≠
User Intent Proven

User Denies Login
    ≠
Compromise Proven

One Suspicious Authentication
    ≠
Entire Identity Environment Compromised

The strongest SOC analyst does not ask only:

“Was the password correct?”

They ask:

“Who authenticated, from where, to what, when, using which access method, whether that behavior matches the identity baseline, and what happened immediately before and after the authentication?”

What’s Next?

➡️ Lab 04 — Windows Security Event Investigation

In the next lab, you will move from identity-focused authentication analysis into a complete Windows host investigation.

You will work with:

Windows Security events
successful and failed logons
account activity
privilege events
process evidence where available
service activity
system events
user/host correlation
timeline reconstruction
event relationships
evidence-based host conclusions

The methodology becomes:

Windows Event → Host → User → Process/Service → Time → Related Events → Context → Conclusion

The central question will be:

“What actually happened on the Windows endpoint, which user and processes were involved, and does the available host evidence support a security incident?”

Lab 03 Suspicious Authentication Investigation

Mission Overview

Mission Information

Learning Objectives

Investigation Methodology

Part 1 — Create the Case Workspace

Part 2 — Open the Investigation Case

Part 3 — Review the Initial Alert

Part 4 — Record the Alert Metadata

Part 5 — Identify the Account

Part 6 — Determine Whether the Account Is Privileged

Part 7 — Identify the Target Asset

Part 8 — Investigate the Source IP

Part 9 — Understand Possible Source-IP Explanations

Part 10 — Build the Initial Authentication Timeline

Part 11 — Analyze Failure Count

Part 12 — User Error Pattern

Part 13 — Brute-Force Pattern Concept

Part 14 — Password-Spray Pattern Concept

Part 15 — Create the Authentication Pattern Register

Part 16 — Check for Successful Authentication

Part 17 — Analyze Successful Login Details

Part 18 — Review Windows Authentication Events

Part 19 — Understand Logon Types Conceptually

Part 20 — Review Linux Authentication Where Applicable

Part 21 — Check Whether Other Accounts Were Targeted

Part 22 — Create the Source-IP Authentication Profile

Part 23 — Check Whether the Same Account Appears from Multiple Sources

Part 24 — Check for Geographic Impossibility Conceptually

Part 25 — Compare Against the User Baseline

Part 26 — Build the Baseline Deviation Matrix

Part 27 — Review Account Lockout Activity

Part 28 — Investigate Stale Credentials

Part 29 — Check Service Accounts

Part 30 — Create the Service Account Profile

Part 31 — Correlate Endpoint Telemetry

Part 32 — Build the Endpoint Correlation Register

Part 33 — Correlate Network Evidence

Part 34 — Build the Network Correlation Register

Part 35 — Correlate VPN Evidence

Part 36 — Check MFA Evidence

Part 37 — Correlate Privileged Activity

Part 38 — Build the Privileged Authentication Register

Part 39 — Search for Related Authentication Alerts

Part 40 — Build the Alert Correlation Matrix

Part 41 — Build the Master Authentication Timeline

Part 42 — Separate Event Time from Ingestion Time

Part 43 — Build Initial Hypotheses

Hypothesis 1 — User Error

Hypothesis 2 — Stale Credentials

Hypothesis 3 — Credential Attack

Hypothesis 4 — Account Misuse

Part 44 — Create the Hypothesis Matrix

Part 45 — Avoid Confirmation Bias

Part 46 — Determine Account Scope

Part 47 — Determine Host Scope

Part 48 — Build the Scope Matrix

Part 49 — Evaluate Indicators of Account Misuse

Part 50 — Identify Positive Controls

Part 51 — Build the Authentication Control Matrix

Part 52 — Determine the Disposition

Expected Activity

Operational Issue

Suspicious — Investigate Further

Potential Account Compromise

Confirmed Account Compromise

Inconclusive

Part 53 — Example — User Error

Part 54 — Example — Stale Credential

Part 55 — Example — Potential Password Spray

Part 56 — Example — Potential Account Compromise

Part 57 — Assign Severity

Part 58 — Assign Confidence Separately

Part 59 — Build the Risk Assessment

Part 60 — Determine Escalation

Part 61 — Create the Escalation Package

Part 62 — Consider Containment Recommendations

Part 63 — Build the Containment Decision Matrix

Part 64 — Preserve Evidence Before Containment

Part 65 — Build the Authentication Evidence Register