Concerned about recent PAN-OS and other firewall/VPN CVEs? Take advantage of Zscaler’s special offer today

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

Multistaged Downloader Leverages Google Drive to Download Advanced Malware

March 25, 2020 - 5 min read

Ever use Google Drive? Of course you have—you and approximately 1 billion other people. And it is estimated that those 1 billion users have loaded more than 2 trillion files on Google Drive. So, it’s a pretty big deal when a cyberattack uses Google Drive to deliver its payload. That’s exactly what was happening with a downloader being tracked by the Zscaler ThreatLabZ team.

As you may know, downloaders are often considered the first stage of infection. They usually contain obfuscated codes to download the actual payload. Sometimes they also have some anti-debugging and evasion techniques to safeguard the actual payload from being detected by anti-malware programs. Downloaders often provide attackers with the ability to gain an initial foothold in the system.

The Zscaler ThreatLabZ team was tracking a highly obfuscated downloader known as Win32.Downloader.EdLoader (the name was given by a Zscaler ThreatLabZ researcher) that has employed some anti-analysis techniques to make analysis more difficult and has been actively spreading during the past few months via a different mechanism. The interesting part of this downloader is that it is leveraging Google Drive to download the final payload.

In this blog, we’ll share our analysis of a campaign using a vulnerability exploit in the initial phase and its use of Google Drive to download a different password stealer in the later phase.

Samples observed in ZScaler cloud

Figure 1: Samples observed in the Zscaler cloud.

The spreading mechanism

This downloader basically comes into the system via spamming campaigns.

During the past few months, we’ve seen multiple spam campaigns featuring various email templates having language specific to the country being targeted. 

Geo regions of infection observed

Figure 2: Geographical regions hit by the infection.

Let’s take a look at how the mechanisms that help the infection spread.

Infection Flow

Figure 3: The workflow of the infection chain.

The user receives an email from the attacker, which contains the malicious attachment in either RTF or XLSM format. 

Mail template

Figure 4: The email template a user receives.

This malicious attachment of the RTF document contains Excel sheets that leverage the CVE-2017-8570 vulnerability exploit to download the initial payload into the victim’s machine.

RTF document with embedded object

Figure 5: The RTF document with the embedded object.

The CVE-2017-8570 vulnerability exploit makes use of a composite moniker in the RTF document to execute a scriptlet of an XML file wrapping the VBScript. In this case, the RTF document has two ObjData files, one of which has an SCT file encoded. This SCT file is then dropped into the %TEMP% folder and executed by a second ObjData file embedded in the RTF document.

SCT file with XML scriptlet wrapping VBScript

Figure 6: The SCT file with an XML scriptlet wrapping the VBScript.

The SCT file contains a hardcoded URL encrypted with a Base64, downloads the initial payload via a PowerShell command and saves it into the %APPDATA% folder, then executes it.

Powershell cmd from the scT file

Figure 7: PowerShell command from the SCT file.

A few of the malicious attachments are XLSM files having obfuscated malicious macros with the function Sub Auto_Open(). When a victim opens the Excel file, a macro code will be automatically executed. Here also, similar to SCT files, a hardcoded URL is being used to download the initial payload and is executed via a PowerShell command.

XLSM file having malicious macro code

Figure 8: The XLSM file with the malicious macro code.

The initial payload is the newly crafted downloader, which uses the shellcode to download the final payload. The final payload is encrypted with a custom algorithm that is decrypted and executed by the shellcode present in the initial downloader.

Downloader analysis

We have successfully tracked down the request and discovered more information about how this downloader works.

It first injects itself into one of the following system processes—RegAsm.exe, MSBuild.exe and RegSvcs.exe—or self-injects using the process hollowing technique. 

Anti-analysis—This downloader uses different anti-analysis techniques:

  • It enumerates all top-level windows on the screen using the EnumWindows API to identify sandbox/emulators. If the count of windows is less than 12, it terminates itself.
  • It patches the DbgBreakPoint and DbgUiRemoteBreakin Windows APIs as an anti-debugging measure.

Patched DbgUIRemoteBreakin API

Figure 9: The patched DbgUIRemoteBreakin API.

  • It tries to detach from the attached debugger using the NtSetInformationThread Windows API and an undocumented thread information class - ThreadHideFromDebugger (0x11).


Figure 10: The NtSetInformationThread API.

  • It checks for debug registers.

Debug Registers

Figure 11: The debug registers.

  • Before making a call to some Windows APIs, it also checks for a breakpoint instruction in the API code.

Checking breakpoint

Figure 12: Checking for a breakpoint instruction.

Payload download and installation

It downloads an encrypted payload. During our analysis, we found different variants that download the payload from Google Drive as well.

Snapshot of encrypted payload

Figure 13: A snapshot of the encrypted payload.

It uses a simple XOR encryption, and the decryption key is hardcoded. We found different variants using different XOR keys.

XOR decryption

Figure 14: The XOR decryption. 

The decrypted payload is mapped and executed in the sample process. Depending on the configuration in the shellcode, the downloader copies itself to the %USERPROFILE% directory. That is where it dropped the two files—self copy and VBScript files—that execute it.

VB script code

Figure 15: The VBScript code.


It creates a run registry key, which points to the VBScript files:


Sandbox detection

Figure 16: Zscaler Cloud Sandbox detected the downloader.



Malicious downloaders have been using advance techniques over the years, but the end goal remains the same - getting malware onto a user’s system. And using a popular user tool, such as Google Drive, to download a malicious payload can infect a large number of machines. The Zscaler ThreatLabZ team continuously monitors and blocks malicious downloaders and other types of advance malware to ensure the protection of our customers.


EDLoader Hash 

Downloaded Malware

























form submtited
Thank you for reading

Was this post useful?

dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.