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.
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.
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.