WannaCry P1 - Detection & Analysis in Memory

Hello all, welcome to the first part of wannacry detection, analysis from forensics perspective .

WannaCry is ransomware that started its attacks in 2017 targeting Microsoft windows machines and cost the world a lot of money.

I decided to do a full analysis of this malware to sharpen my forensics and malware analysis skills .

the malware main attack is encrypting data, but there is another attack I didn’t cover in my analysis because it targets the SMB in some windows server so it can spread through the network, to do this attack it used an exploit called Eternalblue , also the domain that the malware used to download the executable that does this attack did not respond

Lab Setup

I used windows7X64bit / 500MB RAM on VMware to run the malware sample and allowed it to communicate over the network without using a fakedns or fakenet, then I suspended the vim after 3 minutes of execution .

hero Volatility for analysing the memory .

sample hash : 84c82835a5d21bbcf75a61706d8ab549

if you want to try your self you can set up your lab or you can skip the setup part and use my memory_dump .

DumpLink

dump md5 hash : 8ab0198a80acf83780a47a5f3882eb03

Investgating

I use volatility2 so I have to check the image info to get the profile I don’t have any intentions to move to volatility 3

the image info is Win7SP1x64

Process check

I use volatility psxiew so if there were any kind of hidden processes or rootkits, it can be detected

nice, no need to pay effort in finding hidden processes or check process threads to find the malware, we can read the processes names and realize the names of the malware processes, we are not sure for now those are all malware processes but we can be sure that those processes are related to the malware.

the processes are not hidden, but there are some terminated processes, so I will use the psscan to map processes to there parents. then i’ll use the dot tool to view it in graphical view

vol.py -f wanncry.vmem --profile Win7SP1x64 psscan --output dot --output-file psscan.dot

dot -Tpng psscan.dot -o psscan.png

the tree is very large, so we need to zoom in the explorer.exe part as we can find the Wannacry.EXE is a child to explorer.exe

wannacry opened another processes taskdl.exe and 2 ‘@WanaDecryptor’ one of them opened process ‘taskhsvc.exe’

we can notice process 2752 which is @WanaDecryptor opened 28 seconds later than the other one.

also, there is a terminated taskdl.exe process in ‘2021-02-22 17:52:52’

so I will check actions for processes 2464, 2752, 2092, ( 2084 is terminated so the expectation is we can’t find too much information )

Privileges

after we discovered the malware processes, we can start by checking the privileges for each one focus on the enabled only.

vol.py --plugins=my_plugins -f wanncry.vmem --profile Win7SP1x64 privs -p 2464,2752,2092 | grep Enabled

it looks there are no important privileges enabled

we need to check the privileges of 2084 also, as its a terminated process we need to specify the memory offset instead of the process id.

vol.py --plugins=my_plugins -f wanncry.vmem --profile Win7SP1x64 privs --offset=0x000000001e77d2d0

but there is no information available, as expected a very large part of its pages may be used for another process or paged in the disk.

to be sure of what happened to it we can do a pool scan

Pool Object Scan

scanning object types is very useful because it gives a flag about each data type location, if it was paged in disk or not, so if we didn’t find some information about nonpaged objects, that means there is something wrong.

the process is not a paged object. so it means that some pages of process 2084 are used on anther process and overridden

Handles

we didn’t find useful information in processes privileges, so we will check each process handles.

the important handles are files, keys, mutex then we will check the vads if we found any kind of process injection we can go back to handles and follow the threads.

Process 2464

Files

vol.py --plugins=my_plugins -f wanncry.vmem --profile Win7SP1x64 handles -p 2464 -t file

as you can see this process opens several file handles, and there are 2 interesting files 00000000.eky which is located on the desktop, in the same path as with the executable. hibsys.WNCRYT this file is located in temp and looks interesting, it doesn’t look like the encrypted files (the encrypted once ends with )

we can dump those files and check the content for any information

Key

vol.py -f wanncry.vmem --profile Win7SP1x64 handles -p 2464 -t key

