More complex evasion methods

Introduction

This article is part of my series: Inside Different Generations of Ransomware.

If you are interested in the full series, please refer to the mentioned page.

In the previous article, I briefly analyzed the version 2018 of GlobeImposter, released in 2018. Initially, I wanted to analyze both the version 2018 and 2021 in that article. However, I realized that the version 2021 is much more complicated.

Therefore, I decided to separate the version 2021 into this article.

This article presents a deeper analysis of one of the variants of GlobeImposter family, released in 2021. At the end of the article, I conclude the design philosophy of this ransomware.

GlobeImposter 2021

Note: If you are interested in the background of GlobeImposter, please refer to this article.

GlobeImposter 2021 is written in .NET, most likely VB.NET.

Initially, I thought the analysis of GlobeImposter 2021 is as simple as the version 2018. However, I then found out the 2021 version presents a significantly more complex architecture in evasion and anti-analysis.

Extortion message

Reverse Engineering

Information of the version 2021:

• Language: .NET framework VB/C#
• Compiler timestamp:
• SHA256: 5c3ce324ded0942df4b4cbf80cf195263f105daf5c729255c628bb3a4f8ab3de

Open the malware using ExeInfo PE and DIE (Detect It Easy):

ExeInfo PE

DIE

DIE — Entropy

I opened the malware using dnSpy and realized that the malware is heavily obfuscated:

Obfuscated malware

I tried to use different de-obfuscators, such as de4dot and NETReactor Slayer, but all failed to de-obfuscate the malware.

Therefore, I decided to dynamically analyze this malware using the provided functionality of dnSpy.

Note: Since GlobeImposter encrypts *.exe and *.dll, which indicates dnSpy might malfunction once its DLL files are destroyed. You should take a snapshot of your virtual machine to save your time!

Initially, I was confused by the image resource files:

After further investigation, I found out these image resources are not actual media content, but rather serve as containers for encrypted payloads. This technique helps evade static detection, as image resources are typically considered benign and may bypass superficial inspection.

Hexadecimal 4D5A, corresponding to MZ signature in ASCII

The payload stored in the image resource can be dumped after multiple decoding procedures:

Save "FeedbackSize" as payload.bin

Hexdump of payload.bin

Open payload.bin using ExeInfo PE and DIE (Detect It Easy). Both tools confirmed it is a DLL file written in .NET. In addition, it is obfuscated.

However, again, de4dot can only partially deobfuscate the payload.

Therefore, I decided to continue the dynamic analysis, and located the method it calls:

O5.Ga

O5.Ga.aI

The payload pauses (Thread.Sleep) itself for a while. This behavior is likely intended for anti-analysis.

The payload uses Assembly.Load to load another payload from resource after decoding:

I dumped another payload from memory. Again, the new payload is obfuscated using the same method. Both de4dot and NETReactor Slayer can only partially de-obfuscate it.

Hexdump

ExeInfo PE

DIE

Unpacking failed

Open the new DLL payload using dnSpy. It can be observed that there are numerous image resources:

The payload uses the same obfuscation method:

After further investigation, I believe this payload is the main ransomware module since it contains many critical APIs and modules for file encryption, such as ProcessStart, DirectoryInfo, SymmetricAlgorithm and CryptoStream.

SymmetricAlgorithm

CreateDecryptor

CryptoStream

Create hidden window

Despite this, this payload still uses APIs such as Assembly.Load() and LoadLibrary for evasion, but the overall encryption routine remains largely the same as the version 2018.

Finally, the overall execution procedure is summarized below:

graph TD subgraph "Stage 1 payload" A["Launch payload"] A --> B["Convert image to payload (DLL)"] B --> C["Load DLL payload via Assembly.Load"] C --> D["Extract another payload from resource"] end subgraph "Stage 2 payload" C --> E["Decoder and DLL Loader"] D --> |Inject payload| E end subgraph "Stage 3 payload" E --> F["Ransom module"] F --> G["Load more payload via LoadLibrary() and Assembly.Load()"] end linkStyle 0 stroke:#ff0000,stroke-width:2px; linkStyle 1 stroke:#ff0000,stroke-width:2px; linkStyle 2 stroke:#ff0000,stroke-width:2px; linkStyle 4 stroke:#ff0000,stroke-width:2px; linkStyle 3 stroke:#00ff00,stroke-width:2px; linkStyle 5 stroke:#ff0000,stroke-width:2px; linkStyle 6 stroke:#ff0000,stroke-width:2px;

This multi-stage design significantly increases analysis complexity, as each stage introduces additional layers of obfuscation and decoding, effectively delaying full payload exposure.

Conclusion

This article presents an analysis of GlobeImposter 2021, with a focus on its multi-stage execution and evasion techniques.

Since the outbreak of WannaCry, detection mechanisms for ransomware have significantly improved. Traditional indicators such as API imports and static string patterns are now commonly used for detection.

In contrast, GlobeImposter adopts a different strategy. Instead of relying on exploitation-based propagation, it focuses on:

• multi-stage in-memory execution
• heavy obfuscation across all payload stages
• encoded resource-based payload delivery

These techniques reduce the effectiveness of static analysis and increase the difficulty of reverse engineering.

Furthermore, its reliance on RDP brute force for initial access indicates a shift toward targeted attacks, rather than large-scale automated propagation.

Overall, GlobeImposter demonstrates how modern ransomware evolves not by becoming more aggressive, but by becoming more stealthy and modular.

If you have any suggestions or comments, please feel free to leave them below!

THANKS FOR READING