Wanna Cry Ransomware — A Hacker’s Perspective (Part 1)
Hey guys! I have been planning to write this blog post for a while now and today I have finally decided to write about the first Malware Analysis post.
Wanna Cry is a ransomware worm that spread rapidly through across a number of computer networks in May of 2017.
After infecting a Windows computers, it encrypts files on the PC’s hard drive, making them impossible for users to access, then demands a ransom payment in bitcoin in order to decrypt them.
A number of factors made the initial spread of Wanna Cry particularly noteworthy: it struck a number of important and high-profile systems, including many in Britain’s National Health Service; it exploited a Windows vulnerability that was suspected to have been first discovered by the United States National Security Agency; and it was tentatively linked by Symantec and other security researchers to the Lazarus Group, a cyber crime organization that may be connected to the North Korean government.
Who was behind the attack?
The attack used Eternal blue, the name given to the software vulnerability in Microsoft’s Windows operating system, and works by exploiting the Microsoft Server Message Block 1.0. The Server Message Block is a network file sharing protocol and allows applications on a computer to read and write to files and to request services’ that are on the same network.
Ironically, it was allegedly developed as a cyber-attack exploit by the US National Security Agency. Although they were reported to have known of the tool’s vulnerabilities, the NSA didn’t bring it to Microsoft’s attention until the hacker group called Shadow Brokers leaked Eternal Blue to an obscure website.
Further analysis of the attack by companies such as Symantec revealed links to the Lazarus group who in turn have been linked to North Korea although the attack does not bear the hallmarks of a nation-state campaign.
What caused the attack?
On Tuesday, March 14, 2017, Microsoft issued a security bulletin, which detailed the flaw and announced that patches had been released for all Windows versions that were currently supported at that time. The Department of Health was warned about the risks of cyber-attacks on the NHS a year before Wanna Cry and although it had work under way it did not formally respond with a written report until July 2017.
At the time of the attacks, the NHS was criticized for using outdated IT systems, including Windows XP, a 17-year-old operating system that could be vulnerable to cyber-attacks. In an unusual move, Microsoft released a Wanna Cry patch for unsupported systems such as Windows XP which Microsoft stopped supporting in 2014.
The NHS had not rehearsed for a national cyber-attack it was not immediately clear who should lead the response. There were problems with communications because emails were either infected or shut down to prevent the ransomware spreading. It’s clear that the disaster recovery plan at the time had not accounted for a cyber-attack of this scale nor were there communication contingencies if the main network was inaccessible. There was no clear relationship between trusts infected by Wanna Cry and the quality of their leadership, as rated by the Care Quality Commission.
- Each infection generates a new RSA-2048 key pair.
- The public key is exported as blob and saved to “00000000.pky”.
- The private key is encrypted with the ransomware public key and saved as “00000000.eky”.
- Each file is encrypted using AES-128-CBC, with a unique AES key per file.
- Each AES key is generated CryptGenRandom method.
- The AES key is encrypted using the infection specific RSA key pair.
The RSA public key used to encrypt the infection specific RSA private key is embedded inside the DLL and owned by the ransomware authors.
Bitcoin Ransom Addresses
Below mentioned addresses were hard coded into the malware.
Encrypted File Format
typedef struct _wc_file_t
char sig[WC_SIG_LEN] // 64 bit signature WANACRY!
uint32_t keylen; // length of encrypted key
uint8_t key[WC_ENCKEY_LEN]; // AES key encrypted with RSA
uint32_t unknown; // usually 3 or 4, unknown
uint64_t datalen; // length of file before encryption,
obtained from GetFileSizeEx
uint8_t *data; // Ciphertext Encrypted data using
AES-128 in CBC mode
Before proceeding with the code analysis I wanted to have a look at the metadata of the file as this gives out a lot of valuable information which can be beneficial in the later analysis. I always prefer to first look at the strings before deeply analyzing any malware sample. Some of the interesting strings that I found during analysis are mentioned below:
Windows 2000 2195
Windows 2000 5.0
Windows 2000 2195
Windows 2000 5.0
Microsoft Base Cryptographic Provider v1.0
%s -m security
cmd.exe /c “%s”
icacls . /grant Everyone:F /T /C /Q
attrib +h .
I quickly navigated to my isolated machine FlareVM, and with the help of a tool called PEiD I found out that the dropper is compiled with Microsoft Visual C++ and is having a Windows 32-bit subsystem. So, our sample here is not packed.
Moving ahead and identifying what interesting information we can get from the headers of our sample file we can use a tool called PEStudio which gave me pretty interesting information about the headers and metadata of sample. There were a couple of interesting things to note though. We can see that the sample is imitating as a legitimate Microsoft Disk Defragmenter file from Microsoft but the actual filename is specified as “lhdfrgui.exe”.
Another interesting thing to note is the Resource section of the sample which is marked as executable. Malware authors basically hide their extra executable in the resource section. And this is what we found here in this sample. The name of the resource is 1831 and can be confirmed that it is an executable file by looking at the first-byte-text field column which is MZ in ASCII.
With extra executable embedded in the resource section, we can assume that it will be dropped later during the execution of malware and more evil things will be done to the system.
When the WannaCry dropper is executed, it first makes an attempt to connect to the domain http://www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com and checks whether a domain is registered and successful connection to the domain is made or not. If the connection is successful the malware terminates itself. And if the connection to the domain fails then it proceeds with infecting the targeted system.
The dropper does this by checking several arguments being passed to the API calls and if it hits the ZF=0 then it proceeds with the initial infection. The important point to note here is how the malware opens a connection to access the Internet. “dwAccessType” set to 1 means it should bypass any proxy that is configured to access the Internet. So, any machine which is only allowed to communicate to the internet through a proxy will also affect those systems if it is hit by a WannaCry.
The malware then checks for 2 arguments “-m security” before proceeding to which step to take further. This is because if the malware is launched for the very first time on an infected machine then it goes ahead with creating a new service called “mssecsvc2.0” with the two command-line arguments mentioned above. But if it is started without the mentioned arguments, then it skips the service creation step and goes ahead with propagating to the network by exploiting SMB vulnerability.
Next, on the way to performing its initial infection, the malware identifies the name of the target machine and opens up a Service Control Manager and creates a service named “mssecsvc2.0” having a display name as “Microsoft Security Center (2.0) Service” and finally starts a service.
The dropper then locates the embedded resource named R1831, which we saw earlier during static analysis, loads it into memory and writes the contents of that resource to a file at “C:\Windows\tasksche.exe” and moves the contents of that file to a new file “C:\Windows\qeriuwjhrf” if it already exists. If it doesn’t exist then it simply copies the contents to “C:\Windows\qeriuwjhrf”.
The file “tasksche.exe” is basically an encrypter that starts encrypting the files in the backend as soon as it is launched.
The newly created file is then dropped to the specified location and is launched by calling “CreateProcessA”. The file being launched is a console application that will run without any window being seen to the user.
That’s it for today…
See you folks in the next article.