Malware analysis

Since I started to learn about how computer works and how can we program it to do what we want, one thing has catch my attention: The assembly language and the power of reverse engineering. Reversing engineer something and having the knowledge of how it works internally so we can use this knowledge in our own projects or for our own understanding, is the clearly definition to “hack” something. You got to know how something works so you can know how it was done, what it can do and change its behaviour for what you want.

In malware analysis this is the foundation for everything you want to do in this field, reverse engineering is a must, since the bad actors will never hand you over the source code of their malware. If you have enough knowledge of how computer works in their lowest levels, you can understand how the bad actors did what they did and starting see patterns from what their code can do inside a computer.

For this post I will be using some example of malware from the outstanding book: Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software by Michael Sikorski and Andrew Honig¹ . It is a bit outdated but since we want a very simple example of an malware to study, this will suffice.

⚠️ Warning! read this! ⚠️

Before we proceed lets make one thing clear, do not ever try to run or reverse engineering a malware on your production system! It can not only compromise your PC but also the other ones in the network! So please, if you want to learn malware analysis, take some time to read that book and get a bit of the knowledge how to setup your sandbox environment. The malware’s sole purpose is exactly this, compromise and spread in the network, so be careful!

I strong recommend you to always use VMs, with their latest update for both the VM and your host OS! There is cases that malware can even break free from the VMs.² So a good practice to have a fully up to date VM and host OS for that or physically segregated device only for that purpose. Preferably, both, be it a other physical PC or an VM it need to be completely disconnected from the internet Since the malware will try to reach the CnC³ server and wait for instructions or get more tools for it to its work, at least until you know what you’re doing.

Another recommendation if you want to do a dynamic analysis of the malware (I will explain what this method of malware analysis is later), is to use online tools that is already build for this purpose. A good ones is virustotal and hybrid analysis, you just drop your malware file there and they’ll do all the work in an sandbox environment. Besides, you do not even need to upload the file to them, since they work with hash indexing, you can just pass the hash of the malware with SHA256 or SHA1 to see if they already scanned that file (and for sure they will have it indexed! Unless you have a new kind or new modification of the malware specific for your case. It’s possible too.)

⁉️ What? and Who?

Malware analysis is a pretty big field with a lot of techniques that can be a bit overwhelming at first but very rewarding if you know how to reverse engineer an compiled binary of an program. Let alone it be an malware example, that have a lot of defensive measures put in place to thwart any attempt to reverse engineering it, or at least, to make it as hard as possible. Since it is their the best interest to keep their operation and ways to compromise systems hidden and unknown, or at least until its already too late. It’s a forever going cat and mouse game.

❓ Why?

Understanding how a malware works and behaves on a system can help anti-malware and other solutions to block it executions after have a knowledge of it presence in the system but for this systems to actually know how to deal with them, first we need to tell them what to look for or monitor the right calls on the system when some program start behaving very suspicious on an system.

🔎 Signature/Heuristics

Here is where signature and heuristics enters in the scene to detect and respond to this kind of threats in the system. After reversing engineering a malware and studying it and how it operates inside a system we can now program an anti-malware to detect it and respond to its actions before its too late. There is a couple of ways we can do that, lets focus on two the most used today:

• Signature base: This one is very fast to detect a malware and usually have a very low false positives because of the signature of the malware it haves but there is a catch, it can only detects something that he was programmed to know, so new malware (or even a modified version of the malware) will be invisible to this kind of detection. To name a few examples: polymorphic malware, fileless malware, encrypted/packed malware and so on …
• Heuristics base: This one is more about continous monitoring and how things behaves in the system. For instance, what system calls the programs is doing, does a program need to do this kind of system call? Does it looks like suspicious? It is signed by a trusted source? When it runs? Why it is calling this functions? That kind of questions that is tested when heuristic anti-malware is working and sometimes it can be very computer intensive for the system. The good side of heuristics, it can detect previously unknown malware but it does have a high false positives too. So not everything that it detects is actually a malware.

🔔 IoC

IoC is simply put of Indications of Compromise, this can also help a lot in threat intelligence. Since it consist of malware hash, urls that the malware will try to query on the network, IPs that it will try to reach, registry keys it will touch, files created or modified in the system and so on…

When doing the reverse engineering on the malware we try to extract this kind of information, how it works, when it works and where it try to compromise the system, to effectively create the IoC for threat intelligence to be shared on the internet and so other professionals can know if their network, systems or OS is actually compromised. It integrated perfectly to the incident response and give a good actionable data to cybersecurity professionals try to isolate the compromised systems, eradicate the malware and restore the full operation of the effected systems.

🕵 “Know your enemy”

The other use for malware analysis is to know their “fingerprint” in the cyberspace (yeah i like this word) of an specific threat group and study how they operate. This can create a profile of the threat group like:

• TTPs⁴
• Motivations and Goals
• Trends of attacks
• Their infrastructure and capabilities

An good example of this is how the cybersecurity researches keep track of APTs.⁵ We can get for example the APT28, aka Fancy Bear, this APT group is linked to Russia’s General Staff Main Intelligence Directorate (GRU)^{6 7}. They are highly skilled individuals that have a impressive history of causing a lot of havoc in organizations and government around the world⁸ and even interfering in the US presidential elections in 2016⁹ with their advanced tactics of staying hidden in the systems for a long time, extracting information.

❗ How?

So now that we know what malware analysis is and why it exists in the first place. Let’s see it in action, and how it can help the cybersecurity community to “know their enemies” and react to them accordantly when reversing engineering their weapon, the malware, and use it against them.

🛠️ Static analysis

The first way to analyse a malware and a very straightforward one is Static Analysis. In this method we do not actually “run” the malware, instead we just look inside its binary and try to figure out what is their capabilities and their purpose on the system. What they try to accomplish once they run and what is their methods to compromise the system, exploiting vulnerabilities on the target system and what is the IoC’s that can tell that a system is actually infected by this malware, their pattern on the compromised system (signatures, behavior and so on…).

For this I recommend using an VM with a Linux distribution that already has all tools already installed, like Parrot Linux or Kali Linux, both distribution is excellent for cybersecurity professionals and comes with the full arsenal of tools to let you do much more than just malware analysis. I will be using Parrot for this demonstration but both will work perfectly. Just remember to properly isolate the VM from your local network and read the Warning section above! Even the malware that you’re analysing is not for your system. You never know! Better safe than sorry..

The software to help us analyse the malware I will be using the Cutter but you can also use the also outstanding Ghidra for that, they are both very good tools for reverse engineering binaries, actually Ghidra was develop by NSA¹⁰ itself. So, you could not go wrong either way.

We’ll analyse an .exe and its counterpart an .dll extensions and see what this examples and do in a system. Opening them on Cutter we could see the following: Figure 01 .EXE overview

Figure 02 .EXE Imports

Figure 03 .EXE Analysis

With this information we could see that this malware have quite few imports and also is an PE¹¹ that is targeting an Windows OS x86 and indeed is a EXEC (executable file) for windows (never trust the extension of the file! Always check, so now we definitely know). The PE seems not to be obfuscated or compressed (an very common technique when trying to hide the actual malware from reversing engineering or signature based detection that anti-malware uses) since the number of imports in the figure 03 and the sections¹² of the PE is also in “expected” size and format we can say it is not obfuscated or packed.

Another thing we can see from the figure 02 and what this example .EXE capabilities is that it uses a couple of interesting imports accordantly to the Windows API through the Microsoft Developer Network (MSDN) library documentation we could enumerate some of his capabilities:

• CopyFileA: Copies an existing file to a new file.
• CreateFileA: Creates or opens a file or I/O device. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe.
• FindFirstFileA: Searches a directory for a file or subdirectory with a name that matches a specific name (or partial name if wildcards are used).
• FindNextFileA: Continues a file search from a previous call to the FindFirstFile, FindFirstFileEx, or FindFirstFileTransacted functions.

So basically this malware can find files in the system, copy them and create/modify files. Now let’s take a look inside the strings inside this binary and what we can learn from them. The following screenshot seems to have a pretty interesting strings: Figure 04 .EXE Strings

