Privilege Escalation on LEIKAH

Abuse ACL access over groups

Mon, 01 Jan 0001 00:00:00 +0000

Member principals within a Active Directory group automatically inherits the accesses and privileges granted to that group. If the principal we control have sufficient privileges over a group (GenericAll, GenericWrite, AllExtendedRights or Self-Membership), we can add another principal (e.g. a low-priv user) to the group so the principal inherits all access rights granted to the group.

Linux Perspective

From a Linux attacker machine, we can use bloodyAD to add a user to a group.

Abuse ACL Access over User

Mon, 01 Jan 0001 00:00:00 +0000

Force Change Password

The most naive method is to simply change that user’s password. With ForceChangePassword access, which is included with GenericAll access on a user, we should be able to change that user’s password without knowing their current password.

Note

Change an account’s password is considered destructive to the environment due to the potential disruption it may cause. With the account’s password changed, Users may not be able to log in. If the account is a service account, the service can become unavailable. During real-life engagements, only use this technique if written consent from the client is obtained.

ACL Abuse

Mon, 01 Jan 0001 00:00:00 +0000

Permissions in Active Directory are controlled through Access Control Lists (ACL). Each security principal (user, group, process) has a corresponding ACL. ACLs define both who has access to which assets or resource, and what level of access they are granted. ACLs are made up of Access Control Entries (ACE) that explicity allow and/or deny users or groups from access.

If misconfigured, ACLs can be leveraged by attackers to achieve lateral movement or privilege escalation inside the domain. The abuse of ACL access rights are dependent on the specific access granted to the attacking user.

ASREProasting

Mon, 01 Jan 0001 00:00:00 +0000

Theory

Normally, in order for users to obtain their Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC), they have to verify their identity via pre-authentication. If the verification is successful, the KDC would then send a TGT back inside its Authentication Service Response (AS-REP), which is encrypted with a key derived from the user’s password.

Active Directory has an option inside the user’s User Account Control (UAC) settings called Do not require Kerberos pre-authentication. As its name suggests, the KDC would response with the AS-REP containing the user’s encrypted TGT without first verifying the user’s identity.

Group Managed Service Account

Mon, 01 Jan 0001 00:00:00 +0000

The need to protect service accounts against attacks such as Kerberoasting gave rise to Managed Service Accounts (MSA) and later Group Managed Service Accounts (gMSA). While both supports automatic password generation and rotation, the latter allows the same service accounts to be used acrossed different machines.

Members of the group that manage the gMSA are intended to be the machine accounts of the computers where the service account will be deployed on. Members have the ability to read the password hash of the service account (ReadGMSAPassword).

Kerberoasting

Mon, 01 Jan 0001 00:00:00 +0000

Kerberoasting is a privilege escalation technique for Active Directory credited to security researcher Tim Medin, who presented the attack back in 2014. The attack targets domain accounts with Service Principal Names (SPN), which are unique identifiers that Kerberos uses to map a service to a domain service account in whose context the service is running.

Theory

Once the user completes pre-authentication, the Kerberos KDC (Key Distribution Center) issues the user a Ticket Granting Ticket (TGT). The user can then use the TGT to obtain a service ticket from the Ticket Granting Service (TGS) at the KDC. The service ticket is issued for a particular service principal, whose password hash is used to encrypt the service ticket. Users can then use the service ticket to authenticate to the service principal to access the service.

Kerberos

Mon, 01 Jan 0001 00:00:00 +0000

Kerberos is a ticket-based network protocol that enables centralized authentication and authorization management in a network. This is the process a client goes through to access a service in a Kerberos network:

Client requests a Ticket Granting Ticket (TGT) from the Auethenitcation Service (AS) of the Key Distribution Center (KDC) (AS-REQ).
The KDC authenticates the client, then sends back a response (AS-REP).
Client decrypts the AS-REP using the hash of their password, obtaining the TGT.
Client hands the TGT to the Ticket Granting Service (TGS) alongside the service principal name (SPN) of the service they are attempting to access (TGS-REQ).
TGS after verifying the TGT and ensure the client can access the SPN, then responds to the client’s request (TGS-REP).
Client decrypts TGS-REP, obtaining the service ticket.
Client hands the service ticket to the service.
The service decrypts the service ticket using the password hash of its service account and verifies its content, then grants the client access.

Microsoft’s implementation of Kerberos sits at the center of Active Directory. The Domain Controllers (DC) acts as the KDC, enabling both centralized storage of credentials as well as user privileges and permissions. At the same time, different steps within the Kerberos authentication flow can be leveraged by attackers to obtain access to accounts and services. Attackers can use responses from the KDC to crack the target’s password offline (roasting attacks), extract Kerberos tickets from compromised machines, or forge tickets to escalate their privileges.

Lateral Movement and Privilege Escalation

Mon, 01 Jan 0001 00:00:00 +0000

Lateral movement and privilege escalation within the Active Directory domain is a gradual and cyclical process of analyzing the access our account(s) have on the domain’s principals (other users, groups, machines, services), and abusing those accesses to either access other machines or services, or other more-privileged accounts. We repeat this process with the end-goal of achieving total domain compromise.

Misconfigurations of accesses and privileges are what enables attacker’s movement with Active Directory. Rather than obtaining access after exploiting a vulnerability, more commonly, the attacker simply logs in.