Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 1
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.
I had the privilege of attending Microsoft Ready this last July. That allowed for some very useful networking. In this case, I got to speak a bit with some security professionals who do forensic investigations after a compromise. One common attack vector is something seen once the attacker has gained access to a machine. They will usually drop some sort of malware/executable files in specific directories within Windows that anyone can write to. This can be especially beneficial to them when they haven’t yet elevated themselves to local admin rights. They do this because there are directories within the Windows OS that non-admins are allowed to write to. Typically this is to store configuration information or provide writeable locations for temporary files/tasks. That said, an attacker can exploit these locations to run executables, which is something that (at least in my lab) doesn’t happen under normal circumstances.
Interestingly enough, this is actually pretty easy to track at a basic level.
Step 1 – Turn on Process Creation Tracking. If you’ve already been using SCOM to do security monitoring, you would have likely already done this, but just in case you haven’t, this is an advanced audit policy. It will generate 4688 events (and a lot of them) in your security logs.
Step 2 – create a rule that looks for event ID 4688 as well as “.exe” in parameter 6. On top of that, you’ll need to next an Or group to look at the common locations that users can write to within the windows directory:
As you can see, I kept the parameters generic so that I’m not dependent on the drive location. This was pretty easy. If you setup a rule like this, you can drop an executable (say MPViewer) in the c:\windows\temp directory and launch it. It will generate an alert every time.
There is a downside to this. For one, the screen shot above only contains the basic writeable locations. The reality is that every time you add a feature or install something, it’s possible that you create additional locations that need to be tracked. This rule won’t do that, and it’s impossible to know every single one. The other problem is that the same conditions should be monitored for the Program Files and Program Files (x86) directories. Those will vary by application, so again, it’s not something that someone can easily track since they won’t know all the possible combinations. I’ll address that scenario in the next part.
This will be included in the next revision of the Security Monitoring Management Pack. It will contain both the part 1 and part 2 piece. If this is something you’d be interested in testing, please reach out to me on linked in.
Comments
- Anonymous
September 05, 2018
it would be nice to have a dynamic rule, which use for input, output of AccessChk, run on some schedule- Anonymous
September 06, 2018
funny you should say that... That's exactly what I'm covering in part 2. Stay tuned.
- Anonymous