Malware of the Day – IcedID Loader to ALPHV Ransomware Campaign

What is Malware of the Day?

 

Lab Setup

Malware: IcedID Loader to ALPHV Ransomware Campaign

MITRE Tactics: TA0011 Command and Control, T1219 – Remote Access Software, T1566 – Phishing, T1059.005 – Command and Scripting Interpreter, T1486 – Data Encrypted for Impact

Traffic Type: TCP

Connection Type: Reverse TCP

C2 Platform: Cobalt Strike, ScreenConnect, CSharp-Streamer

Origin of Sample: Active Countermeasures Lab

Host Payload Delivery Method: VBS Script

Target Host/Victim: 192.168.2.77 (Windows 10 Pro x64)

Cobalt Strike Server: 143.198.3.13

Cobalt Strike Beacon Delay: 300 seconds

Cobalt Strike Jitter: 99%

ScreenConnect Server: 147.75.62.184

ScreenConnect Beacon Delay: None

ScreenConnect Jitter: None

CSharp-Streamer Server: 172.208.51.75

CSharp-Streamer Beacon Delay: None

CSharp-Streamer Jitter: None

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for command and control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Preface: The Treat Hunting Mindset

As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.

The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.

Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.

By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.

 

Background

A recent campaign has distributed a forked IcedID loader via spam, ultimately leading to the deployment of ALPHV ransomware. This sophisticated operation employs various malware types to achieve sub-goals en route to its primary objective: extortion. For instance, wmiexec is used to install the ScreenConnect RMM tool, which facilitates the installation of Cobalt Strike beacons and CSharp-Streamer, a RAT used for executing a variety of scripts.

In this Malware of the Day investigation, we’ll examine this campaign using a network-based threat detection approach. We’ll utilize RITA, AC-Hunter, and other complementary open-source applications to demonstrate how these tools can detect and identify this campaign prior to the actual deployment of the ransomware, potentially averting the devastating effects of such an attack.

 

Setup

The local corporate network has a single subnet (192.168.2.0/24), containing 6 workstations (192.168.2.77, 79, 82, 87, 88, 89) all running Windows 10 – see Image 1 below. A local, dedicated Zeek sensor (192.168.2.19) running Ubuntu 20.04 pushes hourly logs to a cloud-based AC-Hunter server (64.23.195.234), which also runs Ubuntu 20.04.

 

Image 1. Simplified diagram of today’s IcedID-ALPHV case study setup.

 

Scenario + Chain-of-Infection

In today’s scenario, a threat actor (143.198.3.13, 147.75.62.184, and 172.208.51.75) successfully compromised one of the corporate workstations (192.168.2.77) via a chain of infection similar to those reported recently by The DFIR report – see Image 2 below.

 

Image 2. This excellent DFIR report on this campaign discusses all aspects of the attack in detail.

 

During a momentary lapse of judgment, an employee on this host opened an email prompting them to download and open a ZIP archive. The archive contained a benign README file and a VBS file. Upon executing the VBS file, WScript.exe was called, initiating the infection chain with the IcedID loader. The loader then immediately installed ScreenConnect, a legitimate remote monitoring and management (RMM) tool that operates over port 443.

The threat actor used this RMM tool to promptly install a Cobalt Strike beacon (port 8080), likely for additional post-exploitation capabilities and/or as a redundancy measure. Shortly after, a third payload was downloaded and executed, establishing an outbound connection via C-Sharp Steamer (port 80). This multi-function RAT enables the threat actor to perform further post-exploitation activities.

 

Network Traffic Analysis Using RITA

After the user of the beachhead host (192.168.2.77) reported a significant decrease in system performance, the threat hunting team analyzed the last 24 hours of Zeek logs using RITA. Upon careful review of the connections, the team identified three suspicious connections.

 

First Suspicious Connection

The first of these connections (see the green box in Image 3 below) was a long connection lasting approximately 17 hours and 45 minutes. Not only did this connection top our list, but it’s also one of only four that were classified as being of critical severity. Something else that’s interesting to note is that this connection has a beacon score of 10.70%. While this score is low, it is not 0% – indicating that this long connection was likely intermittent, starting, stopping, and resuming several times within the 24-hour period.

 

Image 3. RITA entry for the first suspicious connection.

 

This connection also has two threat modifiers applied to it: ‘Missing Host Header’ (orange box) and ‘Rare Signature’ (red box). Let’s briefly examine each of these in more detail.

 

Missing Host Header

A host header is an HTTP request header that specifies the domain name of the requested server. For virtual hosting, where multiple domains share a single IP address, the host header allows the server to determine which domain should handle the request.

The host header was made “mandatory” in RFC 2616 and later updated in RFC 7230. In RFC terminology, “mandatory” means required for standard compliance, but it’s not necessarily enforced at the network level. Attackers could intentionally omit it to exploit specific behaviors, either to evade detection or as a potential attack vector.

 

Rare Signature

A User Agent (or “signature”) is a string sent by a client to identify itself to servers, providing information about the client’s software and system. For HTTP connections, RITA compares outgoing User Agent strings from each application. If a connection uses a unique User Agent string—one that appears only once—RITA applies the ‘Rare Signature’ modifier.

This modifier should pique a threat hunters’ interest, as attackers often struggle to predict user agents on target systems without extensive reconnaissance. Many attackers are careless when assigning user agents in C2 configs, since few defensive tools besides RITA and AC-Hunter report unique uses like this.

 

Second Suspicious Connection

The second suspicious connection (see the green box in Image 4 below) was identified as a beacon connection with a high score of 85.90%. It was also one of only four connections classified as being of critical severity.

 

Image 4. RITA entry for the second suspicious connection.

 

This connection also has two threat modifiers applied to it. As with the previous connection, the User Agent string used is unique (‘Rare Signature’). Additionally, it received the ‘MIME Type Mismatch’ modifier (red box).

 

MIME Type Mismatch

A MIME type mismatch occurs when there’s a discrepancy between the declared content type and the actual data in an HTTP/HTTPS response. When requesting data via HTTP/HTTPS, the server provides both the requested data (in the body) and a description of the data type (in the header).

Typically, these should match. However, when they don’t—for example, if the body contains JSON data but the header’s ‘Content-Type’ field reports it as image/jpeg—it’s known as a MIME type mismatch.

While often due to misconfigurations, MIME type mismatches can indicate potentially malicious activity. In C2 scenarios, a server might send encoded executable content while declaring it as harmless plain text.

 

Third Suspicious Connection

Our final suspicious connection (see the green box in Image 5 below) was also identified as a long connection, lasting 22 hours and 12 minutes. However, it wasn’t classified as critical severity—in fact, it only ranks tenth on our list. So why did this connection stand out to our threat hunters as particularly suspicious?

 

Image 5. RITA entry for the third suspicious connection.

 

It’s due to the total amount of data transferred – see the red box. A total of 622.76 MiB was transferred in a 24-hour period. When it comes to legitimate long connections for background services (such as updates, notifications, system time synchronization, telemetry etc), we typically don’t expect hundreds of MiBs to be sent in a 24-hour period. Given this unusual volume, it’s incumbent upon us to investigate further using our other primary tool – AC-Hunter.

 

Network Traffic Analysis Using AC-Hunter

Before continuing our investigation in AC-Hunter, it’s worth noting that we’ll primarily use it to delve deeper into the three connections identified in RITA. However, this isn’t the only valid approach. We could also review all connections in AC-Hunter to see if something stands out that didn’t catch our attention in RITA. For this case however, we’ll focus on the three previously identified connections, knowing we can always return to review all data in AC-Hunter anew if needed.

Upon opening AC-Hunter, we land on the dashboard (Image 6 below), providing an overview of our data. Since our potentially-compromised local host is 192.168.2.77, we select this host IP (green box). As RITA classified the three connections of interest as beacon (143.198.3.13) and long connections (147.75.62.184 and 172.208.51.75), we’ll select these modules on the right-hand side (orange box and red box, respectively).

 

Image 6. The AC-Hunter Dashboard.

 

Beacons Module

After scrolling through the list of connections (light blue box) in our Beacons module (Image 7 below), we locate the outbound host of interest – 143.198.3.13.

 

Image 7. AC-Hunter’s Beacons module.

 

The hourly-connection graph (green box) reveals that while most hourly connections are consistent, there’s a spike between 15:06 and 17:06. This spike indicates a shorter beacon delay during this period compared to the rest of the time. This typically suggests higher rates of activity. While speculative, it’s reasonable to surmise that the threat actor likely performed specific activities during these few hours, after which the connection entered a “low and slow” mode to maintain the connection without further activity.

During the subsequent hours, we observe a “flat top” in the graph (18:08 to 12:08), indicating a consistent hourly connection frequency, which is typical of C2 communication.

Our histogram (red box) in this case is unusual and doesn’t display the bell curve typically associated with C2 connections. To help decode what’s going on here, let’s conceptually break this graph into two components: the large number of connections at 0 seconds (meaning less than 1 second, as AC-Hunter rounds down), and the numerous connections spread out from 0 to 300 seconds.

It’s likely that, as speculated earlier, the high number of connections at 0 seconds correlates to the period of relatively higher activity – corresponding to the spike in our hourly-connection graph. Conversely, the connections spread evenly over 300 seconds suggest that the beacon then likely entered a “low and slow” mode by changing the delay to 300 seconds, with a maximum jitter of 99%. This results in the connections being distributed equally over the entire period, as observed.

As we noted in the previous article, when beacon connections are spread over a wider period, the typical bell curve associated with C2 activity tends to disintegrate. This “disintegrated shape” is fairly uncommon because it’s impractical for threat actors during normal operations. In this specific case, an operator would be uncertain whether they need to wait 1 second, 5 minutes, or any duration in between before reconnecting to their target.

It’s useful for us to note that from an attacker’s perspective, there’s a trade-off between operational efficiency and minimizing network noise. For this reason, they might alternate between two modes: short bursts of activity with low delay/jitter (optimizing for operational efficiency), interspersed with longer periods of inactivity using high delay/jitter settings (optimizing for risk avoidance).

Let’s now turn our attention to the other two connections by navigating to the Long Connections module.

 

Long Connections

Upon accessing the Long Connections module, we observe only three connections lasting more than 5 hours within the last 24 hours (Image 8 below). The first is to 172.172.255.217 (Microsoft), while the remaining two are our connections of interest, highlighted in the green and red boxes respectively.

 

Image 8. AC-Hunter’s Long Connections module.

 

Let’s focus on the connection to 147.75.62.184 (green box), which we identified in RITA as having an unusually large amount of transferred data. Given the questionable legitimacy of this data transfer, we’ll perform an IP reputation check by clicking on it and selecting from the various external reputation databases AC-Hunter provides – as shown in Image 9 below.

 

Image 9. AC-Hunter provides a number of reputation checks in its UI.

 

Upon checking AlienVault, we see this domain is associated with ScreenConnect – as shown in the red box in Image 10 below. While ScreenConnect is a legitimate RMM tool, it’s known to be misused by threat actors. However, let’s refrain from drawing conclusions prematurely and consult additional reputation checks.

 

Image 10. AlientVault results.

 

AbuseIPD reports this IP as belonging to Equinix Services Inc – as shown in the green box in Image 11 below.

 

Image 11. AbuseIPD results.

 

A simple Google search reveals that ScreenConnect’s creator/owner is ConnectWise, not Equinix Services Inc. However, it’s possible that ConnectWise outsources some operational aspects. A follow-up Google search for “Equinix + ConnectWise” confirms this: the top result is a ConnectWise document from 2022 stating that Equinix is used for third-party data center services – as shown in Image 12 below.

 

Image 12. Google search result indicating the connection between Equinix and ScreenConnect.

 

One final action we can perform to ensure we are indeed dealing with ScreenConnect is to have a quick peek at the process responsible for mediating this connection. We can use System Informer (formerly known as Process Hacker) to look at all our connections, whereafter we can see which process is responsible for the connection to 147.75.62.184 over port 443 – see Image 13 below.

 

Image 13. The System Informer Connections tab correlates processes with network connections.

 

Here we can indeed see the ScreenConnect.ClientServices.exe process is responsible for mediating the connection to 147.75.62.184. This confirms that this connection is related to the RMM tool ScreenConnect. While ScreenConnect is a legitimate service and not inherently malware, it can, like AnyDesk and many other RMM tools, be abused by threat actors.

The critical follow-up question is: Is ScreenConnect a tool sanctioned for use by the company? In this case, the answer is unfortunately no, which elevates our suspected compromise to a confirmed one. In other words – we’ve now reached a point where the probability of a compromise is high enough that our role as threat hunters concludes with one final action – notifying the Incident Response team.

 

Conclusion

Today’s Malware of the Day investigation presented three important insights:

  1. Sophisticated campaigns may employ multiple post-exploitation communication tools.
  2. Whether or not something should be considered malware depends on context.
  3. Ransomware is not an isolated event, but the culmination of an entire series of events.

 

Sophisticated campaigns may employ multiple post-exploitation communication tools.

In previous cases we’ve seen how threat actors may use multiple channels in a campaign – for example by employing multiple redirectors to either help obfuscate the traffic, and/or to provide redundancy. But these cases still mostly employed a single tool. It’s thus worth appreciating that sophisticated threat actors may go one step further and employ not just multiple channels, but multiple tools.

In this IcedID-AlphV we observed the use of three: the popular C2 application Cobalt Strike, the remote access trojan (RAT) CSharp-Streamer, and the legitimate RMM tool ScreenConnect.

These multiple communication channels likely serve different purposes:

  1. Cobalt Strike appears to have been used for short bursts of specific activity, and as a backup via a “low and slow” beacon signal.
  2. ScreenConnect, offering direct system control, is often used as part of Ransomware-as-a-Service (RaaS) operations since the so-called “affiliates” are typically not technically proficient individuals, thus leveraging a RMM allows for intuitive system manipulation without command-line expertise.
  3. CSharp-Streamer, a multi-function RAT provides a relatively simple “plug and play” application to perform the gamut of required post-exploitation tasks.

 

This is important to note because, if we were to come across a suspicious connection in RITA/AC-Hunter, that does not mean that we shouldn’t look any further!

 

Whether or not something should be considered malware depends on context.

Are outbound connections to api.slack.com good or bad? It depends on context. Is the use of PsExec to run commands on a remote system good or bad? It depends on context. Is the use of a RMM tool to control another system good or bad? You’ve guessed it – it depends on context.

In the current era of LOLBAS and esoteric C2 channels, the line between good and evil is increasingly blurred. The development of sophisticated IDS and EDR technologies has led to the wide-spread co-opting of legitimate tools/domains to serve the nefarious ends of threat actors.

This means that as Threat Hunters we’ll spend the majority of our time not looking for things that are “definitely evil”, nor disregarding things that are “definitely good”, but scrutinizing things that could be either (see Image 14 below). Context is king.

 

Image 14. “The knife is neither good nor bad; its use determines its nature.” – Anonymous Proverb

 

Ransomware is not an isolated event, but the culmination of an entire series of events.

When it comes to ransomware attacks, what makes headlines is often just the tip of the iceberg. Beneath the surface lies a complex campaign of various malware types and techniques, which all contributed to creating the condition which then ultimately culminates in the deployment of ransomware. It’s useful to frame these events in three broad, consecutive categories – see Image 15 below.

 

Image 15. Extortion (such as Ransomware) typically begins with the Initial Intrusion, followed by numerous Post-Compromise activities

 

The Initial Access phase (such as phishing, exploitation of critical vulnerabilities, and purchase via Initial Access Brokers), represent a very brief moment in time and is subject not only to very high rates of technological flux – by the time a critical vulnerability is patched, two new ones have been discovered – but also to human-error.

Thus, despite the great strides made in the last decade with innovations in Intrusion Detection Systems (IDS) and Endpoint Detection and Response (EDR) technologies, the Initial Access phase is in some sense a problem that may never be fully solved. Conversely, once the stage has been reached where ransomware is actually being deployed (Extortion phase), it may already be too late.

Our best opportunity to prevent a ransomware attack may thus lie in the Post-Compromise phase. Not only is the time spent here (i.e. Dwell time) typically the longest, but the activities may also be the noisiest. And though the specifics of the tools and techniques change over time, there are in some sense universal patterns that are difficult-to-impossible to avoid from the attackers POV.

For example with C2 communication, despite whatever specific application is being used, it will most likely be outbound communication using one of a few types of protocols and producing predictable connection patterns. At the end of the day, sending packets over wires is unavoidable, so the best opportunity to prevent ransomware may be through the identification of post-exploitation activities using Network-based Threat Hunting with tools like RITA and AC-Hunter.

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

IcedID-ALPHV 1 hour capture
icedid_alphv_1h.pcap
File Size: 31.8 MB
SHA-256 Hash: AE420D987512E7643BAA738100EBF2EBCE72E806CA0AB220186AFE561FACD1D6

IcedID-ALPHV 24 hour capture
icedid_alphv_24h.pcap
File Size: 1.3 GB
SHA-256 Hash: 857A5AC52F31FDDF1D429C3945974D90D54559FC96BC063CFD2D2DA3351D8C96

 

Zeek Logs

If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

Importing Zeek logs into AC-Hunter example:

ssh into your AC-Hunter server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/icedid-alphv-zeek-logs/

Then run the following command:

For AC-Hunter v6.x and RITA v4.x and earlier:

rita import /tmp/icedid-alphv-zeek-logs/*.log icedid-alphv

For RITA v5.x+:

rita import --logs=/tmp/icedid-alphv-zeek-logs/*.log --database=icedid-alphv

 

You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “icedid-alphv” you can select and view.

24 Hour Zeek Logs
icedid_alphv_zeek_logs.zip
Size: 7.8 MB
SHA256 Checksum: E1FBD2E1A40175B1EE6A262C587EF08EDF270E589583F53358D94E65FB1059FA

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?
You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

A huge thanks to Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!

 

 

Interested in threat hunting tools? Check out AC-Hunter

Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!

Share this:
AC-Hunter Datasheet
AC-Hunter Personal Demo
What We’re up To
Archives