Refer to the Exhibit Practice Questions

The traffic is normal web browsing to a content delivery network.

Why wrong: Normal web browsing to a content delivery network would generate HTTP or HTTPS requests to standard ports (80/443) with visible GET/POST paths, and would show TCP handshakes and data transferred over those connections. The exhibit instead shows repeated DNS TXT queries, which are UDP-based DNS record lookups carrying no web session data. A CDN might legitimately serve content via HTTPS, but it would not explain the absence of any web requests and the exclusive use of DNS queries.

The issue is most likely ARP spoofing on the local switch port.

Why wrong: ARP spoofing operates at Layer 2, poisoning the IP-to-MAC mapping on a local switch port to redirect traffic to an attacker's machine, causing misrouted frames and MITM interception. It would produce duplicate IP/MAC bindings in the ARP cache and unusual ARP replies, but it would not cause the host to generate a continuous stream of DNS TXT queries at a predictable interval. The exhibit shows a stealthy DNS beacon pattern, which is unrelated to local Layer 2 address resolution issues.

The evidence most strongly indicates a password spraying campaign.

Why wrong: Password spraying involves an attacker trying a few common passwords against many user accounts across the network, which generates failed authentication events, account lockouts, and traffic to authentication services like LDAP, Kerberos, or web single sign-on portals. The exhibit contains no such authentication logs or login attempts; instead, it shows a single host emitting DNS TXT queries with unique subdomains on a regular schedule. This beaconing behavior indicates command-and-control or data exfiltration, not a brute-force credential attack.

Keep both roles assigned but require a manager to review the batch after payment completes.

Why wrong: Post-payment review is useful for detection, but it does not prevent the same person from creating and approving a fraudulent payment in the first place. The control happens too late to fully address the fraud risk described in the exhibit.

Remove the audit role and let payroll staff self-review their own work to save time.

Why wrong: Deleting the audit role eliminates the only independent check on payroll transactions, not just an efficiency step. Self-review is inherently biased because the person who created or modified records is unlikely to catch their own errors or intentional fraud, so the control becomes cosmetic. Without a separate reviewer, the organization also loses the audit trail needed to demonstrate accountability to regulators and external auditors, making the risk worse, not better.

Use a single shared payroll account so the workflow never pauses for approvals.

Why wrong: Using one shared payroll account collapses all individual identities into a single set of credentials, eliminating non-repudiation and making it impossible to determine who actually approved a payment. Even when the workflow technically includes an approval step, any of several users can act without personal accountability, so the control is bypassed in practice. This also violates least privilege and can obscure the attack source during incident investigation, increasing rather than reducing fraud risk.

Least privilege, because each employee should only have the fewest permissions needed for the shared account.

Why wrong: Least privilege is important, but the real issue is broader than simply reducing permissions. The problem is that one identity can complete the full payment workflow, which allows a single person to create, approve, and alter payment data. That concentration of power is what creates the fraud risk, so the better principle is separation of duties.

Need-to-know, because only employees with confidential financial data should see the workflow details.

Why wrong: Need-to-know limits access to information, not necessarily to the ability to complete an entire business transaction. The exhibit is about who can perform which finance actions, not who can read a report. Restricting data visibility may help privacy, but it does not address the fraud risk created by one account being able to execute every step.

Defense in depth, because the organization should add more security layers around the finance process.

Why wrong: Defense in depth means multiple layers of protection, such as logging, approvals, and monitoring. Those layers can help, but they do not specifically solve the core issue shown in the workflow. The exhibit reveals a role-concentration problem, where one identity can complete the entire process. That is precisely what separation of duties is designed to prevent.

Store the private key on the same backup server so recovery is faster.

Why wrong: Putting the private key on the same server creates a single point of failure and weakens key protection. If the server is lost, compromised, or destroyed, the organization may also lose the ability to decrypt the backup key material.

Replace AES with hashing so the archive no longer needs a key.

Why wrong: AES is a reversible symmetric encryption algorithm used to protect backup data, whereas hashing (e.g., SHA-256) is a one-way deterministic function. Replacing AES with hashing would make the archive irreversible; you could compute a digest but never recover the original data, so the backup becomes unrecoverable. Additionally, hashing provides integrity, not confidentiality, and it still requires secret inputs (like a pepper) or exposes data to offline attacks, so the premise that it eliminates key management is false.

Send the private key to backup operators by email so they can restore data quickly.

