Exam: Chapters 26–32 · Security+ SY0-701

Chapters 26–32 Practice Exam

📝 20 scored questions ⏱️ 25-minute target 🎯 Pass threshold: 80% (16/20)

Time remaining

25:00

Part A — Multiple Choice (Questions 1–20)

Ch 26 · Memory Injection

Question 1 of 20

An attacker injects a malicious DLL into a legitimate Windows process such as explorer.exe. Once loaded, the malicious code runs inside that process's address space. Why does this technique help the attacker evade detection?

A. DLL injection disables Windows Defender automatically upon execution B. The malicious code runs inside a trusted, already-running process — security tools monitoring for suspicious processes see only the legitimate host process, not a separate malicious executable C. DLL files are never scanned by antivirus because they are not executable D. Injecting into explorer.exe grants SYSTEM-level privileges automatically

✅ B. DLL injection's key evasion property is that it hides malicious code inside a legitimate host process. Process-based security monitoring sees explorer.exe — a trusted Windows component — doing network connections or reading files. There is no separate suspicious process name to trigger an alert. The malicious DLL inherits the host process's trust context, security token, and whitelisted status. Reflective DLL injection takes this further by loading the DLL from memory without writing it to disk, evading file-based scanning entirely.

Ch 26 · Memory Injection

Question 2 of 20

A malware analyst observes that a suspicious sample starts a legitimate Windows process (svchost.exe) in a suspended state, unmaps the legitimate code from its memory, writes malicious shellcode into the now-empty address space, and resumes execution. What technique is this, and what is its primary advantage over standard process injection?

A. DLL injection — loading a malicious DLL into an existing running process B. Reflective DLL injection — loading a DLL from memory without touching disk C. Process hollowing — the malicious code runs under the exact identity and name of a legitimately spawned process; process listings, security tools, and task managers all show a trusted process name executing from an expected file path D. Thread injection — hijacking an existing thread within a running process to execute shellcode

✅ C — Process Hollowing. The key sequence is: spawn legitimate process suspended → unmap its legitimate code → write malicious code into the vacated address space → resume. The process still shows as svchost.exe in task manager and process monitors, with the correct image path and parent process — because it is svchost.exe from the OS's perspective. The malicious code simply replaced what the process was supposed to run. This is more deceptive than injecting into an already-running process because the new process was never legitimate at all — it was always a shell for the malware.

Ch 26 · Memory Injection

Question 3 of 20

A security architect explains why modern systems deploy both ASLR (Address Space Layout Randomization) and DEP (Data Execution Prevention) together rather than relying on either alone. What does each control independently prevent, and why is the combination stronger?

A. ASLR encrypts memory contents; DEP decrypts them for authorized processes only B. ASLR randomizes the memory addresses of code and data so attackers cannot hardcode target addresses; DEP marks memory regions as non-executable so injected data (shellcode) cannot run even if an attacker overwrites a return address — together they defeat both the "where to jump" and "what to execute" steps of an exploit C. ASLR prevents buffer overflows; DEP prevents DLL injection D. Both controls do the same thing — deploying both is redundant but harmless

✅ B. ASLR defeats exploitation steps that depend on knowing fixed memory addresses — classic exploits hardcoded the address of shellcode or system functions. With ASLR, those addresses change on every boot and process launch. DEP defeats exploitation steps that depend on executing code placed in data regions — classic exploits injected shellcode into the stack or heap (data memory) and jumped to it. With DEP, data memory is non-executable. To bypass both: an attacker needs to defeat ASLR (usually via a memory disclosure vulnerability to leak addresses) and find executable code to reuse (return-oriented programming / ROP). Each control independently raises the bar; together they require defeating both simultaneously.

Ch 27 · Buffer Overflows

Question 4 of 20

A developer writes a C function that copies user input into a fixed-size 64-byte stack buffer without checking the input length. An attacker submits 200 bytes of carefully crafted input. What happens to program execution, and what does the attacker control?

A. The program crashes immediately with a segmentation fault and the attacker gains no control B. The extra 136 bytes overwrite adjacent stack memory including the saved return address — when the function returns, execution jumps to wherever the attacker placed in the overwritten return address, giving the attacker control of program execution flow C. The operating system detects the overflow and kills the process before any damage occurs D. The overflow is contained within the buffer — excess bytes are silently discarded

