The Locked Disk Is Not the Whole System: Analyzing Encrypted Data and Volatile Memory

The Locked Disk Is Not the Whole System: Analyzing

Encrypted Data and Volatile Memory

by Scott A. Macri

What you should know:

- Basic Windows process, storage, file-system, and networking concepts.
- Fundamental incident-response authorization and digital-evidence handling practices.
- Familiarity with memory acquisition, disk imaging, and command-line analysis is helpful but not

required.

What you will learn:

- How encryption state changes the forensic order of operations.
- How to preserve, analyze, and validate volatile evidence from a running encrypted system.
- How to distinguish live endpoint memory, sandbox memory, and reverse-engineered payload evidence.
- How validated findings can support traceable operational decisions without overstating what the evidence

proves.

Introduction

Picture the scene: a Windows workstation is still running, a user is logged in, and an encrypted volume is

mounted. A shutdown may leave investigators with a sound image of the encrypted media, but it can erase
the live state that made the data accessible. RAM may still hold mount context, active processes and
sessions, open file references, decrypted fragments, or cryptographic material that the disk image alone
cannot supply. [1, 2]

That distinction frames the entire examination. Memory analysis is not a shortcut around cryptography. It

is an examination of the temporary operating state created when Windows or an application legitimately
uses protected information. Each artifact still has to be tied to a process, user, storage object, and
supporting source before it can support a conclusion.

This article presents an evidence-centered Windows workflow and explains where sandbox automation

and downstream decision support fit without replacing direct forensic analy

sis.

Understanding Encryption States

Encrypted data is not one forensic condition. A powered-off encrypted drive, an unlocked volume, an

EFS-protected file, an application vault, and TLS-protected network traffic expose different evidence. The
first task is to identify where the information sits in its life cycle: stored, unlocked, opened, processed,
displayed, copied, transmitted, or rewritten. The most useful investigative opportunities often appear at the
transitions between those states.

At Rest, Mounted, and in Use

Full-volume encryption is designed primarily to protect information at rest from offline access. Microsoft

describes BitLocker as encryption for entire volumes, intended to reduce exposure when a device is lost,
stolen, or improperly retired. A forensic disk image can preserve the encrypted source accurately, but
imaging alone does not decrypt it. When the protected volume is locked or the device is powered off, file
contents may remain unavailable without valid recovery material. [3]

An unlocked or mounted volume is different. The underlying storage remains encrypted, but the running

system can decrypt requested sectors and make usable data available to authorized processes. Encrypted-
container products follow the same general pattern: the container stays encrypted on storage while a driver
exposes a mounted file system. The mounted state establishes that a route to the data existed. It does not
establish that every file was opened or that the complete key hierarchy is recoverable from RAM. [3, 12]

File-level encryption may be transparent to the application. Microsoft documents that an application with

the required credentials can open an EFS-protected file and receive unencrypted information through the
file-system layer. Relevant plain text may therefore appear in a document editor, image viewer, indexer,
backup product, or security scanner rather than in an obvious encryption application. [4]

Application and Network Encryption

Password managers, secure messaging clients, encrypted archives, protected databases, and browser

stores control their own decryption life cycles. An application may decrypt an entire database, one record, a
temporary working copy, or a session key. Plain text and metadata may appear in the primary process, a
child process, shared memory, a temporary file, the clipboard, or a rendering component. The duration and
location of that exposure depend on application design and user activity.

Encryption in transit creates another boundary. Packet captures may contain unreadable TLS traffic, but

applications still construct plain text before encryption and process plain text after decryption. Memory can
sometimes connect a connection to a process, user, destination, message fragment, or structured request. A
fragment from one process does not establish that an entire encrypted session has been reconstructed.

Those transitions deserve close attention. Evidence may appear when a locked volume is unlocked, a

protected file is opened, an application authenticates to a vault, or plain text is prepared for transmission.
Remnants may also remain after a process closes until the relevant pages are reclaimed or overwritten.
Understanding the state avoids two opposite mistakes: assuming encryption makes all evidence
inaccessible, and assuming a running system exposes every protected object.

Why Volatile Memory Matters

NIST defines volatile data as live-system information that can be lost when a system is powered down.

RAM holds portions of the active state rather than only persistent storage. It can therefore answer questions
that an encrypted disk image cannot answer by itself: which user session was active, whether a protected
volume was mounted, which processes held file or device handles, whether a suspicious process maintained
an external connection, and whether recognizable protected content reached an application. [1, 2]

Process Context Comes First

Windows gives each process a virtual address space that is translated to physical pages through

operating-system memory-management structures. Process ownership is therefore central to interpretation.
A filename found in a document editor means something different from the same filename in an indexer,
backup utility, endpoint security product, or unassociated memory fragment. The same rule applies to
candidate passwords and keys: location, owning process, surrounding structure, and system state matter
more than apparent randomness or length. [5]

A memory image can preserve process ancestry, command lines, loaded modules, drivers, services,

handles, network objects, file mappings, user sessions, and remnants of terminated processes. Volatility 3
provides plugins for examining many of these Windows structures. Those plugins establish context; they do
not independently prove that protected content was opened or that a byte sequence is a valid key. [11]

RAM Is a Snapshot, Not a Complete History

A live acquisition is captured while the system continues to change. The acquisition utility consumes

resources, processes keep running, pages are allocated and reused, and different portions of RAM are
copied at slightly different times. Windows can also move pageable data between physical memory and the
page file, while file-backed pages may be resident only when needed. A missing password, plain text
fragment, or key is therefore a limit of the captured evidence, not proof that the information was never
present or used. [6, 19]

