In this blog post, we’re gonna be talking about malware investigation. I would like to show you all the different interesting places where malware resides, what are the symptoms that you actually got infected because sometimes you don’t really know because malware can hide pretty well. We will search through all of the places where malware can hide and what are the techniques used by malware in order to function.
The above image is my screen. What you are looking at is a Microsoft Network Monitor, and we will perform a little bit of analysis of a situation and environment when there is a malware running. Our job will be to investigate, and at the same time, learn how to find out certain types of information in the operating system by using different types of tools. Also, we will be investigating what this malware does and what kind of components it has.
Malware investigation step by step
So, let’s have a look at the Microsoft Network Monitor first. We’re going to start the capture to find out the background for our research.
So what we can see over here is a communication between 10.10.2.100 and 10.10.2.10. We can spot that this communication is by Rundll32.exe. So, that’s one of the interesting places for malware to be in. We can see over here that this communication was happening at 2:49:40 and we can also spot that kind of information here, as well, that we’ve got a 2:49:50. We can move farther and see that we’ve got 2:50:00. So, we can see that that type of traffic is happening every ten seconds which is already a little bit weird.
Let me stop this traffic and get to that web server that we are, as a client, communicating with.
So, this is our web server right now and we’ve got here the regular default website. What is the point? The point is that, well, maybe because it’s out there running, maybe we should just stop it and see if the communication still persists.
So, let’s go back to the client and find out, in the trace, if that kind of traffic is still out there. So I’m going to do “New Capture” and “Start” and see if the communication is still there.
So, for now we don’t see it. For now it’s not there. Oops, it’s over there. So, we can still see TLS as a form of a communication. So, we’ve got again, 2:51:11 and we’ve got another one at 02:51:21. So, again that communication is still happening which is a bit weird because we have stopped the web server, right? Well, not necessarily because the web server, as we have it, one thing gets the service that we are affecting here. But another thing is HTTP.sys which is accepting traffic anyway. So, on the web server, we’re going to run NETSH even though quite of old school. We’ve got that.
Within the netsh, we will analyze what kind of services and processes, are listening within the certain type of ports, but definitely within the HTTP traffic.
So, netsh and then let’s do “http showservicestate”.
So, these are the different type of processes that are listed within that particular web server right now. There’s plenty of things as you can see. For the fact that we have stopped IIS doesn’t really mean anything because we’ve got over here, as well, the Remote Management, 5985 and stuff like that. We’ve also got over here something that’s kind of weird which is called “Pricing”.
That is definitely very strange. Let’s try to get access to this. I’m going to do it using Internet Explorer. Instead of asterisks, I’m going to type “localhost”. That’s kind of interesting for me because there’s like absolutely nothing that should be out there because we have stopped our web server. But, a question is, will there be any type of website that is active? And as we see, there is indeed something like that.
If I refresh it by pressing F5, this is changing. Well, basically I can tell you how that part works. This is a very temporary piece of code that is used to encrypt the traffic in between the malware server and malware client. This is in order to make the whole troubleshooting a little bit more difficult. But that’s not what we are focusing on right now. What is more interesting for us is to find out what kind of process is actually engaged in this “Pricing” thing. Let’s find out.
We’ve got over here “Request Queues” and we’ve also got the process ID 976 and 4204. So at that stage, we can get into the Task Manager. We can go to “Details”, sort by the “Process ID”, and we’ve got over here the Process ID 976 and that’s svchost.
Quite an interesting place for a malware to be in. But there is also 4204 and that’s an even more interesting place for a malware to be in because that’s just an executable which can be used for running different types of DLLs.
The question is now how to find more details about it. Well, you can run either Process Explorer or Process Hacker. The two options are possible here. I have here Process Hacker which we will use as an alternative. Previously, we used Process Explorer, so this time, we can use this one. When we search for and by the “Process ID”, we can get into “Properties” and then we can spot in “General” tab what the execution parameters for “rundll32.exe” are .
We can also see that this one is running MalwareServerDll.dll with that particular method we got RunCC. So, this is an export. Basically, we can analyze this particular DLL and find out what it does. Let’s analyze it a little bit as well on the client’s side because we can spot a little bit more over here.
We can see at that stage within the Microsoft Network Monitor, that the process responsible for it was rundll32.exe, but sometimes this information might not be the one that we rely on. At this stage, what we would do is to elevate the console to administrator, and the next stage is to use “xperf” to analyze in detail what kind of processes communicate over the network.
Analyzing Malware Communications
I’m going to run “xperf” with the parameter –on. I’m going to define here “PROC_THREAD” and I’m going to add on top of that “LOADER” and I’m going to add on top of that “NETWORKTRACE”, and to make it nice and pretty, I can specify the buffer size which is going to be 1024. Then “MinBuffers” and then I will specify 256 which is kind of a standard and “MaxBuffers” 256.
Now the question is how we are to specify that. Actually, you can skip this part. I just want to show you something nice where we are actually setting up some boundaries so that our lock does not go crazy and has good performance.
That also sets the details of what should, of course, be the buffer size where we collect data when we are performing the tracing. In the very end, we will need to specify the “MaxFile”, say 256 as well as “FileMode” which we will do as “Circular”. In other words, what you could do, you could even skip the whole thing over here and the only thing you could leave is xperf -on PROC_THREAD+LOADER+NETWORKTRACE. This allows us to perform the tracing of what’s happening within the network with all the necessary details. Let’s do that.
So we run xperf right now and we just need to wait a moment, at least 10 seconds, to be able to get that information out. And when we are done, the next thing we do is xperf and then we do “stop”, “-d” and we dump this information into “network.etl”. So “network.etl” will contain information about anything that was ever communicating within the network. If I want to get a little bit of more information for humans, I can convert that “network.etl” into the regular, for example, text file.
So we’re going to do it within that “xperf” again and “- i” and we will specify our “network.etl” and then we will do: -o (as output) into network.txt, -a (as an action) dumper and network.txt will contain information about different types of communications made and the processes of communicating over the network.
The FINDSTR has plenty of options but in general what we’re going to be using here is the option that allows us to ignore different types of characters. We’ve got over here, “findstr” and then we are specifying, of course, different options that we got. At the very end, we will specify the strings and the filename.
Let’s do that. You might be wondering how do we know which strings to search for? Well, we need to know that structure a little bit, for sure. But for us it’s going to be quite straightforward. Let’s do that. So we’ve got a findstr /i , and then we will specify TCPSend. We will then specify it in the network.txt and that gives us a beautiful output where we can see that indeed “rundll32” is the process name that we’ve been using over here in order to communicate to 10.10.2.10. So this is this characteristic of the traffic that we could see before. We also have the communication from the 10.10.2.100 which is our client. So that also confirms that this is this type of traffic that was happening here and the rundll32 indeed was the one engaged in the whole process.
Let’s again open Process Hacker. I’m going to open it as an administrator and find this process.
Our interest, is to find out the process ID which is by the way 6072. Specifically, we want to find out a little bit more details about what is loaded within that particular executable. We can see like previously that we got MalwareClientDll.dll and also RunClient export.
What is quite interesting for us and I would like to show you a little bit of deeper analysis is that when we get to modules, we can spot what kind of interesting DLLs we are actually loading over here. Another interesting thing is that we can just sort this by name, one thing is the malware client which we can eventually do “Open File Location” and we can copy it and then put it to our Analysis Folder.
Let’s sort by the description now. So it could be something like seen above. We have got here a temporary file which is our malware client. Of course, we see that this is a malware client but what we are quite often searching for is something that is not digitally signed. So when I sort by the verified signer over here, yes, then I see that there are plenty of things that are not necessarily signed.
We’ve got this guy, so what we can do is to get into “Open File Location”, take it, copy it and then paste it for the c:\analysis. We’ve got a bunch of files gathered that we are able to analyze. Let’s dig in. Basically, what is also interesting is that it will be great to analyze this malware client DLL. So, what can we use for that? For example, we can have a look at the Resource Hacker. Resource Hacker is quite an old tool that I’m pretty sure you are familiar with if you did a little bit of analysis before.
Let’s have a look and open our malware client DLL. Lovely. What we can see over here is that there is something called binary 105. And then there is this 1045 which starts with MZ. That is quite interesting because inside, we’ve got MZ, which signifies, by the way, the initials of the Polish guy, Mark Żbikowski, who invents this type of file.
We’ve got this 1045 and we can get into “Actions” and we do “Save Binary Resources”. Because it’s MZ, it’s probably some kind of executable and then we’re going to save it, for example, as “Data” and then it’s going automatically have plenty resources saved so we can analyze it.
We save it as the “Data_1.bin” that is actually a binary file.
We already have saved over here this temporary file which was one of the modules. It will be very interesting if we could, at this stage, compare these files. So let’s dig into it. We’re going to go into c:\analysis and for us, it would be great if we could do fc (file compare), and we’re going to compare bit by bit (/b) that “Data 1.bin” and our other file which is the one that we have extracted from the modules. Let’s find out what comes out of the comparison.
As you can see, they are exactly the same, which confirms at that point that the binary file that we have just extracted that was in the Resource Hacker, is exactly the same as the one that was running over there.
What we can also do is to analyze that particular binary file using the tool, PEBrowse Pro. PEBrowse Pro is quite a nice tool that allows us to analyze in details.
I will put here “All Files” and get into our “Data_1.bin”. We can see here in details, different types of options, where and what this particular file is about. We can spot that. Over here, we can see plenty of details about what this particular file is about. This is quite interesting because we can analyze it a little bit more. But the only thing that we can see is that we’ve got one import that is MSCOREE.DLL and there is just one function which is the _CorDllMain. That is a confirmation of what we already could see in the Process Hacker when we were browsing through the .tmp file for the Rundll32 process.
Even More Tools For Malware Analyses
This is .Net stuff. So when we analyze and when we see this is .Net, what we could do at that stage, is actually ILSpy. So let’s do that. I’m going to open the ILSpy tool which I have in my toolbox.
So what we will do right now is to open a binary file that we’ve got. Let’s do “All Files”. This is the one in ILSpy because apparently, this is .Net code and we can clearly see that this is something that can be de-compiled. We can get into MalwareClientLib and we’ve got here a method which is quite interesting. It is called CheckCC().
And over here, we are able to spot different types of functions but basically what’s our case is that the method that we are using over here which is “decryptAssembly” and is the one that we are using to decrypt an assembly. It will later on be executing on the client computer as a part of this malware.
We can trace it further and we’ve got here something that is called “DecryptRes()” and this is a very interesting function. I would say it is a decryption function that is using, well a couple of algorithms as you see over here, but long story short, we are able to spot that is using a resource that is called “Problem”. This is actually quite interesting because possibly, yes, possibly we will be able to find a little bit more data, a little bit more options, to be able to get access to it.
So, that analysis is endless, and we could really be doing this for hours. However, my goal is to show you who, what, and how deep we can get into the analysis.
Of course, this does not necessarily need to be possible because the code can be obfuscated but who knows?
What I want to show you as well, within this PEBrowse Pro is that we can also open here a MalwareClientDll and the results are going to be a little bit different because in here, we’ve got a little bit more details and we’re able to get into disassembly this particular DLL and that result is going to be a little bit more interesting because we will see here native code. Well for us, right now it’s more. I just want to show you if you are curious. But this is also something that will be able to prove to us that that particular analysis can be as deep as you want it to be because there’s a lot of things that we can check for.
What we are trying to do right now is opening our DLL into PEBrowse Pro so that at the very end, we’re going to be able to disassemble it.
So, when the DLL is opening we can get information about exports and this is something that you already know.
RunClient is the export that we could see in Process Hacker and this is our disassembly so we are able to get into details about what is happening and what is interesting in that particular file. Of course, that analysis is a little bit more difficult. We can see here all the different methods that we’ve been reviewing, so we got RunWebClient, MalwareClientLib, and so on. This is clear for us to spot. We’ve got as well here a little bit more information that could be, for example, a .Net. So, we’ve got ICLRRuntimeInfo and we can get into a little bit more details. We’ve got here “Load and start the .NET runtime” so we’ve got here some signs that can indicate us that is definitely the .net code.
At the very beginning, we’ve got the native code and then later on we’ve got the .NET code. So, that analysis, as you see, can be endless but hopefully I showed you a very nice path to first trace what is communicating over the network. That communication over the network can be quite tricky. Also, we played with a xperf tool, one of the best analysis tools ever, and we have also learned how to have a look inside a DLL or eventually a binary file, which seems to be also an executable file, both in the native code as well in .Net code.
So, this is a little bit of guidance for IT Pros who are searching for a little bit more challenges within the malware analysis.