Client-Side Attacks practice questions

SQL Injection extraction via asynchronous database polling loops

Why it fails: The code utilizes XMLHttpRequest to make HTTP requests to an internal URL, interacting with web applications rather than executing SQL queries. Database polling requires specialized database drivers or direct query syntax, which is absent from this standard HTTP request script.

Server-Side Request Forgery via backend proxy manipulation

Why it fails: Server-side request forgery involves tricking the server into making requests, whereas this script runs entirely inside the client browser. The XMLHttpRequest originates from the victim browser context rather than the backend application server.

Cross-Site Request Forgery payload designed to modify state without reading responses

Why it fails: CSRF typically targets state-changing operations (like POST or PUT requests) where reading the response body is not required. This script performs a GET request and explicitly reads and exfiltrates the response text, which differentiates it from standard CSRF.

It causes the web server to crash due to recursive header evaluation loops in the CORS parsing middleware

Why it fails: CORS headers are evaluated per request by web server middleware and do not cause recursive parsing loops or server crashes. The issue is purely an access control authorization flaw rather than a denial of service vulnerability.

It automatically upgrades all incoming HTTP connections to encrypted TLS connections without requiring redirects

Why it fails: CORS headers dictate cross-origin resource sharing permissions for browser scripts, having no impact on transport layer encryption or protocol upgrading. Transport security is managed via HSTS and TLS configuration settings.

It permanently disables the Same-Origin Policy for all users globally across the entire internet domain

Why it fails: The Same-Origin Policy remains active in the browser; CORS is an intended exception mechanism controlled by server headers. Misconfiguring CORS relaxes these exceptions improperly rather than disabling the core policy globally.

Send an AJAX request to document.cookie to bypass the browser's HttpOnly security restriction.

Why it fails: The HttpOnly flag is enforced at the browser level and explicitly instructs the engine to deny any JavaScript access to the cookie object. No amount of standard script manipulation or AJAX requests can override this security control, as the browser kernel blocks the retrieval call entirely.

Inject a hidden iframe that reloads the page to force the server to reveal the cookie in the DOM.

Why it fails: Reloading the page through an iframe will not change the HttpOnly attribute of a cookie. The server-side instruction remains in effect throughout the session, and the DOM environment remains restricted regardless of the frame structure or page content reloads initiated by the malicious script.

Use an XMLHttpRequest to perform a cross-origin request to read the response headers of the server.

Why it fails: Cross-origin requests are governed by the Same-Origin Policy and CORS headers. Even if the request succeeds, the browser does not expose the HttpOnly cookie information in response headers to client-side scripts, maintaining the integrity of the session token against unauthorized access from third-party origins.

The attacker must be able to read the response from the server to extract the CSRF token.

Why it fails: CSRF attacks are 'blind' in nature, meaning the attacker does not need to see the response content. The exploit relies on triggering a state-changing request. If the attacker could read the response, it would likely be a Cross-Site Scripting or data exfiltration issue rather than pure CSRF.

The attacker must possess the victim's session cookie to successfully forge the request.

Why it fails: The entire premise of CSRF is that the attacker does not need the actual cookie value. The browser handles the cookie inclusion automatically. The attacker simply needs to trick the user into triggering the request, letting the browser perform the heavy lifting of authentication and authorization.

The target application must be vulnerable to reflective XSS on the login page.

Why it fails: CSRF is independent of XSS. While XSS can be used to perform CSRF, a standalone CSRF attack only requires the application to trust ambient credentials without verification. XSS is a separate vulnerability class involving script execution, which is not a prerequisite for standard CSRF exploitation.

default-src 'none'; img-src 'self'

Why it fails: This directive restricts images but does not explicitly define a script-src policy. In many browsers, if script-src is missing, it falls back to the default-src directive. If default-src is 'none', it would block scripts, but the primary mechanism for specifically securing script execution is the script-src directive.

frame-ancestors 'none'

Why it fails: The frame-ancestors directive is designed to prevent clickjacking by controlling which sites can embed the application in an iframe. It does not provide any protection against reflected XSS, as it does not regulate the execution or source of JavaScript code within the application's primary document.

connect-src 'self'

Why it fails: The connect-src directive restricts the domains to which the application can initiate network requests, such as via fetch or XMLHttpRequest. It does not govern the execution of JavaScript, meaning an attacker could still inject and execute malicious scripts even if network requests are strictly limited.

Analyze the server's HTTP response to see if the payload is reflected in the HTML.

Why it fails: For DOM XSS, the payload is typically not present in the server's initial HTTP response. The vulnerability manifests later through client-side processing. Looking at the raw server response is for reflected XSS, not DOM XSS, and will likely lead to incorrect conclusions about the vulnerability type.

