Road to OSCP Part 5: Resizing and transferring your Kali Linux image across the LAN Linux to Windows

OSCP First Exam Attempt Outcome and Going To Try Harder

If you hadn’t guessed already, I failed my first OSCP exam attempt but I am willing to try harder. I rooted 2 boxes in 3 hours, but completely lost my momentum when my KVM hypervisor crashed due to excessive RAM usage by the ScreenConnect Proctoring Service spawning multiple Java processes during the exam.

Except from my exam report (just the bugs with ScreenConnect on my Ubuntu 18.04 Host running a Kali Linux Guest through KVM)

I emergency booted my 32-bit Kali Linux virtual hard disk with NO notes, and attempted to finish the exam with a shot open leg.

But ultimately, I failed because I was not prepared (particularly web application pentesting).

I can’t tell you what is on the machines that I was having difficulty with, but I and my peers went into a debate on whether or not it was a extremely deep rabbit hole, or if there really was a advanced web app injection flaw.

However, after interviewing several certificate holders on LinkedIn, it seems the going average is 3-5 OSCP exam attempts before passing.

I know several personal friends of mine that are on the same path, one lost credit for his 5 point lab report because he took a screenshot of opened notepad.exe of the proof.txt hash, which could have pushed his 65 points into a 70 and a pass. Another failed for using Metasploit on two machines (which includes auxiliary, payload, exploit, post modules of any kind, you are locked to the specific machine as soon as you run a Metasploit module).

I have decided to spend my BlackHat USA, Wicked6, and DEFCON weekend working on fixing my weaknesses, web app pentesting before rescheduling the exam. This time on my Windows gaming laptop.

Because of poor Linux host support for ScreenConnect:

My biggest problem with the proctoring was the screen-sharing software OffSec uses, ScreenConnect, which is a product of ConnectWise, a product I was familiar with as a network administrator. When used with Linux, it uses a java binary to connect you to the session. Unfortunately, this product directly hooks the xorg server in a way that leads to problems. I found out through repeatedly encountering issues with ScreenConnect that it is extremely buggy if your host machine is a Linux distro with an X-Desktop environment such as GNOME.

If the application closes, it will cause the xorg server to hang because it fails to detach itself properly, resulting in a frozen screen that you cannot recover from. The only option is a hard reboot. This isn’t OffSec’s fault obviously, but it did cause massive problems, especially due to the fact that ScreenConnect itself slowly bleeds memory over time, forcing you to eventually reset at some point.

– True Demon


I understand the necessity of introducing proctoring in the OSCP exam — a response to blatant cheating that was devaluing the qualification. However the proctoring software, ScreenConnect, which allows the proctors to monitor your screen, caused some technical issues. It ate up 40-90% of one of my CPUs, and when the proctor asked me to restart the software, my system completely froze up, forcing me to reboot.

When a different proctor asked me to restart the software again later, I explained what happened last time and they were kind enough to let me off the hook. That was fortunate because when I closed the software at the end of the exam, it caused another hard lockup! ScreenConnect is a Java application that’s theoretically cross-plaform, but it appears to have poor Linux support. If I had to retake the exam, I’d grudgingly use Windows as my host system.

– Laurence Tennant

I decided to take my KVM Guests and convert it into VMWare .vmdk format so I can retake my exam the commonly supported way, Windows running VMWare with Kali Linux Guest.

However I have a problem, it seems my virtual hard disk is a bit too large (as a result of QEMU-KVM snapshots).

Screenshot from 2019-07-26 14-09-41

As you can see, my regular 200GB Kali Linux partition has ballooned to 621 gigabytes! As a result of snapshots no doubt.

You see, every time before I ran a apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y, I made sure to generate a snapshot image. There were numerous instances that I broke my Kali Linux installation by…

1. Installing Elastic SIEM Ingestors directly into Kali Linux (not a good idea, because of all the traffic generated from your scanners and popping reverse shells, your online Kibana visualizations will be full of suricata alerts)

2. Broken upgrade (at one point)

And I felt fortunate that I made snapshots almost every single time that I made a major upgrade after reviewing apt-get update && apt list –upgradable.


In this article I plan to show you how to…

1. Shrink a bloated qcow2 virtual machine hard disk and then have the space reallocated

2. Convert the image into a VMWare compatible format

3. Transfer the file over the LAN at gigabit speeds using sftp (Windows OpenSSH doesn’t have secure-copy)

1. Shrink a bloated qcow2 virtual machine hard disk and then have the space reallocated

It actually took me several hours to have this done. So I did the remaining commands remotely with my cell phone.

First, go to your qcow2 image and run the command qemu-img snapshot -l image.qcow2. Then you can selectively delete the snapshots by ID with the qemu-img snapshot -d $ID image.qcow2 command.

Screenshot from 2019-07-26 14-14-06.png

Now, deleting the snapshots does not release the freed storage back to your hard disk, rather, it’s made available for reuse by the VM in case it needs to grow again. You need to run virt-sparsify, which is installed via sudo apt-get update && sudo apt-get install -y libguestfs-tools.

Then run virt-sparsify $PATH/image.qcow2 $PATH/shrunkenimage.qcow2

Screenshot from 2019-07-26 14-19-18.png

This command creates a CLONED qcow2 image that has all of the free space unoccupied by the virtual hard disk.

Warning, you may get the following errors

ERROR: warning: There may not be enough free space on /tmp

This means you need to change your TMPDIR with the command export TMPDIR=/$NEWPATH where NEWPATH could be something like a external hard disk.

ERROR: Enter key or passphrase (“/dev/sda5”)

This nondescript prompt shows up if you enabled LUKS encryption on Kali Linux. Simply enter your LUKS password and there you go. Unfortunately, it doesn’t throw a invalid password error whenever you get it wrong, so I spent about 10 minutes being baffled at the outcome. Basically, I expected qemu-img to explicitly tell me I was supposed to unlock the qcow2 image and to inform me that its the LUKS key that needs to be entered.

After it’s done, just run export TMPDIR=/tmp because this path is critical for things such as web browsing.


2. Convert the image into a VMWare compatible format

This is straightforward, qemu-img convert -f qcow2 -O vmdk image.qcow2 vmdkimage.vmdk.


3. Transfer the file over the LAN at gigabit speeds using sftp (Windows OpenSSH doesn’t have secure-copy)

Windows doesn’t normally support Secure-Copy or “scp” commands for some reason, but it does support sftp.

First navigate to where you stored your converted vmdk image. Then sftp WindowsUser@LANaddress. If your user has spaces, like mine, it would be sftp Chang\ Tan@

From the prompt, change directory with cd Downloads and then put vmdkimage.vmdk.

Screenshot from 2019-07-26 23-06-35

4. Load into the VMWare Player.

Now this new method is poorly documented (outdated instructions online and on the official docs) but basically, you create a new virtual machine and specify the virtual hard disk later. You may have noticed that the wizard fails to let you specify a VMDK, that comes at the end.

Anyways irritated because I am doing someone else’s job (the documentation writer), for them.

Select New Virtual Machine and select I will install the operating system later.

Screenshot from 2019-07-26 23-09-11

We’re going through the entire process of making up a empty VM. You will not have the option to change the virtual hard disk until you click Finish.

Select Linux

Screenshot from 2019-07-26 23-09-17.png

Make up a name for the VM

Screenshot from 2019-07-26 23-09-31.png

From this screen, change the RAM to whatever you desire, mine is 8192 MB.

Screenshot from 2019-07-26 23-10-09.png

Click Close and then Finish

Screenshot from 2019-07-26 23-10-09.png

From the Finished Screen, go back and click on Edit Virtual Machine Settings

Screenshot from 2019-07-26 23-10-17.png

Delete the bogus Virtual Hard Disk.

Screenshot from 2019-07-26 23-10-30.png

On the bottom click on Add… and then New Hard Disk

Screenshot from 2019-07-26 23-10-49.png

Now Add the FULL PATH to your converted vmdk file here.

Screenshot from 2019-07-26 23-11-06.png

Now you can start up the virtual machine in VMWare.

Screenshot from 2019-07-26 23-00-21

I already fixed the display issue in the upper screenshot (I screenshotted it using rdesktop lower resolution). However, there is a display bug where it may not detect your resolution on your Windows machine. You will need to write a xrandr script for your desired resolution and then run it each time you boot (cronjobbing it didn’t seem to work, albeit I used the @reboot parameter which means it may have happened before xserver loaded).

xrandr --newmode "1920x1080"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
xrandr --addmode Virtual1 1920x1080
xrandr --output Virtual1 --mode 1920x1080

Save that into and then run ‘bash’ to redraw your resolution to the correct size.





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s