Select Two (Multi-Select) Questions

Upload the file to a public link and send the URL by email

Why wrong: A public link makes the file easier to access, but it also greatly increases the chance of unauthorized disclosure.

Rename the file to a less obvious name and send it normally

Why wrong: Renaming the file does not protect the contents, so sensitive data is still exposed during transmission and storage.

Save the file locally on a USB drive and hand-deliver it

Why wrong: Physical delivery may seem controlled, but it adds handling risk and does not remove unneeded sensitive data from the file.

Mount the drive read/write so hidden files are easier to access

Why wrong: Read/write mounting can alter evidence and defeats the purpose of forensic acquisition.

Defragment the drive first to improve imaging speed

Why wrong: Defragmentation changes the evidence and is inappropriate before imaging.

Install triage tools directly on the suspect laptop

Why wrong: Installing tools on the suspect system modifies it and can contaminate evidence.

Let all corporate laptops connect directly to SSH on the servers if MFA is enabled.

Why wrong: MFA is useful, but direct access from every corporate laptop still expands the attack surface and makes lateral movement much easier after an endpoint compromise. The scenario explicitly asks to stop direct management access and reduce spread, so a central jump path is better than broad direct reachability.

Expose SSH to the internet because key-based authentication is already strong.

Why wrong: Publicly exposing SSH is unnecessary and increases brute-force, scanning, and exploitation risk. Key-based authentication helps, but it does not justify direct internet access to management services. The requirement is to remove direct access from employee laptops, not extend management services to untrusted networks.

Use split tunneling for admin traffic so management packets can bypass the VPN.

Why wrong: Split tunneling is generally used to route some traffic outside the secure tunnel, which is the opposite of what this scenario needs. Management traffic should be tightly controlled and inspected, not routed around security controls. Bypassing the VPN would weaken the protected management path.

Allow users to install any app if they promise not to open work files.

Why wrong: User promises are not technical enforcement. Unrestricted app installation increases the chance of malware, data leakage, and policy violations on the device.

Store corporate files in the personal photo gallery for easier backup.

Why wrong: Mixing corporate data with personal storage defeats separation and makes selective wipe impossible. It also increases the chance of unintended sharing through consumer apps.

Disable screen locks so users can access business apps faster.

Why wrong: Disabling screen locks lowers device security and increases the risk of unauthorized access. Fast access is not worth sacrificing basic protection on mobile devices.

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.

Send the full employee record set because the contractor is trusted.

Why wrong: Trust does not remove privacy obligations. Sharing more data than needed increases risk and violates the principle of least data exposure.

Upload the file to a public collaboration site so the contractor can retrieve it easily.

Why wrong: A public site would expose the file broadly and undermine both confidentiality and privacy. It is not an acceptable handling method for employee records.

Keep an unrestricted copy on multiple shared drives for convenience.

Why wrong: Extra copies increase the chance of unauthorized access, retention problems, and accidental leakage. Convenience is not a valid reason to weaken handling controls for sensitive data.

Delete the scheduled task immediately so the host returns to normal operation.

Why wrong: Deleting artifacts too early can destroy evidence and does not guarantee the malware is removed. It may also cause the attacker to react or trigger secondary payloads. Containment and collection should come before destructive cleanup.

Reimage the workstation from the golden image as the first response.

Why wrong: Reimaging is a remediation step, but it is too early if the team still needs evidence and scope. It can wipe useful traces of execution, persistence, and command-and-control activity before they are preserved.

Ignore the alert because the PowerShell binary is built into Windows and therefore safe.

Why wrong: Built-in tools are often abused by attackers, so the mere presence of PowerShell does not make the event benign. The suspicious execution chain and beaconing behavior require investigation and containment, not dismissal.

Spooler service logs, because mshta.exe commonly prints documents before starting network activity.

Why wrong: Spooler logs are not a useful source for confirming script execution or beaconing. Printing activity is unrelated to the observed process chain and external communications in this case.

RAID controller logs, because they show whether the workstation’s storage hardware is failing.

Why wrong: RAID logs are only relevant to disk or array health. They do not help identify the execution path, scheduled task creation, or suspicious internet traffic from the endpoint.

NTP synchronization logs, because time drift is the most likely cause of the alert.

