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:
These constants are then used in arrays, and run through a decoder function:
do while i =< ubound(in)
GeRSvfK = out
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:
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:
- There are files in
- There is >= 1 GB of RAM
- There is >= 32 CPU cores
- There is >= 60 GB of disk space
- 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:
You can read a very detailed breakdown of how IcedID is packaged, and its behavior in a fantastic 3 part write-up by Fortinet:
|N/A (doesn’t resolve)
I’ve also uploaded a deobfuscated and annotated version of the initial VBS dropper here: