One of the most common vulnerabilities found in modern software, memory corruption vulnerabilities, can allow attackers to gain unauthorized access to systems and data by modifying a program’s memory. The impact of memory corruption vulnerabilities can range from leaking sensitive information and performing a simple denial-of-service (DoS) to elevating privileges and executing arbitrary code.

Microsoft has shared these vulnerabilities with the relevant maintainers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for these vulnerabilities, now identified as CVE-2023-29491 with a CVSS score of 7.8, have been successfully deployed by the maintainers of the ncurses library, Thomas E. Dickey, in commit 20230408. We wish to thank Thomas for his professionalism and collaboration in resolving those issues. We also worked with Apple on addressing the macOS-specific issues related to these vulnerabilities, and we thank Apple for their response and partnership. Lastly, during our analysis, a researcher named Gergely Kalman engaged us privately over Twitter and contributed relevant use cases in addition to his own hand-coded fuzzer. We thank Gergely for his contributions in advancing this research and community engagement. Users of ncurses are encouraged to update their instances and systems.

In this blog post, we share information about ncurses and the discovered memory corruption vulnerabilities. We also share this research to emphasize the importance of collaboration among researchers, industry partners, and the larger security community in the effort to improve security for all.

Understanding terminal databases

Terminal databases are used by ncurses to be terminal-independent, meaning the capabilities of the terminal are not required to be known ahead-of-time. Terminal databases contain a set of capabilities that ultimately determine the control characters that are sent to the terminal (instructing the terminal to perform basic interactions) and describe various properties of the terminal. Terminal databases come in two major formats: the older and less commonly used termcap (terminal capability) format, and the improved terminfo format. Since terminals can differ on the types of control characters they expect and the operations they support, terminfo became necessary to address this discrepancy.  In its textual syntax, capabilities are separated by commas, and come in three forms:

