Lab 06 Memory Forensics Investigation

Mission Overview

Welcome to Lab 06 — Memory Forensics Investigation.

In the previous labs, you examined persistent evidence from disk, Windows, and Linux systems.

Now you will investigate a different class of evidence:

volatile memory

Memory can contain information that may never be written to disk, including:

• running processes

• process relationships

• command-line arguments

• loaded modules

• network connections

• user sessions

• runtime artifacts

• injected or anomalous process behavior

• remnants of recently executed activity

The central question is:

What was happening on the system at the moment memory was captured?

Mission Goal: Verify a provided memory image, identify system context, examine processes and parent-child relationships, review command-line and network artifacts, correlate runtime evidence, and produce a defensible Memory Forensics Findings Register.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Memory Forensics
Secondary Skill	Runtime Evidence Analysis
Environment	GoHackersCloud Digital Forensics Lab
Evidence Type	Provided training memory image
Testing Type	Offline forensic analysis
Primary Outcome	Memory Forensics Findings Register
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• explain volatile evidence

• verify memory-image integrity

• identify operating-system context

• enumerate processes

• understand parent-child process relationships

• review process creation context

• examine command-line artifacts

• identify loaded modules conceptually

• review memory-resident network connections

• correlate processes with network activity

• distinguish process presence from suspicious behavior

• identify anomalous runtime relationships

• preserve extracted evidence

• build a memory activity timeline

• correlate memory evidence with disk and log evidence

• distinguish facts, interpretations, and hypotheses

• produce a professional memory-forensics report

Memory Forensics Methodology

Use:

Memory Image → Verify → System Context → Process → Relationship → Command Line → Network → Runtime Artifact → Correlation → Evidence

Conceptually:

Memory Image
     │
     ▼
Integrity Verification
     │
     ▼
System Context
     │
     ▼
Process Inventory
     │
     ▼
Parent / Child Relationships
     │
     ▼
Command-Line Evidence
     │
     ▼
Network Relationships
     │
     ▼
Runtime Artifacts
     │
     ▼
Correlation
     │
     ▼
Supported Conclusion

The key principle is:

A strange-looking process is an investigation lead, not automatically a malicious finding.

Part 1 — Understand Volatile Evidence

Volatile evidence can change or disappear when a system is:

• shut down

• rebooted

• processes terminate

• memory is reused

• network sessions close

Examples include:

Running Processes

Network Connections

Loaded Modules

Command-Line Arguments

Process Memory

Logged-In Sessions

Runtime Configuration

Temporary Credentials or Tokens

This is why memory acquisition can be important during incident response.

Part 2 — Understand the Order of Volatility

A simplified model:

Highly Volatile
     │
     ▼
CPU / Runtime State
Memory
Network Connections
Running Processes
Temporary Data
Disk
Backups
     │
     ▼
Less Volatile

This does not mean memory is always collected first in every incident.

Acquisition decisions depend on:

• incident severity

• legal requirements

• business impact

• system stability

• responder authority

• evidence preservation risk

Part 3 — Confirm Evidence Integrity

Document:

Case ID:

Evidence ID:

Memory Image:

Image Size:

Expected SHA-256:

Current SHA-256:

Hash Match:

Acquisition Source:

Acquisition Time:

Investigator:

Examination Date:

Verify:

sha256sum training-memory.raw

Record:

Recorded Hash:

Current Hash:

Match:
Yes / No

Do not continue if integrity cannot be established.

Part 4 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-06/
    ├── Notes/
    ├── Evidence/
    │   ├── System/
    │   ├── Processes/
    │   ├── Command-Lines/
    │   ├── Network/
    │   ├── Modules/
    │   ├── Extracted/
    │   └── Timeline/
    ├── Screenshots/
    ├── Hashes/
    ├── Findings/
    └── Report/

Create:

Lab-06-Memory-Forensics-Journal.md

Suggested structure:

# Lab 06 — Memory Forensics Investigation

## Mission Objective

## Evidence Information

## Integrity Verification

## Memory Image Context

## System Information

## Process Inventory

## Parent-Child Relationships

## Command-Line Analysis

## Network Connections

## Loaded Components

## Runtime Observations

