War on 'Pass the Hash'

At the 2012 User Conference you might remember Joel’s (aka SCADAhacker) demo scenario starting with a corporate user who opens a poisoned PDF. After loading a RAT (remote access Trojan) to reliably control the victim machine, he shows the ‘Pass the Hash’ technique for pivoting within corporate networks using legitimate credentials. In the classic PtH scenario the attacker takes control of a domain.

The tools used in Joel’s demo are readily available to 'casual' attackers. More to the point, attack tools continue to evolve with more powerful exploits. In fact, the latest WCE tool is now kerberos aware. So too, must our cyber defenses evolve.

Since the PI System and most corporations rely heavily on Windows integrated security you should be in the know about Pass the Hash. In my view, Microsoft has declared war on Pass the Hash. The purpose of this post is to call your attention to the TechEd 2013 session featuring detailed information and mitigation advice regarding PtH.

“Pass the Hash and Other Credential Theft and Reuse: Preventing Lateral Movement and Privilege Escalation”

I highly recommend viewing the TechEd recording and slide deck.  Here’s my take on the top 3 mitigations with some PI System spin:

• Mitigations 1 and 2 are quick wins. Don’t be administrator, at least, not all the time! Enable full UAC in Windows Vista and later.  The same is true for the PI System.  Administrator and piadmin access should be reserved for initial provisioning and disaster recovery tasks. Don’t put your data (and systems) at risk due to unnecessary use of full permissions.
• Mitigation 3: Restrict inbound traffic using Windows Firewall.  Your organization needs a way to impede unapproved lateral movement on the network. The Windows firewall is built-in... just do it.  While you’re there, get tough on outbound rules too, at least for your servers and interface nodes.

If you’re like me, you’ve learned to appreciate system defaults whenever possible.Outbound connections are allowed by default so you know there is going to be some extra effort and testing to block by default. 

The observations below are meant as a starting point especially for those with a dedicated PI Server. Other apps running on the machine may require additional rules.

Observations with Windows Firewall Outbound Connections set to Block by Default

1. Perhaps the first thing you might notice on a test VM is loss of network connectivity. Like a real server you’ll want to configure a static IP so the DHCP ports need not be open.
2. Assuring kerberized logins with the domain controller are possible was a more obvious need. Sadly none of the built-in rules seem appropriate. Instead 2 rules were added to allow outbound connections to the following remote ports. Scope these rules for connection to domain controllers. You might need a third if your DNS is separate from AD.
   • UDP rule – Local Ports: All, Remote Ports: 53, 88,123,389,464,3268
   • TCP rule – Local Ports: All, Remote Ports: 88,389,464,3268
3. Group policy support is recommended for domain members but not required. The following 3 built-in rules should be enabled to allow processing of group policy.
   • Core Networking - Group Policy (LSASS-Out)
   • Core Networking - Group Policy (NP-Out)
   • Core Networking - Group Policy (TCP-Out)
4. You might be expecting the PI Server to require a 5450 outbound rule. Not so, inbound rules are sufficient to allow the PI Server to respond to client connections. However a PI HA Secondary server will need an outbound rule to allow connections to the primary.  Similarly PIAFLink replication also needs an outbound rule to connect to a remote AF service. As such the rules should allow outbound connections to the following remote ports for PI and AF respectively. Incidentally, these rules are also applicable to interface nodes and other PI System roles acting as a client.
   • TCP rule – Local Ports: All, Remote Ports: 5450
   • TCP rule – Local Ports: All, Remote Ports: 5457, 5459

As a final tweak the above rules can be assigned to the applicable service. First though you’ll need use the Windows Service Control utility to ‘unrestrict’ the service. Then select the respective PI service on the Programs and Service tab of the Window firewall rule wizard. Yes, we are planning for ‘restricted’ mode services but that is a future discussion.

• SC sidtype pinetmgr unrestricted
• SC sidtype piaflink unrestricted

In summary, Microsoft's top 3 PtH mitigations make sense for a modern PI System and are in direct alignment with OSIsoft best practices. I hope this post was useful for understanding some of the relevant changes in our cyber ecosystem and helps you identify synergies for more efficient defensive initiatives.  Thanks for listening, and safe computing!