Analysis of a VBS Malware Dropper

Recently, I was willingly forwarded a phishing email ( for science! ) which contained a ZIP attachment, requesting the recipient to update their contact information:

Screenshot of initial phishing email

The hyperlink pointed to https://weitblicker.com/wp-content/uploads/2019/10/goes/JVC_83860.zip . Inside this ZIP, was a heavily obfuscated VBS file (found [ here ] if you’d like to follow along).

JVC_30579.vbs

The VBS seemed to employ numerous techniques to make analysis very difficult. First, the file used many commented random strings which due to the string length (an example can be seen above) seemed to crash or bog down numerous tools. Secondly, various decoy functions masked the true execution chain from being quickly visible. Lastly, the actual data for execution is obfuscated and encrypted.

My process of manually investigating this VBS script started with dealing with the large comment blocks. Deftly, I wrote some simple python (see picture below) to remove any line beginning with a single quotation mark ( ' ), so the viewing of the VBS would be much easier (found [ here ]):

Python script to aid in cleaning up VBS

Now that the remaining VBS could load into a text editor without threatening to cause massive blackouts along the east coast (really just freezing my sandbox), I began to study the execution chain of the VBS. The first thing that caught my eye was the initial error bypass at the top of the script, On Error Resume Next . This would allow the code to continue if an error occurs, such as “ a variable not declared” caught during execution of the script. Below this declaration was yet another clue in what the actual execution chain actually was. Anywhere these variables were assigned a value or called would indicate an actual operation performed in the execution of the malware. The next line was the first in many various fluff operations whose only goal was to clutter the script in an attempt to obfuscate the execution routine of the malware from analysis. (I also ponder whether the extra fluff may aid in evasion of automated scanning utilities due to its size).

Top 3 lines in JVC_30579.vbs after removing long comments

After visually inspecting the entire script, I then decided to start at the very bottom and work my way back up. Understanding that RQa , eBAb , Fcb , UeS , qFf were the only variables declared via dim at the top (and anywhere) in the script, I figured I could ignore the operations below the line eXEcUTegLObAL qFf .

Last four lines in JVC_30579.vbs

Ok, so, executeGlobal ? It would appear that this call in VBScript allows one to execute statements passed to the call in the current namespace [ 1 ]. In the context of this script, passing whatever is contained in qFf will be executed. Above this, ignoring the fluff, there is a WScript.Sleep call, which sleeps execution the number of milliseconds passed to the call. Searching for the variable nREy , I found the following assignment:

nREy = 367–266–20 + 302–14 + 25–18 + 24–21 + 384–360–352–440 + 6 + 251 + 30132 

Solving this, it is apparent that the script sleeps for 30,000 ms (30 seconds) before executing the executeGlobal call as a means to potentially bypass AV sandboxes. After this discovery, I also determined it may be best to highlight only the assignments of variables that were actually declared in order to shut out the noise.

Adding exclamation marks to mark known variables’ assignments

Jumping back down to the bottom, I continued my trek back up the script. Three consecutive calls to a function NpNt were made, assigning a value to the qFf variable.

Variable qFf being assigned the output of function NpNt

Skipping up to the function itself, the following is seen: