OilRig’s persistent attacks using cloud service-powered downloaders

From

MailItem.Categories

Created by

Details

<victimID>@yahoo.com

N/A

SC5k v3 instance

Created to register the victim with the C&C server, and renewed periodically to indicate that the malware is still active.

<victimID>@outlook.com

file

C&C server

Attached file is decrypted, decompressed, and dumped on the victim’s computer.

<victimID>@outlook.com

Other than file

C&C server

Attached command is decrypted, decompressed, then passed as an argument to a file already present on the compromised machine, presumably a command interpreter.

<victimID>@aol.com

file

SC5k v3 instance

Created to exfiltrate a file from a staging directory.

<victimID>@aol.com

text

SC5k v3 instance

Created to send command output to the C&C server.

More specifically, SC5k v3 processes (and then deletes) those email messages from the shared Exchange account that have the From field set to <victimID>@outlook.com, and distinguishes between commands and additional payloads by the message category (MailItem.Categories):

• For payloads, the attached file is XOR decrypted using the hardcoded key &5z, then gzip decompressed and dumped in the working directory.
• For shell commands, the draft attachment is base64 decoded, XOR decrypted, and then executed locally using cmd.exe or, in the case of SC5k v3, using a custom command interpreter located under the name <baseDirectory>*Ext.dll. This file is then loaded via Assembly.LoadFrom, and its extend method invoked with the command passed as an argument.

To communicate with the attackers, SC5k v3 creates draft messages with a different From field: <victimID>@aol.com. Attached to these messages are outputs of previously received commands, or contents of the local staging directory. Files are always gzip compressed and XOR encrypted before being uploaded to the shared mailbox, while shell commands and command outputs are XOR encrypted and base64 encoded.

Finally, SC5k v3 repeatedly creates a new draft on the shared Exchange account with the From field set to <victimID>@yahoo.com, to indicate to the attackers that this downloader instance is still active. This keep-alive message, whose construction is shown in Figure 3, has no attachment and is renewed with each connection to the remote Exchange server.

Other OilRig tools using email-based C&C protocol

Besides SC5k, other notable OilRig tools have been discovered subsequently (in 2022 and 2023) that abuse APIs of legitimate cloud-based email services for exfiltration and both directions of their C&C communication.

OilCheck, a C#/.NET downloader discovered in April 2022, also uses draft messages created in a shared email account for both directions of the C&C communication. Unlike SC5k, OilCheck uses the REST-based Microsoft Graph API to access a shared Microsoft Office 365 Outlook email account, not the SOAP-based Microsoft Office EWS API. While SC5k uses the built-in ExchangeService .NET class to create the API requests transparently, OilCheck builds the API requests manually. The main characteristics of OilCheck are summarized in Table 1 above.

Earlier in 2023, two other OilRig backdoors were publicly documented: MrPerfectionManager (Trend Micro, February 2023) and PowerExchange (Symantec, October 2023), both using email-based C&C protocols to exfiltrate data. A notable difference between these tools and OilRig’s downloaders studied in this blogpost is that the former use the victimized organization’s Exchange server to transmit email messages from and to the attacker’s email account. In contrast: with SC5k and OilCheck, both the malware and the operator accessed the same Exchange account and communicated by creating email drafts, never sending an actual message.

In any case, the new findings confirm the trend of OilRig shifting away from the previously used HTTP/DNS-based protocols to using legitimate cloud service providers as a way to hide its malicious communication and to mask the group’s network infrastructure, while still experimenting with various flavors of such alternative protocols.

OilBooster downloader

OilBooster is a 64-bit portable executable (PE) written in Microsoft Visual C/C++ with statically linked OpenSSL and Boost libraries (hence the name). Like OilCheck, it uses the Microsoft Graph API to connect to a Microsoft Office 365 account. Unlike OilCheck, it uses this API to interact with a OneDrive (not Outlook) account controlled by the attackers for C&C communication and exfiltration. OilBooster can download files from the remote server, execute files and shell commands, and exfiltrate the results.

Overview

Upon execution, OilBooster hides its console window (via the ShowWindow API) and verifies that it was executed with a command line argument; otherwise it terminates immediately.

OilBooster then builds a <victimID> by combining the compromised computer’s hostname and username: <hostname>-<username>. This identifier is later used in the C&C communication: OilBooster creates a specific subdirectory on the shared OneDrive account for each victim, which is then used to store backdoor commands and additional payloads (uploaded by the operators), command results, and exfiltrated data (uploaded by the malware). This way, the same OneDrive account can be shared by multiple victims.

Figure 4 shows the structure of the shared OneDrive account and the local working directory, and summarizes the C&C protocol.

