Data carving a malw...
 
Notifications
Clear all

Data carving a malware file from vmdk unallocated space

4 Posts
2 Users
0 Likes
1,497 Views
(@btforensics)
Posts: 14
Active Member
Topic starter
 

Hi Forensic Focus,

I am currently investigating a vmdk image. This machine has been infected by a malware that deleted the MBR and partitions which makes the machine no longer bootable. I am currently trying to extract a deleted file from the unallocated space which I suspect to be the malware file (I'm pretty sure it is). I've used FTK imager to do string search and figured the path and file names matches the IOC of the malware. I've already tried using tools built in in SIFT workstation such as foremost and scalpel but these tools were unable extract file that I need.

I'm trying to extract an .exe file.

I've used a commercial tool Active@ File Recovery for Windows, this tool can see the file that I need, however, since it is a commercial version, I would need to pay for the license to recover the file. I can request my company to buy the software, but I would like to know if there are any other options that I can do?

I would also appreciate if you can provide me some best practice in doing data carving. Maybe the sequence of tools that I need to run first. Because it really takes a long time for me to scan the image for every tool that I use.

Thank you!
btforensics

 
Posted : 27/01/2017 5:48 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

NO. (in the sense that if you have a filename and path then it is NOT "unallocated space").

Anyway, get DMDE
https://dmde.com/

It will be able most likely to rebuild the filesystem and from that you will be able to extract the file, and then it would be one of the tools you should really get a professional license for.

For the record, there is nothing that you cannot do with tools in Linux distro's, the issue here may be that you need some more familiarity with them (and with the filesystem structures you found).
A file is nothing but an extent of physical sectors (possibly contiguous) so all you need to "extract" the file is dd, but your problem (or at least what you should IMHO do besides and before extracting the file) would be to rebuild the filesystem so that you have access to a number of other files and to their metadata).

jaclaz

 
Posted : 27/01/2017 10:46 pm
(@btforensics)
Posts: 14
Active Member
Topic starter
 

Hi Jaclaz,

Thank you for the DMDE tool, I am currently checking it.

I just want to clarify the unallocated space of the vmdk file. When we used FTK imager to mount the vmdk image, it only shows unallocated space (no other volumes). We were able to get the file name and path because we have found IOC for the malware through our sources.

We were able to verify the existence of the malware files by doing string search in FTK imager and also with the Active Disk File Recovery Tool.

A file is nothing but an extent of physical sectors (possibly contiguous) so all you need to "extract" the file is dd, but your problem (or at least what you should IMHO do besides and before extracting the file) would be to rebuild the filesystem so that you have access to a number of other files and to their metadata).

Thank you for this advise, I'll do a research about rebuilding file systems. I'll get back to this thread if I get stuck ) or maybe if you can point me to a website that I can read and get started, that will be nice ) )

We're just new with disk forensics, so we're still learning a lot of new stuff.

Thank you!

 
Posted : 28/01/2017 12:43 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

It is just a matter of "conventions" and "naming". )

Unallocated space usually means space that is not allocated (but within a given filesystem/volume).
The MBR "allocates" the area occupied by a volume.
To the volume a filesystem is (generally) applied,
The filesystem structures "allocate" the area that may be later occupied by files.
If you have a VMDK (which usually is a "whole disk image", comprising the MBR or GPT table and one or more volumes) the mere act of wiping the MBR's partition table does not erase the whole thing, chances are that the volume(s) can be found and thus the partition table be rebuilt.
Even if parts of the volume/filesystem structures have been deleted, other parts of the filesystem structures may be enough to rebuild the volume/filesystem.

Now, what has to be seen specifically is whether the wiping/deleting (besides the MBR partition table) has been vast enough to prevent rebuilding the filesystem of the volume(s).

DMDE (though of course it is not the only tool to do this) has a nice "volume searching" feature, i.e. a function to analyze the whole disk and recognize parts of a pre-existing filesystem.
If it finds such structures (even if partially damaged/missing) it can usually "virtually" rebuild the filesystem, allowing you to navigate it "normally" and extracting the file(s) including their filename and metadata (creation date, etc.).

This is very important because what you know now (if I get this right) is only that a sequence of sectors on disk/image are identical to a known file, but you have no idea when this sequence of sectors was written to disk.

With a reconstructed filesystem (if possible) you can put the file creation (and often also last access) onto a timeline and besides you can check a number of other files for consistency with the timeframe, possibly find other files of dubious nature, and maybe also exclude (or confirm) that the file was "planted" by some malware.

jaclaz

 
Posted : 29/01/2017 5:08 pm
Share: