Pentest Findings & Mitigating Controls

What Enables the Kill Chains for Total System Compromise

At NopSec my red teaming service team never stops amazing me in every single engagement! In a recent red team engagement the team was able to compromise the entire domain starting from a single web vulnerability. This blog post summarizes the story of that compromise and more interestingly tries to understand which mitigating controls failure or success enabled or slowed the spreading of that system compromise to lead to the total Windows domain compromise.

Everything started with network mapping. The red team member detected some web applications used for HR and Procurement purposes. Right in the login screen the consultant identified an exploitable SQL injection vulnerabilities which allows him to dump the backend database username and password tables. In this case, the passwords were encrypted at rest and the mitigating control did not allow the consultant to get access to the password in clear. In this case, the mitigating control and the defense-in-depth worked to prevent and/or slow down the compromise.

The consultant then moved on to analyze other aspx script mapped to the same web server. S/he particularly found a web application that was prone to another SQL injection. This time around the extracted password were not encrypted and the consultant successfully extracted credential pairs that proved to be also Windows domain credentials. In this case, the mitigating control of password encryption is not enabled and allowed the consultant to find Windows domain credentials in clear from the back-end database.

At this point, the consultant moved from web application compromise to lateral movement.

With the gathered domain credentials, he tried to login to any other SMB host in the domain. Eventually, he was able to login into one and found that with those credentials. S/he had access to a SMB with READ/WRITE privileges. This SMB share was also the web root of another web application. In case, the credential reuse across the domain was the control failure that enabled the access to the share.

Leveraging the WRITE privilege access to the SMB share, pen tester uploaded a web shell that enabled the command execution to the host. Once pen tester had access to the host in an unprivileged mode, s/he tried to elevate privileges to SYSTEM unsuccessfully. In this case, the endpoint security solution installed on the host prevent the successful privilege escalation to SYSTEM and it proved to be an effective risk mitigating control.

The consultant then probed other systems with the same logins to see if he was able to gain local administrative access. S/he eventually found one with SYSTEM access. Once s/he got access to this system, s/he probed domain systems where a number of domain administrators logged in. 

Using gathered credentials the consultant also logged in as a local administrator to one of those hosts identified above. Having SYSTEM privilege, s/he used Mimikatz in-memory credentials scraping capability to gather credentials in clear for a domain administrator. Here the mitigating control failure was procedural, in the fact that the domain administrator account should not log into systems arbitrarily throughout the domain but should only login in specifically hardened workstations.

With the domain admin credentials at hand, pen tester moved for the kill and logged into the domain controllers and dumped the contents of the “ntds.dit” file. The “ntds.dit” file contains the username and NTLM hash of all domain users, which granted the consultant unauthorized access to the credential data of all users and systems in the targeted domain. This represents the total compromise of all domain users and systems.

It is interesting to see in this example which steps in a kill chain could be stopped or enabled by the working or failure of mitigating controls.

In this case the following security mitigating controls prevented the successful execution of kill chain steps:

• Encryption of passwords in the database at rest;
• End-point security solution prevented the privilege escalation to SYSTEM and prevented privilege access to the host.
• Certain system did not have local administrator shared credentials across the domain.

In other cases, the security mitigating controls were missing and allowed the compromise to continue to spread across the domain:

• Web application scripts vulnerable to SQL injection vulnerabilities;
• In other cases, the passwords were not encrypted at rest in the databases;
• Shared local administrator credentials allowed access to the hosts with SYSTEM privileges;
• In certain cases, end-point security solutions did not stop privilege escalation and credentials in-memory scraping through Mimikatz
• Domain administrators logging into arbitrary hosts throughout the domain for administrative purposes.

You can see from this use case, that regardless of the vulnerability or security misconfiguration found and exploited by an attacker, the mitigating control conditions or their failure thereof are the determining factors that enable a compromise to continue or getting stopped on their track.

We at NopSec are in the process to map specific vulnerabilities and misconfigurations with the corresponding mitigating controls that would stop the exploitation of their track. Essential to this exercise is the gathering of relevant host-based host and network information representing security controls for each or multiple vulnerabilities. We will update you further on this effort down the road as we are also enabling our Unified VRM platform to be “intelligent” about the status of a certain organization’s mitigating controls related to specific vulnerabilities exploitation risk.