# Domain domination ## Kerberos * main modern authentication mechanism in an Active Directory domain * protocol based on tickets * allows client and server to communicate over insecure network * requires both to trust the KDC third party * main actors in transaction * **KDC**: Kerberos Distribution Center * **Authentication Server (AS)**: verifies uses and issues Ticket Granting Tickets (TGTs) * **Ticket Granting Server (TGS)**: issues service tickets based on TGT * **client** requesting access * **service / target** the client want to access * Windows can fall back to NTLMv2 if Kerberos is not available ### Authentication ![Kerberos authentication](./img/ch06/kerberos_auth.png) * operation 1. request to AS on KDS * request includes timestamp encrypted using client password hash * AS looks up client password hash and decrypts timestamp * client gets ticket-granting ticket (TGT) including session key, encrypted using client password hash * session key encrypted with KDC secret 2. client stores TGT for future use 3. request to TGS on KDS for service access * client sends TGT and request for service * TGS decrypts and verifies TGT, and checks that user is authorised to access service * if yes, client receives * service ticket (ST) encrypted with service's secret * client-service (CS) session key: client and service use this for secure communication during session * 3 long-term keys * client long-term secret key: based on password hash of client * KDC long-term secret (domain key): based on password hash of **krbtgt** account * used to encrypt TGT * used to sign the Privileged Attribute Certificate (PAC) inside TGT * target long-term secret key * based on password hash of target service * used to encrypt service ticket * short-term keys * session key * used to encrypt auth token sent to TGS * used to ecrypt CS session key * CS session key * used to encrypt auth token sent to target * if KDC long-term secret is leaked, full freedom over domain is acquired * Kerberos uses highest encryption available * AS request-response 1. client uses password hash to encrypt initial request * contains * identify * optional timestamp * requested ticket lifetime * ... * hash can be NT hash but default is more secure hashes (PBKDF2 + AES) 2. send request to AS 3. AS attempts to decrypt message 4. on success, reply with TGT and session key * TGT consists of * username * start time and end time (validity of ticket) * PAC (privilege attribute certificate): details user's privileges and access rights, dual signed * with target secret * with KDC secret * client/TGS session key * encrypted using KDC secret * TGS request * authenticator (encrypted using client/TGS session key) * client identify * timestamp * optional nonce * service ticket request: reference Service Principle Name (SPN) client wants to connect with * TGT * TGS response * if TGS receives TGS request with valid TGT * TGS checks client is authorized to use service * if so, create service ticket (ST) and send it back * KDC does not validate privileges * ST has two parts * client portion encrypted using client/TGS session key * server portion encrypted using target secret * includes PAC of user * PAC validation * KDC signature (server signature) * generated by KDC using its private key * ensures PAC was indeed issues by KDC * service using KDC public key to verify signature * service signature * signature crated by service using session key shared between TGS and service * ensure PAC is valid within context of service * service uses target secret to verify signature * target service decrypts and validates server portion of ST and reads PAC * PAC not always fully verified for performance reasons ### Attacks #### Kerberoasting * comes down to cracking target service hash * operation 1. query AD for accounts with SPN 2. request service tickets from KDC using identified SPNs * a malconfigured Kerberos can be negotiated to use weaker encryption 3. extract service tickets 4. brute-force them offline to recover credential * no communication required with target service * no elevated credentials needed * explicitely targets service account passwords * these are chosen by humans -> probably easier to crack * should focus on interesting services: elevated privileges * mitigation * frequent password rotation * use safe passwords * use managed service accounts (MSAs) or group maanged service accounts (gMSAs) * automatically manages password rotation and other security features for service accounts * monitoring and detection * properly configure Kerberos to use strong encryption #### Silver ticket * forged service tickets * no need to compromise krbtgt account * relies on acquiring NTLM hash of service account * relies on Kerberos not fully verifying PACs * custom PAC * escalated permissions * encrypted using NTLM hash of service * PAC not valid but often not checked for performance reasons * mitigation * stract PAC validationn: performance impact * disable NTLM hash usage * regular password rotation * use safe passwords * use MSAs or gMSAs #### Pass-the-ticket * extract ticket from memory of compromised system * use this ticket to request service tickets * if admin ticket, go straight for domain controller * use `psexec` on services to pivot * mitigation * use Credential Guard (encrypted storage in memory) * monitoring and detection * least privilege: limit impact of compromised credentials or tickets #### Newer defenses * protected users * sensitive users can be marked as "protected" * keys are no longer stored in Local Security Authority Subsystem Service (LSASS) * strict limit on caching * weaker encryption schemes not allowed * credential guard * CPU-hardware assisted memory isolation ## NTLM attacks * 2 main strategies * sniff challenge-response and bruteforce client password / NT hash * relay SMB connection (relay attack) * attackers want victims to connect with their machines * manipulate NBT-NS (NetBios Name Server) or LLMNR (Link-Local Multicast Name Resolution) protocols * both allow hosts on subnet to resolve hostnames using multicast address * attacker poisons the response to trick them ([responder](https://github.com/lgandx/Responder) is a good tool for this) ### Spoofing attack * LLMNR or NTB-NS broadcast * used if DNS resolution fails * broadcast is unauthenticated UDP broadcast * any host can answer claiming to be target * attacker can listen for broadcasts for spoofing * similar issues on Linux with mDNS * web proxy auto-discovery (WPAD) * most browsers support automatic proxy detection (WPAD protocol) * protocol tries to resolve [http://wpad.internaldomainname/wpad.dat] * attacker can pose as web proxy * attacker can now see all web traffic and execute JavaScript * mitigation * ensure DNS entry is present * disable link-local resolution * disable autodetect proxy * monitor network ### Offline bruteforce * obtain NTLMv2 hash * spoofing attack * infected Word doc * ... * use hashcat to bruteforce hash ### SMB relay attack * trick client into connecting with attacker * relay authentication messages to KDC * mitigation * disable link-local resolution (as usual) * SMB signing * isolate clients using VLANs * monitoring ## Active directory recon * tools to automatically query and analyse AD information once host is compromised * look for excessive permissions (useful for lateral movement) * BloodHound generates diagrams of active sessions and relationships in AD * can find shortest path to domain admins from kerberoastable users ## Windows privilege escalation * principle of least privilege (POLP) * users should get exactly the permissions needed for their task, no more * best practices * make this default for all accounts * use flexible ACL platform to security elevate and downgrade credentials * audit privileges regularly * monitoring * common flaws * applications with known exploits * DLL search order hijacking * place malicious DLL in directory searched early when loading DLLs * proxy original DLL requests to hide exploit * loaded DLL gets same permissions as application using it * unquoted paths with spaces * `C:\Program Files\program.exe` * if `C:\` writeable, trick Windows into executing `C:\Program` * `wmic` tool lists services including vulnerable ones * writeable windows service executables * overwrite binaries with SYSTEM privileges * privilege escalation * persistence * stealth * mimic original behavior to avoid suspicion * unattended install files * used to perform automated installs * can contain plaintext passwords, info about file locations... * sometimes not cleaned up -> can be read by attacker * group policy preferences (GPP) * allows admins to create domain policies with embedded credentials * insecure storage mechanism * GPPs stored in XML file in SYSVOL (readable by all domain users) * passwords encrypted using *known* 32-byte AES key * [The C2 Matrix](https://howto.thec2matrix.com/) lists all known commercial and open command-control tools "for testing" ### User account control * separation of admin and non-admin functionality * allow users to run common tasks as non-admin or admin without switching user * local admins run most stuff as non-admin * user is asked for credentials if admin is needed * access token is generated for users containing access level of user * mean to improve security * levels * Vista: on or off * later 1. high: ask user for all changes 2. medium: only notify when programs want to make changes; programs can't interfere with prompt 3. low: same as medium, but screen isn't dimmed and programs can interfere with prompt 4. never notify: never ask * can be bypassed * DLL search order hijacking * Metasploit contains UAC bypass techniques ## Domain dominance * gain privileged position within a domain * typically done via * credential harvesting * privilege escalation * lateral movement * exploiting vulnerabilities * implications * widespread access * persistence * data exfiltration * destructive actions: randsomware, data wiping... ### Retrieving AD database * credentials stored in `ntds.dit` file * encrypted with PEK key stored in registry (`syskey`) * if admin access possible: use Volume Shadow Copy to create read-only copy of file * badly secured backups could also be exploited * tools can extract key from registry ### Kerberos golden ticket * golden ticket = TGT created by attacker * needs target and KDC secret * TGT, so secrets are identical (target service is the KDC itself) * requires access to NTLM hash or AES key of krbtgt account * tools allow extraction from memory or `ntds.dit` file * typically for domain admin account with very long validity * first interaction is TGS request using forged TGT * Kerberos is stateless, so doesn't know no authentication was done * mitigations * try to detect tickets with long validity * change krbtgt password *twice* * KDC keeps track of last two passwords and allows either (bruh) ### Skeleton key injection * only works for RC4 encryption * tool patches memory of LSASS process on domain controller and injects single password that works for ny account * manipulates how encrypted timestamp is validated * allows encryption to work with either user's NT hash or skeleton key NT hash * not persistent due to injection in memory * simple if admin rights are acquired on domain controller ### Domain replication attacks * dcsync * impersonating domain controller * requires domain replication privileges * all domain accounts should be considered compromised * dcshadow * more intrusive * register compromised host in domain as DC * craft useful change in schema (e.g. changing passwords) * trigger replication * rogue DC can be demoted after as change has propogated * stealthy: logging is usually done by DC starting the replication (bruh) ### Creating a domain admin account * possible with any user that can create users with arbitrary groups * noisy, will most likely be seen