Key Findings

Check Point Research discovered a new set of malware called Veaty and Spearal that was used in attacks against different Iraqi entities, including government networks.
The malware samples described in this report use various techniques, including a passive IIS backdoor, DNS tunneling, and C2 communication via compromised email accounts.
The passive IIS backdoor appears to be a newer variant of the backdoor reported by ESET as employed by the IIS Group 2 (also attributed by Symantec to GreenBug, aka APT34).
The malware has multiple ties to previously described APT34 malware families, such as Karkoff, Saitama, and IIS Group 2, operating in the same region. Those malware families are affiliated with tun (MOIS).

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 and 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.

Initial Infection

The newly discovered campaign’s initial infection 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, and 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 between March and May 2024. The initial infection likely started from some type of social engineering.

The installer used to deploy the Spearal malware bears the Iraqi General Secretariat of the Council of Ministers logo.

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 CurrentVersionRun for persistence. An example of the Powershell script used to deploy the next stage:

The next 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.

Spearal Config (decoded)

Spearal Backdoor

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 infection chain installs the Spereal malware.

The queries the Spereal malware sent below illustrate how data is transmitted to and from the C2 server.

Initial Authentication:Query: base32encode(“auth:;<username>”)

Response: “stc:;base32encode(<target_comm_id>)” – This provides the target_comm_id which is the victim identifier used in subsequent messages.

Requesting Commands:Query: base32encode(“cmd:;<target_comm_id>”)

Response: Contains one of these commands to execute.

3. Sending Command Results:

First Message (Command Result Start message):Query: base32encode(“crs:;<cmd_id>:;<num of chunks>”) – The maximum length for a chunk is based on the value chunk_len in the configuration (the default value is 30).Response: “ok”.Body Messages (Command Result Body message):Query: base32encode(“crb:;<cmd_id>:;<chunk_index>:;<chunk_value>”).Response (Result OK message): “rok:;<cmd_id>:;<chunk_index>” or “end”.

End Results (Command Result End message):

Query: base32encode(“cre:;<cmd_id>”).

Veaty Backdoor

The infection chain installing Veaty malware

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

The infection begins with disabling certificate verification. This process checks whether an SSL/TLS certificate is valid and trusted when establishing a secure connection to a server. It 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:

Veaty Configuration (decoded)

Communication Channel Initialization

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.

try_defaultcred – Tries to communicate without username and password. The malware tries to communicate with each domain in the following order:internal_domain field from the configuration fileexternal_domain field from the configuration file

the exchange server in the path on the compromised machine(https:///EWS/exchange.asmx)

try_hardcodedCreds – Uses the same list of servers, but the malware tries to communicate using credential values (username and password) from the “creds” key in the config file.
try_externalCreds – Tries to communicate using values from the “external_creds” key in the config file. The C2 server is based on a hardcoded value named mail_domain_external_known, which in our sample is equal to “mail.miicrosoft.com”.
try_trustedNetwork – Tries to communicate using values from the “trusted_networks_creds” key in the config file. The C2 server address is taken from a hardcoded value named mail_domain_external_trusted which in our case is also equal to “mail.miicrosoft.com”.

Command and Control Communication

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:

communicationFolder
receive_sign
placeForSignature – The value can be “subject”, “body” or “subjectorbody”.

The malware uses these values to search 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 a rule searches for emails with the string “PMO” in the subject field and moves them to the deletedItems folder.

The malware adds a new rule with this parameter if the rule doesn’t exist. 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, or “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(<ComputerName>:<UserDnsDomain>:<UserName>).

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.

Example of an Alive message

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: <command_id>;<command>.

Command types:

Download File – Commands that begin with the value “this is my file content” hardcoded in the malware. The malware gets a file path and base64-encoded content to write to the file, with content segments separated by ‘’.
Upload File – Commands that begin with the value “this is my required file path” hardcoded in the file. In this case, the malware gets a file path to read from and sends back its base64-encoded content to the C2.
Execute command – All other commands are executed directly using PowerShell.

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.

SSH Malware

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.

SSH tunneling malware config file.

Attribution

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:

Veaty malware uses techniques and variable names similar to those previously used by Karkoff malware. Both malware use email tunneling in the same way: searching for emails with a pre-configured subject (Dropbox in Karkoff, PMO in Veaty), extracting from these emails commands to execute, and then deleting the email. The implementation of these methods is also similar.

C2 emails in Karkoff. Source: https://mp.weixin.qq.com/s/o_EVjBVN2sQ1q7cl4rUXoQ

The Karkoff malware communicated through compromised email addresses belonging to Lebanese government entities, similar to Veaty, which used compromised mail accounts of Iraqi government entities.
Spearal malware uses techniques that resemble the ones used by Saitama malware: they both use base32-encoded commands passed through DNS tunneling. Saitama was used in an attack that targeted Jordanian government entities.
asiacall.net, a C2 domain associated with this campaign, bears similarities to domain name conventions used by Saitama malware.

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 previous Karkoff and Saitama attacks.

HTTP-Based backdoors

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]

