Security Monitoring–Additional PowerShell Detections Addendum

This is a follow up article to this piece that I wrote in early September. Not surprisingly, there was some noise in my initial lab tests. Two rules in particular were noisy, and the chief culprit happened to be SCOM. The rule governing PowerShell running in memory only  as well as the rule to bypass execution policy. When you think about it, both make sense to some extent, and that’s part of the reason why these features are built in to PowerShell.

If SCOM could not bypass execution policy, for instance, none of its script based data sources could execute if users set their execution policies wrong. As such, I decided to do a minor rewrite of all of the rules to allow for two overridable path based exclusions as I suspect specific applications could generate some noise. I know that SCOM uses a lot of PowerShell scripts. I believe that Exchange does as well. This also allows someone to do an override for a specific object, a group, for for an entire class. I may revisit this to add more, but I that most of our applications keep these items in specific folders, so there shouldn’t need to be any changes there.  I’ll also use this data source for any PowerShell detection I write in the future that may need to be overridden.

I’ve also created similar rules targeted at Windows Event Collector servers. To me, this is probably a bigger thing. It shouldn’t be terribly noisy, as this type of behavior in the desktop environment strikes me as something that should be more rare, but perhaps I’m wrong. As such, there’s nothing overridable in that environment for now.

To override for a specific path, do the following:

  • Identify the rule and the type of override you wish to do (i.e. group, all objects, specific object, etc).
  • Configure the path based override as follows:


Security Monitoring–Using SCOM to Detect Legacy TLS Protocol Usage

This has been on my bucket list for a while now, and I finally got around to figuring it out. TLS is a transport layer protocol that is effectively a part of SSL. Basically, it’s used to encrypt web based traffic so that prying eyes cannot see. Like every protocol, over time its weaknesses are exposed and newer versions are released. Like every protocol, the older versions remain on given that legacy applications can break. Last year, Microsoft started releasing updates to their applications to eliminate TLS 1.0 and 1.1 from usage, and it’s officially recommended that these protocols be shut off with only TLS 1.2 being used.

I spent some time trying to figure out how to audit legacy TLS usage and found that to be an incredibly frustrating search. There’s not much out there on auditing TLS. The answer, as it usually is, was right in front of me from a Kevin Holman article on how to force SCOM to use TLS 1.2. As such, I’ve setup a collection rule to collect these events. That said, this is not plug and play. Before I get into the details, it’s worth noting that event collection rules can generate lots of data in your DataWarehouse. In my own lab, I’m seeing about 600 events a day across 2 systems. So just imagine for a second what that might look like with thousands of systems. You may want to consider turning this on in small quantities (and turning it off once you have the data you need).

Step 1 – Enable Schannel Logging. Kevin covered the details of how to do this in his post. I simply created a GPO and linked it at the domain, though you may want to link to specific OUs instead. In my case, I set a GPO preference to change the following registry key: HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging

This is a REG_DWORD value that needs to be set to 7.

Step 2 – wait a day and run the report. It should look like this:


Security Monitoring–Additional PowerShell Detections

Note that there is an addendum to this piece for override purposes. That can be found here.

A colleague of mine turned me on to this particular article on ways to use PowerShell to bypass execution policies. It’s worth noting that PowerShell is a powerful tool that was designed to give a lot of flexibility to IT professionals and developers. That said, this type of a tool can also be leveraged by the bad guys. As such, it makes sense to target certain types of behaviors that are not very common under normal circumstance, but can see elevated usages by threat actors when they are moving through your environments. I’ve added four rules to the next version of Security Monitoring to alert on suspicious behavior. Three are (at least after initial rounds of testing) on by default. The fourth is off and if noise is a problem, will likely need to remain off.  I would also note that I wouldn’t be surprised if more of these ends up being turned off. PowerShell is used on the back end by a number of applications, and as such, I wouldn’t be surprised to see some of this being done as normal behavior or via design in heavily scripted environment. In that case, you may need to turn these off altogether or simply override for particular machines. This can, however, provide a nice defense in depth posture. It will also help the IA folks reviewing these alerts see what is actually going on in production and decide if these practices should be rethought.

First, as goes without saying, you need Process creation auditing turned on as well as the GPO setting to include command line parameters in audit events set. If you’re already following me or using this solution, you’ve probably already done this. For record, I do keep a public version of the GPOs I’m using here. These are simply auditing GPOs applied at the domain level. But it’s worth emphasizing that a lot of the detection that has been built into this tool requires this auditing to be turned on.

Rule 1: PowerShell script run natively to bypass existing execution policy

In this particular rule, we’re looking for PowerShell scripts being run with a specific execution policy switch. This allows scripts to run regardless of execution policy settings.  This can be by design in a user environment, so simply seeing this doesn’t mean that much. That said, I’m tracking 4688 events that are generated by ‘powershell.exe’ with the –ExecutionPolicy switch set to either bypass or unrestricted. This is also something that could generate noise. SCOM is an offender here, and it’s default install path is excluded for noise reduction purposes.

Rule 2: PowerShell used to Invoke a Remote Expression

I would hope that this is not used with much frequency in a typical environment. Effectively, PowerShell can be leveraged to run remote code. Threat actors love this, as they can effectively use their scripts to connect to an http/https share they have online and execute their custom malware. The best part is they can run this in memory only, making it even harder for AV scanners to detect them. Again, we are looking for 4688 events generated by PowerShell. I’m looking for the “Downloadstring” method and an http or https pattern in the command line.  I wouldn’t expect to see this one happen often, so for now, it’s on.

Rule 3: PowerShell used to Invoke an Encoded Command

This is another one that I wouldn’t expect to see run that frequently. Basically, you can convert any text to a base 64 encoded string. This again can be normal, as it gets around formatting issues that can plague script writers or people like me who aren’t PowerShell experts. With that said, however, the bad guys can use this to hide what they are doing from security software, AV, or security analysts. As such, this rule will generate an alert whenever PowerShell is run with the –ENC or –EncodedCommand switches. Like the remote expression rule above, I don’t see this as something that will happen a lot, but it’s possible that this is legitimate.

Rule 4:  PowerShell Running Only in Memory

Simply put, this is a PowerShell script runs in memory instead of on disk. It’s run using the –NoProfile or –Nop switches. I suspect that this is something that could generate noise. In testing, SCOM was a big one here, which makes sense as MPs run PowerShell scripts. I would not be surprised if other applications such as Exchange generate noise here too.

As always, if you want to test this, reach out to me on Linked In.

Security Monitoring–Configuring SCOM to alert on attempts to kill Windows Defender

This is just a quick update to the next revision of Security Monitoring. If you don’t use Windows Defender, this will not generate any alerts, and in general it should be quiet even if you do use Window Defender.  This will only work if you have the audit process creation GPO set. I’d also note, that you need to have command line auditing turned on as well. I’ve referenced that in other places, but here’s a screenshot if you’re unsure:


If these are set, there is now a new rule that will look for 4688 events with various kill switches meant to stop that process. This alert will also be available if you’re using Windows Event Collectors.


Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 2

You can find part 1 here. You can find part 3 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.

Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 1

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.

Part 2 can be found here.

Part 3 can be found here.