Don’t Be Fooled by Agent Tesla’s Football Club Red Herring

Agent Tesla is a remote access tool (RAT) that is known for stealing credentials from several applications, including web browsers, VPN clients, and mail and FTP applications. It also supports keylogging, screen grabbing, and other functionality. Since it first came on to the scene in 2014, Agent Tesla has evolved into a fully customizable commercial malware tool, which is readily available on underground markets. Given the huge popularity of the malware, this threat has been thoroughly covered by the threat intelligence community, including our analysis in 2018 [1], our reports on COVID-19 related cyber threats [2] [3], and a recent article describing a surge of infections [4]. More recently, we detected a new wave of Agent Tesla attacks that exhibited some interesting characteristics, such as requesting a connection to top European football club websites.

In this blog post, we first present some of VMware’s NSX Advanced Threat Prevention telemetry and email metadata from the attack. We then provide our analysis detailing the most distinctive aspects of the attack, from the use of well-known European football club websites to key tactics, techniques, and procedures (TTPs).

The Agent Tesla Campaign

Figure 1 shows the detection timeline of the campaign that affected some of our customers in both the US and EMEA regions on March 1 of this year. Note that the magnitude of the attack shown in the figure may not represent the actual scale of the campaign.

Often, malspam creators like to use a particular theme for a campaign, which is reflected by email subject lines and attachment file names. For example, the Nemty ransomware attack used smiley emojis in email subjects [5], while the Phorpiex-powered ransomware campaign used the keyword photo in the email subject lines and email attachment filenames [6]. However, in this Agent Tesla campaign, the attacker didn’t use a particular theme. Instead, we saw various topics from flight tickets to payslips. Figure 2 shows the top five email attachment file names seen in the campaign.

Though different keywords were used, there is a common naming pattern shared by the attachment file names: all file names ended with pdf.001. All the attachments are RAR archive files that contain the first-stage payload, which is a downloader. Using keywords such as flight tickets and payslips in email attachment file names can certainly attract attention and make the attachments appealing to recipients, thus increasing the infection rate. This is a common social engineering technique leveraged by threat actors to entice potential victims into opening attachments and activating the download process.

Table 1 shows the metadata of a typical malicious executable extracted from the attached RAR archive files in the campaign. As we can see, the downloader has different names that are consistent with the corresponding RAR archive names.

Table 1: A typical malicious executable extracted from the attached RAR archive files.

The Initial Attack Infection Chain

Figure 3 depicts the first-stage attack infection chain associated with the sample listed in Table 1. As the figure shows, the same executable file was embedded inside various RAR files. Upon execution, the downloader issued connection requests to a list of HTML pages, including a few random URLs pointing to some well-known European football club websites.

Based on what is shown from the infection chain above, there are a few questions that need to be answered:

• What are the tactics behind the decision to use football club websites?
• What payload is downloaded from the hosts?
• What TTPs are used in the final payload?

The following sections attempt to answer these questions by providing a deep dive into the downloader and discussing what we observed from analyzing the final payload.

Stage 1: Downloader

The executable file embedded in the attachment RAR archives, shown in Table 1 and Figure 3, is a .NET malware downloader. We can see from Figure 3 that the following domains were observed upon execution of the downloader:

• chelseafc.com
• mancity.com
• manutd.com
• realmadrid.com
• liverpoolfc.com
• osndjdjjjdjshgaggdkf[.]com

It is easy to recognize that five of them are related to well-known European football clubs. The only one that is not associated with a football club is the random-looking domain osndjdjjjdjshgaggdkf[.]com.

Constructing URLs

Further analysis reveals that these domains were used to construct the URLs (see Figure 3) that contain the same random string “dOVkcmMWSJnEtaXdENzqlBWragOdo”. Figure 4 highlights the process of generating the URLs using these domains.

As we can see, each URL is constructed with three parts:

• 1^st part: http://domain/base/
• 2^nd part: dOVkcmMWSJnEtaXdENzqlBWragOdo
• 3^rd part: .html

The final URLs were then generated, as listed in Figure 3.

There is a decryption key (assigned to text2) highlighted in Figure 4, which is used for decrypting the downloaded payload, as discussed next.

Downloading and decrypting the malicious string

Following the construction of the URLs, the downloader attempts to connect to each of the URLs, as shown in Figure 5. First, the process issues an HTTP request by calling DownloadString() to download the resource as string from a URL specified by text3.

