Threat actors actively employ NodeJS in banking attacks to obtain the targeted victims' online banking credentials. JavaScript web injections are used by threat actors to modify a bank's website login page. Threat actors can gather credentials and one-time passwords thanks to this covert modification.

Additionally, this enables them to get beyond security measures and access user accounts without authorization. Kaspersky Labs cybersecurity scientists have found Coyote malware, which uses NodeJS to assault customers of over 60 institutions.

Forget Old Delphi & MSI

Malware developers frequently utilize MSI installers or the Delphi programming language when creating banking Trojans. In the field of cybersecurity, it is commonly recognized that this technique acts as a popular initial infection vector.

Coyote operates in a somewhat different manner. Rather than following the conventional path of using MSI installers, it chose to use Squirrel, a relatively new tool for installing and updating Windows desktop programs.

With this tool, Coyote masquerades as an update packager and hides its initial stage loader.

The Node.js Loader Script

Eventually, an Electron-compiled NodeJS application is launched when Squirrel is executed. Preload.js, an obfuscated JavaScript code that this program runs, is primarily responsible for copying all executables located in a local folder called temp to the user's captures folder inside the Videos folder. A signed program is then launched from that directory.

Numerous executables, including those connected to OBS Studio and Chrome, are in use. Through DLL sideloading of an executable requirement, the banker is loaded. DLL sideloading takes place in the libcef.dll library in every scenario that our team has examined.

The Nim Loader

The final level of the infection chain is loaded using Nim, a relatively new programming language, which is an interesting component. The loader's goal is to use the CLR to unpack and run a.NET executable in memory. This suggests that, similar to Donut, the loader's goal is to load the executable and run it inside its process.

Interestingly, every time a PC reboots, the same entry point, obs-browser-page.exe, is used as a kind of persistence.

Last But Not Least, the Coyote Banking Trojan

The Trojan is successfully executed after completing all of these procedures. Coyote solely employs string obfuscation with AES encryption; it does not use any code obfuscation techniques.

It invokes a decryption method with the string index as a parameter to obtain a specific string. A table containing base64-encoded data is created as part of the decryption process. Each decoded data item has an Initial Vector (IV) consisting of the first 16 bytes; the remaining bytes are encrypted data that is used in the AES decryption procedure.

Each executable generates the key at random, and the official AES decryption technique makes use of it.Interfaces for net encryption. Using this method, Coyote scans the table for each string it requires access to and uses a unique IV to decode each string.

Persistence & Goals

HKCUEnvironmentUserInitMprLogonScript is first checked to see if it exists, and if it does, Coyote enters the registry value as the complete path of the signed application—in this case, obs-browser-page.exe—to establish persistence.

The goal of the Coyote Trojan aligns with the usual actions of banking Trojans. It waits for the victim's machine to access the designated banking application or website while keeping an eye on all open applications.

We found at least 61 similar applications in our research, all of which were from Brazil. The behavior that Coyote is displaying is comparable to what we previously described in our Tetrade blog post, which strongly confirms that Coyote is a Brazilian banking Trojan.

C2 Communication & Control

The Coyote banker gets in touch with the C2 when any application connected to banking is used and executed. After that, the C2 reacts by using the computer to perform a variety of tasks, such as keylogging and taking screenshots. The sections that follow will go over communication with the attacker server.

Using mutual authentication across SSL channels, the Trojan establishes communication with its command and control server. This suggests that the Trojan utilizes a certificate it has obtained from the attacker-controlled server to establish a connection.

The X509 library from.Net decrypts the resource in which the certificate is kept encrypted. The malware then sends the data it has gathered from the compromised computer and banking apps to the server after confirming that it is connected to the attacker. The data that is sent comprises

1. Machine Name
2. Randomly Generated GUID
3. Banking Application being Used

The attacker uses this data to send a response packet containing instructions. The attacker sends a string with a random delimiter to process these activities. The command type is then represented by the first entry in each list created from the string's positions.

It measures the length of the random string provided as the first parameter to select the preferred command. To put it another way, the size of the string is the only distinction between commands. To obtain user credentials, the Trojan may also ask for particular bank card passwords and generate a phishing overlay.