Threats, Vulnerabilities, and Mitigations practice questions

Credential stuffing

Why wrong: Correct. Credential stuffing leverages lists of known username/password pairs from previous breaches. The analyst observed many failed attempts from one source IP, then a successful login, which matches an attacker testing stolen credentials. Even with MFA, the attack may succeed if the attacker has obtained session tokens or uses other techniques.

Password spraying

Why wrong: Incorrect. Password spraying uses a few common passwords against many accounts. The pattern here shows many failed attempts for the same username before a success, which is more indicative of credential testing rather than spraying a single password.

Shoulder surfing

Why wrong: Shoulder surfing is a physical, in-person technique where an attacker observes a user entering credentials, which would never appear as remote authentication log entries from a single IP address. It also does not produce failed login attempts, because the attacker simply watches and later uses the captured credentials without guessing. Since the logs show network-based attempts and a successful login after failures, this is an online automated attack, not an observation-based method.

Phishing

Why wrong: Phishing is a social engineering attack that uses deceptive emails and malicious attachments to trick recipients into executing malware or revealing sensitive information. The typo-squatted sender address and executable attachment are classic indicators of a phishing attempt.

Smishing

Why wrong: Smishing, a portmanteau of SMS and phishing, leverages text messages on mobile devices to lure victims into clicking malicious links or sending personal information. The incident here is detected by email security, and the threat is an attached executable file, not an SMS-delivered link or request. Because the attack does not use Short Message Service or any mobile messaging channel, smishing is not an applicable label.

Vishing

Why wrong: Vishing, or voice phishing, is an attack that relies on telephone calls, VoIP, or voicemail to trick victims into divulging sensitive data or performing actions. The alert in this scenario comes from email security and involves an executable attachment delivered as an email, meaning no voice channel is used. Since the delivery vector is entirely email-based, vishing cannot be the correct classification.

Increase the maximum upload size so the application can handle more files.

Why wrong: Larger file limits do not stop path traversal or malicious filename manipulation. That change addresses capacity, not input validation. In some cases it could even make abuse worse by allowing larger malicious payloads to be uploaded.

Add browser-side JavaScript validation to reject suspicious filenames.

Why wrong: Client-side validation improves user experience, but it is easily bypassed by modifying the request. Attackers do not rely on the browser interface, so server-side validation is still required. This control helps usability, not real security enforcement.

Hide detailed error messages from end users only.

Why wrong: Reducing error detail can limit information leakage, but it does not stop traversal attempts. The application would still be vulnerable if it accepts and processes unsafe paths. Error handling is useful, but it is not the main fix for the flaw shown.

Restore the server from backup before taking any containment action.

Why wrong: Restoring too early can overwrite evidence and may reintroduce the malware if the restoration source is not verified. Backups matter, but containment comes first when the compromise is still active. The environment must be stabilized before recovery begins.

Delete the suspicious files from the server to stop the encryption process.

Why wrong: Manually deleting files is risky and can destroy evidence without reliably stopping the malware. If the process is still active, the attacker may continue through other paths or credentials. Removing files is not the preferred first containment step when the host is still communicating internally.

Inform users that the incident is likely a false positive and continue monitoring.

Why wrong: The observed behaviors are consistent with active malicious activity, not a harmless alert. Continuing to monitor without containment allows additional damage and possible spread. This would be an operationally unsafe response given the encryption, shadow-copy deletion, and internal SMB activity.

A low-severity finding on an internal test server with no network access

Why wrong: An isolated low-severity issue is less urgent than a critical flaw exposed to the internet.

A cosmetic configuration warning on a printer management interface

Why wrong: A cosmetic warning is not as urgent as a critical vulnerability on a remote-access device.

A medium-severity issue on a device that is powered off and not in service

Why wrong: A powered-off, unused device presents far less immediate risk than a live internet-facing appliance.

Internal print server on an isolated VLAN with no known exploit and no sensitive data.

Why wrong: Although the CVSS score is high, the asset is isolated, has no known exploit activity, and does not store sensitive data. That lowers immediate business and attack-path risk compared with externally reachable or actively exploited systems. It should still be remediated, but not before higher-impact findings.