There are four keys:

a: Specifies the action (e.g., udrr2r3) discussed below.
b: Encrypted shell command.
k: Session Key encrypted with an RSA Private Key.
f: Encrypted filename for download.

Supported commands:

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.

Evolution from IIS group2 and RGdoor

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=<Encrypted command>

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 command methods, 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.

Comparison between the two code samples

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

Evolution of IIS backdoors from RGDoor to CacheHTTP

HTTP Listener – listner

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 https://[REDACTED].gov.iq/owa/auth/login. Incoming GET requests with the parameter snmflwkejrhgsey will execute its value via CMD, sending back the response in HTML format.

HTTP Listener Malware

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

Conclusion

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.

Protections:

Harmony EndpointAPT.Win.OilRig.FAPT.Win.OilRig.WA.G

APT.Win.OilRig.H

Threat Emulation

APT.Wins.Oilrig.ta.B/C/D/E

ABBackdoor.WIN32.CacheHttp.A/B/C

Backdoor.WIN32.Spearal.A/B/C/D/E/F

IOCs

The post Targeted Iranian Attacks Against Iraqi Government Infrastructure appeared first on Check Point Research.

Article Link: Targeted Iranian Attacks Against Iraqi Government Infrastructure – Check Point Research

1 post – 1 participant

Read full topic

​Key Findings

Check Point Research discovered a new set of malware called Veaty and Spearal that was used in attacks against different Iraqi entities, including government networks.
The malware samples described in this report use various techniques, including a passive IIS backdoor, DNS tunneling, and C2 communication via compromised email accounts.
The passive IIS backdoor appears to be a newer variant of the backdoor reported by ESET as employed by the IIS Group 2 (also attributed by Symantec to GreenBug, aka APT34).
The malware has multiple ties to previously described APT34 malware families, such as Karkoff, Saitama, and IIS Group 2, operating in the same region. Those malware families are affiliated with tun (MOIS).

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 and 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.
Initial Infection
The newly discovered campaign’s initial infection 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, and 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 between March and May 2024. The initial infection likely started from some type of social engineering.

The installer used to deploy the Spearal malware bears the Iraqi General Secretariat of the Council of Ministers logo.
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 CurrentVersionRun for persistence. An example of the Powershell script used to deploy the next stage:

The next 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.

Spearal Config (decoded)
Spearal Backdoor
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 infection chain installs the Spereal malware.
The queries the Spereal malware sent below illustrate how data is transmitted to and from the C2 server.

Initial Authentication:Query: base32encode(“auth:;<username>”)

Response: “stc:;base32encode(<target_comm_id>)” – This provides the target_comm_id which is the victim identifier used in subsequent messages.

Requesting Commands:Query: base32encode(“cmd:;<target_comm_id>”)

Response: Contains one of these commands to execute.

3. Sending Command Results:First Message (Command Result Start message):Query: base32encode(“crs:;<cmd_id>:;<num of chunks>”) – The maximum length for a chunk is based on the value chunk_len in the configuration (the default value is 30).Response: “ok”.Body Messages (Command Result Body message):Query: base32encode(“crb:;<cmd_id>:;<chunk_index>:;<chunk_value>”).Response (Result OK message): “rok:;<cmd_id>:;<chunk_index>” or “end”.

End Results (Command Result End message):

Query: base32encode(“cre:;<cmd_id>”).

Veaty Backdoor

The infection chain installing Veaty malware
Veaty is a .NET backdoor that utilizes emails for C2 communications. It can upload and download files and execute commands. The malware leverages compromised email accounts at the gov-iq.net domain to execute its commands in the sample we analyzed.
The infection begins with disabling certificate verification. This process checks whether an SSL/TLS certificate is valid and trusted when establishing a secure connection to a server. It 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:

