Lab 02 — Suspicious Authentication Investigation

Welcome to:

Lab 02 — Suspicious Authentication Investigation

In the previous lab, you investigated an authentication alert that ultimately turned out to be:

Benign
True Positive

This investigation will be different.

This time, several signals begin to align:

Failed Logins

      ↓

Successful Login

      ↓

New Device

      ↓

MFA Anomaly

      ↓

Privilege Activity

Your challenge is to determine whether these signals represent:

Legitimate
User Activity

or:

Account
Compromise

You will move beyond basic alert triage and perform a deeper identity investigation.

Mission Information

Your Role

You are continuing as a:

SOC Analyst

at:

CloudNova Technologies

Your SOC receives a high-priority identity alert involving an employee account.

The user works in:

Finance

and has access to several sensitive enterprise applications.

Your responsibility is to:

Validate

Investigate

Determine Scope

Assess Risk

Contain

Escalate

Document

the authentication incident.

Enterprise Environment

CloudNova uses:

Enterprise Identity Platform

MFA

Corporate VPN

Windows Endpoints

Email

AWS Cloud

Finance Applications

SIEM

EDR

Available telemetry includes:

Authentication Logs

MFA Logs

Device Information

VPN Logs

Identity Changes

Email Audit Logs

Cloud Audit Logs

EDR

Threat Intelligence

Initial Alert

Your SIEM generates:

Alert ID:
ALT-2047

Detection:
Suspicious Authentication
with MFA Anomaly

Severity:
High

User:
emily.carter@cloudnova.example

Source IP:
203.0.113.91

Country:
Netherlands

Application:
Corporate Identity Portal

Failed Logins:
8

Successful Login:
Yes

Device:
Unknown

MFA:
Multiple Denials
Followed by Approval

Time:
14:18 UTC

Detection Logic

The detection identifies:

Multiple
Failed Logins

      ↓

Successful Password
Authentication

      ↓

Repeated MFA
Denials

      ↓

MFA Approval

      ↓

New Device

within:

15 Minutes

Initial Investigation Question

Do not immediately state:

Account
Compromised

Instead determine:

Did the User
Perform the Login?

Was MFA
Socially Engineered?

Is the Device
Legitimate?

What Happened
After Authentication?

Did the Account
Gain New Privileges?

Was Sensitive
Data Accessed?

Lab Objectives

By completing this lab, you will learn how to:

• investigate suspicious authentication.

• analyze failed and successful login sequences.

• review source IP context.

• analyze user authentication baselines.

• investigate new-device activity.

• analyze MFA fatigue patterns.

• review MFA registration changes.

• investigate session creation.

• review identity changes.

• analyze privilege escalation.

• investigate mailbox activity.

• analyze cloud activity.

• correlate authentication across data sources.

• determine whether an account is compromised.

• determine incident scope.

• build an authentication timeline.

• identify possible attack stages.

• map activity to MITRE ATT&CK.

• determine appropriate containment.

• recommend session revocation.

• recommend credential reset.

• determine whether MFA reset is required.

• create an escalation handoff.

• document a defensible SOC investigation.

Prerequisites

You should understand:

Authentication

MFA

Session

Identity

Device

Privilege

SIEM

Threat Intelligence

Account Compromise

Incident Response

Tools Required

Assume access to:

SIEM

Identity Platform

MFA Logs

EDR

VPN

Email Audit Logs

Cloud Audit Logs

Threat Intelligence

Asset Inventory

Case Management

Lab Artifacts

By the end of this lab, create:

01 Alert_Triage_Worksheet.csv

02 Authentication_Timeline.csv

03 User_Baseline.csv

04 Device_Investigation.csv

05 MFA_Analysis.csv

06 Session_Activity.csv

07 Identity_Change_Register.csv

08 Evidence_Register.csv

09 Compromise_Findings.csv

10 Incident_Scope.csv

11 MITRE_ATTACK_Mapping.csv

