In this lesson, you’ll learn about: memory forensics and RAM analysis1. Why Memory Forensics Matters
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
- RAM (volatile memory) is one of the most valuable forensic sources
- It contains data that disappears after shutdown
- Running processes
- Active network connections
- Command history
- Encryption keys
- Malware behavior in real time
- If disk is “history,” RAM is live truth
- Creating a snapshot of physical RAM for analysis
- DumpIt
- Simple one-click RAM dump tool
- Used widely in field forensics
- NotMyFault
- Forces system crash
- Generates full kernel memory dump
- DumpIt → fast and simple
- Crash dump → deeper but disruptive
- Process objects
- Suspicious threads
- Injected code
- Hidden malware artifacts
- Malware often exists only in memory
- Disk analysis alone may miss it
- Look for:
- Passwords
- URLs
- Commands
- API keys
- Identify:
- Legitimate processes
- Suspicious or orphaned processes
- Detect:
- Code injection
- Hidden execution paths
- A powerful memory forensics framework for analyzing RAM dumps
- Extracts structured evidence from raw memory images
- Shows active processes
- Based on system process list
- Finds hidden or terminated processes
- Scans memory directly
- Cross-checks multiple process sources
- Detects rootkits and hidden malware
- If a process appears in psscan but not pslist, it may be hidden
- First step in analysis is identifying:
- Operating system version
- Memory structure layout
- Correct profile = accurate results in Volatility
- Injected DLLs
- Suspicious network activity
- Hidden execution threads
- Malware often hides better in RAM than on disk
- Extract evidence
- Convert results into structured reports
- Document every forensic step
- Make results repeatable and legally defensible
- RAM is the most dynamic and valuable forensic source
- Memory acquisition must be done carefully to preserve evidence
- Tools like DumpIt and crash dumps capture volatile data
- Volatility enables deep inspection of memory structures
- Cross-checking process lists helps detect hidden malware
- Capture RAM → Identify OS → Analyze processes → Detect anomalies → Report findings
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
So think about the computer you're using right now, like,
right at this very second, someone wanted to see your
unencrypted passwords, or you know, the websites you're silently connected to,
or even the exact keystrokes you made five minutes ago,
where would they look.
Speaker 2 (00:15):
Most people would probably points straight to the.
Speaker 1 (00:20):
Hard drive, Yeah, exactly, the hard driver, maybe like cloud storage.
But the true answer is actually much more elusive. All
of that incredibly sensitive active data, it lives in the
random access memory, the RAM.
Speaker 2 (00:33):
It really is a profound realization when you when you
first start looking closely at digital systems. We're just so
conditioned to think about data in terms of static gigabytes
right sitting permanently on a disc somewhere right.
Speaker 1 (00:45):
Like it's carved in stone exactly.
Speaker 2 (00:47):
But the actual lifeblood of the machine, the thoughts it's
having right at this very second, they exist purely in
a volatile state.
Speaker 1 (00:54):
And that brings us to the mission for today's deep dive.
We are asking you, the listener, to essentially step into
the shoes of a digital forensic investigator today.
Speaker 2 (01:04):
I love that.
Speaker 1 (01:05):
Yeah. We're going on a guided audio journey, step by
step through the frontier of memory forensics. We're going to
explore exactly why this volatile memory is the ultimate gold
mine for uncovering cyber attacks, and.
Speaker 2 (01:18):
How you can actually trap and capture a snapshot of
it before it disappears, right, exactly.
Speaker 1 (01:22):
Plus we'll get into the specific tools and techniques used
to hunt down hidden malware.
Speaker 2 (01:27):
It's going to be fun because to really appreciate why
we're hyper focusing on RAM, we have to look at
how this completely flips the traditional script of digital forensics.
Speaker 1 (01:37):
Yeah, the old school way right.
Speaker 2 (01:39):
For the longest time, the absolute standard operating procedure when
you encountered a compromise machine was well, it was simple
and decisive.
Speaker 1 (01:47):
You pull the plug, just rip it out of the wall.
Speaker 2 (01:49):
Literally disconnect the network, rip the power cord out, extract
the physical hard drive and investigate the disc.
Speaker 1 (01:56):
And I mean the logic there is sound on the surface.
You want to freeze the crime scene, right, You physically
isolate the infected drive so the malware can't communicate with
the outside world or start deleting files.
Speaker 2 (02:07):
Exactly. Historically, an investigator would take that physical disc and
use a data dumper. A really classic tool for this
is dd doxe, right, and you use that to create
a perfect sector bisector duplicate of the drive.
Speaker 1 (02:22):
And then to prove that the copy was utterly flawless
and you tamper proof for a court of law, they
would run an MT five checksum.
Speaker 2 (02:30):
Yes, the checksum is crucial. You essentially pass the entire
drive through a mathematical algorithm and it spits out a
unique digital fingerprint.
Speaker 1 (02:39):
So if the fingerprint of your forensic copy perfectly matches
the original drive, your evidence is legally pristine.
Speaker 2 (02:46):
Which is a beautiful system for an era when a
hard drive held maybe a few gigabytes.
Speaker 1 (02:49):
Oh right, that's the catch.
Speaker 2 (02:50):
But we're looking at modern environments today and the physical
disc approach is just cracking under the pressure. First off,
we're dealing with terabytes upon terabytes of store now. Oh easily,
creating a sector bisector image of a massive enterprise server
takes an internity.
Speaker 1 (03:06):
Right, And when a corporation is under active cyber attack,
you don't have three days to sit around waiting for
a progress bar to reach one hundred percent.
Speaker 2 (03:13):
No, the business impact is simply too high. Taking a
critical system offline to image the drive translates to catastrophic downtime.
Speaker 1 (03:23):
It's just not practical anymore.
Speaker 2 (03:24):
But there is a much more fatal flaw here from
a purely investigative standpoint, which is what the moment you
rip that power cord out of the wall, you instantly
destroy all the volatile information stored in the RAM.
Speaker 1 (03:37):
Because it requires a constant electrical current to hold data.
Speaker 2 (03:40):
Exactly. Yeah, no power, no data, It's gone forever.
Speaker 1 (03:43):
And malware developers know this, don't they. They're actively using
our own traditional forensic protocols against us.
Speaker 2 (03:48):
They absolutely are. It's a cat and mouse game. And
to understand how they do it, this requires us to
look under the hood at the dynamic between virtual memory
and physical memory.
Speaker 1 (03:58):
Okay, let's break that down.
Speaker 2 (04:00):
So picture the operating system as a massive complex office building.
Inside there's a memory manager. Its entire job is to
take pages of data that are temporarily waiting in virtual
memory and seamlessly map them over to permanent active slots
in the physical RAM hardware, just.
Speaker 1 (04:17):
To keep the computer running blazingly fast exactly.
Speaker 2 (04:21):
Modern malware is designed to hijack that exact process. Instead
of downloading a malicious dot xy file onto the hard
drive where an anti virus scanner can easily spot it,
sophisticated malware essentially lives off the.
Speaker 1 (04:35):
Land, meaning it doesn't touch the hard drive at all.
Speaker 2 (04:38):
Right, It loads its malicious code directly into the active RAM.
It corrupts the operating system's own memory manager. It executes
its attacks entirely in this volatile space, deliberately avoiding writing
any files to the hard disk.
Speaker 1 (04:52):
Wow, which means if you pull the plug and solely
analyze the hard drive, you will find absolutely nothing. The
malware leaves zero footprint, nothing at all. You know, analyzing
a traditional hard drive image, it's sort of like searching
through a frozen archived filing cabinet down in the basement.
Speaker 2 (05:09):
That's a great way to put it, right.
Speaker 1 (05:10):
You'll find the permanent record, sure, but it takes months
to sift through, and it tells you absolutely nothing about
what the rogue employee upstairs was doing five minutes ago.
Analyzing the RAM, however, is like standing in the active
office and observing the sticky notes scattered all over that
worker's desk, right before they get thrown in the trash.
Speaker 2 (05:27):
Yes, you can read the passwords they just typed. You
can see the unencrypted network portals they just opened.
Speaker 1 (05:33):
Everything is right there out in the open.
Speaker 2 (05:36):
That is a phenomenal way to visualize it, and it
highlights a terrifying reality. If a machine is compromised at
the memory level, you can no longer trust the information
the computer is giving you about its own state.
Speaker 1 (05:48):
Because the operating system itself will lie to you.
Speaker 2 (05:51):
It will it'll hide the malicious processes. Therefore, the only
reliable countermeasure is to freeze time. We have to capture
a perfect snap shot of that RAM state before the
power is lost.
Speaker 1 (06:03):
Okay, So if the malware is hiding in the sticky
notes on the active desk, how do we sneak in
and photograph that desk before the computer throws everything away?
Speaker 2 (06:12):
Well, acquiring memory sounds like a dark art, but the
tools available now make it surprisingly accessible.
Speaker 1 (06:18):
Let's walk through that. What's the first method.
Speaker 2 (06:20):
Let's look at a tool quite literally called dump it.
Dump it very descriptive it is, and dump it is
brilliantly tactical. Precisely because of its simplicity. You don't need
to be a veteran forensic analyst to execute it. Okay,
Imagine an IT manager in a state of absolute panic
because the server is acting erratically. As long as they
(06:42):
are logged in with administrator privileges, they simply double click
and execute the dump it file.
Speaker 1 (06:47):
And what does it actually do?
Speaker 2 (06:49):
The tool automatically triggers takes a complete digital photograph of
the host's physical memory and saves that raw snapshot right
back into the folder it was launched from.
Speaker 1 (06:59):
So it's rapid response collection. But there is a touch
with dump it, right.
Speaker 2 (07:03):
Yeah, there is. Dump it is purely a collection mechanism.
It hands you the massive box of sticky notes, but
it provides zero built in capabilities to actually read or
organize them. It just dumps it, literally just dumps it,
which brings us to a far more integrated, albeit unconventional method. Okay,
Windows crash dumps.
Speaker 1 (07:19):
Now, wait, when anyone hears the phrase crash dump, the
immediate association is the dreaded blue screen of death. I mean,
that's the ultimate queue for a user to panic.
Speaker 2 (07:28):
Oh. Absolutely, In a normal environment, a blue screen is
a disaster. But in the realm of memory forensics, a
system crash is an incredibly powerful built in preservation tool.
How So, when a Windows system experiences critical, unrecoverable instability,
its internal architecture essentially hits an emergency stop button. To
(07:51):
figure out what went wrong later. The system's final dying
act is to take the entire contents of the physical
RAM and violently shove it straight.
Speaker 1 (07:59):
Over to the saving it as a file.
Speaker 2 (08:01):
Right, saving it as a file with a dot DMP extension.
Speaker 1 (08:04):
Wait, I need to stop and clarify this because it
sounds completely counterintuitive.
Speaker 2 (08:07):
I know, I know.
Speaker 1 (08:08):
Our entire goal is to carefully investigate a machine that
has been silently compromised by malware. Why in the world
would we intentionally force that delicate machine to suffer a
catastrophic crash and blue screen? It feels like breaking the evidence, right,
doesn't violently breaking the system risk destroying the exact evidence
we're hunting for.
Speaker 2 (08:27):
It feels wrong, doesn't it. But remember the physics of
RAM that we talked about earlier. Pulling the power plug
destroys the data because the electricity vanishes instantly. A software
initiated crash is entirely different. We are not cutting the power.
We are deliberately weaponizing the operating system's own failsafe protocol.
Speaker 1 (08:46):
Oh.
Speaker 2 (08:46):
I see, by forcing a controlled crash, we trigger that
emergency backup reflex. The crash process itself is what safely
writes the RAM contents to the disc before the system holds.
Speaker 1 (08:58):
So we are essentially pulling the fire alarm just so
the building's automated sprinklers will turn on.
Speaker 2 (09:03):
That is exactly it perfect analogy.
Speaker 1 (09:06):
Okay, that clarifies the strategy. We want the panic button backup.
So how does an investigator actually set this trap?
Speaker 2 (09:12):
Well, instead of aimlessly clicking through menus, you dive into
the Windows administrative core. You're essentially rewiring the operating system's
emergency response protocol.
Speaker 1 (09:21):
Okay, walk me through the steps.
Speaker 2 (09:23):
You'd navigate into the control panel, go to system that
advanced system settings. Under startup and recovery, you change the
debugging information protocol from the default to a complete memory dump.
Got it now. Crucially, the system will immediately beg you
to restart to apply those changes.
Speaker 1 (09:42):
Because Windows always wants to restart.
Speaker 2 (09:44):
Always, But you absolutely must ignore that prompt. If you
restart the machine, you flush the RAM and the malware
you're hunting vanishes into the ether.
Speaker 1 (09:54):
So you lock in the settings and just leave the
system running.
Speaker 2 (09:56):
Exactly. The trap is set. Now we need to trigger.
Speaker 1 (09:59):
The fire alarm, and how do we do that without
unplugging it?
Speaker 2 (10:02):
To do this investigators inject a specialized tool into the system.
It's a utility called not My Fault.
Speaker 1 (10:08):
Not My Fault. I love the naming conventions in this field.
Speaker 2 (10:12):
It's very cheeky, and it's actually available directly for Microsoft's
developer tools. If you're investigating a sixty four bit architecture,
you drop not my Fault sixty four onto the local drive. Okay,
then what you elevate your system permissions to the highest
possible level running your command terminal as an administrator. You
are now operating with the authority required to manipulate the
(10:34):
system's core engine, the.
Speaker 1 (10:36):
Kernel, and from that terminal you execute the tool.
Speaker 2 (10:39):
Yes, what you are doing here is intentionally causing a
kernel memory leak. Think of the kernel as the engine
of the operating system. A memory leak is like flooding
that engine with pure fuel.
Speaker 1 (10:51):
So the system instantly realizes it's about to blow exactly.
Speaker 2 (10:54):
It throws at the blue screen to halt all operations
and immediately vents all its current RAM data safely onto
the hard drive as a massive memory dot DMP file.
Speaker 1 (11:04):
So the machine rebots. You log back in, navigate to
the system root directory by hitting Windows keyplus R and
typing system root and there's your price.
Speaker 2 (11:12):
You've successfully captured the ghost in the machine.
Speaker 1 (11:14):
But capturing it is really only half the battle, because
what you actually possess now is well gigabytes of raw,
unindexed zeros and ones.
Speaker 2 (11:22):
It is an ocean of digital.
Speaker 1 (11:23):
Chaos exactly, So how do we extract meaning from that?
Speaker 2 (11:27):
Forensics teams rely on three escalating analytical techniques to piece
that chaos together.
Speaker 1 (11:33):
Okay, what's the first one.
Speaker 2 (11:34):
The most rudimentary approach is string searching.
Speaker 1 (11:37):
This is exactly what it sounds like, right. You run
a query across the massive file looking for readable tech strings.
Speaker 2 (11:43):
Right. You might be hunting for a known password format,
a suspicious IP address, or a specific fragment of malicious code.
Speaker 1 (11:51):
Just a basic search.
Speaker 2 (11:53):
Yes, and the sheer simplicity of string searching is its
biggest advantage. You ask for a word, it finds the word.
But the fatal flaw is its total lack of context.
Unless you deploy advanced clustering algorithms alongside it, a string
search just hands you isolated fragments of data.
Speaker 1 (12:11):
It's the equivalent of finding a single perfectly cut jigsaw
puzzle piece inside a giant cardboard.
Speaker 2 (12:17):
Box good analogy.
Speaker 1 (12:18):
You pull it out, you see it's peached blue, so
you know it's a piece of the sky. But because
you don't have the picture on the front of the
puzzle box, the context, you have absolutely no idea where
that blue piece fits into the overall crime scene exactly.
Speaker 2 (12:30):
A random IP address means nothing if you don't know
which program was trying to connect to it.
Speaker 1 (12:35):
Right, we need context, which means we need to look
at how the operating system organizes behavior, which leads us.
Speaker 2 (12:42):
To the second technique, finding process objects. In an operating system,
every running application is a process, and those processes execute
smaller individual tasks called.
Speaker 1 (12:53):
Threads okay, processes and threads.
Speaker 2 (12:56):
By analyzing the structure of the memory dump, an investigator
is hunting for rogue threads, meaning code that is actively
executing but suspiciously does not belong to any known registered
process on the machine.
Speaker 1 (13:08):
So it's like an electrician inspecting a building and finding
a mysterious live wire hidden in the wall that doesn't
connect back to any known breaker box. It shouldn't be there,
but it has power.
Speaker 2 (13:18):
Yes, it's a phenomenal weight to spot anomalies. However, we
enter a brutal cat and mouse game here.
Speaker 1 (13:24):
Why is that.
Speaker 2 (13:25):
Because the precise architectural sizes and numerical values of these
processed data structures are a moving target. Microsoft constantly updates them.
Speaker 1 (13:33):
Oh right, updates change the underlying structure exactly.
Speaker 2 (13:37):
The memory structure of a process in Windows ten is
different from Windows eleven. It even changes between minor service
pack updates of the exact same operating system.
Speaker 1 (13:46):
That's a nightmare for tools.
Speaker 2 (13:47):
It is. If your forensic tools are not calibrated to
the exact micro version of the OS, you will misinterpret
the data completely.
Speaker 1 (13:55):
So if process structures are constantly shape shifting and unreliable,
investigators can't rely on them alone. They need something static.
They need an immutable fingerprint, which.
Speaker 2 (14:03):
Brings us to the third technique, finding object signatures.
Speaker 1 (14:08):
What does that mean?
Speaker 2 (14:08):
Practically every digital object, whether it's a hidden network socket
or a specific malware payload, has a unique underlying pattern
of bytes a signature. Okay, investigators use a massive database
of known signatures and systematically sweep the raw memory dump
looking for a mathematical match. It bypasses the OS structure
entirely and just looks for the raw fingerprint of the weapon.
Speaker 1 (14:30):
Got it? So we have our theoretical toolkit searching for
strings to find fragments, hunting for rogue processes to find
hidden behaviors, and matching signatures to find known threats. But
theory doesn't solve cases. How do we actually wield these
techniques against that massive memory dot DMP file.
Speaker 2 (14:46):
Well, we use specialized memory analysis frameworks. A notable mention
in the field is memparser, which is excellent for reconstructing
process information and pulling out the exact command line inputs
and attacker used.
Speaker 1 (14:59):
And it has that future sure for displaying loaded DLLs.
Speaker 2 (15:02):
Right.
Speaker 1 (15:02):
The dynamic link libraries.
Speaker 2 (15:04):
Yes, very useful for seeing what shared code modules the
processes rely on. But the undisputed heavyweight champion of memory
forensics and the real focal point of our analysis today
is Volatility.
Speaker 1 (15:15):
Volatility is a powerhouse. It really is because it's an
open source framework built entirely in Python. It relies on
a modular plugin system. It doesn't matter if you're investigating
a thirty two bit Windows server, a Linux machine, a
Mac or even an Android device.
Speaker 2 (15:30):
Yeah, the community aspect is huge. If a new operating
system update drops today, the global friends of community can
write a Volatility plug in tomorrow to analyze it. It
can digest raw dumps, crash dumps, or even memory suspended
from a virtual machine.
Speaker 1 (15:44):
So to really understand the sheer investigative power of this framework,
let's walk through how an analyst actually interrogates the data
from the command terminal.
Speaker 2 (15:53):
Sure, so you place your Volatility executable and your captured
memory dump into a secure directory.
Speaker 1 (16:00):
Way, if I just point Volatility at this raw memory
DOTSDMP file, it's essentially flying blind, right, What do you mean, Well,
the raw bites don't have a helpful little sticky note
attached that says hello, I am a memory dump from
a Windows XP service pack two machine.
Speaker 2 (16:17):
Ah. Yes, you've hit on the exact reason why the
mandatory first command any investigator runs is image info. Image
in info, you feed the memory file into Volatility and
ask it to analyze the overarching architecture. The image info
command scans the raw data, identifies the core kernel structures,
and deduces the exact operating system profile.
Speaker 1 (16:37):
Because, as we established earlier, if you don't know the
exact service pack, your tools will be looking for the
wrong process structures and your entire investigation will be compromised.
Speaker 2 (16:46):
Precisely, you have to know the rules of the board
before you play.
Speaker 1 (16:49):
The game makes sense.
Speaker 2 (16:50):
Once Volatility knows the rules of the specific operating system
it's looking at, you append that profile to every subsequent command.
Speaker 1 (16:57):
So what's the logical next step.
Speaker 2 (16:59):
The next step is usually to run slist. This command
instructs the framework to reconstruct the standard list of processes
that were visibly running when the memory was frozen.
Speaker 1 (17:08):
It extracts the program name, its unique process ID, and
the exact time stamp it launched.
Speaker 2 (17:14):
Right Yes, And if you need to understand the relationship
between those programs, say to see if a seemingly innocent
web browser suddenly spawn a suspicious command terminal, you run stree.
Speaker 1 (17:24):
Stree like a family tree of the processes exactly.
Speaker 2 (17:26):
It visualizes the hierarchy. But we know malware doesn't play
by the rules. Advanced malware actively unlinks itself from the
operating system's internal doubly linked list. It basically erases its
own name from the official ledger sys slist will never
see it, which is.
Speaker 1 (17:40):
Why Volatility includes the scan command.
Speaker 2 (17:43):
Yes instead of platanely asking the operating system for the
official list of active programs. Scan ignores the ledger completely.
Speaker 1 (17:50):
It just bypasses it.
Speaker 2 (17:52):
It ruthlessly scans the raw physical bites of the memory dump,
hunting for the underlying data structures of processes. It will
find programs that have terminated, and more importantly, it will
find active programs that deliberately unlinked themselves from the official list.
Speaker 1 (18:08):
This brings us to the ultimate malware hunting mechanism. The
crown jewel of this framework is a command called sview.
Speaker 2 (18:15):
Sexview is incredible.
Speaker 1 (18:17):
This is where we combine everything we've learned to catch
the malware in a lie.
Speaker 2 (18:21):
Exactly six of you automates a brilliant comparative analysis. It
runs the polite slist command and then simultaneously runs the
ruthless scan command, and it cross references the result in
a single devastating table.
Speaker 1 (18:35):
Think of it like a teacher trying to figure out
if an invisible student snuck into the classroom.
Speaker 2 (18:39):
Okay, I like where this is going.
Speaker 1 (18:40):
The teacher first looks at the official sign and sheet
on the clipboard that is list right. But then the
teacher puts the clipboard down, walks up and down the aisles,
and physically counts every single head in the room. That
is scan if a student or a malicious process shows
up during the physical headcount, but their name is suspiciously
absent from the official sign in sheet, you have just
(19:02):
definitively identified your hidden threat.
Speaker 2 (19:04):
That is a perfect way to explain it. It's the
ideal mechanism to bypass the lies of a compromised.
Speaker 1 (19:10):
System and on spaceview highlights that invisible rogue process. The
investigation accelerates right oh.
Speaker 2 (19:17):
It kicks into high gear. You can target that specific
anomaly with commands like jealous to extract exactly which code
libraries the malour was utilizing to maintain its stealth.
Speaker 1 (19:27):
And just a practical note here, because parsing hundreds of
lines of terminal data can be completely overwhelming, you can
easily append a simple command just a right facing angle
bracket and result dot txt to export all of Volatility's
findings directly into clean, searchable text documents.
Speaker 2 (19:43):
Yes, exporting is a lifesaver. You are essentially taking a
volatile invisible digital space and transforming it into a highly structured,
interrogatable crime scene.
Speaker 1 (19:53):
That is the true power of memory forensics. We are
no longer limited to the permanent footprints left on a
hard drive. Actually capturing the active thoughts of the machine.
Speaker 2 (20:02):
It's a fascinating transition in how we secure our digital infrastructure,
it really is.
Speaker 1 (20:07):
Let's briefly synthesize the journey we've taken today. We started
with the realization that traditional disc forensics fails against modern
filelest malware that lives exclusively in the RAM, right.
Speaker 2 (20:18):
And then we explored how to weaponize the system's own
fail safes, triggering controlled kernel leaks to generate crash dumps.
Speaker 1 (20:26):
And finally we moved past the limitations of simple string searching,
utilizing the Volatility framework to cross reference data structures and
expose the hidden lies within the operating system itself.
Speaker 2 (20:37):
So to ensure the core concepts of this analysis are
locking in for everyone listening, let's put your new forensic
mindset to a quick.
Speaker 1 (20:43):
Test, a little review question.
Speaker 2 (20:45):
Exactly based on the techniques we've explored today, which of
the following is not a method utilized during active memory analysis?
A string searching, B finding process objects, C finding objects
signatures or imaging partitions.
Speaker 1 (21:01):
I'll give you a second to think about it. The
answer is d Imaging partitions is the legacy process of
perfectly duplicating a physical hard drive.
Speaker 2 (21:10):
Right, which is the exact methodology we had to move
past in order to hunt threats dynamically operating in the RAM.
Speaker 1 (21:17):
We have covered incredible technical ground today analyzing the very
architecture of cyber warfare, but the implications of this extend
far beyond just a command terminal.
Speaker 2 (21:26):
They really do.
Speaker 1 (21:26):
We spent this entire deep dive examining how sophisticated code
can seamlessly hijack the memory manager, rewrite the internal ledgers,
and force an operating system to lie about its own reality.
Speaker 2 (21:38):
It's scary when you really think about it.
Speaker 1 (21:40):
It raises a chilling, almost philosophical question about our reliance
on technology. If a machine's core architecture can be so
thoroughly subverted that it genuinely believes the malware is a
natural part of its own existence, can we ever truly
trust the interface a computer presents to us.
Speaker 2 (21:56):
That is the question?
Speaker 1 (21:58):
Or in this modern threat landscape, do we have to
accept that every digital environment is a potential crime scene,
requiring us to always play the detective. Keep that in
mind the next time you power up your machine.
So think about the computer you're using right now, like,
right at this very second, someone wanted to see your
unencrypted passwords, or you know, the websites you're silently connected to,
or even the exact keystrokes you made five minutes ago,
where would they look.
Speaker 2 (00:15):
Most people would probably points straight to the.
Speaker 1 (00:20):
Hard drive, Yeah, exactly, the hard driver, maybe like cloud storage.
But the true answer is actually much more elusive. All
of that incredibly sensitive active data, it lives in the
random access memory, the RAM.
Speaker 2 (00:33):
It really is a profound realization when you when you
first start looking closely at digital systems. We're just so
conditioned to think about data in terms of static gigabytes
right sitting permanently on a disc somewhere right.
Speaker 1 (00:45):
Like it's carved in stone exactly.
Speaker 2 (00:47):
But the actual lifeblood of the machine, the thoughts it's
having right at this very second, they exist purely in
a volatile state.
Speaker 1 (00:54):
And that brings us to the mission for today's deep dive.
We are asking you, the listener, to essentially step into
the shoes of a digital forensic investigator today.
Speaker 2 (01:04):
I love that.
Speaker 1 (01:05):
Yeah. We're going on a guided audio journey, step by
step through the frontier of memory forensics. We're going to
explore exactly why this volatile memory is the ultimate gold
mine for uncovering cyber attacks, and.
Speaker 2 (01:18):
How you can actually trap and capture a snapshot of
it before it disappears, right, exactly.
Speaker 1 (01:22):
Plus we'll get into the specific tools and techniques used
to hunt down hidden malware.
Speaker 2 (01:27):
It's going to be fun because to really appreciate why
we're hyper focusing on RAM, we have to look at
how this completely flips the traditional script of digital forensics.
Speaker 1 (01:37):
Yeah, the old school way right.
Speaker 2 (01:39):
For the longest time, the absolute standard operating procedure when
you encountered a compromise machine was well, it was simple
and decisive.
Speaker 1 (01:47):
You pull the plug, just rip it out of the wall.
Speaker 2 (01:49):
Literally disconnect the network, rip the power cord out, extract
the physical hard drive and investigate the disc.
Speaker 1 (01:56):
And I mean the logic there is sound on the surface.
You want to freeze the crime scene, right, You physically
isolate the infected drive so the malware can't communicate with
the outside world or start deleting files.
Speaker 2 (02:07):
Exactly. Historically, an investigator would take that physical disc and
use a data dumper. A really classic tool for this
is dd doxe, right, and you use that to create
a perfect sector bisector duplicate of the drive.
Speaker 1 (02:22):
And then to prove that the copy was utterly flawless
and you tamper proof for a court of law, they
would run an MT five checksum.
Speaker 2 (02:30):
Yes, the checksum is crucial. You essentially pass the entire
drive through a mathematical algorithm and it spits out a
unique digital fingerprint.
Speaker 1 (02:39):
So if the fingerprint of your forensic copy perfectly matches
the original drive, your evidence is legally pristine.
Speaker 2 (02:46):
Which is a beautiful system for an era when a
hard drive held maybe a few gigabytes.
Speaker 1 (02:49):
Oh right, that's the catch.
Speaker 2 (02:50):
But we're looking at modern environments today and the physical
disc approach is just cracking under the pressure. First off,
we're dealing with terabytes upon terabytes of store now. Oh easily,
creating a sector bisector image of a massive enterprise server
takes an internity.
Speaker 1 (03:06):
Right, And when a corporation is under active cyber attack,
you don't have three days to sit around waiting for
a progress bar to reach one hundred percent.
Speaker 2 (03:13):
No, the business impact is simply too high. Taking a
critical system offline to image the drive translates to catastrophic downtime.
Speaker 1 (03:23):
It's just not practical anymore.
Speaker 2 (03:24):
But there is a much more fatal flaw here from
a purely investigative standpoint, which is what the moment you
rip that power cord out of the wall, you instantly
destroy all the volatile information stored in the RAM.
Speaker 1 (03:37):
Because it requires a constant electrical current to hold data.
Speaker 2 (03:40):
Exactly. Yeah, no power, no data, It's gone forever.
Speaker 1 (03:43):
And malware developers know this, don't they. They're actively using
our own traditional forensic protocols against us.
Speaker 2 (03:48):
They absolutely are. It's a cat and mouse game. And
to understand how they do it, this requires us to
look under the hood at the dynamic between virtual memory
and physical memory.
Speaker 1 (03:58):
Okay, let's break that down.
Speaker 2 (04:00):
So picture the operating system as a massive complex office building.
Inside there's a memory manager. Its entire job is to
take pages of data that are temporarily waiting in virtual
memory and seamlessly map them over to permanent active slots
in the physical RAM hardware, just.
Speaker 1 (04:17):
To keep the computer running blazingly fast exactly.
Speaker 2 (04:21):
Modern malware is designed to hijack that exact process. Instead
of downloading a malicious dot xy file onto the hard
drive where an anti virus scanner can easily spot it,
sophisticated malware essentially lives off the.
Speaker 1 (04:35):
Land, meaning it doesn't touch the hard drive at all.
Speaker 2 (04:38):
Right, It loads its malicious code directly into the active RAM.
It corrupts the operating system's own memory manager. It executes
its attacks entirely in this volatile space, deliberately avoiding writing
any files to the hard disk.
Speaker 1 (04:52):
Wow, which means if you pull the plug and solely
analyze the hard drive, you will find absolutely nothing. The
malware leaves zero footprint, nothing at all. You know, analyzing
a traditional hard drive image, it's sort of like searching
through a frozen archived filing cabinet down in the basement.
Speaker 2 (05:09):
That's a great way to put it, right.
Speaker 1 (05:10):
You'll find the permanent record, sure, but it takes months
to sift through, and it tells you absolutely nothing about
what the rogue employee upstairs was doing five minutes ago.
Analyzing the RAM, however, is like standing in the active
office and observing the sticky notes scattered all over that
worker's desk, right before they get thrown in the trash.
Speaker 2 (05:27):
Yes, you can read the passwords they just typed. You
can see the unencrypted network portals they just opened.
Speaker 1 (05:33):
Everything is right there out in the open.
Speaker 2 (05:36):
That is a phenomenal way to visualize it, and it
highlights a terrifying reality. If a machine is compromised at
the memory level, you can no longer trust the information
the computer is giving you about its own state.
Speaker 1 (05:48):
Because the operating system itself will lie to you.
Speaker 2 (05:51):
It will it'll hide the malicious processes. Therefore, the only
reliable countermeasure is to freeze time. We have to capture
a perfect snap shot of that RAM state before the
power is lost.
Speaker 1 (06:03):
Okay, So if the malware is hiding in the sticky
notes on the active desk, how do we sneak in
and photograph that desk before the computer throws everything away?
Speaker 2 (06:12):
Well, acquiring memory sounds like a dark art, but the
tools available now make it surprisingly accessible.
Speaker 1 (06:18):
Let's walk through that. What's the first method.
Speaker 2 (06:20):
Let's look at a tool quite literally called dump it.
Dump it very descriptive it is, and dump it is
brilliantly tactical. Precisely because of its simplicity. You don't need
to be a veteran forensic analyst to execute it. Okay,
Imagine an IT manager in a state of absolute panic
because the server is acting erratically. As long as they
(06:42):
are logged in with administrator privileges, they simply double click
and execute the dump it file.
Speaker 1 (06:47):
And what does it actually do?
Speaker 2 (06:49):
The tool automatically triggers takes a complete digital photograph of
the host's physical memory and saves that raw snapshot right
back into the folder it was launched from.
Speaker 1 (06:59):
So it's rapid response collection. But there is a touch
with dump it, right.
Speaker 2 (07:03):
Yeah, there is. Dump it is purely a collection mechanism.
It hands you the massive box of sticky notes, but
it provides zero built in capabilities to actually read or
organize them. It just dumps it, literally just dumps it,
which brings us to a far more integrated, albeit unconventional method. Okay,
Windows crash dumps.
Speaker 1 (07:19):
Now, wait, when anyone hears the phrase crash dump, the
immediate association is the dreaded blue screen of death. I mean,
that's the ultimate queue for a user to panic.
Speaker 2 (07:28):
Oh. Absolutely, In a normal environment, a blue screen is
a disaster. But in the realm of memory forensics, a
system crash is an incredibly powerful built in preservation tool.
How So, when a Windows system experiences critical, unrecoverable instability,
its internal architecture essentially hits an emergency stop button. To
(07:51):
figure out what went wrong later. The system's final dying
act is to take the entire contents of the physical
RAM and violently shove it straight.
Speaker 1 (07:59):
Over to the saving it as a file.
Speaker 2 (08:01):
Right, saving it as a file with a dot DMP extension.
Speaker 1 (08:04):
Wait, I need to stop and clarify this because it
sounds completely counterintuitive.
Speaker 2 (08:07):
I know, I know.
Speaker 1 (08:08):
Our entire goal is to carefully investigate a machine that
has been silently compromised by malware. Why in the world
would we intentionally force that delicate machine to suffer a
catastrophic crash and blue screen? It feels like breaking the evidence, right,
doesn't violently breaking the system risk destroying the exact evidence
we're hunting for.
Speaker 2 (08:27):
It feels wrong, doesn't it. But remember the physics of
RAM that we talked about earlier. Pulling the power plug
destroys the data because the electricity vanishes instantly. A software
initiated crash is entirely different. We are not cutting the power.
We are deliberately weaponizing the operating system's own failsafe protocol.
Speaker 1 (08:46):
Oh.
Speaker 2 (08:46):
I see, by forcing a controlled crash, we trigger that
emergency backup reflex. The crash process itself is what safely
writes the RAM contents to the disc before the system holds.
Speaker 1 (08:58):
So we are essentially pulling the fire alarm just so
the building's automated sprinklers will turn on.
Speaker 2 (09:03):
That is exactly it perfect analogy.
Speaker 1 (09:06):
Okay, that clarifies the strategy. We want the panic button backup.
So how does an investigator actually set this trap?
Speaker 2 (09:12):
Well, instead of aimlessly clicking through menus, you dive into
the Windows administrative core. You're essentially rewiring the operating system's
emergency response protocol.
Speaker 1 (09:21):
Okay, walk me through the steps.
Speaker 2 (09:23):
You'd navigate into the control panel, go to system that
advanced system settings. Under startup and recovery, you change the
debugging information protocol from the default to a complete memory dump.
Got it now. Crucially, the system will immediately beg you
to restart to apply those changes.
Speaker 1 (09:42):
Because Windows always wants to restart.
Speaker 2 (09:44):
Always, But you absolutely must ignore that prompt. If you
restart the machine, you flush the RAM and the malware
you're hunting vanishes into the ether.
Speaker 1 (09:54):
So you lock in the settings and just leave the
system running.
Speaker 2 (09:56):
Exactly. The trap is set. Now we need to trigger.
Speaker 1 (09:59):
The fire alarm, and how do we do that without
unplugging it?
Speaker 2 (10:02):
To do this investigators inject a specialized tool into the system.
It's a utility called not My Fault.
Speaker 1 (10:08):
Not My Fault. I love the naming conventions in this field.
Speaker 2 (10:12):
It's very cheeky, and it's actually available directly for Microsoft's
developer tools. If you're investigating a sixty four bit architecture,
you drop not my Fault sixty four onto the local drive. Okay,
then what you elevate your system permissions to the highest
possible level running your command terminal as an administrator. You
are now operating with the authority required to manipulate the
(10:34):
system's core engine, the.
Speaker 1 (10:36):
Kernel, and from that terminal you execute the tool.
Speaker 2 (10:39):
Yes, what you are doing here is intentionally causing a
kernel memory leak. Think of the kernel as the engine
of the operating system. A memory leak is like flooding
that engine with pure fuel.
Speaker 1 (10:51):
So the system instantly realizes it's about to blow exactly.
Speaker 2 (10:54):
It throws at the blue screen to halt all operations
and immediately vents all its current RAM data safely onto
the hard drive as a massive memory dot DMP file.
Speaker 1 (11:04):
So the machine rebots. You log back in, navigate to
the system root directory by hitting Windows keyplus R and
typing system root and there's your price.
Speaker 2 (11:12):
You've successfully captured the ghost in the machine.
Speaker 1 (11:14):
But capturing it is really only half the battle, because
what you actually possess now is well gigabytes of raw,
unindexed zeros and ones.
Speaker 2 (11:22):
It is an ocean of digital.
Speaker 1 (11:23):
Chaos exactly, So how do we extract meaning from that?
Speaker 2 (11:27):
Forensics teams rely on three escalating analytical techniques to piece
that chaos together.
Speaker 1 (11:33):
Okay, what's the first one.
Speaker 2 (11:34):
The most rudimentary approach is string searching.
Speaker 1 (11:37):
This is exactly what it sounds like, right. You run
a query across the massive file looking for readable tech strings.
Speaker 2 (11:43):
Right. You might be hunting for a known password format,
a suspicious IP address, or a specific fragment of malicious code.
Speaker 1 (11:51):
Just a basic search.
Speaker 2 (11:53):
Yes, and the sheer simplicity of string searching is its
biggest advantage. You ask for a word, it finds the word.
But the fatal flaw is its total lack of context.
Unless you deploy advanced clustering algorithms alongside it, a string
search just hands you isolated fragments of data.
Speaker 1 (12:11):
It's the equivalent of finding a single perfectly cut jigsaw
puzzle piece inside a giant cardboard.
Speaker 2 (12:17):
Box good analogy.
Speaker 1 (12:18):
You pull it out, you see it's peached blue, so
you know it's a piece of the sky. But because
you don't have the picture on the front of the
puzzle box, the context, you have absolutely no idea where
that blue piece fits into the overall crime scene exactly.
Speaker 2 (12:30):
A random IP address means nothing if you don't know
which program was trying to connect to it.
Speaker 1 (12:35):
Right, we need context, which means we need to look
at how the operating system organizes behavior, which leads us.
Speaker 2 (12:42):
To the second technique, finding process objects. In an operating system,
every running application is a process, and those processes execute
smaller individual tasks called.
Speaker 1 (12:53):
Threads okay, processes and threads.
Speaker 2 (12:56):
By analyzing the structure of the memory dump, an investigator
is hunting for rogue threads, meaning code that is actively
executing but suspiciously does not belong to any known registered
process on the machine.
Speaker 1 (13:08):
So it's like an electrician inspecting a building and finding
a mysterious live wire hidden in the wall that doesn't
connect back to any known breaker box. It shouldn't be there,
but it has power.
Speaker 2 (13:18):
Yes, it's a phenomenal weight to spot anomalies. However, we
enter a brutal cat and mouse game here.
Speaker 1 (13:24):
Why is that.
Speaker 2 (13:25):
Because the precise architectural sizes and numerical values of these
processed data structures are a moving target. Microsoft constantly updates them.
Speaker 1 (13:33):
Oh right, updates change the underlying structure exactly.
Speaker 2 (13:37):
The memory structure of a process in Windows ten is
different from Windows eleven. It even changes between minor service
pack updates of the exact same operating system.
Speaker 1 (13:46):
That's a nightmare for tools.
Speaker 2 (13:47):
It is. If your forensic tools are not calibrated to
the exact micro version of the OS, you will misinterpret
the data completely.
Speaker 1 (13:55):
So if process structures are constantly shape shifting and unreliable,
investigators can't rely on them alone. They need something static.
They need an immutable fingerprint, which.
Speaker 2 (14:03):
Brings us to the third technique, finding object signatures.
Speaker 1 (14:08):
What does that mean?
Speaker 2 (14:08):
Practically every digital object, whether it's a hidden network socket
or a specific malware payload, has a unique underlying pattern
of bytes a signature. Okay, investigators use a massive database
of known signatures and systematically sweep the raw memory dump
looking for a mathematical match. It bypasses the OS structure
entirely and just looks for the raw fingerprint of the weapon.
Speaker 1 (14:30):
Got it? So we have our theoretical toolkit searching for
strings to find fragments, hunting for rogue processes to find
hidden behaviors, and matching signatures to find known threats. But
theory doesn't solve cases. How do we actually wield these
techniques against that massive memory dot DMP file.
Speaker 2 (14:46):
Well, we use specialized memory analysis frameworks. A notable mention
in the field is memparser, which is excellent for reconstructing
process information and pulling out the exact command line inputs
and attacker used.
Speaker 1 (14:59):
And it has that future sure for displaying loaded DLLs.
Speaker 2 (15:02):
Right.
Speaker 1 (15:02):
The dynamic link libraries.
Speaker 2 (15:04):
Yes, very useful for seeing what shared code modules the
processes rely on. But the undisputed heavyweight champion of memory
forensics and the real focal point of our analysis today
is Volatility.
Speaker 1 (15:15):
Volatility is a powerhouse. It really is because it's an
open source framework built entirely in Python. It relies on
a modular plugin system. It doesn't matter if you're investigating
a thirty two bit Windows server, a Linux machine, a
Mac or even an Android device.
Speaker 2 (15:30):
Yeah, the community aspect is huge. If a new operating
system update drops today, the global friends of community can
write a Volatility plug in tomorrow to analyze it. It
can digest raw dumps, crash dumps, or even memory suspended
from a virtual machine.
Speaker 1 (15:44):
So to really understand the sheer investigative power of this framework,
let's walk through how an analyst actually interrogates the data
from the command terminal.
Speaker 2 (15:53):
Sure, so you place your Volatility executable and your captured
memory dump into a secure directory.
Speaker 1 (16:00):
Way, if I just point Volatility at this raw memory
DOTSDMP file, it's essentially flying blind, right, What do you mean, Well,
the raw bites don't have a helpful little sticky note
attached that says hello, I am a memory dump from
a Windows XP service pack two machine.
Speaker 2 (16:17):
Ah. Yes, you've hit on the exact reason why the
mandatory first command any investigator runs is image info. Image
in info, you feed the memory file into Volatility and
ask it to analyze the overarching architecture. The image info
command scans the raw data, identifies the core kernel structures,
and deduces the exact operating system profile.
Speaker 1 (16:37):
Because, as we established earlier, if you don't know the
exact service pack, your tools will be looking for the
wrong process structures and your entire investigation will be compromised.
Speaker 2 (16:46):
Precisely, you have to know the rules of the board
before you play.
Speaker 1 (16:49):
The game makes sense.
Speaker 2 (16:50):
Once Volatility knows the rules of the specific operating system
it's looking at, you append that profile to every subsequent command.
Speaker 1 (16:57):
So what's the logical next step.
Speaker 2 (16:59):
The next step is usually to run slist. This command
instructs the framework to reconstruct the standard list of processes
that were visibly running when the memory was frozen.
Speaker 1 (17:08):
It extracts the program name, its unique process ID, and
the exact time stamp it launched.
Speaker 2 (17:14):
Right Yes, And if you need to understand the relationship
between those programs, say to see if a seemingly innocent
web browser suddenly spawn a suspicious command terminal, you run stree.
Speaker 1 (17:24):
Stree like a family tree of the processes exactly.
Speaker 2 (17:26):
It visualizes the hierarchy. But we know malware doesn't play
by the rules. Advanced malware actively unlinks itself from the
operating system's internal doubly linked list. It basically erases its
own name from the official ledger sys slist will never
see it, which is.
Speaker 1 (17:40):
Why Volatility includes the scan command.
Speaker 2 (17:43):
Yes instead of platanely asking the operating system for the
official list of active programs. Scan ignores the ledger completely.
Speaker 1 (17:50):
It just bypasses it.
Speaker 2 (17:52):
It ruthlessly scans the raw physical bites of the memory dump,
hunting for the underlying data structures of processes. It will
find programs that have terminated, and more importantly, it will
find active programs that deliberately unlinked themselves from the official list.
Speaker 1 (18:08):
This brings us to the ultimate malware hunting mechanism. The
crown jewel of this framework is a command called sview.
Speaker 2 (18:15):
Sexview is incredible.
Speaker 1 (18:17):
This is where we combine everything we've learned to catch
the malware in a lie.
Speaker 2 (18:21):
Exactly six of you automates a brilliant comparative analysis. It
runs the polite slist command and then simultaneously runs the
ruthless scan command, and it cross references the result in
a single devastating table.
Speaker 1 (18:35):
Think of it like a teacher trying to figure out
if an invisible student snuck into the classroom.
Speaker 2 (18:39):
Okay, I like where this is going.
Speaker 1 (18:40):
The teacher first looks at the official sign and sheet
on the clipboard that is list right. But then the
teacher puts the clipboard down, walks up and down the aisles,
and physically counts every single head in the room. That
is scan if a student or a malicious process shows
up during the physical headcount, but their name is suspiciously
absent from the official sign in sheet, you have just
(19:02):
definitively identified your hidden threat.
Speaker 2 (19:04):
That is a perfect way to explain it. It's the
ideal mechanism to bypass the lies of a compromised.
Speaker 1 (19:10):
System and on spaceview highlights that invisible rogue process. The
investigation accelerates right oh.
Speaker 2 (19:17):
It kicks into high gear. You can target that specific
anomaly with commands like jealous to extract exactly which code
libraries the malour was utilizing to maintain its stealth.
Speaker 1 (19:27):
And just a practical note here, because parsing hundreds of
lines of terminal data can be completely overwhelming, you can
easily append a simple command just a right facing angle
bracket and result dot txt to export all of Volatility's
findings directly into clean, searchable text documents.
Speaker 2 (19:43):
Yes, exporting is a lifesaver. You are essentially taking a
volatile invisible digital space and transforming it into a highly structured,
interrogatable crime scene.
Speaker 1 (19:53):
That is the true power of memory forensics. We are
no longer limited to the permanent footprints left on a
hard drive. Actually capturing the active thoughts of the machine.
Speaker 2 (20:02):
It's a fascinating transition in how we secure our digital infrastructure,
it really is.
Speaker 1 (20:07):
Let's briefly synthesize the journey we've taken today. We started
with the realization that traditional disc forensics fails against modern
filelest malware that lives exclusively in the RAM, right.
Speaker 2 (20:18):
And then we explored how to weaponize the system's own
fail safes, triggering controlled kernel leaks to generate crash dumps.
Speaker 1 (20:26):
And finally we moved past the limitations of simple string searching,
utilizing the Volatility framework to cross reference data structures and
expose the hidden lies within the operating system itself.
Speaker 2 (20:37):
So to ensure the core concepts of this analysis are
locking in for everyone listening, let's put your new forensic
mindset to a quick.
Speaker 1 (20:43):
Test, a little review question.
Speaker 2 (20:45):
Exactly based on the techniques we've explored today, which of
the following is not a method utilized during active memory analysis?
A string searching, B finding process objects, C finding objects
signatures or imaging partitions.
Speaker 1 (21:01):
I'll give you a second to think about it. The
answer is d Imaging partitions is the legacy process of
perfectly duplicating a physical hard drive.
Speaker 2 (21:10):
Right, which is the exact methodology we had to move
past in order to hunt threats dynamically operating in the RAM.
Speaker 1 (21:17):
We have covered incredible technical ground today analyzing the very
architecture of cyber warfare, but the implications of this extend
far beyond just a command terminal.
Speaker 2 (21:26):
They really do.
Speaker 1 (21:26):
We spent this entire deep dive examining how sophisticated code
can seamlessly hijack the memory manager, rewrite the internal ledgers,
and force an operating system to lie about its own reality.
Speaker 2 (21:38):
It's scary when you really think about it.
Speaker 1 (21:40):
It raises a chilling, almost philosophical question about our reliance
on technology. If a machine's core architecture can be so
thoroughly subverted that it genuinely believes the malware is a
natural part of its own existence, can we ever truly
trust the interface a computer presents to us.
Speaker 2 (21:56):
That is the question?
Speaker 1 (21:58):
Or in this modern threat landscape, do we have to
accept that every digital environment is a potential crime scene,
requiring us to always play the detective. Keep that in
mind the next time you power up your machine.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
iHeartRadio 24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.