Why wrong: Email is an inherently insecure transport mechanism that involves multiple relays, server-side storage, and potential eavesdropping. Sending the private key to backup operators via email exposes the key to interception, forwarding, and unauthorized access, and it violates the principle of least privilege by distributing key material to individuals who only need access during specific recovery events. Because the private key controls the decryption of all AES-encrypted backup keys, a single email compromise could result in the loss of confidentiality of the entire backup archive, making this an unacceptable recovery method.

The invoice is confidential because the signature encrypts the document contents.

Why wrong: Digital signatures do not provide confidentiality by themselves. The document may still be readable to anyone who has access to it. The exhibit only shows the signature validated successfully, which speaks to trust and integrity, not secrecy.

The invoice can be edited if the timestamp is still within business hours.

Why wrong: A timestamp does not grant permission to modify a signed document. If the file were edited, the digest would no longer match the signature. The exhibit explicitly says the digest matches, which supports integrity, not a temporary editing window.

The sender’s private key is now public because the certificate verified successfully.

Why wrong: Verifying a certificate does not expose the sender’s private key. The private key remains protected and should never be made public. Successful verification only means the public certificate chain and signature were accepted as valid by the trust store.

Weak permissions, because the camera streams video to multiple ports.

Why wrong: Weak permissions concern incorrect access control lists on files, directories, or system objects, not the number of ports a service listens on. The exhibit shows network exposure: management and streaming services bound to 0.0.0.0 and firewall rules permitting connections from any source. That is a service-exposure problem, not a permissions misconfiguration. Streaming to multiple ports increases attack surface, but it does not demonstrate that file or object permissions are weak.

Default credentials, because the admin login is enabled.

Why wrong: An enabled administrative account is a standard configuration for initial device access and does not by itself prove that the password is still the factory default. Exploitation of default credentials requires evidence that the username and password match a known vendor default, such as admin/admin or root/12345. The exhibit only shows that the admin login is active, so concluding default credentials is an unsupported assumption. Without login configuration details or a known default credential string, the correct issue remains the exposed network service.

Outdated component, because firmware version 1.0.3 is listed.

Why wrong: A firmware version such as 1.0.3 is simply an identifier; without a vendor advisory, CVE, or a published list of known-vulnerable releases, you cannot claim it is outdated. A lower version number does not automatically mean a security risk—the device might have no disclosed vulnerabilities or may be patched through another mechanism. The exhibit's evidence points to an exposure issue (services on 0.0.0.0 and permissive ACLs), not to a component version risk. The mere presence of a version number does not support a finding of outdated components.

Preventive controls, because they stop every possible compromise completely.

Why wrong: The measures do reduce risk, but they do not eliminate all compromise paths and are not being used in the normal ideal way. The important clue is that the primary security requirements cannot be met on the device itself, so alternate controls are used instead.

Corrective controls, because they repair the controller after an incident occurs.

Why wrong: Corrective controls address damage after a security event or restore systems to a secure state. The exhibit describes measures already put in place before an incident to reduce exposure. That makes them compensating, not corrective, controls.

Deterrent controls, because they mainly scare attackers away from trying.

Why wrong: Deterrent controls discourage attacks, such as visible signage or warning banners. The exhibit contains concrete technical and procedural restrictions that limit access and increase visibility. Those measures do more than discourage; they compensate for missing native protections.

Return the workstation to the user since the outbound connection was blocked.

Why wrong: Blocking one outbound connection does not remove persistence or confirm the system is clean. The exhibit shows script-based activity and a scheduled task, both of which can remain active even after network containment. Returning the device now would risk reinfection or continued compromise.

Delete only the scheduled task and reconnect the host to monitor for more alerts.

Why wrong: Removing one artifact is too narrow when the evidence suggests a broader compromise. The PowerShell payload created a script file and a scheduled task, so there may be additional persistence, credential theft, or payload changes. Reconnecting the host early increases the chance of further impact.

Close the incident because memory capture has already preserved the evidence.

Why wrong: Preserving evidence is only one step in the process. The team still needs eradication and recovery actions before the incident can be closed. The host remains compromised until the malicious code and persistence mechanisms are removed and exposed credentials are addressed.

Geofencing

Why wrong: Geofencing enforces access decisions by comparing the source IP address's geolocation against a static allow/deny boundary, either blocking or permitting the login attempt at that instant. It does not store or analyze historical login patterns, so the preceding failed attempts are completely irrelevant to its decision. Moreover, geofencing can be easily bypassed through VPNs, proxy servers, or cloud-based remote desktops that make an attacker's traffic appear to originate from an allowed region, leaving the anomalous behavior entirely undetected.