• Boolean capabilities: for example, the am capability specifies that the terminal supports automatic margins. In the terminfo textual syntax, Boolean capabilities appear by their name alone, without any additions.
• Numeric capabilities: for instance, the cols capability contains the number of columns in a line. In the terminfo textual syntax, numeric capabilities are recognized with a “#” symbol after their name, followed by the numeric value, such as “cols#80”.
• String capabilities: for instance, the clear capability describes the control character that should be transmitted to the terminal to clear the screen. In the terminfo textual syntax, string capabilities are recognized with a “=” symbol after their name, followed by the string value, such as “clear=\E[H\E[2J”.

POSIX systems usually pre-ship with tens of such databases. It’s possible to parse the capabilities of the current database with the infocmp utility:

Environment variable poisoning

Every modern operating system contains a set of environment variables that might affect the behavior of programs. A well-known technique for attackers is to manipulate those environment variables to cause programs to perform actions that would benefit their malicious purposes, hence “poisoning” them. There have been multiple cases of environment variable poisoning in the past, for instance:

• CVE-2023-22809: users were allowed to elevate their privileges by poisoning the EDITOR environment variable (and similar other environment variables) and running sudoedit, which ultimately allowed them to edit arbitrary files.
• CVE-2022-0563: the environment variable INPUTRC is indirectly used by the chsh and chfn set-UID Linux binaries. It was discovered that INPUTRC could be poisoned to dump the contents of sensitive files on the system.
• CVE-2020-9934: the HOME environment variable could be poisoned to bypass Transparency, Consent, and Control (TCC) on macOS, thus gaining access to otherwise inaccessible sensitive data. We have found a similar bypass and reported it in 2021.
• CVE–2023-32369: the PERL5OPT and BASH_ENV environment variables could be poisoned to bypass System Integrity Protection (SIP) in macOS, thus elevating privileges. We have reported the vulnerability in April 2023.
• The LD_PRELOAD environment variable is commonly used in Linux for code injection purposes.
• The WINDIR and SYSTEMROOT environment variables have been used in the past on Windows for bypassing User Account Control (UAC).

We have discovered that during initialization, the ncurses library searches for several environment variables, including an environment variable similarly named TERMINFO. When using terminfo databases, the program consults a fixed directory path unless a TERMINFO environment variable is present, which instead points the program to an alternative directory that contains compiled terminfo database files. Moreover, there are interesting common programs that use ncurses, most notably top on macOS, which is a set-UID binary (which runs with elevated privileges) that also uses the TERMINFO environment variable. Therefore, finding vulnerabilities in ncurses have the potential to affect many programs and possibly elevate privileges. It’s noteworthy that the potential of poisoning the TERMINFO environment variable was highlighted several times in the past (for example, here), but we have not seen comprehensive research on the topic of terminfo capabilities for offensive security purposes.

For completeness, while this blog post focuses on how attackers could poison the TERMINFO environment variable to potentially exploit ncurses vulnerabilities, the HOME environment variable could have been similarly manipulated. Assuming the TERMINFO environment variable was never defined, ncurses looks for a $HOME/.terminfo directory. This could have been abused by planting a .terminfo directory at an arbitrary path and poisoning the HOME environment variable, so the technique is quite similar.

Stack-based terminfo capabilities

The terminfo capabilities are richer than they first appear. In a nutshell, capabilities are allowed to receive up to nine parameters (p1-p9) and use them in a stack data structure. Furthermore, capabilities work with a stack-like structure and instructions that can push (place an item in the stack) and pop (get an item from the stack) data, perform logical-arithmetic operations, and even support conditions. Here are some examples:

While not Turing-complete, terminfo offers functionality that resembles very basic programming. Due to the complicated logic required by ncurses, security issues are expected to be found, and indeed there have been numerous ncurses vulnerabilities in the past.

It’s interesting to note that while the version of ncurses we checked was 6.4 (latest at the time of research), the ncurses version on macOS was 5.7, but had several security-related patches maintained by Apple. Nevertheless, all our findings are true for all ncurses versions, thus affecting both Linux and macOS.

Discovered vulnerabilities

We discovered several memory corruption vulnerabilities through code auditing and fuzzing. In addition to using our own AFL++ based fuzzer, the use cases contributed by Gergely Kalman assisted in advancing this research.

The discovered vulnerabilities could have been exploited by attackers to elevate privileges and run code within a targeted program’s context. Nonetheless, gaining control of a program through exploiting memory corruption vulnerabilities requires a multi-stage attack. The vulnerabilities may have needed to be chained together for an attacker to elevate privileges, such as exploiting the stack information leak to gain arbitrary read primitives along with exploiting the heap overflow to obtain a write primitive.

Stack information leak

The function that runs the capability logic is called tparm. It is a C variadic function, meaning its number of arguments is not predefined (similarly to printf). The way variadic functions work in C is usually with the va_list structure and its macros, va_start, va_arg, and va_end. The common scenario for such functions is to parse a format-string, conclude the number of parameters it expects, and use the va_arg macro iteratively to fetch those arguments. However, since an attacker can be in full control of the capability’s string, we can make tparm call va_arg more times than it should, effectively leaking information from the call stack. Since we are allowed up to nine parameters, we can leak up to eight unintended arguments, including arguments from the program’s stack:

Parameterized string type confusion

The stack used by the tparm function is just an allocated array with 20 entries (referred as STACK_FRAME in the source code). Each frame can hold either a number (32-bit signed integer) or a string (pointer). To distinguish between a number and a string, the frame uses a Boolean value, which represents whether the data is numeric or not:

Certain push operations can be easily concluded, for example, when pushing an arithmetic result (such as %+) or a literal (%{number}). However, for parameters, things are different. There is no easy way to know ahead of time whether a parameter is expected to be a string or numeric. Therefore, tparm uses a heuristic—it walks the capability string statically, and when it sees %s or %l, it concludes that the last parameter push was a string. This approach can be abused in multiple ways. For example, the macOS top utility calls mvcur, which in turn calls tparm with the cup capability, along with integer parameters. Treating the parameter as a string can trigger strlen on the integer address:

The crash we triggered occurs during an initialization of the mvcur operation, which assesses the “cost” of moving the cursor by invoking tparm with a constant, non-attacker-controlled value. We can improve the attack by using conditions—if the parameter’s value is not that constant value, then treat the parameter as a string, otherwise treat it as a number. Implementation with capabilities is straightforward:

This should be read as:

This primitive is quite powerful, as we can trigger strlen on an arbitrary number, effectively gaining a read primitive. Gaining a read primitive defeats the Address Space Layout Randomization (ASLR) security mechanism to leak address information and, if the binary happens to contain valuable secrets in its memory (like passwords), an attacker could potentially read those as well.

Cost calculating padding off-by-one

We have mentioned mvcur uses a cost-calculating function to determine the costs of certain capabilities. The cost-calculation is done by the function _nc_msec_cost, and it assesses the number of milliseconds it takes to print out a capability, which is strongly derived by delays that could be a part of a capability. Delays are numeric literal values wrapped between ‘$<’ and ‘>’, and they even support a decimal point. We discovered an off-by-one error—if the function sees a decimal point character, it skips one character assuming a digit, with an insufficient check after:

Therefore, it’s possible to have the cost-calculating function read beyond the boundary of the capability string by closing the delay markup with a ‘>’ character immediately following the decimal dot.

Heap out-of-bounds during terminfo database file parsing

The terminfo database files are binary files commonly compiled from the text representation with a utility called tic. The format of the database consists of the following parts:

• The header: contains a magic value, the size of the terminal name, the number of Boolean capabilities, the number of numeric capabilities, the number of string capabilities, and the total size of string capabilities.
• The terminal name
• The capabilities:
  • The Boolean capabilities
  • The numeric capabilities
  • The string capability offsets
  • The string capabilities themselves
• Optional extended entries (in the same order: Boolean, numeric, and strings)

The optional extended entries are user-defined entries. We discovered that the function that performs that database parsing (_nc_read_termtype) can write beyond the boundaries of a heap-allocated chunk, as such:

1. The code uses calloc to allocate room for the strings. While STRCOUNT is a constant representing the maximum length of standard string capabilities (414), str_count is attacker-controlled and defined in the header of the attacker’s terminfo file. This controls the size of the allocated chunk saved in ptr->Strings.
2. After parsing all the standard capabilities, ncurses starts parsing the extended capabilities. The code assigns ptr->num_Strings to STRCOUNT+ ext_str_count, which might be smaller than the non-extended string count, effectively shrinking ptr->Strings with a realloc call.
3. Immediately after the realloc call, we can see ptr->Strings being written beyond its boundaries. Extended string capabilities are parsed and appended after standard string capabilities. The convert_strings function attempts to achieve this by storing data in ptr->Strings + str_count. However, while ptr->Strings was shrunk to STRCOUNT+ext_str_count,  str_count is user-controlled and can be greater than STRCOUNT.
4. If str_count >= STRCOUNT, then ptr->Strings + str_count + ext_str_count will be greater than ptr->Strings + STRCOUNT + ext_str_count and convert_strings will cause a heap buffer overflow.

Denial of service with canceled strings

The ncurses library has a notion of marking strings as “cancelled”. This is useful for terminfo database inheritance and skipping absent capabilities in general. As an example, the function convert_strings that converts strings from the terminfo database file format to the appropriate data structures in memory sets strings as CANCELLED_STRING if the index referring to them is negative.

The value of the CANCELLED_STRING constant is -1, and before processing, the ncurses codebase looks for these strings and converts them to ABSENT_STRING (constant 0). Unfortunately, it does so only for ordinary strings; extended strings do not get that treatment. Specifically, a heuristic determines that strings that begin with the “k” character should be treated as keypad functionality. This allows an attacker to specify an extended string in a way that will make ncurses dereference -1 (0xFFFFFFFFFFFFFFFF):

Protection and detection with Microsoft Defender for Endpoint

While organizational devices and networks may become increasingly secure, attackers continue to exploit unpatched vulnerabilities and misconfigurations as a vector to access sensitive systems and information. Exploiting vulnerabilities in the ncurses library could have notable consequences for users, allowing attackers to perform malicious actions like elevating privileges to run code in a targeted program’s context and access or modify valuable data and resources. Responding to the evolving threat landscape requires us to expand our expertise across devices and platforms as part of our commitment to continuously improve security from Microsoft, not just for Microsoft.

This case displays how responsible vulnerability disclosure and collaborative research informs our comprehensive protection capabilities across platforms. Microsoft Defender Vulnerability Management is able to quickly discover and remediate such vulnerabilities on both Linux and macOS. Additionally, Microsoft Defender for Endpoint has similar detections for potential abuse of terminfo databases for set-UID binaries, such as macOS’s top:

After discovering the vulnerabilities in the ncurses library, we worked with the maintainer, Thomas E. Dickey, and Apple to ensure the issues were resolved across platforms. Additionally, this case displays the value of community engagement to improve security for all as researcher Gergely Kalman’s use case contributions assisted our research efforts. We wish to again thank Thomas and the Apple product security team for their efforts and collaboration in addressing CVE-2023-29491, as well as Gergely for his contributions in furthering this research.

As the threat landscape continues to evolve and threats across all platforms continue to grow, Microsoft strives to continuously secure users’ computing experiences, regardless of the platform or device in use. We will continue to work with the security community to share vulnerability discoveries and threat intelligence in the effort to build better protection for all.

Jonathan Bar Or, Emanuele Cozzi, Michael Pearse

Microsoft Threat Intelligence team

References

• https://invisible-island.net/ncurses/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-29491
• https://invisible-island.net/ncurses/NEWS.html#index-t20230408
• https://twitter.com/gergely_kalman
• https://linux.die.net/man/1/infocmp
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22809
• https://linux.die.net/man/8/sudoedit
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0563
• https://linux.die.net/man/1/chsh
• https://linux.die.net/man/1/chfn
• https://en.wikipedia.org/wiki/Setuid
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9934
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30970
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32369
• https://developer.apple.com/documentation/security/disabling_and_enabling_system_integrity_protection
• https://man7.org/linux/man-pages/man8/ld.so.8.html
• https://attack.mitre.org/techniques/T1574/006/
• https://ss64.com/osx/top.html
• https://blog.trailofbits.com/2023/02/16/suid-logic-bug-linux-readline/
• https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-38464/GNU-Ncurses.html
• https://github.com/apple-oss-distributions/ncurses
• https://owasp.org/www-community/Fuzzing
• https://github.com/AFLplusplus/AFLplusplus
• https://linux.die.net/man/3/tparm
• https://en.cppreference.com/w/c/variadic/va_list
• https://en.cppreference.com/w/c/variadic/va_start
• https://en.cppreference.com/w/c/variadic/va_arg
• https://en.cppreference.com/w/c/variadic/va_end
• https://linux.die.net/man/3/mvcur
• https://cplusplus.com/reference/cstring/strlen/
• https://linux.die.net/man/1/tic
• https://linux.die.net/man/3/calloc
• https://linux.die.net/man/3/realloc

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Uncursing the ncurses: Memory corruption vulnerabilities found in library appeared first on Microsoft Security Blog.

Utilizing an established criminal infrastructure that has incorporated the use of a Southeast Asian financial institution’s subdomain as a command and control (C2) server, the threat actors behind the attack use a backdoor that deploys a wide array of tools and components such as rootkits and an IRC bot to steal device resources for mining operations. The backdoor also installs a patched version of OpenSSH on affected devices, allowing threat actors to hijack SSH credentials, move laterally within the network, and conceal malicious SSH connections. The complexity and scope of this attack are indicative of the efforts attackers make to evade detection.

In this blog post, we present our analysis of the tools and techniques used in this attack and the efforts made by the threat actor to evade detection on affected devices. We also provide indicators of compromise and relevant Microsoft Defender for IoT and Microsoft Defender for Endpoint detections, as well as recommendations for defenders to protect devices and networks.

Attack chain

The threat actors initiate the attack by attempting to brute force various credentials on misconfigured internet-facing Linux devices. Upon compromising a target device, they disable shell history and retrieve a compromised OpenSSH archive named openssh-8.0p1.tgz from a remote server. The archive contains benign OpenSSH source code alongside several malicious files: the shell script inst.sh, backdoor binaries for multiple architectures (x86-64, arm4l, arm5l, i568, and i686), and an archive containing the shell script vars.sh, which holds embedded files for the backdoor’s operation.

After installing the payload, the shell script inst.sh runs a backdoor binary that matches the target device’s architecture. The backdoor is a shell script compiled using an open-source project called Shell Script Compiler (shc), and enables the threat actors to perform subsequent malicious activities and deploy additional tools on affected systems.

Custom backdoor deploys open-source rootkits

Once running on a device, the shell script backdoor tests access to /proc to determine whether the device is a honeypot. If it can’t access /proc, it determines the device is a honeypot and exits. Otherwise, it exfiltrates information about the device, including its operating system version, network configuration, and the contents of /etc/passwd and /etc/shadow over email to the hardcoded address dotsysadmin[@]protonmail[.]com, and to any email address provided by the threat actor as an argument to the script.

On supported systems, the backdoor downloads, compiles, and installs two open-source rootkits available on GitHub, Diamorphine and Reptile. The backdoor configures Reptile to connect to the C2 domain rsh.sys-stat[.]download on port 4444 and to hide its child processes, files, or their content. Microsoft researchers assess that the Diamorphine rootkit is used to hide processes as well.

To ensure persistent SSH access to the device, the backdoor appends two public keys to the authorized_keys configuration files of all users on the system.

The backdoor obscures its activity by removing records from Apache, nginx, httpd, and system logs that contain the IP and username specified as arguments to the script. Additionally, it has the capability to install an open-source utility called logtamper to clear the utmp and wtmp logs, which record information about user sign-in sessions and system events.

The backdoor eliminates cryptomining competition from other miners that may exist on the device by monopolizing device resources and preventing communication with a hardcoded list of hosts and IPs related to these activities. It accomplishes this by adding iptables rules to drop communication with the hosts and IPs and configuring /etc/hosts to make the hosts resolve to the localhost address. It also identifies miner processes and files by their names and either terminates them or blocks access to them, and removes SSH access configured in authorized_keys by other adversaries.

Patching OpenSSH source code

The backdoor uses the Linux patch utility to apply the patch file ss.patch, which is embedded in vars.sh, to the OpenSSH source code files included in its package. Once the patches are applied, the backdoor compiles and installs the modified OpenSSH on the device.

The compromised OpenSSH grants the attackers persistent access to the device and to the SSH credentials the device handles. The patches install hooks that intercept the passwords and keys of the device’s SSH connections, whether as a client or a server. The passwords and keys are then stored encrypted in a file on the disk. Moreover, the patches enable root login over SSH and conceal the intruder’s presence by suppressing the logging of the threat actors’ SSH sessions, which are distinguished by a special password.

The modified version of OpenSSH mimics the appearance and behavior of a legitimate OpenSSH server and may thus pose a greater challenge for detection than other malicious files. The patched OpenSSH could also enable the threat actors to access and compromise additional devices. This type of attack demonstrates the techniques and persistence of adversaries who seek to infiltrate and control exposed devices.

Botnet operation

The backdoor runs a secondary payload embedded in the shell script vars.sh, which is a slightly modified version of ZiggyStarTux, an open-source IRC bot based on the Kaiten malware. Among its features is executing bash commands issued from the C2 and possessing distributed denial of service (DDoS) capabilities.

The backdoor employs various mechanisms to set up ZiggyStarTux’s persistence on compromised systems. It copies the ZiggyStarTux binary to several locations on the disk and establishes cron jobs to invoke it at regular intervals. Moreover, it runs a bash script that registers ZiggyStarTux as a systemd service by creating and configuring the service file /etc/systemd/system/network-check.service.

Analysis of ZiggyStarTux revealed that the threat actors stripped the binary of logging-related strings and incorporated a function that writes the bot’s process ID to /var/run/sys_checker.pid, allowing the backdoor to read that file and conceal that process ID using the installed rootkits.

The ZiggyStarTux bots communicate with the C2 via an IRC server hosted on various domains and IPs located in different geographical regions. Evidence indicates that the threat actors disguise their traffic by utilizing the subdomain of a Southeast Asian financial institution that is hosted on one of their own servers.

To receive commands, the ZiggyStarTux bots connect to the IRC server and join a hidden password-protected channel named ##..##. The server was observed issuing bash commands that instruct bots to download and launch two shell scripts from a remote server. The first script, lscan, retrieves lssh.tgz from the server, an archive of scripts that scan each IP in the subnet for SSH access using a password list. The scripts record the results of each connection attempt in a log file.

The second script, zaz, fetches the compromised OpenSSH package with the embedded backdoor from the remote server. The installation is carried out using the email address ancientgh0st@yahoo[.]com as an argument to serve as an additional exfiltration point for device information. Additionally, zaz retrieves an archive called hive-start.tgz which contains mining malware crafted for Hiveon OS systems, a Linux-based open-source operating system designed for cryptomining.

Indications of criminal cooperation

Microsoft researchers have traced the campaign to a user named asterzeu on the hacking forum cardingforum[.]cx, who offered multiple tools for sale on the platform, including an SSH backdoor. The domain madagent[.]tm was registered in 2015 with an email address matching the username and shared numerous servers over a four-year period with madagent[.]cc, one of the C2 domains of ZiggyStarTux. Furthermore, the distribution of the shell script backdoor between threat actors has been identified, adding to the evidence of a network of tools and infrastructure shared or sold on the malware-as-a-service market.

Mitigation and protection guidance

Microsoft recommends the following steps to protect devices and networks against this threat:

• Harden internet-facing devices against attacks
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least-privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.
  • When possible, update OpenSSH to the latest version.
• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the use of open-source tools and exploits that may be tied to this attack.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Linux/SamDust!MTB
• Trojan:Linux/SamDust.D!MTB
• Trojan:Linux/SamDust.B!MTB
• Trojan:Linux/SamDust.A!MTB
• Trojan:Linux/SamDust.N!MTB
• Trojan:Linux/Reptile.A
• Trojan:Linux/Reptile.B
• Trojan:Linux/Reptile.C
• Trojan:Linux/Reptile.D
• Trojan:Linux/Diamorphine.A!MTB

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Unusual number of failed sign-in attempts

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Suspicious file property modification occurred
• Suspicious termination of security tool
• Suspicious service launched
• Suspicious Linux service created
• File masquerading

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

In addition, customers can use the SSH Brute force detection template in the Syslog solution package to monitor for brute force attempts against their exposed SSH endpoints.

Indicators of Compromise

Rotem Sde-Or, Microsoft Threat Intelligence Community

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post IoT devices and Linux-based systems targeted by OpenSSH trojan campaign appeared first on Microsoft Security Blog.

Zerobot, a Go-based botnet that spreads primarily through IoT and web application vulnerabilities, is an example of an evolving threat, with operators continuously adding new exploits and capabilities to the malware. The Microsoft Defender for IoT research team has been monitoring Zerobot (also called ZeroStresser by its operators) for months. Zerobot is offered as part of a malware as a service scheme and has been updated several times since Microsoft started to track it. One domain with links to Zerobot was among several domains associated with DDoS-for-hire services seized by the FBI in December 2022.

Microsoft has previously reported on the evolving threat ecosystem. The shift toward malware as a service in the cyber economy has industrialized attacks and has made it easier for attackers to purchase and use malware, establish and maintain access to compromised networks, and utilize ready-made tools to perform their attacks. We have tracked advertisements for the Zerobot botnet on various social media networks in addition to other announcements regarding the sale and maintenance of the malware, as well as new capabilities in development.

In this blog post, we present information about the latest version of the malware, Zerobot 1.1, including newly identified capabilities and further context to Fortinet’s recent analysis on the threat. Zerobot 1.1 increases its capabilities with the inclusion of new attack methods and new exploits for supported architectures, expanding the malware’s reach to different types of devices. In addition to these findings, we’re sharing new indicators of compromise (IOCs) and recommendations to help defenders protect devices and networks against this threat.

What is Zerobot?

Zerobot affects a variety of devices that include firewall devices, routers, and cameras, adding compromised devices to a distributed denial of service (DDoS) botnet. Using several modules, the malware can infect vulnerable devices built on diverse architectures and operating systems, find additional devices to infect, achieve persistence, and attack a range of protocols. Microsoft tracks this activity as DEV-1061.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1061 is now tracked as Storm-1061.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The most recent distribution of Zerobot includes additional capabilities, such as exploiting vulnerabilities in Apache and Apache Spark (CVE-2021-42013 and CVE-2022-33891 respectively), and new DDoS attack capabilities.

How Zerobot gains and maintains device access

IoT devices are often internet-exposed, leaving unpatched and improperly secured devices vulnerable to exploitation by threat actors. Zerobot is capable of propagating through brute force attacks on vulnerable devices with insecure configurations that use default or weak credentials. The malware may attempt to gain device access by using a combination of eight common usernames and 130 passwords for IoT devices over SSH and telnet on ports 23 and 2323 to spread to devices. Microsoft researchers identified numerous SSH and telnet connection attempts on default ports 22 and 23, as well as attempts to open ports and connect to them by port-knocking on ports 80, 8080, 8888, and 2323.

In addition to brute force attempts on devices, Zerobot exploits dozens of vulnerabilities, which malware operators add on a rolling basis to gain access and inject malicious payloads. Zerobot 1.1 includes several new vulnerabilities, such as:

Since the release of Zerobot 1.1, the malware operators have removed CVE-2018-12613, a phpMyAdmin vulnerability that could allow threat actors to view or execute files. Microsoft researchers have also identified that previous reports have used the vulnerability ID “ZERO-32906” for CVE-2018-20057, “GPON” for CVE-2018-10561, and “DLINK” for CVE-2016-20017; and that CVE-2020-7209 was mislabeled as CVE-2017-17106 and CVE-2022-42013 was mislabeled as CVE-2021-42013.

Microsoft researchers have also found new evidence that Zerobot propagates by compromising devices with known vulnerabilities that are not included in the malware binary, such as CVE-2022-30023, a command injection vulnerability in Tenda GPON AC1200 routers.

Upon gaining device access, Zerobot injects a malicious payload, which may be a generic script called zero.sh that downloads and attempts to execute Zerobot, or a script that downloads the Zerobot binary of a specific architecture. The bash script that attempts to download different Zerobot binaries tries to identify the architecture by brute-force, attempting to download and execute binaries of various architectures until it succeeds, as IoT devices are based on many computer processing units (CPUs). Microsoft has observed scripts targeting various architectures including ARM64, MIPS, and x86_64.

Depending on the operating system of the device, the malware has different persistence mechanisms. Persistence tactics are used by malware operators to obtain and maintain access to devices. While Zerobot is unable to spread to Windows machines, we have found several samples that can run on Windows. On Windows machines, the malware copies itself to the Startup folder with the file name FireWall.exe (older versions use my.exe). Microsoft Defender for Endpoint detects this malware and related malicious activity on both Windows and Linux devices. See detection details below.

To achieve persistence on Linux-based devices, Zerobot uses a combination of desktop entry, daemon, and service methods:

Desktop entry:

Zerobot copies itself to $HOME/.config/ssh.service/sshf then writes a desktop entry file called sshf.desktop to the same directory. Older Linux versions use $HOME/.config/autostart instead of $HOME/.config/ssh.service.

Daemon:

Copies itself to /usr/bin/sshf and writes a configuration at /etc/init/sshf.conf.

Service:

Copies itself to /etc/sshf and writes a service configuration at /lib/system/system/sshf.service, then enables the service (to make sure it starts at boot) with two commands:

• systemctl enable sshf
• service enable sshf

All persistence mechanisms on older Linux versions use my.bin and my.bin.desktop instead of sshf and sshf.desktop.

New attack capabilities

In addition to the functions and attacks included in previous versions of the malware, Zerobot 1.1 has additional DDoS attack capabilities. These functions allow threat actors to target resources and make them inaccessible. Successful DDoS attacks may be used by threat actors to extort ransom payments, distract from other malicious activities, or disrupt operations. In almost every attack, the destination port is customizable, and threat actors who purchase the malware can modify the attack according to their target.

The following are the previously known Zerobot capabilities:

Previously undisclosed and new capabilities are the following:

How Zerobot spreads

After persistence is achieved, Zerobot scans for other internet-exposed devices to infect. The malware randomly generates a number between 0 and 255 and scans all IPs starting with this value. Using a function called new_botnet_selfRepo_isHoneypot, the malware tries to identify honeypot IP addresses, which are used by network decoys to attract cyberattacks and collect information on threats and attempts to access resources. This function includes 61 IP subnets, preventing scanning of these IPs.

Microsoft researchers also identified a sample that can run on Windows based on a cross-platform (Linux, Windows, macOS) open-source remote administration tool (RAT) with various features such as managing processes, file operations, screenshotting, and running commands. This tool was found by investigating the command-and-control (C2) IPs used by the malware. The script, which is used to download this RAT, is called impst.sh:

Defending devices and networks against Zerobot

The continuous evolution and rapid addition of new capabilities in the latest Zerobot version underscores the urgency of implementing comprehensive security measures. Microsoft recommends the following steps to protect devices and networks against the threat of Zerobot:

• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data. Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect Zerobot malware variants and malicious behavior related to this threat.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• Harden endpoints with a comprehensive Windows security solution:
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • Perform timely cleanup of all unused and stale executables sitting on yours or your organizations’ devices.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the following vulnerabilities and exploits which may be tied to Zerobot activity:

• CVE-2014-8361
• CVE-2016-20017
• CVE-2017-17105
• CVE-2017-17215
• CVE-2018-10561
• CVE-2018-20057
• CVE-2019-10655
• CVE-2020-7209
• CVE-2020-10987
• CVE-2020-25506
• CVE-2021-35395
• CVE-2021-36260
• CVE-2021-42013
• CVE-2021-46422
• CVE-2022-22965
• CVE-2022-25075
• CVE-2022-26186
• CVE-2022-26210
• CVE-2022-30023
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-33891
• CVE-2022-34538
• CVE-2022-37061
• ZERO-36290
• ZSL-2022-5717

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malicious files under the following platforms and threat names:

• Zerobot (Win32/64 and Linux)
• SparkRat (Win32/64 and Linux)

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• DEV-1061 threat activity group detected
• An active ‘PrivateLoader’ malware process was detected while executing
• ‘Morila’ malware was prevented
• ‘Multiverze’ malware was detected

Microsoft Defender for Endpoint also has detections for the following vulnerabilities exploited by Zerobot:

• CVE-2022-22965 (Spring4Shell)

Microsoft Defender for Endpoint’s Device Discovery capabilities discover and classify devices. With these capabilities, Microsoft 365 Defender customers using Microsoft Defender for IoT have visibility into security recommendations for devices with the following vulnerabilities:

• CVE-2014-8361
• CVE-2019-10655
• CVE-2020-25506
• CVE-2021-36260
• CVE-2021-42013
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-37061

Devices with these vulnerabilities are also visible in the Microsoft Defender Vulnerability Management inventory.

Microsoft Defender for Cloud

Microsoft Defender for Cloud alerts with the following titles can indicate threat activity on your network:

• VM_ReverseShell
• VM_SuspectDownloadArtifacts
• SQL.VM_ShellExternalSourceAnomaly
• AppServices_CurlToDisk

Advanced hunting queries

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following query to find related activity in their networks.

Zerobot files

This query finds the file hashes associated with Zerobot activity.

let IoCList = externaldata(TimeGenerated:datetime,IoC:string,IoC_Type:string,ExpirationDateTime:datetime,Description:string, Action:string, ConfidenceScore:real, ThreatType:string, Active:string,Type:string, TrafficLightProtocolLevel:string, 
ActivityGroupNames:string)[@"https://raw.githubusercontent.com/microsoft/mstic/master/RapidReleaseTI/Indicators.csv"] 
with(format="csv", ignoreFirstRecord=True);
let shahashes = IoCList
| where IoC_Type =~ "sha256" and Description =~ "Dev-1061 Zerobot affecting IoT devices"
| distinct IoC;
DeviceFileEvents
| where SHA256 in (shahashes)

Zerobot HTTP requests

This query finds suspicious HTTP requests originated by the IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "NetworkSignatureInspected"
| where Timestamp > ago(30d)
|extend json = parse_json(AdditionalFields)
| extend SignatureName =tostring(json.SignatureName), SignatureMatchedContent = tostring(json.SignatureMatchedContent), SignatureSampleContent = tostring(json.SamplePacketContent)
|where SignatureName == "HTTP_Client"
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, SignatureName, SignatureMatchedContent, SignatureSampleContent

Zerobot port knocking

This query finds incoming connections from IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "InboundConnectionAccepted"
| where Timestamp > ago(30d)
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, InitiatingProcessFileName

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

Indicators of compromise (IOCs):

Domains and IP addresses:

• zero[.]sudolite[.]ml
• 176.65.137[.]5
• 176.65.137[.]5:1401
• 176.65.137[.]6
• ws[:]//176.65.137[.]5/handle
• http[:]//176.65.137[.]5:8000/ws

New Zerobot hashes (SHA-256)

• aed95a8f5822e9b1cd1239abbad29d3c202567afafcf00f85a65df4a365bedbb
• bf582b5d470106521a8e7167a5732f7e3a4330d604de969eb8461cbbbbdd9b9a
• 0a5eebf19ccfe92a2216c492d6929f9cac72ef37089390572d4e21d0932972c8
• 1e7ca210ff7bedeefadb15a9ec5ea68ad9022d0c6f41c4e548ec2e5927026ba4
• 05b7517cb05fe1124dd0fad4e85ddf0fe65766a4c6c9986806ae98a427544e9d
• 5625d41f239e2827eb05bfafde267109549894f0523452f7a306b53b90e847f2
• c304a9156a032fd451bff49d75b0e9334895604549ab6efaab046c5c6461c8b3
• 66c76cfc64b7a5a06b6a26976c88e24e0518be3554b5ae9e3475c763b8121792
• 539640a482aaee2fe743502dc59043f11aa8728ce0586c800193e30806b2d0e5
• 0f0ba8cc3e46fff0eef68ab5f8d3010241e2eea7ee795e161f05d32a0bf13553
• 343c9ca3787bf763a70ed892dfa139ba69141b61c561c128084b22c16829c5af
• 874b0691378091a30d1b06f2e9756fc7326d289b03406023640c978ff7c87712
• 29eface0054da4cd91c72a0b2d3cda61a02831b4c273e946d7e106254a6225a7
• 4a4cb8516629c781d5557177d48172f4a7443ca1f826ea2e1aa6132e738e6db2
• bdfd89bdf6bc2de5655c3fe5f6f4435ec4ad37262e3cc72d8cb5204e1273ccd6
• 62f23fea8052085d153ac7b26dcf0a15fad0c27621f543cf910e37f8bf822e0e
• 788e15fd87c45d38629e3e715b0cb93e55944f7c4d59da2e480ffadb6b981571
• 26e68684f5b76d9016d4f02b8255ff52d1b344416ffc19a2f5c793ff1c2fdc65
• e4840c5ac2c2c2170d00feadb5489c91c2943b2aa13bbec00dbcffc4ba8dcc2d
• 45059f26e32da95f4bb5dababae969e7fceb462cdeadf7d141c39514636b905a
• 77dd28a11e3e4260b9a9b60d58cb6aaaf2147da28015508afbaeda84c1acfe70
• cf232e7d39094c9ba04b9713f48b443e9d136179add674d62f16371bf40cf8c8
• 13657b64a2ac62f9d68aeb75737cca8f2ab9f21e4c38ce04542b177cb3a85521
• eb33c98add35f6717a3afb0ab2f9c0ee30c6f4e0576046be9bf4fbf9c5369f71
• e3dd20829a34caab7f1285b730e2bb0c84c90ac1027bd8e9090da2561a61ab17
• 3685d000f6a884ca06f66a3e47340e18ff36c16b1badb80143f99f10b8a33768
• cdc28e7682f9951cbe2e55dad8bc2015c1591f89310d8548c0b7a1c65dbefae3
• 869f4fb3f185b2d1231d9378273271ddfeebb53085daede89989f9cc8d364f5f
• 6c59af3ed1a616c238ee727f6ed59e962db70bc5a418b20b24909867eb00a9d6
• ef28ee3301e97eefd2568a3cb4b0f737c5f31983710c75b70d960757f2def74e
• 95e4cc13f8388c195a1220cd44d26fcb2e10b7b8bfc3d69efbc51beb46176ff1
• 62f9eae8a87f64424df90c87dd34401fe7724c87a394d1ba842576835ab48afc
• 54d1daf58ecd4d8314b791a79eda2258a69d7c69a5642b7f5e15f2210958bdce
• 8176991f355db10b32b7562d1d4f7758a23c7e49ed83984b86930b94ccc46ab3
• 8aa89a428391683163f0074a8477d554d6c54cab1725909c52c41db2942ac60f
• fd65bd8ce671a352177742616b5facc77194cccec7555a2f90ff61bad4a7a0f6
• 1e66ee40129deccdb6838c2f662ce33147ad36b1e942ea748504be14bb1ee0ef
• 57f83ca864a2010d8d5376c68dc103405330971ade26ac920d6c6a12ea728d3d
• 7bfd0054aeb8332de290c01f38b4b3c6f0826cf63eef99ddcd1a593f789929d6

SparkRat hashes (SHA-256):

• 0ce7bc2b72286f236c570b1eb1c1eacf01c383c23ad76fd8ca51b8bc123be340
• cacb77006b0188d042ce95e0b4d46f88828694f3bf4396e61ae7c24c2381c9bf
• 65232e30bb8459961a6ab2e9af499795941c3d06fdd451bdb83206a00b1b2b88

Rotem Sde-Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Meitar Pinto, Nimrod Roimy, Nir Avnery, Microsoft Defender Research Team
Ramin Nafisi, Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post Microsoft research uncovers new Zerobot capabilities appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1028 is now tracked as Storm-1028.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Malware operations continue to rapidly evolve as threat actors add new capabilities to existing botnets, increasingly targeting and recruiting new types of devices. Attackers update malware to target additional operating systems, ranging from PCs to IoT devices, growing their infrastructure rapidly. The Microsoft Defender for IoT research team recently analyzed a cross-platform botnet that originates from malicious software downloads on Windows devices and succeeds in propagating to a variety of Linux-based devices.

The botnet spreads by enumerating default credentials on internet-exposed Secure Shell (SSH)-enabled devices. Because IoT devices are commonly enabled for remote configuration with potentially insecure settings, these devices could be at risk to attacks like this botnet. The botnet’s spreading mechanism makes it a unique threat, because while the malware can be removed from the infected source PC, it could persist on unmanaged IoT devices in the network and continue to operate as part of the botnet.

Microsoft tracks this cluster of activity as DEV-1028, a cross-platform botnet that infects Windows devices, Linux devices, and IoT devices. The DEV-1028 botnet is known to launch distributed denial of service (DDoS) attacks against private Minecraft servers.

Our analysis of the DDoS botnet revealed functionalities specifically designed to target private Minecraft Java servers using crafted packets, most likely as a service sold on forums or darknet sites. A breakdown of the systems affected by the botnet over the three months from the time of this analysis also revealed that most of the devices were in Russia:

This type of threat stresses the importance of ensuring that organizations manage, keep up to date, and monitor not just traditional endpoints but also IoT devices that are often less secure. In this blog post, we share details on how this botnet affects multiple platforms, its DDoS capabilities, and recommendations for organizations to prevent their devices from becoming part of a botnet. We also share Minecraft server version information for owners of private servers to update and ensure they are protected from this threat.

Cross-platform botnet targets SSH-enabled devices

Microsoft researchers observed that the initial infection points related to the botnet were devices infected through the installation of malicious cracking tools that purport to acquire illegal Windows licenses.

The cracking tools contain additional code that downloads and launches a fake version of svchost.exe through a PowerShell command. In some cases, the downloaded file is named svchosts.exe.

Next, svchost.exe launches malicious.py, the main Python script that contains all the logic of the botnet, whichthen scans the internet for SSH-enabled Linux-based devices (Debian, Ubuntu, CentOS, and IoT workloads such as Raspbian, which are commonly enabled for remote configuration) and launches a dictionary attack to propagate. Once a device is found, it downloads the file Updater.zip from repo[.]ark—event[.]net onto the device, which creates the file fuse. The fuse file then downloads a copy of malicious.py onto the device. Both svchost.exe and fuse are compiled using PyInstaller, which bundles all the Python runtime and libraries necessary to initiate malicious.py.

While malicious.py has specific functionalities depending on whether the file launches on a Windows or Linux-based device (for Windows, the file establishes persistency by adding the registry key Software\Microsoft\Windows\CurrentVersion\Run with the executable as the value), the executable is compiled to operate on both Windows and Linux-based devices. The file communicates with its command-and-control (C2) server to launch the following commands:

• Establish TCP connection to repo[.]ark-event[.]net on port 4676.
• Send initial connection string.
• Receive a key from the server for encryption and decryption, and then encrypt further communication using the Fernet symmetric algorithm.
• Send version information to the server:
  • Windows device: The current Windows version
  • Linux device: Hardcoded version (2.19 in the sample we analyzed)
• Continue receiving encrypted commands from the server

Based on our analysis, the botnet is primarily used to launch DDoS attacks against private Minecraft servers using known server DDoS commands and unique Minecraft commands. Below is the list of commands established in the code:

While most of the commands are methods of DDoS, the most notable command run by the botnet is ATTACK_MCCRASH. The command sends ${env:random payload of specific size:-a} as the username in order to exhaust the resources of the server and make it crash.

TCP payloads on port 25565 have the following binary structure:

• Bytes [0:1] – Size of packet
• Bytes [1:2] – Login Start command
• Bytes [2:3] – Size of username
• Bytes [3:18] – Username string

The usage of the env variable triggers the use of Log4j 2 library, which causes abnormal consumption of system resources (not related to Log4Shell vulnerability), demonstrating a specific and highly efficient DDoS method.

A wide range of Minecraft server versions could be affected

While testing the impact of the malware, researchers found that the malware itself was hardcoded to target a specific version of Minecraft server, 1.12.2. However, all versions between 1.7.2 and 1.18.2 can be affected by this method of attack. There is a slight modification in the Minecraft protocol in server version 1.19, which was released earlier in 2022, that prevents the use of the Minecraft specific commands, the ATTACK_MCCRASH, ATTACK_[MCBOT|MINE] and ATTACK_MCDATA, without modification of the attack code.

The wide range of at-risk Minecraft servers highlights the impact this malware could have had if it was specifically coded to affect versions beyond 1.12.2. The unique ability of this threat to utilize IoT devices that are often not monitored as part of the botnet substantially increases its impact and reduces its chances of being detected.

Protecting endpoints from cross-platform DDoS botnets like MCCrash

To harden devices networks against threats like MCCrash, organizations must implement the basics to secure identities and their devices, including access limitation. Solutions must detect downloads of malicious programs and malicious attempts to gain access to SSH-enabled devices and generate alerts on anomalous network behavior. Below are some of our recommendations for organizations:

• Ensure employees are not downloading cracking tools as these are abused as an infection source for spreading malware.

• Increase network security by enforcing multi-factor authentication (MFA) methods such as Azure Active Directory (now part of Microsoft Entra) MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  
  Microsoft 365 Defender protects against attacks related to botnets by coordinating threat data across identities, endpoints, cloud apps, email, and documents. Such cross-domain visibility allows Microsoft 365 Defender to comprehensively detect and remediate end-to-end attack chains—from malicious downloads to its follow-on activities in endpoints. This rich set of tools like advanced hunting let defenders surface threats and gain insights for hardening networks from compromise.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender. Defender for IoT is updated regularly with indicators of compromise (IoCs) from threat research like the example described in this blog, alongside rules to detect malicious activity.
  
  On the IoT device level:
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• For users hosting private Minecraft servers, update to version 1.19.1 and above.

• Adopt a comprehensive Windows security solution
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • For commercial customers, enable application and browser controls such as Microsoft Defender Application Guard for enhanced protection for Office and Edge.
  • Perform timely cleanup of all unused and stale executables sitting on your organizations’ devices.
  • Protect against advanced firmware attacks by enabling memory integrity, Secure Boot, and Trusted Platform Module 2.0, if not enabled by default, which hardens boot using capabilities built into modern CPUs.

Indicators of compromise (IOCs)

• e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25 (KMSAuto++.exe)
• 143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320 (W10DigitalActivation.exe)
• f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30 (dcloader.exe)
• 4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f (updater.zip)
• eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382 (svchosts.exe)
• 93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251 (fuse)
• 202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1 (malicious.py)
• repo[.]ark-event[.]net

Detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware used in this attack as the following:

• TrojanDownloader:MSIL/MCCrash.NZM!MTB
• Trojan:Win32/MCCrash.MA!MTB
• TrojanDownloader:Python/MCCrash!MTB
• Trojan:Python/MCCrash.A
• TrojanDownloader:Linux/MCCrash!MTB
• Trojan:Python/MCCrash.RPB!MTB
• Trojan:Python/MCCrash.RPC!MTB

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• Emerging threat activity group DEV-1028 detected
• System file masquerade
• Anomaly detected in ASEP registry
• Suspicious process launched using cmd.exe
• Suspicious file launch

Microsoft Defender for IoT

MCCrash-related activity on IoT devices would raise the following alerts in Microsoft Defender for IoT:

• Unauthorized SSH access
• Excessive login attempts

Microsoft Defender for Cloud

Microsoft Defender for Cloud raises the following alert for related activity:

• VM_SuspectDownload

Advanced hunting queries

Microsoft 365 Defender

Run the following queries to search for related files in your environment:

DeviceFileEvents
| where SHA256 in ("e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25","143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320","f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30","4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f","eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382","93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251","202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1")

DeviceFileEvents
| where FolderPath endswith @":\windows\svchost.exe"

DeviceRegistryEvents
| where RegistryKey contains "CurrentVersion\\Run"
| where RegistryValueName == "br" or RegistryValueData contains "svchost.exe" or RegistryValueData contains "svchosts.exe"

DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe")
| where ProcessCommandLine has_all ("-command", ".downloadfile(", "windows/svchost.exe")

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

To supplement this indicator matching, customers can use the following queries against data ingested into their workspaces to help find devices with exposed SSH endpoints, and devices that might be under SSH brute force attempts.

Potential SSH brute force attempt: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/Syslog/ssh_potentialBruteForce.yaml

Exposed critical ports in Azure: https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/CriticalPortsOpened.yaml

David Atch, Maayan Shaul, Mae Dotan, Yuval Gordon, Microsoft Defender for IoT Research Team

Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post MCCrash: Cross-platform DDoS botnet targets private Minecraft servers appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-0832 is now tracked as Vanilla Tempest.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

In recent months, Microsoft has detected active ransomware and extortion campaigns impacting the global education sector, particularly in the US, by a threat actor we track as DEV-0832, also known as Vice Society. Shifting ransomware payloads over time from BlackCat, QuantumLocker, and Zeppelin, DEV-0832’s latest payload is a Zeppelin variant that includes Vice Society-specific file extensions, such as .v-s0ciety, .v-society, and, most recently, .locked. In several cases, Microsoft assesses that the group did not deploy ransomware and instead possibly performed extortion using only exfiltrated stolen data.

DEV-0832 is a cybercriminal group that has reportedly been active as early as June 2021. While the latest attacks between July and October 2022 have heavily impacted the education sector, DEV-0832’s previous opportunistic attacks have affected various industries like local government and retail. Microsoft assesses that the group is financially motivated and continues to focus on organizations where there are weaker security controls and a higher likelihood of compromise and ransom payout. Before deploying ransomware, DEV-0832 relies on tactics, techniques, and procedures commonly used among other ransomware actors, including the use of PowerShell scripts, repurposed legitimate tools, exploits for publicly disclosed vulnerabilities for initial access and post-compromise elevation of privilege, and commodity backdoors like SystemBC.

Ransomware has evolved into a complex threat that’s human-operated, adaptive, and focused on a wider scale, using data extortion as a monetization strategy to become even more impactful in recent years. To find easy entry and privilege escalation points in an environment, these attackers often take advantage of poor credential hygiene and legacy configurations or misconfigurations. Defenders can build a robust defense against ransomware by reading our ransomware as a service blog.

In this blog, we detail Microsoft’s analysis of observed DEV-0832 activity, including the tactics and techniques used across the group’s campaigns, with the goal of helping customers identify, investigate, and remediate activity in their environments. We provide hunting queries to help customers comprehensively search their environments for relevant indicators as well as protection and hardening guidance to help organizations increase resilience against these and similar attacks.

Who is DEV-0832 (Vice Society)?

Microsoft has identified multiple campaigns attributed to DEV-0832 over the past year based on the use of a unique PowerShell file name, staging directories, and ransom payloads and their accompanying notes. To gain an initial foothold in compromised networks, DEV-0832 has reportedly exploited vulnerable web-facing applications and used valid accounts. However, due to limited initial signals from affected organizations, Microsoft has not confirmed these attack vectors. Attackers then use custom PowerShell scripts, commodity tools, exploits for disclosed vulnerabilities, and native Windows binaries to gather privileged credentials, move laterally, collect and exfiltrate data, and deploy ransomware.

After deploying ransomware, DEV-0832 demands a ransom payment, threatening to leak stolen data on the group’s [.]onion site. In some cases, Microsoft observed that DEV-0832 did not deploy ransomware. Instead, the actors appeared to exfiltrate data and dwell within compromised networks. The group sometimes avoids a ransomware payload in favor of simple extortion—threatening to release stolen data unless a payment is made.

The group also goes to significant measures to ensure that an organization cannot recover from the attack without paying the ransom: Microsoft has observed DEV-0832 access two domain administrator accounts and reset user passwords of over 150,000 users, essentially locking out legitimate users before deploying ransomware to some devices. This effectively interrupts remediation efforts, including attempts to prevent the ransomware payload or post-compromise incident response.

Toolset

Ransomware payloads

Microsoft has observed DEV-0832 deploy multiple commodity ransomware variants over the past year: BlackCat, QuantumLocker, Zeppelin, and most recently a Vice Society-branded variant of the Zeppelin ransomware. While many ransomware groups have shifted away from branded file extensions in favor of randomly generated ones, DEV-0832 incorporated branding with their Vice Society variant using .v-s0ciety or .v-society file extensions. Most recently in late September 2022, DEV-0832 again modified their ransomware payload to a variant dubbed RedAlert, using a .locked file extension.

In one July 2022 intrusion, Microsoft security researchers identified DEV-0832 attempt to deploy QuantumLocker binaries, then within five hours, attempt to deploy suspected Zeppelin ransomware binaries. Such an incident might suggest that DEV-0832 maintains multiple ransomware payloads and switches depending on target defenses or, alternatively, that dispersed operators working under the DEV-0832 umbrella might maintain their own preferred ransomware payloads for distribution. The shift from a ransomware as a service (RaaS) offering (BlackCat) to a purchased wholly-owned malware offering (Zeppelin) and a custom Vice Society variant indicates DEV-0832 has active ties in the cybercriminal economy and has been testing ransomware payload efficacy or post-ransomware extortion opportunities.

In many intrusions, DEV-0832 stages their ransomware payloads in a hidden share on a Windows system, for example accessed via a share name containing “$”. Once DEV-0832 has exfiltrated data, they then distribute the ransomware onto local devices for launching, likely using group policy, as shown in the below command:

The group also has cross-platform capabilities: Microsoft identified the deployment of a Vice Society Linux Encryptor on a Linux ESXi server.

PowerShell scripts

DEV-0832 uses a PowerShell script to conduct a variety of malicious activities and make system-related changes within compromised networks. Like their ransomware payloads, DEV-0832 typically stages their PowerShell scripts on a domain controller.

Microsoft security researchers have observed several variations among identified DEV-0832 PowerShell scripts, indicating ongoing refinement and development over time—while some only perform system discovery commands, other scripts are further modified to perform persistence, defense evasion, data exfiltration, and even distribute the ransomware payloads.

Commodity tools

According to Microsoft investigations, DEV-0832 has used two commodity backdoors in ransomware attacks: SystemBC and PortStarter.

SystemBC is a post-compromise commodity remote access trojan (RAT) and proxy tool that has been incorporated into multiple diverse ransomware attacks. In one DEV-0832 intrusion, the attacker used both a compromised domain admin user account and a compromised contractor account to launch a PowerShell command that launched a SystemBC session under the value name “socks”:

PortStarter is a backdoor written in Go. According to Microsoft analysis, this malware provides functionality such as modifying firewall settings and opening ports to connect to pre-configured command-and-control (C2) servers.

DEV-0832 has also deployed ransomware payloads using the remote launching tool Power Admin. Power Admin is a legitimate tool that provides functionality to monitor servers and applications, as well as file access auditing. If an organization has enabled Console Security settings within Power Admin, an attacker must have credentials to make authorized changes.

Other commodity tools identified in DEV-0832 attacks include Advanced Port Scanner and Advanced IP Scanner for network discovery.

Abuse of legitimate tooling

Like many other ransomware actors, DEV-0832 relies on misusing legitimate system tools to reduce the need to launch malware or malicious scripts that automated security solutions might detect. Observed tools include:

• Use of the Windows Management Instrumentation Command-line (WMIC) to launch commands that delete Mongo databases, other backups, and security programs.
• Use of Impacket’s WMIexec functionality, an open-source tool to launch commands via WMI, and Impacket atexec.py, which launches commands using Task Scheduler.
• Use of the vssadmin command to delete shadow copy backups on Windows Server.
• Use of PsExec to remotely launch PowerShell, batch scripts, and deploy ransomware payloads

Additionally, in one identified intrusion, DEV-0832 attempted to turn off Microsoft Defender Antivirus using registry commands. Enabling Microsoft Defender Antivirus tamper protection helps block this type of activity.

Harvesting privileged credentials for ransomware deployment

Like other ransomware groups, after gaining an initial foothold within a network, DEV-0832 moves quickly to gather valid administrator local or domain credentials to ensure they can distribute ransomware payloads throughout the network for maximum impact.

Credential dumps

While Microsoft has not identified all the credential access techniques of DEV-0832, in many instances DEV-0832 accesses Local Security Authority Server Service (LSASS) dumps to obtain valid account credentials that were present in memory. Microsoft also observed that, instead of using a tool like Mimikatz to access a credential dump, DEV-0832 typically abuses the tool comsvcs.dll along with MiniDump to dump the LSASS process memory. Other ransomware actors have been observed using the same technique.

In cases where DEV-0832 obtained domain-level administrator accounts, they accessed NTDS dumps for later cracking. The following command shows the attacker exfiltrating the NTDS.dit file, which stores Active Directory data to an actor-created directory:

Kerberoast

Microsoft has also identified DEV-0832 used the malicious PowerSploit module Invoke-Kerberoast to perform a Kerberoast attack, which is a post-exploitation technique used to obtain credentials for a service account from Active Directory Domain Services (AD DS). The Invoke-Kerberoast module requests encrypted service tickets and returns them in an attacker-specified output format compatible with cracking tools. The group can use the cracked Kerberos hashes to reveal passwords for service accounts, often providing access to an account that has the equivalent of domain admin privileges. Furthermore, one Kerberos service ticket can have many associated service principal names (SPNs); successful Kerberoasting can then grant an attacker access to the SPNs’ associated service or user accounts, such as obtaining ticket granting service (TGS) tickets for Active Directory SPNs that would allow an attacker to do offline password cracking.

Combined with the fact that service account passwords are not usually set to expire and typically remain unchanged for a great length of time, attackers like DEV-0832 continue to rely on Kerberoasting in compromised networks. Microsoft 365 Defender blocks this attack with Antimalware Scan Interface (AMSI) and machine learning. Monitor for alerts that reference Kerberoast attacks closely as the presence of these alerts typically indicates a human adversary in your environment.

Account creation

In one suspected DEV-0832 intrusion, Microsoft observed an operator create accounts that, based on the naming convention, were designed to blend in as admin accounts and allow persistence without malware, as shown in the following command:

Monitoring newly created accounts can help identify this type of suspicious activity that does not rely on launching malware for persistence in the environment.

Exploitation of privilege escalation vulnerabilities

In August 2022, Microsoft security researchers identified one file during a DEV-0832 intrusion indicating that the group has incorporated an exploit for the disclosed, patched security flaw CVE-2022-24521 (Windows Common Log File System (CLFS) logical-error vulnerability). Microsoft released a patch in April 2022. The DEV-0832 file spawns a new cmd.exe process with system privileges.

According to public reporting, DEV-0832 has also incorporated exploits for the PrintNightmare vulnerability to escalate privileges in a domain. Combined with the CVE-2022-24521 exploit code, it is likely that DEV-0832, like many other adversaries, quickly incorporates available exploit code for disclosed vulnerabilities into their toolset to target unpatched systems.

Lateral movement with valid accounts

After gaining credentials, DEV-0832 frequently moves laterally within a network using Remote Desktop Protocol (RDP). And as previously mentioned, DEV-0832 has also used valid credentials to interact with remote network shares over Server Message Block (SMB) where they stage ransomware payloads and PowerShell scripts.

Data exfiltration

In one known intrusion, DEV-0832 operators exfiltrated hundreds of gigabytes of data by launching their PowerShell script, which was staged on a network share. The script contained hardcoded attacker-owned IP addresses and searched for wide-ranging, non-targeted keywords ranging from financial documents to medical information, while excluding files containing keywords such as varied antivirus product names or file artifact extensions. Given the wide range of keywords included in the script, it is unlikely that DEV-0832 regularly customizes it for each target.

Microsoft suspects that DEV-0832 uses legitimate tools Rclone and MegaSync for data exfiltration as well; many ransomware actors leverage these tools, which provide capabilities to upload files to cloud storage. DEV-0832 also uses file compression tools to collect data from compromised devices.

Mitigations

Apply these mitigations to reduce the impact of this threat:

• Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.
• Use Microsoft Defender Vulnerability Management to assess your current status and deploy any updates that might have been missed.
• Utilize Microsoft Defender Firewall, intrusion prevention devices, and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• LSA protection is enabled by default on new Windows 11 devices, hardening the platform against credential dumping techniques. LSA PPL protection will further restrict access to memory dumps making it hard to obtain credentials.
• Refer to Microsoft’s blog Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself for recommendations on building strong credential hygiene and other robust measures to defend against ransomware.

Microsoft customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any administrator, offer significant hardening against ransomware attacks. In observed attacks, Microsoft customers who had the following rules enabled were able to mitigate the attack in the initial stages and prevented hands-on-keyboard activity:

• Block process creations originating from PsExec and WMI commands
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects DEV-0832’s Vice Society-branded Zeppelin variant as the following malware:

• Ransom:Win32/VSocCrypt
• Trojan:PowerShell/VSocCrypt
• Ransom:Linux/ViceSociety

Other commodity ransomware variants previously leveraged by DEV-0832 are detected as:

• Behavior:Win32/Ransomware!Quantum.A
• Behavior:Win32/Quantum.AA
• Ransom:Win32/Zeppelin
• Ransom:Win32/Blackcat

SystemBC and PortStarter are detected as:

• Behavior:Win32/SystemBC
• Trojan:Win32/SystemBC
• Backdoor:Win64/PortStarter

Some pre-ransomware intrusion activity used in multiple campaigns by various activity groups can be detected generically. During identified DEV-0832 activity, associated command line activity was detected with generic detections, including:

• Behavior:Win32/OfficeInjectingProc.A
• Behavior:Win32/PsexecRemote.E
• Behavior:Win32/SuspRemoteCopy.B
• Behavior:Win32/PSCodeInjector.A
• Behavior:Win32/REnamedPowerShell.A

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate threat activity on your network:

• DEV-0832 activity group
• ‘VSocCrypt’ ransomware was prevented

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Use of living-off-the-land binary to run malicious code
• Potential SystemBC execution via Windows Task Scheduler
• Suspicious sequence of exploration activities
• Process memory dump
• Suspicious behavior by cmd.exe was observed
• Suspicious remote activity
• Suspicious access to LSASS service
• Suspicious credential dump from NTDS.dit
• File backups were deleted
• System recovery setting tampering

The post DEV-0832 (Vice Society) opportunistic ransomware campaigns impacting US education sector appeared first on Microsoft Security Blog.

After carefully reviewing the implications, a Microsoft security researcher shared the vulnerability with Google in April 2022 and also reported it with the Chromium bug tracking system. Fixes for the vulnerability, which is assigned as CVE-2022-2587 and has a Common Vulnerability Scoring System (CVSS) score of 9.8 (classifying the vulnerability as critical), were quickly released and have been successfully deployed to end users. We’d like to thank the Google team and the Chromium community for their professional resolution and collaborative efforts.

This research coupled with the recent release of ChromeOS Flex, which can convert various legacy PCs and Macs into Chromebooks, emphasizes the importance of analyzing and monitoring security for devices running ChromeOS. Moreover, as even the most hardened operating systems might contain security bugs, we emphasize the need for strong monitoring of all cross-platform devices and operating systems. The best approach for protecting unmanaged devices is by using Microsoft Defender for Endpoint’s device discovery capabilities to monitor suspicious traffic and help detect attacker activities on such devices.

In this blog post, we share some information about the vulnerability and examine how it could be triggered as well as the possible implications. Displaying how our cross-domain expertise helps us uncover new and unknown threats in the effort to continually improve security for all, we also share details from our research with the larger security community to emphasize the importance of collaboration to secure platforms and devices.

An overview of ChromeOS security

One well-known operating system that uses D-Bus is ChromeOS. ChromeOS is a Google-proprietary Linux-based operating system that runs on Chromebooks, Chromeboxes, Chromebits and Chromebases. ChromeOS is a closed-source system with open-source components that are derived from ChromiumOS, and the operating system uses Google’s own Chrome browser as its principal user interface.

In terms of security, ChromeOS is well hardened; some of the security features on ChromeOS include:

• Hardened sandbox (called minijail)
• Verified boot
• Locked-down filesystem (mounted with noexec, nosuid, nodev) and dm-verity
• Root user restrictions (SECURE_NOROOT)
• When development mode is entered, all locally stored data is wiped

As with other modern browsers, exploiting ChromeOS usually requires chaining vulnerabilities together. Due to hardening measures in ChromeOS, discovering vulnerabilities became a specific niche and, therefore, the number of public vulnerabilities is quite low compared to other operating systems. ChromeOS vulnerabilities generally fall into one of three different classes:

1. ChromeOS-specific logic vulnerabilities
2. ChromeOS-specific memory-corruption vulnerabilities
3. Broader threats such as Chrome browser vulnerabilities

In this case, the discovered vulnerability falls under the second class, ChromeOS-specific memory-corruption vulnerabilities.

Bug hunting

Having discussed and extensively researched D-Bus, we continued this analysis by enumerating the D-Bus services offered on ChromeOS. In general, D-Bus is an Inter-Process-Communication (IPC) mechanism that’s popular on desktop platforms, specifically Linux.

ChromeOS’s developer mode offers the dbus-send utility to send messages over D-bus. As there are many D-Bus services offered on ChromeOS (usually identified by the “org.chromium” prefix), we automated the process and used the dbus-send utility to fetch the full tree of services and their exported methods and signals.

Because most D-Bus services support the org.freedesktop.DBus.Introspectable interface, it’s possible to dynamically fetch exported methods and signals without reading the source code or reverse-engineering the binaries.

Fetching all the exported service names can be performed using the following command:

dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Using org.chromium.ResourceManager as an example, each service can then be enumerated for its declared methods and signals via the following command:

dbus-send --system --dest=org.chromium.ResourceManager --type=method_call --print-reply /org/chromium/ResourceManager org.freedesktop.DBus.Introspectable.Introspect

Considering that the more input a method receives, the higher the probability of finding a security issue, we then focused on methods that export arbitrarily large inputs, such as strings or arrays. It wasn’t long before we found an interesting service: org.chromium.cras.

The vulnerability

The org.chromium.cras D-Bus name is owned by CRAS (ChromiumOS Audio Server), which has a well-documented architecture under the ChromiumOS wiki pages. In essence, CRAS is a server that resides between the operating system and ALSA (Advanced Linux Sound Architecture) as a means of routing audio to newly attached audio-supporting peripherals, like USB speakers and Bluetooth headsets.

Reviewing the exported methods uncovered one method with a particularly interesting handling function: SetPlayerIdentity, which gets one string (an argument called identity) as an input. Since ChromiumOS is open-sourced, tracking the calls is straightforward:

1. In cras_dbus_control.c, the handler function for SetPlayerIdentity is handle_set_player_identity, which extracts the identity argument from the D-Bus message and invoke the cras_bt_player_update_identity function.
2. In cras_bt_player.c, the function cras_bt_player_update_identity that was called checks that the identity input value is not null and is different than the current player identity string (saved under player.identity). If so, it copies the identity variable to player.identity using the C library function strcpy. Of note, “player” is a global variable in the cras_bt_player module and includes an identity field in it, among others.

To the experienced security engineer, the mention of the strcpy function immediately raises red flags. The strcpy function is known to cause various memory corruption vulnerabilities since it doesn’t perform any bounds check and is therefore considered unsafe. As there are no bounds checks on the user-supplied identity argument before invoking strcpy (besides the default message length limitations for D-Bus messages), we were confident we could trigger a heap-based buffer overflow, therefore triggering a memory corruption vulnerability.

Heap-based buffer overflows can be the cause of multiple vulnerabilities, most notoriously leading to arbitrary code execution through various means. This could include overriding a function callback in an allocated object or overriding chunk metadata, which can trigger other unexpected behavior during the lifetime of a program.

Checking how the player.identity string is initialized shows that it’s set in the cras_bt_player_init function as the result of malloc(128), which means it’s allocated on the user’s heap with 128 bytes.

Therefore, the vulnerability could be triggered using a single command line by sending the identity user-controlled D-Bus argument with more than 128 bytes, as displayed in our example code below:

dbus-send --system --dest=org.chromium.cras --type=method_call --print-reply /org/chromium/cras org.chromium.cras.Control.SetPlayerIdentity string:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

As most users don’t need to enable ChromeOS’s developer mode and, thus, can’t use the dbus-send utility, our next task was to find a way to trigger the bug without using developer mode.

Triggering the bug remotely

Thinking we spotted a local memory corruption issue, we wanted to better understand how to trigger the bug. Since the involved functions exclusively get triggered from D-Bus, we looked for functions that trigger the SetPlayerIdentity D-Bus method—if the arguments to those don’t have bounds checks, then those functions could be used to trigger the vulnerability.

Examining the open-source ChromiumOS repositories found that the CRAS audio client invokes the SetPlayerIdentity method (and exports a function with the same name). In turn, it’s called by the CRAS audio handler component’s method MediaSessionMetadataChanged, which extracts the identity from a metadata structure representing a song’s title:

At this point, it was clear that the vulnerability could be triggered via changes to the audio metadata. Looking for MediaSessionMetadataChanged invocations revealed two interesting cases that could both be triggered remotely:

1. From the browser: the browser’s media component invokes the function when metadata is changed, such as when playing a new song in the browser.
2. From Bluetooth: the media session service in the operating system invokes the function when a song’s metadata changes, which can happen when playing a new song from a paired Bluetooth device.

Implications and reporting

We reported the vulnerability to Google in April 2022 as a part of the Chromium bug tracking system and were assigned Issue 1320917, which immediately got assigned as a priority 1 security bug. In parallel, we tracked the issue internally in Microsoft Security Vulnerability Research (MSVR), while using OSINT to look for indications of that vulnerability being used in the wild. We did not find any indications of in-the-wild exploitation.

The impact of heap-based buffer overflow ranges from simple DoS to full-fledged RCE. Although it’s possible to allocate and free chunks through media metadata manipulation, performing the precise heap-grooming is not trivial in this case and attackers would need to chain the exploit with other vulnerabilities to successfully execute any arbitrary code. Given the potential impact of the vulnerability, coupled with the fact that it could be remotely triggered, it’s a security risk that justifies the bug priority and how fast the fix was issued.

We were impressed with the speed of the fix and the effectiveness of the overall process. Within less than a week, the code was committed and, after several merges, made generally available to users. We thank the Google team and the Chromium community for their efforts in addressing the issue.

Improving security for all through research and threat intelligence sharing

As the threat and computing landscape continues to evolve, Microsoft strives to continuously improve security for all through research-driven protections and collaboration with customers, partners, and industry experts, regardless of the device or platform in use.

To defend against the evolving threat landscape, organizations must closely monitor all devices and operating systems across platforms, including unmanaged devices. Unmanaged devices are sometimes ignored or missed by security teams at join time, making them attractive targets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving persistence for the sake of launching broader attacks. Microsoft Defender for Endpoint’s device discovery capabilities help organizations find certain unmanaged devices, including those running ChromeOS, and can detect if they are being operated by attackers when they start performing network interactions with servers and other managed devices.

Microsoft security researchers continually work to discover new vulnerabilities and threats, turning knowledge of a variety of wide-reaching issues into improved solutions that protect users and organizations across platforms every single day. This case displays how vulnerability disclosures and threat intelligence sharing are essential to effectively mitigate issues and protect users against present and future threats. Moreover, by expanding upon our prior research, we can also continue to make positive contributions to the overall security of devices worldwide, even on platforms we currently don’t directly support.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Uncovering a ChromeOS remote memory corruption vulnerability appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-0237 is now tracked as Pistachio Tempest and DEV-504 is now tracked as Velvet Tempest.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The BlackCat ransomware, also known as ALPHV, is a prevalent threat and a prime example of the growing ransomware as a service (RaaS) gig economy. It’s noteworthy due to its unconventional programming language (Rust), multiple target devices and possible entry points, and affiliation with prolific threat activity groups. While BlackCat’s arrival and execution vary based on the actors deploying it, the outcome is the same—target data is encrypted, exfiltrated, and used for “double extortion,” where attackers threaten to release the stolen data to the public if the ransom isn’t paid.

First observed in November 2021, BlackCat initially made headlines because it was one of the first ransomware families written in the Rust programming language. By using a modern language for its payload, this ransomware attempts to evade detection, especially by conventional security solutions that might still be catching up in their ability to analyze and parse binaries written in such language. BlackCat can also target multiple devices and operating systems. Microsoft has observed successful attacks against Windows and Linux devices and VMWare instances.

As we previously explained, the RaaS affiliate model consists of multiple players: access brokers, who compromise networks and maintain persistence; RaaS operators, who develop tools; and RaaS affiliates, who perform other activities like moving laterally across the network and exfiltrating data before ultimately launching the ransomware payload. Thus, as a RaaS payload, how BlackCat enters a target organization’s network varies, depending on the RaaS affiliate that deploys it. For example, while the common entry vectors for these threat actors include remote desktop applications and compromised credentials, we also saw a threat actor leverage Exchange server vulnerabilities to gain target network access. In addition, at least two known affiliates are now adopting BlackCat: DEV-0237 (known for previously deploying Ryuk, Conti, and Hive) and DEV-0504 (previously deployed Ryuk, REvil, BlackMatter, and Conti).

Such variations and adoptions markedly increase an organization’s risk of encountering BlackCat and pose challenges in detecting and defending against it because these actors and groups have different tactics, techniques, and procedures (TTPs). Thus, no two BlackCat “lives” or deployments might look the same. Indeed, based on Microsoft threat data, the impact of this ransomware has been noted in various countries and regions in Africa, the Americas, Asia, and Europe.

Human-operated ransomware attacks like those that deploy BlackCat continue to evolve and remain one of the attackers’ preferred methods to monetize their attacks. Organizations should consider complementing their security best practices and policies with a comprehensive solution like Microsoft 365 Defender, which offers protection capabilities that correlate various threat signals to detect and block such attacks and their follow-on activities.

In this blog, we provide details about the ransomware’s techniques and capabilities. We also take a deep dive into two incidents we’ve observed where BlackCat was deployed, as well as additional information about the threat activity groups that now deliver it. Finally, we offer best practices and recommendations to help defenders protect their organizations against this threat, including hunting queries and product-specific mitigations.

BlackCat’s anatomy: Payload capabilities

As mentioned earlier, BlackCat is one of the first ransomware written in the Rust programming language. Its use of a modern language exemplifies a recent trend where threat actors switch to languages like Rust or Go for their payloads in their attempt to not only avoid detection by conventional security solutions but also to challenge defenders who may be trying to reverse engineer the said payloads or compare them to similar threats.

BlackCat can target and encrypt Windows and Linux devices and VMWare instances. It has extensive capabilities, including self-propagation configurable by an affiliate for their usage and to environment encountered.

In the instances we’ve observed where the BlackCat payload did not have administrator privileges, the payload was launched via dllhost.exe, which then launched the following commands below (Table 1) via cmd.exe. These commands could vary, as the BlackCat payload allows affiliates to customize execution to the environment.

The flags used by the attackers and the options available were the following: -s -d -f -c; –access-token; –propagated; -no-prop-servers

User account control (UAC) bypass

BlackCat can bypass UAC, which means the payload will successfully run even if it runs from a non-administrator context. If the ransomware isn’t run with administrative privileges, it runs a secondary process under dllhost.exe with sufficient permissions needed to encrypt the maximum number of files on the system.

Domain and device enumeration

The ransomware can determine the computer name of the given system, local drives on a device, and the AD domain name and username on a device. The malware can also identify whether a user has domain admin privileges, thus increasing its capability of ransoming more devices.

Self-propagation

BlackCat discovers all servers that are connected to a network. The process first broadcasts NetBIOS Name Service (NBNC) messages to check for these additional devices. The ransomware then attempts to replicate itself on the answering servers using the credentials specified within the config via PsExec.

Hampering recovery efforts

BlackCat has numerous methods to make recovery efforts more difficult. The following are commands that might be launched by the payload, as well as their purposes:

• Modify boot loader
  • “C:\Windows\system32\cmd.exe” /c “bcdedit /set {default}”
  • “C:\Windows\system32\cmd.exe” /c “bcdedit /set {default} recoveryenabled No”
• Delete volume shadow copies
  • “C:\Windows\system32\cmd.exe” /c “vssadmin.exe Delete Shadows /all /quiet”
  • “C:\Windows\system32\cmd.exe” /c “wmic.exe Shadowcopy Delete”
• Clear Windows event logs
  • “C:\Windows\system32\cmd.exe” /c “cmd.exe /c  for /F \”tokens=*\” Incorrect function. in (‘ wevtutil.exe el ‘) DO wevtutil.exe cl \”Incorrect function. \””

Slinking its way in: Identifying attacks that can lead to BlackCat ransomware

Consistent with the RaaS model, threat actors utilize BlackCat as an additional payload to their ongoing campaigns. While their TTPs remain largely the same (for example, using tools like Mimikatz and PsExec to deploy the ransomware payload), BlackCat-related compromises have varying entry vectors, depending on the ransomware affiliate conducting the attack. Therefore, the pre-ransom steps of these attacks can also be markedly different.

For example, our research noted that one affiliate that deployed BlackCat leveraged unpatched Exchange servers or used stolen credentials to access target networks. The following sections detail the end-to-end attack chains of these two incidents we’ve observed.

Case study 1: Entry via unpatched Exchange

In one incident we’ve observed, attackers took advantage of an unpatched Exchange server to enter the target organization.

Discovery

Upon exploiting the Exchange vulnerability, the attackers launched the following discovery commands to gather information about the device they had compromised:

• cmd.exe and the commands ver and systeminfo – to collect operating system information
• net.exe – to determine domain computers, domain controllers, and domain admins in the environment

After executing these commands, the attackers navigated through directories and discovered a passwords folder that granted them access to account credentials they could use in the subsequent stages of the attack. They also used the del command to delete files related to their initial compromise activity.

The attackers then mounted a network share using net use and the stolen credentials and began looking for potential lateral movement targets using a combination of methods. First, they used WMIC.exe using the previously gathered device name as the node, launched the command whoami /all, and pinged google.com to check network connectivity. The output of the results were then written to a .log file on the mounted share. Second, the attackers used PowerShell.exe with the cmdlet Get-ADComputer and a filter to gather the last sign-in event.

Lateral movement

Two and a half days later, the attackers signed into one of the target devices they found during their initial discovery efforts using compromised credentials via interactive sign-in. They opted for a credential theft technique that didn’t require dropping a file like Mimikatz that antivirus products might detect. Instead, they opened Taskmgr.exe, created a dump file of the LSASS.exe process, and saved the file to a ZIP archive.

The attackers continued their previous discovery efforts using a PowerShell script version of ADRecon (ADRecon.ps1), which is a tool designed to gather extensive information about an Active Directory (AD) environment. The attacker followed up this action with a net scanning tool that opened connections to devices in the organization on server message block (SMB) and remote desktop protocol (RDP). For discovered devices, the attackers attempted to navigate to various network shares and used the Remote Desktop client (mstsc.exe) to sign into these devices, once again using the compromised account credentials.

These behaviors continued for days, with the attackers signing into numerous devices throughout the organization, dumping credentials, and determining what devices they could access.

Collection and exfiltration

On many of the devices the attackers signed into, efforts were made to collect and exfiltrate extensive amounts of data from the organization, including domain settings and information and intellectual property. To do this, the attackers used both MEGAsync and Rclone, which were renamed as legitimate Windows process names (for example, winlogon.exe, mstsc.exe).

Exfiltration of domain information to identify targets for lateral movement

Collecting domain information allowed the attackers to progress further in their attack because the said information could identify potential targets for lateral movement or those that would help the attackers distribute their ransomware payload. To do this, the attackers once again used ADRecon.ps1with numerous PowerShell cmdlets such as the following:

• Get-ADRGPO – gets group policy objects (GPO) in a domain
• Get-ADRDNSZone – gets all DNS zones and records in a domain
• Get-ADRGPLink – gets all group policy links applied to a scope of management in a domain

Additionally, the attackers dropped and used ADFind.exe commands to gather information on persons, computers, organizational units, and trust information, as well as pinged dozens of devices to check connectivity.

Exfiltration for double extortion

Intellectual property theft likely allowed the attackers to threaten the release of information if the subsequent ransom wasn’t paid—a practice known as “double extortion.” To steal intellectual property, the attackers targeted and collected data from SQL databases. They also navigated through directories and project folders, among others, of each device they could access, then exfiltrated the data they found in those. 

The exfiltration occurred for multiple days on multiple devices, which allowed the attackers to gather large volumes of information that they could then use for double extortion.

Encryption and ransom

It was a full two weeks from the initial compromise before the attackers progressed to ransomware deployment, thus highlighting the need for triaging and scoping out alert activity to understand accounts and the scope of access an attacker gained from their activity. Distribution of the ransomware payload using PsExec.exe proved to be the most common attack method.

Case study 2: Entry via compromised credentials

In another incident we observed, we found that a ransomware affiliate gained initial access to the environment via an internet-facing Remote Desktop server using compromised credentials to sign in.

Lateral movement

Once the attackers gained access to the target environment, they then used SMB to copy over and launch the Total Deployment Software administrative tool, allowing remote automated software deployment. Once this tool was installed, the attackers used it to install ScreenConnect (now known as ConnectWise), a remote desktop software application.

Credential theft

ScreenConnect was used to establish a remote session on the device, allowing attackers interactive control. With the device in their control, the attackers used cmd.exe to update the Registry to allow cleartext authentication via WDigest, and thus saved the attackers time by not having to crack password hashes. Shortly later, they used the Task Manager to dump the LSASS.exe process to steal the password, now in cleartext.

Eight hours later, the attackers reconnected to the device and stole credentials again. This time, however, they dropped and launched Mimikatz for the credential theft routine, likely because it can grab credentials beyond those stored in LSASS.exe. The attackers then signed out.

Persistence and encryption

A day later, the attackers returned to the environment using ScreenConnect. They used PowerShell to launch a command prompt process and then added a user account to the device using net.exe. The new user was then added to the local administrator group via net.exe.

Afterward, the attackers signed in using their newly created user account and began dropping and launching the ransomware payload. This account would also serve as a means of additional persistence beyond ScreenConnect and their other footholds in the environment to allow them to re-establish their presence, if needed. Ransomware adversaries are not above ransoming the same organization twice if access is not fully remediated.

Chrome.exe was used to navigate to a domain hosting the BlackCat payload. Notably, the folder structure included the organization name, indicating that this was a pre-staged payload specifically for the organization. Finally, the attackers launched the BlackCat payload on the device to encrypt its data.

Ransomware affiliates deploying BlackCat

Apart from the incidents discussed earlier, we’ve also observed two of the most prolific affiliate groups associated with ransomware deployments have switched to deploying BlackCat. Payload switching is typical for some RaaS affiliates to ensure business continuity or if there’s a possibility of better profit. Unfortunately for organizations, such adoption further adds to the challenge of detecting related threats.

Microsoft tracks one of these affiliate groups as DEV-0237. Also known as FIN12, DEV-0237 is notable for its distribution of Hive, Conti, and Ryuk ransomware. We’ve observed that this group added BlackCat to their list of distributed payloads beginning March 2022. Their switch to BlackCat from their last used payload (Hive) is suspected to be due to the public discourse around the latter’s decryption methodologies.

DEV-0504 is another active affiliate group that we’ve seen switching to BlackCat for their ransomware attacks. Like many RaaS affiliate groups, the following TTPs might be observed in a DEV-0504 attack:

• Entry vector that can involve the affiliate remotely signing into devices with compromised credentials, such as into devices running software solutions that allow for remote work
• The attackers’ use of their access to conduct discovery on the domain
• Lateral movement that potentially uses the initial compromised account
• Credential theft with tools like Mimikatz and Rubeus

DEV-0504 typically exfiltrates data on devices they compromise from the organization using a malicious tool such as StealBit—often named “send.exe” or “sender.exe”. PsExec is then used to distribute the ransomware payload. The group has been observed delivering the following ransom families before their adoption of BlackCat beginning December 2021:

• BlackMatter
• Conti
• LockBit 2.0
• Revil
• Ryuk

Defending against BlackCat ransomware

Today’s ransomware attacks have become more impactful because of their growing industrialization through the RaaS affiliate model and the increasing trend of double extortion. The incidents we’ve observed related to the BlackCat ransomware leverage these two factors, making this threat durable against conventional security and defense approaches that only focus on detecting the ransomware payloads. Detecting threats like BlackCat, while good, is no longer enough as human-operated ransomware continues to grow, evolve, and adapt to the networks they’re deployed or the attackers they work for.

Instead, organizations must shift their defensive strategies to prevent the end-to-end attack chain. As noted above, while attackers’ entry points may vary, their TTPs remain largely the same. In addition, these types of attacks continue to take advantage of an organization’s poor credential hygiene and legacy configurations or misconfigurations to succeed. Therefore, defenders should address these common paths and weaknesses by hardening their networks through various best practices such as access monitoring and proper patch management. We provide detailed steps on building these defensive strategies against ransomware in this blog.

In the BlackCat-related incidents we’ve observed, the common entry points for ransomware affiliates were via compromised credentials to access internet-facing remote access software and unpatched Exchange servers. Therefore, defenders should review their organization’s identity posture, carefully monitor external access, and locate vulnerable Exchange servers in their environment to update as soon as possible. The financial impact, reputation damage, and other repercussions that stem from attacks involving ransomware like BlackCat are not worth forgoing downtime, service interruption, and other pain points related to applying security updates and implementing best practices.

Leveraging Microsoft 365 Defender’s comprehensive threat defense capabilities

Microsoft 365 Defender helps protect organizations from attacks that deliver the BlackCat ransomware and other similar threats by providing cross-domain visibility and coordinated threat defense. It uses multiple layers of dynamic protection technologies and correlates threat data from email, endpoints, identities, and cloud apps. Microsoft Defender for Endpoint detects tools like Mimikatz, the actual BlackCat payload, and subsequent attacker behavior. Threat and vulnerability management capabilities also help discover vulnerable or misconfigured devices across different platforms; such capabilities could help detect and block possible exploitation attempts on vulnerable devices, such as those running Exchange. Finally, advanced hunting lets defenders create custom detections to proactively surface this ransomware and other related threats.

Additional mitigations and recommendations

Defenders can also follow the following steps to reduce the impact of this ransomware:

• Turn on Microsoft Defender Antivirus. Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a large amount of new and unknown variants.
• Enforce strong, randomized local administrator passwords. Use tools like Local Administrator Password Solution (LAPS).
• Require multifactor authentication (MFA) for local device access, RDP access, and remote connections through virtual private networks (VPNs) and Outlook Web Access. Solutions like Windows Hello or Fast ID Online (FIDO) v2.0 security keys let users sign in using biometrics and/or a physical key or device.
• Turn on Microsoft Defender Firewall.
• Implement controlled folder access to help prevent files from being altered or encrypted by ransomware. Set controlled folder access to Enabled or Audit mode.
• Investigate and remediate vulnerabilities in Exchange servers. Also, determine if implementing the Exchange Emergency Mitigation service is feasible for your environment. This service helps keep your Exchange servers secure by applying mitigations to address potential threats against your servers.

Microsoft 365 Defender customers can also apply the additional mitigations below:

• Use advanced protection against ransomware.
• Turn on tamper protection in Microsoft Defender for Endpoint to prevent malicious changes to security settings. Enable network protection in Microsoft Defender for Endpoint and Microsoft 365 Defender to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Ensure Exchange servers have applied the mitigations referenced in the related Threat Analytics report.
• Turn on the following attack surface reduction rules to block or audit activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

For a full list of ransomware mitigations regardless of threat, refer to this article: Rapidly protect against ransomware and extortion.

Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Microsoft 365 Defender Threat Intelligence Team

Appendix

Microsoft 365 Defender detections

Microsoft Defender Antivirus

• Ransom:Win32/BlackCat!MSR
• Ransom:Win32/BlackCat.MK!MTB
• Ransom:Linux/BlackCat.A!MTB

Microsoft Defender for Endpoint EDR

Alerts with the following titles in the security center can indicate threat activity on your network:

• An active ‘BlackCat’ ransomware was detected
• ‘BlackCat’ ransomware was detected
• BlackCat ransomware

Hunting queries

Microsoft 365 Defender

To locate possible ransomware activity, run the following queries.

Suspicious process execution in PerfLogs path

Use this query to look for processes executing in PerfLogs—a common path used to place the ransomware payloads.

DeviceProcessEvents
| where InitiatingProcessFolderPath has "PerfLogs"
| where InitiatingProcessFileName matches regex "[a-z]{3}.exe"
| extend Length = strlen(InitiatingProcessFileName)
| where Length == 7

Suspicious registry modification of MaxMpxCt parameters

Use this query to look for suspicious running processes that modify registry settings to increase the number of outstanding requests allowed (for example, SMB requests when distributing ransomware via its PsExec methodology).

DeviceProcessEvents
| where ProcessCommandLine has_all("LanmanServer", "parameters", "MaxMpxCt", "65535")

Suspicious command line indicative of BlackCat ransom payload execution

Use these queries to look for instances of the BlackCat payload executing based on a required command argument for it to successfully encrypt ‘–access-token’.

DeviceProcessEvents
| where ProcessCommandLine has_all("--access-token", "-v") 
| extend CommandArguments = split(ProcessCommandLine, " ")
| mv-expand CommandArguments
| where CommandArguments matches regex "^[A-Fa-f0-9]{64}$"

DeviceProcessEvents
| where InitiatingProcessCommandLine has "--access-token"
| where ProcessCommandLine has "get uuid"

Suspected data exfiltration

Use this query to look for command lines that indicate data exfiltration and the indication that an attacker may attempt double extortion.

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all("copy", "--max-age", "--ignore-existing", "--multi-thread-streams", "--transfers") and InitiatingProcessCommandLine has_any("ftp", "ssh", "-q")

The post The many lives of BlackCat ransomware appeared first on Microsoft Security Blog.

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:

• Initial access
• XorDdos payload analysis
  • Detection evasion capabilities
  • Persistence mechanisms
  • Argument-based code-flow
  • Malicious activity threads
  • DDoS attack thread pool
• Defending against Linux platform threats
• Detection details
• Hunting queries
• Indicators

Initial access

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:

1. Iterates the following folders to find a writable directory:
   • /bin
   • /home
   • /root
   • /tmp
   • /usr
   • /etc
2. If a writable directory is found, changes the working directory to the discovered writable directory.
3. Uses the curl command to download the ELF file payload from the remote location hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as  ygljglkjgfg0.
4. Changes the file mode to “executable”.
5. Runs the ELF file payload.
6. Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary. In this case, it renames the Wget binary to good and moves the file to the following locations:
   • mv /usr/bin/wget /usr/bin/good
   • mv /bin/wget /bin/good
7. Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.
8. After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:

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:

1. The bash script gets the target device’s kernel-related information using the following sequence of commands and sends it to the attacker’s server:
   • lsmod with tail to get the list of loaded Linux kernel modules
   • Modinfo extracts the vermagic number, a string containing information such as the kernel version number and CPU type used by the kernel module to load into kernel space. The vermagic number is gathered from the listed kernel modules.
2. The vermagic string is sent to the attacker’s server in encoded form.

3. If the rootkit binary specific to the kernel build exists on the server, it is downloaded along with the XorDdos ELF as a compressed .tar file.
4. The .tar file is further uncompressed in a new directory named after the string obtained by encoding the MD5 hash of the vermagic string and created under the location /tmp on the target device. After the .tar file is uncompressed, the XorDdos ELF malware installs the XorDdos 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:

1. The bash script prepares archived Linux kernel headers in the /tmp directory.  Linux kernel headers are defining C-language public kernel APIs and data structures to enable compilation of 3rd party kernel modules.
2. The bash script downloads and launches the ELF binary uploader in /tmp. This binary uses an HTTP POST request to upload the archived kernel headers to the attacker’s server.
3. The ELF binary removes the uploader component from /tmp to minimize XorDdos’ footprint.
4. The uploaded archived kernel headers are used on the C2 server to build and compile the rootkit component. Thus, the newly built rootkit component becomes available for download from the C2 server, also making it available for other future infections.
5. The bash script then initiates the prior set of steps to download and install the XorDdos ELF malware, which installs the rootkit into the target device.

XorDdos payload analysis

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:

• crtstuff.c
• autorun.c
• crc32.c
• encrypt.c
• execpacket.c
• buildnet.c
• hide.c
• http.c
• kill.c
• main.c
• proc.c
• socket.c
• tcp.c
• thread.c
• findip.c
• dns.c

The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.

Detection evasion capabilities

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:

1. The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which internally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the calling process.
2. After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is to ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be successful. It then calls setsid() to detach itself from the controlling terminal.
3. The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter __nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root partition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is stopped.  
4. It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to /dev/null. It does this by calling dup2 on the file descriptor for /dev/null.
5. The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the current process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected. Performing this evasive signal suppression helps stop the effects of standard libraries trying to write to standard output or standard error, or trying to read from standard input, which could stop the malware’s child process. The API signal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the signal corresponding to signum.

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.

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:

• Provide root access
• Hide the kernel module
• Hide the malware’s processes
• Hide the malware’s network connections and ports

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:

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:

• /proc/7728 – Contains process-id (PID) 7728-related information
• /proc/698 – Contains PID 698-related information

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.

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:

Persistence mechanisms

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.

Argument-based code-flow

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:

• Opens the file for writing only
• Calls lseek (fd, 0, SEEK_END) to point at the last position in the file
• Creates a random 10-character string
• Writes the string at the end of the file with an additional null byte

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:

• /usr/bin/jwvwvxoupv 4849

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:

• Fetches the process file name corresponding to the provided $pid
• Deletes the file for the provided $pid
• Deletes the installed init services:
  • Deletes /etc/init.d/<file_name>
  • For runlevels 1-5, unlinks and deletes /etc/rc<runlevel>.d/S90<file_name>
  • Performs the command chkconfig –del <file_name>
  • Performs the command update-rc.d <file_name> remove
• Ends the process that was provided as an argument.

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:

• /usr/bin/jwvwvxoupv “cat resolv.conf” 4849
• /usr/bin/jwvwvxoupv gnome-terminal 4849
• /usr/bin/jwvwvxoupv top 4849
• /usr/bin/jwvwvxoupv pwd 4849
• /usr/bin/kagbjahdic id 4849

The fake commands can include:

• cat resolv.conf
• netstat -an
• bash
• whoami
• id
• cd /etc
• ifconfig eth0
• ifconfig
• echo “find”
• uptime
• sh
• top
• gnome-terminal
• su
• netstat -antop
• grep “A”
• who
• ls -la
• pwd
• route -n
• ps -ef
• ls
• sleep 1

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:

• Fetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on /proc/$pid/exe.
• If the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:
  • Intends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that allows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a successful readlink API call.
  • Creates directories similar to the standard code path scenario.
  • Calls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy the content of the current process’s image-file fetched earlier to the following locations with a random name:
    • /usr/bin/
    • /bin/
    • /tmp/   
  • Copies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on /lib/libudev.so.
  • Changes the hash of the written or copied file and then runs it without passing any parameters.
• If the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the remaining time out of five seconds.
• Unhides the current process and the $pid that was provided as part of the third argument.
• Deletes the on-disk file for the current process.

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:

• /usr/bin/
• /bin/
• /tmp/

Once it runs from one of these locations, the malware calls the following functions to perform various tasks:

1. InstallSYS – this function sets up the rootkit by extracting it under /usr/bin folder using a random name and loading it into the kernel.  

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.

2. AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system starts.
3. HidePidPort – Hides the malware’s ports and processes.
4. CheckLKM – Checks whether the rootkit device is active or not, and to see if the rootkit meets the installation requirements, such as an exact kernel header match and no secure boot or other technologies that can block the rootkit’s installation. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the rootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to change the ownership of dropped files with the function lchown(<filename>, 0xAD1473B8, 0xAD1473B8).
5. decrypt_remotestr – Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar and the other directories. After decoding the URLs, it adds them into a remote list, which is later used to communicate and fetch commands from the command and control (C2) server:
   • www[.]enoan2107[.]com:3306
   • www[.]gzcfr5axf6[.]com:3306

Malicious activity threads

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:

• Decodes encrypted strings
• Fetches file stats for /var/run/gcc.pid or, if none exist, then creates the file
• Fetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the location /lib/libudev.so
• Fetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the current process
• Reads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files, based on the matching specified keys in the configuration file, such as:
  • md5=
  • filename=
  • rmfile=
  • denyip=

tcp_thread

The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:

• Reads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while connecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte string.
• Calculates the CRC header, including details of the device such as the magic string, OS release version, malware version, rootkit presence, memory stats, CPU information, and LAN speed.
• Encrypts the data and sends it to the C2 server.
• Waits to receive any of the following commands from the C2 server and then acts on the command using the exec_packet subroutine.

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.

DDoS attack thread pool

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.

Defending against Linux platform threats

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:

• Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
• Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants. 
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet. 
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume. 

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.

Detection details

Microsoft Defender for Endpoint detects and blocks XorDdos’s installer script and rootkit binary as the following malware:

• DoS:Linux/Xorddos.A
• DoS:Linux/Xorddos!rfn
• Trojan:Linux/Xorddos
• Trojan:Linux/Xorddos.AA
• Trojan:Linux/Xorddos!rfn
• Behavior:Linux/Xorddos.A
• Backdoor:Linux/XorDDoSRootkit.A
• Trojan:SH/XorDDoSinstaller.A

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:

• The content of libudev.so was collected into libudev.so.6
• bash process performed System Information Discovery by invoking ifconfig
• gcc.sh was executed after being dropped by HFLgGwYfSC.elf
• A shell command was executed by crond
• SUID/SGID process unix_chkpwd executed

Hunting queries

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"

Indicators

File information

Dropped files

Download URLs

• www[.]enoan2107[.]com:3306
• www[.]gzcfr5axf6[.]com:3306
• hxxp://aa[.]hostasa[.]org/config.rar

Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or
with Saurabh Swaroop
Microsoft 365 Defender Research Team

The post Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices appeared first on Microsoft Security Blog.

We discovered the vulnerabilities by listening to messages on the System Bus while performing code reviews and dynamic analysis on services that run as root, noticing an odd pattern in a systemd unit called networkd-dispatcher. Reviewing the code flow for networkd-dispatcher revealed multiple security concerns, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues, which could be leveraged to elevate privileges and deploy malware or carry out other malicious activities. We shared these vulnerabilities with the relevant maintainers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for these vulnerabilities, now identified as CVE-2022-29799 and CVE-2022-29800, have been successfully deployed by the maintainer of the networkd-dispatcher, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of networkd-dispatcher are encouraged to update their instances.

As organizational environments continue to rely on a diverse range of devices and systems, they require comprehensive solutions that provide cross-platform protection and a holistic view of their security posture to mitigate threats, such as Nimbuspwn. The growing number of vulnerabilities on Linux environments emphasize the need for strong monitoring of the platform’s operating system and its components. Microsoft Defender for Endpoint enables organizations to gain this necessary visibility and detect such threats on Linux devices, allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.

In this blog post, we will share some information about the affected components and examine the vulnerabilities we uncovered. Detailing how our cross-domain visibility helps us uncover new and unknown threats to continually improve security, we are also sharing details from our research with the larger security community to underscore the importance of securing platforms and devices.

Background – D-Bus

D-Bus (short for “Desktop-Bus”) is an inter-process communication channel (IPC) mechanism developed by the freedesktop.org project. D-Bus is a software-bus and allows processes on the same endpoint to communicate by transmitting messages and responding to them. D-Bus supports two main ways of communicating:

1. Methods – used for request-response communications.
2. Signals – used for publish/subscribe communications.

An example of D-Bus usage would be receiving a video chat by a popular video conferencing app–once a video is established, the video conferencing app could send a D-bus signal publishing that a call has started. Apps listening to that message could respond appropriately–for example, mute their audio.

There are many D-Bus components shipped by default on popular Linux desktop environments. Since those components run at different privileges and respond to messages, D-Bus components are an attractive target for attackers. Indeed, there have been interesting vulnerabilities in the past related to buggy D-Bus services, including USBCreator Elevation of Privilege, Blueman Elevation of Privilege by command injection, and other similar scenarios.

D-Bus exposes a global System Bus and a per-session Session Bus. From an attacker’s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.

D-Bus name ownership

When connecting to the D-Bus, components are assigned with a unique identifier, which mitigates against attacks abusing PID-recycling. The unique identifier starts with a colon and has numbers in it separated by dots, such as “:1.337”. Components can use the D-Bus API to own identifiable names such as “org.freedesktop.Avahi” or “com.ubuntu.SystemService”. For D-Bus to allow such ownership, the requesting process context must be allowed under the D-Bus configuration files. Those configuration files are well documented and maintained under /usr/local/share/dbus-1/system.conf and /usr/local/share/dbus-1/session.conf (on some systems under /usr/local/dbus-1 directly). Specifically, the default system.conf does not allow ownership unless specified otherwise in other included configuration files (commonly under /etc/dbus-1/system.d).

Additionally, if the name requested already exists–the request will not be granted until the owning process releases the name.

Vulnerability hunting

Our team has started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis. We have reported two information leak issues as a result:

1. Directory Info Disclosure in Blueman
2. Directory Info Disclosure in PackageKit (CVE-2022-0987)

While these are interesting, their severity is low – an attacker can list files under directories that require high permissions to list files under. Then we started noticing interesting patterns in a systemd unit called networkd-dispatcher. The goal of networkd-dispatcher is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:

Code flow for networkd-dispatcher

Upon examination of the networkd-dispatcher source code, we noticed an interesting flow:

1. The register function registers a new signal receiver for the service “org.freedesktop.network1” on the System Bus, for the signal name ”PropertiesChanged”.
2. The ”_receive_signal“ signal handler will perform some basic checks on the object type being sent, concludes the changed network interface based on the object path being sent, and then concludes its new states–“OperationalState” and “AdministrativeState”–each fetched from the data. For any of those states–if they aren’t empty–the “handle_state” method will get invoked.
3. The “handle_state” method simply invokes “_handle_one_state“ for each of those two states.
4. “_handle_one_state” validates the state isn’t empty and checks if it’s different than the previous state. If it is, it will update the new state and invoke the “_run_hooks_for_state” method, which is responsible of discovering and running the scripts for the new state.
5. “_run_hooks_for_state” implements the following logic:
   • Discovers the script list by invoking the “get_script_list” method (which gets the new state as a string). This method simply calls “scripts_in_path” which is intended to return all the files under “/etc/networkd-dispatcher/<state>.d” that are owned by the root user and the root group, and are executable.
   • Sorts the script list.
   • Runs each script with subprocess.Popen while supplying custom environment variables.

Step 5 has multiple security issues:

1. Directory traversal (CVE-2022-29799): none of the functions in the flow sanitize the OperationalState or the AdministrativeState. Since the states are used to build the script path, it is possible that a state would contain directory traversal patterns (e.g. “../../”) to escape from the “/etc/networkd-dispatcher” base directory.
2. Symlink race: both the script discovery and subprocess.Popen follow symbolic links.
3. Time-of-check-time-of-use (TOCTOU) race condition (CVE-2022-29800): there is a certain time between the scripts being discovered and them being run. An attacker can abuse this vulnerability to replace scripts that networkd-dispatcher believes to be owned by root to ones that are not.

Exploitation

Let us assume an adversary has a malicious D-Bus component that can send an arbitrary signal. An attacker can therefore do the following:

1. Prepare a directory ”/tmp/nimbuspwn” and plant a symlink ”/tmp/nimbuspwn/poc.d“ to point to “/sbin”. The “/sbin” directory was chosen specifically because it has many executables owned by root that do not block if run without additional arguments. This will abuse the symlink race issue we mentioned earlier.
2. For every executable filename under “/sbin” owned by root, plant the same filename under “/tmp/nimbuspwn”. For example, if “/sbin/vgs” is executable and owned by root, plant an executable file “/tmp/nimbuspwn/vgs” with the desired payload. This will help the attacker win the race condition imposed by the TOCTOU vulnerability.
3. Send a signal with the OperationalState “../../../tmp/nimbuspwn/poc”. This abuses the directory traversal vulnerability and escapes the script directory.
4. The networkd-dispatcher signal handler kicks in and builds the script list from the directory “/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d”, which is really the symlink (“/tmp/nimbuspwn/poc.d”), which points to “/sbin”. Therefore, it creates a list composed of many executables owned by root.
5. Quickly change the symlink “/tmp/nimbuspwn/poc.d” to point to “/tmp/nimbuspwn”. This abuses the TOCTOU race condition vulnerability–the script path changes without networkd-dispatcher being aware.
6. The dispatcher starts running files that were initially under “/sbin” but in truth under the “/tmp/nimbuspwn” directory. Since the dispatcher “believes” those files are owned by root, it executes them blindly with subprocess.Popen as root. Therefore, our attacker has successfully exploited the vulnerability.

Note that to win the TOCTOU race condition with high probability, we plant many files that can potentially run. Our experiments show three attempts were enough to win the TOCTOU race condition.

Since we do not wish to run the exploit every time we want to run as root, the payload that we ended up implementing leaves a root backdoor as such:

1. Copies /bin/sh to /tmp/sh.
2. Turns the new /tmp/sh it into a Set-UID (SUID) binary.
3. Run /tmp/sh -p. The “-p” flag is necessary since modern shells drop privileges by design.

Owning the bus name

The astute reader will notice that the entire exploit elevates privileges assuming our exploit code can own the “org.freedesktop.network1” bus name. While this sounds non-trivial, we have found several environments where this happens. Specifically:

1. On many environments (e.g. Linux Mint) the service systemd-networkd that normally owns the “org.freedesktop.network1” bus name does not start at boot by default.
2. Using advanced hunting in Microsoft Defender for Endpoint we were able to spot several processes running as the systemd-network user (which is permitted to own the bus name we require) running arbitrary code from world-writable locations. These include several scenarios on specific environments that allow running arbitrary code as systemd-network, such as running a script from a world-writable directory. We attribute some of those scenarios to customer misconfigurations.

The query we used can also be run by Microsoft Defender for Endpoint customers:

DeviceProcessEvents
| where Timestamp > ago(5d)
    and AccountName == "systemd-network"
    and isnotempty(InitiatingProcessAccountName)
    and isnotempty(FileName)
| project DeviceId, FileName, FolderPath, ProcessCommandLine

We were therefore able to exploit these scenarios and implement our own exploit:

While capable of running any arbitrary script as root, our exploit copies /bin/sh to the /tmp directory, sets /tmp/sh as a Set-UID (SUID) executable, and then invokes “/tmp/sh -p”. Note that the “-p” flag is necessary to force the shell to not drop privileges.

Hardening device security and detection strategy

Despite the evolving threat landscape regularly delivering new threats, techniques, and attack capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems, networks, and sensitive information for malicious purposes. This constant bombardment of attacks spanning a wide range of platforms, devices, and other domains emphasizes the need for a comprehensive and proactive vulnerability management approach that can further identify and mitigate even previously unknown exploits and issues.

Microsoft’s threat and vulnerability management capabilities help organizations monitor their overall security posture, providing real-time insights into risk with continuous vulnerability discovery, contextualized intelligent prioritization, and seamless one-click flaw remediation. Leveraging our research into the Nimbuspwn vulnerabilities to improve solutions, our threat and vulnerability management already covers CVE-2022-29799 and CVE-2022-29800 and indicates such vulnerable devices in the threat and vulnerability module in Microsoft Defender for Endpoint.

To address the specific vulnerabilities at play, Microsoft Defender for Endpoint’s endpoint detection and response (EDR) capabilities detect the directory traversal attack required to leverage Nimbuspwn. Additionally, the Microsoft Defender for Endpoint detection team has a generic detection for suspicious Set-UID process invocations, which detected our exploit without prior knowledge.

Defending against the evolving threat landscape requires the ability to protect and secure users’ computing experiences, be it a Windows or non-Windows device. Microsoft continuously enriches our protection technologies through robust research that protects users and organizations across all the major platforms every single day. This case displayed how the ability to coordinate such research via expert, cross-industry collaboration is vital to effectively mitigate issues, regardless of the vulnerable device or platform in use. By sharing our research and other forms of threat intelligence, we can continue to collaborate with the larger security community and strive to build better protection for all.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn appeared first on Microsoft Security Blog.

January 10, 2022 recap – The Log4j vulnerabilities represent a complex and high-risk situation for companies across the globe. This open-source component is widely used across many suppliers’ software and services. By nature of Log4j being a component, the vulnerabilities affect not only applications that use vulnerable libraries, but also any services that use these applications, so customers may not readily know how widespread the issue is in their environment. Customers are encouraged to utilize scripts and scanning tools to assess their risk and impact. Microsoft has observed attackers using many of the same inventory techniques to locate targets. Sophisticated adversaries (like nation-state actors) and commodity attackers alike have been observed taking advantage of these vulnerabilities. There is high potential for the expanded use of the vulnerabilities.

In January, we started seeing attackers taking advantage of the vulnerabilities in internet-facing systems, eventually deploying ransomware. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks. Organizations may not realize their environments may already be compromised. Microsoft recommends customers to do additional review of devices where vulnerable installations are discovered.  At this juncture, customers should assume broad availability of exploit code and scanning capabilities to be a real and present danger to their environments. Due to the many software and services that are impacted and given the pace of updates, this is expected to have a long tail for remediation, requiring ongoing, sustainable vigilance.

January 19, 2022 update – We added new information about an unrelated vulnerability we discovered while investigating Log4j attacks.

January 21, 2022 update – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

The remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell” (CVE-2021-44228, CVE-2021-45046, CVE-2021-44832) has presented a new attack vector and gained broad attention due to its severity and potential for widespread exploitation. The majority of attacks we have observed so far have been mainly mass-scanning, coin mining, establishing remote shells, and red-team activity, but it’s highly likely that attackers will continue adding exploits for these vulnerabilities to their toolkits.

With nation-state actors testing and implementing the exploit and known ransomware-associated access brokers using it, we highly recommend applying security patches and updating affected products and services as soon as possible. Refer to the Microsoft Security Response Center blog for technical information about the vulnerabilities and mitigation recommendations.

Meanwhile, defenders need to be diligent in detecting, hunting for, and investigating related threats. This blog reports our observations and analysis of attacks that take advantage of the Log4j 2 vulnerabilities. It also provides our recommendations for using Microsoft security solutions to (1) find and remediate vulnerable services and systems and (2) detect, investigate, and respond to attacks.

This blog covers the following topics:

1. Attack vectors and observed activity
2. Finding and remediating vulnerable apps and systems
   • Threat and vulnerability management
     • Discovering affected components, software, and devices via a unified Log4j dashboard
     • Applying mitigation directly in the Microsoft 365 Defender portal
   • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
     • Microsoft Defender for servers
     • Microsoft Defender for Containers
   • Microsoft Sentinel queries
   • RiskIQ EASM and Threat Intelligence
3. Detecting and responding to exploitation attempts and other related attacker activity
   • Microsoft 365 Defender
     • Microsoft Defender Antivirus
     • Microsoft Defender for Endpoint
     • Microsoft Defender for Cloud Apps
     • Microsoft Defender for Office 365
     • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
   • Microsoft Defender for IoT
   • Microsoft Sentinel
     • Microsoft Sentinel queries
   • Azure Firewall Premium
   • Azure Web Application Firewall (WAF)
4. Indicators of compromise (IoCs)

Attack vectors and observed activity

Microsoft’s unified threat intelligence team, comprising the Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), among others, have been tracking threats taking advantage of the remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell”.

The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers. An example pattern of attack would appear in a web request log with strings like the following:

An attacker performs an HTTP request against a target system, which generates a log using Log4j 2 that leverages JNDI to perform a request to the attacker-controlled site. The vulnerability then causes the exploited process to reach out to the site and execute the payload.  In many observed attacks, the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems.

The specially crafted string that enables exploitation of the vulnerabilities can be identified through several components. The string contains “jndi”, which refers to the Java Naming and Directory Interface. Following this, the protocol, such as “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, or “http”, precedes the attacker domain.

As security teams work to detect the exploitation, attackers have added obfuscation to these requests to evade detections based on request patterns. We’ve seen things like running a lower or upper command within the exploitation string and even more complicated obfuscation attempts, such as the following, that are all trying to bypass string-matching detections:

The vast majority of observed activity has been scanning, but exploitation and post-exploitation activities have also been observed. Based on the nature of the vulnerabilities, once the attacker has full access and control of an application, they can perform a myriad of objectives. Microsoft has observed activities including installing coin miners, using Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems.

Exploitation continues on non-Microsoft hosted Minecraft servers

Minecraft customers running their own servers are encouraged to deploy the latest Minecraft server update as soon as possible to protect their users. More information can be found here: https://aka.ms/mclog.

Microsoft can confirm public reports of the Khonsari ransomware family being delivered as payload post-exploitation, as discussed by Bitdefender. In Microsoft Defender Antivirus data we have observed a small number of cases of this being launched from compromised Minecraft clients connected to modified Minecraft servers running a vulnerable version of Log4j 2 via the use of a third-party Minecraft mods loader.

In these cases, an adversary sends a malicious in-game message to a vulnerable Minecraft server, which exploits CVE-2021-44228 to retrieve and execute an attacker-hosted payload on both the server and on connected vulnerable clients. We observed exploitation leading to a malicious Java class file that is the Khonsari ransomware, which is then executed in the context of javaw.exe to ransom the device.

While it’s uncommon for Minecraft to be installed in enterprise networks, we have also observed PowerShell-based reverse shells being dropped to Minecraft client systems via the same malicious message technique, giving an actor full access to a compromised system, which they then use to run Mimikatz to steal credentials. These techniques are typically associated with enterprise compromises with the intent of lateral movement. Microsoft has not observed any follow-on activity from this campaign at this time, indicating that the attacker may be gathering access for later use.

Due to the shifts in the threat landscape, Microsoft reiterates the guidance for Minecraft customers running their own servers to deploy the latest Minecraft server update and for players to exercise caution by only connecting to trusted Minecraft servers.

Nation-state activity

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

MSTIC has also observed the CVE-2021-44228 vulnerability being used by multiple tracked nation-state activity groups originating from China, Iran, North Korea, and Turkey. This activity ranges from experimentation during development, integration of the vulnerabilities to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.

For example, MSTIC has observed PHOSPHORUS, an Iranian actor known to deploy ransomware, acquiring and making modifications of the Log4j exploit. We assess that PHOSPHORUS has operationalized these modifications.

In addition, HAFNIUM, a threat actor group operating out of China, has been observed utilizing the vulnerability to attack virtualization infrastructure to extend their typical targeting. In these attacks, HAFNIUM-associated systems were observed using a DNS service typically associated with testing activity to fingerprint systems.

Access brokers associated with ransomware

MSTIC and the Microsoft 365 Defender team have confirmed that multiple tracked activity groups acting as access brokers have begun using the vulnerability to gain initial access to target networks. These access brokers then sell access to these networks to ransomware-as-a-service affiliates. We have observed these groups attempting exploitation on both Linux and Windows systems, which may lead to an increase in human-operated ransomware impact on both of these operating system platforms.

Mass scanning activity continues

The vast majority of traffic observed by Microsoft remains mass scanners by both attackers and security researchers. Microsoft has observed rapid uptake of the vulnerability into existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor to Linux systems. Many of these campaigns are running concurrent scanning and exploitation activities for both Windows and Linux systems, using Base64 commands included in the JDNI:ldap:// request to launch bash commands on Linux and PowerShell on Windows.

Microsoft has also continued to observe malicious activity performing data leakage via the vulnerability without dropping a payload. This attack scenario could be especially impactful against network devices that have SSL termination, where the actor could leak secrets and data.

Additional RAT payloads

We’ve observed the dropping of additional remote access toolkits and reverse shells via exploitation of CVE-2021-44228, which actors then use for hands-on-keyboard attacks. In addition to the Cobalt Strike and PowerShell reverse shells seen in earlier reports, we’ve also seen Meterpreter, Bladabindi, and HabitsRAT. Follow-on activities from these shells have not been observed at this time, but these tools have the ability to steal passwords and move laterally.

This activity is split between a percentage of small-scale campaigns that may be more targeted or related to testing, and the addition of CVE-2021-44428 to existing campaigns that were exploiting vulnerabilities to drop remote access tools. In the HabitsRAT case, the campaign was seen overlapping with infrastructure used in prior campaigns.

Webtoos

The Webtoos malware has DDoS capabilities and persistence mechanisms that could allow an attacker to perform additional activities. As reported by RiskIQ, Microsoft has seen Webtoos being deployed via the vulnerability. Attackers’ use of this malware or intent is not known at this time, but the campaign and infrastructure have been in use and have been targeting both Linux and Windows systems prior to this vulnerability.

A note on testing services and assumed benign activity

While services such as interact.sh, canarytokens.org, burpsuite, and dnslog.cn may be used by IT organizations to profile their own threat footprints, Microsoft encourages including these services in your hunting queries and validating observations of these in environments to ensure they are intentional and legitimate activity.

Exploitation in internet-facing systems leads to ransomware

As early as January 4, attackers started exploiting the CVE-2021-44228 vulnerability in internet-facing systems running VMware Horizon. Our investigation shows that successful intrusions in these campaigns led to the deployment of the NightSky ransomware.

These attacks are performed by a China-based ransomware operator that we’re tracking as DEV-0401. DEV-0401 has previously deployed multiple ransomware families including LockFile, AtomSilo, and Rook, and has similarly exploited Internet-facing systems running Confluence (CVE-2021-26084) and on-premises Exchange servers (CVE-2021-34473).

Based on our analysis, the attackers are using command and control (CnC) servers that spoof legitimate domains. These include service[.]trendmrcio[.]com, api[.]rogerscorp[.]org, api[.]sophosantivirus[.]ga, apicon[.]nvidialab[.]us, w2zmii7kjb81pfj0ped16kg8szyvmk.burpcollaborator[.]net, and 139[.]180[.]217[.]203.

Attackers propagating Log4j attacks via previously undisclosed vulnerability

During our sustained monitoring of threats taking advantage of the Log4j 2 vulnerabilities, we observed activity related to attacks being propagated via a previously undisclosed vulnerability in the SolarWinds Serv-U software. We discovered that the vulnerability, now tracked as CVE-2021-35247, is an input validation vulnerability that could allow attackers to build a query given some input and send that query over the network without sanitation.

We reported our discovery to SolarWinds, and we’d like to thank their teams for immediately investigating and working to remediate the vulnerability. We strongly recommend affected customers to apply security updates released by referring to the SolarWinds advisory here: https://www.solarwinds.com/trust-center/security-advisories/cve-2021-35247.

Microsoft customers can use threat and vulnerability management in Microsoft Defender for Endpoint to identify and remediate devices that have this vulnerability. In addition, Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect malicious behavior related to the observed activity.

Finding and remediating vulnerable apps and systems

Threat and vulnerability management

Threat and vulnerability management capabilities in Microsoft Defender for Endpoint monitor an organization’s overall security posture and equip customers with real-time insights into organizational risk through continuous vulnerability discovery, intelligent prioritization, and the ability to seamlessly remediate vulnerabilities.

Discovering affected components, software, and devices via a unified Log4j dashboard

Threat and vulnerability management automatically and seamlessly identifies devices affected by the Log4j vulnerabilities and the associated risk in the environment and significantly reduces time-to-mitigate. Microsoft continues to iterate on these features based on the latest information from the threat landscape. This section will be updated as those new features become available for customers.

The wide use of Log4j across many supplier’s products challenge defender teams to mitigate and address the risks posed by the vulnerabilities (CVE-2021-44228 or CVE-2021-45046).  The threat and vulnerability management capabilities within Microsoft 365 Defender can help identify vulnerable installations. On December 15, we began rolling out updates to provide a consolidated view of the organizational exposure to the Log4j 2 vulnerabilities—on the device, software, and vulnerable component level—through a range of automated, complementing capabilities. These capabilities are supported on Windows 10, Windows 11, and Windows Server 2008, 2012, and 2016. They are also supported on Linux, but they require updating the Microsoft Defender for Endpoint Linux client to version 101.52.57 (30.121092.15257.0) or later. The updates include the following:

• Discovery of vulnerable Log4j library components (paths) on devices
• Discovery of vulnerable installed applications that contain the Log4j library on devices
• A dedicated Log4j dashboard that provides a consolidated view of various findings across vulnerable devices, vulnerable software, and vulnerable files
• Introduction of a new schema in advanced hunting, DeviceTvmSoftwareEvidenceBeta, which surfaces file-level findings from the disk and provides the ability to correlate them with additional context in advanced hunting:

DeviceTvmSoftwareEvidenceBeta
| mv-expand DiskPaths
| where DiskPaths contains "log4j"
| project DeviceId, SoftwareName, SoftwareVendor, SoftwareVersion, DiskPaths

To complement this new table, the existing DeviceTvmSoftwareVulnerabilities table in advanced hunting can be used to identify vulnerabilities in installed software on devices:

DeviceTvmSoftwareVulnerabilities 
| where CveId in ("CVE-2021-44228", "CVE-2021-45046")

These capabilities integrate with the existing threat and vulnerability management experience and are gradually rolling out. As of December 27, 2021, discovery is based on installed application CPEs that are known to be vulnerable to Log4j RCE, as well as the presence of vulnerable Log4j Java Archive (JAR) files.

As of January 20, 2022, threat and vulnerability management can discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files. This capability is supported on Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022. It is also supported on Windows Server 2012 R2 and Windows Server 2016 using the Microsoft Defender for Endpoint solution for earlier Windows server versions.

Threat and vulnerability management provides layers of detection to help customers discover and mitigate vulnerable Log4j components. Specifically, it:

1. determines if a JAR file contains a vulnerable Log4j file by examining JAR files and searching for the following file: \META-INF\maven\org.apache.logging.log4j\log4j-core\pom.properties; if the said file exists, the Log4j version is read and extracted 
2. searches for the JndiLookup.class file inside the JAR file by looking for paths that contain the string “/log4j/core/lookup/JndiLookup.class”; if the JndiLookup.class file exists, threat and vulnerability management determines if this JAR contains a Log4j file with the version defined in pom.properties 
3. searches for any vulnerable Log4j-core JAR files embedded within nested-JAR by searching for paths that contain any of these strings:
   • lib/log4j-core- 
   • WEB-INF/lib/log4j-core- 
   • App-INF/lib/log4j-core- 

Figure 1. Threat and Vulnerability recommendation “Attention required: Devices found with vulnerable Apache Log4j versions”

In the Microsoft 365 Defender portal, go to Vulnerability management > Dashboard > Threat awareness, then click View vulnerability details to see the consolidated view of organizational exposure to the Log4j 2 vulnerability (for example, CVE-2021-44228 dashboard, as shown in the following screenshots) on the device, software, and vulnerable component level.

Figure 2. Threat and vulnerability management dedicated CVE-2021-44228 dashboard

Figure 3. Threat and vulnerability management finds exposed paths

Figure 4. Threat and vulnerability management finds exposed devices based on vulnerable software and vulnerable files detected on disk

Note: Scan results may take some time to reach full coverage, and the number of discovered devices may be low at first but will grow as the scan reaches more devices. A regularly updated list of vulnerable products can be viewed in the Microsoft 365 Defender portal with matching recommendations. We will continue to review and update this list as new information becomes available.

Through device discovery, unmanaged devices with products and services affected by the vulnerabilities are also surfaced so they can be onboarded and secured.

Figure 5. Finding vulnerable applications and devices via software inventory

Applying mitigation directly in the Microsoft 365 Defender portal

We have released two new threat and vulnerability management capabilities that can significantly simplify the process of turning off JNDI lookup, a workaround that can prevent the exploitation of the Log4j vulnerabilities on most devices, using an environment variable called LOG4J_FORMAT_MSG_NO_LOOKUPS. These new capabilities provide security teams with the following:

1. View the mitigation status for each affected device. This can help prioritize mitigation and/or patching of devices based on their mitigation status.

To use this feature, open the Exposed devices tab in the dedicated CVE-2021-44228 dashboard and review the Mitigation status column. Note that it may take a few hours for the updated mitigation status of a device to be reflected.

Figure 6. Viewing each device’s mitigation status

2. Apply the mitigation (that is, turn off JNDI lookup) on devices directly from the portal. This feature is currently available for Windows devices only.

The mitigation will be applied directly via the Microsoft Defender for Endpoint client. To view the mitigation options, click on the Mitigation options button in the Log4j dashboard:

You can choose to apply the mitigation to all exposed devices or select specific devices for which you would like to apply it. To complete the process and apply the mitigation on devices, click Create mitigation action.

Figure 7. Creating mitigation actions for exposed devices.

In cases where the mitigation needs to be reverted, follow these steps:

1. Open an elevated PowerShell window
2. Run the following command:

[Environment]::SetEnvironmentVariable("LOG4J_FORMAT_MSG_NO_LOOKUPS", $null, [EnvironmentVariableTarget]::Machine)

The change will take effect after the device restarts.

Microsoft 365 Defender advanced hunting

Advance hunting can also surface affected software. This query looks for possibly vulnerable applications using the affected Log4j component. Triage the results to determine applications and programs that may need to be patched and updated.

DeviceTvmSoftwareInventory
| where SoftwareName contains "log4j"
| project DeviceName, SoftwareName, SoftwareVersion

Figure 8. Finding vulnerable software via advanced hunting

Microsoft Defender for Cloud

Microsoft Defender for servers

Organizations using Microsoft Defender for Cloud can use Inventory tools to begin investigations before there’s a CVE number. With Inventory tools, there are two ways to determine exposure across hybrid and multi-cloud resources:

• Vulnerability assessment findings – Organizations who have enabled any of the vulnerability assessment tools (whether it’s Microsoft Defender for Endpoint’s threat and vulnerability management module, the built-in Qualys scanner, or a bring your own license solution), they can search by CVE identifier:

Figure 9. Searching vulnerability assessment findings by CVE identifier

• Software inventory – With the combined integration with Microsoft Defender for Endpoint and Microsoft Defender for servers, organizations can search for resources by installed applications and discover resources running the vulnerable software:

Figure 10. Searching software inventory by installed applications

Note that this doesn’t replace a search of your codebase. It’s possible that software with integrated Log4j libraries won’t appear in this list, but this is helpful in the initial triage of investigations related to this incident. For more information about how Microsoft Defender for Cloud finds machines affected by CVE-2021-44228, read this tech community post.

Microsoft Defender for Containers

Microsoft Defender for Containers is capable of discovering images affected by the vulnerabilities recently discovered in Log4j 2: CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105. Images are automatically scanned for vulnerabilities in three different use cases: when pushed to an Azure container registry, when pulled from an Azure container registry, and when container images are running on a Kubernetes cluster. Additional information on supported scan triggers and Kubernetes clusters can be found here. 

Log4j binaries are discovered whether they are deployed via a package manager, copied to the image as stand-alone binaries, or included within a JAR Archive (up to one level of nesting). 

We will continue to follow up on any additional developments and will update our detection capabilities if any additional vulnerabilities are reported.

Finding affected images

To find vulnerable images across registries using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Container Registry images should have vulnerability findings resolved recommendation and search findings for the relevant CVEs. 

Figure 11. Finding images with the CVE-2021-45046 vulnerability 

Find vulnerable running images on Azure portal [preview] 

To view only vulnerable images that are currently running on a Kubernetes cluster using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Vulnerabilities in running container images should be remediated (powered by Qualys) recommendation and search findings for the relevant CVEs: 

Figure 12. Finding running images with the CVE-2021-45046 vulnerability

Note: This recommendation requires clusters to run Microsoft Defender security profile to provide visibility on running images.

Search Azure Resource Graph data 

Azure Resource Graph (ARG) provides instant access to resource information across cloud environments with robust filtering, grouping, and sorting capabilities. It’s a quick and efficient way to query information across Azure subscriptions programmatically or from within the Azure portal. ARG provides another way to query resource data for resources found to be affected by the Log4j vulnerability.

The following query finds resources affected by the Log4j vulnerability across subscriptions. Use the additional data field across all returned results to obtain details on vulnerable resources: 

securityresources 
| where type =~ "microsoft.security/assessments/subassessments"
| extend assessmentKey=extract(@"(?i)providers/Microsoft.Security/assessments/([^/]*)", 1, id), subAssessmentId=tostring(properties.id), parentResourceId= extract("(.+)/providers/Microsoft.Security", 1, id)
| extend Props = parse_json(properties)
| extend additionalData = Props.additionalData
| extend cves = additionalData.cve
| where isnotempty(cves) and array_length(cves) > 0
| mv-expand cves
| where tostring(cves) has "CVE-2021-44228" or tostring(cves) has "CVE-2021-45046" or tostring(cves) has "CVE-2021-45105" 

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection query to look for devices that have applications with the vulnerability:

• Vulnerable machines related to Log4j CVE-2021-44228

This query uses the Microsoft Defender for Cloud nested recommendations data to find machines vulnerable to Log4j CVE-2021-44228.

Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Linux/demos/CVE-2021-44228-Log4Shell

RiskIQ EASM and Threat Intelligence

RiskIQ has published a few threat intelligence articles on this CVE, with mitigation guidance and IOCs. The latest one with links to previous articles can be found here. Both Community users and enterprise customers can search within the threat intelligence portal for data about potentially vulnerable components exposed to the Internet. For example, it’s possible to surface all observed instances of Apache or Java, including specific versions. Leverage this method of exploration to aid in understanding the larger Internet exposure, while also filtering down to what may impact you. 

For a more automated method, registered users can view their attack surface to understand tailored findings associated with their organization. Note, you must be registered with a corporate email and the automated attack surface will be limited. Digital Footprint customers can immediately understand what may be vulnerable and act swiftly and resolutely using the Attack Surface Intelligence Dashboard Log4J Insights tab. 

Detecting and responding to exploitation attempts and other related attacker activity

Microsoft 365 Defender

Microsoft 365 Defender coordinates multiple security solutions that detect components of observed attacks taking advantage of this vulnerability, from exploitation attempts to remote code execution and post-exploitation activity.

Figure 13. Microsoft 365 Defender solutions protect against related threats

Customers can click Need help? in the Microsoft 365 Defender portal to open up a search widget. Customers can key in “Log4j” to search for in-portal resource, check if their network is affected, and work on corresponding actionable items to mitigate them.

Microsoft Defender Antivirus

Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants. Microsoft Defender Antivirus detects components and behaviors related to this threat as the following detection names:

On Windows:

• Trojan:Win32/Capfetox.AA– detects attempted exploitation on the attacker machine
• HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
• VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders
• TrojanDownloader:Win32/CoinMiner – detects post-exploitation coin miner
• Trojan:Win32/WebToos.A – detects post-exploitation PowerShell
• Ransom:MSIL/Khonsari.A – detects a strain of the Khonsari ransomware family observed being distributed post-exploitation
• Trojan:Win64/DisguisedXMRigMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Java/Agent.S – detects suspicious class files used in post-exploitation
• TrojanDownloader:PowerShell/NitSky.A – detects attempts to download CobaltStrike Beacon payload

On Linux:

• Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B, Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
• Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/CoinMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/Tusnami – detects post-exploitation Backdoor Tsunami downloader
• Backdoor:Linux/Tusnami.C – detects post-exploitation Tsunami backdoor
• Backdoor:Linux/Setag.C – detects post-exploitation Gates backdoor
• Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation
• TrojanDownloader:Linux/Capfetox.A, TrojanDownloader:Linux/Capfetox.B
• TrojanDownloader:Linux/ShAgnt!MSR, TrojanDownloader:Linux/ShAgnt.A!MTB
• Trojan:Linux/Kinsing.L – detects post-exploitation cryptocurrency Kinsing miner
• Trojan:Linux/Mirai.TS!MTB – detects post-exploitation Mirai malware capable of performing DDoS
• Backdoor:Linux/Dakkatoni.az!MTB – detects post-exploitation Dakkatoni backdoor trojan capable of downloading more payloads
• Trojan:Linux/JavaExploitRevShell.A – detects reverse shell attack post-exploitation
• Trojan:Linux/BashMiner.A, Trojan:Linux/BashMiner.B – detects post-exploitation cryptocurrency miner

Microsoft Defender for Endpoint

Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Due to the broad network exploitation nature of vectors through which this vulnerability can be exploited and the fact that applying mitigations holistically across large environments will take time, we encourage defenders to look for signs of post-exploitation rather than fully relying on prevention. Observed post exploitation activity such as coin mining, lateral movement, and Cobalt Strike are detected with behavior-based detections.

Alerts with the following titles in the Security Center indicate threat activity related to exploitation of the Log4j vulnerability on your network and should be immediately investigated and remediated. These alerts are supported on both Windows and Linux platforms: 

• Log4j exploitation detected – detects known behaviors that attackers perform following successful exploitation of the CVE-2021-44228 vulnerability
• Log4j exploitation artifacts detected (previously titled Possible exploitation of CVE-2021-44228) – detects coin miners, shells, backdoor, and payloads such as Cobalt Strike used by attackers post-exploitation
• Log4j exploitation network artifacts detected (previously titled Network connection seen in CVE-2021-44228 exploitation) – detects network traffic connecting traffic connecting to an address associated with CVE-2021-44228 scanning or exploitation activity 

The following alerts may indicate exploitation attempts or testing/scanning activity. Microsoft advises customers to investigate with caution, as these alerts don’t necessarily indicate successful exploitation:

• Possible target of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication received by this device
• Possible target of Log4j vulnerability scanning – detects a possible attempt to scan for the remote code execution vulnerability in a Log4j component of an Apache server in communication received by this device
• Possible source of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication initiated from this device  
• Possible Log4j exploitation – detects multiple behaviors, including suspicious command launch post-exploitation
• Possible Log4j exploitation (CVE-2021-44228) – inactive, initially covered several of the above, now replaced with more specific titles

The following alerts detect activities that have been observed in attacks that utilize at least one of the Log4j vulnerabilities. However, these alerts can also indicate activity that is not related to the vulnerability. We are listing them here, as it is highly recommended that they are triaged and remediated immediately given their severity and the potential that they could be related to Log4j exploitation:

• Suspicious remote PowerShell execution 
• Download of file associated with digital currency mining 
• Process associated with digital currency mining 
• Cobalt Strike command and control detected 
• Suspicious network traffic connection to C2 Server 
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike) 

Some of the alerts mentioned above utilize the enhanced network inspection capabilities in Microsoft Defender for Endpoint. These alerts correlate several network and endpoint signals into high-confidence detection of successful exploitation, as well as providing detailed evidence artifacts valuable for triage and investigation of detected activities.

Figure 14. Example detection leveraging network inspection provides details about the Java class returned following successful exploitation

Microsoft Defender for Cloud Apps (previously Microsoft Cloud App Security)

Microsoft 365 Defender detects exploitation patterns in different data sources, including cloud application traffic reported by Microsoft Defender for Cloud Apps. The following alert surfaces exploitation attempts via cloud applications that use vulnerable Log4j components:

• Log4j exploitation attempt via cloud application (previously titled Exploitation attempt against Log4j (CVE-2021-44228))

Figure 15. Microsoft 365 Defender alert “Exploitation attempt against Log4j (CVE-2021-44228)”

Microsoft Defender for Office 365

To add a layer of protection against exploits that may be delivered via email, Microsoft Defender for Office 365 flags suspicious emails (e.g., emails with the “jndi” string in email headers or the sender email address field), which are moved to the Junk folder.

We also added the following new alert, which detects attempts to exploit CVE-2021-44228 through email headers:

• Log4j exploitation attempt via email (previously titled Log4j Exploitation Attempt – Email Headers (CVE-2021-44228))

