Post B6U5ToYwT8nCvw890S by jsmall@infosec.exchange
 (DIR) More posts by jsmall@infosec.exchange
 (DIR) Post #B6U5TnmNNhwcVJPMJ6 by wdormann@infosec.exchange
       0 likes, 0 repeats
       
       Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.TL;DR: GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's  poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection 🤔)1) GreenPlasmaHere , an unprivileged user can create an arbitrary memory section in an object.  While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a \CSRSS_TEST_SECTION object.It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKeyThis one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting the FsTx directory on the EFI partition. Potentially because the FsTx replay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass.  And it talks about RecoverySimulation.ini and how it skips re-locking a bitlocker drive.  The thing about this is:1) This RecoverySimulation.ini stuff was talked about publicly last year2) The actual bits in the YellowKey GitHub repo are the contents of an FsTx directory.  Which appears to be be related to Transactional NTFS, which uses CLFS under the hood.  (The files parse with python's dissect.clfs).  Also note that by looking at Windows' fstx.dll, we can see code that explicitly looks for \System Volume Information\FsTx in the FsTxFindSessions() function.Microsoft themselves have this to say about TxF 😂:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.And if one looks at the contents of this FsTx directory in the GitHub repo, there are no strings related to RecoverySimulation.ini in it at all.  Only of interest is perhaps:\??\C:\Windows\win.iniand\??\X:\Windows\System32\winpeshl.iniWhere X:\Windows\System32\winpeshl.ini is what controls what WinRE does when it fires up.But anyway, yes it works.But what's intriguing to me is: Why can the presence a \System Volume Information\FsTx directory on one volume affect the contents of ANOTHER VOLUME when it's replayed?  🤔In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it:[LaunchApp]AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE (X:).  And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment.  While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a \System Volume Information\FsTx directory on one volume has the ability to modify the contents of another volume when it is replayed.  To me, this in and of itself sounds like a vulnerability.
       
 (DIR) Post #B6U5To1yRiQBHghocS by wdormann@infosec.exchange
       0 likes, 0 repeats
       
       Note that I've found the hold CRTL and do NOT lift your finger off it part of YellowKey to be completely unnecessary.From the beginning, I wondered why that was even part of the instructions (what does it accomplish?).  And I guess the answer to that question is: Nothing?🤷‍♂️
       
 (DIR) Post #B6U5ToHvUPBK5AAYU4 by wdormann@infosec.exchange
       0 likes, 0 repeats
       
       Microsoft has released CVE-2026-45585 to document YellowKey mitigations.Specifically, you prevent the FsTx Auto Recovery Utility, autofstx.exe, from automatically starting when the WinRE image launches.With this change, the Transactional NTFS replaying that deletes winpeshl.ini no longer happens. It also recommends switching from TPM-only to TPM+PIN.But wait!, you clever security-conscious person exclaims. If the WinRE partition is unencrypted, what stops an attacker from simply splatting back a vulnerable WinRE partition/image?  You are right, you can indeed do this and you'll get a CMD prompt when WinRE is entered.  However, the modification of WinRE will cause the trust relationship between bitlocker and WinRE to fail.  And as such, while you are at your handy cmd.exe prompt, you will not get an automatically-decrypted bitlocker partition.
       
 (DIR) Post #B6U5ToYwT8nCvw890S by jsmall@infosec.exchange
       0 likes, 0 repeats
       
       @wdormann Why document this "remove this entry" nonsense, why wouldn't they provide a Powershell script that admins could just run without having to pick apart?
       
 (DIR) Post #B6U5TonpZmhbg762DI by jernej__s@infosec.exchange
       1 likes, 0 repeats
       
       @jsmall @wdormann Have a batch file that does it all:@echo offsetlocal enabledelayedexpansionnet.exe session 1>nul 2>&1 || (    powershell -command "Start-Process -FilePath '%~dpf0' -Verb 'runas'"    exit /b)set MP=%SYSTEMDRIVE%\WinREMountmkdir %MP%echo Mounting WinRE partition, this can take a while...reagentc /mountre /path %MP%reg load HKLM\WinRESys %MP%\Windows\System32\config\SYSTEMset REG=HKLM\WinRESys\ControlSet001\Control\Session Managerfor /F "usebackq tokens=2,* skip=2" %%A IN (`reg query "%REG%" /v BootExecute`) DO set OLDVAL=%%Bif "%OLDVAL%"=="" set OLDVAL=xif "%OLDVAL%"=="%OLDVAL:autofstx.exe=X%" (    echo autofstx.exe not present in WinRE) else (    if "%OLDVAL%"=="%OLDVAL:\0=X%" (        echo Setting empty BootExecute        reg add "%REG%" /v BootExecute /f /t REG_MULTI_SZ /d ""    ) else (        set NEWVAL=%OLDVAL:autofstx.exe=%        set NEWVAL=!NEWVAL:\0\0=\0!        if "!NEWVAL:~0,2!"=="\0" set NEWVAL=!NEWVAL:~2!        echo Setting BootExecute to !NEWVAL!        reg add "%REG%" /v BootExecute /f /t REG_MULTI_SZ /d "!NEWVAL!"    ))reg unload HKLM\WinRESysecho Unmounting WinRE partition, this can take a while, too...reagentc /unmountre /path %MP% /commitrd %MP%echo Resetting WinRE BitLocker trust...reagentc /disablereagentc /enablepause
       
 (DIR) Post #B6U5bEsh11uoaOuPei by Rairii@labyrinth.zone
       0 likes, 0 repeats
       
       @wdormann btw, autofstx/fstx is unrelated to transactional ntfs, it's a new component in the servicing stack added in germanium, which explains why the original author only got it to work in latest win11 - the vulnerable component literally does not exist in cobalt and prior releases
       
 (DIR) Post #B6UCTZlYBLECinrRqK by wdormann@infosec.exchange
       1 likes, 0 repeats
       
       @Rairii Thanks!