Memory Forensics with Volatility 3: Recovering Monero Wallet Addresses from Tor in Dark Web Investigations

Hey there, fellow investigators!

If you’ve ever bumped into a Dark Web case, you already know how slippery these bad actors can be. Tor Browser disguises their IPs, and non-custodial wallets (especially Monero) keep their coins untraceable. So instead of finding neat little breadcrumbs on a suspect’s hard drive you often end up with...nothing. Literally, disk forensics might not give you any artifacts That’s why I want to share a little memory-forensics trick that can save the day when disk artifacts are scarce.

In this post, I’ll walk you through how to:

1. Acquire a memory dump with FTK Imager
2. Analyze that RAM dump with Volatility 3
3. Analyze usage of monero address in wallet, Tor Browser and Darknet Marketplace

Let’s dive in

Why Memory? Why Monero + Tor?

• Tor Browser: It’s perfect for keeping a user’s real IP under wraps. By default, Tor browser wont save your browsing history and less artifacts in disk forensics.
• Monero (non‐custodial): You download a local desktop wallet, generate your own seed phrase and keys...and boom your crypto lives in the app, not on some centralized exchange. If the wallet is encrypted you wont be able to analyze any artifacts in disk forensics.

In short, disk forensics often fail while collecting evidence from switched off condition. All you’ll find is execution artifacts of “Tor Browser” or “monero-wallet-gui.exe in prefetch, jumplist, amcache or other execution artifacts.

But! When Tor and your wallet are running, that data (private keys, generated addresses, maybe even clipboard contents) lives in RAM and that’s where Volatility 3 comes in.

Our “Lab” Setup

Before you meet the real suspect, simulate the scenario in your lab. Here’s what I used:

• Host OS: Windows 11 (Build Number: 22631.5189)

• FTK Imager: To Acquire the live memory.

• Volatility 3: Installed on a SIFT VM

• Monero GUI Wallet: Downloaded from getmonero.org (make sure it’s the legit version!).

• Tor Browser: Grab the latest .exe from torproject.org and Marketplace Login

Install and launch monero-wallet-gui.exe, create a new wallet (recording the 24-word seed securely), and copy the generated Monero address to your clipboard via the “Receive” tab.

Next, start Tor Browser, wait for it to connect, and navigate to a Dark Net marketplace (e.g., marketname.onion) in our case we have used abacus and drughub marketplace; login via PGP keys; paste the Monero address into the payment field to simulate a transaction. With both applications active ensuring that the wallet’s private keys and address remain in RAM and Tor holds the browsing session in memory use FTK Imager (File → Capture Memory) to acquire a full .mem dump (saving it to external media). This captures all volatile data, including decrypted keys, clipboard contents, and Dark Web activity.

Meet Volatility 3 (What’s New?)

Alright, so you’re hyped about memory forensics and you’ve heard of Volatility 2. But let me tell you, Volatility 3 is where it’s at right now. It’s a total rewrite in Python 3, and it fixes a ton of the old headaches. Here are the quick highlights on why Volatility 3 is ideal for our Monero/Tor investigation:

Auto Profile Detection
You don’t have to guess the exact Windows build or win32/64 kernel anymore.

New Naming Scheme, Better Plugins
Some plugin names changed (and for the better). For example, you’ll see windows.info instead of the old “kdbgscan + imageinfo.” Everything’s more consistent.

Symbol Table Lookups
By default, Volatility 3 will try to fetch Microsoft symbol tables on-the-fly (so you don’t have to hunt down .dbg files manually). If you work in a classified/air-gapped lab, just download the symbol packs ahead of time and point Volatility 3 at them.

Time to Do Some Analysis!

I already acquired my RAM image with FTK Imager (Memory → Capture). Now let’s analyze it on my SIFT workstation and see what we’ve got. Here’s the first command:

python3 vol.py -f /path/to/memdump.mem windows.info

• /path/to/memdump.mem is your live memory image (make sure you’ve got the correct path/filename).

• windows.info is the plugin that spits out all the basics.

  

A Quick Peek Windows.info Results

(Check out the screenshot I’ve attached for reference.) When you run windows.info, you’ll see lines like:

• OS Version: Windows 11 22H2 (Build 22621) (Windows 11 23H2 is an enablement update over 22H2, meaning both versions share the same kernel and core system files. That’s why Volatility detects build 22621 (22H2) even if your system shows 23H2)

• Architecture: 64-bit (x64)

