Analysis of Sodinokibi Ransomware Variant

Summary

CyOps, Cynet SOC team, recently encountered a new variant of the Sodinokibi ransomware, discovering several interesting traits. In this article we share a detailed analysis.

Sodinokibi Ransomware’s affiliates use a wide range of tactics to distribute the ransomware and earn money. This is shown in a wave of attacks involving the breaching of legitimate websites and replacing of downloaded files with the infected Sodinokibi file, hacking into managed service providers (MSPs) to push Sodinokibi to managed endpoints, and by utilizing spam campaigns for a wide net.

In this case, the Sodinokibi ransomware distributed itself through a phishing email that contained an attachment to lure users to download and open the file containing the malicious payload. Sodinokibi ransomware used a “weaponized” Word document containing VBA macros that act as droppers. The malicious document asks the user to enable macros ). If macros are already enabled, they will execute automatically via AutoOpen function. Overall, the VBA code executes a multi-stage high obfuscation PowerShell script in the attempt to evade AV and security solutions. Additionally, it uses advanced techniques to evade sandboxes.

Fileless attacks such as this have been significantly evolving since 2017 and pose severe challenges to both signature-based and behavioral security tools.

(To learn more how Cynet can help you protect from any type of Ransomware, clickhere)

Investigation Overview

During our investigation, we discovered the following information:

According to the process tree relationship, PowerShell was spawned by WINWORD.EXE that opened a file named “info_17.07.doc”. We discovered the same behavior for another Word file named “VolontariDipendenti-addestramento-congiunto8-12Luglio.doc” and we assume there are more instances of the malicious Office file with different names / hashes.

Once the malicious VBA has been executed, a base64 encoded command was executed through PowerShell.

The decoded command reveals another stage of obfuscation and encoded command:

After decoding the above stage, we received a simple PowerShell code:

The above code attempts to download and execute an executable file named ‘KiLrd.exe’ from malicious URL ‘ hxxp://fcamylleibrahim[.]top/sywo/fgoow[.]php?l=dxclass2.gxl ‘.

The executable file is saved to the User directory folder known as the environment variable as ‘$env:userprofile’ (“C:\Users\user_name”).

We have tried to download the executable file, but unfortunately the malicious URL was not available during the investigation.

The code further attempts to download additional code from another URL: ‘hxxp://185[.]193[.]141[.]248/gs[.]php’:

This code first checks the host’s processor architecture in order to start the right instance of PowerShell (32 bit or 64bit), then it starts the PowerShell process which invokes a relative-long code that resides in an additional URL: ‘hxxps://pastebin[.]com/raw/CY2EEMJN’.

The code turns out to be an Empire module (as explained below) of which the source code is examined in Empire GitHub project:

https://github.com/EmpireProject/Empire/blob/master/data/module_source/code_execution/Invoke-ReflectivePEInjection.ps1

Empire is a post-exploitation framework that includes a pure-PowerShell2.0 Windows agent, and a pure Python 2.6/2.7 Linux/OS X agent. It is the merging of the previous PowerShell Empire and Python EmPyre projects. The Empire framework offers cryptologically-secure communications and a flexible architecture. On the PowerShell side, Empire implements the ability to run PowerShell agents without needing powershell.exe, rapidly deployable post-exploitation modules ranging from key loggers to Mimikatz, and adaptable communications to evade network detection, all wrapped up in a usability-focused framework.

The attackers use the module above in order to reflectively load a DLL file (that turns out to be  ransomware) into the PowerShell process, the DLL is loaded from memory and not from the disk. This is known as an evasion technique to bypass the Anti-Virus software.

The attackers created a byte array containing the malicious DLL file that reflectively loads and hardcodes the byte array into the script. One advantage of doing this is that they can encrypt the byte array and decrypt it in memory, which bypasses Anti-Virus engines.

This is a small part from the Empire script of the attackers, it is a DLL encoded in base64 and converted to a byte array:

Once this module is running with PowerShell, the malicious DLL executes itself within the PowerShell process memory and encrypts the files of the infected machine, and then drops an instructions file in order to ask the user to pay ransom for decrypting the encrypted files.

This ransomware places ransom messages in folders that contain encrypted files. The name of the text file depends on the extension added to the encrypted file and are generated randomly.

For example, if the extension is “. qv 05z ” the ransom message filename will be called “ qv05z -readme.txt “. Sodinokibi also changes the Desktop wallpaper.

The ransomware encrypts the files and changes the desktop wallpaper, also dumping a txt file for instructions on how to pay the ransom for decrypting the files, as you can see in the screenshots below

Attack Flow

Here you can see the process tree when the PowerShell command has executed:

We can see that the vssadmin.exe process spawned by cmd.exe in order to remove shadow copies of the files disables Windows recovery and repair functions at the boot stage, using the command:

C: \ Windows \ System32 \ cmd.exe “/ c vssadmin.exe Delete Shadows / All / Quiet bcdedit / set {default} recoveryenabled No & bcdedit / set {default} bootstatuspolicy ignoreallfailures

This variant of the ‘Sodinokibi’ ransomware is new around the network and we can see that the creation time is from the last week. It is also new in VirusTotal:

Summary of IOC

• SHA256 :

c20e4249716805ab2c8645de65874797a2671ae16a30b9f1625ceb5f4bdd3ae6 – DLL FILE

• Network IOC:

IP address : 185.193.141.248

URL :  hxxp://185[.]193[.]141[.]248/gs[.]php

hxxp://fcamylleibrahim[.]top/sywo/fgoow[.]php?l=dxclass2.gxl

Domain :  fcamylleibrahim[.]top

• File Location:

“C:\Users\user\KiLrd.exe”

Cynet Detection and Protection

This type of attack was detected and blocked by Cynet using several detection mechanisms: