Transcript
Today we'll be taking a look at the ASREP Roasting attack on Active Directory. ASREP Roasting is a low-skill attack that takes advantage of Active Directory accounts that have Kerberos Preauth disabled and can be executed by any authenticated AD user. For an account where Kerberos Preauth is enabled, when the ASREP call is made for a ticket granting ticket, a TGT, to the key distribution center, the KDC, it includes a timestamp and the user's password. Both of which are encrypted. If both are valid, then the TGT is sent back along with the user's password hash. This prevents both unauthorized requests and Kerberos replay attacks. However, in the case where Kerberos Preauth is not required, the ASREP request does not include the timestamp or password and only contains the UPN of the user account that is requesting the TGT. And so the request does not require the user's password. The KDC will happily return the TGT along with the hash of the user's password. So that means we can make this request for a user account to which we do not know the password and the hash is returned to us. Once we have the hash, we can use any of the various brute force tools to get that password out of that hash. This is why enforcing complex passwords is critical for any business. Tools like Netflix Threat Prevention and Netflix Password Policy Enforcer can prevent your users from using simple and easy-to-break passwords, along with tools like Netflix Enterprise Auditor to validate secure passwords across your organization, even for service and administrative accounts. So why would anyone ever even disable Kerberos Preauth? Well, the typical recommendation from Microsoft is to never do it. However, some legacy applications may require it, or maybe there are legacy accounts in your domain that have been around forever and have never been updated to enable Preauth, or various applications in the past have caused certain issues and the workaround was to disable legacy Preauth, and perhaps those users never got updated after the workaround was no longer needed because the problem had been solved. Okay, let me show you how all this works. I will connect to my machine here, and I am logged in as Abby Lien. Abby is a domain user with no domain admin rights and no local admin rights. Presume for the sake of this demo that I was able to either socially engineer Abby into giving me her password, or perhaps Abby is a disgruntled employee that's looking to cause as much trouble as she can for her company. The first thing we're going to do is a bit of reconnaissance. Let's run a quick check using PowerShell to see if any accounts exist in my domain that have Kerberos Preauth disabled. All right, so we see here that we have two accounts that do have Kerberos Preauth disabled, and we can also see the groups each account is in. Eric at the bottom here doesn't seem like an interesting target to us, but luckily this a-franksmith account is a member of domain admins. Now that we have a target in mind, let's use Rubius to make the ASREP call to the KDC to get the ASREP answer with the TGT and, of course, the hash of the password that we're after. So I already have Rubius installed on my system, so let's go there, and we will call Rubius with a couple of command line arguments here. So the first one is going to be ASREP roast. Then we're going to specify our target account, so that's a-franksmith, and we want to specify our format to be hashcat since that's the brute force tool we'll be using to crack the hash. And now we need to specify the output file, so let's just call it hashes.txt. All right, so let's go ahead and run that. As you can see, it ran pretty quickly, and we should now have our hashes in this file. All right, so you can see we have username, and then we have the hash over here. All right, well, that's all we need. Let's exfiltrate this data and take it home with us tonight so that we can use a non-corporate-controlled machine to attempt to crack it. I'll be copying it to a USB drive, but if you have good data exfiltration policies to block USBs, a motivated attacker could simply just write this data down with a pen and paper. Anyway, let's copy this over and take it home. All right, well, I just got home with the data that I exfiltrated, so I've got my hash file here. So let's go ahead and plug this into the computer. All right, so here is the data that I've exfiltrated. This is my hashes file. So I've already gone ahead and downloaded and extracted hashcat. So I have hashcat on my local system here. Let's copy hash into this directory. I've also downloaded and extracted rocky.txt, which is a pretty standard password brute-force dictionary for use with tools like hashcat or JohnTheRipper. So I've got both of those in my directory here. Now we need to open up a command prompt. Let's go to that directory. So here I'm going to run hashcat.exe. We're going to specify an attack type of zero. Then we will specify the encryption type of Kerberos. Then we need to specify our output file. We'll call it cracked.txt. Then we specify our hashes file, hashes.txt, and our brute-force password dictionary. So let's go ahead and let this run. All right, so that finished pretty quickly. Let's just take a look and tell us what it says. So here is our hash target, our AFrankSmith account, and it was able to crack one out of one hashes in that file. So now let's take a look at our cracked.txt file. So here is our user, the encryption type, the encrypted data, and it has successfully gotten the password out. So now I know that I have this password to go with this account. So tomorrow when I'm back in the office, let's see if we can get into any trouble with this AFrankSmith account. All right, well, it's the next day, and now I'm back in the office. Let's see if we're able to do anything with this account, like, oh, say, perhaps RDP to our domain controller. So we'll pick a different account. It's AFrankSmith, and let's use that password that we got from Hashcat, and look at that. We're in. This is another step of this attack that could have been prevented with a tool such as NetRx Privilege Secure, which would have prevented us from having a standing administratively privileged account in our domain. Now, of course, we were lucky and found a privileged account with Priyat disabled, but, of course, an attacker could use this for lateral movement as well, finding an at-risk account, using it to move across the domain and network, using further attacks to get deeper and deeper into Active Directory. So it's not just administrative accounts that you need to secure. Anyway, that's the ASREP attack in a nutshell. It's low effort, low skill, difficult to detect, but it can be easily prevented with just a bit of work, and, of course, with the help of the NetRx suite of data security products. Thanks for watching this demonstration, and be sure to check out our attack catalog on www.netrx.com to see more videos like this one.