✅ B. Stack memory layout: local variables (the 64-byte buffer) sit adjacent to the saved frame pointer and saved return address. Writing 200 bytes into a 64-byte buffer overwrites everything after the buffer — including the return address. When the function completes and executes the ret instruction, it loads the overwritten return address into the instruction pointer. The attacker crafts the overflow payload so the overwritten return address points to shellcode they also included in the payload (or to a ROP gadget chain). The crash in option A does happen when the return address is overwritten with garbage — a successful exploit requires precise control of the value placed at the return address position.

Ch 27 · Buffer Overflows

Question 5 of 20

Buffer overflows are a common vulnerability in programs written in C and C++, but are rarely found in programs written in Java, Python, or C#. What property of C/C++ makes their programs vulnerable, and what do managed languages do differently?

A. C/C++ programs run faster and therefore have less time to check for overflows before they occur B. C/C++ does not perform automatic bounds checking on array and buffer accesses — the programmer is responsible for ensuring writes stay within allocated memory; managed languages automatically check every memory access and throw an exception if bounds are exceeded, preventing writes beyond the allocated region C. C/C++ programs are always compiled without security flags, while managed languages compile with security flags enabled by default D. Buffer overflows only occur in C/C++ because those languages use direct network connections that managed languages encrypt automatically

✅ B. In C/C++, strcpy(dest, src) copies bytes until it hits a null terminator with no awareness of dest's size. If src is longer than dest, the copy overwrites adjacent memory — and the language does nothing to stop it. Java, Python, and C# manage memory through a runtime that checks every array access: array[i] where i >= array.length throws an ArrayIndexOutOfBoundsException rather than writing to the adjacent memory address. This is why operating systems and browsers (written largely in C/C++ for performance) are frequent sources of buffer overflow CVEs, while business applications in Java are not.

Ch 28 · Race Conditions

Question 6 of 20

A Unix program checks whether a file is writable by the current user, then opens the file for writing. An attacker times a symlink swap between the check and the open operation, replacing the target file with a symlink pointing to /etc/passwd. The program opens and writes to /etc/passwd instead. What vulnerability class is this, and what is the "race window"?

A. Buffer overflow — the attacker overflowed the file path variable to redirect the write B. SQL injection — the attacker injected a malicious file path into the check operation C. TOCTOU (Time-of-Check/Time-of-Use) race condition — the race window is the brief interval between the access check and the file open, during which the attacker replaces the checked resource with a different one D. Process injection — the attacker injected code into the program to redirect the file operation

✅ C — TOCTOU. TOCTOU (Time-of-Check / Time-of-Use) occurs when a program checks the state of a resource and then acts on it, but the resource changes between the check and the action. The "race window" is the time gap between the two operations — the vulnerability exists only during this window. If an attacker can change the resource faster than the window closes, they win the race. The fix is to make the check and use atomic — for files, use open() with appropriate flags that perform both operations as one indivisible step, or use file descriptors obtained at check time rather than file paths that can be swapped.

Ch 28 · Race Conditions

Question 7 of 20

A banking application allows concurrent processing of withdrawal requests. Without synchronization, two simultaneous requests for a $500 withdrawal from a $600 account can both read the balance as $600, both pass the balance check, and both execute — overdrawing the account by $400. Which mechanism prevents this race condition?

A. ASLR — randomizing memory addresses prevents concurrent access to the same balance variable B. A mutex (mutual exclusion lock) — the first thread acquires the lock before reading the balance; the second thread must wait until the lock is released; the critical section (read balance → check → deduct) executes atomically with respect to the lock, preventing both threads from passing the balance check simultaneously C. Input validation — rejecting withdrawal amounts larger than the account balance at the API layer D. TOCTOU mitigation — changing the file path to prevent symlink swaps

✅ B — Mutex. A mutex enforces that only one thread executes the critical section at a time. Thread 1 acquires the lock, reads $600, checks sufficient funds, deducts $500, writes $100, releases the lock. Thread 2 was blocked at the lock acquisition; it now acquires the lock, reads $100, and correctly fails the $500 balance check. Without the mutex, both threads execute the "read → check → write" sequence independently and interleave at the worst possible moment. This is also the mechanism behind the double-spend problem in cryptocurrency systems — where simultaneous transaction processing without proper locking allows the same funds to be spent twice.

Ch 28 · Race Conditions

Question 8 of 20

A developer investigating a system freeze discovers: Thread A holds Lock 1 and is waiting to acquire Lock 2; Thread B holds Lock 2 and is waiting to acquire Lock 1. Both threads are permanently blocked. What condition is this, and what is the standard prevention strategy?

A. A race condition — both threads are competing to read the same memory B. A buffer overflow — the threads have exceeded their allocated stack memory waiting for locks C. Deadlock — two threads each hold a resource the other needs, creating a permanent circular wait; prevented by enforcing a consistent lock acquisition order (all threads must acquire Lock 1 before Lock 2) so circular waiting cannot form D. A TOCTOU vulnerability — the threads checked resource availability before acquiring the locks

✅ C — Deadlock. Deadlock requires four conditions (Coffman conditions): mutual exclusion, hold-and-wait, no preemption, and circular wait. The most practical prevention is eliminating circular wait by enforcing a global lock ordering — if all code acquires locks in the same predefined sequence, a circle cannot form. Thread A and Thread B both wanting Lock 1 first means Thread B must wait until Thread A releases Lock 1 before it can proceed — the cycle is broken. Deadlock is a denial-of-service condition for the affected threads; in security contexts it can be deliberately induced to freeze a security monitoring process or create a window for exploitation.

Ch 29 · Malicious Updates

Question 9 of 20

A security researcher discovers that a company uses a private npm package named acme-internal-utils hosted on their internal package registry. The researcher publishes a malicious package with the same name to the public npm registry at a higher version number. Build pipelines that check public registries before private ones download and execute the malicious public version instead. What attack is this?

A. Update hijacking — the attacker intercepted the package download in transit B. Dependency confusion — exploiting build tools that resolve package names against public registries with higher precedence than internal ones, allowing a malicious public package to shadow a private internal package C. SQL injection — the attacker injected commands into the package manager's database query D. SIM swapping — the attacker redirected package registry authentication

✅ B — Dependency Confusion. Dependency confusion (discovered by security researcher Alex Birsan in 2021) exploits package manager behavior where public registries take precedence over private ones when a package name exists in both. By publishing a same-named package publicly at a higher version, the attacker ensures build tools automatically "upgrade" to the malicious public version. It requires zero exploitation of the target's systems — the build pipeline does exactly what it's designed to do, just against the wrong registry. Prevention: configure build tools to always prefer the internal registry for known internal package names using registry scoping, integrity hashes, or package name reservation on public registries.

Ch 29 · Malicious Updates

Question 10 of 20

An organization's security policy requires that all software updates be cryptographically signed before installation. A threat actor compromises the vendor's build server and injects malicious code into the software before the signing step. The update is then signed with the vendor's legitimate code-signing certificate and distributed normally. Does the organization's code-signing requirement protect them?

A. Yes — the malicious code will have a different signature than the legitimate code and will be rejected B. No — code signing verifies that the code came from the signer, not that the code is safe; if the attacker compromises the build pipeline before signing, the malicious code is signed with a legitimate certificate and passes all signature checks C. Yes — code signing certificates include a hash of the original source code that cannot be updated after issuance D. Yes — certificate authorities verify that software is malware-free before issuing code-signing certificates

✅ B. This is the fundamental limitation of code signing demonstrated by the SolarWinds SUNBURST attack (2020). Code signing proves provenance — "SolarWinds signed this" — but it cannot attest to the safety of what was signed. If the attacker modifies the code before the signing step, the signer signs malicious code. The resulting signed package passes every verification check: the signature is valid, the certificate is trusted, the distribution channel is legitimate. Code signing assumes the signer only signs good code. SBOM (Software Bill of Materials) and reproducible builds are proposed mitigations — reproducible builds allow independent parties to verify that a signed binary matches the published source code.

Ch 29 · Malicious Updates

Question 11 of 20

A newly disclosed critical vulnerability affects a popular open-source logging library. A security team needs to determine within hours which of their 400 applications incorporate this library — either directly or as a transitive dependency of another library. Which tool or artifact makes this triage possible quickly?

