hackthebox.eu: Heist Walkthrough
This was a pretty fun Windows box with some good repetition of basic techniques that I have used on live tests. Having these tricks and thought processes in your bag for real tests will not lead you wrong and may help to crack further into networks. Users gonna use and reuse passwords. Let’s get started.
Starting enumeration
nmap -sC -sV -vvv -p- -oA Heist_Scripts 10.10.10.149
Dirb http://10.10.10.149
Not a lot to find, but there is a website with a login page. Let’s take a look at this and see what’s there.
So… what happens if we login as a guest?
Not a whole lot here, but there is an attachment which is interesting. Let’s check that out.
There are some passwords here, time to see if we can recover them.
Cracked
enable password (stealth1agent)
type 7: rout3r:$uperP@ssword
type 15: admin:Q4)sJu\Y8qz*A3?d
Looking at the web interface and the config file we found I have a few usernames of interest such as hazard and admin. I also have 3 passwords. That combined with smb open on the target means that I can test these passwords pretty easily using metasploit.
Looks like the user hazard has access to login to the machine via SMB (sort of, but not really… see below), now to do some more research to see how to use this.
I got a pointer toward lookupsid.py from the forums and tried this to see what I could get. I did get some user enumeration which is a cool new technique!
The interesting thing here is finding the domain SUPPORTDESK. I wonder if this will change some things…
I went back to the MSFConsole smb_login module with an expanded file of users and passwords to try.
Now that is interesting… I’ve found a new user with a valid SMB password. It looks like the user Chase is re-using the type 15 password from the Cisco config. Let’s see if we can get some success using that user and password combination.
The forums suggested this blog post (https://alionder.net/winrm-shell/) to take a look at WinRM. It’s not a sure thing that code like this works… I spent an hour or two messing around with this code and trying to get it to work with various WSMAN errors and other things. But eventually I got it working. I also discovered that for some reason typing the Windows command ‘whoami’ crashed this shell. Not sure why, maybe PowerShell doesn’t like it, but that’s a mystery I’ll have to keep researching to see if I can figure it out.
And I finally got some success here! Later I learned that the user Chase is a member of the group “Remote Management Users” whereas the user Hazard is not. This explains why Chase can get a winrm shell and Hazard didn’t work.
Only in users :(
In remote management users :)
I then navigated up to C:\Users\Chase\Desktop and found the user.txt file.
So that’s user done, now time to start looking at root. Time to go back to enumeration. I need to see where I am and if there are other files and things that can help me. This is why sometimes penetration testers refer to loops in testing, once you gain some access it is necessary to find out more info and see what additional opportunities are opened by that access.
Looking in the folder with the user.txt there is a file named todo.txt. This is as good a place as any to start. Not a whole lot of info here, but that’s not unusual on a test either.
I checked running processes using the PowerShell command Get-Process. There are some firefox browsers running which could be interesting. I know there is a way to dump information from firefox so I’ll take a look at that. (I also saw a procdump in there before so that’s a clue, which seems to have been from another CTF-er. But then this happens in tests as well… people leave stuff lying around that tells you information about a system)
It looks like we could use process dumping to look through the memory of firefox and maybe find useful things. I had to download the exe from Microsoft and Python SimpleHTTPServer on my attack machine to host it. Then I used BitsAdmin on the Windows target to transfer it over. (https://blog.jourdant.me/post/3-ways-to-download-files-with-powershell)
Running it seems to work, now to check and see if anything useful drops out
Then we can grab strings to a file using strings.exe from Windows SysInternals from the output of this dump and maybe find something useful in there.
It took a LOT of looking around and scrolling but then I found something interesting.
login_username=admin@support.htb&login_password=4dD!5}x/re8]FBuZ&login=
I did figure out that I could shorten the amount of scrolling a lot by running strings and using the PowerShell command pipeline to send the output into Select-String to look for password in the output. Using that technique I got what I was looking for in the first line.
I can login to the web interface with that email and password, so I’ll add that password to my file of passwords and try SMB login again.
Those valid credentials should work in our ruby exploit from before. I’ll go and update and see what that gets me.
Looks like we’re in.
And done! This was a fun box with some good general techniques that I forgot and could be useful. The method of keeping a list of usernames and passwords and constantly checking them with a known method (in this case SMB Login scanner with MSF) is one that comes up from test to test. It’s a bit different than brute forcing because you have known passwords and are checking them against known users. This is because humans like to reuse passwords from place to place and if you can connect the dots you can achieve a lot more than you might be able to otherwise. Big thanks to MinatoTW for the cool machine!
Items learned or remembered:
Cisco config file passwords and cracking
Impacket lookupsid.py usage
WinRM shells via Ruby
More methods of transferring files to Windows (specifically BitsAdmin)
SysInternals dumpproc
SysInternals strings