From Malpedia to Metalcore: Daniel Plohmann Talks Malware Research and Music

Malware research is a mix of curiosity, patience, and a knack for digging into the messiest corners of the internet. For Daniel, that curiosity kicked in well before his first professional role. It started with early programming experiments and a fascination for how things work behind the scenes. That spark eventually grew into a career spent picking apart malicious code, building tools and resources for the security community, and going after the odd, rare, and downright strange in the malware world.

In this chat, Daniel talks about his approach to malware analysis, why collaboration matters, and how people can find their way into this field from all sorts of starting points.

After getting my diploma with a thesis on the simulation of wireless networks, I joined the department and was offered to focus on security-related topics, which brought me back to my early interest. My former colleagues Tillmann and Felix, who were veteran botnet fighters at that time already, definitely bootstrapped my start into malware analysis.

The kick of successfully reverse engineering the first malware samples definitely ignited a flame that hasn't vanished ever since, and set the course.

Funny enough, one of the first malware families I had a deep look at was one of the initial bitcoin mining botnets back in 2012, which was written in Delphi (a dialect of Pascal), so I got to look at the machine-level code of the first programming language I learned.

Your work combines academic diligence with hands-on threat intelligence. How has your academic background shaped your approach to practical malware research?

Daniel: I think the academic path helped me the most with developing a good sense for abstraction and structural analysis.

Given that security and threat intelligence are very fast-paced, we often tend to hop from putting out one fire to jumping to the next. The ability to retract one's attention every now and then, connecting dots, and identifying recurring themes/problems is certainly a benefit, especially when aiming for helpful analysis automations.

Oh, and well, having dug through countless pages of scientific papers and textbooks has probably helped to develop a certain immunity to exposing myself extensively to disassembled binary code and dry technical documentation, which is, however, really helpful when wanting to reverse engineer effectively.

What's one major shift you've seen in the threat research field since you started?

Daniel: I would say that starting out in IT security has become much easier nowadays compared to back when I entered the field. While there is so much more going on with the rapid growth of its relevance, learning the ropes has become so much easier, with plenty of books and affordable courses widely available.

Regarding the malware ecosystem itself, it was very interesting and scary to be a first-hand witness to the prevalence shift from financial fraud using banking trojans, which mostly targeted users, to the very destructive and impactful extortion attacks, mostly targeting organizations.

Share this insight:

Malpedia is open to curated contributions. How do you strike the right balance between openness and maintaining high data quality?

Daniel: To this day, all content being added is peer-reviewed by a few volunteers and me, which ensures that at least another pair of eyes confirms the accuracy of metadata and family associations. All binary content, i.e. malware samples, are still reviewed by me to ensure consistency. This is certainly significant effort and using some automation helps with the process, but I think it's ultimately worth it.

Especially when starting with binary analysis, there is a lot of potential for frustration, and one can feel lost easily. But once the initial hill is captured, there is also a lot of fun in it, as long as one remains curious and enjoys learning things.

Share this insight:

As part of your PhD thesis, you developed MCRIT, which builds on concepts like Position Independent Code (PIC) hashing and MinHashing. Could you break down why these two approaches were the backbone of your framework?

Daniel: The idea of PIC hashing is based on observations from Cohen and Havrilla, published in 2009. The goal is to derive a fingerprint on a function level that is quasi-exact and only accounts for memory relocations. Since we frequently encounter statically-linked code, especially from standard libraries such as the Microsoft Visual C runtime or GCC, these can be very well addressed with such a type of fingerprint.

Without fuzziness, matching also means we only look for identical fingerprints, which can be done very efficiently in databases. In their original research, they showed that using such fingerprints can reduce large quantities of functions down 40-fold to unique representations.

MinHashing, on the other hand, is a locality-sensitive hashing scheme that allows accounting for similarity to a certain degree, often used as an efficient storage and lookup technique in the search for similarity and clustering. For using it in the code similarity context, I have adopted well-known features from the academic literature for the function representation used in MCRIT. Both complement each other well when looking at it in a two-stage process.

