Introduction
During these quarantine times, our team focusses on creating new updated topics for courses, analyses evasion, and threat hunting methods. For doing better threat hunting it is essential to know even better than the attacker.
We regularly research bypass methods, and separately combine our findings with tactical abilities like hiding and to operate undetected in our AD lab drills. Attacks like PTH, PTT, golden ticket abuse are still very alive, easy to implement, hard to detect when done properly.
In this writing, we analyzed Microsoft ATA, bypassed it, hunted the packets and recommended mitigations in the end. We greatly benefited from Nikhil Mittal’s past writings on this topic.
What is Microsoft Advanced Threat Analytics?
Microsoft Advanced Threat Analytics (ATA) is based on Microsoft’s Aorato acquisition and provides a solution to help protect your organization from advanced attacks. The key methods to detect attacks are:
- Detection for known malicious attacks and security issues – Known attacks such as pass-the-ticket, pass-the-hash, brute force and so on.
- Behavioral Analytics – Learning the normal patterns of users and the devices they use. Patterns outside the normal will be flagged such as using different devices or working different/longer hours. This is enabled through machine learning and data from Active Directory. A great example of this working would be the Snowden case where all of a sudden he used his credentials to access huge amounts of data instead of the regular data accessed.
We have installed the latest version of Microsoft ATA 1.9.7 on our DC and added Domain Admins, Users, Guests and IT Service Account (Domain Admin) to sensitive accounts/groups list, in short, we add everything to sensitive accounts list to make ATA more aggressive on detections.
Boring Stuff Before We Start
What is Kerberos?
It is mandatory to understand Kerberos and NTLM authentications before diving into MSATA bypass and overpass the hash.
Back in time, NTLM hashes were being sent to servers for authentication. By using it, attackers could easily get NTLM hashes from the network and pass the hash or crack them. Therefore NTLM authentication replaced by Kerberos to make network authentications secure.
Kerberos is an authentication protocol, it allows us to identify users, who provide a secret password.
Kerberos is used in Active Directory. In this platform, Kerberos provides information about the privileges of each user, but it is the responsibility of each service to determine if the user has access to its resources.
- KRB_AS_REQ: Used to request the TGT to KDC.
- KRB_AS_REP: Used to deliver the TGT by KDC.
- KRB_TGS_REQ: Used to request the TGS to KDC, using the TGT.
- KRB_TGS_REP: Used to deliver the TGS by KDC.
- KRB_AP_REQ: Used to authenticate a user against a service, using the TGS.
- KRB_AP_REP: (Optional) Used by service to identify itself against the user.
Kerberos authentication in wireshark.
- For ATA evasion most important packet to understand is the KRB_AS_REQ.Inside the KRB_AS_REQ, the user sends;
- A timestamp encrypted with the client key (NTLM or AES), to authenticate the user and prevent replay attacks (This is important)
- Username of the authenticated user
- The service SPN associated with krbtgt account
- A Nonce generated by the user
KDC decrypts the timestamp with the hash it gets from DC. Here user hashes are used as the key for symmetric encryption since both parties have access to it. If users hash is correct then it provides the user a session key and the rest of the authentication continues. For more details, you can read from https://www.tarlogic.com/en/blog/how-kerberos-works/
Overpass the hash uses the same mechanism and authenticates as the user with its hashes.
Bypassing Over Pass the Hash Detection
Let us begin, first, our team tried the common over-pth to see the ATA alarm.
Dumping user keys
Over-PTH with NTLM hash, then connecting to DC with the TGT ticket obtained.
When we checked ATA we got the alert. The alert was saying that there is a unusual protocol implementation.
Inorder to compare, we tried the same command normally with credentials this time and compared their network traffics.
When compared, all packets were the same except for one, which is the first packet that the client send, AS-REQ.
Their timestamps were encrypted with different keys and they had differences in req-body etypes.
It was observed that over-pth uses ARCHFOUR-HMAC-MD5(NTLMv2) for encrypting the timestamp, on the other hand, our second credential access AS-REQ used AES256-CTS-HMAC-SHA1-96.
Encrypting timestamp with HMAC-MD5 was still a valid method so it works but newer windows systems use AES256 key of the user. This was how ATA caught and flagged the over-pth as possible malicious.
AS-REQ packet of the over-pth;
- Timestamp was encrypted with HMAC-MD5 (NTLMv2).
- There were 7 etypes under req-body, 2 of them were null and ARCHFOUR-MD4 was used.
A normal AS-REQ packet;
- Timestamp was encrypted with HMAC-MD5 (NTLM).
- There were 6 etypes under req-body, AES256 and AES128 were implemented and ARCHFOUR-MD4 was not used.
Solution
Implement AES256 and AES128 keys and make over-pth Kerberos authentication just like a normal one.
Yeah this would work but there was a problem, users AES128 key was not inside client computer memory there was only AES256. Making a request only with AES256 didn’t work and still flagged as malicious by ATA.
It turns out that you can use false AES128 and NTLM keys if your AES256 key is correct. So your timestamp will be encrypted with AES256 key of client and your AS-REQ req-body etypes will implement AES128 and NTLM.
This is how OverPTH evasion payload looks like. Only client administration required and pass the hash still very much lives.
Bypassing Krbtgt Golden Ticket Generation
To generate a golden ticket, krbtgt user key is required. We obtain it remotely by using dcsync for user krbtgt.
Dcsync attack were flagged as malicious.
Instead we can overpth to a privileged account then login to domain controller and dump the krbtgt hash from DC by using lsadump::lsa. This time it was not detected. (Although this bypasses ATA it is a loud way to get krbtgt keys, so it is not a good idea to use it directly in a red team ops, but again our purpose it to bypass ATA here.)
After getting the krbtgt users keys, we generated a golden ticket for carlie.tran(low privilege user) with krbtgt’s NTLM hash and used it.
When used this activity flagged by ATA as following, similar to overpth detection. Although krbtgt key was acquired, attack was flagged as malicious.
When the TGS-REQ packet was analyzed, it is observed that encryption etype used was ARCH-HMAC-MD5 which is an old one.
Solution
Use AES keys instead of NTLM while generating golden tickets. Krbtgt AES keys can be found inside sekurlsa::ekeys output.
When generated with AES256, we can see that tickets Encryption Type is changed also and when used ATA did not catch it. (Mimikatz generates golden tickets for 10 years default, this wasn’t detected in our labs by ATA but an erroneous thing to do in red ops).
Mitigations OverPTH and Golden Ticket Abuse
Mitigation 1: Restrict and protect high privileged domain accounts
Some organizations allow high privilege accounts like those that are members of the Domain Admins group to perform general administration tasks or to log on to user desktops or other systems used for email and Internet browsing, potentially exposing these credentials to attackers. We recommend restricting highly privileged accounts so that they can only be used to log on to sufficiently secured systems that require them. Also, allowing the use of Kerberos delegation with privileged accounts can make it easier for an attacker to reuse them to access additional network resources.
Main objective: This mitigation reduces the risk of administrators from inadvertently exposing privileged credentials to higher risk computers. Domain administrators logging onto a compromised computer may still briefly expose their credentials even if the recommended tasks bellow are implemented. Attackers can capture these credentials during logon despite the account not being authorized to successfully logon.
How:
- Restrict domain administrator accounts and other privileged accounts from authenticating to lower trust servers and workstations.
- Provide admins with accounts to perform administrative duties that are separate from their normal user accounts.
- Assign dedicated workstations for administrative tasks.
- Mark privileged accounts as “sensitive and cannot be delegated” in Active Directory.
- Do not configure services or schedule tasks to use privileged domain accounts on lower trust systems, such as user workstations.
Outcome:
An attacker cannot steal credentials for an account if the credentials are never used on the compromised computer. Using this mitigation significantly reduces the risk of attackers compromising privileged accounts.
Mitigation 2: Restrict and protect local accounts with administrative privileges
Accounts with administrative access on a computer can be used to take full control of the computer. And if compromised, an attacker can use the accounts to access other credentials stored on this computer. In addition, many organizations have deployment and operational processes that result in defining the same administrative local account and password on many computers. Maintaining identical passwords makes it significantly easier for attackers to compromise all computers that use them and obtain all credentials stored on these computers. IT support processes typically do not require the built-in local administrator account to log on over a network connection, which is a common attack vector for lateral movement using credential theft. Note: If all administrative local accounts are already disabled, the steps in Mitigation 2 are not required. Specific instructions for disabling accounts are not included in Mitigation because implementing this strategy requires a design tailored to how your organization supports local and remote users.
Main objective:
This mitigation restricts the ability of attackers to use administrative local accounts for lateral movement PtH attacks.
How:
- Restrict domain administrator accounts and other privileged accounts from authenticating to lower trust servers and workstations.
- Enforce the restrictions available in Windows Vista and newer that prevent local accounts from being used for remote administration.
- Explicitly deny network and Remote Desktop logon rights for all administrative local accounts.
- Create unique passwords for local accounts with administrative privileges.
Outcome:
An attacker who successfully obtains local account credentials from a compromised computer will not be able to use those credentials to perform lateral movement on the organization’s network.
Additional recommendations
- Change krbtgt users password regularly
- Check for golden tickets with abnormal lifetimes.
- Do not allow browsing the Internet with highly privileged accounts Internet activities, such as browsing the Internet and reading email
- Remove standard users from the local Administrators group.
- Configure outbound proxies to deny Internet access to privileged accounts.
- Ensure administrative accounts do not have email accounts or mailboxes associated with them.
References:
- https://www.microsoft.com/en-us/download/confirmation.aspx?id=36036
- https://www.blackhat.com/docs/us-17/thursday/us-17-Mittal-Evading-MicrosoftATA-for-ActiveDirectory-Domination.pdf
- https://docs.microsoft.com/tr-tr/advanced-threat-analytics/what-is-ata
- https://cert.europa.eu/static/WhitePapers/UPDATED%20-%20CERT-EU_Security_Whitepaper_2014-007_Kerberos_Golden_Ticket_Protection_v1_4.pdf
- https://www.tarlogic.com/en/blog/how-kerberos-works/
- https://answers.microsoft.com/en-us/msoffice/forum/all/ntlm-vs-kerberos/d8b139bf-6b5a-4a53-9a00-bb75d4e219eb