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:

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:

]]> https://docs.microsoft.com/archive/blogs/nathangau/security-monitoring-additional-powershell-detections Fri, 07 Sep 2018 16:02:27 GMT https://blogs.technet.microsoft.com/nathangau/?p=2205 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.

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.

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.

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.

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.

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.

Part 2 can be found here.

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.

One piece of feedback that I’ve seen in regards to security monitoring is noise due to services created on a domain controller. In general, this should not be a common event, but occasionally legitimate applications do create services on a domain controller. As such, I’ve done a minor rewrite of this rule to allow for an override for up to 5 services.

There’s a couple things worth noting.

First, this does not replace the rule that runs on all systems that generates alerts for known threats such as wince or psexec. Yes, both of those tools have legitimate uses, and if you’re using them in your organization, then I do recommend turning off that rule.

That said, there’s a second rule targeted only to Windows Domain controllers which will alert any time a service is created on a DC. Again, this is typically not common in an environment, but if you’re an exception to this, read on.

All you need to do is create an override:

That’s pretty straight forward. It’s worth noting that this is using a contains operator against parameter 2 of the event. There’s not much to this particular parameter, but if you’re troubleshooting and having issues, you’ll want to verify the value in the 7045 event that is created. It must match.

These updates will be in the next Security Monitoring MP. If you wish to test these, hit me up on linked in.

One piece of feedback I’ve gotten is that monitoring the creation of scheduled tasks as well as service creation on domain controllers can get a bit noisy due to typical business activities. While these particular activities don’t happen terribly often, it’s possible to have applications that create scheduled tasks or services as needed. As such, both of these generate alerts that are ultimately ignored.

This forced a minor rewrite of both of these rules. Basically, I’ve written in code that allows you to override the rule and specify a particular exception.

Task Scheduler:

I had to go with a security event instead of using the Task Scheduler Operations log. The reason for it is that the Task Scheduler log only mentions what is created. It doesn’t say the program running. As such, you’ll need to do a couple things to get this working properly.

Step 1: Enable auditing of Object Access. This is an advanced policy, but you’ll need to turn on other audit object access events:

You’ll need to do this as the old rule isn’t going to work now.

Step 2: Do your override. That’s straight forward. You can target this against the entire class or a specific object. I’ve created 5 Applications that can be excluded (App1-5 on the screenshot below). This should allow plenty of flexibility.

At this point, save and you’re done. There is a bit of a catch here, and I have to emphasize this.  You need to be as specific as possible. All of the data for this scheduled task is lumped into parameter 6. As you can see from the screenshot below, there’s a lot of text in that parameter. The application running (in my case cmd.exe) is only a small portion of the parameter. I would recommend making sure you put the full path to the application you need to exclude if at all possible.

That’s the task scheduler. I’ll include this rule in the next update of this management pack. If there is interest in using this, hit me up on linked in.

You can find Part 1 here.

You can find Part 2 here.

In summary, we went over various security concerns deploying SCOM. Although there are a bunch listed, there are two that I believe could take down an organization in a hurry: poor run as account distribution or a SCOM admin’s account being compromised. The run as account distribution could allow for quick lateral movement through Tier 1 as well as possibly exposing all of your data to the attacker (depending on the permissions of said run as account). A SCOM admin being exposed could allow for someone to use SCOM as a deployment mechanism to compromise your environment. These are both big deals in my opinion, and when it comes to designing for security, this is the concept that you need to design around.

As such, I think there’s some wisdom in treating this application as though it’s a Tier 0 asset. It should be protected carefully. If you wanted to strictly follow Microsoft’s model, you may end up putting separate management groups in Tier 0, Tier 1 (and possibly multiple management groups here), Red Forest, etc. While I suspect that there will be some in the cyber community that disagree with me (and if so, I would appreciate the feedback), I personally am not sure that this worth the effort. For one, it massively over-complicates administration, as you’re managing multiple SCOM environments. You have to have multiple lines of accountability for SCOM alerts. You now alerts coming from multiple management groups, and will have to tune across multiple management groups as well. You will now deal with multiple sets of reports as well as multiple sets of notifications.  You also haven’t really mitigated any risk to your Tier 1 environment in particular, and that is where all your data is stored. In the cyber community, we stress Tier 0 protection, and that’s good as compromising Tier 0 is by far the easiest way for an attacker to own your environment, but Tier 1 protection is just as critical, as that is where your assets are contained. Remember that in SCOM architecture, the agents should be running as local system, so on their own, they don’t pose a threat no matter where SCOM is located. It’s how you distribute your run as accounts and how you allow Operations Manager to be managed.

