Unit 6: Advanced Malware Detection Using Memory Forensics - Subjective Questions

Code injection is a technique in which malicious code is inserted into the address space of another process and executed under that process's identity.

Memory forensics is effective because it can reveal artifacts that may not exist on disk, including:

• Executable memory regions that are not backed by legitimate files.
• Memory pages having suspicious permissions such as PAGE_EXECUTE_READWRITE.
• Injected DLLs that are absent from normal loader lists.
• Threads whose starting addresses lie outside known executable modules.
• Portable Executable headers, shellcode, or obfuscated instructions in private memory.

Tools such as Volatility can use malfind, vadinfo, memmap, and thread-analysis plugins to identify suspicious memory regions. The detected pages can then be dumped and examined with disassemblers, antivirus scanners, or YARA rules.

A systematic investigation can be performed as follows:

1. Identify suspicious processes: Examine process lists, parent-child relationships, command lines, sessions, and creation times.
2. Inspect virtual memory: Review Virtual Address Descriptor regions for private, executable, or writable-executable pages.
3. Check memory permissions: Give special attention to regions with permissions such as RWX or private RX.
4. Examine content: Search suspicious pages for PE headers, shellcode patterns, API-resolution loops, or high-entropy data.
5. Inspect threads: Determine whether any thread begins execution inside an unbacked or injected region.
6. Compare module views: Detect modules present in memory but missing from Process Environment Block loader lists.
7. Dump suspicious regions: Extract them for static analysis, disassembly, hashing, YARA scanning, and sandbox analysis.
8. Correlate evidence: Combine memory findings with handles, network connections, registry artifacts, and process ancestry.

No single indicator is conclusive. A strong conclusion should be based on several correlated anomalies.

A Virtual Address Descriptor, or VAD, is a kernel data structure used to describe a continuous virtual memory range allocated to a process. It records information such as the starting and ending addresses, memory protection, allocation type, and whether the region is associated with a mapped file.

VAD analysis helps detect injection by revealing:

• Private executable regions: Injected shellcode is often placed in private memory rather than a mapped image.
• Writable-executable memory: RWX regions can allow an attacker to write and execute code in the same area.
• Executable regions without file backing: Legitimate program images are usually associated with executable files.
• Protection inconsistencies: A VAD may report one protection while its page-table entries show unexpected permissions.
• Hidden PE images: Memory may contain MZ or PE signatures even though the region is not listed as a normal module.

VAD findings should be correlated with thread start addresses and memory contents because legitimate software, including just-in-time compilers, may also create private executable pages.

Process hollowing is an injection technique in which an attacker creates a legitimate process and replaces its original executable image with malicious code while retaining the process's trusted identity.

The major stages are:

1. A legitimate process is created in a suspended state, commonly with CreateProcess and the suspended-process flag.
2. The attacker obtains the target process's context and image base.
3. The original executable image is removed or unmapped, for example through NtUnmapViewOfSection.
4. Memory is allocated inside the suspended process.
5. A malicious executable image is copied into the allocated space.
6. Relocations and imports may be repaired if the malicious image is loaded at a different base address.
7. The thread context or entry-point address is modified to point to the malicious image.
8. The primary thread is resumed, causing the malicious code to execute under the legitimate process name.

This technique can evade tools that trust process names or executable paths without validating memory-resident images.

A hollowed process can be identified by comparing information from several independent memory structures.

Important indicators include:

• The executable path in process metadata appears legitimate, but the main image in memory has different content.
• The Process Environment Block image base does not correspond correctly to the expected mapped executable.
• The in-memory PE header, section layout, entry point, or hash differs from the executable on disk.
• The main image region is private memory rather than a normal image-backed mapping.
• The thread instruction pointer or start address points to a suspicious region.
• Loader lists contain missing, inconsistent, or unusual module entries.
• Memory protections and VAD metadata do not match normal PE section permissions.
• Imports, relocations, or PE metadata show signs of manual reconstruction.

A reliable investigation should dump the main process image, rebuild it if necessary, compare it with the disk file, inspect its entry point, and correlate the findings with process creation and thread artifacts. Differences caused by normal relocations or runtime patching must not be treated as hollowing without supporting evidence.

