About Imphash

If you’re not familiar, “imphash” stands for “import hash” of all imported libraries in a Windows Portable Executable (PE) file. You can get started playing with it quickly with its python implementation here:

Why calculate this?

Simple: malware authors are humans, and humans stick with what they know. They go to the same watering holes. So, when a malware author tweaks a few things to throw off a signature of their malicious EXE or DLL, odds are high that their imphash will remain identical. This makes imphash a good way of tracking the life cycle of malware families and their authors. Read more on this on FireEye’s blog:

How does this work in code?

Suppose you have the following snippet at the top of your C++ .cpp file of your malware:

What are the options for a malware developer?

One option is to tell yourself: “I’ve got a fever, and the only prescription is more cowbell, ahem … stages.” Then proceed to modularize your malware, loading each module into memory only when needed, and keep your base stages simple so their imphashes are not that unique. The cons to this approach are: it’s complicated, and while a good practice for malware development, a seasoned developer will admit that even their later stage modules will eventually get captured in PE form by a competent forensicator.

False Flag Imphashes

Suppose that, during your cyber espionage, you want to plant a false flag malware artifact on a targeted host, and you know that imphash calculation will be used by the defenders during forensics. And suppose you have a malware artifact with a very unique imphash that you’d like to emulate. Maybe you’re a red team doing adversary emulation, and this is a training objective. But maybe you’re a nation state trying to implicate another nation state. Or maybe a criminal group trying to “drop a dime” on somebody else.

Red Team Leader at Fortune 1. I left my clever profile in my other social network: https://www.linkedin.com/in/malcomvetter