As shown in Figure 4, the OilRig operator uploads backdoor commands and additional payloads to the victim-specific directory on OneDrive, as files with the .doc and .docx extensions, respectively. On the other end of the C&C protocol, OilBooster uploads command results and exfiltrated data as files with the .xls and .xlsx extensions, respectively. Note that these are not genuine Microsoft Office files, but rather JSON files with XOR-encrypted and base64-encoded values.

Figure 5 shows OilBooster spawning instances of two threads in an indefinite loop, sleeping for 153,123 milliseconds after each iteration:

Both threads interact with the shared OneDrive account:

1. A downloader thread handles C&C communication and executes downloaded payloads.
2. An exfiltration thread exfiltrates data from the local staging directory.

The downloader thread connects to the attacker-controlled OneDrive account and iterates through all files with the .doc and .docx extensions, which are then downloaded, decrypted, and parsed in order to extract and execute additional payloads on the compromised host. A local subdirectory named items in the current working directory (where OilBooster is deployed) is used to store the downloaded files. As shown in Figure 6, each connection attempt is handled in a separate thread instance, launched once every 53,123 milliseconds.

The exfiltration thread iterates over another local subdirectory, named tempFiles, and exfiltrates its contents to the shared OneDrive account, which are uploaded there as individual files with the .xlsx extension. The staging directory is cleared this way once every 43,123 milliseconds in a separate thread instance, as also seen in Figure 6.

Network communication

For C&C communication and exfiltration, OilBooster uses the Microsoft Graph API to access the shared OneDrive account, using a variety of HTTP GET, POST, PUT, and DELETE requests to the graph.microsoft.com host over the standard 443 port. For brevity, we will also refer to these requests as OneDrive API requests. The encrypted communication is facilitated by the statically linked OpenSSL library, which handles the SSL communication.

To authenticate with the OneDrive account, OilBooster first obtains the OAuth2 access token from the Microsoft identity platform (the authorization server) by sending a POST request with the following body over port 443 to login.microsoftonline.com/common/oauth2/v2.0/token, using hardcoded credentials:

client_id=860b23a7-d484-481d-9fea-d3e6e129e249
&redirect_uri=https://login.live.com/oauth20_desktop.srf
&client_secret=<redacted>
&refresh_token=<redacted>
&grant_type=refresh_token

OilBooster obtains a new access token this way, which will be used in the Authorization header of the subsequent OneDrive API requests, along with a new refresh token. OilBooster also has a backup channel to request a new refresh token from its C&C server after 10 consecutive unsuccessful connections to the OneDrive server. As shown in Figure 7, the new token can be acquired by sending a simple HTTP GET request on port 80 to host1[.]com/rt.ovf (a legitimate, likely compromised website), which should be followed by the new refresh token in cleartext in the HTTP response.

The various network connections made by OilBooster are summarized in Figure 8.

Downloader loop

In the downloader loop, OilBooster repeatedly connects to the shared OneDrive account to obtain a list of files with the .docx and .doc extensions in the victim-specific subdirectory named <victimID>/items/ by sending an HTTP GET request over port 443 to this URL:

graph.microsoft.com/v1.0/me/drive/root:/<victimID>/items:/children?$filter=endsWith(name,’.doc’)%20or%20endsWith(name,’.docx’)&$select=id,name,file

If the connection is not successful (the HTTP_STATUS_DENIED response status) after 10 attempts, OilBooster connects to its fallback C&C server, host1[.]com/rt.ovf, to acquire a new refresh token, as discussed earlier.

Alternatively, if the specified directory does not yet exist (HTTP_STATUS_NOT_FOUND), OilBooster first registers the victim on the shared OneDrive account by sending an HTTP POST request over port 443 to this URL: graph.microsoft.com/v1.0/me/drive/items/root:/<victimID>:/children with the JSON string {“name”: “items”,”folder”:{}} as the request body, as shown in Figure 9. This request creates the whole directory structure <victimID>/items at the same time, which will later be used by the attackers to store commands and additional payloads disguised as .doc and .docx files.

On subsequent connections (with HTTP_STATUS_OK), OilBooster processes these files to extract and execute payloads. OilBooster first downloads each file from the OneDrive account and deletes it from OneDrive after processing the file.

Finally, after going through all the .doc and .docx files downloaded from the OneDrive subdirectory, OilBooster records the last connection timestamp (the current GMT time) by creating a new file named setting.ini in the victim’s OneDrive subdirectory, via an HTTP PUT request on port 443 made to this URL: graph.microsoft.com/v1.0/me/drive/root:/<victimID>/setting.ini:/content.

Processing .doc files

Files with the .doc extension downloaded from the shared OneDrive account are in fact JSON files with encrypted commands to be executed on the compromised host. Once a <filename>.doc is downloaded, OilBooster parses the values named s (part of the decryption key) and c (encrypted command) from the file content. It first base64 decodes, then XOR decrypts the c value, using a key that is created by appending the last two characters of the s value to the last two characters of <filename>.

