Ransomware but as a PowerShell script- Analysing Fileless malware

credit — link

Typically, when we think of getting ransomwared, in most cases, it is either an executable or an elf file, upon running it on your system, it encrypts your data and demands a ransom payment to decrypt your files. But ransomware gangs have changed their entire operating model and are literally forming syndicates and causing global disruption with advanced techniques to encrypt and are investing to get a few zero-days that aren’t disclosed to the vendor.

One such advancement from the ransomware groups that helps them in evading firewalls, Anti-Virus machines, and makes the defender’s life harder is the fileless malware. In the words of McAfee, “Fileless malware is a type of malicious software that uses legitimate programs to infect a computer. It does not rely on files and leaves no footprint, making it challenging to detect and remove.”

Simply put, the attacker gains privileged access to a machine and simply injects his malware into the RAM, and, by default, this technique helps in evading most of the signature and behavior-based Anti-Viruses. This type of attack reduces the chance of detection, but it also makes the defender’s job much harder as most of the programs leveraged during the attack are legit and useful programs like PowerShell and WMI (Windows Management Instrumentation).

This article will look into how I analyzed 2 different fileless malware belonging to Sodinokibi and Epsilon Red groups. Sadinokibi is also known as REvil, and it is one of the notorious ransomware groups that originated in Russia. Unlike Sadinokibi, Epsilon Red is quite a new variant that is known to exploit the infamous Exchange Vulnerability to propagate and disrupt operations.

Sodinokibi Analysis

Our first one is sadinokibi’s fileless malware. In this variant, the attacker runs a PowerShell script that encrypts your files. (Thanks to bazaar.abuse[.]ch for the sample)

File Details:
1. Hash: 3d6d90fcb6a702da3e22008b8f4aff13d9bf86fae17fbac9b9bcef2b46de75a8
2.VirusTotal hits: 14/57 (really bad ig)

In the above-mentioned code, line 15 the huge chunk of code is literally crashing the site. So if you wanna check out the encrypted chunk go to Link.

First the function $vbqiuydiny is defined with variables “$zlpzghgxedzvmhgc $sjpknmnzzxcizfowtjo $dwtugeayovmjwpkyfqy” and you have few more variables calling CyrptoUtil module from System.Security and the encryption used to encrypt the payload is AES-256 mode CBC.

The line dwtugeayovmjwpkyfqy has the encrypted payload and you can see it at -Link (Warning: Uploading the site it might crash so be aware). And below it, you can see the entire payload chunk is decoded from Base64 using System.Convert . Further, you can see 2 more variables being defined with Base64 encoded junk, and if you look at lines 8 and 9 the defined 2 variables are being set as IV and Key for the payload to decode.

Now we have the Key, IV and the encryption mode to decrypt the encrypted payload. You can use CyberChef for decryption, remember to convert your base64 encrypted data to hex or RAW or suffer like my wasting more than an hour figuring out why the decryption won’t work.

The decrypted payload is another PowerShell script that had another huge chunk of data encoded in Hex.

The encoded data is at Line 102, again upon keeping the entire data chunk the site is crashing. So you can follow the following link (Warning: Site might crash). This encoded chunk has been filled with gibberish to overthrow and make the analyst life harder by adding “00 00” or “..” in-between.

In line 107 you can see the variable is converted from hex and the “..” are removed and upon decoding the chunk and removing the “..” as per intended.

Now, all we got was gibberish right? No, if you look at the start of the decrypted payload, from lines 11 to 19 and lines 30 to 39 and function wgwrn we can see some strings are broken down into multiple parts because if anyone tries to perform forensic analysis on volatile (RAM) memory it would make the forensic analyst life a little bit harder.

Main Function wgwrn at line 75 we can see kerenel32.dll is being imported and the VirtualAlloc and CreateThread are being implemented to create a remote process to dump the decoded data directly onto memory and execute it.

So, let’s check if the decoded data has anything interesting and why the script is directly dumping it onto the memory. You can find the decoded data at the following Link. And at Line 12 you can see the “This program cannot be run in DOS mode” string.

You can see the highlighted section has the file header of an Executable “MZ” and upon further searching, you can find “.data” and “.rdata” typically found in an executable. I didn’t extract the executable as this looks like it has been packed using upx packer and in decrypted payload, few more string operations were going on which I had hard to understand what was going on. So, I had to stop there :-(

Summary: REvil used Reflective EXE self-injection type from the fileless malware category. The Executable is highly obfuscated first encrypted using AES and then encoded along with some string manipulation.

Epsilon Red PowerShell script

Unlike Sadinokibi fileless malware attacks, epsilon uses around 12 PowerShell scripts that do anything ranging from Deleting backups, Downloading ransomware executable to Evading detection and executing the ransomware itself.

In our scenario, I got my hands on the script that executes the ransomware that was downloaded by another script that downloads the malware onto a specific disk.

As you can see the at first glance it looks like the script is filled with weird gibberish but we can see some useful strings like Us and ers following it. If we take a look at Line 17, the string $a is going through string manipulation by replacing all the special characters like '[' , ']' , '{}{}-{}{}' and {}{}---{}{} . So, now remove the special characters and we can see the main script.

Now our deobfuscated script looks like the following, with $alpha var with characters in Alphabet except for C as this variable is used to enumerate and execute the malware. Line 6 says that the script searches for volumes Z, Y, etc and checks if the volume exists and then runs the already Downloaded ransomware executable which is stored in the RED folder in the system32 file system and its PowerShell window hidden option.

Unfortunately, I didn't get the remaining PowerShell scripts there were around 12 and the executable. So, couldn't complete the entire analysis but you can see how malware authors and ransomware gangs have adapted the fileless malware which helps them remain silent and leaves little traces or artifacts for the analysts to work on.

The most impressive fileless malware that I analyzed was Sadinobiki’s ransomware PowerShell script that we have just seen at the beginning of the file. The way first it encrypted the main PowerShell script the encrypted payload has the executable hex dump which is then added with junk to obscure the executable, and the executable itself is then packed again.

This particular Reflective EXE self-injection method is used in fileless malware along with the above-mentioned anti-analysis and anti-detection methods.

PS: I am always up for correction and please do give some suggestions that I can work on. Limited by resources(home lab) couldn’t perform dynamic analysis.

Socials to connect: Twitter @krishnasai_456, LinkedIn- Link and GitHub- Link

Stay safe and stay curious!!! Till next time ❤

Thank you ❤

Malware Analysis and Forensics ❤|| In love and hate relation with cryptography || N00b Skiddie || ❤You can bait me with a good cup of coffee ❤