Using SCOM to Detect Overpass the Hash Attacks

An overpass the hash attack is another flavor of a pass the hash type attack except that the attacker is passing a key instead of an NTLM hash.  As such, it is technically a kerberos based attack.  This type of attack is useful once an environment is already compromised as the key needed for the attack is obtained from a domain controller.  If the attacker has already compromised your domain controller, they have a number of options at their disposal, including things like a forged golden or silver kerberos tickets (I hope to cover that at some other time).  Once an attacker has your key, they can essentially impersonate you from any system, whether or not your password hash is exposed on the system in question.  As I learned in working on this article, detecting this type of attack is not easy.  Step one was to mine my key from a domain controller:


You can see from my output that with the right access, this is relatively easy to tease out. In this particular case, I’m looking at my AES256 key, though other keys can work here too. Unfortunately, I haven’t been able to spot any worthwhile breadcrumbs at this point.  I’ve discussed this a bit with some of our internal security experts, and unfortunately, there does not appear to be an easy way to tease a lot of this out of my logs.

Now that said, I’ve obtained a key. The next step is essentially to perform a pass the hash attack injecting they key into the PTH instead of an NTLM hash.  Mimikatz has this feature built into it, and I found that it works quite easily in my lab.


I should note that in this scenario, I’m signed on to a member server that does not have an unwitting domain admin signed on to it. Running this launches a shell under the credentials of the domain admin account that I mined from the DC.  However of note, that does generate a useful breadcrumb.  It doesn’t note the account being impersonated, but it does note the user account doing the impersonation:


The target username in this case is the account that is signed on to the server, not the one that is stolen, but this event is clearly generated by my activity. I’d further note that the credential swap rule I created in my initial pass the hash article catches this one already, so I don’t need to create a new rule, but for the record, I’ll repost the screenshot.


Using SCOM to Detect WDigest Enumeration

In a recent conversation with fellow colleague Jessica Payne, it was noted that one of the most common forms of credential theft presently involves using exposed Wdigest credentials.  Wdigest, while not commonly used today, is still enabled by default in large part because of legacy applications that use it. While this was fine back in the 2000/2003 days, it is one of many protocols that is often tied to legacy applications and is no longer a secure protocol by today’s standards.

Exposing WDigest credentials is rather easy.  Kurt Falde wrote a nice article showing how simple this attack can be; and in my own lab, I observed the same behavior. Older operating systems will show clear text passwords.  If you can expose a clear text password, there’s no need to do PtH, PtT, or really any other attack. Fixing this involves a hotfix (KB2871997) along with a registry key.  The value “UseLogonCredential” must be created and set to 0 in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest key. This effectively turns off the ability to expose WDigest credentials in clear text, but doing so can also break legacy applications. It goes without saying that before you do this, you should probably test it and ideally fix any older applications.

Now that said, this is where SCOM comes in.  Because of the nature of this type of authentication, that registry key is very important. Fortunately, registry monitoring is something that SCOM can do natively.  An attacker could potentially change the value of this key or delete it all together. As such, two SCOM monitors are needed.  The first would be to monitor for the existence of said key.  Kevin Holman detailed how to do that here.  If the registry key is not present, your server will show unhealthy.

The second would be to monitor the value of the same registry key.  Again, Kevin has shown us how to do that.  An attacker could potentially change the value of said key to allow them to expose WDigest credentials.

As for logging it, unfortunately, I wasn’t able to find any sort of bread crumb left behind when testing.  That unfortunately means that we cannot use SCOM to detect WDigest enumeration when it occurs. We can however, use a GPO to set these keys and have SCOM monitor them for changes.

I’m working on a management pack that contains these monitors along with additional security rules along with other security related items that SCOM can provide. My only test environment is my lab, which is hardly a production grade environment. I do welcome feedback. While I cannot support this management pack, I can provide it if this is something you are interested in trying it out. My main goal is to keep the noise down to a minimum so that each alert is actionable. While that is not always easy to do, trying this out in other environments will go along way to getting it to that point.  If this is something you are interested in testing, please hit me up on linked in.

Using SCOM to Detect Pass the Ticket Attacks

