Agent.Tesla is a piece of malware that is active since 2014. According to an article that is published on 'krebsonsecurity.com', access right is acquired by paying subscription fee via bitcoin and by the time of the article, it had more than 6,300 customers. 7/24 technical support via Discord channel is also included.
The analyzed attack begins with phishing mail and attachment is an RTF file named 'swift_copy.doc'. The attack vector uses lots of technologies during different steps until reaching to the actual stage that makes desired actions and utilizes different obfuscation techniques for each step. In the end, it drops Agent.Tesla variant and it is capable enough to siphon various data from the system like account details of multiple applications. Besides this, it has also keylogger behavior. The abovementioned variant ensures persistence by adding an entry to the 'run keys' in the registry. Actions of the malware continue at a certain interval.
The Attack Vector
Stage1: Phishing RTF File
The first step of the attack vector comes with an email attachment. The name of the attachment is 'swift_copy.doc' though the file format is RTF. It contains an embedded OLE object and inside that object, there is VBA script. At first sight, it is clear that there are obfuscated data blocks.
This script is responsible to decrypt that data blocks and trigger decrypted data. By updating VBA script as reveal what does it decrypt, it can be clearly observed that it is starting a Powershell process as of the next step.
Inside the Powershell script, there is encrypted data as well. First of all, it decrypts this and it continues the execution within decrypted data by using Add-Type cmdlet. The decrypted script has a class named v279dd and the function named s74574 inside this class is triggered. Strings that are used as a parameter are encrypted and it resolves dynamically. The decryption function is reimplemented using Python and it is patched with plain-text values.
The script has 2 functionalities; first of all, it patches ‘Antimalware Scan Interface’ (AMSI). According to Microsoft documents,
The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product that's present on a machine.
In the case of Powershell, AMSI works as a string-based scanner. Inside AMSI.dll, the AmsiScanBuffer function is used while scanning Powershell scripts. One of the 2 parameters this function gets are: buffer to be scanned and the buffer length. The script patches 'mov edi, r8d' instruction. In the original code, r8d register holds the buffer length. In order to bypass the AMSI scan, corresponding instruction is overwritten with 0x31, 0xff, 0x90 values namely 'xor edi, edi', so the buffer length becomes 0. Then it connects to a web server on the internet to download a file named kali.exe and stores it in %appdata% folder as v6f3a.exe. Ultimately, it creates a new process by executing that file.
The file's format is PE executable and it is developed using AutoIT. AutoIT is looking like Basic language and it is developed to automate Windows functionalities. The interpreter runs its code dynamically and they can be separated or packed inside an executable. In this case, code and interpreter packed and as a first step the code is extracted from the file. 2 different obfuscation techniques are used for the code; one of them is that 'ç' character places between each characters and a dedicated function responsible to clean those strings dynamically. And the other one is that lots of symbols are hex encoded.
The execution starts with reading and joining 9 Icon files from the resources section of the file. Result data is treated as encrypted and at this stage, it enters AES 256 bit decryption routine with using WinAPI. The decrypted data appear to be a PE executable file.
Then it chooses a path with respect to the configuration variable that hard-coded inside the code. The sample that analyzed picks the path ‘%homedrive%\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe’. Then it allocates a place in memory for decrypted PE executable file and hard-coded shellcode data. 'DllCallAddress' is a function of AutoIT and it is used to call a function inside the memory. Parameters of 'DllCallAddress' are the address of the function called, and parameters that passed.
AutoIT code calls a function located at the starting address of the shellcode + 0xBE and passed parameters are the address of the decrypted PE executable and the chosen path. At this point execution pass to the next step, shellcode.
Shellcode is not subject to loader and linker mechanisms of the operating systems. Because of that, it is unaware whether required libraries are loaded into memory and where the required functions are located. For the analyzed sample, it needs 14 WinAPI functions to do what it is tasked to. So the first action taken by shellcode is to resolve required WinAPI functions for the rest of the code. It searches required functions within 2 Windows libraries: Ntdll and Kernel32. These libraries are loaded every process but it is unknown where the functions located. For each function, there is one hard-coded hash inside the shellcode, 2 of them for Ntdll and 12 of them for Kernel32. After finding the location of corresponding libraries by using Thread Environment Block (TEB) and Process Environment Block (PEB) structures, it calculates hash of the export functions names one by one and tries to match with hard-coded ones. To repeat this process, an r2pipe script has been developed, that takes Ntdll and Kernel32 functions and calculates hashes.
In the end, all required functions have been resolved.
The shellcode then creates a process using the path that passed as a parameter and the process is started as suspended. Then it places AES decrypted file to memory and injects that to the suspended process's memory with PE injection technique. At the end of the injection routine, it continues suspended thread with ResumeThread API call. In this way, the execution of the attack vector passed to the next step.
AutoIT code merges and decrypts this step of the attack vector. In order to continue the analysis, a script has been developed to mimic the process of obtaining the corresponding step of the vector. The file is .Net executable. It has 3 capabilities to connect C&C: Http, Ftp, and Smtp. It chooses one of them with respect to the corresponding configuration variable. The analyzed sample chooses Smtp.
The configuration variable does not only determines the C&C connection way but diversifies its activities also. Last but not least, because it chooses Smtp, it hasn't any information like the C&C server address for the Http scenario.
The connection data for e-mail is crafted following a certain pattern:
- E-mail subject is formed as UserName + '/' + ComputerName + one of the hard-coded value that describes connection intention:
- Screen Capture
- Recovered Accounts
- E-mail body is formed as:
- E-mail attachment if the intention is Screen Capture
This step of the attack vector utilizes strong obfuscation techniques. First of all, the strings inside the code are encrypted using a custom algorithm that involves the Rijndael cryptography algorithm at the end. The other obfuscation technique that it uses is that Control Flow Flattening. Fundamentally the mechanism to apply Control Flow Flattening to code is:
- Break up a function code block to basic blocks
- Put all these basic blocks, which were normally different nesting blocks, next to each other
- Encapsulate basic blocks in selective structure (switch) with each block in a separate structure
- Ensure correct flow using the control variable which is set at the end of each basic block.
The aforementioned obfuscation techniques complicate analysis deeply. In order to decrypt encrypted strings, the algorithm that is used inside the code is implemented using Python. The code updated respect to the plain text values.
For the Control Flow Flattening technique, it is determined that it used ConfuserEx, an open-source free obfuscation tool for .Net application and able to recover the original form of the code.
The malware sleeps 15 seconds immediately after it starts its execution. Then it checks the computer name and user name to determine if it contains one of the hard-coded values inside it.
When there is no match, it continues the execution with terminating processes that launch using the same file with the current process. Then it is trying to determine the privilege level of itself when it is running on Windows 7, 8, 10 operation systems. If it has administrator rights, it deletes the file which is located at '%temp%\temp.tmp'. When it hasn't had administrator privileges, it tries at most 3 times to escalate its privilege and the counter is stored inside the file '%temp%\temp.tmp'. The malware has 2 capabilities in order privilege escalation: one of them for Windows 10 and the other one for Windows 7, 8. Both of them work similarly and the 'User Access Control' (UAC) component of the Windows OS is being tried to bypass. UAC is a fundamental component of Microsoft's overall security vision. When an application requires Administrator privileges, UAC force the user to supply valid administrator account credentials. The auto elevation feature has come with Windows 7 to improve the usability of the UAC. The bypass technique exploits the situation which is occurred due to an auto elevated application that behaves according to none-privilege data to take action. For Windows 10, ‘HKEY_CURRENT_USER\Software\Classes\ms-settings\shell\open\command’ registry is prepared as:
- Creates 'DelegateExecute' value under the corresponding registry key.
- Assigns the file's path that the process launch from to that registry.
- Starts ‘C:\Windows\System32\computerdefaults.exe’ application and automatically a brand new privileged process would start.
For Windows 7, 8, ‘HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command’ registry key is used.
- Assigns the file's path that the process launch from to that registry.
- Starts ‘C:\Windows\System32\eventvwr.exe’ application and automatically a brand new privileged process would start.
The malware has hard-coded ‘%appdata%\\MyApp\MyApp.exe’ value as a global variable. It checks this hard-coded value against the file this process launch from. If it doesn't match then it creates a folder named 'MyApp' under '%appdata%' path. It terminates all processes on the system that is launched from the hard-coded path. It copies itself to '%appdata%\MyApp\' and to acquire persistence on the system, it creates registry key ‘Software\Microsoft\Windows\CurrentVersion\Run\MyApp’ under current user and adjust 'SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run' key accordingly. The zone identifier of the '%appdata%\MyApp\MyApp.exe' is deleted after then. Zone identifier data indicates whether the file downloaded from the internet or not.
The malware enters account harvesting routine from various applications such as browsers, e-mail clients, etc. The collected value is sent to the internet via the way according to configuration value.
The list of the application that the malware capable to harvest is:
- Opera Browser
- Yandex Browser
- Comodo Dragon
- Cool Novo
- Torch Browser
- Elements Browser
- Epic Privacy
- Flock Browser
- Opera Mail
- FTP Navigator
It also sets scheduled tasks using .Net Timer class. The analyzed sample has keylogger capabilities and it stores keystrokes and clipboard changes in HTML format. For every 20 minutes, it sends an e-mail the keylogger data.
The other task is capturing a screenshot for every 20 minutes again. Screenshots are stored at the '%appdata%' folder with extension .jpeg and names are calculated dynamically. It also sends an e-mail the screenshots.
After this step, the malware continues its actions with scheduled jobs.