Under The Radar: Circumventing Application Control Solutions

20 minutes or so so this is a lot of material in this talk so thank you for coming this is calm under the radar circumventing application control solutions um who am i my name is jimmy bain i am at beauhopson twitter i am a security assessor and researcher at biolite i'm actually from baltimore so this is a great venue i'm glad to be here i'm actually an alum of towson university right down the street so go tigers if there's any tigers in the audience it's awesome uh this is my first b-sides talk and actually my first talking general so i'm very nervous uh but happy to hear nonetheless uh so i support a couple community

projects i blog at bowhops.com and i actually help advance with the living off the land and binaries and scripts project all right so today we'll discuss a brief overview of com we'll try to keep it short com is calm we'll also take a look at two application witnessing solutions um and as well as i'll get a few different bypasses and some defense considerations at the end after the talk i'll follow the blog post in the event that if i under run there'll be information provided there so let's get started okay so what is com com stands for the component object model it is a binary interface uh for facilitating function calls uh between components uh components are

also called objects a little redundant right uh so functionally it's really middleware it allows two or more applications uh to communicate regardless of the program programming language implementation the underlying os but in reality it's a major part of the windows operating system uh there's some key terminology that we'll use here so there's a concept called an interface basically interface is a definition for exposing member methods and properties that a caller can actually access through a com object a class is actually the implementation of a group of comm interfaces that serve as a template for acom objects class metadata is actually stored in the registry with registered com an object is nothing more really than an

instance of that com class and then we use that to access those interfaces and properties to actually manipulate data so instantiation is really nothing more than the activation of com object so that's a lot there let's see if we can make some more sense of this uh so for register com uh the regis registry keys actually direct the activation of a com object uh so uh the metadata is actually located in hp classes root uh at the registry hive the data is actually emerged from two other hives the hkey local machine and the hd current user interestingly uh key values in each key current user actually override values in um local machine uh in the

event that if there's any sort of uh confliction or keys that need to be uh uh i should say hijacked we'll use that actually we'll come back to that a little bit later on when we talk about some of the application control bypasses so there's a lot of different com keys some of the most important ones actually reside under this class identifier key structure a class id is really nothing more than a guide with squiggly brackets that in itself actually represents a unique identifier for a com object underneath this class id a sub key structure you have server implementations uh there are two uh in proc server 32 and local server 32. uh impro server 32

is is a dll um actual dll or an ocx in processor implementation so when it's loaded it basically gets loaded into the calling process a local server 32 out of process com server invitation is pretty much executable so if you call that it actually spawns an executable there is this thing called a programmatic identifier this is actually a friendly name that we use to call and activate our target combo objects it would be very difficult to do so by cls id it is possible but you know for the most part we do it through the product id there is also a concept called registration freecom which is very interesting uh it's actually um you can actually register

or assign a registrar sorry you can actually activate objects outside the registry using different manifests assembly manifests and that's out of the scope of this talk but it's something to be aware of all right so we have an example of actually the key structure here uh if you can see at the top left the com class id that's actually the unique value that represents the comm object in this case we have an impro server 32 that key value actually points to a com server binary path and in this case uh see windows system32 w show them.ocx and then we have actually two programmatic identifiers here uh in this case uh the friendly name is uh w script that showed that one

uh a version independent prog id it would just be uh w script.shell so what is this thing with com instantiation so we want to use that object so in order to actually leverage uh this object we can use something like descriptos and powershell is is is good for this it facilitates this uh so uh we can actually um call a com object in powershell uh with the new object um commandlet with and the con object parameter so in this case uh we actually will call w script.shell the program id and that actually gets mapped back to the um the program id i'm sorry the class id in the registry when it's invoked the in process server

is loaded into memory and then the com object instance is actually created so from here we can actually see that we can see the actual members of of this particular comm object and and what happens is this is actually that interface methods and properties uh that we can access through the comm object uh so uh we what that really means is we have pointers to those interfaces so that we can actually manipulate data and leverage these uh methods that we choose to uh so in this case uh at the bottom left uh you'll see that we actually do this um we will call the exact method in this context and we simply just launch notepad.exe