After decryption, OilBooster executes the command line in a new thread using the CreateProcessW API, and reads the command result via an unnamed pipe connected to the process. OilBooster then uploads the command result to the shared OneDrive account as a new file named <filename>.xls by sending an HTTP PUT request over port 443 to graph.microsoft.com/v1.0/me/drive/root:/<victimID>/items/<filename>.xls:/content.

Processing .docx files

Files with the .docx extension downloaded from the shared OneDrive account are in fact compressed and encrypted files named <filename>.<original extension>.docx that will be dropped and unpacked on the compromised system. OilBooster first downloads the encrypted file to the local directory named <currentdir>items, using the original full filename.

In the next step, it reads and decrypts the file content using an XOR cipher with .<original extension> as the decryption key, and drops it in the same directory into a file named <filename>.<original extension>.doc, while the first one is deleted. Finally, OilBooster reads and gzip decompresses the decrypted file, drops the result in the same directory as a file named <filename>.<original extension>, and deletes the other one.

Note the unnecessary creation of several files in the process – this is typical for OilRig. We previously described the group’s noisy operations on compromised hosts in its Out to Sea campaign.

Exfiltration loop

In the exfiltration thread, OilBooster loops over the contents of the local directory named <currentdir>tempFiles, and uploads the file contents to the victim’s folder on the shared OneDrive account. Each file is processed in this way:

• OilBooster gzip compresses the original file <filename>.<original extension> and writes the result to a file named <filename>.<original extension>.xlsx in the same directory.
• It then encrypts the compressed file using an XOR cipher and .<original extension> as the key. If there is no file extension, 4cx is used as the default key.

Finally, the encrypted file is uploaded to the OneDrive account, and the local file is deleted.

ODAgent downloader: OilBooster’s precursor

ODAgent is a C#/.NET application that uses the Microsoft Graph API to access an attacker-controlled OneDrive account for C&C communication and exfiltration – in short, ODAgent is loosely a C#/.NET precursor of OilBooster. Similar to OilBooster, ODAgent repeatedly connects to the shared OneDrive account and lists the contents of the victim-specific folder to obtain additional payloads and backdoor commands.

As shown in Figure 10, ODAgent then parses the metadata for each remote file. Subsequently, it uses the value of the mimeType key associated with the file to distinguish between backdoor commands (formatted as JSON files) and encrypted payloads – this is unlike OilBooster, which uses file extensions for that distinction. After processing a file locally, ODAgent deletes the original from the remote OneDrive directory via the OneDrive API.

If the downloaded file is a JSON file, ODAgent parses the a1 (command ID), a2 (encrypted backdoor command) and a3 (secret) arguments. It first derives the session key by XORing the provided secret with the hardcoded value 15a49w@]. Then, it base64 decodes and XOR decrypts the backdoor command using this session key. Table 3 lists all backdoor commands supported by ODAgent.

Table 3. Backdoor commands supported by ODAgent

Other (non-JSON) files downloaded from the shared OneDrive account are files and additional payloads, both encrypted. ODAgent XOR decrypts these files with the hardcoded key 15a49w@], and drops them in the local <currentdir>o directory under the same filename. If the original file has a .c extension, its content is also gzip decompressed (and the extension is then dropped from the filename).

At the end of each connection, ODAgent uploads the contents of the local directory <currentdir>i to the <victimID>/i directory on the shared OneDrive account, preserving the original filenames with the added .c extension.

Conclusion

Throughout 2022, OilRig developed a series of new downloaders, all using a variety of legitimate cloud storage and cloud-based email services as their C&C and exfiltration channels. These downloaders were deployed exclusively against targets in Israel – often against the same targets within a few months. As all of these targets were previously affected by other OilRig tools, we conclude that OilRig uses this class of lightweight but effective downloaders as its tool of choice to maintain access to networks of interest.

These downloaders share similarities with MrPerfectionManager and PowerExchange backdoors, other recent additions to OilRig’s toolset that use email-based C&C protocols – except that SC5k, OilBooster, ODAgent, and OilCheck use attacker-controlled cloud service accounts, rather than the victim’s internal infrastructure. All these activities confirm an ongoing switch to legitimate cloud service providers for C&C communication, as a way to hide the malicious communication and mask the group’s network infrastructure.

On par with the rest of OilRig’s toolset, these downloaders are not particularly sophisticated, and are, again, unnecessarily noisy on the system. However, the continuous development and testing of new variants, the experimenting with various cloud services and different programming languages, and the dedication to re-compromise the same targets over and over again, makes OilRig a group to watch out for.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com.
ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

Files

Network

MITRE ATT&CK techniques

This table was built using version 14 of the MITRE ATT&CK framework.

Source: Original Post

“An interesting youtube video that may be related to the article above”