Faced with an ever-increasing number of internal attacks, network infrastructure security is a key factor in ensuring the confidentiality and integrity of data, as well as the continuity of an organization’s activities.
There are several ways of assessing the security of an internal network. In this article, we present the “offensive” approach, which we believe to be the most effective: internal penetration testing. We detail the principles and objectives, as well as use cases for black box and grey box penetration testing of an internal network.
Detailed plan:
- What is an internal penetration test?
- Scope of an internal network penetration test
- Internal network penetration testing methodology
- Impact of various vulnerability exploits on an internal network
- Perform an internal penetration test with Vaadata, a company specialized in offensive security
What is an internal penetration test?
An internal penetration test consists in assessing the security of an internal network from the position of an attacker who manages to break in. In this type of audit, a pentester will simulate the behavior of an attacker by exploiting potential security flaws, in order to measure their impact and propose corrective measures to reinforce network security.
For this purpose, two scenarios are generally considered:
- Attacker without an account (on the domain) or internal black box penetration test: In this scenario, it is assumed that the attacker is present on the network, but has no prior access to the equipment. This is the scenario that best considers an attacker who succeeds in physically plugging into network sockets, connecting to the wifi network or compromising equipment not linked to an organization’s domain. Furthermore, in an Active Directory context, this means that the pentester has no user account belonging to the domain. In fact, the pentester’s objective will be to gain valid access to a piece of equipment (server, user workstation, domain account, etc.).
- Attacker with account (on the domain) or internal grey box penetration test: Here, we assume that the attacker is present on the network and has valid access to an internal service or piece of equipment. This scenario considers an attacker who succeeds in compromising an employee’s account (via phishing, for example), a workstation or a piece of equipment connected to the domain, or in achieving the objective of the previous scenario. Furthermore, in an Active Directory context, the pentester will have a valid account on the domain with no special privileges. Using this account, the pentester’s objective will be to gain access to sensitive corporate assets, usually by elevating his or her privileges.
Scope of an internal network penetration test
A penetration test is a tailor-made operation. In fact, it is possible to test all the components of your internal network, or to focus on the elements most at risk, depending on the need identified.
During an internal penetration test, the pentesters’ objective will be to find all types of vulnerabilities that could compromise the confidentiality and integrity of stored and exchanged data, as well as the continuity of an organization’s activities.
The tests cover (but are not limited to):
- Servers
- Network equipment
- Workstations
- WI-FI
- Active Directory
For more information, take a look at our article exploring the most common vulnerabilities and attacks on the network infrastructure.
Internal network penetration testing methodology
The methodology will depend on the chosen scenario (black box or grey box) and whether the network has an Active Directory. In both cases, however, the pentester will first perform a network reconnaissance and discovery phase.
Reconnaissance and discovery of the network
During this phase, the pentester looks at its position in the network and the equipment around it. He will list the type of equipment, the services exposed and passively listen to communications. In this way, he can identify:
- Exposed servers or services and their version.
- Exposed services not requiring authentication.
- Communications not using signature or encryption.
- Position of sensitive servers on the network.
- The presence of other networks (VLANs).
Following this reconnaissance, the pentester can launch the corresponding tests for each scenario.
Black box penetration testing of an internal network (scenario of an attack without an account)
Detecting and exploiting vulnerable services
In the absence of a valid account, the pentester will concentrate its efforts on attacks requiring no authentication. This involves analyzing exposed services or servers and their versions. This analysis will be used to detect publicly known vulnerabilities affecting non-updated network components.
Indeed, for an attacker, the presence of non-updated components represents a potential entry point. Some publicly known vulnerabilities have a strong impact on components or servers, such as remote code execution (RCE).
To detect them, the attacker simply needs to enumerate the versions of accessible services or operating systems, and compare the observed versions with databases of known vulnerabilities.
Taking the Windows operating system as an example, a non-updated version can enable an attacker to gain administrator access to the machine without prior authentication. Many publicly known vulnerabilities, such as Eternal Blue (MS17-010), are still being discovered during our audits. They are the direct consequence of a deprecated system or an insufficient update policy.
The example given for Windows machines applies to all network systems and services. The presence of non-updated systems is therefore a highly likely point of entry for an attacker without an account.
Communication eavesdropping and replay without signature or encryption
Given his position within the network, the attacker has the means to passively or actively eavesdrop on network communications.
This generally involves poisoning protocols such as ARP, NBT-NS or LLMNR.
In this way, the attacker will be able to observe and analyze network traffic even if his machine is not the initial target of the exchanges. The pentester will then be in a “Man-In-The-Middle” position.
This listening can even become active by replaying specific requests. In the scenario of an attacker without an account (i.e. in black box), this is a particularly effective attack, especially in an Active Directory environment, with the NTLM Relay attack on SMB ports.
This attack is made possible by the absence of the SMB protocol’s signature mode.
The reasons why this attack is so effective are as follows:
- The SMB protocol is widely used in an internal network.
- The signature of this protocol is disabled by default.
- The consequences of an NTLM Relay attack are often unknown or underestimated.
To carry out this attack, the attacker simply needs to be present on the network and launch open-source tools. These tools will place the attacker in a “Man-In-The-Middle” position and relay the NTLM authentications observed.
The consequence is to obtain a valid SMB session on machines not requiring the signature. This operation is invisible to the victim user.
The impact of the session obtained will depend on the privileges of the victim user. If the user does not have administrator rights, then this session will only enable access to the file shares exposed by the targeted servers. However, if only one of the victim users has administrator rights, then the attacker will be able to use this SMB session to write or read all files, or retrieve all password hashes present on the target machine.
Depending on the nature of these hashes, the attacker can either break them to obtain the password values in clear text, or use them directly on other services.
In this situation, the attacker goes straight to the second scenario (attacker with account).
Even in the absence of the SMB protocol and an Active Directory context, unsigned or unencrypted protocols can also be replayed or listened to using other protocols. This is the case, for example, with the http protocol, which does not guarantee the confidentiality of exchanges.
If the network has web servers for internal use, but these do not use the secure HTTPS protocol, then the attacker will be able to obtain the content of client-server exchanges by simply eavesdropping on the network. As soon as credentials are exchanged, via a login page for example, the attacker will also have knowledge of these credentials and will be able to use them to access this service.
Access to services not requiring authentication
On a network, services are sometimes exposed without requiring authentication. This can happen, for example, when an FTP or SMB service allows anonymous sessions.
Under these conditions, the attacker can interact with the service to see if any sensitive information is exposed (files, keys, personal data, etc.). Sometimes, these services allow write access to these anonymous sessions. In this case, the attacker will have the opportunity to drop malicious files that could trick other users using the service. This is the case, for example, with the deposit of a malicious SCF file in an SMB file share.
Any user subsequently visiting the file share with Windows Explorer will attempt an SMB connection to a server controlled by the attacker. This connection will disclose a netNTLMv2 connection secret to the attacker. This secret can be used to calculate the user’s password.
The success of the calculation will then depend on the complexity of the user’s password. If the password proves insufficiently complex, the attacker will obtain the plaintext value of the password and can then reuse the account thus obtained in the 2nd scenario.
Testing the password policy
As already mentioned, the success of certain attacks will depend on the complexity of user passwords or network services.
While it is difficult in the first scenario to obtain an exhaustive list of all users, it remains possible for the attacker to try to connect to exposed services with default or highly probable identifiers. In this way, the attacker can search for the services or models of certain equipment to gain access to them.
We’re thinking here of certain printer brands or web interfaces accessible with the login combination “admin:admin”. Here, the pentester will use the results of the service enumeration phase as a basis, and attempt to find the most likely login/password combinations, within the limits of network policy.
At Vaadata, we take this a step further by recovering logins and passwords that have been leaked by an external source. For example, the LinkedIn professional social network leak, which took place in 2017. This type of leak has a chance of disclosing passwords that are still in use. A valid login then occurs if the user uses the same password both on external sites and to access his company’s internal service. In this case, the attacker will obtain a valid account and thus meet the conditions of the second scenario.
The password policy will also be put to the test every time the attacker intercepts a login secret or password hash. Indeed, the user’s plaintext password can be calculated from these secrets. Whether it’s hashes recovered from compromised workstations or hashes captured during NTLM authentication, the company’s password policy will make it more or less difficult to recover cleartext password values.
The application of a good password policy is therefore essential to ensure resistance to the attacks described above.
Grey box penetration testing of an internal network (scenario of an attack with an account)
Once an attacker has an account, he or she is able to access certain less privileged services. In other words, services that are accessible to any authenticated user. The aim of this phase is to check that these services do not expose secrets that could be used to escalate privileges.
In an Active Directory context, the auditor will look at the LDAP database, GPOs and service accounts.
Inspecting the LDAP directory
This directory, which is accessible to all authenticated users, contains the list of users and machines in the domain. In addition to providing useful information for the attacker to complete the enumeration phase, passwords are sometimes entered in the description field of LDAP objects. Inspection of these description fields is often fruitful in the discovery of new, valid accounts.
Another use of the LDAP directory by the attacker is the discovery of service accounts. Indeed, service accounts are privileged targets because of their behavior with the Kerberos authentication protocol.
Kerberoasting
This attack targets service accounts with important access rights. For example, an administrator account with the properties of a service account.
Once the attacker has a valid account, it is possible to request a Kerberos ticket to access domain services. This ticket can be requested even if the user does not initially have access to the service.
These tickets are generated using the secret (password) of the associated service accounts. A cryptographic logic enables the attacker to recover the original password of the service account if the complexity of the password is insufficient. This operation is known as the “Kerberoast” attack.
Compromising this password will allow access to a new account and associated services. In our example, this means that the attacker would have obtained the password to the administrator’s account.
Kerberos delegation
Another way to exploit service accounts is to abuse their delegation properties. The Kerberos authentication protocol allows a machine or service account to pretend to be another user. This principle, known as delegation, exists in several forms and has been constantly improved with new versions of Windows. The successive forms of delegation make configuration complex.
The consequence is that a misconfiguration of this principle can be exploited by an attacker to obtain an escalation of privileges. To do this, the attacker will spoof an account with higher privileges by compromising a service account or a machine capable of delegation.
Thus, the analysis of the players in this delegation is a point of attention to have for the pentester.
Inspecting Group Policies
These are group policies in an Active Directory domain. They determine the set of administration and configuration rules for the Windows machines in the network.
Detection of GPP “Group Policy Preferences” usage
One method of auditing is to inspect the SYSVOL file share for passwords. This file share, which contains group policy information, is readable by all users. Passwords can be exposed in this file share, either because they are present in plain text in scripts, or because they are defined in a “GPP” (Group Policy Preferences). Originally, GPPs stored secrets, ensuring their confidentiality.
However, following the sharing of the private key to the encryption algorithm on Microsoft’s public documentation in 2012, all the secrets stored by GPP can now be decrypted.
Analyzing Group Policy Objects (GPOs)
Another method is to identify problematic configurations that could lead to privilege escalation in the Group Policies themselves. For example, users with excessive and unnecessary access rights. Such misconfigurations are detected by consulting all Group Policies.
A tool for graphically displaying these strategies and other properties in the form of a graph will enable the pentester to detect attack paths and enumerate them, even in complex organizations.
ADCS (Active Directory Certificate Services) configuration analysis
The ADCS solution provides customizable services for issuing and managing the digital certificates used by software employing public key technologies.
In our case, these digital certificates can be used to authenticate computer, user or device accounts on a network.
Although the features provided by the solution greatly facilitate certificate management operations, misconfiguration of this solution can have an impact on overall domain security.
Indeed, the solution’s configuration will define how a certificate can be requested, by which entity and for what purpose. Certain problematic configurations of this solution will allow an attacker to generate authentication certificates in the place of other users, thus enabling the spoofing of the user account associated with the generated certificate. In this way, privilege escalation becomes possible.
Impact of various vulnerability exploits on an internal network
The various scenarios and tests presented are designed to assess the impact of an attacker on the audited system. At the end of the 2nd scenario, the auditor is able to assess the maximum impact of an attacker. This impact will depend on the level of privileges obtained.
A system that fails to protect itself from the attacks listed above is likely to allow an attacker to obtain the highest level of privileges.
In an Active Directory context, this refers to domain administrator privileges. Among other things, by obtaining domain administrator privileges, an attacker will be able to compromise all machines and accounts in the domain (user workstations, Windows servers, file sharing, etc.). However, the attacker’s impact generally doesn’t stop there. The disclosure of secrets present on domain machines generally enables the attacker to reach resources outside the domain.
We’re thinking here of website administration passwords, cloud environments and access keys to non-Windows systems. Also, an attacker with this level of privilege will be able to deploy malware across the entire network. This is the case, for example, with ransomware attacks.
Perform an internal penetration test with Vaadata, a company specialized in offensive security
It is important for any manager of an internal or Active Directory network to assess their network’s level of resistance to the attacks described in this article. This assessment can be carried out by one of the audits we offer. Whether black-box or grey-box, we can help you identify the weaknesses in your system and assist you in correcting them.
Contact us to discuss your challenges and requirements.
Author : Benoit PHILIPPE – Pentester @Vaadata