A. A Web Application Firewall — it can scan all 400 applications for the vulnerable library in real time B. An SBOM (Software Bill of Materials) — a machine-readable inventory of all components, libraries, and dependencies in each application that can be queried to immediately identify which applications include the affected library at any version C. ASLR — randomizing memory addresses prevents exploitation of the vulnerable library D. The application's digital certificate — certificates list all dependencies the application was compiled with

✅ B — SBOM. An SBOM is a structured list of every component an application uses: open-source libraries, third-party packages, and their versions. When a vulnerability like Log4Shell (CVE-2021-44228) is disclosed, organizations with SBOMs can query: "which applications list log4j-core in any version?" and get an immediate answer. Without an SBOM, teams must manually inspect build files, package locks, and deployment artifacts for all 400 applications — a process that can take weeks. The 2021 US Executive Order on Cybersecurity mandated SBOM requirements for federal software suppliers precisely because of Log4Shell-type incidents where organizations had no visibility into their transitive dependencies.

Ch 30 · OS Vulnerabilities

Question 12 of 20

A Patch Tuesday advisory includes two critical OS vulnerabilities: (1) A Remote Code Execution (RCE) flaw in the Windows print spooler that requires no authentication. (2) An Elevation of Privilege (EoP) flaw that allows a local standard user to gain SYSTEM privileges. Which vulnerability should be prioritized, and why?

A. The EoP vulnerability — privilege escalation is always more severe than code execution B. The RCE vulnerability — it requires no prior access to the system; an unauthenticated remote attacker can execute arbitrary code directly, making it an entry point with no prerequisites; the EoP flaw requires an attacker to already have local access before it can be used C. They are equal in severity and should be patched on the same schedule D. The EoP vulnerability — gaining SYSTEM privileges is more damaging than remote code execution

✅ B — RCE. An unauthenticated RCE requires nothing from the attacker except network reachability — no credentials, no prior compromise. It is the highest-severity vulnerability category because it is a standalone entry point. An EoP vulnerability requires the attacker to already have a foothold (local access with a standard user account) before they can exploit it. EoP is dangerous but it is a second-stage attack. In practice, attackers chain them: use RCE to gain initial remote access (even with limited privileges), then use EoP to escalate to SYSTEM. The Windows PrintNightmare vulnerability (CVE-2021-34527) is a real example of an RCE in the print spooler that followed exactly this pattern.

Ch 30 · OS Vulnerabilities

Question 13 of 20

An attacker exploits a previously unknown vulnerability in a widely deployed operating system. The vendor has received no prior reports and has no patch in development. Meanwhile, organizations relying on "patch your systems" as their primary security control have no defensive action available. What is this vulnerability type called, and what defensive approach remains effective when patching is impossible?

A. An EOSL vulnerability — the OS has reached end of service life and no patches are planned B. A zero-day vulnerability — a flaw with no available patch; behavioral security controls (anomaly detection, network segmentation, application allowlisting, least-privilege access) remain effective because they detect or limit exploitation based on behavior, not on known signatures C. A known vulnerability — all exploited vulnerabilities are known by definition once they are being used D. A legacy vulnerability — only present on systems running outdated software versions

✅ B — Zero-Day. "Zero-day" means the vendor has had zero days to prepare a patch. The vulnerability may be unknown to the vendor but known to attackers (or a government that purchased the exploit). Signature-based controls (antivirus, IDS signatures) are ineffective against zero-days because there is no known signature. Behavioral controls remain effective: application allowlisting detects unexpected processes; network segmentation limits blast radius; anomaly detection flags unusual behavior patterns; least-privilege means even a successful exploit starts with minimal permissions. Stuxnet, the NotPetya ransomware, and many nation-state attacks relied on zero-day exploits against fully patched systems.

Ch 30 · OS Vulnerabilities

Question 14 of 20

Microsoft releases patches on Patch Tuesday. An organization's policy requires a 30-day testing and staged deployment cycle before patches reach production. A security researcher notes this creates a critical window of exposure. What specific threat does this 30-day delay create?

A. The delay is safe because attackers take at least 60 days to develop exploits for newly disclosed vulnerabilities B. The delay is only a risk for zero-day vulnerabilities, not for patched ones C. Patch Tuesday disclosure makes vulnerability details public — attackers analyze the patches to reverse-engineer the underlying flaws and develop exploits, often within days; a 30-day delay leaves systems exposed for the entire period between public disclosure and deployment, during which exploit code is actively being weaponized D. The delay is irrelevant because Microsoft's security advisories do not contain enough detail for attackers to develop exploits

