Updated September 12, 2022: New information has been added to the initial access and payload analysis sections in this blog, including details on a rootkit component that we found while investigating a XorDdos sample we saw in June 2022.
In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in 2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux endpoints and servers as well as its usage of XOR-based encryption for its communications.
XorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices, XorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to perform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated in August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can also be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.
Botnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables encrypted communications over insecure networks for remote system administration purposes, making it an attractive vector for attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and installs XorDdos on the target device.
XorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion capabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions.
XorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other dangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and distributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.
Microsoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular attacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our in-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy malware.
This blog post covers the following topics:
XorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential combinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed sign-in attempts on devices successfully infected by the malware:
Our analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file to temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus concealing the source of infection during forensic analysis.
The second method involves running a bash script that performs the following activities via the command line:
| Sensitive File | Description |
|---|---|
| /root/.bash_history | Contains the commands that were run earlier |
| /var/log/wtmp | Contains login related record for users |
| /var/log/btmp | Contains record of failed login attempt |
| /var/log/lastlog | Contains the recent login information for users |
| /var/log/secure | Contains information related to security such as logs for authentication failure, sudo logins, and authorization privileges |
| /var/log/boot.log | Contains information related to system boot and message logged via system startup processes |
| /var/log/cron | Contains information related to cron job launch, success and failure error logs |
| /var/log/dmesg | Contains information related to kernel ring buffer messages, hardware devices, drivers, etc. |
| /var/log/firewalld | Contains logs related to firewall activities |
| /var/log/maillog | Contains information related to a mail server running on the system |
| /var/log/messages | Contains generic system activity messages |
| /var/log/spooler | Contains messages from usenet |
| /var/log/syslog | Contains generic system activity messages |
| /var/log/yum.log | Contains the package logs related to installation\remove\update activities done via yum utility |
Whichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos malware. In the next section, we do a deep dive into the XorDdos payload.
Other XorDdos variants that we recently saw in our investigations use this bash script installation method to either download or build its rootkit remotely. This installation method differentiates itself by matching the kernel build of the target device with the rootkit available on the attacker’s command and control (C2) server.
After enumerating the target device, the script communicates with the attacker’s C2 server, and checks if a rootkit that matches the kernel build of the target device exists on the server. If it finds an existing rootkit that matches with the target device, the script downloads the rootkit. The following steps initiate the matching and downloading of the XorDdos malware and rootkit:
If the kernel build of the target device does not match any of the rootkits on the attacker’s server, the bash script initiates the following steps to build and compile the rootkit remotely:
The XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug symbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier to debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this case, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part of the .strtab section in the ELF file:
The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.
XorDdos contains modules with specific functionalities to evade detection, as detailed below.
Daemon processes
A daemon process is a process that runs in the background rather than under the control of users and detaches itself from the controlling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos trojan uses daemon processes, as detailed below, to break process tree-based analysis:
XOR-based encryption
As its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode encoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated data used across the malware’s various modules to conduct its activities.
| Encrypted strings | Decoded value |
|---|---|
| m7A4nQ_/nA | /usr/bin/ |
| m [(n3 | /bin/ |
| m6_6n3 | /tmp/ |
| m4S4nAC/n&ZV\x1aA/TB | /var/run/gcc.pid |
| m.[$n__#4%\C\x1aB]0 | /lib/libudev.so |
| m.[$n3 | /lib/ |
| m4S4nAC/nA | /var/run/ |
| !#Ff3VE.-7\x17V[_ | cat resolv.conf |
| <Encrypted_Remote_URL> | hxxp://aa.hostasa[.]org/config.rar |
Process name spoofing
When a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument is always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and overrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.
Kernel rootkit
Some XorDdos samples install a kernel rootkit, while others embed the rootkit in the XorDdos binary. Upon execution, the XorDdos binary drops the embedded rootkit component into the disk.
A rootkit is a kernel module that hides the presence of malicious code by modifying kernel data structures. The XorDdos kernel rootkit generally has the following capabilities:
Based on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by open-source projects like Suterusu and Rooty.
XorDdos attempts to hide itself by invoking its rootkit. The user mode malware calls the function getself(), which invokes readlink() to fetch the location of the malware file image on disk.
After this step, the malware tries to read the contents of its image file and loads it into a memory buffer, then sends a request to unhide() the process and deletes the image on disk. The technique allows XorDdos to bypass detection or minimize its malicious footprint.
The XorDdos rootkit parses the in-kernel list of loaded modules to remove itself and the protected malware from the list. This approach prevents tools like Ismod from listing kernel-loaded modules.
The following table describes the symbols found in the rootkit and their corresponding functionalities:
| Function name | Description |
|---|---|
| give_root | Provides a root privilege by setting a new set of credentials and assigning its UID, GID to “0” |
| module_hide | Hides the rootkit kernel module |
| module_show | Unhides the rootkit kernel module |
| get_udp_seq_show | Hides the UDP4 connection by hooking /proc/net/udpHides the UDP6 connection by hooking /proc/net/udp6 |
| get_tcp_seq_show | Hides the TCP4 connection by hooking /proc/net/tcpHides the TCP6 connection by hooking /proc/net/tcp6 |
| hide_udp4_port | Adds a provided port to a list of hidden UDP4 ports |
| unhide_udp4_port | Deletes a provided port from a list of hidden UDP4 ports |
| hide_udp6_port | Adds a provided port to a list of hidden UDP6 ports |
| unhide_udp6_port | Deletes a provided port from a list of hidden UDP6 ports |
| hide_tcp4_port | Adds a provided port to a list of hidden TCP4 ports |
| unhide_tcp4_port | Deletes a provided port from a list of hidden TCP4 ports |
| hide_tcp6_port | Adds a provided port to a list of hidden TCP6 ports |
| unhide_tcp6_port | Deletes a provided port from a list of hidden TCP6 ports |
| unhide_allz | Iterates list of all hidden ports and deletes all entries |
| firewall_acceptip | Adds an IP address provided to accept_ips list |
| unfirewall_acceptip | Deletes a provided entry from accept_ips list |
| firewall_dropip | Adds a provided IP address to drop_ips list |
| unfirewall_dropip | Deletes a provided IP address to drop_ips list |
| hide_proc | Adds a provided entry to hidden_procs list |
| unhide_proc | Deletes a provided entry to hidden_procs list |
Process and port hiding
The malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in evading rule-based detections.
The /proc filesystem contains information related to all running processes. A user-mode process can get any process specific information by reading the /proc directory that contains the subdirectory for each running process on the system, such as:
Running the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running processes as part of the ps command.
> strace -e open ps open(“/proc/3922/status”, O_RDONLY) = 6 open(“/proc/4324/stat”, O_RDONLY) = 6 open(“/proc/4324/status”, O_RDONLY) = 6 open(“/proc/5559/stat”, O_RDONLY) = 6 open(“/proc/5559/status”, O_RDONLY) = 6 open(“/proc/5960/stat”, O_RDONLY) = 6 open(“/proc/5960/status”, O_RDONLY) = 6 open(“/proc/5978/stat”, O_RDONLY) = 6 open(“/proc/5978/status”, O_RDONLY) = 6
If the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.
In this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and output control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate between the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its IOCTL calls from other IOCTL calls in the system.
Along with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the second entry stores the value to act on, such as $pid.
| Command | Usage |
|---|---|
| 0 | Check if its rootkit driver is present |
| 1, 2 | Hide or unhide <PID> |
| 3 | Hide <port> |
Hiding network connections
The rootkit also leverages kernel hooking to disrupt the regular invocation of various kernel system calls by substituting the original system call handler in the sys_call_table with its own. The hook functions ensure that the events associated with XorDdos’s malicious activity are filtered out, thus evading detection.
The /proc/net interface provides information about currently active TCP connections and is implemented by kernel APIs tcp4_seq_show() and tcp6_seq_show() .
Utilities, such as netstat, acquire TCP/UDP connection information from files named /proc/net/tcp and /proc/net/udp. These files contain one entry per line, each indicating the source and destination port, the source and destination IP addresses, and other relevant information about the active connection.
The rootkit replaces the default read() system call with hook functions, filters the file read entries, and skips the port it intends to hide, further obfuscating C2 communications.
The following table lists kernel APIs and their hook names used by the rootkit:
| Kernel API | Hooked function by rootkit | Function description |
|---|---|---|
| tcp4_seq_show() | n_tcp4_seq_show() | Hiding /proc/net/tcp, TCPv4 connection |
| tcp6_seq_show() | n_tcp6_seq_show() | Hiding /proc/net/tcp6, TCPv6 connection |
| udp4_seq_show() | n_ udp4_seq_show() | Hiding /proc/net/udp, UDPv4 connection |
| Udp6_seq_show() | n_ udp6_seq_show() | Hiding /proc/net/udp6, UDPv4 connection |
XorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon system startup, as detailed below.
Init script
The malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the system starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions, and dependencies.
Cron script
The malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the following content:
It then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:
System V runlevel
A runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style operating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system configuration and allows access to a different combination of processes. Some system administrators set a system’s default runlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is operational. The /etc/rc<run_level> directory contains symbolic links (symlinks), which are soft links that point to the original file. These symlinks point to the scripts that should run at the specified runlevel.
The malware creates a symlink for the init script dropped at the location /etc/init.d/<base_file_name> with the directories associated with runlevels 1 through 5 at /etc/rc<run_level>.d/S90<base_file_name> and /etc/rc.d/rc<run_level>.d/S90<base_file_name>.
Auto-start services
The malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s LinuxExec_Argv2 subroutine runs the system API with the provided arguments.
The commands chkconfig –add <service_name> and update-rc.d then add a service that starts the daemon process at boot.
XorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes its operation more robust and stealthy. The malware first runs without any argument and then later runs another instance with different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.
Before handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its full process path. The full path is used later to create auto-start service entries and read the file’s content.
In this section, we will cover the main tasks carried out as part of the different arguments provided:
1: Standard code path without any provided arguments
This code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of the entries created in system start-up locations.
The malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these locations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.
It also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the following steps, which modify the file hash to make every file unique:
After modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.
2: Clean-up code path
In this code path, the malware runs with another argument provided as the PID, for example:
Using the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check for another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the fork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by the init process, which disconnects it from the process tree and acts as an anti-forensic technique.
Additionally, it performs the following tasks on a provided $pid:
3: Process name spoofing code path
The malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:
The fake commands can include:
In this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line at runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk related to the current process.
It then enters a five-second loop to perform the following checks:
4: Known locations code path without any provided arguments
This code path is similar to the standard code path, with the main difference being that the malware runs from one of the following locations:
Once it runs from one of these locations, the malware calls the following functions to perform various tasks:
As mentioned in the XOR-based encryption section, the encoded string m7A4nQ_/nA translates to the folder path /usr/bin when decoded with the multi-byte key 0xBB2FA36AAA9541F0. The /usr/bin folder path is where the rootkit is dropped.
The dropped rootkit is further inserted into the Linux kernel module using the insmod command. This is followed by the removal of the dropped rootkit from the disk.
XorDdos uses /proc/rs_dev character device to communicate with the rootkit. It calls the CheckLKM() function to see if the rootkit meets the installation requirements, such as an exact kernel header match and no technologies present that can block the rootkit’s installation, like secure boot or enforced signed loadable kernel module (LKM) loading.
XorDdos attempts to open /proc/rs_dev. If the Linux kernel module interface is up, XorDdos sends an IOCTL request with the unique identifier 0x9748712 with argument “0” to open two-way communication between the XorDdos binary and its rootkit.
After creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a cyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is initialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is used to maintain concurrency between threads accessing a shared object, such as kill_cfg data.
The malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP connection, and retrieving kill_cfg data.
kill_process
The kill_process thread performs the following tasks:
tcp_thread
The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:
| Command | Job |
|---|---|
| 2 | Stop |
| 3 | Create a thread pool for launching DDoS attacks |
| 6 | Download file |
| 7 | Update file |
| 8 | Send system information to the C2 server |
| 9 | Get configuration file to stop processes |
daemon_get_killed_process
The daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier (hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30 minutes.
The malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates threads with twice the number of processors found on the device.
Invoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands received from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.
| Command | Function | Job |
|---|---|---|
| 0x4 | fix_syn | SYN flood attack |
| 0x5 | fix_dns | DNS attack |
| 0xA | fix_ack | ACK flood attack |
XorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system architectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a number of potential targets.
Adept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and performing DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems. Moreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.
XorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with comprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft Defender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation antimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat data, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring, Microsoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes detecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a world-writable location, and any potential follow-on activities on endpoints.
Defenders can apply the following mitigations to reduce the impact of this threat:
As threats across all platforms continue to grow in number and sophistication, security solutions must be capable of providing advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will continue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting all the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.
Microsoft Defender for Endpoint detects and blocks XorDdos’s installer script and rootkit binary as the following malware:
When XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain, including the process tree, file information, user information, and prevention details.
The timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the MITRE ATT&CK techniques and tactics, remediation status, and event entities graph.
Events with the following titles indicate threat activity related to XorDdos:
To locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center:
Failed sign-ins
DeviceLogonEvents
| where InitiatingProcessFileName == "sshd"
and ActionType == "LogonFailed"
| summarize count() by dayOfYear = datetime_part("dayOfYear", Timestamp)
| sort by dayOfYear
| render linechart
Creation of the XorDdos-specific dropped files
DeviceFileEvents
| extend FullPath=strcat(FolderPath, FileName)
| where FullPath in ("/etc/cron.hourly/gcc.sh", "/lib/libudev.so.6", "/lib/libudev.so", "/var/run/gcc.pid")
Command-line of malicious process
DeviceProcessEvents | where ProcessCommandLine contains "cat resolv.conf"
| File name: | HFLgGwYfSC.elf |
| File size: | 611.22 KB (625889 bytes) |
| Classification: | DoS:Linux/Xorddos.A |
| MD5: | 2DC6225A9D104A950FB33A74DA262B93 |
| Sha1: | F05194FB2B3978611B99CFBF5E5F1DD44CD5E04B |
| Sha256: | F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432 |
| File type: | ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped |
| First submission in VT: | 2022-01-25 05:32:10 UTC |
| Dropped file path | File type | SHA-256 |
|---|---|---|
| /etc/init.d/HFLgGwYfSC.elf | Shell Script | 6E506F32C6FB7B5D342D1382989AB191C6F21C2D311251D8F623814F468952CF |
| /etc/cron.hourly/gcc.sh | Shell Script | CBB72E542E8F19240130FC9381C2351730D437D42926C6E68E056907C8456459 |
| /lib/libudev.so | ELF | F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432 |
| /run/gcc.pid | Text | 932FEEF3AB6FCCB3502F900619B1F87E1CB44A7ADAB48F2C927ECDD67FF6830A |
| /usr/bin/djtctpzfdq | ELF | 53F062A93CF19AEAA2F8481B32118A31B658A126624ABB8A7D82237884F0A394 |
| /usr/bin/dmpyuitfoq | ELF | 798577202477C0C233D4AF51C4D8FB2F574DDB3C9D1D90325D359A84CB1BD51C |
| /usr/bin/fdinprytpq | ELF | 2B4500987D50A24BA5C118F506F2507362D6B5C63C80B1984B4AE86641779FF3 |
| /usr/bin/jwvwvxoupv | ELF | 359C41DA1CBAE573D2C99F7DA9EEB03DF135F018F6C660B4E44FBD2B4DDECD39 |
| /usr/bin/kagbjahdic | ELF | E6C7EEE304DFC29B19012EF6D31848C0B5BB07362691E4E9633C8581F1C2D65B |
| /usr/bin/kkldnszwvq | ELF | EF0A4C12D98DC0AD4DB86AADD641389C7219F57F15642ED35B4443DAF3FF8C1E |
| /usr/bin/kndmhuqmah | ELF | B5FBA27A8E457C1AB6573C378171F057D151DC615D6A8D339195716FA9AC277A |
| /usr/bin/qkxqoelrfa | ELF | D71EA3B98286D39A711B626F687F0D3FC852C3E3A05DE3F51450FB8F7BD2B0D7 |
| /usr/bin/sykhrxsazz | ELF | 9D6F115F31EE71089CC85B18852974E349C68FAD3276145DAFD0076951F32489 |
| /usr/bin/tcnszvmpqn | ELF | 360A6258DD66A3BA595A93896D9B55D22406D02E5C02100E5A18382C54E7D5CD |
| /usr/bin/zalkpggsgh | ELF | DC2B1CEE161EBE90BE68561755D99E66F454AD80B27CEBE3D4773518AC45CBB7 |
| /usr/bin/zvcarxfquk | ELF | 175667933088FBEBCB62C8450993422CCC876495299173C646779A9E67501FF4 |
| /tmp/bin/3200 | ELF (rootkit) | C8F761D3EF7CD16EBE41042A0DAF901C2FDFFCE96C8E9E1FA0D422C6E31332EA |
| Installer script | Bash script | 8be8c950d8701ef1149c547ea3f949ea78394787ad1e19fc0eaa7bd7aeb863c2 |
| /usr/bin/djtctpzfdq | ELF | 53f062a93cf19aeaa2f8481b32118a31b658a126624abb8a7d82237884f0a394 |
| /usr/bin/jwvwvxoupv | ELF | 359c41da1cbae573d2c99f7da9eeb03df135f018f6c660b4e44fbd2b4ddecd39 |
| /usr/bin/kkldnszwvq | ELF | ef0a4c12d98dc0ad4db86aadd641389c7219f57f15642ed35b4443daf3ff8c1e |
| /usr/bin/zvcarxfqul | ELF (rootkit) | 483451dcda78a381cc73474711bf3fcae97bd088f67b5a7e92639df52ef5ef25 |
| /usr/bin/zvzvmpqnv | ELF (rootkit) | c8f761d3ef7cd16ebe41042a0daf901c2fdffce96c8e9e1fa0d422c6e31332ea |
Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or
with Saurabh Swaroop
Microsoft 365 Defender Research Team
At the CYBERWARCON 2023 conference, Microsoft and LinkedIn analysts are presenting several sessions detailing analysis across multiple sets of threat actors and related activity, demonstrating Microsoft Threat Intelligence’s ongoing efforts to track threat actors, protect customers, and share information with the wider security community.
A set of memory corruption vulnerabilities in the ncurses library could have allowed attackers to chain the vulnerabilities to elevate privileges and run code in the targeted program's context or perform other malicious actions.
Microsoft has uncovered an attack leveraging custom and open-source tools to target internet-facing IoT devices and Linux-based systems. The attack involves deploying a patched version of OpenSSH on affected devices to allow root login and the hijack of SSH credentials.
Microsoft is excited to announce that we are shifting to a new threat actor naming taxonomy aligned to the theme of weather. The complexity, scale, and volume of threats is increasing, driving the need to reimagine not only how Microsoft talks about threats but also how we enable customers to understand those threats quickly and with clarity.