Your Knowledge Center for all Active Directory Security-Related Research

Pass-the-Hash

Overview
Pass-the-Hash (PtH) is an attack method where the adversary steals the hashed credentials of a user (or a computer) in order to authenticate, via NTLM, to various enterprise resources.

NTLM Background
NTLM is an authentication protocol used by Microsoft. All Windows versions older than Windows XP SP3 use NTLM as their default. Newer versions of Windows still use NTLM for backwards compatibility.

The NTLM authentication protocol works in the following manner:

PtH (1) 

 

  1. The user provides a Domain Name, username and password to access their computer.
    The computer computes a cryptographic hash of the password and discards the actual password.
  2. When the user attempts to access the server, the computer sends the username to the server in cleartext. 
  3. The server generates a 16-byte random number, called a “challenge”, and sends it to the user.
  4. The user encrypts this challenge using its password hash and returns it to the server (aka “response”)
  5. The server sends the following three items to the Domain Controller:
    a. User Name
    b. Challenge sent to the client
    c. Response received from the client
  6. The Domain Controller uses the username to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
  7. The Domain Controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful and the Domain Controller notifies the server.

From the above, it is clear that when an attacker steals the password’s hash then the attacker can impersonate the user (or computer) – authenticating on the user’s behalf – while all communication appears to be legitimate.

Pass-the-Hash Attacks in the Wild
Despite PtH ticket being an “old” attack, first published in 1997, the automation of hacking has allowed it to become much more prevalent. For example, common tools such as WCE and Metasploit have support to carry out PtH attacks in an automated manner.

Additionally, PtH is considered one of the key steps in many APT attacks. To quote Infoworld: “PTH goes hand-in-hand with the types of infamous APT (advanced persistent threat) attacks that have staggered companies such as RSA, Sony, Dupont”

Failed Attempts at Mitigating Pass-the-Hash Attacks
Defenses have aimed to take control of PtH attacks, but unfortunately, all have been defeated one by one. These include: 

  • Limiting access to the computer’s memory to retrieve the hash
    Since the hashes are stored in memory, many attacks relied on accessing the computer’s memory. This measure aims to block attack attempts which directly retrieve the hash from the memory. However, there are other ways to gain access to the hash such as side channel attacks, and a MitM (SMBRelay) attack within the organization.

 

  • Anti-Virus (AV) tools and Intrusion Prevention Systems (IPS) 
    AV tools and IPS are based on signatures and look for the known fingerprints of common exploitation tools. However, tool variations and usage of lesser-known tools defeat the common signature patterns. Additionally, as mentioned earlier, stealing the hash does not necessarily need to be done by reading the computer memory.

 

  • Disabling and restricting admin accounts
    This solution is not realistic in an enterprise environment. Consider a daily backup procedure on various computers; specific tasks that require admin privileges; or even mistakes made by IT admins, such as implementing a 3rd party product that uses the Domain Admin account. In each of these scenarios, the process is run under the Admin account and ultimately leaves the password hash on the computer.

 

  • Fortification measures features in Windows 8.1
    While Microsoft’s attempts are laudable – they do not eliminate the problem. First, it takes years, if at all, for an enterprise to update all their systems to the new operating system. Following the common paradigm “if it works, don’t break”, it can be expected that legacy and highly sensitive systems continue to run old processes to avoid any compatibility issues. Furthermore, since the release of Windows 8.1 there were already publications of PtH attacks defeating the defense measures within several systems, such as RDP’s “Restricted Mode”.

 

  • Monitoring the activity of privileged users
    The problem at hand is not only privileged users. For example, consider the case of an office admin. A PtH attack against the office admin might not enable the attacker direct access to the employee salary tables, to the salary billing server or to the company board’s activities. However, the office admin is likely to have direct access to the CEO’s calendar in order to schedule meetings. Inadvertently, that office admin had become a direct channel to the compromise of the CEO’s machine.

 

  • Tracking the changes to Active Directory
    Tracking changes to Active Directory will not help at all against this attack. The activity within the network looks precisely the same as legitimate activity. No changes whatsoever happen within Active Directory. There are no deletions/ updates/ additions of user – just normal user authentication activity.

 

  • Randomly changing passwords of privileged users
    The philosophy behind these measures is to try and mitigate an attack were it occurring against privileged users. However, this philosophy suffers from various shortcoming:

 

  • Cannot detect an attack. Accordingly, it is not possible to signify whether the mitigation measure is in fact successful or not.

 

  • Cover only privileged accounts. As specified in previous mitigation techniques, focusing only on   privileged users leave a blind spot which attackers exploit

 

  • Apply only to specific login scenarios such as RDP, SSH and FTP. Other login scenarios as simple as logging into the organizational work stations, or to 3rd party products are not supported.

 

  • A subset of Pass-the-Hash (PtH) attacks – for example, SMBRelay – can bypass these measures. This attack subset acts as a Man in the Middle which actively intercepts SMB communications. Once an entity is initially authenticated, the attacker can continue to intercept the communication regardless of any password change.

 

  • Under certain scenarios, Active Directory saves a history of the passwords. Ultimately, this leaves a window of opportunity for an attacker to use the old hash even if the password is reset.

 

  • Require complicated deployments. In a large organization, enforcing a random password change requires dedicated IT and security personnel, the customization of internal products and ultimately may take months to fully deploy.

 

Detecting Pass-the-Hash Attacks
It is important to recognize that PtH attacks are typically persistent and carried out by motivated attackers, thus cannot be prevented. Time has shown that prevention of sophisticated attacks is not a viable solutions. Enterprises should focus on the detection of PtH attacks through a variety of measures, such as:

  • Learning all entities’ behaviors (privileged and non-privileged) in the organization, including their interactions with other entities. 
  • Recognizing anomalous activity such as an entity accessing a resource outside of the organizational hours and unusual interactions between entities 
  • Detecting and alerting on AD-related protocol violations

 

Further reading: 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

http://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2012-Sessions/BH1208

http://labs.portcullis.co.uk/blog/new-restricted-admin-feature-of-rdp-8-1-allows-pass-the-hash/

 

Pass-the-Ticket

Overview
Pass the Ticket (PtT) is an attack where the adversary steals a user’s Kerberos authentication ticket in order to impersonate that user against various enterprise resources.

All Windows-based servers as of Windows 2000 use Kerberos as their default authentication protocol and as such, are susceptible to this kind of attack. However, this attack is not only confined to Windows but to any system which implements Kerberos in its backend (for example, all Linux-based systems). 

Kerberos Authentication Protocol – Background
The Kerberos authentication protocol enables the transparent Single Sign On (SSO) experience. The SSO enables users to actively authenticate (i.e. provide their password) only once even though they access various services – whether in the corporate network or in the Cloud (whereas the Kerberos ticket is translated to SAML tokens).

The Kerberos Authentication protocol works in the following manner:

 

PtT

  1. The user provides the Domain Name, user and password to access their computer.
  2. The computer authenticates to the Authentication Server (AS) residing on the Key Domain Controller (KDC). Accordingly, the KDC provides the computer with a Ticket Granting Ticket (TGT). The TGT is an identifier which enables the computer to request access to services without having the user to re-supply their credentials.
  3. Each time the computer attempts to access a service, it first identifies itself to the Domain Controller (DC), residing on the KDC, with the TGT as provided earlier by the AS. The DC, through its Ticket Granting Server (TGS), provides the user with a ticket for the particular requested service.
  4. The user provides the service ticket to the service. Since the ticket was validated by the TGS, the service grants authorization. Accordingly, the connection between the user and the service is established. 

 

