Windows 10/11: "Mock Folders" as UAC bypass security disaster, leverage Applocker and SRP

[German]Windows 10, Windows 11 (and also their server counterparts) contain a huge flaw that may lead to a security disaster. Attackers can create "mock folders" and store malware there. This alows to run malware with administrator rights (without a UAC prompt). Security features like AppLocker or Software Restriction Policies (SRP or SAFER for short) are probably no longer effective either. Is known to security circles, the issue has now come into my radar through an attack.

A phishing campaign

Currently there is a new phishing campaign targeting companies in Eastern European countries. The Remcos RAT malware is to be foisted on them – the attackers can then use the Remote Access Tool (RAT) to access the infected systems. Security researchers at Sentinel One have documented this campaign in this blog post. Colleagues at Bleeping Computer had picked up on it in this post.

Anatomy of the attack via DBatLoader.

The Sentinel One article explains how the attack works in order to get the Remcos RAT malware onto the system. The attachment of the phishing emails contains a tar.lz archive. Inside it are the DBatLoader files, which usually disguise themselves as Microsoft Office, LibreOffice or PDF documents by using duplicate extensions and/or application icons, but contain the Remcos RAT malware.

If the recipient of the phishing email decompresses this archive and executes the unzipped executable, DBatLoader downloads and executes an obfuscated second stage payload from a public cloud location (Google Drive, OneDrive). The security researchers write:

The malware then creates and executes an initial Windows batch script in the %Public%\Libraries directory. This script abuses a known method of bypassing Windows User Account Control, where trusted directories, such as %SystemRoot%\System32, are faked by using spaces at the end of the script. This allows attackers to perform advanced activities without alerting users.

I had overheard it in passing from my colleagues at Bleeping Computer, but had not grasped the explosive nature of the whole thing. That's why I'm presenting the facts separately below.

Pandora's box: Windows "mock" folder

Microsoft did introduce User Account Control (UAC) with Windows Vista to let users confirm requests for elevated user privileges by applications via a UAC message. Standard users need an administrator account password to do this. But there are two pitfalls that make this a night mare.

Windows folder as UAC exception

I confess, it was not clear to me until now or I never thought about it. Microsoft has defined so called trusted folders in Windows. A program that requires elevated user rights at startup, if other prerequisites are present, then triggers no user account control (UAC) query.

Davis Wellis uncovered this in 2018 in the post UAC Bypass by Mocking Trusted Directories on Medium. In addition to the requirement in the manifest that there be an auto-elevation of user privileges (then the program automatically requests the elevated user privileges at startup, which triggers the UAC request), the program must be properly digitally signed. And as a last condition, the program must be located in a trusted directory like:

"C:\Windows\System32"

Then the associated process gets elevated system privileges via auto-elevation without displaying a UAC prompt.

Mocked Folder Problem

Unfortunately, there is a second vulnerability in Windows that sails as a "mocked folder". As a user, you can create folders that have names similar to Windows' trusted folders. To do this, you append a space to these names.

Mocked Folders of the DBatLoader, Source: Sentinel One.

Sentinel One security researchers have made public the corresponding code of the DBatLoader script that creates the mocked folders in the above image. It becomes a directory:

"C:\Windows \System32 "

is set up in the root directory of the system drive C:\ on which Windows resides. There, the attacker has read/write permissions as a normal user and can place his malicious files (e.g. DLLs) in this folder. Furthermore, the attacker drops copies of legitimate binaries from the Windows System32 subfolder into the mocked folder as well.

If the copy of the binary (which comes from the legitimate Windows System32 folder and is correctly digitally signed) is now called from the dummy folder, it starts via auto-elevation with elevated privileges without triggering a UAC query. At the same time, a DLL expected by the program is also loaded via DLL hijacking if it is located in the same dummy folder. Already the attacker has elevated privileges without any user noticing. Jean Maes made this public on July 11, 2020 in the article UAC bypass through Trusted Folder abuse on his page "Red Team Tips".

Abyss and frightened blog reader

I am not going to discuss the phishing attack to distribute Remcos RAT malware mentioned above. They use exactly this attack path. And I won't go into the "what good is it if the attacker doesn't have admin rights" comments often made in response to my articles on "DLL highjacking" – after all, I had referred to UAC bypassing methods on the blog several times. But there's a nice twist to the story. German blog reader 1ST1 took a closer look at the issue before I was able to write it up and left his impression as a comment (thanks for that). I'll pull out his comments and translated the German text:

Also has something to do with Windows hardening… (And I'm pretty horrified about it right now…).

I just managed as a normal user to bypass Applocker, SAFER and UAC with the simplest means. Starting point: CMD.exe without local admin rights (is a separate user).

Already a strange behavior:

md "c:\Windows "

A subdirectory or file named "Windows " already exists.

Note that for cmd "Windows" and "Windows " are the same. But this can be tricked out …

md "\\?\C:\Windows "
md "\\?\C:\Windows \system32"
copy c:\users\1ST1\downloads\harmlose.exe "\\?\C:\Windows \system32"
start "\\?\C:\Windows \system32\harmlose.exe"

In event viewer, Microsoft Windows AppLocker/EXE and DLL

Event 8002, Applocker: Die Ausführung von %osdrive%\windows \system32\harmlose.exe wurde zugelassen. 

copy c:\users\1ST1\downloads\harmlose_setup.exe "\\?\C:\Windows \system32"
start "\\?\C:\Windows \system32\harmlose_setup.exe" 

In event viewer, Microsoft-Windows-AppLocker/Packaged app-Deployment

Event 8023, Applocker: Die Installation von %osdrive%\windows \system32\harmlose_setup.exe wurde zugelassen. 

And UAC prompt does not show up on launch setup.exe either.

In Applocker there are the following rules definied for EXE and DLL via GPO, alternatively, both are overridden:

Allow everyone c:\windows\*
Allow everyone %systemroot%\*

As you can see, there is no space before "\*". (Just don't switch off both at the same time… :-X No way! Really! Otherwise it's over … R.I.P.)

copy c:\users\1ST1\downloads\von_av_ausgeschlossenes_verzeichnis\eicar.exe \\?\C:\Windows \system32

-> At least the antivirus will take action and prevent worse.

What is happening?

The trick is the space " " between "Windows" and the backslash "\". This is not properly checked by CMD, Applocker, Safer and UAC. Powershell probably doesn't either… In c:\ there are just two Windows folders below each other…, more precisely:

"c:\windows"
"c:\windows "

Do you see the difference? If you go into the second one, you can see all files and folders from the first one. But in the folder "c:\windows \system32" there is only harmless.exe and harmless_setup.exe according to the above test. In contrast, in "c:\windows\system32" everything is lying around that belongs there. By the way, the whole thing also works with "%programfiles% ", "program files " and "program files (x86) "…

Basis of the test was this article. WTF!

Workaround? I don't dare to lock "c:\windows \*" via Applocker/SAFER, because this is guaranteed to be confused as well… Maybe lock "c:\windows?\*"? Looks promising, but what about "c:\windows??\*", "c:\windows???\*", … (or does "c:\windows?*\*" ???) – risky…

Help, Redmond!!! (Patchday is only on the 14th, so still 1 week to patch this…)

However, I have to pulverize the hope for a "patch" on March 14, 2023. I had emailed Stefan Kanthak behind the scenes and asked him about this issue. His replica "all cold coffee" can be found in this German comment, which I extract here in excerpts:

• On Securelist in April 2021, the topic was addressed in the article Defense in depth — the Microsoft way (part 75): Bypass of SAFER alias Software Restriction Policies NOT FIXED by Stefan (SAFER are the Software Restriction Policies, SRP)).
• On Securelist in April 2021 the topic has been addressed by Stefan in the article Defense in depth — The Microsoft way (part 76): arbitrary code execution WITH elevation of privilege in user-writable directories below %SystemRoot%.

Stefan Kanthak writes that (as usual) the young people at the MSRC (Microsoft Security Response Center) didn't realize that this is not only a UAC bypass (for which Microsoft doesn't provide a fix in principle), but that it also undermines SAFER and AppLocker (for which they also don't provide a fix in principle).

In his comment, Stefan Kanthak then links to posts by him, Schneegans and Securelist, where this was also addressed a long time ago. He also points out (probably in response to this comment) that user-set (permanent or volatile) environment variables such as %SystemRoot% and %ProgramFiles% override the system environment variables of the same name (set by the administrator). This is also known and has been proven by Kanthak with linked sources.

How to harden Windows?

Blog readers suggest, to block users without administrator group membership or rights from creating foldern on c:\ via GPO. Mark Heitbrink (Ex MVP for group policies) pointed out, that System root security (Rootsec.inf) was part of the security policy in Windows 2000. He had published the Rootsec.inf on his German site – here is the translated excerpt:

What does Rootsec.inf do? It resets the security settings on the C:\ drive to the original state that came with Windows XP. -> it prevents standard users from creating folders on c:\. Here is the content of Rootsec.inf :

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemDrive%\",0,"D:AR(A;;0x1200a9;;;WD)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)"

Save the code into rootsec.inf. To import the template:

1. Open the desired group policy
2. Navigate to Computer configuration \ Windows settings \ Security settings
3. Open context menu -> select Import policy