✅ C. Patch Tuesday creates a paradox: the same disclosure that informs defenders also informs attackers. When Microsoft publishes a patch, security researchers and attackers both analyze the "diff" between the patched and unpatched binaries to understand exactly what was fixed — and therefore what the vulnerability is. Exploit development then begins from a known starting point. Research consistently shows functional exploits for Patch Tuesday vulnerabilities often appear within 7–14 days. An organization with a 30-day patch cycle is vulnerable for 2–4 weeks after a viable exploit is public. High-severity patches require risk-based exceptions to the standard cycle — emergency deployment for critical vulnerabilities that are being actively exploited.

Ch 31 · SQL Injection

Question 15 of 20

A login form passes the username directly into a SQL query: SELECT * FROM users WHERE username = '[input]'. An attacker enters ' OR '1'='1 as the username. What does the resulting query do, and what security property is violated?

A. The query fails with a syntax error and the login is rejected safely B. The query becomes SELECT * FROM users WHERE username = '' OR '1'='1' — the OR clause makes the condition always true, returning all rows; this bypasses authentication by logging the attacker in as the first user in the table (often an administrator), violating both authentication and authorization C. The query correctly rejects the login because the username field has a maximum length restriction D. The query deletes the users table because the apostrophe is interpreted as a DROP command

✅ B — Authentication bypass via OR 1=1. The injected apostrophe closes the string literal that the application opened. The OR '1'='1' appended after makes the WHERE clause always evaluate to true. The database returns every row in the users table. Most login implementations take the first returned row as the authenticated user — typically the first account created, which is often an admin. The attacker logs in with no valid credentials. This is why OR 1=1 (or any tautology) appearing in database query logs is a strong indicator of SQL injection in progress — legitimate queries never contain always-true tautological conditions.

Ch 31 · SQL Injection

Question 16 of 20

A developer rewrites a vulnerable login query from string concatenation to a parameterized prepared statement. An attacker still submits ' OR '1'='1 as the username. What happens, and why does the parameterized query prevent the injection?

A. The parameterized query rejects the input because it detects the apostrophe character B. The database engine treats the entire submitted string ' OR '1'='1 as a literal username value, not as SQL syntax — the query searches for a user whose username literally equals that string, finds none, and correctly rejects the login C. The parameterized query encrypts the input before passing it to the database D. The query still executes the injection because parameterized queries only protect against numeric input, not string input

✅ B. Parameterized queries (prepared statements) work by separating the SQL structure from the data. The developer defines the query template first — SELECT * FROM users WHERE username = ? — and compiles it. The ? is a typed placeholder. The user's input is then bound to the placeholder as a data value. The database engine never re-parses the input as SQL code — it is fundamentally incapable of interpreting the bound value as commands. An apostrophe in the input is a literal character in a string value, not a SQL string delimiter. The injection payload ' OR '1'='1 is treated as a 13-character username, not as a SQL logical expression. This is why parameterized queries are the definitive fix for SQL injection.

Ch 31 · SQL Injection

Question 17 of 20

An organization deploys a Web Application Firewall (WAF) to block SQL injection attempts, and also applies the principle of least privilege to their database accounts — the web application uses a read-only database account with SELECT permissions only. An attacker successfully bypasses the WAF with an obfuscated injection payload. What is the impact of the least-privilege control on this scenario?

A. The least-privilege control is irrelevant — once WAF is bypassed, the attacker has full database control B. The least-privilege control limits the blast radius — even with a successful injection, the attacker can only execute SELECT queries; they cannot INSERT, UPDATE, DELETE, or DROP tables; data can be read but the database cannot be modified or destroyed C. The least-privilege control prevents the WAF bypass — it blocks obfuscated payloads that WAF misses D. The least-privilege control only applies to the operating system, not to database permissions

✅ B. This is defense-in-depth in action. WAF provides perimeter detection; least-privilege limits the impact if that perimeter is defeated. The WAF failure doesn't grant the attacker permissions beyond what the database account holds. A SELECT-only account cannot execute DROP TABLE, INSERT INTO admin_users, or UPDATE passwords — those commands are rejected by the database engine regardless of how they arrived. The attacker can still read data (a serious breach for sensitive records), but cannot destroy the database or escalate further via database commands. Least privilege transforms a catastrophic breach into a serious but bounded one — exactly the purpose of the control.

Ch 32 · Cross-Site Scripting

Question 18 of 20

An attacker posts a comment on a popular social media platform. The comment contains a JavaScript payload that, when other users view the comment, executes in their browser and posts the same comment to their own profiles. Within six hours the payload has spread to 50,000 accounts. Which XSS variant is this, and what property of this variant enables the rapid spread?

A. Reflected (non-persistent) XSS — the attacker sent a malicious link to 50,000 users individually B. Persistent (stored) XSS — the script is saved on the server and executes automatically for every user who views the infected page; on a social platform where content is shared, each newly infected account can expose additional followers, enabling exponential self-propagating spread (XSS worm) C. DOM-based XSS — the vulnerability exists in the page's client-side JavaScript D. SQL injection — the attacker injected JavaScript into the database via the comment field

✅ B — Persistent / Stored XSS (XSS Worm). Stored XSS saves the malicious script in the server's database. Every user who loads the infected page has the script execute automatically — no crafted link is required. On social networks, the script can be designed to self-replicate: each victim's browser executes the script, which posts the infected comment to their profile, where their followers see it and execute the script in turn. This creates exponential propagation — the 2005 Samy worm on MySpace spread to one million accounts in under 20 hours using exactly this mechanism. Reflected XSS requires the attacker to deliver a crafted link to each victim individually; it cannot self-propagate.

Ch 32 · Cross-Site Scripting

Question 19 of 20

A developer asks whether input validation alone is sufficient to prevent XSS, or whether output encoding is also required. A security architect explains that both are necessary. What does output encoding prevent that input validation might miss?

A. Output encoding is only needed for SQL injection — input validation handles XSS completely B. Input validation checks data at entry; output encoding handles data at display — data that entered the system before validation was implemented, data from trusted internal sources that may contain special characters, and edge cases where validation is bypassed all require output encoding as a second layer; without it, stored data containing HTML-significant characters can be interpreted as script when rendered C. Output encoding is only necessary for HTTPS connections D. Output encoding re-validates input a second time using the same rules as input validation

