V4ensics has observed multiple malware campaigns, which start with a fake Captcha page. The victim visits this page either by visiting a spear-phishing link or just, as seen recently in multiple occasions, through a seemingly benigh advertisement / popup in a site, which hosts pirated content (movies and tv series).
In the fake Captcha page, which the present article analyzes, v4ensics was called to investigate the case of a user, who visited a popular site, which hosted pirated movies and tv series. The user was bombarded with multiple popups, presenting him with seemingly benign advertisements. One of these advertisements constituted the first stage of a Lumma Stealer campaign, which by, inadvertently to the user, going through multiple stages, started with the simple advertisement and could end up with the victim being infected by one of the most notorious infostealers in the wild, Lumma Stealer, unless something went wrong in the process (e.g. a security solution blocked one of the campaign stages making it in this way impossible for the final campaign payload to be executed). While visiting the “original” site (in the examined case site with the pirated content) the victim is directed to another page (hxxps://gubanompostra[.]fly[.]storage[.]tigris[.]dev/emogaping-gotten-into-gubano.html), which consists of a fake captcha verification box. The page asks the intended victim to perform specific actions, which end up with the victim running a malicious command through a Windows OS run.exe prompt, so that the victim is verified as Human.
The command, which is initially copied to the victim’s clipboard is a Powershell command that uses Windows Common Information Model (CIM) to spawn a malicious mshta.exe process. The latter is used to parse and execute the code of an .hta file (Windows HTML Application) located at hxxps[://]iankaxo[.]xyz/mikona-guba[.]m4a.
The file mikona-guba.mp4, which is in fact a malicious .hta file, is highly obfuscated. The file begins with an alphanumeric string, followed by seemingly “junk” bytes. A part of the alphanumeric string is displayed in the first of the following two images, while the second one, a portion of which is depicted in the second image, contains seemingly “junk” bytes.
Analyzing the seemingly “junk” bytes, a couple <script> tags were identified. Some of them contained invalid code (see below).
However, 4 of these <script> tags were correctly structured and when combined, they provide the algorithm for decrypting the next stage payload.
The code depicted above, takes the html code of the page from indices 27 to 29295 (which correspond to the characters of the alphanumeric string mentioned above and depicted partially in image 3), applies a regular expression (/(..)./g) to the obtained characters , and then returns the string from the hexadecimal numbers that matched the regular expression. The returned string is again an obfuscated Javascript code snippet.
This time a function (fitWP) takes as argument an array of decimal numbers and is used to decrypt the next stage by subtracting the number 814 from each number. The two variables, which get “decrypted” in this way, are named YqIKx and RUYP.
RUYP decrypts to “WScript.Shell” and is used to create an ActiveXObject that will execute the decrypted payload residing in YqlKx. This payload is an obfuscated powershell command.
Image 8: Contents of the obfuscated Powershell command
The powershell command performs AES-CBC-128 decryption. The key for decryption is obtained by converting the hexadecimal string “747174685470416C6C4C4D6E52767748” into the ascii string “tqthTpAllLMnRvwH”. The IV corresponds to sixteen null bytes. The decrypted payload is depicted below.
The decrypted payload is Powershell code, which creates a WebClient object and uses the function DownloadString with the url hxxps[://]mapped01[.]sportsspot-moviebuffs[.]com/gubaa01[.]png to download the next stage of the malicious campaign. After downloading the file gubaa01.png, the command “Invoke-Expression” is used to execute the payload.
The gubaa01.png file is of course not an image file, but actually an obfuscated powershell script. The script consists of (a) an initial part of obfuscated powershell code with its main purpose being the construction of an XOR-key and the deactivation of AMSI communication and (b) a second part which converts a byte array to a base64 string, decodes it and uses the generated XOR-key to decrypt the next stage.
The first part of the script consists of thousands of lines.
The function responsible for decrypting the next stage is depicted below.
The xor key is stored in the variable $kWWdZHmACOtYIyNpcRcHGQOmyvOGTxFgFyNnpNvaDrmPwvPH.
Before the key obtains its value, the malicious powershell disables the AMSI communication with the antimalware product running on the PC by setting the amsiInitFailed variable to $true, a technique explained in an article by Mdsec.
The payload used to that end is (post performed deobfuscation) is depicted below.
Subsequently, in order to verify that the AMSI bypass executed successfully (AMSI communication was disabled), function System.Management.Automation.AmsiUtils.ScanContent is used on payload “Invoke-Mimikatz”. “Invoke-Mimikatz” usually triggers the signatures of antimalware products resulting in detection of malicious content. The expected by the malicious payload return value is AMSI_RESULT_NOT_DETECTED , which denotes that AMSI has been successfully bypassed. This value is passed to the variable-key$kWWdZHmACOtYIyNpcRcHGQOmyvOGTxFgFyNnpNvaDrmPwvPH to be used for XOR-ing the payload of the next stage.
The full code, which is used to obtain the key (post performed deobfuscation), is depicted below.
Finally, with the last part of code contained in the powershell script, the next stage is executed.
This command corresponds, post deobfuscation, to the command depicted below.
If the AMSI bypass result is not the expected one, then the next stage will not be decrypted correctly and the malware pipeline will crash.
The next stage uses an AMSI bypass script, by patching CLR.dll, a technique explained in a relevant article.
The AMSI bypass script is the same as the one found in a public Github repository.
Following the AMSI Bypass payload, the malware to be loaded is assigned to a variable in base64 encoding. This malware is a dotnet dropper which is decoded and then invoked.
Upon loading the dropper into iLSpy, two things can be observed:
1. The name of the assembly is Stddetwi
2. The executable is obfuscated by the software SmartAssembly (version 8.2.0.5183)
A less obfuscated version of the assembly can be obtained by using the deobfuscator/unpacker de4dot. After examining the decompiled code, a single function stands out.
The actions performed at this stage, are downloading a file from the internet and then decrypting it using AES-CBC-256. The key, IV and URL are obtained through the resources of the assembly. The process of loading the resources however is still obfuscated by SmartAssembly.
As the decompilation was not very enlightening in finding the required values , the original assembly was loaded into a hex editor. Searching for strings, lead to the discovery of some interesting base64 encoded values.
The strings (at least the printable ones), decode to the values listed in the table below.
Among the strings, 3 in particular stand out.
The dropper accesses a mediafire link to download the main malware and decrypts it via the aes key and iv listed in the table above.
The decrypted malware constitutes once more a dotnet assembly, packed with .NET Reactor (as deemed by Detect-it-Easy).
An overview of the executable is provided in the following image, taken directly from iLSpy.
The malware contains some encrypted executables in its resources, that are decrypted on runtime. It uses more sophisticated techniques than the previous stages.
Using .NET Reactor slayer a more readable version of the malware can be obtained. The following screenshot is taken directly from DnSpy, which was opted for at this point, due to the fact that it supports dynamic analysis and debugging of the executable (assembly).
Reverse engineering the partially deobfuscated program, allowed a greater understanding of its functionalities.
The executable contains the main payloads and configurations in its resources in encrypted form.
It uses multiple methods to decrypt and load the resources. These include the use of Costura library, AssemblyResolve and ResourceResolve callbacks.
The first resource, namely “BgL59yXUnWjxEyq3ut.MCbJbP2lE2ALpeSgJi” is decrypted into the assembly “0b273fb4-1d7e-4bfa-b8d2-dabc722e4286”.
Afterwards, the resource “uAcug” of the obtained assembly is decrypted into the executable “pcElkpeiJJPd” (whose assembly name is “res”).
The latter, contains a resource called “KLKx” which is decrypted and provides some strings used by the .NET executable. These strings include entries related to:
· Anti-sandbox techniques, like cuckoomon.dll, VMware|VIRTUAL|A M I|Xen, select * from Win32_ComputerSystem, select * from Win32_BIOS%;, SOFTWARE\Microsoft\Windows NT\CurrentVersion, Software\Microsoft\Windows\CurrentVersion\Run, which could possibly be used by the malware to fingerprint the machine it is running on in order to detect a possible sandbox environment.
· Anti debugging techniques, like CheckRemoteDebuggerPresent, which corresponds to a function related to debugger detection.
· AMSI tampering, like AmApdxiasiApdxiaScaApdxianBuApdxiaffeApdxiar, aApdxiamsApdxiai.dApdxiallApdxia, which are obfuscated by inclusion of the string “Apdxia” in some positions. When this string is removed, the strings are deobdfuscated into AmsiScanBuffer and amsi.dll respectively, which could possibly be used in amsi disabling procedures.
· Windows Defender bypass, like Add-MpPreference -ExclusionProcess, which is used to exclude files opened by a process from scanning via Windows Defender.
· Wscript.Shell object, like CreateObject(“WScript.Shell”).Run, which is used for running an application or command.
· Tampering with the IP address of the system, like /c ipconfig /release, /c ipconfig /renew¸which are used to release and renew the IP address of the system respectively.
The strings decrypted are listed in the table below.
Two base64 strings that could possibly correspond to key and iv of AES algorithm are also present in the previous table.
Upon decryption, the first 4 bytes of the decrypted stream are dropped and the remaining ones become GZip Decompressed. The decompressed payload is identified as a PE x86 executable which is in fact the actual Lumma Stealer C2 binary.
In order to discover which domains the LummaC2 executable gets in contact with, the binary was loaded into x64dbg.
The Lumma Stealer build is not crypted as evident from the warning message displayed:
The analyzed version of Lumma stealer utilizes ws_32.dll and winhttp.dll in order to communicate with the URLs listed in the table below.
The domains listed in the previous image were obtained via a software breakpoint that was placed in the beginning of the function WinHttpConnect of winhttp.dll, in order to intercept LummaC2 connection attempts.
Five additional URLs were found by performing a ROT15 decryption operation on the current and previous usernames of the steamcommunity account accessed by LummaC2 via URL hxxps[://]steamcommunity[.]com/profiles/76561199822375128.
The obtained URLs are depicted in the image below.
IOCs
A list of files dropped and websites/domains accessed by the the analyzed lumma stealer campaign is provided in the following two tables.
