\n\n
\n\n\nHey there, fellow investigators!
\nIf 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\nThat’s why I want to share a little memory-forensics trick that can save the day when disk artifacts are scarce.
\nIn this post, I’ll walk you through how to:
\nLet’s dive in
\nIn 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.
\nBut! 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.
\n\n\n\n\n\n\n\nBefore you meet the real suspect, simulate the scenario in your lab. Here’s what I used:
\nHost OS: Windows 11 (Build Number: 22631.5189)
\n\nFTK Imager: To Acquire the live memory.
\nVolatility 3: Installed on a SIFT VM
\nMonero GUI Wallet: Downloaded from getmonero.org (make sure it’s the legit version!).
\nTor Browser: Grab the latest .exe from torproject.org and Marketplace Login
\nInstall 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.
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:
\nAuto Profile Detection
\nYou don’t have to guess the exact Windows build or win32/64 kernel anymore.
New Naming Scheme, Better Plugins
\nSome 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
\nBy 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.
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:
\npython3 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.
(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)
\n\nArchitecture: 64-bit (x64)
\nCPU Count: 8 logical processors
\nSystem Time (Snapshot): 2025-04-30 17:35:42 UTC
\nSystem Root: C:\\WINDOWS
\nProduct Type: Workstation (NtProductWinNt)
\nSo bottom line: This is a Windows 11 machine (64-bit, build 22631.5189) with 8 CPUs.
\nOnce you know your profile, it’s time to analyze for running processes. In Volatility 3, the plugin you want is:
\npython3 vol.py -f /path/to/memdump.mem windows.psscanWhat 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:
In our run, we quickly spotted two critical PIDs:
\nNote: 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.
\nNow 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.
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
\nDump Monero Wallet (PID 7440):
\npython3 vol.py -f /path/to/memdump.mem windows.memmap --pid 7440 --dump-dir ./proc_dumpsThis creates a file (e.g., pid.7440.dmp) in ./proc_dumps.
Dump Tor Browser (PID 9776):
\npython3 vol.py -f /path/to/memdump.mem windows.memmap --pid 9776 --dump-dir ./proc_dumpsYou’ll get pid.9776.dmp in the same folder.
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):
\n888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UxcdSo let’s turn that pattern into a grep:
\ncat 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:
In my test run, I saw below results:
\nThat big string is the Monero “receive” address sitting in RAM. Bam—that’s direct proof the wallet generated/pasted that address.
\nWe 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:
\n<!--StartFragment--><li class=\"select-all font-bold ...\">\n86e5VjWanQ1hbdcZenmcBLYgZFfVwhRnjdCXMg3HCuNDgSq2i9tQFRic2qm16ujFH4GyUYP5NG6qaHnkD5AyE7wbK9iKBVe\n</li><!--EndFragment-->\n86e5VjWanQ1hbdcZenmcBLYgZFfVwhRnjdCXMg3HCuNDgSq2i9tQFRic2qm16ujFH4GyUYP5NG6qaHnkD5AyE7wbK9iKBVe\n 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.
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
\n.
\nabacuseeettcn3n2zxo7tqy5vsxhqpha2jtjqs7cgdjzl2jascr4liad.onion, indicating the user visited the marketplace.createorder?postageid=post1&tk=<listingID>&qty=1&crypto=xmr calls (for listing IDs f5c04d7b0ff33749a166abb9 and d65e99a8a72014b2cb40becf), showing they attempted to place Monero orders./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.
\n\n\nThe 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:
\nOn “abacuseeettcn…onion” (a darknet market):
\nOn “drughub666py6f…onion” (another marketplace):
\nsearch_terms=number&page=1).f32b4d88/68a03f86 and a482da10/e4c60a40).Meanwhile, Tor Browser behind the scenes:
\n^privateBrowsingId=1&firstPartyDomain=… fragments)./createorder?…&crypto=xmr) and then poll /balance?crypto=xmr until the vendor acknowledges receipt (or rejects it)..onion hosts in their bookmarks or “onion suggestions.”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!
\nDisclaimer:
\nThis 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.