Lab hypervisor that is scheduled for retirement next month and used only by testers.

Why wrong: A planned retirement and limited lab use reduce the urgency, especially if there is no known active exploit. The issue should be tracked, but the short remaining lifespan and constrained exposure make it less urgent than internet-facing or actively exploited production assets.

Development wiki with low severity, no exploit, and no sensitive data.

Why wrong: This is the lowest-risk item in the list because it has limited exposure and minimal business impact if compromised. It may still deserve remediation during normal maintenance, but it should not outrank systems with public exploit code, active exploitation, or regulated data.

The current domain name used by the command-and-control server.

Why wrong: The scenario says the domain rotates daily, so it is a poor long-term indicator. It may be useful for temporary blocking, but it is not the most durable clue. Attackers expect defenders to burn these indicators quickly and replace them often.

The public IP address currently hosting the malware sample.

Why wrong: Infrastructure IPs can change quickly, especially when adversaries use disposable hosting or fast-flux style setups. This indicator may help short-term blocking, but it is not dependable for long-term hunting. Behavioral and family-specific artifacts are more resilient for this campaign.

Baiting

Why wrong: Baiting is a social engineering technique that lures a victim with a tempting offer such as a free USB drive, movie download, or prize, often to deploy malware or physically compromise a system. Unlike smishing or vishing, baiting does not typically rely on direct credential requests or urgent impersonation. Instead, it exploits human curiosity or greed, and the payload is often a malicious file or infected device rather than a conversation. The described text message and phone call are purely remote, interactive, and focused on obtaining authentication data, not on tricking the user into taking a physical or download action, so baiting is not the correct classification.

Whaling

Why wrong: Whaling is a spear-phishing attack that specifically targets high-ranking executives, such as CEOs or CFOs, due to their elevated access and authority for financial transactions. The scenario describes an employee who is likely a regular target rather than a C-level executive, so it lacks the victim profiling that defines whaling. While the attack uses similar phishing techniques, whaling often involves more extensive reconnaissance, business-like pretexts, and requests for wire transfers or confidential corporate data. Since there is no evidence of executive targeting, this incident is better classified as standard smishing followed by vishing.

Tailgating

Why wrong: Tailgating, also known as piggybacking, is a physical security attack where an unauthorized person follows an authorized employee into a restricted area, often by taking advantage of the employee's courtesy. This technique requires close physical presence at a secured door, turnstile, or access-controlled entrance. The scenario in question involves no physical proximity or access control bypass; it is an entirely remote interaction using a text message and phone call. Tailgating does not involve requesting one-time codes or impersonating IT over a communication channel, making it distinct from the described social engineering chain.

A missing screen-lock timeout on nearby laptops

Why wrong: A missing screen-lock timeout on nearby laptops is a valid physical-hardening issue, but it requires an attacker to have local access to an unattended laptop in the same physical area as the business. It does not explain how a remote attacker from anywhere on the internet could reach and compromise the web server, nor does it have any connection to the server's exposed management interfaces or default administrative password.

A lack of encrypted email attachments

Why wrong: A lack of encrypted email attachments is a confidentiality issue that affects messages transmitted between mail servers and clients, but it has no relation to how the web server is remotely administered. Even if email encryption were fully implemented, an attacker could still exploit the exposed remote administration service and default credentials to take over the server, so this option does not address the actual reported vulnerability.

An outdated printer driver on the finance network

Why wrong: An outdated printer driver on the finance network is an endpoint-level issue that might cause printing errors or local privilege escalation on a user's workstation, but it does not create any externally reachable attack path to the web server. The printer driver is on a separate network segment and has no bearing on the internet-exposed administrative service or the use of default credentials, so it is entirely unrelated to the server compromise described.

Pretexting, because the attacker is impersonating a trusted vendor to create a believable reason for the request.

Why wrong: Pretexting is the best fit because the attacker builds a believable story around a trusted vendor relationship and asks for a sensitive business action. The value is in the fabricated scenario, not just the delivery channel. The realistic invoice details and urgency support the pretext, which is a common pattern in payment-change scams and business email compromise.

Smishing, because the attacker is using a text message to reach the victim.

Why wrong: Smishing is specifically a social engineering attack delivered via SMS or a messaging application, not via email. Since the scenario explicitly describes an email-based communication, the channel does not match smishing's definition. Although the content may be deceptive, classification depends on the medium used; an email-based attack can be phishing or pretexting but not smishing.

Baiting, because the attacker is offering a portal link that appears helpful to the recipient.

Why wrong: Baiting relies on offering an enticing lure—such as free media, a download, or a physical device—to trigger a security-compromising action. In this case, the attacker is not providing a desirable reward but is impersonating a trusted vendor and constructing a fabricated payment-change story. The portal link, if mentioned, would be a mechanism to carry out the deception, but the primary technique is the false pretext, not the attraction of bait.

Immediately accept the risk and leave the server unchanged

Why wrong: Accepting the risk without first validating exploitability, exposure, or business impact is a governance failure. Formal risk acceptance requires a documented decision by the system owner, a clear rationale, a defined review date, and acknowledgment of residual risk. Immediate acceptance because the scanner labels the issue critical bypasses the required triage process and may violate organizational risk tolerance or compliance mandates.

Mark the finding as a false positive and close the ticket

Why wrong: Calling the finding a false positive is premature because the vulnerable package or function is confirmed present; the scanner's detection is not inherently inaccurate. A false positive would mean the version is patched, the test result is invalid, or the software is not actually vulnerable. Unreachability reduces severity but does not make the finding false, so closing the ticket without deeper validation overlooks residual risk and skips required verification.

Remove the server from production immediately and rebuild it from scratch

Why wrong: Immediately rebuilding from scratch is disproportionate without evidence of active exploitation or a clear compromise indicator. Emergency removal introduces significant availability and integrity risk itself, potentially causing more damage than the uncovered vulnerability. A more calculated response is to isolate the server or enable a temporary control, then schedule the rebuild under change management with proper backup and testing.

Finding B

Why wrong: Finding B has a high score, but it requires local access and sits on an internal lab VLAN with no network path.

Finding C

Why wrong: Finding C affects a file server, but the compensating ACL limits exposure and the issue requires authenticated access.

Finding D

Why wrong: Finding D is concerning, but the vendor states the flaw is currently unreachable from the network and there is no patch yet.

DNS amplification, which overwhelms the target with reflected DNS traffic

Why wrong: DNS amplification is a DDoS attack that exploits publicly accessible open DNS resolvers; the attacker sends tiny DNS queries with a spoofed source IP (the victim), and each resolver replies with a large DNS response, multiplying traffic up to 100x and flooding the victim's link. It operates entirely over UDP/port 53 and involves no layer-2 address translation, nor does it require the attacker to be on the same subnet as the victims. The only symptom would be network saturation, not the local gateway MAC being replaced in every user's ARP table.

Replay attack, which resends captured authentication data

Why wrong: A replay attack focuses on reusing captured authentication material, such as a session cookie, Kerberos ticket, or a signed challenge-response tuple, to trick a server into thinking the attacker is the legitimate user. It is an application- or authentication-protocol-level attack that does not touch the ARP cache nor manipulate the addressing used by the local Ethernet LAN. Even if a valid authentication token were replayed, it would give the attacker access to one specific service, not cause all internet-bound traffic from a subnet to be silently diverted to the attacker.

Port scanning, which probes hosts for open services and ports

Why wrong: Port scanning is a reconnaissance method that sends crafted packets to a target host's TCP/UDP ports to determine which services are listening, often as a prelude to exploitation. Although the scanner may be on the same subnet, the probes are addressed directly to the target host and elicit response from that host, so they do not broadcast or alter the IP-to-MAC mappings held by other hosts. The described outage—all users losing gateway reachability and traffic being intercepted—cannot be explained by a process that simply enumerates open ports.

SQL injection is present because the customerId value changes in the URL.

Why wrong: A parameter changing from one integer to another does not by itself indicate SQL injection. SQL injection would require evidence that the application is interpreting malicious SQL syntax, such as quotes, comments, or database error behavior. Here, the clue is unauthorized object access, not database query manipulation.

Cross-site scripting is present because the invoice data is returned in the browser.

Why wrong: Receiving another user's invoice in the browser is not evidence of script injection. Cross-site scripting requires malicious script execution in a victim's browser context. The scenario describes unauthorized data disclosure through an identifier change, which is an access-control problem rather than a content-injection issue.

Insecure deserialization is present because the request uses JSON-like parameters.

Why wrong: The presence of request parameters or JSON formatting does not imply insecure deserialization. That weakness involves tampering with serialized objects or object state during parsing. The scenario provides no evidence of object deserialization, integrity bypass, or gadget-chain exploitation.

A SYN flood is exhausting the DHCP service.

Why wrong: A SYN flood targets TCP connection handling and would be visible as many incomplete handshakes, not as unauthorized DHCP leases or altered DNS responses. DHCP is a separate protocol, and the symptoms described are about address assignment and name resolution, not session exhaustion on a TCP listener.

A port scan is enumerating exposed services on the branch subnet.

Why wrong: Port scanning typically creates many connection attempts across a range of ports or hosts. It does not explain clients getting bad DHCP offers or DNS answers from a suspicious device. The issue here is identity and resolution of network services, not service enumeration.

Password spraying is attempting many logins with common passwords.

Why wrong: Password spraying affects authentication logs, usually across identity providers, VPNs, or SaaS platforms. It has no direct relationship to DHCP leases or DNS replies. Those protocols are involved in network configuration and naming, so password spraying is not the best explanation for this evidence.

The message was transmitted over TLS to the recipient's mail gateway.

Why wrong: TLS only protects message transport between mail systems. It does not validate the sender's identity, the message content, or the destination links. Phishing campaigns commonly use TLS, so this detail is operationally normal and does not reduce the risk by itself.

The email contains a PDF invoice attachment with a normal business filename.

Why wrong: A PDF attachment and a routine filename are both common in legitimate business communication. While attachments should always be handled carefully, this detail alone does not prove malicious intent. Attackers can use any file type, so the file name is weak evidence compared with sender and domain inconsistencies.

The message includes the supplier's logo and a standard-looking signature block.

Why wrong: Logos and signature blocks are easy for attackers to copy from public websites or previous emails. Those elements can make a message look authentic, but they do not verify identity. Security reviewers should treat branding as cosmetic evidence and focus instead on sender, reply-to, and link destination details.

The email signature includes the company logo and a professional font.

Why wrong: The presence of a company logo and professional font in the email signature is not a valid security indicator because these elements are trivial to copy from any legitimate email or website. Email clients render HTML and embedded images from the message body, and an attacker can replicate exact branding without any technical authentication—logos do not verify the sender's identity. Unlike sender authentication methods such as SPF, DKIM, or DMARC, visual formatting provides no cryptographic proof, so it cannot be used to declare an email safe.

The message was delivered during normal business hours.

Why wrong: Delivery during normal business hours is a timing artifact, not a security feature, and it has no correlation with the legitimacy of the sender. Phishing campaigns are often scheduled automatically and can target employees when they are most likely to read email—typically during work hours—so attackers deliberately time their messages for maximum impact. Additionally, email servers can delay delivery due to queueing or retry logic, meaning a received timestamp does not reliably indicate when the attacker sent the message or their intent.

The subject line includes the employee's department name.

Why wrong: Including the employee's department name in the subject line can be a sign of personalization, but modern attackers gather such information from public sources like LinkedIn, corporate websites, or previous data breaches. This personalization is a form of social proof or tailgating, not a technical verification of authenticity, because the attacker can easily insert any known detail into the subject or body. A legitimate internal email might use department names, but spoofed display names and content personalization are not enough by themselves to confirm the message is safe—other indicators must be considered.

Implementing a strict clean desk policy

Why wrong: A clean desk policy is a physical security control that reduces the risk of unauthorized access to sensitive documents left in the open, but it does not mitigate the psychological manipulation techniques central to social engineering. Social engineers exploit human trust, urgency, and authority rather than relying on physical information leakage, so this control has negligible effect on phishing, pretexting, or vishing attacks. While it supports overall confidentiality, it is not a direct countermeasure against social engineering.

Installing physical barriers at building entrances

Why wrong: Physical barriers such as fences, mantraps, and bollards control physical access to buildings and secure areas, but they are ineffective against social engineering, which primarily occurs through digital communication or social interaction. Attackers can easily use phone calls, emails, or impersonation to manipulate employees without ever entering a facility. Even tailgating, a physical vector, is better mitigated by security guards and access control policies than by static barriers. Thus, this control does not address the psychological elements of social engineering.

Disabling USB ports on all workstations

Why wrong: Disabling USB ports is a technical measure that can prevent two specific social engineering attacks: baiting, where an attacker leaves a malicious USB drive for a target, and some forms of precursor access. However, it does nothing to stop phishing, vishing, pretexting, or other manipulation methods that constitute the majority of social engineering incidents. Additionally, it can hamper legitimate productivity and may be circumvented through wireless means. This control is too narrow and is not a primary mitigation for social engineering.

LDAP injection

Why wrong: LDAP injection exploits vulnerabilities in applications that build LDAP filters from user input without proper sanitization, using constructs like `(&(uid=user)(userPassword=pass))` or wildcard `*` to bypass authentication. The observed payloads (`OR '1'='1'`, `DROP TABLE`) are structured for SQL's WHERE-clause logic, not for LDAP filter syntax, which relies on parentheses, ampersands, and pipe characters (e.g., `(|(cn=...)(uid=...))`). Hence, the attack targets a SQL backend, not an LDAP directory.

Command injection

Why wrong: Command injection is an attack where an attacker manipulates user-supplied input to execute arbitrary operating system commands on the host server by injecting shell metacharacters such as `;`, `|`, `&&`, or backticks. The log entries show SQL-specific syntax, not these command separators or OS command names (e.g., `cat`, `ls`, `whoami`). Therefore, this activity is not indicative of command injection.

Cross-site scripting (XSS)

Why wrong: Cross-site scripting (XSS) occurs when an attacker injects malicious client-side scripts, such as JavaScript, into web pages that are then executed in the browsers of other users. The observed log entries contain SQL keywords and operators like `OR '1'='1'` and `DROP TABLE`, rather than script tags, event handlers, or payloads like `<script>alert(1)</script>`, which would be expected for XSS. Thus, the attack pattern does not match XSS.

Transport Layer Security (TLS)

Why wrong: Transport Layer Security (TLS) is incorrect because it secures data only while it is in transit over a network, using encryption and integrity checks to prevent eavesdropping or tampering between client and server. It does not inspect or modify application behavior at runtime, and it has no mechanism to detect or prevent a buffer overflow, which is a memory corruption flaw that occurs when a program writes beyond the bounds of an allocated buffer in its own address space. TLS operates at the session/presentation layer of the OSI model, whereas buffer overflows are exploited at the process memory level, so TLS is completely orthogonal to this type of vulnerability.

Code signing

Why wrong: Code signing is incorrect because it is a static assurance mechanism that verifies the authenticity and integrity of the software binary via a digital signature, confirming that the code was signed by a trusted publisher and has not been altered since signing. However, it provides no runtime protection; once the signed executable is loaded into memory and executing, the CPU and OS do not perform any additional checks based on the signature to prevent memory corruption. A stack-based buffer overflow occurs during program execution due to a failure to validate input length, and code signing cannot detect or block that runtime event because it is not an active defensive control like a stack canary that protects the stack at runtime.

Data Execution Prevention (DEP)

Why wrong: Incorrect. DEP makes memory regions non-executable, which can prevent direct execution of injected shellcode. However, sophisticated attackers can bypass DEP using return-oriented programming (ROP). Stack canaries are generally more effective for detecting the overflow itself, even when DEP is present.