@HerbieZimmerman found this .vbs script today and I thought I’d take a crack at untangling it. Any.run identified it as Amadey, and @James_inthe_box and @executemalware identified it as Hancitor.
tl;dr: Cleaned up vbscript can be found here.
Looking at the .vbs file, you’ll notice that it is all one one line. Google tells us that the colon character can be used in .vbs scripting to put everything on one line.
We can use Cyberchef to beautify this script. Toss the above into Cyberchef, use Find/Replace to replace all colons with the carraige return, new line.
Once you do that, you’ll get output that looks like this:
This looks much better. However, like most malicious scripts, there’s a TON of extra garbage in there. One way to determine what to toss and what to keep is by searching for how many times a variable is used in the script. In line 2, the variable stMOS… equals 18. But that variable is not used anywhere else in the script. Therefore, I tossed it. The same goes for ZkDmROO… on line 5. It’s not used anywhere else and it can deleted. In fact, the pattern you see in lines 4-6 are seen over and over again in the next 1339 lines. Get rid of all of them.
Line 7 contains a very long array tossed into a variable named YicSb…. That one is used more than one time so we will keep it. In fact, lines 7 through 33 all contain very long arrays. Let’s look at variable in line 7 and see how it’s used. Maybe it will lead us to a de-obfuscation function?
7: YicSbOZkZH=aRray(B2,G5,a2,T5,T2 42: uHBDkSZKU=YicSbOZkZH 276: RcuccVWXSm=ARRAY(UHBdkSzkU,quvWCOuE,oWkjOwMb,...) 280: For Each File in RcuccVWXSm 281: rvCMVjqVws.WRITEteXt ULhfLslQ(File) 282: NeXT
Line 276 assembles all of those long arrays. Line 281 runs a function called ULhfLs1Q on it. It’s a good bet that is our decoding function. Here it is after the junk has been cleaned out of it:
funCTiON ULhfLslQ(lHVfMJFxTm) WZvLcrdAj=0 mzmedRaNw="" do wHILe WZvLcrdAj =< UbouND(lHVfMJFxTm) mzmedRaNw=mzmedRaNw+ChrW(lHVfMJFxTm(WZvLcrdAj)-71) WZvLcrdAj=WZvLcrdAj+1 looP ULhfLslQ=mzmedRaNw end funCTiON
But I don’t like looking at those variables. Here’s my cleaned up version.
funCTiON converthex(input) count=0 output="" do wHILe count =< UbouND(input) output=output+ChrW(input(count)-71) count=count+1 looP converthex=output end funCTiON
Here’s how it works. It may seem that each element of the array is taken, 71 is subtracted from it, and the result is changed from hex into ASCII. However, looking at the very end of the script, we see about 321 “const” statements. These swap out the different elements in the arrays for digits.
71 is then subtracted from those values, the result is changed from hex into ASCII, and the result is appended to the output.
Applying this decoding function to the various parts of the script, a few interesting things pop out. There are certainly more than these few.
The script obviously does all of the deobfuscating. But I didn’t have any sort of way to walk through the script, look at the variables, and see how it worked in an interactive way. I’m sure something like that exists, but if so, I don’t know about or have access to it.
So what is the not-so-quick-but-dirty way of doing this?
I made a .vbs file using the deobfuscation function, all of the const statements, and finally a few lines to output the results to the screen. It looked something like this:
funCTiON converthex(input) count=0 output="" do wHILe count =< UbouND(input) output=output+ChrW(input(count)-71) count=count+1 looP converthex=output end funCTiON cONST s9=184 consT G7=92 cONst E2=170 [put rest of const statements here] var=converthex(Array(paste comma-separated array values here)) wscript.echo var
Save that to a .vbs file and you can use PowerShell to call it up using “& cscript.exe [path to file]”
You will see that the results will spit out and you can keep going on your merry deobfuscating way.
Thanks for reading. Remember, the cleaned up output is at the top.