Just came across on a X post from Joe Desimone on some “FUD” malware. Out of curiosity, I took a quick look on the samples.
The sample is quite huge which is about ~135 MiB. It is an electron app packed with NSIS Installer. Since it is NSIS Installer, it can be decompressed by 7zip or any other archive tools.
The main file to look for is app.asar as this contains the electron app’s source code and builder files.
Inside the app folder, there is a lot of files. The manifest file package.json looks promising to start the investigation as it gives some clue on the initial entry of the application.
The variable main is the main entry point of the code, with is background.js in this case. If we try to look for background.js, nothing will be found, only Typescript background.ts found inside the electron folder as it hasn’t compiled into Javascript form yet via the command in transpile-electron.
The variable scripts it’s like a list of commands that can be execute during different development lifecycle. For example, create a Windows dev app by executing npm run dev:electron:win.
After looking at the package.json in app.asar, we can start looking at background.ts for any suspicious sign of malware.
Based on the code in background.ts, it will simply redirect to jumpUp() function.
Wonder where the invoke-start-install called? It can be found in the preload script.
The outMutation.js calls jumpUp() function that will eval a large base64 blob which contains the logic to retrieve the next stage URL which embedded in a Google Calendar page.
Reader can go to Source Code section below for the base64 decoded code.
The Google Calendar page looks like below.
By looking at the source code of the base64 decoded code, it will use regex to extract value from data-base-title, then base64 decode it to get the next stage URL for retrieving the next stage base64 encoded payload.
The base64 decoded value of data-base-title is http://82.197.67[.]174/maMdBrC3gKoJskqUA4gXsQ%3D%3D. Unfortunately, the URL content is base64 form of process.exit(0) that will just end the process for going further🥲. Probably the URL is request sensitive that will response with different content based on the user request header or threat actor just changed the content 🤔.
Believe that the payload is something similar with the unused code in _ex_load.js since both iv and key are used in both cases 🤔.
The code snippet of _ex_load.js can be found in the following section.
Development Artifacts
Upon dig deeper into the builder related files, there are more information can be found. In this case, crypto.js provides more insight on how the does source code generated with the inputs from .env file.
The base64 encoded string in the !!!LINK is the aes-256-cbc encoded partner ID.
Partner ID: 6PHM9GG3zOACOOY
Target URL: aHR0cDovLzgyLjE5Ny42Ny4xNzQvbWFNZEJyQzNnS29Kc2txVUE0Z1hzUSUzRCUzRA==From the transpile-electron command in package.json, node process will execute crypto.js followed with typescript compiling. The crypto.js will load the loadModule.js and replace all the placeholder in the code with some random strings then output into outMutation_clearComment.js and generate outMutation.js which is the code that leads to next stage payload.
Seems like the malware authors are from Russia, based on the comments in crypto.js file.
There is a remaining question on the index.node file, based on my understanding on Google search results, it seems like a Windows DLL binary, but it has been aes-128-cbc encoded. However, in this case, it might be a large base64 blob based on the reference in _ex_load.js. Seems like this is the alternative way to execute the base64 encoded command and they didn’t remove it somehow 🤔
Source Code
Credits to ChatGPT for replacing all the base64 strings in the Javascript code✌️(There is some error on those base64 decoded string)
References
Decompiling and repacking Electron Apps | by Cristian Deleon | Medium
