Pipka: A New Breed of Anti-Forensic Malicious JavaScript

Pipka is one of the most interesting and notorious types of JavaScript skimmers we’ve seen so far. It brings higher level of sophistication, creativity and boldness like never before, as well as putting harder challenges to website security practices.

In November 2019 the Visa Payment Fraud Disruption (PFD) team exposed that earlier in September, a new type of malicious script attacked a “North American” e-commerce website and approximal 16 additional websites. The newly discovered script was later named “Pipka”. But the real story of Pipka doesn’t refer to the number of websites, it’s about the future of JavaScript skimming and the evolving struggle with new cyber arms race on websites.  

Pipka Malware Attacks Background

Similar to other malicious code in websites, Pipka also exploits weaknesses of external installed scripts in order to conduct sensitive data theft. Though we’ve seen it before, Pipka, is different.

To start with, this malware is designed to avoid duplication by an operation that checks whether the code has already been sent or not. But it has another very exciting characteristic and that relates to its efforts to try to reach fully undetected (FUD) status.

Once Pipka attacks a website and commits the malicious action it was designed for, the code removes itself from the infected pages and disappears.

This self-removal feature is a usually typical on desktop malwares that invest much effort to stay hidden. But so far, JavaScript skimmers have not used this ability, except for the normal JavaScript obfuscation.

A Different Kind of Online Skimming Code

Like the Magecart attacks, Pipka malware also injects a hostile code into the target website, allowing online credit card skimmers steal valuable information. Despite the resemblance, Pipka is exceptional at its level of being stealthy and immediately removing itself from the HTML code after execution.

This is why this malicious code is unique and becomes barely detectable, not only by traditional security tools, but also by newer tools that lack the ability to provide dynamic ongoing monitoring and detect behavior modifications.

In this case, we can see how Pipka’s removal feature, points at the differences between what’s considered as static and dynamic from both coding point of view and security practice perspective. The one thing we must take into account regarding the new generation of JavaScript online skimming is the technology behavior. Here and by definition, JavaScript code on webpages is a dynamic component.

Dynamic code requires an approach that can handle it, and this case a methodology like penetration testing or code review simply won’t do. Furthermore, looking at JavaScript skimming from a website security perspective, with an emphasis on detection capabilities, demonstrates why an ongoing monitoring processes are so critical. Especially in such instances that involve dynamic malicious code.

As simple as it sounds, scripts are not supposed to remove themselves from a webpage. But when it does happen, an almost natural assumption would be that this deletion action is intended to hide the script itself and most likely specific action it did. Such action will be detected by a dynamic browser platform that tracks and captures all script actions. If a deletion or a removal process is involved, it will just raise more suspicion, nothing more.

Avoiding the Next Generation of Website Supply Chain Attacks

Over the last decade we’ve seen how organizations increased their security perimeters dramatically to upgrade their defensive capabilities for IT environments. The emergence of Pipka and for surly its new imitators in the future, proves why websites have become far more vulnerable, as we speak.

It also provides us an almost “live” demonstration of the actual struggle between attackers and defenders. The new phase of anti-debugging security tools is a fine example of how defensive techniques evolve. But in the case of Pipka and its lookalikes, common security practices will only work partially.

Now, we should ask ourselves what needs to be done in order to avoid this kind of highly sophisticated attacks? To answer that question, we must take into account how the attack itself is conducted. Obviously in the case of what we can refer to as dynamic attacks, an ongoing behavior analysis will solve it.

The focus in this case refers to what we, at Reflectiz, call the WWW tringle: Who, What & Where, meaning What information it collects, Who collects it, and Where the data is being sent to. More specially, on each “W” segment it relates to the behavior of the malicious code and the channels of communication it uses, the detection of anomalies in webpages, as well as other variables. All becomes critical. In practice, an efficient methodology will have to involve a dynamic behavioral website analysis that refers to the WWW triangle as a whole.

This practice includes continues website monitoring and dynamic baselines, allowing security teams to track and detect any third-party code modification from every possible aspect and eventually mitigate dynamic JavaScript attacks efficiently and effectively.