Reverse Engineering Malware 101(securedorg.github.io)
securedorg.github.io
Reverse Engineering Malware 101
https://securedorg.github.io/RE101/
4 comments
Thanks for the pointer to dnSpy. I'd been using Lutz's .NET Reflector, but since Red Gate took it over, and despite even paying for the Pro license (I needed to be able to debug and step through assemblies that I didn't have the source for, and there was nothing similar at the time), it's become a total pain in the arse to use. This looks like it'll comfortably replace it.
+1 for dnSpy. It's not only a decompiler, but also a debugger. Additionally, it has the best IL editor I've ever used. A parser for the native parts of the PE file (headers and sections) is a great feature too.
What do you think of dotPeek by JetBrains?
https://www.jetbrains.com/decompiler/
https://www.jetbrains.com/decompiler/
+1 for dnSpy. It is the only .NET debugger/decompiler I use these days.
When does running malware in a virtual machine (VM) not make sense, is it commonly not possible, etc.?
VMs are extremely useful for malware RE, but there are a few potential concerns:
- VM breakouts are a security concern. While fairly uncommon this is a risk. Most of that risk exists in drivers and VM acceleration tools and can be mitigated.
- Some malware packers will detect virtual machines and refuse to run. You can bypass this by cracking the VM check of course - but that can sometimes be harder than dumping it on real hardware, depending on the protection and specifics of the situation.
These are much bigger concerns if you're working with 0 day high level stuff and not just typical skiddie malware you pulled off usenet or a fake crack in a youtube video. Most of that stuff is just iStealer or a shitty DDoS-focused RAT and whatever "FUD" RunPE packer was on sale for the cheapest price on HackForums or similar that day. Some people will play this up to be a bigger concern than it realistically is - but a VM will protect you from the malware in almost every case I've seen. Just remember to keep your VM software up to date and avoid using unnecessary pieces.
My paranoid setup is a dedicated machine with 2 VMs, one victim VM and one router VM, quite similar to their setup there. The difference is, my router VM goes over Tor and doesn't allow traffic from the second interface out in any other way. I also use libvirt with kvm with as few extensions and drivers as possible to prevent most VM-based attacks.
- VM breakouts are a security concern. While fairly uncommon this is a risk. Most of that risk exists in drivers and VM acceleration tools and can be mitigated.
- Some malware packers will detect virtual machines and refuse to run. You can bypass this by cracking the VM check of course - but that can sometimes be harder than dumping it on real hardware, depending on the protection and specifics of the situation.
These are much bigger concerns if you're working with 0 day high level stuff and not just typical skiddie malware you pulled off usenet or a fake crack in a youtube video. Most of that stuff is just iStealer or a shitty DDoS-focused RAT and whatever "FUD" RunPE packer was on sale for the cheapest price on HackForums or similar that day. Some people will play this up to be a bigger concern than it realistically is - but a VM will protect you from the malware in almost every case I've seen. Just remember to keep your VM software up to date and avoid using unnecessary pieces.
My paranoid setup is a dedicated machine with 2 VMs, one victim VM and one router VM, quite similar to their setup there. The difference is, my router VM goes over Tor and doesn't allow traffic from the second interface out in any other way. I also use libvirt with kvm with as few extensions and drivers as possible to prevent most VM-based attacks.
VM breakouts are not really a concern though. They're so rare and worth so much that nobody is going to burn them on you.
You're right - if they're zero day. If you don't update your VM and someone lugs some old ones around just to see you could still get bit. Like I said though, odds are actually very low and it's probably not as major of a concern as many people make it out to be.
Malware will often detect the presence of a VM and refuse to run, requiring you to identify and defeat the VM checks or more insidiously appear to run normally but modify the actions it takes. [0]
Generally these problems are solved by modifying the VM so it can no longer be detected. [1]
[0] http://malware.dontneedcoffee.com/2016/04/bedepantiVM.html
[1] http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478
Generally these problems are solved by modifying the VM so it can no longer be detected. [1]
[0] http://malware.dontneedcoffee.com/2016/04/bedepantiVM.html
[1] http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478
More VM setup discussion: https://byte-atlas.blogspot.com/2017/02/hardening-vbox-win7x...
In general, dropping a sample into a VM and executing it is an obvious - and dangerous - approach. Real-world malware has been known to detect VMs and refuse to run. Or attack the VM, escape, and infect the host.
Broadly, it's not a reliable approach and relies to a surprising extent on the cooperation of the malware package.
Broadly, it's not a reliable approach and relies to a surprising extent on the cooperation of the malware package.
How common are VM escapes anyway?
Not widespread, but they do exist.
https://www.zerodayinitiative.com/blog/2017/3/16/pwn2own-201...
https://www.zerodayinitiative.com/blog/2017/3/16/pwn2own-201...
Not widespread is a bit of an understatement. In the context of malware analysis I would be astonished if someone bothered to use a VM escape bug. They're valuable; you don't waste them by sticking them in a piece of malware to pwn some poor malware analyst's machine.
VM detection is much much easier, so there's not much point.
VM detection is much much easier, so there's not much point.
I was thinking the same thing. Who would waste an unpatched vm escape bug just to nab some poor souls laptop, which can be wasted and reformatted in an hour? Sounds like a colossal waste and I bit there's very, very few (if any) examples of it happening in the wild.
I have a feeling escaping from Windows into a Ubuntu host system would not be as effective (though I wouldn't doubt it impossible) as escaping into a Windows OS which is usually the bigger / main target for malware.
Yeah. Unless the analyst is your target environment, I wouldn't expect to see it a serious current VM escape.
I might expect to see someone including an antique attack against some old Sandboxie or something, but nothing more.
I might expect to see someone including an antique attack against some old Sandboxie or something, but nothing more.
Isn't VMware in Windows rather a special case? They've been working together for so many years, after all.
Any known breakouts from Windows guests in VirtualBox on Linux?
Any known breakouts from Windows guests in VirtualBox on Linux?
http://venom.crowdstrike.com/
There have been others. In short, no VM is completely safe.
There have been others. In short, no VM is completely safe.
Does the PE standard differ for x86 and ARM? Windows runs on ARM now right, but in ARM I believe the stack grows up (to higher memory addresses) and in x86, as most people know, it grows down. Does anyone know if PE accounts for this? Or is it just abstracted away in PE?
ARM supports the stack growing in either direction, but on Windows ARM it grows down.
PE/COFF does have some architectural differences though; for example, the relocation types differ across architectures.
PE/COFF does have some architectural differences though; for example, the relocation types differ across architectures.
The only fields in the PE header dealing directly with the stack are:
SizeOfStackReserve: 0x00100000
SizeOfStackCommit: 0x00001000
This looks really cool, can't wait to dig in. Is it legit to redistribute that victim VM Windows 7 image?
Don't screw around with other .NET decompilers, use dnSpy.
https://github.com/0xd4d/dnSpy
It's fully open source, integrates with deobfuscators and includes a binary-level debugger which doesn't require VS separately. Plus it lets you patch assemblies and export debugged data easily which is how I extract most .NET-based packers these days.