 Welcome to my analysis for Hedgehogs. The last technical video has been quite a while ago, the reason being that we did this podcast in between. But I think for change and we should do another technical video. Although we are still not done with the podcast, there's still one more episode to go. But let's start with another technical video. This time about SPORA, the shotgun worm that is also ransomware. Or more specifically, I want to talk to you about how you can use MAVA analysts articles to help you learn about MAVA analysis. Now, these articles are not made for people who want to learn analysis. They are made rather for other analysts so they can benefit from the research results. So they don't show you how you get to these results, but they show you what the analysts found out about a certain ransomware or malware family. Now, how can you use it to learn? First off, you should get the exact same sample that's referenced in such an article. Usually these articles will present you the hashes of the samples that they used as a basis. And every proper article would do that because otherwise your claims cannot be verified, or the claims of the author here in this article cannot be verified. So proper blog articles will provide the file hashes. In our case, the starting point is an HTA application. HTA is an HTML application. So it's an HTML file with some executable code in it written in VB script or in J script or something similar. And that's the original file that drops then another dropper which drops spore sample in the Word document. So we will be starting from that. You might already have problems here. You might ask yourself, how do I get the exact same sample? Well, I will provide some links in the description below so you can links to sharing sites, links to forums where you can request samples, links to, for example, virusshare.com. Those are databases where you can search for samples via the hash. But for new samples, these databases might not be up to date. So you can always try to ask people who have access to virus or ask the analysts to wrote the article. I think a lot of them are happy to help you out. If you say you want to learn analysis, they will probably help you. Okay, so let's start with that. And the advantage of using these articles is if you are fairly new to malware analysis and you have an unknown sample, you really have the problem that you don't know what there is in front of you. Like you will see something, you don't know what it is, you don't know how to interpret it. And that's something, if you read the article, you already know the direction it's going to. And if you read the article and know what's happening in detail there, you can also just try to verify what's written there and see if you find out the same things and if you interpret the things the correct way that you found out. So it's really an advantage if you already know what you are looking at. But you have yourself, you have to work yourself to find out how you get to these results. Sometimes the articles will provide addresses, you can use them. So this is an aid already. Sometimes they don't provide addresses, but you can see certain addresses in the screenshots. Like in this case you see, yeah, I'm not connected to the internet. In this case, you can see an address right here in the jump call. So you can use these addresses to find the reference functions. Or here, similar, there is if the person using IDID not rename parts of the file, like sub functions or sub procedures, they will also have the address in this label on this name, which you can use. All right. Now, what we want to do today is look at one part of the encryption procedure of Spora. The whole encryption procedure is fairly complicated. We kind of do all of that in today. But let's just take a look at one part of it, namely the .key file and how this .key file is being encrypted using AES. Like it's written in here, the .key file contains some information, statistical information about how many files have been encrypted on the system, and some other information, the locale, the username, the campaign ID, and then RSA key. And this file is being encrypted using a newly generated AES key. And this key is then appended also in encrypted form to the .key file after that. So let's just find this AES key, see if it's indeed AES 256-bit, and see if that's being used to encrypt the .key file content. So just that, and let's go from there. Now, our starting point is this HTA application. The HTA application drops another file, a Jscript file into the temp folder, and the Jscript file drops a P file. That's the Spora sample that we want to have. So this is our goal, and it would drop a corrupt Word document. So let's just get this file here. That's what we want to have to get to the encryption function, finally. So here's our dropper sample, our HTA. And we will be using process monitor and process explorer before we can wrap the samples. Yes. Let's try to kill the sample before it's done with encryption. For process monitor, you need to set certain filters. First, for the process name, one should be mshta.exe because that file is being used to execute HTA files. Secondly, the close.js file is executed with wscript.exe. So you send this as a process name. In this case, I said it should contain script. So wscript.exe will be shown. And thirdly, the category should be write. So we see the write actions or write operations by these files and can see where the drop files are being written to. So that's all we do. And we use process explorer to watch the processes appear and kill the file when we don't need it anymore. Kill the process. I mean, all right, execute that. And as expected, the Word file opens. We kill this. And we kill this also. Right. And now we see, okay, that's exactly what's described in the article. Close.js is dropped to temp. The p files dropped to temp with the exact same name on the Word document. Now, this is not a random name. The article describes as well that this is hardcoded in the dropper in the JS file. If you de-apposcaded, you can see that too. And you can also see in VirusTotal that uploads to, in the additional information tab, that uploads of spora, of the spora assembles use that name alongside other names. Like this is dropped by the JS, CloseJS, whereas names like these are being copies of this one. Like this file will copy itself into a certain location and then use names with this pattern. And there's always different, depending on the machine. So, and then there you have files, they always files like these, where the name is just the hash, those were being uploaded by malware analysts usually, as they like to use the hashes for the sample names. Okay, so we have the sample right here. So let's just go there and drag and drop it to the desktop. Before we can disassemble, we need to unpack the file because that's UPX packed file. Yes, that's been UPX. Good thing about UPX is that unpacking is pretty easy. And we will just do that. If you execute UPX.exe will show you which switches you can use, the minus these for decompressing, it will decompress the file in place unless you give a minus error option to write to give it a different location for that. So, let's do that because we might want to keep the original file decompressed. And the original one was this. Now it unpacked this successfully. And we can analyze that using ITER. Again, I will use the free version of ITER, which is pretty old, it's 5.0. But this is because you can use that too without paying anything on the commercial version is pretty, pretty expensive. So it's not for everyone. The ITER is now analyzing the file, which takes a while. And then when this graph appears, we are done. And I recommend that you try to find yourself through this code and just take the article as a help if you don't get anywhere further. In this case, if you scroll down a bit, you see already here some functions related to encryption and cryptic wire context. And so after that cryptic wire context, or I would suspect there's more encryption going on, so I will probably analyze these subcalls here and see what they do or sub processes. All right. And what is this doing, the script acquire context, it's used to acquire a handle to a particular key container within a particular cryptographic service provider. So it is used in calls to the crypto API. And that's kind of the beginning for some encryption stuff right here. And here's a key cryptus Troy key. So basically, I would search in between those two calls for more, for more stuff that's happening with the encryption in Spora. But if you don't get anywhere with this, just as I said, use the screenshots as a hint where these functions you're searching for might be. Today, I would like to verify just one small thing, the encryption procedure of Spora is quite complicated. So let's just verify a small thing about that. And that's this one. There's a key file in Spora. And the in Spora, Spora writes a key file. This key file saves information about some statistical information, how many files of which category have been encrypted by Spora. And what's the username and what's the locale of the system. And also it saves an RSA key in the key file. And these contents are encrypted with AES 256 bit. So let's just verify this small fact that this AES key 256 bit is being used to encrypt the key file. Not more. And if you don't get along finding that, just use this hint here, 4041d7 or 4041e0. In the screenshot, the jump location that will bring you into the right area where you can find the code that you're looking for. So we will jump to this address 4041e0. And that should be about the right area of the code you're looking for. That looks correct. Something with the key file is being done here. And we go back to the beginning. We will rename this function. So we know that it's doing something to the key file. Do well, or let's say key file function, some key file function. We don't know yet what it does, but we can rename it when we know more. So rename it again. And right in the beginning of that function, we see a crypt can key call. What is that doing? Again, visit the documentation. Crypt can key generates a random cryptographic session key or public private key pair. So probably depending on the algorithm handle to the key is returned. And this handle can be used as needed with any crypto API functions that require the key handle. The calling application must specify the algorithm when calling this function because this type is kept bundled with the key. So that's important. Like the key determines the algorithm. And it's, well, the information what algorithms used is bundled with the key. So this function crypt can key already determines which algorithm is being used. And that's in this parameter of the function the ALGID algorithm ID that identifies the algorithm. Clicking on that, you get to this page that describes the algorithm ID and the values here. So use that value to see what algorithm is being used with that key. And taking a look here, the algorithm ID is 6610 in hex. Compare that. And you find out that this is indeed AES 256. Yeah, so we are on the right track. We know that this is being used. And the key that is being generated is written to that address that is pushed here onto the stack. And what is in EAX at this point, it's the address that is a that is a local variable called hkey. I don't name that hkey because it's being used as hkey. But we already know more about it. We know it's an AES key. So let's just write it in here and rename that. And then we know when it's being used again that this is an AES key, 256 bit. And indeed, it's being used later on with the script export key function. So it kind of converts this key to something else to that buffer here. Converted AES key. All right. And if you look down a bit, there is a call to crypt and crypt, which is used to encrypt some data. And crypt encrypt it encrypts data. The algorithm used is designated by the key held by the CSP module and is referenced by the hkey parameter. So the hkey parameter here will determine the algorithm that's being used by crypt encrypt. Whereas PB data, that's this, it's a pointer to the buffer that contains the plain text to be encrypted. So if you debug it, you can see in this what kind of data is being encrypted. But we already know that it's the AES key that's being encrypted right here. Yes, the key is being encrypted using another key. And that's being pushed onto this deck here. If you follow that, it's in the text section, it's a value in the text section. And this address is being referenced by another function, like it's referenced by our function, of course, but also by another one. And if you click on that, you get here into this function, you would have to analyze this function to know where this key is coming from. But just look at the calls right here. Some object is being decoded. And later on, there's some crypt import public key info. So a key is public key is imported. So it looks like the key we will be we were looking for this hkey is a an RSA key public RSA key. So let's rename that to public RSA key. Okay, go back to the key file function where it's been used. So public RSA key is being used to encrypt this exported RES AES key. Good. But this is not what we wanted to see, but you can you will know from the text here that this is indeed the case, this newly generated AES key is being encrypted with the attacker's public RSA key, right? Okay, but is this AES key now also used to encrypt the key file content? Probably. Let's take a look. Here's another call to crypt encrypt. And this time hkey is the AES key, the original one, not the encrypted one. And PB data is in this buffer. So here's the plain text that's being encrypted. And what you would have to do is look for for where this comes from. So this is a parameter to the key file function. That means if you debug this file and just look into the contents of this buffer, you might see what's inside. You might see that this is indeed the key file content, which is probably created before this key file function is called. So yeah, if you look down below, you will see some calls to create file and write file. And this pattern with this dot key in the end. So this will be creating the actual key file and writing the encrypted contents to disk. And that's the right function here. We were looking at using AES 256 bit encrypting this key file content. So let's rename it maybe key file content. You would have to verify this that this is indeed the content. But I think I think you get the hang of it now. Of course. That's the cool thing about renaming it. If it's used later, you can see what is being done. We have this name here of the key file. And then there's a write file operation with this content. Makes sense, I think. Okay. And that's it for today. I don't want to make this any longer. I'm also a bit exhausted by now. Yeah. And I hope to see you next time. I think the next video will be the podcast again. So stay tuned and thank you for watching. We will be continuing and please see that as well. So see you next time.