A key differentiator of MCRIT is that it enables the derivation of occurrence frequencies for code indexed with it. Which use cases does this help with in a real-world investigation?

Daniel: Firstly, this allows to guide analyst attention towards code that is more likely intrinsic for the malware family under investigation, i.e., the parts of the code that bear its characteristics and capabilities. In consequence, we also built a feature in MCRIT that further builds on this insight and allows the automated generation of identification rules, targeting code specifically that is observed across multiple samples/versions of the malware family but not found anywhere else.

Secondly, when focusing beyond unique code, this also allows for highlighting rare code, and thus pointing a spotlight on code overlaps between a few, possibly related malware families, providing leads for authorship attribution. Thirdly, and inverting the first aspect, it also allows us to show which code is commonly found across the whole data set, meaning that MCRIT can outline areas of potential library code, simply by inference from its popularity.

You shared that MCRIT is built to work seamlessly with Malpedia. What advantages does this integration provide, especially in terms of actionable results?

Daniel: Yes, indeed, several features, and especially the frequency-based analysis, have been heavily inspired by first having an extensive, accurately labeled malware corpus available. For us, MCRIT helps with the curation of data, as it supports the rapid analysis and sorting into families. I expect that other users may be using MCRIT similarly with Malpedia as a baseline data set to aid their malware investigations.

The rule generation approaches outlined before, in turn, benefit Malpedia because they allow us to provide automatically generated high-fidelity rules for the malware families. It can be seen as a technical symbiosis.

Can you walk us through how Hunt.io fits into your workflow as a threat researcher?

Daniel: As I am mostly focusing on binary analysis in my daily work, the AttackCapture tool, which covers recordings of malware spotted in open directories, has great value for me. I was able to discover and extract several offensive tools regularly observed in the wild and other interesting malware samples from the data gathered by Hunt.io.

Are there particular types of hunting tasks where Hunt.io really shines?

Daniel: I also really like the C2 Infrastructure UI as it helps to get an idea of currently active adversarial infrastructure. This helps me stay informed about the popularity and frequency of use for malware and attack tools, which indirectly serves as an estimate for where to put a focus in my own work.

Have you discovered anything surprising or unexpected through Hunt.io: a hunch that turned into a major lead, perhaps?

Daniel: There was a post last year on the Hunt.io blog, which featured the discovery of a PlugX builder in an open directory. As one of my current pet projects is to dig through the history of PlugX, this came in very handy, as I was able to dig up multiple other builders based on the insights from this initial file.

The AttackCapture tool, which covers recordings of malware spotted in open directories, has great value for me. I was able to discover and extract several offensive tools regularly observed in the wild and other interesting malware samples from the data gathered by Hunt.io

Share this insight:

We know you play the guitar. What kind of music do you gravitate toward when you're decompressing from a long day of threat research?

Daniel: There's actually a wide spectrum of music that I would generally consider in that scenario. It vastly depends on the mood of the day. Lately, it would either be some (progressive) metalcore like ERRA, Invent Animate, and Currents, but anything electronic is also always welcome, some Drum and Bass, or possibly an energetic live set from Boiler Room or Cercle.

Have you ever worked on a project that merged your love for music and tech, even in a fun or experimental way?

Daniel: I have experimented a bit with synthesizers when dabbling with electronic music, as well as playing with programmatic generation of MIDI tracks. For my band, I've also done recording of demo tracks and some engineering. I'd definitely like to expand on these things!

What's next for you? Any upcoming research areas or side projects you're particularly excited about?

Daniel: One of my major research scopes is still set on code similarity. While there is a lot of great work done already on techniques that do the actual comparison between pieces of code, I think there is still significant room for improvement in using these technical results to provide an actual benefit when performing analysis, e.g., highlighting the most expressive and insightful code overlaps.

Apart from that, I've started playing with natural language processing and exploring additional ways in which the information gathered with Malpedia can be leveraged in further ways to aid us as a community.