Sitemap
Allen Ace

Allen Ace

SOC analyst writing about detection engineering, DFIR, and building explainable BEC detection. Open-source builder

Memory Forensics Investigation Report

9 min readAug 16, 2026

--

Memory forensics provides visibility into malicious activity that may not be recoverable through traditional file-system analysis alone. This investigation examined a Windows memory image captured during the execution of a suspected malware sample, with a focus on identifying suspicious process activity, abnormal memory regions, potential process manipulation, modified executable structures, and network artifacts.

Press enter or click to view image in full size

The investigation used Volatility 3 and MemProcFS as complementary memory-analysis frameworks, with Procmon providing supporting endpoint telemetry.

The investigation progressively narrowed from system-wide process enumeration to the analysis of dfsvc.exe (PID 5252). Multiple observations increased the investigative priority of this process, including:

  • Suspicious PAGE_EXECUTE_READWRITE memory regions identified by Volatility malfind.
  • Corresponding suspicious-memory findings in MemProcFS FindEvil.
  • A PE_PATCHED indicator associated with the investigated process.
  • Loaded networking and cryptographic modules requiring contextual analysis.
  • Network artifacts associated with the investigated process.
  • Supporting process telemetry linking PID 1188 to malz3.exe.

No individual artifact was treated as conclusive. The assessment was based on the correlation of independent observations across memory-analysis frameworks and supporting telemetry.

Overall assessment: The combined evidence is consistent with compromise of dfsvc.exe and possible in-memory execution or process manipulation. Additional endpoint, network, and reverse-engineering evidence would be required to establish the precise injection mechanism and attack chain.

Investigation Scope

The investigation focused on the following areas:

  • Windows process enumeration
  • Process ancestry
  • Suspicious memory allocation
  • Potential code injection
  • Executable/writable memory regions
  • Loaded DLLs and modules
  • PE structure modification
  • Network artifacts
  • Cross-tool evidence correlation
  • IOC identification

The investigation was not intended to provide a complete reverse-engineering analysis of the suspected malware or reconstruct every activity performed on the endpoint.

Evidence and Methodology

The primary evidence source was a Windows memory image captured during the suspected malware execution.

Supporting telemetry was obtained from the associated host investigation.

Press enter or click to view image in full size

The original memory image was excluded from the repository. Its integrity information is maintained separately through the evidence documentation.

The investigation followed a progressive workflow:

Memory Image
│
▼
Evidence Validation
│
▼
Process Enumeration
│
▼
Process Relationship Analysis
│
▼
Suspicious Memory Detection
│
▼
Target Process Analysis
│
▼
Module Analysis
│
▼
Network Artifact Review
│
▼
Cross-Tool Correlation
│
▼
IOC Identification
│
▼
Analytical Assessment

This methodology was designed to avoid treating isolated forensic artifacts as definitive evidence of compromise.

Process Investigation

Process Enumeration

Volatility 3 windows.pslist was used to establish the process population present within the memory image.

The analysis considered:

  • Process names
  • PIDs
  • PPIDs
  • Process creation information
  • Process relationships
  • Processes requiring additional investigation

dfsvc.exe was identified as a process requiring further examination.

The raw output is preserved as:

volatility/pslist.txt

The process was subsequently investigated using its PID.

Assessment

Process enumeration establishes the initial investigative baseline but does not independently demonstrate malicious activity. Additional memory, process, module, and network evidence was therefore required.

Process Relationship Analysis

Volatility windows.pstree was used to reconstruct process ancestry.

The investigation identified a PPID associated with the suspicious process. The corresponding parent process was not present in the reconstructed process tree, consistent with the possibility that the parent had terminated before memory acquisition.

Supporting Procmon telemetry was subsequently reviewed.

The telemetry associated PID 1188 with:

malz3.exe

This provided additional context for reconstructing the execution chain.

Evidence:

volatility/pstree.txt

Assessment

The absence of a parent process from a memory-derived process tree is not, by itself, evidence of malicious behavior. Correlation with Procmon provided additional context but does not independently establish the complete execution chain.

Volatility Malfind

Volatility windows.malfind was used to identify process memory regions exhibiting characteristics associated with potentially injected or executable code.

Suspicious memory regions were identified within:

dfsvc.exe

Of particular interest were regions with:

PAGE_EXECUTE_READWRITE

Memory that is simultaneously writable and executable can provide an execution environment for dynamically injected code.

However, RWX memory is not inherently malicious. Legitimate software can also create executable/writable regions under certain circumstances.

Assessment

The presence of multiple suspicious executable/writable memory regions increased the priority of dfsvc.exe for further investigation.

The result was therefore treated as an investigative lead rather than a standalone compromise determination.

Evidence:

volatility/malfind.txt

Target Process Analysis

The investigation focused on:

Process: dfsvc.exe
PID: 5252

Additional process information was obtained through Volatility.

The process was also extracted from memory for potential subsequent malware analysis.

Example extraction:

vol.py -f <memory-image> windows.pslist --pid 5252 --dump

