WannaCry Analysis and Cracking

Hey guys! I have been planning to this blog post for a while now and today I have finally decided to write about the first Malware Analysis post.

So today we will be dealing with the famous WannaCry ransomware, we will see the common technique of finding out the type of malware + break into how does the actual malware work and try to device a basic guideline for everyone to follow along.

Points to keep in mind

1. PLEASE USE A VM to do your malware analysis
2. To get the password and the zip drop me a text on twitter. ( I don’t want to give it out in public as it might lead to real damage and might be used with malintent).

After extracting the file we see the following.

Raw FIle

Let’s dig in to see what’s up? Before we start we will be using Volatility to play around the memory dumps you can use X number of tools to break into and see how to do things but the idea of this blog post is to understand how does malware analysis work.

So first thing that I usually do is figure out the type of file and the background on the file (eg :- what OS the file was taken from?)

To get the background we can use a simple plugin in volatility

volatility -f <file> imageinfo

That yields us this :-

So before jumping to the tools I wanted to see what exactly this malware affect so I ran a simple strings <file> and realized it has something to do with the task scheduler and there were different python code fragments involved

TaskSch

Now to understand how to break into a dump file a good point to start is usually checking what kind of files and process it was running.

I used pslist another plugin in volatility to check that.

It returned with something really interesting…

0x81fde308 @WanaDecryptor@ 740 1940 2 70 0 0 2017–05–12 21:22:22 UTC+0000

So it was some decryption mechanism to check once malware is kicking.

It can be tough to spot what process does what but another process worth nothing is lsass (Local Security Authority Subsystem Service) which is basically process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.

So you can get lots of juicy information via lsass.

Other than that if you are paying attention you’d know we are interested in

0x82218da0 tasksche.exe 1940 1636 7 51 0 0 2017–05–12 21:22:14 UTC+0000

Because this is the only process lead that we got from our strings.

Now a good way to do things is figure out what was the invoking parent for both of these process, if we find the process that creates the decrypter it’s likely it is the same process that created the locker.

So we used psscan to check the PID and PPID and not surprising at all we see this.

We can see that decrypter and tasksche are related indeed so I planned to drop into looking at what library the both processes used (740,1940)

Now looking at the DLL library used by 1940 and 740

by using volatility -f wcry.raw dlllist -p <PID>

We got the directory and libraries used by both the processes.

Common thing to notice is that they both use the same directory for the execution.

C:\Intel\ivecuqmanpnirkt615\@WanaDecryptor@.exe & C:\Intel\ivecuqmanpnirkt615\tasksche.exe

Looking more closely on few different things we realize that they are running different windows APIs like Secur32.dll to encrypt Ws2_32 to create socket etc.

Now moving into checking into the handles (those of you are unfamiliar with windows API handles are an integer value that identifies a process to Windows.

volatility -f wcry.raw handles -p 1940

We got to know that it is using some sort of mutex.

Importance of mutex :-

It is used to make sure once infected computer doesn’t get infected again to reduce the noise and footprint.

Looking at the mutant MsWinZonesCacheCounterMutexA

let’s google this one up, It quickly nets us it’s wannacry

This is one of the ways to classify the malware (via mutex).

Now let’s keep digging to see what exactly was going on in the background as we saw above in the dll list we saw a library called urlmon.dll from dlllist was also used which is used to invoke browsers to see if there’s any network connection made or command over remote happening.

For this we will use bulk_extractor and put this dump to the pcap.

command used :- bulk_extractor -E net -o pcap /<file>

I was able to find all the IP’s that system tried to connect to while malware was functioning.

Enough background let’s move into the actual code fragment if we could find any and break into the malware.

I planned to pin point a file scan pertaining to

C:\Intel\ivecuqmanpnirkt615\tasksche.exe

By using the following command

volatility -f wcry.raw filescan | grep ivecuqmanpnirkt615

Let’s dump the binary for the files we are interested in :-

Moving on with checking the files (you can also reverse engineer them to understand them better) but I wanted to get a high level view.

We can see the messages via strings.

We can see the background script used

Lets dump the memory now

There we are with mutant execution and some raw code.

After reading dumps I realized there’s even a onion address where the bitcoins were supposed to be given out.

So we started from a raw file saw process + mutex + some code analyzed binary (high level) + broke into crypto libs and finally the onion tor links.

That’s it for today!

Thank you!