Figure 16. Sample alert on malicious sender display name found in email correspondence

This detection looks for exploitation attempts in email headers, such as the sender display name, sender, and recipient addresses. The alert covers known obfuscation attempts that have been observed in the wild. If this alert is surfaced, customers are recommended to evaluate the source address, email subject, and file attachments to get more context regarding the authenticity of the email.

Figure 17. Sample email with malicious sender display name

In addition, this email event as can be surfaced via advanced hunting:

Figure 18. Sample email event surfaced via advanced hunting

Microsoft 365 Defender advanced hunting queries

To locate possible exploitation activity, run the following queries:

Possible malicious indicators in cloud application events

This query is designed to flag exploitation attempts for cases where the attacker is sending the crafted exploitation string using vectors such as User-Agent, Application or Account name. The hits returned from this query are most likely unsuccessful attempts, however the results can be useful to identity attackers’ details such as IP address, Payload string, Download URL, etc.

CloudAppEvents
| where Timestamp > datetime("2021-12-09")
| where UserAgent contains "jndi:" 
or AccountDisplayName contains "jndi:"
or Application contains "jndi:"
or AdditionalFields contains "jndi:"
| project ActionType, ActivityType, Application, AccountDisplayName, IPAddress, UserAgent, AdditionalFields

Alerts related to Log4j vulnerability

