Read Security Logs Like a SOC Analyst

Investigate a simulated security incident across Windows, network, and syslog sources.

Introduction

30 Second Summary

Every time someone logs into a computer, opens a web page, or gets blocked by a firewall, a log entry is created somewhere. Security analysts read these logs every single day to figure out what happened when something goes wrong.

In this project, you will investigate a simulated security incident by reading three different types of logs, just like a real SOC analyst would on their first day at a new job.

What You'll Build

Imagine a new alert fires at work and you need to figure out what happened. You open the Windows Security Event Logs, trace the network traffic in a packet capture, decode a firewall's syslog messages, and piece together a timeline that tells the full story of an attack.

By the end of this project, you'll have:

  • The ability to open any Windows Security event and immediately identify who logged in, when, how, and whether it succeeded or failed.
  • The skill to open a PCAP file in Wireshark and trace a network conversation between two machines, identifying protocols and suspicious patterns.
  • The confidence to look at a raw syslog line and decode the priority value into its facility and severity, identifying what system sent it and how urgent it is.
  • A completed incident timeline that correlates timestamps and indicators across all three log types to reconstruct what happened during the attack.
  • Secret Mission: Write a formal mini incident report summarizing your findings across all three log sources.

Do I need any prior experience?

No prior cybersecurity or programming experience is required. You just need a Windows computer. This project includes setup instructions for every tool you will use, including Wireshark (free to download).

Before We Start

Before you start opening logs and running commands, take a moment to lock in what you are about to investigate and why it matters.

Read Windows Security Event Logs

Your tools are installed and your admin access is confirmed. Now it is time to investigate your first log source.

Windows Security logs are the first place a SOC analyst looks when investigating account compromises. Every logon, failed password attempt, and privilege escalation on your machine is recorded here. In this step, you will explore these events on your own machine and learn how to find what matters.

In this step, get ready to:
  • Explore Windows Security events in Event Viewer and see the volume problem firsthand.
  • Use PowerShell to surgically query specific Event IDs.
  • Create a personal cheat sheet of key Event IDs and Logon Types.
Explore Event Viewer manually

Before using any automation, a SOC analyst should see the raw logs with their own eyes. Event Viewer is the built-in Windows tool for browsing event logs. You will open it and navigate to the Security log to see what your machine has been recording.

  • Press the Windows key to open your search bar.
  • Type Event Viewer and press Enter to open it.
  • In the left pane, expand Windows Logs.
  • Click Security.

The results pane fills with hundreds or thousands of individual security events. Each row is one thing that happened on your machine.

  • Scroll through the list and notice the sheer volume of events.
  • Find any event with Event ID 4624 in the list and click on it.
  • Look at the General tab in the lower pane to see the event details.

What do these fields mean?

Event ID 4624 means a user successfully logged on to this computer. Inside the event details, look for these key fields:

  • Account Name: who logged in.
  • Logon Type: how they logged in. Type 2 means interactive (at the keyboard). Type 3 means over the network. Type 10 means Remote Desktop.
  • Source Network Address: where they came from.
  • TimeCreated: when it happened.

Now scroll through a few more events. Notice how many come from SYSTEM or service accounts performing routine background tasks.

Finding a specific human logon manually is like finding a needle in a haystack. This is the core problem: thousands of routine system events bury the interesting ones, making manual browsing impractical.

Don't see any events in the Security log?

Ensure you opened Event Viewer with administrator privileges. The Security log requires admin access to read. Close Event Viewer, right-click it in your search results, and select Run as administrator.

help me troubleshoot why my Security log is empty in Event Viewer

Use PowerShell to cut through the noise

Manual browsing cannot scale. PowerShell lets you query the Security log with surgical precision, filtering by Event ID to find exactly what matters. Think of it as a search engine for your logs.

  • Switch back to your admin PowerShell window from earlier.
  • Find all failed login attempts by running this command:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} -MaxEvents 10

What does this command do?

Get-WinEvent reads from the Windows event log. The -FilterHashtable parameter narrows results to the Security log and Event ID 4625 only. Event ID 4625 means a logon attempt failed (bad password or unknown username). Repeated failures from the same source often indicate a brute-force attack.

