We’re Seeing a Resurgence of the Demonic Astaroth WMIC Trojan

By Jerome Doaty and Garrett Primm

The Cofense™ Phishing Defense Center (PDC) has recently defended against a resurgence of Astaroth, with dozens of hits across our customer base in the last week. In just one week, some estimated 8,000 machines have been potentially compromised.

The Astaroth trojan, named for its use of satanic variable names (the “Great Duke of Hell” in ancient lore), has been around since late 2017. Astaroth is known for infecting victims through fake invoice emails, the majority of which originate from a malicious sender impersonating legitimate services using cam.br domains.

Fig. 1 Impersonating TicketLog

This revived campaign has been well planned and supported, exclusively targeting South Americans. All the campaign’s URLs are Cloudflare hosted, only delivering their payloads to South American IP addresses.

Fig. 2 Successful payload download

Astaroth’s initial payload is a malicious .lnk file, a common delivery method used by threat actors. Malicious .lnk files contain a link to a URL (instead of the expected local URI) to grab the next payload.

Leveraging Existing Windows Services to Deliver Malware

Windows Management Instrumentation Console (WMIC) provides a command line interface to WMI. WMIC is a good tool for managing windows hosts and is widely favored by desktop administrators. The verb get can be used in a myriad of ways to retrieve information for a machine, however in this case os get /format: is being abused to download payloads from non-local resources with .xsl extensions. Downloading stylesheets allows for emended JavaScript and VBS to be run from within them, at which point any type of malware could be staged and run quite easily. In the case of Astaroth trojan, the .lnk file contains an argument into WMIC.exe to run in non-interactive mode, which forgoes opening a window that the victim could notice, to download the hardcoded url in the .lnk. and exit.

Fig. 3 WMIC abuse

Astaroth retrieves a .php file from this URL containing a style sheet with embedded JavaScript. Navigating to the web page manually to view:source reveals the code, which at the time of writing happened to not be obfuscated in any significant way.

Fig. 4 Embedded JS in .xsl.

After defining several variables, some of which contain ActiveX objects for file execution and manipulation later, the script uses a function to “roll” a random number.

Fig. 5 “radador” dice roll function

The number selected is then used to select a payload URL from a list.

Fig. 6 Domain list

The code frequently reuses the “xVRxastaroth” variable, potentially useful for future fingerprinting. All the 154 domains listed were hosted on CloudFlare. An increasingly popular tactic by threat actors is to use legitimate hosting services like Google Cloud or CloudFlare for their payload and C2  infrastructure, making it much more difficult to safely block IPs.

Fig. 7 CloudFlare hosting

After the domain has been selected, the payload URL to another stylesheet is loaded using WMIC yet again. The domain that is selected will have the hard-coded value of /Seu7v130a.xsl? appended to it as well as a randomly selected number between 1111111 and 9999999.

For example:

hxxp://ta4dcmj[.]proxy6x-server[.]website/09//Seu7v130a[.]xsl?3314468[.]xsl

This payload contains much more embedded JavaScript and is part of the core functionality of the malware delivery. The same variables that are declared in the initial stylesheet are reused here, including the RNG roller for a payload domain. After selecting a payload URL, the script will create copies of certutil and regsvr32 to the temp directory for later use.

Fig. 8 Making a copy of certutil and regsvr32

Certutil.exe (a copy is renamed to certis.exe by the trojan) is normally used in a windows environment to manage certificates, but in this case, it is used by the second stylesheet to download the malware payloads. The script creates a function that will run the copied certutil in the temp folder with parameters -urlcache and the options -f and -split. This will cache a force fetched URL and save the fetched URL to a file.

Fig. 9 Caching URLs and downloading payloads

This function is used repeatedly to retrieve the rest of the malware payload. A check is also performed to ensure each file has been downloaded to the correct folder before proceeding.

Fig. 10 Ensuring the files have been downloaded

After the malware is downloaded and files verified, the script will check in the C:\Program Files\ directory for the presence Avast antivirus, which happens to be the most common installed AV worldwide.

Fig. 11 AV detection

If there is no Avast install present, the script proceeds to the final .dll execution using regsvr32 and quits.

Fig. 12 The trojan is complete

A database of victims

