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

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 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:

Param($key,$attribute)$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) {     $bag.addvalue('AuthPkg',$AuthPkg)}$bag

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.