Iranian Malware Attacks Iraqi Government

Check Point Research (CPR) has been closely monitoring a campaign targeting the Iraqi government over the past few months. This campaign features a custom toolset and infrastructure for specific targets and uses a combination of techniques commonly associated with Iranian threat actors operating in the region.

The toolset used in this targeted campaign employs unique Command and Control (C2) mechanisms, including a custom DNS tunneling protocol and a tailor-made email based C2 channel. The C2 channel uses compromised email accounts within the targeted organization, indicating that the threat actor successfully infiltrated the victim’s networks.

Using such distinctive C2 mechanisms, along with other attack-related artifacts such as malicious IIS modules, suggests possible connections to APT34, an Iranian MOIS-affiliated group. The malware families and methodology employed overlap with Karkoff, Saitama, and IIS Group2 clusters, all of which have ties to APT34.

The initial infection for the newly discovered campaign is kicked off by a series of files that use double extensions to masquerade as document attachments. Examples of the file names include Avamer.pdf.exe , Protocol.pdf.exe , IraqiDoc.docx.rar . We also observed an infection that starts with an installer called ncms_demo.msi . All these files were uploaded to VirusTotal (VT) from Iraq in the months of March-May 2024. The initial infection likely started from some type of social engineering.

These files triggered the execution of PowerShell or Pyinstaller scripts which dropped two additional files: the malware executable (EXE) file and its corresponding configuration. Notably, the scripts manipulated file write and access times, and added entries to the Windows registry under \CurrentVersion\Run for persistence. An example of the Powershell script used to deploy the stage:

The stage introduces one of two new malware families: Veaty or Spearal and their configurations. Both configuration files are structured as XML files with base64-encoded keys and values.

The Spearal malware is a .NET backdoor that utilizes DNS tunneling for communication. The Command and Control (C2) server is stored as srvip in the configuration file, and the malware sends TXT queries to this server.

The data transferred between the malware and the C2 server is encoded in the subdomains of DNS queries using a custom Base32 scheme. The domain used is either specified in the malware’s configuration domn field or defaults to iqwebservice[.]com .

The queries sent by the Spereal malware are detailed below, illustrating how data is transmitted to and from the C2 server.

Veaty is a .NET backdoor that utilizes emails for C2 communications. It can upload and download files and execute commands. In the sample we analyzed, the malware leverages compromised email accounts at the gov-iq.net domain to execute its commands.

The infection begins with disabling certificate verification. This is the process that checks whether an SSL/TLS certificate is valid and trusted when establishing a secure connection to a server and allows the malware to communicate with the Exchange server (its C2) without being detected by certificate-based security measures.

The malware uses information from its configuration file in various aspects of communication with its C2 server:

The malware determines which server to use and how to communicate with the server based on different hardcoded values. The malware has 4 flags (listed below) and attempts to communicate using each flag with a value of “True” until the communication with the exchange server succeeds.

The flags are used in the order in which they appear.

Veaty uses targeted mailboxes as its means of C2 communication. To prepare those mailboxes as C2 servers, it initializes a new rule so all its commands and responses will be moved to a relevant folder. Veaty has 3 values it uses to organize those emails:

The malware uses these values to for a rule containing the receive_sign string in the placeForSignature field, with the target folder specified by the communicationFolder value. In this specific instance, it checks if there is a rule searching for emails with the string “PMO” in the subject field and moves them to the deletedItems folder.

If the rule doesn’t exist, the malware adds a new rule with this parameter. The rule’s name is taken from the inboxRuleName hardcoded field, which in our case is “ MicosoftDefaultRules ”. As a result, any email with the predefined string in the subject will be moved to the deletedItems folder. This setup helps the attackers use those mailboxes as C2 channels but reduces the chance of being discovered by the account holder.

Veaty has two types of messages: Alive messages, otherwise referred to as “HeartBeat” messages, and Command messages.

Alive messages are dispatched as emails in the following format:

Subject: alive_msg_subj hardcoded value

Body: ” alive_msg_body ” + “ ID: ” + base64( : : ).

The recipient for Alive messages is based on the alive_mail value in the configuration file, and the message is sent at intervals (in minutes) corresponding to the value of al_time from the configuration file.

Command messages that match the rule established by the malware described above are searched for in the C2 mailbox. The command itself can be in the “ attachment ” (which was used in this specific campaign) or “ body ” of the mail, based on the hardcoded value ItemPlace . The commands are AES-encrypted with the enc_key value from the configuration file and base64-encoded. The commands are in the following format: ; .

The results are sent to the sender of the command mail and encrypted similarly. The format of the results email is also based on ItemPlace and the placeForSignature values:

The malware also contains several functions and variables it doesn’t use, which might indicate that it is based on different code and that the authors left in some extraneous data.

Analysis of the threat actors’ infrastructure led to the discovery of a similarly formed XML config file, likely used by a third backdoor to facilitate SSH tunneling. The IP address mentioned in the configs, 37.1.213[.]152 , is associated with the domain mofaiq[.]com , pointing to the same targeting of Iraqi government entities.

The Veaty and Spearal Tactics, Techniques and Procedures (TTPs) are very similar to two other malware families, Karkoff and Saitama, which are attributed to the same APT34 actor.

TTP and Code overlaps:

Using similar tools, techniques, and infrastructure against targets from the same geographical region leads us to conclude that this operation is carried out by an actor with a similar nexus to those who carried out Karkoff and Saitama attacks.

While investigating the previously mentioned samples, we encountered an intriguing IIS module backdoor named CacheHttp.dll that likely targeted the same organizations in Iraq. This module represents a newer iteration of malware that was previously attributed to IIS Group 2 and GreenBug.

The backdoor listens for OnGlobalPreBeginRequest events within the IIS server and executes its main functionality when these events occur.

The execution process begins by checking if the Cookie header is present in incoming HTTP requests and reads until the ; sign. The main parameter is F=0/1 which indicates whether the backdoor initializes its command configuration ( F=1 ) or runs the commands based on this configuration ( F=0 ).

If F=1, the configuration parameters are included in the Cookie header after the , character as a series of key-value pairs in the following format: Cookie: F=1,a=[u/d/r/r2/r3]&b=[Shell_Command]&k=[Session_Key]&f=[File]

The ‘ b ’ and ‘ f ’ values are encrypted with AES-CBC using the ‘ k ’ value and base64-encoded. The ‘k’ value is encrypted with an RSA private key that the attacker possesses, and the public key for this RSA private key is hardcoded inside the file.

The communication from the IIS backdoor to the C2 is encrypted in a similar way. A random AES-CBC key is generated and used to encrypt the data. The key itself is then encrypted with a public RSA key hardcoded in the file in which the attackers have the private key and then sent together with the data to the C2 server.

CacheHttp.dll represents an evolved version of the IIS Group2 backdoor. While its core functionality remains similar, it introduces two new additional methods for command execution: r2 and r3 .

Notably, the communication flow has undergone a significant change. Unlike the Group2 variant, which communicates via the HTTP body, CacheHttp.dll now communicates through the Cookie field. This shift aligns with the communication technique observed in the older RGDoor, another IIS backdoor attributed to APT34. In RGDoor, the C2 communication format is:

Cookie: RGSESSIONID=

Another interesting sample , uploaded to VT from Pakistan in February 2023, represents a straightforward IIS backdoor with minimal functionality. Specifically, it offers four distinct methods to execute commands. Notably, this sample’s communication method shares similarities with CacheHttp . Commands are transmitted within the Cookie field in this format:

Cookie:_sessionsID=hex(value),c=?,t=?,p=[1/2/3/4]

The Pakistani sample utilizes four distinct methods for executing commands, suggesting a potential connection to CacheHttp, which employs three command execution methods (r, r2, r3). The code and implementation techniques show similarities between the two backdoors.

In addition, the close relationship between APT34 and Greenbug, and the overlapping TTPs and targets in the Middle East, suggests that all these tools, CacheHttp, IISGroup 2, and RGDoor, might be variants of the same tool.

listner is another passive backdoor uploaded to VT in the same context as the previously described malware. This tool is a basic .NET-based HTTP listener, registered to handle incoming HTTP requests to the URL . Incoming GET requests with the parameter snmflwkejrhgsey will execute its value via CMD, sending back the response in HTML format.

Despite its simplicity, this malware once again highlights the threat actor’s inclination towards passive backdoors.

This campaign against Iraqi government infrastructure highlights the sustained and focused efforts of Iranian threat actors operating in the region. The custom toolset and dedicated infrastructure observed in this operation are similar to techniques commonly associated with APT34, an Iranian MOIS-affiliated threat actor.

The deployment of a custom DNS tunneling protocol and an email-based C2 channel leveraging compromised accounts highlights the deliberate effort by Iranian actors to develop and maintain specialized Command and Control mechanisms. This distinctive blend of straightforward tools, written in .NET, combined with sophisticated C2 infrastructure, is common among similar Iranian threat actors.

The discovery of the Veaty and Spearal malware families and the presence of a passive IIS backdoor aligns this campaign with previously identified activity clusters like Karkoff, Saitama, and IISGroup2. These artifacts further solidify the link between this operation and APT34’s known tactics, techniques, and procedures.