What’s new in this year’s Almanaq?

Almaq is a highly specific malware written for the .NET platform that targets two specific servers: a file system server running at 150.200.11.101 and a SQL database server running at 150.200.12.1\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 150.200.11.101, database table layouts and the connection string of 150.200.12.1 in order to attack the two servers. Almaq binaries can steal information from 150.200.11.101 and encrypt some of its files, they can also alter and query data from 150.200.12.1 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, azurewebsites.net and 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 150.200.11.101 and 150.200.12.1 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 adobereader, printer and 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 150.200.12.1, 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 150.200.11.101 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 150.200.11.101.

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.

Considering the http://servicesx.gearhostpreview[.]com/data.asmx, Almaq files can utilize the following operations:
Commands
ConfermScript
ConnectionString
ConnectionStringWell
ExecutedSelect
Files
LockList
Model
Response
Scripts
Selectlist
SendMail
Set
Settings
WellFiles
Saveimage

Operation Commands returns command line commands that are all infected computers supposed to run. Each command has a specific ID number.

The full list for http://servicesx.gearhostpreview[.]com/data.asmx:

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.

Operation 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 http://servicesx.gearhostpreview[.]com/data.asmx:
servicesx[.]gearhostpreview.com/Files/Dll.exe
servicesx[.]gearhostpreview.com/Files/Microsoft.Win32.TaskScheduler.dll
servicesx[.]gearhostpreview.com/Files/New Dll.exe
servicesx[.]gearhostpreview.com/Files/Newtonsoft.Json.dll
servicesx[.]gearhostpreview.com/Files/prenter.exe
servicesx[.]gearhostpreview.com/Files/Printer.exe
servicesx[.]gearhostpreview.com/Files/Printr.exe
servicesx[.]gearhostpreview.com/Files/Read me.bat
servicesx[.]gearhostpreview.com/Files/security.exe
servicesx[.]gearhostpreview.com/Files/Service.exe

Yet, for example, files
systemservicex[.]azurewebsites.net/Files/SearchFile.exe
adobereader[.]azurewebsites.net/Files/acrobat reader.exe
from already inactive C&Cs are not present there.

Operation Scripts returns two database scripts that Almaq files run in the SQL database 150.200.12.1\\MSSQLSERVER. These scripts alter and query the database. A connection string to this database can be obtained by operation ConnectionString.

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
Addscript
AddscriptForpayer
Confirm
EditScript
GetScripts
ReadScript
ScriptDelete
ScriptReset
ScriptUpdateState

Scripts are stored encrypted using AES-256.

Server communication

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:

Dll.exe
Microsoft.Win32.TaskScheduler.dll
New Dll.exe
Newtonsoft.Json.dll
prenter.exe
Printer.exe
Printr.exe
Read me.bat
security.exe
Service.exe
SearchFile.exe
acrobat reader.exe.

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
• wipers: security.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 150.200.11.101 and will be described later on.

Droppers

Files from this module are usually named after  common computer programs (sometimes misspelled) such as adobe reader, adobe, Printer, Prenter, Printr or 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 150.200.12.1 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 spoolsv.exe file.

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:\Users\<userName>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
C:\Program Files\Microsoft Visual studio
C:\ProgramData\Microsoft
C:\Program Files\Adobe

All downloaded Almaq files are added to the machine’s startup by modifying the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key.

Threads Database.Run and SelectClass.RunSelect execute scripts and commands, received by the C&C server, on the SQL database at 150.200.11.101. 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.Run() and 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 Service.exe.

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 Service.exe.

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.

The thread 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

The Service.exe file performs a DoS attack on the 150.200.12.1 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  http://servicesx.gearhostpreview[.]com/data.asmx:
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 Service.exe file.

Uploaders

Files fitting into this module are usually named Dll.exe, New Dll.exe, DllLiberary.exe, svchost.exe and SearchFile.exe. Their main function is to search for the AL_MASHREQ.exe file either on the victim’s computer or at 150.200.11.101. 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

C:\AL_MASHREQ\bin\AL_MASHREQ.exe
150.200.11.101\Backup\New folder\Update\bin\AL_MASHREQ.exe
or
150.200.11.101\Backup\New folder\Update\AL_MASHREQ.exe

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 Dll.exe file

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.

Wipers

Binaries from this module are called security.exe and their main purpose is to encrypt certain files at 150.200.11.101. Based on our analysis, the Almaq malware authors have deep, private knowledge of the  150.200.11.101 server at their disposal, as  they use hard-coded credentials to connect to 150.200.11.101 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
150.200.11.101\share\HMIS_Claims_Documents
150.200.11.101\share\HMIS_Members_Documents
150.200.11.101\share\HMIS_vendor_Documents
150.200.11.101\share\HMIS_Customer_Documents
150.200.11.101\share\CIS_patients_Documents
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 security.exe file.

Discussion

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 150.200.11.101 and the SQL database server running at 150.200.12.1\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 150.200.0.0–150.200.255.255 which includes both server IP addresses and is owned by the Missouri Western State University (https://myip.ms/info/whois/150.200.11.101). 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 150.200.11.101 and 150.200.12.1 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)

Samples

• https://github.com/avast/ioc/blob/master/Almaq/samples.sha256
• https://github.com/avast/ioc/blob/master/Almaq/samples.sha1
• https://github.com/avast/ioc/blob/master/Almaq/samples.md5

C&C

• https://github.com/avast/ioc/blob/master/Almaq/network.txt