Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection

Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection
Sean Metcalf CTO DAn Solutions sean dansolutions . com === Halo Red vs Blue photo by Ed Speir IV. All Rights Reserved. Used with Permission "McFarlane Halo 3 Series 1 - Red Mark VI Spartan and Blue CQB Spartan" Photo by Ed Speir IV. All Rights Reserved. Used with Permission.

About Chief Technology Officer - DAn Solutions Microsoft Certified Master (MCM) Directory Services Security Researcher / Purple Team Security Info -> ADSecurity.org

Agenda Deep Web Evil Code Cyber, Cyber, and more CYBER! CYBER!
Just kidding…

Agenda Introduction Red Team Blue Team Recon Breach
Escalate - Getting DA in AD Persist - Forging Kerberos Tickets Blue Team Detecting Forged Kerberos Tickets Active Directory Attack Mitigation It is more important than ever for defensive teams to understand current attacks. In late 2014, I performed Security research focusing on Kerberos hacking specifically Golden Tickets, Silver Tickets, & MS exploit. I ran through attacks in different lab environments and documented how they work. Starting with the question: “How can I detect Golden Tickets?” This presentation was originally developed to brief customers on AD Kerberos attacks and the ways to detect & defend. I have since expanded it to cover attacker exploitation of AD, detection, and mitigation. There are lots of screenshots! We will walk-through of some attacks from what I call the “AD Attack Playbook”, including some interesting ways to use Silver Tickets. Much of this information some of you will already know. However, there are a few items that are not public. Yet. ===

Paradigm Shift: ASSUME BREACH
According to Mandiant M-Trends 2015 report Intrusion average detection time: 2013: 229 days 2014: 205 days (> 6 months!) Longest Presence: 2,982 days ( >8 years!) 69% of organizations learned of the breach from outside entity The average detection time of a breach was over 6 months in 2014 and most organizations didn’t detect the breach. Someone else told them about it. This is a post-exploit talk – attacker is on a computer on the network. We start this talk with the understanding that the perimeter is compromised regularly. Mandiant 2015 Threat Report Mandiant 2014 Threat Report

Perimeter Defenses Are Easily Bypassed
Perimeter Defenses Used to Be Enough. The castle’s high outer wall and moat are not enough anymore. Attackers have gotten really good at Swimming & Climbing. goes right through perimeter defenses. : ) ===== “Message for you, sir!” Photo screenshot from the movie, “Monty Python & the Quest for the Holy Grail”

Assume Breach Means: Layered Defense
Layered defense. From outer moat & castle wall(s) to several interior walls. “Mont Saint-Michel in Normandy, France on the left was the real life inspiration for the design of Minas Tirith in the Lord of the Rings film.” This is a great example of layered defense – even if an attacker gets inside the outer walls, there are several more to get through. Unless you have a Winged Nazgul.  ==== - Mont Saint-Michel Photo by Dinsick. Photos from Wikipedia.org Minas Tirith (

Kerberos TGT Ticket Since we will be talking about Golden and Silver Tickets, it’s natural to start with some Kerberos fundamentals. In Kerberos a user has a ticket which is used to gain access to a resource. The Ticket-Granting-Ticket, TGT, is the authentication ticket and the Ticket-Granting-Service, TGS ticket is the service ticket which provides access to Kerberos enabled services. Let’s look at the format of a TGT (TGS is similar): ===== “PAC validation is a security feature that addresses PAC spoofing, preventing an attacker from gaining unauthorized access to a system or its resources by using a tampered PAC. This is critical in applications where user impersonation is utilized. PAC validation ensures the user presents exact authorization data as it was granted in the Kerberos ticket. “ [MS-PAC]: Privilege Attribute Certificate Data Structure 4.1.1 Tampered PAC Data The signature of a PAC prevents elevation of privilege attacks. The signature MUST be verified to avoid these attacks. “When the PAC validation occurs, the server encodes a KERB_VERIFY_PAC_REQUEST request message [MS-APDS] and transmits it to the DC through generic pass-through mechanism [MS-NRPC]. The DC decodes the request and extracts the server checksum and the KDC checksum values. If the checksum verification succeeds, the DC returns a success code to the server. An unsuccessful return code indicates that the PAC has been altered.” KILE supports the following checksum types. Each checksum type is described, and a number is specified, in the corresponding RFC. CRC32 [1] [RFC3961] rsa-md4 [2] [RFC3961] rsa-md4-des [3] [RFC3961] des-mac [4] [RFC3961] des-mac-k [5] [RFC3961] rsa-md4-des-k [6] [RFC3961] rsa-md5 [7] [RFC3961] rsa-md5-des [8] [RFC3961] sha1 (unkeyed) [-131] [RFC3961] hmac-sha1-96-aes128 [15] [RFC3962] hmac-sha1-96-aes256 [16] [RFC3962] hmac-md5-string [-138] [RFC4757] Encryption Types KILE SHOULD support the Advanced Encryption Standard (AES) encryption types:<19> AES256-CTS-HMAC-SHA1-96 [18] ([RFC3962] section 7) AES128-CTS-HMAC-SHA1-96 [17] ([RFC3962] section 7) and MAY<20> support the other following encryption types, which are listed in order of relative strength: RC4-HMAC [23] [RFC4757]<21> RC4-HMAC-EXP [24] [RFC4757]<22> DES-CBC-MD5 [3] [RFC3961]<23> DES-CBC-CRC [1] [RFC3961]<24> Kerberos V5 encryption type assigned numbers are specified in [RFC3961] section 8, [RFC4757] section 5, and [RFC3962] section 7.<25> Ticket Flag Details The Kerberos V5 protocol specifies a number of options and behaviors with regard to the flags ([RFC4120] section 2) that are encoded in a ticket. KILE implements the following ticket flags: The INITIAL and PRE-AUTHENT flags ([RFC4120] section 2.1): By default, KDCs require pre-authentication when they issue tickets. Clients SHOULD pre-authenticate. KDCs MUST enforce pre-authentication. Therefore, unless the account has been explicitly set to not require Kerberos pre-authentication, the ticket will have the PRE-AUTHENT flag set. The HW-AUTHENT flag ([RFC4120] section 2.1): This flag was originally intended to indicate that hardware-supported authentication was used during pre-authentication. This flag is no longer recommended in the Kerberos V5 protocol. KDCs MUST NOT issue a ticket with this flag set. KDCs SHOULD NOT preserve this flag if it is set by another KDC. The RENEWABLE flag ([RFC4120] section 2.3): Renewable tickets SHOULD be supported in KILE. The POSTDATED/MAY-POSTDATE flag ([RFC4120] section 2.4): Postdated tickets SHOULD NOT be supported in KILE. The FORWARDABLE/FORWARDED flag ([RFC4120] section 2.6): Forwarded tickets SHOULD be supported in KILE. The TRANSITED-POLICY-CHECKED flag ([RFC4120] section 2.7): KILE MUST NOT check for transited domains on servers or a KDC. Application servers MUST ignore the TRANSITED-POLICY-CHECKED flag. The OK-AS-DELEGATE flag ([RFC4120] section 2.8): The KDC MUST set the OK-AS-DELEGATE flag if the service account is trusted for delegation (section ). For more information, see [ADDLG]. Key Version Numbers The Kerberos V5 protocol specifies key version numbers ([RFC4120] section 5.2.9). Key version numbers are used in the Kerberos V5 protocol to distinguish between different keys in the same domain. KILE key version numbers (as defined in [RFC4120] section 5.2.9) are unsigned 32-bit integers. KILE supports key version numbers for read-only domain controllers (RODCs). Each RODC will have a different key version number.<27> This allows the domain controller to distinguish between keys that are issued to different RODCs. The key version number consists of 32 bits. The first 16 bits, including the most significant bit, are an unsigned 16-bit number which SHOULD identify the RODC. The remaining 16 bits SHOULD be the version number of the key.

Kerberos Overview Moving on to how a user gets and uses tickets… User logs on with username & password. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ). KDC, Domain Controller, checks user information (logon restrictions, group membership, etc) & creates TGT. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data. The User presents the TGT to the DC when requesting a TGS ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP). The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening). Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC. [Passport & Visa analogy] ===== The Authentication Service (AS) exchange ([RFC4120] section 3.1): Kerberos authentication service request (KRB_AS_REQ) ([RFC4120] section 5.4.1): The client sends a request to the KDC for a ticket-granting ticket (TGT) ([RFC4120] section 5.3). The client presents its principal name and can present pre-authentication information. Kerberos authentication service response (KRB_AS_REP) ([RFC4120] section 5.4.2): The KDC returns a TGT and a session key the client can use to encrypt and authenticate communication with the KDC for ticket-granting service (TGS) requests, without reusing the persistent key. The Ticket-Granting Service (TGS) exchange ([RFC4120] section 3.3): Kerberos ticket-granting service request (KRB_TGS_REQ) ([RFC4120] section 5.4.1): The client sends a request to the KDC for a ticket ([RFC4120] section 5.3) for the server. The client presents the TGT ([RFC4120] section 5.3), an authenticator ([RFC4120] section 5.5.1), and the Service Principal Name (SPN). * Kerberos ticket-granting service response (KRB_TGS_REP) ([RFC4120] section 5.4.2): The KDC validates the TGT ([RFC4120] section 5.3) and the authenticator ([RFC4120] section 5.5.1). If these are valid, the KDC returns a service ticket ([RFC4120] section 5.3) and session key the client can use to encrypt communication with the server. The Client/Server Authentication Protocol (AP) exchange ([RFC4120] section 3.2): * Kerberos application server request (KRB_AP_REQ) ([RFC4120] section 5.5.1): The client requests access to the server. The client presents the ticket ([RFC4120] section 5.3) and a new authenticator ([RFC4120] section 5.5.1). The server will decrypt the ticket, validate the authenticator, and can use any authorization data ([RFC4120] section 5.2.6) contained in the ticket for access control. * Kerberos application server response (KRB_AP_REP) ([RFC4120] section 5.5.2): Optionally, the client might request that the server verify its own identity. If mutual authentication is requested, the server returns the client's timestamp from the authenticator encrypted with the session key. * The AS exchange and TGS exchange are transported by Kerberos implementations. The AP exchange is passive and relies on an upper-layer application protocol to carry the AP exchange messages. Applications that use AP exchange messages directly are typically called "kerberized" applications. Most applications use the Generic Security Service Application Program Interface (GSS-API) and may even be wrapped by higher-level abstractions such as Simple Authentication and Security Layer (SASL) [RFC2222], which allows for "kerberized" connections to mail servers.

