Today I am going to give you some details on what you might have ran into once that your Anti-Virus / Web-Protection software indicates an infection with the title “JavaScript Obfuscation”.
A brief description of Javascript
First of all we need to understand that JavaScript is a scripting language. Scripts are loaded through the reply to the request your Browser is sending in order to load the page. The scripts then are executed on your home machine.
You can compare this with ordering music, before you get the CD sent to you, you need to send a request to have it delivered (order), then the remote site (music store) delivers the CD, however, you still do not hear the music. In order to hear the music you need to play the CD in you local CD player. The same way JavaScript needs to be run on your computer compared to other scripting languages / programming languages (PHP, perl etc.) that run directly on the remote server to display content.
This explains the first part of the name “JavaScript Obfuscation” so we need to speak about the second part… “Obfuscation”.
Why is the term “Obfuscation” used?
Wikipedia states that Obfuscation is:
“… the hiding of intended meaning in communication, making communication confusing, willfully ambiguous, and harder to interpret.” (source: Wikipedia.org “Obfuscation”)
We already have pointed out that for the execution of JavaScript on your local device a certain communication needs to be taking place. This communication cannot be obfuscated directly by the attacker, at least in most of the cases. However, the malicious code that he is purposely adding to the source code of the website that you are accessing can be obfuscated.
As a programmer you sooner or later would come across the topic of code obfuscation. In software development source-code is obfuscated to make it harder for competitors to copy your product. Else some of the applications a company develops could be easily converted back to source code (for example: .NET C# Applications) and copied, modified and sold by competitors. Therefore I need to point out that obfuscation does not naturally incorporate some evil.
In the case of “JavaScript Obfuscation” the attacker wants to make it harder to interpret the code, of course this is a willful actions, therefore the criteria of the term “Obfuscation” is met.
By making it harder to interpret the code, the functionality becomes harder to understand, and for some webmasters the obfuscated code might look like something essentially needed to run the website.
How is obfuscation done?
I have already shown you an example of obfuscation (and that was specific Javascript Obfuscation) on my last post “Further findings on the Blackhole Exploit Kit”. You can see the source code in the image below:
As you certainly have seen the Javascript shown mostly contains out of numbers. The numbers are stored in an array, you can imagine an array to be a drawer cabinet with each drawer carrying a number and containing exactly 1 item.
The drawers here contain numbers, the script opens each drawer to get the number, does some math with the number and finally converts it to a non obfuscated sign or letter of the alphabet (ascii char). In order to do this the “fromCharCode” function is used, which basically converts a CharCode (which looks like a number) to a char (which looks like a sign or letter).
The combination of the entire signs/letters gives you the malicious script in non-obfuscated nature.

Code retrieved from converting numbers based on malicious code algorithm and converting from Charcode into readable text.
Difficulties with Obfuscation
You certainly saw that there were only a few non obfuscated items in the obfuscated code. The code that was not obfuscated were standard functions of JavaScript that are required to de-obfuscate the code.
Basing a positive detection criterion exclusively on the presence of the functions would result in a high number of false-positive findings, such functions are used by many scripts in a non-malicious way.
Basing positive detection on the numbers present in the code would not do the trick either, the attackers would just change the algorithm for obfuscation and no more results are returned.
Due to the 2 facts mentioned above further criteria needs to be used, such as “Where does the code occur?”, “Is the code a legit item of a CMS?”. As you can see it is getting tricky.
How do I handle the issue?
Getting a warning about the “JavaScript Obfuscation” being present on your website or a website that you visit does not forcefully mean that the code of the “JavaScript Obfuscation” has been added to the website permanently.
In most cases I have seen the code was added through various other mechanism as pointed out on the other posts of this blog. This means when I started looking for the source code shown in the first picture, I would not find anything. However, knowing that the code appears in my traffic protocol, I know that the website is infected.
This is where most webmasters would state “XYZ said my site is infected but it is not…” you may have been looking for the code, which certainly is not entirely wrong. It takes knowledge to handle such cases in a professional way, and it takes time. Furthermore you would need the right tools to figure out what is going on. All this certainly are not items that are available to a webmaster of the website of a small company or even a family website.
Having a strong background in programming as well as in IT-Security I have developed my own tools. The tools make handling such cases easier and in the end help me to provide those that are requesting my help a professional solution.
Depending on the complexity of a case it takes 24h-48h to get a website cleaned, this involves various stages of checking the code for remainders of malicious items. I also check the server logs to take potential steps of locking out the attacker from trying to attack the site again.
As you can see the topic of “IT Security” and attacks on websites can get pretty complex.
Please feel free to contact me in case of further questions.