Study guide
14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting
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
14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting
Key Takeaways Explain This Topic AI
Reactive work starts from an event or a firing detector (queue, IR, emergency containment); proactive work reduces future incidents or future noise (hunting, tabletops, scanning, detection engineering, FP remediation).
False-positive remediation exists to stop the same junk from training analysts to click Close; the durable output is a detection-engineering ticket, not only a closed alert.
Detection engineering turns TTPs and past incidents into maintainable rules; vulnerability scanning is a proactive control taught in depth in chapter 13 that also explains some benign SOC alerts.
Tabletop exercises rehearse decisions without live malware; DFIR answers what happened and how to contain it; threat hunting searches with a hypothesis before an alert exists.
Alert-queue work is reactive; a purple-team tabletop is proactive even though it talks about attacks.
Last updated: September 2026
Proactive versus reactive is a trigger, not a personality
TryHackMe's SAL1 training content (24 March 2025) asks you to classify security activities as proactive or reactive , then to explain false-positive (FP) remediation , detection engineering , vulnerability scanning , tabletop exercises , digital forensics and incident response (DFIR) , and threat hunting . This independent section covers that map. The trap is treating "proactive" as a moral upgrade and "reactive" as failure. A SOC that never reacts is asleep. A SOC that only reacts repeats the same 40 junk alerts every Monday.
Reactive work starts because something already happened or a detector already fired. The alert queue, live incident response (IR) , emergency isolation, and forensics on a host you already believe is compromised are reactive. The trigger is an event, a ticket, or a user report.
Proactive work tries to reduce future incidents, future dwell time, or future noise before the next page. Threat hunting without a ticket, tabletop practice, scheduled vulnerability scanning, writing new detections, and fixing noisy rules are proactive. The trigger is a hypothesis, a calendar, or a backlog of quality work—not a red badge in the SIEM.
The same human can do both in one week. The classification is about why you started , not about whether the work uses Splunk.
- Activity Default bucket Trigger Success looks like
- Alert-queue triage Reactive A firing alert or inbound ticket Correct verdict and next action
- Emergency containment / IR Reactive Declared or suspected incident Attacker stopped; evidence preserved
- DFIR casework Mostly reactive A case that needs reconstruction Timeline, scope, and durable lessons
FP remediation Proactive (fed by reactive pain) Repeated junk or a proven misfire Rule tuned; queue quieter next week
- Detection engineering Proactive Coverage gap or new TTP Maintainable rule, not a one-off search
- Vulnerability scanning Proactive Schedule or change window Weaknesses found before attackers
- Tabletop exercise Proactive Planned scenario Decisions rehearsed; gaps written down
Threat hunting Proactive Hypothesis ("if they used X, we would see Y") Confirm or refute; new detection or a documented miss
False-positive remediation: stop teaching the queue to lie
An FP is a detection that fired on something that is not the bad thing the rule claims (section 14.4). FP remediation is the follow-through: you do not only close today's alert; you change the system so the same misfire is less likely tomorrow.
Purpose:
Protect analyst attention. If L1 spends a shift proving the same helpdesk script is not malware, nobody is watching the rare C2.
Protect trust. A queue that is 90 percent junk trains people to click Close. That is how true positives die.
Give detection engineering evidence: sample events, the legitimate business process, the host or user that should be excluded with expiry , and the risk if you exclude too broadly.
L1's job in FP remediation is a quality ticket , not a silent allow-list in production. "Ignore all PowerShell" is not remediation; it is a false-negative factory. "Exclude signed Deploy-Helpdesk.ps1 from \\tools.cedar-bank.example\it when parent is msiexec.exe , review in 90 days" is remediation.
Detection engineering: turn pain into rules you can live with
Detection engineering designs, tests, and maintains the logic that creates alerts: SIEM correlation searches, EDR behavioral rules, email-gateway policies. Purpose is coverage of real attacker behavior with a false-positive rate a shift can survive.
Inputs: MITRE ATT&CK techniques, past incidents, threat-intel reports, L1 FP tickets, and purple-team results. Outputs: versioned rules, documentation (what it detects, what it does not), and a plan for telemetry if the rule cannot see the data.
L1 is not the detection engineer. L1 is the customer of detections and the first reporter when they rot. If you never file the FP, engineering never sees the rot.
Vulnerability scanning: proactive finding of weaknesses (pointer)
Vulnerability scanning is a scheduled or on-demand search for known weaknesses: missing patches, exposed services, weak web paths. SAL1 training content treats external versus internal and web versus network scanning in depth in chapter 13. In this chapter, remember two SOC-facing facts:
Scanning is proactive . You would rather a scanner find SMB signing off than a ransomware crew.
Scanning creates telemetry that can look like attacks: port sweeps, web probing, sudden connections to newly registered domains in a scan scope. Those alerts are often benign true positives when the source is the approved scanner in the approved window—not proof that scanning "does not belong in a SOC."
Do not re-learn scan types here. Do learn to classify the activity : the scan program is proactive; a 03:00 SOC alert caused by the scanner is still a reactive ticket you must dispose correctly.
Tabletop exercises: practice decisions without detonating malware
A tabletop exercise is a discussion-based rehearsal. A facilitator injects a scenario ("ransomware note on a file server," "CFO wire-fraud email"). Participants say what they would do, whom they would call, and which evidence they would collect. Nobody needs to drop a payload on production.
Purpose: find broken phone trees, missing workbooks, unclear authority to isolate a branch workstation, and assumptions like "IR is always in the building." Tabletops are proactive . They become purple-flavored when red-team operators and detection engineers sit in the same room and the injects match techniques red actually uses in tests.
A tabletop is not DFIR. No disk image is taken. Success is a written after-action: decisions, owners, and gaps—not a malware sandbox report.
DFIR: reconstruct and respond when a case exists
Digital forensics answers what happened, on which systems, with evidence that could survive scrutiny: timelines, artifacts, integrity of images. Incident response contains, eradicates, and recovers. Together, DFIR is how an organization handles a serious case without guessing.
Purpose in a security posture: stop the bleeding and learn. A DFIR report that never becomes a detection or a workbook change wastes the incident. Default bucket is reactive (there is already a case). The lessons should feed proactive work.
L1 does not become a forensic examiner on every High alert. L1 preserves: do not reboot-wipe a host the workbook says to isolate; do not forward malware to random mailboxes; do record exact times so IR is not reconstructing from memory.
Threat hunting: look before the alert exists
Threat hunting is a hypothesis-driven search through telemetry for attacker behavior that current rules may have missed. Example hypothesis: "If an adversary used signed binaries to live off the land, we would see rundll32.exe with unusual network children on branch PCs outside change windows." The hunter searches, confirms or refutes, then either writes a detection, opens an incident, or documents that the hypothesis failed.
Purpose: shrink dwell time —the period an adversary is inside before anyone notices. Hunting is proactive . It uses the same SIEM as the queue, which confuses candidates into calling it reactive. The trigger is the hypothesis, not a notable event.
Hunting is not "scroll Splunk until scared." Unguided scrolling is how people invent stories and miss the queue.
Worked contrast: Monday queue versus Thursday tabletop
Reactive — alert queue. Monday 09:10 UTC, Cedar Bank L1 has 36 "encoded PowerShell" alerts from IT-WKS-04 . Each is the documented Monday helpdesk installer. Closing all 36 with the same sentence is still reactive queue work . If L1 stops there, Tuesday will look identical. The proactive twin is an FP-remediation ticket to detection engineering with a sample command line, signer, share path, and a request to exclude that pattern with an expiry.
Proactive — purple-team tabletop. Thursday 14:00 UTC, the facilitator injects: "Red will describe a Word-to-PowerShell beacon on a branch PC; blue, walk your workbook without opening production." Nobody runs malware. Detection engineering admits the encoded-PowerShell rule would have fired on the helpdesk script and on the red technique, so severity-alone cannot be the verdict. IR admits after-hours isolation authority is unclear for branches. The output is a gap list: tune the rule, add a workbook step for parent-process checks, clarify who can isolate BR-WKS-* . That meeting is proactive , even though the story is an attack.
If you mix the buckets on an exam item: "Which of these is reactive?" the Monday queue is the answer. "Which is a proactive exercise involving red and blue?" the Thursday tabletop is the answer. Do not call the tabletop reactive just because people talked about C2. Do not call FP remediation "only reactive" if the durable fix is a better rule—the pain was reactive; the fix is proactive.
Independent coverage of these SAL1 activity topics is the difference between a busy SOC and a SOC that gets quieter and sharper over a quarter.