Headlights. Indicators. Trunk releases. Seatbelts. Airbags. Just about any part of a car you can think of is governed by a long and complicated government regulation. It’s all about safety, ensuring that the car-buying public can trust that their vehicles won’t unduly injure or maim them in regular operation, or in the event of accident.

However, one part of the modern automobile has largely escaped regulation—namely, the humble door handle. Automakers have been free to innovate with new and wacky designs, with Tesla in particular making waves with its electronic door handles. However, after a series of deadly incidents where doors wouldn’t open, regulators are now examining if these door handles are suitable for road-going automobiles. As always, regulations are written in blood, but it raises the question—was not the danger of these complicated electronic door handles easy to foresee?

Trapped

A number of automakers have developed fancy retractable door handles in recent years. They are most notably seen on electric vehicles, where they are stated to have a small but measurable aerodynamic benefit. They are often paired with buttons or other similar electronic controls to open the doors from the inside. Compared to mechanical door handles, however, these door handles come with a trade-off in complexity. They require electricity, motors, and a functioning control system to work. When all is well, this isn’t a problem. However, when things go wrong, a retractable electronic door handle often proves inaccessible and useless.

 

It’s not hard to find case reports of fatal incidents involving vehicles with electronic door handles—both inside and out. Multiple cases have involved occupants burning alive inside Tesla vehicles, in which electronic door handles failed after a crash. Passengers inside the vehicles have failed to escape due to not finding emergency release door pulls hidden in the door panels, while bystanders have similarly been unable to use the retracted outside door handles to free those trapped inside.

In response, some Tesla owners have gone so far as to release brightly-colored emergency escape ripcords to replace the difficult-to-spot emergency release pulls that are nearly impossible to find without prior knowledge. In the case of some older models, though, there’s less hope of escape. For example, in the Tesla Model 3 built from 2017 to 2023, only front doors have an emergency mechanical release. Rear passengers are out of luck, and must find another route of escape if their electronic door handles fail to operate. No Tesla vehicles feature an easily-accessible mechanical release that can be used from outside the vehicle.

It’s worth noting that in the US market, federal regulations have mandated glow-in-the-dark trunk releases be fitted to all sedans from the 2002 model year onwards. You could theoretically escape from the trunk of certain Teslas more easily than a Cybertruck or Model 3 with a failed electrical system.

Tesla isn’t the only company out there building cars with retractable door handles. It does, however, remain the most prominent user of this technology, and its vehicles have been involved in numerous incidents that have made headlines. Other automakers, such as Audi and Fiat, have experimented with electronic door handles, both for ingress and egress, with varying degrees of mechanical backup available. In some cases, automakers have used smart two-stage latches. A small pull activates the electronic door release, while a stronger pull will engage a mechanical linkage that unlatches the door. It’s smart engineering—the door interface responds to the exact action a passenger would execute if trying to escape the vehicle in a panic. There are obviously less concerns around electronic door releases that have easily-accessed mechanical backups; it’s just that Tesla is particularly notable for not always providing them.

Over the years, national automotive bodies have thrown up their arms about all sorts of emerging automotive technologies. In the United States specifically, NHTSA has famously slow-walked the approval of things like camera-based rear-view mirror systems and replaceable-bulb headlamps, fearing the worst could occur if these technologies were freely allowed on the market.

Meanwhile, despite the obvious risks, electronic door handles have faced no major regulatory challenges. There were no obvious written rules standing in the way of Tesla making the choice to eliminate regular old door handles. Nor were there strict regulations on emergency door releases for passengers inside the vehicle. Tesla spent years building several models with no mechanical door release for the rear passengers. If your door button failed, you’d have to attempt escape by climbing out through the front doors, assuming you could figure out how to open them. Even today, the models with mechanical door releases still often hide them behind interior trim pieces or carpets, where few passengers would ever think to look in an emergency.

Obvious Mistakes

Things are beginning to change, however. Chinese regulators have led the charge, with reports stating that electronic retractable door handles could be banned as soon as 2027. While some semi-retractable styles will potentially avoid an outright ban, it’s believed new regulations will require a mechanically redundant release system as standard.

