The Analysis of User Data In VADs: Extraction of Precise Data in Notepad Memory And Hunting For Malware Behavior

This blog was coauthored by Nithin Chenthur Prabhu and Abdelrhman Mohamed.

Notepad is a common tool for windows users to jot down important notes or messages quickly. Beyond text files, Notepad can also open files in various known and unknown formats. However, over the years, adversaries have exploited Notepad as part of their malicious strategies, sometimes even disguising their activities by masquerading malicious processes as Notepad.

Given this trend, it’s important to understand what resides in Notepad’s process memory region. Advanced Persistent Threats (APTs) like Cozy Bear, Double Dragon, and Lazarus have utilized Notepad for process injection, DLL sideloading, shellcode or payload injection, and process hollowing.

We will look into methods for extracting user data from Notepad’s process memory and analyzing it for signs of malicious behavior.

To being our tests, we’ll use a Windows 10 virtual machine as a test environment. We launched Notepad and typed: “Abdelrhman and Azr43LKn1ght”.

If necessary, we can close Notepad, as its process will remain in memory for a short time. The first step is to capture the workstation’s memory using tools like FTK Imager’s Memory Capture, DumpIt.exe, or Magnet RAM Capture.

If the memory dump is not in .dmp format, it must be converted for compatibility with WinDbg. Tools like Volatility and MemProcFS can assist with this conversion. Once the memory dump (e.g., <file>.dmp ) is ready, we can process to debug it using WinDbg to analyze the captured Notepad process for signs of malicious behavior.

Before diving into the analysis, let’s examine the structure of memory in Windows. The operating system uses the _EPROCESS structure to represent a process. Each process has its own linear address space, called the Virtual Memory Space or Virtual Address Space, which is completely isolated from other processes.

This address space includes several key components:

• The core process executable: The main binary file of the process.
• Loaded modules: A list of all associated Dynamic Link Libraries (DLLs) an shared libraries.
• Process stack: Memory used for function calls and local variables.
• Process heaps : Memory areas for dynamic memory allocation.
• Virtual Address Descriptors (VADs): Regions of memory allocated by the process.

The structure of _EPROCESS is:

The Process Control Block (PCB), represented by the _KPROCESS structure, is located at the base of the _EPROCESS structure. The PCB contains essential fields like:

• DirectoryTableBase: Used for address translation.
• Total time spent in kernel mode and user mode: Tracks the process’s CPU’s usage.
• Process state: Indicated whether the process is running, waiting, or suspended.

Another critical field in _EPROCESS is ActiveProcessLinks, a doubly linked list that links all active processes on the machine. This list is fundamental to system process management, enabling tools like Task Manager and system APIs to navigate, access, and manage running processes effectively.

This structure is essential for operating system process management, as it facilitates efficient operations like process information retrieval and scheduling.

In 2010, a notorious malware called Prolaco exploited this system. It performed Direct Kernel Object Manipulation from user mode without any kernel space driver or rootkit. Prolaco achieved this by:

• Enabling SeDebugPrivilege using the ZwSystemDebugControl function.
• Accessing the first _EPROCESS object from PsInitialSystemProcess in the NT kernel module.
• Traversing the double linked list of _EPROCESS objects to locate its own malware process.
• Unlinking its process from the ActiveProcessLinks list by overwriting the flink (forward link) of next process and the blink (backward link) of previous process.

The PsActiveProcessHead is a global kernel variable that holds the address of the first process in the list of active processes.

The Process Environment Block (PEB) is a pointer in kernel mode that references an address in user mode. It holds critical information about a process, including:

• Pointers to the process's DLL lists.
• The current working directory.
• Command-line arguments.
• Environment variables.
• Details of heaps.
• Handles for standard input/output streams.

VadRoot is the root node of the VAD tree. The VAD tree holds detailed information about all memory segments allocated to a process. This includes the original access permissions which are read, write, or execute and whether a file is mapped to the memory region.

To begin analyzing the Notepad process, we first nee to locate the _EPROCESS block associated with notepad.exe. This can be achieved using the !process command in WinDbg:

!process 0 0 notepad.exe

The !process extension provides information about the specified process or all processes, including the _EPROCESS block. Here’s a breakdown of the command argument:

