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
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 .
dump md5 hash : 8ab0198a80acf83780a47a5f3882eb03
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
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 )
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
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.
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
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
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
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”.
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.
like what we did in process 2752 we will investegate each process
vol.py -f wanncry.vmem --profile Win7SP1x64 handles -p 2752 -t file
the interesting files objects are :
which is related to odbcint.dll , and it can be used to provide database reading/writing APIs
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.
it uses this file to load a font so this may be the process that displays the message
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
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
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.
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 .
- 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.
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.
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 .
from the previous part, we know that the malware has 2 processes that connect throw the network 2340, 2092.
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.
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
Note: anyway the domains of wannacry aren’t working now.
we need to list all of them , as it may help to discover which API does the malware use or any strange dll used.
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.
vol.py -f wanncry.vmem --profile Win7SP1x64 dlllist -p 2340
nothing is interesting for now in this processes dlls
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
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
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.
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
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.
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 .
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 :
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
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
the same it has 2 heaps with no important information like before
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.
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.
you can notice some .wnry and .exe
so let’s grep all exes and wnry file names from this process bin.
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.
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 .
we had found very useful information we can count some of them as IOCs at least for this part.
- creat : Software\WanaCrypt0r
- add to : SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the value path\to\tasksche.exe
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.
- msg/m_chinese (simplified).wnry
- msg/m_chinese (traditional).wnry
Bitcoin wallet addresses
Other Strings and Commands
- icacls . /grant Everyone:F /T /C /Q
- attrib +h .
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