You should see up to 10 failed logon events listed with timestamps and account information. If your machine has no failed logons, you may see fewer results or an empty list.

  • Now find successful logons with more detail by running:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} -MaxEvents 5 | Format-List TimeCreated, Id, Message

Why pipe to Format-List?

Format-List expands each event into readable fields (timestamp, ID, and the full message body) instead of a cramped table view. This lets you see the Account Name, Logon Type, and Source Network Address inside each event's message.

You should see five successful logon events, each showing the full details of who logged in, when, and how.

  • Finally, find privileged logons (admin sessions) by running:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4672} -MaxEvents 3

What is Event ID 4672?

Event ID 4672 means special privileges were assigned to a new logon. In plain terms, someone logged in with admin-level access. In an investigation, this event tells you whether an attacker gained elevated privileges after getting in.

Notice what you CAN see from these events: who logged in, when, the logon type, and whether it succeeded or failed. Notice what you CANNOT see: what the user did on the network after logging in, what servers they connected to, or what data moved. Windows logon events tell you the door opened, but not where the person went afterward.

Getting 'No events were found' for some queries?

This is normal. Your machine may not have recorded events of every type. For example, if nobody has failed a login attempt on your computer, Event ID 4625 will return nothing. The important thing is that the command ran without errors.

help me understand why Get-WinEvent returns no events for a specific Event ID

Build a quick-reference cheat sheet

SOC analysts keep reference notes for the Event IDs they see most often. You will create a text file that becomes your personal lookup whenever you investigate Windows logs in the future.

  • Create a new text file called windows-events-cheatsheet.txt in your logs-lab folder on your Desktop.
  • Open the file in Notepad (or any text editor) and type the following reference content:
4624 = Successful logon
4625 = Failed logon (repeated failures = brute force)
4672 = Special privileges assigned (admin logon)
4634 = Logoff
4648 = Logon using explicit credentials (RunAs)

Logon Type 2 = Interactive (at the keyboard)
Logon Type 3 = Network (from another machine)
Logon Type 10 = Remote Desktop

Why these specific IDs?

These five Event IDs cover the most common account-related security events. In a real investigation, you would search for 4625 to spot brute-force attempts, 4624 to confirm a successful compromise, and 4672 to determine if the attacker gained admin privileges.

The Logon Types tell you HOW someone logged in. Type 3 (Network) from an unexpected source is often more suspicious than Type 2 (Interactive), because it means someone connected remotely.

  • Save windows-events-cheatsheet.txt.

✔️ Awesome, I've got everything!

Great. Make sure you have saved your cheat sheet file.

ⓧ I'd like to double check the full code

Your windows-events-cheatsheet.txt should contain these lines:

4624 = Successful logon
4625 = Failed logon (repeated failures = brute force)
4672 = Special privileges assigned (admin logon)
4634 = Logoff
4648 = Logon using explicit credentials (RunAs)

Logon Type 2 = Interactive (at the keyboard)
Logon Type 3 = Network (from another machine)
Logon Type 10 = Remote Desktop

Now let's confirm your PowerShell querying skills with a final check.

Before you run the next command, predict: how many logon events do you think your machine has recorded? Do you think all five will show your own account name, or will some be system accounts?

  • Run this verification command in your admin PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} -MaxEvents 5

You should see five logon events returned, each with a TimeCreated timestamp and event details. Most of them will likely be system or service account logons rather than your personal account. That is normal and exactly what a SOC analyst would see on any Windows machine.

Command returns an error?

If you see an access denied message, your PowerShell session may have lost its admin elevation. Close the window and reopen PowerShell by right-clicking and selecting Run as administrator.

help me fix access denied errors when running Get-WinEvent in PowerShell

You have now decoded Windows Security events using both the GUI and the command line. You know the key Event IDs by heart. Next up, you will open a network packet capture in Wireshark to see what happens AFTER someone logs in, filling the gap that host logs alone cannot answer.

Read Network Traffic in Wireshark

In the previous step, you explored Windows Security Event Logs and saw exactly who logged in, when, and how. But you also noticed a gap: Windows logs tell you a door opened, they cannot tell you where the person went afterward.