Timing determines evidentiary value. Relevant pages may disappear after an application closes, a user

logs out, a volume is dismounted, or the system shuts down. A timely capture does not guarantee recovery,
but it preserves an operating state that cannot be recreated exactly. RAM should be examined alongside
page files, hibernation files, crash dumps, disk images, application records, endpoint telemetry, and
network evidence when those sources are available and within scope.

What Investigators Are Actually Trying to Prove

In practice, most encrypted-data cases reduce to a small set of questions. NIST SP 800-86 organizes

forensic work around collection, examination, analysis, and reporting, which is a useful reminder that
recovery is only one step. The examiner still has to connect an artifact to system state and explain what it
can support. [1]

Accessibility:

Was the protected disk, volume, container, file, or application store accessible during the

captured session? Lock or mount status, volume and device objects, encryption drivers, mount points, open
handles, application paths, and unlock-related events may help answer that question. Accessibility alone
says nothing about which individual files were opened.

Attribution:

Which user, process, service, or driver interacted with the protected resource? Process

ancestry, session identifiers, security context, command lines, signing information, handles, and network
connections help distinguish expected use from suspicious access.

Use:

What protected information was actually processed? A filename can show a reference, a mapped

region can link content to a file, and a text fragment can show that some plain text reached a process. The
strength of the conclusion depends on how well those observations can be connected and corroborated;
none by itself shows that a user read the complete object.

Malicious access:

Did malware read protected files, access another process, inject code into an authorized

application, stage a temporary copy, capture the clipboard or screen, create an archive, or transmit data? A
process handle or external connection can support a hypothesis, but exfiltration normally requires
corroborating endpoint, file-system, or network evidence.

Credential or key validity:

Does a candidate value match the expected format and context, and can it

produce a repeatable result against an authorized working copy? A random-looking sequence remains a
candidate until functional validation shows that it unlocks, mounts, authenticates to, or decrypts the
expected object.

A useful report stops at the narrowest conclusion supported by the combined evidence. It may establish

that a volume was unlocked without identifying the credential, show that a protected file was opened
without recovering the full plain text, or identify suspicious access without confirming transfer. Those are
meaningful results when the boundaries are stated plainly.

Preserve the Opportunity

Any action on a live system changes evidence. Opening a terminal, connecting storage, launching an

acquisition utility, isolating the endpoint, or querying a process consumes resources and alters RAM. The
goal is not a change-free acquisition, which is impossible, but a controlled collection with a practical
footprint and a complete record of what changed. NIST advises organizations to decide quickly whether
volatile operating-system data should be preserved and to balance evidentiary value against operational
risk. [1]

Authority, Safety, and Visible State

Confirm legal and organizational authority before acquisition. A memory image may contain credentials,

communications, personal information, cryptographic material, regulated data, and content belonging to
users outside the immediate incident. Authorization should identify the target system, permitted sources,
handling restrictions, and whether stopping active harm takes precedence over preservation.

Document the visible state before unnecessary interaction: power and lock state, displayed time, logged-

in users, open applications, mounted drives, connected removable media, encryption prompts, network
connectivity, security alerts, and signs of active encryption or data transfer. Photographs can preserve the
physical and screen context. Compare the displayed clock with a trusted time source later so that memory
findings can be correlated accurately with logs and sensors.

Isolation and Acquisition

Network isolation can limit attacker access or continued data loss, but it can also terminate sessions that

help identify remote infrastructure and active communications. Record who authorized isolation, when it
occurred, how it was implemented, which connections were expected to remain, and whether memory was
captured before or after the change.

Use a prepared, tested acquisition method rather than relying only on tools already present on a

potentially compromised system. Record the acquisition utility name, version, executable hash, exact
command, destination, start and completion times, warnings, and errors. Write to controlled storage with
sufficient capacity, and avoid unnecessary writes to the system drive.

Hash the completed image, preserve the original with appropriate access controls, and analyze a verified

working copy. Preserve photographs, notes, acquisition logs, tool details, time comparisons, and
authorization records with the image. Document partial collections, failed tools, terminated connections,
and any state that could not be preserved. An incomplete but accurately described acquisition is more
defensible than an apparently complete image whose provenance cannot be explained.

Build a System-State Baseline

Before searching for keys or plain text, reconstruct the system state. A baseline identifies expected

applications, encryption components, users, resources, and communications, giving the examiner a
reference point for evaluating later artifacts.

Validate the Image and Symbols

Verify the working-copy hash and confirm that the framework can interpret the operating-system

structures. Volatility 3 relies on symbols to resolve Windows data structures. For many supported builds, it
can automatically obtain PDB data from Microsoft and generate the required intermediate symbol
information. Preserve the framework version, symbol details, command, output format, execution time, and
every warning or error. Missing or mismatched symbols can produce incomplete or misleading results. [11]

Processes, Sessions, and Execution

Inventory processes with identifiers, parent identifiers, names, sessions, creation times, exit times when

available, and thread or handle counts. Compare standard process-list traversal with pool-scanning
methods, but do not treat a difference as proof of concealment. Terminated processes, reused memory,
acquisition smear, and corrupted structures can also produce inconsistencies. Corroborate unusual entries
with mapped executables, command lines, handles, threads, modules, and network objects.

Associate processes with user and logon sessions. The person visible at the keyboard is not necessarily

