Malware News Ryuk Ransomware: A Targeted Campaign Break-Down

[silversurfer]

Content source

https://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/

Over the past two weeks, Ryuk, a targeted and well-planned Ransomware, has attacked various organizations worldwide. So far the campaign has targeted several enterprises, while encrypting hundreds of PC, storage and data centers in each infected company.

While the ransomware’s technical capabilities are relatively low, at least three organizations in the US and worldwide were severely hit by the malware. Furthermore, some organizations paid an exceptionally large ransom in order to retrieve their files. Although the ransom amount itself varies among the victims (ranging between 15 BTC to 50 BTC) it has already netted the attackers over $640,000.

Curiously, our research lead us to connect the nature of Ryuk’s campaign and some of its inner-workings to the HERMES ransomware, a malware commonly attributed to the notorious North Korean APT Lazarus Group, which was also used in massive targeted attacks. This leads us to believe that the current wave of targeted attacks using Ryuk may either be the work of the HERMES operators, the allegedly North Korean group, or the work of an actor who has obtained the HERMES source code.

In the below analysis we review the highly targeted attacks that Ryuk has been involved in and make a detailed comparison between it and the notorious HERMES ransomware used in other operations. We also address the financial aspects of the campaign and illustrate how, through tracking the money trail, Ryuk’s authors seem to want to disguise their received payments by dividing and transferring them among multiple wallets.

Full Analysis: Ryuk Ransomware: A Targeted Campaign Break-Down - Check Point Research

 

[Libera Milanesi]

@endsecure Very appreciative, kudos to you mate.

 

[Libera Milanesi]

I was doing a bit of evening reverse-engineering on the dropper whilst taking some notes in-case I saw anything which could be addressed by the engineering team (which is my cup of tea) and noticed something the sample is doing on-execution which is really bothering me.

- it has been cleaned up a bit with the naming so it is clearer to read.

It really bothers me that the author of the loader for the ransomware has used LoadLibraryA instead of GetModuleHandleA to get a handle to the Kernel32.dll module. Kernel32.dll will always be loaded under context of the ransomware loader process by default because it isn't a native process only relying on ntdll.dll. There'll be an entry in the PEB's Ldr linked lists. It bothers me because while LoadLibraryA is going to check if the module is loaded under the context of the current process already instead of blindly re-loading it (which means the functionality is still going to work fine), it just makes more sense to use GetModuleHandleA where appropriate.

I know one other person who gets bothered by things like this, but his condition is a lot more severe. He becomes bothered by a lot more. You should see him on a day without coffee.

For those that are interested as to why the sample needs a handle to Kernel32.dll in the first place:
1. Gets a handle to Kernel32.dll module in virtual address space of current process (which is the ransomware loader process).
2. Dynamic import using the handle to Kernel32.dll to find the address of the IsWow64Process routine.
3. If the address can be retrieved, calls it.
4. Sample does all of this to determine if it's running on a 32-bit or 64-bit version of Windows since the loader PE is 32-bit which means on a 64-bit environment it'll be running with Windows On Windows 64 (WOW64) emulation (since 64-bit Windows has a 64-bit kernel so for compatibility it acts as a translation layer (e.g. fix data-types for compatibility among other things).

[1] - Depending on whether the environment is 32-bit or 64-bit, the loader will drop a different PE to disk. It will then execute this dropped PE.

EDIT: [1]

 

[Libera Milanesi]

The ransomware loader is checking whether the environment is 32-bit or 64-bit Windows because it drops a different PE to disk based on this using the WriteFile (Kernel32.dll) routine. It uses the CreateFileW (Kernel32.dll) routine to create the file, and then it writes to the created file with the WriteFile (Kernel32.dll) routine the correct bytes for the chosen PE to drop.

I edited my previous post to mention the dropping to disk.

 

[Libera Milanesi]

@endsecure It really interests me that some vendors failed the Reflective DLL Injection tests when I know a few engineers from certain vendors who can do it themselves with their eyes closed in no time. They need to get that under lock and key ASAP.

Reflective DLL injection is just normal DLL injection except you're replicating the Windows Loader; you're loading the module manually into the targeted process. This also means there won't be an entry of the module in the Ldr list for the Process Environment Block, unless you manually added it there.