Network packet captures fill that gap. A PCAP file records every conversation that happened on the wire. In this step, you will open a real capture file in Wireshark and learn to isolate and read network conversations, just like a SOC analyst hunting for post-compromise activity.

In this step, get ready to:
  • Open a PCAP file in Wireshark and understand the three-pane layout.
  • Apply display filters to isolate specific traffic from the noise.
  • Follow a TCP stream to reconstruct a full HTTP conversation.
Open the sample PCAP and orient yourself

Your Http.cap file contains a real network capture of HTTP traffic. Opening it in Wireshark is like pressing play on a security camera recording of network activity.

  • Press the Windows key to open your search bar.
  • Type Wireshark and press Enter to open it.
  • Click File in the Wireshark menu bar.
  • Click Open.
  • Navigate to your Http.cap file (in your logs-lab folder on the Desktop) and open it.

You should see the packet list populate with rows of data. Each row is one packet that traveled across the network.

What am I looking at?

Wireshark shows you three panes. The top pane is the packet list, with columns: No., Time, Source, Destination, Protocol, Length, Info.

Click on any packet. The middle pane shows the packet decoded layer by layer (Ethernet, IP, TCP, HTTP). The bottom pane shows the raw bytes. This three-pane layout is how you will always work in Wireshark.

Notice the color coding in the packet list. Different colors represent different protocols, helping you scan visually for patterns.

Don't see any packets?

Make sure you opened Http.cap (not a different file). If you see a blank screen, the file may not have downloaded correctly. Re-download it from the Wireshark SampleCaptures page and try again.

help me open a PCAP file in Wireshark

Apply display filters to find what matters

Just like PowerShell filtered the noise in Windows logs, Wireshark display filters isolate the traffic you care about. The filter bar sits at the top of the Wireshark window.

  • Click in the display filter bar at the top of the Wireshark window.
  • Type http and press Enter.

The packet list now shows only HTTP traffic. You can see which websites were requested, what data was sent back, and the exact timestamps.

What does this filter show me?

The http filter reveals the "where did they go" information that Windows logs could not provide. You can see GET requests (pages visited), POST requests (data submitted), and server responses.

  • Clear the filter bar and try typing dns, then press Enter.

This shows only DNS lookups. DNS reveals which domain names a machine tried to resolve, even if the connection itself was encrypted.

  • Clear the filter bar and try this filter for new connection attempts:
tcp.flags.syn==1 && tcp.flags.ack==0

What does this SYN filter show?

This filter shows only SYN packets. A SYN packet is the very first message in any new TCP connection. Seeing a burst of SYN packets to many ports on one machine is a classic sign of a port scan.

  • Clear the filter bar. Look at the Source column and pick any IP address you see in the capture.
  • Type a filter using that IP address to isolate one machine's traffic. For example, if you see 145.254.160.237, type:
ip.addr==145.254.160.237

Replace the IP address with whichever one you spotted in the capture. This isolates every packet to and from that single machine.

Filters are your scalpel

In a real investigation, you might have millions of packets. Display filters let you slice down to just the attacker's IP, just the suspicious port, or just the protocol that matters. Memorize http, dns, and ip.addr== as your starting trio.

Filter shows zero results?

Check for typos in the filter bar. Wireshark highlights the filter bar in green when the syntax is valid and red when something is wrong. If you see red, look for missing equals signs or misspelled protocol names.

For the dns filter: if Http.cap contains no DNS packets, getting zero results is expected. The filter is still working correctly.

help me use Wireshark display filters

Follow a TCP stream to reconstruct a conversation

Display filters show you individual packets, but a real conversation spans many packets back and forth. Wireshark can stitch all the packets from one conversation together into a readable stream.

  • Type http in the filter bar and press Enter to show only HTTP packets.
  • Right-click on any HTTP packet in the packet list.
  • Select Follow, then click TCP Stream.

Before you look at the result, predict: what kind of information do you think this stream will show you?

A new window appears showing the complete conversation in readable text. You can see the HTTP request (the GET line with the path) and the server's full response (headers plus the HTML body). Client traffic appears in one color and server traffic in another.

Why does this matter for investigations?

This is how SOC analysts reconstruct what a user or attacker accessed on the network. If an attacker logged into a server (which you saw in the Windows event logs), this stream view shows you exactly what pages they visited, what data they downloaded, and what commands they sent.

  • Close the stream window by clicking Close at the bottom.
  • Clear the filter bar to see all packets again.

Follow TCP Stream is greyed out?

This option only works when you have a TCP packet selected. If you right-clicked on a non-TCP packet (like an ARP or ICMP packet), the option will be disabled. Make sure the http filter is active first, then right-click one of the filtered packets.

help me follow a TCP stream in Wireshark

You now know how to isolate and read network conversations. You can open any PCAP file, filter to the traffic that matters, and reconstruct exactly what happened on the wire.

You can now read two out of three log sources. Next up, you will decode syslog messages from network devices like firewalls and routers, completing your ability to investigate across all major log types.

Read Syslog Messages

In the last step, you followed TCP streams in Wireshark and reconstructed full network conversations. You now know who logged in AND where they went afterward.

Network devices like firewalls, routers, and switches do not write Windows Event Logs. They send syslog messages instead. If an attacker's traffic crossed a firewall, the evidence lives in syslog, and without this skill you would miss an entire category of security evidence.

In this step, get ready to:
  • Decode the RFC 5424 syslog message format.
  • Calculate facility and severity from a priority value.
  • Identify security-relevant patterns in syslog sequences.
Decode the syslog format

Windows does not natively generate syslog. To practice reading these messages, you will create a file with sample entries that simulate what a SOC analyst receives from network devices like firewalls.

  • Press the Windows key to open your search bar.
  • Type Notepad and press Enter to open it.
  • Paste the following three syslog messages into the empty file:
<34>1 2025-01-03T14:07:15.003Z firewall.corp.local sshd 12345 ID47 - Failed password for root from 203.0.113.50 port 22
<165>1 2025-01-03T14:08:02.000Z switch01.corp.local kernel - - - Link down on interface eth0/1
<38>1 2025-01-03T14:07:20.500Z firewall.corp.local sshd 12345 ID48 - Accepted password for admin from 203.0.113.50 port 22

What is the syslog format?

These messages follow RFC 5424, the standard format for syslog. Each message is structured as:

<Priority>Version Timestamp Hostname App-name ProcID MsgID Structured-Data Message
  • Priority: a number in angle brackets that encodes which system sent the message and how urgent it is.
  • Version: always 1 for RFC 5424 messages.
  • Timestamp: ISO 8601 format showing exactly when the event happened.
  • Hostname: the device that sent the message (e.g. firewall.corp.local).
  • App-name: the application or process that generated the event (e.g. sshd).
  • Message: the human-readable description of what happened.
  • Save the file by pressing Ctrl+S.
  • In the Save As dialog, navigate to your Desktop.
  • Set the File name to syslog-samples.txt and click Save.

You should see the file title in Notepad's title bar change to syslog-samples.txt, confirming the save succeeded.

File saved as .txt.txt?

If Notepad adds a second .txt extension, change the Save as type dropdown to All Files (*.*) before saving. This prevents Notepad from appending its own extension.

Why did my file get a double extension?

Calculate facility and severity from priority

The Priority number in angle brackets encodes two values: which system sent the message (Facility) and how urgent it is (Severity). A single division operation decodes both.

The formula is: Priority = (Facility x 8) + Severity. To reverse it, divide by 8. The quotient is the Facility and the remainder is the Severity.

  • Decode the first sample message with priority <34>:
  • 34 / 8 = 4 remainder 2. Facility 4 = security/authorization (auth). Severity 2 = Critical.
  • Decode the second sample with priority <165>:
  • 165 / 8 = 20 remainder 5. Facility 20 = local use 4 (local4). Severity 5 = Notice.
  • Decode the third sample with priority <38>:
  • 38 / 8 = 4 remainder 6. Facility 4 = security/authorization (auth). Severity 6 = Informational.

What do these severity levels mean?