Pass the Ticket Attacks
Pass the Ticket (PtT) actually includes various attack scenarios:

  1. An attacker steals tickets (whether TGT or service tickets) from the user’s local machine. By default, and by design, the tickets are stored on the end-user’s machine. Consequently, an attacker that steals a user’s ticket can impersonate the user to various enterprise services: from data stores that hold intellectual property to Cloud-based systems. A stealthy attacker can further utilize the tickets to gain lateral movement within the enterprise- say, moving from one machine to the next in order to gain elevated permissions or access a highly sensitive computer.
  2. An attacker steals users’ TGT tickets or service tickets by compromising delegated server. In this scenario, the service is delegated to request system or service access on the user’s behalf (aka “Double Hop”). As a result, the server running the delegated service must store the users’ tickets for the requested access. An attacker compromising the delegated server essentially obtains all the tickets stored on that machine and can access further services on behalf of any of the users. An attacker can also perform an effective Denial of Service (DoS) by preventing any user to continue and access further resources. 
    For instance, an SSL VPN can be configured as a “trusted for delegation” entity and, on behalf of the users, ask for their tickets to the organizational SharePoint. An attacker, on the one hand, can remotely access the enterprise’s SharePoint by impersonating any employee connecting via the enterprise’s VPN. On the other hand, the attacker can also deny users from authenticating to the SharePoint server. 
    As another example, consider the case of a database holding credit card data and is accessed via a dedicated SharePoint Web interface. Due to PCI compliance the database is separated from the SharePoint server which, in turn, is delegated to perform authorization on users’ behalf. An attacker compromising the SharePoint server obtains access to all the stored tickets and can effectively log in to the database on their behalf. 

 

Pass the Ticket Attacks – Points to Consider

  1. PtT attacks are falsely perceived as an attack which is generated only through domain computers. The reason for this misconception is that domain computers authenticate via Kerberos.
  2. The thing to notice, however, is that any computer, whether within the domain or not, can perform Kerberos authentication. For example, an attacker can inject a non-domain computer with a stolen ticket and cause the authentication process to proceed as usual.
  3. Security issues associated with delegation are exacerbated given that the KDC is controlled and maintained by IT teams – and not by the security teams. Given the less-paranoiac nature of IT admins, they may not realize that they are performing delegation (e.g. “2-click configuration”), or are not fully aware of the risks that delegation poses. Worse yet, some systems such as certain Business Intelligence services installed on SharePoint, require delegation in order to be installed. 

 

Pass-the-Ticket Attacks in the Wild
PtT attacks are easy to implement, where common automated pen-testing tools, such as WCE (Windows Credential Editor), include the support of this type of attacks. PtT attacks are also an initial step in an APT attack. In fact, Microsoft admitted to the security issue that Active Directory faces through PtT attacks already in 2013 during their BlueHat Conference.

Failed Attempts at Mitigating Pass-the-Ticket Attacks
Unfortunately, the following solutions and best practice have proven to fail in mitigating PtT attacks:

  • Limiting the tickets’ lifetime
    Currently, TGTs are limited to 10 hours and service tickets are limited to 10 hours. However, this timeframe is still reasonable for an attacker executing on a user’s machine and waiting for the exact timeframe to operate. More so, Windows by default allows extending the ticket’s expiration by 7 days.
  • Placing systems that randomly change the passwords.
    This solution does not attempt to address the problem since the attack has nothing to do with passwords. Once the user logs on to their computer, in whatever way, the granting of the TGT takes place.
  • Using multi-factor authentication
    Smart cards, bio metric solutions, and other multi-factor authentication measures do not attempt to address the problem either. The point is that the user receives the Kerberos ticket after the authentication process completes. In other words, once the user has authenticated – through any secure measure – an attacker is able to proceed with the ticket theft.
  • Activating logs
    Logs may indicate suspicious behavior; however, they do not detect the attack or mitigate it. More so, since in this attack the attacker impersonates a legitimate user – the indicators of attack are extremely subtle and may be drowned out by the sea of other log events.
  • Enforce the re-booting of user systems and the quitting of all client applications that access Kerberos-system when users leave their work area
    This measure will not prevent the theft of tickets since malware installed on a compromised machine can steal the user’s ticket at any stage. With today’s malwares being capable of surviving re-boots, the malware can import the stolen ticket which remains valid once the OS runs again. 

 

Detecting Pass the Ticket Attacks
Measures for detecting and preventing PtT attacks include:

  • Learning the behaviors of all entities (privileged and non-privileged in the organization) and correlating their performed activities
  • Analyzing authentication protocols to detect and alert on violations 

 

Further Reading:

http://www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf

http://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2012-Sessions/BH1208

http://technet.microsoft.com/en-us/library/cc961963.aspx

Coming Soon