 Welcome to Meme Analysis for Head Shocks. You've probably already seen it in the news but there was a supply chain attack on 3CX desktop app. This is a voice over IP software so you can call people with that. Lots of companies use this software and now there has been a software update with malicious code inside. Today we're going to analyze this with Binary Ninja. Let's look into it. So we first got to know about 3CX via the bleeping computer article. This is not so uncommon so if you have not everything curious first time at the client software, if you're a blogger in Meme Analysis, checking articles is one thing you will have to do to add some new signatures for something that the others found. One of the reasons you write articles or Meme Analysis articles is to also help other analysts analyzing this. So bleeping computer, they commonly get their information, compile their information from more in depth technical articles. So one of the things I recommend you do is always find the actual analysis source of that because they usually contain more information. So bleeping computer, you will see references in here so we can read the article, find references here to Sophos analysis and this is actually just Web Archive GitHub repository, Centino 1. So we have a few articles that you would then read in depth to find out some more information about the matter you're going to analyze and that's completely legitimate of course to do that. We already know from this article that FFMPag is the malicious TLL of this application. We already know that this is going to download some icon files and here is some more information. Interesting and they mentioned here some kind of info stealer that is the last stage. Is it even on virus total? Let's check this and it's not so that's too bad. Alright, okay, but how do we start? Well, the first thing that we have is the MSI file and if you like this is the let's say original file that gets downloaded from the CCX update and that you unpack just with seven zip. So let's do that and here you have the files. We know that we need this one, the D3D compiler and we know we need the FFMPag so let's get them and rename them a little. If you follow my channel you will know that I always advocate to check the strings. Now there's one issue with this. Let's see. This is going what feels like forever. The problem with legitimate applications that have been Trojanized where someone patched malicious code into them is legitimate applications are usually huge so you see it's quite hard to find the actual location of the malicious code this way and that makes it difficult indeed. Now there are several ways you can deal with when you have to find a malicious code of a Trojanized application. The first one is you get a clean or in this case you don't have a clean version of that one, a previous version and use a tool that does some binary diffing then you can find the changed functions and specifically look into those. But of course you should also always just check the entry point of the files. For DLL this is like DLL main and then you can also see if there are some added exports or something like that. That would be very obvious of course but that's where I would start. Also they mentioned that those files are signed. We can let's check that as well. So this one is signed by Microsoft and I think the FFM pack is used but yeah, right so this is a signed file. If that's a malicious one there are two options how a malicious file can be signed and have a valid certificate. They can steal the certificate somehow or they can manipulate the certificate section to contain some data without destroying the actual file. In the manipulation case running the file will not execute any malicious code still but you could hide some data in that. So let's check. Alright and we should wait now for the analysis to finish otherwise you are going to start looking into stuff that you will find out is being analyzed later. So how could we actually start? Well with Binja I would first start with the triage summary because here you find the imports and exports. You can check those specifically if you find let's say screenshots of the malicious code in some analysis articles. Check what APIs are being called from that screenshot and then you can use the imports here to find the API. Let's say you found virtual protector click on that and then find the reference to that and there it's being called. Then of course something you should do is try the entry point. This is a DLL so the entry point must start in the let's find the DLL main actually. So this one will start where the DLL dispatch DLL main dispatch function is called. Go into that and between the DLL main CRT dispatch call the two ones there is the DLL main so this is the function we are looking for. We check that we see there's not much inside it's just checking for arc 2 and we go into that one and here is the actual malware code. How do I know that because this is loading this D3D compiler and we already know from the articles that this one is where the malicious code is extracted. So let's call this right and now we are gonna check what this is actually doing. One of the things I'm always doing is like getting some sort of overview checking the end of that what's happening here down below. These labels they point to some yeah I'm not sure what this is some kind of okay get last error heap free so this is just some free function. So this is something like free in exit and let's get to this one. So this is an event handle AB monitor refresh event checks if that was successful and then it checks if this event already exists. So this is the last error and this error should not be that it already exists. We have another function here that's not known now from viewing this. This looks like some library stuff that I don't I think that was mem said. All right and get module fine name we have a yes all right this is a buffer that receives a unique code module fine name like this is double the size of that one. This is buffer we are having here and the law you actually it's the five parts of the module that we get the whole path including the folders and that is being saved into this buffer. It took a while for it to register that and that is the size and it's in characters and is it in characters in teachers. Yes, and that is the size and bytes and it's filling that with zeros. So here it searches for the beginning of a character. So we have the backslash so this is getting appointed to the last occurrence of this character. And that means here we have the start like slash slash ffm pack dot dll. This is what's inside this one here. Rename our name with slash and here we have the same but it's a module fine name without the slash so just the module fine name. This is just some error checking. So this here replaces the module fine name with the d3d compiler underscore 47 dll. That way it basically it grabs the whole purpose of that is it grabs the folder it is currently located in and then checks inside that folder for the d3d compiler dll. So this is what is being done here. Can I display this as a character? Okay, it's just some way to do that. If the pseudo code doesn't make sense, check the disassembly that's where you find the exact instructions that might be a bit more useful to you. So it's creating if getting a file handles a great file just gets the file handle. We have here the trial handler. Because that's the file that's being used. And why do I have to scroll sideways that's a bit unconvenient and convenient. So it reads the file and heap a lock. So here we have some buffer where it reads the file inside that. And that is a sequence you should remember because this is looking for mz. So this is reading the dll the way it was that they don't like that now. Let's change the type. Sorry. That's better. We have another weird thing here. Let's get back. Now it looks a little bit better. So we allocate a buffer with this file size will read that. So this buffer actually contains our deal. And since it starts at mz, what we can do at this point is put the dos header as a type for that because that's where it starts. The types you find under view types types that are already there. Let's check does header does header and copy this. And like this a dos header. And now we see the reference is here e magic, which is correct. And here elf new. So let's look for the peak of specification. And you will find that at 0 3 C, which is what you saw before, there is the elf new value which points to the PE 00 signature. If you haven't already watched my video about how PE files are structured that will help you with that. So right after PE 00, there is the start of the headers, start of the cough header, more specifically. And so that's where we are at this point. However, this doesn't make so much sense because generally the other values of the dos header are not of interest for malware. So let's look into this as a disassembled version. So this is elf new. And that means at this point, we are getting the offset to PE 00. So this is PE 00, this adds 18. Let's change this actually to decimal. So that means it's PE 00 plus 20. So the PE 00 has four bytes plus 20 means we are then at the optional header. And that is something you can verify here. The cough header stops at 20. So like the last offset value is the last field is at 18. And that has a size of two. So after that, there's the optional header, which is where we are at at this point. And then we are there. Let's look into it on the high level view. And we can change this, the optional header. And we can also change the type here to the optional header. See if that helps us a little bit. Now this is PE 64 optional header. There are different headers depending on if it's a 64 or 32 PE. What's the difference between those? When you check here, you already see there are different offsets depending on a PE 32 plus 64 bit. There are different offsets of that. The reason is right. Well, is it here? No, I found it. The reason is this field, the base of data field, which is only present in 32 bit, so 32 bit PEs and not in the 64 bit PEs. So the 64 bit P error is actually smaller. Now remember we are using the, we are reading this file right here. I'm not sure if I checked the bitness. I guess I didn't. So that's the one. And we see this is 64 bit one. So that should be all right to use this. So it helps a little bit with this here. This is calculating, checking if it's the 64 or 32 bit PE. I'm not sure why they check that because it seems like when they apply this patch here that they know what they were loading. But okay, maybe it's copied from somewhere and then would explain this display. This is enum, set this as a type. So here we see it's checking. And if it's not 32 bit, then this value here will be one. And then it means we have some alignment value here. So this means some alignment value. And due to that alignment value, this is now not correct here. So actually, let's check that this is something again. What we are dealing with is this is the optional header. This is the start of PE00. Then we add the optional header and then we add 84. Or since we need that as a decimal, that's 132. And right below there's something similar and 128 and 132. So let's check those here. So 128 is the start of the certificate table. That's unusual. Generally malware would not... That's not a value I would remember. Let's put it that way. I had to look this up here. Whereas something like getting the optional header offset that one I would see. And you see the field is composed of eight bits. The first four are the address and the other four are the size. This one, that's actually the address. And it's not the resource table. We see the resources are here. So we are off by eight bytes. 16 bytes, not eight bytes. Which is due to this alignment here. So it determines where the certificate starts certificate address plus three. So this is some kind of index current offset that is being checked against the size. And this is like moved. And so we are searching at this offset certificate address plus offset. And then it checks. That's why it's plus three because it checks from minus three. And then it searches for these values. Look into the summary FE field phase. It's recommended that if you find such values just Google them. Sometimes you find stuff. Or you can Google them like that maybe. And on Twitter, ECM test. So it seems to be used quite often in with crypt. So this is not really helping us. But it looks like this is checking for the sequence here. Search feed phase in the certificate. And it's doing that until it finds the end of the certificate. So when it's found, it will do what's happening here minus current offset. So this is the start of the certificate again. Not exactly. It's right after feed phase because that's why the current offset is right after the feed phase thingy. But it's plus eight. So what's happening here? It's allocating some space for buffer. That's the size of the buffer. It takes this size from third size minus eight. So at the end of the certificate, there is the size of the whole thing. No, third size minus current offset. That's the buffer length. The rest of the data. Feed phase, there's some data and the data goes until the end of the certificate. So this is the buffer length that is being calculated here. And here we copy the data inside. But these are two loops that go until 100 hex, which is like the same as 256. This is something you should remember as being RC4. If you search for RC4 on Wikipedia, please get the English one, thanks. So, yes, this is what you see here. So these are the two loops. It's the KSA key scheduling algorithm. And what we want or that we are interested in would be the key. So apparently this looks like it because it is like this key and then index. So it's kind of like getting a value from this. Using this as an array here. And so this is RC4 for the data in the certificate. And after that, here's the RC4 stuff. After that it calls virtual protect on that address, which is just the start of the buffer. So there is some code starting right at the beginning of that. It calls virtual protective page execute read write. So at some point it should run this here. That is the execution of the function. So this is probably some shell code since it decrypts this buffer and right at the start of the buffer. This is executed. Let's go into that and verify this. So we know this is getting the values from D3D compiler. We also know it's looking for feed phase, but I still would like to check this certificate location. So you find that in the data directory. And there is the certificate table. That's where it starts at offset 49E000. So here's the start of the certificate data and we should find feed phase at this point. And here it is at feed phase twice. That is interesting. And that's then the data here right after feed phase. We do select the block. Just append zeroes. And that is encode code feed phase. Looks all right. And this is perfect for Cybership. So we know it's using RC4. We also know the buffer it is using from the buffer of the key. And this looks already all right. And especially this one. If you see nulls and it's probably all right for code because code often contains like zero values. So does an PE file. So this looks all right. Let's save this. So that's it for unpacking the first stage. We are going to look at the next stage in the next video. And I hope to see you soon. Let me know if you like this kind of analysis. So see ya.