Spyderbat Blog

Defending Linux-Based Clouds from Cryptojacking

Written by Spyderbat | May 31, 2022 8:22:00 PM

2021 saw a marked rise – 35% – in malware targeting Linux systems. To anyone familiar with recent trends in business cloud migration, this should come as no surprise. 

Between 2017 and 2021, the global cloud storage market more than doubled from $30 billion to $76 billion and is projected to balloon to $390 billion by 2028. By the end of 2021, 94% of enterprises were running workloads in the cloud. For malware designers, the explosion of cloud use and remote access points has opened a lucrative window of opportunity.

90% of clouds run on Linux, but the cybersecurity industry remains focused on handling Windows-based threats. In the meantime, attackers – cryptominers in particular – are taking advantage of this expanding and largely undefended attack surface to skim quick cash off the unprepared. Already Palo Alto Networks has found Linux-based cryptojacking operations on 23% of business cloud infrastructures.

 

Cryptominers and Linux

 Malicious cryptomining operations – or cryptojacking – are the low-risk cash grab of cybercrime. Cryptojacking uses malware to steal and monetize exposed CPU cycles in Linux cloud environments. When carried out successfully, the victims remain unaware, and the attackers instantly pocket history-free privacy coins, such as Monero and Zcash.

Unlike ransomware and other schemes to steal or expose personal data, cryptojacking doesn’t require any direct interaction between attacker and victim. This mitigates the attacker’s exposure and allows many operations to run simultaneously. Cryptocurrencies like Monero also offer miners the added benefit of being hardware-independent, providing a lower overhead than Bitcoin’s application-specific integrated circuits (ASICs). Thus with minimal investment upfront and a modest skill set in the XMRig application – the preferred Monero mining app accounting for 89% of reported incidents – cryptominers can get to work wherever they find unprotected points of ingress.

 

Spyderbat Runtime Security

 With the current network defense toolkit for Linux, security teams often lack critical capabilities for detecting perimeter breaches and maintaining system-level visibility into patchworks of highly virtualized multi-cloud systems. As attackers enhance mining malware to mimic legitimate processes and observe credible CPU tolerances, network defenders find themselves mired in a growing stack of logs for various network devices, firewalls, DNS and proxy servers.

While stitching it all together manually isn’t theoretically impossible, it is increasingly time-consuming – to the exclusion of other critical operations. That cloud structures are often ephemeral – being wiped and rebuilt on the order of days to hours – further disadvantages analysts trying to triage a variety of potential threats known to conceal a high volume of false positives.

Spyderbat tackles this challenge with an industry-first universal trace for all Linux system-level activity. Using Spyderbat’s  Behavioral Web, analysts access a visualized focused trace capturing one or more security concerns. Without pulling and comparing log data from half a dozen sources, analysts instead view Spyderbat's trace to see exactly what is happening - how the cryptojacker got it, how their malware executed, and any backdoors or other forms of persistence they established, even if these activities span across different systems, user sessions, and long periods of time.

This screenshot from Spyderbat presents a real cryptojacking attack captured from one of our honeypots. This is a patched Linux cloud droplet with only the SSH service exposed with a weak user password. It was popped within minutes.

Using Spyderbat, we can see exactly what the attacker does and the outcomes from the script executed:

1. After logging in, the cryptojacker downloads a script and makes it executable, then executes the script.

2. The first stage of the script is to run a series of commands to learn about the system and disable running services, such as:

 

/bin/grep -c processor /proc/cpuinfo

/sbin/sysctl -w vm.nr_hugepages=3

/usr/bin/systemctl stop filesystem.service

/usr/bin/systemctl stop fbackup.service

/bin/systemctl stop vsphereui.service

/usr/bin/systemctl stop vsphere.service

 

3. The next stage of the script removes files (such as service configuration files, libexec executables, and identifies and stops a long list of running processes.

 

4. The last stage of the script downloads several executables, libraries, and json content, and reloads itself as a service. 

 
Using Spyderbat’s ‘relative time’ feature, you can see in the last screenshot that the script fully executed in 11 seconds. The server is now fully owned by the cryptojacker with valuable processing cycles consumed by the services. The system is also locked out from SSH access. 

Too often cloud administrators are not aware they have been cryptojacked until they receive their monthly usage bill. In addition to financial losses, organizations lose time rebuilding images from the most recent snapshot.  

Instead of using specific detections or behavior models to identify cryptojacking, Spyderbat uses a signatureless detection method. The red dots visible in the screen shots represent Spyderbat flags. Flags represent individual detections based on known attack techniques or uncommon activities. Instead of alerting you to each detection which may result in a large number of false positives, Spyderbat automatically scores traces of causally-related activity. Scores are calculated from the # of flags, diversity of flags, breadth of activity, and other factors. Spyderbat reassesses the score of the trace with each new causal activity, whether flagged or not. In this case, Spyderbat recognized the cryptojacking attack within milliseconds based on the trace’s rapidly increasing score. 

 

Experience Spyderbat in real-world scenarios by viewing our Defend the Flag challenges.