I don’t know the function for each key so I can’t decide which key shouldn’t be used or why it used each key.

so the best thing to do is to search all the process to find which process use every single key if we found the key used is not used by any other processor used by all the malware process only or mutual between the malware and important system process, then we can search for the key function and decide is this bad activity or not.

note: as we saw in the object pool scan keys are paged pool objects so we can’t find all the keys resident in memory, some time I will back to the life system to analyse key values, or to understand the key purpose

every key described with safe means the exe use them to get system information.

• IMAGE FILE EXECUTION OPTIONS : is safe

• VERSIONS : is safe

• SESSION MANAGER : is safe

• MACHINE : is safe

• CUSTOMLOCALE

it seems to a safe key, as NLS contains some default keys for the system but it can be a remarkable key for the malware processes, as those processes are the only processes that use this key

 vol.py -f wanncry.vmem --profile Win7SP1x64  handles -t key | grep  'CONTROLSET001\\CONTROL\\NLS\\CUSTOMLOCALE'

but we can’t get the key values as this hive is resident in memory

so I went back to the machine and look at the key-value but the key doesn’t have any values

• PROPERTYBAG

there are 3 keys but located in different hives .

those keys contain some information about the directories on the system.

as expected those keys hives are not resident in memory.

and the malware use keys that map to folders “Common Documents”, “Personal”, “Desctop” and 2 keys point to another key map to “DocumintsLiberary”.

• APPCOMPATFLAGS

nothing interesting on this key also it’s used by many other processes.

Mutannt / Mutex :

vol.py -f wanncry.vmem --profile Win7SP1x64  handles  -p 2464 -t mutant 

mutex is very important evidence in wannacry case

we cant view all mutexes because its a disk paged objects like keys

but we have the important part her

As you can see, this process uses 2 unique mutexes which are not known on windows.

Note: in 2017 the DFIR teams used those mutexes to stop wannacry form encrypting data, running PowerShell script to create mutexes with the same name, then they implemented it in some of the very first tools to stop wannacry.

Process 2752

like what we did in process 2752 we will investegate each process

File

vol.py -f wanncry.vmem --profile Win7SP1x64  handles  -p 2752 -t file 

the interesting files objects are :

• odbcint.dll.mui

which is related to odbcint.dll , and it can be used to provide database reading/writing APIs

• MFC42.dll.mui

this dll is related to Microsoft visualStudio, so that means at least this part is written using Microsoft Visual C++ , it can be obfuscated or packed.

• StaticCache.dat

it uses this file to load a font so this may be the process that displays the message

Key

vol.py -f wanncry.vmem --profile Win7SP1x64  handles -p 2752 -t key

there are many keys like its parent “Wannacry.exe”.

it has many NLS keys, this may because it needs some information about the local machine time,…., etc. remember this is the process that counts the time of payment.

the new keys are

• PROTOCOL_CATALOG9, NAMESPACE_CATALOG5

those keys are related to windows sockets and network connection, but this process doesn’t look like it started a network connection, as there are no handles to any network file to setup the sockets.

Mutant / Mutex

this process has only one mutex but it looks like it’s paged to disk

Process 2340

this process is the same executable as the 2752 process but it looks like it has some differences in behaviour , so i will cover only the differences

Files

as you can see there are 2 new files handles.

• Endpoint , AsyncConnectHlp :

those 2 handles are very important to establish a network connection.

so we can assume this process is doing a network connection, we will be sure when we come to the network part.

also this process can be the one that shows the encryption message, but when you do a live dynamic analysis of the malware you can see the message box appear after 30~60 second from starting the dropper, but for this process, it starts after 5~10 second, so it can’t be the message box process, we can also check the windows output for the 2 processes and the process that set to the default output strings is not the encryption message process.

vol.py -f wanncry.vmem --profile Win7SP1x64  windows -p 2340  | grep Name:

vol.py -f wanncry.vmem --profile Win7SP1x64  windows -p 2752  | grep Name:

the time is set in this process so this is the message box process.