Classic DLL injection:

• Loads a DLL into another process, often using LoadLibrary.
• The DLL is commonly file-backed and may appear in standard loader lists.
• Investigators may detect an unexpected module, suspicious path, or remote thread.

Reflective DLL injection:

• Loads a DLL directly from memory using a custom loader.
• The DLL may not be written to disk or registered in normal loader lists.
• It may appear as a private executable region containing a PE image.

Process hollowing:

• Creates or uses a legitimate process and replaces its original image with malicious content.
• The process name and path may remain legitimate while the memory-resident image is different.
• Investigators look for mismatches among the Process Environment Block, VADs, loader lists, thread entry points, and disk image.

Thus, classic injection usually adds a conventionally loaded module, reflective injection manually maps a hidden module, and hollowing replaces or disguises the main process image.

An API hook is a modification that redirects an API call from its intended implementation to another function or code region.

Malware installs API hooks to:

• Intercept sensitive data such as passwords, keyboard input, or network traffic.
• Hide files, processes, registry entries, modules, and connections.
• Alter the results returned by security or system-management functions.
• Monitor application behavior and steal data before encryption.
• Redirect execution to malicious routines.
• Maintain persistence or control over selected system operations.

Hooks may be implemented by modifying an Import Address Table, Export Address Table, inline function instructions, callback pointer, or kernel dispatch table. Hooks are not automatically malicious because debuggers, security products, and compatibility tools also use them. Investigators must validate the hook destination and associated module.

Import Address Table hooking:

• Replaces a function pointer in a module's Import Address Table.
• Affects calls made through the modified import entry.
• Can be detected by checking whether the pointer falls inside the expected exporting module.

Export Address Table hooking:

• Alters an exported function address in a module's Export Address Table.
• Can affect callers that resolve the function after the modification.
• Detection involves comparing export addresses with a trusted module image and expected section boundaries.

Inline hooking:

• Overwrites the first instructions of a function with a branch to another location.
• Can redirect both direct and dynamically resolved calls.
• Common signs include unexpected jump or call instructions at a function entry point and a trampoline containing displaced instructions.

IAT and EAT hooks primarily modify pointer tables, whereas inline hooks alter executable code. Each technique should be verified by checking whether the redirection target belongs to a legitimate, signed module or to suspicious private memory.

API-hook detection involves identifying redirections and determining whether they are legitimate.

Detection procedure:

1. Enumerate process modules and their address ranges.
2. Inspect IAT and EAT entries for pointers outside the expected module.
3. Disassemble important API entry points and look for unexpected branches, trampolines, or overwritten instructions.
4. Compare in-memory code bytes with a trusted copy of the same module version.
5. Identify the final destination of each suspicious redirection.
6. Determine whether the destination lies in a known signed module, an unlisted module, or private executable memory.
7. Dump and analyze the destination region for shellcode or malicious PE content.
8. Correlate the hook with process activity, network evidence, and other compromise indicators.

Investigators must account for operating-system hot patches, endpoint security software, instrumentation frameworks, and legitimate compatibility hooks. A hook becomes strongly suspicious when it redirects into unknown or unbacked executable memory.

A kernel-mode rootkit is malicious code that executes with kernel privileges and modifies or abuses kernel components to conceal activity, control the operating system, or interfere with security tools.

Detection is difficult because a kernel rootkit can:

• Modify kernel data structures and function pointers.
• Hide processes, drivers, files, network endpoints, and registry objects.
• Intercept system calls and I/O requests.
• Disable or deceive security software.
• Remove itself from standard driver and module lists.
• Manipulate the same operating-system APIs used by live forensic tools.

Memory forensics reduces this trust problem by analyzing an acquired memory image externally. Investigators can compare linked-list enumeration with pool scanning, validate pointers against known modules, inspect executable kernel memory, and detect inconsistencies that a rootkit cannot easily hide across every kernel structure.

Kernel modules can be listed by walking the operating system's normal loaded-module structures. This produces information such as the module name, base address, size, and path. Volatility-style frameworks may provide plugins such as modules or their equivalents for this purpose.

