So Vulnerable: Common Findings from Penetration Testing

By Chris Green, Structured Security Engineer, CISSP-ISC2, CISA ISACA, QSA PCI SSC, PCIP PCI SSC

Amid rising global tensions and numerous warnings from the?Department of Homeland Security’s Cybersecurity & Infrastructure Security Agency (CISA), organizations across the globe can expect to see an increase in cyber attacks from nation-states, criminal gangs, and copycats riding the wave. These attacks may vary in sophistication depending on the source of the malicious actor, but organizations should be prepared to encounter any level of foe.

While a robust security program is tasked with focusing on numerous facets such as continuous posture assessment, monitoring and detection, threat hunting, and incident response, Structured’s Governance, Risk and Compliance team would like to share some of the most common findings from penetration testing that often lead to compromise.

While many organizations are transitioning to cloud-based infrastructure, user-endpoints and cloud infrastructure can still be a focus of attack. The following details common findings from penetration testing public-facing assets, followed by what we commonly see while probing internal assets.

Common Findings from Penetration Testing Public-Facing Assets

No multi-factor authentication (MFA) on public-facing authentication portals?– During testing, we mimic the most popular attacks used by malicious actors: social engineering and password-spraying attacks. These attacks exploit the human element to obtain valid credentials. They frequently deliver. When credentials are obtained, they’re tested against all the public-facing authentication portals we can find to determine if MFA is in use. This can include Microsoft 365, VPN portals, employee resource portals, etc. This commonly allows access to mailboxes and cloud drives where sensitive data can be accessed. Worse yet, a VPN portal with no MFA implementation leads straight to the internal network. MFA everywhere is a great motto to live by.

Application vulnerabilities?– As we see secure development practices becoming more and more common, application vulnerabilities found in the OWASP top 10 commonly provide access to sensitive data or command of backend systems via injection or fuzzing. Cross-site scripting vulnerabilities are also commonly discovered that can be used to run scripts within a customer’s or employee’s browser leading to a malicious site or download. Keep in mind that these vulnerabilities aren’t just limited to assets developed in-house. Third-party products such as Apache, WordPress, or your VPN appliance portal can contain vulnerabilities that if left unpatched, may be exploited. Which segues to…

Unpatched systems?– Public-facing assets running outdated software versions may be susceptible to attack. Even when no publicly available exploit exists, criminal actors frequently develop custom exploits to leverage when vulnerabilities are discovered. Maintaining a?regular vulnerability and patch management schedule?is vital.

Sensitive ports open to the internet?– Port scans are always performed upfront to enumerate ports, services, and operating systems that are in use.?When sensitive ports and protocols such as SMB and RDP open to the internet, a whole host of attacks can be performed such as password spraying, enumerating internal data, or allowing a direct path to the internal environment. It’s best to close these doors in favor of a remote access solution or VPN.

Common Findings from Penetration Testing Internal Assets

Non-restrictive permissions?– Once inside, especially if valid credentials have already been obtained, open permissions are an attacker’s best friend. Any compromised accounts with elevated permissions, particularly local administrator rights, can allow an attacker to extract various password hashes from any machine where the account holds such rights. Tools exist that allow attackers to quickly check for elevated permissions across an entire subnet in a single go, making the hunt for privilege escalation that much easier.

Reusing local Administrator account passwords across multiple systems?– If an Active Directory account is found to have local administrator rights on a Windows endpoint, the NT password hashes of the local accounts can be extracted. Using the pass-the-hash technique, the local Administrator account can be used to access any endpoint on the network where that account’s password is reused. If the local Administrator account has local administrator rights on those machines also, the attack surface is dramatically increased rather than keeping the attacker siloed to a single endpoint.

Caching credentials on Windows servers and other non-mobile Windows endpoints?– With a compromised Active Directory or local account with local administrator rights, cached credentials in hashed form can be extracted from endpoints to be cracked offline. The hashed credentials of administrator accounts are frequently found and can be cracked when weaker passwords are in use. While cached credentials may be necessary for mobile devices such as laptops that are not always connected to the domain, stationary Windows endpoints can be hardened by disabling credential caching.

Continued use of legacy protocols such as LLMNR and Net-BIOS?– LLMNR and Net-BIOS are still enabled by default on Windows Servers and can allow an attacker to capture hashed credentials using common tools. These hashes may be cracked when weaker passwords are in use providing an attacker a foothold on the network.

Weak passwords for accounts with Service Principal Names (SPN) set?– Any compromised Active Directory credential of an enabled account, no matter the level of permissions granted, can be used to perform a “Kerberoast” attack. In this attack, Active Directory accounts with SPNs set can be extracted along with a password hash that can be cracked when weaker passwords are in use. These accounts are often service accounts that may hold elevated permissions on the Windows endpoints where they’re in use. Due to their potential sensitivity, long, complex passwords should be used.

SMB signing not enabled and enforced allowing for relay attacks?– Again, to capture hashed credentials. Devices that don’t have SMB signing enabled and enforced can be targeted for various flavors of relay attacks in which an attacking device sends a signal to a victim to trick it into sending credentials, typically in hashed form. An attacker can then attempt to crack the hash, or if an NT hash is captured, authenticate to devices using the pass-the-hash technique. SMB signing ensures that only signed requests are observed while poisoned requests are ignored.

Unpatched systems?– Like the public-facing side, internal assets, particularly Windows endpoints, running outdated software versions may be susceptible to attack. Infamous exploits such as Eternal Blue are still ever-present on servers and can quickly lead to system-level access. Again, maintaining a regular vulnerability and patch management schedule is crucial to plug these holes.

File server storage and permissions?– Standard user accounts often have access to much, or all, of the files stored on file servers. Malicious actors can search for keywords such as “password” looking for spreadsheets or text files where users have created makeshift password managers, “ssh” for SSH keys to protected systems, or “config” for appliance configuration files that may contain the hashed passwords of local user accounts. The lack of strict permissions can also make matters worse during a ransomware attack. Should a user who falls victim to the attack have permissions to files or shared folders outside of their department or duties, the attack can spread to encrypt any files where permissions allow. File servers should be reviewed regularly for password storage and strict access permissions to shares should be audited regularly to limit access to only what is required for each user.

Conclusion

While this is by no means an exhaustive list, remediating many of these can minimize the quick wins — either convincing a malicious actor to move on or allowing an organization more time to detect and react to an intrusion. Understanding what and where your assets are is the first step in identifying your attack surface. Once the low-hanging fruit items are cleaned up, assessing the organization against the?Center for Internet Security’s (CIS) Critical Security Controls?can assist in establishing a security baseline from which to grow and improve security posture.

Whether your security program is just starting to grow or is well established, regular assessment, tuning, and vigilance are the new normal as we brace for the threats associated with world events. Leave no stone unturned.

About the Author

Chris Green?is a Security Engineer with over eight years of experience in security and networking. His background includes information security assessments and penetration testing, PCI QSA assessments, network infrastructure design, security infrastructure design, implementation, and troubleshooting. Chris has performed security assessments following NIST SP 800-30 and CIS Controls guidelines, PCI DSS assessments following the v3.2.1 standards, and penetration testing following NIST SP 800-15 and using the processes defined in the Certified Ethical Hacker (CEH) methodology.