Bypass the Windows AppLocker bouncer with a tweet-size command If you're relying on Microsoft's AppLocker to lock down your office or school Windows PCs, then you should check this out. A security researcher says he's found a way to potentially bypass the operating system's software whitelist and launch arbitrary scripts. AppLocker lets IT admins managing large networks of machines define …
This post has been deleted by its author
Yeah, or back in Win 95 when you could use the help menu at the login screen to access the desktop and Windows Explorer without logging in. I suppose these are much the same as most of the iOS lock screen bypass exploits you see today. You would have thought that automated testing should be able to catch the bypass-via-navigation issues these days. No idea how you'd have caught this regsvr bug without knowing about it though
This hack is the result of an impressive amount of knowledge of how the inner blocks of Windows fit together, wrapped up in that moment of genius of "hey, what if I tried this ?" and bingo! a new hack is born.
It doesn't feel all that important - until some scum finds a way to use it to download some OS-hijacking malware. The real question is : how on Earth did including the means to parse a URL be considered a good idea when making the functionality list of regsvr32 ?
A part from the obvious "it's Microsoft".
"hey, what if I tried this ?"
I'll bet that is how a lot of expliots are discovered - people trying things that the original designer never dreamed of.
It might not take a huge amount of knowledge of the inner workings to discvover but to actually build, test and confirm a successful exploit is interesting. I have stumbled across a couple of things by accident (typing or selecting the wrong file name) that have turned out to be useful (no real exploits though).
"hey, what if I tried this ?"
"I'll bet that is how a lot of expliots are discovered - people trying things that the original designer never dreamed of."
My father in law was leading the software QA lab of a large company. He had testers that looked at the design documents and immediately found holes, like accepting 8 [:space:] as an allowed password. This made the whole lab very happy - and the programmers less so.
If you need to ask you possibly don't have the skill or possibly the rights to do so. If that is not the case go ahead, if you are a drug dealer or some other assorted low life no doubt someone will give you away anyway. Money talks in criminal circles so watch any friends you thought you had.
Of course be aware that someone, (perhaps a dodgy friend?) might already have done this to you, better go and check your bank account via some other none PC route.
@"If you need to ask you possibly don't have the skill or possibly the rights to do so."
Is that a yes or no? Are we allowed to close this security loophole? You didn't answer my question, and yes I have the right to ask it.
Is Apple allowed to fix the security hole that the FBI used? Is Microsoft allowed to secure its OS or do the Dutch police want to use the holes?
@"if you are a drug dealer ...assorted low life ...criminal circles...dodgy friend..."
I didn't understand your rant. Can we get Windows PC's secure enough they can be used to count an election results? Can we get smartphone secure enough that even the President of the United States can carry one without fear the NSA has a backdoor in it? Can we get cloud apps that can be used to write political speeches without every FBI man having a read? Can we get phones that can be used by Dutch Internal Affairs when investigating why the Dutch police are misusing the money laundering law for political campaigns?
Look, the applocker default rules allow everything below c:\windows. No wonder cmd.exe works. Modify the xml so that a different exe outside of c:\windows is started - does not work here.
Or modify the default rules so that only admins may start cmd.exe - stops working here.
What's the "exploit" worth, then?
I was criticizing the article's title. regsrv32.exe does not bypass applocker, no matter who executes it.
What it does is give us another means of executing script code, in fact, it was always there, so it is not even an exploit that was found. The only connection to applocker is, that with defaults on (which are: programs out of c:\windows and c:\progs are blocked, scripts are blocked (vbs/bat/com/ps1...) one would not expect to be able to execute script code on that system.
Now let's think: why wouldn't we expect that system not to let us execute script code? There's tons of executables in c:\windows, all might offer ways to execute "some" script code, JUST NOT scripts ending with .vbs/bat/cmd/ps1... from untrusted locations. But any other script code? Sure. regsvr32 is an example, there might be others. So surely, even if this does not really bypassing applocker, it urgently asks for review of your settings (Applocker/NTFS-ACLs) regarding regsrv32. Defaults applied? You shouldn't..
"A little more": Surely, the researcher has "found" something. He found a relatively unknown way to execute script code by means of regsvr32.exe. So if we assume that applocker users don't care for locking down their systems (?) AND use default rules AND DO NOT revise the executables these default rules do whitelist, well, then yes, this IS dangerous.
In secured environments, in addition to the default rules (if those are used at all), you would at least use NTFS ACLs to restrict usage of executables in c:\windows that are not needed to administrators. So tell me: what non-admin would ever need regsvr32? No answer expected.
>>"what non-admin would ever need regsvr32"
>Make sure it's unavailable, then. Job done.
Security comes at various levels. Accidental user breaches, like flash exploits, which should be fairly easy to contain with jails and stub resource areas.
Combating users who are trying to subvert the system is much harder. You can govern the executable flag (e.g. on unix) but we're at a whole new (but possibly required) level of system examination when we are passing data which may turn out to be executable as a script.
I think one of my favoured solutions to this would be, "any system executable that takes a url as a parameter passes it through a system proxy." and its extension, "most applications use http/smb/nfs etc and therefore can use a system proxy rather than being given generic network access." Sadly, these days many a commercial OS itself can hardly be trusted, so that may not be acceptable.
With the proxy (or probably audit facility) we have some enforced auditing and possible control and the system can do the encryption/decryption so you can't sneak dodgy data in - or at least if you do, there is a record of it.
What is being abused here is some whitelisted executable. The default rules do whitelist several hundred executables below c:\windows. Now it might surprise many, that the default rules are not what Microsoft recommends to use. In fact, the https://www.microsoft.com/en-us/download/details.aspx?id=40330 applocker design guide even writes
--
To avoid scenarios like this, AppLocker allows the administrator to create a set of permissive
default rules that will allow the user to interact with the operating system without
restriction.[...]
While allowing an inexperienced administrator to safely interact with AppLocker, it does not
create a secure environment. The guidance provided in this document recommends that the
default rules not be used. By following the process in this document, an administrator can
safely create a highly tailored set of AppLocker policies without the need for the default
rules.
To reiterate, DO NOT ENABLE THE DEFAULT RULES
--
And to finally visualize how rotten the default rules are: they allow execution of executables from folders that users may write to. There are several folders below c:\windows where users might copy some virus and execute it. For example c:\windows\temp. To find all folders, use accesschk https://technet.microsoft.com/en-us/sysinternals/accesschk.aspx
and the command (elevated): accesschk.exe BUILTIN\Users c:\Windows\ -w -s
So to be honest: although this topic is a remarkable find, it will only apply to those who did not restrict things after the principle of least privilege or even use the default rules. And as I just showed there are even worse things configured if we choose to create the default rules.
So I tried to reproduce... and failed for a part. (reproduced on win2012r2)
The problem with your examples is that you already may start calc.exe. You have the rights. Same goes for cmd.exe. You already have the right to start it, so executing your scripts results in applocker not blocking cmd.exe. If you block it, you get a script error on calc.exe
When I deny all users in my testenvironment to start calc.exe, I get a script error in backdoor.srt and in the last excel macro. I cannot start calc.exe. Even as administrator (I denied everyone rights to calc.exe) I cannot start it with applocker on.
So, the only problem you have found is that you can run scripts by this backdoor. Applocker shouldn't allow that. But it partly documented. As documented Applocker will only block scripts with the extensions .ps1, .bat, .cmd, .js and .vbs. It does not block .sct.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