A rootkit may unlink its driver from the official loaded-module list. Therefore, investigators also use scanning methods such as modscan or pool-tag scanning to locate module and driver objects directly in memory.

Cross-view analysis compares:

• Modules obtained from the official linked list.
• Modules found by physical-memory scanning.
• Driver objects found through object-manager structures.
• Executable kernel regions and address ranges referenced by callbacks or dispatch tables.

A module found by scanning but absent from the normal list may be hidden or unloaded. The investigator must validate timestamps, object state, memory reuse, and executable contents because stale structures can create false positives.

When an unknown kernel module is discovered, the investigator should perform the following checks:

• Record its base address, size, name, path, and load order.
• Determine whether it appears in all expected module and driver enumeration views.
• Verify that its memory range contains a valid PE image and sensible section boundaries.
• Calculate cryptographic hashes and compare them with trusted software inventories and threat intelligence.
• Examine digital-signature and certificate information when recoverable.
• Compare the in-memory image with its corresponding disk file.
• Inspect imported APIs, strings, embedded configuration, and suspicious device names.
• Check whether callbacks, timers, SSDT entries, interrupt handlers, or driver dispatch routines point into it.
• Search for writable-executable sections, unpacked payloads, and modified code.
• Correlate the module with process, network, registry, and persistence evidence.

The module should not be classified as malicious solely because it is unfamiliar; hardware vendors and security products commonly install legitimate third-party drivers.

An I/O request packet, or IRP, is a kernel data structure that represents an I/O operation as it travels through one or more drivers.

I/O processing generally works as follows:

1. An application or kernel component requests an operation such as read, write, create, close, or device control.
2. The I/O manager creates an IRP containing the operation code, buffers, status information, and stack locations.
3. The IRP is sent to the target device's driver stack.
4. Each driver processes the request, passes it to a lower driver, completes it, or registers a completion routine.
5. The final status and data are returned to the requester.

A driver object contains a MajorFunction table whose entries point to dispatch routines for major IRP operations. Rootkits may replace these pointers or attach a malicious filter driver to intercept requests. Memory investigators therefore validate whether dispatch addresses belong to the expected loaded driver modules.

Driver dispatch-table analysis focuses on the function pointers stored in a driver object's MajorFunction array.

Detection steps include:

1. Enumerate driver objects and obtain their associated driver modules.
2. Extract dispatch addresses for operations such as create, read, write, close, and device control.
3. Map every dispatch address to the kernel module containing that address.
4. Flag pointers that fall outside the owning driver or outside all known modules.
5. Inspect suspicious destinations for trampolines, shellcode, or hidden modules.
6. Compare dispatch entries with a trusted system of the same operating-system build and driver version.
7. Examine attached device stacks to determine whether a filter driver legitimately handles the request.
8. Correlate anomalies with hidden drivers, callbacks, timers, and executable pool allocations.

A pointer into another driver is not automatically malicious because legitimate filter and framework drivers may redirect I/O. The ownership, purpose, signature, and code at the destination must be validated.

A device tree is a hierarchical representation of driver and device objects that shows how the operating system organizes hardware, logical devices, and attached driver stacks.

Displaying device trees can reveal:

• Driver objects and the device objects they control.
• Physical, functional, and filter device relationships.
• Device names and symbolic links.
• Drivers attached above or below another driver.
• Storage, keyboard, network, and file-system filter components.
• Unexpected or unnamed device objects created by malware.
• Hidden drivers that remain connected to active device stacks.

This analysis is valuable because a rootkit may hide its module from a loaded-module list while its device object or attachment remains necessary for operation. Investigators should examine unusual attachments and validate the responsible code address against known module ranges.

A rootkit can intercept keyboard or storage operations by creating a filter device and attaching it to the relevant device stack. Requests then pass through the malicious driver's dispatch routines.

An investigator can detect this by:

• Displaying the device tree for keyboard, disk, volume, or file-system devices.
• Identifying unexpected filter devices attached to established stacks.
• Mapping each device object to its driver object and loaded module.
• Inspecting driver names, device names, flags, and attachment order.
• Checking MajorFunction pointers for redirection into unknown memory.
• Looking for unlisted modules that own active device or driver objects.
• Examining device-control handlers and completion routines.
• Dumping suspicious driver code and searching for logging, concealment, or exfiltration functionality.

