As a security consultant(cy), you always want to bring value to your client. You want to make sure the client understands their security posture and the impact and importance of the vulnerabilities that are brought to their attention. I recently took some time to reflect on my nearly decade-long career in information security, which led to a moment of introspection. After reviewing the assessments I've conducted across various consultancies and a diverse range of clients worldwide, I realized a recurring pattern: we often encounter the same vulnerabilities time and again.
Initially, I wondered if this repetition was due to a bias in the types of clients or sectors I serve. To explore this further, I decided to crowdsource insights from the broader cybersecurity community.
As it turns out, I am not the only one that feels this way, which led me to create this blog post.
Instead of moving the proverbial needle one client at the time, I hope the more visibility this blog post gets, the more difficult my job as an offensive operator becomes. At the end of the day, my goal is to help organizations become more resilient against cyber-attacks. If I find it harder to break in and achieve full compromise, real adversaries will face the same challenges.
How I Compromised my First Domain
When I started my career in information security, I finally got the opportunity to work on an assessment that involved interacting with an internal network of a city in Belgium. I was paired up with the engagement lead (shoutout to Jonas Bauters). As a rookie with no experience, I did what anyone in my position would do—I looked over Jonas’s shoulder to see what he was up to. He pointed my attention to a blogpost written by Marcello, better known as byt3bl33d3r on the internet. I dug up the article because it’s relevant to this blog post.
Here's the crazy part: the blog post just worked—literally. We followed the steps in the article and gained domain admin privileges relatively quickly. Now, why is this relevant? If you look at the blog post timestamp, it was written in 2017. This post I’m writing now is form 2024. How many of you would be surprised to learn that the techniques highlighted in that post… still work?
Change is Hard and Scary—So Is the Unknown
Was the blog post from 2017 an anomaly? Or are there other long-standing weaknesses within organizations that persist to this very day? And if so, why are these problems still affecting organizations?
The answer is: no, the blog post was not an anomaly. Many weaknesses that are notoriously persistent and don’t seem to get squashed, no matter how many years the cybersecurity industry has been shouting about it. The explanation is painfully obvious: because it requires organizations to change. Change can be scary, change is hard! Especially in large organizations that can’t afford downtime for a patch or take the chance a firewall rule might be misconfigured. While I appreciate that change is difficult, I hope to address at least one other reason why some of the findings I will discuss in this blog post still occur, and that is because organizations might still not be aware of some of these issues.
Organizations typically need a penetration test or vulnerability assessment to get a report on these vulnerabilities. Not all organizations are doing regular offensive assessments, so not all organizations are aware of the problems I will highlight. Essentially, this blog post is “free consulting advice,” with the aim of saving organizations from conducting an assessment which will likely highlight one or many of the weaknesses in this blog post.
It Starts with Passwords and the “Strong Password Policy” Paradigm
For years, passwords have been a problem that our industry has never fully solved. Weak passwords like <companyname>123, <companyname><currentyear>, <season><year> have always had some degree of success for attackers. Over the years, our computing power has made password cracking faster and easier than ever.
To counter this, the security industry has long evangelized that organizations must enforce a “strong password policy.” This means requiring a minimum password length of 12 or more characters, at least one special character, a capital letter, and a number. To top it all off, users are often required to rotate their complex password every few weeks or months.
The industry thought this security control would solve the password problem. However, it arguably made things worse. Why? Because of the human brain.
Humans are not designed to remember long and complex sequences of characters and are definitely not designed to remember multiple variations of them. As a result, when faced with a password policy like the one described above, most users use predictable “shortcuts” to make their passwords easier to remember:
- If the policy requires a special character, users typically will add it to the very end of their passwords, with the most used special characters being “!” and “?”.
- If a capital letter is mandatory, it is often the first letter of the password.
- When numbers are required, they’re usually placed at the end of the password, just before the special character.
- for password rotations, users tend to reuse the same password and increment or decrement a number by 1.
Unfortunately, the most common passwords observed in 2024 are still unbelievably easy to guess, (see below). While enforcing a password policy is not a bad idea, forcing password rotation is.
A Better Approach
Rather than relying solely on outdated password policies, organizations should consider alternative authentication methods, like biometrics or smart cards. Another option is to use a password manager, though they aren’t a silver bullet either (as I’ll explain later in this post).
Multi-Factor Authentication to the Rescue! Or Maybe Not?
Multi-factor authentication (MFA) is the next step in securing authentication portals. Traditionally, applications require only a username and a password to authenticate users. MFA enhances this process by adding an extra layer of security.
MFA typically combines:
- Something you know (e.g., your password),
- Something you have (e.g., a mobile phone or a hardware token),
- Something you are (e.g., your iris or thumbprint), or in some cases,
- Somewhere you are (e.g., your geolocation).
While it is true that MFA increases the security posture of login portal, not all MFA methods are equally secure. For example, an American financial services company providing insurance and banking products announced on X that they are now accepting voice ID as an MFA method.
This raises concerns, especially with the rise in deepfake technology and voice cloning, as these technologies are becoming increasingly popular amongst threat groups. In fact, research by McAfee found that AI voice scams have already impacted 1 in 4 adults.
Another popular MFA method is sending a code via text message. However, this is notoriously insecure due to a phenomenon called SIM swapping. In a SIM swapping attack, a threat actor can pose as the victim and convince the mobile company to issue a new SIM card for the victim’s phone number. If successful, the threat actor gains control of your number and intercept text messages, including MFA codes.
In short, the MFA method implemented matters a great deal, and while MFA can be bypassed in attacks such as proxy-in-the-middle attacks, they still offer a significant security advantage. The most secure MFA methods include:
- Biometrics,
- Smartcard,
- Hardware token, and
- Mobile applications that require entering a code into the app.
But Look How Well Our External Perimeter Is Secured!
Most organizations do a decent job at securing their external facing resources, which is a good thing. If they didn’t, far more organizations would get compromised. However, many organizations tend to underestimate the importance of securing their internal perimeter.
The internal-facing infrastructure of organizations is a breeding ground for vulnerabilities:
- Misconfigurations,
- Outdated operating systems and web applications,
- Single factor authentication, and
- Insecure legacy protocols that are still in use.
Once a threat actor finds access to an organization’s the internal perimeter—often through a social engineering attack—they can abuse these flaws to elevate their privileges and ultimately compromise the entire environment.
The Tale of LLMNR and NBNS: Protocols that Refuse to Die
One of the most frequent findings in our penetration testing assessments is the continues use of Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBNS) protocols. These are fallback mechanisms for DNS, but they are considered outdated and insecure.
What are LLMNR and NBNS?
LLMNR and NBNS act as fallback methods when a computer cannot resolve a hostname through conventional ways (DNS). For example, should DNS fail to resolve a specific hostname because the user made a typo, these protocols send broadcast messages to the entire subnet, asking if any device can provide the IP address for the unresolved entry.
In normal operations, this will not impact the business, as no device on the subnet would respond if the host does not exist. This changes however, if an attacker is on the subnet waiting for a broadcast message from LLMNR or NBNS. These protocols don’t validate the identity, meaning they will blindly trust the first device that replies to the broadcast. This could lead to a victim authenticating to an attacker-controlled device.
For more information about the impact of this flaw, SANS has a nice workshop titled NTLM Relaying 101: How Internal Pentesters Compromise Domains.
New Technology is Great—If You Actually Use It
The astute observer might have spotted in the Harry Potter meme that not only were LLMNR and NBNS mentioned, but also IPv6. Why is that? As it turns out, IPv6 is an excellent invention to address the fact that we are running out of public IPv4 addresses. It is the successor of IPv4.
The IPv4 address space (both public and private) is limited to 2³², or 4,294,967,296 unique IP addresses. IPv6 has a significantly more address space: 2¹²⁸ or 3.403×10³⁸, which equals 340,282,366,920,938,000,000,000,000,000,000,000,000 unique IP addresses. That’s approximately 340 undecillion, 300 decillion—a number so large that it’s safe to say we won’t run out of public IPv6 addresses anytime soon. 😊
That said, when it comes to private networking, IPv4 addresses are typically divided into three classes: class A, class B, and class C. In total, there are over 17 million private IPv4 addresses available. These are not publicly routed, meaning every organization can use these ranges internally without worrying about IP collisions.
For 99.999999% of organizations, the number of private IPv4 addresses is plenty to network their internal infrastructure. As a result, IPv6 is rarely used for private addressing.
Interesting fact: Did you know that IPv6 is enabled by default on all modern network interface cards (NICs), even if you are not using it?
When a NIC is set to support IPv6, the computer will occasionally send out a DHCPv6 broadcast message asking for an IPv6 address. If the organization is not using IPv6, it’s unlikely a DHCPv6 server is configured, meaning the computer won’t receive an IPv6 address and will fall back to IPv4.
The situation changes if an adversary is present on the network and sets up a rogue DHCPv6 server. If done correctly, an adversary could assign the target computer with an IPv6 address and configure a malicious DNS server to redirect traffic.
Much like LLMNR and NBNS, this scenario can lead to users unknowingly authenticating to attacker-controlled resources. This can result in relaying attacks, or offline password cracking attacks.
Printers: The IT Admin’s Worst Nightmare
Another way that attackers could potentially force authentication is through the print spooler service. The print spooler service is enabled by default on all Windows computers and can be abused to force one machine to authenticate to another. This technique can be very useful to an adversary.
Recommendation: Disable the print spooler service on tier 0 assets or any other assets that don’t require it. While there are other methods to coerce authentication, these fall out of scope of this blog post.
Unsecured Web Applications and Admin Portals
Printers themselves aren’t the only nuisance—any domain-joined device with a poorly secured web application can be problematic. Many organizations struggle with securing internal-facing web applications, leading to two common vulnerabilities:
- No Authentication: Some internal web applications are left unsecured, requiring no authentication to access.
- Weak Credentials: Others rely on weak credentials like admin:admin.
In some cases, these web applications connect to Lightweight Directory Access Protocol (LDAP) for purposes such as an address book. If an attacker gains access to the web application, there might be an option to change the LDAP server address. This could allow an attacker to intercept plain text credentials of the connector account, (see example below).
Active Directory Certificate Services Are So 2021—But Still Relevant
Active Directory Certificate Services (ADCS) is a widely used technology in many organizations. As a form of public key infrastructure (PKI), it supports several legitimate business use cases, including:
- Secure Email (S/MIME),
- VPN and Wi-Fi Authentication,
- Web Server SSL/TLS,
- Code Signing,
- Smart Card Logon,
- Document Signing, and
- Device Authentication.
The technology has been around for a while and is reliant on outdated coding practices that don’t necessarily prioritize security. For years, the attack surface of ADCS was left unexplored (at least not publicly). This changed when SpecterOps (Hi Friends!) released a white paper in 2021, regarding abuse cases and misconfigurations.
The findings from SpecterOps exposed a lot of misconfigurations, sometimes leading to almost instantaneous domain compromise. The complexity of ADCS and the prevalence of these issues make it no surprise that these misconfigurations are still common in many of our engagements.
Rather than listing every possible ADCS vulnerability—which would essentially duplicate SpecterOps’ excellent work—we will focus on two of the most common ADCS misconfigurations we find during our penetration testing engagements.
Misconfigured Certificate Templates
One of the most common findings during our assessments is misconfigured certificate templates. This is a favorite of ours, as it allows compromise of the domain almost immediately.
The way ADCS works is the certificate authority (CA) server publishes certificate templates. These templates can be configured for many use cases, but from an adversarial perspective, the templates use for authentication purposes are the most interesting.
One common misconfiguration happens when the certificate admin enables an option allowing the requestor to supply the subject name in their request. In simple terms, this means that anyone authorized to request a certificate based on this template can tell the certificate server to issue a certificate on behalf of someone else. For example, they could request a certificate in the name of a domain administrators—not the original requestor.
This misconfiguration allows adversaries to get their hands on a certificate that allows them to authenticate as a domain administrator. This can happen almost instantly, provided the template does not require manager approval (a security feature that requires a certificate administrator to manually approve requests).
Active Directory Web Enrollment with Default Configuration
Another common vulnerability we observe is the use of ADCS’s optional “web enrollment” feature. Whilst web enrollment itself is not a security vulnerability if configured properly, the default settings applied to the web server when this feature is enabled are insecure. Since ADCS is an older technology, the web application bundled with ADCS web enrollment is outdated as well. In fact, the default configuration has a few significant flaws:
- HTTP Instead of HTTPS: The web server that hosts the application serves traffic over HTTP, not HTTPS, which means communications are unencrypted.
- NTLM Authentication: The portal relies on NTLM authentication, which is vulnerable to attack.
With the default settings, web enrollment becomes an easy target for NTLM relaying attacks. An adversary can coerce users or systems into authenticating to an attacker-controlled resource. This allows attackers to request authentication certificates for any user or system they exploit.
Managing Assets is Hard, Scanning for Sensitive Information is Almost Impossible
Many organizations struggle with inventory management, i.e., keeping track of the infrastructure they actually own. If that presents a significant challenge, imagine an organization’s struggle when managing file shares or internal websites looking for potential sensitive data exposure.
It’s not just websites and file shares either. What about source code containing hard coded secrets, and databases storing sensitive, unencrypted information.
In more advanced, stealthy operations, a lot of time is spent scouring all exposed resources we have access to, looking for anything sensitive that can help achieve our objectives.
You Thought We Were Done Talking About Passwords, Didn’t You?
Another common finding is password reuse. Humans aren’t the best at remembering things, especially passwords. While password managers do exist, we still see many organizations failing to adopt password management tools company-wide. If users have multiple accounts, for example “sky” and “sky_adm”, there is a chance the same password is used across both accounts. While this is problematic for domain joined accounts, it’s especially problematic when it involves the local “administrator” account.
Arguably, the local administrator account is the most significant issue when we find this problem. When local administrator account passwords are reused across multiple systems, an attacker only needs to compromise one system and reuse those credentials to laterally move across the environment. In extreme cases, this weakness can allow attackers to compromise all systems in the organization.
On top of that, service accounts are also often problematic, often having weak, easy to guess passwords or passwords that never change. This leaves the door open for attacks known as kerberoasting, a technique that recently celebrated its tenth anniversary. (Feeling old yet, Tim Medin? Shoutout to the inventor of the technique!)
Finally, we cannot end the “passwords are bad” section without mentioning default credentials. The impact of default credentials varies based on the actual systems/applications where the default credentials are present, however, there are cases where they’ve led to full domain compromise (AD Manager Plus anyone?).
Something that often gets overlooked and is a favorite of ours at operators in Neuvik, are SQL servers. these servers are domain-joined and accept domain level authentication, which can lead to interesting techniques for attackers such as hash leaks through stored functions (xp_dirtree, xp_fileexist) or in some extreme cases remote code execution through xp_cmdshell. SQL servers create a local account, called the “sa” (System Administrator) account during installation. Any guesses on what a common password for the “sa” account is?
Here’s a clue: ¡ʇɔǝɹɹoɔ ǝɹɐ noʎ 'ɐs sı ʇunoɔɔɐ ɐs ǝɥʇ ɹoɟ pɹoʍssɐd uoɯɯoɔ ʇsoɯ ǝɥʇ ʇɐɥʇ pǝssǝnƃ noʎ ɟı
Last But Not Least… Misconfigurations
If you are not a cybersecurity practitioner, you might be surprised to learn that most compromises we perform during assessments have very little to do with actually “exploiting” many vulnerabilities.
Most of the time, we rely on misconfigurations in Active Directory (AD) itself. Combined with the aforementioned findings, we can elevate our permissions in the environment and achieve our objectives.
So, What Are Some Recommendations We Can Give to Help?
To conclude this blog post, I want to give some recommendations for organizations to immediately increase their security posture and make the life significantly harder for adversaries, penetration testers, and red teamers (sorry, colleagues in the infosec consulting space!).
In fact, our dear friends in Australia! recently collaborated with:
- United States (US) Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA),
- Canadian Centre for Cyber Security (CCCS),
- United Kingdom National Cyber Security Centre (NCSC-UK), and
- New Zealand National Cyber Security Centre (NCSC-NZ).
Together, they released a guide on how to detect and mitigate AD compromises. This guide is excellently well written. If you haven’t read it yet, we highly recommend it. You can find the paper here.
Recommendations
1. Establish a Security Program
If you don’t already have one, this should be your first order of priority. Build a program that includes asset management, vulnerability management, penetration tests, and ultimately red teaming, purple teaming and adversary emulation campaigns.
2. Address Legacy Technology
Once you have an overview of your IT assets, implementing a process to sunset end-of-life technology (both soft and hardware). If legacy systems cannot be replaced, mitigate risk by segmenting them with a proper firewall.
3. Implement Deception Technology
Deploy honey tokens, users, passwords and files to alert the SOC when someone is poking their noses into things they should not.
4. Enable MFA
Use authentication method like smart cards or biometrics wherever possible.
5. Remove Local Administrator Rights
Eliminate local admin privileges for normal users, where possible. Optionally, look into “just enough administration” technology.
6. Invest in Endpoint Security
Ensure you have proper endpoint telemetry and detection capabilities. Invest in solutions like Endpoint Detection and Response (EDR), Security Orchestration, Automation, and Response (SOAR), or Extended Security Orchestration, Automation, and Response (XSOAR), and complement them with application control, exploit guard, and attack surface reduction. Remember, defense in depth is key!
7. Utilize Offensive Tradecraft for Defensive Purposes
Run tools like BloodHound, PingCastle, Purple Knight, and Locksmith, in your environments.
Strengthening Your Defenses
Securing your organization’s infrastructure doesn’t have to be overwhelming, but it does require a focus on continuous improvement. By addressing misconfigurations, upgrading outdated systems, and implementing strong authentication, you can make it much harder for adversaries to succeed. Taking action today will strengthen your defenses and prepare you for the evolving threats of tomorrow.
Want to stay ahead in the field of offensive operations? Explore more resources and join the SANS community today to stay connected to the latest insights and innovations.
