Saturday, December 24, 2016

ConvertTo-MvmcVirtualHardDisk: The entry is not a supported disk database entry for the descriptor.

I’ve ran into this issue twice now when trying to convert an ova into a vhd using ConvertTo-MvmcVirtualHardDisk.

Here’s what happens…

I download the ova, rename the file to .zip and extract the contents.  The virtual machines have typically been created/tested with Virtual Box so the archive usually includes an ovf and vmdk.

I open PowerShell and attempt to use ConvertTo-MvmcVirtualHardDisk but run into this error:


Here’s how to fix it.

1. Download dsfok-tools by Dariusz Stanislawek and extract the contents of the archive.

2. Run cmd.exe as administrator

3. Extract descriptor1.txt from the vmdk using dsfo.exe


4. Make a backup copy of descriptor1.txt.  If anything goes wrong just inject the backup.

5. Open descriptor1.txt (using NotePad++)


6. Comment all the lines after #DDB, delete the NUL and any “white space” at the end of the file.  Save the file.


7. Inject descriptor1.txt into the vmdk using dsfi.exe


8. Convert the vmdk to vhd


9. Create the virtual machine, attach the disk and boot the machine.


SkyDogCTF Walkthrough


This is the first time I’ve attempted a CTF.  Here’s a walkthrough for each flag.

Nmap scan…


SSH on port 22222 – Found flag #1 flag{53c82eba31f6d416f331de9162ebe997}


Cracked the hash – “encrypt”

 findmyhash md5 -h 53c82eba31f6d416f331de9162ebe997  


I pulled the index.html file with wget and found a comment about IE4 and /oldIE/html5.js


Reviewed the js file; the first line is hex…


Decoded the hex and found flag #2 flag{7c0132070a0ef71d542663e9dc1f5dee}


Cracked the hash – “nmap”


DIRB scan… and found /personnel


Tried to access /personnel but it seems to be “protected”


I assume “IE4” was a clue so I tried accessing /personnel with an IE4 user agent – found flag#3 flag{14e10d570047667f904261e6d08f520f} and another clue – so far so good.


I decided to take a look with FireFox… Agent Hanratty


Cracked the hash – “evidence” …  Clue = new + flag = newevidence


I tried to access /newevidence with IE4 user agent – 401 Unauthorized


Same using Burp Suite (using proxy to manipulate user agent) and FireFox


Tried to logon, hanratty:hanratty, didn’t work;


What is Agent Hanratty’s first name? Google says it’s Carl


I setup Burp Suite Intruder in an attempt to gain access but the free version is pretty slow…


… so I wrote a crude script in Python.  This let me try several username combinations with a couple dirb word lists for the password.  I got lucky with username “carl.hanratty” and password “Grace”.


 import subprocess;  
 import os;  
 import base64;  
 import time;  
 username = 'carl.hanratty'  
 seperator = ':'  
 count = 0  
 filename = '/usr/share/wordlists/dirb/others/names.txt'  
 target = ''  
 useragent = '--user-agent=Mozilla/4.0 (compatible; MSIE 4.0; Windows NT 5.0)'  
 accept = '--header=Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'  
 acceptlang = '--header=Accept-Language: en-US,en;q=0.5'  
 acceptenc = '--header=Accept-Encoding: gzip, deflate'  
 connection = '--header=Connection: close'  
 with open(filename) as fp:  
   for line in fp:  
     password = line.replace("\n","")  
     creds = username + ":" + password  
     b64 = "%s" % (base64.b64encode(creds.encode('ascii')))  
     print "Trying %s %s" % (creds,b64)  
     auth = "--header=Authorization: Basic %s" % (b64)  
     if os.path.isfile("/root/Desktop/scripts/newevidence"):  
     count += 1  

I took a look with FireFox…


Checked out the hyperlink “Evidence Summary File” - found flag #4 flag{117c240d49f54096413dd64280399ea9}


Cracked the hash – “panam”


The hyperlink “Possible Location” links to an image.jpg, saved it, ran it through binwalk and then steghide with password “panam”.  found flag #5 flag{d1e5146b171928731385eb7ea38c37b8} and another clue.  So far, the cracked hashes are clues for the next flag but…


I got stuck here for a bit and tried a bunch of things.  I ended up taking things back to the beginning with nmap.

I wasn’t sure why the server was running HTTPS; everything I found so far was accessible over HTTP.  I took a look using openssl s_client and found flag #6 flag{f82366a9ddc064585d54e3f78bde3221}. 


Since it’s labeled “flag3” - I was supposed to find it earlier in the game – better late than never.

Cracked the hash – “personnel” – HA! yes, this was a clue for earlier.  Thank goodness dirb found the directory.


Stuck again… decided to give SSH a whirl… meh.  Brute force here we come…

I tried some standard name lists with various combos of username formats with the cracked hashes and clues as passwords.  It was taking too long; the username list had too many names.  I need to be more specific…