• First 0 argument specifies the process option, which in this case is set to 0, meaning "all process contexts."
• Second 0 argument specifies the "flags" parameter. A flag value of 0 means "minimal output."

We now know the _EPROCESS block’s address of notepad.exe is ffff8701845ce340

.process /r /p ffff8701845ce340

This command sets the debugger’s context to the specific process, notepad.exe. The /r switch tells WinDbg to reload the user-mode symbols and modules for the specified process. The /p switch forces the debugger to synchronize its process state with the target, halting the process execution to provide an accurate view of its memory and current state.

Before looking at the VAD tree, let’s first look at the PEB.

From this, we understand that the process heap base is 0x21f68490000 and heap parameters are:

• HeapSegmentReserve = 0x100000 (1MB)
• HeapSegmentCommit = 0x2000 (8KB)
• HeapDeCommitTotalFreeThreshold = 0x10000 (64KB)
• HeapDeCommitFreeBlockThreshold = 0x1000 (4KB)
• NumberOfHeaps = 0x4 (4 heaps)
• ProcessHeaps = 0x7fff55657d40 (pointer to array of heap handles)

From this, we get the heap allocation offsets from ProcessHeaps address that points to the heap handles.

From this, we get the heap allocation offsets:

0000021f68490000, 0000021f682a0000

0000021ef85b0000, 0000021f6a060000

Now, let’s look at the VAD tree for all memory allocations for our process. This can be accessed through the VadRoot field, located at offset 0x7d8 from the _EPROCESS structure.

We can see that the root of the VAD tree points to the first node which is at address 0xffff8701844d00a0.

Let’s inspect the root node of the VAD tree.

This node has two child nodes, each accessible via pointers. One child node is located to the left of the current node, and the other is to the right, depending on their respective positions in memory. By traversing the tree through these child nodes, we can reach a node that represents a heap allocation. Here, we will check the VADFLAGS and the allocation offsets for more memory allocation details.

Now, we can look at the node’s core to determine the offset of allocation. This will give us the starting and ending virtual address space offset.

Now, let’s look into the VADFLAGS.

 Lock = 0: The VAD is currently not locked for any operations.

 LockContended = 0: No other threads are waiting to acquire a lock on this VAD.

 DeleteInProgress = 0: The VAD is not being deleted.

 NoChange = 0: The VAD can be modified.

 VadType = 0: This is VadNone type, typical for normal memory allocations like heaps.

 Protection = 4: This means PAGE_READWRITE protection - the memory can be read from and written to this heap.

 PreferredNode = 0: No specific non-uniform memory access (NUMA) node preference for this memory.

 PageSize = 0: Using standard system page size (typically 4KB).

 PrivateMemory = 1: This is private memory, not shared with other processes.

Let’s look into the starting and ending offset of the heap allocation. StartingVpn is 0x21f6a060 and the EndingVpn is 0x21f6a06f. Since the page size is 4096 bytes (or 0x1000), the resulting address range will be 0x21f6a060000 - 0x21f6a06f000.

Now, let’s look into HEAP structure of our heap address.

The first entry in the heap is located at 0x21f6a060740, while the last valid entry is at 0x21f6a06f000, which is also the EndingVpn. Before that we will have to look into _HEAP_ENTRY of encoding of the first heap allocation.

Let’s look into the first _HEAP_ENTRY.

