🐧
Hassan Saad
  • WHO AM I ?
  • Red Teaming
    • C2 Infrastructure
    • External Reconnaissance
    • Initial Compromise
      • Executable File (EXE)
      • HTML Application (HTA)
      • Visual Basic (VBA Macros)
      • Password Spraying
      • MITM Attack
      • Email Spoofing
    • Host Reconnaissance
      • Seatbelt
      • Screenshots & Keylogging
    • Host Persistence
      • Task Scheduler
      • Startup Folder
      • Registry AutoRun
      • COM Hijacking
    • Host Privilege Escalation
      • Automated Tools
      • Unquoted Service Path
      • Weak Service Permission
      • Weak Service Binary
      • Always Install Elevated
      • UAC Bypass
    • Domain Reconnaissance
      • PowerView
      • BloodHound
      • Linux Host
      • Internal Applications
    • Lateral Movement
      • PowerShell Remoting
      • PsExec
      • WMI
      • DCOM
    • Credentials Access
      • LogonPasswords
      • Security Account Manager (SAM)
      • Domain Cached Creds
      • Kerberos Tickets
      • DPAPI
      • User Impersonation
      • Pass The Hash
      • Over Pass The Hash
      • Internal Password Spraying
      • Sniffing
      • NTLM Relay
    • Pivoting & Forwarding
      • SOCKS Proxy
      • Reverse Port Forwards
      • Local Port Forwards
      • Session Passing
      • P2P Listeners
      • NTLM Relay
    • Kerberos
      • Authentication
      • Kerberoasting
      • ASREP-Roasting
      • Unconstrained Delegation
      • Constrained Delegation
      • Linux Credential Cache
    • Group Policy
      • Enumeration
      • RSAT (GPMC)
      • Sharp GPO Abuse
    • Access Control Lists (DACL)
      • GenericAll
      • WriteDacl
      • WriteOwner
    • MS SQL Servers
      • Enumeration
      • NetNTLM Capture
      • Command Execution
      • Lateral Movement
      • Privilege Escalation
    • Domain Dominance
      • DCSync Backdoor
      • AdminSDHolder
      • Remote Registry Backdoor
      • Skeleton Key
      • Silver Ticket
      • Golden Ticket
    • Forest & Domain Trusts
      • Parent/Child
      • One Way (Inbound)
      • One Way (Outbound)
    • Evasion Techniques
      • Obfuscation
      • Process Injection
      • LAPS
      • AppLocker
      • PowerShell Constrained Mode
      • AMSI
      • Antivirus Exclusion
  • Penetration Testing
    • Information Gathering
    • Scanning
    • Exploitation
    • Post Exploitation
    • Password Attacks
    • Web Attacks
    • Exploit Development
  • Technology Essentials
    • Linux
      • Basics
      • Tasks
    • Windows
      • Basics
      • Tasks
    • Network
      • Basics
      • Tasks
    • Programming
      • Basics
      • Tasks
  • Bug Hunting
    • XSS on Nokia
    • XSS on Wuzzuf
    • Business Logic Flaw on Souq (Amazon Company)
    • Rate Limit Bypass on LinkedIn
    • Sensitive Data Exposure on Google
  • Tools
    • Recon Hunter
    • Mail Hunter
    • Mobile Hunter
    • Chimera (Threat Hunter)
  • Extras
    • SQL Injection
    • Web Basics
    • Mobile Testing
      • Mobile Testing 1
      • Mobile Testing 2
      • Mobile Testing 3
Powered by GitBook
On this page
  1. Red Teaming
  2. Kerberos

Authentication

PreviousKerberosNextKerberoasting

Last updated 2 years ago

  1. A principal sends an authentication server request (known as AS_REQ) to the DC.

  2. If authentication succeeds, then the DC sends back a reply (AS_REP) to the principal. In this reply is a ticket that gives the principal permission to request access to resources on the network. This ticket is called the Ticket Granting Ticket (TGT). The TGT only proves that the principal has successfully authenticated on the network and provides access to one service – the Ticket Granting Service (TGS).

  3. When the principal wants to request resources on a Kerberos-enabled service, it first must request a ticket to access that specific resource from the TGS. This TGS Request (TGS_REQ) is sent to the TGS, hosted on the DC.

  4. The TGS then verifies the TGT and accepts that the principal has been given access to the requested resource presented in the TGS request. If everything checks out, then the TGS sends a reply (TGS_REP) back to the principal with a secret key inside called the session key. The session key is used to encrypt messages between the principal and the service for which it is requesting resources.

  5. Once the principal receives the TGS_REP, it can then request access to the network resource from the service. This is done through an Application Request (AP_REQ) to the service that is secured with the session key provided in the TGS_REP.

  6. Once the service receives the AP_REQ, it verifies that the request is valid by decrypting the message from the principal. Successful decryption is enough to validate the request. If everything checks out, then the service allows access to the requested resources and sends a reply (AP_REP).