the Exploit is stupid

[Salah-Code-Lab]

Why the hell would someone deploy this on a Unencrypted drive to allow the drive to be decrypted
heck to even drop it in the first place Requires the drive to be decrypted
Like this exploit is completely useless let alone Physical access
and if you managed to add the xml in the first place
then the drive is accessible
then why even bother adding it in the first place
are you trying to bullshit us mate ?
Impractical pieces of shit exploits

[didotb]

I think you misunderstand. WinRE partition cannot be encrypted with bitlocker otherwise WinRE fails to function.

There even is a microsoft forum talking about some people not able to access WinRE due to bitlocker being turned on in the same drive WinRE is installed.
https://learn.microsoft.com/en-us/answers/questions/4061885/how-to-enable-winre-while-bitlocker-is-on

[Salah-Code-Lab]

I think you misunderstand. WinRE partition cannot be encrypted with bitlocker otherwise WinRE fails to function.

There even is a microsoft forum talking about some people not able to access WinRE due to bitlocker being turned on in the same drive WinRE is installed. https://learn.microsoft.com/en-us/answers/questions/4061885/how-to-enable-winre-while-bitlocker-is-on

Hey Didotb,

You maybe didn't get the point, but adding a file to an encrypted disk or partition is impossible without corrupting it. If you want to add this XML file in the first place, the disk must be decrypted to copy the file to it.

Why the heck would someone copy the file and give themselves a limited time window to do so, while the OS is already wide open? And don't get me wrong, you can still boot to WinRE, but you can only access the SYSTEM partition, not the primary partition which won't do you any good as an attacker.
Oh, I completely forgot about something: this thing needs a reboot after you write the XML to the target directory.
If an attacker actually triggers a reboot, the whole attack FAILS.
They would have just terminated their own access in a stupid way!
Well, unless the attacker has physical access say, they stole the laptop or PC while it was somehow left turned on.
But even then, why would they need to apply an XML exploit if the PC is already wide open?
This isn't a Exploit
this is just how windows works basically
and my guy Of course When you trigger a Offline scan windows Must decrypt the Disk to scan it in the first place

[Olof-Lagerkvist]

The XML file is not added to an encrypted volume. It is added to the separate Recovery Environment volume that is not encrypted.

But still, adding this XML by itself does to activate the exploit. An offline scan needs to be prepared in the encrypted system volume too and that is where your point is still valid. You cannot do that without keys to the system volume anyway.

[Salah-Code-Lab]

The XML file is not added to an encrypted volume. It is added to the separate Recovery Environment volume that is not encrypted.

But still, adding this XML by itself does to activate the exploit. An offline scan needs to be prepared in the encrypted system volume too and that is where your point is still valid. You cannot do that without keys to the system volume anyway.

That is exactly what I am arguing about. Also, to add it while the OS is offline, you would need a physical attack initiated by someone and I think it is pretty obvious that physical attacks are always out of scope.

[GeldHades27355]

It is actually even less likely IMHO.

SCENARIO 1 – remote/from running/sleeping OS
Dropping the file to WinRE from running OS requires mounting it first, which requires elevation. Doing that programmatically in a best practice environment would be VERY hard indeed. (but obviously not impossible, given the other Vulnerabilities MSNightmare dropped)
If you had physical access, it might be even harder, as unsupervised devices should be locked.
Modern Standby devices (almost all these days) will not let you inject code into RAM (and thereby storage) on standby either.
If you managed that, you cloud run Start-MpWDOScan to initiate the offline scan, which will also reboot the device.
Even assuming you managed all of that, you still need physical access to the device before you can complete your mischief.

SCENARIO 2 – local / offline OS
Again, you must have physical access.
Sure, boot up, skip Bitlocker on system drive and you have access to WinRE.
Drop the files to WinRE and restart.
Now, you're stuck. You can't initiate an offline Defender Scan without unlocking Windows first.

Seems like a VERY targeted scenario with VERY narrow scope. Certainly nothing that works at scale.

Yellowkey was MUCH scarier.

Am I missing something?

[Salah-Code-Lab]

It is actually even less likely IMHO.

SCENARIO 1 – remote/from running/sleeping OS Dropping the file to WinRE from running OS requires mounting it first, which requires elevation. Doing that programmatically in a best practice environment would be VERY hard indeed. (but obviously not impossible, given the other Vulnerabilities MSNightmare dropped) If you had physical access, it might be even harder, as unsupervised devices should be locked. Modern Standby devices (almost all these days) will not let you inject code into RAM (and thereby storage) on standby either. If you managed that, you cloud run Start-MpWDOScan to initiate the offline scan, which will also reboot the device. Even assuming you managed all of that, you still need physical access to the device before you can complete your mischief.

SCENARIO 2 – local / offline OS Again, you must have physical access. Sure, boot up, skip Bitlocker on system drive and you have access to WinRE. Drop the files to WinRE and restart. Now, you're stuck. You can't initiate an offline Defender Scan without unlocking Windows first.

Seems like a VERY targeted scenario with VERY narrow scope. Certainly nothing that works at scale.

Yellowkey was MUCH scarier.

Am I missing something?

No you are not missing anything and that is why i called the Exploit impractical
because even after everything you do
you need physical access while the scan is running
but why initiate the scan in the first place if you already have access to a Unencrypted partition that has data
ready for Exfil ?
You'd just be terminating yourself as a attacker
we have a saying that states:
"If an attacker has physical access, it's not you're computer anymore."