12 Containment_Plan.md

13 Escalation_Handoff.md

14 SOC_Investigation_Report.md

Part 1 — Understand the Alert

Record the alert details.

Create:

Alert_Triage_Worksheet.csv

Use:

Field	Value
Alert ID	ALT-2047
User	emily.carter@cloudnova.example
Source IP	203.0.113.91
Country	Netherlands
Failed Logins	8
Successful Login	Yes
MFA Denials	Multiple
MFA Approval	Yes
Device	Unknown
Severity	High
Time	14:18 UTC

Triggering Sequence

The alert represents:

Password Failure

Password Failure

Password Failure

      ↓

Password Success

      ↓

MFA Denial

MFA Denial

MFA Denial

      ↓

MFA Approval

      ↓

New Device

First Observation

This pattern is more suspicious than:

Failed Password
      ↓
Successful Password

alone.

Why?

Because the MFA behavior may indicate:

MFA Fatigue

Social Engineering

Unexpected User Action

Part 2 — Identify the User

Identity records show:

Name:
Emily Carter

Department:
Finance

Role:
Finance Operations Manager

Employment:
Active

Account Type:
Standard User

Additional Access:
Finance Reporting
Corporate Email
AWS Billing Dashboard

Primary Location:
London, UK

Working Hours:
08:00–17:00 UTC

Risk Context

The account is not a global administrator.

However, it has access to:

Financial Information

Corporate Email

Cloud Billing Data

Therefore compromise still matters.

Part 3 — Establish Authentication Baseline

Review:

30 Days

of authentication history.

Normal activity:

United Kingdom

Corporate Laptop

London Office

Home ISP

Corporate VPN

Common device:

EMILY-LAPTOP

Device ID:
DEV-6621

Current authentication:

Country:
Netherlands

Device:
Unknown

Baseline Result

You now have:

New Country

New Device

New Source IP

These increase suspicion.

But remember:

New
      ≠
Malicious

Part 4 — Investigate the Source IP

Threat-intelligence enrichment returns:

IP:
203.0.113.91

Country:
Netherlands

Provider:
Cloud Hosting Provider

Residential:
No

VPN / Proxy:
Possible

TOR:
No

Threat Reputation:
Previously Observed
in Credential Abuse
Campaigns

Confidence:
Medium

Interpretation

This is stronger evidence than:

Unknown IP

because it has:

Known
Risk Context

But threat intelligence remains supporting evidence.

It does not independently prove compromise.

Part 5 — Authentication Timeline

Search authentication logs.

You find:

14:09
Password Failure

14:10
Password Failure

14:11
Password Failure

14:12
Password Failure

14:13
Password Failure

14:14
Password Failure

14:15
Password Failure

14:16
Password Failure

14:17
Password Success

14:17
MFA Push Sent

14:17
MFA Denied

14:17
MFA Push Sent

14:18
MFA Denied

14:18
MFA Push Sent

14:18
MFA Approved

14:18
Authentication Successful

Key Pattern

Multiple
Password Failures

      ↓

Password Success

      ↓

Repeated MFA
Push Requests

      ↓

Denials

      ↓

One Approval

This is consistent with a possible:

MFA Fatigue
Scenario

Part 6 — Investigate MFA

Create:

MFA_Analysis.csv

with:

Time	Event	Result	Significance
14:17	MFA Push	Sent	Authentication challenge
14:17	MFA	Denied	User rejected request
14:17	MFA Push	Sent	Repeated challenge
14:18	MFA	Denied	User rejected again
14:18	MFA Push	Sent	Third challenge
14:18	MFA	Approved	Authentication completed

Analyst Question

Why would the user:

Deny

two authentication requests and then:

Approve

the third?

Possible explanations:

Accidental Denial

Confusion

User Initiated Login

MFA Fatigue

Social Engineering

You need user confirmation and post-login analysis.

Part 7 — Review MFA Registration

Search:

MFA Method
Changes

before and after the login.