Why wrong: Time synchronization problems can affect investigations, but they do not explain malicious process launches or outbound beaconing. They are a lower-priority support check, not the best telemetry for this alert.

Create separate local usernames and passwords in each application for every employee.

Why wrong: This increases password sprawl and makes offboarding slower across multiple systems.

Store passwords in a shared vault and let users retrieve them when needed.

Why wrong: A shared vault does not eliminate password reuse and introduces unnecessary credential exposure risk.

Allow the mobile app to authenticate only from remembered devices, without central identity controls.

Why wrong: Device remembering may improve convenience, but it does not provide central identity governance.

Allow rooted devices if the antivirus app is current.

Why wrong: Rooted devices weaken platform trust and can bypass many mobile security controls.

Place all apps in one shared profile and use a single passcode for every user.

Why wrong: Shared profiles blur data boundaries and make selective wipe and accountability much harder.

Disable remote wipe so personal photos are never affected.

Why wrong: Disabling remote wipe prevents the organization from responding effectively to lost or compromised devices.

Finding 2, because any default setting should always outrank all other issues automatically.

Why wrong: Default settings matter, but this wiki is low impact and low exploitability compared with more critical findings.

Finding 5, because any outdated software should be fixed before higher-impact business systems.

Why wrong: The lab VM is isolated and has low business impact, so it should not outrank critical exposure points.

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.

Give each container a public IP and restrict access by source IP allowlist.

Why wrong: Source IP filtering may reduce exposure, but public IPs still make the service broadly addressable and easier to scan or attack. The scenario explicitly says the service must be reachable only by internal applications, so keeping it private is a better architectural choice than relying on external allowlists alone.

Bake database passwords into the container image so deployment is simpler.

Why wrong: Embedding secrets in an image is risky because the image may be copied, cached, scanned, or retained long after deployment. Anyone with access to the image can potentially extract the password. Simplicity does not outweigh the security and lifecycle problems created by hardcoded credentials.

Assume the cloud provider's tenant isolation alone is enough to protect secrets from misuse.

Why wrong: Tenant isolation protects one customer from another, but it does not solve application-level secret handling or misuse by authorized insiders. The scenario requires the secrets not be readable in plaintext from the host or image, which calls for explicit secret management and permission controls, not trust in isolation alone.

Reimage the workstation immediately before collecting evidence.

Why wrong: Reimaging too soon can destroy evidence that may be needed in the investigation.

Tell the user to keep working until tomorrow.

Why wrong: Telling the user to keep working leaves the threat active and exposed.

Delete recent logs to reduce noise.

Why wrong: Deleting logs removes clues and makes later investigation much harder for responders.

Turn off logging to preserve disk space.

Why wrong: Turning off logging would hide malicious activity and make investigation far harder. It may free space, but it directly weakens detection and response capabilities.

Allow unrestricted browser extension installs.

Why wrong: Unrestricted extensions widen the attack surface and create another path for malicious code. This makes the workstation less secure, not more hardened.

Merge all developer and production systems into one VLAN.

Why wrong: A flat network increases lateral movement opportunities and undermines containment. It is the opposite of a secure baseline and defense-in-depth design.

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.

Immediately shut down the portal until the dependency risk is completely eliminated.

Why wrong: Shutting the portal down is a form of risk avoidance, which conflicts with leadership's stated desire to keep the service available. It may be appropriate in some high-risk situations, but it does not fit this scenario's requirement to continue operations.

Ignore the finding until the next annual audit cycle.

Why wrong: Ignoring the finding does not manage risk and leaves the organization exposed without documentation or accountability. It is an operational mistake, not a valid treatment strategy.

Transfer the issue to the help desk by opening a routine support ticket.

Why wrong: A support ticket may track the work, but it does not transfer risk in the management sense. Risk transfer usually involves contracts, insurance, or outsourcing arrangements, not simply handing the issue to operations.

Use a shared local administrator account for the app so offboarding is easier.

Why wrong: Shared local accounts prevent accountability and make rapid, reliable offboarding much harder.

Allow anonymous public links as the default method for external collaboration.

Why wrong: Anonymous sharing increases exposure and conflicts with the goal of reducing tenant and user risk.

Rely on manual quarterly cleanup tickets to disable former employees.

Why wrong: Quarterly manual cleanup is slow and leaves unnecessary access active for too long.