2020 Under the Hoodie Report Reveals Pen Testers’ Most-Loved Vulnerabilities

Penetration testing (“pentesting”) is the practice of simulating a criminal breach of a sensitive area in order to uncover and fix defensive failures. Rapid7’s recently released report, Under the Hoodie, draws from the experiences of our Rapid7 pen testing services teamers to highlight key vulnerabilities and reinforce the value of routine pentesting for both our physical and virtual world. The report covers the hows and whys of penetration testing, covering mainly internal and external network compromises, with some supplementary data on social engineering and red team simulations.

The insights shared in this report are a result of survey responses collected from 206 engagements from June 2019 through June 2020. Understanding the vulnerabilities that pen testers rely on will help you make sure your organization is prepared to patch particular vulnerabilities in order to mitigate popular attack techniques.

The types of vulnerabilities found and exploited by pen testers depend largely on the type of penetration test being performed. There are two types of pentesting jobs: inside jobs (internal network assessments and code reviews) and outside jobs (external network assessments, social engineering engagements, and red team simulations). This blog post will explore the most common vulnerabilities found during inside jobs and highlight how InsightVM, Rapid7’s vulnerability risk management solution, can help.

Common vulnerabilities, according to Under the Hoodie

The top three most common vulnerabilities encountered during internal network assessments  are:

1. SMB Message Signing Not Required (14%)
2. LLMNR and NetBIOS Poisoning (13.2%)
3. Kerberoast (10.8%)

Taken together, this is a powerful set of vulnerabilities that can quickly elevate an attacker to Domain Admin (DA) privileges.

SMB Message Signing

The first vulnerability, involving SMB message signing, is common in a mixed environment of Microsoft and non-Microsoft SMB clients. SMB message signing is a fundamental cryptographic control that lets SMB clients and servers properly authenticate to each other. However, it’s not enabled by default in most situations. While the procedures for enabling SMB message signing are well documented by Microsoft, many Windows Administrators aren’t fanatical about enforcing this basic cryptographic control, especially if the asset population of the network is either very dynamic or not well known to the IT operations staff.

Troubleshooting SMB connectivity issues also tends to start with disabling SMB signing temporarily, and temporary troubleshooting measures are notorious sources for persistent enterprise misconfigurations. This is all to say that if SMB signing isn’t strictly required by every host on the network, pen testers can take advantage of this lack of cryptographic assurances of destination server identity to get in a position to steal SMB-based credentials.

LLMNR and NetBIOS spoofing

That brings us to the second most popular vulnerability, LLMNR and NetBIOS spoofing. If a client doesn’t already have cached network address information for a given server on the internal network, they might try to perform a “Link-Local Multicast Name Resolution” (or LLMNR), and whatever machine on the local network responds first is the one that the client will believe is the destination server. Of course, if both the real client and the real server required SMB signing, this impersonation wouldn’t last very long, since the spoofed SMB server wouldn’t be able to authenticate correctly. However, as discussed above, pen testers often run into situations in which SMB signing isn’t required on internal engagements.

So, combining the two issues above gets an attacker in a pretty solid position to start acquiring Windows password hashes. A client, which doesn’t require SMB signing, needs to find a server it doesn’t have an address for, and that server (for whatever reason), doesn’t have a pre-defined DNS entry. It asks the network, “New cache, who dis?” and the attacker’s machine helpfully responds, “It me! Who dis?” and challenges the client for a Windows authentication. The client, believing the attacker’s server, provides a hash as part of the SMB challenge/response, which can then be cracked later by the attacker and reused to log in to the client directly.

Kerberoast

Once the attacker has access to a Windows domain user’s account, they typically can log in to any workstation in that domain—specifically, workstations that may be running services that need a Kerberos-enabled service account to run. Enter the “Kerberoasting” attack, where an attacker on a local machine can peek at the running processes and perhaps get access to an encrypted (but crackable) version of a domain service account’s password. Service accounts, like those that run domain backups or antivirus, tend to run with pretty high privileges, and if their passwords are set by humans, they tend to be pretty crackable in short order.

Finally, some services don’t take advantage of domain-based Kerberos tickets for authentication. If an attacker is able to log in to a domain-connected workstation, those credentials are merely a Mimikatz session away.

Not just Windows configurations

Of course, most internal networks have several types of operating systems and networked software running, not just the standard, default configurations of Microsoft clients and servers. For these situations, pen testers can seek out software with Critical Security Patches Missing (leveraged 8% of the time in this study) or running Obsolete or Unsupported Software (present in 5.2% of engagements), and draw on the thousands of known, pre-existing proofs-of-concept or working exploits available to them.

MS08-067 and MS17-10

Two vulnerabilities stand out as pretty standard go-tos for any internally scoped network assessment: MS08-067, which was weaponized in the Conficker exploit back in 2008, and MS17-10, which was the central vulnerability to the EternalBlue exploit kit of 2017. These two issues are among the famous vulnerabilities of the past decade, so you would think that IT and IT security teams would have long ago excised these vulnerabilities from their internal networks. Unfortunately, that’s not the case, as Figure 5 shows.

Interested in learning about the unknown unknowns, lateral movement techniques, code review assessments, and outside jobs? Check out the full Under the Hoodie Report!

How InsightVM can help detect, prioritize, and remediate these vulnerabilities

Utilizing the power of the Rapid7 Insight cloud, InsightVM is the industry-leading vulnerability management solution for your modern environment. InsightVM gives you:

• Clear Risk Assessment and Prioritization: InsightVM identifies vulnerabilities across your modern IT infrastructure, from local to remote, and cloud to containerized assets. Capabilities like Attack Surface Monitoring with Project Sonar, Container and Cloud Assessment, Threat Feeds, and our proprietary Real Risk Score offer insight into how those vulnerabilities translate into business risk, and which are most likely to be targeted by attackers.
• Remediation with Impact and Influence: InsightVM provides the shared view needed to align traditionally siloed teams and drive impact with features such as Live Dashboards, IT-Integrated Remediation Projects, Automation-Assisted Patching, and Automated Containment. Its Goals and SLAs feature supports a proactive approach to vulnerability management with tracking and metrics that create accountability for remediators and demonstrate impact across teams.
• Unified Endpoint Assessment: The Insight Agent is a universal, lightweight agent that collects data across the Rapid7 Insight cloud. With it, you can get live intel into both network and user risk on your endpoints.
• Maximization of Your Tech Stack: InsightVM not only integrates with 40+ other technology solutions, but also offers a fully documented RESTful API that makes it easy to automate virtually any aspect of vulnerability scanning.