What are the best solutions for sandboxing and debugging?

Malware analysis involves sandboxing, debugging, and analysis tools. I'm hoping you guys can help me figure out the finer details in setting up my malware analysis rig.

I think I want to do nested VMs (like Qemu running within Virtualbox running within VMware, or something like that) for added security against VM breakout 0 days, but I want to know what you think. I have 32GB of RAM so I can afford to be inefficient.

I won't give the VMs network access just in case they have some self-propagating Cryptolocker-esque shit that tries to infect my network drives. Or maybe I should just set up a separate VLAN and make ACL rules so that my test rig can't interact with any other private addresses, meaning it can't touch my other local stuff. Then I could still monitor shit in Wireshark even if I can't into proper debugging forensics.

As far as debuggers go, I've heard that Ollydbg is good, but I have no experience with such things so I'm not sure if that's true or not.
Also how can I make a VM not appear to be a VM? And how can I get around some malware's anti-debugging features?

Also, aside from Wireshark and Process Explorer, what are some other good tools for analyzing what's happening within an OS? Windows or GNU/Linux, doesn't matter, since I'll be doing tests for malware and exploits for all kinds of systems.

Thanks in advance, cuties.

Please, be my boyfriend!

Second physical machine and KVM switch. Get an in-circuit-emulator, not cheap (although you can find used ones occasionally) but nothing is able to detect one because it works at the hardware level.

if my uneducated self were to get into this, this is what I would do.

Get a dedicated machine.
Take out wifi and blue tooth if they are in.
Disconnect speaker and microphone.
Figure out how to reflash the bios and harddrive firmware.
Information can travel to the test machine, but nothing can get out. Use read only media, like CDs, DVDs, sdcards with write enable physical switched off, to transfer data.
To document work on the test machine, use a webcam to film the screen and use effects to eliminate flicker.

Or use a video card with a RCA output and record sessions onto VHS.

>>5
At least use s-video so you might have a chance of reading it.

>>3
viruses can hack usb controllers http://www.wired.com/2014/07/usb-security/

>>6
That would actually work well. Now I want to try this.

>>7

Any time a USB stick is plugged into a computer, its firmware could be reprogrammed by malware on that PC, with no easy way for the USB device’s owner to detect it.

If that's true, I really want to try it.

>>7
And your point is? It's a separate machine, which is supposed to get hacked. Of course you would never plug in any USB devices you don't want to get hacked.

>>10
Such as a KVM switch?

>>11
lol wut? A KVM switch is not a USB device.

>>10
If you use a dedicated PC as opposed to virtualization you run the risk of getting hard drive or even BIOS level rootkits which will persist even after reformats. Hell, there has even been a GPU rootkit proof-of-concept recently. No antivirus programs scan VRAM or check graphics card firmware. It's actually a pretty genius concept if you think about it.
But yeah, I don't want to infect my actual hardware. I'd rather just run a virtual machine and reload the snapshot whenever I want to start off fresh. Reflashing a BIOS constantly isn't someone I'd want to do. And I have no idea how I'd go about resetting hard drive firmware.

>>12
I suppose you must still use PS/2 devices then.

>>13
The motherboard on that machine has a BIOS write-protect jumper. No software can override that. The HDD is old enough that it doesn't have any firmware update feature, and ditto for the "GPU".

>>14
Obviously. PS/2 is superior. Does what it needs to and nothing more. No overly complex driver stack with tons of attack area, just 4 I/O ports to a mask-ROM MCU.

>>13
But if it knows an exploit for the virtual machine it can break out of a ring and then proceed to attack the physical machine.

>>15

The motherboard on that machine has a BIOS write-protect jumper.

Why didn't I think of that!

When I use an input device, I don't want eight extra KILOBYTES of worthless
protocol and vulnerable stack code! I just want a PS/2itor!!
Not a "USBitor". Not a "BlueToothitor". Those aren't even WORDS!!!! PS/2!
PS/2! PS/2 IS THE STANDARD!!!

Are VM breakout exploits really that common?
My logic behind using nested VMs is that if there's a VM vulnerability that malware makes use of, it would probably only affect one vendor, not all VM software. So, for example, if there's a Virtualbox bug, the malware could break out of Virtualbox. But if I run a Virtualbox VM INSIDE of a VMware VM, wouldn't that make it safer?
Keep in mind I'd be using "snapshots" which are VMs that you reload every now and then from a static file rather than letting persistent changes happen.

>>17
Malware doesn't have to be less than 512 and fit in a single floppy sector anymore. Flame(Stuxnet 2.0)was 20MB and had Lua scripting. I'm sure that the virus or worm or whatever can have all the known exploits for every version of VirtualBox, VMWare, Qemu, Bochs, vzlinux, XEN, kEmu, OpenVZ, and all the other vitualization software that I don't know about.

>>18

known exploits

old and patched CVEs don't matter because I keep my software up to date
unless there are tons of 0 days for sale on the deep web I don't think it should be a huge issue
the only really high-profile hypervisor vulnerability recently was venom, and it got a ton of publicity

>>19
Just don't run nation-state level malware.

>>20
On VX sites, how can I tell which malware samples are nation-state vs. Russian neckbeard tier?

>>18
seems hella risky

* package all your 0days as Lua scripts;
* or have a central repo where anon ips can download 0days;
* or is it a 0day as a service?

>>21,22
Forget it, it's NP-complete.

>>22

* or is it a 0day as a service?

People sell exploit kits on various deep web sites. I'm not sure if they're zero days per se, but there are plenty of CVE-based ones, since there's always a big lag time for patching where a vulnerability is still useful despite the software publisher providing a patch.
You don't need to reinvent the wheel to steal Joe Public's credit card information when he chooses to install Flash but never update it and ignore SSL warning messages.

That being said, I just want to clarify (for the NSA or whoever might misinterpret it negatively) that I'm not in that kind of business. I merely research this stuff and want to learn more about malware.

I think it'd look good on a resume to list that I'm a malware researcher. Am I wrong?

>>25
For someone educated in it, yes it would look very good. People who don't know much about it will assume you are a dangerous criminal. Unfortunately there's no low-tech analogy for what security researchers do. No one tries to break into stores and then document how they did it to the store manager. As far as the average person is concerned, anyone trying to break security is a criminal.

>>26
That analogy doesn't quite work. It's more like I set up different kinds of locks and windows in my own house and then attempt to break in. It's no one else's place, so they can't get mad at me. At least for the pen testing part. And the malware stuff is like analyzing a crime scene or scam artist.

Okay, I think I have come up with an idea for what I want to do.
I will run Linux on a cheap(ish) computer (that will need a decent amount of RAM) that is dedicated solely to malware analysis. I will install Ganoo plus Linux as the primary OS and then run VMware running a Windows VM. Within the Windows VM, I will run Virtualbox, and run another Windows VM. The Linux machine will periodically reload the nested VM snapshots.
I won't use any network connection at all, unless you count VMs interacting with each other on the single host. I've actually done more research and come to the realization that many pieces of malware stay dormant until they've verified a connection to their C&C server, and there are ways to spoof it. You can add an entry to your hosts file to redirect malwarecontrolldomain.com to a private address (like 192.168.1.10) which is a fake server you've set up in another VM within the first VM. Sometimes they will attempt to send login credentials to an FTP server so they can upload log files containing information about the infected host machine.
The Linux host box will be running a Windows virtual machine, probably VMware, but I can always change the specific vendors later. The important thing is that they'd be different so VM escape exploits have limited scope. Within the Windows VM, which will have networking and shared folders disabled for no interaction with the host VM, it will have the nested Windows VM for actually running the malware and analysis tools, and a nested Linux VM which will be used for the dummy server. These 2nd layer VMs will have networking enabled for inter-VM communication only.
Instead of using an internet connection or whatever, I can always add more stuff to the airgapped malware computer using DVD-Rs or CD-Rs. Optical media like that is read-only, so that should be safe. And they're cheap enough that I can just throw them out afterwards. It could be risky to add files via a flash drive, because there is malware which can rewrite USB device firmware in ways that are transparent to most users.
I will reload the VM snapshots after every analysis session and I can also reflash the BIOS every now and then using some bios.bin file on a CD. If there is ever any malware that has a combination of VM escape and BIOS rootkit features, I can avoid it that way.
If I need any sort of information off of the airgapped malware analysis PC, I can use a video capture device, similar to the ones people use for recording video game console footage.
Does this sound better?
The only weakness I see in this setup is that some malware might detect that it's being run in a VM and then kill itself. But even without VMs, anti-debugging and anti-analysis features still exist, so I don't really think there would be that much use in running it on the native OS.

>>28
Sounds good. Also don't forget about big sdcards. They have little switches on the side that if you flip the right way make write access physically impossible.

>>29
Is that really a physical thing or just a driver/firmware thing that checks to see if the switch is set?

>>30
Pretty sure it's physical. Looking it up now...

>>31
I was wrong. How sad. It just ``designates it for read-only access''. I really thought it physically disconnected a write-enable pin.
https://en.wikipedia.org/wiki/SDCard#Card_security

For one way communication to the test machine you could write an audio modem and play data from a trusted machine to the microphone slot of the test machine.

Or use a phone modem and cut the wire that goes back. That would be more sane.

where the fuck are you finding malware that requires this absurd level of protection to just disassemble it?

>>34
Can't some networking hardware adapt and transmit on supposed listening wires and vice versa? I know for a fact that Cisco hardware uses something called auto-MDIX, but maybe phone modems are simpler. Back from the age when people had to use crossover cables that physically crossed cables over when connecting similar devices so that they wouldn't both transmit on the same wires and listen on the same wires.
But even if the old hardware can't compensate for that, it's possible that advanced enough malware could. After all, there are even ways of siphoning data from power alone. I might need a battery backup instead of using mains power when doing malware analysis.
But then again, this is getting into tinfoil hat territory. But fuck powerline ethernet though.

>>34
Or simply use unidirectional RS232.

>>37
Is it provably unidirectional?

>>35
It's not that I'm anticipating that malware will break out of a VM and infect the BIOS and load malware before even reaching the bootloader, but this stuff is possible. I'd rather be safe than sorry.

Nested non-kernel-based virtual machines are slow as fuck. Choppy even in CLI stuff. I guess I'll have to redo it as a KVM this time (not to be confused with keyboard, video, and mice switches). Oh well. And I tried out virt-manager as opposed to Virtualbox and it seems fine.
Aside from performance, does anyone here know the difference between a normal and kernel-based virtual machine? Is it any less sandboxed?

>>38
Well, you can make your own cable; or if you're really paranoid, wire up a repeater box yourself.

>>39
It's easy - write your own virtual machine, one that nobody knows about so that nobody could possibly find loopholes though it. Now that I think about it, you could even use a computer that isn't x86 as this way, it'd be impossible for malware that is compiled for x86 to run.

>>42

it'd be impossible for malware that is compiled for x86 to run.

but the whole point is to run it
static analysis is harder than just running it and seeing what it does

>>43
I believe what >>42-dono meant is to write an x86 emulating VM.

A good viral analysis system would track changes to the snapshot, after the virus has finished execution. Similarly how you search memory for variables, during cracking.

>>43
Whom are you quoting?

>>46
lol, the mad nigger is back