Agent Telsa is a spyware, keylogger and information stealer Trojan written in C# that has been active since 2014 as a MaaS (Malware as a Service).
Commonly distributed via emails, the attacker intends to lure the victim into opening the attachment.
Once macros have been enabled, the malware will simply drop an executable and execute itself.
In Agent Tesla, we can identify 5 different stages:
- Malicious document via spear-phishing
- Initial executable dropped by the macros
- Extracting the second executable
- Extracting the third and last executable
- Communicate via SMTP over port 587 with the C2
After dropping the initial executable, only the final one will be malicious and, if my guesses are right, the main purpose was to make the malware analyst job much more difficult.
Last but not least, different anti-debugging and obfuscation techniques have been used to evade antiviruses and beginner analysts.
I always start with a quick behavioral analysis on the sample so I can better understand how the malware operates, creates and injects.
My first fear was that Any-Run would not have been able to execute it since it’s a commercial malware and most likely they could contain anti-vm and anti-sandbox checks but, luckily for me, it ran perfectly.
Pretty straight forward and nothing else to add; the malware maintains persistency by adding a new task to the
Task Scheduler and by modifying the
An XML configuration file for the task has been created into
C:\Users\admin\AppData\Local\Temp\ by executing
schtask.exe from the command line and supplying the following string:
/Create /TN "Updates\&startupname&" /XML "C:\Users\admin\AppData\Local\Temp\tmp1F0.tmp
The malicious code injects itself into
RegSvcs.exe (a standard executable by default on Windows machines that loads assemblies), and constantly sends SMPT packets to
We can see that personal information gets transmitted over port 587 to the C2 and by a quick search on Fortinet’s report, additional software are targetted such as web browsers, email clients, VPNs, FTP clients and download managers.
In order to execute the malicious executable upon reboots, a key has been added to the
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key pointing to
C:\Users\admin\AppData\Roaming\oPLNOE\oPLNOE.exe, our malicious executable.
This executable (
BSCPQ.exe) will be the main
container for all the other malicious activities that it will perform.
Why did I call it a
There are a lot of functions and at first glance and it appears to be a UNO card game with multiplayer capabilities.
After checking again the strings of the executable, I stumbled upon an incredibly long string that had no reason to be in a UNO match.
Now I started getting more excited because I also find the same reference inside the decompiled game and even something else:
And if you’re careful enough, you can see that the string Ir that it’s equal to cnJCh, that value points exactly to the bitmap that will definitely contain data or even additional malicious code.
We should also note that the long string we saw before has a name: SAS.
There are 3 functions that works with these variables and data:
- The first method is the constructor that will call the Rate method and passing an array of object that contains exactly 3 values: Castle.Ir, Castle.Iq and WinFormsFirstOne.
- The second method will reverse a string.
- The third method will replace all the occurrences of Quotes_on_Life with the character A from the SAS variable, reverse it and decode it from base64.
And if we debug the executable and place a breakpoint to read the byte array value, we can see a new executable:
To make the next executable analysis easier, I managed to write all the bytes to file (later on I learned that I could just dump the value from a variable to file by right-clicking it).
The second executable is called
sparta.dll and it’s loaded in the same memory as the first executable.
As you can clearly see, a more interesting obfuscation technique has been applied to those methods in order to make the analyst cry when analysing them but, luckily, that was not the case.
The analysis was pretty straightforward and wasn’t even difficult since it had the same behavior of the first executable:
- Extract the malicious code from somewhere
- Load the assembly code into the memory
- Execute it
After spotting some bitmap manipulation methods, I realised that we have a bitmap from the first executable and to not waste too much time analysing useless code, I simply dumped the final assembly.
The final executable was IMPOSSIBLE for me to debug, decrypt, analyse and even for dnSpy to decompile it.
I managed to use
de4dot to get rid of those stupid Unicode characters methods but it was not worth it.
Patching the code would have resulted in many compilation errors because of it and neither debugging was possible because of those damned anti-debug threads running and checking.
And to make it more difficult,
ConfuserEx has been used to protect the final executable from analysts.
I managed to learn interesting things but failed at the same time to fully analyse the sample through dnSpy.
I have no idea how to proceed and de-obfuscate it so I’ll end this post here by doing a little summary of what the final executable does when launching it on
- The dropper gets distributed via phishing attacks (based on Fortinet’s Report).
- It loads another executable in the dropper’s memory.
- The second executable loads a third heavily obfuscated one that would result in the final one.
- This executable will be placed in
%APPDATA\Roaming\oPLNOE%and set the registry key
Runto this path, achieving persistence upon reboots.
- The third executable can transfer sensitive information such as credentials, keyloggers, running programs and files via SMTP on port 587.
- It disables the task manager by doing
REG add HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System / v DisableTaskMgr / t REG_DWORD / d 1 / ffrom the CLI.