Recover missing .vmx .vmdk descriptor files – esxi 5.5 6.0 6.5

To recreate .vmx file, bios etc, the easiest way is to create a new VM with the same hardware settings as the original one (of course, if you remember it…). So just "New Virtual Machine –> Typical" and so on.

To recover a .vmdk descriptor file you should follow below steps:

  1. Identify the size of the flat file in bytes. Create a new blank virtual disk that is the same size as the original. This serves as a baseline example that is modified in later steps.
  2. vmdk_missing
    As on above screenshot, use the vmkfstools command to create a new virtual disk: vmkfstool -c size -a lsilogic -d thin name where:
  • -c size – This is the size of virtual disk
  • -a virtual_controller (BusLogic, LSILogic,Paravirtual, or IDE)
  • -d thin  – This creates the disk in thin-provisioned format (also zeroedthick , eagerzeroedthick options available)
  1. Rename the descriptor file (also referred to as a header file) of the newly-created disk to match the name of the original virtual disk.

rename_vm

  1. Modify (using vi) the contents of the renamed descriptor file to reference the flat file.
  • run vi name_of_vmdk. In my case vi recreated_vmdk.vmdk . You will see similar file with name of -flat.vmdk file:

vmdk_file_view

  • change the colored name to a new one. (on vi editor, please type "i" to edit file). In my case:

vmdk_recreated

  • save file by typing :wq!
  1. Now you can add a disk to VM:

Found a random USB drive?

Plugging in that USB stick you found lying around on the street outside your office could lead to a security breach.

This is no secret, of course. We have all (hopefully) been aware of the dangers of inserting an unknown USB device into our computers for some time. Heck, the technique has even made it into the Mr Robot TV series.

But what may not be widely known is just how successful the tactic can be for allowing hackers to compromise your computer systems.

Research presented this week at BlackHat by Elie Bursztein of Google’s anti-abuse research team shows that the danger is alarmingly real:

…we dropped nearly 300 USB sticks on the University of Illinois Urbana-Champaign campus and measured who plugged in the drives. And Oh boy how effective that was! Of the drives we dropped, 98% were picked up and for 45% of the drives, someone not only plugged in the drive but also clicked on files.

It seems folks just can’t resist picking up a USB stick that they see lying around – Bursztein says that it only took six minutes for the first device that he “lost” to be picked up.

Bursztein was curious as to whether there were ways of influencing the likelihood of someone plugging a found USB stick into their computer, so they left five different types scattered across the University of Illinois campus: drives labeled “exams” or “confidential”, drives with attached keys, drives with keys and a return address label, and generic unlabelled drives.

One would like to imagine that people are less likely to plug in a USB drive if it is clearly labelled with the owner’s contact details, and that appears to be borne out by the statistics.

On each type of drive, files consistent with the USB stick’s appearance were added. So, “private” files were added to USB sticks that were unlabelled or were attached to keys or a return label, “business” files to sticks marked confidential, etc.

However, in reality each of the files was actually an HTML file containing an embedded image hosted on the researcher’s server. In this way they were able to track when files were accessed.

Seemingly personal files on USB drive

Upon opening the HTML file, users were asked if they wished to participate in a survey asking why they plugged in the drive. Approximately 20% agreed (perhaps encouraged by the promise of a gift card for their assistance).

Just over two thirds of the people who responded to the survey said that they accessed the USB sticks with the intention of returning them to their rightful owner. 18% admitted that they were “curious”, and 14% gave other explanations.

Now from the security point of view it’s worth recognizing that a security breach could already have happened by this point.

The most basic – and simplest to conduct – attack would have seen malicious code placed in the HTML file that would have been automatically activated upon viewing, perhaps downloading further malware from the internet. Alternatively, users could have been taken to a phishing site, and tricked into handing over login credentials through social engineering.

In addition, there is also always the danger that an attacker might have planted executable malware directly onto the USB stick, and hoped that an unsuspecting user would allow it to run on their computer.

A more sophisticated attack, however, would see the use of a device using HID (Human Interface Device) spoofing to trick a computer into believing that it was in reality a keyboard. As soon as the “USB stick” is plugged in it would inject keystrokes – building a set of commands that could open a reverse shell that could give a hacker remote access to the victim’s computer.

In a blog post, Bursztein explains in depth how he was able to camouflage a keyboard-spoofing device so that it looked near-identical to a genuine USB stick.

Keyboard-spoofing is not the most sophisticated type of attack possible through a malicious USB stick however.

Perhaps the most complex and stealthy attack would see the plugged-in device exploiting a zero-day vulnerability in the computer’s USB driver – similar to the method used in the notorious Stuxnet attack against the Natanz uranium enrichment facility in Iran.

Your chances of having a USB zero-day vulnerability used against your organization is remote, unless you are of particular interest to an intelligence agency or state-sponsored hackers.

Keyboard-spoofing HID attacks and especially basic social engineering attacks tricking users into opening files on a newly-found USB stick, however, are much more likely, which means it is essential that you educate your workers about the risks and urge them to hand lost property in rather than attempting to identify a device’s owner themselves.

In short:

USB devices should be treated with caution. Never plug in an unattended, unidentified USB stick.
Keep your security defenses, policies and patches up to date.