Here, we use the CompactHeader from the encoding to calculate the heap allocation size. To do this, we perform an “Exclusive OR” with the second QWORD of the heap entry, which is 10000b49`bfddfc08. The result is 0x0003 as the last word.

When multiplied by 0x10, this value gives us 0x30, which is the size of the entire heap allocation. Adding this size to the starting address gives us: 0x21f6a060770.

Now, using the same process, we can get 0x20, which will give us the next heap allocation, 0x21f6a060790.

Now we can list all heap memory allocations of our process with !heap -s -v -a.

The -s flag provides a summary of all the heaps, including details like total size, number of segments, number of blocks, and other statistics. This flag is useful for getting an overall picture of the heap usage in the process.

The -v flag is used for more detailed output to the command, such as specific heap flags, debugging information, and metadata about each heap. This level of detail can help in understanding the state and properties of each heap in-depth.

The -a flag is used to display all memory blocks allocated in the heap, including their sizes, addresses, and other properties. This is useful for finding patterns, such as unusual memory blocks or potential injected code.

Now we can look into the heap we analyzed.

This will be same as the size and allocations we calculated.

We also have to parse all the subsegments. The offset of LFH Heap will be in the heap’s FrontEndHeap, which is 0x21f69dc0000.

From here, we can go to the subsegment zone and look at the subsegment zone header.

Here, the fourth QWORD is 0x9, which tells us that there are a total of nine subsegments in this particular zone. Now, let’s look into the first subsegment that starts after the zone header, which is 0x20 bytes.

Here, the UserBlocks start at 0x0000021f6a063c60, so let’s look at the header of the UserBlock.

The header is 0x40 bytes, so the first allocation will start at 0x0000021f6a063ca0. The total allocations will be 0x13 in count and 0x30 bytes in size, as mentioned in subsegment header.

We have all the allocations, but the heaps that need to be analyzed are the segment0x0 heaps, not the LFH and subsegments which will have user_flag.

Now, let’s look into a heap entry, its flags, and its significance.

HEAP_ENTRY_BUSY: Indicates if a memory block is currently in use (1) or free (0) - this is the fundamental allocation status flag.

HEAP_ENTRY_EXTRA_PRESENT: Signals that the heap block contains additional metadata beyond the standard header structure.

HEAP_ENTRY_FILL_PATTERN: Shows that the block is filled with a specific pattern, typically used for detecting memory corruption or buffer overflows.

HEAP_ENTRY_INTERNAL: Marks blocks that are reserved for the heap manager's internal use rather than application allocation.

HEAP_ENTRY_VIRTUAL_ALLOC: Identifies memory blocks that were allocated directly through VirtualAlloc instead of normal heap allocation.

HEAP_ENTRY_USER_FLAGS: This flag is used to indicate whether a memory block is marked for user-defined purposes, which can be helpful for debugging or tracking allocations in a more customized way. Reserved space for application-specific flags, allowing custom metadata to be associated with heap blocks.

HEAP_ENTRY_SETTABLE_FLAG1: First user-definable flag that can be used for custom memory management implementations.

HEAP_ENTRY_SETTABLE_FLAG2: Second user-definable flag available for custom memory tracking or debugging purposes.

We have many heaps for this process, but we need only those that have extra user_flag.

Now, let’s look at the heap contents. For this we can use db 0000021ef85b2ad0 L80.

Now, we have successfully extracted the desired information from memory! This method can be applied to any file opened in notepad.exe, making it straightforward to recover any file opened in notepad.exe from a memory image.

Now, let’s make a custom notepad-like application. This will provide better understanding of heap allocations.

Debugging the process and analyzing, we are able to get the heap allocation, which is:

Let’s do that on real malware with the malware sample of brbbot.exe.

1 Find Process _EPROCESS (core).

2 Set Debugger Process context.

3. Now, let’s look into all the heap allocations.

As this is an actual malware process without any user defined heap allocations, we need to check all heaps associated with the process, not just the user_flag or extra heaps. The first heap address is 0000000001300000, and last heap address is 00000000016f5fd0. It’s better to view all the contents of the particular heap allocation. To do this, we can use the WinDbg command: db 0000000001300000  L 80000.

Further analysis on the malware’s heap allocations shows that it maintains a network connection with the threat actor’s server. During its execution in the system’s background, the malware sends encrypted data to the attacker’s server.

Takeaways and Applications

In this blog post, we explored heap memory management within Windows, focusing on the structure and functionality of _HEAP_ENTRY and the significance of its various flags in determining the state of memory allocations. We learned:

• What is heap memory allocation in Windows and how it is managed.
• The structure of process memory in Windows.
• How to manually analyze heap allocation and subsegment allocations.
• The process of decoding _HEAP_ENTRY and understanding its associated flags and their uses.
• The role of heap protections and how to analyze user-defined and program-defined heap allocations.

The ability to manually parse heap allocations allows for deeper insights into application behavior. This understanding enables more informed decisions regarding reverse engineering and digital forensics and incident response (DFIR) analysis of malwares and other Windows applications.

As we continue to navigate the complexities of memory management, the insights gained from these structures will remain invaluable for enhancing Windows core analysis skills.

Explore more DFIR resources and stay ahead in the ever-evolving field. Join the SANS community today to stay connected to the latest insights and innovations.