Account lockout policy

Why wrong: Account lockout policies are a preventive control that increments an authentication-failure counter and disables the account after a fixed threshold, such as five failed attempts. They have no awareness of a subsequent successful login unless the account is actually locked, and attackers can frequently evade the threshold by spacing out their attempts over a long period. Because the policy lacks any concept of geographic origin or event sequencing, a successful login from a new country after a burst of failures will appear perfectly normal once valid credentials are supplied.

SIEM correlation rules

Why wrong: SIEM correlation rules can combine events from multiple sources, but they rely on predefined logic. While they could be configured to detect this pattern, they are less adaptable to novel or subtle anomalies than UBA, which uses behavioral baselines and machine learning.

Send the same annual awareness slide deck to everyone again without changing the content.

Why wrong: Sending the same annual awareness slide deck to everyone again without changing the content will not resolve the behavioral gaps highlighted in the exhibit. The data shows that executives and customer support have disproportionately high click rates and near-zero reporting rates, which generic, annual, static content fails to address. Repeated, unchanged material leads to habituation and offers no practice or reinforcement, so it is an ineffective awareness action.

Block all external email so users cannot click suspicious messages.

Why wrong: Blocking all external email is an excessively restrictive technical control that would severely disrupt business operations and legitimate communication. Even if it were implemented, it would not address the underlying awareness deficit because attackers can pivot to other vectors like internal phishing, compromised accounts, or web-based lures, and it provides no training on how to identify or report suspicious messages. Security awareness requires enabling users to make good decisions, not isolating them from all external contact.

Take no action because IT already reports suspicious messages well.

Why wrong: Taking no action because IT already reports suspicious messages well is a dangerous assumption, as the exhibit shows that other departments, particularly executives and customer support, have very low report rates. The overall security posture depends on every employee, not just IT, because attacks target all users, and a single high-performing group does not mitigate the risk posed by groups with weak detection and reporting behavior. Ignoring the exhibit's evidence of poor performance in other groups leaves the organization vulnerable to phishing and business email compromise.

Install the same certificate on every client so the browser warning is suppressed.

Why wrong: Installing the same certificate on every client will not suppress the browsing warning because the warning is triggered by a hostname mismatch between the certificate's Subject/SAN and the requested domain (pay.example.net). Client-side trust stores only determine which Certificate Authorities are accepted; they do not override hostname verification for the server's certificate. Moreover, distributing the certificate's private key to every client is a severe security risk, as any recipient could impersonate the server, and it creates an unmanageable key-distribution and revocation problem across all endpoints.

Disable certificate name checking in the browser until the certificate expires.

Why wrong: Disabling certificate name checking bypasses the browser’s Subject Alternative Name (SAN) validation, which would allow the portal’s certificate to match any domain, defeating the purpose of certificate validation entirely. This is tempting because name mismatches are a common cause of browser warnings, and disabling the check would suppress the alert without replacing the misconfigured certificate. In a controlled lab environment where a self-signed certificate is used for testing, disabling name checking can be a temporary workaround, but it is never a secure remediation for a production payment portal.

Replace TLS with a shared symmetric key configured on the web server and all users.

Why wrong: Replacing TLS with a shared symmetric key configured on the web server and all users is impractical and insecure for a public payment portal. Distributing a single shared secret to every user is logistically impossible without a secure out-of-band channel, and any compromise of that key would allow an attacker to decrypt all traffic or impersonate the server. Symmetric-key systems lack authentication of the server's identity, non-repudiation, and the scalability of a PKI; they provide no way to establish trust or revoke individual users' access, which is why they cannot replace certificate-based TLS for public-facing services.

Provide the export because the requester is a manager with a legitimate business relationship to employees.

Why wrong: Manager status alone does not confer an entitlement to export PII under role-based access control; the privacy notice explicitly limits home addresses and personal phone numbers to HR and payroll processing. A legitimate business relationship only establishes a reason to communicate, not a lawful basis to access sensitive personal data outside the stated purpose. The correct action is to deny the unreserved export and steer the requester toward the approved work-contact list or an official privacy review.

Send the data to the manager if the manager promises not to share it externally.

Why wrong: A verbal promise not to share externally is not an enforceable data governance control and leaves no audit trail; the manager’s informal assurance does not constitute the required legal basis under data-processing policy. The purpose limitation in the exhibit still applies, so the export would be a prohibited secondary use regardless of confidentiality assurances. Approved mechanisms such as a signed internal data-usage agreement or a formal privacy review are the only acceptable paths to access this protected data.

