"Lab 02 — Security Log Analysis Fundamentals"

Mission Information

Item	Details
Lab	02
Lab Name	Security Log Analysis Fundamentals
Track	CompTIA CySA+
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ Cybersecurity Analyst Lab
Primary Systems	Windows + Linux + Analyst Workstation
Skills	Log Analysis, Event Investigation, Authentication Analysis, Event Correlation

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

Your SOC receives thousands of events from endpoints, servers, applications, identity systems, firewalls, and security tools.

Most events are normal.

Some may indicate:

• failed authentication

• unauthorized access attempts

• account misuse

• privilege escalation

• suspicious process execution

• configuration changes

• attacker activity

Your responsibility is not simply to read individual log entries.

You must determine:

What happened, when it happened, where it happened, who performed the activity, and whether the activity is suspicious.

In this mission, you will generate security activity across Windows and Linux systems and investigate the resulting telemetry.

---

Mission Objectives

By completing this lab, you will be able to:

• understand the purpose of security logs

• identify common security log sources

• analyze Windows Security events

• analyze Linux authentication events

• investigate successful and failed authentication

• filter large volumes of events

• identify important event attributes

• construct basic investigation timelines

• correlate related events

• distinguish normal activity from potentially suspicious behavior

• document investigation findings

---

1. Understanding Security Telemetry

Security analysts depend on telemetry generated throughout enterprise environments.

Common sources include:

Endpoints
   ↓
Operating System Logs
   ↓
Authentication Logs
   ↓
Application Logs
   ↓
Network Devices
   ↓
Security Products
   ↓
Cloud Platforms
   ↓
SIEM

Examples include:

Source	Example Telemetry
Windows	Security Event Log
Linux	Authentication logs
Firewall	Allowed/blocked connections
IDS/IPS	Attack alerts
Endpoint Security	Malware/process activity
DNS	Domain queries
Proxy	Web requests
Cloud	API and identity activity
Applications	Login and application events

Later labs will centralize many of these events using a SIEM.

For now, you will investigate them directly on the systems that generated them.

---

2. The Five Questions of Log Analysis

When analyzing an event, begin with five questions.

WHO?
WHAT?
WHEN?
WHERE?
RESULT?

For example:

WHO:
analyst01

WHAT:
SSH login

WHEN:
21:14:32

WHERE:
CYSA-LINUX01

RESULT:
Successful

These questions help transform raw telemetry into an investigation.

---

3. Verify Your Lab Environment

Start the three virtual machines created during Lab 01:

CYSA-ANALYST
10.10.10.10

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

From the analyst workstation, verify connectivity:

ping -c 4 10.10.10.20

Then:

ping -c 4 10.10.10.30

Your lab should resemble:

                   CYSA-ANALYST
                    10.10.10.10
                          |
                 Isolated Lab Network
                          |
              +-----------+-----------+
              |                       |
        CYSA-WIN01              CYSA-LINUX01
        10.10.10.20             10.10.10.30

---

4. Create an Investigation Workspace

On CYSA-ANALYST, create a folder for this investigation:

mkdir -p ~/CySA-Lab/Investigations/LAB02

Create evidence directories:

mkdir -p ~/CySA-Lab/Investigations/LAB02/{Logs,Screenshots,Findings}

Create an investigation notes file:

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

---

5. Investigate Windows Security Logs

Log into:

CYSA-WIN01

Open:

Event Viewer

Navigate to:

Windows Logs
→ Security

Review several events.

Pay attention to:

Time Created
Event ID
Level
Source
User
Computer
Task Category
Event Data

The Windows Security log contains important telemetry related to:

• authentication

• account management

• privilege use

• process execution

• security policy changes

• auditing activity

---

6. Important Windows Security Event IDs

Cybersecurity analysts should recognize frequently encountered Event IDs.

Event ID	Description
4624	Successful logon
4625	Failed logon
4634	Account logged off
4648	Logon attempted using explicit credentials
4672	Special privileges assigned to a new logon
4688	New process created
4720	User account created
4722	User account enabled
4724	Password reset attempted
4726	User account deleted
4732	Member added to local security group

You do not need to memorize every Windows Event ID.

The important skill is understanding what evidence you need and how to find it.

---

7. Query Recent Windows Events

Open PowerShell as Administrator.

Run:

Get-WinEvent -LogName Security -MaxEvents 20

Now display selected fields:

Get-WinEvent -LogName Security -MaxEvents 20 |
Select-Object TimeCreated, Id, ProviderName

You should see output similar to:

TimeCreated              Id
-----------              ----
25/08/2026 20:31:44      4624
25/08/2026 20:31:44      4672
25/08/2026 20:30:10      4634

Your actual events will be different.

---

8. Generate Successful Authentication Activity

Lock the Windows workstation:

Windows Key + L

Log back into the system normally.

Return to PowerShell.

Query successful authentication:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624
} -MaxEvents 10

Record:

Timestamp
Username
Computer
Event ID
Logon Type
Source Information

---

9. Understanding Windows Logon Types

Event ID 4624 includes a Logon Type.

Common examples include:

Logon Type	Meaning
2	Interactive
3	Network
4	Batch
5	Service
7	Unlock
8	Network cleartext
9	New credentials
10	Remote interactive
11	Cached interactive

The logon type provides important context.

For example:

4624 + Logon Type 2

may represent a normal local login.

Whereas:

4624 + Logon Type 10

may indicate a remote interactive session.

Neither is automatically malicious.

Context determines whether the activity is suspicious.

---

10. Generate Failed Authentication Events

For this exercise, generate a few controlled failed login attempts on your own lab system only.

Lock:

CYSA-WIN01

Enter an incorrect password two or three times.

Then authenticate correctly.

Return to PowerShell.

Search for failed logons:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
} -MaxEvents 10

Inspect the newest events.

Look for:

Account Name
Failure Reason
Logon Type
Source Network Address
Workstation Name
Timestamp

---

11. Filter Windows Events by Time

Large enterprise systems can generate enormous numbers of events.

Analysts therefore filter telemetry.

Create a start time:

$StartTime = (Get-Date).AddMinutes(-30)

Search recent failed authentication:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
    StartTime=$StartTime
}

You have now narrowed the investigation to a specific time window.

---

12. Investigate Process Creation

If process auditing was enabled during Lab 01, generate several processes.

Run:

whoami

Then:

ipconfig

Then:

netstat -ano

Now search for Event ID 4688:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4688
} -MaxEvents 20

Look for:

New Process Name
Creator Process
Subject User
Process ID
Timestamp

Process telemetry becomes extremely important during malware and endpoint investigations.

---

13. Build a Windows Activity Timeline

Using the events you generated, create a simple timeline.

Example:

Time	Event ID	Activity	Result
20:10	4625	Login attempt	Failed
20:11	4625	Login attempt	Failed
20:12	4624	Login	Successful
20:12	4672	Privileges assigned	Successful
20:14	4688	Process executed	Successful

Notice how individual events begin forming a story.

Failed Login
     ↓
Failed Login
     ↓
Successful Login
     ↓
Privilege Assignment
     ↓
Process Execution

This is the beginning of event correlation.

---

14. Investigate Linux Authentication Logs

Move to:

CYSA-LINUX01

Check authentication logs:

sudo tail -n 30 /var/log/auth.log

Depending on your Linux distribution, authentication events may instead be primarily available through the systemd journal.

Run:

sudo journalctl -u ssh -n 30

Look for:

Timestamp
Hostname
Service
Process ID
Username
Source IP
Authentication Result

---

15. Generate Successful SSH Activity

From CYSA-ANALYST:

ssh <username>@10.10.10.30

Enter the correct password.

After connecting:

whoami

Then:

hostname

Exit:

exit

Return to CYSA-LINUX01.

Run:

sudo grep "Accepted" /var/log/auth.log | tail

Or:

sudo journalctl -u ssh --since "10 minutes ago"

Identify the successful authentication event.

---

16. Generate Failed SSH Authentication

From CYSA-ANALYST, connect again:

ssh <username>@10.10.10.30

Enter an incorrect password once or twice, then terminate the attempt.

This activity must remain limited to your own isolated lab environment.

Return to CYSA-LINUX01.

Search:

sudo grep "Failed password" /var/log/auth.log | tail

If your system primarily uses the journal:

sudo journalctl -u ssh --since "10 minutes ago"

Look for failed authentication entries.

---

17. Compare Successful and Failed SSH Events

You should now have two types of events.

Successful

Typical fields include:

Accepted password
Username
Source IP
Source Port
SSH Protocol

Failed

Typical fields include:

Failed password
Username
Source IP
Source Port
SSH Protocol

Compare them.

Ask:

Was the same account targeted?

Did both originate from the same IP?

How many failures occurred?

Was a successful login observed afterward?

How close together were the events?

---

18. Count Failed Authentication Events

On Linux:

sudo grep "Failed password" /var/log/auth.log | wc -l

To examine source addresses:

sudo grep "Failed password" /var/log/auth.log

For a small lab, manual inspection is sufficient.

In enterprise environments, analysts use SIEM queries and aggregation to perform this analysis across millions of events.

---

19. Understand Suspicious Authentication Patterns

Consider these two situations.

Scenario A

10:00 Failed login — user01
14:20 Failed login — user01

This could simply be normal user error.

Scenario B

10:00:01 Failed — admin
10:00:03 Failed — administrator
10:00:05 Failed — root
10:00:07 Failed — support
10:00:09 Failed — backup

This pattern deserves investigation.

Potential indicators include:

• high authentication frequency

• many targeted accounts

• unusual source addresses

• privileged accounts being targeted

• failures followed by success

• activity outside normal working hours

• unexpected remote access

A single event rarely provides the entire answer.

---

20. Correlate Source IP Activity

Your SSH activity originated from:

CYSA-ANALYST
10.10.10.10

Your Linux logs should therefore contain references to:

10.10.10.10

Search:

sudo grep "10.10.10.10" /var/log/auth.log

You are now investigating events using a known indicator.

This same technique applies to:

IP addresses
Usernames
Hostnames
Domains
File hashes
Process names
Email addresses
URLs

---

21. Investigate sudo Activity

Run a privileged command on the Linux server:

sudo whoami

Then:

sudo apt update

Search authentication telemetry:

sudo grep "sudo" /var/log/auth.log | tail -n 20

Look for:

Username
Command
Working Directory
Target User
Timestamp

Privilege activity is important because attackers frequently attempt to elevate privileges after gaining access.

---

22. Compare Windows and Linux Authentication Telemetry

You have now investigated authentication on two operating systems.

Investigation Field	Windows	Linux
Successful login	Event 4624	Accepted authentication
Failed login	Event 4625	Failed authentication
Privilege activity	4672 / related events	sudo
User	Account Name	Username
Source	Source Network Address	Source IP
Time	TimeCreated	Syslog/journal timestamp

The syntax differs.

The investigation questions remain similar.

Who authenticated?

Where did they authenticate?

Where did they come from?

Was authentication successful?

What happened afterward?

---

23. Create an Investigation Timeline

Build a timeline containing events from your lab.

Example:

20:10:01
Failed Windows authentication

20:10:10
Failed Windows authentication

20:11:02
Successful Windows authentication

20:15:33
SSH authentication failed

20:15:40
SSH authentication failed

20:16:04
SSH authentication successful

20:17:12
sudo command executed

A timeline helps analysts understand the sequence of activity.

---

24. Event Correlation

Suppose your logs show:

21:10:01
Multiple authentication failures

21:10:45
Successful authentication

21:11:20
Privileged command executed

Individually:

Failed Login
Successful Login
Privileged Command

may not prove malicious activity.

Together:

Repeated Failures
       ↓
Successful Authentication
       ↓
Privilege Activity

may represent a security investigation worth escalating.

This is correlation.

---

25. Identify Baseline vs Anomaly

Analysts need to understand normal behavior before identifying abnormal behavior.

Potential Baseline

User: analyst01
System: CYSA-WIN01
Login Time: 09:00
Source: Local
Frequency: Daily

Potential Anomaly

User: analyst01
System: CYSA-WIN01
Login Time: 02:30
Source: Unknown remote address
Failures: 25
Successful Login: Yes

Anomaly does not automatically mean compromise.

It means:

Investigate further.

---

26. Create an Investigation Record

Document your findings in:

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

Use:

# LAB02 Investigation

## Investigation ID

LAB02-AUTH-001

## Systems

CYSA-WIN01
CYSA-LINUX01