Legitimate antivirus, encryption, backup, and input software also installs filter drivers. Therefore, signature verification, vendor validation, code analysis, and comparison with a known-good machine are necessary before declaring an attachment malicious.

Major forms of kernel-space hooking include:

• System-call table hooking: Entries in a system-service dispatch table are changed to point to malicious code. Suspicious entries may resolve outside the legitimate kernel modules.
• Inline kernel hooking: Instructions at the beginning of a kernel function are overwritten with a branch or trampoline.
• IRP dispatch hooking: Function pointers in a driver's MajorFunction table are replaced.
• Interrupt or descriptor-table hooking: Entries in structures such as the Interrupt Descriptor Table are redirected.
• Callback manipulation: Malicious callback functions are registered to monitor or alter process, thread, image, registry, or object operations.
• Import-table hooking: Kernel-module import pointers are redirected to unexpected destinations.

Associated artifacts include modified pointers, branches at function entry points, executable non-module memory, hidden drivers, unusual callbacks, and mismatches between memory and trusted kernel binaries.

A robust cross-view methodology should include the following stages:

1. Establish the correct profile: Identify the exact operating-system version, architecture, kernel build, and loaded symbols.
2. Enumerate modules through multiple views: Compare linked lists, pool scans, driver objects, and executable kernel mappings.
3. Validate critical pointers: Map system-call entries, dispatch routines, callbacks, interrupt handlers, and timer routines to known module ranges.
4. Check executable code: Compare important kernel-function bytes with trusted binaries and inspect unexpected branches.
5. Inspect memory permissions: Locate writable-executable kernel pages and executable pool allocations.
6. Analyze pointer destinations: Dump unknown targets and examine them for PE images, shellcode, trampolines, and obfuscation.
7. Correlate structures: Connect suspicious hooks with hidden modules, devices, callbacks, timers, and persistent services.
8. Preserve evidence: Record addresses, bytes, hashes, module ownership, and tool output.

False positives can be minimized by:

• Using symbols and binaries that match the exact operating-system build.
• Accounting for hot patches, virtualization, security products, and legitimate filter drivers.
• Comparing with a known-good system of the same configuration.
• Requiring multiple supporting indicators instead of relying on a single unusual pointer.

Kernel callbacks are functions registered with the operating system so that a driver is notified when a particular kernel event occurs.

Examples include callbacks for:

• Process and thread creation or termination.
• Executable-image loading.
• Registry operations.
• Object-handle creation and duplication.
• File-system and shutdown events.

Callback enumeration assists malware detection by showing which modules receive notifications about security-sensitive events. For each callback, the investigator should map its function address to a loaded module, check whether the module is signed and expected, and inspect callbacks that point into hidden or unbacked memory.

Malware may use callbacks to monitor processes, protect itself, block security tools, capture information, or reinfect processes. However, legitimate security software also uses callbacks extensively, so context and module validation are essential.

Kernel timers schedule an action for a future time or at repeated intervals. When a timer expires, it may cause a deferred procedure call, or DPC, to execute at an elevated interrupt level.

Malware can abuse timers and DPCs to:

• Execute malicious code periodically.
• Restore hooks or callbacks removed by security tools.
• Monitor system activity.
• Trigger delayed payloads.
• Maintain functionality without a visible user-mode process.

Investigation procedure:

1. Enumerate active kernel timers and associated DPC objects.
2. Record expiration times, periods, processor assignments, and routine addresses.
3. Map every DPC routine address to a known kernel module.
4. Flag routines pointing into hidden modules, freed memory, executable pools, or unknown regions.
5. Examine the owning driver and related device objects.
6. Disassemble and dump suspicious destination code.
7. Correlate timers with kernel callbacks, dispatch hooks, and other persistence artifacts.

Timer entries from legitimate drivers are common. Suspicion is strongest when the routine address has no valid module ownership or belongs to an untrusted hidden driver.