Pentesting Stories: Hard shell, soft center
Blog by Danut Niculae, Security Consultant Operations Center
Sometimes you’re pressed for budget, pressed for time, or both. SecureLink understands this. So, when a request is received along the lines of, “Could you just quickly invest a few days to check into something…”, it is taken seriously. A quick check is usually better than no check at all. In this case, SecureLink received a request to see what it could achieve if it invested a few days in this project. The goal was to assess what would happen if an attacker walked into the office and connected to the network.
Once we were connected, the first thing we saw is that we were in a Microsoft Windows Domain environment. It was up-to-date and patched. Now, one thing we know about Windows is it has a default trust model. This model represents: once you’re in, you’re trusted.
There are multiple ways to approach this model. One of our favorite ways is tricking a user with phishing into opening an email with a hidden malicious SCF file. This will include a link to an icon from our attacker’s computer. As the machine will retrieve the icon from an Service Message Block (SMB) connection, it first needs to identify and authenticate itself before we can retrieve the icon. Hence the NTLMv2 hashes will be broadcasted with the authentication phase, which then is ours. But we didn’t have this kind of time, and criminals trying to get to your things, won’t either. So, we used a different method.
The process to target was ‘Link-Local Multicast Name Resolution’ (LLMNR). This process allowed us to resolve names without being connected to DNS servers. It was built upon the default trust model and was enabled by default, so it could be exploited. While there are good arguments against LLMNR, and you can disable it, doing so will likely cause difficulties, especially with legacy applications. So, for all practical purposes, the process is always there.
If only we had a way to hijack LLMNR queries. The trick is to shout louder than your neighbor. “Hey, I know who this is!”. There is a nifty tool available for this, from SpiderLabs, an American company. Listening to queries and responding to the potential victim’s machine broadcast, that this machine is, in fact, the machine the queries are listening for. Because the victim’s machine and user belong to a domain, and so is the machine they are trying to query, the victim will send encrypted authentication credentials and identity validation.
We collected hundreds of password hashes this way. Using those hashes, we could relay them to another machine, accessible by a domain admin. As soon as the hashes are broadcasted by the administrator, we relay those hashes onto a machine and obtain the highest access level on a Windows machine; System.
As we now had access to a machine where the domain admin was on, we started scraping the machine’s memory. In particular the LSASS process, enforcing the security policy. From this memory scrape, we obtained the clear text password. domain.
With this clear text domain admin password, we again generated a ‘golden ticket’, which means complete domain compromise and persistence for many years.
Once we had a domain admin, we used a secondary technique called Domain Controller Sync (DCSync) which tells the Domain Controller (DC) that there is a secondary domain controller and that we like to synchronize users. The DC then sends us all the users in the system’s hashes.
In the end, using the LLMNR hijacking tool, we came into possession of almost everyone’s encrypted passwords, in this case thousands. Just to be sure, we tried to crack them in our offices, to check for alternate processes to gain persistence. We were surprised to discover, that only within a few days, we had managed to crack half of them, on humble hardware. This meant, even if the initial compromised accounts were blocked, or disabled, we would have several ways back into the domain.
The Golden Ticket attack is used by threat actors to obtain domain persistence. The technique leverages the lack of validation on the Kerberos authentication protocol in order to impersonate a particular user, valid or invalid. This is due to the fact that users who have a Ticket-Granting Ticket (TGT) in their current session are considered trusted by Kerberos and therefore can access any resource in the network.
This was a typical case of ‘hard shell, soft centre’. As soon as the organisation provided us with network access and a room to sit in on site we were already in the soft centre, and within a day the domain was fully compromised. This is due to various issues with the ‘soft centre’ architecture: there was limited segmentation, an open trust model and an open network.
On top of this, the simple breaking of thousands of passwords, meant that many passwords could then be ‘guessed’. Using several libraries of known passwords, we obtained half of them. There’s always a balance between usability and password complexity, but here the balance was clearly not right.
A few days is generally too short a time for a thorough, valuable assessment of an application or architecture. However, in this case an initial proof of concept allowed the customer to justify a budget for a more in-depth assessment. It helps us that the security community continues to share great tools but bear in mind criminals can access these tools too.