the owner of every user-mode process; services, remote sessions, scheduled tasks, management agents, and
compromised accounts may be active simultaneously. Command lines and console history can expose
container paths, mount options, scripts, output locations, or credentials passed insecurely, but they are not a
complete audit trail.

Services, Drivers, Handles, and Network Objects

Encryption products commonly rely on services, filter drivers, storage drivers, authentication

components, and supporting libraries. Compare observed components with the expected product and
installation. An unfamiliar module is not malicious merely because it is unsigned, loaded from an unusual
path, or visible only through scanning; these characteristics require corroboration.

Handles connect processes to files, registry keys, devices, mutexes, events, and other processes. A handle

to a protected file or another process is evidence of a relationship, not proof that the complete content was
read or copied. Interpret the object type, path, process, access context, and related artifacts together.

Network objects can tie local and remote addresses and ports to processes. Memory may preserve active

or recently closed structures, so compare results with process state, timestamps, DNS records, firewalls,
proxies, EDR telemetry, and packet captures. End the baseline with a concise map of users, sessions,
processes, services, drivers, resources, and communications that can guide targeted encryption analysis.

Locate Encryption-Related Activity

After the baseline, identify the protection mechanism and the components that enabled access. The

relevant evidence differs for full-volume encryption, encrypted containers, EFS, application vaults,
encrypted archives, and ransomware.

Identify the Mechanism and State

For BitLocker-protected storage, Windows reports separate volume, protection, and lock states. A

volume may be fully encrypted and still be unlocked for the running system. Tools such as Get-
BitLockerVolume and manage-bde expose these states on a live host. Memory analysis may not reproduce
every status field, but the distinction guides interpretation of volume objects, drivers, mount points, and file
activity. [3]

Do not rely solely on a graphical encryption application. A management interface may exit after a

container is mounted while a driver continues to expose the file system. VeraCrypt, for example,
documents that the stored data remains encrypted while the mounted volume is available through the
driver, and that the volume becomes inaccessible again after unmount or restart. [12]

Connect Storage to Processes

For an encrypted container, try to connect three elements: the underlying container or device, the

mounted file-system location, and the processes accessing files through that location. Drive letters, mount
points, device names, file objects, handles, mapped paths, command lines, user sessions, and application
buffers can help establish the chain. A handle to a file on the mounted volume is stronger evidence of
interaction than the container file alone, but further evidence is needed to show how much was read or
whether anything was transmitted.

Transparent file encryption shifts the focus toward the consuming application. An authorized document

editor can receive plaintext from EFS without performing the file-system decryption itself. Application-
managed encryption requires tracing the primary process, helper processes, loaded cryptographic libraries,
temporary files, shared memory, clipboard use, and connections. A protected attachment might pass
through a messaging client, an extraction process, a temporary directory, and a document viewer, with
different evidence in each location.

Legitimate Use, Malicious Access, and Ransomware

Possible signs of unauthorized access include an unexpected process holding protected-file handles, code

injection into an authorized application, suspicious cross-process access, archive or staging activity,
command lines that reference protected paths, and external connections associated with data-accessing
processes. These observations justify deeper examination. Collection or exfiltration requires a broader
evidentiary chain.

In ransomware cases the question is reversed: which process encrypted accessible data? Memory may

help identify the responsible process, ancestry, target paths, open files, command-line options, ransom-note
text, network infrastructure, unpacked code, and cryptographic operations. The presence of a cryptographic
library is not proof of ransomware because legitimate software uses the same primitives. Behavior, targets,
execution context, and file-system change must align.

Search for Decrypted Content

Searches should be process-centered and hypothesis-driven. Scanning an entire image for common words

can produce thousands of unrelated matches and weaken provenance. Begin with the application, service,
driver, or suspicious process most likely to have handled the protected data.

Target Relevant Regions and Known Content

Windows virtual address descriptors describe ranges in a process address space and their properties.

Combined with mapped-file and process context, they help narrow the search to image-backed, file-backed,
heap, stack, and other allocations before extraction. Relevant regions may contain application buffers,
document or message fragments, filenames, paths, search terms, database records, configuration, clipboard
content, or structured objects. [5, 11]

Known-content searches are usually more productive than generic keyword searches. A distinctive

document phrase, unique record identifier, email address, filename, heading, field name, or case-specific
account can reduce false matches. Search multiple encodings, including UTF-8 and UTF-16, and expect
fragmentation, serialization, compression, and pointer-based structures. A search that returns no hit is
inconclusive because the content may have moved, changed form, or fallen outside the acquisition.

Mapped Files, Cached Objects, and Fragments

Windows can associate file contents with a process virtual address range through file mapping. Compare

mapped-file paths, file handles, memory ranges, cached file objects, recovered content, and the protected
source on disk. Volatility 3 can extract certain cached file contents from a memory image, but recovered
objects may be partial, stale, or modified. Hash and preserve each extracted item with its source object,
process association, method, and limitations. [11, 20]

Small fragments can still be probative. A paragraph, database row, message subject, account number,

temporary extraction path, or request built from protected data may establish that information reached a
process. Preserve surrounding bytes and structure. Report the narrow finding, such as a text fragment
matching a protected document recovered from a private region of the active viewer, rather than claiming
recovery of the complete document.

Secondary Copies and Memory Clearing

Protected data may move through child processes, previews, thumbnails, temporary files, clipboard

operations, security scanners, and shared-memory components. Trace process ancestry, paths, timestamps,
and handles before deciding whether a secondary copy reflects normal behavior or unauthorized access.

Security-conscious applications may clear sensitive buffers. Microsoft advises applications using