You find:

No New
Authentication Method

No MFA Device
Registration

No MFA Removal

This means the attacker did not appear to establish a new MFA mechanism.

But they may still have gained:

Authenticated Session

Part 8 — Investigate the Device

The successful login shows:

Device ID:
Unknown

Device Name:
Unknown

Managed:
No

Compliance:
Unknown

Browser:
Chrome

OS:
Linux

Emily’s normal endpoint:

Windows
Managed
Corporate Device

Device Finding

The successful login originated from:

Unmanaged
Linux Device

that has:

No Previous
User History

This materially increases suspicion.

Part 9 — Review Concurrent Sessions

At:

14:18 UTC

Emily already has an active session from:

DEV-6621

in:

London, UK

The new session originates from:

Netherlands

at nearly the same time.

Observation

Two sessions:

Session A

Known Corporate Device
London

      +

Session B

Unknown Device
Netherlands

exist concurrently.

This is a significant anomaly.

Part 10 — Review Impossible Travel

At:

13:58 UTC

Emily authenticated from:

London

At:

14:18 UTC

the second login occurred from:

Netherlands

20 minutes later.

This appears geographically inconsistent.

However:

Impossible Travel
      ≠
Confirmed Compromise

because VPN or cloud services can distort location.

But when combined with:

New Device

MFA Denials

Risky IP

confidence increases.

Part 11 — User Verification

SOC contacts Emily.

Emily states:

I am working
from London.

I did not try
to log in from
another device.

I received several
MFA prompts.

I denied the first two.

I accidentally
approved the third
because the prompts
kept appearing.

Critical Finding

This provides direct context supporting:

Unauthorized
Authentication

Part 12 — Update Incident Classification

You now have:

User Denies Login

      +

Repeated MFA Prompts

      +

Accidental Approval

      +

Unknown Device

      +

New Country

      +

Risky Source IP

The case should now be treated as:

Potential
Account Compromise

and escalated.

Part 13 — Investigate Post-Login Activity

Search activity from:

14:18–15:00 UTC

You find:

14:20
Corporate Email Access

14:22
Finance Application Access

14:24
User Profile Viewed

14:26
Directory Group Search

14:29
AWS Billing Dashboard Access

14:31
Mailbox Rules Viewed

14:34
New Inbox Rule Created

14:35
External Forwarding Configured

Major Investigation Pivot

The session is no longer only:

Suspicious
Authentication

You now have:

Post-Compromise
Activity

Part 14 — Investigate Inbox Rule

Email audit logs show:

Rule Name:
FinanceReports

Action:
Forward Messages

Destination:
external-report@outside.example

Created:
14:34 UTC

This activity was performed from:

Session B

the suspicious session.

Observation

This indicates potential:

Mailbox
Persistence

and

Information
Collection

Part 15 — Investigate Cloud Activity

AWS audit logs show:

14:29
Billing Dashboard Access

14:30
Cost Report Viewed

14:31
Billing Export Requested

No:

IAM Role Change

Access Key Creation

Security Group Change

was identified.

Cloud Scope

The compromised account appears to have accessed:

Billing Information

but no evidence currently shows:

Cloud Privilege
Escalation

Part 16 — Review Identity Changes

Search for:

Password Change

Role Change

MFA Change

Group Membership

Application Consent

You find:

No Password Change

No Admin Role

No MFA Change

No Group Change

This is useful for scope.

Part 17 — Review OAuth and Application Consent

You find:

No New
OAuth Application

No New
Consent Grant

This reduces one persistence path.

Part 18 — Review Endpoint Activity

Emily’s corporate endpoint:

DEV-6621

shows:

No Malware Alert

No Suspicious PowerShell

No Credential Dumping

No Unknown Process

Interpretation

The evidence currently suggests:

Identity
Compromise

rather than:

Corporate Endpoint
Compromise

Part 19 — Determine Likely Attack Scenario

Current evidence supports:

Credential
Obtained

      ↓

Attacker
Attempts Login

      ↓

Repeated MFA
Prompts

      ↓

User Accidentally
Approves

      ↓

Attacker Gains
Session

      ↓

Email Access

      ↓

Cloud Billing Access

      ↓

Mailbox Rule

      ↓

External Forwarding

What Do We Know About Credential Theft?

We know the attacker successfully supplied:

Correct Password

But we do not yet know:

How the Password
Was Obtained

Possible sources:

Phishing

Credential Reuse

Infostealer

Previous Data Breach

Social Engineering

Do not claim a specific initial-access method without evidence.

Part 20 — Determine Incident Scope

Create:

Incident_Scope.csv

Use:

Entity	Type	Status	Evidence
Emily Carter	Identity	Compromised	User confirmation + session activity
Session B	Session	Malicious	Unknown device + unauthorized activity
Corporate Email	Application	Affected	Mailbox rule created
Finance Application	Application	Accessed	Audit logs
AWS Billing	Cloud	Accessed	Cloud audit logs
DEV-6621	Endpoint	No compromise found	EDR review

Part 21 — Determine What Is Not Yet Known

Unknowns include:

How Credentials
Were Stolen

How Long the
Attacker Had Password

Whether Other
Accounts Were Targeted

Whether Forwarded
Email Contained
Sensitive Information

Whether Data Was
Downloaded Elsewhere

Track these separately.

Part 22 — Build the Authentication Timeline

Create:

Authentication_Timeline.csv

Use:

Time	Source	Event	Significance
13:58	Identity	Normal London login	Baseline
14:09–14:16	Identity	8 password failures	Credential attempts
14:17	Identity	Password success	Correct credential obtained
14:17–14:18	MFA	Two denials	Unexpected MFA
14:18	MFA	Approval	Attacker gains session
14:18	Identity	New session	Unknown device
14:20	Email	Mailbox access	Post-login activity
14:29	AWS	Billing access	Cloud activity
14:34	Email	Inbox rule created	Persistence
14:35	Email	External forwarding	Possible collection/exposure

Part 23 — Build Evidence Register

Create:

Evidence_Register.csv

Use:

Evidence ID	Source	Observation	Significance
EVD-001	Identity	8 failed logins	Authentication attack pattern
EVD-002	MFA	Repeated denials then approval	MFA fatigue indicator
EVD-003	Device	Unknown unmanaged Linux device	Strong anomaly
EVD-004	Identity	Concurrent London session	Supports unauthorized second session
EVD-005	User	User denies login	Strong validation
EVD-006	Email	Inbox rule created	Post-compromise activity
EVD-007	Email	External forwarding	Possible information exposure
EVD-008	AWS	Billing access	Cloud scope
EVD-009	EDR	No endpoint compromise	Scope limitation

Part 24 — Compromise Findings

Create:

Compromise_Findings.csv

with:

Finding	Evidence	Confidence
Password was successfully used by unauthorized actor	Identity + user confirmation	High
MFA fatigue likely contributed to access	MFA + user confirmation	High
Unknown device created session	Device telemetry	Confirmed
Account accessed from unauthorized location	User + identity logs	High
Mailbox rule created by suspicious session	Email audit	Confirmed
External forwarding enabled	Email audit	Confirmed
AWS billing data accessed	Cloud audit	Confirmed
Endpoint compromise not identified	EDR	Moderate

Part 25 — Determine Classification

This is no longer:

Benign
True Positive

Classification:

Confirmed
Account Compromise

with:

High Confidence

Part 26 — Incident Severity

Factors:

Confirmed Account
Compromise

MFA Bypass
through User Approval

Finance User

Email Access

External Forwarding

Cloud Billing Access

Candidate severity:

High

depending on organizational methodology.

Part 27 — Immediate Containment

Recommended priority actions:

Revoke Suspicious
Session

      ↓

Revoke All
Active Sessions

      ↓

Reset Password

      ↓

