net-sec-samenvatting/06_domain_domination.md

13 KiB

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

  • 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 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 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