On-Demand Webinar

Anatomy of an Attack: How the Bad Guys Use Certutil and MSBuild to Stay Below the Radar

For as long as security professionals have implemented advanced security controls, the bad (and good) guys always seem to find plenty of ways around them. To begin with they started using reflective memory attacks to load DLLs “by hand” thus bypassing system choke points where critical controls such as allowlisting could be enforced. That’s in addition to the usual buffer overflows and shellcodes.

But in this real training for free session I’m going to show you a very powerful method, found in the wild, to quietly download a large and functional malware (e.g. RAT, keylogger, ransomware) without depending on any unpatched vulnerability. The one big requirement is the ability to run the VBA macro in the Word document that kicks the whole thing off.

The challenge for bad guys attacking a well patched, hygienic environment with strict controls is to get a sizeable amount of code to dependably run. Let’s say you succeed in getting a VBA macro to run in a Word document you send to someone at the target organization. You can only do so much in VBA to begin with and only as long as the user keeps the document open. So, you want to quickly download a larger chuck of code and get it running in another process while it remains active. But in this security-conscious environment if you simply download evil.exe and run it, legacy application allowlisting (e.g. AppLocker) will block it because it’s not on the allowlist or signed by an authorized software vendor like Microsoft or Adobe (because we know Adobe’s code signing servers are secure, right?). Or if application allowlisting isn’t in use, a threat hunter is going to see this strange program hash showing up in the logs.

In this session I’ll show you how this evil Word document’s macro downloads an innocent looking PNG image from a legitimate website but which has some binary shell code hidden within encoded in base64. Then the macro uses a weird feature in certutil.exe (a built-in Windows program) to convert the base64 content to actual binary code and hide it in the user’s profile. The file is actually a C# project file which is then fed into MSBuild. But not to create an EXE or DLL which is what you normally use MSBuild for. That wouldn’t help us if we are attacking a well secured environment for which attack was developed. Instead it gets far more interesting. I’ll show you how a little-known feature in msbuild, called inline tasks, allows bad guys to run powerful C# code without ever loading a DLL or EXE.

You’ll also see many other techniques such as hiding malicious code inside a well-known process and how the attacker reduces their radar signature by running certutil and msbuild via a “proxy” process so that there’s no suspect process lineage as in “WTW? Why is MS Word running certutil and msbuild.”