With that in mind, my ideal architecture would be to place my  management group in the Red Forest. To back track a bit, a red forest is an untrusted domain. If you implement a RF, you will use IPSEC to prevent management of your resources through any other way. That means no more RDP to a server from your standard desktop. You will use a privilege access workstation (PAW) that is joined to the red forest, as IPSEC will prevent you from accessing your server environment in any other way. The RF has no internet access or email, so it’s not prone to being infected by malware, and since it’s not trusted, it’s much harder to laterally move into it (though side note, if you’re using the same passwords in RF as you are in prod, then you do effectively have the same hash, which could in theory be compromised).

This does present some challenges. For one, to manage the production environment, you’ll need to setup gateways in production and configure certificate authentication between the management group and the gateways. This isn’t terribly difficult to do, but it can introduce a few points of failure, namely agent and gateway failover, as these do not occur automatically. Jimmy Harper wrote a nice piece on how to do this, and since (as I understand it) the commands are the same in 2016 as they are in 2012, I’ll simply link it here.  Since agent deployment is not a static thing, you’ll likely need to run the agent failover PowerShell as a scheduled task on the management server on a periodic basis, and add the gateway failover scripts as a part of any new gateway deployment. At least in this scenario, you’re only managing one management group, and you’ve mitigated the risks associated with SCOM administration. Second, you are still at risk to run as account distribution issues. I recommended in part 2 of this series that these be audited. This isn’t hard to do from the admin console. The bottom line is that this is something that needs to be performed with some frequency, as a poorly distributed run as account can lead to a very quick compromise. Third, this may present issues depending on how you created your RF. I’m definitely approaching it as more of a management network for the entire domain. If you have an RF that is for DA credentials only, then this really isn’t the best option, and you’re going to need to put it in your Tier 1 management network. That type of network will be joined to the production domain, so care will need to be taken to protect it against credential theft.

Legacy Protocols and Operating Systems

This is last thing that comes to mind in architecture for a secure SCOM environment. It goes without saying that leaving on legacy protocols potentially exposes yourself to all sorts of attacks. I think at this point, we are all familiar with the consequences to leaving SMB1 enabled. Though the exact cost to IT organizations remains unknown, the estimates range from hundreds of millions to around $4B for WannaCry alone, much of which could have been prevented if organizations had moved away from Windows XP well before the 2017 attack was launched.

That sadly, is not the only legacy protocol out there. Other protocols include NTLM V1, LANMAN, Digest Authentication, and older versions of TLS. All of these are, at this point, on official deprecation lists from Microsoft. Turning them off certainly presents risks to older applications, so there’s some value in eliminating older apps, or at the very least restricting where these protocols can be used.

SCOM, for the record, does not require any of these protocols, so I highly recommend removing these, as well as deprecating older Operating systems such as Server 2008/2012.

It is worth noting that there are issues with the SCOM installer and legacy protocols. I’m hoping that Microsoft does fix this at some point, as I know this has been reported to the product team, but there are some known issues with certain legacy protocols and the SCOM installer. In that case, you may need to turn them on only for the purpose of deployment.

• RC4, documented on my blog.
• TLS – I haven’t observed this, but have been told that the installer can have issues if older versions of TLS are not turned on. This does make sense as TLS 1.3 support was added in a recent SCOM 2016 UR.
• NTLM V1 – Again, I haven’t observed this, but I do know there is an active investigation regarding the SCOM reporting piece requiring NTLM V1 for install.