Amy Ciminnisi 0:00

Welcome to the Talos Takes Podcast, where we discuss Talos' latest research and security news. This podcast is for everyone, from the C suite to the front lines. Hello and welcome to another episode. I'm Amy Ciminnisi, and today we are tackling the component object model, or COM. And fair warning up front here: this episode and the blog that it's based on are both quite technical. I totally went over my head the first time that I read it. So I encourage you to go read it or listen to this episode, spend some time with it, process it, and uh you've been warned. Anyway, it's not new to any of us that security is a game of constant trade-offs, right? We're balancing the need for speed against the need for deep, accurate analysis, and the volume of alerts just keeps climbing. When you're staring at a binary that just won't give up its secrets, you often hit a wall made of opaque GUIDs and indirect V-table calls. That's where calm comes in. It is essential for legitimate software to function in Windows, but it's also a playground for threat actors who are looking to move laterally, maintain their persistence, or simply evade our detection tools. Joining me today is Vanya Schweitzer, who released a blog last week that's an introduction to reversing malware that uses COM in Windows. We're going to break down why COM is such a powerful tool for adversaries, how you can start spotting the actual malicious signals within all the noise, and how to make your next reverse engineering session a little bit less of a headache. Vanya, hello. Welcome to the show.

Vanja Svajcer 1:49

Hi, Amy. Great to talk to you.

Amy Ciminnisi 1:51

Yeah, so glad to have you. Can you give us a brief intro to COM?

Vanja Svajcer 1:56

Well, um, like you said, COM is a really quite an old technology. It's one of those Windows Core things that built in from the early 90s, actually. And we used to know it as OLI or object linking and embedding or ActiveX. And then it evolved over time. And now it's known as COM or DCOM for distributed component object model. And even some of the latest versions of Windows, Windows 10 and 11 have technologies such as Windows Runtime, which are actually built on Windows CO. So it's really present everywhere. And the intention of Microsoft was at the time to allow for components written in different languages to communicate with each other. But it turned out that most of the time the uh software programmers and developers are using it is to try to reuse some of the functionality which was already built inside Windows.

Amy Ciminnisi 2:55

Got it. So it's a lolbin or living off the land binary. Um, can you spell out why it's so popular with attackers?

Vanja Svajcer 3:04

First of all, I I think we have to make a distinction between the COM as used in the compiled binary file versus the COM that's used as a component in script languages. I mean, it's almost equally used, but with script languages looking from the malware analysis or threat researchers perspective, it's so much easier to read because it's just like a scripting code. You can just see when some uh COM uh component was instantiated and how it's easy to use in the scripting languages. So here in the blog post, I was trying to focus on the binary standard. And so you you only see it in malware samples we which are compiled. Uh, and the the motivation for the the blog came from maybe even almost a year ago. It's certainly not a new problem. Uh but but I long time ago, the only the the only way I used to reverse engineer malware samples using com is to go through this very manual process. And then then the idea was to create to see how what's the proper way actually of doing it. And from my kind of research or the learning process came a couple of presentations and some of the conferences, and then this blog which we published last week. Um, so let's come back to go back to the reason why the threat actors we would use this in binary standard. I think first of all, it it kind of allows malware to conduct operations by using standard Windows functionality. And at the same time, you can avoid Windows 32 API API functions. So those are the standard functions which we usually use to program system programs in Windows. But those programs, those functions are frequently monitored by the EDR software. So with COM, sometimes you it appears that the functionality that's executed on the systems system will not appear from the original malicious process, but from some standard Windows component like uh servicehost or explorer.exe. And it will appear as it's just like a standard Windows functionality. It may not raise necessarily any kind of suspicious level in somebody who's looking at the logs or what's happening on the Windows. The second part is that by using com in binary files, the way the COMB is implemented is always through the set of indirect calls into the function table, so-called virtual table functions, which are kind of similar to virtual table functions, uh virtual function tables, which are kind of present in in C. Only this is now made different so that any language can use this contract between the client, which would be the program or malware, and uh usually the server, which can exist either inside the process of the malware file, or it can be a separate process on a on a on a local machine on the system, or it can even be another server, another net on the uh on the network on the in the victim's network environment. So you know, COM can be used for lateral movement, setting uh persistence, schedule job, writing files, downloading, whatever. But the process of analysis is somewhat involved. If you just look at the call, you see the instantiation of into one function. That function gets an interface to the array of those function pointers, and then every function of those so-called interface that you want to use to achieve certain functionality is used by indirectly calling into the um beginning of the function function table plus some offset where the function pointer is. So it's kind of like jumping through the hoop. So the analysis actually is not so easy. So you don't see it's it's an open file. You only see call edx plus 30, for example. So you need you need to be able to decode this, like what's happening behind that.