If the download is successful and the downloaded string contains both an opening tag “<p>” and a closing tag “</p>”, a decryption loop is followed to decrypt the payload string in text4 using the key stored in text2 (see Figure 4).

A red herring using football club domains

As Figure 5 shows, there is an exception handler to catch any errors caused by unsuccessful download or decryption.  If an exception occurs and the URL stored in text3 contains “www”, then the process moves to the next iteration to check a new URL. In the list of domains we identified above, all the football club-related domains contain “www”, while the random-looking domain does not. As the URLs associated with the football clubs do not exist, requesting these pages results in either HTTP 404 errors or redirection to the home pages of the football club websites. Whether it is a 404 error or a redirection, an exception will be raised (for redirection, an exception is raised from the decryption loop, see Figure 5). In other words, the process deliberately skips all football club-associated URLs.

Our investigation shows that all these benign football club domains had nothing to do with the malware and they were not used in the later stages of the attack. They were used together with malicious domain(s) by the malware writer to construct URLs with similar patterns. As a result, using the football club domains in the attack turned out to be a red herring to confuse analysis. It is anyone’s guess why these football clubs were chosen by the attacker. One possible reason is that since all the mentioned football clubs are well-known globally, the malware author can leverage the same clubs in attacks across various regions. We detected the attacks in both the US and EMEA regions (see Figure 1). Another possible reason is that the malware writer simply doesn’t like these football clubs and attempted to have the corresponding domain names included in blocklists based on automated analysis of the malware sample.

The downloaded malicious string before and after decryption

In the case of an actual malicious domain, an HTTP GET request to the following URL:

http://osndjdjjjdjshgaggdkf[.]com/base/94A0A1D9C118D2C034654303F65BE91C.html

would receive a proper response in the form of an HTML page (before the server was taken down). The HTML page contains an encrypted string that is wrapped around tags “<p>” and “</p>”. The malware downloader then extracts the string and decrypts it to build the next stage payload at runtime. Figure 6 shows the HTTP response, part of the encrypted string, and the decrypted content.

Converting the decrypted string into a byte array

The decrypted content is a decimal-encoded string delimited with the character “x”. The delimiter character is removed from the decrypted string and the resulting pure decimal-encoded string is then converted into a byte array. Figure 7 shows the process of converting the decrypted string into a byte array.

The byte array, which is a .NET loader containing the final Agent Tesla payload, will be loaded as a binary into memory using the Assembly.Load() function. The loader then invokes the Main() function of the embedded Agent Tesla to execute the final payload.

Stage 2: Agent Tesla Payload

Reversing the Agent Tesla RAT provides interesting insights into the TTPs leveraged by the malware authors. In the remainder of this section, we discuss various aspects of the TTPs, from killing existing Agent Tesla processes to achieving persistence, to host fingerprinting and data exfiltration.

Killing existing Agent Tesla processes

Upon execution, the payload first checks and kills any existing Agent Tesla processes. As Figure 8 shows, the malware compares the corresponding file name of each running process with the newly dropped Agent Tesla payload copy saved in the %appdata% directory on the infected host. The running process is killed if the file name of the process is the same as the new payload copy.

Gaining persistence and preventing detection

Malware often uses persistence and detection prevention to stay in control of a host for a long time after gaining access to a system. In this attack, the malware first makes its own copy invisible to Windows Explorer by setting “Hidden” and “System” attributes, as shown in Figure 9. Then a process is set to gain persistence by creating Registry Run keys for the payload.

What is a Zone.Identifier? Zone.Identifier (also called Alternative Data Stream, ADS) was first introduced with Windows XP SP2. A Zone.Identifier is generated when a file is saved to a local file system from a different security zone (hence named Zone.Identifier). The Zone.Identifier is a small file containing some metadata about the downloaded file, such as the security zone where the payload was downloaded from. There are five common security zones, including the Internet zone [7]. Based on the Zone.Identifier, Windows will pop up a warning message if one tries to access a file downloaded from an untrusted web site. As a result, deleting the Zone.Identifier will not only remove the trace of the payload origin, but it also will turn off the warning message from Windows and hence increase the difficulty of detecting the malware.

Fingerprinting host information

The Agent Tesla infostealer is known to harvest sensitive data, including key system information, from the infected host. Figure 10 shows some common metadata that the malware collects from the host:

• Username
• Computer name
• OS name
• CPU processor
• RAM size

When exfiltrating data to a command-and-control (C2) server, host information is transmitted as well so the attacker knows from which machine the data is harvested.

Types of exfiltrated data

There are mainly three types of data that the Agent Tesla infostealer harvests (see Figure 11):

• Screenshots
• Credentials from applications, such as web browsers and FTP clients
• Keystrokes

The process of stealing different types of data proceeds in a controlled manner. As Figure 11 shows, there is a timer that tells the program when to trigger a particular functionality to harvest certain types of data.

For example, to steal credentials from various applications, Agent Tesla calls the credential-stealing function, named SendPasswordAndCredential() in our analysis. Figure 12 shows a snippet of the function, which contains a User Data path for a list of web browsers from which the credentials will be stolen.

Data exfiltration techniques

To transmit the harvested data to a C2 server, the malware provides several protocols. A particular protocol-based method is triggered depending on the configuration setting, which is specified by a data exfiltration method variable (named DataExfilMethod in our analysis, see Figure 13). As we can see from the figure, the following data exfiltration techniques can be used for sending screenshot data:

• HTTP
• SMTP
• FTP
• Telegram

Of the data exfiltration techniques, sending data via SMTP tends to be the most common method used in Agent Tesla attacks, thanks to its simplicity. A malware writer can simply use a compromised email account to achieve this, which is likely to be the case in this attack (see Figure 14).

When the SMTP method is called to send data, it also checks the type of exfiltrated data. If it is a screenshot (with DataType ==1, shown in the figure), the screenshot will be sent as a JPEG image attachment in the email; for other types of data, it will be compressed as a ZIP archive attachment.

The feature of using the Telegram service in this payload implies that the sample is similar to Agent Tesla v3 variants, as identified in the report [4] in which the analysis pointed out that the Telegram service was only used in v3 samples, not in v2 variants. Abusing Telegram in cyberattacks is not new. Leveraging Telegram has become increasingly popular to facilitate malicious activities because it allows the attacker to remain anonymous and provides access to the infected devices from virtually anywhere. The recent attack from ToxicEye RAT is another example of this kind of technique [8].

We also noticed that the payload provides the option of using a Tor proxy to transmit data in the HTTP data exfiltration method if the proxy is enabled. The malware will kill any existing Tor process before installing a new Tor client (see Figure 15).

VMware NSX Detection with MITRE ATT&CK Mapping

VMware NSX customers are well-protected against Agent Tesla. Figure 16 shows the analysis overview from a controlled environment when executing the initial malware in the attached archive. As shown in the figure, VMware’s AI-driven NSX Advanced Threat Analyzer successfully detected the malware as Agent Tesla. In addition, it also detected a few other high-risk artifacts, such as targeting Windows saved credentials, malicious code reuse, registering for autostart during Windows boot, and creating hidden executable files.

As the figure above shows, the analysis overview also contains a MITRE ATT&CK tactic and technique mapping for some of the key malicious behaviours observed during the attack execution. The typical ATT&CK tactics include TA0004: Privilege Escalation, TA0005: Defense Evasion, TA0003: Persistence, and TA0007: Discovery, which corresponds to ATT&CK techniques such as T105: Process Injection, T1547: Registry Run Keys / Startup Folder, and T1033: System Owner / User Discovery. A detailed MITRE ATT&CK tactic and technique mapping for Agent Tesla can be found in the MITRE report [9].

Conclusion

In this report, we analyzed a recent Agent Tesla attack and discussed our investigation and findings. The attacker used a typical malspam with RAR archive attachments to deliver the first stage Agent Tesla downloader. Our analysis showed that the downloader used a few well-known football club domains together with a C2 domain to construct URLs with a similar pattern. It turned out that the use of football club domains was purely a red herring to confuse analysis. Further investigation into the actual downloaded Agent Tesla payload revealed some interesting techniques which were leveraged to increase the infection rate. For example, the malware writer took various steps to achieve persistence and evade detection of the payload, including setting “Hidden” and ‘System” attributes, creating Windows Registry Run Keys, and deleting the Zone.Identifier. In terms of data exfiltration, the payload provided a few configurable methods, including the SMTP protocol, HTTP with Tor proxy option, and FTP and Telegram.

Bibliography

Appendix: IoCs

Indicators of compromise identified from this report can be found on VMware TAU’s GitHub IoCs repository.