Reset / Re-Register
MFA

      ↓

Remove Mailbox Rule

      ↓

Disable External
Forwarding

      ↓

Review OAuth Grants

      ↓

Monitor Re-Authentication

Part 28 — Why Revoke All Sessions?

Do not only:

Reset Password

because an attacker may retain:

Existing
Authenticated Session

or:

Refresh Token

The response must address:

Credentials
+
Sessions

Part 29 — Credential Reset

Reset:

User Password

and invalidate:

Known
Authentication Tokens

according to the identity platform’s response procedures.

Part 30 — MFA Reset

Because the user approved a malicious MFA request:

Review Registered
Authentication Methods

and perform:

MFA Reset
or
Re-Registration

if required by policy.

Part 31 — Remove Email Persistence

Delete:

FinanceReports

mailbox rule.

Disable:

External Forwarding

Then search:

All Mailbox Rules

for unexpected changes.

Part 32 — Search for Additional Email Activity

Investigate:

Sent Mail

Deleted Mail

Search Activity

Downloads

External Forwarding

Other Rules

Part 33 — Search Other Accounts

The source IP:

203.0.113.91

should be searched across identity logs.

Question:

Did the Same
Source Attempt
Other Accounts?

Assume you find:

12 Other Users

Authentication Failures

No Additional
Successful Login

Important Finding

The incident may be part of:

Password Spray

or

Credential Attack

against multiple users.

Part 34 — Expand Scope

Create:

Related_Account_Review.csv

with:

User	Failed Attempts	Success	MFA	Status
Emily Carter	8	Yes	Approved	Compromised
User 02	3	No	N/A	Targeted
User 03	2	No	N/A	Targeted
…	…	…	…	…

Part 35 — Threat Hunting Pivot

Search:

Source IP

      ↓

All Users

      ↓

All Applications

      ↓

Last 24 Hours

Then search for:

Same User Agent

Same Device Fingerprint

Same ASN

Similar Authentication
Pattern

Part 36 — MITRE ATT&CK Mapping

Create:

MITRE_ATTACK_Mapping.csv

Possible mapping:

Activity	Tactic	Technique
Credential use	Credential Access / Initial Access context	Valid Accounts
MFA push abuse	Credential Access / Defense Evasion context	Authentication Process Abuse
Cloud/email login	Initial Access / Persistence context	Valid Accounts
Mailbox rule	Persistence	Email Collection / Account Manipulation context
Directory searches	Discovery	Account Discovery
AWS billing access	Discovery / Collection	Cloud Service Discovery

Use the ATT&CK mappings appropriate to your approved curriculum and current ATT&CK version.

Part 37 — Attack Story

Your current incident narrative is:

Unknown Actor
Possesses Emily's
Password

      ↓

Attempts Authentication

      ↓

Repeated MFA
Challenges Sent

      ↓

User Denies
Two Requests

      ↓

User Accidentally
Approves Third

      ↓

Attacker Gains
Authenticated Session

      ↓

Accesses Email

      ↓

Performs
Directory Discovery

      ↓

Accesses AWS
Billing Information

      ↓

Creates
Mailbox Rule

      ↓

Enables External
Forwarding

Part 38 — Containment Plan

Create:

Containment_Plan.md

Use:

# Incident

Confirmed Account Compromise

# Identity Actions

Revoke all sessions

Reset password

Review authentication methods

Reset MFA where required

Review privilege assignments

# Email Actions

Remove malicious rule

Disable external forwarding

Review mailbox audit activity

Search sent/deleted messages

# Cloud Actions

Review cloud activity

Validate no privilege changes

Review billing exports

Monitor renewed access

# SOC Actions

Block / monitor source IP
according to policy

Search related users

Hunt similar MFA patterns

Monitor reauthentication

# User Actions

Notify user

Provide MFA fatigue guidance

Confirm safe reauthentication

Part 39 — Escalation

This incident requires escalation because:

