Oski Stealer String Decryption — Zero2Automated

The Oski Stealer String Decryption challenge, part of the Zero2Automated series, involves reverse engineering the string decryption routine from a Oski Stealer sample and developing a script to automate the decryption process. The provided sample is identified by the hash:

707adf85c61f5029e14aa27791010f2959e70c0fee182fe968d2eb7f2991797b

Unpacking the Malware

To begin our analysis, we examine the sample using PEStudio to determine its characteristics. It is immediately clear that this is a 32-bit .NET executable, and its high entropy suggests that it is packed.

DIE Entropy section

Next, we proceed with **dnSpy** for further inspection. We quickly notice a call to the function ttJiDM, which, however, does not reveal any code. Additionally, a new instance of the gc class is created, leading us to the main function.

The constructor of the gc class contains multiple lines of code, but our attention is drawn to the Invoke method, which, in the context of .NET unpacking, is analogous to VirtualAlloc and VirtualProtect API calls for normal executables.

Through dynamic analysis, we can determine which method is actually invoked. In particular, lines 34 and 35 are of primary interest.

gc constructor

At line 34, it is likely that the function loads an assembly file, from which it retrieves the method of interest. This method is later invoked at line 49.

The function D5d plays a crucial role in retrieving an array from the BayesMe object, which is stored in the file’s resources. This array is then decoded into a .NET assembly, which is dynamically loaded by the function itself.

Through runtime inspection, we can confirm that the method identified at line 35 is EhgUZIvRw, which is soon invoked. Next, we proceed with its analysis.

The static method EhgUZIvRw belongs to a different .NET module than the previous one, specifically named FuncAttribute.dll, as shown in the image below.

FuncAttribute.dll module

Similar to the previous module, both functions and classes have obfuscated names, making it difficult to determine their purpose at a glance. The most effective approach is to toggle breakpoints on the UnsafeInvokeInternalfunction, which is part of the mscorlib module. This allows us to monitor every call to Invoke along with its parameters. It is likely that the unpacked version of the Oski stealer will be dropped through this function.

UnsafeInvokeInternal function

A quick inspection of the function reveals a call to Thread.Sleep for 45733 milliseconds (approximately 45 seconds), during which the main process enters a standby state.

After this prolonged delay, we observe an array being retrieved, converted into an assembly object, and subsequently invoked at line 52 within an internal function named UJOdcJrJaxN058mJyX.

Sleep function

Could this be the unpacked Oski stealer?

As seen previously, the static method being invoked is fQRwCeWyVS, which belongs to yet another .NET module, named DotNetZipAdditionalPlatforms.dll, as shown in the image below.

DotNetZipAdditionalPlatforms.dll module

At this stage of the challenge, our primary goal is to extract the Oski Stealer payload, so we will not conduct a deep analysis of these additional modules. However, it is important to note that among other actions, a scheduled process is created with the purpose of executing a .NET executable located at AppData\Roaming\cYcPaAiPYUC.exe.

This scheduled script is created via the Windows Task Scheduler, using an XML configuration file, as shown below.

XML configuration

Continuing the analysis with a breakpoint on the UnsafeInvokeInternal function, we observe two key method invocations:

• Assembly.Load
• GetRuntimeDirectory

Upon inspecting the first call, nothing particularly interesting is found — an array of size 0x71400 is loaded, but it turns out to be another .NET module, while we know that Oski is written in C++.

The second call, however, leads to a new function of interest: evIlDKwwfOqtAVPasvA.veMSOMDjV.

This function stands out because one of its arguments contains the name of the executable under analysis, along with an array of size 0x32000.

Suspicious array

If this array represents a PE executable, and given the name of the file, it is highly likely that the malware employs a self-injection technique.

Extracted PE

Heureka! The extracted file is a C++ executable, confirming that this is indeed the Oski Stealer payload.

Now, it’s time to analyze the actual loader.

Ready to dive deeper into the intricate world of reverse engineering?

This article provides just a glimpse! For the full breakdown, detailed scripts, and exclusive insights, head over to my website and unlock the **complete solution**.

Don’t miss the rest of the story!