Key

all the keys are the same as the 2752 process

Mutant / Mutex

also this process has only one mutex but it looks like it’s paged to disk .

Process 2092

File

• Endpoint , AsyncConnectHlp

this process has a network and sockets files handles more than the previous process.

• R000000000006.clb looks to be an interesting handle but unfortunately, this is a system file used by many processes, so for now we cant say it dropped or a harmful file.

• Roaming\tor\lock

this is the real interesting handle, as the process uses some files from tor . but wait, the machine didn’t have tor installed. it may be a dropped file, or just this is a file folder called tor located in the Appdata folder.

we will try to extract this file and check this folder but in other section.

Key

there are no interesting or new keys.

just the same as process 2464, also it has the network key.

also this process has 3 mutexes but it looks like it’s paged to disk .

Network

from the previous part, we know that the malware has 2 processes that connect throw the network 2340, 2092.

2340 connections

vol.py -f wanncry.vmem --profile Win7SP1x64  netscan | grep  2340

this process establishes a connection to the localhost on port 9050, it looks like searching for something related to the exploitation or just checking something.

2092 connections

vol.py -f wanncry.vmem --profile Win7SP1x64  netscan | grep  2092

nice, as you can see, this process is listening to port 9050, so the private connection was to this process.

also, it dose some connections to the localhost in different ports.

then it starts to send requests to 5 is (each time those ips are different or at least 3, 4 of them ), the only evidence we have to clarify those connections this behaviour is the tor path on AppData folder, if it was the internet application then it means those connections happened to an onion domain so the route is different almost every time.

The Connected IPs

• 94.130.200.167:443
• 51.81.93.162:443
• 83.212.99.68:443
• 204.11.50.131:9001
• 82.149.227.236:9001
• 131.188.40.189:443

Note: anyway the domains of wannacry aren’t working now.

Dlls Scan

we need to list all of them , as it may help to discover which API does the malware use or any strange dll used.

2464 WannaCry.EXE

vol.py -f wanncry.vmem --profile Win7SP1x64   dlllist  -p 2464

nothing is interesting in those Dlls, it uses only the system DLLs. also, it contains the exe on the virtual base address 0x400000, with a size of 0x3d000, which means the exe is divided into 61 pages, we hope to find it all in the memory vads.

2340 WannaCry.EXE

vol.py -f wanncry.vmem --profile Win7SP1x64   dlllist  -p 2340

nothing is interesting for now in this processes dlls

2752 WannaCry.EXE

vol.py -f wanncry.vmem --profile Win7SP1x64   dlllist  -p 2752

nothing is interesting for now in this process dlls, it is the same as the other 2340 except it has a cmd argument **co**

2092 WannaCry.EXE

vol.py -f wanncry.vmem --profile Win7SP1x64   dlllist  -p 2092

those are an interesting process dlls , it’s not using only the system DLLs, but also it used some other dlls located on the desktop on the same path where the dropper is, in a folder called TaskData. it looks like this folder is one of the dropped data.

Markable dlls used

• zlib1.dll : it needs this dll in doing compression or decompression (or some kind of unpacking resources ).

• SSLEAY32.dll : it needs this dll for communication as it was sending requests to ips on port 443.

the other dlls used in encryption, we will look into it in the analysis part because it will take too much to identify each dll used methods and its functions

we can count all those dlls on the Taskdata path part of the IOCS.

we can list all the files on this path and count it with the IOCs, all thesis file are dropped from the malware…

vol.py -f wanncry.vmem --profile Win7SP1x64  filescan | grep -i "Desktop\\TaskData"

unfortunately those files objects are not resident in memory

let’s look at the AppData Roaming path if we can find any valid information there.

vol.py -f wanncry.vmem --profile Win7SP1x64  filescan | grep  "AppData\\Roaming"

but unfortunately, there is no important data except the path we got before.

let’s try to go back one folder and search in all AppData folder, may the malware dropped anything there also.

vol.py -f wanncry.vmem --profile Win7SP1x64  filescan | grep  "AppData"