Amy Ciminnisi 7:14

Awesome. So you look at several malware families for this blog, uh, specifically Quackbot, Attor, and Warm Cookie. Uh, and they all use COM in pretty different ways, um, from persistence to command and control. Um, I'm curious if this variety suggests that attackers are more sophisticated in how they live off the land, or is it that COM is a path of least resistance for getting things done in a Windows system?

Vanja Svajcer 7:48

Well, I wouldn't say it's the path of the least resistance, but it's just just a just a very useful and very extensive big platform that kind of provides a uh an is exposed as quite a large attack surface, exposing a lot of the Windows system functionality. So it kind of only makes sense that that the threat actors will reuse that. Because like on any particular Windows version, like in Windows 10, there are over 10,000 COM classes that can be used for some functionality. They expose more interfaces than their classes. And you know, by a by by a creative programmer or threat actors, they can be utilized in a very creative way, right? So it's just there. I you know, it's not like a super sophisticated, but overall it is quite complex behind the scene. So I think definitely less sophisticated threat actors have have a number of examples how they can use Qualm for achieving persistence or lateral movement or so on. But also the more sophisticated actors use you know some of the standard interfaces, such as the ones that I already mentioned, but there will be some completely unknown interface, which they will be able to use for, I don't know, um terminating EDR software in some ways that nobody knew about before, or uh communicating with uh C2 servers, like in the case of Background Intelligent Transfer System, the bits, which is used by Windows for updates, but you can also use it for to download files or community over the same protocol. Um so I think the more sophisticated the threat actor is, the more creative will they be in the their usage of COM.

Amy Ciminnisi 9:32

Right. So you mentioned that it can be very labor intensive. Um, but in a soccer IR environment, you always kind of have to balance the depth of analysis against the need for speed. Um when people are triaging a binary, how do they know if it's worth the effort to dive into the comm structure versus just moving on to the next alert?

Vanja Svajcer 9:58

I mean, you can do quite quickly um a triaging on whether the the actual malware sample is importing some of the functions that can indicate that the COM is being used. And then if you see that this function is, for example, a reference within the file many, many times, that clearly indicates that this is a COM-heavy function uh calling piece of malware. And and oftentimes you you would see the the absence of some of the standard Windows 32 API calls, and then you probably go, okay, so I understand this is likely a com thing. I know what's involved here. You know, it's it's it's to be honest, it's not the most labor-intensive thing when you think about the the whole area of research, uh reverse engineering. But uh it's still quite annoying because uh you you from the first glance, it's not immediately obvious what this uh sample, and you don't even know whether it's a malware sample, does at that point. You know, maybe you're looking at something completely legitimate.

Amy Ciminnisi 11:06

Right. Um, but then I'm wondering when people are looking for malicious com usage in their environment, you know, what's the first thing that you look for? Um is there a specific interface or behavior that should raise a red flag?

Vanja Svajcer 11:23