The first message (failed login) is rated Critical because a failed authentication attempt could signal an attack. The third message (successful login) is Informational because it records routine access. The second message (link down) is a Notice because it describes a noteworthy network change.

Severity tells you where to look first. In a real SOC, you would triage Critical and Alert messages before reading Informational ones.

  • Open your existing windows-events-cheatsheet.txt file from your Desktop.
  • Add the following severity reference at the bottom:
Syslog Severity Reference:
0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debug
  • Save windows-events-cheatsheet.txt.
  • Confirm the severity reference appears at the bottom of the file.

Why add syslog severity to the Windows cheatsheet?

SOC analysts reference all their log knowledge in one place. Keeping Event IDs, Logon Types, and Severity levels in a single file means you have one quick-reference document for any investigation.

Identify security-relevant patterns

Individual log lines tell you facts. Patterns across multiple lines tell you stories. Look at your three sample messages sorted by timestamp and see if a narrative emerges.

  • Switch back to syslog-samples.txt in Notepad.
  • Read the three messages in chronological order:
  • 14:07:15 firewall.corp.local: Failed SSH login for root from 203.0.113.50 (Severity: Critical).
  • 14:07:20 firewall.corp.local: Successful SSH login for admin from the same IP 203.0.113.50 (Severity: Informational).
  • 14:08:02 switch01.corp.local: Network link down on a switch port (Severity: Notice).

What is the attack pattern here?

Someone failed to log in as root, then successfully logged in as admin five seconds later from the same source IP. This pattern (failed then succeeded from same IP) is a classic indicator of credential guessing.

The link-down event on the switch could be coincidence or could indicate the attacker disconnecting a device. In a real investigation you would search for more activity from 203.0.113.50 to confirm.

Before you review the answer below, look at the first syslog line and try to identify all its parts from memory: Priority, Facility, Severity, Source host, Application, and what the message describes.

✔️ I can decode all the fields

Here is the full decode for the first line to confirm your answer:

  • Priority: 34.
  • Facility: 4 (security/authorization).
  • Severity: 2 (Critical).
  • Source host: firewall.corp.local.
  • Application: sshd.
  • Message: Failed SSH password attempt for root from 203.0.113.50.

If your answers match, you can now pick up any syslog line and immediately understand what it is telling you.

ⓧ I need a refresher on the math

Take the number inside the angle brackets (34) and divide by 8.

  • 34 divided by 8 = 4 with a remainder of 2.
  • The whole number (4) is the Facility. Look it up: Facility 4 = security/authorization.
  • The remainder (2) is the Severity. Look it up: Severity 2 = Critical.

The rest of the fields follow the format: Version (1), Timestamp, Hostname (firewall.corp.local), App-name (sshd), ProcID (12345), MsgID (ID47), Structured-Data (- means none), then the Message.

You can now read syslog messages from any network device. In the next step, you will combine evidence from Windows logs, network traffic, and syslog to build a complete incident timeline.

Correlate the Evidence

You have now explored all three log sources a SOC analyst depends on. Windows Event Logs showed you that a door opened. Network traffic showed you where the person went after walking through. Syslog showed the firewall saw the attacker arrive.

Each source alone gave you only a fragment of the story. Correlation across all three is what transforms raw data into a complete incident timeline. This is the core skill that separates a SOC analyst from someone who just reads logs.

In this step, get ready to:
  • Build a chronological incident timeline combining evidence from all three log sources.
  • Extract Indicators of Compromise (IOCs) from the timeline.
  • Document what each log source uniquely contributed to the investigation.
Build an incident timeline

A SOC analyst's most powerful deliverable is a clear, chronological timeline. It tells the story of what happened, when, and how each piece of evidence connects to the next.

  • Create a new text file called incident-timeline.txt in the same folder where you saved your other files (e.g., C:\Users\YourName\Desktop\logs-lab\).
  • Paste the following timeline into the file. Each entry combines evidence from the syslog messages you decoded in the previous step, the Windows Event IDs from your cheat sheet, and the network capture you explored in Wireshark:
INCIDENT TIMELINE
=================

