We are going to install a sandbox solution that requires Ubuntu Server as the underlying OS (the product is not shipped as a ready to install appliance). For performance reasons the malware samples are stored on file system and not in the DB. The OS will be running on the ESX VM.
My question - is there any potential risk of backing up such a OS that will contain malware samples? I'm thinking of .vmdk level backup that allows granular restores as well.
The medium malware is stored on is irrelevant. Malware is just data, and data can only cause harm if something interprets it. This can mean anything from directly executing a malicious file to opening a malicious image in a vulnerable image viewer. Assuming the malware comes in the form of malicious executables or libraries, when it is stored on a filesystem or a .vmdk container, it cannot do any harm. The only way it could do harm is if it were somehow executed, such as by being extracted from the container and run on the host or run on a virtual machine which was vulnerable to a VM escape exploit. If it's saved where it's not going to be executed, it is completely harmless.
I used to work with malware samples and what we used to have was a repository that every body on the team could mount on his laptop. Thats fine but you could mount the malware files incorrectly and give them execution permissions that is not a good idea. What was very helpful for us was to change the first two bytes of the malware files. Notice that in windows correspond to MZ and in Linux to other bytes that can not remember now. The key of this is that if the malware sample gets clicked it wont be executed because the ELF header was modify the first two bytes. Depends on what you are doing with the samples this could be a valid option for you or not. Hope it helps
