Introduction

Part II of the WanaCrypt0r code analysis has arrived. We’re going to be starting out where we left off last time, which is with the Microsoft Windows MS17-010 Server Message Block (SMB) exploit/”worm component” that made the ransomware so dangerous by allowing it to spread to other vulnerable (not patched) systems on the network without the computer users having to click a single thing. The reason why we’re going to look at this component first is because it is part of the original executable file that initiates WanaCrypt0r. We will also be looking at the attached, compressed, resource files and their functionality in a subsequent post. Let’s first look at a high-level view of what the SMB exploit even is, what it does, and then how WanaCrypt0r uses it.

What is this SMB exploit that we speak of?

In order to understand the exploit, it helps to understand what Windows Server Message Block is in the first place. Let’s have a look at the official description of SMB from Microsoft:

The Server Message Block (SMB) protocol is a network file sharing protocol that allows applications on a computer to read and write to files and to request services from server programs in a computer network. The SMB protocol can be used on top of its TCP/IP protocol or other network protocols. Using the SMB protocol, an application (or the user of an application) can access files or other resources at a remote server. This allows applications to read, create, and update files on the remote server. It can also communicate with any server program that is set up to receive an SMB client request. Windows Server 2012 introduces the new 3.0 version of the SMB protocol.

This protocol was originally created by Barry Feigenbaum at IBM and was adopted by Microsoft Windows. It is the older Windows networking protocol which was more prominently used before Active Directory. The exploit CVE is CVE-2017-0145 and it actually only affects SMBv1, when the current version of SMB is SMBv3. However, a major underlying problem with software, particularly that we’ve seen with Windows, is that businesses, organizations, and even home users will have specialized software and devices which are only compatible with certain, outdated versions of Windows. For this reason, software updates or operating system upgrades are often not installed, allowing for exploits like this to take advantage of older systems.

So how does SMB actually correspond to WanaCrypt0r?

Essentially, a Windows computer with SMBv1 installed and enabled would be sitting on a network and listening for connections on port 445. When a certain “special message” was sent to the machine on that port, this would allow an attacker to run a program on the machine without even being physically present and on the machine, and without the computer’s user even taking any action at all. So this is what happens:

1. The attacker finds a way to get someone in a large (or small) network to open the WanaCrypt0r file. This is not very difficult with social engineering techniques and trickery.

2. Once the original executable is opened and the killswitch is not enabled, WanaCrypt0r immediately scans the network and sends the “special message” to all of the computers on the network. This message triggers the exploit mentioned above and then allows WanaCrypt0r to copy and execute itself on the other computers on the network.

3.This cycle continues and since the other component of WanaCrypt0r encrypts all data files on each machine, it locks up entire networks, halting businesses, schools, and other organizations.

With all of that out of the way, let’s get back to the code behind WanaCrypt0r. We left off at the module where the ransomware executes StartServiceCtrlDispatcherA and passes a function start address, which I’ve named register_service. This means that when the malicious service that WanaCrypt0r created previously starts, it will immediately execute the code within register_service:

Windows Services

But what exactly does StartServiceCtrlDispatcherA do? The way the Windows service system works is that a Service Manager is part of the operating system and it is in charge of, you guessed it: managing the services. When a service is starting, it must first launch by using StartService and then within around 30 seconds of launching, it needs to call StartServiceCtrlDispatcher which tells the Service Manager which thread that the service will be running on and gives it control over the service. If you are confused about what a service is in the first place, it’s just a separate category for a program to run “in the background” and automatically start when the system boots up, so that it is not grouped with the other programs that the user has started like Firefox, Chrome, etc… Malware loves to utilize services to hide from the main Task Manager process list, but mostly to automatically start whenever the computer is turned on without the user knowing. A list of services can be viewed by pressing Ctrl+Shift+Escape and navigating to the services tab on Windows 7 and newer.

So what code does the service execute once it’s handed over to the Service Manager? The below code sets up a Service Control Handler and then launches the exploit payload with a call to a function that I’ve named “fire_threads” because the function starts additional threads:

Notice the highlighted subroutine which I’ve named smb_exploits. This doesn’t get directly called, but instead, it gets pushed to _beginthreadex as a function pointer and then _beginthreadex in turn starts a thread and finally executes the smb_exploits code. Let’s look into smb_exploits to get to the bottom of this exploit.

Finding victim computers on the network

