Select Two (Multi-Select) Questions

hivelist

Why it fails: hivelist lists registry hives, not process-specific.

connscan

Why it fails: connscan scans for network connections, not process-specific info.

HKEY_CLASSES_ROOT\*\shell

Why it fails: Shell keys under HKEY_CLASSES_ROOT define context-menu handler commands, executing on user interaction rather than at logon. It tempts because shell extension hijacking is real persistence, and this path is correct when investigating right-click menu-based execution instead of Run keys.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\AppInit_DLLs

Why it fails: AppInit_DLLs loads a DLL into every process loading User32.dll, which is process-injection persistence, not logon Run-key execution. It tempts because it is a legitimate, frequently abused autostart location, and it is the right answer when the question asks about AppInit persistence.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Why it fails: Services keys host Windows service executables and drivers, giving persistence via service creation rather than logon Run keys. It tempts because services are a genuine, widely abused autostart mechanism, and this path is the correct answer when investigating service-based persistence instead.

Printer spool logs.

Why it fails: Not security-relevant.

HVAC system logs.

Why it fails: Operational, not security.

Enable Telnet for remote management

Why it fails: Telnet transmits management credentials and sessions in cleartext, so anyone capturing traffic can read them, defeating the hardening mandate. It tempts because Telnet is simple and universally supported, but hardening requires SSH or an encrypted management channel instead.

Use default credentials for initial setup

Why it fails: Default credentials are publicly documented, so leaving them enabled lets anyone authenticate to the device, directly contradicting hardening. It tempts as a convenient starting point during initial provisioning, but hardening requires changing them immediately; the correct practice is disabling unused services and applying ACLs.

Social engineering

Why it fails: Social engineering targets people through phishing or pretexting, generating no network traffic for a firewall to inspect, so it cannot be blocked by packet rules. It is tempting because it is a recognised reconnaissance category, and would be addressed through security awareness training and email filtering instead.

WHOIS lookups

Why it fails: WHOIS queries hit public registry servers, not the target's hosts, so firewall rules on the perimeter cannot intercept them; they are passive reconnaissance. Blocking them is tempting because WHOIS reveals registrant and DNS ownership data, useful when mapping an external footprint from third-party sources rather than active probing.

Delete the alert to reduce noise

Why it fails: Deleting the alert destroys the audit trail and evidence required for investigation, reporting and compliance. It is tempting because it clears queue noise quickly, but genuine noise reduction uses tuning, suppression rules or false-positive marking, never deletion of a critical detection record.

Search for similar alerts in the past

Why it fails: Historical correlation is a later triage step; the immediate priority is containing the threat and preserving volatile evidence. It is tempting because reviewing past similar alerts does build context and identify campaigns, but doing it before containment delays response to an active critical incident.

Immediately power off the affected system

Why it fails: Powering off destroys volatile memory, running processes and network connections that forensics needs, and may alert the attacker. It is tempting because it appears to stop the threat instantly, but isolation from the network achieves containment while preserving evidence for investigation.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Why it fails: Winlogon persistence abuses the Shell, Userinit or Notify values, not a Run key, so it fails the stem's specific requirement. It is tempting because Winlogon is a well-known autostart location, and it would be correct if the question asked which key hosts Userinit rather than Run.

HKLM\System\CurrentControlSet\Services

Why it fails: The Services subkey stores installed service definitions, which malware can abuse, but it is not a Run key; persistence there requires creating or modifying a service. Run keys sit under CurrentVersion\Run in HKLM or HKCU, which is what the question asks for.

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Why it fails: User Shell Folders defines profile path locations, not autostart entries, so writing here does not execute code at logon. It is tempting because it sits under the same Explorer key tree as genuine Run keys, but it would only be the answer if the question asked where folder redirection paths are configured.

HTTP 404 errors generated by users mistyping URLs in the browser.

Why it fails: HTTP 404 errors from mistyped URLs are common user errors and do not indicate data leaving the network. They involve small requests and no uploads. While they can clutter logs, they are not a suspicious pattern for exfiltration and should not be treated as such.

Repeated GET requests to the same internal web server for static images.

Why it fails: Repeated GET requests for static images on an internal server are typical of normal web browsing or application behavior. They do not involve external destinations or large uploads, so they are not indicative of data exfiltration. This pattern is benign and should not be prioritized as suspicious.

Downloading software updates from a known vendor's HTTPS site.

Why it fails: Downloading updates from a known vendor over HTTPS is normal, expected traffic. It is inbound rather than outbound data, and the destination has a trusted reputation. This activity does not match exfiltration patterns, which involve outbound data transfer to untrusted or new destinations.

/etc/init.d/

Why it fails: /etc/init.d/ contains SysV init scripts executed at boot by the init daemon, not entries in a cron schedule. It is tempting because it is a legitimate Linux persistence path, and would be correct if the question concerned legacy init-based startup persistence instead of cron-based mechanisms.

/var/log/cron

Why it fails: `/var/log/cron` stores historical execution logs for cron jobs, not the job definitions themselves. For persistence, an analyst must inspect the crontab files or directories (e.g., `/etc/crontab`, `/var/spool/cron/`) where scheduled commands are declared. It is tempting because cron logs confirm that jobs have run, which could mislead an investigator into thinking the log file itself is the persistence mechanism, whereas it merely records the output of a separate, pre-existing cron task.

/etc/systemd/system/

Why it fails: /etc/systemd/system/ holds systemd unit files, which provide service-based persistence through systemctl enable, not cron scheduling. It is tempting because it is a genuine Linux persistence location, and would be the right answer if the question asked about systemd services rather than cron jobs.

/proc/cpuinfo

Why it fails: /proc/cpuinfo exposes processor model, cores, and flags — static hardware data regenerated at boot, with no persistence or timestamps. It is tempting because /proc entries are volatile and attacker-touchable, and cpuinfo would be relevant when profiling host capability during malware analysis rather than proving compromise.

/etc/passwd

Why it fails: /etc/passwd holds local account definitions, not authentication events; a modified entry shows account tampering but no login, process, or command history. It is tempting because attackers do add rogue accounts, and passwd would be the right artefact when auditing unauthorised local user creation.

/var/log/auth.log

Why it fails: auth.log records authentication events such as logins and sudo use, which reveal access attempts but not the scheduled jobs, services or startup scripts that re-execute malware after reboot. It is tempting because it exposes attacker activity, yet persistence identification relies on cron, systemd units and init files instead.

~/.bash_history

Why it fails: bash_history shows commands typed interactively, which may hint at how malware was installed, but it captures no mechanism that automatically restarts on boot. It is tempting because it can reveal attacker tooling, yet persistence requires examining cron jobs, systemd units or rc scripts rather than shell command history.

Correlating multiple alerts

Why it fails: Correlating multiple alerts is Tier 2 escalation work, joining related detections into an incident. Tier 3 conducts deep forensic analysis, reverse engineering and adversary tracking. Alert correlation fits a Tier 2 analyst validating and enriching escalated incidents.

Monitoring SIEM dashboards

Why it fails: Monitoring SIEM dashboards is Tier 1 triage work, watching queues and escalating alerts. Tier 3 instead performs proactive threat hunting, malware reverse engineering and detection engineering. Dashboard monitoring would be correct for a Tier 1 analyst handling initial alert review.

Initial triage of alerts

Why it fails: Tier 3 handles deep-dive hunting, malware reverse engineering and incident containment, not queue triage. Alert triage belongs to Tier 1, which owns the monitoring queue and escalates validated incidents upward. Choosing this confuses the escalation ladder's entry rung with its advanced-analysis rung.

Clear the network logs to ensure accurate analysis.

Why it fails: Clearing logs destroys the very evidence needed to trace an exfiltration attempt, directly obstructing the investigation. It is tempting as a way to remove noise before analysis, but log retention is the correct practise; clearing is appropriate only under a defined retention policy after evidence is preserved.

Focus exclusively on inbound traffic from external sources.

Why it fails: Exfiltration moves data outward, so inbound-only inspection misses the outbound flows carrying stolen data to external command-and-control or drop servers. It is tempting because inbound traffic often carries the intrusion vector, and would suit detecting initial exploitation rather than data leaving the network.

Immediately block all outbound traffic from the suspect host.

Why it fails: Blocking all outbound traffic halts the exfiltration but destroys the evidence trail and disrupts legitimate business flows, preventing scope assessment. It is tempting as an immediate containment reflex, and would be right during active incident response once analysis is complete, not while analysing traffic.

Better suited for protecting a large number of devices simultaneously.

Why it fails: HIDS agents must be installed and maintained per host, so scaling to many devices multiplies deployment and management overhead. NIDS sensors sit at network chokepoints and cover all downstream hosts from one point, making NIDS the choice for broad simultaneous coverage.

Less susceptible to host-based attacks.

Why it fails: HIDS runs on the host it monitors, so it cannot be less susceptible to attacks against that same host; compromise of the host typically compromises the agent. It is tempting because HIDS analyses host internals such as file integrity and system calls, which NIDS cannot see, making it the right pick when detecting local privilege escalation or tampering.

Lower latency in detecting network attacks.

Why it fails: HIDS monitors host logs, file integrity and system calls, so it cannot observe network traffic and therefore adds no network-attack detection latency advantage. NIDS inspects packets at network segments, giving it that visibility; HIDS is chosen for endpoint-level compromise detection instead.

A single successful login from a known IP during business hours.

Why it fails: One successful login from a recognised IP within working hours matches normal user behaviour and shows no failure pattern. Brute force is identified by repeated authentication failures, not a single success. This entry is tempting because any login can precede compromise, but a solitary legitimate-looking success lacks the volume needed.

A failed login attempt from an external IP at 3:00 AM.

Why it fails: A lone failed login from an external IP, even at an odd hour, is routine internet noise and shows no repetition. Brute force requires many rapid failures against one account or host. This entry is tempting because the time and external source look alarming, but volume, not timing, is the indicator.

A user changing their password after a successful login.

Why it fails: Changing a password after authenticating is ordinary account maintenance and involves no failed attempts. Brute force manifests as many rapid authentication failures, which this entry does not contain. It is tempting because credential changes can follow compromise, yet a single routine change without preceding failures is not suspicious.

To reduce network latency for monitored traffic

Why it fails: Proxies add an inspection hop, caching and policy checks that increase latency rather than reduce it. It is tempting because caching genuinely speeds repeated content delivery, making a proxy correct when the requirement is bandwidth conservation or faster retrieval of frequently requested resources.

To provide a complete log of all network traffic for forensics

Why it fails: A proxy logs only the sessions routed through it, so traffic bypassing it or using non-proxied protocols is absent, preventing a complete forensic record. It is tempting because proxy logs are rich and centralised, making them correct when the requirement is application-layer visibility for web-bound traffic.

To replace the need for endpoint anti-malware software

Why it fails: A proxy inspects and logs traffic flows; it cannot scan endpoint filesystems, memory or processes, so malware on a host remains undetected. It is tempting because proxies do filter URLs and block malicious destinations, which is genuinely useful for egress control and web monitoring, but that is content inspection, not host protection.

Kerberoasting

Why it fails: Kerberoasting targets service accounts.

Brute force

Why it fails: Brute force tries passwords.

Golden ticket

Why it fails: Golden ticket forges Kerberos tickets.

SMTP logs

Why it fails: SMTP logs are specific to email and less common as a primary SIEM source.

SNMP traps

Why it fails: SNMP traps are more for network performance monitoring than security events.

DNS queries

Why it fails: DNS logs can be security-relevant but are not a primary SIEM source.

IP address whitelist

Why it fails: IP address is a location factor, not a standard MFA factor.

Password

Why it fails: Password is a knowledge factor, but MFA requires two different factors; password alone is not MFA.

Security question

Why it fails: Security question is a knowledge factor, same category as password.

Store the evidence in a public folder for easy access

Why it fails: Storing evidence in a public folder destroys its integrity: shared permissions allow anyone to alter or delete files, breaking the chain of custody required for legal proceedings. It is tempting as a convenient way to share artefacts with investigators, which would suit informal collaboration, not evidence destined for court.

Delete any sensitive files to protect privacy

Why it fails: Deleting files destroys evidence and breaks the chain of custody, potentially making the artefacts inadmissible. It is tempting when the files contain personal data, and deletion would be correct under a data-retention policy outside a legal hold or active investigation.

Run the system normally to capture volatile data

Why it fails: Running the system normally alters timestamps, logs and memory state, contaminating evidence; volatile data must be captured with approved forensic tooling first. It is tempting because live data is valuable, and running the system would be correct during routine incident triage where legal admissibility is not required.