Darkside Ransomware Analysis: Improving Ransomware Protection

The following analysis of the Darkside ransomware was completed by Dataprise’s Cybersecurity Analyst Susan Verdin and originally published May 20 on her blog.

---

MD5: c4da0137cbb99626fd44da707ae1bca8

Sha1: a38e9891152755d9e7fff7386bb5a1bca375bd91

Sha256: 1d4c0b32aea68056755daf70689699200ffa09688495ccd65a0907cade18bd2a

Phase 1: Initial Assessment

Upon extracting, the sample appears to be an executable. Nothing appears to stand out, but one indicator of a malicious file is the file size, which appears to be 61 kilobytes.

Checking the properties of the file, it appears to be signed by a digital certificate. This is often done to make systems believe that the code is not malicious. The digital certificate also appears to be valid. Sectigo is a well-known certificate authority. However, the signer’s name is strange. A quick Google search does not provide much information on the company. The only information that is provided is that it is a private company, but no website, email or phone number shows up.

Next the file is opened within PE Studio. With MD5, SHA1 and SHA256 hashes shown first. If we take the MD5 hash to VirusTotal, it is flagged as malware 47 times out of 70, which is a clear indicator that this file is indeed malicious.

Back into PE Studio, we look particularly at the properties, “first-bytes-hex” and “first-bytes text”. The first four bytes “4D 5A” translate to “MZ” in text. They are introduced inside the file header, which tells the system that this is an executable and should run as such. We can confirm this inside HxD as well.

Back into PE Studio, we look at a list of indicators. The indicators that stand out here are:

• The count of libraries is suspicious
• The count of imports is suspicious
• The file contains self-modifying executable sections
• The file references a certificate

The only library that this executable appears to call is kernel32.dll. Which is defined in the list of libraries. This could tell us that because this code is self-modifying, it may call different libraries later to achieve different goals. Something in the code could trigger it to change and reveal it’s true intentions.

The only import that is brought in by the Import Address Table(IAT) is ExitProcess which is handled by kernel32.dll. This import will take this executable’s running process and terminate it.

There are two types of self-modifying malware. Metamorphic and Polymorphic. In the static analysis later, we can examine the code to determine the type.

As stated earlier, malware will use digital certificates to make themselves appear valid to the OS and will run like a normal executable.

Next, we look at the strings section to see if anything further stands out. the string “CdB” looks interesting. I did a Google search and found that it stands for “Constant Database”, a library and data format created by Daniel J. Bernstein. It acts as an “on-disk associative array” meaning a place that stores certain values. These values can be stored as a single key. A CdB only has two operations, creation, and reading. It is designed to be fast and reliable. Upon further reading, he is also the creator of “Salsa20” a 256 bit stream cipher. This could tell us that there is encryption involved in the sample’s code. In the next lines, we find function“FindNextFile” which is also handled by kernel32.dll. This call comes after “FindFirstFile” or “FindFirstFileEx”. When this function is called, this could indicate that it is looking for a file in order to take a certain action, once returning information about said files. If we go further towards the bottom, we will find more information about the digital certificate, including links, city names, and a possible address.

Lastly, we check to see if this malware is a packed executable, in “Detect It Easy”. A packed executable is an indicator that malware is not only trying to obfuscate it’s code, but also try to evade detection by anti-malware software. In “Detect It Easy”, as click on “Entropy”, we can see that it is 98% packed however, text1 and. rdata are not packed, which indicates that the entry point is inside one of these headers. By getting to the original entry point of the packed executable, we can see if there are more imports or libraries to be found inside.

Phase 2: Dynamic Analysis

When the malware is run, we see that it begins to encrypt everything that it can find on the machine and leaves behind a ransom note.

FakeDNS-NG, a tool for DNS redirection shows us that the ransomware attempted to reach out to the certificate authority and left some strange characters behind, which could be some encrypted data.

RegShot shows us that there were new registry keys created and some were deleted. One was created for the icon and one for the file extension. An icon was saved to C:\ProgramData\ and a certificate was saved to the system’s certificate authority.

Phase 3: Static Analysis

In the first section, we determined that the sample is in fact a packed executable. Again, packing is used as an evasion and obfuscation technique in order to hide from anti-malware software and make analysis efforts more difficult. In this case, I attempted to drop the sample into different PE identifying software and it could not identify the packer. Only the software that compiled the program which appears to be Visual Studio C++ 2015. In this case, we will need to manually unpack the program. The way to do this is to find the original entry point where it begins, then dump the program and rebuild the PE with the new import address table (IAT).