Last month, I wrote a two part series on using SCOM to detect pass the hash attacks. I’ve decided to take some time and focus on pass the ticket attacks. There isn’t a whole lot different between the two attack methods.  Both require administrative rights on the machine (and let’s face it, that is easy to get for an attacker), and both essentially mine the LSA for authentication information.  The main difference between the two is that PtH is stealing NTLM hashes and using them to authenticate. PtT is stealing kerberos tickets, and these can eventually be used to forge your own KDC, thus making you an admin forever. It is well known that Kerberos is more secure than NTLM; the main reason behind this is that the tickets expire every few hours.  The default is 10 hours, but that is configurable via GPO.  Passwords, on the other hand, have a much longer expiration period, and as such, attackers much prefer mining passwords either via PtH attacks or Wdigest enumeration.  That said, an attacker can still enumerate and use kerberos tickets once they have obtained access to your system.  In this experiment, my unwitting domain administrator is logged on to a machine doing work while an attacker sits silently by in another session.  From the attacker’s administrative session, I simply use the mimikatz feature to enumerate and export all tickets.  It wasn’t hard to find domain admin, see below:


Mimikatz was even kind enough to save those tickets, just in case I needed them, along with every other ticket in use by the system.  You can see below the four tickets that my administrator is currently using.


Now that the attacker has your tickets, he or she can move them to another machine and inject them into a session or simply inject the ticket into his or her current session.   That’s not very hard to do:


Last but not least, we simply access what we want to get.  In this case, I opened explorer and connected to the C$ share of a server that I didn’t have access.  I unfortunately did not find any kind of log information on the machine which I was using to transfer credentials.  I did however, find this little nugget on the machine I accessed.


The good news is that this is the same event that I discovered when performing a pass the hash attack.  My SCOM monitor for pass the hash is in place and this flagged immediately. The bad news is the credential swap rule that I configured originally was not generated. That particular rule has been very reliable in that it has only flagged when I used mimikatz to elevate credentials in my environment. It doesn’t seem to work with pass the ticket.  My next attempt was to do the same on a domain controller. Again, I had no problems, as I generated the exact same event on the DC.  Now note that I had to turn this particular rule off for DCs as this is somewhat normal behavior and was generating too much noise in my environment.  What is a bit less normal, however is the IP address.  In my lab, I don’t have segmented VLANs that you find in most production environments, as such, I cannot filter a rule by IP addresses.  This will require some unique customization to your specific environment, but in terms of generating a red flag as to a possible intruder, I think it is well worth it.


The key here is parameter 19.  Instead of defining this as the IP address does not equal the IP address of the domain controller, you could create a “does not match wildcard” condition.  The # sign represents any digit, and if you say have a server VLAN of 192.168.3.x, you could represent this as 192.168.3.###.  Now I’d note that your event logs do drop off the leading zeros, so you may have to use an or group and create additional conditions to get it working properly.  That said, with this condition, I’ve excluded the VLAN that this server resides on. If my attacker connects from a different network segment (which they usually will as they do not have control over where the victim system resides), you could potentially create some additional rules targeting access from specific IP addresses.

One final note, I’m working on a management pack that contains these rules along with additional security rules along with other security related items that SCOM can provide. My only test environment is my lab, which is hardly a production grade environment. I do welcome feedback. While I cannot support this management pack, I can provide it if this is something you are interested in trying it out. My main goal is to keep the noise down to a minimum so that each alert is actionable. While that is not always easy to do, trying this out in other environments will go along way to getting it to that point.  If this is something you are interested in testing, please hit me up on linked in.

SCOM 2012 and 2016 WebConsole and FIPS Compatibility

In order to configure SCOM for FIPS, you will need to download some items. This link contains everything you need for this process.

As a quick overview, FIPS stands for Federal Information Processing Standards and it’s a set of algorithms that has to do with encryption of data at rest and data in transit.  FIPS is not turned on by default as many applications are not FIPS compliant out of the box.  You see this in use more in high security environments.  Like many applications, SCOM is not FIPS compliant by default.  Changes need to be made in order for it to be compliant.  There’s a KB article on this subject published here.  This article changed at some point and it’s currently inaccurate in a few places and somewhat misleading.  I’ve placed a request to get it updated, but to date it has not been updated.  Updating for FIPS is a somewhat cumbersome process, so I’ll walk through the step by step in this blog.

First off, let’s determine if FIPS is enabled.  That’s easy enough to do.  Open the registry and navigate to the following key:


The “Enabled” DWORD value will be set to 1.  This is often set via GPO in secure environments, so simply changing this will be reverted. 


Turn on FIPS and reboot your system, and your webconsole will look something like this:


I would note that on some internal cases, there can be an internal server error listed here instead.

Now to the fix:  WARNING:   Backup all files you touch in this section before proceeding.

