Nowadays the Malware-As-A-Service is one of the criminal favorite ways to breach
During our monitoring operations we discovered an infection-chain designed to deliver this kind of malware to some Italian companies. The attack has been carried out impersonating personnel from the Liberian division of a global Oil Corporate. The malicious email message were spoofed, but the reference to the employee was realistic and suggests he may have conducted some preliminary OSINT.
|Brief Description||Agent Tesla Doc Macro Dropper|
Table 1. Static information about the doc macro
The document uses a common phishing schema, it invites the user to enable the macro execution due to compatibility reasons with older Microsoft Office versions. The document contains an obfuscated VBA macro.
Despite the variable names and the altered code flow, the macro simply decodes its hidden payload and then executes it. In fact, after a series of text replacement the document spawns another Powershell script.
Code Snippet 1
The Powershell stage is substantially composed of three parts: the first is the declaration of function “b72f3()”, having the purpose to deobfuscate the second part of the script, contained into the “$k61b35e” variable. It actually is a C# source code snippet, compiled and loaded within the Powershell process at execution time. Once loaded, the third part of the script invokes the “o81f67()” method of the just compiled “p99a3fb” class.
Code snippet 2
Code Snippet 2 is the C# class to be loaded. It has the objective to download the payload from the drop url previosly decoded by the “b72f3()” function: “hxxp://www.handrush[.com/wp-content/plugins/akismet/views/DurGhamPop[.exe”
The payload is stored into “%APPDATA%\Roaming” path and it is immediately executed through the “Process.Start()” function.
|Threat||Agent Tesla Loader|
|Brief Description||Agent Tesla .NET C# loader|
Table 2. Static information about the AgentTesla evasive loader
The dropped file payload is a .NET executable embedding some anti-analysis tricks. If it is executed on a virtual environment, the malware kills itself. It also uses some anti-debugging trick to decide if terminate its execution.
According to the MSDN documentation, the method Delegate.CreateDelegate “creates a delegate of the specified type that represents the specified static method of the specified class, with the specified case-sensitivity and the specified behavior on failure to bind“. This way, the control flow is switched to the delegated method which actually points to a DLL containing the anti-analysis logic.
Before passing the control to the “swety.dll” library, which is a sort of helper component with no particular scope except the identification of analysis environments, the first instructions executed here are designed to decode and load a byte array embedded inside the executable, unpacking the obfuscated code.
The Figure above shows how this payload is encoded within the byte array and the routine invoked to retrieve it. This byte array is actually a well-formed dll loaded through the “Thread.GetDomain().Load()” method. At this point, the control finally passes to the “swety.dll” library, the module in charge to detect the analysis environment.
|Threat||Swety evasion module|
|Brief Description||.NET Swety evasion module|
Table 3. Static information about the “swety” evasive module
This component is always a .NET executable. The name of the classes are self-explicative: for instance, there are clear references to Virtual Machine detection logic.
In Figure 9, the malware retrieves the information about the current hardware and compares it with a defined set of criteria, when it finds a match, it kills itself. Otherwise, the dll continues its execution and loads another PE file hidden inside the initial loader. This last executable file runs as a new thread within the initial loader context.
|Brief Description||Agent Tesla Payload|
Table 4. Static information about the AgentTesla payload
The extracted payload is a .NET binary file. AgentTesla and Hawkey have lots of pieces of code in common, and the analysis we made two months ago about the Hawkeye payload is similar to this one.
Also in this case every sensitive information, string or other information is encrypted through Rijndael algorithm and it tries to evade the sandbox to the common user names of the principal sandboxes. The persistence mechanisms is practically the same and the installation path of detected during the analysis is “%APPDATA%/Roaming/SecondLORI/SecondLORI.exe”
After its installation, the malware starts to retrieve all the credential stored within a wide list of web browsers, FTP clients, File Downloaders etc. For instance, it is able to steal accounts from:
The harvested credentials are then sent back to the attacker servers. The malware leverages the .NET API to easily set up a mail client to transmit the loot to a particular mailbox.
The name of the sender, “Lori”, matches the name in the persistence mechanism, “SecondLORI”. This username may belong to a previously compromised email account the attacker uses as a sort of SMTP relay to deliver the loot to the real exfiltration address, a GMail mailbox named “email@example.com”.
As we stated in the previous post about a custom weaponization of the Hawkeye info-stealer, these kinds of malware are well known and highly used by cyber criminals. But despite their popularity event into the info-sec community, these “commodity tools” still result to be quite effective especially when combined within custom multistage infection chains, renewing their dangerousness and effectiveness.
Further technical details, including Indicators of Compromise, are reported in the analysis published by the experts at the Cybaz-Yoroi ZLAB.