## Timeline

## Correlation

## Findings

## Limitations

## Conclusion

Part 5 — Select the Analysis Tool

A controlled lab may use:

• Volatility 3

• another approved memory-analysis platform

The exact commands can vary by:

• operating system

• memory image

• framework version

• symbol availability

The methodology is more important than memorizing one command.

Part 6 — Identify the Memory Image Context

First determine what system the image represents.

Record:

Operating System:

Version / Build:

Architecture:

Hostname:
If available

Image Acquisition Time:

Memory Size:

Evidence Source:

A forensic framework may derive some of this information from the image.

Part 7 — Understand Memory Profiles and Symbols

Older memory-forensics workflows often relied heavily on manually selected profiles.

Modern frameworks such as Volatility 3 use operating-system symbols and automated mechanisms differently.

The important principle is:

Use the analysis framework appropriate for the image and document the version used.

Record:

Tool:

Tool Version:

Operating System Identified:

Symbol/Framework Notes:

Part 8 — Enumerate Processes

A primary memory-analysis activity is building the process inventory.

With Volatility 3, a Windows training image may support a command such as:

python3 vol.py -f training-memory.raw windows.pslist

Record the output.

Important fields may include:

PID

PPID

Process Name

Creation Time

Exit Time
Where available

Part 9 — Build the Process Register

Create:

PID	PPID	Process	Created	Exited	Relevance

Do not immediately classify unfamiliar names as suspicious.

Part 10 — Understand PID and PPID

PID

Process Identifier.

PPID

Parent Process Identifier.

Conceptually:

Parent Process
    PID 100
       │
       ▼
Child Process
    PID 200

Parent-child relationships can provide important execution context.

Part 11 — Build the Process Tree

Where supported, use a process-tree view.

For example:

python3 vol.py -f training-memory.raw windows.pstree

Conceptually:

System
 └── services.exe
      ├── service-a.exe
      └── service-b.exe

explorer.exe
 ├── browser.exe
 └── application.exe

Create your own simplified process tree for relevant processes.

Part 12 — Understand Normal Process Relationships

Some Windows process relationships are generally expected.

For example:

System
  ↓
smss.exe
  ↓
csrss.exe / wininit.exe

and user activity may involve:

explorer.exe
   ↓
User Application

But implementation details vary by Windows version.

Do not rely solely on memorized process trees.

Part 13 — Identify Process Relationship Anomalies

Ask:

Is the parent plausible?

Is the process path expected?

Was it created during the incident period?

Does it have a relevant command line?

Does it communicate externally?

Is similar evidence present on disk?

An unusual parent-child relationship is a lead.

It is not proof of maliciousness.

Part 14 — Build the Parent-Child Register

Parent	Child	Time	Expected	Investigation
explorer.exe	training-app.exe		Yes	Normal
app.exe	powershell.exe		Context needed	Review

Part 15 — Compare Process Enumeration Methods

Memory frameworks can identify processes using different techniques.

One view may enumerate active linked processes.

Another technique may scan memory structures and reveal additional process remnants.

For example, a Windows Volatility workflow may use:

python3 vol.py -f training-memory.raw windows.psscan

Compare results.

Part 16 — Understand Why Process Lists Can Differ

Differences may occur because:

• a process exited

• memory structures remain

• acquisition timing

• framework behavior

• damaged data

• hidden/unlinked structures

Do not immediately conclude rootkit activity simply because two process views differ.

Part 17 — Build the Process Comparison Matrix

Process	Process List	Memory Scan	Status	Interpretation
App01	Yes	Yes	Active	Expected
App02	No	Yes	Historical/Review	Investigate

Part 18 — Review Process Command Lines

Command-line evidence can add important context.

For a Windows image, a framework may support:

python3 vol.py -f training-memory.raw windows.cmdline

Record relevant output.

A command line may reveal:

Executable

Arguments

File Paths

URLs

Configuration

Script Names

Part 19 — Handle Sensitive Command-Line Data

Command lines can contain:

• passwords

• API tokens

• keys

• usernames

• internal URLs

Do not unnecessarily reproduce sensitive values.

Use:

--password <REDACTED>

in the report when appropriate.