Before I unpack the program, I wanted to see where the encryption began. I moved into the first call instruction, and noticed the instruction, “mov ecx, F0”. This means that the value F0 is moved into the register, ECX. Then, our sample is moved into ESI. In the next instruction, the program wants to move a 32 bit word in EBP with 8 added to the value in EBP, and then EBP’s value is moved into EAX. EAX is going to equal 8. Next, a d-word is stored in EAX and moved into EDX. EDX also equals 8. EBX will equal 4. EDI will equal 8. The value of EAX changes because now 12 is added to 8, which will give us 20. (Salsa20 remember?) In the next three instructions, new values will be stored in EDX, EAX, and EBX. Currently, ESI still holds the malware. ECX still equals F0 which again is 240. 240 + C is 252 because C in hex is 12. This value is now stored in EDX. Then once again, 8 is added to ECX and stored in EAX. This value is 260. And then, finally, adding 4 to ECX gives us 264 and is stored in EBX. Lastly, the value of ECX is stored in EDI. In the next set of instructions, the values are subtracted from the registers. Currently, EDX is storing the value 252. 10101010 equals 170 in decimal. 252–170 = 82. EDX is now 82. EAX is 90. EBX is 94. This algorithm will continue over and over until the sign flag equals 1. Hence the instruction JNS. This is our Salsa20 encryption algorithm as it uses addition on 32-bit words. This is the first part of it. The second part does what is called an exclusive-or, which you will see under the JNS instruction. The XOR, edx, edx instruction sets EDX to equal zero as well as ECX. In addition to this, it appears to carry our 16-bit instructions as well.

After discovering the encryption algorithm, I run the program again and put a breakpoint on the last call before it calls “ExitProcess”. This last call to the program is where the interesting processes happen.

When entering this call instruction, you see multiple calls and jumps to the program. This point I found interesting was this call in particular:

This was the first time I saw a new DLL called. One that was not in our library previously.

According to MSDN, this DLL controls functions and processes in the user environment. This DLL called this function:

For this to be called, CreateEnvironmentBlock had to be called first. That function retrieves environment variables for a specified user, and then can pass to the function, “CreateProcessAsUser”. What this essentially means is that it most likely wants to create a user that it can escalate privileges with if the current user profile is not set as admin. Probably to bypass UAC.

Continuing through the program, the program called function “CommandLineToArgvW” which means it is passing some parameters to the command line. What we do not know yet is what those could be. After it passes those, it loads the DLL, SHCore.dll.

At this point, I returned to that first call where userenv.dll was loaded. I went ahead and marked this point as the OEP and then dumped using Scylla.

After dumping in Scylla, I rebuilt the PE and IAT and loaded the unpacked sample into PEStudio again.

Upon loading into PE Studio, we notice a new signature, “Stranik 1.3 Modula/C/Pascal/”. The malware Trojan.Emotet is packed with this software and was identified as polymorphic, which means we are indeed dealing with polymorphic malware.

Next, we look at the libraries, and we see that all of them are now showing.

In the imports section, we see all the imports that the malware uses.

Right away we can tell it is using Anti-Debugging measures to try and stop us. Some of the functions listed that it uses for this are:

• NtQuerySystemInformation
• NtSetInformationProcess
• NtQueryInformationProcess
• GetTickCount

For Privilege escalation, it appears to query an access token which contains the security properties of an object. In this case it is looking for the user token which has the identity and privilege information needed to authenticate to a particular account. It also looks for the security identifier (SID). If the information on the user account shows that it does not have admin access, it will call “SetNamedSecurityInfoW” to try and take ownership and make the account an admin so that it can bypass UAC.

Darkside will also attempt to look for a domain controller to infect by calling DsGet functions several times. It will also check if the user is part of the domain by calling “NetGetJoinInformation”. If the user is part of the domain, it will look through any network paths and check if they have valid UNC paths. If those conditions are met, it will attempt to traverse the network to spread itself there.

Darkside also can create, start and destroy any services as well as use this to remain persistent on systems.

Lastly, Darkside appears to attempt to start an internet connection, with functions, “InternetOpen, “InternetConnect”, “InternetSetOption”, and “InternetQueryOption”, and also will attempt to reach a certain website by calling “HttpQueryInfo”, “HttpOpenRequest”, and “HttpSendRequest”. It most likely needs to do this to validate its digital certificate as shown earlier and also potentially connect to a C2 server.

Identified MITRE Attack Techniques:

Reconnaissance — Gathering Victim Information

Persistence — Creating Processes

Privilege Escalation — Tampering with access token information and editing security privileges, taking ownership and bypassing UAC

Defense Evasion — Bypassing UAC

Discovery — Domain Trust Discovery, File and Directory Discovery, and Network Share Discovery

References:

https://attack.mitre.org/tactics/enterprise/

https://docs.microsoft.com/en-us/

The Emotet-ion Game (Part 3)

http://www.crypto-it.net/eng/symmetric/salsa20.html

https://cr.yp.to/salsa20.html

https://en.wikipedia.org/wiki/Cdb_(software)

As technology continues to advance, ransomware attackers will continue to find new ways to extract sensitive information from your company, which is why ransomware protection is crucial. It is more important than ever to take preventative measures like cyber program management, and continuous vulnerability management, to ensure rapid response time and minimal damages. At Dataprise, we can help you get a jump start on ransomware protection and risk mitigation with ‘no cost’ IT assessment services for your IT environment.

---

Find out more about Dataprise ransomware protection and prevention below!