## Observation

Multiple authentication events were generated and reviewed.

## Windows Evidence

Event IDs:
- 4624
- 4625
- 4672
- 4688

## Linux Evidence

Sources:
- auth.log
- systemd journal

## Indicators

Source IP:
10.10.10.10

## Timeline

Add observed events here.

## Assessment

Document whether the observed activity appears expected or suspicious.

## Recommended Action

Document any additional investigation that would be required.

---

27. Mission Challenge — Authentication Investigation

You are now the SOC analyst responsible for investigating the following alert:

Multiple failed authentication attempts were observed shortly before a successful login.

Using only telemetry generated inside your lab, investigate the activity.

Determine:

1. Which account was targeted?

2. Which system received the authentication attempts?

3. What source generated the activity?

4. How many failures occurred?

5. Was authentication eventually successful?

6. What happened after authentication?

7. Were privileged commands executed?

8. What evidence supports your conclusion?

9. Does the activity appear expected or suspicious?

10. Would you escalate the event?

---

28. Analyst Findings

Create a short findings summary.

Example:

Investigation ID:
LAB02-AUTH-001

Affected Asset:
CYSA-LINUX01

Source:
10.10.10.10

Account:
analyst01

Observed Activity:
Multiple failed SSH authentication attempts followed by successful authentication.

Post-Authentication Activity:
Privileged command execution observed.

Assessment:
Activity was generated intentionally as part of the laboratory exercise.

Real-World Assessment:
The same pattern from an unknown source would require additional investigation.

Severity:
Low — Controlled Lab Activity

---

29. Evidence to Capture

Capture evidence demonstrating your investigation.

Recommended evidence:

01-windows-security-log.png
02-windows-4624-success.png
03-windows-4625-failure.png
04-windows-4688-process.png
05-linux-auth-log.png
06-ssh-success.png
07-ssh-failure.png
08-sudo-activity.png
09-source-ip-correlation.png
10-investigation-timeline.png
11-investigation-findings.png

Store evidence under:

CySA-Lab/
└── Investigations/
    └── LAB02/
        ├── Logs/
        ├── Screenshots/
        ├── Findings/
        └── investigation-notes.md

---

30. Validation Checklist

• CySA+ lab environment is operational

• Windows Security logs were reviewed

• Event ID 4624 was investigated

• Event ID 4625 was investigated

• Process telemetry was reviewed

• Linux authentication logs were investigated

• Successful SSH authentication was identified

• Failed SSH authentication was identified

• Source IP information was identified

• sudo activity was investigated

• Events were correlated across a timeline

• Normal and suspicious patterns were compared

• Investigation findings were documented

• Evidence screenshots were captured

---

31. Mission Review

In this lab, you moved beyond simply opening log files.

You followed an analyst workflow:

Generate Activity
       ↓
Find Relevant Logs
       ↓
Filter Events
       ↓
Extract Important Fields
       ↓
Build Timeline
       ↓
Correlate Activity
       ↓
Assess Behavior
       ↓
Document Findings

This is one of the foundational skills of cybersecurity operations.

Raw logs are simply records.

The analyst’s job is to turn those records into a story of what happened.

---

Skills Developed

After completing this mission, you should be able to:

• navigate security logs

• investigate Windows Event Logs

• investigate Linux authentication telemetry

• identify successful and failed authentication

• understand common Windows Event IDs

• interpret Linux SSH authentication events

• filter logs by event and time

• identify source addresses and accounts

• investigate privilege activity

• build basic security timelines

• correlate related events

• recognize suspicious authentication patterns

• document analyst findings

---

What’s Next?

Lab 03 — Windows Event Log Investigation

You now understand the fundamentals of security log analysis.

In the next mission, you will focus specifically on Windows endpoint telemetry.

You will investigate Windows Security, System, PowerShell, and Microsoft Defender-related telemetry and learn how endpoint events can reveal suspicious activity.

You will work with:

• authentication events

• account activity

• process execution

• PowerShell telemetry

• service activity

• scheduled tasks

• security configuration changes

• endpoint security events

• event correlation

• investigation timelines

The objective is to move from basic log analysis toward endpoint-focused security investigation.

➡️ Next: Lab 03 — Windows Event Log Investigation