Part 20 — Build the Command-Line Register

PID	Process	Command Line	Relevance

Record exactly what is visible.

Do not execute any command found in memory.

Part 21 — Understand Command-Line Evidence

Good:

The memory image contains a command-line artifact showing powershell.exe invoked with a reference to the designated training script.

Avoid:

The script definitely executed successfully.

The command line supports invocation context.

Successful execution may require additional evidence.

Part 22 — Review Console / Command History Where Available

Depending on operating system and memory state, additional console-related artifacts may be recoverable.

These can provide context around:

• typed commands

• console sessions

• command interpreters

Availability varies.

Treat recovered history as supporting evidence.

Part 23 — Identify Network Connections

Memory can contain evidence of network activity existing at or near acquisition time.

For Windows images, a framework may support:

python3 vol.py -f training-memory.raw windows.netscan

Potential fields include:

Protocol

Local Address

Local Port

Remote Address

Remote Port

State

PID

Process

Part 24 — Build the Network Connection Register

Time	PID	Process	Local	Remote	State	Relevance

This is a key memory-forensics artifact.

Part 25 — Correlate Process and Network Activity

Example:

PID 4240
Process: browser.exe
        │
        ▼
Remote:
192.0.2.10:443

This supports:

The process was associated with the observed network endpoint in the captured memory evidence.

It does not automatically establish whether the connection was malicious.

Part 26 — Build the Process-to-Network Matrix

Process	PID	Remote Endpoint	Port	Expected	Follow-Up
browser.exe			443	Yes	Context
training-app.exe				Unknown	Review

Part 27 — Compare Memory Network Evidence with PCAP

If the lab provides network evidence, later correlation may look like:

Memory Network Connection
          +
PCAP
          +
DNS
          =
Stronger Communication Evidence

At this stage, record endpoints for later correlation.

Part 28 — Review Loaded Modules Conceptually

Processes commonly load libraries and modules.

A memory framework may allow examination of process-linked modules.

The purpose is to answer:

What components are associated with this process?

Are paths expected?

Are modules consistent with the application?

Are any relationships unusual?

Do not automatically classify an unfamiliar DLL or module as malicious.

Part 29 — Build the Module Observation Register

Process	Module	Path	Expected	Relevance

Use this only for case-relevant processes.

Part 30 — Understand Process Paths

The process name alone is insufficient.

For example:

example.exe

could exist in:

C:\Program Files\Vendor\

or:

C:\Users\Public\

Path context can materially affect investigative priority.

Where the framework provides path information, record it.

Part 31 — Build the Process Context Register

Process	PID	Path	Parent	Command Line	Network

This is stronger than maintaining separate disconnected observations.

Part 32 — Review User Session Context

Memory may contain evidence related to active user sessions.

Record where supported:

User:

Session:

Logon Context:

Relevant Processes:

Acquisition-Time Status:

Again:

Account/session evidence does not automatically identify the human operator.

Part 33 — Correlate User Session and Processes

Suppose:

User session:
lab-user

and:

explorer.exe
   ↓
training-app.exe

within that session.

This may strengthen user-context attribution.

But be precise:

The process was associated with the user session.

This is stronger than:

The named person intentionally executed the program.

Part 34 — Review Process Creation Times

Process timestamps can help reconstruct a runtime timeline.

Build:

Time	PID	Process	Parent	Observation

Compare creation times with:

• logon events

• file activity

• scheduled tasks

• network connections

Part 35 — Identify Processes Relevant to the Incident Window

Prioritize processes that:

• started during the incident period

• have unusual parent relationships

• have relevant command lines

• communicate with case-relevant endpoints

• reference training scripts/files

• correlate with disk evidence

This reduces noise.

Part 36 — Understand Process Exit Evidence

Some memory artifacts may provide exit times.

A terminated process may still leave recoverable structures.

Record:

Process:

Created:

Exited:

Active at Acquisition:
Yes / No / Unknown

Part 37 — Examine Environment Information Where Available

Process environments may contain useful context such as:

• paths

• application variables

• execution settings

Do not harvest secrets unnecessarily.

Use environment evidence only when it addresses an investigation question.

Part 38 — Review Handles Conceptually