This query looks for alert activity pertaining to the Log4j vulnerability.

AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation',
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previously titled Log4j Exploitation Attempt
)

Devices with Log4j vulnerability alerts and additional other alert-related context

This query surfaces devices with Log4j-related alerts and adds additional context from other alerts on the device.  

// Get any devices with Log4J related Alert Activity
let DevicesLog4JAlerts = AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation'
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previouskly titled Log4j Exploitation Attempt
)
// Join in evidence information
| join AlertEvidence on AlertId
| where DeviceId != ""
| summarize by DeviceId, Title;
// Get additional alert activity for each device
AlertEvidence
| where DeviceId in(DevicesLog4JAlerts)
// Add additional info
| join kind=leftouter AlertInfo on AlertId
| summarize DeviceAlerts = make_set(Title), AlertIDs = make_set(AlertId) by DeviceId, bin(Timestamp, 1d)

Suspected exploitation of Log4j vulnerability

This query looks for exploitation of the vulnerability using known parameters in the malicious string. It surfaces exploitation but may surface legitimate behavior in some environments.

DeviceProcessEvents
| where ProcessCommandLine has_all('${jndi') and ProcessCommandLine has_any('ldap', 'ldaps', 'http', 'rmi', 'dns', 'iiop')
//Removing FPs 
| where not(ProcessCommandLine has_any('stackstorm', 'homebrew')) 

Regex to identify malicious exploit string

This query looks for the malicious string needed to exploit this vulnerability.

DeviceProcessEvents
| where ProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'     
or InitiatingProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'

Suspicious process event creation from VMWare Horizon TomcatService

This query identifies anomalous child processes from the ws_TomcatService.exe process associated with the exploitation of the Log4j vulnerability in VMWare Horizon installations. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where InitiatingProcessFileName has "ws_TomcatService.exe"
| where FileName != "repadmin.exe"

Suspicious JScript staging comment

This query identifies a unique string present in malicious PowerShell commands attributed to threat actors exploiting vulnerable Log4j applications. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has "VMBlastSG"

Suspicious PowerShell curl flags

This query identifies unique, uncommon PowerShell flags used by curl to post the results of an attacker-executed command back to the command-and-control infrastructure. If the event is a true positive, the contents of the “Body” argument are Base64-encoded results from an attacker-issued comment. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has_all("-met", "POST", "-Body")

Microsoft Defender for Cloud

Microsoft Defender for Cloud’s threat detection capabilities have been expanded to surface exploitation of CVE-2021-44228 in several relevant security alerts:

On Windows:

• Detected obfuscated command line
• Suspicious use of PowerShell detected

On Linux:

• Suspicious file download
• Possible Cryptocoinminer download detected
• Process associated with digital currency mining detected
• Potential crypto coin miner started
• A history file has been cleared
• Suspicious Shell Script Detected
• Suspicious domain name reference
• Digital currency mining related behavior detected
• Behavior similar to common Linux bots detected