Confirmed
Unauthorized Access

      +

MFA Abuse

      +

Email Persistence

      +

Sensitive Application
Access

Escalate to:

Tier 2 SOC

Incident Response

Identity Team

Email Security

Cloud Security

as appropriate.

Part 40 — Escalation Handoff

Create:

Escalation_Handoff.md

Use:

# Incident

Confirmed account compromise
involving Emily Carter.

# Initial Alert

Repeated password failures,
successful authentication,
multiple MFA denials and
subsequent MFA approval.

# Key Evidence

User denied initiating login.

Unknown unmanaged Linux device.

Source IP associated with
credential abuse activity.

Concurrent legitimate
London session.

Unauthorized mailbox rule.

External forwarding enabled.

AWS billing dashboard accessed.

# Scope

Identity:
Confirmed compromise.

Email:
Affected.

AWS Billing:
Accessed.

Endpoint:
No compromise
currently identified.

# Containment Recommended

Revoke sessions.

Reset password.

Reset MFA.

Remove mailbox rule.

Disable forwarding.

Review OAuth.

Search other targeted accounts.

# Priority

High.

# Required Teams

Tier 2 SOC

Incident Response

Identity

Email

Cloud Security

Part 41 — SOC Investigation Report

Create:

SOC_Investigation_Report.md

Use:

# Case Information

Case ID:
CASE-2047

Alert:
Suspicious Authentication
with MFA Anomaly

# Initial Severity

High

# User

Emily Carter

# Initial Alert

Document alert details.

# Investigation Scope

Identity

MFA

Device

Email

AWS

Endpoint

# Evidence Reviewed

Authentication Logs

MFA Logs

Device Information

User Confirmation

Email Audit Logs

Cloud Audit Logs

EDR

Threat Intelligence

# Timeline

Reference:
Authentication_Timeline.csv

# Investigation

Document investigation
chronologically.

# Findings

Confirmed unauthorized
authentication.

MFA fatigue contributed
to access.

Suspicious session
used unmanaged device.

Mailbox rule created.

External forwarding enabled.

AWS billing information
accessed.

No endpoint compromise
currently identified.

# Classification

Confirmed
Account Compromise

# Confidence

High

# Severity

High

# Scope

Identity:
Affected

Email:
Affected

AWS Billing:
Accessed

Corporate Endpoint:
No compromise identified

# Containment

Document actions.

# Escalation

Tier 2 / IR required.

# Outstanding Questions

Credential theft source

Potential email exposure

Other targeted accounts

Potential additional sessions

# Analyst Conclusion

Document final
evidence-based assessment.

Part 42 — Final Analyst Conclusion

Example:

Investigation confirmed
unauthorized access to
Emily Carter's enterprise
account.

Authentication logs showed
multiple failed password
attempts followed by a
successful authentication
from a previously unseen
unmanaged Linux device
located outside the user's
normal operating geography.

The authentication generated
multiple MFA push requests.
The user confirmed denying
the first two requests and
accidentally approving the
third despite not initiating
the login.

After authentication,
the suspicious session
accessed corporate email,
the finance application
and AWS billing information.

Email audit records confirmed
that the suspicious session
created a new inbox rule
and enabled forwarding to
an external address.

No evidence currently
indicates compromise of
the user's assigned
corporate endpoint.

The incident is assessed
with high confidence as
an account compromise
involving MFA push abuse.

Immediate session revocation,
credential reset, MFA reset,
email remediation and
expanded identity hunting
are required.

Part 43 — Facts vs Hypotheses

Facts:

User Denied
Initiating Login

MFA Denials
Occurred

MFA Approval
Occurred

Unknown Device
Used

Mailbox Rule
Created

Forwarding
Enabled

Hypotheses:

Password Was
Stolen by Phishing

Attacker Is
Specific Threat Actor

Sensitive Email
Was Exfiltrated

These require additional evidence.

Part 44 — What Not to Claim

Do not state:

