Self Assessment

QWERTY INFORMATION STEALER

Published On : 2024-08-19
Share :
QWERTY INFORMATION STEALER

EXECUTIVE SUMMARY

At CYFIRMA, our commitment is to provide timely insights into prevalent threats and malicious tactics affecting both organizations and individuals. This report provides a comprehensive analysis of a recent malware identified as QWERTY Info Stealer, which was hosted on the domain mailservicess[.]com with a Linux-based VPS server, demonstrates sophisticated anti-debugging techniques and data exfiltration methods. Initial investigation reveals that it employs multiple anti-debugging strategies, by checking for a debugger presence using Windows API functions, engages in extensive data collection, downloads additional payloads to perform file indexing / exfiltration, and sends data to a Command and Control (C2) server via HTTP POST requests.

INTRODUCTION

The sample was retrieved from a publicly indexed web server with the domain mailservicess[.]com. The server, based in Frankfurt am Main (Germany) is identified as running a Linux-based virtual private server with limited services exposed. This report details the technical aspects of the malware, including its file characteristics, anti-debugging techniques, data collection methods, and interaction with the C2 server. The analysis reveals the malware’s sophisticated mechanisms for evading analysis and its capability to perform extensive data exfiltration operations. Based on the HTTP communications with the C2 server and the unique strings found in the samples, we have named this unknown stealer “Qwerty Info Stealer.”

KEY POINTS

  • The malware ‘QWERTY Stealer’ is hosted on the domain mailservicess[.]com.
  • It downloads from URL hxxps://mailservicess[.]com/res/data/i.exe.
  • It is hosted on a Linux-based VPS in Frankfurt, Germany.
  • The malware uses multiple anti-debugging techniques.
  • It creates directories to store collected data and telemetry.
  • It gathers system information and Internet Explorer data.
  • It downloads and executes additional payloads named in.exe and up.exe.
  • It indexes all files in a system and uploads them to the C2 server.
  • The malware uses the keyword ‘qwerty’ in HTTP calls during exfiltration.

ETLM ATTRIBUTION

The sample was hosted on an openly indexed web server with the domain mailservicess[.]com, which has an a record of 194[.]5[.]212[.]74. The sample was downloaded from the following URL: hxxps[:]//mailservicess[.]com/res/data/i.exe.
The IP address 194[.]5[.]212[.]74 is assigned to a Linux-based VPS server located in Frankfurt am Main, Germany: at the time of writing, only the SSH service is running on port 6579, and no other web service ports are available. The server is identified as running Ubuntu Linux 20.04, according to OSINT information.
Who is records show the registration details of this domain. The following details were used to register it:

These details indicate that the domain administrator is based in Kuala Lumpur, Malaysia, however this information may be forged.

ANALYSIS:

File Name i.exe
File Type PE64
Size 2.0MiB (2123776 Bytes)
SubSystem GUI
SHA256 369d8855d2531dce55d046735ff9a26ee4441f3f4509aad35f570c0a0b567c5d
Compiler TimeStamp 2024-06-26 23:21:14 UTC

This executable has a total of 10 sections defined in the PE header, (see figure 1) of these sections, 2 have executable permissions.

The sample employs anti-debugging techniques: upon execution, it checks whether a debugger is present on the system, and it uses the API call IsProcessorFeaturePresent() with the argument 0x17 to determine if the __fastfail option is available.

According to Microsoft documentation, the argument 0x17 corresponds to PF_FASTFAIL_AVAILABLE.

The IsProcessorFeaturePresent() function in the Windows API is used to determine if a specific processor feature is available on the current system. If this feature is not present, the sample terminates itself immediately.

The sample then calls the IsDebuggerPresent() Windows API to check if the process is being executed within a debugger (see figure 2).

After implementing the first two anti-debugging checks, the malware author employs a third technique to detect debuggers. The __CheckForDebuggerJustMyCode function – which is a part of the Windows API, but not widely documented or commonly used in standard applications – is utilized. This function is primarily intended to help developers to detect if their code is being run under a debugger, and it is likely used here to determine if the code is being executed in a debugging environment.
This technique is commonly used within malware to evade analysis and detection by security researchers and analysts (see figure 3).

