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.

• ✗

  List the process's open handles

  Why it's wrong here

  Listing a process's open handles reveals its resources, such as files, registry keys, and synchronization objects, but these are not specific to code injection. Injected shellcode often runs entirely within the existing process context without opening or accessing new handles, since it may only need to use already-loaded APIs or raw memory. While handle enumeration can expose suspicious activity like a process accessing a known malware file, it does not directly confirm the presence of foreign executable code in memory.

• ✗

  Examine the process's environment variables

  Why it's wrong here

  Environment variables are inherited from the parent process and can be modified at runtime, so they are not a reliable indicator of code injection. Malware may occasionally store data in environment variables, but the injection process itself—typically using VirtualAllocEx and WriteProcessMemory—does not alter them. Examining environment variables could reveal artifacts like a path to a malicious executable, but it cannot validate whether a process's memory contains injected code.

• ✗

  Check the process's parent process

  Why it's wrong here

  Checking the parent process can help identify suspicious execution chains, such as a script host launching PowerShell, but code injection does not change the parent PID. Injected code is executed in the context of the existing process, so the parent relationship remains exactly as it was before the injection. Parent-process analysis is more useful for detecting process hollowing, where a legitimate process is replaced, or for tracing initial infection vectors, but it is not a direct indicator of in-memory injection.

• ✓

  Scan for executable memory pages not backed by a file on disk

  Why this is correct

  A definitive sign of code injection is the presence of an executable memory region that is not backed by an on-disk file. Malicious shellcode is often allocated with VirtualAllocEx and written via WriteProcessMemory, producing a private, executable page that does not map to any section object. Memory forensics tools like Volatility's malfind enumerate the Virtual Address Descriptor (VAD) tree to identify such executable pages without a backing file, making this technique a core method for detecting fileless injection.

• ✓

  Compare the loaded DLL list with known good baselines

  Why this is correct

  Comparing the loaded DLL list to a known-good baseline can reveal unauthorized modules, such as a malicious DLL injected into a process via the LoadLibrary technique. This approach is a valid detection method because unexpected DLLs or missing DLLs may indicate tampering. However, it is less comprehensive than scanning for executable memory pages, as reflective DLL injection or pure shellcode may not appear in the module list at all. Nonetheless, DLL baseline comparison is a valuable complementary check during a memory forensics investigation.

Go deeper

Related to this question