How sys01 stealer will get your sensitive Facebook info

The attack begins by luring a victim to click on a URL from a fake Facebook profile or advertisement to download a ZIP file that pretends to have an application, game, movie, etc.

The infection chain is divided into two parts: the loader, and the Inno-Setup installer that drops the final payload.
The loader is usually a legitimate C# application susceptible to a side-loading vulnerability that comes with a hidden malicious dynamic link library (DLL) file that’s eventually side-loaded to the application.
This legitimate application drops the Inno-Setup installer that decompresses to a whole PHP application containing malicious scripts.
The PHP scripts are responsible for stealing and exfiltrating information.
The scripts are encoded using different techniques, which makes their analysis and detection harder.

THE LOADER
We’ve seen the payload delivered in diverse ways including DLL side-loading, Rust and Python executables, and many others.
All methods eventually drop an Inno-Setup installer which, at the next stage, drops and executes the PHP information stealer.
In the next sections Analysts elaborate on various delivery techniques and luring themes the attackers use.

Note: these delivery methods are representative samples.
There are many other variations of these methods with minor modifications.

DLL SIDE-LOADING V1
In this method, the victim downloads a zipped folder with different luring themes such as world cup live streaming, free applications, and more that abuse legitimate applications vulnerable to DLL side-loading attack.
The zipped folder usually holds the following file patterns:

Executable.
A benign, legitimate executable abused to side-load the malicious DLL
[A-Z]Data.dat (hidden).
A ZIP or self extracting archive (SFX) containing legitimate HTML webpages used as a decoy
[A-Z]License (hidden).
The Inno-Setup installer to be executed (base64 encoded with some string modifications)
DLL (hidden).
The malicious side loaded DLL

The malicious DLL has two main goals: displaying the decoy to the victim and executing the Inno-Setup installer.
It does this by creating a thread that checks whether the License file exists.
If it doesn’t, it downloads the file from its command and control (C2) server, then decodes and executes it.
In the main thread the SFX/ZIP file is executed/decompressed, and the victim is shown the decoy HTML files.

In some samples Analysts noticed cases where the .dat and License files are not included in the zipped folder.
Instead, they’re downloaded from the C2 using the following pattern:

https:///files/dld?t=wcup.
Downloads the License file
https:///files/dlz?t=wcup.
Downloads the .dat file as a ZIP
dld Download the License (base64 encoded with string replacements)
dlz Download .zip (.dat file with the decoys)

DLL SIDE-LOADING V2
In this method, the victim downloads a ZIP folder that purportedly contains an application or movie etc.

The above image shows an example of Garmin’s ElevatedInstaller.exe being abused to side-load the malicious DLL.
Once the executable starts running, it side-loads the malicious DLL that decodes and drops three files to the %temp% folder:

vcruntime140.dll Dependency
rhc.exe (hidec) Executable that accepts an executable as an argument and executes it with hidden console
.exe Rust executable compiled with Cargo
Next, it creates a scheduled task that runs the Rust executable by passing it as an argument to rhc.exe.
Before exiting, it pops up a message box informing the victim that the execution didn’t succeed.

The Rust executable then downloads the next stage-an Inno-Setup installer that deploys the PHP information stealer from /files?t=&tp=d.

We’ve also spotted similar delivery methods that dropped Python executables compiled with Nuitka instead of Rust to drop the next stage Inno-Setup.

DLL SIDE-LOADING V3
Similar to the other delivery methods, in this scenario a victim downloads what seems to be a game, movie, nude album, etc.

All the executables named as image files are in fact the same benign executable-WDSyncService.exe that is abused to side-load a malicious DLL named WDSync.dll.

The WDSyncService.exe file is signed by Western Digital and acts as Western Digital’s sync service, which is written in C#.
Additionally, this executable uses several shared libraries, including WDSync.dll which is hidden in the ZIP file and obfuscated with SmartAssembly.
The rest of the DLLs WDSyncService.exe uses are compressed and encrypted within WDSync.dll using the embedding dependencies feature by SmartAssembly.

Once a victim has executed one of the executables from the ZIP folder, a fake message box pops up and alerts the user to install a “framework” to open the file.

Meanwhile, a thread with malicious logic is executing.
It starts with de-obfuscating the next stage (string replacements + base64 decoding) and writing it to a %tmp% folder under the hardcoded name TS.exe and executing it with “t” as an argument.
Once the execution completes, the file is deleted to leave no evidence on the machine.

The dropped executable (TS.exe) can be executed with one of the following options: t, d

