News Feed
  • DrugHub has agreed to fully refund all users who lost money in the SuperMarket exit scam.  
  • Retro Market has gone offline. Circumstances of the closure unknown.  
  • SuperMarket has closed following an exit scam by one of the admins.  
  • The admin of Incognito Market, Pharoah, has been arrested by the FBI several months after exit scamming.  
  • Silk RoadTorhoo mini logo
  • darknet markets list
  • Popular P2P exchange LocalMonero has announced it is closing.  

VirtualBox nolog setup writeup : OpSec | Torhoo darknet markets

As we all probably know VirtualCuckBox being Type 2 Hypervisor is subpar compared to bare metal Type 1 hypervisors yet it still has a large user base.
If you are annoyed by its tendency to keep logs fat and dripping with OpSec damaging details do read on.
I hereby present you a small guide on how to disable its logging for good.

VirtualBox keeps logs in several different places:
The current user home: ~/.config/VirtualBox/
Also for each individual VM you create it also erects a directory corresponding to it named Logs.

First make sure you stop all running VirtualBox processes, go to these folders and delete every log file - *.log
Now you should set some environment variables to disable logging - pretty stupid I know :)
I've tried many different ways to set them but the only ways that worked for me are:

1. Manual execution by setting them directly before executable(just an example, feel free to do it another way):
export VBOX_RELEASE_LOG_DEST=nofile && export VBOX_LOG_DEST=nofile && export VBOXSVC_RELEASE_LOG_DEST=nofile && export VBOX_GUI_SELECTORWINDOW_RELEASE_LOG_DEST=nofile && virtualbox
This method is pretty clunky and inconvenient, sometimes still created some logs. Setting them globally for all users on the machine(better):
cat >> /etc/environment <<\EOF
VBOX_RELEASE_LOG_DEST=nofile
VBOX_LOG_DEST=nofile
VBOXSVC_RELEASE_LOG_DEST=nofile
VBOX_GUI_SELECTORWINDOW_RELEASE_LOG_DEST=nofile
EOF

Do keep in mind that you would have to logout/login to have these put in motion and effect.

The end result should be no log files created at the two destinations mentioned at the beginning.
Note that it in each individual VM directory it still creates directory named Logs but it now should remain empty.
I'll approve the post but it goes without saying disabling these doesn't mean logging won't be completely removed as numerous artifacts remain in a system relating to VirtualBox. The closest you can get to no logs is running in RAM like Tails or taking alternative routes like having ridiculous amount of RAM for live like systems.

Others should add their input on matter as I haven't used VirtualBox extensively in light of better options.
/u/DaSnake 📢
1 points
1 week ago
That goes without saying.
Thank you for your insight.
/u/datarape
3 points
1 week ago*

by /u/DaSnake
VirtualBox keeps logs in several different places... Here's how to disable logging for better OpSec...


Turning off logs in VirtualBox is surface level but if your threat model is the feds, this is nowhere near enough. There are deeper issues and documented vulnerabilities (CVEs) that make VirtualBox dangerous from an OPSEC standpoint let me explain

Why VirtualBox is a Problem for OPSEC:

It’s a Type 2 Hypervisor
Type 2 hypervisors run on top of a full operating system. This means everything your VM does is dependent on the host if the host leaks, logs, or gets popped, your entire setup is compromised.

Documented Exploits (CVE Examples)
There have been multiple Remote Code Execution (RCE) and Escape to Host CVEs affecting VirtualBox:

CVE-2018-2844: A guest VM could exploit this to execute code on the host system using the E1000 network adapter.

CVE-2019-2525: Another guest to host escape vulnerability. If your VM is compromised, the attacker can run code on the host no logs needed.

CVE-2021-2442: Vulnerability in the clipboard-sharing feature could allow data exfiltration or memory corruption attacks.

Any one of these if exploited by a LE malware payload or a custom kernel module could link your “isolated” VM directly to your real IP and hardware.

Ways they can deanonymize you:


  • They can serve malicious market pages that trigger exploits in Tor Browser or your VM.
  • They can identify VirtualBox specific artifacts in memory or through side-channel analysis.
  • They can deliver host escape malware and pivot into your main OS, deanonymizing you fully.
  • They can capture your host MAC address, real IP, timezone, and system UUID once they’re on the host.


Safer Alternatives:


  • Switch to Qubes OS for serious isolation designed for compartmentalized workflows.
  • Use KVM (Kernel Virtual Machine) on a stripped-down Linux distro (no systemd, hardened kernel).
  • Avoid any hypervisor that requires a full host OS beneath it.
  • Treat all VMs as burnable and short lived.
  • Use AppArmor or SELinux confinement if you must use VirtualBox.


Disabling logs in VirtualBox does not make it safe.

If a market ever gets compromised and LE uses a browser 0day or a kernel exploit (which they have), you’re one CVE away from being exposed. Always assume your VM will be breached, and design your OPSEC like it already has.
/u/DaSnake 📢
1 points
1 week ago
Fully agree.
This is just for reference and convenience as a lot of folks use it.
One should stay far away from the idea that VirtualBox is anywhere near safe or private lol
Especially relying on it for mission critical stuff.
/u/Saunders I remember we were chatting about this recently. Thought you may want to read this.
I have a KVM for Whonix post here /post/c32ab31604fbf1d85eac if anyone is interested.
/u/diaperspray P
1 points
1 week ago
Always wanted to try Qubes but my threat level is not what it used to be so I won't bother.

Treat all VMs as burnable and short lived.

We used to do this with Tails too, after a purchase we would use a whole new 16gb thumb for Tails and destroy the old one, use to get em for really cheap back then so no biggie.
Qubes is overkill for 99+% of people. I gave up on Qubes in two days. I've found a good balance and am always working on improving.
/u/diaperspray P
1 points
1 week ago
I agree, I got good chi in my current setup and I'm always breaking/fixing shit everyday to keep learning.
/u/pgpfreak P
1 points
1 week ago*
I'd argue KVM is overkill for 90+% of buyers. The small ones anyway. I've read /u/datarape remarks with attention (thanks for the insight man!). If I understand correctly, getting the host OS compromised would mean 1. being infected with a malware on the guest machine then 2. being targeted by a 0-day attack for host machine escalation. This is a totally plausible risk and I'm not trying to underplay it in any way. However, I'd believe the threat model requirements of an average darknet buyer to be fulfilled with an up-to-day machine running VirtualBox and, obviously, other risks covered (meaning Whonix, PGP, full disk encryption, etc.). This is another story for a market admin, fraud artist or vendor. Maybe I'm wrong here though. I'd be glad to discuss it.
Also, I agree turning logs off is surface level. It doesn't really answer the fundamental risks of using VirtualBox. While giving a false sense of safety.
It's honestly the open source/closed source agruement for me, not that VirtualBox leaves some log files that are encrypted anyway.

Plus, KVM Whonix workstation has not crashed yet. I would've had to power off the VirtualBox one at least three times by now.
/u/pgpfreak P
1 points
1 week ago*
The code is open-source. The whole repository is public. And the project is distributed through GPL3.0.

wwwDOTvirtualboxDOTorg/browser/trunk

Last time I asked about why the reluctance, people had reservations because merge requests (updates) have to be approved by Oracle. Which means the main and probably only contributor is a private company. From a strict OPSEC position one can still audit and compile the source code. I guess the issue is more because nobody will do it without their contribution being recognized one way or another.
This is common vulnerability nowadays. It's no mystery the Mozilla foundation has been dependent of Google funding for years. Which means, to some extend, Tor browser does too. This is not enough for us to stop using it. Because the code is exposed and we trust the maintainers (more than Oracle anyway).
I was mistaken. I should do more research before commenting then. Thank you for the information.

But I still stand that KVM Whonix workstation has not locked up yet, and VirtualBox would have multiple times by now.
Obviously I prefer the ease of the Whonix script to get Virtualbox installed, imported, and up and running and will be "supporting" both in /d/whonix .

But getting KVM running was not super difficult either with some command line knowledge and a couple hours of free time.
/u/pgpfreak P
1 points
1 week ago*
I'm pretty confident a previous comment mentioned close-source at some point actually. I had the license file already opened in a tab when I received notification of your message. Had to check too to be honest :) I've played with both KVM and VirtualBox but not enough to give a relevant opinion. As you mentioned I'm sure most users will choose the later simply for the user interface.
/u/Saunders
1 points
1 week ago
Yeah and i was thinked of connecting to whonix via vpn port with macchanger before to avoid network providers sus and im using kvm for whonix also so i should be fine right? Btw thanks for your concern
/u/diaperspray P
1 points
1 week ago
[removed]
/u/DaSnake 📢
1 points
1 week ago*
I'd very much like to but I haven't got a winscum box to test and verify at my disposal at the moment.
These variables should be set globally or per user *Teh winscuMs wAy*
/u/diaperspray P
1 points
1 week ago
I see.