Security Operations practice questions

Disable the software updater immediately to prevent further registry modifications.

Why wrong: Disabling the software updater might prevent future legitimate updates and does not address the possibility that the updater is being exploited. The analyst should first confirm whether the activity is malicious.

Create an exception rule in the EDR to suppress future alerts for this process.

Why wrong: Creating an exception without thorough investigation risks allowing an attacker to hide malicious activity behind a trusted process name. This is a common but dangerous shortcut.

Isolate the workstation from the network and reimage the system immediately.

Why wrong: Isolation and reimaging are extreme measures that should be reserved for confirmed compromises. Without evidence that the workstation is truly infected, this action would be premature and disruptive.

Immediately block the IP address at the perimeter firewall.

Why wrong: While blocking the malicious IP is a valid containment step, it should not be the first action. The analyst should first determine if any valid accounts were targeted, as a successful logon could have already occurred. Blocking prematurely might also hinder further observation of the attack pattern.

Run a full antivirus scan on the domain controller.

Why wrong: An antivirus scan is not warranted at this point. The logs indicate an authentication attack, not malware activity. Scanning the domain controller would divert resources from addressing the immediate threat and would not prevent the ongoing logon attempts.

Notify the company's legal department for law enforcement involvement.

Why wrong: Legal involvement and reporting to law enforcement may be appropriate later, but it is premature before confirming that the attack is successful or that sensitive data has been accessed. The analyst should first investigate and contain the threat.

Increase the failed attempt threshold to 20 attempts within the same 5-minute window.

Why wrong: Raising the threshold reduces sensitivity but may still generate false positives from fast typists and could allow a true brute-force attack to succeed if the attacker keeps under the new limit.

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

Why wrong: This would detect password spraying attacks (many accounts, one password), not brute-force against a single account. It does not address the false positive issue described.

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

Why wrong: This is unreliable because not all users submit password reset requests, and an attacker could also initiate a reset to evade detection. It does not effectively reduce false positives in a consistent manner.

Shut down the server to prevent further damage

Why wrong: Incorrect. Shutting down the server destroys volatile memory data and may also trigger anti-forensic behavior from malware. Forensic best practice is to capture volatile data before powering off.

Create a forensic disk image of the hard drive

Why wrong: Incorrect. While disk imaging is important, it is less urgent than capturing volatile data because disk contents persist even after shutdown. Disk imaging should be performed after memory capture.

Run a full antivirus scan on the system

Why wrong: Incorrect. Running an antivirus scan modifies the system state (e.g., by accessing files, creating logs, or quarantining malware) and can destroy volatile evidence. Scanning should be performed on a forensic copy, not the live system.

Immediately block the user account and the source IP address at the CASB.

Why wrong: This is too aggressive without confirmation that the activity is malicious. The account could be compromised, but a permanent block may alert an attacker and hinder forensic collection. Containment should be done as part of a coordinated incident response, not as a solo action.

Contact the user directly by phone to verify whether they initiated the download.

Why wrong: While verification is useful, this should not be the first step. If the account is compromised, contacting the user may tip off the attacker. The incident response process should be initiated first to ensure proper evidence handling and coordination.

Disable the SharePoint document library and remove all user permissions to prevent further data loss.

Why wrong: Disabling the entire library would cause a denial of service to legitimate users and is excessive. The focus should be on the specific account and session, not on shutting down the resource for everyone.

The DNS server logs showing the queried domains and subdomains.

Why wrong: DNS server logs may record the queried domain and sometimes the subdomain, but they often truncate long subdomains or omit them entirely, making them unreliable for extracting the full encoded payload.

The workstation's process creation logs showing which process initiated the DNS queries.

Why wrong: Process creation logs indicate the executable that generated the DNS queries, but they do not contain the actual data transmitted in the queries, so they cannot confirm the contents of the exfiltrated file.

The firewall logs showing outbound connections from the workstation to the external DNS server on port 53.

Why wrong: Firewall logs only show connection metadata such as source/destination IP addresses and ports. They do not contain the actual DNS query content, so they cannot reveal what data is being transmitted.

Normal software update check

Why wrong: Incorrect. While some software updates use periodic checks, they usually occur at less regular intervals, often with randomized delays to avoid server load, and the data transferred is typically larger (e.g., update manifests or actual patches). The extremely consistent timing and small size are more indicative of beaconing.

DNS tunneling

Why wrong: Incorrect. DNS tunneling exfiltrates data by encoding it in DNS queries, which use UDP port 53 (or sometimes TCP port 53). The traffic described is over TCP port 443 (HTTPS), not DNS, so this pattern does not match DNS tunneling.

Data exfiltration via HTTPS

Why wrong: Incorrect. Data exfiltration via HTTPS typically involves transferring larger volumes of data in a single session or over a shorter period. The steady 1 KB every 5 minutes would take an extremely long time to exfiltrate significant data, making this pattern unlikely for exfiltration. Beaconing is far more probable.

An attacker performed a pass-the-hash attack using cached credentials from jsmith's workstation.

Why wrong: Incorrect. Pass-the-hash attacks target NTLM authentication hashes, not smart card certificate-based authentication. Smart card authentication uses a private key and certificate, not a password hash.

The VPN server's certificate was forged, allowing the attacker to intercept jsmith's credentials.

Why wrong: Incorrect. Forging the VPN server certificate would allow a man-in-the-middle attack to intercept credentials, but it would not allow the attacker to authenticate as jsmith without possessing his smart card and PIN.

The user's account password was guessed through a brute-force attack and then used to create a new certificate.

Why wrong: Incorrect. A password alone cannot be used to enroll a new smart card certificate without additional identity proofing and approval from the certificate authority. Brute-forcing the password would not directly enable certificate-based authentication.

DNS query logs from the internal DNS server

Why wrong: DNS logs record domain name resolution queries, not raw TCP connection attempts. They would not show the SYN packets or the scan pattern.

Web proxy logs from the corporate proxy server

Why wrong: Web proxy logs only capture HTTP/HTTPS traffic that is explicitly proxied. RDP traffic on port 3389 would not typically go through a web proxy, so these logs would not contain relevant data.

VPN gateway authentication logs

Why wrong: VPN gateway logs record successful and failed authentication attempts for remote users. They do not capture external connection attempts that do not reach the VPN server or involve authentication.

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.

Begin the eradication phase by immediately reimaging the workstation.

Why wrong: Reimaging is part of the eradication and recovery phases. It should only be performed after containment and after any necessary forensic data has been collected. Skipping containment could allow the threat to spread further.

Conduct a full forensic analysis of the workstation's hard drive.

Why wrong: Forensic analysis is important for understanding the scope of the incident, but it typically occurs after containment. Performing analysis before containment may allow the threat to continue operating and causing harm.

Update the firewall rule to block all outbound traffic to the malicious IP.

Why wrong: While updating a firewall rule can help block further connections to the malicious IP, it does not address the already compromised workstation, which may still be able to use other protocols or paths to communicate out. Isolating the workstation is more immediate and comprehensive.

Run a comprehensive antivirus scan on the server.

Why wrong: Incorrect. Running an antivirus scan may alert the attacker and does not immediately stop the data exfiltration. Containment should occur first; scanning is part of the eradication and recovery phases.

Notify the Chief Information Security Officer (CISO) of the incident.

Why wrong: Incorrect. While notification is a critical step in incident response, the immediate action should be containment to limit damage. Reporting typically occurs after initial containment and verification of the incident.

Power off the server to prevent further damage.

Why wrong: Incorrect. Powering off the server may destroy volatile data (e.g., memory contents, running processes) that are vital for forensic analysis. Logical network isolation is preferred unless physical safety is at risk.

Run a full antivirus scan on the workstation.

Why wrong: While scanning may be part of the investigation, it is not the first priority. The system is actively communicating with a C2 server, and delaying containment could allow data theft or additional compromise. Containment should come before remediation.

Review firewall logs to see if the traffic is being blocked.

Why wrong: Reviewing logs does not immediately address the active threat. The analyst must act to stop the ongoing communication; log analysis can be performed after containment.

Inform the user to shut down the workstation.

Why wrong: Shutting down the workstation would stop the traffic but may destroy volatile evidence (e.g., running processes, memory artifacts). A proper forensic acquisition requires controlled disconnection rather than a shutdown.

Configure an account lockout policy to lock the 'admin' account after three failed attempts.

Why wrong: An account lockout policy on a critical database server could lock out legitimate administrators if they accidentally mistype credentials, and it may not prevent the attacker from moving to other target accounts. This option is incorrect because it negatively impacts availability and does not address the source IP.

Disable the 'admin' account until the source IP can be investigated.

Why wrong: Disabling the account would prevent all administrative access, potentially disrupting critical operations and causing downtime. It does not address the root cause and may be overly aggressive.

Require multi-factor authentication on the 'admin' account for all remote logins.

Why wrong: While MFA strengthens authentication, it does not stop the current attack because the attempts are still hitting the server and using up processing resources. Also, MFA may not be supported by all legacy systems or could be bypassed. It is a good preventive control but not the best immediate mitigation.

Disable the users' accounts.

Why wrong: This is incorrect because disabling accounts is a drastic step that would halt all user activity, including legitimate work, and it does not directly address the email propagation path.

Perform a forensic analysis of the emails.

Why wrong: This is incorrect because forensic analysis is an investigation step that occurs after containment; performing it first would delay stopping the spread of the attack.

Delete the emails from the users' mailboxes.

Why wrong: This is incorrect because deleting emails only removes the messages from already affected mailboxes but does not prevent new malicious emails from arriving; containing the source is more effective.

Disable the user account immediately and reset the password.

Why wrong: Disabling the account immediately may be too aggressive without confirming the login was malicious. It could disrupt legitimate user activity if the alert is a false positive (e.g., the user is traveling). Proper incident response requires analysis before containment.

Conduct a full forensic analysis of the user's workstation.

Why wrong: A full forensic analysis is not the immediate next step for a single anomalous login alert. Such an in-depth investigation is reserved for confirmed compromises or incidents with significant impact. It would be premature and resource-intensive at this point.

Report the incident to law enforcement.

Why wrong: Law enforcement reporting is typically reserved for incidents that involve criminal activity, data breaches, or legal obligations. This single alert does not yet warrant such a report; the incident must first be investigated and confirmed.

Recovery

Why wrong: Recovery is not the next step. Recovery restores systems to normal operation after eradication has been completed. Attempting recovery before eradication could leave the system vulnerable to reinfection.

Containment

Why wrong: Containment has already been performed by isolating the workstation. Repeating containment would be redundant and delay progression to the next phase.

Lessons Learned

Why wrong: Lessons Learned is the final phase of incident response, conducted after recovery. It involves post-incident review to improve future responses, not immediate next steps.

Data loss prevention (DLP) system

Why wrong: A DLP system is designed to detect and prevent unauthorized data transfers or leaks. It does not record who changed file permissions; it monitors data in motion or at rest for policy violations.

Mandatory access control (MAC)

Why wrong: MAC is a security model that uses system-wide policies to control access to resources, typically based on labels. While it defines who can access what, it does not log or track the history of permission changes.

Host-based intrusion prevention system (HIPS)

Why wrong: HIPS monitors host activities to block suspicious behavior or attacks. It may log security events, but it is not designed to capture routine administrative permission changes; its primary focus is threat prevention.

Increase the account lockout threshold to a lower number

Why wrong: This would lock accounts more quickly but does not address the core issue: the attacker uses many different usernames. Locking accounts faster does not prevent the attacker from moving to the next username.

Implement geofencing to block traffic from the attacker's region

Why wrong: Geofencing restricts access based on geographic location, but it does not stop a determined attacker who may use a VPN or proxy. It is not a direct mitigation for brute force attacks across usernames.

Enable detailed failed login attempt logging

Why wrong: While logging helps with detection and forensic analysis, it does not prevent the attack from continuing. The analyst already observed the attempts; proactive controls like rate limiting are needed.

Disable the user account immediately to prevent further access

Why wrong: Disabling the account without first verifying with the user is too hasty. The activity could be legitimate (e.g., the user is on vacation) and disabling the account could cause unnecessary business disruption. Incident response best practices recommend gathering more information before taking irreversible actions.

Continuously monitor the account for additional suspicious activity

Why wrong: While monitoring is a valid security operation, it should not be the next action when a successful authentication from an unusual location is detected. Waiting could allow an attacker to continue using the account, potentially accessing sensitive data. The analyst should actively investigate rather than passively monitor.

Revoke all active sessions for the user account

Why wrong: Revoking all sessions without first confirming whether the activity is legitimate could lock the user out of necessary systems, causing productivity loss. It also does not address the root cause if the account is compromised, as the attacker might simply initiate new sessions. The proper approach is to verify with the user before taking containment actions.