Understand How a SOC Works by Setting Up a Basic Monitoring Environment

Welcome!

You are a Junior SOC Analyst at CyberSecure Solutions. Your organization wants to monitor its systems for suspicious activity.

Your task is to set up a basic monitoring environment, collect system logs, identify suspicious events, and investigate them as a SOC analyst would.

Topic : SOC Fundamentals

1) Introduction to Security Operations Center (SOC) 

2) Roles and responsibilities of a SOC analyst

3) Security monitoring fundamentals

Open your browser and search for “(https://wazuh.com)” on your preferred search engine.

Click the first result, which should direct you to the official Wazuh website

Navigate to the Documentation section from the homepage.

Now scroll down then you will find the documentation menu click on the “documentation” ,then  locate and select Installation Alternatives.

Then in the “installation alternatives” select Virtual machin(VM).

Choose the Wazuh Virtual Machine (OVA) option. By default, the documentation may display the latest version (e.g., 4.8). Use the version dropdown in the top-right corner to select Wazuh 4.14.7 

In the Packages List table, find the OVA file link for Wazuh 4.7 and click to download it. The file size is approximately 3-4GB, depending on the version. 

Launch VMware Workstation 17 Pro on your system.

Click File > New Virtual Machine to start the VM creation wizard.

Select I will install the operating system later and click Next. Choose Linux as the guest operating system. Click Browse and locate the downloaded Wazuh 4.14.7 OVA file.

Click Import to begin importing the OVA file into VMware. This process may take a few minutes, depending on your system’s performance.a

Select the Wazuh VM in VMware and click Power on this virtual machine. 

Once the VM boots, you’ll be prompted with a login screen. Use the default credentials:

Username: wazuh-user

Password: wazuh

After logging in, the Wazuh system should be fully operational.

Access the Wazuh Web Interface

Check the IP address assigned to the Wazuh VM:

In the VM’s terminal, run the command ip addr or ifconfig to identify the IP address (e.g., 192.168.172.128). Note the IP address for the next step. On your host machine, open a web browser and navigate to https://<VM-IP-ADDRESS> (e.g., https://192.168.172.128).

Then will get this interface.

Identify the main components of a basic SOC

Steps

1. Open the monitoring/SIEM platform.

2. Identify the following components:

   • Endpoint

   • Log Source

   • SIEM

   • Alert

   • SOC Analyst

3. Understand how logs move through the environment.

Collect system logs for monitoring.

Steps

1. Start the Windows/Linux test machine.

2. Install the monitoring agent according to the instructor's instructions.

3.Register the endpoint with the SIEM.

4.Confirm that the endpoint appears as Active/Connected.

5.Verify that logs are being received.

Expected Output

The test endpoint is visible in the monitoring dashboard and is sending logs.

Generate controlled events and observe how they appear in the SOC.

Steps

Perform safe activities on the test machine, such as:

• Log in and log out.

• Use an incorrect login password several times.

• Create and delete a test file.

• Start or stop a test service.

• Make a permitted configuration change.

• Open the SIEM dashboard.

• Search for the generated events.

• Record:

  • Date/time

  • Event type

  • Source system

  • Username

  • Result

Expected Output

Students identify their generated events in the monitoring platform.

Learn how a SOC analyst investigates an alert.

Steps

• Open the alerts/security events section.

• Select a suspicious event.

• Examine:

  • Source IP

  • Username

  • Timestamp

  • Event type

  • Number of attempts

  • Target system

• Determine whether the event is:

  • Normal activity

  • Suspicious activity

  • Potential incident

• Record your conclusion.

Expected Output

Students produce a basic alert investigation.

Understand how SOC analysts respond to detected threats.

Steps

• Select a controlled suspicious event.

• Identify the appropriate defensive action.

• Apply the action in the lab environment, such as:

  • Disable a test account.

  • Block a test IP address.

  • Change a compromised test password.

  • Remove unnecessary access.

• Verify that the action was successful.

• Check the monitoring dashboard for new events.

Expected Output

Students demonstrate a basic detection-to-response workflow.

Create a basic SOC incident record.

Record:

Example Finding

• Incident:

Multiple Failed Login Attempts

• Observation:

Multiple unsuccessful login attempts were detected

for a test account.

• Investigation:

The events were reviewed for timestamp, username,

source and frequency.

• Action:

The test account was temporarily disabled.

• Status:

Resolved.

Expected Outcome

Example doc.for soc lab1

Open your web browser (Chrome, Edge, Firefox, etc.).

Visit the Splunk Enterprise download page.

Now signup by entering the following credential

• Enter your email address.

• Create a password if required.

• Fill in basic details such as:

  • First Name

  • Last Name

  • Submit the form.

After that you will be redirected to the download page. now click on the windows "download now".

After that it will redirect you to another page.

After that click on "Try this url" to start the download process.

Then accept the license agreement and then click on install.

Then click on next.

Then set up the username and password for the splunk enterprise.  

Then wait for download to get finished and then click on launch button

Then wait for download to get finished and then click on launch button.

If the browser does not open automatically:

Use the following url to open thes splunk http://localhost:8000

If the browser does not open automatically:

Use the following url to open thes splunk http://localhost:8000

Then enter the username and password you use to setup.

Now verify the installed splunk is working or not

The document asks students to identify:

• Endpoint
• Log Source
• SIEM
• Alert
• SOC Analyst and understand how logs move through the environment.

Endpoint

Kali Linux

Log Sources

Workflow

Kali Linux

     ↓

System Logs

     ↓

Splunk Universal Forwarder

     ↓

TCP 9997

     ↓

Splunk Enterprise

     ↓

Search

     ↓

Alert

     ↓

Investigation

     ↓

Response

Kali Linux

     ↓

System Logs

     ↓

Splunk Universal Forwarder

     ↓

TCP 9997

     ↓

Splunk Enterprise

     ↓

Search

     ↓

Alert

     ↓

Investigation

     ↓

Response

Create Splunk Index

The original task requires the endpoint to be registered, shown as active/connected, and sending logs. SOC

In Splunk, this is done using a Universal Forwarder.

In Splunk Web:

Settings

   ↓

Indexes

   ↓

New Index

In Splunk Web:

Settings

   ↓

Indexes

   ↓

New Index

• Create: soc_lab

• Use: Index Name: soc_lab

• Click: Save
• Splunk supports creating custom event indexes through Settings → Indexes → New. 

Configure Receiving Port

In Splunk Web:

Settings

   ↓

Forwarding and receiving

   ↓

Configure receiving

In Splunk Web:

Settings

   ↓

Forwarding and receiving

   ↓

Configure receiving

• Choose: New Receiving Port
• Enter: 9997
• Save.
• Splunk documentation identifies 9997 as the conventional receiver port for forwarders

Verify 9997

On the Splunk server:

You should see something listening on:9997

Install Universal Forwarder on Kali

Download the Linux Universal Forwarder package from Splunk.

For a .tgz package:

The standard Linux installation directory is:

/opt/splunkforwarder

``` :chatgpt-content-reference{index="18"}

Start Universal Forwarder

Create the local UF administrator credentials when prompted.

Connect UF to Splunk

On Kali:

Enter the UF credentials when requested.

Splunk documents this exact add forward-server <host>:9997 workflow. 

Verify Forwarder Connection

Run:

You want to see your Splunk server as an active forward.

Splunk specifically recommends list forward-server to verify the forwarding configuration

Configure Log Collection

Create:

Put:

[monitor:///var/log/auth.log]

disabled = false

index = soc_lab

sourcetype = linux_secure

[monitor:///var/log/syslog]

disabled = false

index = soc_lab

sourcetype = linux_messages_syslog

[monitor:///var/log/audit/audit.log]

disabled = false

index = soc_lab

sourcetype = linux_audit

These are useful Splunk source types for Linux authentication, syslog and audit data; Splunk includes pretrained source types such as linux_secure, linux_messages_syslog, and linux_audit.

Put:

[monitor:///var/log/auth.log]

disabled = false

index = soc_lab

sourcetype = linux_secure

[monitor:///var/log/syslog]

disabled = false

index = soc_lab

sourcetype = linux_messages_syslog

[monitor:///var/log/audit/audit.log]

disabled = false

index = soc_lab

sourcetype = linux_audit

These are useful Splunk source types for Linux authentication, syslog and audit data; Splunk includes pretrained source types such as linux_secure, linux_messages_syslog, and linux_audit.

Restart UF

Then:

You should see:

• /var/log/auth.log
• /var/log/syslog
• /var/log/audit/audit.log

Generate a Simple Test Event

• On Kali: logger "Splunk SOC lab connectivity test"
• Now go to Splunk: Search & Reporting
• Run: index=soc_lab "Splunk SOC lab connectivity test"
• If the event appears:Kali → UF → Splunk is working.

• On Kali: logger "Splunk SOC lab connectivity test"
• Now go to Splunk: Search & Reporting
• Run: index=soc_lab "Splunk SOC lab connectivity test"
• If the event appears: Kali → UF → Splunk is working.

This is your most important checkpoint.

The original document asks you to generate controlled events such as login/logout, failed passwords, file creation/deletion, service activity and permitted configuration changes. SOC SOC

We'll reproduce all of them.

Login/Logout

Make sure SSH is running:

Create a test account:

Give it a lab password.

Then:

Enter the correct password.

Then:

Search: index=soc_lab sourcetype=linux_secure ("Accepted password" OR "session opened" OR "session closed")

Failed Login Attempts

Now intentionally enter the wrong password several times:

• Enter an incorrect password about 5 times.
• You should see: Permission denied
• Search Splunk: index=soc_lab sourcetype=linux_secure "Failed password"
• This should show your failed login events.

Create/Delete Test File

Install auditd if required:

Start it:

Create a dedicated lab directory:

Add an audit rule:

The Linux audit system supports filesystem rules using a directory/path, permissions and a key for later investigation.

Now:​

Write to it:

Then:

Search:

index=soc_lab sourcetype=linux_audit "siem_lab_file"

You should find the file activity.

Start/Stop Test Service

Use the cron service if available:

Then search: index=soc_lab sourcetype=linux_messages_syslog ("Starting" OR "Started" OR "Stopping" OR "Stopped")

You should see service-related events.

Permitted Configuration Change

Create a temporary test configuration file:

Modify it:

Search:

index=soc_lab sourcetype=linux_audit "siem_lab_file"

Because /opt/soclab is being audited, the change should appear.

Search All Generated Events

• Now use one combined search:

index=soc_lab earliest=-30m

| eval event_type=case(

    match(_raw,"Failed password"),"Failed Login",

    match(_raw,"Accepted password"),"Successful Login",

    match(_raw,"session opened"),"Session Opened",

    match(_raw,"session closed"),"Session Closed",

    match(_raw,"siem_test.txt"),"File Activity",

    match(_raw,"Starting|Started|Stopping|Stopped"),"Service Activity",

    true(),"Other"

)

| table _time host source sourcetype event_type _raw

| sort - _time

• This gives you the same information the document asks students to record:

Date/Time

Event Type

Source System

Username

Result

• Now use one combined search:

index=soc_lab earliest=-30m

| eval event_type=case(

    match(_raw,"Failed password"),"Failed Login",

    match(_raw,"Accepted password"),"Successful Login",

    match(_raw,"session opened"),"Session Opened",

    match(_raw,"session closed"),"Session Closed",

    match(_raw,"siem_test.txt"),"File Activity",

    match(_raw,"Starting|Started|Stopping|Stopped"),"Service Activity",

    true(),"Other"

)

| table _time host source sourcetype event_type _raw

| sort - _time

This gives you the same information the document asks students to record:

• Date/Time
• Event Type
• Source System
• Username
• Result

This is where Splunk becomes really useful.

The document asks you to examine:

• Source IP
• Username
• Timestamp
• Event Type
• Number of Attempts
• Target System

and decide whether the activity is:

• Normal
• Suspicious
• Potential Incident
• SOC

Search Failed Logins

Run:

Extract Username and Source IP

Run:

rex can extract fields from raw events using named regular-expression groups. ​

Count Failed Attempts

This is the important investigation search:

You'll get something similar to:

This is exactly what we need for the investigation.

Splunk's stats command is designed to aggregate events and group results by fields such as host/source.

Correlate Failed + Successful Login

Now run:

This lets you determine:

• Who?
• What?
• When?
• From where?
• How many attempts?
• Was there a successful login?

Make the SOC Decision

For this lab:

Multiple failed login attempts

        ↓

Same username

        ↓

Same source

        ↓

Repeated within short time

        ↓

Suspicious Activity

        ↓

Potential Security Incident

Because these are intentionally generated lab events, your report should state that the activity was controlled test activity, while demonstrating how a SOC analyst would classify the pattern.

For this lab:

Multiple failed login attempts

        ↓

Same username

        ↓

Same source

        ↓

Repeated within short time

        ↓

Suspicious Activity

        ↓

Potential Security Incident

Because these are intentionally generated lab events, your report should state that the activity was controlled test activity, while demonstrating how a SOC analyst would classify the pattern.

Create the Splunk Alert

Now we convert the investigation into an actual SOC alert.

Use:

Click:

Save As

   ↓

Alert

Configure:

Title:

SOC - Multiple Failed Logins

Click:

Save As

   ↓

Alert

Configure Title: SOC - Multiple Failed Logins

• Alert type: Choose: Scheduled
• Time range: Last 5 minutes
• Schedule: Every 1 minute
• Trigger condition: Number of Resultsis greater than 0
• Severity: Medium
• Action: For this lab: Add to Triggered Alerts

The document gives four possible actions:

• Disable a test account
• Block a test IP
• Change compromised test password
• Remove unnecessary access

Disable the test account

First check its status:

Test the Defensive Action

Try logging in using the correct password:

Then disable it:

Check again:

You should see the account in a locked state.

Verify in Splunk

Search:

index=soc_lab sourcetype=linux_secure ("soclab" OR "locked" OR "authentication failure")

| table _time host source sourcetype _raw

| sort - _time

The account should no longer allow the login.

You now have:

Detection

   ↓

Investigation

   ↓

Decision

   ↓

Account Disabled

   ↓

Verification

You now have:

Detection

   ↓

Investigation

   ↓

Decision

   ↓

Account Disabled

   ↓

Verification

The document specifically asks for an incident record containing:

• Incident ID
• Date/Time
• Alert
• Source
• Severity
• Status
• Action Taken
• Analyst

Incident Report

Observation

Multiple unsuccessful login attempts were detected against the controlled test account.

Investigation

The Splunk security events were reviewed to determine the timestamp, username, source IP address, target host and frequency of the failed authentication attempts.

Finding

The repeated failed authentication attempts were classified as suspicious activity in the controlled lab environment.

Response

The test account was temporarily disabled as a defensive measure.

Verification

A subsequent authentication attempt was unsuccessful, confirming that the defensive action was effective.

Status

Resolved

This follows the same incident structure and example finding used in the original document. SOC

The original document expects these deliverables: SOC

SOC Environment Diagram

Use:

Kali Endpoint

     ↓

System Logs

     ↓

Universal Forwarder

     ↓

TCP 9997

     ↓

Splunk Enterprise

     ↓

Search

     ↓

Alert

     ↓

Investigation

     ↓

Response

     ↓

Incident Report

Use:

Kali Endpoint

     ↓

System Logs

     ↓

Universal Forwarder

     ↓

TCP 9997

     ↓

Splunk Enterprise

     ↓

Search

     ↓

Alert

     ↓

Investigation

     ↓

Response

     ↓

Incident Report

Connected Endpoint Screenshot

Capture:

• Kali terminal

• splunk list forward-server

• active forward

Sample Security Events

Capture Splunk Search results showing:

• successful login

• failed login

• file activity

• service activity

• configuration activity

Alert Investigation

Capture:

• failed-login search

• source IP

• username

• timestamp

• attempt count

• target host

Defensive Action

Capture:

sudo passwd -S soclab

before/after the account is locked.

Also capture the failed login after the account is disabled.

Incident Report

Submit the SOC-001 report with your actual timestamp and student name.

Student Deliverables

Students should submit:

• SOC Environment Diagram

• Screenshot of Connected Endpoint

• Sample Security Events

• Alert Investigation

• Defensive Action

• Incident Report

Great job!
You have successfully completed your SOC Monitoring Environment lab.

In this lab, you have: Understood the SOC workflow, Set up a Splunk-based monitoring environment, Connected Kali Linux logs using Universal Forwarder, Generated and monitored security events, Investigated security alerts, Applied basic defensive actions and documented incidents.

You are now ready to move to the next stage of SOC monitoring and incident response.

Great job!
You have successfully completed your SOC Monitoring Environment lab.

In this lab, you have: Understood the SOC workflow, Set up a Splunk-based monitoring environment, Connected Kali Linux logs using Universal Forwarder, Generated and monitored security events, Investigated security alerts, Applied basic defensive actions and documented incidents.

You are now ready to move to the next stage of SOC monitoring and incident response.

Topic : SOC Fundamentals

1) Introduction to Security Operations Center (SOC) 

2) Roles and responsibilities of a SOC analyst

3) Security monitoring fundamentals