APT34 targets Jordan Government using new Saitama backdoor

On April 26th, we identified a suspicious email that targeted a government official from Jordan’s foreign ministry. The email contained a malicious Excel document that drops a new backdoor named Saitama. Following our investigation, we were able to attribute this attack to the known Iranian Actor APT34.

Also known as OilRig/COBALT GYPSY/IRN2/HELIX KITTEN, APT34 is an Iranian threat group that has targeted Middle Eastern countries and victims worldwide since at least 2014. The group is known to focus on the financial, governmental, energy, chemical, and telecommunication sectors.

In this blog post, we describe the attack flow and share details about the Saitama backdoor.

Malicious email file

The malicious email was sent to the victim via a Microsoft Outlook account with the subject “Confirmation Receive Document” with an Excel file called “Confirmation Receive Document.xls”. The sender pretends to be a person from the Government of Jordan by using its coat of arms as a signature.

Excel document

The Excel attachment contains a macro that performs malicious activities. The document has an image that tries to convince the victim to enable a macro.

After enabling the macro, the image is replaced with the Jordan government’s the coat of the arms:

The macro has been executed on WorkBook_Open(). Here are the main functionalities of this macro:

• Hides the current sheet and shows the new sheet that contains the coat of arms image.
• Calls the “eNotif’ function which is used to send a notification of each steps of macro execution to its server using the DNS protocol. To send a notification it builds the server domain for that step that contains the following parts: “qw” + identification of the step (in this step “zbabz”) + random number + domain name (joexpediagroup.com) = qwzbabz7055.joexpediagroup.com. Then it uses the following WMI query to get the IP address of the request: Select * From Win32_PingStatus Where Address = ‘” & p_sHostName & “‘” which performs the DNS communication the the created subdomain.
• Creates a TaskService object and Gets the task folder that contains the list of the current tasks
• Calls ENotif function
• Checks if there is a mouse connected to PC and if that is the case performs the following steps
  • Creates %APPDATA%/MicrosoftUpdate directory
  • Creates “Update.exe”, “Update.exe.config” and “Microsoft.Exchange.WenServices.dll”
  • Reads the content of the UserForm1.label1, UserForm2.label1 and UserForm3.label1 that are in base64 format, decodes them and finally writes them into the created files in the previous step
  • Calls a ENotif function for each writes function
• Checks the existence of the Update.exe file and if for some reason it has not been written to disk, it writes it using a technique that loads a DotNet assembly directly using mscorlib and Assembly.Load by manually accessing the VTable of the IUnknown. This technique was taken from Github (link). Even though, this technique was not used in this macro since the file was already written, the function name (“Test”) suggests that the threat actor is trying to implement this technique in future attacks.
• Finally, it calls the ENotif function.

• Defines a xml schema for a scheduled task and registers it using the RegisterTask function. The name of the scheduled task is MicrosoftUpdate and is used to make update.exe persistent.

Saitama Backdoor – A finite state machine

The dropped payload is a small backdoor that is written in .Net. It has the following interesting pdb path: E:\Saitama\Saitama.Agent\obj\Release\Saitama.Agent.pdb.

Saitama backdoor abuses the DNS protocol for its command and control communications. This is stealthier than other communication methods, such as HTTP. Also, the actor cleverly uses techniques such as compression and long random sleep times. They employed these tricks to disguise malicious traffic in between legitimate traffic.

Another element that we found interesting about this backdoor is the way that it is implemented. The whole flow of the program is defined explicitly as a finite-state machine, as shown in the Figure 7. In short, the machine will change its state depending on the command sent to every state. Graphically, the program flow can be seen as this:

The finite-machine state can be:

BEGIN

It is the initial state of the machine. It just accepts the start command that puts the machine into the ALIVE state.

ALIVE

This state fetches the C&C server, expecting to receive a command from the attackers. These servers are generated by using the PRNG algorithm that involves transformations like the Mersenne Twister. These transformations will generate subdomains of the hard coded domains in the Config class (Figure 8).

Figure 9 shows an example of the generated subdomain:

This state has two possible next stages. If the performed DNS request fails, the next stage is SLEEP. Otherwise, the next stage is RECEIVE.

SLEEP and SECOND SLEEP

These states put the backdoor in sleep mode. The amount of time that the program will sleep is determined by the previous stage. It is clear that one of the main motivations of the actor is to be as stealthy as possible. For example, unsuccessful DNS requests puts the backdoor in sleep mode for a time between 6 and 8 hours! There are different sleep times depending on the situations (values are expressed in milliseconds):

There is also a “Second Sleep” state that puts the program on sleep mode a different amount of time.

RECEIVE

This state is used to receiving commands from the C&C servers. Commands are sent using the IP address field that is returned by the DNS requests. Further details about the communication protocol are provided later in this report. In a nutshell, every DNS request is capable of receiving 4 bytes. The backdoor will concatenate responses, building buffers in that way. These buffers will contain the commands that the backdoor will execute.

DO (DoTask)

That state will execute commands received from the server. The backdoor has capabilities like executing remote pre-established commands, custom commands or dropping files. The communication supports compression, also. The following figure shows the list of possible commands that can be executed by the backdoor.

It is pretty shocking to see that even when attackers have the possibility of sending any command, they choose to add that predefined list in the backdoor in Base64 format. As we can see, some of them are common reconnaissance snippets, but some of them are not that common. In fact, some of the commands contain internal IPs and also internal domain names (like ise-posture.mofagov.gover.local). That shows that this malware was clearly targeted and also indicates that the actor has some previous knowledge about the internal infrastructure of the victim.

SEND – SEND AND RECEIVE

The Send state is used to send the results generated by commands to the actor’s server. In this case, the name of the subdomain will contain the data. As domain names are used to exfiltrate unknown amounts of data, attackers had to split this data in different buffers. Every buffer is then sent through a different DNS request. As it can be seen in the Figure 12, all the required information in order to reconstruct original data is sent to the attackers. The size of the buffer is only sent in the first packet.

Attribution

There are several indicators that suggest that this campaign has been operated by APT34.

• Maldoc similarity: The madoc used in this campaign shared some similarities with maldocs used in previous campaigns of this actor. More specifically similar to what was mentioned in CheckPoint’s report this maldoc registers a scheduled task that would launch the executable every X minutes, also it uses the same anti sandboxing technique (checking if there is a mouse connected to the PC or not). Finally, we see a similar pattern to beacon back to the attacker server and inform the attacker about the current stage of execution.
• Victims similarity: The group is known to target the government of Jordan and this is the case in this campaign.
• Payload similarity: DNS is the most common method used by APT34 for its C&C communications. The group is also known to use uncommon encodings such as Base32 and Base36 in its previous campaigns. The Saitama backdoor uses a similar Base32 encoding for sending data to the servers that is used by DNSpionage. Also, to build subdomains it uses Base32 encoding that is similar to what was reported by Mandiant.

Malwarebytes customers are protected from this attack via our Anti-Exploit layer.

IOCs

Maldoc:
Confirmation Receive Document.xls
26884f872f4fae13da21fa2a24c24e963ee1eb66da47e270246d6d9dc7204c2b
Saitama backdoor:
update.exe
e0872958b8d3824089e5e1cfab03d9d98d22b9bcb294463818d721380075a52d
C2s:
uber-asia.com
asiaworldremit.com
joexpediagroup.com