300-215 practice question 4 of 25

Data has been exfiltrated and advertised for sale on the dark web. A web server shows: Database unresponsiveness PageFile.sys changes Disk usage spikes with CPU spikes High page faults Which action should the IR team perform on the server?

Full set: 131 questions
Answer options
A: Review the database.log file in the program files directory for database errors
B: Examine the system.cfg file in the Windows directory for improper system configurations
C: Analyze the PageFile.sys file in the System Drive and the Virtual Memory configuration Correct answer
D: Check the Memory.dmp file in the Windows directory for memory leak indications
Correct Answer:
C. Analyze the PageFile.sys file in the System Drive and the Virtual Memory configuration
Explanation

The combination of symptoms—high page faults, changes to PageFile.sys, and correlated disk and CPU spikes—are classic indicators of a condition known as "thrashing." This occurs when the system's physical memory (RAM) is exhausted, forcing the operating system to excessively swap memory pages to and from the virtual memory file (PageFile.sys) on the disk. This heavy I/O activity causes the performance degradation. In an incident response context, this behavior is highly suspicious and could be caused by a malicious process staging large amounts of data (e.g., from the database) in memory before exfiltration. Analyzing the virtual memory configuration and the page file is the most direct way to identify the offending process and potentially recover forensic artifacts.

Why Incorrect

A. Reviewing database logs is a secondary action. The symptoms point to an OS-level memory contention issue causing the database unresponsiveness, not an intrinsic database error.
B. system.cfg is not a standard, critical Windows configuration file. The symptoms indicate a dynamic, runtime problem, not a static system misconfiguration.
D. A Memory.dmp file is a system crash dump. The scenario describes an unresponsive server, not one that has crashed (i.e., generated a Blue Screen of Death). ---

References

1. Official Vendor Documentation (Microsoft):

Microsoft Corporation. (2023). Troubleshoot high-memory-usage issues. Microsoft Learn. This document explains how to use tools like Performance Monitor to diagnose memory issues by observing counters such as Page Faults/sec. It directly links high page faults to insufficient memory and the use of the page file

validating the analysis of the symptoms. (Reference Section: "Collect data").

Microsoft Corporation. (2023). Overview of memory management. Microsoft Learn. This document details the role of the Virtual Memory Manager (VMM) and the page file (Pagefile.sys) in Windows

providing the foundational knowledge that changes to this file and high fault rates are central to memory pressure analysis. (Reference Section: "Pagefiles").

2. Official Vendor Documentation (Cisco):

Cisco Systems

Inc. (2016). Incident Response: Live Data Collection from Windows Systems. Cisco White Paper. This guide outlines critical data to collect from live Windows systems during an incident. It emphasizes collecting information about running processes

memory usage

and network connections to identify malicious activity

which aligns with investigating the process causing the memory pressure described in the scenario. (Reference Section: "Volatile Data Collection Procedure

" Step 4: "Processes").

3. University Courseware / Reputable Institution:

Hogan

M. (2012). Remnants of an Attack: A Pagefile Analysis. SANS Institute InfoSec Reading Room. This SANS Gold paper

a resource used in advanced cybersecurity education

details the forensic value of Pagefile.sys. It explains that the page file can contain fragments of data

passwords

and other artifacts from running processes

making its analysis crucial during an investigation involving data staging or exfiltration. (Reference Section: "What is the Pagefile and Why Do We Care?").

Scroll to Top