Astaroth whitepaperMar 29th, 2020
Malware of the day
The Astaroth info-stealing malware uses multiple fileless techniques to install on a computer and steal passwords. This malware family has been tracked for a long time, notably by the Microsoft Advanced Threat Protection (ATP) group, and signatures were developed to monitor their activity. However, in order to avoid detection, Astaroth recently changed its fileless techniques. Notably, it now avoids the use of WMI (which was a trigger for previous detection) and instead hides via alternate data streams (ADS). The following post by ATP describes the changes:
So, how would this new version be picked up in SMARTSentinel, the engine behind the SMARTMonitor service?
Let’s start by looking at thebreakdown of the infection chain published by ATP. The report identifies 5 stages:
- The infection stage, where the spearphishing component drops the initial zip which gets decrypted to start the infection chain;
- The stager phase, where the additional malware components are downloaded;
- The main script phase, where the different malware components are reassembled in preparation of their injection in memory;
- The injection phase, where the malware is injected into memory via process hollowing;
- The monetization phase, where the attacker actively puts his malware to work to steal passwords.
In this infection chain, our coverage model would detect several items in the first three stages, where the malware is being installed. Phase 4 and 5, where malware purely resides in hollowed processes, would leave few traces that would be observable in our current model. However, that gives us plenty of opportunity of catching it.
Figure 1 illustrates which component of the attack chain would be picked up by SMARTSentinel and sent to a SMARTMonitor analyst for review.
Let’s break down each detection opportunity.
One of the great tricks of Astaroth is that its delivery ZIP package contains files that appear at first glance as innocuous. This would not generate analert in SMARTSentinel, however, one of the files, the LNK file, is actually a BAT script that calls CMD with the following command line (reposted from ATP):
This would show up as a command line that needs to be reviewed by an analyst, and particular care would be applied because CMD is a known living off the land binary (LOLbin). An analyst would immediately flag this as suspicious because of the obvious attempt at obfuscation, which is not a hallmark of legitimate use.
An analyst would see the URL and immediately identify it as non-legitimate. Furthermore, they would see the .zip file is saved with a different extension. This blatant attempt at obfuscation is not seen in legitimate programs and would be an immediate marker of foul play.
Finally, the alternate data stream abuse and the reconstruction of the malware DLL, while difficult to detect for traditional AV products, would be trivial to detect from the daily command line review. After all, these techniques are essentially never used by legitimate software, so, they stand out very clearly as anomalies.
First, the ADS abuse uses the following command line provided by ATP:
Which would be automatically reviewed extensively by our team because CMD is a known LOLbin.
The same applies to the creation of the DLLs
Which would trigger command line review for CMD, a known LOLbin. The presence of type, a rarely used command to read text files at the command line, would draw the analyst’s attention. Then, it would be evident that no legitimate program would create a DLL in this manner.