Time        | Source                | Event
------------|----------------------|----------------------------------------------
14:07:15    | Syslog (firewall)    | Failed SSH login for root from 203.0.113.50
14:07:20    | Syslog (firewall)    | Successful SSH login for admin from 203.0.113.50
14:07:20    | Windows Event 4624   | Logon Type 3 (Network) for admin account
14:07:21    | Windows Event 4672   | Special privileges assigned to admin
14:07:25    | Network capture      | HTTP GET request to internal server from compromised host
14:08:02    | Syslog (switch)      | Link down on interface (possible lateral movement)

What does this timeline show?

Read it top to bottom and you see the attack unfold in under one minute. The attacker tried root, failed, then succeeded as admin 5 seconds later. Windows confirmed the logon arrived over the network (Type 3) and that admin privileges were immediately assigned.

Five seconds after gaining access, the network capture shows the compromised host making an HTTP request to an internal server. Finally, a switch port went down. No single log source told this story on its own.

  • Save incident-timeline.txt.
  • Read through your timeline from top to bottom. You should see a clear escalation: failed login, successful login, privilege escalation, data access, infrastructure impact.
Identify the indicators of compromise

Now that you have the timeline, you can extract the specific observables that identify this attacker. In a real SOC, these Indicators of Compromise (IOCs) would be shared with other analysts so they can search their own logs for the same activity.

  • Add the following IOC section below your timeline in incident-timeline.txt:
INDICATORS OF COMPROMISE (IOCs)
===============================

- Attacker IP: 203.0.113.50
- Targeted accounts: root (failed), admin (succeeded)
- Attack type: Credential guessing / brute force
- Time window: 14:07:15 to 14:08:02 (under 1 minute)
- Post-compromise activity: HTTP access to internal server

Why extract IOCs separately?

IOCs are the searchable fingerprints of an attack. In a real SOC, you would now search all three log sources for any OTHER activity from 203.0.113.50 to understand the full scope of the compromise. You would also share these IOCs with your team so they can block the IP at the firewall and hunt for the same indicators across the entire network.

  • Save incident-timeline.txt.
  • Confirm your IOCs section lists 5 specific indicators. Each one is something another analyst could search for in their own logs.
Reflect on what each log source contributed

The final piece of your investigation file documents WHY you needed all three sources. This reflection cements the lesson and becomes a reference for future investigations.

  • Add the following section at the bottom of incident-timeline.txt:
LOG SOURCE CONTRIBUTIONS
========================

- Windows Event Logs: Confirmed the logon happened on the target host, showed privilege escalation (4672)
- Network Traffic (PCAP): Showed what the attacker accessed AFTER logging in, revealed data movement
- Syslog: Showed the failed attempt that preceded success (the firewall saw both), revealed network infrastructure impact

No single source told the full story.

What does each source uniquely tell you?

  • Windows Event Logs are the "host-level truth". They confirm the logon landed and that privilege escalation happened. Without them, you would only know someone connected, not that they got admin rights.
  • Network Traffic is the "wire-level truth". It shows exactly what data moved and where the attacker went after gaining access. Without it, you would know the door opened but not what was taken.
  • Syslog is the "perimeter truth". It shows the failed attempt that preceded the successful one, proving this was credential guessing, not a legitimate admin login. Without it, you might think the admin simply logged in normally.
  • Save incident-timeline.txt.

Before you review the complete file, think about this: could you explain to another person what happened in this incident using only your timeline? What would be the first sentence you would say?

  • Open incident-timeline.txt and read it from top to bottom. You should see three sections: the chronological timeline with 6 entries, the IOCs list with 5 indicators, and the log source contributions with 3 bullet points.

✔️ Awesome, I've got everything!

Your investigation file is complete. You have built the same kind of deliverable a SOC analyst produces during a real incident response.

ⓧ I'd like to double check the full file

Here is the complete incident-timeline.txt file for comparison:

INCIDENT TIMELINE
=================

Time        | Source                | Event
------------|----------------------|----------------------------------------------
14:07:15    | Syslog (firewall)    | Failed SSH login for root from 203.0.113.50
14:07:20    | Syslog (firewall)    | Successful SSH login for admin from 203.0.113.50
14:07:20    | Windows Event 4624   | Logon Type 3 (Network) for admin account
14:07:21    | Windows Event 4672   | Special privileges assigned to admin
14:07:25    | Network capture      | HTTP GET request to internal server from compromised host
14:08:02    | Syslog (switch)      | Link down on interface (possible lateral movement)

INDICATORS OF COMPROMISE (IOCs)
===============================

- Attacker IP: 203.0.113.50
- Targeted accounts: root (failed), admin (succeeded)
- Attack type: Credential guessing / brute force
- Time window: 14:07:15 to 14:08:02 (under 1 minute)
- Post-compromise activity: HTTP access to internal server

LOG SOURCE CONTRIBUTIONS
========================

- Windows Event Logs: Confirmed the logon happened on the target host, showed privilege escalation (4672)
- Network Traffic (PCAP): Showed what the attacker accessed AFTER logging in, revealed data movement
- Syslog: Showed the failed attempt that preceded success (the firewall saw both), revealed network infrastructure impact

No single source told the full story.

Not sure if your timeline is complete?

  • Check that your timeline has exactly 6 entries, each with a timestamp, source, and event description.
  • Confirm the timestamps are in chronological order (earliest first).
  • Verify that all three log sources appear: Syslog, Windows Events, and Network capture.

Help me check my incident timeline for completeness.

You just did what SOC analysts do every day. You took scattered evidence from three different systems and assembled it into a clear story of what happened. Your timeline file is now a professional-grade investigation artifact.

Ready for a real challenge? In the Secret Mission, you will take this investigation one step further and write a formal incident report that a manager could read and act on.

Secret mission

Write a Mini Incident Report

SOC analysts do not just find evidence. They communicate findings clearly to stakeholders who need to make decisions. Can you synthesize your investigation into a structured report that a non-technical manager could act on?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs.

Resources you used:

  • Wireshark 4.6.7 (installed application with Npcap).
  • Downloaded sample file: Http.cap.
  • Project text files: windows-events-cheatsheet.txt, syslog-samples.txt, incident-timeline.txt, incident-report.txt.

Keep everything running

No action needed. Choose this if you want to keep Wireshark installed for future packet analysis and your reference files handy for your next investigation.

  • Wireshark stays installed and ready for live captures whenever you need it.
  • Your cheat sheets and timeline files remain where you saved them for quick reference.

Pause - I'll come back to this later

Close any open applications to free up memory. Your files and installed software remain on disk for when you return.

  • Close Wireshark if it is open.
  • Close your PowerShell Administrator window.
  • Close Event Viewer if it is open.

Delete - I don't want to use this again

Remove all project resources and installed software to start fresh. Follow each step below.

  • Close Wireshark completely before uninstalling.
  • Open Settings on your Windows machine.
  • Select Apps.
  • Find the Wireshark entry and click Uninstall.
  • Find the Npcap entry and click Uninstall. Npcap was installed alongside Wireshark for packet capture.
  • Delete your project files by opening PowerShell and running the command below. Adjust the path if you saved your files to a different folder.
Remove-Item -Recurse -Force "$HOME\Desktop\logs-lab"

Saved files elsewhere?

If you created your text files outside the logs-lab folder, delete them individually wherever you saved them. The files to remove are windows-events-cheatsheet.txt, syslog-samples.txt, incident-timeline.txt, and incident-report.txt.

Nice Work!

Nice Work!

You just investigated a simulated security incident across three different log sources, the same skill every SOC analyst uses on day one of a new job.

You've learned how to:

  • Read Windows Security Event Logs using both Event Viewer and PowerShell, and identify key Event IDs (4624, 4625, 4672) that reveal logon activity on a Windows machine.
  • Open any PCAP file in Wireshark, apply display filters, and follow TCP streams to reconstruct the full network conversations between machines.
  • Decode syslog priority values into facility and severity codes, and correlate evidence across all three log sources to build an incident timeline that tells the full story of an attack.
  • Investigated a simulated security incident end-to-end and wrote a professional mini incident report with an executive summary, IOCs, and actionable recommendations (Secret Mission).

Ready to quiz yourself?