Process extraction provides an opportunity to examine executable content recovered from memory and potentially identify differences between the runtime process and its corresponding on-disk representation.

Loaded Module Analysis

Volatility windows.dlllist was used to examine modules loaded by PID 5252.

The investigation identified several modules requiring contextual review, including:

apphelp.dll
rasapi32.dll
rasman.dll
mswsock.dll
winhttp.dll
ws2_32.dll
bcrypt.dll
bcryptPrimitives.dll
ncrypt.dll
ncryptsslp.dll
crypt32.dll
dfdll.dll

These modules were not classified as malicious solely because they were present.

Several are legitimate Windows or .NET components associated with:

  • Networking
  • Cryptography
  • Application compatibility
  • Remote access functionality
  • ClickOnce/.NET functionality

Their relevance was evaluated in the context of the suspicious memory characteristics already identified within dfsvc.exe.

Assessment

DLL presence alone is insufficient to establish compromise. The module findings therefore served as supporting context rather than primary evidence.

Evidence:

volatility/dlllist.txt

MemProcFS Corroboration

MemProcFS was introduced as an independent analysis framework to provide another representation of the same memory evidence.

The purpose of the secondary analysis was to determine whether significant observations identified through Volatility could be corroborated independently.

Relevant artifacts are preserved under:

memprocfs/

FindEvil Analysis

MemProcFS forensic FindEvil output identified dfsvc.exe within the suspicious-memory findings.

This was significant because it independently supported the suspicious-memory observation generated by Volatility malfind.

Evidence:

memprocfs/forensic-findevil.txt

The correlation can be summarized as:

Volatility malfind
│
▼
Suspicious memory in dfsvc.exe
│
▼
MemProcFS FindEvil
│
▼
dfsvc.exe identified again
│
▼
Increased investigative confidence

Assessment

Agreement between the two frameworks increased confidence that the suspicious memory characteristics warranted further investigation and were not solely dependent on a single tool’s output.

PE Modification Evidence

MemProcFS reported a:

PE_PATCHED

condition associated with the investigated process.

This indicates that characteristics of the process’s Portable Executable structure differed from the expected PE representation.

The observation was significant because it occurred alongside the previously identified suspicious memory regions.

However, the finding does not independently establish the mechanism responsible for the modification.

Possible mechanisms would require additional evidence to distinguish between:

  • Process injection
  • Runtime patching
  • Malware execution
  • Other forms of memory modification

Assessment

The PE_PATCHED finding strengthened the overall suspicion surrounding dfsvc.exe, but was not treated as definitive evidence of a specific injection technique.

MemProcFS Process Analysis

The MemProcFS process artifacts were compared against the Volatility process-tree output.

Evidence:

memprocfs/process-tree.txt
volatility/pstree.txt

The comparison provided an additional perspective on process relationships and helped validate the broader process-analysis findings.

Network Artifact Investigation

Network artifacts were examined through MemProcFS to determine whether the memory image preserved evidence of network activity associated with the investigated process.

Get Allen Ace’s stories in your inbox

Join Medium for free to get updates from this writer.

Evidence:

memprocfs/netstat.txt

The analysis considered:

  • Local addresses
  • Remote addresses
  • Ports
  • Process associations
  • Listening states
  • Connection states

A network artifact represented as:

0.0.0.0:0

was identified as requiring further investigation.

This observation was not treated as standalone proof of command-and-control communication.

Potential explanations considered during the investigation included:

  • Backdoor functionality
  • C2-related behavior
  • Proxy/tunneling functionality
  • Other process networking behavior

Assessment

The network artifact increased the investigative significance of dfsvc.exe, particularly when considered alongside the suspicious memory and PE modification findings.

Additional DNS, firewall, proxy, packet-capture, or EDR telemetry would be required to establish successful external communication.

Evidence Correlation

The investigation relied on correlation rather than isolated indicators.

The primary evidence chain was:

dfsvc.exe
│
├── PID 5252
│
├── Suspicious RWX memory
│
├── Volatility malfind detection
│
├── MemProcFS FindEvil detection
│
├── PE_PATCHED indicator
│
├── Network-related modules
│
└── Network artifact requiring investigation

Supporting process telemetry provided additional context regarding process ancestry.

The convergence of these observations increased confidence that dfsvc.exe represented a high-priority investigative target.

Press enter or click to view image in full size

Finding 1 — Suspicious Memory

dfsvc.exe contained memory regions exhibiting characteristics associated with potentially injected or dynamically executed code.

Finding 2 — Independent Corroboration

The suspicious process was identified by both Volatility and MemProcFS.

Finding 3 — PE Modification

MemProcFS reported a PE_PATCHED condition associated with the investigated process.

Finding 4 — Network Activity

Network artifacts associated with the investigation warranted additional examination but were insufficient to conclusively establish C2 communication.

IOC Handling

Potential indicators identified during the investigation are maintained separately from the narrative report.

Host IOCs

