Cleaning the atmosphere

When security systems analyze large amounts of email correspondence, the initial step normally involves filtering based on sender verification. Strict filtering policies are usually in place to address most ways of delivering malware via email.

If an email contains a password-protected archive, for example, it does not matter how cleverly the key is specified — the email will not be delivered. Malware distributed as executable files, scripts, attached emails, and HTML documents is handled similarly. Such emails will not be delivered, regardless of the file status.

This means that the task of built-in sandboxes comes down to filtering emails that contain office documents. At the same time, email domains of major corporations, solutions providers, and government entities are considered safe — provided they have passed sender address verification — which is why most emails from them are delivered without additional analysis. In the case described below, this is exactly what the hackers took advantage of.

The sender and recipient addresses belonged to the same organization. An analysis of the email did not reveal that its headers had been forged, which could have suggested that the sender had been compromised.

The analysis revealed that the email had been sent through a feedback form on the organization's official website. It is noteworthy that cybercriminals used the feedback form in Russian to target the employees of the organization's English-speaking division.

As payload, the email contained a modular banking Trojan called TrickBot. Threat actors use the Trojan as a foothold at the vulnerability post-exploitation stage. For example, the group Wizzard Spider used Trickbot as a substitute for Cobalt Strike in early attack stages.

This type of attack requires manual labor, preliminary research into the potential victim, resources, and time. As a result, such campaigns are targeted and sophisticated rather than mass-scale. The case in question is not unique, however.

The case reveals weaknesses in email security systems where the load is reduced by sender verification. If the solution that your organization uses includes an anti-spam system, we strongly recommend testing it against the infection vector described above.

In typical email security systems, the next step after sender verification is checking the format of the attached files. Here too the security approach stems from business processes where receiving a password-protected archive or executable file attached to the email is an anomaly most of the time.

Receiving emails with files that the security system does not recognize, however, is considered not to pose a threat. Such files are meant to be opened with specific software used within the target organization.

As it is shown in the example below, however, this creates opportunities for threat actors, who in this case decided to use an exploit in a regular Windows Help file.

The initial file was designed to use multiple stagers to deliver the TrueBot Trojan (also known as Silence.Downloader) to the target endpoint. The threat group Silence is known for using the Trojan.

As mentioned at the beginning of this article, even when strict filtering policies are in place, businesses rely on cloud antivirus software and sandboxes to analyze office documents because they cannot stop the documents from being circulated.

After checks by cloud antivirus solutions, which are not particularly effective against new types of threats, the sender's document is sent to a sandbox for analysis. However, most security vendors do not focus enough on countering known ways of bypassing sandboxes.

In the case in question, the threat actors used techniques pertaining to the last category. The initial file was a PPT presentation that contained three macros.

This is what the file structure looked like in Group-IB's Business Email Protection:

Most sandboxes that analyze such attachments in corporate email launch the file and wait for suspicious activity.

Let's imagine that a regular human user has opened an office document and is facing the following situation:

They will most likely close the window assuming that the file is damaged. This response is not typical for security systems. Let's now look at one of the three macros contained in this document:

The threat actors adjusted their malicious activity to fit actions typical for people rather than machines. In this situation, most typical sandboxes wait until the analysis time is over and then mark the file as "safe" without detecting anything suspicious.

The attack was conducted by a Nigerian group called TMT (also known as SilverTerrier), which focused on business email compromise (BEC). Emails in such attacks are often disguised as commercial proposals, requests for money transfers, or messages from an HR department. The goal is to withdraw funds or steal confidential data. You can learn more about the group here.

The cases described above are just specific examples, but even they reveal fundamental weaknesses in most modern-day corporate email security systems. There are even more ways to deliver malware to end users, however.

Companies usually do not have sufficient resources to compile a comprehensive list of scenarios for internal audits. With this in mind, we created a free automated email security testing system called Group-IB Trebuchet.