2.1 Analyst VM, Splunk, and Dynamic Alerts

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:

1. 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.
2. Asset-box using the host, user, mailbox, or IP named in the alert.
3. Source-box using documented indexes and sourcetypes (email gateway, proxy, Windows Security, Sysmon, DNS, firewall).
4. Read the raw event. Extracted fields drop parent processes, full command lines, and mail headers.
5. 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.

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):

1. 13:02:11 UTC — Email gateway — "Newly observed sender domain to CFO" — asset: mailbox cfo@northwind-log.example
2. 13:04:44 UTC — Proxy — "Suspicious script download" — asset: WS-FIN-14 (10.20.40.88), user j.patel
3. 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.

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.