Processes may maintain handles to:

• files

• Registry keys

• processes

• synchronization objects

This can help answer:

Which resources was the process interacting with?

Use only the case-relevant output.

Part 39 — Correlate Process with File Evidence

Suppose memory indicates:

training-app.exe

and a file handle or command line references:

C:\Users\lab-user\Downloads\training-document.dat

Then compare with Labs 02–04.

Conceptually:

Memory Process
      +
File Reference
      +
Filesystem Evidence
      =
Stronger Context

Part 40 — Review Suspicious-Looking Runtime Relationships

Indicators that deserve investigation can include:

Unexpected Parent/Child Relationship

Unusual Process Path

Relevant Script Interpreter

Unexpected Network Endpoint

Temporary Directory Execution

Process Existing Only in Memory Scan

Unexpected Module Relationship

These are leads.

They are not automatic findings.

Part 41 — Build an Anomaly Register

ID	Process	Observation	Evidence	Status
MEM-A01		Unusual parent	pstree	Review
MEM-A02		Relevant remote connection	netscan	Correlate

Classify:

Expected

Requires Investigation

Supported Concern

Validated Finding

Inconclusive

Part 42 — Avoid Process-Name Bias

A process named:

svchost.exe

may be legitimate.

A process named:

update-helper.exe

may also be legitimate.

Do not decide based on the name alone.

Investigate:

Name + Path + Parent + Time + Command Line + Network + Disk Evidence

Part 43 — Build the Runtime Evidence Model

For each priority process:

Process
   │
   ├── PID
   ├── PPID
   ├── Path
   ├── Create Time
   ├── Command Line
   ├── User / Session
   ├── Modules
   ├── File Relationships
   └── Network Relationships

This creates a much stronger profile.

Part 44 — Extract an Artifact Only When Necessary

If the lab framework allows extraction of a designated training object, treat it as derived forensic evidence.

Store under:

Evidence/Extracted/

Record:

Derived Evidence ID:

Source Process:

Source Image:

Extraction Method:

Filename:

SHA-256:

Purpose:

Do not execute extracted binaries or scripts.

Part 45 — Hash Extracted Artifacts

For example:

sha256sum Evidence/Extracted/MEM-EX01.bin

Record the hash in your evidence register.

Part 46 — Maintain Evidence Lineage

Example:

E06 — Memory Image
       │
       ▼
E06-W01 — Working Memory Image
       │
       ├── MEM-PROC-01 — Process Record
       ├── MEM-NET-01  — Connection Record
       └── MEM-EX01    — Extracted Artifact

Every derived item should trace back to the memory image.

Part 47 — Correlate Memory with Windows Evidence

Example:

Windows Prefetch:
TRAININGAPP.EXE execution evidence
               +
Memory:
TRAININGAPP.EXE active process
               +
Event Log:
process activity
               =
Strong execution evidence

This is far stronger than one artifact alone.

Part 48 — Correlate Memory with Linux Evidence

For Linux memory images, the same general principle applies:

Authentication
      +
Memory Process
      +
Command Line
      +
Filesystem / Log Evidence
      =
Stronger Runtime Reconstruction

The exact framework plugins differ by operating system.

Part 49 — Correlate Memory with Network Evidence

Suppose memory shows:

training-app.exe
→ 192.0.2.50:443

and PCAP later shows:

Host
→ 192.0.2.50:443

and DNS shows a related resolution.

Now:

Process Evidence
       +
Network Evidence
       +
DNS Evidence
       =
Strong Communication Correlation

Part 50 — Build the Memory Timeline

Use relevant process events.

Example:

Time	Source	Event	Confidence
09:11	Process	browser started	Confirmed
09:14	Process	training-app started	Confirmed
09:15	Network	connection associated with PID	Confirmed
09:18	Process	training-app exited	Supported

Do not invent precision the artifacts do not provide.

Part 51 — Add Context from Other Labs

You may later combine:

Time	Source	Event
09:10	Windows Event Log	User logon
09:14	Memory	Program started
09:15	Memory	Network connection
09:16	Filesystem	File modified

This begins forming a stronger incident reconstruction.

Part 52 — Build the Memory Correlation Matrix

Create:

Question	Memory Evidence	Other Evidence	Confidence
Was app running?	Process list	Prefetch	High
Did process connect remotely?	netscan	PCAP	High
Was script referenced?	command line	filesystem	High
Which user context?	session evidence	logon logs	Supported

Part 53 — Separate Fact, Interpretation, Hypothesis

Fact

A process record for TRAININGAPP.EXE exists with PID 4240.

Interpretation

TRAININGAPP.EXE was present as a process at or around memory acquisition.

Hypothesis

The application caused the security incident.

The third conclusion requires much more evidence.

Part 54 — Example Finding: Process Execution Context

Finding:
Case-relevant process identified in memory.

Observation:
The memory image contains a process record for TRAININGAPP.EXE
created during the investigation period.

Supporting Evidence:
The process appears within the user-session process tree and
contains a command line referencing the designated training file.

Correlation:
Disk evidence separately identifies the same executable and
related file path.

Confidence:
High.

Limitation:
The evidence does not independently establish malicious intent.

Part 55 — Example Finding: Network Relationship

Finding:
Case-relevant runtime network connection identified.

Observation:
Memory network artifacts associate TRAININGAPP.EXE with a TCP
connection to the designated training endpoint.

Correlation:
The endpoint also appears in the supplied network evidence.

Conclusion:
The evidence supports that the process was associated with the
observed communication.

Limitation:
The connection alone does not establish the nature of the
application-layer activity.

Part 56 — Example Observation: Unusual Parent

Observation:
A case-relevant process has an unexpected parent process compared
with the application's normal training baseline.

Investigative Relevance:
The relationship warrants correlation with command-line,
filesystem, and event-log evidence.

Classification:
Requires Investigation.

Conclusion:
The parent-child relationship alone is insufficient to establish
malicious activity.

Part 57 — Example Observation: Process Scan Difference

Observation:
A process was identified through memory scanning but was not
present in the active linked process list.

Possible Explanation:
The process may have terminated before acquisition or its
structure may remain in recoverable memory.

Next Step:
Review creation/exit times and correlate with other process and
event evidence.

Conclusion:
The discrepancy alone does not establish process hiding.

Part 58 — Build the Memory Forensics Findings Register

Create:

ID	Artifact	Process	Observation	Correlation	Confidence
MEM-01	Process
MEM-02	Command line
MEM-03	Network
MEM-04	Parent-child

Add:

• PID

• PPID

• timestamp

• evidence source

• follow-up

• limitation

Part 59 — Build the High-Priority Process Register

Create:

Process	Why Prioritized	Evidence Needed	Status
App01	Incident-period start	Logs + disk	Correlated
App02	Unusual network	PCAP	Pending

This prevents random investigation.

Part 60 — Document Positive Evidence

Examples:

Expected process ancestry observed

No unexplained network activity for priority process

System process paths consistent with baseline

Known application communication confirmed

Relevant process absent at acquisition

Positive evidence may weaken or eliminate a hypothesis.

Part 61 — Document Memory Limitations

Memory analysis has significant limitations.

Examples:

• snapshot represents one point in time

• terminated activity may be incomplete

• acquisition can alter memory

• some memory may be unavailable

• paging may affect evidence

• framework parsing may be incomplete

• encrypted application content may remain opaque

• absence of artifact does not prove absence of activity

Include these limitations in the report.

Part 62 — Reverify the Memory Image

At completion:

sha256sum training-memory.raw

Compare:

Pre-Examination Hash:

Post-Examination Hash:

Match:

Integrity Status:

Expected:

Match:
Yes

Part 63 — Mission Challenge

Using the provided memory image, complete:

CASE INFORMATION

Case ID:

Evidence ID:

Memory Image:

Image Size:

Acquisition Time:

SHA-256 Verified:


SYSTEM CONTEXT

Operating System:

Version / Build:

Architecture:

Hostname:

User / Session Context:


PROCESS INVENTORY

Total Relevant Processes:

Priority Process 01:

PID:

PPID:

Parent:

Creation Time:

Exit Time:

Path:

Command Line:

User Context:


Priority Process 02:

PID:

PPID:

Parent:

Reason Prioritized:


NETWORK ACTIVITY

Process:

PID:

Local Endpoint:

Remote Endpoint:

Protocol:

Connection State:

Expected:

Correlation:


RUNTIME ARTIFACTS

Relevant Module:

Relevant File Relationship:

Relevant Command-Line Evidence:

Relevant Session Evidence:


PROCESS CORRELATION

Prefetch / Disk Evidence:

Event Log Evidence:

Filesystem Evidence:

Network Evidence:

DNS Evidence:


TIMELINE

Earliest Relevant Process Event:

Event 01:

Event 02:

Event 03:

Latest Relevant Event:


ANOMALIES

Anomaly 01:

Evidence:

Classification:

Anomaly 02:

Evidence:

Classification:


FINAL ANALYSIS

Most Important Process:

Most Important Parent-Child Relationship:

Most Important Network Relationship:

Highest-Confidence Finding:

Strongest Correlation:

Largest Evidence Gap:

Unconfirmed Hypothesis:

Overall Conclusion:

Recommended Next Investigation:

Part 64 — What Not to Do

Do not:

Modify the original memory image

Execute extracted binaries

Execute recovered scripts

Use recovered credentials

Attempt account access

Publish passwords or tokens found in memory

Treat unfamiliar processes as automatically malicious

Treat parent-child anomalies as proof of compromise

Treat process-scan differences as proof of hiding

Treat an IP connection as proof of command-and-control

Assume process presence identifies the human operator

Ignore acquisition time

Ignore tool/framework limitations

Present hypotheses as confirmed facts

The rule is:

Observe → Correlate → Qualify → Conclude.

Part 65 — Troubleshooting

Framework Cannot Identify the Image

Check:

• image format

• tool version

• operating system support

• symbol availability

• image corruption

Do not alter the source evidence.

Process Plugin Returns Few Results

Possible causes:

• incomplete capture

• unsupported image

• memory corruption

• acquisition state

• framework limitations

Try an appropriate alternative process-enumeration method.

Document the difference.

Process Appears in Scan but Not List

Do not immediately report hiding.

Investigate:

• exit time

• process creation time

• residual memory structure

• other process artifacts

Network Scan Returns Nothing

Possible explanations:

• no active connections

• relevant connection had closed

• image does not preserve required structures

• unsupported framework parsing

Absence of a memory connection does not prove the host never communicated.

Command Line Is Empty

Some processes may have incomplete or inaccessible command-line data.

Correlate other artifacts.

Timestamps Do Not Match Disk Logs

Check:

• timezone

• acquisition time

• clock drift

• timestamp semantics

• whether the evidence represents different stages of activity

Evidence Requirements

Capture:

Evidence 01

Memory-image SHA-256 verification.

Evidence 02

Operating-system identification.

Evidence 03

Tool and framework version.

Evidence 04

Process inventory.

Evidence 05

Process tree.

Evidence 06

Process comparison results.

Evidence 07

Priority Process Register.

Evidence 08

Command-Line Register.

Evidence 09

User/session context.

Evidence 10

Network Connection Register.

Evidence 11

Process-to-Network Matrix.

Evidence 12

Process Context Register.

Evidence 13

Relevant module/runtime evidence.

Evidence 14

Anomaly Register.

Evidence 15

Extracted artifact and SHA-256, where applicable.

Evidence 16

Evidence lineage.

Evidence 17

Memory Timeline.

Evidence 18

Memory Correlation Matrix.

Evidence 19

Memory Forensics Findings Register.

Evidence 20

Post-examination integrity verification.

Mission Deliverables

Complete:

• memory image verified

• lab workspace created

• analysis tool/version documented

• OS context identified

• acquisition context documented

• Process Register created

• process tree analyzed

• PID/PPID relationships reviewed

• multiple process enumeration methods compared where available

• priority processes selected

• command lines examined

• sensitive values redacted

• user/session context reviewed

• network relationships analyzed

• Process-to-Network Matrix created

• relevant module/path evidence reviewed

• file/process relationships correlated

• runtime anomalies classified cautiously

• extracted evidence hashed where appropriate

• evidence lineage maintained

• disk/log/network correlation completed

• memory timeline created

• facts separated from hypotheses

• positive evidence documented

• investigation limitations recorded

• Memory Forensics Findings Register completed

• memory image reverified

• final report completed

Lab Report Template

# Lab 06 — Memory Forensics Investigation

## Executive Summary

## Mission Objective

## Case Information

## Evidence Information

## Integrity Verification

## Acquisition Context

## Analysis Tools

## System Identification

## User / Session Context

## Process Inventory

## Process Tree Analysis

## Process Enumeration Comparison

## Priority Processes

## Command-Line Analysis

## Process Path Analysis

## Network Connection Analysis

## Process-to-Network Correlation

## Loaded Component Analysis

## File / Handle Relationships

## Runtime Anomalies

## Memory Timeline

## Cross-Artifact Correlation

## Investigation Hypotheses

## Positive Evidence

## Memory Forensics Findings Register

## Evidence Lineage

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Process Register

## Appendix B — Network Register

## Appendix C — Timeline

## Appendix D — Hashes

Knowledge Check

Question 1 — Why is memory called volatile evidence?

Because its contents can change rapidly and may be lost when the system powers down or runtime state changes.

Question 2 — What does PID represent?

The identifier assigned to a process.

Question 3 — What does PPID help determine?

The parent process associated with a child process.

Question 4 — Does an unusual parent-child relationship prove malware?

No.

It is an investigative lead requiring additional evidence.

Question 5 — Why examine process command lines?

They can reveal how an application was invoked, including relevant arguments, paths, files, or URLs.

Question 6 — What can memory network artifacts provide?

Evidence associating processes with local and remote network endpoints at or near acquisition time.

Question 7 — Does a remote network connection prove malicious communication?

No.

The destination and communication require contextual analysis.

Question 8 — Why compare different process enumeration techniques?

Because different methods may identify active, terminated, or residual process structures.

Question 9 — Does a process found only by a memory scan prove process hiding?

No.

Other explanations such as process termination must be considered.

Question 10 — What makes memory evidence most powerful?

Correlation with disk, log, authentication, DNS, and network evidence.

Skills Achieved

After completing this lab, you should understand:

• volatile evidence

• order of volatility

• memory-image integrity

• memory-analysis frameworks

• operating-system context

• process enumeration

• PID and PPID

• process trees

• process scanning

• process relationship analysis

• command-line artifacts

• user/session context

• network artifacts

• process-to-network correlation

• process path context

• loaded-module concepts

• runtime artifact analysis

• anomaly classification

• evidence extraction

• derived evidence hashing

• evidence lineage

• memory timeline construction

• cross-artifact correlation

• forensic hypothesis management

• professional memory-forensics reporting

Professional Takeaway

Memory forensics is not:

“Find a weird process and call it malware.”

The professional approach is:

Process
   +
Parent
   +
Path
   +
Command Line
   +
User Context
   +
Network Connection
   +
Disk Evidence
   +
Logs
   =
Defensible Runtime Context

Always distinguish:

Process Exists
     ≠
Process Is Malicious

Network Connection Exists
     ≠
Command-and-Control Proven

Process Scan Difference
     ≠
Rootkit Proven

Account Context
     ≠
Human Identity Proven

The real strength of memory forensics comes from answering:

“What was running, how was it related to other processes, what was it communicating with, and how does that runtime evidence correlate with everything else we already know?”

The methodology is:

Verify → Identify → Enumerate → Relate → Correlate → Qualify → Conclude

What’s Next?

➡️ Lab 07 — Browser, Email & Phishing Forensics

In the next lab, you will reconstruct a simulated phishing incident by correlating:

• email headers

• sender and reply-to information

• message timestamps

• URLs

• attachment metadata

• browser history

• visited domains

• downloads

• browser timestamps

• downloaded filenames

• endpoint file evidence

• DNS/network evidence

The investigative sequence becomes:

Email → Link → Browser → Download → File → Endpoint Activity → Network Evidence → Timeline → Correlation

By the end of Lab 07, you should be able to answer:

“Did the available evidence support a sequence from suspicious email delivery through browser interaction and file activity, and which parts of that sequence are confirmed versus inferred?”