Just-In-Time (JIT) Access

Users are granted privileges for a limited amount of time to perform a specific task, and once the time is up, the privileges are revoked automatically.

When JIT is used in combination with Active Directory, the Privileged Access Management Feature (PAM) must be enabled. Upon enabling the feature, it writes certain attributes that we can enumerate as a standard user. Note that once PAM is enabled in AD, it cannot be disabled again.

Even though JIT requires that Privileged Access Management is enabled in the domain, having it enabled is not a guaranteed indicator that JIT is in use since PAM also supports other features.

Exploitation of JIT solutions often happens in the later stages of an assessment.

Compromised JIT solution could become a weak link if multiple accounts with the power to request and approve access fall into the wrong hands

Most of the JIT solutions require that someone else approves the request on behalf of the user if it is not auto granted based on adding more trust to a specific user itself, so we may have to compromise several accounts in order to take advantage of the solution unless the solution itself has a vulnerability that we can exploit directly.

The AD PowerShell Module is often used by system administrators to manage AD via PowerShell and is a part of the Remote Server Administration Tools (RSAT). RSAT mostly requires administrative privileges, but simply loading the DLL used for Active Directory management does not. Microsoft.ActiveDirectory.Management.dll

Microsoft.ActiveDirectory.Management.Commands NamespaceMicrosoftLearn

Enumeration

#Microsoft.ActiveDirectory.Management.dll

Get-ADOptionalFeature -Filter *

IsDisableable      : False
Name               : Privileged Access Management Feature

For further enumeration, we can enumerate the infrastructure itself to find traces of JIT. We could thoroughly enumerate users, groups, GPOs, description fields, etc. Information about a JIT solution may also come from an assumed breach penetration test or from websites visited on compromised clients, etc.

found a JIT manager application on MGMT01 based on mary's browser history. Visiting http://mgmt01 reveals the web application.

According to the website, mary has previously requested access to the sql_admins group, and according to the status, it has been approved by someone. Reviewing the RequestedTimespan, it appears that the access lasted one hour

powerview

#check the validity of the group, see if the requested group still exist
Get-NetUser mary | select memberof

#found access group to JIT solution (j_request) instead, enum for other group and got j_approve and check its member to see if we can hack approver to approve access
Get-NetGroup | ft
Get-NetGroup j_approve | select member

#enum available GPO that applies to user groups
Get-NetGPO | select displayname

#enum interesting GPO
Get-NetGPO l_web01
gpcfilesyspath           : \\corp.com\SysVol\corp.com\Policies\{99EC2AB4-0FD4-406E-8FDA-BE451DEB2AA6}

#check $gpcfilesyspath/Machine/Preferences/Groups/groups.xml to see if it configure anything, e.g. 
<Properties action="U" newName="" description="" deleteAllUsers="0" deleteAllGroups="0" removeAccounts="0" groupSid="S-1-5-32-544" groupName="Administrators (built-in)">
<Members>
<Member name="CORP\la_web" action="ADD" sid="S-1-5-21-3515682028-2106700410-3524882512-7604"/>
</Members>
</Properties>
#GPO is configuring the built-in Administrators group on a specific machine in the domain, adding the group la_web to the Administrators group

Requests may also be configured to happen automatically, adding more trust to the user account logging in. Can try request for other group, but even it is granted, may need logout and login to refresh TGT for the new groups to be in effect. Hard to do if we do not know the password for the account.

Abusing MSSQL / WinRM enabled App Ser

In this case, the sql_admins gives access to the MSSQL instance on SQL01 and it uses a remote login. If our user is added to the sql_admins group in Active Directory, we can simply purge our existing Kerberos tickets with klist purge, initiate the login, and have a new TGT assigned. The same goes for WEB01 since it has WinRM enabled, which supports Kerberos authentication.

#check if currently already granted a interested group
whoami /groups

#after approval
klist purge
Enter-PSSession -ComputerName WEB01

#in remote session
hostname
whoami /groups
#got admin

Refreshing TGTs may not always be a simple task unless we have access to clear text passwords or we can use NTLM authentication with pass-the-hash techniques

In RDP client, #Microsoft SQL Server Management Studio#

MSSQL 1433a' or 1=1-- | a' or '1'='1