Reading Time: 8 minutes

Ryhsida is a ransomware gang that became famous starting from May 2023 after being correlated to a series of high profile cyber attacks in west Europe, north an south America and Australia. The group seems to be linked with the known Threat Actor “Vice Society”.

The team takes his name from a centipede species called Rhysida, this specific kind of insect is the second largest genus in the subfamily Otostigminae, with species found in the Neotropics, Indo-Malaya, and Africa.

We know that you couldn’t care less about it, but we managed to exfiltrate a photo from the organization affiliate’s workstation showing an high resolution image of their leader.

Initial Access

Rhysida attacks usually start with external reconnaissance targeted to unveil services like RDP or VDI having easy credentials, in alternative they may use brokers who sell them verified SSL VPN accounts.

Rhysida – Malware Analysis

Here we present the analysis of a specific Rhysida payload retrieved during incident response operations.
It differs from the usual available online as its size is reduced to 424 KB (434,176 bytes) versus 1MB and 1.3MB of current available samples. We will see specifically its behavior both from the point of view of simple dynamic analysis and from the slightly lower level with reverse engineering and debugging techniques. Follow me, I hope you are not afraid of insects!

Static Analysis

Directories

The binary once inspected with PE-Bear clearly shows that the “.rdata” and “.data” sections are quite relevant compared to the others and indeed they contains useful components that will be later used during execution

The directories of the EP are the following “.text”, “.data”, “.rdata”, “.pdata”, “.xdata”, “.bss”, “.bss”, “. CRT” and “.tls”.

A peculiarity found in this binary is the high number of sections it has; from an evasion perspective having multiple sections like Rhysida payload has, may increase the suspiciousness rating a security software can apply to its static analysis.

From the header file you can detect some useful information related to the nature of the file such as:

• ASLR (Address Space Layout Randomization) – Address space layout randomization (ASLR) is a computer security technique involved in preventing exploitation of memory corruption vulnerabilities. In order to prevent an attacker from reliably jumping to, for example, a particular exploited function in memory, ASLR randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries.
• DEP (Data Execution Prevention) – Data Execution Prevention (DEP) is a technology built into Windows that helps protect you from executable code launching from places it’s not supposed to. DEP does that by marking some areas of your PC’s memory as being for data only, no executable code or apps will be allowed to run from those areas of memory.
• Structured Exception Handling (SEH) – Structured exception handling (SEH) is a Microsoft extension to C and C++ to handle certain exceptional code situations, such as hardware faults, gracefully. Although Windows and Microsoft C++ support SEH, we recommend that you use ISO-standard C++ exception handling in C++ code

From the “Explicit Import Table” we detect the following DLLs imported from the binary during loading:

• advapi32.dll
• kernel32.dll
• msvcrt.dll
• user32.dll

The “Function Table” shows what the payload declares he can do once executed, however this scenario can change quickly thanks to dynamic dll loading that will extend payload’s capabilities.

Following are all the functions coming from the statically imported DLLs

CryptAcquireContextA; CryptGenRandom; AddVectoredExceptionHandler; GetCurrentProcessId; GetCurrentThread; GetCurrentThreadId; GetThreadContext; GetThreadPriority; RaiseException; RemoveVectoredExceptionHandler; RtlAddFunctionTable; RtlLookupFunctionEntry; SetProcessAffinityMask; SetThreadContext; SuspendThread; TerminateProcess; VirtualProtect; rand; srand; CloseHandle; CreateEventA; CreateSemaphoreA; DeleteCriticalSection; DuplicateHandle; EnterCriticalSection; GetCurrentProcess; GetFileAttributesA; GetHandleInformation; GetLastError; GetModuleFileNameW; GetProcessAffinityMask; GetStartupInfoA; GetSystemInfo; GetSystemTimeAsFileTime; GetTickCount; InitializeCriticalSection; IsDebuggerPresent; LeaveCriticalSection; OutputDebugStringA; QueryPerformanceCounter; ReleaseSemaphore; ResetEvent; ResumeThread; RtlCaptureContext; RtlVirtualUnwind; SetEvent; SetLastError; SetThreadPriority; SetUnhandledExceptionFilter; Sleep; TlsAlloc; TlsGetValue; TlsSetValue; TryEnterCriticalSection; UnhandledExceptionFilter; VirtualQuery; WaitForMultipleObjects; WaitForSingleObject; __C_specific_handler; __dllonexit; __doserrno; __getmainargs; __initenv; __iob_func; __lconv_init; __pioinfo; __set_app_type; __setusermatherr; _acmdln; _amsg_exit; _beginthreadex; _cexit; _endthreadex; _errno; _exit; _filelengthi64; _fileno; _findclose; _findfirst64; _fmode; _fullpath; _initterm; _lock; _lseeki64; _onexit; _setjmp; _stat64; _ultoa; _unlock; _write; abort; acos; calloc; exit; fclose; fflush; fgetpos; fopen; fprintf; fread; free; frexp; fseek; fsetpos; ftell; fwprintf; fwrite; malloc; memcmp; memcpy; memmove; memset; printf; raise; realloc; rename; signal; sprintf; strcat; strcmp; strcpy; strlen; strncmp; strncpy; system; vfprintf; wcscpy; _time64; _snwprintf; _findnext64; longjmp; _strdup; _getcwd; _chdir; MessageBoxW.