Step 1:  The first thing you need to do is to get a DLL file off of the SCOM CD. IMPORTANT NOTE:  This file is found only on the SCOM 2012 RTM or SCOM 2012 with SP1 CD.  It is not on the SCOM 2012 R2 CD.  They are located in the \SupportTools\AMD64 folder of the CD.  Copy the Microsoft.EnterpriseManagement.Cryptography.dll file to C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server.  (note, this is your SCOM installation directory.  This is the default location, but that can vary based on your setup).

Also download a copy of gacutil.exe.  This isn’t easily found.  It’s a part of the SDK kit for Windows as well as some of the .NET development tools.  It is not in the SCOM CD.  I’d make it available for download, but that doesn’t seem to be an option for this source.   The SDK kit is free, and can be found here.  It’s a rather large download, so be patient.  For the purposes of this step, place gacutil.exe on your desktop.

Step 2:  Next, we will open up a command prompt in administrative mode and then type the following:

cd desktop and press ENTER

gacutil.exe /i “C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Microsoft.EnterpriseManagement.Cryptography.dll” and press ENTER.


Tope notepad and press ENTER.

What you’ve done to install the DLL file and then open up notepad in admin mode.  You want this because the files you need to edit are in protected locations on the OS, and as such, it will not let you save over them.  Opening notepad as an administrator gets you around that problem.

Step 3:  From notepad, open the following file:


NOTE:  You’ll need to switch from viewing only text files to all files to see this in notepad.  As well, if your windows directory is not the standard directory, you’ll need to adjust the path.  The location of where this addition should be is not specified in the article… BUT, location DOES matter. Scroll down to the very end.  Paste this information right before the </configuration> line.

<cryptoClass SHA256CSP=”System.Security.Cryptography.SHA256CryptoServiceProvider, System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
<cryptoClass HMACSHA256CSP =”Microsoft.EnterpriseManagement.Cryptography.HMACSHA256, Microsoft.EnterpriseManagement.Cryptography, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″/>
<nameEntry name=”SHA256″ class=”SHA256CSP”/>
<nameEntry name=”HMACSHA256″ class=”HMACSHA256CSP”/>

Note, you may want to copy this off of the web link as my formatting isn’t quite the same.  It should look something like this:


Save it.  Do not close Notepad.

Step 4: Repeat step 3 for the following file locations:

  • %WinDir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
  • %WinDir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

Step 5: From notepad, open the following file:

C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\WebConsole\WebHost\web.config

This file is a bit trickier to edit due to the fact that the tags you are looking for show up twice.  In every case, the tag shows up first in a commented out section.  If you make the edits there, it won’t work.  You have to find the second tags (see screenshot below).  First locate the <encryption> tag and add the following line underneath it:

<symmetricAlgorithm iv=”SHA256″/>

Second, locate the <Connection element.  Replace the <Connection… and the <Session lines with the following lines:

<connection autoSignIn=”True” autoSignOutInterval=”30″>
<session encryptionKey=”SessionEncryptionKey” tokenAlgorithm=”SHA256″>

Save this.  It will look something like this (note I circled the comment lines so you can see them as well).


Step 6: From notepad, open the following file:

C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\WebConsole\MonitoringView\web.config

Note this is also where the KB article goes wrong, pointing you to some .NET locations.  Those tags do not exist in those locations. Once this open, you can repeat step 5 covering the <encryption> element and <connection elements.  Those steps do not change.  There is one caveat here though.  The <session> tag is closed differently between this file and the one in step 5.  If you replace these directly, you’ll remove the ‘/’ tag at then end which will cause a mal-formed URL or something like that.  You can simply add a line and add a </session> immediately following the <session encryptionKey=”SessionEncryptionKey” tokenAlgorithm=”SHA256″> line.   The issues with the comment marks are present here as well.  Make sure you update the correct elements.

After that, you need to locate the <system.web> element and paste the following lines beneath it:

<machineKey validationKey=”AutoGenerate,IsolateApps” decryptionKey=”AutoGenerate,IsolateApps” validation=”3DES” decryption=”3DES”/>


Save this and close notepad.

It wouldn’t hurt to reset IIS after this point or just reboot the system.

Relaunch the web console.  It should look something like this:


If you made a mistake in the above steps, the error message should tell you where the mistake is, even so far as going to the exact line/character of the file.  You may need to turn on debugging to get that information.  If so, the error message will give you instructions on how to do that.  Compare that closely to the information in the link to see what went wrong.  Any typo can kill this.  It’s best to copy and paste where possible.