As for the US, the sleeping giant of NHTSA has finally awoken in the wake of Bloomberg‘s reporting on the matter. As reported by CNBC, Tesla has been given a deadline of December 10 to deliver records to the federal regulator, regarding design, failures, and customer issues around its electronic door release systems. The Office of Defects Investigations within NHTSA has already recorded 16 reports of failed exterior door releases in the a single model year of the Tesla Model Y. It’s likely a drop in the ocean compared to the full population of Tesla vehicles currently on roads. Meanwhile, the US automaker also faces multiple lawsuits over the matter from those who have lost family members in fatal crashes and fires involving the company’s vehicles.

In due time, it’s likely that automotive regulators in most markets will come out against electronic door handles from a safety perspective alone. No matter how well designed the electrical system in a modern vehicle, it’s hard to beat a lever flipping a latch for simplicity and robustness. The benefits of these electronic door handles are spurious in the first place—a fraction of a percent reduction in drag, and perhaps a little more luxury appeal. If the trade-off is trapping passengers in the event of a fire, it’s hard to say they’re worthwhile.

The electronic door handle, then, is perhaps the ultimate triumph of form over function. They’re often slower and harder to use than a regular door handle, and particularly susceptible to becoming useless when iced over on a frosty morning. For a taste of the future, lives were put at risk. Anyone could see that, so it’s both strange and sad that automakers and regulators alike seemed not to notice until it was far too late. Any new regulations will, once again, be written in blood.

Welcome back, aspiring DFIR investigators!

If you’re diving into digital forensics, memory analysis is one of the most exciting and useful skills you can pick up. Essentially, you take a snapshot of what’s happening inside a computer’s brain right at that moment and analyze it. Unlike checking files on a hard drive, which shows what was saved before, memory tells you about live actions. Things like running programs or hidden threats that might disappear when the machine shuts down. This makes it super helpful for solving cyber incidents, especially when bad guys try to cover their tracks.

In this guide, we’re starting with the basics of memory analysis using a tool called Volatility. We’ll cover why it’s so important, how to get started, and some key commands to make you feel confident. This is part one, where we focus on the foundations and give instructions. Stick around for part two, where we’ll keep exploring Volatility and dive into network details, registry keys, files, and scans like malfind and Yara rules. Plus, if you make it through part two, there are some bonuses waiting to help you extract even more insights quickly.

Memory Forensics

Memory analysis captures stuff that disk forensics might miss. For example, after a cyber attack, malware could delete its own files or run without saving anything to the disk at all. That leaves you with nothing to find on the hard drive. But in memory, you can spot remnants like active connections or secret codes. Even law enforcement grabs memory dumps from suspects’ computers before powering them off. Once it’s off, the RAM clears out, and booting back up might be tricky if the hacker sets traps. Hackers often use tricks like USB drives that trigger wipes of sensitive data on shutdown, cleaning everything in seconds so authorities find nothing. We’re not diving into those tricks here, but they show why memory comes first in many investigations.

Lucky for us, Volatility makes working with these memory captures straightforward. It started evolving, and in 2019, Volatility 3 arrived with better syntax and easier to remember commands. We’ll look at both Volatility 2 and 3, sharing commands to get you comfortable. These should cover what most analysts need.

Memory Gems

Below is some valuable data you can find in RAM for investigations:

1. Network connections

2. File handles and open files

3. Open registry keys

4. Running processes on the system

5. Loaded modules

6. Loaded device drivers

7. Command history and console sessions

8. Kernel data structures

9. User and credential information

10. Malware artifacts

11. System configuration

12. Process memory regions

Keep in mind, sometimes key data like encryption keys hides in memory. Memory forensics can pull this out, which might be a game-changer for a case.

Approach to Memory Forensics

In this section we will describe a structured method for conducting memory forensics, designed to support investigations of data in memory. It is based on the six-step process from SANS for analyzing memory.

Identifying and Checking Processes

