Introduction

During the past few days, as one might expect, we’ve been getting lots of news, reports, and files for the ransomware entitled WanaCrypt0r/WannaCry/WanaCrypt. First and foremost, the good news is that customers of PC Matic SuperShield were protected from WanaCrypt0r the entire time. However, this post aims to provide a technical analysis of how WanaCrypt0r works, as it was clearly a threat to be reckoned with. The purpose of this post is to use the ransomware as an example to show malware analysts, enthusiasts, IT professionals, and the curious techniques that allow an attack like this to occur. At PC Pitstop, in addition to quality software, we stand behind quality training and education.

A Little Background

One of the problems with classifying malware samples as “trojan,” “dropper,” “keylogger,” and other types is that some malware is essentially “all of the above” or at least exhibits behavior from more than one of these classifications. This is certainly the case with WanaCrypt0r. Technically, it could be labeled as ransomware, a worm, a dropper, and even a rootkit because it infects the kernel as well as user space. Due to this, we need to examine the overall mission that this malware appears to be trying to accomplish: Spread to as many computers as possible and encrypt files, asking victims to pay up to a bitcoin account. Due to the latter, WannaCrypt0r may be best described as a ransomware. Strangely, as of this writing, there are no public records of anyone who paid the ransom actually getting their files unlocked and while of course there is never a guarantee, unlocking files could actually help criminals remain in business and keep future victims paying.

The general behavior of WanaCrypt0r from an infected victim’s point of view is as follows:

• Upon execution, the victim’s data files on system and network drives are encrypted, as long as a “killswitch” website is not reachable. If the killswitch site can be connected to, WanaCrypt0r will not run.
• An exploit is used which spreads the ransomware to other Windows machines on the network which have not received a security update
• A ransom message is displayed, asking for payment of $300-$600 in Bitcoin in order for the victim to receive a decryption key and unlock his/her files. The original cost is listed as $300 but victims are told that this will double if the payment is not made after 3 days and after 7 days, the files will be lost forever.

This behavior is very typical of most ransomware out there today, however one differentiating factor is how WanaCrypt0r spreads itself around networks by using an exploit called ETERNALBLUE which was released as part of the EquationGroup code leaks on April 14, 2017.

Getting Started – The Killswitch

You’ve probably heard that WanaCrypt0r also featured a so-called “killswitch” by attempting to connect to a server like so:

Interestingly, this killswitch URL is placed front-and-center in WinMain(), the program’s entry-point. The author was apparently not concerned with a malware analyst locating this URL, despite the fact that it has the ability to stop the malware from executing the payload.

WanaCrypt0r first attempts to connect to this URL and proceeds only if the connection fails. This can be seen in the following disassembly’s highlighted area:

According to Microsoft Developer Network, InternetOpenUrlA returns NULL/0 if the connection to the URL was not successful. On the second highlighted line, we see:

mov edi, eax

Which places the return of InternetOpenUrlA into edi, A few more lines down, edi is tested for a zero value with

test edi, edi
jnz short close_and_exit

Finally, the program quits with ExitProcess if the connection was successful by using the jnz opcode.

Since the URL is now up, we need to modify the program slightly to get it to run, which can be done by opening up a debugger and placing a breakpoint at memory address 004081A5. As we see above, this is the address at which the program determines whether it should run the malicious code or exit. At this point, we will change the “Z” flag or Zero Flag in the debugger to 1 by double-clicking it. It is the red 0 pictured on the right of the screenshot:

The Embedded Executable Resource and Establishing a Service

If we step back to basic analysis for a second and examine the file in a Portable Executable static analysis tool such as PE Studio, we see that there is a very suspicious red flag: An embedded executable file of type “R” with the name “1831”:

As we see above, even though the resource is in fact encrypted, it is still recognizable visually and by the system as a proper Portable Executable file due to the first two bytes of “MZ” (4D 5A) as well as the appearance of bytes “50 45” (PE) later in the file.

Of course, we could dump out this resource and open it up in analysis tools itself but we can also go into the main binary and search for function imports such as LoadResource, LockResource, and FindResource which the malware could use to load up and work with this embedded binary resource. Upon doing so, we locate it in the original WanaCrypt0r file:

However, before proceeding to this code after checking for the killswitch, as mentioned above, WanaCrypt0r checks for 2 commandline arguments given to itself on startup which are “-m security”:

The reason that it does this is because by checking for the arguments, it can know whether this is first launch on the machine or not. If the arguments are not found, WanaCrypt0r will create a new service out of itself and this service will start it with the two arguments applied. This means that after the service is created because the ransomware has been run before on the machine, it will skip the service creation step and then just attempt to start the service. It starts a service called mssecvc2.0, which allows it to load into memory and start whenever the computer boots up. The first time around, the malware chooses the left path and executes a function that I’ve named “create_serv_Wrap”, which first creates a new service of itself, then drops the executable resource that we examined above onto disk, finally  running it as well. We will see exactly how this happens after this figure, but first take a look at how the malware sets itself to auto-start on bootup by setting the dwStartType parameter of CreateServiceA to 2 which is of course Auto Start: a popular choice for malware as one may imagine:

The actual executable that it runs at bootup is simply the main malware executable itself, but the service name has a 2.0 appended to it and this time, it is started with the commandline arguments “-m security” as seen above.

Before moving on, we have to take a little aside to look at one more technique that WanaCrypt0r features which can help slow or freeze analysis by beginner analysts. Instead of referencing the file handling functions directly in the code, it places function pointers to each API call in another area of memory and then references those pointers. A common analysis technique is to check the Imports section of a malware file and then cross-reference the usage of the import throughout the file. When this technique is not featured, for example, there may be 10 locations in the malware which directly call WriteFile and all 10 will appear as cross-references, allowing an analyst to easily spot the context of the writes. But in order to hunt down these calls in WanaCrypt0r, we must first label each function pointer address and then in turn cross-reference those instead of the direct API call. This is pictured below. Also note that I’ve renamed each function pointer to an underscore followed by the name of the function to which it points:

Notice how after each series of instructions follows a mov _SomeCall, eax instruction. GetProcAddress is being used to grab the address of the function and store it in a variable at each of these movs.

Now that we’ve covered that, the next step that the malware takes is to prepare and to write the payload/resource to a file:

At this point, we can see the ransomware setting up a path of C:\WINDOWS\tasksche.exe and C:\WINDOWS\qeriuwjhrf  and then calling MoveFileExA. This call copies C:\WINDOWS\tasksche.exe to C:\WINDOWS\qeriuwjhrf if it already exists. If it does not already exist, it simply writes the resource to the C:\WINDOWS\qeriuwjhrf path.

Finally, WanaCrypt0r launches the resource, which has now been dropped to an executable file, by calling CreateProcessA on it as shown here in red:

The Exploit/Worm Component

After the service is properly setup on the machine, StartServiceCtrlDispatcherA is run and passed into it is a serviceStartTable struct which contains as a member, the start address of the beginning of the payload function which I’ve named “register_service” which in turn launches the worm/network component of the malware as well as the EquationGroup SMB exploit. The beginning of this module can be seen in the following figure:

This networking component is what contains the “meat” of the ransomware and what makes it unique. It utilizes the leaked EquationGroup ETERNALBLUE exploit which is demonstrated in Metasploit here. This exploit allows WanaCrypt0r to spread itself to all networked Windows devices which have not been patched with the MS17-010 security update. This update was actually released back on March 14th of this year, but as you probably know many individuals and networks do not immediately install all updates, leaving this vulnerability open.

Summary

In summary, WanaCrypt0r first checks for a killswitch URL, then checks for commandline arguments and sets up a service which auto starts on bootup. Once established, an attached executable resource file is dropped to disk and ran, as well as threads started which execute worm code that spreads the ransomware around the network via EquationGroup’s ETERNALBLUE exploit of the collection of vulnerabilities listed as part of the MS17-010 bulletin. In order to keep this from going on forever, we will end part I here. In the next part of this analysis, we will dive into the dropped executable and vulnerability code and also look at some of the compression and encryption used in WanaCrypt0r.