Threat Thursday: Jupyter Infostealer is a Master of Disguise

Summary

Jupyter infostealer is a master of deception, a highly modular malware that hides deep within legitimate installer packages. Once executed, it can receive further malicious components via its command-and control (C2) server to enhance its capabilities. These components can include executables and malicious PowerShell scripts.

One of the downloads is an information stealing module, designed to scoop up victim credentials like their computer name, user admin rights, workgroup, browser password database, and other useful information. It also targets popular browsers such as Google Chrome™, Microsoft Edge®, Opera, Brave, and Mozilla Firefox. Upon finding one of these browsers installed, it gathers and exfiltrates sensitive user data stored within these browsers, such as login data (usernames and passwords), cookies, and web data, including “autofill” information such as the user’s name, home address, and email address.

It also targets a large number of crypto wallets, including Atomic Wallet, MyMonero Wallet, and Ethereum Wallet, and additionally seeks to access several Remote Access Applications including OpenVPN and Remote Desktop Protocol (RDP).

This malware is particularly noxious, as it does not target specific organizations or business verticals, and it does not have a set goal or agenda. It targets all victims who inadvertently fall for its ploys.

Discovery and Execution

When Jupyter was first discovered at the end of 2020, it initially bundled itself with legitimate executables. When executed, it revealed an obfuscated PowerShell script hidden within. Throughout 2021, this threat group has focused its development efforts on increasing levels of stealth and obfuscation, including loading the Dynamic-Link Library (.DLL) of Jupyter reflectively into memory rather than writing the file to disk.

In its current form, Jupyter now tends to be bundled in large Windows® installer packages (.MSI), often exceeding 100 MB in size. These packages are still bundled with legitimate applications, and also signed with valid digital certificates to further hide their intentions.

On installation, the package will load and attempt to install the bundled legitimate application. However, deep within the code of these Trojan installers resides a relatively small, heavily obfuscated and encrypted PowerShell script that will run in the background.

Operating System

Risk & Impact

Technical Analysis

Many Faces, Many Names, Many labels

Over a short period of time, Jupyter has masqueraded as many different applications and installers. The malware has also changed its core file extension to .MSI, and it uses different operations to execute its obfuscated PowerShell script.

This flexibility has led various security research organizations to label the malware family differently, based on Jupyter’s core module naming functions, or downloaded components. Previous names include Polazert, Yellow Cockatoo, and more recently SolarMarker/Deimos. The malware has since abandoned the Indicators of Compromise (IoCs) that were the basis of these naming conventions, to thwart easy identification.

Infection Vector

Jupyter’s initial infection vector can vary widely. Typically, Jupyter is hosted on fake downloader websites that masquerade as legitimate hosts. These sites typically offer a free download for a PDF book or a simple application. These can either be visited by a victim unintentionally, or via a link in a malicious email.

Figure 1: Jupyter samples are often signed with digital certificates to appear trustworthy

Jupyter is often bundled with freeware applications and signed with un-revoked digital certificates as shown in Figure 1, making the download appear more legitimate.

In previous iterations, Jupyter had moved away from using Windows Portable Executables (.EXE files) in favor of large Windows Installer Packages (.MSI). This is likely because MSI is a file type that is less likely to be scanned by some antivirus (AV) programs, and because large files (beyond 100 MB) are less likely to be inspected by automated sandbox routines and other automated AV scanning solutions.

Installation

On execution, the Windows installer package will display an installer pop-up for the intended legitimate application, as shown in Figure 2, while loading its data and silently running in the background.

Figure 2: Trojanized MSI files appear to install the desired application as expected

Over the past campaign, Jupyter has used a wide range of methods to deploy itself. Typically, the malware contains two core files – an executable and a Windows PowerShell containing the malicious code – though it is not limited to this arrangement.

Some variants of Jupyter have also deployed a temporary file (.TMP) into the victim’s %AppData%\Roaming\Temp\ directory, and they have dropped an additional Microsoft PowerShell (.PS1) file, as shown in Figure 3, to generate the typical content of Jupyter’s core malicious PowerShell script.

Figure 3: Contents of Jupyter MSI installer

PowerShell

All samples of Jupyter have heavily relied on PowerShell. The malware uses PowerShell both to obfuscate its malicious code, and to execute that code without it ever writing itself to disk on the victim’s machine.

It avoids writing itself to disk by loading the DLL of Jupyter reflectively into memory. Normally, DLLs are injected into a process from a file that is written to disk. Reflective DLL injection is a technique that forcefully injects code into a victim process from memory rather than disk.

As the fully un-obfuscated malware does not reside on disk, it requires a persistence mechanism to be created, such as registry keys that reload the malware when the victim machine is started up. This makes Jupyter DLL difficult to both detect and analyze, unless dumped from memory.

Figure 4: Breakdown of Jupyter PowerShell

Jupyter’s core PowerShell typically can be broken down into six different steps or components, as shown in Figure 4 and the table below. Each step facilitates a specific goal, function, or ability. Though a lot of samples of Jupyter follow the same steps, variations are present in Jupyter’s PowerShell code, and some samples have been noted to operate in slightly different ways to achieve the same ends.

