Study guide
9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF
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
9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF
Key Takeaways Explain This Topic AI
Code injection abuses an application or OS interpreter (unexpected shells or language runtimes spawned by the web worker); SQL injection abuses the database engine — same word family, different logs.
Path or directory traversal appears as ../ or encoded dot-dot sequences in URLs and as HTTP 200 responses that return files the web user should never receive.
Input validation constrains untrusted parameters at the application boundary; it does not automatically fix every business-logic bug or every field the developer forgot to check.
Patching removes known vulnerable code; it does not stop every unpatched custom flaw or every request that never hits the upgraded host.
A WAF can block many known HTTP attack signatures at the edge, but an origin 200 with traversal in the URL means the request still reached the application — coverage gaps and bypass paths must be investigated.
Last updated: September 2026
Code injection versus SQL injection
SAL1 training content groups code injection with XSS, SQL injection, and path traversal as common web attacks. Analysts must not treat every "injection" alert as the same incident type. SQL injection smuggles database language into a query. Code injection smuggles instructions into whatever interpreter the application already runs: a template engine, an eval -style language feature, or an operating-system command channel. The impact can look similar (data theft, takeover), but the artefacts differ.
Recognition for code injection starts at process telemetry, not at a payload cookbook:
The web worker ( nginx worker, httpd , java , w3wp.exe , node ) spawns /bin/sh , bash , python , perl , or powershell.exe with no change ticket.
Application logs show a 200 or 500 on an endpoint that then correlates to a child process in System Monitor (Sysmon) or Linux Audit daemon (auditd) (those tools are taught in depth in section 9.4).
Outbound connections appear from the application host to an unknown IP immediately after that spawn — a pivot, not a browser XSS cookie theft.
Worked, sanitized host snippet after a web alert: 2026-09-18T11:07:44Z src=203.0.113.80 GET /export format=[suspicious] status=200
- 2026-09-18T11:07:44Z parent=w3wp.exe child=cmd.exe pid=4488 host=WEB-02
- 2026-09-18T11:07:45Z child=powershell.exe parent=cmd.exe
That is code injection or command injection at the recognition level: the IIS worker should not be a parent of a command shell during an export. SQLi on the same timestamp would instead show a database audit spike without a new shell. Do not copy command lines from malware reports into a lab "to try it." Preserve the tree, isolate the pool identity, and ask development which parameter maps to an interpreter.
Path and directory traversal in logs
Path traversal (also called directory traversal ) occurs when user-controlled input is used to build a file path and the application fails to constrain the result to an intended directory. Attackers historically use parent-directory segments. You need to recognize those segments in telemetry, not practice them against live systems.
Analyst-visible patterns:
Literal ../ or ..\ in the URL path or in a file , template , download , or lang query parameter.
Encoding variants such as %2e%2e%2f or double encoding in WAF and access logs. Encoding is a bypass attempt against naive filters; seeing it in a log is an indicator, not a how-to.
HTTP 200 responses whose body looks like an operating-system or application configuration file (password databases, web server configs, environment files, source maps) rather than the usual JSON or HTML for that route.
Content-length far above or below the baseline for that endpoint, or Content-Type: text/plain on a route that normally returns application/json .
Worked, sanitized pair (the important comparison for this section): # WAF (public hostname www.example.com)
2026-09-18T13:15:02Z action=block status=403 rule=path-traversal uri=/static/%2e%2e/%2e%2e/app/.env src=192.0.2.77
- # Origin (same application, hostname origin-prod.internal.example.com, no WAF in path)
- 2026-09-18T13:15:09Z status=200 bytes=612 uri=/static/../../app/.env src=192.0.2.77 ua=same-as-blocked-request
The WAF did its job on the public name. Seven seconds later the origin returned 200 and a 612-byte body for a traversal-shaped path. Possible explanations: the client hit a hostname or port that skips the WAF; an internal tool or mis-issued certificate pointed scanners at origin; or a second URL path was not in the WAF policy. The analyst's finding is not "WAF is useless." The finding is "WAF block does not prove origin never served the file."
Input validation, patching, and WAF — what each does and does not catch
SAL1 training content names three defensive measures: input validation , patching , and WAF . Memorize the job of each so you do not close a ticket with the wrong owner.
Input validation inspects untrusted parameters at the application boundary and allows only expected types, lengths, character classes, and canonical paths. It can stop many XSS reflections, many SQLi string concatenations, and many ../ file arguments on the fields that are actually checked . It does not catch business-logic abuse (a valid ID you are not allowed to see), it fails when a developer validates the display name but not the filename, and it fails when the app decodes input after validation (canonicalization bugs).
Patching replaces vulnerable code with a fixed version: a library CVE, a framework update, or an internal hotfix. It removes the root cause for that known flaw. It does not help the night the CVE drops and the change window is next Tuesday. It does not help a custom endpoint that was never in the vendor advisory. It does not help a forgotten replica that still runs the old build. Analysts still need inventory: which host served the 200?
WAF inspects HTTP at the edge (signatures, anomaly scores, allow-lists, virtual patching). It can buy time when a patch is not installed, and it produces high-value block logs. It does not see requests that never traverse it (direct-to-origin, other ports, non-HTTP channels). It can miss encodings, multipart tricks, and JSON fields the rule set does not inspect. It is not a substitute for fixing code. A WAF 403 is evidence of an attempt; it is not evidence that the same actor failed everywhere.
Control What it does What it does not catch Analyst question
Input validation Constrains parameters in the running app Unvalidated fields, decode-after-check, logic bugs Which parameter was checked, and after which decode?
Patching Removes known vulnerable code Unpatched copies, zero-days, custom flaws Which build/hash served this 200?
WAF Blocks many known HTTP attack patterns at the edge Direct-to-origin, unscored encodings, non-HTTP Did origin still return 200 on another name?
Analyst comparison: WAF block versus origin 200
Use a consistent checklist when traversal or injection signatures fire:
Record WAF action, rule ID, and status (403, 406, 301 to a captcha, or action=allow with a logged match).
Query origin access logs for the same source IP, the same path family, and a ±15 minute window — including internal hostnames and default site bindings.
If origin is 200 and the body is a sensitive file, treat confidentiality as impacted even if the WAF also shows blocks.
If origin is 404/403 and WAF is block, the attempt may have failed; still hunt for siblings (other paths, other vhosts).
File the code fix (validation + patch) separately from the WAF rule request. Virtual patching is a stopgap, not closure.
Trap: encoded traversal that the WAF blocks as %2e%2e%2f may still succeed if the origin normalizes a different encoding the WAF does not decode the same way. Trap: a 200 with a traversal string in the referrer only is not a successful file read. Trap: static-site 200s that return HTML error pages with a 200 status can look like success until you inspect the body.
Code injection, SQLi, XSS, and traversal all share one operational moral: the HTTP status on a single hostname is not the incident. The incident is whether untrusted input became code, a query, or a file path, and whether data or control left the intended boundary. The next two sections leave the web tier and follow initial access, persistence, and credential theft on endpoints.