Top 10 vulnerabilities found in internal pentests

In recent years, cybersecurity has become increasingly important for companies due to a variety of threats, including sensitive data breaches, compromised internal information systems (IS), and reputational damage. As a result, our clients are seeking to increase their security posture. One way to achieve that is to conduct internal penetration tests.

This service consists of the simulation of a cyberattack, carried out by security experts, within the company’s network to find vulnerabilities in the system and elevate privileges on the infrastructure, the same way a real opponent would (but without causing real damage). The goal is to find weaknesses and provide recommendations to fix them before a real attacker can exploit them.

Our penetration testing team has conducted many internal security audits for various clients over the years. Here are the top 10 vulnerabilities we find, how we were able to exploit them, and recommendations to solve them.

1) Legacy naming protocols

Windows is using multiple naming protocols to identify computers or services across the network to facilitate users’ access to them. The most widely used is DNS (Domain Name System): each computer that joins the domain or service is added to the DNS server, so whenever a user asks for a specific resource, the DNS service answers with the matching IP.

Unfortunately, if a user makes a mistake when querying a resource, then the DNS server cannot answer (e.g.: by assuming a CIFS (Common Internet File System) service like SMB (Server Message Block) exists at “ws-share.domain.tld”, while the user is asking for “w-share.domain.tld”, the DNS server won’t answer because “w-share” is not in its database). In this case, Windows will still try to answer using fallback protocols such as mDNS (Multicast DNS), NBNS (NetBIOS Name Service), or LLMNR (Link-Local Multicast Name Resolution).

All these are broadcast protocols, which means a request is sent to everyone in the attempt to find the IP of “w-share.domain.tld”. The problem is that if someone in the network is responding to this query with its own IP address, the client asking for “ws-share.domain.tld” may be redirected to initiate an authentication process, sending directly to the attacker an NTLMv2 response, which includes the hash of his password. In this scenario, the attacker can gather the hashes of multiple users’ passwords and try to crack them offline.

To prevent this threat, it is recommended to avoid using old legacy protocols by disabling them and only allow the use of DNS. This can be done through Group Policy Object (GPO).

2) NTLM relay

Another widely used technique is the NTLM (NT LAN Manager) relay. This attack relies on the lack of signature verification during the NTLM authentication, when a user tries to access a service (mostly LDAP – Lightweight Directory Access Protocol – or SMB).

NTLM authentications work in 3 steps:

1. The client makes an authentication request for a resource to a server.
2. The server sends a challenge to the client. 
3. The client sends a response to the server (it is the challenge encrypted using the client’s password).

Attackers in a Man-in-the-Middle (MitM) position may intercept the authentication request between a user and a service A, forwarding that request to a service B. Then, as they receive the challenge from service A, they forward it to the client and wait for his answer, which they will send back to service B. This way, they can authenticate themselves as the client to service B, without any knowledge of his password.

This attack does not work anymore if services request the client’s signature. Be aware that enabling signature and requiring signature is different: in the first case, the signature is possible and not mandatory, whereas in the second it will be asked everytime.

3) LAPS misconfiguration

Since it is very difficult to manage computers in large environments, Microsoft added a solution to automatise the management of the local administrator account, which is called LAPS (Local Administrator Password Solution). This solution adds two new properties to computer objects: “ms-Mcs-AdmPwd” and “ms-Mcs-AdmPwdExpirationTime” (a clear text password and its expiration date).

By default, only high privileged accounts may read the “ms-Mcs-AdmPwd” properties, but because some groups often have more privileges than they should, it is not rare to find users allowed to read these properties, even though they should not, which grants them local administrator rights.

Another misconfiguration our team encounters is when users have extended rights over a computer A. In this scenario, if the user has the right to add a new computer to the domain, they may add a computer B (on which he has administrator privileges) and synchronise its local administrator password with computer A (overwriting his own password). Afterwards, since they are already local administrators on the machine, they just need to read the “ms-Mcs-AdmPwd” property to obtain the password.

Using LAPS is a very efficient way to protect computers but it may be hard to restrict users from having read access or extended rights over the password.

4) Share permissions

During internal penetration tests, once a security auditor has an account, he may verify if there are open shares over the network and check if there is one that is configured with weak restrictions, such as “anonymous” access, “full read” access, or “write” access.

“Anonymous” access to a share means that anybody, even without an account, can access this share. Giving “write” access to too many principles may also result in users modifying data (e.g., binaries) to introduce backdoors. On the other hand, giving “read” access to everybody can end up in critical information exposure.

It is difficult to manage permissions correctly because of the number of users and groups, or even because of the number of shares available, but having a strong and restricted share policy reduces the attack surface.

5) Abusing Group Policy

Group Policy Object (GPO) is a feature that helps administrators to manage and control the working environment of users and computer accounts within an organisation. An attacker who has an account in the domain may access the SYSVOL (system volume) shares of any domain controller to retrieve those GPO. If administrators use GPO to push and execute scripts on computers, it may contain critical information such as a credentials.

Another risk is when a user has too many rights (like CreateChild, WriteProperty, or GenericWrite) over a GPO. In this scenario, a user may change it to take over the computers to which GPO applies.

To resolve this vulnerability, do not write clear text passwords in GPO and verify carefully who has writing privileges over your GPO.

6) ADCS template misconfiguration

ADCS (Active Directory Certificate Service) is a service used for issuing and managing certificates for users, computers or services. It allows you to configure templates that will then be used to generate certificates. However, since these templates are very modulable, they also contain dangerous options. For instance, some templates might be used to authenticate users on the domain, so if the template allows a user to request a certificate on behalf of another account (“ENROLLE_SUPPLIES_SUBJECT” option), an attacker might as well request a certificate and add in the SAN field (Subject Alternative Name) the name of a domain administrator. The ADCS will therefore issue a valid certificate to the attacker, which he might use to authenticate himself as a domain administrator.

Another vulnerability our team finds during pentests is templates that can be overwritten by any “authenticated user”. In this case, we are able to change the template options to authorise “client authentication”, and we can modify the subject of the certificate in order to generate a certificate on behalf of a domain administrator, thus compromising the entire IS.

Companies should verify the rights of their ADCS template to restrict the access to its modification, and they have to make sure that users are not able to supply the subject of the certificate.

7) Using SPN for user accounts (kerberoasting)

A not so new but still present vulnerability is the usage of SPN (Service Principal Name) for non-technical accounts – the so-called kerberoasting attack. SPN is an identifier of a service instance (e.g. MSSQL01_svc/sql.domain.tld:1433 represents the account MSSQL01_svc on sql.domain.tld). If an account has the “servicePrincipalName” property, every user may request a TGS (Ticket-Granting Service) for its service. This TGS includes an encryption of the account’s password, so an attacker may ask for a TGS and try to crack the password offline. This is not that dangerous for service accounts, because passwords are usually random and long enough, therefore harder to crack, but it becomes problematic for user accounts, because most of the time, even with a good password policy, it is easier to crack them with a good dictionary and efficient rule sets.

So, do not set the SPN property for user accounts and make sure to enforce a good password policy to limit the possibility of having attackers crack passwords.

8) Outdated systems and software

A threat that we frequently face in internal pentests is the discovery of outdated systems or software, which are vulnerable to Common Vulnerabilities and Exposures (CVE). It is hard to have a good update policy, especially in large companies, but this might be an easy entry for attackers, since new vulnerabilities are discovered and exploited every day, and many PoC (Proof of Concept) are often available.

Organisations must set up a good update policy to limit the possibility of cyberattackers exploiting those vulnerabilities.

9) SCCM misconfiguration

Recently, during an internal audit, our team has found a way to compromise the entire domain of a client by abusing the misconfiguration of the SCCM (System Center Configuration Manager) service. This product helps administrators to install, manage and configure computers in a domain. Unfortunately, the account used to perform configuration tasks was a domain account with too many rights (domain administrator rights).

The fact is that a local administrator of a computer managed by SCCM can decrypt the SCCM NAA (Network Access Account) password, because it is only protected by the Windows Data Protection API. Therefore, becoming local administrators on a workstation is often achieved by our experts.

Microsoft recommends not to use domain accounts to perform the configuration of computers or, at least, to restrict permissions.

10) Weak password policy

Finally, the most common vulnerability we face during our audits is having weak user passwords. As computing power increases, it is easier for attackers to crack more complex passwords, and even easier when the password policy used is weak. For example, this article shows how a password of 8 characters with upper, lowercase and special characters takes 5 days to be recovered and costs 3000$. 

The French Security Agency (ANSSI) recommends a password length between 9 and 11 characters to protect low sensitivity data, 12 to 14 for medium sensitivity content, and 15 or more for a high to a very high sensitivity level. They also recommend using uppercase, lowercase, digits, and special characters. Highly sensitive accounts should also be using Multi-Factor Authentication (MFA).