Modify the server-side source code to remove input validation routines.

Why it fails: Penetration testers must work within the environment provided by the client. Modifying server-side code is outside the scope of testing activities and violates standard rules of engagement. Verification must be performed by interacting with the application as a black-box user, not by altering the application backend.

exploit/windows/smb/ms17_010_eternalblue

Why it fails: This module exploits the MS17-010 vulnerability to achieve remote code execution, but it does not involve relaying captured NetNTLMv2 hashes. The scenario specifies relaying credentials to a host without SMB signing, not exploiting a missing patch, so this module is inappropriate for the described attack path.

auxiliary/spoof/llmnr/llmnr_response

Why it fails: This module poisons LLMNR queries to capture NetNTLMv2 hashes, which is the step you have already completed. It does not perform the relay to a target host, so it cannot fulfill the requirement of using those captured credentials to execute a payload on an SMB-signed-disabled system.

auxiliary/server/capture/smb

Why it fails: This module only captures SMB authentication attempts and stores the resulting hashes for offline cracking; it does not relay those credentials to another host or execute a payload. In the scenario, you need active relay to a target that lacks SMB signing, so a pure capture module fails to achieve the required objective.

Hashcat with the -m 5600 mode

Why it fails: Hashcat mode 5600 is for NetNTLMv2 hashes, but the question asks for a tool specifically designed for this type of cracking; while Hashcat is valid, the scenario emphasizes a tool that natively supports the format without additional mode specification. However, in practice both are used; the key is that John the Ripper is often the default choice for NetNTLMv2. This option is plausible but not the best fit because the question implies a tool that directly handles the format, and Hashcat requires the correct mode, which is not mentioned. The correct answer is John the Ripper with the explicit format flag.

Mimikatz with the sekurlsa::logonpasswords command

Why it fails: Mimikatz is used to extract credentials from memory on a compromised host, not to crack NetNTLMv2 hashes offline. The sekurlsa::logonpasswords command dumps plaintext passwords and hashes from LSASS, but it requires local access to the target. In this scenario, you have only a captured hash and need offline cracking, so Mimikatz is not applicable.

Responder with the -w flag

Why it fails: Responder is used to capture NetNTLMv2 hashes by poisoning LLMNR, NBT-NS, and mDNS, but it does not crack hashes. The -w flag enables the WPAD proxy server, not password cracking. This tool is for the capture phase, not the cracking phase, so it cannot recover the plaintext password from the captured hash.

Use a malicious .lnk file that executes a PowerShell one-liner when double-clicked.

Why it fails: A .lnk file is not a document that Office opens; it requires the user to double-click a shortcut, which is a different attack vector. The scenario specifies opening a weaponized document, implying an Office file. While .lnk attacks are effective, they do not fit the context of macro-disabled Office documents.

Use a malicious Excel 4.0 (XLM) macro embedded in a .xlsm file.

Why it fails: Excel 4.0 macros are also blocked by the same Group Policy that disables VBA macros in Office 2016, because the policy applies to macro execution broadly. While XLM macros can sometimes bypass older defenses, modern Group Policy settings and Office updates specifically address them. This technique is unlikely to succeed under the stated restrictions.

Deliver a malicious .docm file with a VBA macro that uses AutoOpen().

Why it fails: The AutoOpen() macro is a VBA macro, and the Group Policy explicitly disables macro execution. Even if the user enables content, the policy prevents the macro from running. This approach directly violates the stated restriction and will fail.

Inject a keylogger into the application using a stored XSS vulnerability to capture keystrokes.

Why it fails: A keylogger would capture user input, but the scenario involves stealing data transmitted via postMessage, which may not involve user keystrokes. While XSS could be used to read postMessage events if the script runs in the application's origin, the question asks for the best technique to intercept messages sent to an iframe. Hosting a malicious page that embeds the application is more direct and does not require an XSS vulnerability.

Use a man-in-the-middle proxy to intercept and modify the postMessage traffic between the application and the iframe.

Why it fails: postMessage is a client-side JavaScript API that operates within the browser; it does not generate network traffic that can be intercepted by a proxy. The messages are passed directly between windows in the browser's memory. A MITM proxy would not see postMessage calls, so this approach is ineffective. The vulnerability must be exploited within the browser context.

Perform a DNS rebinding attack to bypass same-origin policy and read the iframe's content.

Why it fails: DNS rebinding can bypass same-origin policy in some cases, but it is complex and not specifically suited for intercepting postMessage events. The vulnerability here is the lack of origin validation in postMessage, which can be exploited simply by embedding the application in an iframe on a malicious page. DNS rebinding would not directly allow reading postMessage data and is overkill for this scenario.