CryptProtectMemory to clear sensitive information when it is no longer needed. That practice narrows the
recovery window, but it cannot guarantee that every copy disappeared. Libraries, interface components,
child processes, logs, or temporary files may have duplicated the value. [7]

Analyze Candidate Credentials and Key Material

Passwords, recovery credentials, derived keys, session keys, volume keys, and expanded key schedules

are different artifacts. A value should not be labeled from length, entropy, or proximity to an encryption-
related string alone.

Distinguish Authentication from Encryption Keys

BitLocker illustrates a layered design. The Full Volume Encryption Key encrypts volume data, the

Volume Master Key protects that operational key, and one or more key protectors secure the Volume
Master Key through mechanisms such as a TPM, PIN, startup key, password, or recovery material. An
examiner might recover a user-entered secret, protector-related data, derived material, an operational key,
or an expanded key structure. These values are not interchangeable, and finding one does not mean the
others were recovered. [3]

Search within components associated with the relevant operation: encryption drivers and services,

applications that opened protected files, authentication processes, password managers, archive or database
tools, and processes performing unauthorized encryption. Plain text credentials may exist briefly before
protection or while being used, but applications can clear them, transform them through key derivation, or
rely on hardware-backed operations that reduce exposure.

Recognize Structure, Then Validate

Searching for high-entropy data alone produces many false candidates, including compressed data,

encrypted blocks, executable code, and unrelated buffers. Some software implementations retain expanded
cipher key schedules with recognizable structural redundancy. Cold-boot research demonstrated that those
structures can help identify or reconstruct keys even when memory contains errors. Structural consistency
makes a candidate more interesting, but it does not reveal which device, application, or connection used it.
[13]

Treat a suspected credential or key as a candidate until four questions are answered: Where was it found?

Is its format consistent with the expected mechanism? Was the relevant application or volume active? Does
it produce the expected repeatable result against authorized evidence? Test only a working copy. Confirm
more than a successful mount or API return by checking the expected file system, files, metadata, or case-
specific content.

Record failed candidates and unsuccessful tests. They define the limits of the examination, prevent

repeated effort, and demonstrate that the final assessment resulted from validation rather than selection
bias. A report should distinguish a working volume key from a user password and a session key from a
long-term secret.

Protect Recovered Secrets

A validated key or password may expose more information than the original artifact and may remain

valid for other systems or backups. NIST key-management guidance treats keying material as sensitive
throughout its lifecycle. Store recovered secrets separately where appropriate, encrypt them at rest, restrict
access, and avoid unnecessary disclosure in screenshots or narrative reports. [14]

Correlate Memory with Disk and Application Evidence

Memory is a snapshot, not a self-sufficient account. A defensible examination compares volatile findings

with independent sources that can confirm the encryption mechanism, timing, user, process, and activity.
The point of correlation is to determine whether the sources describe the same object or event, not simply
whether they contain the same string.

Persistent Storage, Paging, and Hibernation

A disk image can preserve partitions, encryption metadata, container files, protected databases, file

attributes, and application configuration. The disk establishes what was stored; memory helps establish
what was accessible or active. A handle to a file on a mounted volume can be compared with the persistent
path, and a memory fragment can be compared with the authorized file after successful access or
decryption.

Windows may move modified pageable data from RAM to a page file. Page files may retain content that

was not physically resident at acquisition, including plain text fragments, paths, application buffers, and
cryptographic structures. They often provide less process context than a structured memory image, so
ownership has to be reconstructed cautiously from adjacent data and corroborating sources. [19]

Standard hibernation writes the contents of physical memory to Hiberfil.sys so that Windows can restore

the operating system, applications, and devices. Fast Startup is different: Windows logs off user sessions
first and preserves kernel, driver, and session 0 state in the hibernation file. Determine which power
transition produced the file before treating it as a complete user-session image, and establish whether it
represents the incident period. [8]

Application, Event, and Command Records

Applications may retain recent-file lists, session databases, temporary or auto-recovery files, cached

previews, database journals, archive extraction paths, mount history, and application-specific logs. These
records can support or challenge a memory interpretation. A filename in a process may reflect interactive
use, preloading, indexing, scanning, or preview generation; normal application behavior matters.

Depending on the configured providers and audit policy, Windows Event Logs may document startup,

authentication, storage activity, application execution, PowerShell activity, security controls, and
encryption-related errors. PowerShell operational logs and Script Block Logging can add command context
when they were enabled before the incident. Missing records are not proof that an action did not occur. [9,
10]

Normalize timestamps carefully. Record the source, time zone, UTC conversion, system clock error,

acquisition duration, delayed writes, and clock differences between endpoints and sensors. Do not present
timestamps from unrelated sources as equally precise.

Endpoint and Network Telemetry

EDR, DNS, firewall, proxy, packet-capture, cloud, DLP, email, messaging, and remote-access records

can help determine whether access to protected data remained local. An external connection alone is weak
evidence of exfiltration. Stronger support may come from transfer volume, staging or archive creation,
protocol activity, destination ownership, matching server logs, or data observed elsewhere.

Preserve contradictions. A suspicious process handle may initially suggest unauthorized access, while

signing records and telemetry may show an approved security scanner. Classify findings as confirmed,
supported, unresolved, or contradicted, and state what additional evidence would be needed. Correlation
should expose uncertainty, not force the evidence into a preferred narrative.

Distinguish Three Memory-Analysis Scenarios

"Memory analysis" can refer to live endpoint forensics, sandbox guest analysis, or reverse engineering of

code recovered from memory. They are complementary, but they answer different questions and must
retain separate provenance.

Live Endpoint Memory

A live endpoint image represents the actual investigated system. It can preserve real users, mounted

volumes, open protected files, services, drivers, connections, decrypted fragments, and malicious
interaction. Volatility 3 interprets a supported memory image; it does not acquire the image itself. The
acquisition utility and the analysis framework are separate evidentiary stages with separate versions,
commands, hashes, and limitations. [11]

Sandbox Guest Memory

A malware sandbox observes a sample in an isolated guest. When enabled, CAPEv2 can create a full

guest-memory dump, generate process memory dumps, and capture unpacked, injected, extracted, or
decompressed executable content. CAPEv2 documented completion of its Volatility 3 integration in
February 2021. Configuration determines whether memory processing runs and which plugins are selected;
CAPE v2.5, released January 16, 2026, added more Volatility 3 modules. [15, 16]

Sandbox memory shows what occurred during a controlled detonation, not what necessarily occurred on

the original endpoint. The guest can differ in operating-system build, applications, user activity, privileges,
security controls, and network conditions, and malware may change behavior when it detects analysis.
Sandbox results support hypotheses and behavioral understanding; incident claims still require endpoint,
disk, or network confirmation.

Extracted Code and Reverse Engineering

Memory examination may recover an executable, injected module, shell code region, unpacked payload,

or partial process image. Static reverse engineering can then examine executable structure, imports, strings,
constants, control flow, cryptographic routines, configuration handling, and anti-analysis logic. Ghidra
provides disassembly, decompilation, graphing, scripting, and interactive analysis of compiled code. It does
not reconstruct Windows process objects, handles, or network state. [17]

The questions remain distinct: memory forensics asks where code ran and what resources it could access;

reverse engineering asks what the code appears designed to do; sandboxing asks what it did under
controlled conditions. A strong investigation may use all three, but it should never merge an endpoint
memory object, a sandbox dump, and a reverse-engineering report into one undifferentiated source.

From Forensic Finding to Decision Support

Recovering an artifact does not finish the investigation. The examiner still has to preserve its source, test

its reliability, record contradictory evidence, and explain what action the finding can support. This is the
point where forensic analysis becomes decision support.

Separate Observation from Judgment

Consider the observation: "Process 4268 held a handle to E:\Protected\AcquisitionPlan.docx." That fact

does not establish that the process read the complete document, displayed it to a user, copied it, or
transmitted it. Additional evidence might show that the protected volume was unlocked, the process
belonged to the active user, matching text appeared in its private memory, and recent-file artifacts
referenced the same path. The supported conclusion could then be that the document was opened and
processed during the captured session, not that it was exfiltrated.

A durable case record keeps five things separate: the observation; provenance such as the image, process,

address, command, and tool version; validation from independent evidence; the analyst interpretation; and
the confidence, contradictions, and limitations attached to that interpretation. Tool output should remain
distinct from analyst judgment, and unresolved artifacts should remain available for later review.

Promote Only Validated Artifacts

Memory may yield hashes, domains, IP addresses, URLs, paths, mutexes, process names, or ATT&CK-

related behaviors. Do not automatically turn each value into a detection or intelligence indicator. Evaluate
source context, incident relevance, corroboration, false-positive risk, expected lifetime, and handling
restrictions. A rejected operational indicator may still be useful evidence for a hypothesis or an identified
intelligence gap.

THRaXe as a Downstream Example

THRaXe provides one example of a downstream workflow. It can preserve malware-analysis artifacts,

manage indicator life cycle, record confidence and analyst justification, correlate samples with threat-
intelligence entities, and maintain permission-aware, auditable decisions. It is not a replacement for live
memory acquisition or direct Volatility analysis. [18]

Its current architecture uses Ghidra for static reverse engineering and an external CAPEv2 environment

for behavioral analysis. When Volatility 3 processing is enabled inside CAPEv2, memory-derived sandbox
findings can be carried in the CAPE results returned to the wider workflow. That is indirect Volatility 3
support through CAPEv2, not native acquisition or analysis of endpoint RAM by THRaXe. [16, 18]

A practical chain may begin with endpoint memory identifying a suspicious executable and related

indicators. The recovered sample can then be validated, reverse engineered, and detonated. Confirmed
hashes, domains, behaviors, and relationships can be retained with the evidence and reasoning behind them.
The operational value comes from traceability, not from the number of tools in the chain.

Common Analytical Errors

Most failures in this area are interpretive, not mechanical. A tool may extract the right artifact while the
report assigns it more meaning than the evidence can carry. The following mistakes are especially common.

Treating Encryption as a Single Condition

A locked disk, an unlocked volume, an open encrypted file, and an authenticated application session
represent different forensic states. Investigators should identify whether the protected resource was merely
present, mounted, actively accessed, or decrypted for use.
An encrypted container on disk establishes presence, nothing more. A mounted volume establishes
accessibility, not file-by-file use. Plain text in memory shows exposure to a process, but it does not reveal
how long the content was present or whether a user intentionally viewed it.

Powering Down Before Evaluating Volatile Evidence

Shutting down a running system can return encrypted storage to a protected state while erasing the session
information needed to explain how the data was being used. Mount context, process relationships, open
handles, decrypted fragments, and cryptographic material may not survive a normal shutdown.
This does not mean investigators should always acquire RAM before taking any other action. Safety, active
exfiltration, destructive malware, operational impact, and legal authority may require a different priority.
The error is failing to make and document the decision deliberately.

Searching for Keys Before Establishing Context

Memory is full of high-entropy data, encrypted and compressed blocks, executable code, and cryptographic
material unrelated to the case. A whole-image search for key-shaped byte sequences can therefore produce
an impressive list of false candidates.
A stronger approach begins with the relevant process, driver, session, or memory region. The examiner
should identify which component handled the encrypted resource before evaluating candidate credentials or
key material. Structural similarity may justify testing, but only functional validation can establish that a
candidate works with the authorized evidence.

Treating Readable Strings as Verified Plain text

Readable text is common in RAM. It may come from application resources, cached data, earlier activity,
released buffers, indexing, logging, or an unrelated file.
A plain text fragment becomes meaningful when the examiner can connect it to the relevant process, file,
volume, session, or application object. The conclusion should reflect the strongest relationship that can be
demonstrated, such as a string found in a relevant process, content associated with a mapped file or open
handle, or content independently matched to the protected source.

Ignoring Process Ownership

The same filename or document fragment can have different meanings depending on where it was found. A
path in a document editor may indicate user access. The same path in an antivirus process may reflect
security scanning. A matching fragment in an indexing service may indicate automated processing rather
than interactive use.
Process ownership, parent-child relationships, session context, loaded modules, handles, and network
activity provide the context needed to interpret the artifact.

Confusing Access with Exfiltration

Opening a protected file is not the same as exfiltrating it. An external connection associated with the
process is also insufficient on its own. The conclusion depends on whether the evidence connects access,
collection or staging, and an actual transfer path.
An exfiltration assessment should look for a supported chain of activity:
1. Access to the protected resource.
2. Collection or staging.
3. Archive or transformation activity.
4. A relevant outbound connection.
5. Transfer evidence in endpoint, network, proxy, or remote-service records.
Where one or more steps are missing, the report should describe the evidence as suspicious access, possible
collection, or an unresolved exfiltration hypothesis rather than a confirmed transfer.

Assuming Tool Output Is a Conclusion

Memory-analysis tools parse operating-system structures and expose artifacts. They do not decide intent,
authorization, or evidentiary significance; that remains an analytical task.
A process listing identifies processes. A handle listing identifies object references. A network scan
identifies network structures. A string search identifies matching bytes. The analyst must still determine
whether the output is complete, correctly parsed, relevant to the encryption mechanism, and corroborated
by other evidence.
Errors, symbol problems, unsupported operating-system builds, corrupted structures, and acquisition
inconsistencies should be retained in the case record because they affect confidence in the results.

Treating Sandbox Memory as Endpoint Memory

Memory captured during malware detonation describes the sandbox guest, not the original system. It can
reveal unpacked payloads, injected code, configuration, network behavior, or cryptographic operations
performed during controlled execution.
The sandbox may differ from the investigated endpoint in operating-system version, privileges, files,
applications, security controls, network access, and user activity. Malware may also change behavior when
it detects virtualization or analysis tooling. Use sandbox findings to understand behavior and generate
hypotheses, then test incident claims against endpoint, disk, or network evidence.

Assuming a Missing Artifact Proves an Event Did Not Occur

Relevant memory may have been overwritten, paged out, cleared, compressed, stored in another
representation, or missed by an incomplete acquisition. Failure to recover a password, key, or plain text
fragment defines a limit of the examination. It does not establish that the protected data was never accessed.
Negative findings are still useful when stated accurately.
For example: "No validated BitLocker key material was identified in the acquired memory image using the
documented examination methods." That statement is more defensible than claiming that no key existed in
memory at any point during the session.

Failing to Preserve Contradictory Evidence

The first plausible explanation can become difficult to dislodge. When analysts retain only the artifacts that
support it, confirmation bias replaces reviewable analysis.
A suspicious process handle may support unauthorized access, while code-signing data or endpoint
telemetry may identify the process as an approved security product. Both findings must be preserved.
Contradictions affect confidence and may identify additional questions that the investigation must resolve.

Mixing Observations, Interpretations, and Conclusions

A clear report should distinguish among three levels:

Observation:

A process held a handle to a file on an unlocked encrypted volume.

Interpretation:

The process had the ability to interact with the file.

Conclusion:

The process read the file, supported by matching content recovered from its memory and

corroborating application records.
When those levels blur, a limited artifact can be presented as proof of a complete event. Keeping them
separate makes the reasoning easier to review, challenge, and reproduce.

Overstating the Role of Automation

Automation is well suited to repetitive work such as process enumeration, artifact extraction, sandbox
detonation, indicator normalization, and correlation. It cannot replace source validation, context, or human
judgment.
Platforms such as CAPEv2, Volatility 3, Ghidra, and THRaXe support different stages of the workflow.
Their outputs become defensible only when provenance is preserved and the analyst explains how the
evidence supports the final assessment.

A smaller set of well-sourced findings is more useful than a larger collection of poorly contextualized
artifacts. The record should preserve the relationship among the protected resource, the volatile state, the
analytical method, the corroborating evidence, and the conclusion.

Practical Investigation Checklist

This checklist provides a repeatable sequence for examining encrypted data and volatile memory. It does
not replace organizational procedures, legal authority, or examiner judgment. Adapt it to the operating
system, encryption technology, incident type, and available evidence.

1. Confirm Authority and Scope

Before interacting with the system:

●

Verify legal, administrative, and investigative authority.

●

Identify the systems, accounts, applications, and data included in scope.

●

Determine whether protected, privileged, classified, regulated, or personally identifiable information
may be exposed.

●

Establish handling requirements for recovered credentials and cryptographic material.

●

Record the date, time, examiner, system location, and initial condition.

2. Document the Live System

Before changing the system state:

●

Photograph or record the visible screen.

●

Note logged-in users and active sessions.

●

Record displayed applications, warnings, and error messages.

●

Identify visible drive letters, mounted containers, network shares, and remote sessions.

●

Record the system time and compare it with a trusted time source.

●

Note connected storage devices and network interfaces.

●

Document whether the system appears locked, unlocked, hibernating, or actively processing data.

3. Evaluate Immediate Risk

Determine whether the system is:

●

Actively encrypting or deleting files

●

Communicating with suspected malicious infrastructure

●

Exfiltrating data

●

Running destructive malware

●

Dependent on a remote session or network resource

●

Likely to lose access to encrypted data if power or connectivity is removed

Document the reason for isolating the system, leaving it connected, or taking another containment action.

4. Acquire Volatile Evidence

Using approved tools and procedures:

●

Capture physical memory.

●

Record the acquisition tool, version, configuration, and command.

●

Capture relevant system and network information when authorized.

●

Preserve page files and hibernation files during subsequent storage acquisition.

●

Record acquisition start and completion times.

●

Hash the resulting image immediately.

●

Preserve tool logs, warnings, and error messages.

●

Create verified working copies for analysis.

Analyze a verified working copy, not the original acquisition file.

5. Establish the System-State Baseline

Identify:

●

Operating-system version and build

●

Active and recently terminated processes

●

Process identifiers and parent-child relationships

●

User sessions and authentication context

●

Services and drivers

●

Loaded modules

●

Command lines and console activity

●

File and object handles

●

Network connections

●

Signs of process injection or hidden execution

Record parsing errors or unsupported structures that may limit the analysis.

6. Identify the Encryption Mechanism

Determine whether the protected data involves:

●

Full-disk or volume encryption

●

An encrypted container

●

File-level encryption

●

An encrypted archive

●

A password manager or application vault

●

An encrypted database

●

Secure messaging or communications software

●

Malware or ransomware encryption

Identify the relevant applications, services, drivers, files, volumes, and configuration artifacts.

7. Determine the Access State

Evaluate whether the protected resource was:

●

Present but locked

●

Mounted or unlocked

●

Open in an application

●

Referenced by a process

●

Decrypted into memory

●

Copied, staged, or transmitted

●

Re-encrypted by malicious activity

Do not treat these states as equivalent. Record the evidence supporting each determination.

8. Examine Relevant Processes

Prioritize processes that:

●

Mounted or managed the protected resource

●

Opened files from the protected location

●

Displayed or processed decrypted content

●

Received user credentials

●

Communicated with external systems

●

Created archives or temporary files

●

Accessed authorized applications unexpectedly

●

Performed suspicious encryption activity

For each relevant process, preserve its session, command line, parent, handles, mappings, loaded code,
network activity, and extracted memory regions.

9. Search for Decrypted Content

Use case-specific search terms such as:

●

Unique document phrases

●

Filenames and protected paths

●

Record identifiers

●

Email addresses

●

Account numbers

●

Database fields

●

Message subjects

●

Known file signatures

Search appropriate encodings and preserve surrounding context. Record the process, memory address,
region type, search method, and relationship to the protected source.

10. Evaluate Credentials and Key Material

For each candidate:

●

Record where it was recovered.

●

Determine whether its format matches the expected credential or key type.

●

Associate it with the relevant process, driver, or session.

●

Preserve surrounding structures and metadata.

●

Test only against verified working copies.

●

Confirm that successful access produces the expected file system, file, database, or application state.

●

Record unsuccessful tests.

●

Store validated credentials and keys as sensitive evidence.

Do not describe a value as a confirmed password or key until it has been functionally validated.

11. Correlate with Persistent Evidence

Compare memory findings with:

●

Disk and file-system artifacts

●

Encryption metadata

●

Application histories and logs

●

Recent-file records

●

Temporary and recovery files

●

Page files and hibernation files

●

Windows Event Logs

●

PowerShell and command history

●

Endpoint detection telemetry

●

Firewall, DNS, proxy, and packet records

●

Cloud and remote-service audit logs

Preserve evidence that contradicts the working hypothesis as well as evidence that supports it.

12. Separate Evidence Sources

Clearly distinguish among:

●

Memory acquired from the affected endpoint

●

Memory generated during sandbox detonation

●

Files or payloads extracted from memory

●

Static reverse-engineering results

●

Behavioral-analysis results

●

Threat-intelligence or correlation-platform findings

Treat sandbox behavior as a lead, not proof of endpoint behavior, unless incident-specific evidence
corroborates it.

13. Form and Test Conclusions

For each major finding, document:

Observation:

What was recovered or parsed.

Provenance:

Where the artifact originated and how it was produced.

Interpretation:

What the artifact may indicate.

Validation:

What independent evidence supports or challenges the interpretation.

Conclusion:

The narrowest defensible statement.

Confidence:

Confirmed, supported, unresolved, or contradicted.

Limitations:

Missing evidence, acquisition gaps, parsing problems, timing uncertainty, or alternative

explanations.

14. Preserve the Analytical Record

Retain:

●

Original and working-image hashes

●

Tool names and versions

●

Commands and configuration files

●

Symbols and supporting data

●

Exported artifacts

●

Screenshots and notes

●

Search terms

●

Failed and successful validation attempts

●

Analyst interpretations

●

Contradictory evidence

●

Final reports and review history

The record should allow another reviewer to follow the path from the original acquisition through each
analytical step to the final conclusion.

Conclusion

Encryption changes the order of operations. On a live system, the first question is not simply whether the
media is encrypted, but what is currently unlocked, mounted, open, and being processed.
RAM may preserve details that disappear at shutdown: active processes, mounted-storage context, open file
references, user sessions, network connections, plain text fragments, and candidate key material. That
opportunity is temporary and incomplete. Acquisition improves the chance of recovery; it never guarantees
a password, key, or complete document.
A disciplined examination preserves the live state, builds a system baseline, identifies the protection
mechanism, and narrows the search to the components that handled the data. Candidate content,
credentials, and keys keep their provenance and are tested only against authorized working copies. Disk
artifacts, application records, logs, endpoint telemetry, and network evidence then provide the
corroboration.
Live endpoint memory, sandbox guest memory, and code extracted for reverse engineering are different
evidence sources. Volatility 3, CAPEv2, and Ghidra support different parts of the work. Their findings can
reinforce one another only when the source and limitations of each object remain clear.
Automation and decision-support platforms help organize artifacts, repeat analysis, manage indicators, and
preserve review history. They do not decide what an artifact means. That judgment still belongs to the
examiner and must be visible in the record.
The useful question is not whether the examiner can "break" encryption. It is what state the system was in,
what that state exposed, and what the evidence can actually prove.

Key Terms

Data at rest:

Information stored on persistent media, including encrypted volumes, containers, files, and

databases.

Data in use:

Information actively processed by an operating system, application, or hardware component.

Volatile data:

Live-system information that can be lost when power is removed or the system state

changes.

Memory image:

A captured representation of physical memory acquired for forensic examination.

Virtual address descriptor (VAD):

A Windows structure describing a range within a process virtual

address space.

Key protector:

A mechanism that protects or releases another cryptographic key, such as a TPM, PIN,

password, recovery value, or startup key.

Expanded key schedule:

Round-key material derived from a cipher key for use by a block-cipher

implementation.

Provenance:

The documented origin, processing history, and evidentiary context of an artifact or finding.

Functional validation:

Testing a candidate credential or key against authorized evidence to confirm the

expected repeatable result.

Sandbox memory:

Memory captured from an isolated analysis guest during controlled execution, not from

the original endpoint.

References

[1] K. Kent, S. Chevalier, T. Grance, and H. Dang, Guide to Integrating Forensic Techniques into Incident

Response, NIST SP 800-86, 2006. https://doi.org/10.6028/NIST.SP.800-86

[2] National Institute of Standards and Technology, "Volatile Data," CSRC Glossary.

https://csrc.nist.gov/glossary/term/volatile_data

[3] Microsoft, "BitLocker Overview," "BitLocker FAQ," "Get-BitLockerVolume," and manage-bde

documentation. https://learn.microsoft.com/windows/security/operating-system-security/data-
protection/bitlocker/ ; https://learn.microsoft.com/windows/security/operating-system-security/data-
protection/bitlocker/faq ; https://learn.microsoft.com/powershell/module/bitlocker/get-bitlockervolume ;
https://learn.microsoft.com/windows-server/administration/windows-commands/manage-bde

[4] Microsoft, "Backup and Restore of Encrypted Files" and "File Encryption."

https://learn.microsoft.com/windows/win32/fileio/backup-and-restore-of-encrypted-files ;
https://learn.microsoft.com/windows/win32/fileio/file-encryption

[5] Microsoft, "Virtual Address Space." https://learn.microsoft.com/windows/win32/memory/virtual-

address-space

[6] Microsoft, "Virtual Address Space and Physical Storage."

https://learn.microsoft.com/windows/win32/memory/virtual-address-space-and-physical-storage

[7] Microsoft, "CryptProtectMemory function." https://learn.microsoft.com/windows/win32/api/dpapi/nf-

dpapi-cryptprotectmemory

[8] Microsoft, "System Power States." https://learn.microsoft.com/windows/win32/power/system-power-

states

[9] Microsoft, "Windows Event Log." https://learn.microsoft.com/windows/win32/wes/windows-event-log
[10] Microsoft, "about_Logging."

https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_logging

[11] Volatility Foundation, Volatility 3 Documentation, Windows tutorial, symbol-table documentation,

and plugin reference. https://volatility3.readthedocs.io/

[12] IDRIX, "VeraCrypt Introduction." https://veracrypt.io/en/Introduction.html
[13] J. A. Halderman et al., "Lest We Remember: Cold-Boot Attacks on Encryption Keys," 17th USENIX

Security Symposium, 2008. https://www.usenix.org/conference/17th-usenix-security-symposium/lest-
we-remember-cold-boot-attacks-encryption-keys

[14] E. Barker, Recommendation for Key Management: Part 1 - General, NIST SP 800-57 Part 1 Rev. 5,

2020. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[15] CAPEv2 Project, CAPE Sandbox v2.5 Book, analysis results and submission options.

https://capev2.readthedocs.io/ ; https://github.com/kevoreilly/CAPEv2

[16] CAPEv2 Project, changelog entries for Volatility 3 integration (February 5, 2021) and CAPE v2.5

(January 16, 2026). https://github.com/kevoreilly/CAPEv2/blob/master/changelog.md

[17] National Security Agency, Ghidra Software Reverse Engineering Framework.

https://github.com/NationalSecurityAgency/ghidra

[18] BITS-N-BYTES.io, LLC, THRaXe Capability Statement, architecture diagram, and platform help

documentation, 2026. Author-provided technical documentation.