In the first part of this analysis have been presented the two types of macro-enabled documents with powershell downloader spreading via emails in recent campaign. The powershell downloaders and/or the macros were slightly obfuscated, however, it was easy to defeat this obfuscation and reveal their purpose.

Unfortunately, during my analysis the downloaded content was not present on the involved servers and also in the most cases it was not available even during the analysis on sandboxes like Any.Run or Hybrid-Analysis. But after a while, I was able to found at least one analysis at Any.Run, in which the powershell downloader successfully downloaded the malicious content. So, in this article is covered this one case.

Powershell downloader

The second document from the first part of my analysis is actually the one sample mentioned above, which Any.Run report contains the downloaded data. Recall from the last article, the analyzed document contains macros, which lead to execution of the encoded powershell command. After decoding we can see the following powershell downloader:

Fig. 1: Decoded Powershell downloader

The first URL hxxp:// (which is supplied to the method DownloadString) was active during the execution at Any.Run, so we can see the downloaded content, which is then invoked as an powershell expression (IEX from the picture above is the alias to the commandlet Invoke-Expression).

Fig. 2: Captured communication with malicious URL

Fig. 3: Downloaded end executed content from the malicious URL

It is not obfuscated, and it is clear that this piece of powershell script download and execute string again, but this time, the content is downloaded from pastebin. However, during the campaign only the 8 AV engines detected this unobfuscated 2nd stage of powershell downloader:

Fig. 4: Detections of 2nd powershell downloader

Moreover, the downloaded content from pastebin has even less detection ratio, with the score 169 only:

Fig. 5: Detections of pastebin content

Before we can proceed with this content from pastebin, it is useful to remind the behavior of the 2nd powershell downloader:

  • download and execute script from hxxps://
  • execute function Invoke-HQLAPCCSDIGBUMKZIHEIZPFSX (probably defined in the content downloaded from pastebin)

Powershell injector from pastebin

Now, let’s continue with pastebin’s content. It is mostly unobfuscated powershell script, too. It seems that only two function names are partially mangled: Invoke-HSOAWYAZUAGTMWM and Invoke-HQLAPCCSDIGBUMKZIHEIZPFSX mentioned above. Also the parameters of these functions are readable, and we can found names like PEBytes, ExeArgs, ProcName and ProcId, which give us the sense of what this script is probably able to do.

Fig. 6: Powershell script from pastebin

Scrolling down the script, we found the code related to the structure of PE files like headers, sections, imports and exports, and code for accessing the Win32 API functions often uses for code injection, like VirtualProtect, WriteProcessMemory, CreateRemoteThread.

Fig. 7: Powershell code related to the structure of PE files

Fig. 8: Powershell code related to the structure of PE files

This code is pretty-formatted and easily readable with meaningful variable and function names, unlike the macros and powershell from the first part of analysis. It is a reason for assumption that this code is copy-pastes from some publicly known tool. Trying to search for code snippets will bring us to the PowerSploit’s Invoke-ReflectivePEInjection. Yes, its name is self-describing, this script performs reflective injection of PE file (DLL library) into desired process and also loads all of the dependencies of the injected PE file.

This PowerSploit’s Invoke-ReflectivePEInjection looks very similar to our pastebin’s content, with one big difference at the end of our sample: the function Invoke-HQLAPCCSDIGBUMKZIHEIZPFSX containing Base64-encoded data used as the PEBytes argument of the function Invoke-HSOAWYAZUAGTMWM, which is the renamed function Invoke-ReflectivePEInjection from the PowerSploit:

Fig. 9: Base64-encoded PEBytes

Injected PE

After decoding the PEBytes32 we get the DLL file, which is detected by the VirusTotal and Intezer as a GandCrab ransomware:

$ -hash 6aa3f17e5f62b715908b5cb3ea462bfa6cecfd3f4d70078eabd418291a5a7b83

  ██╗   ██╗████████╗████████╗ ██████╗  ██████╗ ██╗
  ██║   ██║╚══██╔══╝╚══██╔══╝██╔═══██╗██╔═══██╗██║
  ██║   ██║   ██║█████╗██║   ██║   ██║██║   ██║██║
  ╚██╗ ██╔╝   ██║╚════╝██║   ██║   ██║██║   ██║██║
   ╚████╔╝    ██║      ██║   ╚██████╔╝╚██████╔╝███████╗
    ╚═══╝     ╚═╝      ╚═╝    ╚═════╝  ╚═════╝ ╚══════╝ v0.9.3
 Find the name of the evil
 Robby Zeitfuchs, Mark Lawrenz
 Copyright (c) 2013-2015

--- scanner malware classification ---
  ransomware: 10
     dropper: 0
     exploit: 3
  downloader: 1
    riskware: 1
     rootkit: 0
        worm: 0
      trojan: 8

--- average detection rate ---
count hashes: 1
totalscanner: 60
   positives: 30

--- scanner malware family determination ---
Most frequent word: gandcrab (count=9)
Second most frequent word: malicious (count=3)

Fig. 10: Intezer analysis of GandCrab DLL

Also, examining the strings from this DLL reveals the original filename of this DLL file: krab5.dll, which points to version 5 of the well-known ransomware GandCrab. The mentioned analysis of this sample from Any.Run ended with GandCrab infection, too:

Fig. 11: GandCrab ransom note from Any.Run analysis


While the most of the contacted URLs in the Ursnif campaign from February 2019 have been cleaned (or, at least, haven’t provided any malicious content during my analysis and during publicly available analysis on various sandboxes), at least in one case one URL was active. This one URL came from the powershell downloader with two options/methods for downloading and executing the malicious content. Probably the one method has been used for downloading the Ursnif malware and second leads to the infection with GandCab ransomware: the powershell downloader included in the VBA macro have downloaded the 2nd stage downloader, which uses the PowerSploit Reflective Injection for injecting the GandCrab DLL into its process. This case have been covered in the 2nd part of the analysis.