Wednesday, August 9, 2017

Week of Evading Microsoft ATA - Day 3 - Constrained Delegation, Attacks across trusts, DCSync and DNSAdmins

Welcome to Day 3 of Week of Evading Microsoft ATA. The week has been split in the following days:
Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts
Day 5 - Attacking ATA deployment, limitations of research and mitigation

On Day 3, Let's see some more Kerberos attacks which can be used to bypass ATA. Also, since we already escalated to DA on Day 2, we will also discuss attacks across domain trusts which are not detected by ATA.

Constrained Delegation
Constrained delegation allows access to a service by impersonating *any* user if the service account is configured so (msds-allowedtodelegateto). You can read more about this attack here, here and here. All of the three are fantastic posts, please go through them to understand the attack.

ATA doesn't detect this attack.Why? Read on.

If we abuse unconstrained delegation with the help of Kekeo:

Request a TGT:
Request a TGS as Administrator using the above TGT:
Encryption type 0x17 means RC4-HMAC. See this article.

Now, is 0x17 an anomaly? Not really, even though AES has been introduced since Server 2008, service accounts, inter-domain tickets and inter-forest tickets still use RC4 encryption. So there is no downgrade for ATA to detect, by default, as far as TGS_REQ is concerned.

Once we have the TGS, it can be used in the current session to access the service:

Even if we force enable AES on the service account ATA doesn't detect it as we need to move the entire domain (trusts, legacy machines etc. still use RC4) to AES before 0x17 can be considered anomaly.

I think there is one chance of detection, while requesting a TGT, there is an encryption downgrade for the AS-REQ packet (see the screenshot above). But it is up-to the ATA team to tune-it and make the detection reliable.

Also, there is no detection for alternate tickets. It is possible to access any service running with the same service account as the service for which constrained delegation is enabled. See the section, "Server SPN target name validation level" in this article. That means, if we have access to a service like time on the domain controller using constrained delgeation we can request a TGS for a service like HOST (Schedule tasks and many others), RPCSS (WMI), CIFS (File server) and take over the DC completely and ATA won't detect it.

But please keep in mind that if we access the LDAP service and try to run DCSync attack (replication), ATA will detect it. In fact, during my testing, I found out that DCSync is one of those attacks which ATA rarely misses.
Above is based on my understanding of constrained delegation and service accounts. Please correct me if I messed up something :)

The ATA team commented that they are "currently working on detecting abnormal delegation usage".

Attacks Across Trusts

Let's discuss couple of attacks across domain trusts. Many attacks across domain trusts are not detected. That inter-domain tickets use RC4 is one of the reasons for this. We will discuss only two of most interesting attacks, escalation from domain to forest root and DCSync (replication) without detection.

Escalation from domain DA to forest root enterprise admin

It is well known that if we have DA access to one of the domains of a forest, it is possible to escalate privileges to the enterprise admin of the forest root. Read Sean's blog post here to understand the attack.

To use this attack, we just need the krbtgt hash of the current domain and some other information (domain SID, parent domain SID etc.) which is available to any normal user in active directory. We forge an inter-domain TGT, sign and encrypt with the krbtgt hash of child for validation and append SID history. When the parent DC receives this TGT for accessing a service in the parent domain, it reads the SID history and if it is set to Enterprise Admins, we are granted that privilege.

Now, this is how the network capture looks like on the child DC when the above attack is executed:
Because domain trusts use RC4 encryption by default what we see above is NOT a downgrade. To make this an anomaly, it will be required to enable the support of AES in the Trust properties in the Active Directory Domains and Trusts:
ATA currently does not take into account if AES is enabled for a trust.

DCSync across trust

As I stated earlier, DCSync is rarely missed by ATA. But if it is done from a chilld domain controller, DCSync is not detected by ATA which makes sense as domain controllers replicate stuff all the time. Since we escalated to Enterprise Admin above, we have sufficient privileges to do so.

First, using a golden ticket or overpass-the-hash, escalate privileges to DA on a member machine of child domain. Then run the below command from the member machine:
ATA does not detect this! :)

This makes it much easier to laterally move in the parent domain as we can extract AES keys and avoid detection later.

Abusing the DNSAdmins group membership

Another attack which is not currently detected by ATA is the ability to run remote code as SYSTEM on a Windows DNS server (or DC - if it works as DNS server as well). Read this post and this one by me for more details. Also, DNSAdmins is not a protected group :)

That is all for Day 3!




2 comments:

  1. Ex client work and i appreciate your information about the Social Engineering it's a good work.
    Social Engineering

    ReplyDelete

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