Forwarder
A lightweight agent that collects data from endpoints or other sources and sends it to Splunk for processing.
CompletedSIEM & Log AnalysisHands-On Splunk Training
Splunk: The Basics
TryHackMe — Splunk: The Basics
A practical introduction to Splunk architecture, log ingestion, JSON field extraction, and Search Processing Language through the investigation of VPN activity.
- Role
- SOC Analyst Trainee
- Environment
- TryHackMe Splunk Simulation
- Scenario
- Splunk: The Basics
- Status
- Completed
- SIEM
- Splunk Enterprise
01Scenario Overview
This room introduced Splunk Enterprise as a Security Information and Event Management platform used to collect, search, analyze, and visualize machine data. Organizations can centralize events from endpoints, applications, identity systems, network devices, firewalls, and business services to support monitoring and investigation.
The practical exercise used VPN logs to move from raw data ingestion to focused analysis. I uploaded a newline-delimited JSON file, stored it in a dedicated index, verified that each line became a separate event, and queried the resulting fields with SPL.
02Core Splunk Architecture
Indexer
Processes incoming data, transforms it into searchable events, and stores it in indexes.
Search Head
Provides the interface where analysts run SPL searches, investigate events, build reports, and create dashboards.
Data source → Forwarder → Indexer → Search Head → Analyst insight
03Core Event Metadata
index
The logical data store that contains related events and defines the primary search scope.
source
The file, stream, or input from which an event originated.
sourcetype
Describes the data format and helps Splunk determine how events should be parsed.
host
The endpoint, server, or device associated with the event.
04VPN Log Ingestion
I used Splunk’s Add Data → Upload workflow to import the supplied VPN_logs file. Because the file contained newline-delimited JSON, keeping the detected JSON source type ensured that every line was handled as an individual event.
Select Source
Choose Upload and select the local VPN_logs file.
Select Source Type
Keep the JSON source type detected by Splunk and confirm the event preview.
Input Settings
Create or select the VPN_Logs index and review the associated host value.
Review
Check the source, source type, host, and destination index before submission.
Complete
Finish the upload, open Search & Reporting, and set the time picker to All time.
Validate
Run a base search and compare the returned count with the imported dataset.
05SPL Investigation Queries
SPL (Search Processing Language) uses a base search followed by pipe-delimited commands that progressively filter, transform, and summarize results. When JSON fields were not automatically visible, | spath extracted them from the event data.
Validate the import
index=VPN_Logs
| stats countConfirm the total number of events stored in the new index.
Find a user
index=VPN_Logs
| spath
| search UserName="Maleena"
| stats countCount VPN events associated with the specified username.
Correlate an IP address
index=VPN_Logs
| spath
| search Source_ip="107.14.182.38"
| stats values(UserName) as UserName countIdentify the username associated with a source IP and count matching events.
Exclude a country
index=VPN_Logs
| spath
| search Source_Country!="France"
| stats countCount events from every country except France.
Count activity from an IP
index=VPN_Logs
| spath
| search Source_ip="107.3.206.58"
| stats countMeasure the number of VPN events associated with one source IP.
The exact challenge answer values are intentionally not reproduced here. The queries document the repeatable method used to obtain and validate each result in the lab.
06Skills Demonstrated
Data onboarding
- Uploaded newline-delimited JSON
- Selected the correct source type
- Created a dedicated index
SPL fundamentals
- Scoped searches by index
- Filtered structured fields
- Used pipe-delimited commands
Field extraction
- Parsed JSON with spath
- Validated usernames and IP fields
- Handled exact field names
Event analysis
- Counted matching events
- Correlated users with IPs
- Excluded geographic values
07Key Lessons Learned
Parsing determines search quality
Correct source-type selection and event boundaries are essential; poorly parsed data produces unreliable fields and counts.
Time range matters
Setting the time picker to All time prevents valid imported events from being hidden by the default search window.
Validate before investigating
A simple event count confirms that the dataset is present before more specific filters are applied.
Field names are exact
Queries must use the dataset’s precise field names and capitalization, such as UserName, Source_ip, and Source_Country.
Pipes create readable analysis
Breaking a search into extraction, filtering, and statistics stages makes the investigation easier to understand and verify.
SIEM data needs context
User, IP, country, host, and time information become more useful when they are correlated rather than reviewed in isolation.
08Training Context
This case study documents hands-on learning completed in the TryHackMe Splunk: The Basics room. The work was performed in a controlled training environment and is not presented as production SOC employment.
The write-up focuses on concepts, configuration decisions, investigation methodology, and reusable SPL. Protected flags, credentials, and challenge answer values are intentionally excluded.