• CPU Count: 8 logical processors

• System Time (Snapshot): 2025-04-30 17:35:42 UTC

• System Root: C:\WINDOWS

• Product Type: Workstation (NtProductWinNt)

So bottom line: This is a Windows 11 machine (64-bit, build 22631.5189) with 8 CPUs.

Next Up: Finding Our Suspicious Processes with PSSCAN

Once you know your profile, it’s time to analyze for running processes. In Volatility 3, the plugin you want is:

python3 vol.py -f /path/to/memdump.mem windows.psscan

What does windows.psscan do? It scans the entire physical memory for EPROCESS structures, not just the linked list of processes. This means you’ll see:

1. Hidden processes (rootkits or processes that unlinked themselves)
2. Processes that may have just exited (but still have leftover memory structures)
3. Everything that was in memory, even if the normal process list has already dropped it.

In our run, we quickly spotted two critical PIDs:

• 7440 → This is the Monero GUI wallet process.
• 9776 → Tor Browser (it shows up as “firefox.exe” because Tor is a modified version of Firefox; don’t get confused by that!).

Note: Tor masquerades its process name, so whenever you see “firefox.exe” in a Dark Web case, double-check—there’s a good chance it’s actually Tor.

Memory Dump Time for Specific PIDs

Now that we know the PIDs, we want to dump out each process’s memory to analyze it in isolation. In Volatility 3, you can dump a single process’s addressable pages using the windows.memmap plugin. This replaces the old Volatility 2 memdump -p <PID> command.

Why use windows.memmap?

• It walks through each process’s VAD tree (Virtual Address Descriptor) and extracts all resident pages.
• You’ll get both code and data pages.
• If you’re doing a strings search, you’ll end up with a huge file, but at least you’re scanning only what belongs to that process (instead of the entire machine RAM).

Commands

1. Dump Monero Wallet (PID 7440):

   python3 vol.py -f /path/to/memdump.mem windows.memmap --pid 7440 --dump-dir ./proc_dumps

   This creates a file (e.g., pid.7440.dmp) in ./proc_dumps.

2. Dump Tor Browser (PID 9776):

   python3 vol.py -f /path/to/memdump.mem windows.memmap --pid 9776 --dump-dir ./proc_dumps

   You’ll get pid.9776.dmp in the same folder.

Finally, Time for Evidence Extraction

Now the fun part grepping for Monero addresses inside those extracted process dumps. A valid Monero address is 95 characters long and always starts with “4” (or “8” for integrated addresses). Example (the official Monero donation address):

888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1Uxcd

So let’s turn that pattern into a grep:

cat proc_dumps/pid.7440.dmp | strings | grep -Eo '^[48][A-Za-z0-9]{94}$'

• cat pid.7440.dmp | strings → pulls out every printable character sequence from the Monero wallet memory.

• grep -Eo '^[48][A-Za-z0-9]{94}$' → matches only lines that:

  • Start with 4 or 8
  • Continue with 94 more alphanumerics
  • Are exactly 95 characters long

In my test run, I saw below results:

That big string is the Monero “receive” address sitting in RAM. Bam—that’s direct proof the wallet generated/pasted that address.

Double-Check with Tor Browser’s Memory

We also dumped Tor’s process (PID 9776) into pid.9776.dmp. Let’s see if the same Monero address pops up there:

cat proc_dumps/pid.9776.dmp | strings | grep "86e5VjWanQ1"

What we saw in Tor’s memory dump was something like:

<!--StartFragment--><li class="select-all font-bold ...">
86e5VjWanQ1hbdcZenmcBLYgZFfVwhRnjdCXMg3HCuNDgSq2i9tQFRic2qm16ujFH4GyUYP5NG6qaHnkD5AyE7wbK9iKBVe
</li><!--EndFragment-->
86e5VjWanQ1hbdcZenmcBLYgZFfVwhRnjdCXMg3HCuNDgSq2i9tQFRic2qm16ujFH4GyUYP5NG6qaHnkD5AyE7wbK9iKBVe
  

Seeing that address inside the Tor process means the user definitely pasted their Monero address into a Dark Net Market “payment” or “withdrawal” field (that <li>…</li> HTML fragment came straight from the page’s DOM). In other words: at the time of the RAM dump, they were actively preparing a Monero transaction in Tor.

Final Check: Which Dark Net Market (DNM)?

Okay, we know the wallet address is in Tor’s memory. But which marketplace was open? Time for a quick strings search on Tor’s HTML. Maybe we spot a famous DNM domain like abacusmarket.onion or darkfriedfood.onion. Here’s a simple way:

cat proc_dumps/pid.9776.dmp | strings | grep "\.onion"

You might get something like

.

• At around 16:50 UTC, Tor Browser built a circuit and requested the homepage of abacuseeettcn3n2zxo7tqy5vsxhqpha2jtjqs7cgdjzl2jascr4liad.onion, indicating the user visited the marketplace.
• Shortly thereafter, they issued two separate createorder?postageid=post1&tk=<listingID>&qty=1&crypto=xmr calls (for listing IDs f5c04d7b0ff33749a166abb9 and d65e99a8a72014b2cb40becf), showing they attempted to place Monero orders.
• They also loaded the endpoint /balance?crypto=xmr on the same onion domain, confirming they checked their Monero wallet balance.

Circuit #48 built at 16:50:42 UTC → 22:20:42 IST: Tor Browser connected to abacuseeettcn3n2zxo7tqy5vsxhqpha2jtjqs7cgdjzl2jascr4liad.onion (visited website).

Circuit #50 built at 17:04:34 UTC → 22:34:34 IST: The user issued two createorder?postageid=post1&tk=<listingID>&qty=1&crypto=xmr calls (created orders).

Circuit #55 closed at 17:20:04 UTC → 22:50:04 IST: They accessed /balance?crypto=xmr (loaded Monero balance).

…right next to the address. That’s all the proof you need. At capture time, the suspect was on Abacus Market’s checkout page, pasting their Monero “receive” address into the “Send X XMR here” box.

The user briefly switched to drughub666…onion, which appears to be a completely separate marketplace (likely focused on narcotics or contraband) using PGP keys. The endpoints f32b4d88/68a03f86 and a482da10/e4c60a40 look like listing IDs on that site. There’s also a /search=simple&search_terms=number&page=1—a generic search call, probably filtering by keyword “number.”

Summary:

1. On “abacuseeettcn…onion” (a darknet market):

   • They logged in.
   • Searched for “spoof” products.
   • Viewed at least two listing IDs (f5c04… and d65e99…).
   • Attempted to create orders on both, paying with Monero.
   • Monitored their wallet balance repeatedly to see if funds arrived.
   • Checked their profile, messages, and order statuses (“disputed,” “shipped”).
   • Opened the anti-phishing/safety page.
   • Looked at “support” (likely to see FAQs or open a ticket).

2. On “drughub666py6f…onion” (another marketplace):

   • They performed at least a paginated search (search_terms=number&page=1).
   • Viewed two listings (f32b4d88/68a03f86 and a482da10/e4c60a40).
   • Possibly compared availability or pricing.

3. Meanwhile, Tor Browser behind the scenes:

   • Cached favicons for several other .onion addresses.
   • Applied private-browsing isolation (the repeated ^privateBrowsingId=1&firstPartyDomain=… fragments).
   • Presented alt-svc headers to switch to HTTP/2 where possible.
   • Displayed internal errors about bookmark insertions or script injections.

• The user is actively logged in to at least one darknet marketplace (the “abacusee…” site) and exploring all aspects of their buyer account—product pages, orders (including disputes or shipped items), private messages, support, security/antiphishing, etc.
• They’re also simultaneously—or in parallel—visiting a second marketplace (“drughub666…”), looking at listings there as well.
• Every time they land on a listing, they try to pay with Monero (/createorder?…&crypto=xmr) and then poll /balance?crypto=xmr until the vendor acknowledges receipt (or rejects it).
• The dozens of “fake-favicon” lines simply reflect Tor Browser caching icons for all the various .onion hosts in their bookmarks or “onion suggestions.”
• The repeated debug lines (domPolicy, alt-svc, errors about folders) are purely Tor/Firefox internals enforcing privacy, isolation, and performance, rather than signifying anything new about the user’s actions.

That’s it—live memory to pay dirt. Disk forensics might’ve turned up empty, but Volatility 3 plus a few smart grep rules is how you pin down Tor + Monero activity in your next Dark Web case. Good luck, and happy hunting!

Disclaimer:
This blog serves as a guide for law enforcement agencies conducting forensic investigations into dark web cases. No illicit items were purchased at any point—every procedure demonstrated is a simulated exercise carried out on live sites for training purposes. The information provided herein is intended solely for educational use and should not be employed to facilitate or engage in any unlawful activity.