Cryptowall's ransomware's tough layers peeled Cryptowall's 2.0 incarnation is hidden in a tough shell crafted by developers paranoid about the security research community, technical analysis reveals. The ransomware has matured much since it emerged last year, encrypting victims' files and demanding money for the supply of a decryption key. It's superior design lead to …
In principle, if the share is not writable by the user who has it mounted, then it can't be modified. That's not to say that some clever bit of code might look for privilege elevation vulnerabilities to get around it.
Put another way, it's a good reason to not have "everyone can write anything" shares - limit write permissions to only those user/groups that need it (it can be done at a folder level, so you might only allow certain users to write to the marketing folder, while letting everyone read/access the brochures etc).
But that's just good security practice anyway.
"An honest question - does it matter whether the share on the other machine is writable or not?"
If you're unlucky enough to be running NT3.51/4.x on your file server you could see compressed files on read-only shares get corrupted by clients attempting to write to them (same happened even if the files were also marked read-only on the read-only shares). They *should* have fixed that one by now, but I wouldn't bet my data on it. ;)
And in case anyone is still curious but can't read the code for some reason, it:
- Looks for processes named "VBoxService.exe" and "vmtoolsd.exe", which are helpers that are generally run in Virtual Box and VMWare VMs, respectively.
- Looks to see if any process has "sbieDll.dll" loaded. That's part of Sandboxie.
So the "VM detection" is really just a trio of simple heuristics. There are more sophisticated ways of detecting execution inside a VM, such as looking at how the CPU handles invalid opcodes or other "perturbations" (Powerpoint; see slide 14).
Yes, obviously. Sandbox detection and encryption are examples of what's called "raising the work factor" in the security business. As is every security mechanism, regardless of the user's hat color.
The Cisco researchers didn't say it was impossible to reverse-engineer Cryptolocker. They said it was hard.
(Naive single-stepping can easily be defeated, incidentally, for example by checking timings. The investigator has to notice such checks and adapt to them by branching around them, changing the values they're comparing, and so on. There's a fair bit of research in this area. It is not simple.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