I wrote a Powershell script which queried Google looking for names related to the search strings I provided… (cheating? maybe… I didn’t review the results to see if anything was related to SkyDogCTF).

 $searchstrings = @(  
 $names = gc C:\temp\names.txt  
 $googlenames = $null  
 $firstnamelastnames = @()  
 $googlednames = @()  
 $i = 1  
 $totalsearches = $searchstrings.count  
 foreach($searchstring in $searchstrings)  
  write-host "Searching Google [$i of $totalsearches]... " -foregroundcolor Green  
  $googlesays = (Invoke-WebRequest "$searchstring" -useragent ([Microsoft.PowerShell.Commands.PSUserAgent]::InternetExplorer))  
  $googlenames += $names | ?{$googlesays.rawcontent.contains($_)}  
  $f = 1  
  $totalnames = $googlenames.count  
  $l = $1  
  write-host " Parsing Results..." -ForegroundColor Cyan  
  #look for "firstname lastname"  
  foreach($firstname in $googlenames)  
   if($googlesays.rawcontent.contains("$firstname") -eq $true)  
    $googlednames += "$firstname"  
   foreach($lastname in $googlenames)  
    if($googlesays.rawcontent.contains("$firstname $lastname") -eq $true)  
     $firstnamelastnames += "$firstname $lastname"  
  write-host "...Sleeping" -foregroundcolor Red  
  start-sleep -seconds 2  
 $firstlast = ($firstnamelastnames | Group-Object).Name.replace(" ","")  
 #$first_space_last = ($firstnamelastnames | Group-Object).Name  
 $first_dot_last = ($firstnamelastnames | Group-Object).Name.replace(" ",".")  
 $first_underscore_last = ($firstnamelastnames | Group-Object).Name.replace(" ","_")  
 $firstlast += $firstlast.tolower() + $firstlast.toupper()  
 #$first_space_last += $first_space_last.tolower() + $first_space_last.toupper()  
 $first_dot_last += $first_dot_last.tolower() + $first_dot_last.toupper()  
 $first_underscore_last += $first_underscore_last.tolower() + $first_underscore_last.toupper()  
 #$googlednames | Group-Object  

… this gave me a smaller list of usernames.  It was taking about 2 minutes to run ~200 usernames with one password at the default of 16 tasks in hydra.  I wasn’t sure of the username format so I used a couple variations and ended up with ~600 usernames and 8 passwords.  Again, I used the previous cracked hashes and clues for the password list.  I kicked hydra off and headed to bed.

The next day… ugh.  No hits but looking back through the logs I see a bunch of failures, reattempts, etc.  To make a long story short, I rebooted the server and tried the  user list with each password using the –p switch.  I also throttled tasks down to 1.  I was finally able to run through the lists with a smaller number of failures/reattempts.  I’ll have to revisit this again in the future… anyhow, I got a hit.


SSH to the server with the credentials for barryallen; Found flag #7 flag{bd2f6a1d5242c962a05619c56fa47ba6}


Cracked the hash – “theflash”


The last flag has to be in the file; so I downloaded it


Ran it through binwalk; appears to be a zip archive


Unzip and binwalk… looks like a dmp?


Ran it through volatility


Dumped the clipboard contents… “666c61677b38343164643364623239623066626264383963376235626537363863646338317d”


found flag #8 flag{841dd3db29b0fbbd89c7b5be768cdc81}


Attempted to crack the hash… not a known hash.


Thursday, November 17, 2016

No OpenCL compatible devices found

I ran into an issue running hashcat on my Hyper-V Kali Linux VM.  I kept getting an error “OpenCL Platform #1: Mesa, skipped! No Open CL compatible devices found ERROR: No devices found/left”


I did a little Googling and eventually came across this site which documents how to install the Intel CPU ICD.

Very helpful stuff!  From there I followed the OpenCL driver link and finally ended up at a download link for the OpenCL Runtime for Intel Core and Intel Xeon processors.


I downloaded the runtime for Ubuntu, decompressed the archive and ran the install script.


Opened hashcat and booyah!  There’s my CPU.


Tuesday, October 18, 2016

Citrix corrects clear text credentials in latest version of SecureHub

It looks like Citrix has finally corrected an issue with WorxHome/SecureHub for iOS.  Versions of WorxHome/SecureHub prior to version included clear text username and password in the WorxHome logs.

Friday, October 14, 2016

XenMobile device grooming using the XenMobile public API and Powershell

I've been working on a Powershell module for XenMobile which you can find here.  The module mostly has get commands for now but I am actively updating...

Current functions


**Update** 10/24/2016 - I changed the XenMobile Powershell module by renaming delete-xmdevice to remove-xmdevice

For example, here's how you can delete inactive devices from XenMobile using this module.

This can be done in the XenMobile console but if you have a bunch of devices to clean up - it might be easier to do it with a script or scheduled task.

Friday, October 7, 2016

Citrix pulls Secure Hub from iOS App Store! Worx Home is missing too!

It looks like Citrix pulled Secure Hub from the iOS App Store and Worx Home is missing as well!

Obviously, there's probably a problem with Secure Hub and they had to pull it. But, uh... with Worx Home missing as well - how are iOS users supposed to enroll?

Happy Friday - Thanks Citrix!

Update - 10/7/2016 @ 2:30 PM

Citrix Secure Hub 10.4 for iOS has been removed from Apple App Store

Is this a joke?  Next communication on 10/10/2016!  Give me a break - this is ridiculous.

Update - 10/7/2016 - Citrix sent out the following notification.

Dear Valued Citrix XenMobile and Citrix Workspace Suite Customers,

This afternoon we released XenMobile 10.4 which included XenMobile Server, XenMobile apps and Secure Hub (formerly Worx Home). We've since received some customer reported issues that are detailed below.

Executive Summary:

Citrix Secure Hub 10.4 for iOS has been removed from Apple App Store due to some customers reporting issues when they upgrade from Secure Hub 10.3.10 to 10.4.

Please do not use MDX Toolkit 10.4 and XenMobile apps 10.4 for iOS if you have already downloaded these artifacts. MDX Toolkit 10.4 and XenMobile apps 10.4 for iOS have been removed from

Worx apps on end-user iOS devices will continue to work even if end users could not successfully update to Secure Hub 10.4. If Worx Home update to Secure Hub 10.4 was not successful, Worx Home will continue to function on the device without any requirement for re-enrollment.

There is no issue with Secure Hub 10.4 for Android.

Next customer communication will be sent out on Monday Oct. 10, 2016


Before Secure Hub 10.4, Worx Home 10.3.10 for iOS was updated to leverage the VPN Network Extension capability available in Apple’s iOS 10 which allows MDX-enabled apps to share data between each other.

The usage of VPN Network Extension in iOS 10 greatly improves the SSO (Single Sign-On) experience across all MDX apps and also reduces the number of flips back to Secure Hub. The VPN Network Extension is used by XenMobile Advanced Edition and XenMobile Enterprise Edition only on iOS 10 devices.

Secure Hub 10.4 was recently released to App Store on October, 6th, 2016.

Secure Hub 10.4 upgrade issues have been reported by some customers on iOS 10 devices who are using it with XenMobile Advanced Edition to XenMobile Enterprise Edition.


During the upgrade to Secure Hub 10.4, the following issues were observed:

Secure Hub upgrade failed on first attempt
User either got “Unable to download. Done/Retry” or the download remained in “Waiting” stage (user had to cancel the download)
Second attempt to upgrade succeeded

After upgrading to Secure Hub 10.4
User was prompted to “Allow VPN config”
After allowing, Secure Hub works as expected.

Diagnosis & Workaround

Though this problem was not observed during internal QA testing and extensive EAR testing (via TestFlight), Secure Hub 10.4 upgrade from the App Store fails during the first attempt because VPN Network Extension is still running on Worx Home 10.3.10.

This behavior is observed with upgrades from the App Store. Once the upgrade fails, iOS terminates the VPN extension in Worx Home 10.3.10 automatically. However, on the second upgrade attempt, Secure Hub 10.4 upgrade succeeds and the user has to enable the VPN Network extension by accepting the prompts.

The current workaround for users who have access to Secure Hub 10.4 is to de-activate the VPN by going to Settings -> VPN. If VPN is disabled prior to the upgrade, Secure Hub 10.4 upgrades successfully on first attempt. User will then need to enable the VPN Network extension by accepting the prompts as before. Removal of Secure Hub 10.4 for iOS from App Store Since the issue is applicable to all iOS 10 customers who are using XenMobile Advanced and Enterprise Editions, we have removed Secure Hub 10.4 from the App Store.

We have also removed MDX Toolkit 10.4 and XenMobile apps 10.4 from your customer download pages. Please do not use MDX Toolkit 10.4 and XenMobile apps 10.4 for iOS if you have already downloaded these artifacts.

Next Steps

Citrix is investigating on a fix to ensure upgrades can work smoothly even if VPN Network Extension is running. Once a fix is implemented and tested, a new version of Secure Hub 10.4 for iOS will be made available on the App Store. The next communication update will be on October 10th, 2016.

The XenMobile Team

Friday, September 16, 2016

A specified logon session does not exist. It may already have been terminated

I have a NetGear wireless router with a neat feature called ReadyShare.  NetGear ReadyShare let's me connect a USB drive to my router and create a network share.  It's been working great but I recently reloaded my Windows 10 desktop and started getting the following error.

"\\readyshare is not accessible.  You might not have permission to use this network resource.  Contact the administrator of this server to find out if you have access permissions.  A specified logon session does not exist.  It may already have been terminated."

I suspect a security settings was causing an error so I checked the Windows firewall and found my desktop's Wi-Fi connection had the public "profile" applied (Windows Key + S then search for "windows firewall")...

I prefer for this to be set to private for my home network so I went into settings (Windows Key + I), clicked Network & Internet, clicked Wi-Fi, clicked my Wi-Fi connection, and enabled "Make this PC discoverable".

My "ReadyShare" is now accessible after the profile change!