 My name is Sean Pierce and this is abusing native shims for post exploitation. That's what it says. Track 101. Good morning. There's more people here than I thought there would be. I'm going to assume everyone is hungover. So let's just get this show on the road. About me, my name is Sean Pierce. I have a CISSP and a few other certs. It's my Twitter handle. If you want to email me about the stuff, sdb at secure Sean.com, github and sdb.tools or sites that I can control or that github directory. Just as a disclaimer, I'm not a pen tester. I'm not a developer and I'm not an eyesight representative. They are my employers. And then you might think, oh, why are you using their slides? It's because they look really nice. And to that point, I just want to say that I love who I work for and there's just a bunch of great people there and really smart and they're just fantastic and I just cannot say enough good things about them and they threaten intelligence. And if you want to know more about them, that's their website. So why am I here? Well, when I was 21, my dad took me to Las Vegas and we were sitting down the Rio buffet and he was like, what do you want to do and I saw someone walk by with a black hat bag and I was just like, no way. And so I tracked him down and I was like, oh, is this going on right now? And he's like, no, but Defcon is. So I found it in Riviera. I snuck in and bought a t-shirt and I had a great time. That's really cool people and it really encouraged me to get into this field a lot more. And my dad passed away a few years ago. And I think he'd be really proud that I was given this talk here today with y'all and he really is the reason why I'm here. So getting on to the talk. So a bit of history behind application compatibility. It's kind of funny and it is the reason why I think Microsoft has such a dominant place in the market because they go to so much effort to keep with application compatibility. Like an enormous amount of effort that you cannot even really imagine. And like just as a simple case study, the original SimCity that ran on Windows 3.1 had a free after use vulnerability. It's a free after use bug. So it would free some memory, it would call the free function and say I'm done with this memory and still continue to use it. And that's terrible. But lucky for it, the old operating system didn't really use a whole lot of memory. It didn't really have a whole lot of concurrent processes running and it didn't really take it back all that much. And then in the new operating system, Windows 95, the memory manager was way more efficient and had processes that it would actually want memory all the time. And so this program would crash quite frequently. And of course if you're a user and you install an old favorite game on a new operating system with a nice new computer and it keeps crashing all the time, you're going to blame the operating system. And Microsoft really couldn't have this. And even like one of the heads of the Windows dev team, he drove down with his pickup truck to a local egghead store when there were still egghead stores. And he filled up his pickup truck with every game he could buy off the shelf from the store and drove it back to Redmon and said to his developers, everyone take at least three games and it has to work on Windows 95. Just has to. And so they would hard code things into the operating system to watch for certain crappy code that was written by random people all over the world. And they would account for that in the operating system. Which is kind of terrible. But it was what they wanted to do to maintain such application compatibility. And there are other case stories and I encourage you to read the old new thing, one of the Windows developers and testers. He had this blog called the old new thing and he put it into a book. And some of the stories are pretty funny. Like he had one where the graphics card manufacturer wrote this driver and in the driver specifications you have to implement this function that basically says, takes in one parameter and it says, do you support this? And this graphics card manufacturer simply returned true for everything. Which is terrible because that's how the operating system determined if it should do something in hardware or software. And so Microsoft called them up and it was just like, hey, WTF. And they were just like, we don't care. Honestly we don't care. And even if we did, we'd have no way of pushing out a patch. And even if we wanted to do that, that card is old and we don't even support that anymore and we don't even have the source code for it anymore. Which is apparently a really common problem. And so Microsoft built their own database of what graphics cards supported what and they hooked that function and then they just did it all themselves. So Microsoft goes to great lengths to make sure that this stuff still works. And it's not just for third party bad code or just dumb programmers. It's also for OS bugs because certain programmers leaned on certain features or lack thereof in the operating system. Such as this case study of a synchronous buffer commit. Basically when you call a write function and you think you're writing some data to the disk, you're actually just put it into the buffer and the operating system will write things efficiently to the hard drive and batches or whatever else. But if you have like a database program, that's not so good because you need to guarantee that your file, that your database is in a certain state. Now Windows had this function where it would basically say write everything to disk. Flush the buffer. You know, synchronous buffer commit to the disk. Great. So you can guarantee that it worked. And developers love this because it was really efficient. They saw that there was almost no performance impact. And then they moved to like a newer version of the operating system, Windows 95, and they noticed their database program was going really, really slow. And it turned out Microsoft never actually implemented that function. There was a knob. It didn't actually do anything. So when they thought they were like flushing something to disk, it wasn't at all. Which is terrible. So what was Microsoft to do with these programs that are now running super slow? They knocked out the function again. Which is hilarious. This line where the operating system pretends or lies about something frequently happens between versions of Windows. Like Windows 7. Like that's the major version of 7. But there are so many programs that had bugs and how it determined what version something was. They just called it Windows 6.1. Like that's the function call. That's what it returns. It's Windows 6.1 instead of 7. Because so many applications would run on this, they just failed to run on Windows 7. So they do crazy things like that. And they also have a lot of lying when it comes to 64-bit or 32-bit apps running in 64-bit machines. And I'll have some examples here in a bit. So a while ago, Microsoft tried to stop hard coding values into the operating system. And they started to bundle a bunch of stuff together. So there's a few basic vocabulary words. There's a fix, there's a mode, and there's a shim. So a fix is one of these little things. This is just if you right-click on a program and then go to properties and go to the compatibility tab, here you can say run as administrator or have certain display setting like that. And that's a fix. It's a single thing that does one little thing. A mode is a bunch of fixes bundled together. So if you say compatibility mode right here, then you say I want Windows XP, SP3, or this or that. And you get a bunch of fixes that are already put together. And these configurations are bundled together in what they call a shim database file or an SDV file. So what actually happens when a process is being shimmed? Well, some parent process will call a function like create process or shell execute or something like that. And when it gets down to a lower-level API calls, the operating system, NTDLL, checks the registry to see if this child process should be shimmed. And then it sets an undocumented environment variable called AppCompat or underscore underscore AppCompat. I do believe maybe one underscore. And it'll specify what it needs to do. And then the child process does a similar kind of checking to make sure it should be shimmed as well. So it typically works in that a table, a data structure in memory called the import address table holds all the addresses for the operating system function calls that that program is going to use. And this is cool because most hooking, including this root kit framework, I mean compatibility framework, will use that table to hook in whatever it wants to manipulate. So when I say shim, I'm usually talking about the code that sits in between the import address table and the rest of Windows API. And they made some great hooking libraries and they told no one about it. Like if you try to dynamically load something like with load library, it hooks that too. If you try to get the export address table for one of the DLLs, it'll get that too. So they do this stuff pretty well. So the official uses for shims are not just for third parties but a good use example is a fix it patch. So if you are seeing exploit against your enterprise and this is your day and you tell Microsoft and they'll like, okay, okay, we'll patch it, you know, come Tuesday, patch Tuesday and a month and you're just like, I can't wait for that. They'll give you a fix it patch. And if you crack that open, you'll see that's actually just a shim database file, an SDV file with certain configurations and usually that has some kind of patching information. And a lot of times it's not like a super elegant fix but it'll like, worse comes to worse, it'll cause a memory leak or it'll crash the process before it gets exploited. So it's a better solution than getting exploited. EMIT, the enhanced mitigation experience toolkit, uses shimming as well to get a process and either like, up its security by like saying you must enforce ALSR, you must enforce DEP and other stuff like that. And it's really quite effective. So I want to introduce to you the tool that Microsoft released that lets us make our own shims. And it's called the application compatibility administrator. And I want to show you a cool undocumented trick. And the text, like I said, is a little small. You need to be administrator to run this. Well, you need to be administrator to install the shim. And I'll tell you why in a minute. So here, I created a fix. I specified putty.exe is a program that I wanted to shim. And I said, here's the file on disk. I'll tell you why in a minute it wanted the file so badly. Now you'll see here that there's a bunch of fixes that Microsoft has already made. Or I'm sorry, modes. And they provide all this internally. And that's really cool of them. But they provide like 300 some odd fixes. Some of them like API tracer, API logger, read bios, reroute registry keys, reroute file pass, fun, fun stuff. Now if you go to where that program is and you open up a command line. And then you run the app compat or the application compatibility administrator from the command line with the option of slash x. Everything will look normal. And you go through the same sort of thing. I'll specify that putty should be the program, my target program. Now you'll notice that instead of like the 300 some odd fixes we had, we now have 800 and 8. A lot of them are very special. They're very specific to a program. So you see like Adobe Acrobat 5 or Norton antivirus or something like that. And that's fun. It's cool to see how Microsoft was manipulating those particular processes. Now I just specified one of my favorite fixes called inject DLL. And as you can imagine it allows us to inject any arbitrary DLL even over a UNC path into any process we choose. And it runs with that process's rights. So here I'm just specifying a DLL that works better than the root directory. Now earlier I chose putty. I had to browse to putty and say I want this executable. And this is the reason why. Because it went and analyzed that file and said here's a check sum. Here's a bunch of stuff I can trigger off of. Compile time and all that. And I can use that to trigger and execute my shim. But I removed all of those and said I just wanted to trigger off the name putty.exe. I'll let this video run. So I have to save a shim database file beforehand. I just specified the file name and I'm saving it to disk. And I'm going to use a program called SDB inst. An installer for SDB files that's found on every Windows computer out there. Installing it on the command line here, SDB inst. You should pay attention to this tool because we'll talk about it later. I'll say installed successfully. And then it's installed. So now every time I execute putty. Okay. Wait. There's my DLL. Are we, are we, Jesus, I've never met a more grabby speaker in my life. I always run out of time in all my practice talks. Oh, I'm sorry. All right. Well, then we'll get this over quickly. We also have Mike on stage. Mike is a new attendee. He's representing all you new attendees. So how's he doing? Question for the crowd. Fuck are you doing here at 10 a.m. on Sunday? You must be some kind of God or something. Anyway, there you go. First time attendee. Defcon. Cheers. Thank you for coming. Anyways, let's talk about putty now. Great putty. Also, I really like more of a conversation. So if someone has more of a question, feel free to yell out. But I do have to roll pretty fast on this. Okay. Anyone, everyone good on that? Just made a shim and installed it with Microsoft's tool. Now this is the public version of the tool. They have a private version which shows them more information and gives them a bit more capability on a lot of things. And I'll show you some of those things in a minute. But one of them, one of the major ones, is hot patching. This public tool has no awareness of hot patching. But in shim database files, you can specify that something be hot patched. And that is crazy powerful. So I said you need to be administrator and you really only need to be administrator to write to two registry keys. And that's all it takes to install a shim. And that's all SDB inst did. Well, I did a little more. So basically it copied my SDB file that was on the desktop. And then dropped it into a windows folder so it can't be messed with. And made two registry entries. The first one specifies that there is a program, putty.exe that does need to be shimmed. And then the second one right under it installed SDB. This is a GUID that points to this one. And it specifies exactly the path on disk of my shim database file, the SDB file. And I've played with this. And it's funny because you can actually specify, go in there and change that to a UNC path so you can actually have your shim database loaded over the network instead. Which is hilarious. So those are the registry keys that I was referring to. So they're current high key local machine. That's why you need admin privileges. But if you boot it from a live disk and you're able to edit the registry, you don't need to be admin. And those are the default file locations that it'll drop the copied SDB file into. Now if you use SDB ends, the standard installer that's found on all the windows machines and you install something, it'll add that fix to the add remove programs. It'll add that shim to the add remove programs menu. And you can just click it and say uninstall and it'll pop it out. Bad guys I've seen have used this. It'll use SDB ends and it'll install it, install their shim, do their thing and then immediately uninstall it because they don't want it showing up here. And that's really weird to me because all it does is add those registry keys. That's all you need. So if they just added those registry keys, they wouldn't have this show up. But I've never seen any bad guy manually install something to the registry or manually install a shim. So there's a simple YAR rule that I put up there and it keys off the magic value. So what can we do with this? More maliciously. We can do targeted persistence. Obviously if putties run every single time, there is some stuff I can grab from it or whatever. I'll show the demo in a second. But we already kind of had that. There is this registry key that malware has used. It's been around for a while. And if you have a program name in it and then you have the string debugger, then it will execute your debugger instead of this program. So we have a similar type of persistence mechanism. But shims are way more powerful. We can do some API logging. We can terminate any application we want. There's a terminate exe fix. I don't know why that's a fix. But there's great things you can do with it. Since you're already in the process space, you can capture all the credentials that are going through. You can redirect application logs. You can snoop slash redirect network traffic. You can trochanize any application like we saw with putty.exe. And cyber espionage groups have used this before. Like there was one group that was very interested in SCADA systems. And so when they compromised a machine, they dropped a shim database file which would just key off that SCADA software running. So if the software never ran, they wouldn't care and they wouldn't get a callback. But if it did run, it would grab this information and execute their malicious code and send back some config stuff. So we can also force vulnerable DLL loading. So I can specify that an old DLL should be loaded instead of the nice new one. So I can reintroduce a 10-year-old vulnerability into a system if I ever get kicked out. I can subvert system integrity. And I'm going to show an example of that. I can do what I could have done in the past UAC bypassing, but Microsoft just patched that. I was just like, ah! Just right before my talk. So and since I'm a malware guy, I'm really into malware obfuscation. I'll let you read that for a second. So in Windows Vista, if you all will remember, there was the UAC prompt popping up left and right all over the time because processes needed to elevate their privileges to do something. Legitimate things like direct access to the hard drive or even sound volume is the one that's usually targeted. And people didn't like that. So Microsoft quietly added this little feature and didn't document it anywhere. And the manifest file, the manifest part of the binary called auto elevate. And it would set that equal to true. And if that was correct, then that program, when it launched, would automatically elevate to system level authority. Which is hilarious. They didn't think it was that big a deal because you have to be signed by Microsoft in order for this property to work. But with shims, there's a cool little fix called redirect exe that says, oh, you see that program running? No, run this one instead. You know, just because. And run it with the same privileges. So the common tactic would be to install a shim and you have your malware on disk or UNC path. And you say, okay, I want to run sound volume. But wait a second. Redirect exe run this thing instead. And my malware now has the system level privileges that sound volume did. So that's fun. And here's a little sample of the Drydex malware using it. It would run stb-enst, again, making this, you know, ad remove programs entry and, you know, whatever else. And it would just use redirect exe fix for its malware because it wanted to install as hyper religious. A number of malware families have used this much more recently in the past year. It's become more widely used. But I think after the Microsoft fix, it won't be used as much. However, the Microsoft patch was an optional patch and didn't install by default just FYI, depending on your policy settings. So black energy, Gootkit, roaming tiger, search protect. I actually got infected with it when I began doing my research. It's just a potentially unwanted program. It's not that big a deal. Gooptar, A, or, you know, update spelled weird, Drydex. And there's a few other malware families, but these are like the big ones. So black energy, particularly the second variation, is an interesting piece of malware because it's been around for a while. It was originally used for cybercrime and then it was picked up for use by cyber espionage and got way more sophisticated with 64-bit plugins, rootkits and all this other fun stuff. And it used shimming for a UAC bypass. And it was the first malware family to do so, at least that I know of. And they also did something else slightly interesting. They used another fix called DisableNXShowUI, which was it disables the NX bit so stuff on the stack. So, that was funny. The second espionage group to do something interesting with it was called Roaming Tiger, where it was outed by ESETs. Anton, I don't want to butcher his last name. This group was outed last year as well by iSight by my company. They called it Sandworm. They attributed it to the Sandworm team. This group was outed by ESET at Zero Nights last year as well. And here we can see, well, it may not be very easy to see, but we're using John Erickson, his STB Explorer to analyze this STB file that they would drop. And they would basically say, I don't want any of the Microsoft pre-defined fixes, although there are plenty. I want my own fix, which you can do. And they said their fix applies to explore.exe. And all you need to do to make a custom fix is to make a DLL that exports two functions, and then you need a shim that says, use this DLL. That's where the fix is. Pretty simple to do. So I'd like to show some examples of how a pentester might use this stuff or how malware might use this in the future. There are anti-analysis examples I'll get to in a bit, but I really like the idea of old to take a crappy old piece of malware with some hard-coded IP address or registry key value or path name or whatever, and when it runs on a system that you've compromised, you can specify, hey, change this at run time. This IP address is actually this IP address. This registry value is this. This is actually expelling to this location. So if an incident responder ever came across from a computer, eventually he probably would, and finds that this malware is running and you can make it some simple thing and he dumps it or he gets it off a disk and he runs it in a sandbox and he says, oh, it's just doing something really simple. It's peeking out to this IP address, it's doing this and the IP address has been dead. I'll search my enterprise for that IP address or domain name or whatever. I don't see it. Okay, we're good. That was hard-coded. There's no way to change it. Little does he know that it was changing dynamically at run time and HTTP files can modify things like that at run time. Putty.exe, I showed earlier with inject DLL fix. We can, where's my mouse? There it is. We can inject an arbitrary DLL and there's a cool little program out there called PuttyWriter by a guy named Adrian Furtuna. I'm sorry, Adrian, if I just butchered that. But it's cool and it's a DLL that when injected into Putty will hook the basically input and output networking and will use a connect back to send you that information. So all you have to do, I just ran Putty on the left to show you that it is Putty. On the right, I've set up a Linux machine and I've started Netcat listener. And here I'll go through the same sort of deal where I make a fix and apply it to Putty for an inject DLL and I specify PuttyWriter. And PuttyWriter will be injected from then on, no matter where you execute Putty from as long as you're executing it on this machine, it will inject PuttyWriter. It will connect back to my shell and show me everything which is awesome. And you can also configure PuttyWriter to execute a command upon connection. So, you know, if I were doing malicious things, I would just specify the command of put this key into your authorized key files under the .ssh folder so I can now get in or drop some connect back thing. There I'm specifying I don't want any of those things in case Putty came out with a new version. Although I guess they could change those send and receive function locations. So I'm going to fast forward it a bit because I don't have a whole lot of time. So there I am installing the shim from the command line then deleting the file. Now here I'm running Putty and PuttyWriter was automatically injected and made a connect back net cat listener on the right and here you can see I am legitimately just using Putty to log in and I can see all the key strokes that are coming across including the username and password which will happen in just like two seconds because the SSH service was being super slow. And there you have it. So I can watch everything they are doing, I can inject a command in there, fun stuff. The second example I'm going to show you here is where I'm going to use the correct file path fix to redirect a path. Now over on the right there's a network share that I've opened up it's like a machine called controller slash catch is the share name. So here I'm making a shim specifying Firefox. I highly encourage all of you to check this out and look at every single of these fixes documented and otherwise because there is a lot of fun to be had with these things. So normally with the correct file path fix with the correct file path fix it would fix some program that was hard coded to C colon slash documents and settings to C colon slash users and that was for like from Windows XP to Windows 7 programs apparently made that mistake and that's terrible but they did that. They had lots and lots of path redirects for that kind of thing and with that slash or dash B parameter I'm saying don't do that. Don't do anything except for what I'm specifying right here right now and I do that right here. I found the Firefox profile and then I give it a semi colon and then give it the new path which is slash slash controller slash and I remove all those parameters all the filters that it could trigger off of I'm going to fast forward this a little bit I'm saving the file and installing it deleting that the original SDB file and then I'm executing Firefox and here over on the right it's redirecting all of its stuff over across to my network share which is awesome. There's the keys key3.db which is where Firefox stores its password no prompting from Mozilla from Firefox that the profile was changed or corrupted or anything because it is being lied to by the operating system which is hilarious. Another example I mentioned subverting system integrity that's kind of a big thing for me at least because I really prefer stealth and misdirection when it comes to war games, red teaming all that fun stuff and here I'm demonstrating auto runs awesome fantastic tool by Marcus Ganovic Sysinternals where it will show you tons and tons of places where malware will really enjoy planting some code because that's how it can get automatically executed when either a user logs in or when the machine boots up I have several versions sorry I'm going to rewind this a bit because I just downloaded and compiled Dexter it's a POS malware and it's right there on the desktop POS.exe and I executed it and it deleted itself and I'm showing in this little video that I'll post on YouTube I'll post all my stuff online eventually and we can see with auto runs it's detecting that registry key has something really suspicious in it and you can even right click and go jump to value and it will pull up regedit and show the exact registry key that it found that was so weird so here I've made a shim which is awesome if I don't say so myself and here I'm redirecting the file pass the registry keys so that when it looks for that particular registry key which is a particularly common one which is the current version Microsoft Windows NT run registry key it redirects it to an empty registry key so auto runs all these versions will not detect my malware anymore furthermore I chose some other tools in there like process explorer proc dump and I just added the terminate exe fix so as soon as someone tries to execute any of those they'll just fail no way around that well I say that you can easily just change the name of the process or change the name of the file and it won't be shimmed anymore that's hilarious I can shim auto runs and even better I've also added a shim for regedit so registry the registry editor built into Microsoft will not detect my malware anymore it will not see that malware key now the latest version of auto runs does something a little different and so my default registry redirect shim doesn't really work on it so it will show up for the latest version but none of the prior versions so here let me back up just a little bit so for here it showed up in the latest version 13.4 and I said go to this registry key and it's not there for regedit which is hilarious okay so moving on to the malware which is my favorite thing because I really like malware I broke it down to three categories benign executables which we saw like putty where we can use a lot of fixes to make it malicious like inject DLL or load library redirect which is an awesome fix as well and we can also do hot patching where we could just hot patch in just overwrite the OEP and we can, the original entry point for the executable for those of you don't know or we could make our own ROP chain and use load there to build out some malicious stuff but that's a little tedious so the next category is I would say dependently malicious software or dependently malicious executable and there can be some kind of kill switch in your program and your malware that without a shim installed on the system it wouldn't be able to get around like there's an ignore exception fix or you can hot patch all the jump instructions of the program and redirect the program flow at run time to actually do your malicious deeds. Tons and tons of ways to do this there is just an infinite number of ways you can make something bad or from bad to worse and the last category was an obfuscated executable where it is clearly malicious but it will just fail to do anything without the shim. So an example of the dependently malicious software would be something like this where I have some shell code up there that I want to execute and I use just MSF venom to pull that out and I'm sorry for those of you who can't see I just got some metasploit shell code and here I have some assembly that was label jump to label and that produces the ebfe instruction which is an infinite loop it just jumps to itself over and over again so if you execute this program it will just jump to itself over and over again no way around that so there is a shim here that I made with stb explorer that will create a patch that just knocks out that ebfe instruction so when this malware is running on the intended victim system it will be malicious it will actually call the shell code if not the IR guy who dropped it in a sandbox will think that nothing is happening and this is how I make and install that stb file so I use John Erickson's stbexplored.exe slash c and have that config file and that's the output of the program I specify output.sdb and then I install it with stb ints you can also use John Erickson's stb explorer to install stealthily by just adding the registry keys and not using stb inst so just fyi here is something more obfuscated I have don't try to mess with this code because I shortened it to make it easier to read I have some shell code right below it I have the shell code key I made it the same length simple xor obfuscation where for byte for byte key to shell code it does an xor and then tries to execute the result and you might be thinking why not use a single byte key or multi byte key this is because I can make a shim that patches over this key with a value that I choose so I can decrypt this to literally anything I want I can say I want these bytes now to be some metasploit code or I now want these bytes to be something else so I can do that quite easily and I think that's quite exciting because when you have this kind of packer type stub in the shim you don't have your malicious payload on file or in the malware you don't have it in the shim but it will only be produced dynamically on the target system if you so choose so for those of you who just want straight up persistence here is the config for patching explore.exe for windows 7 64 bit windows 7 x86 and windows 8 and so sorry I have to run through this real fast the current prevention from this is a number of good tools but what can defenders do well you can disable shimming through group policy but that's not recommended because windows uses this stuff internally like I believe IE when you go into compatibility mode it's actually using a shim if there's a program named install.exe it's automatically elevated through shimming this is kind of important if you have install.exe it's automatically elevated in windows you can remove the shim engine the thing that's actually doing the patching that's not recommended either because like I said lots of other things use it like emit you can remove the STB installer that's a good start unless you are applying fix it patches to things but you can just bad guys can just use the manual entry method the manual install method and you can always just allow access to that box but that's probably never going to happen so the current tools out there I've already talked about most of them the public application compatibility tool kit and the manager and the installer STB on every windows computer STB Explorer by Don Erickson will make shims and explore them show you the database values all cool undocumented features in there shims.exe was made by a guy I think his name was like something like that I told him I was giving this talk and he was like oh that's cool that's awesome I was just like hey can I demo your tool he's just like yeah sure go for it can you send me a trial version he's like no you have to pay for it I was just like yeah or you can just let me demo it or screenshots he's like no you're going to have to pay for that whatever there's a Kim Cash shims are checked all the time because processes begin execution all the time this is a great you know they had to cash that information and that's a great place for forensic value that a program was executed so that explores some of that but none of these programs and nothing out there helps defend or prevent malicious shims so I made a number of tools I broke them into three categories where you can scan a file for you can scan something so you can determine if it will be shimmed or not it will just tell you yes this would have been shimmed and it will tell you the thing that would have been applied to it the fixes that would have been applied to it there's a shim process scanner which will scan every process in the OS I've only tried it for windows 764 bit but it seems to work it does that through checking the DLLs that are loaded into the process to see if any of those are the shim DLLs or app help DLLs and it checks the registry and it checks the PEB flags because they're undocumented flags in the process environmental block structure that says whether something is being shimmed and then I made just a really basic script to check for to see if the DLLs are any of the process spaces and shim guard I originally made this for the purpose of preventing shim from being installed but that was actually pretty hard to do because that I would have to like mess with the permissions and then when something tried to install to it and failed it would notify me and that got a little too complicated and then I just made a power shell script to alert as well and then I made two plugins for the response side of things Autopsy is an open source graphical forensic front end and it's really cool you can load a disk image or whatever else and you can search for things on it and I search for STP files and in the future I'll like start doing more stuff with it and I like whitelisted a bunch of hashes for known good STP files and Volatility is the open source memory live memory forensics framework and I made a plugin for that to search for STP files so just to wrap it up I like to have these quotes up there from Microsoft I give them a lot of crap but they've done an enormous amount of work and I appreciate them a lot but I love how the quotes say no shim is available to bypass the Windows 7 user account control except for the redirect EXE or the load library redirect it says no harmful code can be injected into the process except for load injectial L fix or custom fixes and it's like you're not opening any additional security vulnerabilities you cannot use shims to bypass security mechanisms in Windows except for the disable advanced RPC client hardening fix or the disable windows defender fix or the disable ALSR fix or the disable SEH fix or disable the NX bit fix there's a few others out there that are pretty hilarious I just want to note some prior work I'm sorry for the guy that was trying to take a picture of that I'll post it online I promise Alex Ianu is a great reverse engineer he started a blog series called Secrets to Application Compatibility Database but didn't finish it he stopped halfway through which is a shame because he never got to the really good stuff and then I found these guys they blogged about something a while back I wish I'd found their blog a lot sooner but I didn't Mark Baggett was one of the first ones I think to talk about this in a security context at Derbycon and John Ericsson talked about this last year of Black Hat Asia particularly about the hot patching the shim engine stuff special thanks to my peeps John Greg Wyatt and Patrick John for encouraging me, Greg for yelling at me Wyatt for helping me with the volatility plugin because the documentation is terrible and Patrick because I made a lot of my own functions to prevent hooking I saw my own string handling functions and he said it made him want to stab out his eyes and that was good insight for me other resources about this stuff I suggest checking out Raymond Chin's blog and I just wanted to say I apologize I am sorry the application compatibility I'm adding more load to this crap because I know so many people hate it and it's a pain to so many people I don't think we have time for questions at all out in the hall I can so I'll talk to you I'm a little hungry so I might like try to get some food while people are talking to me but there's my github and there's my twitter in case you realize I was cool and there's my email you can email me at that's it