Study guide
2.1 Analyst VM, Splunk, and Dynamic Alerts
TryHackMe Security Analyst Level 1 SAL1
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy
2 SOC Simulator Exam Skills
2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes
3 Network Essentials
3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission
4 Operating System Basics
4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity
5 Cryptography, Cloud, Web and Scripting Basics
5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs
6 Cybersecurity Fundamentals and MITRE ATT&CK
6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques
7 Kill Chain, NIST CSF, and Attack Indicators
7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain
8 Social Engineering and Network Attacks
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns
9 Web Exploitation and Endpoint Attacks
9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd
10 Command and Control, Malware, and LOLBAS
10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS
11 EDR, Firewalls, and WAF
11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation
12 SIEM and SOAR
12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration
13 Threat Intelligence and Vulnerability Scanning
13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning
14 SOC Team, Activities, and Alert Triage
14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts
15 SOC Metrics, Escalation, and Communication
15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication
2.1 Analyst VM, Splunk, and Dynamic Alerts
Key Takeaways Explain This Topic AI
TryHackMe's format article (23 February 2025) sets two SOC Simulator scenarios at 2 hours each with a variable number of alerts; scoring (29 March 2025) gives each scenario 400 of the exam's 1,000 marks.
The SOC Simulator advice article (11 March 2025) describes two real-world incidents investigated in real time on the Analyst VM with Splunk, and states that alerts trigger dynamically.
Spend the first 10 minutes on documentation, a full queue snapshot, timestamps, and affected assets before deep hunting a single ticket.
Craft bounded Splunk searches (time, host/user, documented index) and pivot on observed IoCs; do not treat the simulator as a CTF flag hunt.
Re-check the queue after every classification cycle because later dynamic alerts often complete the attack chain.
Last updated: September 2026
The TryHackMe Security Analyst Level 1 (SAL1) exam puts most of its weight on hands-on work. TryHackMe's scoring article (29 March 2025) assigns 200 marks to the multiple-choice section and 400 marks to each of two SOC Simulator (SOC Sim) scenarios— 800 of 1,000 marks . TryHackMe's format article (23 February 2025) describes two practical simulation scenarios , a 2-hour limit per scenario , and a variable number of alerts . The SOC Simulator exam-advice article (11 March 2025) adds that you investigate two real-world security incidents in real time using the Analyst VM and Splunk , and that alerts trigger dynamically . This independent study material covers those published simulator mechanics so you can run a Security Operations Center (SOC) workflow under the clock.
What you are walking into
A SOC Sim scenario is a live shift, not a zip file of pre-staged flags. At start you receive company context and an alert queue that may still be short. As the simulated attackers continue, new detections appear. Variable counts mean one scenario can be a tight phishing-and-beacon chain while another sprinkles noisy false positives around a quieter true-positive core. You cannot memorize "there will be N tickets." You can memorize a loop that still works when the ninth alert lands at minute 71.
Dynamic alerts create a sequencing problem. If you treat the first item as the entire exam, you will still be decorating a case note when a later Command and Control (C2) detection arrives. If you bounce randomly between tickets looking for a dramatic screenshot, you will mis-order the story and miss correlations. The published advice is to treat the scenario as a real SOC: identify threats, escalate when necessary, and report findings clearly.
The Analyst VM is a desk, not a playground
The Analyst VM is the investigation workstation for the scenario. Use it the way an analyst uses a jump box on day one at a new company:
Open company documentation before deep hunting.
Launch Splunk —the Security Information and Event Management ( SIEM ) surface named in the advice article—and confirm you can search.
Keep the case-report or notes UI visible so times and hostnames are copied, not recalled from memory.
Use the tools and log sources the documentation says this company actually has.
The VM may include a browser, a text editor, and utilities. That does not invite you to exploit the VM, dump every file under /opt , or run password crackers "in case." Those are capture-the-flag ( CTF ) reflexes. Classification, escalation, and case reports score investigation of the fictional company's incident, not cleverness against lab plumbing.
Splunk: narrow first, then pivot on evidence
TryHackMe's SOC Simulator advice tells you to craft precise Splunk queries that filter noise and focus on key logs . Precision is a sequence, not one lucky search:
Time-box using the alert timestamp. A phishing click at 13:04 UTC does not require a 30-day search. Start with a window such as 30 minutes before through two hours after, then expand only if evidence points outside that window.
Asset-box using the host, user, mailbox, or IP named in the alert.
Source-box using documented indexes and sourcetypes (email gateway, proxy, Windows Security, Sysmon, DNS, firewall).
Read the raw event. Extracted fields drop parent processes, full command lines, and mail headers.
Pivot on indicators of compromise (IoCs) you actually observed: URL, hash, IP, sender domain, mailbox, or parent process.
A methodical first query looks like a filter, not a wish. After you confirm a URL or destination IP, a second query may go wide across indexes for that string. Wide-first searches ( index=* error OR malware OR hack ) burn the two-hour budget and train you to invent a story from noise.
Query hygiene under exam pressure
Copy hostnames from the alert. Do not type WS-FIN-41 when the ticket says WS-FIN-14 .
Keep UTC versus local time straight. Case reports that mismatch Splunk _time look fabricated.
Paste useful search one-liners into your notes so you can re-run them when a new dynamic alert names the same user.
- If documentation lists an asset-owner lookup, use it before escalating an "unknown workstation."
- Documentation first — it changes verdicts
The same advice article calls documentation critical : understand log sources, attack patterns, and response steps. Read it as operational truth for this company, not as flavor text.
Question the docs answer Why the answer changes your work
Which indexes and sourcetypes exist? You stop searching data this company never collected.
What are production, lab, and scanner subnets? A port sweep from the vulnerability-scan VLAN may be expected; the same sweep from a finance laptop is not.
Which mail domain and gateway are official? You can tell a lookalike sender from an internal forward.
Which hosts are crown jewels? A beacon from the CFO workstation is not the same as a beacon from a kiosk, even if the malware family matches.
What is the approved scan window and scanner name? Scheduled scanner traffic is often a benign true positive , not an incident worth paging anyone.
If you skip the docs, you will escalate the approved scanner and miss the workstation that actually pulled a payload.
This is not a CTF flag hunt
CTF habits that waste SAL1 simulator time:
Searching for strings such as flag{ or hunting hidden trophy files.
Attacking the Analyst VM instead of investigating the fictional company.
Assuming one magic event "wins" the scenario.
Ignoring later dynamic alerts because you already "found the attacker."
Writing a dramatic narrative with no timestamps, hosts, or IoCs.
SOC habits that map to how the scenario is scored:
Check alert timestamps and affected assets , then related logs (the published step-by-step approach).
Look for repeat offenders and correlations across alerts.
Escalate when there are clear IoCs ; do not escalate every noisy ticket.
Keep moving. If you are unsure, document what you have and continue—the advice article's time-management rule.
Worked mini-scenario: the first 10 minutes at Northwind Logistics
Imagine the scenario title is "Northwind Logistics — suspicious mail and endpoint activity." The scenario clock shows 02:00:00 remaining. Do the following, in order. The company names and alerts below are a teaching example, not a leaked exam script.
Minutes 0–2: orientation, not the reddest button. Open documentation. Write down four facts: corporate domain northwind-log.example ; Splunk indexes email , proxy , windows , firewall , dns ; finance VLAN 10.20.40.0/24 ; approved vulnerability scanner SCAN-01 at 10.20.9.15 ; mail gateway mx1.northwind-log.example ; crown jewels FILE-FIN-01 and the CFO mailbox. You have not classified anything yet, and that is correct.
Minutes 2–4: queue snapshot. Three alerts are visible (more may appear later because alerts are dynamic):
13:02:11 UTC — Email gateway — "Newly observed sender domain to CFO" — asset: mailbox cfo@northwind-log.example
- 13:04:44 UTC — Proxy — "Suspicious script download" — asset: WS-FIN-14 ( 10.20.40.88 ), user j.patel
- 13:01:02 UTC — Firewall — "Outbound to newly registered domain" — asset: SCAN-01
Do not start with alert 3 just because firewalls feel "network-y." Check timestamps and assets against the docs. Alert 3's source is the approved scanner. Park it as likely authorized scanning until a 60-second Splunk check confirms the destination matches a documented scan target, not a C2 domain reused by the finance laptop.
Minutes 4–7: bind time and assets for the plausible chain. Alerts 1 and 2 are two minutes apart, same business unit, a human mailbox plus a workstation. In Splunk, bound _time to 12:50–13:20 UTC. Search index=email for the CFO message and sender domain. Confirm a lookalike domain, a mismatched Reply-To, and a link. Search index=proxy for host=WS-FIN-14 and that URL. Confirm a GET for invoice.js from the workstation, not from SCAN-01 .
Minutes 7–10: provisional verdicts and a written hook. Alert 1 is a true positive for phishing delivery, with IoCs (sender domain, URL, message ID). Alert 2 is a true positive for payload retrieve, tied to WS-FIN-14 / j.patel . Alert 3 is likely a benign true positive for scanner traffic; close or hold it with one line citing SCAN-01 in the asset list. Write those three lines into the case notes now , including UTC times. Then re-open the queue—dynamic alerts for process creation or C2 may already be landing. Ten minutes are gone and you already have a chain, not a single lonely ticket.
- Minute Action Artefact you should have
- 0–2 Read company documentation Domain, indexes, scanner identity, crown jewels
- 2–4 Snapshot every visible alert Time, detection name, asset, user
- 4–7 Bounded Splunk on the plausible chain Confirm or refute mail → click → download
- 7–10 Provisional labels + IoCs in notes TP / FP / benign labels you can reopen
- 10+ Re-check the queue New dynamic alerts that continue the chain
That opening is the whole environment skill: documentation, queue, time, assets, precise Splunk, notes, then continue. The remaining 110 minutes are the same loop with more evidence.
A practical 120-minute budget
TryHackMe does not publish a per-alert scoring sheet beyond the classification / escalation / case-report split taught in the next section. A usable clock discipline is still required because the format article gives you a hard 2 hours per scenario and the technical-issues article (taught next) warns that running out of time marks the section 0.
0–10 min: docs, queue map, first chain.
10–90 min: investigate, classify, escalate true positives, watch for new alerts.
90–110 min: second pass on anything still unknown; hunt confirmed IoCs across indexes.
110–120 min: freeze new hunting; finish case-report structure.
If a single alert is still confusing at minute 40, write what you know, mark the gap, and move. The advice article is blunt: the exam is time-sensitive, so do not get stuck on one alert.