Not all samples of Jupyter observed over its recent campaign have the same behavior. Some deploy their decoy files in different directories. Others opt not to XOR their DLL’s code, while still encoding themselves with Base64.

Decoy

To thwart analysis, one of the first actions of Jupyter’s PowerShell is to create hundreds of randomized “junk files” as decoys, as shown in Figure 5, while leaving a single file as the core component of the malware. These decoys are files that are created by the malware that serve no malicious use or purpose except to hide the single malicious file within their midst.  

Figure 5: Decoy Files dropped by Jupyter

Previously observed iterations of Jupyter would drop their core .DLL to disk. Though this ploy is still used by Jupyter, it does not deploy the DLL directly to disk anymore. The deobfuscated version of the malware is now only loaded into memory.

With each execution of the PowerShell script, the malware will generate a new directory for its randomized set of decoy files and core malware component. Over the course of this recent campaign, Jupyter has deployed itself in three distinct locations on a victim device:

• %AppData%\Roaming\Adobe\ [Random 15 Char directory]\
• %AppData%\Roaming\Microsoft\ [Random 15 Char directory]\
• %AppData%\Roaming\Nvidia\ [Random 15 Char directory]\

Persistence

On execution, Jupyter will silently run its PowerShell script. This script can be modified to display its true intentions for analysis, as displayed in the image below.

Figure 6: Persistence-based mechanisms via registry keys

The sample used for this analysis of Jupyter creates a new directory in the folder C:\Users\%Admin%\AppData\Roaming\Microsoft. In this example, the directory was named kNPqHZeEjTuJAXRY, as seen in Figure 6. These locations are randomized by the malware and a new one is generated per execution.

The malware will add an additional shortcut file to the Windows\Start Menu directory via %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. This also uses a randomized name derived from a variable in its PowerShell code. This shortcut is deployed by the malware as a persistence mechanism, so it will execute the file on startup, as shown in Figure 7.

Figure 7: Example of Jupyter sample startup shortcut

Jupyter also generates two different registry keys during the execution of its PowerShell code. The first key is added to the victim’s machine in the following location, as seen in Figure 7: Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\%.cwvynlbszymn%

This final part of the registry key is also randomized; each time the malware is executed, it will generate a new randomized sequence. This key points to the second registry key generated by the malware, as shown in Figure 8.

Figure 8: RegKey added by Jupyter

The data within the second registry key added by Jupyter contains a PowerShell command that will re-execute the malware, as shown in Figure 9. This is used as a further persistence mechanism by the malware.

Figure 9: Core registry key re-executing Jupyter

Once located, the contents of this registry key can be further analyzed and inspected. Like its initial PowerShell script, its intentions are to deobfuscate the malware’s main DLL and load it reflectively into memory.

This PowerShell command, as shown in Figure 10, is a truncated version of the original PowerShell code. Its purpose is to re-run, or execute the malware, on startup. This code is notably smaller in size, as it omits previously achieved steps and functionality, such as deploying the decoy files and adding registry keys.

Figure 10: PowerShell contents of registry keys

Core DLL

The core DLL related to Jupyter is .NET-compiled. Previous iterations of this DLL contained labelled functions, and it was not obfuscated, which gave clear indications of the malware’s intentions. In late 2021, newer iterations and versions of the malware became more sophisticated. The malware no longer uses identifiable labels for its functions, adding further obfuscation to its code’s contents. Despite this evolution, the functionality of this “core module” remains largely the same.

Figure 11: Differences between versions of Jupyter

The initial functionality of this module is to establish contact with the malware’s C2 infrastructure. The malware achieves this using the .NET WebRequest provider to send POST requests to a hard-coded IP address located within each sample of Jupyter.

During analysis, we noted that the C2 infrastructure for Jupyter appears to remain offline until it is required. The malware continues running in the background and awaits its infrastructure coming online. It will check for the availability of the C2 at regular intervals until successful connection is achieved.

The request to the C2 contains RSA-encrypted data, including a hard-coded RSA key as seen in Figure 12, that is used for future communications. Jupyter also uses Advance Encryption Standard (AES) encryption for its communications.

AES is a commonly used symmetric block cipher. Jupyter uses this encryption standard on its communication to prevent packet interception and inspection when communication, deployment of modules, and exfiltration of data is occurring between the malware core module and the C2.

Figure 12: Contents of Jupyter’s “configuration” function

If a successful connection is achieved, the core module begins its reconnaissance of the victim’s device to locate information such as:

• Machine name
• Windows version
• CPU architecture (x86/x64)
• User’s admin rights
• Workgroup
• DNS
• Protocol version
• Machine status (idle/active)

Jupyter contains a “ping” function that will attempt to send this information, along with following:

• Version ID of the malware (version)
• A unique hash derived from the victim device hardware (hwid)
• A Base64 unique identifier hash per communication (uniq_hash)

Once communication has been established with its C2, Jupyter’s modular design allows the threat to receive further malicious components to enhance its capabilities, as seen in Figure 13. These components can include executables and further malicious PowerShell scripts.

Figure 13: C2 activity and download of additional components

Versions

Each sample of Jupyter has a “Version ID” (shown in Figure 12) that is used in C2 communication. A newly discovered Version ID often signifies a change, update, or the addition of further capabilities to the core malware module. Different variations of Jupyter can largely be identified by characteristics of these Version IDs.

Table 1: Jupyter versions

Modules

Once Jupyter has finished creating persistence, it begins checking a hard-coded C2 for the next module to download. Throughout our research, we observed a variety of different modules served by the C2. On examining this main Jupyter module and the capabilities of the code, it is possible to rename the obfuscated functions to estimate their name prior to obfuscation:

Figure 14 – Original function names versus renamed functions based on capabilities

One of the downloaded components is an information-stealing module, which includes a PowerShell script and payload. The payload is decoded by the PowerShell script and then reflectively loaded into memory.

Infostealer Module:

This module uses several functions to extract information from various sources on a victim’s computer. One of the functions used is the Data Protection API (DPAPI). Within this API, a class called ProtectedData contains two wrappers: “Protect” and “Unprotect.” The infostealing module makes use of the “Unprotect” wrapper, which is passed a byte array of encrypted data and returns a byte array of decrypted data.

As seen in Figure 15, the Unprotect wrapper is called via the method “a01e73a94eb4d2952c37caa645a74.”

Figure 15 – Extraction of Chrome password database and encryption key for database

The Chrome JSON configuration is stored in the local AppData directory in a file called “Local State,” which is parsed using a class starting with “a5f8…” Within this configuration is an entry called “os_crypt,” which has a further entry called “encrypted_key.” The “encrypted_key” is used to encrypt saved login data.

The infostealer module uses a utility class “a01e…” to read this encrypted key, and a static class function starting with “a671…” to call DPAPI Unprotect. As the key is prefixed with DPAPI signature bytes, a loop runs five times to omit this. Once the “encrypted_key” is formatted, it is then stored in a class field called “aes_key.” Further to this, a randomly named copy of the Chrome “Login Data” file is written to the temporary directory in Windows, which is then stored in the class field “pwds_db” and deleted from the temporary directory.

There is no decryption of the stored Chrome login data taking place in the function shown in Figure 15; the relevant data is read and stored into class member fields “aes_key” and “pwds_db.” The “pwds_db” and “aes_key” values are collected and converted to Base64. This indicates the malware authors are opting to perform credential decryption following data exfiltration. This makes sense from an efficiency perspective, as they have everything necessary to decrypt the login data after stealing the Chrome information.

The infostealer module targets the following browsers:

• Google Chrome
• Microsoft Edge
• Opera
• Brave
• Mozilla Firefox

It also gathers the following browser data:

• Login data (usernames/passwords)
• Cookies
• Web data (Autofill information such as names, addresses, emails)

Figure 17: Decrpyting Chrome data

Jupyter targets the following crypto wallets:

• Atomic Wallet
• Guarda Wallet
• SimplEOS Wallet
• NEON Wallet
• Wasabi Wallet
• MyMonero Wallet
• Jaxx Wallet
• Electrum Wallet
• Ethereum Wallet
• Exodus Wallet
• GreenAddress Wallet
• Coin Wallet
• Bither Wallet
• Coinomi Wallet
• Ledger Live Hardware wallet
• Trinity Hardware wallet
• Scatter Hardware wallet
• Wildcard any file matching: *wallet*.dat
• Wildcard any file matching: *.wallet

Remote Access Applications Targeted:

• OpenVPN
• Remote Desktop Protocol (RDP)

Conclusion

At the close of 2021, Jupyter saw rapid enhancements to prior iterations. This made the newer versions of malware harder to detect, scan and prevent, leading to a rise in devices affected by the malware.

Now that Jupyter is being bundled with legitimate, signed software, this ploy makes it difficult to detect the threat before it has been deployed onto a victim system. As the malware executes via DLL reflection, it gives little indication that it is running silently in the background. Once on a victim system, Jupyter will use multiple persistence mechanisms, and it will even install the legitimate software it’s bundled with to further deceive the victim.

To further conceal its activities, Jupyter’s C2 infrastructure tends to remain offline for large periods of time, operating in short bursts of activity rather than constant communication.

The modular nature of the malware keeps its core-module compact. Jupyter largely focuses on stealing information, deploying various modules to obtain passwords, credentials, and other data. However, the malware is not just limited to these activities. Once it gains a foothold on the system, it can download a wide variety of components, making it an extremely dangerous piece of malware.

YARA Rule

The following YARA rule was authored by the BlackBerry Research and Intelligence Team to catch the threat described in this document:

Indicators of Compromise (IoCs)

BlackBerry Assistance

If you’re battling this malware or a similar threat, you’ve come to the right place, regardless of your existing BlackBerry relationship.

The BlackBerry Incident Response team is made up of world-class consultants dedicated to handling response and containment services for a wide range of incidents, including ransomware and Advanced Persistent Threat (APT) cases.

We have a global consulting team standing by to assist you providing around-the-clock support, where required, as well as local assistance. Please contact us here: https://www.blackberry.com/us/en/forms/cylance/handraiser/emergency-incident-response-containment