Taking apart a double zero-day sample discovered in joint hunt with ESET (opens in new tab)

There are two parts here: an exploit for Adobe Reader, and a local privilege escalation for Windows.

The Adobe one is a standard memory safety bug. This is the kind of thing you can find with fuzzers pretty easily, or by examining file formats for potential overflows. The exploitation techniques here are using ROP chains to get execution to shellcode from a JavaScript heap-sprayed shellcode. Both are widely used techniques, and there are tools to assist exploit writers in finding and using ROP gadgets.

I don't know Windows as well, so I can't speak to the second exploit.

There is an offensive security conference called Infiltrate that has videos floating around that you can find online. Finding 0days in constantly attacked stuff like Windows is getting harder, but the tools these guys are building are getting more complex / interesting. I'd say the bar is higher, but it's still not hard to do and some lesser known platforms like QNX are straight easy if you have some time.

Much like, say, JavaScript development the tooling and instruction is of a much higher quality and much more diffuse. If you're smart and you put in a couple of years you can do it too, and some of these vulns fetch millions, though they're frequently blown on pwn2own contests or otherwise responsibly disclosed. I suspect that that is going to change over the next couple years as every major government amps their cyberwarfare / int budgets.

I don't understand how VirusTotal was able to catch this. I suspect the malware author uploaded it because they wanted to ensure it appeared clean to all malware detectors - VirusTotal is a great way to test that!

It seems VirusTotal is a tool for running 70 anti-virus products at once against the same file. How can VirusTotal catch freshly developed malwares? How would VirusTotal even suspect that an uploaded file was fresh malware? That doesn't make sense to me.