Jackpot! We can learn a lot with the string inside this .EXE that is also inside the section .data, there is a very interesting name: “kerne132.dll” the malware is probably trying to create this file inside the system to maintain his persistence when it execute and this could be a good IoC for us to know if a system is infected with this kind of malware. Since this malware is from lab01-01, it will try to find his .DLL counterpart to do other things here too.

Another thing we can see is the wildcard in the “C:\*” and the “.exe” it seems that this malware will try to mess with all the .exe inside the system too. We’ll keep a eye on that kind of possibility.

Lets now analyse the .DLL counterpart of this .EXE and see what is his capabilities too: Figure 05 .DLL Overview Figure 06 .DLL Analysis Figure 07 .DLL Imports

Analysing the DLL extension we now are sure it’s an DLL file accordantly with the type show on the figure 05, we can also see that there is some very interesting imports that this DLL is calling. For instance, we can see it’s using WS2_32.dll that is an library, accordantly to the Microsoft’s Windows API Documentation, that provides the necessary functions for network communication. So this DLL will try to communicate with something to do more things. The function that it imports is inet_addr, connect, socket, send and recv. That is also ensure our suspect that this DLL will have the capabilities to reach something and receive some command or data.

Another interesting function that it does import is the Sleep function, so this DLL also have the ability to “hibernate” or “Suspends the execution of the current thread until the time-out interval elapses”, as Microsoft’s Documentation says. Alongside the Sleep function there is also another interesting function called CreateProcessA, once again accordantly to the Microsoft’s documentation, “Creates a new process and its primary thread. The new process runs in the security context of the calling process”.

Let’s take a look in the strings that this DLL have and see what we can further learn about this DLL capabilities.

Figure 08 .DLL Strings

Analysing the strings inside the .data section we have a lot of very interesting things, first an IP address. This could be another one IoC for us to publish about this malware, the other things is the “hello”, exec and some kind of ~random~, or better, yet not understood string “SADFHUHF”.

We could go on like this for quite an good time and start going inside the disassembly¹³ and start dissecting this EXE and DLL bit by bit, but the purpose of this analysis here I think is pretty clear. The power of static code analysis is indeed incredible, we could learn quite a lot by just seeing an overview about the binary, the imports that this binary need from the Windows OS and the strings that is inside this binary. Of course, this is a very simple example of malware, do not expect to be this straightforward approach on a real one and specially an very up to date one but one thing is certain, they can try to obfuscate and encrypt all they want there is tools and sandboxes that can help you understand the malware (virustotal, hybrid analysis and PEiD to name a few) format that they are using and even decrypt the malware (dynamic code analysis, virustotal and hybrid analysis site again, can help in this one) to get the “real” binary to analyse just like we have done until now. In the end of the day, the malware need to execute and will do a lot of obfuscation and checks to make sure it is in an valid system that it want to infect and are not being analysed by an researcher, you just need to fake it good enough to let them think they are in a real user system and show to us the real binary of the malware and that is where the Dynamic Analysis comes in…

🔬 Dynamic analysis

Let’s face it, static code analysis will have its limitation. We can definitely learn quite a lot in static analysis without running the malware at all but there will be times that we will hit an dead end and we need another technique to allow us to learn even more about an malware, like for example an Dropper¹⁴ that will reach its CnC server to get the “real” malware for us. Well, here is where the dynamic analysis comes in.

This time we will not look at the binary, we’ll monitor the whole system and/or the malware to see what its actually doing in the system and analysing it as it’s thinking that is running in a true user environment. Dynamic analysis I like to compare it like doing an illusion magic, you make the malware “think” it is running in a genuine end-user system but in reality we are seeing everything he is doing, we are in the control of the situation. Like dumping the memory from a VM or monitoring it inside an sandbox system with a sets of tools that help us see what its doing in real time on the system. After that we will have a report of everything that was done, what it try to reach, what it tries to modify, create, read and so on…

As you can see, Dynamic analysis is also a very powerful technique that complements the Static analysis. In the static analysis we have a good understanding and we build our theory of what this example could do. In the Dynamic analysis, we actually confirm it by running it in an safe environment (make sure to read the warning section if you have not done so!)

