Trojan.Siggen28.53599

• sha1: 853d6a17f0a1a4035b52699a447eeb4ad1ca6cf7

Description

A malicious program for Windows written in C++. The main functionality of the trojan is to download and manage modules received from its C2 server.

Operating routine

The trojan has a number of basic and helper structs that are initialized at startup and stored as pointers in global variables.

Basic structs:

WinAPI wrapper

The trojan uses WinAPI system functions via a wrapper struct that contains a table of functions, library pointers, library load addresses, and an anti-debugging flag.

The table contains the following functions:

• Functions for working with WinAPI, i.e., for finding a function pointer and calling it
• Helper functions—the ad hoc implementation of the LoadLibrary and GetProcAddress calls
• The configuration of the input parameters for a range of functions

When launched, the trojan initializes its main struct. It does this by using a modified CRC32 algorithm to find library load addresses in the PEB_LDR_DATA system struct. The trojan uses two methods to access functions stored in the libraries:

• Ad hoc implementation of the LoadLibrary and GetProcAddress calls

The trojan has two functions that mimic the implementation of LoadLibrary and GetProcAddress. This method is used when the trojan needs access to an API contained in a library that has not yet been loaded into the process memory.

• Searching for libraries by their hashes in the PEB_LDR_DATA system struct

The trojan searches for a required library in the PEB_LDR_DATA struct, using the InMemoryOrderModuleList list, which contains pointers to all the libraries loaded into the process memory and their names. The library name is matched by comparing the hash value generated using the modified CRC32 algorithm with the requisite library name. Next, the required library function is found in the table of exported library functions, in which case the function names are hashed in the same way. The library name and function are read using the modified CRC32 algorithm.

Logger struct

This is a struct whose main purpose is to generate the application log. The log contains information about errors and the step currently being executed.

System information collector struct

The main purpose of this struct is to collect system information and send it to the C2 server.

C2 server communication struct

This struct ensures the interaction with the C2 server. It contains a struct for working with the winhttp.dll library and information about the control server: the port, IP address and routing table.

Module and configuration struct

The main function of this struct is to manage the operation of modules and their configurations. It contains vectors that describe the modules, their configuration, and auxiliary system information.

Manager struct

The main purpose of this struct is to control program operation and ensure interaction between other structs. It holds pointers to all the other primary structs: WinAPI wrapper, logger, communication, and configuration.

Helper structs:

• Structs for working with cryptography – SHA-1, SHA-256

• Structs for working with auxiliary libraries: bcrypt, winhttp

• Structs for storing various flags

Debugger evasion

When launched, the trojan also initializes 3 threads to evade debuggers:

Checking the debug registers

The trojan obtains the context of the parent thread and checks that the values of the Dr0–Dr7 registers are set to 0.

Checking for debugged environment

In the KUSER_SHARED_DATA structure, the trojan checks the first two bits in the KdDebuggerEnabled field; the value of these bits must be set to 0.

Using the NtQueryInformationProcess function, the trojan checks for the presence of a debugger by reading various parameters of the PROCESSINFOCLASS structure: ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, ProcessTlsInformation.

Checking for debugger drivers

The trojan scans the %WINDIR%\System32\drivers directory for files that indicate the presence of debugging software. It then calculates the filename hash, using the modified CRC32 algorithm, and compares the result to the blacklist hashes.

Checking for a copy of the trojan in the system

After initialization, the trojan attempts to create a mutex which is a Base64 SHA-1 encoded hash of the MachineGuid string value. If the attempt to capture the mutex fails, the line "Found another agent running. Exiting..." is written to the application log and the trojan is terminated.

Verifying keys and creating a handshake

The trojan checks for an existing handshake. This is done by accessing the key in the "Microsoft Software Key Storage Provider" CNG key storage, using the NCryptOpenKey function. The key name is a SHA-256 hash of the MachineGuid value. If such a key does not exist, the availability of the network connection is checked: if the connection is established, the trojan initiates the creation of the handshake:

• A copy of the RSA internal key from the “Microsoft Software Key Storage Provider” CNG key storage is created
• A key is received from the server
• This key is stored in the storage with a name corresponding to the SHA-256 hash of the MachineGuid value.

The trojan parses the incoming packet for a new C2 server address and port number. Once the handshake is established, the following system information is sent to the C2 server: CPU architecture, OS name, user interface type, installed application identifiers, disk information, user names, and locale.

Basic functions

The trojan performs the following actions:

• Loads and unloads modules
• Sends messages to the C2 server about its operation or errors
• Changes the configuration of modules
• Updates the trojan body, if necessary

Module structure and configuration

A module is a dynamic library that is projected into the memory and has the following exportable functions:

Start
Stop
Configure
GetID
GetStatus
SetStatus
GetStarted
GetHandler
Destroy
PushErrorCMR

The module identifier indicates its function, i.e., knowing the identifier, you can determine which tasks are sent by the C2 server.

JSON with module configuration

{
  "triggers": [
    {
      "schedule": "",
      "process": "",
      "repetitions": "",
      "sendCmr": {
        "name": "",
        "interval": ""
      }
    }
  ]
}

Module’s execution result

After the module completes its task, it generates a response

{
  "CommandModuleResponse": "",
  "requestId": "",
  "moduleId": "",
  "exitCode": "",
  "info": "Error" //this field is only shown if there was an error in the module’s operation; otherwise this field is missing.
}

Trojan update

While in operation, the trojan checks the availability of its update flag. If this flag is set, the trojan performs a series of system checks, and, based on the results, selects one of the two update strategies. If antivirus software is detected on the compromised PC, the trojan is updated through the loading of shellcode; otherwise, it is updated using the Inject module.

Checking for antivirus software

The trojan body contains a list of hashes of antivirus program names. When scanning for antivirus software, the trojan obtains a list of processes and calculates the hashes of running applications, which are compared to the following hardcoded list:

•	msmpeng 
•	mssense 
•	avastsvc
•	dwservice
•	avp
•	nortonsecurity
•	coreserviceshell
•	avguard
•	fshoster32
•	vsserv
•	mbam
•	adawareservice
•	avgsvc
•	wrsa

Shellcode for directory removal

Input arguments: directory name

Actions performed:

• Looks up the kernel32.dll library address in the PEB_LDR_DATA struct
• Gets the functions for the shellcode’s operation from the library export results, where the library name and function names are determined by their hashes
• Determines the path to the %LOCALAPPDATA%\EROCS\ directory
• Overwrites with zeros and deletes all the files in the specified directory
• Deletes the directory itself

Shellcode for restarting the trojan

Actions performed:

• Gets the list of processes, using the NtQuerySystemInformation function (the SystemProcessInformation parameter); checks that the UniqueProcessId field is equal to 0x434F5245
• Deletes the HKEY_CURRENT_USER\Software\Uninstall key

Self-deletion

The trojan also has a self-deletion function that is triggered when the “deadline” registry key, which is responsible for the trojan lifetime and is updated when a new command from the C2 server is received, is set to a specific value. The trojan also initiates the self-deletion procedure, using WinAPI if errors are detected during the above checks. In this case, it performs the following actions:

• Deletes its directory
• Deletes the handshake
• Deletes registry keys created while the trojan is in operation

Sending messages to the C2 server

The following User-Agent values are used by the trojan to send messages:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.3
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/53
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.3

All outgoing and incoming messages are encrypted using RSA.