iocs/host-iocs.csv

Potential categories include:

  • Process names
  • PIDs
  • File paths
  • Hashes
  • Relevant DLLs
  • Registry artifacts

Network IOCs

iocs/network-iocs.csv

Potential categories include:

  • IP addresses
  • Domains
  • Ports
  • Network connections
  • Other network artifacts recovered from memory

Only evidence-supported artifacts should be promoted to confirmed IOCs.

MITRE ATT&CK Considerations

The observed behavior warrants consideration of:

T1055 — Process Injection

The available evidence is consistent with process manipulation or in-memory execution; however, the precise injection mechanism was not established.

The investigation therefore does not assign a more specific process-injection sub-technique without additional supporting evidence.

Further reverse engineering and endpoint telemetry would be required before mapping techniques such as Process Hollowing or other specific injection mechanisms.

Blue Team Detection Opportunities

The investigation highlights several defensive opportunities.

Endpoint Detection

Security monitoring should prioritize:

  • RWX memory allocations in unusual processes
  • Executable memory inconsistent with expected process behavior
  • PE modification indicators
  • Abnormal process ancestry
  • Unexpected network activity from normally non-network-facing processes

Memory Forensics

Memory acquisition should be considered when:

  • Malware is suspected but disk artifacts are inconclusive
  • Process injection is suspected
  • Fileless execution is suspected
  • EDR telemetry indicates suspicious process behavior
  • Network activity cannot be adequately explained by available endpoint artifacts

Threat Hunting

The investigation can support hunting hypotheses around:

Unusual process → executable/writable memory
↓
PE modification
↓
suspicious network activity

These conditions can be used to guide retrospective searches across EDR, Sysmon, network, and memory-forensics telemetry.

Limitations

The following limitations apply to the investigation:

  1. Analysis was performed against a captured memory image rather than a live endpoint.
  2. Some processes may have terminated before acquisition.
  3. Memory artifacts do not necessarily preserve the complete execution history.
  4. Network artifacts recovered from memory do not independently establish successful external communication.
  5. Legitimate Windows DLLs may appear in suspicious processes.
  6. RWX memory regions are suspicious but are not inherently malicious.
  7. Additional endpoint, network, and reverse-engineering evidence would be required to reconstruct the complete attack chain.

These limitations were considered when assigning confidence to the findings.

Analyst Assessment

Based on the available evidence, dfsvc.exe should be treated as a high-priority suspicious process within the investigated execution environment.

The strongest evidence is the convergence of:

  • Suspicious executable/writable memory regions
  • Volatility malfind detection
  • MemProcFS FindEvil detection
  • PE_PATCHED evidence
  • Supporting process telemetry
  • Network artifacts requiring further investigation

No individual artifact was treated as conclusive.

The assessment instead reflects the correlation of multiple observations generated from the same memory image and supporting telemetry.

Overall Assessment: The evidence is consistent with compromise of dfsvc.exe and potential in-memory execution or process manipulation. The available evidence does not establish the exact injection mechanism, malware family, persistence mechanism, or external infrastructure.

Recommended Next Steps

If this investigation were part of a live incident-response engagement, recommended actions would include:

  1. Isolate the affected endpoint if compromise is confirmed.
  2. Preserve the original forensic image and evidence metadata.
  3. Hash and preserve extracted process artifacts.
  4. Perform static analysis of the extracted process.
  5. Perform controlled dynamic analysis in an isolated malware-analysis environment.
  6. Review EDR telemetry for process injection and memory allocation events.
  7. Investigate DNS, proxy, firewall, and network telemetry.
  8. Search the environment for related processes, files, hashes, and paths.
  9. Hunt for associated network indicators.
  10. Investigate potential persistence mechanisms.
  11. Determine the initial execution vector.
  12. Document confirmed IOCs for detection and containment.

Evidence Inventory

Press enter or click to view image in full size

Conclusion

This investigation demonstrates the value of memory forensics as an investigative layer within modern Blue Team and incident-response operations.

The investigation progressed from broad process enumeration to targeted analysis of dfsvc.exe, followed by suspicious-memory detection, module analysis, independent MemProcFS validation, and network artifact review.

The key lesson was the value of evidence correlation.

Suspicious Process
│
▼
RWX Memory
│
▼
Malfind Detection
│
▼
MemProcFS FindEvil
│
▼
PE Modification
│
▼
Network Artifact
│
▼
Correlated Suspicion

Rather than relying on a single forensic indicator, the investigation combined multiple observations to increase analytical confidence.

This evidence-driven approach reflects a practical Blue Team methodology:

Identify → Validate → Correlate → Assess → Respond

Memory forensics is therefore particularly valuable when conventional file-based analysis or endpoint telemetry does not provide sufficient visibility into potentially malicious execution.

Get the comprehensive analysis on GitHub

Contact: Portfolio

--

--

Allen Ace
Allen Ace

Written by Allen Ace

SOC analyst writing about detection engineering, DFIR, and building explainable BEC detection. Open-source builder