Store the export in a shared drive so multiple teams can use it for convenience.

Why wrong: Persisting the export to a shared drive would expand access beyond the individuals with a need-to-know and violate the least-privilege principle, as shared drives often have broad team-wide ACLs and lack role-based scoping. Data minimization requires that personal data be accessible only to specifically authorized personnel, not to any team that finds it convenient. Additionally, storing records outside the authoritative HR/payroll system undermines the organization’s ability to enforce retention, consent, and breach-notification obligations.

DNSSEC, because it validates DNS records and would stop local address-to-MAC spoofing.

Why wrong: DNSSEC protects DNS data integrity, but this incident is about forged ARP replies on a local subnet. ARP operates below DNS and is used to resolve IP addresses to MAC addresses. DNSSEC would not stop the bad ARP mappings shown in the capture.

Port forwarding, because it can direct traffic to the correct internal host more reliably.

Why wrong: Port forwarding is a routing or NAT convenience mechanism, not a protection against forged Layer 2 address resolution. The problem here is that clients are learning a fake MAC address for the gateway. Forwarding does not validate ARP or stop spoofed replies.

Load balancing, because it would distribute traffic and reduce the impact of connectivity issues.

Why wrong: Load balancing improves availability for services, but it does not detect or prevent ARP poisoning on a local broadcast domain. The exhibit shows hosts being tricked into using the wrong MAC address, which must be addressed with a Layer 2 security control.

Worm

Why wrong: A worm is a self-contained malicious program that replicates and spreads to other systems automatically, typically by exploiting network services, email, or removable media. The exhibit depicts a scheduled task that launches a destructive script only when a specific date and username match, with no apparent propagation or network-spreading functionality. Since the artifact lacks any self-replication or lateral movement mechanism, it does not qualify as worm behavior.

Spyware

Why wrong: Spyware is designed to covertly monitor user activity and collect sensitive data such as keystrokes, browsing habits, credentials, or screen captures, usually for exfiltration to an attacker. The exhibited script is instead a destructive payload that deletes user files once its logical trigger conditions are met; there is no indication of data gathering, keystroke logging, or a communication channel to transmit stolen information. Thus, the behavior aligns with a logic bomb rather than spyware.

Rootkit

Why wrong: A rootkit is a stealth mechanism that provides an attacker with continued privileged access by hiding files, processes, or registry keys, often by hooking or patching operating system internals. The evidence in the exhibit focuses on a timing- and username-based condition that, when satisfied, deletes files—not on concealment of malicious artifacts or escalation of privilege. While a logic bomb can be combined with rootkit techniques, the exhibit's trigger-based destruction is the defining characteristic, so rootkit is not the most likely classification.

Bluetooth pairing abuse

Why wrong: Bluetooth pairing abuse exploits the short-range Bluetooth radio stack (typically ~10 meters) and involves pairing procedures like PIN/Passkey, Just Works, or Numeric Comparison. The exhibit shows two Wi-Fi access points broadcasting the same SSID, one with stronger signal and a suspicious captive portal — this is LAN-layer behavior, not Bluetooth. Bluetooth threats such as Bluejacking, Bluesnarfing, or BlueBorne do not create duplicate SSIDs or trigger web-based login portals. An attacker performing Bluetooth attacks would need to pair with a victim device, not spoof a network to lure connections.

NFC skimming

Why wrong: NFC skimming is a proximity attack that targets near-field communication, which operates at less than 4 cm and is used for contactless payments, badges, or device pairing. Skimming typically involves an attacker placing an NFC reader near a victim's card or phone to harvest data passively. The evidence here involves wireless network access (SSIDs and a captive portal), which is a completely different OSI layer and range. NFC skimming would not involve broadcasting an SSID or serving a login page, and it requires the attacker to be physically closer than the exhibit implies.

DNS poisoning

Why wrong: DNS poisoning corrupts the domain-name resolution system so that a legitimate hostname resolves to a malicious IP address, often achieved by injecting fake DNS records or compromising a DNS server. The exhibit shows two access points with the same SSID and a suspicious captive portal — that is a Layer 2/3 access-control issue, not a name-resolution failure. There is no evidence of modified DNS records, poisoned cache, or unusual IP resolution. Even though an evil twin could later be used to perform DNS redirection, the immediate indicator is the rogue AP and captive portal, not DNS manipulation.