Business Security Update: Pass The Hash Attacks Pt.2!

By Lesley Kipling, Forensic Security expert, Microsoft Global Business Support

Hi all, Lesley here with another exciting installment from the world of security and compromise, malware and hack attacks.

In the last posting, we spoke about Pass-The-Hash attacks (PtH) and why we should all care about them.  I’d like to put the topic to bed with a discussion around some of the changes we’ve made here at Microsoft over the last couple of months to combat this type of attack.   First off the bat, I want to make you aware of brand new PtH documentation from Microsoft’s own Trustworthy Computing, hosted on its very own web resource here.  Do take some time out of your busy schedules to read through the document with an eye to how these tactics can be applied to safeguard your own organisation.  Understanding the mitigations to help prevent the different types of credential theft and implementing these tactics before they are needed will positively impact the security posture of any organisation – and unfortunately small organisations are no more exempt from these attacks than our enterprise customers.

Additionally, I mentioned the insecurity of using passwords inside Group Policy Preferences (GPP).  GPP items are stored in SYSVOL to which everyone has read only access.  For that reason and to prevent the transmission of the passwords in clear text over the network, passwords in the GPP XML source code are encrypted using 256-bit Advanced Encryption Standard (AES) encryption.  For those in the know, AES is a symmetric-key encryption algorithm, which simply means the same key is used to encrypt as it is to decrypt. This of course means that the key must be known to both parties in the communication chain or the decryption will fail.  In the case of GPP, the client reads the XML, decrypts the password, and implements the configuration.  In order to allow the client to decrypt the encrypted password in the XML file, the derived key used in the encryption is hardcoded in both GPP preferences and the Client Side extensions, making the passwords discoverable.  All that geek speak aside, the bottom line is with the ability to read the XML in SYSVOL, the attacker no longer requires administrative access to memory to pull password hashes, instead he can simply elevate his privileges to that of any account GPP has been used to store the passwords of.  Consequently, we made what might seem to some like a drastic decision and decided to deprecate the ability to store passwords in GPP with the release of MS14-025, more details here.  Given the speed with which exploit frameworks were implementing the ability to expose these insecurely stored passwords, as veterans of the cybersecurity trenches my team are in a position to definitively say this decision was the right one.

Moving on to yet another prevalent attack we are seeing at the moment: that of Ransomware, known by many different names and malware aliases but most often copies of the most successful of ransomware malware, CryptoLocker.  The malware encrypts user documents on the local machine and any shares to which that user has access.  The vector is most often a phishing email containing a link to the ransomware installer.  The first many users know of an infection is a popup soliciting money to decrypt their documents and, because anti-virus programs can remove the infection before users have written down the instructions, every folder contains an unencrypted document on how to pay the ransom so the user can recover their files.  Once upon a time the encryption key was mistakenly left on the machine or embedded in the malware itself, which allowed the AV companies to help their customers recover their documents.  This is seldom the case today, so be prepared for the fact that your AV vendor may well not be able to help you.   

As the malware infects in the context of the currently logged on user, just imagine (if you will) clicking this link whilst logged on as an administrator who potentially has access to every shared folder on the network, and perhaps even the online backups.  The moral of that story is don’t logon as administrator and be careful what you click!  The mantra of the day is backup, backup, backup, store them offline and occasionally restore them to ensure you are getting the data you need to recover, without paying unscrupulous crime syndicates huge sums of money to get your data back. 

Oh and I should add, it certainly helps to understand where your business critical data is held – locally on a user’s machine which is not part of the backup strategy will not save you from having to pay out. 

As always, we hope this information proves useful to you in your quest for security excellence.

Additional Resources:
- Microsoft Security Blog
- Trustworthy Computing Did you find this article helpful? If so, let us know via the comments box below or on @TechNetUK