Almaq is a highly specific malware written for the .NET platform that targets two specific servers: a file system server running at
18.104.22.168 and a SQL database server running at
22.214.171.124\MSSQLSERVER. Unfortunately, we were unable to resolve the two IP addresses, which makes it more difficult for us to make assumptions about the targeted servers, however, we believe they could be part of a private network or use some sort of white-listing access control mechanism. This is based on our analysis of Almaq binaries and is further described towards the end of the analysis.
Our assumption is that the Almaq malware authors spread malicious binaries on the internet, hoping to infect other machines and use them to attack both of the aforementioned servers, to alter, steal and destroy data contained on them. It is possible that more than 100 computers have been infected, so far. Almaq itself consists of a number of different files and several C&C servers, all working together to attack the aforementioned servers from already infected machines. While the C&C servers mainly distribute Almaq files and commands to infected machines, the Almaq binaries abuse the knowledge of internal directory structures and the credentials of 126.96.36.199, database table layouts and the connection string of 188.8.131.52 in order to attack the two servers. Almaq binaries can steal information from 184.108.40.206 and encrypt some of its files, they can also alter and query data from 220.127.116.11 and possibly cause a denial of service for long periods of time.
Almaq’s C&C servers are hosted on public cloud computing platforms, specifically,
gearhost.com. In addition to distributing Almaq files and commands to the infected machines, the C&C servers are also used to store stolen data, both from the infected computers and from the targeted servers, and accept various messages from the infected machines.
Almaq consists of several executable and library files with different functionalities that work together in order to achieve persistence on victims’ computers and from them attack the 18.104.22.168 and 22.214.171.124 servers. Generally, an Almaq file, which has been executed on the victim’s machine, downloads other Almaq binaries from a C&C server and executes them on the victim’s machine. The executable files then keep attacking the aforementioned servers from the victim’s machine. Almaq uses deceptive file names such as
svchost for its malicious binaries.
Splitting Almaq into modules
Based on major behavioral characteristics, most Almaq files can be split into three modules, which could be labeled as droppers, uploaders and wipers. Binaries from the first module typically download all other Almaq files from its C&C servers and setup execution on the victim’s machine. Binaries from this module can also attack the server running at 126.96.36.199, set other Almaq files to periodically execute on the victim’s computer and even destroy data on the infected computer.
The second module consists of files that share characteristics of an uploader. The binaries in this module search for a specific file called
AL_MASHREQ.exe in hard-coded paths at 188.8.131.52 or on the victim’s machine in
C:\ drive. If this file is found, it is (or only the path to it) uploaded to a C&C server. Unfortunately, we were unable to track this file or find it on any of Almaq’s C&C servers. The file could bring more light to Almaq and help us answer questions around Almaq’s purpose.
The last module consists of files that characteristically function like a wiper (malware that irreversibly destroys files without any notice or potential file recovery option). The binaries in this module use the AES-256 cipher to encrypt all files in hard-coded directories stored on 184.108.40.206.
Almaq is a highly specific malware that exploits deep knowledge of two systems’ configuration and their structures in order to alter, steal and destroy data contained on them. However, since we were unable to track the
AL_MASHREQ.exe file and as some of Almaq’s functionalities seem to be a bit odd and out of context, we wonder whether Almaq was developed with the intention to be a serious malware.
C&C and communication
As mentioned before, Almaq incorporates C&C servers hosted on public cloud computing platforms. Almaq’s C&C servers can be divided into two categories: servers that allow file, command and database commands to download (to follow Almaq naming convention, we will call database commands scripts) and servers that allow script manipulation. Servers communicate with each other via Simple Object Access Protocol (SOAP) and their supported operations are described by Web Service Description Language (WSDL).
First category C&C
We were able to track three servers that allow file, command and script download. One is still active and the remaining two are already inactive:
After connecting to the servers, a full list of supported operations that Almaq files can utilize is downloaded. These operations provide, for example, command line commands, a connection string, select commands and scripts to the SQL database and files to download.
http://servicesx.gearhostpreview[.]com/data.asmx, Almaq files can utilize the following operations:
Commands returns command line commands that are all infected computers supposed to run. Each command has a specific ID number.
The full list for
It can be seen that commands 23 to 26 search for the
AL_MASHREQ.exe file about which we will talk further in the text.
Files contains URLs to specific Almaq files that are supposed to be downloaded to the victim’s computer and then executed. The list of obtained Almaq files differs based on the C&C server.
The full list from
Yet, for example, files
from already inactive C&Cs are not present there.
Scripts returns two database scripts that Almaq files run in the SQL database
220.127.116.11\\MSSQLSERVER. These scripts alter and query the database. A connection string to this database can be obtained by operation
Number of infected machines
We believe that it is possible to obtain the number of infected machines from the operation
Settings. The operation
Settings returns an information record about an infected machine, giving it a name. This record contains, among other things, the infected machine’s name and its ID. Almaq uses the .NET
Environment.MachineName property to give a name to an infected machine, however, if a new name that does not have a record is provided, the operation
Settings creates a new record for this name with a new sequential ID number. Given this, we were able to create a machine which we named machine_name and received a new sequential ID of 190. However, since it is very simple to create more machines like this machine_name_1, machine_name_2, etc. and practically anyone could do that, the number 190 does not really give any relevant information about the number of infected machines.
Second category C&C
We were able to track a server that allows script (database commands) manipulation
Supported operations are
Scripts are stored encrypted using AES-256.
Communication between these two server categories is mediated by the
AlMashreqService.dll file. It is a .NET file that contains specifications for all supported operations from the first-category servers and it also handles script decryption from second-category servers. As mentioned before, scripts are stored encrypted, however, the same hard-coded AES-256 encryption key and hard-coded IV is used for all the scripts.
Different Almaq module types
Most Almaq files can be categorized into three modules which can be labeled as droppers, uploaders and wipers. These files can be obtained from C&C servers by operation
Files, where each C&C server returns a slightly different list of Almaq files.
The list of all binaries mentioned above are:
To split this list into the main modules, we get:
droppers: prenter.exe, Printer.exe, Printr.exe, acrobat reader.exe
uploaders: Dll.exe, New Dll.exe, SearchFile.exe
The binaries Microsoft.Win32.TaskScheduler.dll and Newtonsoft.Json.dll are valid Microsoft libraries that Almaq uses along its process. File
Service.exe denies the service of the SQL database at 18.104.22.168 and will be described later on.
Files from this module are usually named after common computer programs (sometimes misspelled) such as
spoolsv to disguise their malicious behavior. Their main purpose is to download and execute Almaq binaries from C&C servers, however, they can also set up some Almaq files to periodically execute, alter and query the 22.214.171.124 SQL database, run aforementioned command line commands and delete files on the victim’s computer. Each of those functionalities is handled by a different thread.
The code snippet below illustrates multiple threads in the
Main() function of a
The first thread
@object.DownloadFiles handles the download of other Almaq binaries. Based on the analysis of Almaq binaries, we observed that downloaded files are, for most of the samples, saved to the current folder and to the
C:\ProgramData\Comms folder on the victim’s computer. However, for some samples, they can also be saved to the following folders:
C:\ProgramData\Microsoft Visual studio
C:\Program Files\Microsoft Visual studio
All downloaded Almaq files are added to the machine’s startup by modifying the
SelectClass.RunSelect execute scripts and commands, received by the C&C server, on the SQL database at 126.96.36.199. We were able to obtain some scripts from C&C servers, however, it is difficult to make assumptions about their purpose without deeper knowledge of Almaq’s attack context.
One of the last threads, the
Program.RunApp thread, searches the
C:\ProgramData\Comms\ folder for a file with the same name as the running binary and, if found, it executes it up to two to four times.
The last two functions, the
SchedulerClass.RunService() setup some Almaq binaries to periodically execute. The
SchedulerClass.Run() sets up a binary with the same name as the running binary and the
SchedulerClass.RunService() sets up a binary called
The execute is set into the
C:\ProgramData\Comms\ folder and triggered daily with 15 minute repetition intervals.
The code snippet below illustrates the
RunService() function which is responsible for the periodic execution of the binary
Some Almaq binaries also include an
@object.Start thread which attempts to connect to a C&C server by resolving the
alhussienweb.ddns[.]net URL. We were able to obtain two resolved IP addresses – which could possibly be the attackers IP addresses, provided by telecomegypt (https://te.eg/wps/portal/te/), a telecommunications company in Egypt.
|IP||Date resolved||IP location|
|2019-04-30||Egypt Al Jizah Te Data|
|2019-04-27||Egypt Al Jizah Te Data|
FormatingClass.Format can be also part of some Almaq binaries. Its mere functionality is to delete all files in all directories on the victim’s computer, confusing us a bit, since it does not fit into the overall Almaq’s workflow.
Since Almaq files from this module are set up to execute many other Almaq binaries, the obvious question is whether victims notice something unusual when using their computer. Almaq does not try to hide its actions and it can be detected pretty easily for example via Process Explorer.
The following screenshot was taken after executing an Almaq file called
Printr.exe. All shown processes are malicious Almaq processes
Users may also become suspicious when Almaq binaries run into an execution problem. For example, the process called
security.exe has a description containing a typing error
SheardFolder, hence if it runs into an execution problem, an alert like the pop up below, indicates that something wrong is going on.
Service.exe file performs a DoS attack on the 188.8.131.52 SQL database by running multiple SQL commands within isolated transactions including 15 minute sleeps. The SQL commands can be obtained by the
LockList operation from a C&C server.
A full list of commands from
update web_payers set state=0
update top(10) sa_customer set stopped=isnull(Null,stopped)
update top(10) st_vendor_contracts set last_update_by=isnull(Null,last_update_by)
update top(10) st_vendor set v_latitude=isnull(Null,v_latitude)
update top(10) company_plan_items set st_class=isnull(Null,st_class)
update top(10) plan_members set st_class=isnull(Null,st_class)
update top(10) st_employee set mob_push_flag=0
Even though these commands do not destroy the data in the database, their repetitive execution within isolated transactions causes a DoS of the database.
Each command is executed within a transaction with
IsolationLevel.Serializable, which is an isolation level that prevents other users from updating or inserting rows into the dataset until the transaction is completed. Within this transaction there is a 15 minute Sleep(). After the Sleep() terminates, the entire thread sleeps for 15 minutes and then runs again, making the database repeatedly out of service.
The code snippet below illustrates the main functionality of a
Files fitting into this module are usually named
SearchFile.exe. Their main function is to search for the
AL_MASHREQ.exe file either on the victim’s computer or at 184.108.40.206. After and if this file is found, the behavior of the Dll files (plus svchost) and SearchFile differs. Dll and svchost binaries upload the file to a C&C server, however, SearchFile binaries only upload its path to a C&C server. Despite the cooperation between the two Almaq file types appearing logical, we have not found any indications that the stored path from SearchFile would be utilized by the Dll and svchost files in any way.
In more detail,
Dll files and
svchost search for the
AL_MASHREQ.exe file at the following paths
and, if found, upload it to a C&C server under victim’s GUID (derived from .NET API Guid.NewGuid()).
The code snippet below illustrates the
Main() function of a
SearchFile searches entire
C:\ drive on the victim’s computer for all files matching the “
*MASHREQ.exe” pattern and, if found, sends a message with a path to the file to a C&C server.
Binaries from this module are called
security.exe and their main purpose is to encrypt certain files at 220.127.116.11. Based on our analysis, the Almaq malware authors have deep, private knowledge of the 18.104.22.168 server at their disposal, as they use hard-coded credentials to connect to 22.214.171.124 and search for files to encrypt in specific directories.
The code snippet below shows the
Main() function of a
security.exe Almaq file.
Almaq encrypts all files that were created no longer than three years ago from the directories
with AES-256. The encryption key is derived from .NET API Guid.NewGuid() uniquely for each file and is not stored or sent anywhere.
The code snippet below illustrates the main functionality of a
As previously mentioned, Almaq consists of many binaries with different functionalities, all working together to achieve persistence and attack the file system server running at
126.96.36.199 and the SQL database server running at
188.8.131.52\MSSQLSERVER. Even though the behavior of Almaq’s files is rather straightforward, the context of the Almaq attack is not completely clear. The attackers have the credentials needed to access both servers at their disposal, which begs the question: Why distribute Almaq binaries if the attackers could just attack both servers themselves. This brought us to the aforementioned idea of both servers having a white-listing access control mechanism that excludes the attackers, hence the attackers spreading Almaq binaries are hoping to infect a white-listed computer.
Another scenario takes into account the public IP range
184.108.40.206 which includes both server IP addresses and is owned by the Missouri Western State University (https://myip.ms/info/whois/220.127.116.11). Taking this into consideration, Almaq could be an attack targeting the Missouri Western State University. However, this seems unlikely, since the possible attacker’s IP addresses are located in Egypt and registered at telecomegypt (https://te.eg/wps/portal/te/).
Yet another scenario could be that both attacked IP addresses are not meant as public ones but are part of some internal network to which the attackers do not have access to. Since both IP addresses
18.104.22.168 seem to be a bit too beautiful to be randomly generated (in layman’s terms, many numbers are divisible by 10), we suppose both were human hard-coded. This would explain why addresses from the public IP range are used in a private network, since the standard and expected solution is to use IP addresses from the private range in a private network. An example of such private network could be a private network that is part of a company and an attacker could be a former employee who knows the credentials, yet cannot access the network anymore.
Indicators of Compromise (IoC)
|Associated FTP servers|