so there is a concept called active scripting and that's based on com ole automation um in windows there's two major active scripting engines uh that expose other respective languages and that's jscript and vbscript so script hosts is something that actually actually hosts scripting engines for running a script code a few examples you might be familiar with are c script.exe wscript.exe nsxml36.dll and the script object dll a facilitator is a term that i actually made up uh it's it's um you've probably heard things called like allah bins if you're familiar with some of the twitter uh stuff going on recently uh so in this case really a facilitator is a binary that actually um will proxy say a

a script or or some sort of a script code to an actual script engine so something like red server 32 or mshda is actually calling another um script host 2 to run that code so what does all this really mean at the end of the day attackers typically look for ways to be calm one of those applications is allocation white listing uh other ways other things that dockers look to do with defensive asian and persistent and payload delivery we'll take a look uh at uh application whitelist bypasses specifically a little later on uh so here's some excellent resources on comm if you're interested uh common 60 seconds window system archaeology um and calm the power thief

these are great researchers um james forshaw matt nelson casey smith rob maslin uh they uh they actually go into com pretty in-depth in these talks highly suggest you look at these if you have the time uh and at the bottom if you're familiar uh if you're from baltimore um you'll know what that is you probably need a few of those to get through some of the common tunnels uh you know it's definitely it's definitely a ride all right so what is application control application application control is pretty much the practice of restricting restricting unauthorized code based on some criteria or some set of rules uh it can be based on assigning certificates uh publisher or like file properties like hash or

extension uh and even file path the main approach for white listing really is three you can whitelist you can block or you can use a hybrid of both we sort of use the term application troll to really mean application way listing you can still have policies that block while others allow so you know it's it's locally we just refer to it as application white listing um in this talk we'll focus on two of the microsoft solutions they highly available readily available we'd pick probably more on vendors if we had access to them all right so uh what is that locker app locker is an actual application control solution introduced in windows server 2008 and windows 7 enterprise

configuring is very straightforward it's configured through group policy supports two modes pretty much enforcement and audit rules can be set for executables installers scripts and dlls uh rule conditions are based on file hash path publisher in app blocker we can actually configure default rules pretty uh easily these are really good for testing and baselining not recommended for um for actual production uh because there are evasion techniques and we'll see that shortly um app locker is not actually considered a security boundary it's actually considered a compliance boundary and that's important because uh it does not enforce a code integrity policy and and what that means is that in windows there's something called the windows lockdown policy

and the idea is that um they're implications where we can evade applocker by simply calling one of those script hosts and executing unsigned code because in theory a lot of those are trusted because they are technically signed [Music] so in the screenshot below we see an effective app locker policy uh trying to call this evil.js file and it's blocked and the reason for that is is because uh the path rules are are blocking this because it does not allow from that path uh the next application control solution is uh windows offender application control uh this was actually formerly called device garden um evolution of names right changes every two years so um this was first introduced in

windows server 2016 and windows 10 enterprise uh it's actually configured with powershell mallets and it it also enforces an enforcement and an audit mode um rules are um i should say rule conditions are based on rule levels that include file hash file name publisher and various level of certificate signing if you you know based on different levels of signing the default rules can actually be set but for the most part those are very restrictive so companies should create their own rules in order to customize whatever fits their organization so um wdac actually enforces a code integrity policy and that's very interesting and through something called uh user mode code integrity and you can set that in the wdac uh

xml policy that you set for your organization uh so under umci and that's that's what that's user mode code integrity uh system is locked down to prevent the extrusion of authorized binaries unsigned code and installer packages uh it is considered a security boundary so if you find a bypass you should report to microsoft uh it's very possible that you can get a cd out of it at the very least you might make the block rules so um and below in the screenshot we have an example of of w deck actually blocking evil.js so of course no talk is complete without mentioning powershell again um as many already know how shell scripting language built for net um has com interoperability which is

pretty cool a lot of great use cases for development i.t for a long time it's been abused by attackers hopefully that's shifting a little bit more i think we're seeing more of that uh really great detection optics in version five since version five um script block logging module logging prescription uh obviously we should all have that turned on and monitoring that in our organizations it supports um a language mode called strain language mode and that actually restricts access to different classes types command list scripts uh and uh it's very effective when backed by an application control solution that enforces good integrity now that's interesting because clm is turned on in app locker as well but without the code integrity

um support uh it's sort of uh it sort of nullifies it a little bit so let's start looking at some of these bypasses this one isn't necessarily com-related but this is just default rules i really wanted to drive home this point these path rules are are very open so you set up default roles with app locker uh a user uh who can write to uh some directory or or some path uh can easily copy that jsc file like say in sequin as tasks and then and then run that script uh so in this case uh we simply pop calculate exe and then successfully run our shell code or should say scrapbook code this is probably the one of the more

well-known attacks a lot of you defenders out there are probably familiar with this as well as your red teamers um i call it 50 shades of squiggly do because this is originally originally called squiggly do but actually a squidward takes advantage of so this was actually discovered by casey smith initially but it actually uses the runtime script component and that's the script object dll and what's interesting is that you can actually use a script component file whether locally remotely and you can fetch that and actually run uh run script code uh so if you see on the uh in the actual image there that second block um it's actually pretty cool because that's that's actually embedded

jscrip code right there so if you successfully run this it actually will go out and create that comm object and run that code so in this case we actually do just that so the bolded the actual bold at the top block there is a representation of how you can use redsear32 to run this unsigned code with that there's actually other variants there are a pub prn wbs which is a really cool technique discovered by matt nelson uh it actually does an injection prn wbs doesn't probably do sanitization so just just another form of abusing this script object dll there's also other variants that you can use through these inf files i blogged about a few of these last year

probably too many of them honestly but nonetheless other ways to pretty much perform swivelling to attack the next uh sort of um bypass for app locker in this case is with xml stylesheet transformation uh this is another area pioneered by casey smith um he uh he found a few techniques a few ways to figure out a way to embed script code in these transform files and what's interesting under the hood these actually views uh the this mx and sxml three and six dlls these are the scriptos so as an example this was posted last year discovered last year this using wmic to go out and fetch this remote xsl style sheet to then invoke and execute uh that script of

code in this case we're just simply launching another uh command processor uh very very interesting attack uh and some of these uh attacks actually at one point uh may have or have in fact bypass device guard as well so keep that in mind as microsoft patches and updates that block rule list so let's talk a little bit more about powershell so powershell constraint linkage mode is very restrictive but under um another enforcement mechanism or should they have a control mechanism like app locker there is no code integrity enforcement so interestingly we can actually abuse that new object commandlet and that com object parameter to pretty much instantiate any com logic that we want so in this case i chose a object

called microsoft xml bom that's that's actually a very interesting one because that will come back later on in the wdx section i will comment on that as well but here we use this and we leverage a a method called uh transform node we can actually take the xsl stylesheet and call that function and execute that script of code embedded in that xsl file all right so a couple of block resources odor mode gave a great presentation last year at derbycon i highly recommend checking out and then adam chester xbn wrote a really nice blog post on uh the powershell technique for to bypass the new object uh malet so let's talk about debbie deck so wdac

uh the discussion would not be complete without talking about the windows lockdown policy now uh windows lockdown policy is activated when umci is under an enforced code integrity policy uh it actually um it is implemented in a library a link library called wlp.dll which is quite fitting and it exports a function called wldp is class is class in approved list which is pretty much does the heavy lifting uh for valuing whether a particular class id is safe and and what this is is that um it does this by checking a list of approved com class objects that are allowed to run on the respective system and that's already predefined typically by microsoft somewhere in the os

if you recall during con activation the prog id is first resolved to a class id say if we're trying to activate that under umci if the class id is in the approved list the activation is allowed otherwise it is not uh so at the bottom slide uh i listed a couple ways to potentially go about looking for wdac bypasses and and these this isn't a comprehensive list uh this is just a few ideas that i had or i've seen in the past uh so not every script host out there is is uh wldp enlightened and enlightened means uh pretty much uh scriptos that actually is compiled with this wldp.dll but the last two we're going to cover

discovering unsafe com objects that are in improved list and reintroducing old code that is still trusted so last year um a lot of uh great research by some uh um uh great folks uh very very motivated i took a a class last year uh taught by matt graber uh very very great it was powershell focus but talked a lot about bypasses and really got me thinking okay you know that blocker is cool but i need to step up my game and really look for ways that show more impact and this was kind of neat so this was sort of the driver for that uh so the the script stuff was was neat but the xml stuff really really drove

