Tuesday, August 8, 2017

Week of Evading Microsoft ATA - Day 2 - Overpass-the-hash and Golden Ticket

Welcome to Day 2 of Week of Evading Microsoft ATA. The week has been split in the following days:

We left Day 1 with admin access to the box where a domain admin (DA) token is available. The next step is to get access to the credentials of the DA. Here, credentials could be clear text password, NTLM hash, AES keys, user token etc. 

Overpass-the-hash
Let's pull hashes for the DA "tempDA" using Invoke-Mimikatz:
Once we have access to the NTLM hashes, we can use Overpass-the-hash attack to create a Kerberos ticket and access resources and services as tempDA. From an administrative shell:
We now have DA privileges! Nice, isn't it? Not really! ATA caught us:
What now? If we read the detection, it says "The encryption method of the Encrypted_Timestamp field of AS_REQ message from OPS-USER11 has been downgraded based on previously learned behavior." Ok. Let's investigate this!

Let's see how the Encrypted_TimeStamp (in the PreAuthentication Data) field of AS-REQ message looks like when normal authentication (cleartext password) is used:
Now, below is how the same filed looks like when we use NTLM hash for Overpass-the-hash:
So, the encryption type downgrade is quite evident from the screenshots above. How to avoid this downgrade? By using AES keys! Use below command to extract AES keys from a remote computer:
And then use the below command to use it for Overpass-the-hash (note that we can use whatever AES128 keys if they are not available). It is always advisable to use all the hashes:

Bingo! We have elevated our privileges to DA and this doesn't get detected by ATA!

Please note the following from Benjamin's post: "AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with KB2871997, in this case you can avoid NTLM hash."

Another detection of Overpass-the-hash, as seen in the screenshot above, is "Unusual protocol implementation". I _believe_ that this detection is because of another field (supported encryption) in the AS-REQ packets. Can't confirm this and will welcome more research and comments on this:
Another interesting thing to notice is, we can use Overpass-the-hash for generating false alerts on ATA! Failure events can be generated for any user, even a non-existing user, in the domain. Any made-up NTLM hash can be used for this.


Golden Ticket
Once, we have access to DA, let's establish persistence in the domain. We can create a Golden Ticket for that. Let's pull the RC4/NTLM hash of krbtgt account from the domain controller to create a golden ticket.
Let's create a golden ticket and inject it in memory. As soon as a resource in the domain is accessed, ATA will detect the golden ticket as:
Similar to Overpass-the-hash, ATA looks for encryption downgrade. Since golden ticket is a TGT, the focus is on TGS-REQ packet. Let's have a look at the encryption method of the TGT field of a TGS-REQ in case a user accesses a resource normally:
And this is how a golden ticket generated using NTLM hash of krbtgt looks like:
Clearly a downgrade. How to make a golden ticket appear normal? Right! AES keys once again!

Let's use "/inject" option of the lsadump::lsa module in mimikatz:
"/inject" provides additional credentials. How? Why? See this post.

Once we have the AES keys, a golden ticket can be generated and used without detection:

Another Golden Ticket Bypass
Previous one is not the only golden ticket bypass! When I found out the next one, I couldn't believe it!

We can actually avoid golden ticket detection while still using RC4/NTLM hash of the krbtgt account by using a non-existent username!
In ATA 1.8, ticket lifetime based detection was introduced. "If a Kerberos ticket is used for more than the allowed lifetime, ATA will detect it as a suspicious activity" - What's new in ATA version 1.8

Now, let's hold our horses and think. Why should we save a golden ticket to disk at all? It is the no-change of krbtgt hash which provides the persistence and NOT the golden ticket. We can always create a golden ticker whenever there is a need to access a resource, just keep the krbtgt hash handy!

Also, we can set lifetime of the ticket while creating a golden ticket. Enumerate the Kerberos policy using (Get-DomainPolicy)."Kerberos Policy" from PowerView. The default ticket lifetime is 10 hours. In the lab, it is setup as 1 hour. To avoid using a ticket beyond lifetime we can use the following options. The golden ticket create in the below command is valid for one hour after two hours from the time of creation and can be renewed during 7 days (10080 minutes):
Make sure that you purge the golden ticket from the target box otherwise ATA will detect it.

That is all for Day 2. Hope you liked it! :)



2 comments:

  1. Very interesting! Wrote some articles on kerberos and tickets too:
    https://decoder.cloud/2017/06/30/from-pass-the-hash-to-pass-the-ticket-with-no-pain/

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete

Note: Only a member of this blog may post a comment.