A walk down the memory lane: Vol 2

 So, in the first part of the series we pushed out a tool that we used for SpyEye configuration dumping, but it can also be used for other things.

In this part, we'll touch the subject of API name hashing, a technique pretty widely used on both bulk malware and APT malware. I reckon most of the readers are aware of it, but let's do a short introduction.

Commonly when you compile a your code project into an executable, the linker will generate a table of all the system API calls that are used in your program. It can be a handful of system calls like CreateFileW or OpenProcessToken. When analyzing normally compiled binaries the process is a whole lot of smoother when your disassembler/decompiler can tell your straight out of the box which API is being called.

In order to hinder analysis, some malware authors use a technique called API name hashing. Instead of direct calls to various API's, the malware uses "magic" values that are resolved in the runtime by the malware itself. So instead of having a sweet, readable disassembly like this:

you will be getting a much harder to read output, looking something like this:

In order to lessen the impact on analysis time we use a core C project called ApiNameHasher. It has support functionality to hash and print our all API's from a single DLL, or you can choose to dump everything for the whole c:\Windows\System32\*.dll

Now, the API hashing technique changes to one malware to the next. Hence the actual hashing is done in a separate function that receives the API name as parameter. That way when we see a new malware using yet another new way of hashing an API name, we can just do a quick reverse engineering of the hashing function and drop it into the ApiNameHasher.

The C code is available on our Github repo

The original code was a bit cluttered after heavy use, but I left 2 sample functions as an example as they use different approaches in the "style".

The first one is called LazarusHasher:

Sometimes it's faster (for us atleast) to just basically copy and edit the assembly code and then paste it as inline assembly in the ApiNameHasher. This approach works easily for 32-bit code. For 64-bit code you cannot inline the assembly, but you can create an .asm file that holds the code and then add a build dependency for MASM, the Microsoft Assembler. This way is useful especially if there are some compiler semantics at play that you don't have the time to figure out.

The second one is called BlackBubbleHasher. It's an internal name we use for a malware that has not been documented publicly yet, but it's basically a next-generation variant of StealthVector from APT41:

In this function, the whole hashing was reverse engineered into C, and then dropped into the ApiNameHasher.

We absolutely love the tool. We can still see the metadata from it's first uses, when it was compiled using Visual Studio 2008. 16 years already and we bet it has still a lot of love left in it.

A walk down the memory lane

 A walk down the memory lane

A while ago we had to search for an old piece of code we had to check up something. During that, we woke up to the fact that we had literally hundreds of different code projects stashed away.

Some projects were simple, focused on doing a thing or another related to a specific piece of malware, like API name hashing, a technique quite commonly used by various malwares in order to hinder the analysis.

Some projects were not so simple, like extracting malware encryption keys directly from a live process memory, or brute forcing whatever the encryption was that a specific malware used.

We thought it'd be fun to dust off a few of the projects and share them. Even though the malware families they target are long gone, the techniques used in the projects still apply and can be adapted to malware families that roam the internet nowadays. All the source codes will be published over at Github. They will be shared under the MIT license, so feel free to do whatever you want with the sources. We'd love to hear if you adapt the code to do something new :)

So here we are, walking down the memory lane, starting the series with...

SpyEye

SpyEye emerged around 2010. Described by the Department of Justice as a "preeminent malware banking Trojan", it was used to infect over 50 million computers worldwide from 2010 to 2012, causing nearly $1 Billion in financial losses.

SpyEye used a technique that was called "man-in-the-browser". It basically injected itself into explorer.exe and processes that belonged to web browsers, hooking up several API's that it needed in order to monitor the what the user was browsing.

Certain web page forms were captures by the malware, and sent to it's creators. Also, whatever the victim had in the Autofill of the browser got snatched as well and sent onwards. So they got hold of banking id's and passwords that they could use later on steal all the moneys from victims.

SpyEye used a configuration file to get instructions on which banks it should target and how. The configuration resided in a modified ZIP-file that was protected with a 32 byte long alphanumeric password. You had to know the password in order to know what's in the configuration.

During it's peak, there were dozens of new SpyEye variants rolling in each and every day. Analyzing the samples by hand to extract the configuration was simply not a choice. Hence, we needed automation.

We created a DLL that would be injected into the running malware process. The DLL just sat and waited for the malware to decompress and deobfuscate itself.

Basically, when the actual malware.exe was executed it injected a copy of itself into the explorer.exe process and then killed it's original process.

Our DLL just waited for the moment when the OS would tell it to unload itself (DllMain() being called with DLL_PROCESS_DETACH flag), after which it scanned the process memory of the malware, looking for a potential password. If found, the password candidate was saved to a 'keyring' file and be later used to decrypt the configuration file.

Analyzing new SpyEye samples became a breeze and could be made in an automated fashion. We had hundreds of passwords in the keyring at the end, allowing us to decrypt virtually almost any SpyEye configuration that we got our hands on.

But what happened to SpyEye? In 2016, two individuals were sentenced to a combined 24 years and 6 months in prison for their roles in developing and distributing SpyEye.

Fake Ransomware decryption tools: The rabbit hole

 

Backstory

During the past month or so, following the announcement of our Akira ransomware decryption service, we have been responding to Akira incidents around the world. Recently, a victim organisation contacted us for help, but their story was quite unusual compared to the other victims we have been assisting.

As it turned out, they had indeed been hit by the Akira ransomware but in addition to this, they shared a decryption tool with us and told us that they had contacted some "Decryption Experts" and paid for this tool upfront. As their Akira incident was recent and the decryption tool that they shared with us was not made by Avast, we immediately knew that something suspicious was going on. 

As a recap: Legitimate decryption tools released to the public can help with older variants of Akira, that had a much more simple encryption scheme. The current variant of Akira uses up to 8 encryption keys per file, as well as two different encryption schemes, which makes it unfeasible to release a standalone decryption tool. This is why we offer the decryption as a paid service (paid after successful decryption), since it takes considerable amounts of computing power and manual binary analysis performed by our experts.

We decided to take a closer look at the tool they shared to see what they had paid for. What we uncovered was a widespread campaign of new fake ransomware decryptors, being actively advertised via Youtube channels, tailor made websites and reddit.

This post may get a bit technical at some points.

Fake decryptor analysis

The fake akira decryptor tool (SHA1: c66c5f0e7876a53c1af4da241d6248c05ff9dc4b) comes to us from the future in the form of a .NET executable with a modified compiler timestamp of "22/11/2080 7.08.52".

Fake Akira decryptor user interface

Supposedly, all the victim has to do is to input their unique Login ID/Chat ID that is found in the Akira ransomware note. Behind the scenes, the Login ID is checked to see if matches a hardcoded value. Our hypothesis is that this hardcoded value is the actual victim Login ID that the victim has passed on to the actors behind this campaign. The actors then compile a new executable for each victim, with their ID hardcoded into the program.

DnSpy analysis

By loading the executable into dnSpy, an open source .NET debugger and assembly editor, we can take a look at what the code is doing. To save us some effort, the actors have chosen not to obfuscate their code and static analysis is a breeze. Immediately after loading the binary into dnSpy, looking at the embedded resources, we spotted an additional logo image referring to a "universal decryptor". We will circle back on this discovery after analyzing the "Decryption" part of the code.

Akira Decryption.exe resources

Looking inside the EncryptDecryptFiles class, we find the Decrypt() function. The function starts by comparing the user submitted login ID to a hardcoded value as previously mentioned. If the value matches, the function goes through each file present defined in the current path (C:\\) and looks for files that contain the string "akiraa" in their name. 

We are not sure if this typo is intentional or if it is simply an error on the actors part, because on a machine with an Akira infection, the encrypted files have an ".akira" suffix. Because of this, the check fails on every file and an error message is shown to the victim: "Your personal ID is expired by Hackers. Please update!" Of note: By design (logic error or intentional), even if the program would find ".akiraa" files and overwrite them, it would still display the same error message to the victim.

Decrypt function

Interestingly, the executable also contains an Encrypt function, which is never called in the binaries that we found. Our hypothesis is that this function is called in the variants that the actors use to first encrypt files in order to show that the decryption is working in their demo videos. This is further supported by the presence and usage of actual cryptography functions via the System.Security.Cryptography .NET API.

Cryptography API usage

Pivoting on resources

To circle back on the universal decryptor image that was present in the resources, we found two interesting artifacts to further pivot on and look for related binaries. The first artifact was the Akira decryption image displayed in the tool, named "tumblr_252fa...". Searching for this string in Virustotal showed 3 similar binaries. One supposedly for lockbit decryption, one for djvu and one for phobos ransomware.

Virustotal search for the resource name

These 3 binaries are also .NET executables and a quick analysis reveals that they are identical in function to the Akira decryption binary. Below is a comparison of the Akira decryption binary and one of the newly found binaries. The Decrypt function (and other functions) are identical, except for the hardcoded Chat ID that the victim provides to the actors.

Comparing the two binaries in dnSpy

The second artifact is the presence of the "universal decryptor" image in the resources. Searching for universal decryptor in google, we came across a website "universaldecryptor.net". This website promises guaranteed recovery of files for stop/djvu ransomware victims in exchange for an undisclosed amount of Tether (USDT) or Bitcoin cryptocurrency. 

The page is filled with seemingly fake reviews and testimonials along with a FAQ section to reassure victims of the legitimacy of the operation. Victims are instructed to contact the actors via whatsapp, telegram or email, most likely to carry out the payment of cryptocurrency and receive the fake decryption tool.

universaldecryptor website

The page also contains an embedded Youtube video, allegedly showing the tool working and decrypting files. Searching on Youtube for "ransomware decryption" leads to multiple channels and several hundreds of videos advertising the successful decryption of any number of ransomware variants. ( lockbit, akira, djvu, phobos etc.).

These videos and their descriptions containing links lead us to the akiradecryption[.]org website. Looking awfully familiar. Any doubt that these websites and programs are not connected, should be gone by this point. The client that reached out to us originally also confirmed that this is indeed where they received the akira decryption executable from.

akiradecryption website

Looking at the list of Youtube channels we found during analysis reveals that on some channels, the campaigns have been active for at least 2 years. All channels follow a similar pattern of releasing "proof of concept" videos for whatever ransomware strain, with the video showing how the tool supposedly decrypts files.

one channel with multiple videos for different ransomware

Conclusion

The uncovered campaign is yet another example of criminals trying to exploit desperate victims for financial gain. It should go without saying, but in the event of a ransomware attack your first point of contact should be your local law enforcement agency, followed by actual incident response experts and legitimate security vendors. (not a website that requests USDT, Bitcoin or any other cryptocurrency as payment for their services).

In addition to this, the importance of backups (and actually verifying that you can restore from said backups) can not be overstated. 

We have notified the relevant parties to get these channels, websites and user accounts taken down.

If you got this far, thank you for reading the post and stay safe. If you have any questions or need assistance with Akira recovery or anything else, don't hesitate to reach out to us at support@fitsec.com.

Eerik Reis, Toni Koivunen & The Fitsec APT research team

Indicators of Compromise

Websites:

hxxps://akiradecryptor[.]org

hxxps://universaldecryptor[.]net

hxxps://lockbitdecryptor[.]com

hxxps://phobosdecryptor[.]ru

hxxps://bytees[.]org

hxxps://stopdjvudecryptor[.]org

Youtube channels:

@StopRansomware

@stopdjvuransomware

@stopdjvudecryptortool

@stopdjvudecryption3546

@stopdjvuransomwaredecryptor

@DecryptorMaestros

@stopdjvudecryptorofficial

@Stopdjvudecryption211

@davidson797

@Howtodecryptguide676

@RansomwareDecryptoruniversal

@AkiraDecryptor

@decryptakiravirus

@Akirafilesdecryption

@HuntersInternationalDecryptor

@Boldbytes-hb8jp

@RansomAttack

@dotertool

@akiraransomwre

@safepcfromransom

@Decryptorransomware

File hashes (fake decryption binaries):

b67788c6dbd20b39d9ca44e8c8ed46a7e4295160

565d14be027095852bee7ecae5c554f0d322e720

ae0c64f2ad1075a76c4b348ed69e61a8864a8897

🚨 Exciting News

We at Fitsec Ltd are now able to successfully decrypt files encrypted by the Akira malware! And can now help victims! Do not hesitate to contact us.

https://www.akirahelp.com/
https://feed.fitsec.com/

hashtag#akira hashtag#akiraransomware hashtag#ransomware hashtag

 

Integrate Threat Intelligence Feeds into Third-Party Security Solutions

Integrating Threat Intelligence Feeds into third-party security solutions is a critical step towards effective threat detection and response. Through this integration, organizations can automate numerous cybersecurity processes, enhancing both the speed of response and the accuracy of detection

API Integrations:

API integrations allow for direct and real-time data exchange between threat intelligence feeds and security solutions. This significantly accelerates threat identification and enables immediate response, minimizing potential damage.

 

SIEM and SOAR Systems:

SIEM systems analyze and prioritize threat data, providing in-depth insights into potential threats. SOAR solutions take this a step further by automating the processes of threat detection, investigation, and response. Together, these systems create a strong foundation for threat management by seamlessly integrating threat intelligence data into security operations.

 

Challenges:

Challenges in integration include ensuring data quality and reliability. By selecting reliable threat intelligence sources and adhering to best practices in data management, organizations can reduce false positive alerts and improve the efficiency of their security solutions.

 

By integrating threat intelligence feeds into third-party security solutions, organizations can significantly improve their ability to detect and respond to threats in real-time. This not only speeds up response times but also makes the work of the cybersecurity team more efficient, allowing them to focus on more critical tasks. When executed correctly, this integration provides organizations with a significant competitive advantage in the realm of cybersecurity.