Threat Thursday: RedLine Infostealer Update

Summary

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.

Operating System

Risk & Impact

Technical Analysis

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

Connecting to C2 Server with Net.TCP

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 in the 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:

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

C2 Communication with Binary-Translated SOAP

In addition to using MC-NMF, RedLine also uses a wide-range of other Net.TCP protocols to carry out its malicious communications.

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.

CreateSequence

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 very first byte of data is [0x06]. It means this packet format is “Sized Envelope Record,” according to MC-NMF.
• The next data [0x77] is total data size.
• The following data is the payload of Sized Envelope Record, according to MC-NMF. The format is based on MC-NBFSE because RedLine specified it when the net.TCP connection was established.
• Then it shows the total string size [0x1e] for user registered strings, based on MC-NBFSE.
• The next data is the first registered string data size [0x1d] and the following data is the registered string itself, which is the C2 server address, in this case.

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.

• There is a C2 server address in “<a:To>” tag (net[.]tcp://45[.]132[.]104[.]3:52352/).
• The value of “<Identifier>” tag is used by an Ack message such as “SequenceAcknowledgement.” We will refer the value as “session identifier” in this report.

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 “<Identifier>” 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

CheckConnect confirms that both sides have a valid session. Figure 8 shows “CheckConnect” request. It contains two important parameters.

• The “main identifer” value in the “<r:Reason>” tag and the “<r:Sequence>” tag.
• The value of “<r:MessageNumber>” tag. It increments the value if it sends a request with “main identifier” value.

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 “<r: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)

EnvironmentSettings

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.

BlockedCountry

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:

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.

This threat also looks for this same information in the following Gecko browser directories.

It also searches for the presence of Discord, FTP clients, and files related to cryptowallets.

Init

The “Init” request contains basic information on victim environments, such as:

• IP address
• OS version
• Machine name
• Screen resolution

As shown in Figure 11, the value of “ReleaseID” comes from embedded encrypted strings, as shown in Figure 12. 

Figure 12: Embedded Encrypted Strings

What Happens After Initialization

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.

Additional Payloads from RedLine C2 Server 

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:

• XMRig
• EthMiner
• Amadey
• DCRAT
• BitRAT
• Clipper
• Fabookie
• Remcos
• Async_RAT

Conclusions

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.

YARA Rule

The following YARA rule was authored by the BlackBerry Research & Intelligence Team to catch the threat described in this document:

Indicators of Compromise (IoCs)

BlackBerry Assistance

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.