nice, in the local/temp folder there are many folders with extension WNCRYTows and contain file .db

great, there are a lot of databases related to wannacry, the prefix of folders can be used as an IOC , also the file hibsys.WNCRYT

Advanced Persistence

before diving into vads I check some registry keys and check the run key for the user who started and opened the dropper, and guess what I found the malware registered himself on the registry so it will be autorun every time this user login.

the key name is : gvwcegcjpglxe848

but you know nothing is called luck, but always there’s WHY.

so I decided to trace this action following the time.

unfortunately, the timeline didn’t give me valid information about how did happen, so i wrote a plugin to trace the changes on registry keys.

GetLastModKey

then I used it to list all the registry key changes from the start of wannacry.exe to the end

vol.py --plugins=my_plugins -f wanncry.vmem --profile Win7SP1x64 getlastmodkey -t '2021-02-22 17:52:20'

then I found 2 important information instead of one.

the malware creates a new registry called WanaCrypt0r contains one key wd

vol.py -f wanncry.vmem --profile Win7SP1x64 printkey -K "Software\\WanaCrypt0r"

it points to the desktop or the location of wannacry.

we can check if this key injected or used by another process or not.

vol.py -f wannacry.vmem --profile Win7SP1x64 handles -t key | grep WanaCrypt0r

nice, there is no process used it , which mean this keys is prepared for another process that will be downloaded or unpacked if the system was valuable or the domain replied.

the second part is, the malware edited the registry key somehow in the same second that taskdl.exe terminated on, it may be related to this edit, or cleared the memory so there will be no evidence for this change except if you called all the keys.

anyway the vads will help us to collect all missing information.

Diving in VADs

VADs will provide us with very important information, by checking them for process injection or even getting data from process memory and heap.

Heaps

unfortunately, we can’t directly use the volatility plugin heaps so we need to check the process headers for _PEB then get the heap number for the process then we can get each heap location and extract the corresponding VAD.

note: we will not extract all process vads, so it will be easy for us to search for some information as doing this process for all vads including dlls vads will be hard , but for checking processes heaps we can extract the heaps one by one .

Processes 2464

we need a volatility shell for this session

vol.py -f wanncry.vmem --profile Win7SP1x64 volshell -p 2464

then we need to get the number of heaps :

proc().Peb.NumberOfHeaps

and there are 2 heaps only.

then check the process heaps array of pointers.

H_Pointer = proc().Peb.ProcessHeaps

now get the 2 pointers by jumping to the array location and count 8 bytes for each one.

H1  db(H_Pointer , 8 )
H2  db(H_Pointer+8 , 8 )

now we will extract only those 2 heaps

vol.py -f wanncry.vmem --profile Win7SP1x64 vaddump -p 2464 -b 0x360000 -D vadDump2464/

this one doesn’t contain important strings, it looks like environment variables .

vol.py -f wanncry.vmem --profile Win7SP1x64 vaddump -p 2464 -b 0x10000 -D vadDump2464/

also, this seems to contain environment vars, and some information about its child, we already know

Process 2340

it may contain any information as it did kind of network connection.

we will do the same as before you just need to move to this process object header, you can use **cc(pid = 2340 )** or use the offset

and 2752

the same it has 2 heaps with no important information like before

Process 2092

it’s our last hope process

nice this process contains 3 heaps, so we hope to find something.

vad 0x10000 and 0x420000 looks like last process except than 0x420000 contains some process names

but 0x20000 contains a strange message, looks like a log message.

now we are done with heaps with no valid information except this message.

Search in VADs

now we will extract the VADs, and try to narrow our search so we can extract only the VADs with protection level PAGE_READWRITE

but before extracting the vads lets search for any kind of dll injection.

for that, we can use **ldrmodules** so we can check all dlls linking.

vol.py -f wanncry.vmem --profile Win7SP1x64 ldrmodules -p 2464,2340,2092,2752 | grep False

