*Published : 05 Jan 2025* # What is the *Protected Users* AD security group ? The protected users group is a package of security features that will act Windows systems as they manage your authentication. **Here is a representation of the Kerberos protocol** ```mermaid sequenceDiagram Client->>+DC: AS_REQ (ask for session key and TGT) DC->>-Client: AS_REP (respond with TGT and session key) Client-->>+DC: TGS_REQ (hands TGT, ask for TGS) DC-->>-Client: TGS_REP (respond with TGS) Client-->>+Server: AP_REQ (hands TGS) Server-->>-Client: AP_REP (respond with Service Session key) ``` **The following features are applied** * **DC's perspective** : * Will refuse NTLM, Digest, or CredSSP authentication attempts (legacy authentications Security Support Provider) * Will refuse Kerberos DES or RC4 encryption in the pre-authentication steps * In the [AS_REQ](http://aurelien26.free.fr/kerberos/01_simple/AS_REQ.html), the client encrypts a timestamp (*PA-ENC-TS-ENC*) with the user's Kerberos ekeys (an altered form of the user's password). This data block can be intercepted on the network and the password can be cracked, especially if encryption is down graded to DES ([ASREQroast](https://www.thehacker.recipes/ad/movement/kerberos/asreqroast)). * In the AS_REP, the DC respond to the client with a TGT and with a bloc of information called [EncASRepPart](http://aurelien26.free.fr/kerberos/01_simple/AS_REP.html) which is encrypted with the user's ekeys (can be [intercepted](https://github.com/Yaxxine7/ASRepCatcher/tree/main) and cracked offline) * Will refuse Kerberos authentication attempts without pre-authentication * Will only hand 4 hour long TGT * Will refuse any kind of Kerberos delegation (constrained, unconstrained, or ressource based) * **Authentication client's perspective** : * Will not cache password hashes locally (though *some* authentication secrets will remain, as [a mimikatz dump might show you](https://adsecurity.org/?page_id=1821), i.e the Kereberos Ticket itself, but these are still [harder to re-use](https://www.thehacker.recipes/ad/movement/kerberos/ptt)) * LSASS will not store Kerberos ekeys * Will not cache domain credentials (dcc cache) - Offline login will not be permitted * **Authentication server's perspective** : * Nothing **Here is a non-exhaustive view of the risks covered by Protected Users** | | Offensive technics | The risk covered by protected Users | | ----------------------- | ---------------------------------- | ----------------------------------------------------------------------------------------------------------- | | NTLM | Capture LM/NTLM hashes | Yes | | NTLM | Relay NTLM auth | Yes | | NTLM | Pass the hash | Yes | | Kerberos | Pre-auth bruteforce | No but makes it harder (stronger encryption is used) | | Kerberos | Pass the key | No but makes it harder (Kerberos eKeys are still created and stored for a brief moment upon authentication) | | Kerberos | Overpass the hash | Yes | | Kerberos | Pass the ticket | No | | Kerberos | Pass the cache | No | | Kerberos | Forge tickets using krtgt password | No | | Kerberos | ASREQroast | No but makes it harder | | Kerberos | ASREProast | No but makes it harder | | Kerberos | Kerberoast | No | | Kerberos | Delegations abuse | Yes | | Kerberos with cert auth | msDS-KeyCredentialLink abuse | No | | Kerberos with cert auth | UnPAC the hash | Unknown | | Kerberos with cert auth | Pass the Certificate | No | # Thing required before going throught this Protected Users aims at securing the various attacks being made against privileged user account in Active Directory. In a defensive strategy and starting from nothing, there exists some steps to take before going through the hussle of PU (and the NTLM restriction problem). > [!Tip] Less admins means less problems Once plug-in, **PU will provoke authentication issues**. The fewer users you have to get into PU, the fewer headaches might happen. > [!Tip] Prioritise NTLM relay mitigation > The NTLM restrictions you are about to perform will never cover the whole organization. If NTLM relay mitigation are not setup, efforts made in the direction of PU will be useless as the attacker can just use NTLM relay on remaining the remaining privileged service accounts (without PU) > [!Tip] Turn on some PU features manually > Finally, PU is a package of features. It's best to turn on some of them manually first in order to better anticipate NTLM problems when PU is really setup > - **[Disable RC4 and DES encryption](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos)** on Kerberos on target accounts > - Enable "**this account is sensible and cannot be delegated**" manually on target accounts > - Make sure kerberos pre-authentication is enabled manually on target accounts > - Disabled Digest and CredSSP > - Reduce kerberos TGT lifetime via [GPO](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket) > - Make sure admin accounts are not used for scheduled task or as service account Finally, as system requirements, * The functional level of the schéma needs to be of 2012 R2 - DCs can be on Windows Server 2012 R2 ; * Windows client systems will apply PU restrictions with Windows 7 as long as they have KB2871997 installed (and higher OS versions). # How does Protected Users operates ? A Security Support Provider (SSP) is a collection of authentication package for a type of authentication protocol. For exemple, the NTLM SSP has NLTMv1 and NTLMv2 authentication package. Those SSP are allowed to create and manipulate authentication secrets (i.e alternated forms of the user's password) on windows systems. Since Windows 7, the way a user can give out its password to authenticate is very standardized and secured. * On the client system, the password is briefly stored in clear-text and handled to the SSP which each have their own ways and format for storing credentials (NTLM has simple hashed, Kerberos has ekeys, session keys and tickets). * The user gives it's password once and it's automatically formated to every available SSP format. - In the client system, any application that wish to use AD authentication must go through the Security Support Provider Interface (SSPI) which itself will handle authentication with the server [Here is how Microsoft draw it](https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/security-support-provider-interface-architecture) ![[authn_securitysupportproviderinterfacearchitecture 1.jpg]] - Upon authentication, the SSP negociation takes place with the server ; this is where the server gives the list of supported SSP to the client, and where both agree on which SSP to use (usually either Kerberos or NTLM) # Anticipate NTLM usage Applications ***usually*** use Kerberos for their authentication but also ***might*** not. If Microsoft only developpes Kerberos compatible application since the year 2000, tiers applications might not. Microsoft gives a good [list](https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/security-support-provider-interface-architecture#BKMK_NTLMSSP) of what NTLM can still be used for (and therefore, service that needs to be tested if you were to implement PU) **What is NTLM used for ?** (what is about to break) > - Client/server authentication > - Print services > - File access by using CIFS (SMB) > - Secure Remote Procedure Call service or DCOM service > - RDP when the destination computer is referred as an IP address **What is Kerberos used for ?** > - ==Active Directory queries that use the Lightweight Directory Access Protocol (LDAP)== > - Remote server or workstation management that uses the Remote Procedure Call service > - Print services > - Client-server authentication > - Remote file access that uses the Server Message Block (SMB) protocol (also known as Common Internet File System or CIFS) > - Distributed file system management and referral > - Intranet authentication to Internet Information Services (IIS) > - Security authority authentication for Internet Protocol security (IPsec) > - Certificate requests to Active Directory Certificate Services for domain users and computers > - RDP when the destination computer is referred as a domain name Considering that all Microsoft developed applications work with Kerberos only, it's hinted that Tier 0 admins should be your priority targets # Application and authentication protocol In the kerberos authentication process, the AS_REQ and AS_REP messages can be integrated into various transport protocoles depending on the destination application service. For exemple, for web application, the AS_REQ is encoded into the HTTP header, while LDAP expects it in the bind request In the LDAP case, Authentication can achieve this either by using LDAP and LDAPS bind requests that are both accepted by domain controllers. Or they can pass their windows authentication over LDAP using SASL bind (Simple Authentication and Security Layer). ### LDAP Simple Bind Ldap Simple Bind * the AD account password is transmitted in **clear text** over the network * Is accepted by the DC unless signature has been configured![[Pasted image 20250115143726.png]] * Is rejected once Protected Users is set on the account * ![[Pasted image 20250115144050.png]] * As mentioned in the prerequisites of Protected Users, imposing NTLM relaying mitigation (and thus LDAP signature) should be a priority over protected User. ### SASL Bind * SASL is a framework that aims to provide an authenticating mechanisms on top of any transport protocole. Thos SASL mechanisms are not used any more * Instead, in an authentication context, SASL is calls for an abstraction layer called GSS-API. * GSS-API is a set of functions that allow secure exchange of information ("tokens") for the authentication protocole. It provides security services to the data transmitted by it. * It accompanies its data exchange with a cryptographic tag known as an Message Integrity Code (MIC), * it encrypts the token if needed * Those token are opaques to the upper layers. They contain blobs of informations used by a given authenticating protocole. * Before all of this, SASL has to know which authenticating protocole is installed on each parties. For this, it calls SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) to list and select available protocols. * Here is an example of a Kerberos AP_REP inside a SASL/LDAP bind request with LDP.exe as LDAP client. ![[Pasted image 20250115171449.png]] > [!NOTE] Before GSS-API > In the first RFC defining SASL, "SASL mechanisms" were supposed to be cleary defined and listed protocols for any developers to pick from. RFC 2222 states that IANA was suppose to maintain this list of "allowed" authentication mechanisms. The IETF did [standardized some of them](https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml) but eventually gave up. # LDAP over TLS Clients may access AD data using LDAPS ; Even thought TLS can achieve client authentication at its level by having a user certificate on the client machine, this is not required for the [ldaps session to take place](https://learn.microsoft.com/en-in/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority). Here is a capture packet of LDAPS initialisation process ![[Pasted image 20250116120042.png]] It's unclear how most LDAPS clients are implemented but, since we know that client authentication is not needed on the TLS layer for the LDP.exe client, it has to be required in the application layer (therefore either using a simple bind, or a SASL Bind). So in the end, LDAPS might or might not work with Protected Users depending on which binding operation is used # Using NTLM logs Microsoft dedicate special log settings for NTLM usage via a group policy object called "[Network security: Restrict NTLM: Audit NTLM authentication in this domain](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain)". - Logs end up on each DC in Applications and Services Log\Microsoft\Windows\NTLM. NTLM blocking was [extensively studied](https://techcommunity.microsoft.com/blog/askds/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows/397191) for a time until NTLM was seen as impossible to get rid of. - You can [query each DC remotely](https://github.com/estradeb/AD-help-script/blob/main/QueryNtlmEvents) and export it to CSV to parse it. - The idea was to follow the path there after : 1. GPO 1 : [Network security: Restrict NTLM: Audit NTLM authentication in this domain](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain)" to single out left over NTLM services on the target OU of servers 2. GPO 2 : "*Network security: Restrict NTLM: Add server exceptions in this domain*" to add them as exceptions on the target OU of servers 3. GPO 3 : "*Network security: Restrict NTLM: NTLM authentication in this domain*" to forbid any new NTLM authentication on the target OU of servers Exemple of Event 8004 : ![[Pasted image 20250211153547.png]] >[!warning] >While "Restrict NTLM" GPOs might be of help to single out left over NTLM services in the environnement, there is little chance security admins can find an appropriate solution for all the impacted services. >**Protected users has the advantage of targeting a specific set of critical users** on which NTLM can be disabled without headache **but lack the ability to single out service exceptions**. # Documentation | Microsoft, «Protected Users Security Group,» Available: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group. | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A. Bordes, «Kerberos samples,» Available: http://aurelien26.free.fr/kerberos/. |