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
Fig. 3 WMIC abuse
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.
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
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 how phishing awareness training can help your organization defend against trojans..
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.