A bit of history about how my security research project goes terrible wrong and how I named a malware family.
The year is 2016, more specifically March 2016.
My fellow security researcher (Bival) and I (Th3 0bservator) discussed about global Ransomware threat, future of this thread and how to contribute to a fast and reliable detection techniques. During our discuss he argued that are virtually impossible for any Ransomware to infect that company he work, just because the security’s software that company has in place.
I catch the challenge to create a POC to prove that they are wrong, and few days latter I present my hypotheses for the POC.
- Prove that is possible to write a viable “Ransomware” using the .Net Framework;
- Prove that is hard and painful to anti-virus to detect this kind of
(IL based) virus; - Understand the execution environment;
- Understand the technical challenges to create a real and operational ransomware;
- Provide code and samples to AV companies and Security researchers;
My primary theory was that the AV Engines are incapable to detect IL based virus due the real time and platform specific compilation of IL to Native Code. In my case, .NET framework.
Why .NET? Simple! Because I like it and don’t now how to write any line in C or C++. .NET is powerful, cool, and an important thing is .NET has the best of the best Garbage Collector ever.
Now, just we are speaking about ransomware, and ransomware are basically a brute force file encryption tool, I decide to release all the power of my two cryptographic certifications (2015 “Maryland College” and 2013 “Stanford University”) into the code. Once into the hell road and how I like to do my best in any project, I got my knowledge of Microsoft MCP .NET, Advanced .NET Debugging Certification and finally the 2013 “London University” Malicious Software and Underground Economy Certification to create the POC.
After the VS.NET download and install (Legally!!!!!), I create a new Solution and start the development.
Coffee Break
It’s time for a small break and tell how came to my knowledge all the repercussions of my little project.
I’m writing this article on March 28, 2019.
I wake up at 06:39 AM (GMT-3), eat my breakfast, wake my son, made his bottle, take him to the school and walk to nearest subway station listening to a science podcast.
I arrive to my destination approximately at 09:03 AM (GMT-3) and after some jokes and usually morning greetings one of my colleges tell me that they spend some hours on past night on Google searching about my NXRansonware project. They told me what they found and my heart start to beat fast and fast and more faster.
Essentially, some Security Researchers around the world tracks the “I’ll Make you Cry” Ransomware and the NXRansomware reversed engineering code and assets back to my github base code project. SCARRRYYYYYY.
The hacker responsible for the real work attack used the same name (NXRansomware) and very minor changes on my original POC code (file white list, encryption key, etc).
Encryption Algorithm
Using the combination of RSA-2048 and AES-256, both dynamically generated, NXRansomware POC creates a virtually impossible environment for file recovery. Also, the AES-256 key have 10% probability to be recreated before encrypt the next file.
NXRansomware
Backing into 2016, it’s time to code. In bellow you can see the code basic (very basic) execution workflow.
Other controls are in place to create additional barriers to the Dynamic Analysis.
Everything are passed as reference into the C# code and sometimes as pointers. Strings are stored as SecureString, every other volatile variable (string or array) are wipe-out from memory.
Almost every method into code have instructions to .NET Compiler to place the code inline into the final assembly.
// <summary>
/// Clear Array Content from Memory
/// </summary>
/// <param name="array"></param>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static void ClearArray(ref byte[] array)
{
for (int i = 0; i < array.Length; i++)
{
array[i] = (byte)random.Next(0, 255);
}
}
/// <summary>
/// Clear String Content from Memory
/// </summary>
/// <param name="array"></param>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe void ClearString(ref string str)
{
if (str == null) { return; }
int strLen = str.Length;
fixed (char* ptr = str)
{
for (int i = 0; i < strLen; i++)
{
ptr[i] = (char)random.Next(0, 255);
}
}
}
Also, to cheat the victims the final executable are names
GoogleUpdate.exe and contains the Google Icon.
Time to Stop
After write the ransomware sample and parts of related C&C, i submits several times the final executable to VirusTotal engine and after three months none (yes, none) AV Engines detects my ransomware.
Victory! POC is Done. All my hypotheses are proved successfully.
But, I really start to thinking that POC are became dangerous and decide to finish the project. I stopped the coding, delete some C&C improvements that I made, packed all source files, submit to my public GitHub account and forgot the project.
And here my mistake started
I NEVER, really, NEVER should have send that code to GitHub, but I have good intentions. I think that some other fellow researcher could find the code and learn how to prevent the future threats of this kind.
Next Steps
Now, I’m thinking in evolve my previous POC with a more advanced code, including file less infection and some dynamic code generation. Maybe some kind of multistage infection and, who knows, I use ECC Crypto.
Why? Simple!
Because the predictable evolution of this kind (and others) of threat are in place and I have absolute sure that have many others, at this moment, engineering the evil.
But, as lessons learned, now I use my new POC as presentation and education before release the code in GitHub.
And, to finish this post…..
to know your enemy you must become your enemy