Unit 42 analyzes npm supply chain evolution post-Shai Hulud. Discover wormable malware, CI/CD persistence, multi-stage attacks and more.
The post The npm Threat Landscape: Attack Surface and Mitigations (Updated May 1) appeared first on Unit 42.
JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.
JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.
The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.
Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.
JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.
Malicious email used in JanelaRAT campaigns
Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.
However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.
Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.
JanelaRAT infection flow evolution
The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.
Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.
The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.
In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.
JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.
The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.
All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.
After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.
Following socket initialization, the malware launches two background routines:
Timer that looks for 10 minutes of inactivity
EntrarPixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.
This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:
<C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>
We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.
| Parameter | Description |
| VS | JanelaRAT version |
| PL | OFF by default |
| AN | Yes or No depending on whether banking security software process exists |
This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.
If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.
To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.
| Action Performed | Description |
| Capture desktop image | Send compressed screenshots to the C2 |
| Specific screenshots | Crop specific screen regions and exfiltrate images |
| Overlay windows | Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials |
| Keylogging | Keystroke capture |
| Simulate keyboard | Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements |
| Track mouse input | Move the cursor, simulate clicks, and report the cursor position |
| Display message | Show message boxes (custom title, text, buttons, or icons) |
| System shutdown | Execute a forced shutdown sequence |
| Command execution | Run CMD or PowerShell scripts/commands |
| Task Manager manipulation |
Launch Task Manager, find its window, and hide it to prevent discovery by the user |
| Check for banking security software process | Detect the presence of anti-fraud systems |
| Beaconing | Send host information (malware version, profile, presence of banking software) |
| Toggle internal modes | Enable and disable modes such as screenshot flow, key injection, or overlay visibility |
| Anti-analysis | Detect sandbox or automation tools |
Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.
This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.
The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.
Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:
When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.
An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.
In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.
The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.
This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.
Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.
According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.
JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.
This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.
To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.
808c87015194c51d74356854dfb10d9e MSI Dropper
d7a68749635604d6d7297e4fa2530eb6 JanelaRAT
ciderurginsx[.]com Primary C2
In the course of its investigations, Volexity frequently encounters malware samples written in Golang. Binaries written in Golang are often challenging to analyze because of the embedded libraries and the sheer size of the resulting binaries. This issue is amplified when samples are obfuscated using tools such as Garble, an open-source Golang obfuscation tool.
The popularity of Golang amongst malware developers, and the use of obfuscators to make reverse-engineering harder, raised the need for better tooling to assist in reverse-engineering efforts. Volexity developed GoResolver, an open-source tool that uses control-flow graph similarities to retrieve obfuscated functions names. GoResolver is available for download on GitHub here.
Note that throughout this blog post, Garble obfuscation is used to demonstrate GoResolver’s effectiveness. However, the same principles apply to other closed-source Golang obfuscators observed by Volexity.
One of the obfuscators commonly encountered by Volexity is Garble. Its functionality is described in the README, a screenshot of which is shown below:
Despite these listed features, all of which significantly hinder manual static analysis, binaries obfuscated using Garble present interesting properties that weaken the overall apparent strength of its obfuscation.
For example, the randomization employed by Garble for function and package names is not truly random. Due to how Golang resolves function names, randomized names must stay consistent across all functions of a package, so they are highly reused:
As shown in the image above, the “E2AKV7TQjQ” string is reused across many functions as it represents the package name. Manually looking at the functions called by this garbled string, it can be inferred that this represents the os/exec package. Consequently, if one function from a package is identified, the package can be identified for the entire binary. All other obfuscated functions can then be associated with this package. This logic greatly improves the symbol recovery.
Some tools already exist to help retrieve lost symbol information, the most well-known of which is Mandiant’s GoReSym. GoReSym works by bypassing the symbol table entirely. Instead, it extracts function names and type information from Go’s internal runtime structures, ModuleData and PcLineTab, in the same way as the Golang runtime would, using the Golang runtime’s own parser whenever possible. As these structures are necessary for Golang binaries to work properly, Garble cannot strip them.
As the retrieved symbols are still randomized, Volexity recognized an opportunity to go further by using control-flow graph similarities to identify the original package and function names.
Control-flow graphs can be used to represent different paths a binary may take during execution. Even when recompiled across different compiler versions, the resulting control-flow graph of a given algorithm will remain similar. By measuring the similarity between the control-flow graph of two functions in two different binaries, it is sometimes possible to assert if they result from the same algorithm.
A paper published in 2020 describes an efficient technique to compute the normalized similarity (0.0 to 1.0) between two control-flow graphs by computing the weighted ratio of similar assembly instructions across nodes of the control-flow graph. By implementing this technique and comparing Garbled samples against generated clean template Golang samples, it could then be possible to fully resolve the randomized symbol names to their original form.
An illustration of this process is below:
Two graphs are compared, and the similarity between each set of two blocks in the graph is computed. In the illustration above, the red and blue blocks contain the exact same instructions but in a different order, and thus have a similarity of 1.0.
The GoResolver toolchain is composed of four projects:
| Project | Description |
| GoResolver | A Golang symbol recovery tool through symbol extraction and control-flow graph similarity |
| GoGrapher | A binary similarity tool that computes the control-flow graph similarity between two binaries |
| GoStrap | A Golang reference sample bootstrapping tool that allows users to generate Go samples of any Golang version and feature the requested set of libraries |
| GitToolFetcher | A simple tool to install, manage, and run multiple, concurrent versions of GitHub-hosted projects |
An overview of the interactions within the projects of the GoResolver toolchain is shown below:
To install the GoResolver toolchain, please ensure your system’s dependencies match the following minimum requirements:
| Language | Version |
| Go | 1.20.6+ |
| Python | 3.12+ |
Each Python-based component of the toolchain is available on pypi, so you can simply run the following command to install:
pip install goresolver
GoResolver also provides plugins for IDA Pro and Ghidra. The following versions are supported:
| Tool | Version | Python Version |
| IDA Pro (IDAPython) | 9+ | Python 3.12+ |
| Ghidra (PyGhidra) | 11.3+ | Python 3.12+ |
In Volexity’s experience, analysis of Golang binaries is significantly faster in IDA Pro.
To illustrate usage of the GoResolver toolchain, Volexity built the Stowaway agent using Garble. The sample (1df2cd0d12e5028d5dbda33a4e4404e0) is available on VirusTotal.
When the sample is disassembled using IDA Pro, most functions have generic names using the format sub_OFFSET. This is to be expected, since Garble stripped the symbol table. Performing a complete analysis would be tedious; instead, the sample is submitted to GoResolver.
GoResolver will first try to identify the version of Golang used to build the malware sample. This is usually done by parsing the BuildInfo or identifying Golang version string fragments in the binary. For garbled Golang binaries, however, neither approach works, since Garble ensures no version fragments or BinaryInfo remain in the compiled executable.
While Garble removes all directly identifiable information, it is still bundled with the Golang runtimes. Since the Golang runtime changes between different versions, GoResolver can use this information to fingerprint the runtime version. By generating reference data for each major Golang version and computing the similarity of each runtime with the malware sample, the tool can pinpoint the Golang version used to compile the malware sample. Volexity has identified that testing only 2% of the Golang runtime was sufficient to discriminate between major versions. This improves both efficiency and resource usage when computing the similarity of each major Golang version of the malware sample.
To submit a sample to GoResolver, simply call the tool with the path to the sample as argument, for example:
goresolver /path/to/sample.exe
The submission of the malware sample to GoResolver is shown below:
Once the Golang version of the malware sample is identified, the template compiled with this specific version will be used as a reference. GoResolver then computes the full binary similarity, which is combined with the symbols extracted similarly to those used by GoReSym. This results in the final symbol report, which can then be imported into your SRE tool of choice.
The before-and-after import comparison of resolved symbols is illustrated below:
As shown above, numerous symbols have been resolved to more meaningful names, even though they are still partially obfuscated. Even in cases where symbols haven’t been fully resolved by the similarity algorithm, statistical analysis helps resolve the package and modules names, as can be seen with the “os” package shown below:
Even though these symbols are only partially resolved, knowing their package name helps understand the binary layout. This also helps the analyst avoid reversing runtime and library methods, allowing them to instead focus on the malware’s actual core logic.
To ease the integration of the GoResolver toolchain into analyst workflows, Volexity has made plugins available for both IDA Pro and Ghidra. Both plugins allow easy import of recovered symbol data generated by the GoResolver CLI tool into their respective symbol databases. While their interface differs, both plugins rely on the same codebase and thus provide the same capabilities.
When using IDA Pro, the following dialog is shown:
The GoResolver plugin features two modes of operation, depending on how you want the GoResolver toolchain to integrate into your workflow: “Analyze the current file” or “Import a previous report”. These options are selectable on the left-hand side.
The Analyze option lets you run GoResolver directly within IDA Pro. Once the analysis is complete the generate report file will be automatically imported into the symbol database.
The Import option requires you to generate a report file using the standalone GoResolver CLI beforehand. This can then be imported into the symbol database by selecting the path to the previously generated report file.
When using Ghidra, the following dialogs are shown:
These dialogs offer the same options as the IDA Pro plugin; the Analyze and Import modes behave the same way.
Both plugins are available in the “Plugin” directory within GoResolver’s repository.
Golang is more often the language of choice for many malware authors, due to embedded libraries and the size of the resulting binaries. To add additional complexity, malware written in Golang is often obfuscated. The ability to reverse engineer obfuscated malware written in Golang is an important part of digital forensic investigations.
Volexity has developed GoResolver, an open-source tool that uses control-flow graph similarities to retrieve obfuscated functions names. The use of control-flow graph similarity, in conjunction with pre-existing symbol extraction techniques, allows the resolution of more complete symbols than previously achievable. This ensures a better understanding of the binary, and helps analysts focus on reversing the core malware logic. Volexity plans to integrate more features, such as automatic Golang strings parsing and various improvements to facilitate the Golang binaries reversing, so watch for updates in the GoResolver repository on GitHub.
Volexity would like to thank Mandiant’s threat intelligence division for its documentation of the Golang runtime’s symbol-parsing mechanism, as well as their work on GoReSym.
Volexity also thanks Mr. Hyun-il Lim from the Kyungnam University for the research and paper on control-flow graph similarity algorithms.
The post GoResolver: Using Control-flow Graph Similarity to Deobfuscate Golang Binaries, Automatically appeared first on Volexity.
