Security Monitoring: Using SCOM to Detect Bypassed Authentication Package Back Door

One persistence method that an attacker can use is to modify an Operating System’s authentication packages in order to give the attacker a back door for entry into a system as desired. Auditing this behavior in SCOM turned out to be a bit trickier than I would have liked.

The key in question is HKLM\System\CurrentControlSet\Control\LSA\Authentication Packages. As it turns out, Authentication Packages is a multi-string registry key, which is something that SCOM’s native registry provider cannot read by default. As such, a simple registry monitor will not work, making this a lot more complicated.

To solve the problem, I had to create a custom composite monitor type (note: special thanks to Brad Watts for helping me complete this). I’ll spare you the XML on that and simply note that if you’re interested, reach out to me and I’ll get you a copy. At the heart of the XML is the following PowerShell Property Bag script:

$api = New-Object -comObject ‘MOM.ScriptAPI’
$bag = $api.CreatePropertyBag()
$AuthPkgs = @(Get-ItemProperty -Path $key -Name $attribute | select -ExpandProperty $attribute)
$AuthPkg = $AuthPkgs[0] + $AuthPkgs[1] + $AuthPkgs[2] + $AuthPkgs[3]
if($AuthPkg -ne $null) {

The script is fairly straight forward, you pass the key and attribute as parameters. It reads them individually and then concatenates the first four entries. It’s clunky, but that allows you to read and monitor a multi line registry key. Any changes to it based on the configured value (in our case, there’s only one msv1_0) will generate an alert. The value is able to be overridden as well, just in case there is a need.

Security Monitoring: Detecting Wdigest Authentication

One of the noisier items in the Security Monitoring Management Pack is the monitor that triggers against all Windows 2008 R2 and below systems if the proper WDigest post patch configurations have not been applied. WDigest is another older protocol that was addressed with KB 2871997. Prior to 2008R2, Wdigest credentials remained in the LSA of the Operating System in an unencrypted state, allowing a tool such as Mimikatz to enumerate the password of all logged on accounts in clear text. While KB2871997 allowed for a fix in the vulnerability, this still required setting a registry key in order to turn off WDigest.

The main reason for this is the risk of what would break if this authentication mechanism was disabled. As with many legacy protocols, legacy applications that have not been updated are vulnerable, as such, this protocol remains on by default. Ultimately, this poses a significant risk to the organization. If they leave it on, they are at risk to an attacker. If it’s shut off, they could potentially break a critical application.

Fortunately, this is a traceable event. Kurt Falde lists the details here.

As such, the security monitoring MP will now have a collection rule looking for WDigest events. This will not work out of the box, however.

Step 1:  Enable the “Audit Credential Validation” advanced audit policy. In this case, look for successes.

Step 2: Create a collection rule targeted at Domain Controllers looking for event 4776 in the security log. Parameter 1 must also contain WDigest.

I would note that the next release of the security monitoring MP (currently slated for early 2018) will have the rule setup for Step 2 along with a pre-canned report. Once that is out, only Step 1 will be needed.

Feel free to add comments or reach out to me on LinkedIn, especially if you are interested in evaluating the next release.

Security Monitoring: Using SCOM to Detect SMB1 Authentications

I think at this point, we are all aware of the dangers posed by continuing SMB1 authentication in an environment. The virus wannacry infected more than 400,000 machines and caused a number of outages across many organizations.

Detecting SMB1 is unfortunately not quite as easy as some protocols. A colleague of mine, Leanne Livingstone, provided me with a simple PowerShell script that can be run to see active SMB connections on any server.

Get-SmbSession | Select Dialect,ClientComputerName,ClientUserName | ? Dialect -lt 2

We initially experimented with an alert generating rule for this; however, that generates a lot of noise. As such, this has been moved to a report.

Brad Watts created a simple collection rule using this script and the report. It will list both the user(s) and machine(s) doing SMB1 authentication so that administrators can determine which systems in their environment need to be adjusted.

Security Monitoring: Using SCOM to detect NTLMv1 and LanManager Authentication Types

One of the big changes in the next release of the Security Monitoring management pack will be reports designed to let administrators if they are using older protocols in their environments. It goes without saying that many older protocols are often full of vulnerabilities. As well, they tend to be on by default due to concerns about what might break should they be shut off.

Recently, a colleague of mine wrote a nice article in regards to these protocols. This post will concentrate a bit more on the auditing aspect of the article. What we have done in the security monitoring MP is to create two collection rules targeting authentication on domain controllers. These will look for the following conditions:


  • Event ID = 4625
  • Parameter 11 (Authentication Package) = NTLM
  • Parameter 15 = NTLMv1 (note that the friendly view name differs from the name in the event description. The friendly view name is LMPackageName.)


  • Event ID = 4625
  • Parameter 11 (Authentication Package) = NTLM
  • Parameter 15 = LM (note that the friendly view name differs from the name in the event description. The friendly view name is LMPackageName.)

The reports will tell us where this access is taking place along with which accounts are using it. This should give administrators a better picture to the types of activities going on in their environments.

Feel free to add comments or reach out to me on LinkedIn.