After performing its anti-debugging checks, the sample begins collecting data for stealing. It creates two directories at C:\Users<USERNAME>\AppData\Roaming\TestLog\ and C:\Users\user\AppData\Roaming\Intel\ on the machine (see figure 4 &5).

Then it collects telemetry and system information by querying multiple API calls:
GetComputerNameA() Windows API retrieves the name of the computer, as used in the network or by the operating system (see figure 6).

The GetAdaptersInfo() function in the Windows API is used to retrieve information about the network adapters on a computer (see figure 7).

The GetVersionExA function in the Windows API retrieves information about the version of the operating system currently running on the computer (see figure 8).

Similarly, GetUserNameA is executed to get system username details (see figure 9).

The GetAdaptersInfo() function collects information about all available network interfaces and their assigned IP addresses. The sample then converts this network address information into a readable IP format using the j_inet_ntoa function (in Windows, j_inet_ntoa is used to convert an Internet Protocol (IP) address from its numeric format into a readable string format (see figure 10).

The sample then checks the value assigned to the environment variable “APPDATA” using the GetEnvironmentVariableA() API function (see figure 11).

Using the retrieved value of the “APPDATA” variable, the sample creates a text file at the path C:\Users<USERNAME>\AppData\Roaming\TestLog<COMPUTER_NAME>.txt. It then writes all the telemetry information collected from the API calls mentioned above into this file (see figures 12 and 13).

The sample then collects and captures Internet Explorer data by reading sensitive web browser files, as illustrated below.

It also accesses Internet browser history and cookies (see figure 15).

The sample then copies itself with the name “Systems.exe” into the directory C:\Users<USERNAME>\AppData\Roaming\Mozilla\ (see figures 16 and 17).

The sample then connects to its C2 URLs: hxxp[:]//mailservicess[.]com/res/data/in.exe and hxxp[:]//mailservicess[.]com/res/data/up.exe, and downloads two additional executables for further execution (see figures 18 and 19).

Below are the HTTP GET calls used to download in.exe and up.exe (see figures 20 and 21).

The downloaded file ‘in.exe’ is saved with the name “index.exe” in the directory C:\Users<USERNAME>\AppData\Roaming\intel\ (see figure 22).

 

The other downloaded file, ‘up.exe’, is saved with the name “upload.exe” in the directory C:\Users<USERNAME>\AppData\Roaming\intel\ (see figure 23).

The sample then executes both of the downloaded executables, “index.exe” and “upload.exe”, one by one (see figure 24).

File Name Index.exe
File Type PE64
Size 2.0MiB (2116096 Bytes)
SubSystem GUI
SHA256 e70f64a374e1784942c771940f07f08cdee78144f2135bf1665557d1fcee0f16
Compiler TimeStamp 2024-06-26 19:39:54 UTC
File Name Upload.exe
File Type PE64
Size 550.0KiB (563200 Bytes)
SubSystem GUI
SHA256 2d40e892e059850ba708f8092523efeede759ecd6e52d8cb7752462fcdb6f715
Compiler TimeStamp 2024-04-05 05:46:12 UTC

The index.exe file indexes all the files on the system, while the upload.exe file uploads these files to the C2 server hxxp[:]//mailservicess[.]com.
The index.exe file scans and indexes all files from all drives and directories, as shown below.

All the above indexed files are uploaded to a C2 server one by one using HTTP POST calls.
To send and exfiltrate a file from a system, it first reads the file and then send its binary content via an HTTP POST request (figures 29 and 30).

In the same manner, all files are exfiltrated to the C2 server.
The telemetry data that was fetched and collected at the start of execution is also sent to the C2 server (figure 31).

CONCLUSION

The analysis of the QWERTY info stealer malware sample highlights its anti-debugging tactics and extensive data exfiltration capabilities, such as the IsProcessorFeaturePresent(), IsDebuggerPresent() functions, and the lesser-known __CheckForDebuggerJustMyCode function. Its data collection mechanisms are thorough, encompassing system telemetry, browser data, and file indexing, and the malware’s exfiltration process – which involves downloading additional payloads and sending collected data to the C2 server via HTTP POST requests – underscores the significant threat posed by this sample. Continued vigilance and advanced detection strategies are essential to mitigate the risks associated with such sophisticated malware.