Privilege Elevation

The subject creates or modifies an identity, directory, group, role, token, or authorization attribute so that an account or process receives permissions beyond its normal access context. This may include introducing privileged Security Identifier History values, modifying group or role assignments, or altering identity attributes that are evaluated during authorization.

The change may be made through an approved administrative interface or through unauthorized technical manipulation.

The subject bypasses, manipulates, or abuses a technical control intended to regulate elevated execution or access to protected capabilities. This may include abuse of set-user-ID or set-group-ID permissions, bypass of Windows User Account Control, manipulation of sudoers or cached sudo authorization, or alteration of platform consent and privacy controls.

This Sub-section concerns defeating or misusing the elevation control itself.

The subject activates elevated permissions that are assigned to them or conditionally available through an established organizational or operating-system mechanism. This may include sudo, an elevation prompt, just-in-time access, privileged identity management, cloud role assumption, or an equivalent governed process.

The activation may itself be approved or unapproved. It should be recorded where entering the elevated context is materially relevant to an investigation, including where an approved mechanism is used outside its authorized purpose or before a later infringement.

Kerberoasting is a technique that can be exploited by a subject to escalate privileges and gain unauthorized access to sensitive systems within a network. From the perspective of a subject—who may be a low-privileged user with legitimate access to the network—the attack takes advantage of weaknesses in the Kerberos authentication protocol used by Active Directory (AD).

Kerberos Authentication Process

In a Kerberos-based network (like those using Active Directory), clients—users, computers, or services—authenticate to services using service tickets. When a client wants to access a service (e.g., a file server or email service), it requests a service ticket from the Ticket Granting Service (TGS). This request is made using the Service Principal Name (SPN) of the target service.

The TGS then issues a service ticket containing the hashed credentials (password) of the service account associated with that SPN. These credentials are encrypted in the service ticket, and the client can present the ticket to the service to authenticate.

Subject Requesting Service Tickets

A subject, typically a domain user with limited privileges, can exploit this process by requesting service tickets for service accounts running critical or high-privilege services, such as domain controllers or admin-level service accounts. These accounts are often associated with SPNs in Active Directory.

The subject can identify these SPNs—often for high-value targets like SQL Server, Exchange, or other administrative services—by querying the domain or using enumeration tools. Once these SPNs are identified, the subject can request service tickets for these service accounts from the TGS.

Cracking the Service Tickets

The key aspect of the Kerberoasting attack is that the service tickets contain hashed credentials of the service account. If these service accounts use weak, easily guessable passwords, the subject can extract the service tickets and attempt to crack the hashes offline using tools like Hashcat or John the Ripper.

Since these passwords are typically not subject to regular user password policies (i.e., they may not be as complex), weak or easily cracked passwords are a prime target for the subject.

Privilege Escalation and Unauthorized Access

Once the subject successfully cracks the password of a service account, they can use the credentials to gain elevated privileges. For example:

• If the cracked service account belongs to a high-privilege service (e.g., Domain Admins or Enterprise Admins), the subject can use these credentials to access systems, services, and parts of the network they would not ordinarily be permitted to access. This could include sensitive files, servers, or even Active Directory itself.
• The subject can use these credentials to move laterally within the network, expanding their access to additional systems that are typically restricted to high-privilege accounts.
• With administrative-level access, the subject can make changes to critical systems, alter configurations, or install malicious software. This could lead to further insider events, such as data exfiltration, malware deployment, or even persistent backdoors for ongoing unauthorized access.

Reconnaissance and Exploitation

The subject can perform additional reconnaissance within the network to identify other high-privilege accounts and services associated with service accounts. They can continue requesting service tickets for additional SPNs and cracking any other weak passwords they find, gradually escalating their access to more critical systems.

With broad access, the subject may also attempt to manipulate access controls, elevate privileges further, or carry out malicious actions undetected. This provides a potential stepping stone to more serious insider threats and an expanded attack surface for other actors.

The subject exploits a vulnerability in an operating system, application, kernel component, service, driver, hypervisor, container runtime, or other privileged software to obtain permissions beyond their existing execution context.

This Sub-section applies as Preparation where exploitation increases the subject’s capability before a later infringement. Where the exploitation itself causes the principal harm, unauthorized modification, or operational disruption, investigators should also apply the relevant Infringement.