Option t copies the executable to %appdata%PackagesTS.exe and registers a new scheduled task to trigger every day and repeat every hour with option “d” as an argument.

Option d checks if the file %localappdata%m.txt exists.
If it does, the program exits because it means the info stealer is already running on the machine.
If the file does not exist, the executable decodes and drops the next stage Inno-Setup executable to %temp%\ and executes it with /VERYSILENT /SUPPRESSMSGBOXES /NORESTART as arguments.
As before, when the execution finishes the file is deleted to remove evidence from the machine.

INNO-SETUP TO PHP INFORMATION STEALER
Once the Inno-Setup installer executes, it drops a PHP application with additional files, usually to %localappdata[A-Z]{4}.
Between different variants of this information stealer, Analysts saw the following files used to execute the malicious logic:

include.php Responsible for installing persistence via scheduled tasks
index.php Executes the main logic of the stealing act
version.php (embedded in index.php if it does not exist) Holds the stealer version
rhc.exe Hides the console window of started programs (hidec)
rss.txt (other variants have a different name) Base64 encoded string with several string replacements.
Once decoded, this executable, written in Rust and compiled with Cargo, gets the current date and time, and decrypts Chromium-based browsers’ encryption key
In older variants the PHP scripts were not obfuscated in any manner.
In newer variants Analysts noticed commercial encoders ionCube and Zephir, which are self-written extensions that obfuscate the PHP scripts.

After dropping the folder, the Inno-Setup executable executes php.exe include.php, or passes this command line as an argument to rhc.exe.

include.php registers two scheduled tasks:

rhc.exe php.exe include.php
rhc.exe php.exe index.php
rhc.exe php.exe index.php
The first task is triggered at log-on.
The second task is triggered every two minutes.
The attacker must know the time to set it in the scheduled task.
It does this by decoding the rss.txt into an executable, adding a uniquid at the end of the executable, and dropping it to %temp%tmp.exe.
If for some reason the operation fails, this script gets the current date and time running: “wmic os get LocalDateTime /value”.

index.php is the script where the stealing logic takes place.
It starts by setting a configuration array with the following information:

version-Stealer version
b-Bot name (SYS01 is the bot name we’ve seen in all the variants Analysts covered, which is why Analysts named the php stealer SYS01)
tmpData-Path for saving temporarily used files
url_endpoint-A list of C2 domains

During each execution, the script shuffles and randomly defines one of the domains to be used as the C2 in the entire script.

Next, the script creates a machine ID associated with the victim and saves it to %localappdata%packagesm.txt for future executions.
The machine ID is constructed by the following: uniqid() + _ + rand(111111, 999999).
Later, it will call the getTask function that constructs the malicious URL
nd issues a GET request to the C2 with information identifying the victim.
The response is a Json object with zero or more tasks in it.

The main script routine goes over each task and acts accordingly.
As seen in the main function there are five task types: get_ck_all, dlAR, upload, r, dl.

get_ck_all Gets all cookies.
Iterating over based_ch, which consists of a list of Chromium-based browser names.
It tries to extract the cookies and login data for each browser name, and after extracting this information checks if the flag sendD (send data) is set to true.
If so, it posts the stolen information to its C2.
The attacker additionally checks whether the user has a Facebook account logged in or not.
It does this by checking if the cookie hostname contains facebook.com and collects the session specific cookies xs and c_user that store the user ID and session secret respectively.

If the victim has a logged in Facebook account (checked with xs name in Facebook’s cookie), and the rs_flag (resource flag) is set to true, the attacker will query Facebook’s graph API using the access token, obtained via Facebook’s graphql API, to steal the victim’s Facebook information and send it back to the C2.
The stolen information is that set as fields in the URL parameter.

dlAR Download and run.
Downloads a file from the given URL and executes it with the given arguments.

At the time of writing, in the given task the downloaded file was an Inno-Setup executable that dropped a legitimate WD Discovery app to side-load the malicious WDLocal.dll.

The side-loaded DLL issues a GET request to one of its hardcoded URLs with parameters stating the old machine ID, new machine ID, and the current version of the information stealer.
The response is a Json object that holds the new version number, URL to download the new version, command to be executed, and arguments.
The response is parsed, and the new stealer is downloaded and executed.
Next, it creates a scheduled task that executes the updated routine, which triggers at log-on and every 30 minutes.

upload Asks for a file to be uploaded to the C2, checks whether the file exists, and uploads it.

“r” Gets a command to run, executes it, and posts the result back to the C2.
“dl” Sends a get request with the parameter “a=update” to the C2 and does the same as the dlAR task.