"Lab 10 — Authentication Attack Investigation"

Mission Information

Item	Details
Lab	10
Lab Name	Authentication Attack Investigation
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ SOC / SIEM Lab
Primary Systems	SIEM + Windows Endpoint + Linux Server + Analyst Workstation
Skills	Authentication Analysis, Identity Investigation, Password Attack Detection, Source-IP Analysis, SIEM Correlation, Incident Triage

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

Your SIEM has generated several alerts related to authentication activity.

The alerts indicate:

Multiple Failed Logins
        ↓
Several Accounts Targeted
        ↓
Successful Authentication
        ↓
Privileged Activity

At first glance, the activity could represent:

a user entering an incorrect password
an application using outdated credentials
an administrator troubleshooting access
brute-force activity
password spraying
compromised credentials

Your job is to determine what actually happened.

You must investigate the identity, source system, affected accounts, authentication pattern, successful sessions, and activity occurring after authentication.

Mission Objective: Perform a complete identity-focused investigation and determine whether observed authentication activity represents benign behavior, suspicious activity, or a security incident requiring escalation.

Mission Objectives

By completing this lab, you will be able to:

investigate authentication alerts
distinguish common authentication attack patterns
analyze repeated login failures
recognize password spraying behavior
recognize brute-force behavior
identify targeted accounts
analyze source IP addresses
investigate successful logins after failures
interpret Windows logon types
investigate SSH authentication
investigate privileged accounts
correlate network and identity telemetry
build authentication timelines
pivot across users, IPs, and hosts
classify and document an authentication incident

1. Authentication as a Security Boundary

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Attackers frequently target authentication because valid credentials may allow them to bypass other security controls.

Typical identity attack paths include:

Credential Discovery
      ↓
Authentication Attempt
      ↓
Successful Access
      ↓
Privilege Use
      ↓
Lateral Movement
      ↓
Further Compromise

This makes authentication telemetry one of the most valuable sources available to SOC analysts.

2. Common Authentication Attack Patterns

You should understand several different behaviors.

Brute Force

Repeated attempts against one account.

admin
admin
admin
admin
admin

Pattern:

One Account
    +
Many Password Attempts

Password Spraying

A small number of passwords attempted across many accounts.

user01
user02
user03
user04
admin

Pattern:

Many Accounts
    +
Few Password Attempts

Credential Stuffing

Credentials obtained from another source are tested against accounts.

Valid Account Abuse

The attacker already possesses working credentials.

There may be few or no failed logins before successful access.

3. Start the Lab Environment

Start:

CYSA-SIEM
10.10.10.40

CYSA-ANALYST
10.10.10.10

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

Verify all required agents and telemetry sources are connected.

Your SIEM should receive:

Windows authentication telemetry
Linux authentication telemetry
Zeek network telemetry
Suricata alerts

4. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB10/{Evidence,Screenshots,Findings}

Create:

touch ~/CySA-Lab/Investigations/LAB10/investigation-notes.md

Use:

Investigation ID:
LAB10-AUTH-001

5. Define the Investigation Questions

Before searching the SIEM, define what you need to answer.

Who was targeted?

Where did the activity originate?

Which systems were affected?

How many attempts occurred?

Were multiple users targeted?

Did authentication succeed?

What happened after success?

Was privileged activity observed?

Was the source expected?

Should the alert be escalated?

This prevents unfocused log searching.

6. Establish the Investigation Time Window

Open the triggering authentication alert.

Record:

Alert Time
First Observed Event
Last Observed Event
Source IP
Destination
Account

Set your SIEM time range to include several minutes before and after the alert.

For example:

Alert Time:
20:15

Investigation Window:
20:05–20:25

This allows you to identify activity preceding and following the alert.

7. Investigate Windows Failed Logons

Search for:

Event ID 4625

Filter to:

CYSA-WIN01

Review:

Account Name
Source Network Address
Logon Type
Failure Reason
Workstation
Timestamp

Create a table:

Time	Account	Source	Logon Type	Result
20:11	user01	10.10.10.10	3	Failed
20:12	user01	10.10.10.10	3	Failed
20:13	user01	10.10.10.10	3	Failed

Your actual events will differ.

8. Count Failures by Account

Group failed authentication events by username.

Your SIEM may provide aggregation functionality.

Conceptually, you want:

user01 → 8 failures
user02 → 2 failures
admin  → 1 failure

This helps identify whether the activity is concentrated on one account or spread across many.

9. Count Failures by Source IP

Now group by:

Source IP

Example:

10.10.10.10 → 12 failures
10.10.10.50 → 1 failure

A single source generating many authentication failures may deserve additional investigation.

10. Analyze the Account-to-Source Relationship

Create a simple matrix.

Source	user01	user02	user03	admin
10.10.10.10	5	5	5	5

This pattern differs significantly from:

Source	user01
10.10.10.10	20

The first resembles:

Password Spraying

The second resembles:

Brute Force

11. Generate a Safe Password-Spraying Simulation

Do not automate credential attacks.

Use controlled activity only inside your own lab.

For example, create a few test accounts on CYSA-WIN01 if appropriate.

Then manually generate one failed authentication event against several test accounts.

Example:

labuser01
labuser02
labuser03
labuser04

Use only your lab environment.

The goal is to observe the pattern, not perform high-volume guessing.

12. Investigate the Resulting Pattern

In the SIEM, group by:

Source IP
+
Username

You should see:

One source
      ↓
Multiple accounts
      ↓
Small number of failures per account

This is the conceptual signature of password spraying.

13. Recognize Brute-Force Behavior

Brute-force behavior typically looks more like:

One Source
      ↓
One Account
      ↓
Many Authentication Failures

Example:

10.10.10.10
      ↓
administrator
      ↓
15 failures

Do not rely on count alone.

Consider:

Time Window
Account Criticality
Source
Successful Login
Normal User Behavior

14. Investigate Successful Windows Authentication

Search for:

Look for successful logins involving accounts that previously experienced failures.

Record:

Timestamp
Account
Source
Logon Type
Authentication Package
Logon ID

The critical question is:

Did any targeted account successfully authenticate after the failures?

15. Correlate Failed and Successful Authentication

Build:

Failed Login
     ↓
Failed Login
     ↓
Failed Login
     ↓
Successful Login

Pay attention to:

Same Account?
Same Source?
Same Endpoint?
Same Time Window?

If all match, investigation priority increases.

16. Investigate Windows Logon Type

A successful Windows authentication may include:

Logon Type

Useful examples:

Type	Meaning
2	Interactive
3	Network
7	Unlock
10	Remote Interactive
11	Cached Interactive

A remote login following repeated failures can be more interesting than a normal workstation unlock.

Again, context determines risk.

17. Investigate Privileged Windows Accounts

Determine whether any affected account is:

Administrator
Local Administrator
Privileged Service Account
Domain Administrator
Other Sensitive Identity

An authentication alert involving a privileged account should generally receive more attention.

Search for:

to identify special privileges assigned to sessions.

18. Correlate Logon ID

For Windows events, use:

Logon ID

where available.

Example:

4624
Logon ID: 0x123ABC

and:

4672
Logon ID: 0x123ABC

This can confirm that privilege assignment belongs to the same authenticated session.

19. Investigate Linux SSH Failures

Search your SIEM for:

Failed password

or your normalized failed-authentication field.

Review:

Source IP
Username
Destination
Timestamp
Authentication Method

Build a similar failure table.

20. Investigate Successful SSH Authentication

Search:

Accepted password

or equivalent.

Determine:

Was the same account targeted?

Was the same source involved?

How long after the failures did success occur?

This is a key indicator during authentication investigations.

21. Investigate sudo Activity

After successful Linux authentication, search:

sudo

Look for:

Username
Command
Target User
Timestamp
Working Directory

Correlate:

SSH Success
    ↓
sudo

The question changes from:

Did someone log in?

to:

What did they do after logging in?

22. Investigate Active Sessions

On your Linux lab system, you may use:

who

and:

during a controlled investigation.

This provides live context for active user sessions.

Your SIEM remains the primary evidence source for this mission.

23. Pivot on the Username

Select one suspicious account.

Search the SIEM for:

<username>

Review all events involving that identity.

Look across:

Authentication
Privilege
Process
Endpoint
Network

This is an identity pivot.

24. Pivot on the Source IP

Now search:

10.10.10.10

or the source identified in your investigation.

Look for:

Windows authentication
Linux authentication
Zeek connections
Suricata alerts

This determines whether the same source interacted with additional systems.

25. Pivot on the Destination Host

Search:

CYSA-LINUX01

Then:

CYSA-WIN01

Determine whether the source attempted authentication against multiple systems.

This could indicate broader credential testing.

26. Correlate Zeek Network Evidence

Search Zeek telemetry for the source.

For example:

10.10.10.10

Look for connections to:

depending on what exists in your environment.

Network telemetry can confirm that the source actually established connections to authentication services.

27. Correlate Suricata Alerts

Search Suricata telemetry for:

Source IP

Review any related alerts.

Do not assume the IDS alert itself proves an authentication attack.

Use it as additional context.

28. Build the Authentication Attack Timeline

Create a timeline.

Example:

Time	Source	Host	Event
20:01	10.10.10.10	CYSA-WIN01	user01 failed
20:02	10.10.10.10	CYSA-WIN01	user02 failed
20:03	10.10.10.10	CYSA-WIN01	user03 failed
20:04	10.10.10.10	CYSA-LINUX01	analyst failed
20:05	10.10.10.10	CYSA-LINUX01	analyst successful
20:06	10.10.10.10	CYSA-LINUX01	sudo activity

This immediately reveals the relationship between events.

29. Recognize a Password-Spraying Pattern

A password spray could resemble:

One Source
      ↓
user01 — Fail
user02 — Fail
user03 — Fail
user04 — Fail
admin  — Fail

Characteristics:

Many accounts
Low attempts per account
Same or related source
Short or repeated time windows

Attackers use this technique partly to avoid account lockout thresholds.

30. Recognize a Brute-Force Pattern

A brute-force pattern could resemble:

One Source
      ↓
admin — Fail
admin — Fail
admin — Fail
admin — Fail
admin — Success

Characteristics:

Single or small number of accounts
High attempt volume
Repeated failures
Potential eventual success

31. Recognize Credential Stuffing Conceptually

Credential stuffing often involves:

Known Username + Password Pairs
               ↓
Authentication Attempts
               ↓
Multiple Services

You will not perform credential stuffing in this lab.

The analyst task is to recognize possible evidence such as:

valid credentials succeeding rapidly
many accounts accessed from one unfamiliar source
unexpected geography or infrastructure
previously unseen authentication patterns

32. Investigate Authentication Timing

Examine whether activity occurred:

During working hours
Outside working hours
Immediately after password reset
During maintenance
During an approved test

Timing does not prove malicious intent.

But it adds context.

33. Investigate Failure Reasons

Windows Event ID 4625 may expose failure reasons.

Examples may indicate:

Unknown username
Bad password
Disabled account
Locked account
Logon restriction

A large number of failures against nonexistent usernames may suggest account enumeration or automated activity.

34. Investigate Account Lockout Events

Depending on your Windows environment, you may encounter events relating to account lockout.

If present, investigate:

Account
Timestamp
Source
Preceding failures

Account lockouts can be both:

Security Indicator

and:

Operational Impact

35. Identify High-Value Accounts

Mark accounts such as:

administrator
root
service accounts
backup accounts
security administrators

as higher-value identities.

Authentication attempts against these accounts may warrant faster escalation.

36. Identify First Seen Source Activity

Ask:

Has this source IP authenticated successfully before?

Search historical events.

Compare:

Known Source

versus:

Previously Unseen Source

A new source is not automatically malicious, but can increase investigation priority.

37. Identify First Seen Account-to-Host Relationship

Ask:

Does this user normally access this system?

Example:

User:
finance01

Normal Assets:
Finance Workstations

Observed:
CYSA-LINUX01

An unusual account-to-host relationship can be important.

This introduces behavioral context.

38. Analyze Success-to-Failure Ratio

Suppose:

Source A:
2 failures
20 successes

This may reflect ordinary user activity.

Compare:

Source B:
100 failures
1 success

The second deserves more attention.

Ratios can help analysts understand behavior beyond raw counts.

39. Correlate Post-Authentication Activity

After successful authentication, search for:

Privilege changes
sudo
Process execution
PowerShell
Network connections
Service activity
Account changes

An authentication event becomes much more significant when followed by suspicious actions.

40. Build an Identity Investigation Chain

Your investigation can evolve as:

Alert
  ↓
Account
  ↓
Source IP
  ↓
Affected Host
  ↓
Authentication Pattern
  ↓
Successful Session
  ↓
Privilege Activity
  ↓
Process / Network Activity
  ↓
Assessment

This is a strong identity-centered SOC workflow.

41. Assign Investigation Severity

Consider:

Number of Attempts
+
Number of Accounts
+
Success After Failure
+
Account Privilege
+
Source Reputation
+
Affected Asset
+
Post-Login Activity

Example:

5 failures against normal account:
Medium

versus:

Password spray
+
Administrator login success
+
Privilege activity:
High / Critical investigation

42. Determine True Positive vs Benign Activity

Possible benign explanation:

User changed password
     ↓
Old mobile device continues authenticating
     ↓
Repeated failures

Possible suspicious explanation:

Unknown source
     ↓
Multiple accounts targeted
     ↓
Successful privileged login

Both may initially create similar authentication alerts.

Analyst investigation determines the difference.

43. Build an Authentication Investigation Table

Create:

Indicator	Observation	Analyst Interpretation
Source IP	10.10.10.10	Lab analyst workstation
Accounts	4	Multiple targets
Failures	8	Elevated
Successful Login	Yes	Significant
Privileged Account	Yes/No	Risk factor
Post-Login sudo	Yes	Increased concern
Zeek Evidence	Present	Network confirmed
Suricata Evidence	Present/Absent	Supporting context

44. Mission Challenge — Identity Investigation

The SOC provides this alert:

Multiple authentication failures involving several accounts were followed by successful access to a monitored server.

Using your SIEM, determine:

What source generated the activity?
Which systems were targeted?
Which accounts were targeted?
How many attempts occurred per account?
Does the pattern resemble brute force or password spraying?
When did the activity begin?
Was authentication successful?
Which account successfully authenticated?
Was the account privileged?
What logon type or authentication method was used?
Did the same source generate the failures and success?
What happened after successful authentication?
Was privileged activity observed?
Did Zeek confirm the network session?
Did Suricata generate related telemetry?
Has the source appeared previously?
Is the activity authorized?
Should the event be escalated?

45. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB10/investigation-notes.md

Use:

# LAB10 Authentication Investigation

## Investigation ID

LAB10-AUTH-001

## Alert

Multiple authentication failures followed by successful authentication.

## Source

Document:
- IP address
- hostname
- first seen
- previous activity

## Target Systems

Document affected hosts.

## Targeted Accounts

Document:
- usernames
- number of attempts
- privileged status

## Authentication Pattern

Classify:
- normal user error
- brute force
- password spraying
- possible credential stuffing
- valid account abuse
- requires further investigation

## Successful Authentication

Document:
- account
- host
- source
- timestamp
- logon type / authentication method

## Post-Authentication Activity

Document:
- privilege activity
- processes
- commands
- network connections
- account changes

## Network Correlation

Document Zeek and Suricata evidence.

## Timeline

Construct the complete authentication sequence.

## Assessment

Determine whether activity appears benign, suspicious, or malicious.

## Severity

Low / Medium / High / Critical

## Analyst Decision

Escalate / Close / Continue Investigation

## Recommended Actions

Document next steps.

46. Example Analyst Findings

A controlled lab assessment might resemble:

Investigation:
LAB10-AUTH-001

Source:
CYSA-ANALYST
10.10.10.10

Targets:
CYSA-WIN01
CYSA-LINUX01

Observed Pattern:
Multiple authentication failures against several accounts followed by successful SSH authentication.

Successful Account:
analyst01

Post-Authentication Activity:
sudo commands observed.

Network Evidence:
Zeek confirmed the SSH connection.

