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:


$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.

Comments (5)
  1. Rajkumar Anbazhagan says:

    Good work….may i know how to get this XML to test in my SCOM infra?

    1. Nathan Gau says:

      Hit me up on my linked in profile. I’ll be more than happy to send you a copy of the latest version. All I ask for is feedback.

  2. odmig says:

    Great work!!

  3. Hi Nathan
    my question is kind of OT, but I’ll try it anyway.
    One of my customers is implementing a Microsoft Tier Modell (ESAE) in order to secure AD. I am resposible for SCOM and I am looking for the best way to place our Management Group into the Modell.
    Is it better to put the Management Group incl. the DB into tier 0 and monitor from there tier 0 and tier 1? Or is it better to install a dedicated Management Group for tier 0 and one for tier 1?

    Thanks in advance for you opinion.


    1. Nathan Gau says:

      I’m actually putting a series together on that right now. I apologize for not seeing this as apparently our system thought your comment was spam. The next part will cover most of your questions I think. I hope to have that up no later than next week. The cliffs notes is that I’m going to recommend putting SCOM in the Red Forest and using gateways, but I’ll throw a couple different options out there.

Comments are closed.

Skip to main content