Start by listing all processes that are currently running. Harmful programs can pretend to be normal ones, often using names that are very similar to trick people. To handle this:

1. List every active process.

2. Find out where each one comes from in the operating system.

3. Compare them to lists of known safe processes.

4. Note any differences or odd names that stand out.

Examining Process Details

After spotting processes that might be problematic, look closely at the related dynamic link libraries (DLLs) and resources they use. Bad software can hide by misusing DLLs. Key steps include:

1. Review the DLLs connected to the questionable process.

2. Look for any that are not approved or seem harmful.

3. Check for evidence of DLLs being inserted or taken over improperly.

Reviewing Network Connections

A lot of malware needs to connect to the internet, such as to contact control servers or send out stolen information. To find these activities:

1. Check the open and closed network links stored in memory.

2. Record any outside IP addresses and related web domains.

3. Figure out what the connection is for and why it’s happening.

4. Confirm if the process is genuine.

5. See if it usually needs network access.

6. Track it back to the process that started it.

7. Judge if its actions make sense.

Finding Code Injection

Skilled attackers may use methods like replacing a process’s code or working in hidden memory areas. To detect this:

1. Apply tools for memory analysis to spot unusual patterns or signs of these tactics.

2. Point out processes that use strange memory locations or act in unexpected ways.

Detecting Rootkits

Attackers often aim for long-term access and hiding. Rootkits bury themselves deep in the system, giving high-level control while staying out of sight. To address them:

1. Search for indicators of rootkit presence or major changes to the OS.

2. Spot any processes or drivers with extra privileges or hidden traits.

Isolating Suspicious Items

Once suspicious processes, drivers, or files are identified, pull them out for further study. This means:

1. Extract the questionable parts from memory.

2. Save them safely for detailed review with forensic software.

The Volatility Framework

A widely recommended option for memory forensics is Volatility. This is a prominent open-source framework used in the field. Its main component is a Python script called Volatility, which relies on various plugins to carefully analyze memory dumps. Since it is built on Python, it can run on any system that supports Python.

Volatility’s modules, also known as plugins, are additional features that expand the framework’s capabilities. They help pull out particular details or carry out targeted examinations on memory files.

Frequently Used Volatility Modules

Here are some modules that are often used:

pslist: Shows the active processes.

cmdline: Reveals the command-line parameters for processes.

netscan: Checks for network links and available ports.

malfind: Looks for possible harmful code added to processes.

handles: Examines open resources.

svcscan: Displays services in Windows.

dlllist: Lists the dynamic-link libraries loaded in a process.

hivelist: Identifies registry hives stored in memory.

You can find documentation on Volatility here:

Volatility v2: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Volatility v3: https://volatility3.readthedocs.io/en/latest/index.html

Installation

Installing Volatility 3 is quite easy and will require a separate virtual environment to keep things organized. Create it first before proceeding with the rest:

bash$ > python3 -m venv ~/venvs/vol3

bash$ > source ~/venvs/vol3

Now you are ready to install it:

bash$ > pip install volatility3

Since we are going to cover Yara rules in Part 2, we will need to install some dependencies:

bash$ > sudo apt install -y build-essential pkg-config libtool automake libpcre3-dev libjansson-dev libssl-dev libyara-dev python3-dev

bash$ > pip install yara-python pycryptodome

Yara rules are important and they help you automate half the analysis. There are hundreds of these rules available on Github, so you can download and use them each time you analyze the dump. While these rules can find a lot of things, there is always a chance that malware can fly under the radar, as attackers change tactics and rewrite payloads. 

Now we are ready to work with Volatility 3.

Plugins

Volatility comes with multiple plugins. To list all the available plugins do this:

bash$ > vol -h

Each of these plugins has a separate help menu with a description of what it does.

Memory Analysis Cheat Sheet

Image Information

Imagine you’re an analyst investigating a hacked computer. You start with image information because it tells you basics like the OS version and architecture. This helps Volatility pick the right settings to read the memory dump correctly. Without it, your analysis could go wrong. For example, if a company got hit by ransomware, knowing the exact Windows version from the dump lets you spot if the malware targeted a specific weakness.

In Volatility 2, ‘imageinfo‘ scans for profiles, and ‘kdbgscan‘ digs deeper for kernel debug info if needed. Volatility 3’s ‘windows.info‘ combines this, showing 32/64-bit, OS versions, and kernel details all in one and it’s quicker.

bash$ > vol -f Windows.vmem windows.info

Here’s what the output looks like, showing key system details to guide your next steps.

Process Information

As a beginner analyst, you’d run process commands to list what’s running on the system, like spotting a fake “explorer.exe” that might be malware stealing data. Say you’re checking a bank employee’s machine after a phishing attack, these commands can tell you if suspicious programs are active, and help you trace the breach.

‘pslist‘ shows active processes via kernel structures. ‘psscan‘ scans memory for hidden ones (good for rootkits). ‘pstree‘ displays parent-child relationships like a family tree. ‘psxview‘ in Vol 2 compares lists to find hidden processes.

Note that Volatility 2 wants you to specify the profile. You can find out the profile while gathering the image info.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> pslist

vol.py -f “/path/to/file” ‑‑profile <profile> psscan

vol.py -f “/path/to/file” ‑‑profile <profile> pstree

vol.py -f “/path/to/file” ‑‑profile <profile> psxview

Volatility 3:

vol.py -f “/path/to/file” windows.pslist

vol.py -f “/path/to/file” windows.psscan

vol.py -f “/path/to/file” windows.pstree

Now let’s see what we get:

bash$ > vol -f Windows7.vmem windows.pslist

This output lists processes with PIDs, names, and start times. Great for spotting outliers.

bash$ > vol -f Windows.vmem windows.psscan

Here, you’ll see a broader scan that might catch processes trying to hide.

bash$ > vol -f Windows7.vmem windows.pstree

This tree view helps trace how processes relate, like if a browser spawned something shady.

Displaying the entire process tree will look messy, so we recommend a more targeted approach with –pid

Process Dump

You’d use process dump when you spot a suspicious process and want to extract its executable for closer inspection, like with antivirus tools. For instance, if you’re analyzing a system after a data leak, dumping a weird process could reveal it is spyware sending info to hackers.

Vol 2’s ‘procdump‘ pulls the exe for a PID. Vol 3’s ‘dumpfiles‘ grabs the exe plus related DLLs, giving more context.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> procdump -p <PID> ‑‑dump-dir=“/path/to/dir”

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑pid <PID>

We already have a process we are interested in:

bash$ > vol -f Windows.vmem windows.dumpfiles --pid 504

After the dump, check the output and analyze it further.

Memdump

Memdump is key for pulling the full memory of a process, which might hold passwords or code snippets. Imagine investigating insider theft, dumping memory from an email app could show unsent drafts with stolen data.

Vol 2’s ‘memdump’ extracts raw memory for a PID. Vol 3’s ‘memmap’ with –dump maps and dumps regions, useful for detailed forensics.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> memdump -p <PID> ‑‑dump-dir=“/path/to/dir”

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.memmap ‑‑dump ‑‑pid <PID>

Let’s see the output for our process:

bash$ > vol -f Windows7.vmem windows.memmap --dump --pid 504

This shows the memory map and dumps files for deep dives.

DLLs

Listing DLLs helps spot injected code, like malware hiding in legit processes. Unusual DLLs might point to infection.

Both versions list loaded DLLs for a PID, but Vol 3 is profile-free and faster.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> dlllist -p <PID>

Volatility 3:

vol.py -f “/path/to/file” windows.dlllist ‑‑pid <PID>

Let’s see the DLLs loaded in our memory dump:

bash$ > vol -f Windows7.vmem windows.dlllist --pid 504

Here you see all loaded DLLs of this process. You already know how to dump processes with their DLLs for a more thorough analysis. 

Handles

Handles show what a process is accessing, like files or keys crucial for seeing if malware is tampering with system parts. In a ransomware case, handles might reveal encrypted files being held open or encryption keys used to encrypt data.

Both commands list handles for a PID. Similar outputs, but Vol 3 is streamlined.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> handles -p <PID>

Volatility 3:

vol.py -f “/path/to/file” windows.handles ‑‑pid <PID>

Let’s see the handles our process used:

bash$ > vol -f Windows.vmem windows.handles --pid 504

It gave us details, types and names for clues.

Services

Services scan lists background programs, helping find persistent malware disguised as services. If you’re probing a server breach, this could uncover a backdoor service.

Use | more to page through long lists. Outputs are similar, showing service names and states.

Volatility 2:

vol -f “/path/to/file” ‑‑profile <profile> svcscan | more

Volatility 3:

vol -f “/path/to/file”  windows.svcscan | more

Since this technique is often abused, a lot can be discovered here:

bash$ > vol -f Windows7.vmem windows.svcscan

Give it a closer look and spend enough time here. It’s good to familiarize yourself with native services and their locations

Summary

We’ve covered the essentials of memory analysis with Volatility, from why it’s vital to key commands for processes, dumps, DLLs, handles, and services. Apart from the commands, now you know how to approach memory forensics and what actions you should take. As we progress, more articles will be coming where we practice with different cases. We already have a memory dump of a machine that suffered a ransomware attack, which we analyzed with you recently. In part two, you will build on this knowledge by exploring network info, registry, files, and advanced scans like malfind and Yara rules. And for those who finish part two, some handy bonuses await to speed up your work even more. Stay tuned!

The post Digital Forensics: Volatility – Memory Analysis Guide, Part 1 first appeared on Hackers Arise.

Welcome back, aspiring forensic investigators!

We continue our practical series on digital forensics and will look at the memory dump of a Windows machine after a ransomware attack. Ransomware incidents are common, although they may not always be the most profitable attacks because they require a lot of effort and stealth. Some operations take months of hard work and sleepless nights and still never pay off. Many attackers prefer to steal data and sell it on the dark web. Such data sells well and quickly. State sponsored APTs act similarly. Their goal is to stay silent and extract as much intelligence as possible.

Today, a thousand unique entries of private information of Russian citizens cost about $100. That’s cheap. But it also shows how effective Ukrainian and foreign hackers are against Russia. All this raises demand for digital forensics and incident response, since fines for data leaks can be enormous. It’s not only fines that are a threat. Reputation damage is critical. If your competitor has never, at least yet, experienced a data breach and you did and it went public, trust in your company will start crumbling and customers will be inclined to use your competitors’ services. An even worse scenario is a ransomware attack that locks down much of your organization and wipes out your backups. Paying the attackers gives no guarantee of recovering your data, and some companies never manage to recover at all.

So let’s investigate one of those attacks and learn something new to stay sharp.

Memory Analysis

It all begins with a memory dump. Here we already have a memory dump file of an infected machine that we are going to inspect.

Installing Volatility

On our Kali machine we created a new Python virtual environment for Volatility. Keeping separate environments is good practice because it prevents tools from interfering with other dependencies. Sometimes installing one tool can break another. Here is how you do it:

bash$ > python3 -m venv env_name

bash$ > source env_name/bin/activate

Now we are ready to install Volatility in this environment:

bash$ > pip3 install volatility3

It is also good practice to record the exact versions of Volatility and Python you used (for example, pip3 show volatility3 and python3 --version). Memory forensics tools change over time and some plugins behave slightly differently between releases. Recording versions makes your work reproducible later.

Image Information

One of the first things we look at after receiving a memory dump is the captured metadata. The Volatility 3 command is simple:

bash$ vol -f infected.vmem windows.info

When you run windows.info, inspect the OS build, memory size, and timestamps shown by the capture tool. That OS build value helps Volatility pick the correct symbol tables. Incorrect symbols can cause missing or malformed output. This is especially important if you are working with Volatility 2. Also confirm the capture method and metadata such as who made the capture, when, and whether the capture was acquired after isolating the machine. Recording this chain-of-custody metadata is a small step that greatly strengthens any forensic report.

Processes

The goal of the memory dump is to preserve processes, injections, and shellcode before they disappear after a reboot. That means we need to focus on the processes that existed at capture time. Let’s list them all:

bash$ > vol -f infected.vmem windows.pslist

Suspicious processes are not always easy to spot. It depends on the attacker’s tactics. Ransomware processes, unlike persistence mechanisms, are often obvious because attackers tend to pick violent or alarming names for encryptors. But that’s not always the case, so let’s give our image a closer look.

Among other processes, a ransomware process sticks out. You may also notice or4qtckT.exe and other processes with unknown names. Random executable names are not definitive proof of maliciousness, but they’re a reliable starting point for closer inspection. Some legitimate software may also generate processes with random names, for example, Dr.Web, a Russian antivirus.

When a process name looks random, check several things: the process parent, the process start time (did it start right before the incident?), open network sockets, loaded DLLs, and whether the executable exists on disk or only in memory. Processes that only exist in the RAM image (no matching file on disk) often indicate in-memory unpacking or fileless behavior. These are important signals in malware analysis. Use plugins like windows.psscan (process scan) to find processes that pslist might miss and windows.pstree to visualize parent/child relationships. Also check windows.dlllist to see suspicious DLLs loaded into a process. Injected code often pulls suspicious DLL names or shows unnatural memory protections on executable pages.

Parent Relationships

Once you find malware, your next step is to find its parent. A parent is the process that launches another process. This is how you unravel the attack by going back in the timeline. windows.pslist has two important columns: PID (process ID) and PPID (parent process ID). The parent of WanaDecryptor has PID 2732. We can quickly search and find it.

Now we know that the process with a random name or4qtckT.exe initiated WanaDecryptor. As it might not be the only process initiated by that parent, let’s grep its PID and find out:

bash$ > vol -f infected.vmem windows.psscan | grep 2732

The parent process can show how the attacker entered the machine. It might be a user process opened by a phishing email, a scheduled task that ran at an odd hour, or a system service that got abused. Tracing parents helps you decide whether this was an interactive compromise (an attacker manually ran something) or an automated spread. If you see network-facing services as parents or child processes that match known service names (for example, svchost.exe variants), dig deeper. Some ransomware uses service abuse, scheduled tasks, or built-in Windows mechanisms to reach higher privileges or persistence.

Handles

In Windows forensics, when we say we are “viewing the handles of a process,” we mean examining the internal references that a process has opened to system resources. A handle in Windows is essentially a unique identifier (a number) that a process uses to access an operating system object. Processes do not work directly with raw resources like files, registry keys, threads, or network connections. Instead, when a process needs access to something, it asks Windows to open that object, and Windows returns a handle. That handle acts like a ticket which the process can use to interact with the object safely.

bash$ > vol -f infected.vmem windows.handles --pid 2732

First, we see a user (hacker) directory. That should be noted for further analysis, because user directories contain useful evidence in NTUSER.DAT and USRCLASS.DAT. These objects can be accessed after a full disk capture and will include thorough information about shares, directories, and objects the user accessed.

Inspecting the handles, we found an .eky file that was used to encrypt the system

This .eky file contains the secret the attacker needed to lock files on the system. These keys are brought from the outside and are not native system objects. Obtaining this key does not guarantee successful decryption. It depends on what kind of key file it is and how it was protected.

When you find cryptographic artifacts in handles, copy the file bytes, if possible, and get the hashes (SHA-256) before touching them. Export them into an isolated analysis workstation. Then compare the artifact to public resources and sandbox reports. Not every key-like file is the private key you need to decrypt. Sometimes attackers include only a portion or an encrypted container that requires an additional password or remote secret. Public repositories and collective projects (for example, NoMoreRansom and vendor decryptors) may already have decryption tools for some ransomware families, so check there before calling data irrecoverable.

Command Line

Now let’s inspect the command lines of the processes. Listing all command lines gives you more visibility to spot malicious behavior:

bash$ > vol -f infected.vmem windows.cmdline

You can also narrow it down to the needed PIDs or file names:

bash$ > vol -f infected.vmem windows.cmdline | grep or4

We can now see where the attack originated. After a successful compromise of a system or a domain, the attacker brought their malware to the system and encrypted it with their own keys.

The command line often contains the exact flags or network locations the attacker used (for example, -server 192.168.x.x or a path to an unpacker). Attackers sometimes use command-line switches to hide behavior, choose a configuration file, or provide a URL to download further payloads. If you can capture the command line, you often capture the attacker’s intent in plain text, which is invaluable evidence. Also check process environment variables, if those are available, because they might contain temporary filenames, credentials, or proxy settings the malware used.

Getting Hashes

Obviously the investigation does not stop here. You need to extract the file from memory, calculate its hash, and inspect how the malware behaves on AnyRun, VirusTotal, and other platforms. To extract the malware we first need to find its address in memory:

bash$ > vol -f infected.vmem windows.file | grep -i or4qtckT

Let’s pick the second hit and extract it now:

bash$ > vol -f infected.vmem windows.dumpfiles --physaddr 0x1fcaf798

The ImageSection dump (.img) usually looks like the program that was running in memory. It can include changes made while the program was loaded, such as unpacked code or adjusted memory addresses. The DataSection dump (.dat), on the other hand, shows what the file looks like on disk, or at least part of it. That’s why there are two dumps with the same name. Volatility detected both the in-memory version and the on-disk version of or4qtckT.exe

Next we generate the hash of the DataSectionObject and look it up on VirusTotal:

bash$ > sha256sum file.0x1fcaf798.0x85553db8.DataSectionObject.or4qtckT.exe.dat

We recommend using robust hashing (SHA-256 instead of MD5) to avoid collision issues.

For more information, go to Hybrid Analysis to get a detailed report on the malware’s capabilities.

Some platforms like VirusTotal, AnyRun, Hybrid Analysis, Joe Sandbox will produce behavioral reports, network traffic captures, and dropped files that help you map capabilities like network C2, persistence techniques, and whether the sample attempts to self-propagate. In our case, this sample has been found in online sandbox reports and is flagged with ransomware/WannaCry-like behavior. Sandbox summaries showed malicious activity consistent with file encryption and automated spread. When reading sandbox output, focus on three things: dropped files, outbound connections, and any use of legacy Windows features (SMB, WMI, PsExec) to move laterally.

Practical next steps for the investigator

First, preserve the memory image and any extracted files exactly as you found them. Do not run suspicious samples on your analysis workstation unless it is fully isolated. Second, gather network indicators (IP addresses, domain names) and add them to your blocklists and detection rules. Third, check for related persistence mechanisms on disk and in registry hives, if you have the disk image. Scheduled tasks, HKLM\Software\Microsoft\Windows\CurrentVersion\Run entries, service modifications, and driver loads are common. Fourth, feed the sample hash and any dropped files into public repositories and vendor sandboxes. These can help you find other victims and understand the campaign’s breadth. Finally, document everything, every command and every timestamp, so you can later show how the evidence was acquired, processed, and analyzed. For memory-specific checks, run Volatility plugins such as malfind (detect injection), ldrmodules (module loads), dlllist, netscan (network sockets), and registry plugins to inspect in-memory registry hives.

Summary

Think of memory as the attacker’s black box. It often holds the fleeting traces disk images miss, things like unpacked code, live network sockets, and cryptographic keys. Prioritizing memory first allows you to catch those traces before they’re gone. Volatility can help you list running processes, trace parent–child chains, inspect handles and command lines. You can also dump in-memory binaries and use them as artifacts for a more thorough analysis. Submitting these artifacts to sandboxes will give you a clear picture of what happened on your network, which will give you valuable IOCs to prevent this attack and techniques used. As a forensic analyst you are required to preserve the image intact, work with suspicious files in an isolated lab, and write down every command and timestamp to keep the chain of custody reliable and actions repeatable.

If you need forensic assistance, we offer professional services to help investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field.

For more Memory Forensics, check out our upcoming Memory Forensics class.

The post Digital Forensics: Investigating a Ransomware Attack first appeared on Hackers Arise.