JS Malware Obsfucation
Obfuscation
An integral part of malware development or at least trying to figure it out centers around a practice called Obfuscation. Obfuscation is ‘[t]he alteration of computer code to preserve its behavior while concealing its structure and intent’.. Deobfuscation is the process of turning unreadable, or comically obscure code into something readable. To me, the practice of doing it in Javascript is interesting because it seems like the last language you would want to use if you’re developing malware. Out of this line of thinking, I wanted to spend time exploring how JS malware operates and how people use JS to infect machines.
How are JS Viruses launched?
Primarily JS Malware uses Windows Script Host/WSH to do the majority of the work. Most people who write these viruses are not using NodeJS itself to do anything. WSH launches a Javascript file and then depending on the use, they either use WSH to write files or ActiveXObjects to write files. I am open to being proven wrong, but at the moment I cannot find one that targets Unix systems as a single JS file itself. With this in mind, we can move on to what I think is the more interesting part of this conversation. What techniques are commonly used to make these files unreadable
How do malware authors mask intent or structure?
Hex and Unicode
Any set of characters in Hex or Unicode is supported by the lexical grammar rules that JS interprets. This has legitimate and ambiguous uses but I would suggest following the lexical grammar link posted earlier. A clear example of how I have seen this used in the wild is:
String['\u0070\u0072\u006f\u0074\u006f\u0074\u0079\u0070\u0065'].test = function(){
console.log('test');
}
This creates a prototype function called test, which under the hood is interpreted as:
String['prototype'].test = function(){
console.log('test');
}
I have also seen this used to hide commands used by WSH or ActiveXObjects.
Eval
Eval is kind of a fun, nasty, and slow way of hiding code. This often uses hex, unicode, base64 decoded strings, or charCodes to hide a payload. We can take a quick look at eval to see how it works. Let’s say I have a string that is a complete block of JS Code. I can run it as the following:
eval("let murr = 1200; console.log(murr);");
1200
We have this eval statement that reads a variable called murr and logs it to the console. We then get an output of 1200. Simple enough. How this is used in the wild, is it’s often used to do more dirty work. Any time you see an eval statement, you should have some yellow-to-red flag go up in your head.
Function and Variable bloating
This is relatively straightforward. Let’s assume I create a ton of variables, that call other variables that do nothing in any meaningful way. You would rightfully assume I am a prick if you had to clean up my mess. This is not unknown to developers in any case. It’s not indicative of malware but poor practices. Now let us also assume I do this with functions as well. I declare them with awful names and then write functions that call functions that might or might not do something useful. This is a layer of fatigue that makes it difficult to clean up. If I saw all of the following in a file, I would assume that the author of this file is trying to do something sneaky.
Comment bloating
This also is pretty upfront. I have looked at Wikiloader, SSloader, and a few other samples, and they will bloat the code with a lot of comments. These are often just words to fill space or sometimes contain more code to obfuscate the payload further.
Closing thoughts
There are probably other ways that we can think of how code can be made hard to read. I am not assuming that this short post is a universal truth making it a pain in the ass to understand. I do think that this is a generally good rule for what to expect if you choose to do this in your free time. How these are implemented is more interesting than at face value, and that is what I am trying to move towards. Hopefully, this builds an interest in you, the reader, as much as it does me.
