Credential Theft

Introduction

• Attackers prioritize the collection of credentials almost immediately after the post-exploitation phase of the attack cycle.

• Privilege escalation or the collection of additional and more privileged credentials is almost always required to fully compromise a network.

• Since nearly every activity in Windows is tied to an account, it can be difficult to laterally move without a privileged account.

• In addition to privileged and known compromised account tracking, analysts should also monitor for new account creations. These events occur infrequently and are used by some threat actors to evade monitoring or create "sleeper" accounts that may escape remediation efforts and allow immediate access back into the enterprise post-breach.

• A common account vulnerability present in many enterprises is a shared local admin account utilizing the same password across many devices. In this scenario, the compromise of one system allows lateral movement to many others, along with the possibility of collecting more credentials at each additional system accessed.

• Local account usage is rare in the enterprise and can be easily monitored via event logs. Enterprises can further reduce their attack surface by creating unique passwords for every local admin account and denying network logons for these accounts.

Evolution of Credential Attack Mitigation

• Like many other security issues in Windows, poor initial credential implementation coupled with the ever-present backward compatibility demands has been Microsoft’s nemesis in securing the operating system.

Vista / Windows 7

• User Account Control (UAC) was introduced to implement mandatory access control and least privileges support.

• Managed Service Accounts were released with Server 2008R2 and are one of the few mitigations available to combat some of the most advanced Kerberos ticket attacks. (The initial implementation was lacking. The latest iteration, Group Managed Service Accounts, is much more flexible and admin-friendly)

• Still missing security features (like process isolation)

Windows 8

• Microsoft took a hard look at the havoc being caused by tools and techniques like Mimikatz and pass the hash and decided to act.

• CredSSP and other single sign-on (SSO) credentials like TsPkg and Wdigest are no longer cached in memory by default. This removes the Mimikatz ability to recover plaintext credentials from these sources.

• Local accounts can be easily restricted from network or remote interactive logons to domain-joined systems. This breaks pass-the-hash attacks, mounting remote shares, remote WMI, PsExec, and remote scheduled tasks using local administrator accounts

• Proctected process was introduced, Protected processes can only load signed code and can only be attached to by other protected processes.

• The LSASS process, in particular, was singled out as protected in order to defeat many of the common credential dumping tools that inject code into LSASS to collect credentials. Unfortunately, protection is off by default and is unlikely to get rolled out widely through the enterprise. Mimikatz gets around this protection via a signed driver

• ...

Windows 10

• Credential Guard is a game changing technology that isolates hashes and tickets using a security boundary enforced by machine virtualization. (While it has software and hardware requirements and will be some time before it is widely deployed, it effectively defeats all of the current user account hash and ticket dumping techniques currently in the wild.)

• Remote Credential Guard is an update to Restricted Admin and protects any account (not just admin) during RDP sessions.

• Guard is a new take on application control that can lock down systems to prevent untrusted code (like credential dumping utilities) from running on a system.

Compromising Credentials

Hashes

• Hashes are available in the LSASS process and can be extracted with admin privileges. Once dumped, hashes can be cracked or used immediately in a pass-the-hash attack.

• The password for each user account in Windows is stored in multiple formats: LM (Deprecated) and NT hashes are most well-known.

• TsPkg, WDigest, and LiveSSP can be decrypted to provide plaintext passwords (prior to Win8.1)

• Local account password hashes are available in the SAM registry hive and domain account hashes are present in memory during interactive sessions.

• Several standard attacks allow an attacker access to these credentials: memory extraction directly from LSASS, dumping the LSASS process for offline attacks, and extraction of local account hashes from the SAM hive in memory or on disk. Administrator privileges are required for all of these attacks. Once the hashes are dumped, they can be easily cracked with tools like John the Ripper or via rainbow table pre-computation attacks. Alternatively, they can be used for authentication in their original form (Pass-The-Hash)

• A domain user account must interactively log on to a system for its hash to be present in memory, and the hashes are only available while the user is logged on (unless applications or processes are still using them after logging off.

Cleartext Passwords

• Researchers have also found many other types of stored credentials in memory, some of which can be easily extracted and decrypted, resulting in cleartext passwords.

• Some of these are a result of single sign-on (SSO) like TsPkg and Wdigest, while another, LiveSSP, is derived from the new Windows “Live” cloud accounts that can now be used to log on.

Pass-the-Hash

• Pass the hash allows an attacker to authenticate using a stolen account hash without ever knowing the cleartext password.

• Pass the hash is limited to NTLM authentication and takes advantage of the fact that only the hash is necessary to respond to an NTLM challenge-response protocol.

• While most authentication in a Windows enterprise is now using Kerberos, NTLM is still almost always available.

How to defend

• Prevent admin account compromise.

• Stop remote interactive sessions with highly privileged accounts.

• Proper termination of RDP sessions.

• Upgrade to the latest Windows version or use the latest security controls in the current version.

• Microsoft has recently taken major steps to reduce hash vulnerabilities. Windows 8.1+ no longer stores WDigest and TsPkg credentials by default. However, WDigest plaintext credentials can be re-enabled by an attacker by updating HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest with a “1” in registry value "UseLogonCredential" . (Excellent Key to Audit For)

• A final defence is to ensure that local administrator account passwords are unique and not shared across the workstation segment.

Tools:

• Mimikatz

• fgdump

• gsecdump

• Metasploit

• AceHash

• PWDumpX

• creddump

• WCE

Tokens

• Every Windows logon and process has an associated security token.

• A token contains security context and privileges for an account.

• Special tokens, named impersonate and delegate, facilitate access control and single sign-on (SSO), specifically allowing processes to be run under a different account security context.

• Impersonate tokens allow local security context shifts, and the more powerful delegate tokens facilitate authentication even across network resources.

Token Stealing

• If a token is present on the system, a user with the Selmpersonate privilege (or with the admin or SYSTEM privileges necessary to add it) can extract the token and reuse it to do a variety of tasks like local privilege escalation, adding users or managing group membership, and mapping remote admin shares or running PsExec (delegate tokens only).

• Attackers commonly use this technique to elevate privileges from local admin to domain admin. The attack is also particularly useful in situations where hashes cannot be easily extracted from LSASS, such as when it is designated as a Win8.1+ Protected Process.

• In modem Windows systems (post-Windows 2003SP1), tokens are present only when an account is logged in.

• Servers are a particularly lucrative place to find them since they may have simultaneous users.

• Another commonly exploited vector is on systems where an administrator has connected via RDP but did not perform a proper session termination.

How to Defend

• Prevent admin account compromise.

• Stop remote interactive sessions with highly privileged accounts.

• Proper termination of RDP sessions ( If a session is disconnected but not closed, the token can persist on a system while that session is still present. Group Policy can be used to “set a time limit for disconnected sessions” )

• Upgrade to the latest Windows version or use the latest security controls in the current version.

• Account designation of “Account is Sensitive and Cannot be Delegated” in Active Directory.

• Domain Protected Users security group accounts do not create delegate tokens.

• Similar to password hashes, the best way to protect sensitive tokens is to not interactively log in to systems with highly privileged accounts and stop attackers from gaining local administrative rights that can allow token stealing.

• Coveted “delegate" tokens are only present during interactive logon sessions! Thus, avoiding console logons, RDP, and runas largely removes the ability to steal delegate tokens.

• In Windows 8.1+, forcing an account to use “Restricted Admin” prevents hashes and tokens from being available on the remote system during interactive logons like RDP.

• High-value accounts can also be designated in Active Directory as not able to be delegated.

• Perhaps the most elegant solution now exists in Windows 8.1+ systems. Members of the Protected Users security group do not create delegate tokens, even during interactive sessions.

Tools

• Incognito

• Metasploit

• PowerShell

• Mimikatz

Cached Hashes

• Stored domain credentials to allow logons when domain controller access is unavailable.

• Most systems cache the last 10 logon hashes by default (This number was increased to 25 for Server 2008)

• Credentials can persist in this cache for very long periods.

• Attackers hope that at some time in the past, a domain administrator (or similarly highly privileged account) logged on to the system interactively and had their credentials stored indefinitely.

• Cached domain credentials are stored in the Security registry hive in the SECURITY\Cache key.

• Administrator (or System) privileges are required to access the saved hashes, which are in mscash2 format for modem Windows operating systems. Since data is kept in the registry, these hashes persist indefinitely, even after a reboot.

• Mscash2 hashes are encrypted and thus cannot be used in pass-the-hash attacks. They are also secured better than NT hashes, including a hash salt of the username to defeat pre-computation attacks.

• Tools like John the Ripper and hashcat can brute force crack these hashes, but with a good password policy in place, decryption can be very slow.

• Of particular interest in this slide is the difference between dumping local hashes and cached credentials.

  • Local Hashes: These are local accounts that belong to this system. (SYSTEM SAM)

  • Cached Hashes: These are potentially much more interesting to an attacker since they are domain credentials and not subject to prevalent local account restrictions. (SYSTEM SECURITY)

• Cached credentials are salted with the account username and thus must be cracked via brute force.

How to Defend

• Prevent admin account compromise.

• Limit the number of cached logon accounts (SOFTWARE Microsoft Windows NT Current Version Winlogon ( cachedlogonscount value))

• Enforce password length and complexity rules (Since Bruteforce is essential for this attack type)

• Domain Protected Users security group accounts do not cache credentials.

LSA Secrets

• Credentials stored in the registry to allow services or tasks to be run with user privileges.

• In addition to service accounts, may also hold application passwords like VPN or auto-logon credentials.

• Administrator privileges allow access to encrypted registry data and the keys necessary to decrypt. Passwords are plaintext.

• From an attacker perspective, service accounts are by far the biggest draw, as they are very common in the Windows enterprise, are often highly privileged, and rarely change.

• LSA Secrets are stored in encrypted form in the Security hive registry key SECURITY/Policy/Secrets.

• Each secret has its own key, and a parent key within SECURITY/Policy can decode the “secrets”.

• In addition to the Security hive, dumping tools require access to the System hive to access a final decryption key.

• Administrator privileges allow access to all of the registry areas necessary to dump the LSA Secrets.

• Once decrypted, all passwords are in cleartext, making them particularly valuable for use with applications like RDP

How to defend

• Prevent admin account compromise.

• Do not employ services or schedule tasks requiring privileged accounts on low-trust systems.

• Reduce number of services that require domain accounts to execute (Heavily audit any accounts that must be used)

• (Group) Managed Service Accounts.

• Since it can be very difficult to totally remove the reliance on LSA Secrets, any accounts that are likely to be present in this key should follow the least privilege rule and be heavily audited.