So, to make things simple and straightforward we’ll be using virustotal but hybrid analysis is a good alternative too for dynamic analysis. These tools give you the power to simulate that sandbox environment that we talked about before and have the entire report of what is going on inside that environment. It will greatly simplify the process to analyse the malware’s binaries while keeping your environment safe from any damage or, even worst, compromise your entire production network. Knowing that i strongly recommend first starting the dynamic analysis with these online tools.

First we will hash, both, our DLL and EXE extension files and submitting the hash string to the virustotal and see if someone has already analysed before, and sure thing it has! The report is the following: Figure 09 .EXE virustotal report

Going to the behaviour tab on virustotal’s report, we can see some pretty interesting activities from this EXE, it indeed have the capabilities to read and copy files on the compromised systems, it also has the capabilities to enumerate files on windows and do it recursively like we have theorized in the static code analysis step. In the MITRE ATT&ACK¹⁵ we can also see some threat model that the online tool has capable to enumerate for us, not everything is accurate but it definitely helps to give us more knowledge about this example and actually confirms what we have seen from the static code analysis.

Now let’s see the DLL counterpart of this EXE file and see if the assumptions that we had about this DLL hold true after the dynamic analysis. Figure 09 .DLL virustotal report

We can see that this .DLL create an TCP socket, send and receive data from it. It also create a mutex¹⁶ in the Windows environment for handle file operations, from that we can see that indeed our static code analysis was correct but how about that IP that we found to be our IoC? Does that hold true too?! And that strange string in the .data binary, “SADFHUHF”? Let’s see what virustotal can shine a light on these questions for us Figure 10 .DLL virustotal deep analysis

So it all checks out. This DLL has contact that IP address, that for this example is actually an local connection inside the machine or a loopback connection¹⁷ connection to talk to another process inside the same OS. The strange string (not stranger things ba-dum-tss 🥁) is used as a Mutex’s name for handle multiple process to access/modify shared files/variables on the compromised system, also a good IoC for this specific malware. So we can conclude that this DLL and EXE is working together, since DLL will not execute on their on (except you force it¹⁸) and it will create a file “kerne132.dll” on the system and it will mess with all .EXE in the compromised system. It also has a functionality to run command with “exec” and “sleep” that we have seen in figure 08 inside the DLL strings.

Finally we can conclude that this example is about a backdoor and it will maintain it persistence messing with all the EXE inside the system and creating this “kerne132.dll” on the compromised system.

😈 The deception

We got the bad guys, we find everything that we’re looking for. We got them, right? Well, not quite… Indeed the static analysis we got a lot of information that for sure helped us to profiling what this malware is and what is its capabilities but there is a catch here…

Indeed the static analysis put us on the right track to get a very useful information, there is not doubt about that but the dynamic analysis did not help us too much. Why? Well this example actually needs both (EXE and DLL, see figure 04. It will search for its DLL) of the files to be in the machine in the time of execution and it also need an specific argument to actually make it run on the system. So what the virustotal has return us is more in-depth analysis of the static code (heuristic analysis, if you will, of the static code) and not the dynamic analysis.

So to actually make this example to actually run and do what it means to do we need to go even deeper in the static code analysis and see what it expected to receive in its argument and here comes the power of the disassembler that I said at the end of the static analysis.

Actually we could use figure 04 that is the string inside EXE and see that there is one string that I did not mentioned and is inside .data section of our .EXE example, it is “WARNING_THIS_WILL_DESTROY_YOUR_MACHINE”. This seems pretty obvious to be an fail safe that the author create to not allow anyone executing this EXE in their machine because it will indeed destroy your production system, as we have seen, this malware change all EXE inside the C:/ path, but how do you know this is the actual argument it need to execute? Well this is where the fun part start:

Figure 11 .EXE Disassembly flow 01

Figure 12 .EXE Disassembly flow 02

We now open the EXE once again in our static analysis tool, Cutter, and make it actually auto-analyse the binary so we can have our disassembly flow like in figure 11 and 12. After search for that string, we find that the function that is locate in our disassembly is fnc.004011440. How can we be sure this is the argument? Well, look at the figure 11 and see the assembly command cmp, that is compare, to number 2. This is our first indication this logic is for test the number of arguments the header of this function is also telling us that this function need some arguments, after that we have an jne, or jump if not equal, that strongly encourage us to see this is where this EXE will test the number of arguments and if does not have what it wants it will just exit.

Next we see the string that we’re looking for, “WARNING_THIS_WILL_DESTROY_YOUR_MACHINE”, following this flow in figure 12 we can see at the assembly block 0x0040148d it will test if the string is exactly this one once again with the jne assembly command. If it is not, it will follow that green arrow to the right and exit the program but if it is, it will starting by creating a file and after that we can see the path to kernel32.dll. We don’t need to follow the white rabbit to see that this is indeed what we’re looking for. Now we can actually make this malware run and observe its functionality as a whole.

I do not recommend going further than this but if you know what you’re doing and have actually read the warning section, you can now create a VM with a Windows XP and detonate this EXE alongside his DLL and see what will happen. The result is indeed catastrophic:

Figure 13 WinXP compromised

So now we can see that it did create that kerne132.dll. Lets see if he actually write something in the original kernel32.dll comparing the hash before and after compromise:

Figure 14 Comparing hash kernel32.dll original vs after compromise

It didn’t changed the original kernel32.dll but it did read it! so why he didn’t change the original one? As we can see, from our dynamic analysis, the malware did change a lot of .EXE in the system, practically every single one inside C:\ path and here we need a little bit of knowledge how kernel32.dll works inside Windows system and why it was target by this malware. The kernel32.dll is a very critical DLL on Windows OS, it enables programs to do file operations, memory operations, process and thread operations, I/O operations and hardware operations. So, yeah, it’s a very critical DLL, even the name as “kernel” just reminds us that is something that is in the core of any system but why the malware didn’t modified it? Let’s go back for our static code analysis to find out, now using a very powerful tool named as decompiler¹⁹ alongside our graphic flow of our disassembled code to make things even easier for us, after all we are humans and we need to return that hexadecimal code as close as possible to the source code to actually understand what it is doing. Assembly is the first step and helps quite a lot but C/C++ is even better to understand a lot more of the structure of this malware and that’s where the decompiler comes in.

Inside our cutter decompiler we could see this very interesting function named on 0x00401440 address position in our .EXE malware example: Figure 15 Decompiler EXE calls DLL

It is calling two .DLL, the kernel32.dll in the system and malware .DLL that it will try to find in the same path the .EXE is, if it does not find its .DLL it will exit but the most important knowledge we can extract from this decompiler, is the windows API “CreateFileA” and the second argument of it. We can see it calls kernel32.dll with second argument as 0x8000000 and the malware .DLL with the second argument as 0x100000. What does it means? Well let’s find out in the windows API documentation page and sure thing we found it, here is what this means:

Figure 16 CreateFileA function operations summary

In the Figure 16 we can finally know that it is only reading the kernel32.dll, that’s why it didn’t modified it but it’s doing all the operation on the malware .DLL. So we continue analysing the decompiler and see that the malware is actually coping the entire kernel32.dll leaving the last part of the original malware .DLL intact, or for better terms, it is appending its malware .DLL with all the kernel32.dll from the system and finally copying the malware DLL as the kerne132.dll to the system as can be seen in the Figure 17:

Figure 17 malware copying its DLL to “kerne132.dll”

Here we have the evidence that it will not only create the kerne132.dll malicious file in the machine but it will link every single .EXE in the system to this new malicious .DLL that is now replacing the original kernel32.dll from the system. Now, let’s see what this malicious .DLL file looks like before it copy the kernel32.dll to it in our decompiler, we already know from our previous analysis that this .DLL has the capabilities to do network operations and execute commands in the system, see figure 07, 08 and 09.

Figure 18 decompiler DLL function

Well, that shows pretty much what the original malware DLL is capable to do. First, we can see that strange string that we discovered to be a mutex “SADFHUHF”, after that the DLL is sending a “hello” message thought the socket it opened on the system. Next the iVar2 is used with this mutex and is the one that will be used to receive the command from CnC server. If it does not receive anything it will sleep but if it receive any string or a char in iVar2 it will get that command and execute in the machine with the CreateProcessA. This thing will be executed in all EXE, so this is why the malware EXE copied the kernel32.dll and leave this code from the original DLL malware, it will try to always talk to the CnC server every time the machine execute an EXE.