the only one that looks injected are that **dll.mui** but by searching for the **mui** the results said this file is specialized for each process and each mui is not used by another process, so we can say it’s not a kind of dll injection.

now time to extract what we can extract from vads data for malware processes.

Process 2464

vol.py -f wanncry.vmem --profile Win7SP1x64 vaddump -p 2464 -D vadDump2464/

this process is the one that is responsible for creating the registry WanaCrypt0r due to the creation time, there was no process except this dropper. also, it may be responsible for adding to the run key, and it was true we may be not able to find any evidence for the WanaCrypt0r key as it’s very careful about registry keys.

we can start by searching for key modification by searching all vads using the path of the key.

grep -l 'Software\\WanaCrypt0r'  vadDump2464/*

as expected, there is no information about it.

so we can search for any information about the Run key, using the same way or by using the key name.

grep -l 'Windows\\CurrentVersion\\Run'  vadDump2464/*

it’s found in 3 vads.

strings vadDump2464/WannaCry.EXE.1e79db30.0x0000000000900000-0x00000000009fffff.dmp vadDump2464/WannaCry.EXE.1e79db30.0x0000000002b80000-0x0000000002c7ffff.dmp vadDump2464/WannaCry.EXE.1e79db30.0x0000000010000000-0x000000001000ffff.dmp | grep 'Windows\\CurrentVersion\\Run'

it opened cmd to start reg and add the key (cmd were not found on the processes )

by taking a quick look at those 3 vads we can find those interesting information.

it seems to use AES and save something related to it in the dky file.

also, it seems to be creat some shell script

there are some strings with .wnry at the end, it may be the configuration files or some important files related to the malware

it uses taskkill to end some processes like databases instance.

and we will find this great information, a 5 onion domains, followed by the like to tor project. this process is the dropper, so all this data were packed inside it, and it dropped the domains and like to be used by the other processes.

the last thing you will find is the names of the files, one of them were on the handles of the processes.

Quick static analysis to the binary :

we can find the binary of the exe on vad 0x400000, we need only to check some strings from it.

strings vadDump2464/WannaCry.EXE.1e79db30.0x0000000000400000-0x0000000000759fff.dmp

you can notice some .wnry and .exe

so let’s grep all exes and wnry file names from this process bin.

the wnry looks to be the configuration files and message in many languages.

and some exe names that are hardcoded in the bin.

also by doing a quick skimming to the strings you can see this interesting part.

we already know about the encryption part and cmd usage.

the new thing is the 3 strange strings, one of them is the bitcoin address the show on the decryption message, so we can assume that the 3 are bitcoin addresses.

icacls , attrib: it looks to be searching for hidden files and permissions, and also hide something or try to hide something.

WNcry@2ol7: this is not looking like a random string, it may be the password for the protected packed files.

Process 2340 .

for this process, we can start by extracting vadinfo to get all the vads with protection level PAGE_EXECUTE_WRITECOPY.

don’t forget to get also the executable vad which is in vad 0x0000000000400000.

we can start by doing this kind of static analysis to the bin.

vol.py -f wanncry.vmem --profile Win7SP1x64  vaddump -p 2340 -b 0x0000000000400000 -D vadDump2340/

it uses the languages wnry files, that had been dropped.

also, it tries to remove the VSS.

those are the interesting parts in the bin vad.

by checking the other vads there are only 2 vads that had valid information 0x0000000000090000, 0x0000000000600000, you can find some information we already know like the onion domains, bitcoin addresses and some encryption APIs.

process 2752 is typically the same as 2340 except 2752 had some extra values set like the start and end time of the 7 days.

Process 2092

from all information, we found we can say that this process is typically a tor process, but with different names.

it includes some RSA keys and ips also some strings to mention that this is a tor project process.

the string we found on the heap was a kind of check state string.

also , we can find some requests that had been sent on vads 0x00000000037f0000 and 0x00000000041d0000 .

IOCS

we had found very useful information we can count some of them as IOCs at least for this part.

Mutex

• MsWinZonesCacheCounterMutexA
• MsWinZonesCacheCounterMutexA0

Registry

• creat : Software\WanaCrypt0r
• add to : SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the value path\to\tasksche.exe

Files

most of the files are not memory resident so we can’t depend on its hash, we can just get the dropped files name for now.

• c.wnry
• t.wnry
• b.wnry
• r.wnry
• s.wnry
• t.wnry
• u.wnry
• msg/m_bulgarian.wnry
• msg/m_chinese (simplified).wnry
• msg/m_chinese (traditional).wnry
• msg/m_croatian.wnry
• msg/m_czech.wnry
• msg/m_danish.wnry
• msg/m_dutch.wnry
• msg/m_english.wnry
• msg/m_filipino.wnry
• msg/m_finnish.wnry
• msg/m_french.wnry
• msg/m_german.wnry
• msg/m_greek.wnry
• msg/m_indonesian.wnry
• msg/m_italian.wnry
• msg/m_japanese.wnry
• msg/m_korean.wnry
• msg/m_latvian.wnry
• msg/m_norwegian.wnry
• msg/m_polish.wnry
• msg/m_portuguese.wnry
• msg/m_romanian.wnry
• msg/m_russian.wnry
• msg/m_slovak.wnry
• msg/m_spanish.wnry
• msg/m_swedish.wnry
• msg/m_turkish.wnry
• msg/m_vietnamese.wnry
• AppData\local\Temp\hibsys.WNCRYT
• 00000000.eky
• 00000000.pky
• 00000000.res

Executable

• taskhsvc.exe
• tasksche.exe
• @WanaDecryptor@.exe
• taskdl.exe
• taskse.exe

Dropped Dlls

• zlib1.dll
• libeay32.dll
• ssleay32.dll
• libssp-0.dll
• libevent-2-0-5.dll
• libgcc_s_sjlj-1.dll

File Handles

• Windows\SysWOW64\en-US\MFC42.dll.mui
• Windows\SysWOW64\en-US\odbcint.dll.mui
• Users\user\AppData\Roaming\tor\lock
• Windows\SysWOW64\en-US\KernelBase.dll.mui

Folders

• the\same\path\TaskData
• Users\user\AppData\local\Temp"number”.WNCRYTows

Domains

• gx7ekbenv2riucmf.onion
• 57g7spgrzlojinas.onion
• xxlvbrloxvriy2c5.onion
• 76jdd2ir2embyv47.onion
• cwwnhwhlz52maqm7.onion

Bitcoin wallet addresses

• 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
• 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
• 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

Other Strings and Commands

• icacls . /grant Everyone:F /T /C /Q
• attrib +h .
• WNcry@2ol7

Conclusion

wannacry is ransomware that encrypts the user files on the machine, then asks for 300$ in bitcoin that increases to 600$ after 3 days, and if the victim didn’t pay in 7 days the data will not be retrieved.

the malware starts execution by dropping some files that are packed inside it, those files contain configuration files encrypted in wannacry form, and a bitmap image to set to the background also dropped some dlls that will be used by some of the executables that had been dropped .

Tor is one of the dropped files, it will use its communication to reach some onion domains that are kind of the controllers.

on the same time it checks the states of the system files to find which are hidden and which are not, check the file permission to get all these user files then start to encrypt them.

and it can delete the VSS at some point , we can assume it does that after the end of 7 days end, so it makes your data unrecoverable.

the dropper starts some of the executables that had been dropped like @WanaDecryptor@.exe.

also, the registry takes a part of the cake, and a new registry is added with key-value points to the dropper path and some persistence to do some action, so it can start whenever the user logs in again, by adding one of the dropped executables to a new run key.

in parallel, it starts to search the network for the DHCP server, then starts to search it for eternalblue exploit, so it can spread throw the network.

in the end, it shows the famous decryption message by @WanaDecryptor@.exe asking the victim to pay and display one of 3 bitcoin wallet addresses.

and you have the choice between losing your data or losing your money and data.

THANK YOU FOR READING , I hope you all enjoyed