* Posts by Comport-Colin

4 publicly visible posts • joined 22 Apr 2016

Bypass the Windows AppLocker bouncer with a tweet-size command

Comport-Colin

There's more where this came from

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.

Comport-Colin

Re: Does it work? Not for me.

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..

Comport-Colin

"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.

Comport-Colin

Does it work? Not for me.

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?