Using SCOM to Detect Pass the Ticket Attacks

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.

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.

Comments

• Anonymous
  January 31, 2017
  Good day Nathan. Can I receive MP for SCOM? Sorry, but I have problem with linked in. Thanks.
  • Anonymous
    February 24, 2017
    absolutely. I'll reach out privately.