Veaty Configuration (decoded)
Communication Channel Initialization
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.

try_defaultcred – Tries to communicate without username and password. The malware tries to communicate with each domain in the following order:internal_domain field from the configuration fileexternal_domain field from the configuration file

the exchange server in the path on the compromised machine(https:///EWS/exchange.asmx)

try_hardcodedCreds – Uses the same list of servers, but the malware tries to communicate using credential values (username and password) from the “creds” key in the config file.
try_externalCreds – Tries to communicate using values from the “external_creds” key in the config file. The C2 server is based on a hardcoded value named mail_domain_external_known, which in our sample is equal to “mail.miicrosoft.com”.
try_trustedNetwork – Tries to communicate using values from the “trusted_networks_creds” key in the config file. The C2 server address is taken from a hardcoded value named mail_domain_external_trusted which in our case is also equal to “mail.miicrosoft.com”.

Command and Control Communication
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:

communicationFolder
receive_sign
placeForSignature – The value can be “subject”, “body” or “subjectorbody”.

The malware uses these values to search 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 a rule searches for emails with the string “PMO” in the subject field and moves them to the deletedItems folder.
The malware adds a new rule with this parameter if the rule doesn’t exist. 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, or “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(<ComputerName>:<UserDnsDomain>:<UserName>).
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.

Example of an Alive message
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: <command_id>;<command>.
Command types:

Download File – Commands that begin with the value “this is my file content” hardcoded in the malware. The malware gets a file path and base64-encoded content to write to the file, with content segments separated by ‘’.
Upload File – Commands that begin with the value “this is my required file path” hardcoded in the file. In this case, the malware gets a file path to read from and sends back its base64-encoded content to the C2.
Execute command – All other commands are executed directly using PowerShell.

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.
SSH Malware
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.

SSH tunneling malware config file.
Attribution
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:

Veaty malware uses techniques and variable names similar to those previously used by Karkoff malware. Both malware use email tunneling in the same way: searching for emails with a pre-configured subject (Dropbox in Karkoff, PMO in Veaty), extracting from these emails commands to execute, and then deleting the email. The implementation of these methods is also similar.

C2 emails in Karkoff. Source: https://mp.weixin.qq.com/s/o_EVjBVN2sQ1q7cl4rUXoQ

The Karkoff malware communicated through compromised email addresses belonging to Lebanese government entities, similar to Veaty, which used compromised mail accounts of Iraqi government entities.
Spearal malware uses techniques that resemble the ones used by Saitama malware: they both use base32-encoded commands passed through DNS tunneling. Saitama was used in an attack that targeted Jordanian government entities.
asiacall.net, a C2 domain associated with this campaign, bears similarities to domain name conventions used by Saitama malware.

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 previous Karkoff and Saitama attacks.
HTTP-Based backdoors
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]
There are four keys:

a: Specifies the action (e.g., u, d, r, r2, r3) discussed below.
b: Encrypted shell command.
k: Session Key encrypted with an RSA Private Key.
f: Encrypted filename for download.

Supported commands:

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.
Evolution from IIS group2 and RGdoor
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=<Encrypted command>
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 command methods, 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.

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

Evolution of IIS backdoors from RGDoor to CacheHTTP
HTTP Listener – listner
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 https://[REDACTED].gov.iq/owa/auth/login. Incoming GET requests with the parameter snmflwkejrhgsey will execute its value via CMD, sending back the response in HTML format.

HTTP Listener Malware
Despite its simplicity, this malware once again highlights the threat actor’s inclination towards passive backdoors.
Conclusion
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.
Protections:

Harmony EndpointAPT.Win.OilRig.FAPT.Win.OilRig.WA.G

APT.Win.OilRig.H

Threat Emulation

APT.Wins.Oilrig.ta.B/C/D/E

ABBackdoor.WIN32.CacheHttp.A/B/C

Backdoor.WIN32.Spearal.A/B/C/D/E/F

IOCs

The post Targeted Iranian Attacks Against Iraqi Government Infrastructure appeared first on Check Point Research.
Article Link: Targeted Iranian Attacks Against Iraqi Government Infrastructure – Check Point Research
1 post – 1 participant
Read full topic