Deobfuscating and Analyzing a VBS dropper

Last week, I received an interesting email. It included some vague details about why I needed to download and view the attached invoice. It was something I had been waiting to receive for months. Finally, among a sea of random financial schemes and fraud, I had access to spam containing actual malware. Time to pull it apart!

The Dropper (stage one)

The initial file is a zip, with a vbs file inside of it. The zip is likely just to make it harder for more naive AVs to detect it. The VBS has a few different obfuscation techniques in place. The most significant of these techniques revolves around the manipulation of integer arrays into shifted strings. To do this, the program has a large number of constants defined:

conST r2=27
CONsT rr2=38
coNSt C5=42
cOnST D4=130
ConST t=132
coNst g2=146
...

These constants are then used in arrays, and run through a decoder function:

Function GeRSvfK(in)
  i=0
  out=""
  do while i =< ubound(in)
    out=out+ChrW(in(i)-13)
    i=i+1
  loop
GeRSvfK = out
End Function

Essentially, GeRSvfK just subtracts 13 from each item in the array and gets a character from that value. Using this, I was able to decode a large portion of the dropper script and take a closer look at some of the functionality. I wrote a quick tool for decoding any given array to make this easier:
https://gist.github.com/Plazmaz/2ee343040322814aa91416585852832e

Some of the more interesting components of this dropper are the targeting and anti-debugging techniques in place. It checks various aspects of the system via WMI services, and it will only execute if the following conditions are met:

1. There are files in %TEMP%
2. There is >= 1 GB of RAM
3. There is >= 32 CPU cores
4. There is >= 60 GB of disk space
5. There is >= 1500 MB total VRAM

Additionally, there are two additional checks that don’t revolve around system requirements. First, the program will open an alert box with this message:

User <username> An unexpected error has occurred. Your request cannot be processed at this time. Please try again later. (0x1368084)

While this seems unimportant, what’s actually happening is the program has started a timer, and detects how long it takes for the user to close the alert box. If this time is less than two seconds, the program exits. This is likely due to behavior of certain sandboxes or debugging programs.

The second check is a process check, to determine if any programs on this list are running:
https://gist.github.com/Plazmaz/4ea742541ba2eb6ad75e38348145882f (oddly enough, “mmr.exe” is actually in there twice, which may provide some value to cross-reference w/ other similar malware). This seems to be mostly debugging and AV tools, although it also includes some developer tools, such as “ping.exe”. This behavior is not necessarily new/unique, but is interesting regardless.

If all the above checks pass, the program will then construct a zip file in memory by decoding and combining several large arrays. Then, it will load the executable stored within the zip and run it. This is the end of the first stage.

The executable (stage two)

By looking at the behavior of the unpacked executable in a sandbox, it looks to be a variant of the IcedID malware. It uses the same technique of grabbing C2 servers by opening a websocket the first site, dioneras.top/data2.php?1C00C7CC98D464FE , which provides several other C2 domains:

leonopic.top
piloresi.top
emperimen.com
uniresio.top

You can read a very detailed breakdown of how IcedID is packaged, and its behavior in a fantastic 3 part write-up by Fortinet:
https://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-one.html

Notable IoCs

Files:

Domains:

HTTP:

I’ve also uploaded a deobfuscated and annotated version of the initial VBS dropper here:
https://gist.github.com/Plazmaz/7a9285e392a4dc0eeb4048c141c1c14c