Yeah, you you you you look for this co-create instance uh function. And if if that's get called, of course, that can be immediately imported, you know, as a in the import section segment of the file, uh, but it can also be resolved dynamically. So that's a little bit more difficult because then you have to guess like when when some some uh function is resolved dynamically. However, what you need to do, you go back uh when you see the call, and then you have to identify two things because there are two really important parameters of those fun that that function. One is so-called class ID or a global unique identifier, which is like 128-bit long number, which is in in like a very specific format. It has like a specific structure in memory. Um, so if that structure is already declared as that specific unique ID structure, you will be able to see it in the file. But oftentimes Malver again tries to hide um the way how the the GUID uh or the interface ID is is put together. So sometimes you will have uh operations, which in some areas of memory, usually the stack, uh, will will kind of place or form a string which will be uh the the unique identifier. So those two things. One is the class, and the second is the in is the interface. So the class basically logically uh groups those interfaces, and interfaces are are just contracts between the client, I mean the malware file and the operating system or the server. In that case, you know, what functions are exposed. So so um internally the the object which is created using that function will have its own data, it's it's it will all have its own data members and so on, but none of the data members are um uh exposed to the clients. And and this is done for the reason that we achieved that interprogramming language uh uh functionality that was the main point of com. So two things like one is a class GUI, the second is interface IDs, and then you you find them, they are 128-bit numbers, and then you need to try to find how do they map uh to the human readable names. So on on the on the client, on the machine, if you're running it, all the mapping between the uh user or global unique identifiers for both the classes and the interfaces have been traditionally in the Windows registry, although in some of the newer versions, that mapping is not so not so clear. So there are various ways how you are able to map the unique identifier towards the the username. So, you know, and then then you kind of make a decision. I see this is trying to uh instantiate the class for the uh uh interface to create uh a new schedule task, which will point to the attempt to achieve persistence on the system.

Amy Ciminnisi 14:30

Right. So there are a lot of tools that help analysts recognize com usage and malware samples, but it's still really important to understand the basics yourself, uh, which is what this blog provides. So for analysts who are new to hunting for this usage in their environment, what advice would you have?

Vanja Svajcer 14:54

Well, the although although this blog point is tight, a blog post uh is titled Introduction to Qualm with Windows Threads, um, it is kind of relatively technical. But I think for for the like threat researchers and blue team members, it's important to understand the basics of it. It's important to understand what happens in the background so that they can recognize when some malware sample may be using comb for the for the functionality. Um, in addition to that, they need to, after they know like roughly how it works, so they can recognize it, then they can they they they can just try to use some of the tools like all of you.net, which is a great tool for investigating comb on the systems. But also, if they do any kind of reverse engineering on Ida Pro or Binary Ninja, there are plugins um which also help with resolving and and uh helping uh to transition between the uh just looking at weird indirect calls into something that's kind of understandable and readable by the analyst. But I think before before that you need to try to at least once uh kind of reverse or understand what happens in the background without the help of those tools, right? And then later you can you can use the tools. So so my idea is to kind of introduce the reader from the how would you do it completely manually to hey, in fact, there are some tools that can help with it.

Amy Ciminnisi 16:24

Right. So after someone maybe has done that baseline uh research and knowledge gathering and learning, um, what do you want them to walk away from it with? You know, maybe something that will make their next um triaging just a little less painful, a little more effective. Um, what advice would you have for someone who's trying to take the next step?

Vanja Svajcer 16:51

Yeah, I would I would say the best advice is just try to do it. Do go and do some hunting, you know, that uh learn some of the most important uh com classes and interfaces, find the most uh commonly used uh interface IDs or class IDs, uh put them in some Yara rule and put them into virus total or whatever repository or malware you have and see what it comes up with. Uh there will be a lot of completely clean and legitimate files, so you may have to spend uh a lot of time triaging to see which is the malware file among all the clean files that will be also detected using com. But hopefully, and eventually you will you will stumble upon something which is kind of entirely new and which will get you very excited to reverse engineer it and then just dig deeper, start doing it manually, and then you know, apply the tools, which are more or less linked from the blog.

Amy Ciminnisi 17:57

Yeah, and I'm probably just preaching to the choir here, but you can read as many books or take as many courses as you want about this, but it's a whole other story to actually go out and do it. Learning by doing is so critical in cybersecurity. So, Vanya, thank you so much for joining us today. This was really useful, even if, you know, some of it went over my head a little bit. Um, still still learned so much from you today. So thank you.

Vanja Svajcer 18:26

Thank you, Amy. It was great talking to you.

Amy Ciminnisi 18:28

Great having you on. And thank you so much, everyone, for tuning in. I will put Vanja's blog in the show notes. So please go and read that. It's chock full of information, and there are a bunch of really great resources at the end as well. Tune in in another two weeks for a new episode. And until then, stay safe out there.