[GeldHades27355]

There's that, too. 🤣

I was just exploring ways this could work. None of them are very practical and certainly not scalable.

I am not aware of any way to initiate an offline defender scan without prior access to the trusted OS environment. In which case, as you point out, you already HAVE access to unencrypted, local data. Duh.

In fact, in modern cloud environments, you'd WANT to stay within the trusted OS, so data exfiltration has potential access to cloud storage in addition to local storage.

Getting offline access to cloud-connected PC storage may only give you ~5-10% of that person's data. Most of it will be OneDrive on-demand pointers to a cloud file.
Although you could inject malware that way to continue the exploit once the OS is back up and a user has initiated a session.

IMHO this is just MSNightmare continuing their personal feud / crusade against MSFT, trying to prove bad design.

While other PoC are definitely impressive and scary, this is one is not imho.

[Salah-Code-Lab]

There's that, too. 🤣

I was just exploring ways this could work. None of them are very practical and certainly not scalable.

I am not aware of any way to initiate an offline defender scan without prior access to the trusted OS environment. In which case, as you point out, you already HAVE access to unencrypted, local data. Duh.

In fact, in modern cloud environments, you'd WANT to stay within the trusted OS, so data exfiltration has potential access to cloud storage in addition to local storage.

Getting offline access to cloud-connected PC storage may only give you ~5-10% of that person's data. Most of it will be OneDrive on-demand pointers to a cloud file. Although you could inject malware that way to continue the exploit once the OS is back up and a user has initiated a session.

IMHO this is just MSNightmare continuing their personal feud / crusade against MSFT, trying to prove bad design.

While other PoC are definitely impressive and scary, this is one is not imho.

Yeah and as we said Exploits are practical and consistent
and this isn't considered a vulnerability since windows itself needs to decrypt the drive to scan the C:\ drive
for the rest of exploits, yeah some are scary but the last one
RoguePlanet isn't it is a vulnerability but not a Exploit
i tried Multiple Environments i ran it thousands of times while defender was off
then Edited the code so it can be ran as system and it failed miserably
it isn't a exploit it is a Vulnerability nothing more nothing less
Let them continue they just revealed zero days worth thousands of $ for free on github
what a loser

[GeldHades27355]

Yellow key files were blocked on all windows devices within 24 hours. So you needed another OS to prep the USB stick.
But that WAS reproducible, actually quite trivially. Even easier than the PoC instructions suggested.
It exploited an obsolete NTFS function, that Microsoft has been telling folks to NOT use anymore for years (it's from the Vista days).
But of course, certain apps depend on that stone age 💩, so MS left it in. Customers don't want state-of-the-art, they want their old crap to keep working. 🤦

Anyways, Yellowkey was patched two (three?) weeks later so: also obsolete.

Regardless: I am happy this person is giving MS blue team a run for their money.

In effect, MSNightmare is helping MS and thereby us by disclosing all this stuff publicly.

Regarding missing out on bugbounty: The feud between them is personal. Literally. And legal. I worked for MS on the Windows Device team for a while and still know some folks. This is revenge. Plain and simple. MS is leveraging it for all its worth.

Frankly: publishing it doesn't really do any major damage, other than embarrassing MSFT to a VERY small extent.

If MSNightmare wanted to do REAL damage and/or realize maximum gains – they'd share/sell these vulns and exploits in secret with appropriate ... organizations.

[Salah-Code-Lab]

Yellow key files were blocked on all windows devices within 24 hours. So you needed another OS to prep the USB stick. But that WAS reproducible, actually quite trivially. Even easier than the PoC instructions suggested. It exploited an obsolete NTFS function, that Microsoft has been telling folks to NOT use anymore for years (it's from the Vista days). But of course, certain apps depend on that stone age 💩, so MS left it in. Customers don't want state-of-the-art, they want their old crap to keep working. 🤦

Anyways, Yellowkey was patched two (three?) weeks later so: also obsolete.

Regardless: I am happy this person is giving MS blue team a run for their money.

In effect, MSNightmare is helping MS and thereby us by disclosing all this stuff publicly.

Regarding missing out on bugbounty: The feud between them is personal. Literally. And legal. I worked for MS on the Windows Device team for a while and still know some folks. This is revenge. Plain and simple. MS is leveraging it for all its worth.

Frankly: publishing it doesn't really do any major damage, other than embarrassing MSFT to a VERY small extent.

If MSNightmare wanted to do REAL damage and/or realize maximum gains – they'd share/sell these vulns and exploits in secret with appropriate ... organizations.

Correct he would had sold them to keep the exploit hidden for longer for threat actors to use it
but hey good for us that he shared them for zero value
and yeah there had been issues with their old stuff but they are keeping it for backward compatibility
windows is made for Convenience
so any old third party drivers
any app that is old can still function
to this day you can use ExAllocatePoolWithTag even though it is obsolete (according to MS)
and honestly ? we also do the same thing but indirectly
by: If shit is working keep it that way do not edit it
if their Core OS is working on "Obsolete" API and functions
then let it run do not interfere

[ByteJoseph]

But we call it GreatXML

[Salah-Code-Lab]

But we call it GreatXML

Ironic how it ain't great at all