loaders.re

This project is coming soon. For now, here is what we have planned:

Loader families commonly go unlabeled within malware analysis reporting, unless they are popular or infamous. Even if reporting for a loader exists, it can be very difficult to find due to the interchangable nature of loaders.

This makes loader tracking quite difficult, and thus—we have decided to create a taxonomy system to facilitate easier tracking and lookup of loaders.

Reinventing the wheel?

Have you ever heard of HijackLoader? IDATLoader? Maybe you have, but did you know that it is also named GHOSTPULSE? What about ASMCrypt or DoubleFinger? SHADOWLADDER? Turns out, based on open-source reporting, these are all apparently different names for essentially the same thing.

Within industry reporting, it is very common for multiple names to be utilized for the same malware family, and we understand that we are the 15th competing standard to fix them all—however, we are hoping to aggregate loader characteristics in a way that simplifies the hunting of loaders.

With this in mind, we are creating a new taxonomical system to label loaders, inspired by the naming schemes that companies typically adopt for adversaries.

For example, within some companies, Spider is utilized for financially motivated groups and Sleet is utilized for groups out of North Korea.

How does it work?

There’s a fundamental problem with naming loaders. Most infection chains utilize several disjoint stages, and even “one loader” might consist of several components written in different languages by different developers. Sometimes, further stages are added or removed from loaders as well, making it difficult to definitively state which loader is used when.

That is a problem that is beyond the scope of this project. Our goal is simply to connect words with individual stages and hopefully connect the stages to their characteristics such as searchable strings, API calls, and a general understanding of its logic.

We are also hoping for some help from the community in order to add new entries and to help build a comprehensive list of loaders. We also hope that the community can help identify the loaders described within the compendium.

We understand that there are likely hundreds of thousands of loaders out there, and creating a lookup for every single loader is infeasible, but we hope to make even just a few analysts’ jobs easier. We also understand that this will take time, and we don’t (and won’t ever) promise that this will be ‘complete’ in any way, shape, or form. This is (in its current stage) simply a passion project in which we try to contribute information for loaders we analyze in our free time.

With that in mind, the general idea is as follows:

• The programming language(s) utilized by an individual stage is represented by a mineral/gemstone.
• A random flower name is utilized to identify the logic of a given loader stage.

Here is an example loader chain:

1. QuartzDahlia (Launch4j)
2. AmberAmethystDaisy (JPHP portion of D3F@ck Loader)
3. QuartzBegonia (Unknown C++ Loader)
4. DiamondDaffodil (Shellcode stage within QuartzBegonia)
5. LummaStealer

Here is the current list of programming languages corresponding to mineral/gemstones. This is not comprehensive, and in fact, we don’t know if loaders even exist for all of these languages. As more languages end up being used within loaders, the list will get an update.