home for me so i was um until last spring i was poking around and i ended up finding that there was a comm object called microsoft.xml dom 1.0 that is the property for a class object that exposes some interesting functions so i used a script like this to enumerate all of the actual comm objects that pass that approval check from wdlp wldp i'm sorry so that object stuck out so i queried those methods and and right off the bat i saw these transform node methods and and set property and i was like okay this looks like a potential indicator for for bypass so i loaded up the um the xsl script that i had and uh sure enough as i executed i was

able to execute that that script code right middle and actually invoke and actually instantiate a comma object that otherwise should have been allowed so microsoft patched this last november the uh they passed the bypass vulnerability and updated the com server and basically that com server is msxml3.dll so i tested that but uh tested that patch to make sure it worked and sure enough it did however in december i actually was building a new test machine and uh sort of came with an idea i'm like you know it's interesting i wonder if i could replay some of these things uh so um hey actually uh i actually pulled over a few versions of ms xml3 from previous operating system

versions or different build families and copies over to the new wdac machine and interesting one of those one of those binaries were actually still signed and what i found was let's say like you take a build series like windows 10 build 14 783 right so you know 1473.1 uh binaries um in this case we're actually still signed by something like you know build series 1473.476 so think about incremental patch cycle as time goes on and a lot of stuff is actually stored in the window side by side directories uh but you know at the time i was i was just trying to aggregate and copy as many files as i could over so um so a deeper look into this actually

revealed that it was catalog signed and um this gave me the idea like okay well that means uh microsoft made actually updated a patch uh set a patch for this nsxl3 dll but they did not they did not actually um remove uh the thumbprint from uh this um this actual catalog sign file so that that was that was neat so i i took uh the um i decided that a com hijack was probably the appropriate way to go about this so i i exported that com object class structure from the hk local machine hive and then i updated the paths respectively for hk current user and i change the path to the improv server 32 value

to point to uh my outdated vulnerable ms xml implementation so import it back in and immediately because the hk cu keys over it ride the hklm that showed up in the current road so just as i expected replayed the previous cv and there we have it go to execution again so i reported this to microsoft uh and decide and they pretty much decided not to patch the hygiene issue they were going to patch it but they ultimately decided to add rules to the block list and you know that that sort of uh that's interesting and and that's fine it mitigates maybe this particular uh attack but you know it still leaves the open of the door open for other opportunities

for abuse that might take advantage of this catalog hygiene issue so um before going onto some defense i got only got a few minutes i really want to give a big shout out to philip zuckerman uh he's done some really great research recently uh for uh device guard uh he had a talk at troopers uh called a sneaky passive squad i highly recommend checking that out if you're interested in this area as well as um matt graber's and james forshall's blogs uh really great resources for for wdak all right so a few defensive considerations i'm pushing time here so you know application control most organizations don't implement it uh if you do that's that's a good start

in the right direction uh highly recommend you look into it um some things to consider in powershell upgrade the five take advantage of those security optics take advantage of constraint language mode you can also actually detect uh powershell.com instantiation events uh with if you monitor for id 4103. it's actually kind of neat furthermore antivirus make sure your vendor supports um ansi uh mz's is is really uh growing capability um the um the there's exposure that ansi has with event racing for windows etw mac graber and fuzzystack have have done some research in this area and you can actually potentially pull out like the content of scriptlet code execution with these uh been tracing for windows

logs uh so hopefully uh we'll see some more uh adoption of that in the future as well uh but if you have a vendor that doesn't support amazon you might really want to consider uh finding a new vendor um also um keep an eye keep an eye keep an eye on your app locker and your wdac logs uh if you see uh weird block execution events it's probably a likely indicator of compromise uh and for policy and rule improvement uh there's a project called unlocker for applocker a really good way to boost your app locker roll sets uh for wdac uh make sure you update the microsoft block rules list if you are implementing it

um this changes from time to time and keep your patches updated and of course uh test the fxcf rules uh there's some great frameworks out there miter attack frameworks you probably hear this a lot more for edr testing well they help with uh whitelisting protection as well and also some other tools mentioned here so that's it uh thank you all for uh for coming to my talk and thank you for being with me