Torhoo onion mirror : torhoocc3yugradvhrppml2fin4xob7kgg7uf42s4xk7p6r5vzy62ead.onion

Host OS anti forensics : OpSec | Torhoo darknet markets

Hi,

What are some anti forensics stuff you could do on a Linux Host OS (let's say on a normal Debian 12 host OS), you have Whonix QEMU/KVMs sitting on inside of a veracrypt harddrive, with a hidden volume you want to deny the existance of.

I have brainstormed the following:

startup:
-remove all logs in /var/log/
-symbolic link it to /tmp/
-kernel logs clearing

cronjob (every minute):
-clear logs like on startup

shutdown + reboot sequence (which can be triggered with a keyboard shortcut, set in the Host OS)
-forceful immediate shutdown of all qemu/kvm VMs
-close all veracrypt volumes (but i think it's already added into veracrypt)
-clear logs like on startup
-shutdown the computer (not a forceful shutdown) (i'm assuming the ram get cleared out when doing a classic shutdown, but not sure)

Anything else that could be done to make sure that the hidden veracrypt volume is never found even if the computer ends up in the hands of forensic experts ? Bonus points for additional anti forensics measures to waste as much of their time as possible lol (Timestomping cronjob ?)

/u/heavyweaponsguy

1 points

1 year ago

Good list. Also disk encryption at the host level besides the veracrypt encryption of your VMs files. Read through here: /search/?q=hardening&author=HeadJanitor /u/HeadJanitor has posted a lot of good stuff on hardening, the first page of that search should advance you enough.

i'm assuming the ram get cleared out when doing a classic shutdown, but not sure

RAM always clears on poweroff, but it takes about 10-20 minutes for it to fully clear from the chips. Allowing for fancy cold boot attacks. That's why Tails overwrites all memory with 0s while it's powering down. I think you can probably find a method of doing the same if you really care, including memory encryption for prevention but the latter probably opens new risks more than not if done poorly.

/u/azrael13

1 points

1 year ago

Take swap into account as well

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago*

do you know of a simple tool that can be installed via apt that automatically clears RAM ?
i've found this just now https://github.com/Kicksecure/ram-wipe, https://www.kicksecure.com/wiki/Ram-wipe that may be what I need

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago

edit: will dig deeper into how tails does it and try to replicate it
https://tails.net/contribute/design/memory_erasure/

/u/[deleted]

1 points

1 year ago

maybe just have some decoy drives for QEMU/KVMs.
Name the whonix-workstation 'Ubuntu' with ubuntu.qcow2 in decoy drive, and real ubuntu.qcow2 in hidden drive.
Name the whonix-gateway 'Debian with debian.qcow2 in decoy drive, and real debian.qcow2 in hidden drive.

then you can hide in plain site.

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago

yes that's my current setup.
whonix vms inside veracrypt hidden volume,and a copy of those same vms inside the decoy partition

/u/[deleted]

1 points

1 year ago

how are you currently clearing the logs out of curiosity?
also what does the symlink do?

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago*

Current way of implementation (very hackish and not complete by any means), feel free to let me know how i can improve it. as i detailed in this tutorial of mine http://blog.nihilhfjmj55gfbleupwl2ub7lvbhq4kkoioatiopahfqwkcnglsawyd.onion/servers/anonymity/index.html

The symlink makes sure that logs are moved onto RAM instead of disk

First let's make sure all logs get erased upon system shutdown (by piping all logs to go to a temporary folder (ex: /dev/shm or /tmp/) ):

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat startup.sh
#!/bin/bash
sudo rm -rf /var/log
sudo rm -rf /dev/shm/*

sudo ln -s /dev/shm /var/log

sudo dmesg -c
sudo dmesg -n 1
sudo dmesg -c

#also uncomment the kernel.printk line in /etc/sysctl.conf to avoid the kernel from printing out errors

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ vim /etc/sysctl.conf

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat /etc/sysctl.conf | grep printk
kernel.printk = 3 4 1 3


[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ sudo vim /etc/systemd/system/start_logremover.service
[sudo] password for nihilist:

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat /etc/systemd/system/start_logremover.service
[Unit]
Description=Clearing logs at startup
Wants=network.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/root/startup.sh
TimeoutStartSec=0

[Install]
WantedBy=shutdown.target

Next, we make sure that the logs are regularly cleared on the host OS:


[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat removelogs.sh
#!/bin/bash

# crontab -e
# * * * * * /root/removelogs.sh # minutely remove logs if there are any

rm -rf /dev/shm/*
rm -rf /var/log/*
dmesg -c

Next, we make sure that the logs are cleared upon shutdowns and reboots.

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat /etc/systemd/system/shutdown_logremover.service
[Unit]
Description=Clearing logs at shutdown
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/root/shutdown.sh
TimeoutStartSec=0

[Install]
WantedBy=shutdown.target


[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat /etc/systemd/system/reboot_logremover.service
[Unit]
Description=clear logs upon rebooting
Conflicts=reboot.target
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/root/shutdown.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[ mainpc ] [ /dev/pts/2 ] [~/logremover]
→ cat shutdown.sh
#!/bin/bash

#remove VMs

sudo virsh -c qemu:///system destroy Whonix-Gateway
sudo virsh -c qemu:///system destroy Whonix-Workstation
sudo virsh -c qemu:///system undefine Whonix-Gateway
sudo virsh -c qemu:///system undefine Whonix-Workstation
sudo virsh -c qemu:///system net-destroy Whonix-External
sudo virsh -c qemu:///system net-destroy Whonix-Internal
sudo virsh -c qemu:///system net-undefine Whonix-External
sudo virsh -c qemu:///system net-undefine Whonix-External

#then unmount veracrypt volumes

sudo veracrypt -d -f

# then cleanup logs

sudo rm -rf /dev/shm/*
sudo rm -rf /var/log/*
sudo dmesg -c

In the shutdown.sh script we also make sure that the VMs are removed, and that the veracrypt volumes are unmounted, before clearing up the logs.

but as /u/heavyweaponsguy mentionned, this doesnt solve the cold boot attacks problem, i need to figure out how to wipe the ram upon shutdowns aswell

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago*

found a way to repeatedly fill the available ram with 0s quickly, but i cant make it overwrite any RAM that's currently in use. So i guess it's fine in the context of having the veracrypt drives closed, and QEMU/KVM processes shutdown. (meaning the memory for those is supposed to be free, hence overwriteable)

root@debian12-tests:~# cat wiperam.sh 
#!/bin/bash

rounds=3
for i in $(seq 1 $rounds);
do
        swapoff -a
        echo "[+] Filling available RAM with /dev/zero ($i/$rounds)..."
        head -c 512G /dev/zero | tail 
        swapon -a
done

root@debian12-tests:~# ./wiperam.sh 2>/dev/null
[+] Filling available RAM with /dev/zero (1/3)...
[+] Filling available RAM with /dev/zero (2/3)...
[+] Filling available RAM with /dev/zero (3/3)...

/u/BastardSon

1 points

1 year ago

Vet interesting topic, following.

/u/asfaleia ⚔️ασφάλεια⚔️

1 points

1 year ago

If the disk is properly encrypted, all of that is hidden there. It also depends on the type of disk you use.

What you elaborate is the fact that the adversary is in your system. Unless you are highly specific, there is no way to tell if those steps are enough or even effective at all. If the adversary managed to crack your system in a way that allows him to see your /var/log/ he can see you deleting that information and your whole activity is useless.

Make sure you run authentic Qubes in the first place. Second, make sure you set up your Qubes securely and in manageable way (don't spend 50% of your time on maintenance and troubleshooting). Things need to make sense in context. Consider the marginal utility for your setup. Third, don't flag yourself for further investigation.

If you manage those 3 points, you are in a better position than 99% of the other people that don't.

In general, have functioning real world OpSec, specific to your situation and operation, not random guides.

/u/nihilist1 📢 Professionals Have Standards

1 points

1 year ago*

Yes, but i'm also trying to take into account the "if you're forced to give out your password" scenario, hence a regular LUKS encryption isn't enough.

That's why all the effort, it revolves around the veracrypt hidden partition mainly.

Now, i agree Qubes OS is a good standard to follow, which i'll need to write a few tutorials with, but first i want to explore how you can harden the regular linux distro with some simple scripts to make sure that no anonymous activity is disclosed from the Host OS

/u/asfaleia ⚔️ασφάλεια⚔️

1 points

1 year ago

If you are considering the adversary having physical access to your security critical lsystem at the root level and dom0 it is even worse. If you are forced to compromise your password protecting your encrypted Qubes disk, the forensics can potentially be used to find out about the activity even of the disposable VMs. The QubesOS is not amnesic.

You can try to run everything in DispVMs and implement the encryption of RAM, but it is not yet clear what other traces are on the system that a skilled adversary can forensically recover. For example the SSD itself is an issue because it doesn't overwrite the data properly and the wiped out data could potentially be forensically recovered.

It all comes down to your OpSec and threats you can realistically face. The probability is one of the main points to consider. Don't get ready for a nuke if you are facing a man with the stick ;)

If the physical attack is in your threat model, use amnesic system instead of QubesOS to keep your disk encryption untouched or implement countermeasures that destroys the LUKS header. (Facing again the issue with the disk itself of course.)

Btw this is part of our security and OpSec trainings too....

/u/[deleted]

1 points

1 year ago

what they're trying to get at is - "If an adversary forced you to give out the host password, would the OS be clean from the KVM Whonix machines - assuming the .cowq drivers were in a decoy veracrypt hidden partition".

Yes you would see the machines in the virtual manager, but the decoy drives would be clean, and the hidden drives would contain DN related activities.

I've thought about this before, but apart from log files, I don't know what forensically could be found on Debian.
We're not talking about Qubes, dom0 here. We're talking about Debian 12, KVM and Whoinix WS + GW.

/u/asfaleia ⚔️ασφάλεια⚔️

1 points

1 year ago

Still the same. Check it yourself. Make an image of the disk, hash it. Make your activities, super cool concealment. make an image of the disk again, hash it. If the hash didn't change, you are fine. If not, you are fucked.

The SSD or HDD handling of data (not reliable wiping) is not touched by anything you do above. It is an issue of the disk HW, not an OS it serves.