Phishing Caused
the Compromise

unless evidence proves it.

Do not state:

Data Was Stolen

only because forwarding was configured.

Do not state:

Corporate Laptop
Was Clean Forever

because current EDR review found no evidence.

Use:

No Evidence
Currently Identified

Part 45 — Investigation Decision Tree

Suspicious Login
      ↓
Was User
Responsible?
      │
      ├── Yes
      │    ↓
      │ Continue
      │ Context Review
      │
      └── No
           ↓
      Unauthorized
      Authentication
           ↓
      What Happened
      After Login?
           ↓
      Session Activity
           ↓
      Persistence?
           ↓
      Data Access?
           ↓
      Contain
           ↓
      Escalate

Part 46 — Authentication Investigation Checklist

Use this checklist for future investigations:

01 User

02 Source IP

03 Geography

04 Device

05 Password Result

06 MFA Result

07 MFA Denials

08 MFA Registration

09 Concurrent Sessions

10 Login Baseline

11 User Confirmation

12 Post-Login Activity

13 Privilege Changes

14 Mailbox Rules

15 Cloud Activity

16 OAuth Grants

17 Endpoint Activity

18 Related Accounts

19 Session Revocation

20 Credential Reset

Part 47 — Common Analyst Mistakes

Avoid:

Calling Impossible Travel
an Automatic Compromise

Trusting MFA Approval

Ignoring Concurrent Sessions

Stopping After
Password Reset

Ignoring Mailbox Rules

Ignoring Cloud Activity

Ignoring Other
Targeted Users

Assuming Credential
Theft Method

Part 48 — Why Post-Login Activity Matters

If you investigated only:

Authentication

you might conclude:

Suspicious Login

But post-login telemetry reveals:

Mailbox Rule

External Forwarding

Cloud Access

which changes the case to:

Confirmed
Compromise

Part 49 — Why User Verification Matters

User confirmation is strong contextual evidence.

But it should still be correlated with:

Technical Logs

Device

MFA

Session

Activity

because:

Human Memory
Can Be Wrong

Part 50 — Why Session Analysis Matters

Modern attacks may continue through:

Sessions

Tokens

Cookies

Refresh Tokens

even after:

Password Change

Therefore account containment must consider:

Authentication
State

not only credentials.

Mission Success Criteria

You have successfully completed this lab when you can explain:

Why the Alert
Was Suspicious

Why MFA Denials
Mattered

Why the New Device
Mattered

Why Concurrent
Sessions Mattered

Why User Confirmation
Changed the Case

What Post-Login
Activity Proved

Why the Mailbox Rule
Was Important

How AWS Activity
Affected Scope

Why the Endpoint
Was Not Automatically
Considered Compromised

Why Session Revocation
Was Required

Why Password Reset
Alone Was Insufficient

Why the Case
Required Escalation

Portfolio Deliverables

Keep:

01 Alert_Triage_Worksheet.csv

02 Authentication_Timeline.csv

03 User_Baseline.csv

04 Device_Investigation.csv

05 MFA_Analysis.csv

06 Session_Activity.csv

07 Identity_Change_Register.csv

08 Evidence_Register.csv

09 Compromise_Findings.csv

10 Incident_Scope.csv

11 MITRE_ATTACK_Mapping.csv

12 Related_Account_Review.csv

13 Containment_Plan.md

14 Escalation_Handoff.md

15 SOC_Investigation_Report.md

Portfolio Structure

Lab 02 — Suspicious Authentication Investigation
│
├── 01 Alert
├── 02 Authentication
├── 03 User Baseline
├── 04 Device
├── 05 MFA
├── 06 Sessions
├── 07 Identity Changes
├── 08 Evidence
├── 09 Findings
├── 10 Scope
├── 11 ATT&CK
├── 12 Related Accounts
├── 13 Containment
├── 14 Escalation
└── 15 Investigation Report

Knowledge Check

1. What makes an authentication alert suspicious?

