10/21/2021 | News release | Distributed by Public on 10/21/2021 07:06
RedLine infostealer is a popular malware family distributed predominantly via phishing email campaigns. Our initial Threat Thursday blog for RedLine highlighted the dangers and capabilities of this threat. Recent analysis of the malware family has identified a significant update to its command-and-control (C2) communication mechanism.
Initially, RedLine infostealer implemented SOAP (Simple Object Access Protocol) over HTTP, but we have discovered that more recent samples implement SOAP data over Net.TCP Port Sharing Protocol instead. This update makes it more difficult to identify and understand communication data being exchanged between a victim and the malware's C2 servers.
In the wild since 2020, RedLine has become a more prevalent threat since April 2021. Though the core mechanisms of RedLine are largely the same, the difference between previous RedLine samples and the current versions are primarily related to changes in its transport mechanism.
RedLine's recent switch from HTTP to Net.TCP C2 communication was likely made to thwart initial packet analysis and inspection of the malware's C2 interactions, by both human and automated network packet-filtering systems. By using Net.TCP, the threat makes its traffic more difficult to identify as malicious, so that it can carry out its activities more effectively.
When analyzing Simple Object Access Protocol (SOAP) over HTTP, data data is formatted in a way that makes it more human-readable, as shown in Figure 1. Because newly observed samples of RedLine no longer use HTTP, the data structures appear significantly different.
Figure 1: Differences between previous and current RedLine samples
The Net.TCP protocol is based on MC-NMF (.NET Messsage Framing) Protocol. NMF is a mechanism for framing messages, specifically SOAP messages like those used in RedLine. MC-NMF is a highly flexible protocol that is ideal for bidirectional messaging. This can be abused by RedLine to both send and receive communications from a victim device.
Specifications for the protocol are available on the Microsoft web site. Based on the information in the specification sheet, the initial packet (Figure 2) is interpreted as shown inthe next table below.
Figure 2: Initial request
Once dynamically executing on a victim's device, RedLine will make an initial request to its malicious infrastructure. As the malware uses MC-NMF, the packets it sends to the C2 are structured as follows:
Index |
Byte Data |
|
0x0 |
0x00 |
This is a Version Record format |
0x1 |
0x01 |
Major Version |
0x2 |
0x00 |
Minor Version |
0x3 |
0x01 |
This is a Mode Record format |
0x4 |
0x02 |
Duplex mode |
0x5 |
0x02 |
This is a Via Record format |
0x6 |
0x1D |
URI length |
0x7 - 0x23 |
0x6E - 0x2F |
URI (net[.]tcp://45[.]132[.]104[.]3:52352/) |
0x24 |
0x03 |
This is a Known Encoding Record format |
0x25 |
0x08 |
Use Binary Dictionary as specified in MC-NBFSE |
If the C2 server accepts the request, it responds in the form of an acknowledgement (Ack) packet. In MC-NMF, this done via a Preamble Ack Record.
A Preamble Ack Record is a Property Record that is sent to indicate receipt of the Preamble End Record. This indicates that all messages have been successfully sent.
The packet just contains [0xb], which is a Preamble Ack Record, as shown in Figure 3. By receiving this data, RedLine is ready to send/receive binary-translated SOAP data.
Figure 3: Preamble Ack Record
In addition to using MC-NMF, RedLine also uses a wide-range of other Net.TCP protocols to carry out its malicious communications.
Protocol Name |
Descripption |
MC-NBFSE |
.NET Binary Format: SOAP Extension |
MC-NBFS |
.NET Binary Format: SOAP Data Structure |
MC-NBFX |
.NET Binary Format: XML Data Structure |
By using these protocols, RedLine can efficiently encode common strings for the SOAP protocol data. The malware can also eliminate duplicate strings using such protocols. This reduces the size of its packets when communicating between C2 server and victim, which minimizes the footprint of the malware.
Once a session is established, we can analyze the communication between C2 server and victim. In the following sections, we show C2 communication for initialization with binary-translated SOAP data. This table contains the SOAP request and response, as well as its related functionality.
SOAP Request |
SOAP Response |
Functionality |
CreateSequence |
CreateSequenceResponse |
Create session |
CheckConnect |
CheckConnectResponse |
Start C2 communication with session |
EnvironmentSettings |
EnvironmentSettingsResponse |
Select scanning targets |
Init |
InitResponse |
Send basic information on victim environment |
After RedLine has established a Net.TCP session, it sends binary data translated from SOAP data as shown in Figure 4.
Figure 4: Binary-translated SOAP request
Based on MC-NBFSE, MC-NBFS, MC-NBFX and MC-NMF specifications, the binary can be translated to SOAP data.
In this case, its C2 server address is net[.]tcp://45[.]132[.]104[.]3[:]52352
Following on from that, we can further analyze the SOAP data. Figure 5 goes into more detail of this for the "CreateSequence".
Figure 5: Translating CreateSequence
The data that follows is SOAP data, as shown below.
Figure 6: Create sequence (SOAP)
To create a connection between the victim and the C2 server, a handshake must be completed before malicious activities can proceed, similar to a traditional HTTP handshake. This is initiated with the creation of a "CreateSequence" request.
"CreateSequence" makes an ID to maintain the following C2 communication. The request contains two important parameters.
The response data is also binary. The binary format and SOAP format are shown in Figure 7. The response contains an important parameter.
The "Main Identifier" related to the value of the "" tag is an important parameter, and RedLine uses it for the ensuing C2 communication. For clarity, we will refer to the value as "main identifier" in this report.Figure 7: Create sequence response (binary and SOAP)
CheckConnect confirms that both sides have a valid session. Figure 8 shows "CheckConnect" request. It contains two important parameters.
Once the request is accepted, RedLine receives "CheckConnectResponse" response as shown in Figure 9.
Figure 9: Check connect response (binary and SOAP)
RedLine sends a "SequenceAcknowledgement" request to the C2 server when it receives response data like "CheckConnectResponse." This notifies the C2 server that the previous communication succeeded. As shown in Figure 10, it contains "Session Identifier."
In addition, there is an "<_r3a_acknowledgementrange>" tag, and its "Upper" attribute is incremented when it sends a "SequenceAcknowledgement" request to the C2 server.If the parameter's integrity is broken, the ensuing communication will fail.
Figure 10: Sequence acknowledgement (binary and SOAP)
After "CheckConnect," an "EnvironmentSettings" request is sent to the C2 server. Once received, the malware will send an "EnvironmentSettingsResponse" containing core information for infostealer functionality.
RedLine has notable functions named "BlockedCountry" and "BlockedIP" tags, which contain country names and IP addresses. During analysis, the sample avoids infecting machines in the following Eastern European nations:
RU |
Russia |
AZ |
Azerbaijan |
UA |
Ukraine |
MD |
Moldova |
BY |
Belarus |
UZ |
Uzbekistan |
KZ |
Kazakhstan |
TM |
Turkmenistan |
TJ |
Tajikistan |
AM |
Armenia |
KG |
Kyrgyzstan |
The response also has a target list which contains information that RedLine collects. The malware gathers information from web browsers, file transfer protocol (FTP) clients, instant messengers (IM), cryptocurrency wallets, VPN services, and gaming clients.
RedLine searches for the following Chrome browser directories, which contain login credentials, browser cookies, auto-fill information, and credit card details.
%USERPROFILE%\AppData\Local\Battle.net |
%USERPROFILE%\AppData\Local\Chromium\UserData |
%USERPROFILE%\AppData\Local\Google\Chrome\User Data |
%USERPROFILE%\AppData\Local\Google(x86)\Chrome\User Data |
%USERPROFILE%\AppData\Roaming\Opera Software\ |
%USERPROFILE%\AppData\Local\MapleStudio\ChromePlus |
%USERPROFILE%\AppData\Local\Iridium\User Data |
%USERPROFILE%\AppData\Local\7Star\7Star\User Data |
%USERPROFILE%\AppData\Local\CentBrowser\User Data |
%USERPROFILE%\AppData\Local\Chedot\User Data |
%USERPROFILE%\AppData\Local\Vivaldi\User Data |
%USERPROFILE%\AppData\Local\Kometa\User Data |
%USERPROFILE%\AppData\Local\Elements Browser\User Data |
%USERPROFILE%\AppData\Local\Epic Privacy Browser\User Data |
%USERPROFILE%\AppData\Local\uCozMedia\Uran\User Data |
%USERPROFILE%\AppData\Local\Fenrir Inc\Sleipnir5\setting\modules\ChromiumViewer |
This threat also looks for this same information in the following Gecko browser directories.
%USERPROFILE%\AppData\Roaming\Mozilla\Firefox |
%USERPROFILE%\AppData\Roaming\Waterfox |
%USERPROFILE%\AppData\Roaming\K-Meleon |
%USERPROFILE%\AppData\Roaming\Thunderbird |
%USERPROFILE%\AppData\Roaming\Comodo\IceDragon |
%USERPROFILE%\AppData\Roaming\8pecxstudios\Cyberfox |
%USERPROFILE%\AppData\Roaming\NETGATE technologies\Blackhaw |
%USERPROFILE%\AppData\Roaming\Moonchild Productions\PaleMoon |
It also searches for the presence of Discord, FTP clients, and files related to cryptowallets.
%userprofile%\Desktop|*.txt,*.doc,*key*,*wallet*,*seed*|0 |
%userprofile%\Documents|*.txt,*.doc,*key*,*wallet*,*seed*|0 |
The "Init" request contains basic information on victim environments, such as:
As shown in Figure 11, the value of "ReleaseID" comes from embedded encrypted strings, as shown in Figure 12.
Figure 12: Init response (binary and SOAP)
After "InitResponse," RedLine sends information containing details from the victim environment to the C2 server.
In our previous RedLine blog, we described what information the malware collects. There are slight differences in this newer version. Table 2 contains details of the following updated C2 communication.
New SOAP Request |
New SOAP Response |
Functionality |
PartSteamFiles |
PartSteamFilesResponse |
Same as previous version |
PartBrowsers |
PartBrowsersResponse |
Same as previous version |
PartLanguages |
PartLanguagesResponse |
Send language setting |
PartDiscord |
PartDiscordResponse |
Same as previous version |
PartProcesses |
PartProcessesResponse |
Send running process name, command line and process ID |
PartDefenders |
PartDefendersResponse |
Send antivirus product, anti-spyware product and firewall product |
PartInstalledSoftwares |
PartInstalledSoftwaresResponse |
Send installed software Information |
PartNordVPN |
PartNordVPNResponse |
Same as previous version |
PartOpenVPN |
PartOpenVPNResponse |
Same as previous version |
PartProtonVPN |
PartProtonVPNResponse |
Same as previous version |
InitDisplay |
InitDisplayResponse |
Send screenshot of victim environment |
PartFtpConnections |
PartFtpConnectionsResponse |
Same as previous version. There is no function for WinSCP. |
PartHardwares |
PartHardwaresResponse |
Send CPU, graphic card and RAM information. |
PartColdWallets |
PartColdWalletsResponse |
Same as previous version |
PartInstalledBrowsers |
PartInstalledBrowsersResponse |
Same as previous version |
Confirm |
ConfirmResponse |
It does not contain interesting information |
Getupdates |
GetupdatesResponse |
The response contains URLs for additional payloads |
VerifyUpdate |
VerifyUpdateResponse |
The base structure is like Getupdates. It adds "updateId" tag. |
LastMessage |
End of communication |
BlackBerry has monitored RedLine C2 activity continuously, and we have observed the malware aiding other malware families once it's installed on a compromised victim's device.
With a strong focus on cryptocurrency coin miners, a lot of RedLine's IOCs are strongly linked to and used by other malware and malware families such as:
The popularity of RedLine continues to grow, and the malware is clearly still in development. Though the malicious capabilities have remained the same, the malware no longer uses SOAP over HTTP and instead uses binary-translated to SOAP over Net.TCP protocol.
This evolution makes the data exchanged between the malicious C2 traffic and the victim more difficult to analyze and detect, as the data is no longer human-readable.
The following YARA rule was authored by the BlackBerry Research & Intelligence Team to catch the threat described in this document:
rule Mal_InfoStealer_Win32_Redline_Stealer_Update_Unobfuscated_2021 |
RedLine Infostealer (SHA256) Examples:
C2 Server's IP / Port
URLs for Additional Payload
|
If you're battling this malware or a similar threat, you've come to the right place, regardless of your existing BlackBerry relationship.
The BlackBerry Incident Response team is made up of world-class consultants dedicated to handling response and containment services for a wide range of incidents, including ransomware and Advanced Persistent Threat (APT) cases.
We have a global consulting team standing by to assist you, providing around-the-clock support, where required, as well as local assistance. Please contact us here: https://www.blackberry.com/us/en/forms/cylance/handraiser/emergency-incident-response-containment
Want to learn more about cyber threat hunting? Check out the BlackBerry Research & Intelligence Team's new book, Finding Beacons in the Dark: A Guide to Cyber Threat Intelligence - now available for pre-order here.
The BlackBerry Research & Intelligence team examines emerging and persistent threats, providing intelligence analysis for the benefit of defenders and the organizations they serve.