After the malware is successful in infecting a host it will generate a plaintext log (r1.log) located in the tempwl directory. This log contains the external IP, the geographic location, the machine name, the time the machine was infected, as well as fields to be logged in the threat actor’s database.

Fig. 13 Victim logging

This information is then sent to a sqlite database located in the root directory of the first payload URL as seen in the snippet below. There were multiple open directories in ~/9/. Decrementing the number to 0 revealed several other open directories with downloadable sqlite databases, more than likely from previous campaigns. These victims totaled in the thousands, with approximately 8,000 in a single week.

Fig. 14 Open directory…

Here is one of the databases viewed in a sqlite browser. Each field is base64 decoded.

Fig. 15 Database dump

Decoded, it reveals a detailed log of each affected machine. Note the first entry of a machine hosted on a Canadian VPS. This was the first entry across every database dump gathered and was certainly an anomaly compared to the otherwise South American machines, the primary target of this malware. It’s difficult to say for sure, but this was possibly the threat actor testing his infrastructure.

Fig. 16 Potentially infected machines 

The Malware

After the Astaroth trojan verifies that each core file and binary has been run, the malware payload is executed. It is important to note that any payload could be delivered via WMIC stylesheet abuse, and Astaroth should be considered a versatile delivery method. However, the campaign that the PDC has recently observed has been delivering this keylogger exclusively. Amongst the downloaded files,  the fake .gif and .jpg files appear to be dependencies for the malware. However, their magic bytes are not of any known file type and there are no .text or other PE sections in the hex, suggesting that they are not executable. There does appear to be function names however, including PeekMessageA, which has been previously observed in other keylogging malware. There are also several log files present, and a folder called vri that is also populated with logs as the malware runs.

Fig. 17 Complete List of Malware Files

Fig. 17-2 Magic Bytes of “.jpg” file

Fig. 17-3 Function names

To target specific victims, Astaroth is locale aware; any attempts to run the malware without locale spoofing will result in failed downloads and the inability to run the .dll files. Some cursory analysis of one of the .dlls reveals it was  coded in Delphi, as well as use the GetLocaleInfoA function, allowing it to pull the locale information of the infected machine.

Fig. 18-1 Coded with Delphi

Fig. 18-2 Locale Aware

This problem was easily defeated by changing registry values in HKEY_CURRENT_USER>Control Panel>International to reflect a Brazilian locale, as well as enabling a Portuguese keyboard.  The .dlls are first registered and run using regsrv32 in silent mode. A startup event is also created to gain persistence.

Fig. 19-1 regsvr32 running the .dlls

Fig. 19-2 A startup event for persistence

The malware will run 2 .dlls from regsvr32 simultaneously, spawning userinit, ctfmon, and svchost processes.

Fig. 20 New processes

The malicious svchost constantly queries ieframe.dll, as well as IWebBrowser2 Interface using CLSID dc30c1661-cdaf-11D0-8A3E-00c04fc9e26e, both key components to interact with Internet Explorer.

Fig. 21 ieframe.dll and IWebBrowser2

This is crucial because the malware targets Internet Explorer specifically. To ensure its victim will use IE, it will terminate any process in-focus that is Chrome or Firefox, in hopes the victim will believe the browsers are “malfunctioning.” Whenever a victim uses IE and browses to specific Brazilian banks or businesses, the malware will only then begin to log keystrokes.

Fig. 22 Keylogging and exfiltrating data

The exfiltrated data is base64 that decodes into more custom encoded strings that appear to be “/” delimited. They more than likely must be XOR-ed against a specific string, so decoding is very difficult if not impossible.

Fig. 23-1 Exfiltrated data

Fig. 23-2 Custom encoded strings

Astaroth is a particularly potent threat for South American businesses. This is attack vector presents interesting problems, as blocking or restricting the use of WMIC may not be a feasible solution for some administrators.

Like malicious OfficeMacros, this form of social engineering-based attack is best mitigated with user training and awareness. Thousands of global organizations use Cofense PhishMeTM to do just that. Discover what it can do for yours.

 

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.

Microsoft Office Macros: Still Your Leader in Malware Delivery
Automate Your Phishing Defense While Keeping Human Control

Leave a Reply