Malware ROI and the Return of Malicious Macros: It’s Not Personal, It’s Business

We have written frequently on Threat Insight about the return of malicious macros as an exploit technique in email-borne threats, and while the campaigns have evolved the question has lingered: How and why did this ‘outdated’ technique so quickly become a key part of massive malware campaigns? It’s a truism to say that cybercriminals are a business, but how does that affect their choice of technology?

Attack techniques come and go as technology and user behaviors change and defenses adapt to new threats – and sometimes take their eye off old ones – and the return of malicious macros offers an opportunity to examine and understand the drivers behind these adaptations, an exercise that is equal parts business case and technical analysis. By combining technical analysis of malware samples with investigation on cybercriminal forums, this report exposes the economic and technical drivers behind the recent rise of malicious macros and enables cybersecurity practitioners to better defend their organizations against this and future advanced threats.

Proofpoint research into threats and underground forums finds that, from a cost perspective, malicious macros deliver the most ‘bang for the buck’ because they combine lower up-front and maintenance costs with higher effectiveness to create a ‘killer app’ for cybercriminals.

Technical analysis and threat intelligence allow us to identify the cause behind the explosive return of malicious macros as an exploit technique featuring daily in massive campaigns:

  • Highly successful at evading not only traditional signature- and reputation-based defenses, but also newer behavioral sandboxes
  • Able to be frequently updated easily and at low cost
  • Cross-platform and “unpatchable,” because it is not limited by vulnerabilities on a specific operating system or application version
  • Reliance on end-user interaction leverages social engineering to bypass automated defenses
  • Low up-front and maintenance costs increase return on investment (ROI)

Combined in a single solution, it is no surprise that malicious macro attachment campaigns have grown so rapidly in both size and frequency, and we can expect that they will only begin to subside when this equation changes and either their cost increases or effectiveness decreases to the point that they can no longer deliver the same ROI.

Our new report, “The Cybercrime Economics of Malicious Macros,” examines the technical and business characteristics of malicious macros to provide insights into the behavior of threat actors and other members of the cybercriminal underground through a case study in the way of technical innovation and business value can combine to create a landscaping-changing malware trend. Click here to download the report.

Generic DLL Proxy


On a technical level, the CIA has some fascinating abilities. And I’m not just talking about the zero-day weaknesses in about every possible device, but also the trojan capabilities. On several documents, the CIA mentions “Antivirus defeat” – which are a bunch of ways they can bypass personal security software while executing on the victim’s machine. Some of this includes placing the executable in the recycle bin (Comodo defeat) and mutating the executable’s resources so that it passes heuristic check (Avira defeatF-Secure defeatBitDefender defeat).

In researching deeper, it has become clear that there are ways to improve on the DLL hijacking methods employed by the CIA in a manner that is more generic and adaptable to different scenarios.

Current State of the Art

It is interesting to examine how CIA trojans startup at boot. I found several documents referring to this, using Group policy startup, services and other methods. But one method seemed to stand out from the rest – using DLL hijacking. The CIA seems to be keen on this method, as they have a list of popular software where they found DLL hijack methods (Fine dining). It may be safe to say they use this method to disguise some data theft operation as a normal operation – this makes sense since the CIA uses operatives.

Consider the following: An operative is in the field, collecting data for an upcoming operation. For instance, the first requirement is finding out what type of phones, wifi routers, or other connectable devices are available at a target organization or with a target person. To complete this, code is written for that scanning operation, and then the operative needs to execute it while undercover. It makes sense that the operative would need some cover on his machine.

For example, they load all of the code into an innocent process, such as a VLC player. Then when VLC starts (by the operative), the code executes, and it hijacks a DLL used by VLC. This method also makes sense for target machines. VLC might already be configured as trusted by the protection software, and since there were no modifications to any file in it, it will still be trusted. A good example is the “Rain maker” module:

“RainMaker v1.0 is a survey and file collection tool built for a FINO QRC operation. IOC/FINO is looking to expand asset-assisted operations. The intended CONOPS involves using an asset to gain access to a target network. The asset has the ability to plug in a personal thumbdrive to the network. In this scenario, the asset will have “downloaded” the portable version of VLC player (2.1.5)  and will listen to music during work hours. While she is listening to music, the tool will execute the survey and a prioritized file collection. All collected data will be stored to the root of the removable media it is executing from. When the asset next meets with the case officer, the thumbdrive is retrieved and the collection is processed.”

From the WikiLeaks documents, it looks like the CIA uses this method a lot. Also, since the functionality of the hijacked DLL is still needed, they would need to proxy all functions exported by the DLL. This is apparent from the way they describe some of the DLL hijacks they found.  For instance in the Opera hijack, they state the DLL is ideal for hijacking, since it only exports one function. This means they would only need to proxy one method.

And so finally I reach my point – DLL proxying can be made easier, if only you could a write a DLL that is generic in what it proxies. If one could write a DLL that proxies any other DLL, it could simply be dropped anywhere (with a specific name, of course), and be loaded. And this is where i think the CIA did not investigate enough – since this can easily be achieved.

A better way – The Generic DLL

The main idea is this: When a process loads a DLL, it will use the LoadLibrary API. This API returns the base address where the DLL was loaded. So when proxying, the process receives the base address of the proxying DLL, and that is why all of the functions from the original DLL need to be exported:

Dll hijacking techniques used by CIA 1.png

In order to build a generic proxy DLL, one must make sure the base address of the original dll is returned to the loading process. That way, there is no need to proxy anything, and stop being the middleman:

Dll hijacking techniques used by CIA 2.png

How can this magic happen? It’s actually pretty easy. All that is needed is to walk the stack and find the function call to LoadLibrary, specifically – the return address from it. Then write a different address there that points to this small piece of code that sets the return value and then jumps into ADDR. That’s it. The calling process will receive whatever is set in the return value as the base address.

The code used to swap the return value is really simple, and looks like this:



Doing it this way gives a few advantages:

  1. Simplicity – Don’t care about the amount of exported functions
  2. Robustness – No need to create a different version per-dll hijack method
  3. Stickiness – Can easily look for DLL hijacking methods, since no versioning is required

To summarize, the CIA does its best to give its operatives a good cover. Still, executing malicious code requires a cover, and DLL hijacking provides a good way to both keep the integrity of the executing software and to execute the malicious code within it. This approach should also work for trojans, which can be dropped on “innocent” machines, and loaded into target processes. Using this method might require proxying the exports of the proxied dll – which can be solved by creating a generic “invisible” DLL.