✅ B. Input validation and output encoding are complementary defenses at different points in the data lifecycle. Validation is a preventive control at data entry — it rejects or sanitizes malicious input before storage. Output encoding is a preventive control at data display — it converts HTML-significant characters (< > " ' &) into their entity equivalents so the browser renders them as visible text instead of executing them as markup. Both are needed because: (1) validation rules can have gaps or be bypassed; (2) data from internal systems, APIs, or legacy imports may contain special characters; (3) the context in which data is displayed changes (HTML body, HTML attribute, JavaScript string, URL) and each requires different encoding. Defense-in-depth: validation reduces what reaches storage; encoding prevents what reaches storage from executing.

Ch 32 · Cross-Site Scripting

Question 20 of 20

In the 2017 Subaru vulnerability discovered by Aaron Guzman, an XSS flaw in the vehicle management web interface allowed an attacker to steal authentication tokens from victims who clicked malicious links. The stolen tokens could be used indefinitely to access any vehicle registered to the victim's account. What two security failures combined to make this attack permanently damaging?

A. SQL injection and missing MFA — the attacker also accessed the backend database directly B. Buffer overflow and process injection — the attacker ran code on the vehicle's embedded system C. XSS enabling token theft combined with non-expiring authentication tokens — the XSS provided the delivery mechanism to steal tokens; the non-expiring design meant a stolen token granted permanent, irrevocable access with no time limit; fixing either flaw alone would have contained the damage D. Stored XSS and SQL injection — the attacker stored a payload that also queried the vehicle database

✅ C. Each flaw amplified the other. XSS alone is serious — it steals session tokens — but if tokens expire in 24 hours, the attacker's window is limited and re-attack is required. Token expiration alone is a good control but doesn't prevent XSS from functioning. Combining XSS token theft with a never-expiring token creates a permanent access grant: one successful XSS click gives the attacker access to the victim's Subaru account forever, with no further action required. The attacker could add their own email to multiple victims' accounts and manage those vehicles indefinitely. Additionally, the token granted access to any service request — not scoped to specific operations — multiplying the impact. Fixing both: implement token expiration and patch the XSS. Either fix alone meaningfully reduces risk; both together eliminate the combination.

Part B — Scenario Analysis (Unscored — for practice)

Ch 26–29 · Scenario

Scenario A — Memory Attack Investigation & Secure Development Remediation

An endpoint detection platform triggers an alert on a Windows workstation: the legitimate process lsass.exe is reading unusual amounts of memory from its own address space and making outbound connections to an external IP. Separately, the organization's security team has been informed that a critical C++ application processes user-supplied filenames without bounds checking. A junior developer proposes "just add a length check in the UI layer" as the fix. Analyze the memory attack on lsass.exe, explain why the UI-layer-only fix is insufficient, and design a complete remediation for the C++ application.

Memory Attack on lsass.exe — Analysis:

What is happening: LSASS (Local Security Authority Subsystem Service) is the Windows process that manages authentication — it holds plaintext credentials, NTLM hashes, and Kerberos tickets in memory for currently logged-in users. Suspicious memory reads on lsass.exe combined with outbound connections strongly indicates a credential dumping attack — likely using a tool like Mimikatz or a similar memory reading technique. The attacker has achieved code execution on the workstation and is extracting credentials from lsass.exe memory to enable lateral movement to other systems on the network.

Immediate response: (1) Isolate the workstation from the network immediately to prevent lateral movement with any stolen credentials. (2) Invalidate all credentials that were active on that machine — force password resets for all users who logged in recently. Revoke any Kerberos tickets. (3) Investigate how the attacker achieved initial code execution — review recent browser history, email attachments, USB connections, and process creation events to identify the initial attack vector. (4) Check other machines on the network for signs of lateral movement using the stolen credentials — review authentication logs for unusual logons from the compromised workstation's credentials.

Protective controls for future prevention: Enable Windows Credential Guard, which uses virtualization-based security to isolate the credentials stored by lsass.exe in a separate protected environment that cannot be read by normal processes, including malicious code running with SYSTEM privileges. Credential Guard specifically prevents Mimikatz-style credential dumping by making lsass.exe memory inaccessible from the host OS context. Also configure LSA protection (RunAsPPL) which requires lsass.exe to run as a Protected Process.

Buffer Overflow in C++ Application — Why UI-Layer Fix is Insufficient:

The problem with client-side / UI-layer validation: Input validation in the UI (frontend form, client-side JavaScript, or input field length restriction) only affects inputs arriving through that UI path. An attacker can bypass the UI entirely — using a proxy to intercept and modify requests, crafting direct HTTP requests to the API, or calling the C++ function directly if it's exposed through any other interface. The vulnerable C++ code does not know or care how the input arrived. If the bounds check is only in the UI layer and not in the C++ function itself, any input that reaches the function through any channel other than the protected UI is unchecked.

Complete Remediation:
(1) Input validation at the function level (primary fix): The C++ function that processes the filename must validate the input length before copying it into any fixed-size buffer. Use safe string functions: replace strcpy with strncpy (with explicit size limit), or better, use std::string which manages its own memory safely. Add an explicit length check at the top of the function that rejects any input exceeding the expected maximum filename length. This fix is in the right place — at the function boundary, regardless of which caller invoked it.
(2) Compile-time protections: Enable stack canaries (compiler flag /GS on MSVC or -fstack-protector on GCC). Stack canaries place a known value between the buffer and the return address — if the canary is overwritten by an overflow, the program detects corruption and terminates before the return address is used.
(3) OS-level mitigations: Ensure ASLR and DEP are enabled for the application — this does not fix the vulnerability but makes exploitation significantly harder by randomizing addresses and preventing code execution in data regions.
(4) Code review and static analysis: Run static analysis tools (Coverity, PVS-Studio, Clang's AddressSanitizer in testing) to identify all other instances of unsafe string operations in the codebase. A single unsafe strcpy identified suggests others likely exist.
(5) Keep the UI-layer check: The junior developer's UI check is not wrong — it is just insufficient alone. Retain it as a defense-in-depth layer. Defense at the UI prevents common mistakes by legitimate users; defense at the function protects against all callers. Both are needed.

Ch 30–32 · Scenario

Scenario B — Web Application Security Assessment Findings

A penetration test of a customer-facing web application produces three findings: (1) The login form is vulnerable to SQL injection — the tester successfully bypassed authentication using ' OR '1'='1. (2) A product review field stores and renders user input without sanitization — the tester injected a script that stole the session cookie of an admin user who viewed the reviews page. (3) The server is running a version of the OS with three unpatched critical CVEs, one of which is a remote code execution vulnerability that has public exploit code. Rank these findings by severity, explain the complete remediation for each, and describe why the layered combination of all three creates a risk greater than any single finding alone.

Severity Ranking:
1st — OS RCE with public exploit (Critical): An unauthenticated RCE with public exploit code is the highest severity. The attacker doesn't need to interact with the application at all — they directly execute code on the server as the OS. This is the most direct path to full server compromise and requires no application-layer interaction.
2nd — SQL Injection authentication bypass (Critical): A second critical finding — unauthenticated access to any account with no valid credentials. The attacker can access all customer accounts, read the database, and potentially escalate further via database commands.
3rd — Stored XSS session theft (High): Requires a victim to view the infected page (one extra step), but stealing an admin session cookie provides full administrator privileges within the application — potentially equivalent in impact to authentication bypass for administrative functions.

Remediations:

Finding 1 — OS RCE: Emergency patch. This has public exploit code and should be treated as actively exploitable. Apply the patch immediately — do not wait for a maintenance window. If patching cannot be immediate (e.g., requires application testing), implement a network-level workaround: restrict which source IPs can reach the vulnerable service at the firewall, and deploy a WAF rule blocking known exploit patterns for this specific CVE. Set a hard 48-hour deadline for the patch. Additionally, disable or restrict the vulnerable service if it is not required for the application's function.

Finding 2 — SQL Injection: Rewrite queries to use parameterized prepared statements. Replace every instance of string-concatenated SQL query construction with parameterized queries — the placeholder (?) pattern with bound parameters. This is the definitive fix. Supplementary controls: (a) Apply least-privilege database accounts — the web application's database user should have only the permissions its queries require (typically SELECT, and INSERT/UPDATE only for the specific tables the application writes to). (b) Deploy WAF rules for SQL injection patterns as a second-layer detection. (c) Conduct a full code review to identify all other SQL-constructing code in the application. (d) Enable database query logging to detect future injection attempts.

Finding 3 — Stored XSS: Implement output encoding and input validation. Output encoding: before rendering any user-supplied content in HTML, encode HTML special characters (< > " ' &) into their entity equivalents. This prevents the browser from interpreting stored content as script. Input validation: validate and sanitize all user input at entry — strip or reject HTML tags and JavaScript event handlers from review content. Defense-in-depth: deploy a Content Security Policy (CSP) header that instructs browsers to refuse execution of inline scripts and restrict script loading to explicitly trusted sources. Add the HttpOnly flag to the session cookie — this prevents client-side JavaScript from reading it via document.cookie, directly defeating the session theft technique used in the test.

Why the Combination Is More Dangerous Than Any Individual Finding:
Each finding has individual impact. Together they create compounding attack chains:

Chain 1 (OS RCE → Full server): The OS RCE gives an unauthenticated attacker code execution on the server, bypassing all application security completely. From there they can read the database directly, steal credentials of all users, and own the full application stack — rendering the SQLi and XSS findings moot (they already have everything).

Chain 2 (XSS → Admin session → SQLi exploitation): The XSS steals the admin session cookie, giving the attacker admin-level access to the application. As admin, they have access to application features that may execute broader SQL queries, enable SQLi in more privileged contexts, or expose internal data not available to standard users.

Chain 3 (SQLi bypass → Privilege → OS): The SQLi authentication bypass may give access to admin credentials stored in the database (in hashed or cleartext form). With admin credentials, an attacker may be able to access server administration interfaces that provide a path to OS-level commands — particularly if the application is hosted on infrastructure with admin panels exposed.

The principle: in security, vulnerabilities multiply each other's impact when they can be chained. A single finding of medium severity combined with another finding of medium severity may produce a critical-severity exploit path that neither finding created alone. Remediating all three findings individually also eliminates the chains between them.

← Exam: Ch 19–25 All Chapters Exam: Ch 33–34 →

—

Pass threshold: 80% (16 / 20 correct)

← Ch 19–25 Exam All Chapters Ch 33–34 Exam →

Exam: Application Attack Methods