@jagotu@infosec.exchange

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · Jun 10, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social good :)

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 14, 2026

Replying to @jagotu@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social Ok, I probably figured something out (observed behavior, so take with a pinch of salt): When properly deploying WinRE, you need to register the hash of the WIM in the volume's bitlocker metadata (item type 0x11). WinRE gets handed an unlocked volume only if the stored hash matches the wim that was actually booted. "reagentc /enable" properly calculates the hash and registers it in the volume metadata. Windows update when updating WinRE seems to sometimes forget to. So on devices that were recieving WinRE updates, a bug might save them from this vuln. Now you might be asking if the WIM hash can be updated in the metadata without somehow invalidating it :) I guess someone will have to try, but hopefully not. This "WIM binding" is described in the BitUnlocker aritcle (https://techcommunity.microsoft.com/blog/microsoft-security-blog/bitunlocker-leveraging-windows-recovery-to-extract-bitlocker-secrets/4442806) as "Trusted WIM boot hash verification". tl;dr It seems some machines are not vulnerable because someone (WU) forgot to update the Trusted WIM boot hash in bitlocker metadata when updating WinRE, making the WinRE untrusted.

3

1

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social Ok, the theory is dead. I just validated myself the fact that doing "reagent /disable" and "reagent /enable" made my device vulnerable even on the latest WinRE build, when it was not before. Behaves the same, just C: stays unlocked. So it's something about how WinRE is deployed, not which version it is. What a mess.

3

4

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social That is indeed an out of date WinRE, from december (https://support.microsoft.com/en-gb/topic/kb5072537-safe-os-dynamic-update-for-windows-11-version-24h2-and-25h2-and-windows-server-2025-december-9-2025-6e3ae479-d2dc-4e01-a5bd-ae652ba8debb) Alright, so I'm starting a theory. It was fixed in latest WinRE but updating it is notorously broken and bad so a lot of machines will be hit anyway. I couldn't reproduce on either february or april builds of WinRE. So it could be fixed by either january (https://support.microsoft.com/en-us/topic/kb5074111-safe-os-dynamic-update-for-windows-11-versions-24h2-and-25h2-january-29-2026-7d2ab6bf-c62d-467e-a1cb-240bf5ef96ac) or february (https://support.microsoft.com/en-us/topic/kb5077180-safe-os-dynamic-update-for-windows-11-versions-24h2-and-25h2-february-10-2026-d47532c0-d1f4-456f-8f9e-e97c156fd2f0) updates.

1

6

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social Can you maybe check the WinRE version you are reproducing on? https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-update-to-winre?view=windows-11#validate-the-windows-re-version-in-an-online-windows-os Need to read both "Version" and "ServicePack Build"

0

1

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social Interesting, that is a very valid scenario then and kinda makes sense. This whole thing is weird... I have a device I was trying it on and the exploit "worked" (winpeshl.ini was deleted, cmd opened immediatelly) but I was consistently presented with a locked C drive. Normal Bitlocker deployment with PCR7,11 measurements. I'm starting to grow suspicious that there are either different versions of WinRE or different ways WinRE can be deployed (suggested by the reagentc /disable;reagentc /enable making it work for some people), and some of them just always relock the drive before the exploit's entrypoint. There are SafeOS updates from at least February (KB5077180, 10.0.26100.7817), March (KB5079471, 10.0.26100.8031), April (KB5083826, 10.0.26100.8235) and now May (KB5089593, 10.0.26100.8455) 2026. I was testing on the February one.

1

10

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @jagotu@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social btw. My quick analysis matches Will's. A transaction log rollback results in winpeshl.ini being deleted, so cmd starts instead of the "blue screen recovery picker" (recenv.exe). In scenarios where recenv would be handed an unlocked drive and was supposed to relock it later (based on which recovery option you pick) this obviously doesn't happen, and you get full access. Anything above that I will have to see to believe :)

6

14

2

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · May 13, 2026

Replying to @wdormann@infosec.exchange

@wdormann@infosec.exchange @GossiTheDog@cyberplace.social The only "explanation" I can think of is it could work with TPM+PIN _if you know the PIN_. So a scenario where a lowpriv laptop user (who knows the PIN) is doing a privesc. I learned to never say never, but I have a hard time imagining a bypass for the PIN requirement by exploiting something on the Windows side of things. But FWIW, even for such a weaker reading, I have never ever seen the WinRE bootprocess ask for a PIN, always just the recovery key, and once you get code exec PCR11 is already locked, so you can't "redo the PIN authentication".

5

15

1

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · Nov 11, 2022

Replying to @jagotu@infosec.exchange

@maldr0id@infosec.exchange @maddiestone@infosec.exchange But I can already 100% support the "everyone should use Frida" sentiment. For me definitely the biggest game changer as there are things I couldn't imagine doing at all without Frida. And it's free!

2

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · Nov 11, 2022

Replying to @maldr0id@infosec.exchange

@maldr0id@infosec.exchange @maddiestone@infosec.exchange Alright, thanks. Next time I have an Android project I'll try the demo and maybe push my employer to go for the full one. JEB is one of those tools I always thought could be a big help but never had the "push" where you miss a capability so much you go try something new. Your post is a good push though ☺️

1

0

JaGoTu 🦊🏳️‍🌈

@jagotu@infosec.exchange · Nov 11, 2022

Replying to @maldr0id@infosec.exchange

@maldr0id@infosec.exchange @maddiestone@infosec.exchange Interesting advice, could you mention the biggest game changers of JEB for you? It's hard to know what one's missing on with products that are not cheap to just try buying randomly.

3

0

JaGoTu 🦊🏳️‍🌈

Posts

Remote instance