Internal Pentest : The delay that helped migrate our Meterpreter session to meet the Domain Controller
Background
Last few months, our team were engaged to perform penetration testing against a medium size organisation. Their objective is to determine how far a threat actor could do if remote access has been compromised. They requested us to not use any advanced obfuscation techniques at the early phase of the testing as they would evaluate the security software that their company recently subscribed to protect their employees’ devices from unauthorised activities. Let us name that product T, the Endpoint Protection & Security.
Proposal
We proposed to conduct an internal penetration test where we included the following items:
- Standard vulnerability scanning using commercial and open-source tools. This is to cover known vulnerabilities and unpatched systems.
- Escalation assessment. This is where we determine to what extent the attacker could do in then event the remote access of an employee has been compromised.
Vulnerability scanning
We scanned using Nessus, Nmap and other tools. Boring but they are still helpful for our client to ensure their systems are well examined.
Escalation assessment
We were provided with a low-access domain user (user-R) after we were able to demonstrate one SQL Injection vulnerability that we discovered on one of their public assets which allowed us to get some of their employees’ valid credentials.
As usual, we started by gathering information and enumerating the network from the host that we were given access. It started getting interesting when some of our scripts were blocked and quarantined by the T software. We further investigated it and found that T only performed that when it detected the scripts or files originated from unknown sources. We were able to overcome this by fake-signing our Meterpreter executable file.
However, we noted other than that, it will as well quarantine the file when it detected suspicious process/activity being executed by that file.
While investigating T’s behaviours by planting our Meterpreter executable file, one of our team members noticed that there was actually a slight delay (3-4 seconds) before the file will be deleted once it has been executed. That looked odd. We utilised Meterpreter’s Post Manage modules, post/windows/manage/migrate to abuse this slight delay. Surprisingly, it worked and we managed to get a stable Meterpreter session!
At this stage, we managed to complete half of their objectives. Then, we further evaluated how extent the threat actor can do from there.
Path to DA
We ran Bloodhound to determine paths that we can use to compromise a domain administrator. From the map generated, we observed there were several users created with the domain administrator access. That was the shortest path as suggested by Bloodhound.
Through the Meterpreter session we obtained, we were able to compromise another user that has a local administrator access on its machine, user-E. We sprayed user-E credentials across the networks and observed that user-E was as well a local administrator on other several machines. Using crackmapexec, we dumped available credentials in the hosts’ memory and was able to gained a hash belonged to one of the domain administrator users.
Conclusion
Overall, this organisation’s security was pretty well hardened. Appropriate security measurements were in place and their small IT team did a great job plus helpful throughout our testing. This was their first time asking a company to conduct the escalation assessment and we were happy to receive good feedback from them.
We suggested the following to them to further increase their security posture:
- Revisit the T product manual and see if the delay can be removed and ensure stricter rules to be implemented. We felt that the vendor did not carefully configure the rules but instead leave the product run using its default settings.
- Consider to have monitoring team or subscribe to an external Security Operation Center (SOC) services.
- Improve their password policies.
- Prevent their users from reusing same password across their accounts
- Reduce the numbers of domain administrator users and ensure they are only assigned to IT security members when possible. As for their mid-size organisation, a few numbers of domain administrators are sufficient.
