First seen in 2014, AgentTesla (S0331) is a .NET platformed stealer that has recently surpassed Emotet and Trickbot to become one of the most prevalent malware threats. At present it is the #2 most submitted malware family submitted to the ANY.RUN sandbox service, mostly thanks to the Emotet crew appearing to have taken an early Christmas vacation. From pray and spray spam runs through to more resourced campaigns targeting critical infrastructure sectors, AgentTesla appears to have a wide variety of operators. Up until 2019 it was available through the website of the developer, www.agenttesla[.]com, as moreorless a SaaS subscription that included 24x7 support, web management, delivery and packing services, and regular updates:
Predictably, the service was sold with the disclaimer “Agent Tesla is a software for monitoring your personal computer. It is not a malware. Please, don’t use for computers which is not access permission.”, in much the same fashion as open-source RAT’s and ransomware are cautioned on GitHub as being “for educational purposes only”. While cracked and leaked copies of the tool were always available through forums and marketplaces, their availability has naturally exploded following closure of the official service.
As a SaaS offering with a reported 6300+ customers (source: Krebs on Security), it was fair to expect that the feature set and reliability of the tool would continually improve to remain competitive, meet customer requirements and stay ahead of defenses. Current features include:
Occasionally custom modules have been seen in samples, such as the WiFi credential stealer.
Like many varieties of malware, delivery is primarily via email. Compromised email credentials are frequently used for sending, and messages utilise your garden variety logistics, financial and current event templates. Most often we observe the AgentTesla payload attached to messages in an archive, but maldoc delivery is also commonplace. A full spectrum of payload delivery mechanisms are seen being employed by the maldocs, including links, macros, DDE commands and Office exploits (e.g. CVE-2017-11882 and CVE-2017-8570).
Loaders employ obfuscators/crypters for source protection and almost always .NET reflection to load the AgentTesla stealer, as will be illustrated in the following samples.
The sample that we will first investigate in this post begins with a payment themed message that leverages the branding of a Turkish garment company:
Attached to the email is a zip file containing the payload: “swift copy.exe” (sha256: 9d626bb9d442d3762e5366f0fbefae41708936b9c254141fcf3b0a1b80291ebb). The sample is detected by 44 of 71 engines on VirusTotal (report) – so it’s not exactly low key.
The sample is copied to a 64-bit Windows 7 analysis VM that is running a FileZilla FTP server and has a handful of dummy accounts set up, including for CoreFTP:
We know that this is one of the tools that AgentTesla is capable of stealing credentials from, so it is expected that this will prompt the sample to attempt exfiltration.
The debugger used is dnSpy (https://github.com/dnSpy/dnSpy).
“PongGame” may seem like an odd choice of namespace for a loader, but this isn’t at all abnormal for the obfuscators used with AgentTesla. Naming conventions of legitimate programs are often adopted and applied across metadata, namespaces, classes, methods and objects.
The loader imports System.Reflection, indicating .NET reflection is likely used to load additional modules during unpacking:
Before stepping through the execution, we review the program resources, of which there are two that stand out. It is well known that AgentTesla makes heavy use of steganography, so it is safe to assume the single image (XDDVe) will at some point be passed through a decoding routine. However, there is no reference to it in the loader:
There is also a long string that is preceded with TVqQ which is base64 for “MZ”, the magic number for the MS-DOS EXE format:
A reference to this is seen in method “dddddddddddd”, where the value of this resource converted from a URL string token to a byte array using System.Web.HttpServerUtility.UrlTokenDecode, and the byte array then loaded as an assembly. A breakpoint is set prior to the assembly being invoked and execution is run through to this:
This unpacked assembly is MARCUS.dll and the method that will first be invoked is Jarico.Buta. The DLL is also obfuscated and has relatively few classes:
A breakpoint is set on Jarico.Buta and execution is continued through to here:
Shortly after this is an image object is returned by a method that takes a resource name and project name as parameters. Breaking at this point shows that the project and resource are the loader and image:
The image is run through several decoding methods which produces an additional executable:
Stepping through a little further we see the executable is named “IDvurjJAoNJbsjjolQx” and the entry point is the Main method:
IDvurjJAoNJbsjjolQx is an obfuscated executable with a sizable resource named “YMh2sbk1276”:
No direct reference to this is found, however a method is found where a resource is loaded into a byte array, so a breakpoint is set after the array has been formed:
The value of \uE00C confirms that the loaded resource is what was expected. Contents of this resource are passed through several decoding routines to produce another executable:
The memory section is dumped to disk and the resulting file – the AgentTesla stealer – is opened in a new dnSpy session. While still a little obfuscated, the source is relatively easy to read through:
In this sample, configuration items are extracted from a specific position (i.e. offset and length) within a UTF8 byte array and converted to string format:
We can also set a breakpoint prior to HTTP POSTs or email messages being sent to obtain the respective config (i.e. HTTP request or SMTP credentials):
Imports are made for the kernel functions required by the keylogger:
And below these is the method that implements the keylogger:
This second sample illustrates a couple of different aspects of .NET malware: anti-tamper measures and persistence.
Upon loading the sample into dnSpy and jumping to the module initialiser, we are presented with decompiler errors intentionally resulting from the anti-decompiler measures implemented by the obfuscator:
Attempting to run the sample also fails and the method at the entry point of the program appears to be empty. While it is possible to remove these protections with dnSpy by editing the IL instructions, a much faster method is simply running the payload and dumping the unpacked assemblies with a tool such as MegaDumper (https://github.com/CodeCracker-Tools/MegaDumper):
Hollows Hunter (https://github.com/hasherezade/hollows_hunter) is also a useful tool in similar situations.
This produced two executables and a handful of DLLs:
The smaller executable is AgentTesla and the larger is a loader.
In this case, the level of obfuscation is much lower than the previous sample, so more insight into the capabilities can be gleamed thanks to cleaner class, method and attribute names (e.g. DPAPI, HttpToSocks5Proxy, SafariDecrypter, TorBrowser, VaultCli, etc):
While the previous sample used the simple method of storing the configuration as plaintext in a UTF8 byte array, this instead stores an encrypted configuration as a list of unsigned integer arrays:
Among the functions of the loader is setting up persistence via scheduled task. The bytes of the current assembly are first written to a path under %APPDATA%:
A scheduled task XML configuration is then formed, referencing the path of the dropped executable, and written out to a temporary text file:
The configuration is passed to schtasks.exe which sets up the scheduled task according to the XML:
In effect, the scheduled task will run gnFZsnV.exe upon logon. Scheduled tasks aren’t a particularly stealthy method of persistence, so should a suspected victim of AgentTesla be triaged, the scheduled task will be highlighted by Sysinternals AutoRuns (https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns):
If you enjoyed this blog post and want to follow other interesting malware finds that I make, I regularly share them on Twitter: @phage_nz
If you'd like to find out more about how Inde can help detect this security threat, you can contact us here.