Microsoft Defender for IoT

Microsoft Defender for IoT has released a dedicated threat Intelligence update package for detecting Log4j 2 exploit attempts on the network (example below).  

Figure 19. Microsoft Defender for IoT alert 

The package is available for download from the Microsoft Defender for IoT portal (Click Updates, then Download file (MD5: 4fbc673742b9ca51a9721c682f404c41).  

Figure 20. Microsoft Defender for IoT sensor threat intelligence update

Microsoft Defender for IoT now pushes new threat intelligence packages to cloud-connected sensors upon release, click here for more information. Starting with sensor version 10.3, users can automatically receive up-to-date threat intelligence packages through Microsoft Defender for IoT.

Working with automatic updates reduces operational effort and ensures greater security. Enable automatic updating on the Defender for IoT portal by onboarding your cloud-connected sensor with the toggle for Automatic Threat Intelligence Updates turned on. For more information about threat intelligence packages in Defender for IoT, please refer to the documentation.

Microsoft Sentinel

A new Microsoft Sentinel solution has been added to the Content Hub that provides a central place to install Microsoft Sentinel specific content to monitor, detect, and investigate signals related to exploitation of the CVE-2021-44228 vulnerability.

Figure 21. Log4j Vulnerability Detection solution in Microsoft Sentinel

To deploy this solution, in the Microsoft Sentinel portal, select Content hub (Preview) under Content Management, then search for Log4j in the search bar. Select the Log4j vulnerability detection solution, and click Install. Learn how to centrally discover and deploy Microsoft Sentinel out-of-the-box content and solutions.

Figure 22. Microsoft Sentinel Analytics showing detected Log4j vulnerability

Note: We recommend that you check the solution for updates periodically, as new collateral may be added to this solution given the rapidly evolving situation. This can be verified on the main Content hub page.

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection queries to look for this activity:

• Possible exploitation of Apache Log4j component detected

This hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache. Attackers may attempt to launch arbitrary code by passing specific commands to a server, which are then logged and executed by the Log4j component.

• Cryptocurrency miners EXECVE

This query hunts through EXECVE syslog data generated by AUOMS to find instances of cryptocurrency miners being downloaded. It returns a table of suspicious command lines.

• Azure WAF Log4j CVE-2021-44228 hunting

This hunting query looks in Azure Web Application Firewall data to find possible exploitation attempts for CVE-2021-44228 involving Log4j vulnerability.

• Log4j vulnerability exploit aka Log4Shell IP IOC

This hunting query identifies a match across various data feeds for IP IOCs related to the Log4j exploit described in CVE-2021-44228.

• Suspicious shell script detected

This hunting query helps detect post-compromise suspicious shell scripts that attackers use for downloading and executing malicious files. This technique is often used by attackers and was recently used to exploit the vulnerability in Log4j component of Apache to evade detection and stay persistent or for more exploitation in the network.

• Azure WAF matching for CVE-2021-44228 Log4j vulnerability

This query alerts on a positive pattern match by Azure WAF for CVE-2021-44228 Log4j exploitation attempt. If possible, it then decodes the malicious command for further analysis.

• Suspicious Base64 download activity detected

This hunting query helps detect suspicious encoded Base64 obfuscated scripts that attackers use to encode payloads for downloading and executing malicious files. This technique is often used by attackers and was recently used to the Log4j vulnerability in order to evade detection and stay persistent in the network.

• Linux security-related process termination activity detected

This query alerts on attempts to terminate processes related to security monitoring. Attackers often try to terminate such processes post-compromise as seen recently to exploit the CVE-2021-44228 vulnerability.

• Suspicious manipulation of firewall detected via Syslog data

This query uses syslog data to alert on any suspicious manipulation of firewall to evade defenses. Attackers often perform such operations as seen recently to exploit the CVE-2021-44228 vulnerability for C2 communications or exfiltration.

• User agent search for Log4j exploitation attempt

This query uses various log sources having user agent data to look for CVE-2021-44228 exploitation attempt based on user agent pattern.

• Network connections to LDAP port for CVE-2021-44228 vulnerability

This hunting query looks for connection to LDAP port to find possible exploitation attempts for CVE-2021-44228.

• Linux toolkit detected

This query uses syslog data to alert on any attack toolkits associated with massive scanning or exploitation attempts against a known vulnerability

• Container miner activity

This query uses syslog data to alert on possible artifacts associated with containers running images related to digital cryptocurrency mining.

• Network connection to new external LDAP server

This query looks for outbound network connections using the LDAP protocol to external IP addresses, where that IP address has not had an LDAP network connection to it in the 14 days preceding the query timeframe. This could indicate someone exploiting a vulnerability such as CVE-2021-44228 to trigger the connection to a malicious LDAP server.

Azure Firewall Premium 

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios including UDP, TCP, HTTP/S protocols since December 10th, 2021. Below screenshot shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Recommendation: Customers are recommended to configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2021-44228 exploit.  

Figure 23. Azure Firewall Premium portal

Customers using Azure Firewall Standard can migrate to Premium by following these directions. Customers new to Azure Firewall premium can learn more about Firewall Premium.

Azure Web Application Firewall (WAF)

In response to this threat, Azure Web Application Firewall (WAF) has updated Default Rule Set (DRS) versions 1.0/1.1 available for Azure Front Door global deployments, and OWASP ModSecurity Core Rule Set (CRS) version 3.0/3.1 available for Azure Application Gateway V2 regional deployments.

To help detect and mitigate the Log2Shell vulnerability by inspecting requests’ headers, URI, and body, we have released the following:

• For Azure Front Door deployments, we have updated the rule 944240 “Remote Command Execution” under Managed Rules
• For Azure Application Gateway V2 regional deployments, we have introduced a new rule Known-CVEs/800100 in the rule group Known-CVEs under Managed Rules

These rules are already enabled by default in block mode for all existing WAF Default Rule Set (DRS) 1.0/1.1 and OWASP ModSecurity Core Rule Set (CRS) 3.0/3.1 configurations. Customers using WAF Managed Rules would have already received enhanced protection for Log4j 2 vulnerabilities (CVE-2021-44228 and CVE-2021-45046); no additional action is needed.

Recommendation: Customers are recommended to enable WAF policy with Default Rule Set 1.0/1.1 on their Front Door deployments, or with OWASP ModSecurity Core Rule Set (CRS) versions 3.0/3.1 on Application Gateway V2 to immediately enable protection from this threat, if not already enabled. For customers who have already enabled DRS 1.0/1.1 or CRS 3.0/3.1, no action is needed. We will continue to monitor threat patterns and modify the above rule in response to emerging attack patterns as required.

Figure 24. Remote Code Execution rule for Default Rule Set (DRS) versions 1.0/1.1 

Figure 25. Remote Code Execution rule for OWASP ModSecurity Core Rule Set (CRS) version 3.1

Note: The above protection is also available on Default Rule Set (DRS) 2.0 preview version and OWASP ModSecurity Core Rule Set (CRS) 3.2 preview version, which are available on Azure Front Door Premium and Azure Application Gateway V2 respectively. Customers using Azure CDN Standard from Microsoft can also turn on the above protection by enabling DRS 1.0.

More information about Managed Rules and Default Rule Set (DRS) on Azure Web Application Firewall can be found here. More information about Managed Rules and OWASP ModSecurity Core Rule Set (CRS) on Azure Web Application Firewall can be found here.

Indicators of compromise (IOCs)

Microsoft Threat Intelligence Center (MSTIC) has provided a list of IOCs related to this attack and will update them with new indicators as they are discovered: https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample Data/Feeds/Log4j_IOC_List.csv

Microsoft will continue to monitor this dynamic situation and will update this blog as new threat intelligence and detections/mitigations become available.

Revision history

[01/21/2022] – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

[01/19/2022] New information about an unrelated vulnerability we discovered while investigating Log4j attacks

[01/11/2022] New threat and vulnerability management capabilities to apply mitigation directly from the portal, as well as new advanced hunting queries

[01/10/2022] Added new information about a China-based ransomware operator targeting internet-facing systems and deploying the NightSky ransomware

[01/07/2022] Added a new rule group in Azure Web Application Firewall (WAF)

[12/27/2021] New capabilities in threat and vulnerability management including a new advanced hunting schema and support for Linux, which requires updating the Microsoft Defender for Linux client; new Microsoft Defender for Containers solution.

[12/22/2021] Added new protections across Microsoft 365 Defender, including Microsoft Defender for Office 365.

[12/21/2021] Added a note on testing services and assumed benign activity and additional guidance to use the Need help? button in the Microsoft 365 Defender portal.

[12/17/2021] New updates to observed activity, including more information about limited ransomware attacks and additional payloads; additional updates to protections from Microsoft 365 Defender and Azure Web Application Firewall (WAF), and new Microsoft Sentinel queries.

[12/16/2021] New Microsoft Sentinel solution and additional Microsoft Defender for Endpoint detections.

[12/15/2021] Details about ransomware attacks on non-Microsoft hosted Minecraft servers, as well as updates to product guidance, including threat and vulnerability management.

[12/14/2021] New insights about multiple threat actors taking advantage of this vulnerability, including nation-state actors and access brokers linked to ransomware.

The post Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability appeared first on Microsoft Security Blog.