Threat researchers at Fortinet Labs have spotted a novel attack attributed to the Iranian hacking group known as APT34 group or Oilrig, who targeted a Jordanian diplomat with custom-crafted tools. Like many of these attacks, the email contained a malicious attachment. However, the attached threat was not a garden-variety malware. Instead, it had the capabilities and techniques usually associated with advanced persistent threats.
Spearphishing Email
This spearphishing attack targeted a Jordanian diplomat, with the sender pretending to be a colleague from the IT department of the same governmental organization.
The email carried a malicious Excel attachment that contained VBA macro code that executes to create three files, a malicious executable, a configuration file, and a signed and clean DLL.
Another unusual finding concerns two anti-analysis mechanisms implemented in the macro: the toggling of sheet visibility in the spreadsheet and the other a check for the existence of a mouse, which may not be present on malware analysis sandbox services.
Malicious Excel File
In most attacks involving Excel, no hidden sheets are used. And in those cases where hidden sheets are used, the hidden sheet typically holds the malicious code. In this attack, however, the visibility of two sheets is quickly switched as soon as the workbook is opened.
One possible reason for this may be an anti-emulation technique. Emulators (such as the freely available ViperMonkey) may or may not support all Excel functionality, such as the hiding of sheets.
The astute observer may have also noticed line 25 in the previous image. Line 25 calls a function that contacts the C2 server.
Unlike most malicious macros, this one uses WMI (Windows Management Instrumentation) to ping the C2 server instead of a more commonly used tool, such as PowerShell or CMD.
Furthermore, this function is called multiple times during macro execution. It basically works as a state monitor to keep track of what’s happening during the attack. The tMsg variable changed during different stages of the attack, allowing the attackers to view their network logs to see the state of their macro.
The rds variable is a random four-digit number, with the same four digits used consistently throughout the macrostate check-in process.
| C2 | Macro State |
| qwzbabz[four-digits].joexpediagroup[.]com | Macro start |
| qwzbbbz[four-digits].joexpediagroup[.]com | Connected successfully to task scheduler |
| qwzbaez[four-digits].joexpediagroup[.]com | Successfully created malicious PE file |
| qwzbbez[four-digits].joexpediagroup[.]com | Successfully created XML config file |
| qwzbcez[four-digits].joexpediagroup[.]com | Successfully created signed Microsoft PE file |
| qwzbdez[four-digits].joexpediagroup[.]com | Double-check malicious PE file was created |
| qwzbeez[four-digits].joexpediagroup[.]com | Successful manual execution of malicious PE file |
| qwzafzz[four-digits].joexpediagroup[.]com | Begin task scheduler configuration for persistence |
| qwzbbfz[four-digits].joexpediagroup[.]com | Successfully created scheduled task |
As alluded to in the table above, the macro has the capability to create three files. A malicious PE file was created as %LocalAppData%\MicrosoftUpdate\update.exe. A configuration file was created as %LocalAppData%\MicrosoftUpdate\update.exe.config. And the third file, %LocalAppData%\MicrosoftUpdate\Microsoft.Exchange.WebServices.dll, was signed and clean.
While the malware authors decided to store these three files inside the Excel file, they again chose to do so in a way that is not commonly seen.
Three user forms are stored inside the Excel file. Each user form has a label, and each label has a caption. As seen in the image above, the caption contains base64 encoded data. Form1 contains the malicious update.exe file. Form2 contains the configuration file. And Form3 contains the clean Microsoft file.
The malware authors also used the Excel macro to create a persistence method for their update.exe file. They accomplished this by setting a scheduled task.
The task is named MicrosoftUpdate and repeated every 4 hours. The macro also uses deprecated IdleSettings properties, such as Duration (which starts the task only if the computer has been idle for ten minutes) and WaitTimeout (which determines how long to wait for an idle condition). This task was set to allow 20 days to complete. Taking into account the date of the email and assuming the task ran immediately, the task would run until at least May 16, 2022.
In addition to the visibility switch technique described earlier, a second technique was also seen in this macro to possibly avoid automated analysis. This macro does this by checking for the existence of a mouse. If a mouse is not connected, the macro does not create any of the three files.
There are a couple of instances where a mouse would not be attached to a computer. First, a mouse is not necessarily needed if the computer is controlled remotely. The only mouse needed would be installed on the controlling computer. And second, a mouse is not needed if an analysis machine is simply processing and emulating Office files. A script can be created to automatically perform all the actions necessary without a mouse.
Dropped Files
As explained earlier, this malicious Excel macro includes the ability to create three files. In this section, we will look at them individually, starting with the two benign files.
A signed file was embedded inside the Excel file and dropped to the following location: %LocalAppData%\MicrosoftUpdate\Microsoft.Exchange.WebServices.dll. Another innocuous file was dropped as %LocalAppData%\MicrosoftUpdate\update.exe.config. Its contents are to be used as configuration data. Here are the contents after decoding:
The third file is the actual malware. It was created in the same location as the two previously dropped files, as %LocalAppData%\MicrosoftUpdate\update.exe. It was a .NET binary and contained the main payload.
The malicious executable is a .NET binary that checks program states and puts itself to sleep for eight hours after launching. The analysts believe the hackers probably set this delay on the assumption that the diplomat would open the email in the morning and leave after eight hours so that the computer would be unattended.
When active, the malware communicates with C2 subdomains using a domain generation algorithm (DGA) tool. DGA is a widely-used technique that makes malware operations more resilient to domain takedowns and block-listing.
It then sets up a DNS tunnel to communicate with the provided IP address. This is a rarely seen technique that helps threat actors encrypt the data exchanged in the context of this communication, making it hard for network monitors to catch anything suspicious.
Some of the domains used in the campaign are suspiciously named, obviously attempting to masquerade as well-known and trusted entities like AstraZeneca, HSBC, and Cisco.
Next, the C2 sends twenty-two different backdoor commands to the malware, which are executed through PowerShell or the Windows CMD interpreter.
Finally, the exfiltration of stolen data is done via DNS, with the data embedded into the request, making it appear standard in network logs.
Indicator of Attack:
| Command | Interpreter | Payload |
| 1 | PS | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress |
| 2 | PS | Get-NetNeighbor -AddressFamily IPv4 | Select-Object “IPADDress” |
| 3 | CMD | whoami |
| 4 | PS | [System.Environment]::OSVersion.VersionString |
| 5 | CMD | net user |
| 7 | PS | Get-ChildItem -Path “C:\Program Files” | Select-Object Name |
| 8 | PS | Get-ChildItem -Path ‘C:\Program Files (x86)’ | Select-Object Name |
| 9 | PS | Get-ChildItem -Path ‘C:’ | Select-Object Name |
| 10 | CMD | hostname |
| 11 | PS | Get-NetTCPConnection | Where-Object {$_.State -eq “Established”} | Select-Object “LocalAddress”, “LocalPort”, “RemoteAddress”, “RemotePort” |
| 12 | PS | $(ping -n 1 10.65.4.50 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.4.51 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.65.65 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.53.53 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.21.200 | findstr /i ttl) -eq $null |
| 13 | PS | nslookup ise-posture.mofagov.gover.local | findstr /i Address;nslookup webmail.gov.jo | findstr /i Address |
| 14 | PS | $(ping -n 1 10.10.21.201 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.19.201 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.19.202 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.24.200 | findstr /i ttl) -eq $null |
| 15 | PS | $(ping -n 1 10.10.10.4 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.50.10 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.22.50 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.45.19 | findstr /i ttl) -eq $null |
| 16 | PS | $(ping -n 1 10.65.51.11 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.6.1 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.52.200 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.6.3 | findstr /i ttl) -eq $null |
| 17 | PS | $(ping -n 1 10.65.45.18 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.28.41 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.36.13 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.51.10 | findstr /i ttl) -eq $null |
| 18 | PS | $(ping -n 1 10.10.22.42 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.23.200 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.45.19 | findstr /i ttl) -eq $null;$(ping -n 1 10.10.19.50 | findstr /i ttl) -eq $null |
| 19 | PS | $(ping -n 1 10.65.45.3 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.4.52 | findstr /i ttl) -eq $null;$(ping -n 1 10.65.31.155 | findstr /i ttl) -eq $null;$(ping -n 1 ise-posture.mofagov.gover.local | findstr /i ttl) -eq $null |
| 20 | PS | Get-NetIPConfiguration | Foreach IPv4DefaultGateway | Select-Object NextHop |
| 21 | PS | Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object SERVERAddresses |
| 22 | CMD | systeminfo | findstr /i \”Domain\” |
Indicator of Compromise
Files
| Indicator | SHA256 |
| Confirmation Receive Document.xls | 82A0F2B93C5BCCF3EF920BAE425DD768371248CDA9948D5A8E70F3C34E9F7CCA |
| Microsoft.Exchange.WebServices.dll | 7EBBEB2A25DA1B09A98E1A373C78486ED2C5A7F2A16EEC63E576C99EFE0C7A49 |
| update.exe.config | C744DA99FE19917E09CD1ECC48B563F9525DAD3916E1902F61B79BDA35298D87 |
| update.exe | E0872958B8D3824089E5E1CFAB03D9D98D22B9BCB294463818D721380075A52D |
Other
| Indicator | Value |
| Mutex | 726a06ad-475b-4bc6-8466-f08960595f1e |
| C2 domain | joexpediagroup[.]com |
| C2 domain | asiaworldremit[.]com |
| C2 domain | uber-asia[.]com |
Mitre TTPs
| Initial Access | |
| T1566.001 | Spearphishing |
| Execution | |
| T1059.001 | PowerShell |
| T1059.003 | Windows Command Shell |
| T1053.005 | Scheduled Task |
| T1204.002 | Malicious File |
| T1047 | Windows Management Instrumentation |
| Persistence | |
| T1053.005 | Scheduled Task |
| Defense Evasion | |
| T1480 | Execution Guardrails |
| Discovery | |
| T1087.001 | Local Account |
| T1083 | File and Directory Discovery |
| T1049 | System Network Connections Discovery |
| Command and Control | |
| T1071.004 | DNS |
| T1132.002 | Non-Standard Encoding |
| T1568.002 | Domain Generation Algorithms |
| Exfiltration | |
| T1041 | Exfiltration Over C2 Channel |
APT34 has been previously linked to the Iranian government and is a capable threat actor that operates in the shadows, not leaving any traces behind.
As such, Fortinet’s report is valuable for researchers and defenders alike, who should take note of the published indicators of compromise.
Source/Credits: https://www.fortinet.com/blog/threat-research/please-confirm-you-received-our-apt
https://www.bleepingcomputer.com/news/security/iranian-hackers-exposed-in-a-highly-targeted-espionage-campaign/