Tally Writeup w/o Metasploit
Reconnaissance
Run the nmapAutomator script to enumerate open ports and services running on those ports.
All: Runs all the scans consecutively.
We have 22 ports open.
Port 21: running Microsoft ftpd
Ports 80, 81, 5985, 32843, 32844 & 47001: running Microsoft HTTPAPI httpd 2.0
Port 15567: running Microsoft IIS httpd 10.0
Ports 139 & 445: running SMB
Ports 135, 49664, 49665, 49666, 49667, 49668, 49669 & 49670: running Microsoft Windows RPC
Port 808: running ccproxy-http
Port 1433: running Microsoft SQL Server 2016
Port 32846: running StorageCraft Image Manager
Before we move on to enumeration, let’s make some mental notes about the scan results.
We have a bunch of ports running web servers. We’ll start off with enumerating port 80 and work our way down. I terminated nmapAutomator since it would have taken a very long time to enumerate all those ports.
Nmap didn’t report anonymous login for FTP, so this is unlikely to be our point of entry, unless we get credentials. Nmap has reported this as a false negative before, so it is always good to manually verify it.
Same goes for SMB. We’ll need credentials to access the service.
Port 1433 is running a Microsoft SQL Server. If we can find a system administrator account, we’ll have code execution.
Enumeration
I always start off with enumerating HTTP.
Port 80 HTTP
Visit the application in the browser.
It’s running SharePoint. Since SharePoint has specific directories, we won’t use the normal word list when we gobuster it. Instead we’ll use a specific one to sharePoint.
This outputs a ton of results to go through. It is easier to instead just do a google search on the important URLs in SharePoint and try those. One interesting entry is the viewlsts.aspx page that displays the site content.
We see that there is one document and one site page. Clicking on Documents we find a document titled ftp-details.
Download the document and view it.
The document contains an FTP password but no username. Next, click on SitePages. This for some reason directs us to the following incorrect URL.
Simply removing the _layouts/15/start.aspx# portion of the URL allows us to view the site pages.
Click on the Finance Team page.
Now we have both a username and password to log into the FTP server!
Port 21 FTP
Log into FTP.
View the files in the current directory.
Navigating through the directories, we find a KeePass database in Tim’s directory.
Download the database to our attack machine.
The KeePass database is password protected. In order to crack the password using John the Ripper (JtR), we’ll have to extract a JtR compatible hash of the password. This can be done as follows.
Then run JtR on the hash.
We get a hit back informing us that the password is “simplementeyo”.
Now we have all the information we need to open the KeePass database. To do that from the command line, we’ll use the kpcli program.
Going through the entries, we find two credentials. One of the credentials Finance/Acc0unting labelled Tally ACCT share will probably give us access to SMB, so we’ll start there.
Port 139 SMB
Let’s log into the ACCT share using the credentials we found.
After enumerating all the directories, we find two interesting entries. The first is in the zz_Archived\SQL directory.
View the content of the file on the attack machine.
We have SQL credentials for an old server.
The other interesting entry we found is in the zz_Migration\Binaries\New folder directory.
The file tester.exe looks like a custom executable file. Download it to your attack machine.
Use the strings command to print the list of printable characters in the file.
We get another SQL username and password.
Port 1433 SQL
Let’s test out the first credentials we found to log into the database.
-S: server
-U: username
-P: password
We get a login failed error. Let’s test out the second credentials we found.
We’re in!
Since this is a System Administrator (SA) account, we should be able to run system commands.
Test out the whoami command using xp_cmdshell.
We get an error telling us that the xp_cmdshell option is disabled. Since we have an account with the highest level of privilege (SA), we can simply enable it.
Try the whoami command again.
Perfect, we finally have code execution!
Initial Foothold
Let’s use that to send a reverse shell to our attack machine.
Download the Nishang repository and copy the Invoke-PowerShellTcp.ps1 script into your current directory.
Add the following line to the end of the script with the attack machine configuration settings.
When called, this sends a reverse shell back to our attack machine on port 1234.
Start up a python server in the directory that the shell script resides in.
Setup a listener to receive the reverse shell.
Then download and execute the powershell script in SQL.
We get a shell!
Grab the user.txt flag.
Privilege Escalation
View the content of Sarah’s desktop directory.
There’s two interesting files SPBestWarmUp.ps1 and SPBestWarmUp.xml. Looking through the SPBestWarmUp.xml script we see that it is running the SPBestWarmUp.ps1 with Administrator privileges every hour (indicated by the field <Interval>PT1H</Interval>) . This is probably run as a scheduled task. We can confirm that once we get a reverse shell with administrator privileges.
Let’s view the permissions on SPBestWarmUp.ps1.
As the user Sarah, we own the file. Therefore, we could simply change the content of the file to include a reverse shell and wait until the hour changes and the scheduled task gets executed with administrator privileges.
Change the content of the script to send a reverse shell back to our attack machine.
Wait until the scheduled task is run. We get a shell!
We can view the scheduled tasks using the following command.
Grab the root.txt flag.
Lessons Learned
To gain an initial foothold on the box we exploited four vulnerabilities.
Insecure SharePoint permissions. An anonymous user was allowed to access SharePoint content. We used that to our advantage to enumerate site pages and documents on SharePoint. The administrator should have secured/restricted external anonymous access, especially when it is a public facing website.
Cleartext FTP credentials. After enumerating the content saved on SharePoint, we found a document that contains an FTP password and a site page that contains the username that corresponded to the password. We then used these credentials to log into the FTP server. Sensitive information should not be stored in cleartext and permission restrictions should be put in place that prevent an unauthorized user from accessing files that contain sensitive information.
Weak authentication credentials. After logging into the FTP server, we found a KeePass database that was protected with a weak password. Clearly, the user is security-aware and therefore is using a KeePass database to store his passwords. However, the password to the database was not strong enough and therefore we were able to crack it in a matter of seconds and gain access to all the other passwords that the user had stored in the database. The user should have used a strong password that is difficult to crack.
Hardcoded password in an executable. After cracking the password for the KeePass database, we found SMB credentials that allowed us to log into one the shares. There, we found a custom executable file that contained a hardcoded SQL system administrator (SA) password. Using these credentials, we logged into the SQL database and executed system commands to gain initial access on the box. It’s considered insecure practice to store passwords in applications. If it is absolutely necessary, there are several ways you can obscure these passwords and make it harder for an attacker to discover the passwords. However, with enough skill, time and motive, the attacker will be able recover the passwords.
To escalate privileges we exploited one vulnerability.
Security misconfiguration. There is a scheduled task that runs a user owned file with administrator privileges. Since we owned the file, we simply changed the content of the file to send a reverse shell back to our attack machine. To avoid this vulnerability, the scheduled task should have been run with user privileges as apposed to administrator privileges. Or, restrictions should have been put on the script that only allow an administrator to change the file.
Last updated