2. Why does a new IP not automatically prove compromise?

3. Why is authentication baseline useful?

4. Why is a new device important?

5. What is MFA fatigue?

6. Why are repeated MFA denials followed by approval suspicious?

7. Does MFA approval prove a login is legitimate?

8. Why should MFA registration changes be reviewed?

9. What is a concurrent session?

10. Why can concurrent geographic sessions be important?

11. What is impossible travel?

12. Why does impossible travel not prove compromise?

13. Why is user verification useful?

14. What technical evidence should support user verification?

15. Why should post-login activity always be reviewed?

16. What does a mailbox rule tell an analyst?

17. Why is external forwarding high risk?

18. Why should OAuth grants be reviewed?

19. What cloud activity should be checked after account compromise?

20. Why should endpoint telemetry still be reviewed?

21. Does identity compromise automatically mean endpoint compromise?

22. Why should the source IP be searched across all users?

23. What is incident scope?

24. What is the difference between confirmed and unknown scope?

25. Why should facts and hypotheses be separated?

26. Why should the method of credential theft remain unknown without evidence?

27. Why must sessions be revoked?

28. Why is a password reset alone insufficient?

29. When should MFA be reset?

30. Why should mailbox rules be removed?

31. Why should related users be hunted?

32. When should the case be escalated?

33. What makes this a confirmed account compromise?

34. What factors influence severity?

35. What makes the final conclusion defensible?

Key Takeaways

Authentication investigation follows:

Alert
      ↓
User
      ↓
Source
      ↓
Device
      ↓
MFA
      ↓
Session
      ↓
Post-Login Activity
      ↓
Scope
      ↓
Containment

Remember:

New Location
      ≠
Compromise

MFA Approved
      ≠
User Authorized

Password Reset
      ≠
Session Revoked

Identity Compromise
      ≠
Endpoint Compromise

Mailbox Forwarding
      ≠
Confirmed Exfiltration

but:

User Denial
+
MFA Fatigue
+
Unknown Device
+
Unauthorized Session
+
Malicious Post-Login Activity

can provide strong evidence of:

Account
Compromise

The professional workflow is:

Authentication
      ↓
Validation
      ↓
Session Analysis
      ↓
Activity Analysis
      ↓
Scope
      ↓
Containment
      ↓
Escalation

Career Connection

This lab mirrors real work performed by:

SOC Analysts

Identity Security Analysts

Blue Team Analysts

Incident Responders

Security Operations Analysts

During an interview, you should be able to explain:

I investigated
a suspicious authentication
alert involving repeated
password failures,
MFA denials and a
successful login from
an unknown device.

I established the user's
normal authentication
baseline, reviewed the
source IP, device,
concurrent sessions and
MFA events.

The user confirmed
they had not initiated
the login and had
accidentally approved
one of several MFA prompts.

I correlated the
suspicious session with
mailbox rule creation,
external forwarding and
cloud application access.

I assessed the account
as compromised,
recommended immediate
session revocation,
credential and MFA reset,
email remediation and
expanded hunting across
other targeted accounts.

What’s Next?

➡️ Next: Lab 03 — Phishing Email Investigation

You now know how to investigate:

Suspicious
Authentication

and determine whether credentials were actually abused.

The next question is:

How Might
Those Credentials
Have Been Stolen?

In the next lab, you will investigate a suspicious email from the moment it enters the enterprise.

You will analyze:

Sender

Email Headers

SPF

DKIM

DMARC

URLs

Domains

Attachments

Recipients

Email Gateway

Threat Intelligence

User Interaction

You will determine whether the message represents:

Spam

Benign Email

Credential Phishing

Malware Delivery

Business Email
Compromise Attempt

You will also determine:

Who Received It?

Who Clicked?

Who Submitted
Credentials?

What Should
Be Blocked?

What Should
Be Removed?

Which Users
Require Follow-Up?

➡️ Next: Lab 03 — Phishing Email Investigation