IDS Context:
Related Suricata telemetry was present.

Classification:
Password-spraying-like pattern followed by successful access.

Lab Context:
Activity was intentionally generated for the CySA+ exercise.

Real-World Assessment:
The same sequence from an unauthorized source would warrant immediate escalation and credential compromise investigation.

Severity:
High Pattern — Controlled Laboratory Activity

47. Recommended Response Actions

In a real authentication incident, possible actions include:

Validate account owner
Review recent authentication history
Reset compromised credentials
Revoke active sessions
Disable account if necessary
Require MFA
Block malicious source
Review privilege changes
Investigate affected endpoints
Search for lateral movement
Review additional targeted accounts
Preserve logs and evidence

Actions should follow organizational policy and incident severity.

48. Evidence to Capture

Capture:

01-authentication-alert.png
02-windows-4625-events.png
03-failures-by-account.png
04-failures-by-source.png
05-password-spray-pattern.png
06-successful-login.png
07-logon-type.png
08-privileged-session.png
09-linux-ssh-failures.png
10-linux-ssh-success.png
11-sudo-activity.png
12-username-pivot.png
13-source-ip-pivot.png
14-zeek-correlation.png
15-suricata-correlation.png
16-authentication-timeline.png
17-investigation-table.png
18-analyst-findings.png

49. Validation Checklist

Authentication alert was reviewed
Investigation time window was established
Windows failed logons were analyzed
Failures were grouped by account
Failures were grouped by source
Account-to-source relationships were analyzed
Password-spraying behavior was understood
Brute-force behavior was understood
Successful Windows authentication was investigated
Logon type was reviewed
Privileged accounts were identified
Event ID 4672 was investigated where applicable
Linux SSH failures were investigated
Successful SSH login was investigated
sudo activity was correlated
Username pivoting was performed
Source-IP pivoting was performed
Destination-host pivoting was performed
Zeek telemetry was correlated
Suricata telemetry was reviewed
Authentication timeline was created
High-value accounts were considered
Historical source activity was reviewed
Post-authentication activity was investigated
Event severity was assigned
Analyst findings were documented
Evidence was captured

50. Mission Review

In this mission, you moved beyond detecting authentication anomalies and performed a full identity-focused security investigation.

You followed:

Authentication Alert
        ↓
Identify Source
        ↓
Identify Accounts
        ↓
Analyze Failure Pattern
        ↓
Brute Force or Spray?
        ↓
Search for Success
        ↓
Investigate Privilege
        ↓
Investigate Post-Login Activity
        ↓
Correlate Network Evidence
        ↓
Build Timeline
        ↓
Make Analyst Decision

The critical lesson is:

Failed logins alone rarely tell the whole story.

The strongest authentication investigations connect:

Identity
   +
Source
   +
Target
   +
Time
   +
Successful Access
   +
Privilege
   +
Post-Login Behavior
   =
Authentication Incident Context

Skills Developed

After completing this mission, you should be able to:

investigate authentication alerts
recognize brute-force patterns
recognize password-spraying patterns
understand credential-stuffing indicators
group failures by user and source
investigate successful access after failures
interpret Windows logon types
identify privileged account activity
investigate SSH authentication
correlate sudo activity
pivot on users, IPs, and systems
correlate identity and network telemetry
assess first-seen behavior
analyze post-authentication activity
build authentication timelines
classify identity-related security incidents
recommend appropriate response actions

What’s Next?

Lab 11 — Phishing Email Investigation

Authentication attacks frequently begin with credential theft.

In the next mission, you will investigate one of the most common initial-access techniques faced by SOC analysts: phishing.

You will analyze:

sender information
display-name impersonation
email headers
Return-Path
Reply-To
Received headers
SPF
DKIM
DMARC
URLs
domains
attachments
file hashes
indicators of compromise
suspicious redirects
threat-intelligence enrichment
user impact
analyst verdicts

The investigation moves from:

Suspicious Authentication

back toward a possible cause:

Phishing Email
      ↓
Credential Theft
      ↓
Account Compromise

➡️ Next: Lab 11 — Phishing Email Investigation