This is a serious question. I really enjoy deep-diving on the internals of malware, but I also do malware reversing as a hobby. I do not have time to do this as part of my actual blue-team job. Rare is the situation where the internal mechanisms of the malware matter enough to me, someone not building an EDR, to act upon.
So my question is, for whom are the endless IDA Pro screenshots, when the article ends on IoCs consisting of…hashes and filenames? I am certain there are serious malware analysts at big shops like Talos and Unit42 that appreciate these dives. But is that it? Is it theater? Is there utility I’m missing? I’m just bewildered.
I analyze malware (for fun and profitz) and I do find generally these technical deep dives very helpful!
The IDA screenshots and the IOCs allow me to follow the train of thought that the authors had, and independently verify their findings in my own research. I think of it like the authors adding their sources; I would assume that the samples in the IOC table are what they had analyzed to lead to the conclusions that they drew in the article. This is usually the case, but in the event that it’s not then that raises some flags about the integrity of the author.
[Aside: I do understand there may be cases that the sourcing is sensitive; in which case I strongly believe that the analyst is responsible for at least finding the closest non-sensitive source to add so that the present research matches the IOCs.]
The particular article that you shared has some really great annotations in the IDA screenshots and labelled the structures really well, and if I were researching this malware too, it would significantly speed up my analysis than starting from nothing.
That said, some articles (not the one you have shared) overdo the screenshots and don’t really add a lot of value besides add clutter and make the article unreadable. So some of this style of articles are more helpful than others too. Personally I have a mental list of threat intel shops and authors that are better at presenting this kind of research than others too.
So yeah, I do think these articles are for you! Someone involved in malware analysis for its own sake.
What I’m getting at is the analysis-out-of-necessity for the defenders who need to understand what to do about malware. Maybe it’s just an audience mismatch, but I just wish that the kinds of indicators this kind of article provides would at least take advantage of the depth to which they explore the sample. In this case (and many like it), all the indicators could be obtained without opening a disassembler.
This is a very fair concern and it does touch on a central tension I have with writing reports which is - do people (other than other malware analysts) actually find this research useful?
What kind of information would you find useful from these malware deep-dives?
I think part of the difficulty is that I (and a lot of other malware analysts) haven’t really had the experience of being anything other than that and it’s really easy to be locked in that way of thinking
So the trick for me is actionability. I want the analysis, if possible, to produce more than just atomic indicators. This is where MITRE can really come in handy. Take what you know about the sample, review MITRE, and call out what behaviors apply. I’m even hoping that we can normalize things like Sigma when appropriate to make the pivot from intel to detection seamless.
I enjoyed it, but I like to reverse engineer OS internals and malware for fun. I don’t think I ever had seen a EDR killer overwrite pointers to code integrity functions in the kernel since that should trigger kernel patch protection and cause a bugcheck (perhaps it doesn’t since the overwrite target is existing kernel code).
I don’t know if it answers your question, but I found it useful and enjoyed it since I used to work closely with antimalware internals.
I also found this article useful as a malware RE; the number one use this kind of article has for me is if I’m triaging something and I have no idea what it is (and especially if I’m being asked for a full writeup of all malware capabilities yesterday…) Somebody else writing their detailed writeup and functions and features they observed can save a lot of time.
The other way that these are useful is for hunting / pivoting. If someone has a detailed analysis of specific features in a specific malware that they observed, and, crucially, other activity that they observed along with that malware, I can match samples or activity that I’m seeing against what they’re seeing, verify that the malware is the same as what I have (and not, say, some other generic EDR killer), and start getting an idea about TTPs commonly used in activity involving this malware.
That said, I do find that there is often a disconnect between what malware analysts produce and what first-line defenders actually need. I especially find that there’s not a lot of overlap between malware analysts and detection engineers. To bring up systemic issues again: the answer to “how do you detect EDR killers” is…kind of always the same for every EDR killer. They always rely on dropping, then loading, a vulnerable driver/badly designed driver, regardless of what other kind of fancy loading happens before that point and what other kind of fancy unhooking or killing happens after that point. So for malware analysts, really what we should be providing is “what driver is this”, “where does it get dropped to”, “what is the path of the handle to the driver”, and “does the loader do anything else that’s easily detectable by EDR” (once the driver is loaded there’s not much the EDR can do…)
Generally, I assume the behavioral and technical indicators are for responders and such, and the IDA screenshots are for other reversers. At least, that’s how I’ve always taken it. Back when I was getting started, seeing those screens and in-depth writeups helped me learn my trade. Heck, sometimes they still help, quite a lot.
“What am I looking at? Wait, I remember seeing something similar in a writeup on another sample by some researcher who actually writes things. Let me go back and look at that…”