My experience in
SANS SEC560:
Network Penetration Testing & Ethical Hacking
From September 25-30 I attended the SANS Institute SEC560 Network Penetration Testing and Ethical Hacking training course in Baltimore, MD. This is my second SANS training, and both have been absolutely fantastic. The course instructor, Jeff McJunkin (https://www.linkedin.com/in/jeffmcjunkin/), is energetic, excited about the topics and material, and extremely knowledgeable about cybersecurity concepts in general and network penetration testing in particular. I thoroughly enjoyed the class, learned a lot, and was privileged enough (pun intended!) to come away with a coveted SEC560 Capture the Flag challenge coin:
I also came away with a deeper understanding of many of the principles behind some of the technology component hardening standards maintained by the cybersecurity community, such as the US Department of Defense (DoD) Security Technical Implementation Guides (STIG). I’ve long wondered why some of the guides require such seemingly esoteric and minute configurations of a particular piece of technology. The Windows Server 2012 STIG, for instance, has over 340 guidances, most of them “in-the-weeds” style technical configuration, such as: “The LanMan authentication level must be set to send NTLMv2 response only, and to refuse LM and NTLM.”
Well, SEC560 and Mr. McJunkin provided concrete clarification on the issue: the reason for the minutiae in these guides is that simple real-world techniques exist to take advantage of misconfigurations in system components. There are also lots—I’m talking dozens, if not hundreds—of free tools available that allow a novice hacker to quickly and effectively apply these techniques to compromise a network. This fact got me thinking about what we working to secure small-to-medium sized businesses can do from a network component configuration standpoint to slow down or stop the advance of an adversary intent on compromising the IT networks our businesses depend on. I can boil down my many takeaways from the training into three main recommendations (well, four, considering a “zeroth” foundational assumption).
1) Assume your Network is already Compromised
The simplicity of the penetration techniques and availability and ease of use of the tools makes it trivial for an attacker to compromise most networks. If you assume they are already in, the following recommendations should help delay or stop the attacker’s lateral movement through the network, and hopefully prevent future successful initial entries into your network.
2) Patch Everything! ASAP!
As soon as a patch is released by a software or hardware vendor, the adversary gets to work reverse-engineering the patch to develop an exploit for the vulnerability the patch is meant to remediate. This patch-reverse-engineering cycle doesn’t even take into account the fact that some patches remediate zero-day vulnerabilities with exploits available before the patch is released. When an exploit is developed it is immediately ported into the hacking tools, and the adversary is ready to attack, taking advantage of unpatched vulnerabilities to further compromise your network.
To thwart this objective of the adversary, your goal should be a configuration management process that allows application of patches within 72 hours of release. 72 hours may seem extremely optimistic, and perhaps risky due to the occasional volatile nature of patches. Assuming you have a working patching apparatus in your network (e.g. SCCM or WSUS for Microsoft components, scripted installs for Linux, Satellite servers, etc.), you may be inclined to wait to patch to ensure adequate time for patch testing. Understandable.
Understand, however, that this delay is exactly what the adversary anticipates. Bryan Simon (@bryanonsecurity), another SANS instructor who taught the SANS SEC511 course I took in 2016, makes the valid argument that the entire world is your patch testing apparatus, especially for ubiquitous Windows OS and software. Pay attention to industry blogs and social media, (for example, Woody Leonhard: https://twitter.com/woodyleonhard) for feedback during the first 48 hours after the patch is released; if you haven’t heard anything negative, assume the patch isn’t volatile and execute the patch within the next 24 hours.
3) Make your password policy simple but strong
The speed of modern processors and low cost of on-disk and in-memory storage has made password cracking simple for our adversary. And cracking passwords is well worth the effort for the adversary—why wait for vulnerability exploits to be published when you can simply gather credential information from readily-visible network traffic, crack the passwords (or worse yet pash-the-hash), and simply log in as an expected user on the network? As analogy: what would a burglar rather do: pick the lock on your front door, or simply use the key you left under the mat? But you don’t have to leave the key under the mat. There are some pretty painless configurations you can set in your network as part of a simple but strong password policy:
- Require passwords to be at least 15 characters in length, preferably much longer—in Windows, 15 characters nullifies the OS’ ability to store and transmit passwords in the older vulnerable LANMAN format, and each additional character increases the time it takes to crack by an order of magnitude.
- Eliminate the complexity and expiration requirements for passwords—“complex” passwords (e.g. “P@ssw0rd!” vs. “password1”) don’t fool modern password crackers, and only encourage users to write down their password and/or reuse the same password across multiple applications. So, ditch those complexity requirements of characters from multiple cases, digits, special characters, etc. Require long but simple passwords to encourage the use of passphrases the user can remember, and then allow the user to keep the password in perpetuity, changing only when a known breach occurs. Better yet: encourage and enable the use of password managers in your environment.
- Engage strong password storage encryption, and disengage the weak—Windows and Linux provide configuration mechanisms to engage strong hashing algorithms for encrypted storage and transmission of passwords; Linux engages these mechanisms by default. The STIG I cited above—“The LanMan authentication level must be set to send NTLMv2 response only, and to refuse LM and NTLM.”—is a configuration that can be set in Windows security policy. Use the STIGs or other secure benchmarks, such as those published by the CIS, to guide password configuration in your environment.
4) Turn on Encryption by Default
As a community we’ve gotten pretty good at expecting the external services we use to engage encryption. For example, we expect public-facing web servers that accept payment information from us to show “https” in the URL (you do, right?), and we use apps (e.g. WhatsApp) that engage encryption to protect our privacy. Yet, mistakenly, many of us don’t have these same expectations for our internal networks. Any unencrypted traffic in your network is valuable to the adversary, even if it doesn’t explicitly contain credential information.
For example, you make it easy for the adversary if your valuable intellectual property or personally identifiable information (PII) is transmitted in the clear on your network—the adversary doesn’t need to hack your database to exfiltrate the data, they simply need to sniff and copy off traffic. And if you don’t encrypt data at rest, when that adversary does compromise a component, the information he/she is after is readily available without the extra burden of tracking down encryption keys. Some common examples of vulnerable unencrypted internal components:
- Internal web servers that don’t engage TLS. All data sent to/from these servers is free to view on the network. And if your internal web server communicates with an external database, that data could be sent over public networks.
- Internal databases that don’t store data in encrypted format.
- Mobile devices that don’t have full-disk encryption engaged—even if a password is required to login to the device, if this device is lost or stolen, the adversary can simply mount the hard drive in another machine to access the data.
- VOIP traffic—this traffic is plain text, and can be used by the adversary to re-play voice conversations (YEP!)
Yes, encryption is expensive and burdensome to manage, but so is a breach of intellectual property or PII-the Equifax breach is just the latest in a long, sad line of examples of this reality. Whenever the option exists, encrypt.
By rapidly patching your systems and engaging a simple but strong password policy, you will significantly reduce your adversary’s ability to initially compromise or move laterally throughout your network. Then, engaging encryption by default in all system components will make it much more difficult for the adversary to effectively harvest any information he/she may be after.
Learn what is different about Totem’s Cybersecurity Awareness Training.
Good Hunting!
–Adam Austin
Cybersecurity Lead
