Security Operations practice questions

Modify the rule to trigger only when the failed attempts originate from multiple distinct source IP addresses.

Why wrong: This is correct because a genuine brute-force attack often uses a distributed set of source IPs to evade rate limiting, whereas a legitimate user mistyping typically connects from a single IP. This change filters out most false positives while still detecting distributed attacks.

Modify the rule to trigger only when the failed attempts are against multiple distinct user accounts.

Why wrong: Changing the trigger to require failures against multiple distinct user accounts converts the rule from detecting a vertical brute-force attack (many attempts against one account) to a horizontal password-spraying attack (one password attempted across many accounts). The false positive in question is a single legitimate user repeatedly mistyping their password, which produces many failures on one account; this change would suppress that noise, but it would also blind the SIEM to a genuine single-account brute-force attack. It sidesteps the tuning problem rather than solving it, because the attacker's source-IP distribution is the more reliable discriminator.

Add an exception to suppress alerts for any user account that has a valid password reset request within the same time period.

Why wrong: Suppressing alerts whenever a password reset request exists for the same user is unreliable because many legitimate users who mistype their password simply retry with the correct one, without ever initiating a reset. Worse, an attacker performing a brute-force attack can submit a password reset request themselves to create a false alibi, causing the SIEM to ignore the failed login burst. This exception is easy to game, depends on a side-channel workflow that may not always be auditable, and does not provide a deterministic relationship between the failed attempts and the reset request.

DNS query logs from the internal DNS server

Why wrong: DNS query logs record only domain name resolution requests and responses, such as a client asking for the IP address of a hostname. They do not contain any information about TCP connection attempts, SYN packets, or destination ports like 3389. A port scan that generates traffic directly to an IP address without a preceding DNS query would leave no trace in these logs, making them useless for identifying reconnaissance activity.

Web proxy logs from the corporate proxy server

Why wrong: Web proxy logs capture only HTTP and HTTPS traffic that is explicitly routed through the corporate proxy server, typically for web browsing. Remote Desktop Protocol (RDP) uses TCP port 3389 directly to the target host and is not an HTTP-based protocol, so it generally bypasses the proxy entirely. Even if a client used an HTTP CONNECT tunnel, the proxy log would show only the tunnel establishment, not the underlying scan pattern, and no such proxy configuration exists for unfiltered external traffic. Therefore, these logs would lack evidence of the port scan.

VPN gateway authentication logs

Why wrong: VPN gateway authentication logs record only events at the VPN concentrator itself, such as successful or failed IKE/IPsec or SSL-VPN login attempts, along with the VPN source IP and username. An external port scan targeting RDP services on internal hosts is addressed directly to those hosts' IP addresses and port 3389, not to the VPN gateway's listening ports (e.g., 443, UDP 500/4500). Because the scan never reaches the VPN authentication process or the gateway's session establishment stage, these logs would show no corresponding entries.

Boot the laptop from a forensic boot CD that loads a write-blocker driver and then create a forensic image.

Why wrong: This is incorrect because booting from any media (even a forensic CD) will cause the BIOS and potentially the running forensic OS to write data to the suspect hard drive (e.g., creating temporary files or modifying the registry) before the write-blocker driver becomes active. The drive could be altered before the write-blocker is enforced.

Perform a live acquisition of the hard drive using a network forensic tool while the system is still running.

Why wrong: This is incorrect because live acquisition involves interacting with the running system, which can modify file timestamps, memory, and temporary files. It also may not capture deleted or hidden data reliably. The goal is to preserve the hard drive's contents without any changes, so a live acquisition is not appropriate when a static image is required.

Ask the suspect to log off and shut down the laptop normally, then remove the hard drive and image it using a write-blocker.

Why wrong: This is incorrect because a normal shutdown allows the operating system to perform writes, such as flushing disk caches, writing event logs, and updating registry hives. These writes can modify or destroy potential evidence. The analyst should never rely on a normal shutdown when the device is already on.

Apply the change during peak business hours to notice problems quickly

Why wrong: Applying the change during peak business hours maximizes the blast radius: a misconfigured allow or deny could disrupt thousands of connections or block critical services when traffic volume is highest. Troubleshooting during peak load is further complicated by noisy logs, high packet rates, and business pressure, which can lead to rushed, poor decisions. Scheduled maintenance windows are designed for such changes because they limit user impact and give you time to analyze the system.

Disable firewall logging during the change to reduce noise

Why wrong: Disabling firewall logging during the change eliminates the evidence needed to detect a misconfiguration and to diagnose why a legitimate flow is dropped or an attack is allowed. Without logs, you cannot correlate the rule change with the resulting behavior, nor can you verify that the rule matches the intended traffic and nothing else. Logs also serve an audit trail for compliance, and their absence can leave a security gap during a high-risk operation.

Skip documentation because the rule only affects one vendor

Why wrong: Skipping documentation for a rule that affects only one vendor still creates an undocumented change that is not reviewable by peers and cannot be audited later. Without a description of the business purpose, an administrator in the future may mistake the rule for stale and remove it, breaking the vendor integration. Proper documentation also records the rule's placement, source/destination, and the associated change ticket, which is essential for incident response and firewall rule lifecycle management.

Delete the mailbox forwarding rule and empty the trash folder, so the attacker cannot read old messages.

Why wrong: Deleting the mailbox forwarding rule and emptying the trash folder are destructive actions that remove direct evidence of the attacker’s activity and persistence mechanisms. The forwarding rule itself contains forensically critical metadata (e.g., creation timestamp, source IP, rule parameters) that can reveal when and how the compromise occurred; deleting it destroys that timeline. Emptying the trash permanently erases emails that may contain proof of data exfiltration, attacker instructions, or other malicious communications. Incident response best practice is to preserve evidence first—by exporting logs, capturing snapshots, or documenting the rule’s exact configuration—before taking any containment steps, so that actions do not unknowingly eliminate the very artifacts needed for attribution and scope analysis.

Reimage the admin workstation immediately, because the issue must have started on the endpoint.

Why wrong: There is no evidence here that the administrator’s workstation is the source. Reimaging too early would discard useful volatile and logged evidence and might not even stop the cloud-side compromise if the attacker used only the account token.

Disable all company email for every user until the account investigation is finished.

Why wrong: A full mail shutdown is a broad, disruptive response that is not justified by the scenario. It would severely impact operations and is unnecessary when the suspicious activity appears limited to one privileged account and its artifacts.

The server’s warranty status, because hardware replacement may be needed later.

Why wrong: The server's warranty status is static administrative metadata that can be retrieved from vendor records or purchase orders at any time. It has no bearing on documenting the current attacker activity, active sessions, or outbound SMB connections that would disappear upon reboot. In incident response, the focus is on preserving volatile evidence, and warranty information does not contribute to identifying the scope of the lateral movement or preserving forensic data.

A fresh operating system patch, because updating quickly reduces all risk.

Why wrong: Applying a fresh operating system patch in the middle of an investigation is a remediation action that changes the host's state and may overwrite critical artifacts such as event logs, registry keys, and running processes. Rapid patching could also disrupt an ongoing attack chain, giving the adversary an opportunity to alter course or evade detection before the incident is fully contained. The correct priority is to capture volatile data first, then reimage or patch as part of a controlled recovery process.

A user satisfaction survey, because affected staff can describe what they noticed.

Why wrong: A user satisfaction survey collects subjective opinions about system performance or usability, not forensically sound evidence of attacker activities. While end-user observations may provide anecdotal leads, they cannot replace the need to preserve live system data like active sessions and network connections, and they are always available to gather after the volatile evidence has been secured. Depending on survey responses for incident response would introduce delay and fail to capture the technical indicators needed to confirm lateral movement.

Browse the original disk using the operating system file explorer to confirm the case folder is present.

Why wrong: Browsing the original disk through the operating system file explorer is a fundamental forensic mistake because the OS will automatically mount the filesystem, update the accessed timestamp on directories and files, and may create system restore points or thumbnail caches. These changes modify the original media, making it impossible to later prove the image is an exact replica of the source. Forensic examiners must instead rely on a hardware write blocker during acquisition and verify the result with cryptographic hashes, never directly interacting with the original disk.

Store the suspect drive and the forensic copy in the same unlocked folder to simplify access.

Why wrong: Storing the original suspect drive in the same unlocked folder as the forensic copy violates evidence segregation and access-control principles. An unsecured, co-located environment allows any person to view or touch the original, destroying the chain of custody and providing no proof of who had access or when. If the original is accidentally modified, the forensic copy cannot be used to repair it, because the only true source is gone; proper practice is to lock the original in a sealed evidence bag inside a controlled evidence locker while the working copy remains separately secured.

DHCP lease logs, because they identify the internal workstation that first received the suspicious email.

Why wrong: DHCP logs can help map a device to an IP address, but they do not explain a cloud mailbox forwarding rule or a foreign sign-in. They are too indirect for confirming account takeover or token abuse in this scenario.

Print server logs, because mailbox forwarding often causes documents to be printed unexpectedly.

Why wrong: Print server logs capture print jobs sent to network printers or multifunction devices. Mailbox forwarding is a server-side Exchange Online or Microsoft 365 rule that redirects email at the transport layer; it does not spawn print jobs or any print-related activity. Even if an attacker triggered printing as a post-compromise action, print logs would not reveal the sign-in origin, MFA status, or session token details needed to confirm account takeover. Therefore, print server logs are unrelated to the core question of how the mailbox was accessed or how persistence was established.

Physical badge-access logs, because they prove whether the user was in the office when the login occurred.

Why wrong: Badge logs may support an alibi check, but they do not prove malicious access or identify the session source. They are useful only as supporting context, not as the first source for this mailbox compromise investigation.

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

Why wrong: Spooler service logs record print queue activity, submitted jobs, and printer driver events; they do not capture process execution, parent-child relationships, or outbound network connections. Mshta.exe is the HTML Application host, which executes embedded scripts via scripting engines; it does not routinely print documents before establishing network activity. The alert's key evidence is the execution chain from Outlook to mshta, which spooler telemetry cannot possibly contain, so these logs are irrelevant for validating this suspicious behavior.

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

Why wrong: RAID controller logs are exclusively indicator of storage hardware health, including array degradation, rebuild status, and disk failures. They have no ability to record application-level process launches, script execution, or network beaconing, so an mshta.exe spawn from Outlook would not appear in them. Even if a RAID volume were failing, that would not explain the execution chain or the outbound connections, making these logs entirely unrelated to the investigation.

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

Why wrong: NTP synchronization logs track clock adjustments and time-drift calculations for the endpoint, which can occasionally hinder log correlation during an incident, but they do not cause or indicate malware activity. The mshta.exe process cannot be initiated by time offset, and NTP telemetry contains no information about executed parents, children, or network destinations. To assess this alert, you need process lineage and web traffic records, not clock data; time drift is a supporting context at best, not the root-cause evidence.

Printer spooler logs from the user’s workstation

Why wrong: Printer spooler logs on a user's workstation record local print jobs, printer driver installs, and spooler service events, which are irrelevant to a remote cloud portal authentication. They contain no information about the cloud session, the token issuance, or any mailbox rule changes that may have been made. In a cloud account compromise, the forensic evidence lives in identity providers and cloud audit services, not in local print infrastructure, so these logs would only distract the investigation.

DHCP lease logs for the office network

Why wrong: DHCP lease logs for the office network map MAC addresses to IP addresses for the LAN, but a successful cloud admin sign-in could occur from any network, including a mobile carrier or a VPN endpoint. Even if the lease shows the user's workstation was active at the time, it does not indicate whether the cloud authentication was legitimate or malicious, nor does it capture any subsequent changes to mailbox rules. These logs lack the application-layer details needed to validate an identity provider event.

USB device connection logs from the user’s laptop

Why wrong: USB device connection logs from the user's laptop track physical device insertion and can support evidence of data theft or malware delivery, but they have no bearing on a remote sign-in to a cloud administration portal. The compromise in question is authenticated through the identity provider, and the attack actions are in cloud audit logs, not in the laptop's hardware event log. Unless the incident involved physical access, USB logs are a low-priority source and do not help validate the session or rule modifications.

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

Why wrong: Mounting the drive read/write is catastrophic because the operating system will immediately modify the volume upon mount, such as updating last-accessed timestamps, writing journal entries, or creating System Volume Information files. These modifications change the file system's metadata and can overwrite deleted files or slack space that might contain recoverable evidence. Hidden files are simply files with system/hidden attributes; they are fully accessible via a read-only forensic mount or a forensic imaging tool, so making the drive writable has no legitimate forensic purpose.

Defragment the drive first to improve imaging speed

Why wrong: Defragmenting a drive reorganizes the physical layout of files and moves data clusters to contiguous locations, which completely alters how data is stored on the media. This process rewrites file allocation table entries and can overwrite unallocated space or residual data from previously deleted files, destroying potential evidence. Forensic imaging is designed to capture the disk exactly as it exists, and the marginal speed improvement is irrelevant, as imaging is performed at the block level using sector-by-sector reads, not file placement.

Install triage tools directly on the suspect laptop

Why wrong: Installing triage tools onto the suspect laptop requires writing software to the system's hard drive or altering its storage. This changes the system's registry, creates executable files, updates file timestamps, and may overwrite free or unallocated space that could contain deleted evidence. Proper forensic triage requires booting to a trusted read-only forensic environment, such as a live CD or USB drive, so that all analysis tools run entirely from external media without touching the suspect's storage.

Run a full antivirus scan immediately, because the scan report will serve as the primary evidence.

Why wrong: A full scan can change files, trigger malware behavior, and overwrite useful artifacts. It is not the best first action when the priority is preserving volatile evidence and containing the endpoint. Scan results also do not replace live data capture.

Reboot the laptop into Safe Mode so the attacker’s code will not load.

Why wrong: Rebooting into Safe Mode eliminates all volatile evidence—including memory-resident malware, live network connections, and active processes—that is essential for incident analysis. Attackers commonly deploy persistence mechanisms like scheduled tasks or services that load even in Safe Mode, so this measure does not guarantee neutralization. Moreover, the reboot event itself can trigger anti-forensic scripts that encrypt or wipe logs and artifacts. Safe Mode belongs to the later remediation phase, never before forensic data collection from a live system.

Power off the laptop immediately to prevent the incident from spreading further.

Why wrong: Immediate power-off prevents any further live collection and can destroy evidence that exists only in memory or active sessions. While it may stop some malicious activity, it is too blunt for the stated requirement to preserve evidence first.

Browse the user’s files to confirm whether the laptop contains stolen documents.

Why wrong: Opening files before proper forensic handling can change metadata, create access artifacts, and weaken the evidentiary value of the device. In a legal case, investigators should minimize interaction with the original evidence and use approved forensic methods after preservation is complete.

Remove the hard drive and place it in an unmarked box for convenience.

Why wrong: Removing components without documenting the process can break chain of custody and complicate later analysis. An unmarked box provides no integrity assurance and makes tracking harder. The evidence should be sealed, labeled, and recorded in a formal transfer process.

Let the employee continue using the laptop until legal staff are available.

Why wrong: Allowing the employee to keep using the laptop can overwrite deleted files, alter file system metadata (like access and modification times), and generate new user data that obscures the device's original state. In an insider theft case, every additional interaction after the incident complicates forensic analysis and gives the defense grounds to claim spoliation or contamination. The device must be seized promptly and preserved under controlled conditions to maintain evidentiary integrity for potential litigation.

Disable the SIEM rule entirely because backup jobs are normal.

Why wrong: Disabling the rule removes visibility into the same behavior if an attacker imitates the backup process or abuses those credentials. The goal is tuning, not blind spots. A better approach is to make the rule more precise so it still alerts on abnormal activity.

Mark every backup-related alert as harmless without review.

Why wrong: Automatically dismissing all related alerts creates a dangerous assumption that normal activity can never be abused. Attackers often hide in routine processes and trusted accounts. The rule should still watch for deviations, rather than being ignored completely.

Stop logging backup systems so they no longer create noise.

Why wrong: Suppressing logs sacrifices investigative visibility and makes it harder to detect misuse or troubleshooting issues. Logging is still valuable even when tuning alerts. The right fix is to refine detection logic, not eliminate data sources.

Restore user files from the most recent backup and reconnect the host immediately.

Why wrong: Restoring user files from backup addresses data recovery, but reconnecting the host immediately ignores the need to validate that the malicious extension and persistence mechanism are actually gone. If the backup is not scanned or the host is not cleaned, the restored files may reintroduce the infection or the endpoint may still execute malicious code on boot. Recovery requires a deliberate sequence—eradicate, validate, then reconnect—so immediate reconnection is premature and risks recompromising the network.

Announce the incident to users without changing the host configuration.

Why wrong: Announcing the incident to users is a communication and awareness action, but it does nothing to remove the malicious extension or scheduled task from the endpoint. Without modifying the host configuration, the attacker's persistence mechanism remains active, allowing the malware to continue executing and potentially reestablish a foothold. Notification is part of the overall response, but eradication demands technical remediation, not just informing stakeholders.

Leave the browser extension in place and only change the user password.

Why wrong: Changing the user's password revokes known compromised credentials, but it leaves the malicious browser extension and scheduled task untouched, so they can still operate with the user's browser context or system privileges. The extension could steal new credentials or perform actions under the user's identity, and the scheduled task provides persistence to reinstall or continue abuse. Password rotation is a containment step, not an eradication step; the malware itself must be removed to properly end the incident.

A medium-severity missing patch on an offline lab VM with no network connectivity.

Why wrong: This finding is the lowest urgency because the lab VM is offline and has no network connectivity, eliminating any remote attack vector. A missing patch is only advantageous to an attacker if they have a path to reach the system; with the machine fully isolated, the vulnerability cannot be triggered externally. While patch hygiene should still be maintained to prevent future risk once the system is reconnected, it is reasonably deferred compared to externally exposed or actively exploited issues.

A low-severity TLS configuration warning on a public site that does not handle sensitive information.

Why wrong: This finding is low priority because it concerns a TLS configuration warning, typically a protocol cipher or certificate issue, rather than a direct exploitable vulnerability. Given that the public site does not handle sensitive information, the confidentiality impact is minimal, and the issue is likely to be a compliance or best-practice concern. It should be repaired in the same maintenance cycle as other minor configuration items, but it is far less urgent than active exploitation, default credentials, or high-severity RCEs on data-bearing systems.

Mount the backup share permanently so restores are always faster.

Why wrong: Permanently mounting the backup share ensures it remains accessible via SMB, which directly replicates the condition that allowed the ransomware to encrypt both the live file share and the attached NAS backups. The blast radius would remain unchanged because the backup volume stays online and writable over the same protocol. This option is tempting because a persistent mount eliminates restore delays caused by remounting credentials or network discovery, and it would be correct in a scenario where the sole objective is minimising recovery time after a non-malicious failure, such as a power outage.

Join the NAS to the same administrative group used by production servers.

Why wrong: Joining the NAS to the same administrative group as production servers means every administrator credential with rights over the file share also grants full control over the backup repository. A single Kerberos ticket or local account compromise then provides authorized access to both live and backup data, eliminating the security boundary that should separate recovery assets and making lateral movement trivial.

Disable restore testing to avoid risking the backup environment.

Why wrong: Disabling restore testing to protect the backup environment removes the only verification that backup media, catalog metadata, and recovery procedures actually work end-to-end. Silent failures such as bit rot, incomplete snapshots, or incompatible versions cannot be detected until a live disaster, when the organization discovers that its primary recovery path is invalid and faces permanent data loss.

Immediately isolate the workstation from the network without reviewing any other evidence.

Why wrong: Isolation is a high-impact containment action and should never be the first move when the alert is ambiguous; you may be interrupting a legitimate software update, causing availability loss across the environment. Without first correlating endpoint data (process tree, digital signature) and network context (destination reputation), you risk acting on a false positive while also potentially missing the opportunity to observe the behavior for more evidence. A measured triage approach allows you to confirm the alert's validity, then contain if warranted, rather than blindy applying network access controls.

Suppress every future alert from that subnet permanently.

Why wrong: Permanently suppressing an entire subnet is a dangerous over-tune because it hides all future security signals from that CIDR range, including genuine intrusions that later migrate onto that subnet. A false-positive exception should be scoped as narrowly as possible—by specific process, target domain, and timeframe—and it must retain the ability to alert if the pattern deviates even slightly. Continuously monitoring means maintaining visibility; a permanent blanket suppression violates this core principle and creates a persistent blind spot for the SOC.

Assume the traffic is benign because it occurs at a regular interval.

Why wrong: Regular periodicity is a hallmark of malware command-and-control (C2) beaconing, often built to evade detection by mimicking a legitimate heartbeat or update check. Solely relying on a consistent schedule ignores other critical indicators like the destination's reputation, the TLS certificate, or the process responsible for the traffic—all of which are far more discriminating. An attacker can deliberately set a beacon interval to appear routine, so time-based reasoning alone is naive and not a defensible justification for marking the alert as a false positive.

Delete the mailbox and create a new user account.

Why wrong: Deleting the mailbox and recreating the account is a destructive measure that destroys forensic evidence. The compromised mailbox likely contains the phishing email, malicious payloads, and attacker-induced changes such as inbox rules or forwarding setups. This evidence is critical for determining the scope of the breach and preventing future incidents. The correct containment approach preserves the account in a quarantined state while investigating, not deleting it.

Disable all external email delivery for the entire organization.

Why wrong: Disabling external email delivery for the entire organization is an extreme, business-wide action that goes far beyond the scope of this single compromised account. It would halt all legitimate external correspondence for every user, causing massive disruption and potentially harming partner relationships. Targeted containment, such as blocking the specific sender, restricting the compromised account's outbound messages, or revoking the attacker's known IP addresses, achieves the same security goal without the collateral damage.

Wait for the user to confirm whether the message was legitimate before acting.

Why wrong: Waiting for the user to confirm legitimacy unacceptably delays containment while the compromised credentials remain active. The SOC has already confirmed the user entered corporate credentials, which is strong evidence of a successful phishing attack or credential theft. Every minute the attacker retains access increases the risk of data exfiltration, lateral movement, or establishing persistence. Incident response best practice is to contain first and ask questions later, especially when there is concrete evidence of compromise.

Share one root password across the whole team.

Why wrong: Sharing a single root password across a team destroys non-repudiation—if a destructive command runs, you cannot identify which individual executed it. It also makes credential rotation painful, because changing the password forces every team member to be notified and update their notes. Instead, issue each admin a personal account with sudo privileges, so actions are attributable and access can be revoked individually when someone leaves or changes roles.

Embed the account password directly in the script.

Why wrong: Embedding a password directly inside the script means the secret is stored in plaintext, often in a file that might be world-readable, committed to git, or included in backups. If an attacker gains read access to the script or its version control history, they can recover the credential and reuse it elsewhere. The correct approach is to fetch secrets dynamically from a secrets manager, or inject them via environment variables that are restricted at runtime.

Disable logging so the maintenance job runs faster.

Why wrong: Disabling logging to speed up a maintenance job is a misguided trade-off because the loss of auditability greatly outweighs any negligible performance gain. Logs are essential for identifying the cause of a failed job, detecting unauthorized changes, and meeting compliance requirements. A well-configured job writes to a dedicated log or syslog, and the overhead is typically sub-second compared to the security value.