Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 2
Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
You can find part 1 here.
***Please Read This First***
I need to preface this article by simply saying that this is the type of thing that needs to be thought through before simply turning on. This is mainly due to the fact that this next security monitoring solution could potentially create A LOT of objects in SCOM. I did have a brief chat with Kevin Holman about this to confirm my own concerns before publishing. It’s worth noting that a large number of objects isn’t necessarily a bad thing if there are no monitors attached. There are not in this case, but as a side note that also implies that we should not be targeting the classes this MP creates with monitors. That would be bad. Likewise, larger environments should be careful when rolling something like this out. The solution (in my lab) created about 20 objects per server. In a small environment of a couple hundred servers, this isn’t a big deal, but if you’re monitoring 5000 servers, you just created a hundred thousand objects. More objects can equate to performance issues as well as database bloat. Again, there are no monitors targeted at the class created, so performance impact should be minimal. That said, test this carefully in a big environment or roll it out selectively to critical assets.
***Thank you***
Now on to the solution. We discussed previously the issue that the problem with monitoring critical OS writeable directories is that they can be different for just about every OS. Fortunately, someone smarter than me already did most of the work. What I’ve basically done is to borrow a portion of Aaron Margosis’ “AaronLocker” solution for AppLocker and repurpose it as a SCOM discovery. Simply put, I’ve updated Security Monitoring to discover these file locations. To be clear, I do think that App Locker is the right answer here, though it can be bypassed (we have some detection for that), and it does take a bit of effort to get setup. But in terms of actually locking down these directories, this is the right answer. That said, this is not a solution that is on by default. You’ll need to do some configuration in SCOM as well as deploy a sysinternals tool to servers that you want to use.
Step 1 – Download AccessChk.exe and deploy it to the servers you want to monitor. For the record, I only tested copying this to the Windows\System32 directory, though I suspect it will work in any directory that has an environment variable configured.
Step 2 – You will need to turn this discovery on. I’ve made this fairly easy to do. I’ve written in a registry discovery that is on by default. It looks for a specific registry key HKLM\Software\SCOMSecurityMonitoringMP\DiscoverUserWriteableLocations. Once this key is created, a seed class will be discovered which will kick off this script. The registry discovery runs somewhat frequently, but the script based discovery is set to run once a day. I’ve made this fairly easy to do. Simply go to the “Windows Computer” view and use the Security Monitoring tasks to create the key:
The registry is protected, so I suspect you’ll need to enter credentials to create these keys. Alternatively, you could use a tool like SCCM or a GPO to do this. This is what you’ll see:
Note that if you use the Remove task, it will trigger an undiscover and effectively remove the new objects.
Step 3 - At this point, you’re largely done. I’ve set the script to use the %windir%, %ProgramFiles%, and %ProgramFiles% (x86) short cuts. This means that for a standard OS with one drive, you’re done. That said, some organizations carve out multiple disks, and as such, these short cuts don’t catch everything. I’ve built in a solution to the discovery to address this. You’ll need to locate the “Security Monitoring: Discover Writeable File Locations” discovery.
From here, you need to do an override. There’s a box called “AdditionalLocations” that can be passed into Aaron’s script. This is a comma delimited list. All I did was create an array and enter the contents with a split by a comma. I do recommend putting quotes around your path (i.e. ‘D:\program files’,’D:\Program Files(x86)’).
Now you are done. Your results should look something like this:
In order to minimize noise, I’ve done a couple other things. The rule described in part 1 of this article is disabled for all members of the seed class you defined. In place, a new rule is turned on. It’s a bit more simple, looking for the 4688 event ID, .exe in param 6, and requiring a match with the FolderPath class in parameter 6. It will look something like this:
A couple notes. I’ve built some alert suppression into both of these alerts. This will filter by the logging computer. This should prevent alert spam. You’ll only get a high repeat count in this scenario. For the rule in this part, you can override for specific objects, so if you have an app that executes in C:\windows\temp (this is bad practice by the way), you can override the specific object on the specific machine.
I’m also adding the rule described in part 1 to the forwarded events detection. If you’re forwarding 4688 events to a Windows Event Collector server, it will generate an alert.