To confirm this lets see what is inside the “kerne132.dll” and the malware original .DLL and also get some example of some random .EXE that this malware has access and modified.

Figure 19 Hashing malware DLL

Figure 20 Comparing malware DLL before (left) and after (right) compromise, beginning of differences

Figure 21 Comparing malware DLL before(left) and after (right) compromise, end of the differences

On figure 19 we can see that “kerne132.dll” is actually the same as malware DLL after compromise, so it did copy kernel32.dll data inside of it and then copied the malware DLL after compromise as “kerne132.dll”, as previously noted in figure 17. On figure 20 and 21, we can also see what is the difference between both of them, malware DLL after and before the compromise. This space was already waiting to be complemented by kernel32.dll data, so what is that data that it copied and why?

Figure 22 Comparing metadata the original malware DLL (left side) vs after compromise (right side)

Looking at figure 22 the metadata²⁰’s comparison between original malware DLL vs after the compromise we can see that the size is the same but the strings and symbols has grow quite a lot. So it already had space to accommodate all this data copied from kernel32.dll file, specifically inside the original windows kernel32.dll’s .rdata section.

Why to copy .rdata to an spoofed kernel32.dll file? Well, rdata is actually read-only data and is an crucial section to store constant data and other static information, like calling a function that is described in this .rdata section to do its function, since this .DLL do not have the original function but has the malicious action, it will be used to execute his malicious functions every time this .DLL is called, as we conclude before, every .EXE in the system was injected to call “kerne132.dll” instead the original kernel32.dll from windows. This malware is using an technique called DLL Hijacking to make all functions call its malicious functions instead the real ones. In this case, performing the remote connection to an CnC server. This can be further supported by this evidence inside the malware .EXE that will find and replace every .EXE in the system with the spoofed kerne132.dll:

Figure 23 Malware EXE decompiler of function find kernel32.dll and modifying it call “kerne132.dll”

At figure 32 we can see the malware .EXE calling a function __stricmp from library MSVCRT.dll. This function is basically an case-insensitive comparison of strings, if this returns 0 both strings is the same and that is exactly what the malware is doing. Search inside the entire EXE for any match of kernel32.dll and replacing it with the spoofed “kerne132.dll”

Before closing this analysis lets get a example of a compromised .EXE and have a proof that this is actually what is going on here.

Figure 24 Comparing Ping.exe before(left) and after(right) the malicious activity

*Figure 25 Comparing Ping.exe’s function before(left) and after(right) *

In figure 24 we can see that it indeed injected the malicious DLL and in figure 25 we can see where it did inject it, directly on the call for SetThreadUILanguage, that is responsible to set the language interface in the UI for the user. Also note that this function is called very early in the program, in this case the Ping.exe, so this malware want to make sure it will call the spoofed .DLL no matter what and do its thing.

There you have it, in this analysis we can conclude that our IoC is this kerne132.dll, IP address and this “finger print” of all EXE that this malware have touched in the compromised system. It was pretty long analysis but it was worth it, since we had to mix a bit of advanced tools and knowledge to actually understand a lot of what, why and how.

💡 Conclusions

Malware analysis give us insight how the bad actors try to compromise the system, analyse their patterns and label them to track down each individual group or malware families though their TTPs and learn from them to in turn create the IoCs and a good and very well informed threat intelligence thus making the cyberspace safer for everyone.

We could also see the incredible power of static analysis with dynamic analysis can give to us and how they can work together to help us understand the malware. With that we could create our own IoC based on our observations (and confirmations) of how the malware infiltrate inside the system and try to hide using ways to thwart any detection like we have see in the dynamic analysis section.

Like I have said, this example is pretty simple and straightforward for an real world malware but the idea follows these patterns, sometimes you can not analyse the malware with static code, it could be encrypted or have different tactics to prevent its analysis but one thing is certain, it is projected to run in the system, to compromise. One way or the other it will execute and will give you what you want, it just a matter to have the required knowledge and tools to understand it. Once you have the knowledge of something, it no longer has control over you.

“Knowledge is power. Knowledge shared is power multiplied.” — Robert Noyce, co-founder of Intel Corporation.

---