The strings found in the payload provide some information about the resources it will use during its execution and the actions taken such as:

• background change to bg.jpg in the compromised device
• Shadow copies deletion (cmd.exe /c vssadmin.exe Delete Shadows /All /Quiet)
• Traces deletion (cmd.exe /c for /F “tokens=*” %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl “%1”)
• Ransom note is hardcoded inside the payload

Dynamic Analysis

Execution Flow

What follows is the execution flow that the binary had during the analysis inside a controlled environment.

The payload executes without issues nor conditional checks on the environment that could interfere with the most common dynamic analysis methods.

As expected we see the execution of two previously mentioned commands used to delete shadow copies and traces from event logs

• exe /c vssadmin.exe Delete Shadows /All /Quiet
• exe /c for /F “tokens=*” %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl “%1”

The payload execution process works with the following function order:

• Shadow Copies deletion
• Disk file indexing
• Configuration file decryption (in memory)
• File extension checks for excluded extensions
• Encryption routine
• Event viewer deletion routine

Advanced Dynamic Analysis

File encryption routine – ChaCha20

One of the key indicators that tells you a payload is using ChaCha20 to encrypt data is this magic string “expand 32-byte k” found during the file encryption routine that resembles to be a sigma constant used to expand the stream cipher. This is just a cleartext indicator that can give us some instant information about the payload composition and structure. More about this later in the article.

The payload excludes the following paths and extensions from the encryption routine by looking statically to the decompiled function code

That assumption will be confirmed in the debugging phase where we will see that the malware skips those elements during the encryption cycle execution.

By looking at the indexing order is easy to see that the encryption starts from top to bottom of the retrieved file paths.

At this point let’s have a look at the encryption function more closely with the following GIF that shows a live data encryption segment

The routine responsible for the data encryption does its simple job by following precise steps:

• decrypting the “Rhysida-0.1” configuration data and place it into “rsp+20” memory location
• retrieves file content data using “_fread” function
• moves the file data to the RCX register before calling the “fury.420020” function
• calls the encryption function and then writes the file back into the original file

and exactly in this way Rhysida manages to encrypt the whole attacked system.

It’s not hard to see that Rhysida team is continuing to improve their ransomware payload, and at the moment we are still on his early stages, at the moment this article was written many other different payloads were encountered during incident response activities, with a completely different behavior and structure.

Windows Event Log Deletion

At the end of the encryption routine the payload executes a command that loops through the windows event log registers and clears it completely. This is done to cover its way through the machine it has been executed and eventual lateral movements done by the attacker.

Obfuscation Techniques

This specific binary does not have exotic way to obfuscate how it executes nor implements any relevant anti-debugging technique. Payloads like this seems to be written in a hurry and without any deep knowledge of low-level malware development skills, this idea is reinforced by the “wallpaper change” that seems not yet fully implemented

Another possibility could be that the payload is still in the early stages of its development as we mentioned before and we will be surprised by Rhysida developer with new astonishing features in the near future. The previous sentence could be validated from a string pointing to the ransomware configuration that has been found during the debugging session that says “Rhysida-0.1”

Code errors and flaws

During malware analysis many execution issues has been encountered like method exceptions in the implementation of Tomcat’s RSA key handling functions probably because of an issue with provided arguments

This can be easily confirmed by having a look to the open-source library freely available on the internet

Other instances of simple logic errors are seen till the end of payload execution but nothing too scary to compromise the “main ransomware purpose”.

PREVENTION & HUNTING

Yarix Labs is constantly working to trace APT and Ransomware Groups movements by profiling techniques and attack patterns in order to provide one of the bests Security Services to his customers ranging from Incident Response, Cyber Threat Intelligence, Red Teaming to Security Operation Center Monitoring.

What follows are all the IoCs identified during all malware analysis done to draft the current article

Autore

Nicolas Fasolo is a member of the Yarix Incident Response Team. In the free time he works as an independent “Security Researcher” and “Security Developer” with an unbridled passion for malware analysis. During his CEH Master certification training path he achieved Top 1 in the world for the “Quarter 4 December 2021”. “Cybersecurity Podcast” Author.