Partager via

Using SCOM to Capture Registering Remotely Located DLL Files

  • Article

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’ve started browsing some sites that are cataloguing known attack vectors and came across this particular vulnerability that is worth discussing.  Many seasoned IT pros understand the use of RegSvr32 to register DLL files.  This executable is very integral to Windows as registers DLLs for OS and application use.  A little known flaw is that it can be used to load DLL files that are not contained on the server itself, thus bypassing antivirus detection. We’ve already built one rule set based off this flaw for a known attack method which is documented here. In this particular case, we are looking for a method to bypass AppLocker.  The attacker loads a DL file called scrobj.dll from a remote location.  While this is beneficial in detecting a known attack, this attack method can easily be altered as names of DLL files can be changed on recompile.

That said, the method is not quite as easy to adjust.  The attacker must use a URL allowing us to create a rule set in SCOM to audit process creation looking for that specific in formation.  The criterion is fairly straight forward:

  • Event ID = 4688
  • Parameter 9 contains either of these strings:
    • /s /n /u /i:https://
    • /s /n /u /i:https://

For the purpose of this rule, I’m not continuing to filter by regsvr32.  That keeps me out of playing around with case sensitivity when matching a pattern.  The switches and URL call should match.

A more thorough explanation of what is going on with this method of attack can be found at this location.

I would note that while Antivirus cannot catch this method, EMET is a mitigation for it.  If EMET is not configured for your environment though, this rule set targeted towards Windows Servers and EventCollectors should work if you have them enabled.

With that said, I’m testing this in my lab presently and plan on including it in the next release of the Security Monitoring Management Pack. I’m not expecting much in terms of noise, but if by chance you have a legitimate application that is using this method, you can use choose to add a Parameter 9 ‘does not contain’ <insert name of DLL here> to the and portion of this rule.  That will eliminate any noise associated with known applications.

Comments