Tycoon: Ransomware Targeting Java's JIMAGE on Multiple Platforms

The Blackberry Research and Intelligence Team and KPMG's UK Cyber Response Services Team have reported "Threat Spotlight: Tycoon Ransomware Targets Education and Software Sectors." This report outlines the "multi-platform Java ransomware targeting Windows and Linux that has been observed in-the-wild since at least December 2019" and which they've called "Tycoon."

The report provides a high level description of how the Tycoon ransomware is executed: "Tycoon ransomware comes in form of a ZIP archive containing a Trojanized Java Runtime Environment (JRE) build. The malware is compiled into a Java image file (JIMAGE) located at lib\modules within the build directory." The report describes the "sparsely documented" JIMAGE "file format file format that stores custom JRE images which is designed to be used by the Java Virtual Machine (JVM) at runtime." Additional high-level overviews of the JIMAGE file format can be found in JIMAGE - Java Image File Format, How Modules Are Packaged in Java 9, What Is a Custom Runtime Image in Java 9?, So what is a .jimage?, Alan Bateman's description, and slide 49 of JDK 9 Java Platform Module System. The JIMAGE format was introduced with JDK 9 modularity (Project Jigsaw).

Alan Bateman (owner of JEP 220 ["Modular Run-Time Images"])has explained why it's difficult to find documentation on the JIMAGE format: "The format is deliberately not documented and best to assume it will change and evolve over time as it inhales new optimizations." The jdk.jlink module documentation provides very brief mention of the jimage command-line tool and mentions that it is used "for inspecting the JDK implementation-specific container file for classes and resources." It also points out that there is no API for accessing jimage, which is different than for the module's two other tools (jlink and jmod). Similarly, there is no jimage tool reference on the "Java Development Kit Version 14 Tool Specifications" page even though jlink, jmod, and many other tools are featured there.

The previously mentioned report states that "the ransomware is triggered by executing a shell script that runs the Main function of the malicious Java module using the java -m command." The report also talks about Tycoon using Image File Execution Options Injection with Windows registry and then appearing to target Windows and Linux: "The malicious JRE build contains both Windows and Linux versions of this script." This reports adds that Tycoon's "Trojanized Java Runtime Environment (JRE) build" exists as a ZIP file placed in lib/module.

The "Conclusions" section of "Tycoon Ransomware Targets Education and Software Sectors" makes some interesting conclusions based on research observations. In particular, I find it interesting to read why they believe Tycoon in a targeted attack. The authors also point out, "This is the first sample we've encountered that specifically abuses the Java JIMAGE format to create a custom malicious JRE build."

I recommend reading the report "Threat Spotlight: Tycoon Ransomware Targets Education and Software Sectors" directly, but for those interested in summaries and others' observations related to this report, the following may be of interest.

• A new Java-based ransomware targets Windows and Linux (TechCrunch, TechCrunch)
• This new ransomware is targeting Windows and Linux PCs with a 'unique' attack (ZDNet)
• Newly discovered Tycoon ransomware leverages obscure Java image format (Silicon Angle)
• Multi-Platform 'Tycoon' Ransomware Uses Rare Java Image Format for Evasion (SecurityWeek)
• There's a new Java ransomware family on the block (CyberScoop)

The discovery of Tycoon is likely to bring significantly more attention to JIMAGE than ever before.

Octopus Scanner: Java Build Tools and Malware

Alvaro Muñoz recently posted "The Octopus Scanner Malware: Attacking the open source supply chain" on the GitHub Security Lab site. I found this post to be interesting for a number of reasons, including its detailed coverage of how the Octopus Scanner malware works and how it was discovered, how the GitHub Security Incident Report Team (SIRT) went about addressing it, how it affected a popular Java IDE, and how GitHub works to detect and address risks to open source software deployed on its site.

Muñoz calls Octopus Scanner "an OSS supply chain malware" and writes that 26 GitHub-hosted open source projects "were backdoored by this malware." In the post, Muñoz describes in detail how Octopus Scanner works. The post in its entirety is worth reading, but here are some highlights describing Octopus Scanner:

• "Octopus Scanner malware is only interested in the pre-jar and post-jar tasks" of "a NetBeans project build."
• "The malware disguises itself as an ocs.txt file, but we can easily determine is is actually a Java Archive (JAR) file."
• "The malware also infected any JAR files that were available in the project, such as dependencies - not necessarily just build artifacts."
• "The octopus.dat payload is the binary that actually performs the NetBeans build infections."
• "cache.dat is responsible for backdooring the built classes so that when these classes get executed, they will infect the underlying system."
• Octopus Scanner is designed to target "UNIX-like systems", MacOS, and Windows.

I found the highly detailed approach to diagnosing Octopus Scanner's behavior in the GitHub post to be fascinating and insightful reading. It was especially insightful to see the tools and methods used to understand better how Octopus Scanner behaves. For example, they used ClassFileTransformer and "a Bytecode manipulation library such as Javassist or ByteBuddy to inject our analysis code" into the "class responsible for decrypting the blob ... right before it actually gets loaded into the JVM."

Besides the interesting details of how Octopus Scanner works and how it was discovered and researched, other interesting insights in this GitHub post are related to the risks open source builds face. Muñoz writes, "Infecting build artifacts is a means to infect more hosts since the infected project will most likely get built by other systems and the build artifacts will probably be loaded and executed on other systems as well." Muñoz adds, "In an OSS context, it gives the malware an effective means of transmission since the affected projects will presumably get cloned, forked, and used on potentially many different systems. The actual artifacts of these builds may spread even further in a way that is disconnected from the original build process and harder to track down after the fact."

Muñoz opens the post and concludes the post with some discussions about this and other attempts at sabotaging open source products and their builds. One chilling thought is included in the Conclusion: "Since the primary-infected users are developers, the access that is gained is of high interest to attackers since developers generally have access to additional projects, production environments, database passwords, and other critical assets. There is a huge potential for escalation of access, which is a core attacker objective in most cases."

JEP 342: The JVM and Spectre

JEP 342 ("Limit Speculative Execution") has transitioned from "Draft" state to "Candidate" state, but it has not yet been targeted to a specific JDK release (see graphic for steps in JEP process). Jesper Wilhelmsson has written that JEP 342 "covers the initial work to make use of new C++ compiler options to limit speculative execution in native code in the JDK." JEP 342's "Summary" succinctly describes its purpose, "Help developers and deployers defend against speculative-execution ('Spectre') vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases."

JEP 342 aims to provide a "distinct, alternate JVM in the JDK that is compiled with" C++ "compiler options that limit the extent to which the CPU can do speculative execution" and which "can be selected at launch time." The JEP states that the plan is to "include a distinct, alternate JVM in the JDK that is compiled with these options and can be selected at launch time." The JEP 342 text describes the specific C++ compilers and options affected by this JEP:

• Linux gcc (gcc 7.3.0+)
  • -mindirect-branch=thunk
  • -mfunction-return=thunk
  • -mindirect-branch-register
• Windows VisualStudio (Visual Studio 2017 version 15.7+)
  • /Qspectre

JEP 342 describes the default execution of the java launcher to continue to be as it is today (nothing to avoid speculative execution), but with the availability of a command-line flag [-nonspeculative] to disable speculative execution. The decision was made to avoid always prohibiting speculative execution because it should "be up to the end user to decide whether to limit speculative execution." The ability to choose is important because, as the JEP states, the impact of "limiting speculative execution ... can be significant for the C and C++ code in the HotSpot JVM, but it is negligible for the C and C++ code outside of the JVM." It is worth noting here that the "non-JVM code" will always be compiled with the new C++ options addressing speculative execution given that there is very little performance impact in those areas.

Spectre has been one of multiple threats to software applications and it's nice to see new possibilities for dealing with these threats potentially coming to the JVM.

Java Zero Day Vulnerability Exploits JMX and MethodHandles

I recently identified software security issues (#2), especially related to Java, as one of the most significant software development themes of 2012. Not even a month into 2013, a news story receiving a lot of press is the U.S. Department of Homeland Security's issuing of Alert (TA13-010A), which is described with more technical details in Vulnerability Note VU#625617. Oracle has since released a Security Alert for CVE-2013-0422.

Vulnerability Note VU#625617 includes a paragraph that is particularly insightful:

By leveraging the a vulnerability in the Java Management Extensions (JMX) MBean components, unprivileged Java code can access restricted classes. By using that vulnerability in conjunction with a second vulnerability involving recursive use of the Reflection API via the invokeWithArguments method of the MethodHandle class, an untrusted Java applet can escalate its privileges by calling the the setSecurityManager() function to allow full privileges, without requiring code signing. Oracle Java 7 update 10 and earlier Java 7 versions are affected. OpenJDK 7, and subsequently IcedTea, are also affected. The invokeWithArguments method was introduced with Java 7, so therefore Java 6 is not affected.

The above scenario is described in great detail in Tim Boudreau's excellent The Java Security Exploit in (Mostly) Plain English and he references Java 0day 1.7.0_10 decrypted source code that demonstrates the code that can implement an attack that takes advantage of the described JMX/MethodHandles combination vulnerability. Kafeine's (Malware don't need Coffee) post 0 day 1.7u10 (CVE-2013-0422) spotted in the Wild - Disable Java Plugin NOW ! provides numerous screen snapshots to illustrate this Java Zero-Day Malware in action.

The TA13-010A/CVE-2013-0422 Java Zero Day Vulnerability has made the mainstream news with coverage by Norton/Symantec (What's All the Buzz About Java? Fixing The Vulnerability and Java Zero-Day Dished Up from Cool Exploit Kit), McAfee (Java Zero-Day Vulnerability Pushes Out Crimeware), InformationWeek (Java Zero Day Attack: Second Bug Found), Fox News (Reuters: As Hacking Concerns Build, U.S. Warns on Java Software), CNN (Critical Java vulnerability due to incomplete earlier patch), and many more news outlets.

As stated above, Oracle has issued a patch, but the Department of Homeland Security still recommends disabling Java in the browser.