203.0.113.5 internalbank.corp.com. Users of that workstation who type "internalbank.corp.com" in a browser are now directed to the tester's server. Which DNS attack category does this represent, and why does it bypass the corporate DNS server?C:\Windows\System32\drivers\etc\hosts; Linux/macOS โ /etc/hosts. This attack is limited to the local machine (unlike DNS server compromise which would affect all clients) but is effective if the attacker has local admin access. DNSSEC cannot protect against this โ it signs DNS responses, but the hosts file bypasses DNS entirely. Defense: monitor hosts file integrity; restrict local admin access; use endpoint security tools that alert on hosts file modifications.SELECT * FROM users WHERE username='[INPUT]' AND password='[INPUT]'. An attacker enters admin'-- as the username and any string as the password. The resulting query is: SELECT * FROM users WHERE username='admin'--' AND password='anything'. The attacker is authenticated as admin. Which vulnerability enables this attack and what is the complete, correct remediation?<img src="https://bank.com/transfer?to=attacker&amount=5000" style="display:none">. Their browser automatically sends a GET request to that URL, including their bank session cookie. The transfer completes successfully. The victim authorized nothing. Which attack is described and what server-side control specifically prevents it?A security team investigates a serious incident at a financial services firm. The timeline shows: (1) An on-path attacker on the corporate LAN sent forged ARP replies claiming the gateway's IP belonged to the attacker's MAC, redirecting all employee traffic through the attacker's machine. (2) During this interception, the attacker captured session cookies for the HR portal โ which used HTTP for session management. (3) Using these cookies, the attacker accessed the HR portal without credentials, changed bank routing information for payroll, and exfiltrated employee records. (4) A separate investigation reveals an IT admin's Active Directory credentials were stolen via pass-the-hash โ their NTLM hash was extracted from a compromised workstation and used to authenticate to the domain controller without ever cracking it. Classify each stage of the attack, identify the vulnerable design decision that enabled each, and specify the exact technical control that would have prevented each stage.
Classification: ARP poisoning / on-path attack at Layer 2. The attacker exploited the lack of ARP validation โ ARP has no authentication; any device can claim any IP-to-MAC mapping.
Vulnerable design: No Dynamic ARP Inspection (DAI) on the managed switch.
Control: DAI validates ARP packets against the DHCP snooping binding table. An ARP reply claiming the gateway IP with a non-gateway MAC would be dropped at the switch port before reaching any endpoint. This single control stops ARP poisoning entirely on a managed switch.
Stage 2 โ Session Cookie Capture:
Classification: Session hijacking / replay attack. Once on-path, the attacker captured plaintext session cookies from HTTP traffic.
Vulnerable design: The HR portal issued session cookies without the Secure flag (allowing HTTP transmission) and did not enforce HTTPS for authenticated sessions.
Control: (1) Secure cookie flag โ instructs browsers to never send the cookie over HTTP; (2) HTTPOnly flag โ prevents JavaScript access; (3) HSTS โ enforces HTTPS for all communication, so even if ARP poisoning succeeds, the attacker sees only encrypted HTTPS traffic and cannot read session cookies from it. Note: if stage 1 (ARP poisoning) is prevented, stage 2 becomes impossible anyway. Defense in depth means each stage has an independent control.
Stage 3 โ Unauthorized HR Portal Access:
Classification: Session replay attack using hijacked credentials (the captured session cookie). The attacker used a valid cookie to impersonate an authenticated employee.
Vulnerable design: Session cookies had no binding to IP address or user-agent; the cookie was sufficient alone for authentication with no secondary factor.
Control: Beyond cookie security, adding MFA at the HR portal for sensitive actions (payroll routing changes, bulk data exports) would have required the attacker to have a second factor they lacked. Activity monitoring โ alerts on bulk data exports or payroll routing changes โ would have detected the anomalous access regardless of authentication method.
Stage 4 โ Pass-the-Hash Domain Controller Access:
Classification: Pass-the-hash attack. NTLM authentication accepts the hash directly as proof of identity โ the attacker never needed the plaintext password.
Vulnerable design: (1) NTLM authentication still enabled on the domain controller; (2) LSASS credential storage not protected against memory scraping; (3) admin account used for day-to-day workstation activity, leaving hashes cached on endpoints.
Controls: (1) Credential Guard โ isolates LSASS in a virtualized secure container; credential dumping tools cannot read credentials from it; (2) Protected Users security group โ prevents NTLM authentication for group members (forces Kerberos, which uses time-limited tickets with nonces rather than replayable hashes); (3) Privileged Access Workstations (PAW) โ admin accounts should only be used on hardened, dedicated machines, not general-purpose workstations where malware can dump their hashes; (4) Disable NTLM authentication domain-wide where Kerberos is available.
A security auditor reviews a company's authentication and cryptographic posture and finds three issues: (1) The company's document management system signs contracts using MD5 as the hash algorithm before applying RSA-2048 signatures. (2) The public-facing web portal redirects HTTP to HTTPS via a 301 response, but has no HSTS header; a demo shows an attacker on the same Wi-Fi network can capture employee credentials in plaintext. (3) The employee portal's password database uses SHA-256 without salting. After a simulated breach of the password table, a GPU cluster cracks 55% of passwords in 3 hours, and all 47 accounts using the same password ("Welcome1") are cracked simultaneously from a single hash computation. For each finding, state the attack it enables, classify it as an algorithm attack or implementation attack, and provide the precise remediation.
Attack enabled: Birthday attack / hash collision. An attacker can engineer two documents with the same MD5 hash (practical since 2004). Having an authorized party sign the legitimate document, the attacker substitutes the fraudulent one โ the RSA-2048 signature validates on the fraudulent document because both share the same MD5 digest. RSA-2048 is not involved in the vulnerability; the weakness is entirely in the hash algorithm.
Classification: Algorithm attack. MD5's collision vulnerability is in its mathematical design. Any correct implementation of MD5 is vulnerable โ the issue is the algorithm choice, not the configuration.
Remediation: Replace MD5 with SHA-256 in the signature algorithm (SHA-256withRSA). SHA-256 provides 2128 birthday-bound collision resistance โ computationally infeasible. Re-sign any high-value existing contracts with SHA-256 where legally required.
Finding 2 โ HTTP to HTTPS Redirect Without HSTS:
Attack enabled: SSL stripping. An on-path attacker intercepts the 301 redirect before it reaches the browser. The victim's browser never learns HTTPS exists; stays on HTTP; transmits credentials in plaintext. The attacker maintains HTTPS with the server. No browser warning appears. The demo confirms this works despite HTTPS being configured.
Classification: Implementation attack. HTTPS is correctly configured on the server. TLS is not broken. The 301 redirect is a server response that can be intercepted. The deployment is vulnerable because HSTS (which makes HTTPS enforcement browser-side, before any HTTP request is sent) was not implemented.
Remediation: Add the HSTS header to all HTTPS responses:
Strict-Transport-Security: max-age=31536000; includeSubDomains. After browsers store this policy, they refuse to send any HTTP request to the domain โ SSL stripping has nothing to intercept. For maximum protection: submit to the HSTS preload list (ships the policy in the browser, protecting first-time visitors before they've ever received the HSTS header).Finding 3 โ SHA-256 Without Salting:
Attack enabled: Two simultaneous vulnerabilities: (a) Offline brute force at GPU speed โ SHA-256 evaluates at ~10 billion hashes/second; 55% cracked in 3 hours demonstrates the speed advantage over slow-hash algorithms like bcrypt. (b) Batch cracking of identical passwords โ without salting, all 47 accounts using "Welcome1" store the same hash; cracking it once reveals all 47 passwords simultaneously, multiplying the attacker's return per cracking computation.
Classification: Implementation attack. SHA-256 is a sound cryptographic algorithm โ but it is designed for speed (cryptographic agility, code signing, data integrity). For password storage, speed is a liability; an attacker benefits from the same speed. Using SHA-256 for passwords without salting is a deployment choice, not an algorithm flaw.
Remediation: (1) Replace SHA-256 with bcrypt (cost โฅ 12) or Argon2id โ algorithms designed to be computationally expensive per hash (~50ms per attempt vs. ~0.0001ms for SHA-256); this reduces GPU cracking from billions/second to thousands/second. (2) Add per-user random salting โ unique salt generated for each user, stored alongside the hash; identical passwords produce different hashes; rainbow tables are useless; batch cracking is eliminated โ each account must be attacked individually. Both controls are required together; bcrypt already includes internal salting, making it the single recommended choice for new implementations.