Unraveling the Intricacies of C# DLL Injection Malware: A Deep Dive into Malicious Code

In the world of cybersecurity, every day is a battle against an evolving army of digital adversaries. Today, we're going to explore the thrilling, mysterious realm of C# DLL Malware. This journey will involve analyzing file hashes, decoding the secrets behind VT analysis, and delving into the intricacies of this malicious code. If you're ready for an exciting ride into the world of cybersecurity, fasten your seatbelts and join us on this fascinating adventure!

File Hash & VT Analysis: Unveiling the Bad Boys

Our adventure begins with file hashes, the unique fingerprints of digital files. The file hash "732f235784cd2a40c82847b4700fb73175221c6ae6c5f7200a3f43f209989387" leads us into the enigmatic world of "Malware.cryptlib64.dll.malz." The name itself sends shivers down the spine, promising an exhilarating quest to uncover its secrets.

As our journey progresses, we reach the critical point of Virustotal (VT) analysis. It's here that we discover the true power and reach of our malware. Scoring 11/69 on the VT infection scale, this DLL malware has evidently been quite active in the digital world.

Basic Static Analysis: Strings, Secrets, and Path-etic Discoveries

Now, let's delve into the mysterious code behind this DLL. Through basic static analysis, we decipher some of the essential components and functionalities within this malware.

Strings & Floss Output:

The dark arts of encoding and encryption come to light as we examine strings like "AES_Encrypt" and "AES_Decrypt." These are the tools of the hacker's trade, lurking in the shadows.

The "Main" function is where it all begins, and "WrapNonExceptionThrows" hints at the malware's devious strategies.

I noticed something interesting here mscorlib, it is a series of Dot Net libraries that can be imported when we are building C# applications. This imports a bunch of functionality for a C# application, and it's assigned dynamically at runtime. So it loads all of the functions of these libraries into C# binary when it is executing in the common language runtime. We can also see there is a call out to the Dot Net Framework version. Now that we are working with C# binary we can use a program to recover the intermediate language of the assembly.

DnSpy

I'm going to start analyzing with the program class.

• We have a byte array in which we have sha256 bytes of string looks like we are going to use these bytes at some point since we have an AES decrypt method it must be the password.

• We have a big base64 string which is also the first argument of the AES decryption method.

• It looks like we decoded it from base64 and AES decrypted the block string.

• We write all text to place in the OS, we get the environment variable of the public directory and we write this to a file called embed.xml

• We have another block of base64 text that we only decode and write all the text to C:/Users/Public/Documents/embed.vbs

• It opens the HQC current user directory hive, going to the subkey "Software\Microsoft\Windows\CurrentVersion\Run" and setting key value "embed" and we are setting the value to "C:\Users\Public\Documents\embed.vbs". Looks like a persistence mechanism

Basic Dynamic Analysis:

Since it is a DLL we cannot detonate this malware like we do with other malware. We need a container to run this DLL like rundll32.

Rundll32

To run this DLL we will have to provide the method we want to call which is embedded in this case.

After Initial detonation, I didn't notice any popup or error message. This malware is going to drop two files in the OS. I analyzed the two files embed.xml and embed.vbs.

Host Indicators

I confirmed that two files were dropped at the location mentioned in the code.

We also saw a registry edit in the code, we can confirm with regedit whether the key is added or not.

Yes, indeed the registry key is created.

Analyzing embed.vbs and embed.xml

• Looks like here also we have a big block of base64 encoded string which is also compressed.

• We also have a call to system.reflection.assembly.load that means that whatever the base64 block is doing it is then loaded reflectively as a reflective assembly a common TTP to avoid EDR and antivirus.

I decoded and decompressed code with PowerShell, I saved the output to a file and found out it is binary. This binary is the actual payload that the malware drops.

Network Signatures:

The binary embed.vbs is trying to call http://srv.masterchiefsgruntemporium.local/en-us/index.html

And the victim will get a callback at the local port

It is sending a DNS A request

Conclusion: The Thrilling Finale

Our journey through the world of C# DLL malware comes to a thrilling conclusion. This exploration into the darkness of code has revealed the intricate layers of sophistication hidden within a seemingly innocent file. File hashes and VT analysis have helped us uncover a sophisticated player in the digital battlefield.

But the world of cybersecurity is a never-ending adventure. As defenders, we must stay vigilant, continuously improving our knowledge and tools to outsmart the ever-evolving forces of digital darkness. So, the next time you encounter an innocuous-looking DLL file, remember this exciting journey, and always be prepared for the unexpected.

Summary

• We have a registry run key that runs the VB script embed.vbs when someone logs in to the victim machine.

• The VB script uses using MS build executable and passes it to the embed.xml build file. This build file looks like a C2 reverse shell payload.

• This payload calls back to the host srv.masterchiefsgruntemporium.local. Looks like the listener is set up on the host.

References

• Malware analysis - C# DLL Malware

• VirusTotal - C# DLL Malware