A .pdf file with embedded JavaScript.

Why it fails: Modern PDF readers like Adobe Acrobat Reader have JavaScript disabled by default and require user approval to enable it. A fully patched system will not execute embedded JavaScript automatically. This format is unlikely to achieve code execution without user interaction.

A .lnk file that points to a malicious executable.

Why it fails: A .lnk file requires the user to double-click it, and Windows may display a security warning. While effective, it often requires additional user interaction and may be blocked by email gateways. The scenario specifies executing upon opening the email attachment, which implies less interaction.

A .docx file containing a malicious macro.

Why it fails: A .docx file cannot contain macros; macros require a macro-enabled format like .docm. Even if renamed, Word will not execute macros from a .docx. Additionally, macros are disabled by default in modern Office. This format will not execute code without user interaction.

Embedding the HTA inside a standard PDF document using an external URI scheme pointing to a remote script

Why it fails: PDF files use different rendering engines and cannot natively execute HTA payloads directly inside their document structure. While PDFs can trigger external links or launch embedded binaries, mshta.exe execution requires direct file invocation or browser-based protocol handlers rather than standard PDF readers.

Hosting the HTA file on an Apache web server with a fake mime-type configuration forcing automatic execution

Why it fails: Modern web browsers enforce strict MIME-type checking and security policies that prevent automatic execution of downloaded binaries. Even if the server misconfigures the Content-Type header, the browser will either block the download or prompt the user, requiring manual local execution.

Converting the HTA payload into a malicious shortcut (.lnk) file that calls PowerShell with hidden window arguments

Why it fails: Shortcut files rely on invoking cmd.exe or powershell.exe directly rather than utilizing the mshta binary format. While .lnk files are a common delivery vector, they do not leverage HTML Application mechanics or the specific script-processing capabilities of the mshta engine.

SQL Injection

Why it fails: SQL injection involves manipulating database queries rather than targeting user browsers through reflected markup. This vulnerability manifests when input is concatenated directly into backend SQL statements, leading to data exposure or authentication bypass instead of client-side script execution.

Remote Code Execution

Why it fails: Remote code execution affects the server-side application logic by allowing attackers to execute operating system commands via vulnerable functions. Unlike client-side XSS, RCE compromises the underlying server infrastructure rather than the browser context of individual visiting users.

Cross-Site Request Forgery

Why it fails: CSRF forces an authenticated user to execute unwanted actions on a web application in which they are currently logged in. It relies on predictable request parameters rather than injecting and executing arbitrary scripts within the context of the victim browser.

Direct execution of native ELF binaries on the underlying Linux web server operating system

Why it fails: Uploading binary files to a web directory does not cause the operating system to execute them automatically without direct shell access. Web servers treat uploaded assets as static content unless an execution vulnerability like remote code inclusion exists.

Immediate compromise of the backend database via automated SQL injection through the filename

Why it fails: While filenames can sometimes be leveraged for SQL injection if improperly concatenated, simply uploading a file does not exploit database queries. The primary risk of unrestricted file uploads involves client-side script execution or server-side file inclusion.

Bypassing network perimeter firewalls through encapsulated ICMP tunneling inside the image metadata

Why it fails: Image metadata cannot tunnel ICMP past a firewall; that requires raw socket or protocol encapsulation, unrelated to file upload. The real client-side risk is stored cross-site scripting: an uploaded file with an HTML or SVG extension served from the public directory executes in a victim's browser session.

The user must double-click the document while holding down the Shift key to bypass AutoOpen restrictions

Why it fails: Holding down the Shift key while opening an Office document actually prevents auto-executing macros like AutoOpen or Document_Open from running. This is a legitimate troubleshooting and security feature built into Office to help users bypass malicious automation.

The file must be saved in the local startup directory and the user must open the application normally

Why it fails: Saving to the startup directory does not bypass Office macro security; Protected View and macro blocking still apply unless the location is a Trusted Location. That placement suits persistence across logons, not the default execution path for a weaponised document.

The target workstation must have macro auditing disabled via Group Policy Objects before execution

Why it fails: Group Policy Objects are administrative settings managed by domain controllers, not user actions required for exploit delivery. Exploiting a target via phishing relies on bypassing user-level trust boundaries rather than modifying enterprise domain group policies.

Extracting plaintext password hashes directly from the remote web server operating system memory

Why it fails: Browser JavaScript cannot read remote server process memory, so operating system credential extraction is unreachable from this context. XSS is leveraged to act within the victim's authenticated session, for example issuing same-origin requests or exfiltrating tokens, not to dump host memory.

