Troubleshooting Scenario Questions

Manually check each file for suspicious extensions.

Why it fails: Manually inspecting filenames for suspicious extensions is not a malware scan and cannot detect malicious content hidden in documents or renamed files, so the policy requirement stays unmet. It tempts as a quick workaround when automated scanning fails, yet only a completed antivirus scan satisfies the mandate.

Disable write protection and rescan.

Why it fails: Disabling the write-protect switch alters the media's hardware state and permits writes, but the mandated scan still has not completed, so policy is unmet. It tempts because removing the obstruction appears to unblock the scan, yet the correct action is to scan the drive on a system where the antivirus can complete before any transfer.

Proceed with the file transfer since the scan failed due to hardware issue.

Why it fails: Proceeding transfers unscanned media, directly violating the policy that requires a completed malware scan before use; a hardware fault is not an exemption. It tempts because the write-protect switch itself prevents malware writing to the drive, yet the presentation files remain uninspected and could carry malware onto the destination host.

/var/log/kern.log

Why it fails: kern.log records kernel messages such as hardware and driver events, so it holds no SSH authentication entries. It is tempting because kernel-level logging sounds security-relevant, and would be correct when diagnosing firewall drops, OOM kills or driver faults rather than login attempts.

/var/log/messages

Why it fails: On Debian and Ubuntu, SSH authentication records go to /var/log/auth.log, not /var/log/messages, which carries general non-auth system notices. It is tempting because messages is a central log on Red Hat systems, where it would be correct if sshd were configured to write there.

/var/log/syslog

Why it fails: On systemd distributions, SSH authentication events are written to /var/log/auth.log or the journal, not syslog, which captures general system messages. It is tempting because syslog aggregates many daemons, and would be correct on systems where sshd logs there via rsyslog configuration.

Review the bash history of root user.

Why it fails: Bash history records interactive commands, not the process or network context of the listening SSH daemon, so it cannot confirm whether the high port was authorised. It is tempting because history reveals attacker actions, and would be correct when tracing commands executed after a confirmed compromise.

Check /etc/crontab for malicious scheduled tasks.

Why it fails: Crontab entries reveal persistence mechanisms, not the identity or parent of the process currently bound to that high port, so the active intrusion stays unexamined. Checking scheduled tasks is tempting because attackers commonly establish cron-based persistence, and it would be correct once the listening process is identified and persistence hunting begins.

Run 'ps aux' to list all processes.

Why it fails: Listing processes with 'ps aux' shows running commands but not which process owns the listening socket, so the suspicious SSH listener remains unidentified. It is tempting because process enumeration is a standard triage step, and it would be the right choice when hunting for anomalous binaries or resource-hogging processes rather than mapping a port to its owning PID.

Export the logs to a CSV file and email them to the security team

Why it fails: Exporting to CSV and emailing alters the logs' metadata and breaks the chain of custody, since emailing creates copies without documented hash values or transfer records. It is tempting because CSV exports suit routine reporting and analysis, but NIST evidence preservation requires forensic imaging with hashing to maintain integrity for legal admissibility.

Use a write-blocker to create a forensic image of the entire hard drive

Why it fails: Imaging the entire drive captures unrelated data and, without a documented hash and custody transfer, still fails the chain-of-custody requirement; the stem asks specifically for the database audit logs. Full-disk imaging suits cases needing deleted-file or unallocated-space recovery.

Copy the audit logs to a USB drive and store it in a locked drawer

Why it fails: Copying logs to a USB drive creates no hash value, no write-blocked original and no documented transfer record, so chain of custody cannot be demonstrated. Physical media transfer suits isolated systems where imaging is impossible, but here it destroys evidentiary integrity.

ARP spoofing

Why it fails: ARP spoofing poisons layer-2 address resolution to redirect or intercept traffic on a local subnet; it does not generate the volumetric flood from many compromised devices described. It would be the right answer if the scenario involved man-in-the-middle interception within a LAN segment rather than server overload.

DoS

Why it fails: A DoS attack originates from a single source; the stem specifies many compromised devices, which is a distributed denial-of-service (DDoS). DoS is tempting because the symptom — a server overwhelmed so legitimate users cannot connect — is identical, but the source count is the distinguishing factor.

DNS poisoning

Why it fails: DNS poisoning corrupts resolver records so clients are redirected to attacker-controlled addresses; it does not itself produce overwhelming traffic volumes from many devices. It would fit a scenario where users reach a fraudulent site, not one where the legitimate web server is saturated and unavailable.

A parent process with a valid digital signature

Why it fails: A valid digital signature indicates a legitimately signed binary, which is a benign indicator rather than a malicious characteristic; attackers often use unsigned or stolen-certificate binaries. It is tempting because signature checks are part of triage, but a valid signature alone neither confirms nor suggests compromise.

A process with a long uptime and low CPU usage

Why it fails: Long uptime with low CPU usage describes a stable, idle legitimate process such as a service; malicious processes more often show short lifetimes, high CPU, or unusual network activity. It is tempting because persistence mechanisms do run quietly, but these metrics alone are not a recognised malicious indicator.

A process chain where the parent is svchost.exe and child is explorer.exe

Why it fails: svchost.exe spawning explorer.exe inverts the normal relationship: explorer.exe is the user shell and typically launches svchost-hosted services indirectly, so this chain suggests injection or masquerading. It is tempting because svchost.exe is a legitimate host process, but its presence as a parent of explorer.exe is the anomaly.

Chain of Custody Procedure

Why it fails: Pulling the cable destroyed volatile evidence such as running processes and memory contents; the violated procedure governs evidence preservation and order of volatility, not custody documentation. Chain of custody tracks who handled evidence after collection. It applies once artefacts are seized, not when live data is lost.

Forensic Analysis Procedure

Why it fails: Forensic analysis procedure governs how evidence is gathered and preserved, but the failure here is that volatile data was destroyed before acquisition, not that analysis was performed incorrectly. It would be the right answer if the team had collected data properly yet analysed it unsoundly.

Escalation Procedure

Why it fails: Escalation procedure defines when and to whom an incident is reported, not how the responder handles the host. Pulling the cable is a containment action, so escalation was not the violated control; it would apply if the responder had failed to notify the on-call team within the required timeframe.