Get_IP_Addresses is a function which in turns calls GetAdaptersInfo and several other common networking functions like htons, htonl, and ntohl. These latter functions all convert data from big endian to little endian and vice versa because when data is sent over TCP/IP, it is sent in big endian byte order whereas the x86 and x86-64 architectures operate in Little Endian. Thus, the conversion needs to be made at the endpoints for all network transactions. The question now is, why is WanaCrypt0r calling GetAdaptersInfo? According to the Microsoft Developer Network (MSDN), GetAdaptersInfo returns a pointer to this struct:

typedef struct _IP_ADAPTER_INFO {
struct _IP_ADAPTER_INFO *Next;
DWORD ComboIndex;
char AdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
char Description[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
UINT AddressLength;
BYTE Address[MAX_ADAPTER_ADDRESS_LENGTH];
DWORD Index;
UINT Type;
UINT DhcpEnabled;
PIP_ADDR_STRING CurrentIpAddress;
IP_ADDR_STRING IpAddressList;
IP_ADDR_STRING GatewayList;
IP_ADDR_STRING DhcpServer;
BOOL HaveWins;
IP_ADDR_STRING PrimaryWinsServer;
IP_ADDR_STRING SecondaryWinsServer;
time_t LeaseObtained;
time_t LeaseExpires;
} IP_ADAPTER_INFO, *PIP_ADAPTER_INFO;

I’ve bolded a couple members of interest. First, struct _IP_ADAPTER_INFO *Next because this tells us that the data structure is a linked-list. As we can see here, this data structure contains a lot of useful information about the device’s network adapter, such as the adapter’s name and description. However, in this particular case, WanaCrypt0r is interested in the IP addresses that it is using, which are in the IpAddressList member. This is clear because right after calling GetAdaptersInfo, the malware calls inet_addr on the return struct at the locations of the IP addresses. inet_addr converts a string IP address, the way it is stored in the above data structure, to a proper IN_ADDR IP address data structure for usage with the networking protocol. As you probably know, IPv4 addresses look like 127.0.0.1 for example. They are made up of 4 bytes, each byte can represent the number 0-255. The inet_addr function takes a string as input, like the 127.0.0.1 example, and splits the data into number data types so that the networking functions can reference each byte individually, by word (split in two), or as one full unit.

WanaCrypt0r takes these IPs and uses them to attack other computers on the network in the next section. After gathering the IPs, it sleeps for a short while and then starts another thread which runs the below code:

Running the exploit

After sending some test packets to port 445 of other devices and getting positive feedback, it’s game time for WanaCrypt0r to exploit the SMB vulnerability. To do this, run_the_exploit has a bunch more networking functions, but it’s fairly obvious that this is the actual exploit payload because it uses the send network function to send data and when we view this data in the data section of the file, we can actually see the SMB exploit instructions:

“PC Network Program 1.0 Lanman 1.0 Windows For Workgroups” is all part of establishing an SMB connection. This old Informit article actually describes the process in detail and you can see this very step listed under the “Stage Two: Negotiating a Dialect” heading. As far as the actual data used to trigger the exploit, the disassembly looks like a bunch of shellcode but Exploit-DB has an example in C code here.

Summary

To recap what we’ve covered in this post, WanaCrypt0r uses many new threads to probe the network for SMB vulnerability and then exploit it in order to spread to other machines and lock up their files. It does this in addition to the actual ransomware encryption component which we have not looked at yet. However, there are many pieces of ransomware out there such as Cerber, CryptoLocker, and Locky but this SMB exploit is what makes WanaCrypt0r so effective. Luckily, if you had PC Matic SuperShield, you would have already been protected against WanaCrypt0r, but it’s also good to make sure that you keep your software protected by downloading and installing the latest updates. Many times, the updates are released because security holes are found and patched up. Without utilizing these updates, the holes are left open and exploited by the bad guys. Of course the update notifications never appear at the right time, but it’s important to schedule an update during a time when the computer is not being used so that it does get done sooner rather than later. In fact, Microsoft had already released an update which would have completely prevented WanaCrypt0r from spreading if everyone had an up-to-date system. While this is unlikely, we can all do our best to protect ourselves when we understand the importance of updates.
This will end the part of the WanaCrypt0r analysis which introduces the networking/SMB exploit/worm portion of the ransomware. In the next post, we will go over the details of the encrypted, attached resource file where WanaCrypt0r hides some code as well as bitcoin wallet and TOR addresses.