Modifying the enterprise DNS records hosted on the primary domain controller via client-side DOM manipulation

Why it fails: JavaScript runs in the browser sandbox and cannot reach the domain controller or modify DNS zone data; DOM manipulation affects only the rendered page. Client-side script is used to read the victim's session, cookies or CSRF tokens, not to alter server-side directory records.

Bypassing enterprise firewall packet inspection rules by encapsulating shellcode inside HTTPS headers

Why it fails: XSS executes JavaScript in the victim's browser session, enabling session hijacking, credential theft or CSRF-style actions; it cannot tunnel shellcode through HTTPS headers, which is a network-layer evasion technique. Encapsulating payloads in HTTPS headers is tempting for bypassing deep packet inspection, but that belongs to command-and-control or exfiltration scenarios, not browser-based script execution.

Input processed by a backend database stored procedure for primary key generation

Why it fails: Database stored procedures generating primary keys never emit their output into HTML, attribute, or script contexts, so injected characters cannot reach a browser parser. It is tempting because stored procedures are a recognised injection surface, but that concerns SQL injection, where parameterised calls and least-privilege execution — not XSS context analysis — are the correct controls.

Input stored as an encrypted binary blob inside the browser local session storage

Why it fails: Data stored as encrypted binary blobs in local storage is treated as static data structures by the client application. It does not get evaluated or parsed as active HTML markup unless explicitly decoded and rendered by the application DOM.

Input utilized as a parameter value inside a server-side JSON response header without content-type sniffing

Why it fails: JSON responses with proper application/json content-type headers are parsed as data objects by modern browsers rather than executed as HTML markup. Without explicit DOM rendering of the JSON values into the page, script execution cannot occur.

ISO files automatically disable Windows Defender Antivirus real-time protection upon mounting

Why it fails: Mounting an ISO does not alter Defender's real-time protection state; that service runs independently of any mounted volume. The technique works because files inside the mounted image lack the Mark-of-the-Web zone identifier, so SmartScreen and Protected View prompts are skipped. Disabling Defender requires tampering with settings or exclusions.

ISO files encrypt all internal payload binaries, rendering static signature analysis completely impossible

Why it fails: ISO files are not encrypted containers; their contents are readable and can be signature-scanned once extracted. The effectiveness stems from Mark-of-the-Web not propagating to files inside mounted images, bypassing SmartScreen and Office macros warnings. Encryption would require a separate tool such as VeraCrypt, not ISO mounting.

Mark of the Web attributes are permanently stripped from all files stored within virtual disk containers

Why it fails: The Mark of the Web can still be applied to files extracted from archives or disk images depending on the browser and extraction method used. ISO containers are not a universal guarantee against MOTW propagation across all Windows versions.

The application is completely immune to Cross-Site Scripting because a Content Security Policy is strictly enforced

Why it fails: The policy includes 'unsafe-inline' in script-src, which permits inline <script> blocks such as the token assignment, so injected inline script executes. A strict policy without 'unsafe-inline' or nonces would block it; here the directive is deliberately weakened, leaving reflected or stored XSS viable.

The server is vulnerable to remote code execution because the nginx version header is explicitly exposed

Why it fails: Exposing the server software version header reveals information for reconnaissance but does not grant remote code execution or relate to client-side CSP configurations. Version disclosure is an informational finding rather than a direct execution vulnerability.

The session token is vulnerable to interception because the response is transmitted over unencrypted HTTP

Why it fails: While the snippet shows HTTP/1.1, the exhibit does not provide transport layer security details, and the core vulnerability highlighted is the CSP directive. The primary security misconfiguration in the exhibit is the allowance of unsafe inline script execution.

The server-side application logs for suspicious input patterns.

Why it fails: DOM-based XSS is executed locally within the user's browser. The malicious payload often resides in the URL fragment, which is never sent to the server. Therefore, server-side logs will rarely capture the attack, making them an ineffective place to look for DOM-based vulnerability patterns.

The database queries for evidence of script injection.

Why it fails: Database queries are relevant for SQL injection or stored XSS, but they do not reveal DOM-based vulnerabilities. DOM XSS is entirely browser-resident and does not involve the database or server-side application logic, making database audit logs irrelevant for identifying the root cause of this specific vulnerability.

The server's response headers to check for security misconfigurations.

Why it fails: While security headers like CSP are important for defense-in-depth, they do not help identify the vulnerable client-side code itself. The flaw is logic-based within the JavaScript implementation, which requires manual code review or dynamic debugging to find the specific path from source to sink.