In this case study our client is an international company with thousands of workstations and servers in total at different premises. These hosts are organized in several domains and the domains are collected in a common domain forest. Our client wanted to know how big threat a malicious employee with minimal access would present to the systems of the company. At the same time he also wanted to test the IDS and IPS solutions being introduced in practice.
What can we do if we, as responsible decision makers, wonder how our systems in whole would react to a real attack? It is easy to see that the traditional vulnerability assessment is not the best choice in this case, as it is more like a security audit than a real hacker attack. Whereas the goal of the red team testing approach is to provide the client with a realistic picture of how efficient the introduced policies and how well-trained the IT specialists are, and what level of safety awareness the employees have in general. Accordingly the red team testing is the simulation of a real attack, which is only known to a small group of insiders at the customer. In the course of the simulation the attacker’s goal is usually to compromise the client’s system to the greatest possible extent without causing intentional damage of course.
The team of Boltonshield has already gained many years of experience in the field of red team testing and seen a lot of interesting cases during several successful projects. It is important to note that the starting point for the red team testing projects is always subject to agreement. Before making a decision we have to identify the client’s needs and also the possible directions of the attacks that the systems are most exposed to.
In the case used for the study the red team testing lasted a week according to our agreement. The project ends prematurely in case we manage to prove that the system can be compromised decisively or our activity gets discovered.
We jumped over the moat
At the beginning of the red team testing we got our own office where we could work without interruptions. With the exception of the insiders all employees received the information that we would undertake an audit in connection with the company procedures.
After the inspection of the available network ports it was quickly clear to us that a port-based Network Access Control (PNAC) is implemented on our client’s network in accordance with the IEEE 802.1X standard. It can be an efficient tool with the appropriate configuration settings, as it is able to detect and block that anyone gains access to the network. However, as in the case of all protocols, it has its weaknesses too. It can be evaded the easiest if we look for devices connected to networks which presumably do not support this standard. Since the operation of these devices must also be ensured somehow, they are generally managed as exceptions. In the course of the process the devices are identified based on their MAC addresses, and then they can legally connect to the network even without proper authentication.
The overwhelming majority of the network printers still do not implement all NAC standards, so they can be attractive targets. In one of the remote corners of the room we could find a network printer which was only trapping dust. Connected to the nearest network port it immediately got an IP address from the DHCP server, which means that its MAC address was still considered an exception on the authenticator server.
Although the printer did not display the MAC address on its control panel, by using a hub we managed to get in between the printer and the network passively. This way we could intercept the communication between them and get a valid MAC address in a very short time. With the knowledge of this MAC address we could also connect to the network.
So we could beat the first line of defense successfully. Since some of us wanted to work simultaneously but we only had one valid MAC address, we converted one of the machines practically into a router. All other machines participating in the assessment communicated with the network over this single host.
The walls collapse
After the successful connection we could start to explore the network. We had to pay special attention not to act with too much “noise.” If our activity gets discovered, it could have put an end of the project easily. This practically meant that we were not allowed to use most of the active reconnaissance techniques. That is why at first we tried to identify the vulnerable workstations and servers by the passive interception of the network traffic.
After a short period of time we already had some access routes of network file sharing and the IP addresses of some workstations, so we started their assessment. While we were analyzing the shares more thoroughly, we discovered something interesting.
Freely accessible network sharing
The share called ADBackupManager was completely different from the others, which was publicly accessible to everyone. In the share we found an executable file, some DLL files and a database file, too. Based on the name of the share we thought it would be worth examining these files more extensively. With the use of reverse engineering techniques we managed to decrypt the application practically to its source code. Thereby we learned that the purpose of the application was the preparation of the back-ups for the network share set. For the proper operation the application also needs a domain level access. This access was stored in the database in encrypted form. Since the decryption algorithm and the necessary key were hardcoded into the source code of the application, we could decrypt the encrypted password easily.
Encrypted password stored in a databaseDecrypt function with IV parameterCall of decrypt function with the hardcoded key
We checked the access quickly and found it was valid. At this point we could communicate with the domain server in an authenticated way which was the next important milestone.
Castle captured
With the access we could query all the users of the domain, their groups and the valid ACL Access Control Lists (ACL), too. The next step was the execution of the attack called “kerberoasting,” in the course of which we requested service tickets for the service accounts of the domain with the help of our valid access. Each ticket is encrypted with the NTLM hashes of the given service accounts. It gives us the chance to try to decrypt the acquired tickets by testing millions of passwords offline. If a ticket can be decrypted, then we also obtained the password of the given service account. In our experience the service accounts protected with a medium weak password can be cracked rather fast in this way.
Successful ticket query
We managed to request a service ticket for a service account, for which an admin flag was set. In general the service accounts are privileged domain accounts, but the existence of the admin flag strongly indicates that the given user may have even more privilege. We finally managed to crack the service ticket of the svc_backupmgr user just within an hour. After a quick query we also learned that the given user belongs to the “Backup Operators” group.
Privileges of the svn_backupmgr user
With this user we could log in to one of the domain controllers over the “winrm” service. The privilege escalation was practically obvious with the backup privilege. In the course of the first step of the attack we queried the SAM and SYSTEM hives from the registry. In the next step we retrieved the NTLM hash of the local administrator user out of the hives. With the hash we could log in to the server even without knowing the password by using the pass-the-hash technique, this time with an administrator access, as well.
SAM and SYSTEM hive retrievalTaking a snapshot of the NTDS
With the proper privileges we could take a snapshot of the NTDS which contained the password hash of all domain users.
At this point it could be established that the domain was fully compromised. We acquired the hashes of thousands of users, including the domain and enterprise administrators. Armed with the acquired authentication data we would have had the privilege to carry out any action in the domain in several premises of the company.
A complete surprise
The coexistence of following severe vulnerabilities made the successful attack possible:
defective physical security (open network ports)
presence of NAC exceptions (long unused device still on the list of exceptions)
network share with sensitive content publicly accessible to anyone
use of authentication hardcoded data
service account protected with a weak password
too much privilege provided for service account (remote log over winrm)
In the course of the red team testing project we carried out almost only actions for which the users of the domain have the privilege normally. Accordingly we did not cause any security incidents or alerts in the client’s IDS and IPS devices.
When just after a few days we presented our results to our client’s decision makers, they were very much surprised. As they say they asked the relevant specialists several times if they experienced any suspicious incident but they repeatedly got a definite no as an answer.
The results confirmed our client, parallel to taking the instant measures, that he should ask us to perform a full-scope internal assessment. In the course of the red team testing several critical vulnerabilities were revealed and based on the results of the multiple-round joint cooperation it can be established that the security level of our client’s system improved significantly shortly afterwards.
You can get in touch with us to find out exactly how Boltonshield can help your organisation.
The coexistence of following severe vulnerabilities made the successful attack possible: