Remember Magecart?
In November last year, security researchers discovered that the the infamous malware, known for harvesting credit card details from checkout forms, [wplinkpreview url=”https://sensorstechforum.com/sites-magecart-malware-reinfected/”]could re-infect even after clean-up.
Now, Magecart is active once again in notorious campaigns in which 277 e-commerce websites were infected in supply-chain attacks. What does this mean?
New Magecart Campaigns Detected
Security researchers from RiskIQ and Trend Micro came across a new subgroup known as Magecart Group 12 which is infecting targeted websites by inserting skimming code into a third-party JavaScript library. This technique loads the malicious code into all websites that utilize the library.
Further research into these activities revealed that the skimming code was not directly injected into e-commerce websites, but to a third-party JavaScript library by Adverline, a French online advertising company, which we promptly contacted. Adverline has handled the incident and has immediately carried out the necessary remediation operations in relationship with the CERT La Poste, said Trend Micro researchers in their report.
RiskIQ researchers have also been closely monitoring the Magecart group. Apparently, Group 12 created its infrastructure in September last year, domains were registered, SSL certificates were set up through LetsEncrypt, and the skimming backend was installed. The hackers also utilize a small snippet with a base64 encoded URL for the resource which is decoded at runtime and injected into the page, RiskIQ’s report highlights.
The group managed to compromise targeted websites through Adverline at the end of 2018.
It should be noted that Magecart Group 12’s skimming code is slightly different, with “an interesting twist” – it protects itself from deobfuscation and analysis by performing an integrity check on itself.
As for the actual injection script, it arrives in two stages, both designed to perform a self-integrity check. Here’s how the two stages take place, as explained by RiskIQ:
– The entire first stage is executed as a function, which is globally defined (this is important)
– The second stage is encoded and padded with junk data, which is written into a new div object
– This second-stage data is then unpadded, decoded, and eventually executed
– The executed code grabs a reference to itself (which was globally set) and is put through a hashing function which is the JavaScript implementation of Java’s hashCode.
– If the check validates the next stage is executed.
Fortunately, Adverline has already fixed the issue by removing the malicious code from the affected JavaScript library.
Milena Dimitrova
An inspired writer and content manager who has been with SensorsTechForum since the project started. A professional with 10+ years of experience in creating engaging content. Focused on user privacy and malware development, she strongly believes in a world where cybersecurity plays a central role. If common sense makes no sense, she will be there to take notes. Those notes may later turn into articles! Follow Milena @Milenyim
Follow Me: