CS0-003 Security Operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Registry Run keys

  Why this is correct

  The registry Run key (HKLM\Software\Microsoft\Windows\CurrentVersion\Run) is a classic autostart persistence mechanism; a command using reg.exe to add a value there explicitly indicates the attacker intends to execute a payload at user logon. Inspecting this key for the malicious entry is the highest-priority action because the observed telemetry directly aligns with this persistence method, and the associated binary path or command can be identified and remediated. This is not merely incidental—the command's purpose is to modify this specific key.

• ✗

  Windows Event Logs for service creation

  Why it's wrong here

  Windows Event Logs for service creation are indeed a valuable persistence detection source, with Event ID 7045 logging new service installations, but this activity typically results from commands like `sc create` or the Service Control Manager API, not a `reg add` command. Since the observed command targets a registry Run key rather than creating a service, checking service creation logs would not reveal the persistence mechanism used by this attacker. However, defenders should still review these logs for secondary persistence methods, as attackers often deploy multiple techniques.

• ✗

  Browser history

  Why it's wrong here

  Browser history is completely unrelated to the command-line telemetry indicating registry persistence; it records web browsing activity such as visited URLs and search queries, which could reveal C2 infrastructure or download sources but says nothing about the registry modification in question. A threat hunter would not look at browser history to confirm or deny persistence via a Run key, and doing so would waste time while the immediate persistence vector remains unchecked. This option is a distraction from the relevant endpoint forensics.

• ✓

  Scheduled tasks

  Why this is correct

  Scheduled tasks are another heavily abused persistence mechanism, commonly created via `schtasks.exe /create` to execute a payload at logon or on an interval, and the threat hunter may see corresponding command-line telemetry if the attacker used this method. In this scenario, the specific command shown appears to be a registry modification, but scheduled tasks are still worth checking because attackers frequently combine persistence mechanisms for redundancy, and a scheduled task might reference the same malicious binary or command. Therefore, this is a valid area to investigate alongside the Run key.

• ✗

  Network connections

  Why it's wrong here

  Network connections are not directly related to registry persistence; examining network connections (e.g., netstat or network flow logs) would reveal active C2 communication or data exfiltration, which is a post-persistence behavior, not the persistence mechanism itself. The `reg add` command is a local, atomic operation that does not involve network sockets, so checking connections would not help verify the Run key change. While network telemetry is useful for detecting the attacker's later actions, it is not the immediate priority for confirming this persistence technique.

Go deeper

Related to this question