JavaScript obfuscator: Overview and technical overview
JavaScript has long been used as a method of hiding malicious payloads, especially via websites. A new development has seen this technology leveraged as a phishing email attack vector.
When it comes to scripting languages, few are as well known, or well implemented, as JavaScript. It is used in web applications and is very popular thanks to its ease of use, massive libraries and the fact that it runs on almost any computing platform.
Parts of these positive attributes have created a real danger for unwitting email users. JavaScript is being utilized in phishing attacks where JavaScript code is being injected into target computers. Phishing attacks that use this kind of method to infect target machines with malicious code have increased by over 70%, as reported by Akamai researcher Or Katz.
See Infosec IQ in action
The following shows the attack types and increases from the report:
- Content escaping obfuscation techniques, 72%
- Base64 encoding, 800%
- HEX encoding variable name obfuscation, 86%
- Eval execution obfuscation, 400%
There are a few reasons why these kinds of attacks have suddenly become popular, primarily because JavaScript is a client-side scripting language. This means that once the script has run on a target computer, the user or victim will essentially be feeding their personal information into a local page.
This page has been generated by the malicious code embedded in the email. This means that it is far more difficult to detect any malicious code up until the asset has been rendered.
Methods used for obfuscation
As most people already know, content escaping is a big factor in these attacks as a means of obfuscation. Obfuscation in programming and coding means that all of the code in an application is reworked to make it difficult, or impossible, to understand. Variables are named to be more confusing, comments are removed, data structures are changed and functions are introduced that confuse and change data.
Some countermeasures can be used to help detect malicious JavaScript code in websites, such as String Pattern Analysis. Similar methods could be used to thwart email attacks but this is not widely adopted at this stage, as seen in the rise of attacks that use this delivery method.
This method is useful only to a point, however, because the information of the malicious payload is normally only revealed upon the page being rendered.
In an example piece of code, Kats highlighted the seven different elements of code used in an obfuscation attack. A payload array is generated, then passed on to another segment of code where a function shuffles all of the payload data. The third snippet of code then retrieves the first payload’s values, and then a second payload is generated. An anonymous JavaScript function then performs additional operations on the second payload, hands it over to the sixth piece of code and then finally the code is executed.
Katz explains, “The page code contains two payload arrays, flagged as sections one (1) and four (4) in the image. These arrays contain the encrypted content of the final page to be rendered, the decoded JavaScript function that is responsible for decryption of the first payload and the JavaScript code keywords such as ‘push’ and ‘shift’ that will be used by other functions on the original page.”
This makes it very difficult for the intent of the script to be known because it is handling the data, looping it into functions that will eventually generate the page data that the victim will see. The result is that much of the data cannot be analyzed without first rendering the page and then debugging it.
There are legitimate, non-malicious reasons for wanting to use a JavaScript obfuscator, especially if you’re client-side. In web browsers, it is possible to view the source code of a web page after it has been rendered, and if your code is not protected then it is easy for a user to copy that code and see what your web application is doing. This opens the door for people to possibly reverse engineer the app.
Developers usually use obfuscation in the source code of an application if parts of that code are exposed to the general public.
Impact on email security
The current wave of email-based attacks is proving more popular thanks to the relative success that the creators of these campaigns are seeing. Criminals around the world are starting to use this new method of scamming unsuspecting users, so it is important for an increase in user education relating to cybersecurity and phishing.
Basic observations about link structures, language used in the email and anything else that raises suspicion need to remain the focal point of email users. The global pandemic has also driven many phishing campaigns that take advantage of people and fool them into sharing information.
If you receive an email that you are not sure about, then it is usually safer to disregard it and contact the company or person directly and ask them if they are indeed trying to contact you. Always follow your organization’s best practices when dealing with phishing.
Get six free posters
Reinforce cybersecurity best practices with six eye-catching posters found in our free poster kit from our award-winning series, Work Bytes.
Is a Javascript obfuscator necessary?
The main takeaway from all of this is that we should remain very careful when accessing emails and visiting websites. Single-layer defenses are no longer feasible when trying to filter out threats. Antivirus software, cybersecurity training, education and user vigilance are the only way to minimize the attack surface of new threats such as this JavaScript phishing attack.
In the case of these JavaScript attacks, it is not even safe to click on any rendered elements that appear within the body of the mail. If you are in doubt about the source, legitimacy or safety of an email, then it is safer to delete it than to click any links or attachments.
Sources:
JavaScript obfuscation on phishing pages continues to rise by 70%, KnowBe4
JavaScript obfuscation moves to phishing emails, DARKReading