Kerberos Key Points Kerberos policy only checked when TGT is created.
NTLM password hash for Kerberos RC4 encryption. Logon Ticket (TGT) provides user auth to DC. Kerberos policy only checked when TGT is created. DC validates user account only when TGT > 20 mins. Service Ticket (TGS) PAC validation is optional & rare. Server LSASS sends PAC Validation request to DC’s netlogon service (NRPC) If it runs as a service, PAC validation is optional (disabled) If a service runs as System, it performs server signature verification on the PAC (computer account long-term key). Microsoft uses the NTLM password hash for Kerberos RC4 encryption. Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC. The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC) If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key). ==== KERB_VERIFY_PAC_REQUEST request message [MS-APDS] and transmits it to the DC through generic pass-through mechanism [MS-NRPC]. The DC decodes the request and extracts the server checksum and the KDC checksum values. If the checksum verification succeeds, the DC returns a success code to the server. An unsuccessful return code indicates that the PAC has been altered. ValidateKdcPacSignature registry key was added to enable or disable PAC verification for services (KB ). [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] “ValidateKdcPacSignature”=dword: “Services that are running as part of the Windows OS do not perform PAC validation. They carry out server signature verification on the PAC by using the long-term key that the KDC shares with the server.” “PAC validation is a security feature that addresses PAC spoofing, preventing an attacker from gaining unauthorized access to a system or its resources by using a tampered PAC. This is critical in applications where user impersonation is utilized. PAC validation ensures the user presents exact authorization data as it was granted in the Kerberos ticket. “ [MS-PAC]: Privilege Attribute Certificate Data Structure 4.1.1 Tampered PAC Data The signature of a PAC prevents elevation of privilege attacks. The signature MUST be verified to avoid these attacks. “When the PAC validation occurs, the server encodes a KERB_VERIFY_PAC_REQUEST request message [MS-APDS] and transmits it to the DC through generic pass-through mechanism [MS-NRPC]. The DC decodes the request and extracts the server checksum and the KDC checksum values. If the checksum verification succeeds, the DC returns a success code to the server. An unsuccessful return code indicates that the PAC has been altered.” --- The domain policy controlling Kerberos options such as ticket lifetime and approved encryption types are checked at ticket creation and written into the TGT ticket as appropriate. These aren’t validated later when reading the ticket. AD Kerberos ticket lifetime by default is 10 hours (TGT & TGS) and can be automatically renewed for up to 7 days (TGT). The Microsoft Kerberos service only validates a TGT’s PAC (UPN, Domain, group membership) ensuring the user is valid & enabled only after the ticket is 20 minutes old. The Golden Ticket attack takes advantage of this, so any TGTs (Golden Tickets) with a spoofed PAC are only valid for 20 minutes. However, any service tickets (TGS) derived from a Golden Ticket are valid for the 10 hour default lifetime. Most services (i.e. runs as service) don’t request PAC validation from the Domain Controller after receiving a TGS service ticket, the PAC data can be entirely fictitious and accepted as fact. When the RC4 encryption algorithm is used, the key is the NTLM password hash. This means access to various account NTLM hashes provides easy Kerberos hacking opportunities. Windows 7 & Windows 2008 R2 support Kerberos AES encryption (AES128 & AES256) meaning when older operating systems are removed, AES Kerberos encryption can be exclusively enabled. PAC Validation “PAC validation is a security feature that addresses PAC spoofing, preventing an attacker from gaining unauthorized access to a system or its resources by using a tampered PAC. This is critical in applications where user impersonation is utilized. PAC validation ensures the user presents exact authorization data as it was granted in the Kerberos ticket. One key reason why a PAC should be verified as unaltered is to ensure that no additional privileges have been maliciously added to - or removed from - the ticket. This makes the PAC validation an important consideration when designing applications that impersonate users and access sensitive data, or applications that grant administrative privileges.” “Performing PAC validation implies a cost in terms of response time and bandwidth usage. It requires bandwidth usage to transmit requests and responses between an application server and the DC. This may cause some performance issues in high volume application servers (KB906736). In such environments, user authentication may induce additional network delay and traffic for carrying PAC validation messages between the server and the DC. “ “Kerberos PAC validation in Windows In Windows implementation, the application server derives the authorization data (PAC) and requests Windows OS to generate an access token. The access token encapsulates account's identity, group memberships, and system privileges, and is used to make authorization decisions. Windows OS uses the identity of the application server to determine when it needs to validate the PAC. Services that are running as part of the Windows OS do not perform PAC validation. They carry out server signature verification on the PAC by using the long-term key that the KDC shares with the server. The OS sends PAC Validation messages to the DC (through NRPC) when it wants to ensure the PAC has not been tampered. It involves the DC to validate the PAC when a non-privileged application attempts to authenticate a ticket. Windows OS sends the PAC validation messages to the NetLogon service of the DC when the service does not have the TCB privilege and it is not a Service Control Manager (SCM) service. The Local Security Authority Subsystem Service (LSASS) process will send PAC validation messages to the DC when the LSA client (the application server) is not running in the context of local system, network service, or local service; or it does not have SeTCBprivilege (Act as part of the operating system). User rights: Act as part of the operating system This policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs. Note: SeTcbPrivilege enables to assign a user account the right to “Act as Part of the operating system”. Local system, network service and local service accounts are Windows-defined Service User Accounts. Each account has a set of specific privileges attached to it. Windows Server 2003 SP2 has introduced the option for controlling PAC validation on a server-wide basis for application services that are authenticating users. The ValidateKdcPacSignature registry key was added to enable or disable PAC verification for services (KB ). When the value of this entry is 0, Kerberos does not perform PAC validation on a process that runs as a service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You have to restart the computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry is present and has a value of 1. The default value in Windows Server 2008 for this entry is 0. In a nutshell, two main conditions prevent PAC validation from occurring in Windows OS: - the application has the SeTcbPrivilege privilege (“Act as part of the operating system”); - the application is a service and the ValidateKdcPacSignature registry key is set to disable PAC validation.”

Red Team (Offense)

Attacker Goals Data Access & Exfiltration Persistence Email Shares
SharePoint Persistence AutoRun WMI “Sticky Keys” PowerShell Attackers have two primary goals: Data access & Persistence Insiders have “persistence” and want to find the juiciest data to extract.

PowerShell Overview Dave Kennedy: “Bash for Windows”
Available by default in supported Windows versions v2: Win 7 / Win 2k8R2 v3: Win 8 / Win 2012 v4: Win 8.1 / Win 2012R2 Provides access to WMI & COM Leverages .Net Framework Microsoft binary = whitelisted Download & run code in memory Get-AllTheThings! If you work with computers, either on the infosec side or as an admin, it’s time to learn PowerShell if you haven’t already. PowerShell is a built-in Windows component in all support versions of Windows and provides access to WMI & COM & Leverages .Net Framework. It’s a Microsoft binary, so it’s whitelisted and blocking PowerShell.exe can break things (MS apps, logon scripts, etc). Download & run code in memory (Invoke-Expression) ==== Verb-Noun syntax Interactive commands –> scripts –> full “commands” Vista EOL was 2012.

Offensive PowerShell PowerSploit PowerView
Invoke-Mimikatz (updated 2/16/2015) Invoke-TokenManipulation Invoke-Shellcode Get-GPPPassword Persistence PowerView Hunting Sys Admins If you do nothing else, review the PowerSploit GitHub repository PowerSploit tools are used extensively by attackers Invoke-Mimikatz = PowerShell version of Mimikatz – runs in memory, never touches disk. Get-GPPPassword – Find and decrypt passwords in Group Policy Preferences. PowerView include great tools for finding what computers admins are logged on to. ==== PowerSploit: PowerView: PowerShell replacement for net * cmd tools. Exploits the fact that Windows will usually tell you who’s logged on.

“SPN Scanning”: Service Discovery
SQL servers, instances, ports, etc. MSSQLSvc/adsmsSQLAP01.adsecurity.org:1433 Exchange exchangeMDB/adsmsEXCAS01.adsecurity.org RDP TERMSERV/adsmsEXCAS01.adsecurity.org WSMan/WinRM/PS Remoting WSMAN/adsmsEXCAS01.adsecurity.org Hyper-V Host Microsoft Virtual Console Service/adsmsHV01.adsecurity.org VMWare VCenter STS/adsmsVC01.adsecurity.org The easiest way for service discovery is by leveraging standard LDAP queries in what I call “SPN Scanning”. S The Service Principal Name (SPN) is used as a signpost to identify a service on a server that supports Kerberos auth. The service registers it’s SPN in AD associating it with the computer or user object (if there’s a service account configured for the service). SPN Scanning enables service discovery without network port scanning. SPN Format: SPN type or class “/” computer FQDN “:” port or other data specific to service (instance). Ex: Discover all SQL servers, SQL instances, and SQL ports. ====== An SPN is a string of the following format. For more information on the <alphanum> element, see [RFC2396] section 1.6. SPN = serviceclass "/" hostname [":"port] ["/" servicename] serviceclass = alphanum servicename = alphanum Where: serviceclass is a string that identifies the class of the service, such as "www" for a Web service or "ldap" for a directory service. hostname ([RFC2396] section 3.2.2) is a string that is the name of the system. This SHOULD be the fully qualified domain name (FQDN). port ([RFC2396] section 3.2.2) is a number that is the port number for the service. The servicename segment is a string that is the distinguished name (DN), objectGuid, Internet host name, or fully qualified domain name (FQDN) for the service. An application can supply a name of the form "RestrictedKrbHost/<hostname>" when its callers have provided the hostname but not the correct SPN for the service. Applications SHOULD NOT use "RestrictedKrbHost/<hostname>" due to the security considerations in section Applications calling GSS-API directly MUST provide a target name which SHOULD be an SPN<28> for their service applications for Kerberos authentication.

SPN Scanning for MS SQL Servers with Discover-PSMSSQLServers
PowerShell script I wrote that discovers all SQL servers in an AD forest by SPN (MSSQL*). The report shows the service account associated with the SQL service running on the server including information about the server. No admin rights or special PowerShell modules required (works with PowerShell v2). === Discover-PSMSSQLServers SPN Directory:

Getting Domain Admin in Active Directory
Poor Service Account Passwords Passwords in SYSVOL Credential Theft Misconfiguration / Incorrect Perms Exploit Vulnerability Getting Domain Admin in Active Directory There are several ways an attacker escalates access from a user to a Domain Admin. Generally speaking, admins (most people) often hit the easy button & don’t think out of the box… er bag.  Service Account passwords rarely change (even if there’s policy) Let’s talk about service account password… ====

Admins Bypass Password Policy
Admins don’t like having to change the service account password every x number of days. Some cheat. Check, uncheck and the account password doesn’t need to be changed anymore! Detection of this is not possible with data exposed via LDAP. However…

Detecting Password Policy Bypass
Repadmin is used by AD admins to check AD replication & provides information on all AD object replication by attribute. By looking at the unicodePwd attribute, which stores the password for the user object, we can identify when the password was really changed. You can see on this screen shot that the dates don’t match. Someone cheated! I wrote a script that scans all admin/service accounts in an AD forest for this discrepancy and reports on accounts with “fake” password changes” - Code not published yet, but will be uploaded to my GitHub repository.

SPN Scanning for Service Accounts with Find-PSServiceAccounts
You can also “SPN” scan for service accounts. I have found this to be the most reliable methods for finding real service accounts, services running with SA creds. As opposed to searching for accounts with service in the name or description. This script discovers all service accounts (user accounts with an associated SPN) in the AD Forest and reports on it. ====== Find-PSServiceAccounts SPN Directory: SPN Directory:

Cracking Service Account Passwords (Kerberoast)
Request/Save TGS service tickets & crack offline. “Kerberoast” python-based TGS password cracker No elevated rights required! No traffic sent to target! Reference: Tim Medin “Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades” An attacker can crack service account passwords without ever getting admin access to the server or the network. The attacker gets a foothold on a computer & Requests TGS tickets for several services with service accounts. Exports the TGS tickets from memory, saves them to files, & uploads to a website or webservice (Google Drive). An attacker owned computer on the internet grabs these files & runs Kerberoast against them until it identifies the correct NTLM password hash that will open one. Success in opening a TGS means the service account password was found! Tim Medin described and released Kerberoast at DerbyCon 2014. === Scenario: PowerShell script gathers a TGS for every service account and uploads to web site. Automated process runs Kerberoast and cracks service account passwords. Tim Medin’s DerbyCon 2014 presentation: “Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades”

Group Policy Preferences (GPP)
Authenticated Users have read access to SYSVOL Configuration data xml stored in SYSVOL Password is AES-256 encrypted (& base64) Credential Use Cases: Map drives Create Local Users Data Sources Create/Update Services Scheduled Tasks Change local Administrator passwords **In 2006, Microsoft Bought Desktop Standard’s “PolicyMaker” Rebranded & released with Windows Server 2008 as “Group Policy Preferences” Provides useful capability to leverage Group Policy to “deploy” scheduled tasks with explicit credentials and change the local admin passwords on large numbers of computers at once. The credential password is AES-256 bit encrypted which should be good enough… *** ===== GPP Popular Features: - Deploy scheduled tasks with explicit credentials. - Change local Administrator password. Password in GPP xml file is encrypted using AES-256, but AES private key is available on MSDN website. Drives.xml Printers.xml Services.xml ScheduledTasks.xml DataSources.xml

Exploiting Group Policy Preferences
The private key is publicly available on MSDN except Microsoft published the private key for this encryption which enables attackers to take the encrypted blob of data and easily extract the clear-text password from it! *** === MSDN Group Policy Preferences Password Encryption Key

Exploiting Group Policy Preferences
\\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\ This issue was first publicly identified in January, 2012 by Emilien Gauralt the blog post “Exploiting Windows 2008 Group Policy Preferences” which is unfortunately no longer available. Just a few months after this post, in May of 2012, Chris Campbell posted about Group Policy Preference Password Retrieval with PowerShell and posted PowerShell code which decodes the password from a GPP xml file. The latest version of this code is now Get-GPPPassword in PowerSploit. All domain Group Policies are in this location. Search this location for xml files containing the keyword “cpassword” Grab the data in this field and run an AES decrypt function against it and. Password is now decrypted! ===== 6/2012: Rewt dance posted expanded reference All domain Group Policies are located in SYSVOL: \\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\ Example GPP xml Decoded GPP encrypted password “cpassword” 1/2012: Emilien Gauralt “Exploiting Windows 2008 Group Policy Preferences” No longer on the net 5/2012: Chris Campbell - GPP Password Retrieval with PowerShell

The GPP Credential Vulnerability Fix?
Vulnerability in GPP could allow elevation of privilege (May 13, 2014) MS (KB ) Install on all systems with RSAT Passwords are not removed from SYSVOL Two years after the issue is identified and exploited, there’s a patch (MS14-025) Patch has to be installed on ALL computers where admins administer Group Policy. Does not remove existing GPP xml files – passwords may still be exposed in SYSVOL!

Mimikatz: The Credential Multi-tool
Dump credentials Windows protected memory (LSASS). * Active Directory Domain Controller database . * Dump Kerberos tickets for all users. * for current user. Credential Injection Password hash (pass-the-hash) Kerberos ticket (pass-the-ticket) Generate Silver and/or Golden tickets (depending on password hash available). * Requires debug or system rights ***Mimikatz: Windows program created by Benjamin Delpy in 2007 to learn more about Windows credentials. These are just some of Mimikatz’s capabilities. For this talk, we will be focusing on credential theft and injection. The items listed with an asterisk require debug or system rights. PowerSploit tool “Invoke-Mimikatz” provides Mimikatz functionality in PowerShell. For the purpose of this talk, Mimikatz & Invoke-Mimikatz are used interchangeably. Inject credentials into current user session (memory) for use (and access). * Requires debug or system rights ====

Dump Credentials with Mimikatz
Mimikatz dumps creds from LSASS which includes any accounts that have logged on recently. Shows clear-text password for users. This can be prevented with Windows 8.1 & Windows 2012 R2 or newer (or KB ). May include creds from admin logon days or weeks ago! Logoff properly or Reboot. KB does a better job of clearing credentials from LSASS after use. Services configured with explicit credentials are in LSASS.

Default Logon Rights to Domain Controllers
Enterprise Admins (admin on all DCs in the forest), Domain Admins Administrators Backup Operators Server Admins Account Operators Print Operators Other groups delegated in your environment ***Don’t use built-in groups. Create custom delegation. Members of Print Operators & Account Operators can logon to DCs by default. Change this by modifying the policy. *** ===== Account Operators Members of this group can create, modify, and delete accounts for users, groups, and computers located in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit. Members of this group do not have permission to modify the Administrators or the Domain Admins groups, nor do they have permission to modify the accounts for members of those groups. Members of this group can log on locally to domain controllers in the domain and shut them down. Because this group has significant power in the domain, add users with caution. Allow log on locally; Shut down the system. Print Operators Members of this group can manage, create, share, and delete printers connected to domain controllers in the domain. They can also manage Active Directory printer objects in the domain. Members of this group can log on locally to domain controllers in the domain and shut them down. This group has no default members. Because members of this group can load and unload device drivers on all domain controllers in the domain, add users with caution. Backup Operators Members of this group can back up and restore all files on domain controllers in the domain, regardless of their own individual permissions on those files. Backup Operators can also log on to domain controllers and shut them down. This group has no default members. Because this group has significant power on domain controllers, add users with caution. Back up files and directories; Allow log on locally; Restore files and directories; Shut down the system. Remote Desktop Users Members of this group can remotely log on to domain controllers in the domain. This group has no default members. No default user rights. Administrators Members of this group have full control of all domain controllers in the domain. By default, the Domain Admins and Enterprise Admins groups are members of the Administrators group. The Administrator account is also a default member. Because this group has full control in the domain, add users with caution. Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. Server Operators On domain controllers, members of this group can log on interactively, create and delete shared resources, start and stop some services, back up and restore files, format the hard disk, and shut down the computer. This group has no default members. Because this group has significant power on domain controllers, add users with caution. Back up files and directories; Change the system time; Force shutdown from a remote system; Allow log on locally; Restore files and directories; Shut down the system. Domain Admins Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution. Enterprise Admins (only appears in the forest root domain) Members of this group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. Because this group has full control of the forest, add users with caution. Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. References: "Admin Free" Active Directory and Windows, Part 1- Understanding Privileged Groups in AD "Admin Free" Active Directory and Windows, Part 2- Protected Accounts and Groups in Active Directory Assign "Log On locally" Rights to Windows Domain Controller

Account Operators Can Logon to DCs?
Compromise “HelpDeskSteve” and compromise the domain. ***Compromise one help desk account to potentially compromise the domain. Help Desk always have long, complex passwords that change regularly. Right? *** ===== Account Operators Members of this group can create, modify, and delete accounts for users, groups, and computers located in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit. Members of this group do not have permission to modify the Administrators or the Domain Admins groups, nor do they have permission to modify the accounts for members of those groups. Members of this group can log on locally to domain controllers in the domain and shut them down. Because this group has significant power in the domain, add users with caution. Allow log on locally; Shut down the system. References: "Admin Free" Active Directory and Windows, Part 1- Understanding Privileged Groups in AD "Admin Free" Active Directory and Windows, Part 2- Protected Accounts and Groups in Active Directory Assign "Log On locally" Rights to Windows Domain Controller

Dumping AD Domain Credentials
Dump credentials on DC (local or remote). Run Mimikatz (WCE, etc) on DC. Invoke-Mimikatz on DC via PS Remoting. Get access to the NTDS.dit file & extract data. Copy AD database from remote DC. Grab AD database copy from backup. Get Virtual DC data. Two primary options as an attacker: Dump credentials using code directly on the DC or remotely. Copy the DIT from somewhere to an attacker controlled system. ===== PowerSploit Invoke-Ninjacopy can leverage PS Remoting to copy off NTDS.dit (though larger DB files may not copy properly and could be corrupt due to the way it copies NTFS data).

Dump AD Credentials with Mimikatz
Use Mimikatz to dump credentials from LSASS on the DC or remotely. KRBTGT Account password hash is most useful – enables attacker to create Golden Tickets.

Remotely Grab the DIT! Leverage WMIC (or PowerShell remoting) to Create (or copy existing) VSS Copy the files from the VSS Snapshot to local computer This screenshot shows the attacker used the clear text password discovered earlier using Mimikatz. What if we don’t have that?

Remotely Grab the DIT using Pass The Ticket
WMIC Pass-The-Ticket! Same scenario, except this time, we leverage a stolen (or forged) Kerberos ticket). Note that the NTLM password hash for an account can be used to get a Kerberos ticket (over-pass-the-hash)

Instead of VSS, why not leverage NTDSUtil?
***NTDSUtil is the command utility for natively working with the AD DB (ntds.dit) & enables IFM set creation for DCPromo. IFM is used with DCPromo to “Install From Media” so the server being promoted doesn’t need to copy domain data over the network from another DC. The IFM set is a copy of the NTDS.dit file created in this instance in c:\temp This file may be staged on a share for promoting new DCs or it may be found on a new server that has not been promoted yet. This server may not be properly secured. ***

The Back Door: DC Backups!
Are your DC backups properly secured? Are they on a network share? Are they on a NAS device? Who has access? Get access to DC backups & backdoor the domain with the ntds.dit file off the backup share. Make sure any network accessible location that stores DC backups is properly secured. Only Domain Admins should have access to them. Someone else does? They are effectively Domain Admins! ====

Exploiting Virtual Domain Controllers
Where are your DC virtual hard drives stored? Who administers the virtual server hosting the DCs? Are your VMWare/Hyper-V host admins considered Domain Admins? Hint: They should be. Get access to virtual DC storage data and have access to the domain credentials. Do you run VMWare? Vcenter Admins are full admins (DA equivalent to VMWare). With Vcenter Admin rights: Clone DC and copy down data to local hard drive. Your Vcenter Admin group is in AD? You probably want to change that… Delegate the proper rights to the appropriate groups, don’t provide an attacker the ability to backdoor AD through a Server admin account. Your Virtual Admins need to be considered Domain Admins. Once an attacker has the NTDS.Dit file… =====

Dump Password Hashes from NTDS.dit
Once an attacker has the system hive from the registry & the NTDS.Dit fie, they have ALL AD credentials! This screenshot is from a Kali box with the Impacket python tools installed. The DIT is dumped using the secretsdump python script in Impacket. Easy. Get the DIT = OWN the domain ====== The old way ( esedbexport ntds.dit Install libesedb Run ntdsxtract against the result. The new way: Impacket with secretsdump.py secretsdump.py Performs various techniques to dump secrets from the remote machine without executing any agent there. For SAM and LSA Secrets (including cached creds) we try to read as much as we can from the registry and then we save the hives in the target system (%SYSTEMROOT%\Temp dir) and read the rest of the data from there. For NTDS.dit, we have to extract NTDS.dit via vssadmin executed with the smbexec approach. It's copied on the temp dir and parsed remotely. The scripts initiates the services required for its working if they are not available (e.g. Remote Registry, even if it is disabled). After the work is done, things are restored to the original state.

MS14-068: (Microsoft) Kerberos Vulnerability
MS (CVE ) Patch released 11/18/2014 Domain Controller Kerberos (KDC) Service didn’t correctly validate the PAC checksum. Create a Kerberos “Golden Ticket” using a valid AD user account. November 18th, 2014 Microsoft released the MS patch to fix a major issue in how the Kerberos service validated the PAC checksum on Kerberos tickets. MS was the last patch relating to PAC validation. MS exploit enables a domain user to modify the Kerberos ticket to become a Domain Admin. The best description of this issue is writing “pilot” on a boarding pass and when the flight attendant sees it, escorts you to the cockpit welcoming you as “captain” and asks if you would like a coffee before take-off. == MS Reference

MS14-068: Exploit Process AS-REQ: Request a TGT with no PAC as standard user. AS-REP: DC replies with the TGT (no PAC). Generate a forged PAC (MD5) signed with user pw hash. TGS-REQ: Send the PAC-less TGT to the DC with the forged PAC as an Authorization-Data. DC creates a new TGT & inserts the forged PAC in its own Authorization-Data. TGS-REP: TGT with forged PAC sent to user - Domain Admin! (on vulnerable DCs) The exploit: Request a TGT without a PAC as a standard user, DC replies with the TGT. Generate a forged PAC, without a key… so “signed” with MD5 algorithm instead of HMAC_MD5 Send the PAC-less TGT to the DC with the forged PAC as Authorization-Data The DC creates a new TGT and inserts the forged PAC in its own Authorization-Data TGT with forged PAC sent to user – seen as Domain Admin on vulnerable DCs User to Admin in 5 minutes!

MS (PyKEK) Stage 1 “PyKEK” Python script exploit released 12/5/2014 Limited success with patched or Win2012/2012R2 DC in site The first published exploit of MS was 2 weeks after the patch, written by Sylvain Monné called PyKEK. PyKEK is a Python script that runs on any python-capable system (Raspberry Pi?) anywhere on the network as long as it can communicate with an unpatched DC. End up with a ccache file. Generated TGT only valid when submitted to vulnerable DCs. Mitigating factor: Limited success with patched or Win2012/2012R2 DC in site === MS Reference

MS14-068 (Mimikatz) Exploit Stage 2
Use Mimikatz to inject forged TGT. Domain Admin rights on vulnerable DCs. Take the PyKEK generated ccache file & inject the TGT into memory with Mimikatz for use as a Domain Admin! Using this ticket, access to the admin$ share on the DC is granted! ====

MS Kekeo Exploit 1/4/2015: Benjamin Delpy wrote a MS exploit & tweeted capability & screenshots - public as of 3/15/2015! Success: Patched or Win2012/2012R2 DCs in the same site. Automatically discovers the vulnerable DC & targets it! Additional steps making TGT valid for all DCs. Send new TGT to vulnerable DC, asking for Delegation ticket DC creates new TGT & sign PAC (HMAC_MD5) &its krbtgt key TGT with forged PAC sent to user – valid DA ticket on all DCs Benjamin Delpy (author of Mimikatz) wrote a MS exploit called Kekeo that improves on PyKEK. It finds & targets a vulnerable DC and works regardless if there are patched or 2012/2012R2 DCs in the site. Same exploit path as PyKEK, but adds another step at the end resulting in having a valid TGT which can be presented to any DC in the domain for access. It does this by using the exploit-generated TGT to get an impersonation TGT which works everywhere. Released the code on GitHub last month. ====== Kekeo Exploit steps: Request a TGT without a PAC as a standard user, DC replies with the TGT. Generate a forged PAC, without a key… so “signed” with MD5 algorithm instead of HMAC_MD5 Send the PAC-less TGT to the DC with the forged PAC as Authorization-Data The DC creates a new TGT and inserts the forged PAC in its own Authorization-Data TGT with forged PAC sent to user – seen as Domain Admin on vulnerable DCs Kekeo addition: Send the new TGT to the vulnerable DC, asking for a Delegation ticket The DC creates a new TGT and sign the PAC with HMAC_MD5 and its krbtgt key TGT with forged PAC sent to user – seen as Domain Admin on all DCs

User to Admin in 5 Minutes?

“Victims quickly learned that the path from a few infected systems to complete compromise of an Active Directory domain could be incredibly short.” “Kerberos Attacks: After gaining domain administrator privileges, attackers used the Kerberos golden ticket attack to authenticate as any privileged account—even after domain password resets.“ - Mandiant M-Trends 2015 report Two quotes from Mandiant’s M-Trends report released last month. Attackers compromise a few computers and quickly get Domain Admin rights Once they get DA rights, they use Kerberos Golden Tickets to persist, even when domain passwords were reset.

Forging Kerberos Golden/Silver Tickets
Requires KRBTGT pw hash / service account pw hash. Forged TGT (Golden Ticket) bypasses all user restrictions. Create anywhere & use on any computer on the network. No elevated rights required to create/use. Impersonate existing user. Invent a fictional user with elevated rights. Spoof access without changing group membership User password changes have no impact on forged ticket! Forging Kerberos tickets depends on the password hash available to the attacker Golden Ticket requires the KRBTGT password hash. Silver ticket requires the Service Account password hash. Create anywhere and user anywhere on the network, without elevated rights. Spoof access without modifying AD groups. Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account. ==== Requires prior admin access to pull NTLM password hashes (or exploit vulnerable KDC service). No elevated rights are required to generate or use a Silver (TGS) or Golden (TGT) Ticket. Created anywhere – they don’t need to be created on the domain or even on the same network. Used from any computer on the network – the computer doesn’t have to be domain-joined. Impersonate any user (invent one!) with existing rights or “elevate” account in ticket to any AD group: Domain Admins, Enterprise Admins, Schema Admins, etc. A forged Kerberos ticket can be created for a non-existent user on the network with full Domain Admin rights. Create a ticket with a valid user account and spoof another user’s access (user RID in PAC). User password changes have no impact or effect on a Golden Ticket. Can be used to bypass account smartcard requirement (interactive logon only). Since it is a TGT, any account restrictions are removed and aren’t checked for enforcement later.

KRBTGT: The AD Kerberos Service Account
KRBTGT account: disabled and not visible. Sign/encrypt AD Kerberos tickets Pwd set when domain created & (almost) never changes Password changes when DFL -> 2008 (or newer). Current & Previous Password valid for Kerberos tickets KRBTGT password exposed? Requires changing twice! Microsoft KRBTGT password change script on TechNet RODC Kerberos Account: KRBTGT_######. KRBTGT account password hash encrypts TGT & signs the PAC in TGT & TGS Has the same password last set date as when the domain was stood up (until changed) Password doesn’t change in production environments, except when raising the Domain Functional Level to 2008 or above. I have seen KRBTGT accounts with passwords from 2002 & 2003 in large production environments. Current & Previous Password are valid for Kerberos tickets. Changing it once isn’t good enough. KRBTGT password exposed? Requires changing twice! Microsoft KRBTGT password change script on TechNet published in February. RODC KRBTGT is specific to that RODC & cryptographically isolated from the domain KRBTGT account. === Microsoft KRBTGT password change script on TechNet published in February. Password changes can be tracked with the msds-KeyVersionNumber attribute which is the same as the unicodePwd attribute version number 2002/2003 Timeframe: Windows 2000, Windows XP, Windows 2003 Server. KRBTGT Account Reference:

KRBTGT: The AD Service Account
Domain KRBTGT account RODC Kerb Account: KRBTGT_###### & has BackLink attribute linking the account to it’s RODC. ==== Track Password Changes with Key Version Number (msds-KeyVersionNumber). KVNO is 2 in a new (2008) domain, increments with each password change.

The Golden Ticket (Forged TGT)
Encrypted/Signed by KRBTGT (RID 502). Bypasses Smart Card authentication requirement Golden Ticket options: Impersonate existing Domain Admin Create Fictitious user Spoof access by adding groups to the ticket Impersonate C-level executive access Where are the crown jewels? Golden Tickets became (in)famous (you know, more famous) during Skip Duckwall & Benjamin Delpy’s presentation at BlackHat 2014 in Vegas. The Golden Ticket is a valid TGT since it’s Encrypted & Signed by the domain KRBTGT account. It bypasses SmartCard auth requirement since it bypasses the usual checks the DC performs before creating the TGT. Used to get valid TGS tickets from DCs in the AD forest. Provides a great method of persisting on a domain with access to EVERYTHING! Events are logged on Domain Controller security logs. =====

Golden Ticket (Forged TGT) Communication
No AS REQ / AS REP (missing steps 1 & 2) Golden Ticket (forged TGT) presented to get TGS. TGS is valid – not forged Let’s step through creating a Golden Ticket

Forging a Golden Ticket: KRBTGT NTLM Hash
***First, we need the KRBTGT password hash. Where do we get it? Use Mimikatz! Newer method dumps current & previous KRBTGT password hashes (as of 3/31/2015, 2nd graphic). ***

Forging a Golden Ticket: Domain Admins
Next, we identify the Domain Admins. A good target is Luke Skywalker, RID 2601 By default, Mimikatz uses RID 500 which is the default Administrator account for the domain. Attackers are more likely to use an active, valid DA when using Golden Tickets to fly under the radar.

Forging a Golden Ticket: Impersonate Valid DA
Create a Golden Ticket using the account name “LukeSkywalker” with the RID “2601” (which belongs to LukeSkywalker). Mimikatz uses the KRBTGT account NTLM password (ServiceKey) to encrypt & sign the TGT. The Groups ID listed are: 513: Domain Users 512: Domain Admins 520: Group Policy Creator Owners 518: Schema Admins 519: Enterprise Admins Save the ticket to a file, or use /ptt to Pass-the-Ticket – automatically injects the TGT into memory. ==== Mimikatz and Active Directory Kerberos Attacks

Forging a Golden Ticket: Fictional User
Create a Golden Ticket using the account name “DarthVader” with the RID “2601” (which belongs to LukeSkywalker) or make up a RID (“9999”) Note that we could also impersonate a different account name (CEO or Director of R&D) & RID and add Luke Skywalker’s RID to the Groups ID list using the groups parameter (/groups). This means golden tickets can be customized to impersonate anyone with spoofed access to anything! === /ptt = Pass-the-Ticket – automatically injects the TGT into memory. Mimikatz uses the KRBTGT account NTLM password (ServiceKey) to encrypt & sign the TGT. The Groups ID listed are: 513: Domain Users 512: Domain Admins 518: Schema Admins 519: Enterprise Admins 520: Group Policy Creator Owners Mimikatz and Active Directory Kerberos Attacks

Silver Tickets. In late December 2014, Varonis posted that Silver Tickets are patched! Based on feedback from the security community, Varonis updated the blog post with a new title: “Microsoft Fixes A Kerberos Silver Ticket Vulnerability”. The post is still incorrect. I use this as an example of the confusion regarding Silver Tickets even among security professionals. >31:00< ==== In case the article is taken down, here it is: Microsoft Fixes Kerberos Silver Ticket Vulnerability Posted 12/29/2014 The Kerberos Golden Ticket already had a mythic status in the hacking world even before this summer’s Black Hat conference rolled around. In theory, a hacker could create a universal authentication ticket and lurk forever in an organization’s IT system. The how-to-accomplish part, though, was always a little murky. At the conference a lot of buzz was generated by some very solid papers and presentations explaining the nitty-gritty details of minting Golden Tickets. Over the summer more evidence also began to mount that Golden Tickets attacks had been seen in the wild, leading to CERT-EU’s prevention advisory. Still Not That Easy Even with all the new information and support from special grayware, it still ain’t that easy to obtain a Golden Ticket in a Kerberos-based Microsoft installation. Hackers would have to move laterally or gain direct access to a Microsoft domain controller, and then find the password hash of a special account, krbtgt—the secret key that’s used by Kerberos to encrypt all ticket granting tickets or TGTs. Once they’ve gotten that far, they could then handcraft the data fields of a raw ticket, specifying an expiration date far into the future and domain admin access. And that’s what Golden Tickets are made of: TGTs with an elevated access and effectively unlimited lifetimes, encrypted with the hash of the krbtgt password. You can read more about them here. The Silver Ticket I recently learned about a slightly less ambitious, but I think a more realizable, attack against Kerberos. The hackers this time focus not on the TGT, but a secondary credential, known as a service ticket (ST). For those who need a quick refresher course on Kerberos, I wrote about the whole shebang in these two posts, which compare this authentication system to the ticketing done once upon a time at Disney’s Magic Kingdom. Yes, I know, but there really were strong parallels. In brief, the ST is the credential a client sends directly to an , file, SQL, SharePoint, or any other Microsoft server in order to gain access. The ST was like the Disney ride ticket, whereas the TGT was similar to the general admission ticket. What is a Silver Ticket? It’s just a forged ST. The reason why the attack is easier to pull off is that an ST in Kerberos is encrypted with the hash of each server’s password. Unfortunately, these underlying server passwords are far too often weak. They’re entered manually by busy sys admins when they register the server’s name or SPN—e.g., 2015, sharepoint1234, <favorite beer>1235, etc. On the other hand, the krbtgt password, which is at the center of Kerberos authentication, is likely designed by security pros to be long, complex, and completely non-intuitive. Microsoft Steps In In the Silver Ticket attack, hackers passively collect STs on the network and then by using brute force techniques—very effective against obvious passwords– attempt to decrypt the data. If they’re successful, they’ll have the bit string of the server’s password hash. Just as with the Golden Ticket, they now can mint STs to gain access to the specific server that they’ve cracked. silver ticket hash Microsoft doesn’t validate the “Server Checksum” for the PAC. But not so fast! Microsoft added a separate check on the STs to prevent this kind of attack. It’s technically another hash that’s applied to a part of the ST, known as the Privilege Attribute Certificate (PAC). PACs were a Microsoft enhancement to Kerberos’s ST, containing identity details on the user, including group permissions. The idea was to save the servers some overhead in contacting Active Directory since the PAC would have all the necessary access rights for users. Signed But Not Validated So in the service ticket generated by Kerberos, Microsoft added a check on the PAC (see the graphic) itself: it hashed the PAC using the krbtgt password as a key, and then added the resulting hash value as a separate field. This should in theory completely block the Silver Ticket attack. The hackers don’t have the hard-to-get krbtgt account in this exploit, and therefore are prevented from forging the ST. Unfortunately, for performance reasons, many administrators turn off this validation check, which would add a delay as the Kerberos server itself is contacted to calculate the krbtgt hash. Worse yet, hackers discovered that even when this is enabled, Kerberos doesn’t properly validate the hash: you could enter a random string for the hash and still gain entry! By the way, Tim Medin, a security researcher and pen tester, has a beautiful presentation and a fuller explanation of Silver Tickets. You Should Update Microsoft finally got the message that Silver Tickets are a real threat. In November, they officially announced a vulnerability and issued a software update. The patch corrects the verification hole and is considered critical for Windows 2008R2 and below. For everything else, the patch should be done on, as Microsoft says, a “defense-in-depth” basis. Sure the Silver Ticket can be stopped with strong passwords on all the servers—this attack assumes guessable passwords. And if you don’t want to do a patch just yet, you can still monitor for a Silver Ticket exploit by looking for a special privilege escalation—it’s event You can read more about it in this Microsoft technet bulletin. Mission accomplished: this Silver Ticket threat is now over. But have the hackers finished finding vulnerabilities in Kerberos? I doubt it. Discover more hidden flaws in authentication systems. Our free ebook explains how to lower security risks.

The Silver Ticket issue is not something that can be patched.
It exploits the way Kerberos works in Active Directory. ===

The Silver Ticket (Forged TGS)
Service account configured for Kerberos auth (SPN). Encrypted with the service account private key: Service account NLTM password hash AD computer account NLTM password hash Service opens TGS ticket to validate. Golden Ticket equivalent access to service. No associated TGT exists, so no comm with a DC Alluded to at BlackHat during the “Golden Ticket” presentation (Duckwall/Delpy) and discussed partly during Tim Medin’s DerbyCon 2014 talk. Skip & Benjamin have provided additional information on Silver Tickets since, but confusion remains. While a Golden ticket is a forged TGT valid for gaining access to any Kerberos service, the silver ticket is a forged TGS. This means the Silver Ticket scope is limited to whatever service is targeted on a specific server. The attacker needs the service account password hash (perhaps from using Kerberoast?). TGS is forged, so No associated TGT, meaning the DC is never contacted. Any event logs are on the targeted server. In my opinion, Silver Tickets can be more dangerous than Golden Tickets. While the scope is more limited than Golden Tickets, the required hash is easier to get. =====

Silver Ticket (Forged TGS) Communication
No communication with the DC at all. Missing steps 1 & 2 (AS REQ / AS REQ) & steps 3 & 4 (TGS REQ / TGS REP) If PAC validation occurs, which we know it doesn’t, the Silver Ticket wouldn’t work since the attacker didn’t have the KRBTGT password hash to sign it (otherwise they would be using Golden Tickets!). === PAC Validation won’t fix this if computer account is used. “The Local Security Authority Subsystem Service (LSASS) process will send PAC validation messages to the DC when the LSA client (the application server) is not running in the context of local system, network service, or local service; or it does not have SeTCBprivilege (Act as part of the operating system). “

Silver Ticket: Domain Controller Exploitation
Attacker dumped AD & has all domain creds. Corp IT changed all user, admin, and service account passwords (and KRBTGT pw 2x). Attacker still has Domain Controller computer account password hashes. What is possible with these? Silver Ticket Exploitation Scenario: Company S was breached. Attacker dumped all AD credentials, so Corporate IT disconnected the internet & changed all user, service account, admin & KRBTGT (twice) account passwords. Attacker still has the Domain Controller Password hashes for the associated AD computer account.

Create a Silver Ticket using the account “LukeSkywalker” with the RID “2601” (which belongs to LukeSkywalker) to impersonate a valid DA account. Target the DC’s CIFS service which provides access to the Windows file system via shares (c$, d$, etc). This enables the attacker to connect to the Windows shares on the DC as a Domain Admin. ==== /target = DC FQDN /service = CIFS – Provides access to the Windows file system via shares (c$, d$, etc) /ptt = Pass-the-Ticket – automatically injects the TGT into memory. Mimikatz uses the Service Account NTLM password (rc4) to encrypt the TGS. The Groups ID listed are: 513: Domain Users 512: Domain Admins 518: Schema Admins 519: Enterprise Admins 520: Group Policy Creator Owners Mimikatz and Active Directory Kerberos Attacks

Once the Silver Ticket is created and injected, access the c$ share on the DC. Copy the exploit script to c:\windows\temp (or somewhere more interesting) That’s nice, we can get our exploit script on the DC’s file share, but how do we get it to run?

Create another Silver Ticket impersonating a valid DA, this time targeting the HOST service on the DC. This provides access to several internal Windows components which the service “HOST” automatically covers. This enables creation of a scheduled task… ==== Create a Silver Ticket using the account name (SAMAccountName) “LukeSkywalker” with the RID (ID) “2601” (which belongs to LukeSkywalker). /target = DC FQDN /service = HOST – Provides access to a variety of services on the DC /ptt = Pass-the-Ticket – automatically injects the TGT into memory. Mimikatz uses the Service Account NTLM password (rc4) to encrypt the TGS. The Groups ID listed are: 513: Domain Users 512: Domain Admins 518: Schema Admins 519: Enterprise Admins 520: Group Policy Creator Owners Mimikatz and Active Directory Kerberos Attacks

Use the injected Silver Ticket for the HOST service to create or modify a scheduled task on the target DC to run the uploaded exploit script. Of course we use an innocuous sounding task name or replace an existing valid one. Confirm the Scheduled Task is configured to run. Yup, it’s there and ready to run.

Success! Domain pwned!

Gain access to a Domain Controller’s AD computer account password. Generate Silver Ticket for CIFS SPN to access file system via default shares. Generate Silver Ticket for HOST SPN to create scheduled task to run as local System (and re-exploit the domain). HOST = alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem, policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman, netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss, remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule, tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc Summary: With the computer account password hash an attacker can compromise the computer. If that computer is a DC, an attacker can compromise the domain! All using Silver Tickets. By default, computer account passwords change every 30 days and 2 passwords are stored on the computer and on the DCs (the current & previous passwords). Sounds like the KRBTGT account password setting? PAC Validation won’t solve this since the services are system services. What if you want a SHELL to the DC? ==== “The Local Security Authority Subsystem Service (LSASS) process will send PAC validation messages to the DC when the LSA client (the application server) is not running in the context of local system, network service, or local service; or it does not have SeTCBprivilege (Act as part of the operating system). “ “The ValidateKdcPacSignature registry key was added to enable or disable PAC verification for services (KB ). [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] “ValidateKdcPacSignature”=dword: When the value of this entry is 0, Kerberos does not perform PAC validation on a process that runs as a service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You have to restart the computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry is present and has a value of 1. The default value in Windows Server 2008 for this entry is 0. In a nutshell, two main conditions prevent PAC validation from occurring in Windows OS: - the application has the SeTcbPrivilege privilege (“Act as part of the operating system”); - the application is a service and the ValidateKdcPacSignature registry key is set to disable PAC validation.” “Example of SMB scenario in Windows The client tries to access a Windows SMB share requiring Kerberos authentication. It sends the security token in the KRB_AP_REQ during session establishment. Windows SMB/CIFS server service requests the OS to create an access token. Now it needs to decide how to perform PAC validation. Windows SMB/CIFS server service runs under Local System Account. In terms of Kerberos terminology, the SMB/CIFS service represents the application server. The Local System Account has SeTCBPrivilege (SE_TCB_NAME privilege enabled). As a result, Windows OS will not be sending PAC validation messages to the DC. Only the server signature in PAC_SIGNATURE_DATA will be checked to determine if the PAC is valid. This verification is done thanks to the long-term key that the KDC shares with the server. Typically, when you establish SMB_SESSION_SETUP to a Windows member server, the server signature of the PAC from KRB_AP_REQ in the KerberosToken is checked.” ====== SPN Directory:

Silver to Gold Using a Silver Ticket to get a Golden Ticket with a DC’s computer account So, what if the DC has PowerShell Remoting enabled? Create 2 Silver Tickets using the DC’s computer account password: HTTP & WSMAN. This enables the attacker to run PowerShell commands remotely on the DC.

Silver to Gold Create a new PowerShell remoting session
Run customized version of Invoke-Mimikatz that gets the current KRBTGT password. Using a silver ticket with a DC’s computer account password hash, we got the KRBTGT password hash and now can generate Golden Tickets! Note: In my limited testing, I haven’t been successful using the previous computer account password to create silver tickets.

Blue Team (Defense) Computer security defense sometimes feels like 300 vs 300,000

Detect Mitigate Prevent Raising the Bar
Blue Team activities should align with one of these items. Each of these should “raise the bar” making the attackers job more difficult. Each hoop an attacker has to jump through increases the potential they will tip the defender of their actions.

Detecting MS14-068 On the Wire
AS-REQ TGS-REQ ***According to the Kerberos spec, a TGT might be requested without a PAC… Though not usually in a Microsoft environment. A TGS without a PAC? That should never happen. *** MS Reference

According to CERT-EU’s Golden Ticket whitepaper released last summer and last updated in October 2014, Golden Ticket attacks do not have clear indication in Windows logs. ====== Protection from Kerberos Golden Ticket Mitigating pass the ticket on Active Directory CERT-EU Security White Paper

I have found they can be detected clearly in the Windows event log.
These indicators were tested in a compromised environment and showed forged ticket use. They were also tested in a clean environment with no false positives.

Detecting Forged Kerberos Golden (TGT) & Silver (TGS) Tickets
Normal, valid account logon event data structure: Security ID: DOMAIN\AccountID Account Name: AccountID Account Domain: DOMAIN Golden & Silver Ticket events may have one of these issues: The Account Domain field is blank when it should contain DOMAIN. The Account Domain field is DOMAIN FQDN when it should contain DOMAIN. Golden Ticket events are on the Domain Controller. Silver ticket events will be on the targeted computer. This means that unless a Silver Ticket is used against a Domain Controller, the events will not be logged there. If you aren’t pulling security events from all your servers in addition to DCs, it’s time to start. Windows security events should have a domain listed in the domain field. I discovered events related to forged Kerberos tickets don’t correctly include the domain information. Forged Kerberos tickets have a blank domain field or the domain FQDN instead of the short domain name. In addition to these, I have found some other interesting items, but my research isn’t complete yet. 

Detecting MS14-068 Exploit Security Events
Normal, valid account logon event data structure: Security ID: DOMAIN\AccountID Account Name: AccountID Account Domain: DOMAIN MS Exploit events may have 1 (or more) of these: The Account Domain field is blank when it should be DOMAIN The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Account Name is a different account from the Security ID. If you have a DC without the MS patch you will see these events on that DC when a MS TGT is used. Much like Silver & Golden tickets, there are event anomalies in the domain field of the events. Additionally, with the PyKEK exploit, the account name is often a different name from the one listed in the Security ID (which is spoofed for admin access) *Ensure your DC build process involves patching the server with MS before running DCPromo.*

Golden & Silver Ticket Event Anomalies
Event ID: 4624 (Account Logon)* Account Domain is FQDN & should be short domain name Account Domain: LAB.ADSECURITY.ORG [ADSECLAB] Event ID: 4672 (Admin Logon)* Account Domain is blank & should be short domain name Account Domain: _______________ [ADSECLAB] Event ID: 4634 (Account Logoff) The events with the asterisk are ones with anomalies common across events where Kerberos forged tickets were used. Events with anomalies I’ve discovered include the standard logon event (4624), admin logon (4672), & logoff (4634). ====

Detecting MS14-068 Exploit Events
Event ID: 4624 (Account Logon)* The Account Domain field is DOMAIN FQDN when it should be DOMAIN. Account Name is a different account from the Security ID. Event ID: 4672 (Admin Logon)* Account Domain is blank & should be DOMAIN. Event ID: 4768 (Kerberos TGS Request) The italicized items are unique to this type of attack.

Silver Ticket Event 4624: Account Logon
Valid Forged Ticket Let’s look at some events - Note: These are just some of the events I discovered while researching forged ticket detection. In this Silver Ticket event on a member server, the domain field is the domain FQDN when compared with a valid event which has the short Domain Name.

Silver Ticket Event 4634: Account Logoff
Valid Forged Ticket In this Silver Ticket event on a member server, the domain field is blank and in a valid event, it contains the short domain name.

Silver Ticket Event 4674: PowerShell Remoting
Silver ticket event from the Silver Ticket use against a DC to gain access to PowerShell remoting. Domain is blank & the process name is wsmprovhost.exe used for PowerShell remoting.

Golden Ticket Event 4672: Fictional Admin Logon
Valid Forged Ticket In this Golden Ticket event on a Domain Controller, there are a couple of anomalies. The SID didn’t enumerate since this SID doesn’t exist in the domain. This never happens for a current logon event. Only after a user account is deleted will this occur and should only appear in archived events (since deleted users can’t logon). And the domain field is blank – the primary indicator.

Golden Ticket Event 4672: Fictional Admin Spoofing
Valid Forged Ticket In this Golden Ticket event on a Domain Controller, The Security ID and the Account Name doesn’t match. And the domain field is blank – the primary indicator.

Golden Ticket Use: KRBTGT password changed 2x
After the KRBTGT account password is changed twice, the existing Golden Ticket cannot be opened by a DC. This is the resulting event.

MS14-068 PyKEK Exploit Ticket Event 4624
This PyKEK exploit event on a Domain Controller has mismatched Security ID (showing the admin account) and Account Name – the valid domain account name used in the exploit. (and the domain field is the domain FQDN instead of the short domain name) Valid Forged Ticket

MS14-068 Kekeo Exploit Ticket Event 4672
This Kekeo exploit event on a Domain Controller exhibits the primary indicator – the domain field is blank. Valid Forged Ticket

MS14-068 Exploit Event on Patched DC
If someone is attempting to exploit MS on DCs with the patch, this is the event that is logged.

Other Interesting Events
Sometimes “normal” events are more than they appear.

VSS Volume Backup Events
Detecting Volume Shadow Copy (VSS) events – Dedicate a couple of DCs for backup. Any VSS events on other DCs are unauthorized and need to be investigated. These events are in the System Log.

NTDSUtil AD Database Snapshot Events
Detecting NTDSUtil snapshot events – Same thing, identify 1 or 2 where this is authorized and Any events on other DCs need to be investigated. These events are in the Application Log.

BatMan likes it! BatMan also likes mitigation.

Active Directory Attack Mitigation: Protecting Admin Credentials
New Admin Model Separate user & admin accounts No user accounts in admin groups Number of Domain Admins = 0 Complete separation of administration ADAs use SmartCard auth w/ rotating pw ADAs never logon to other security tiers. ADAs should only logon to a DC (or admin workstation or server). Protect AD admins from credential theft. Make sure only admin accounts are members of admin groups. I have found standard users in admin groups even when the organization had a rule requiring separate admin accounts. The Domain Admins group needs to be empty now. Domain Admins has full admin rights to Active Directory, all DCs, all servers, and all workstations. The Admin model needs to be revamped to protect against the current threats. This separation of administration is necessary to ensure that compromise at one level doesn’t compromise the domain, because when that happens, you are in a world of hurt. AD Admins use SmartCard authentication w/ rotating passwords via script to ensure the associated password hash changes regularly. This means that ADAs never logon to other security tier systems – only DCs or admin workstation/servers. ===== TWC: Pass-the-Hash and Credential Theft Mitigation Architectures Date: May 14, 2014 from 1:30PM to 2:45PM DCIM-B213 Speakers: Nicholas DiCola, Mark Simos Download Mp4: Slides:

Special workstation for admins. Windows 8.1 AntiVirus Microsoft EMET Microsoft AppLocker (app whitelisting) Auto-patching No Internet Access Separate network subnet(s) only allow comms to DCs & trusted admin servers A special admin workstation is necessary to mitigate credential theft. Even with two accounts, user & admin, the admin still uses a regular workstation for RunAs and RDP, which requires the admin credentials to be entered. This is unwise on a computer that access websites and . Last item – if possible, since these will be targeted. Based on Microsoft Recommendations presented at TechEd 2014 in the “Pass-the-Hash and Credential Theft Mitigation Architectures” ==== (DCIM-B213) Speakers: Nicholas DiCola, Mark Simos TechEd North America 2014 Presentation TWC: Pass-the-Hash and Credential Theft Mitigation Architectures (DCIM-B213) Speakers: Nicholas DiCola, Mark Simos Date: May 14, 2014 from 1:30PM to 2:45PM Download Mp4: Slides:

Admin & special accounts: Don’t allow delegation.

Active Directory Attack Mitigation: Protecting Service Account Credentials
Use long, complex (>25 characters) passwords. Implement Fine-Grained Password Policies (DFL >2008). Leverage “(Group) Managed Service Accounts”. MSAs passwords automatically changed. No Domain Admin service accounts running on non-DCs. Limit SAs to systems of the same security level, not shared between workstations & servers (for example). Use long, complex (>25 characters) passwords - Implement Fine-Grained Password Policies (DFL >2008). Leverage “(Group) Managed Service Accounts” - MSAs passwords automatically changed. No Domain Admin service accounts running on non-DCs. Limit SAs to systems of the same security level, not shared between workstations & servers (for example). Push your vendors to fix their credential management

AD Attack Mitigation: PowerShell Security
Limit PowerShell Remoting (WinRM). Limit WinRM listener scope to admin subnets. Disable PowerShell Remoting (WinRM) on DCs. Audit/block PowerShell script execution via AppLocker. PowerShell v3+: Enable PowerShell Module logging (via GPO). Enables tracking of PowerShell command usage Search PowerShell logs for “mimikatz” Leverage Metering for PowerShell usage trend analysis. JoeUser ran PowerShell on 10 computers today? Track PowerShell Remoting Usage Embrace, don’t block PowerShell. PowerShell is a tool that can be abused much like the others. Blocking the PowerShell.exe doesn’t stop PowerShell use. Note that Execution policy is NOT a security method. Limit PowerShell Remoting (WinRM) - Limit WinRM listener scope to admin subnet & Disable PowerShell Remoting (WinRM) on DCs. Audit/block PowerShell script execution via AppLocker. Once you have PowerShell v3+, Enable PowerShell Module logging (via GPO). This Enables tracking of PowerShell command usage providing capability to detect invoke-mimikatz use – just search PowerShell logs for “mimikatz” Leverage Metering for PowerShell usage trend analysis - JoeUser ran PowerShell on 10 computers today? Track PowerShell Remoting Usage through NetFlow data OR check the PowerShell logs on clients (event ID 06) & servers (event id 400) === Event ID 06: PowerShell Remoting (client PowerShell log) Event ID 400: PowerShell Remoting (server PowerShell Operational log) PowerShell command logging in PowerShell Log Event ID 4103 WinRM / PowerShell Remoting service port = 47001 WinRM default comm ports = 5985 (HTTP) & 5986 (HTTPS). Metasploit now supports PowerShell Remoting (3/24/2015) Powershell Remoting Remote Command Execution Authored by Ben Campbell | Site metasploit.com This Metasploit module uses Powershell Remoting (TCP 47001) to inject payloads on target machines. If RHOSTS are specified it will try to resolve the IPs to hostnames, otherwise use a HOSTFILE to supply a list of known hostnames. tags | exploit, tcp advisories | CVE , OSVDB MD5 | 2d8ac665c f92ec5020b93848c Bump up logging on PowerShell logs.

Mitigating Kerberos Attacks
Monitor scheduled tasks on Domain Controllers. Block internet access to DCs & servers. Monitor security event logs on all servers for known forged Kerberos & backup events. Include computer account password changes as part of domain-wide password change scenario. Change the KRBTGT account password (twice) every year & when an AD admin leaves. Monitor scheduled tasks on Domain Controllers. Block internet access to DCs & servers. Monitor security event logs on all servers for known forged Kerberos & backup events. Include computer account password changes as well as the KRBTGT account (twice) as part of domain-wide password change scenario. Change the KRBTGT account password (twice) every year (more frequently depending on corporate policy) & when an AD admin leaves. ===== The Domain member: Maximum machine account password age policy setting determines the maximum allowable age for a computer account password. In Active Directory–based domains, each computer has an account and password, just like every user. By default, the domain members automatically change their domain password every 30 days. Increasing this interval significantly, or setting it to 0 so that the computers no longer change their passwords, gives a malicious user more time to undertake a brute-force password-guessing attack against one of the computer accounts. The machine account password change is initiated by the computer every 30 days by default . Since Windows 2000, all versions of Windows have the same value. This behaviour can be modified to a custom value using the following group policy setting in Active Directory. Domain member: Maximum machine account password age You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options Question How often does the machine password account change in AD (is it different for various Windows operating systems)? Answer If a workstation does not change its password, will it not be allowed to log onto the network? Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed. So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time. Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally. The relevant Netlogon parameters that come into play and we can think about changing here are: ScavengeInterval (default 15 minutes), MaximumPasswordAge (default 30 days) DisablePasswordChange (default off). DisablePasswordChange would prevent the client computer from changing its computer account password. Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value = DisablePasswordChange REG_DWORD Default = 0 Group policy setting: Computer Configuration\windows Settings\Security settings\Local Policies\Security Options Domain member: Disable machine account Password changes Warning: If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller. Here is the article that talks about disabling automatic machine account password change: KB ScavengeInterval controls how often the workstation scavenger thread runs - the workstation scavenger is responsible for changing the machine password if necessary: HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value: ScavengeInterval REG_DWORD 60 to Seconds (48 hours) Default : 900 (15 minutes) MaximumPasswordAge determines when the computer password needs to be changed. Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value = MaximumPasswordAge REG_DWORD Default = 30 Range = 1 to 1,000,000 (in days) Group policy setting: Computer Configuration\windows Settings\Security settings\Local Policies\Security Options Domain member: Maximum machine account Password age To clear things up, it is 7 days on Windows NT by default, and 30 days on Windows 2000 and up. The trust password follows the same setting. So Trust between two NT 4 domains is 7 days. Trusts between Windows 2000 and up and anything else is 30 days. So what this means is if: 2000 and NT4 trust password is 30 days 2000 to 2000 is 30 days 2000 to 2003 is 30 days 2003 to 2003 is 30 days After the Netlogon service starts, the Workstation service scavenger thread wakes up. If the password is not older than MaximumPasswordAge, the scavenger thread goes back to sleep and sets itself to wake up when the password will reach that age. Otherwise, the scavenger thread will attempt to change the password. If it cannot talk to a DC, it will go back to sleep and try again in ScavengeInterval minutes. The ScavengeInterval setting can be modified to a custom value using the group policy setting in Active Directory. Group policy setting: Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval Further we have given the following clarification regarding the behavior described in:

Other Mitigation Delete (or secure) GPP policies and files with creds.
Remove Windows 2003 from your network. Disable default local admin account & delete all other local accounts. Implement Security Back-port patch (KB ) & enable regkey. Also adds new local SIDs. Set GPO to prevent local accounts from connecting over network to computers (easy with KB ). CMD Process logging & enhancement (KB ). Implement network segmentation. Incorporate Threat Intelligence in your process and model defenses against real, current threats. KB : Support for the Protected Users group Remote Desktop Client support for the Restricted Admin RDP mode Removal of credentials after logoff New well known (local) SIDs LOCAL_ACCOUNT – Any local account will inherit this SID LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP – Any local account that is a member of the administrators group will inherit this SID Removal of clear-text credentials from LSASS KB Steps: * Enable the Audit Process Creation policy. * Enable the “Include command line in process creation events” feature. === An overview of KB Microsoft security advisory: Update to improve Windows command-line auditing: February 10, 2015

Summary Attackers will get code running on a target network.
The extent of access is based on the defensive posture. Advanced attacks with forged tickets can be detected in logs. Protect AD Admins or a full domain compromise is likely! Early stages of my research, will have other interesting items to share later.  Attackers will get code running on a target network (spearphishing, web exploits, social engineering, etc). The extent of access is based on the defensive posture. Even advanced attacks that leverage forged Kerberos tickets can be detected in logs. Protect AD Admins from credential theft or a compromise of a few systems can quickly become a full domain compromise! Early stages of my research, will have other interesting items to share later.  I’m already working on a follow-up presentation. 

Thanks! Many others in the security community!
Alva “Skip” Duckwall Benjamin Delpy Chris Campbell Joe Bialek Matt Graeber Rob Fuller Will Schroeder Many others in the security community! My wife & family for putting up with me being on the computer every night! 

Contact Twitter: @PyroTek3 Email: sean [@] dansolutions . com
Blog: Github: Slides:

References Skip Duckwall & Benjamin Delpy’s Blackhat USA 2014 presentation “Abusing Microsoft Kerberos – Sorry Guys You Still Don’t Get It” kerberos-sorry-you-guys-dont-get-it Tim Medin’s DerbyCon 2014 presentation: “Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades” TechEd North America 2014 Presentation: TWC: Pass-the-Hash and Credential Theft Mitigation Architectures (DCIM-B213) Speakers: Nicholas DiCola, Mark Simos Chris Campbell - GPP Password Retrieval with PowerShell Protection from Kerberos Golden Ticket - Mitigating pass the ticket on Active Directory CERT-EU Security White Paper SWP_14_07_PassTheGolden_Ticket_v1_1.pdf An overview of KB Microsoft security advisory: Update to improve Windows command-line auditing: (2/10/2015)

References Kerberos, Active Directory’s Secret Decoder Ring Kerberos & KRBTGT: Active Directory’s Domain Kerberos Account PowerShell Code: Check KRBTGT Domain Kerberos Account Last Password Change Mimikatz and Active Directory Kerberos Attacks Mining Active Directory Service Principal Names MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege Microsoft Enhanced security patch KB SPN Directory: PowerShell Code: Find-PSServiceAccounts PSServiceAccounts

References DEF CON 22 - Ryan Kazanciyan and Matt Hastings, Investigating PowerShell Attacks Mandiant 2015 Threat Report PowerSploit: PowerView: PoshSec: Microsoft Kerberos PAC Validation microsoft-kerberos-pac-validation.aspx "Admin Free" Active Directory and Windows, Part 1 & 2 directory-and-windows-part-1-understanding-privileged-groups-in-ad.aspx

Appendix

PowerShell Module Logging GPO

My Lab Event Logging Config

Silver Ticket Event 4672: Admin Logon
Valid Forged Ticket

Valid Forged Ticket

Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection

Similar presentations

Presentation on theme: "Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection

Similar presentations

Presentation on theme: "Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection"— Presentation transcript:

Similar presentations

About project

Feedback