CG - The Evolution of Magecart Attacks

all right let's get started guys so the next talk is the evolution of Mage card attacks and our speakers for today are gal M and Roman liski I'm sorry if I got the name incorrectly but yeah I'm going to give it to you [Applause] welcome thank you so hello and thanks for coming um my name is gal Mei and here with me is Roman lowski and today we're going to talk about the evolution of magecart which is an uh ongoing research that we are doing for almost 3 years as part of the talk we'll show you some techniques that attackers do in order to uh complicate their attacks and make them more uh sophisticated and

harder to detect let me start with a uh introducing ourselves so I'm gal I'm leaving the threat research team of akamine browser protection group Roman here is part of the team our main field of expertise is the client side security everything that happens inside the browser in terms of uh JavaScript injection Mage cart obviously but also ad injection affiliate FR attack infos Stealers and so on and also a bit of fishing detection the agenda for today will be separated into three main parts we will start with a short introduction about Mage cart we'll talk about what it is how it looks like and what makes it be so dangerous after that we will get to

the main focus point of this talk the advanced attack methods there we will talk about hiding methods and data exfiltration methods H we will talk about the differences between them later and we will end up with mitigations and protections so let's start with the introduction to magecart uh magecart also called uh web scheming or formjacking attack is a kind of attack where the attacker injects a piece of malicious JavaScript code into targeted websites in order to steal uh their end user sensitive data in most cases we are talking about um e-commerce websites where the attacker inject its code into the checkout pages of these websites and of course aims to steal the end user sensitive information such as payment

information credit card data and so on the attack flow so the end user browses online gets to uh a targeted website and reaches the checkout page then there he enters his sensitive information and the JavaScript behind the scenes takes this information and ex filtrates it to the command and control server after that the check out process continue as usual what makes Mage cart so dangerous compared to other other kinds of uh um client side attacks so first of all this is a server server side originated attack the attack itself is delivered as part of the site the code itself is coming as any other resource of the website from the s s side to the web

browser as opposed as opposed of um other client side threats that usually comes part of malware or a malicious extension that installed on the end user machine here we are talking about something that comes from the server side and infects all the sessions of the targeted website it also sets the responsibility for the attack on the website owners and not on the end end user itself second the number of affected users as the attack comes from the server side um uh as a attack comes from the server side every session of the website is infected and in fact every user that will enter his sensitive information into the checkout page will be a Target and a victim of this attack

and last this is a silent execution attack it means that it does nothing to the user experience it does not sh shows popups or thing like that on top of the screen everything is concluded on one single request that is being sent from the web browser to the attacker's command and control server behind the scenes let's take a look on a very basic attack example so we have here uh 20 lines of JavaScript codes that perform a generic Mage card attack um at first we register to an event on the page here we will look for Mouse over event over the submit button in the page when it will be triggered we will start with the data collection we will

iterate over all the input fields in the page we'll take their name or ID and um of course their value with the sensitive information as part of it and in the end we'll send it as a simple xhr request to the uh command and control server uh and that's it we also recorded the here had demo ahead to connect all the points so um this is a checkout page that we created for this Dem demo on the right side you can see the attacker command and control server as part of this page we injected the same simple codes that I just show now I will fill in the sensitive information and once I will overover re

my uh pointer over the place order button you will be able to see a request being sent from the browser to the attacker's command and control server with all the sensitive information as part of it uh in a very few words about the infection methods how sites getting infected with magecart so we see two main vectors of infection the first one is a direct first party infection here we are talking about exploitation of non vulnerability vulnerabilities and cves that exist as part of the technologies that the website is built with or usage of um leaked credentials and tokens and using them accessing uh storage containers and injecting the JavaScript to there the second Vector is supply chain

attacks here we don't Target specifically and directly the website itself we target a third party vendor or a third party service that is loaded as part of the site injecting the JavaScript to this vendor and using its access to the website we actually uh get access uh for the uh malicious script so now we have the basic understanding of what Mage cart attacks are and let's uh talk about the main focus point of the stock the advanced attack methods I will say ahead um some of the methods that we will show right now are relevant for any kind of JavaScript injection and not only for magecart but we will focus on the magecart perspective of this kind of uh

uh techniques and first let me start with the hiding methods so hiding methods refer to anything that attackers do in order to implement the attack in a more Silent Way in the website something that will give it a more legitimate sense um things that will complicate it that will complicate the reverse engineering of the malicious code and uh will help in order to evade from static scanners and I will start with the very basic one I guess those of you are familiar with JavaScript uh won't consider it as something sophisticated ofation basically in a language that can take this simple command line and show it like that you can do almost everything and this is

exactly what of ation is about uh taking a clear code taking its variable names and strings and transforming them in a way that will that they will be less readable and harder to uh understand and complicating also the code execution flow in order to complicate the reverse engineering of the code the motivation here is again to complicate the reverse engineering of the code and also iding uh ioc's that exist as part of it on the other hand as you can see it makes the code look very suspicious uh here you can see two examples of the same simple codes that I just showed you uh being offis skated with two of the most common office CS in the field and as you can

see they look pretty suspicious next we have abusing known Services uh as you can imagine a major part of the decision whether something is malicious or not is based on uh where it comes from the domain name that the attack is loaded from and where it sends the data to uh where the domain name that it connects to uh attles uh use known services and abuse them in order to inject the malicious code to the page and use the um uh domain name reputation of these known services in most cases we are talking about tag managers here you can see an example of a real Attack that used Google tag manager in order to inject the Mage Cod code to the

page um on the first image you can see the actual malicious code AS part of the GTM JS tag after that it being rendered in the page and in the third image there you can see the actual Mage cut request with sens sensitive information being sent and the initiator is GTM JS Google tag manager. JS the motivation as you can see the initiator of this this attack is Googl tag manager.com a domain name that um static scanners want suspect and consider something malicious and uh it will help attackers in order to evade from static analysis scanners and that's next we have the scriptless infection here uh the motivation of the attacker is to separate the uh injection

into a loader a very basic one that will bring the actual malicious code as an asynchronous request and then we'll evaluate it on the page uh as you can see in the example here we have a very basic HHR request that calls and imports the actual code as anxit child Quest and then evaluates it on the page the motivation the actual malicious code is not stored on a specific file so scanners and static scanners uh won't be able to uh take it and analyze it statically and also the request initiator itself in most cases will be the page URL itself as the loader is mostly injected as an inline script to the page and then when

it evaluates the code it will with its uh uh initiator so attackers took the idea of separating the attack into a loader and a a a resource that comes after after it to the next step in what we call Two Steps loaders uh two steps loaders refer to loaders that bring to the page the malicious code not as a clear JavaScript code but there something else such as image or a CSS file take a look on the example here you can see on the left inside uh the loader that is injected to the page uh and as part of it it calls a file named stylesheet.css on the right side you can see the CSS CSS

file um theoretically it looks like a valid uh regular CSS but if you'll take a look behind the scenes you can see that um it contains a lot of white spaces as part of it what happens here the loader takes those white spaces and from them decodes the actual malicious code and then executes it on the page again the motivation is to evade from static scans the actual malicious code is not stored in a file or a JavaScript tag it comes from another resource that later is uh decoded and executed on the page one particular use case of two steps loaders is theography um here we are talking about web scheming Mage cut attacks that

inject to the page both a loader and a hidden image and then the loader takes this image and from it extracts the actual malicious code and evaluates it on the page again the motivation is the same there is no specific file that contains the actual malicious code it is decoded on the go uh as part of the website execution another way to run JavaScript outside of a script tag is running in a non-script tag take a look on the example here you can see an image tag that we created with a source that does not really exist and we set for this image tag an on error attribute once the image will be failed to be imported to the page uh this

JavaScript will be executed and initiate the Mage C attack on the page itself uh static scanners tend to scan the the the website and take only the script tags as part of it in that case we will be able to evade from them as the JavaScript will be run outside of a regular script tag in the the page last let's say that I'm a security researcher and I understand that something is wrong about a specific script and they want to investigate and reverse engineer it we saw many cases where attackers injected to the page uh anti-debugging mechanisms to the to the script sorry anti-debugging mechanisms that complicate the reverse engineering of the code and sometimes even make it

impossible to understand what it performs without modifying and removing this piece of code from the uh injection the most common one is Dev tool check you can see on the screen right now two uh techniques that attackers use in order to detect these Dev tools uh in the browser in most cases the dev tools check come with a self-destruction mechanism once detected the attack stops immediately removes all the traces from the page and we even saw some use cases where the attacker actually burn the IP address of the machine that we browsed from in order to make sure that the same code won't be delivered to it again and now Roman will explain you about the data exitation

methods yeah so so on the next couple of slides I will uh talk about the last phase of typical match card attack which is the data exfiltration phase um so the the idea here is to exfiltrate the stolen data to the command and control server of the attacker uh in a most evasive way and avoid detection so uh the first technique it's a very common and it's used not only in match card but also in other attacks type of attacks as well uh obfuscation and encryption so the uh the Checker will try to send the data um obscurely and not as a plain text in order to make the text unreadable uh so there are different

types of encoding techniques and ofation techniqu encoding and encryption techniques uh one of the most common techniques that we encountered in recent mat Cod campaigns was uh were was B 64 encoding in some more advanced cases we encountered even asymmetric encryption uh there is an example here uh of a case where uh encryption was used uh in order to en encrypt the sensitive stolen data uh so the next technique uh the usage of websocket so websockets is a a communication protocol for a persistent bidirectional communication between browsers and servers and um um the attackers U metod comp attackers usually use uh websockets for two main uh purposes uh the first one is to fetch the malicious code and the second one is

to uh exfiltrate the stolen data using the same websocket channel uh that created in order to fetch the malicious code it's considered uh a less common and a more discrete uh uh network network to transmission NPI and compared to a traditional transmission request like transmission method like xhr uh and fetch request uh and this way the attackers can in some cases evade better for evade better from uh static uh uh security Security Solutions and uh static uh scanners that may run on the affected page uh regarding the one one more word about the example so the example here uh uh illustrate how websocket is connected is initiated on the page uh and uh the the the websocket channel that uh it

creates and used in order to uh Fetch and exper the data uh the usage of uh the next technique is the utilization of HTML tags uh so this technique uh the main advantage of this technique is that deters use uh um HTML tags like image tags anchors and links and links um those those type of tags initiate Network request the techer use uh the tags in order to uh exfiltrate the data they are doing it by concatenate uh the stolen data the sensitive data as a query param to this requests to the this type of requests uh and this way they the the the network request will be sent uh to the command and control server of

the attacker uh uh the main advantage of uh of this technique is in some cases it can bypass uh uh content security uh policy uh restrictions that usually uh Target uh uh script domains and there is an example here that uh illustrates how how this how this technique is works so there is a malicious code in this case the malicious code is upated uh you can see it creates an image tag where the SRC uh points to the the command and control server of the techer uh and the stolen data attached to to the query params uh of the request as a Bas 64 encoded string uh once I decoded the the string uh you can see the in clear text uh the

data that that is sent out uh to theer uh the next technique uh so there are cases in many cases uh uh websites usually e-commerce websites but not only uh use uh third party services for their uh checkout uh process so in such cases they they doing it by uh um U by the usage of if frames or some external third party uh pages in such cases the attacker the the malicious code that injected by the attackers won't have access to the sensitive Fields uh and and there there will be no uh option for deters to to to read the sensitive dat data so to bypass to work around uh this issue uh the techers use a Technique we

call fake forms they create the malicious code creates a fake form that mimics the original form uh that uh the website is Implement uh the fake form injected as an overlay on top of the original form uh and once the data is entered is submitted uh there the uh the tecker will send it uh send it back to his command and control server the example here show how it's done you can see uh two if frames uh the top one is the original form which is hidden uh and the second uh and the second I frame is an i frame that injected by the techer and shown on top of the original one by the way this is uh the only technique

that actually uh impacts uh the user experience since it requires the user to enter his credit card details his personal details twice uh uh so it's a quick demo from a real uh from a real Attack uh from a real website that was attacked recently um that uh combines all the technique that I showed till now that I presented up till now so there is a fake form that injected first uh once the user submit the data you can see that uh a web so you can see the websocket channel on the right side um the the personal data is sent as a b 64 encoded string in this uh websocket channel uh and once I took

this string and uh uh decode it uh I found out that the request included all the uh sensitive data that was entered to the fake form the form that you see now on the screen is the original one uh which presented only after uh the data is submitted uh the first time on the fake inside the F fake form um the next technique is abusing known services so the idea here is using a well-known and trusted Services uh that uh and like telegram or Google tag manager and use those Services uh in order to exate the stolen data uh I created we recorded a quick demo here um so you can uh see how it's

done using telegram uh bot channel so once the sensitive data on this page is submitted uh the malicious code initiate a network request that sent to a uh a telegram uh resource uh but behind the scenes it's a telegram B channel that owned by tcher once the payload uh arrives the the the the uh the stolen data attached as a in as a encrypted string once we decrypt it again we reveal the data that was sent out uh last but not least the last technique is uh slow Bridge it's a less common technique the idea here is to split the exfiltration phase uh into uh two two steps uh so the first step will be on the sensitive page itself once the

sensitive data the credit card data for example um uh will be sub will be entered into the form uh the malicious code will save it uh temporarily in one of the available available uh browser storages like session storage it can be local storage or cookies in some cases um and then uh the malicious code will wait for user navigation and only after the user navigation uh the malicious the sensitive do the malicious code will read the data from the the browser storage and send it back to his commanded control server uh it can be a good technique uh to evade from uh Security Solutions that usually run in a more strict way on the sensitive page

itself like the login page or checkout page so this was the uh Advanced exfiltration Techniques uh the last uh the last part I want to talk about the protection and mitig ation uh um techniques so we split them into two three main groups uh in browser Solutions of browser Solutions and runtime solution as a side note I will add here that uh the latest PCI DSS security regulations that uh released May um last year uh now requires uh each and every company or website that process credit card payment data to implement uh uh browse security measures and solutions uh against match card so the first group uh uh what we call in browser Solutions so the iner

solutions uh uh two two main technique two main mechanisms are um content security policy headers I uh I mentioned them before and Sub sub resource Integrity uh so these mechanisms can provide some some uh uh uh some protection against mag cart uh the main advantages that it's hard to maintain them each and every uh update inside the script or each and every new script that added to the page will require uh some updates uh some update in those mechanisms they are not running in the same context uh as the page and they won't provide a protection if the malicious code injected is part of a thirdparty script um that uh a legit third party script that are uh running

on the page uh off brother Solutions we are talking about scanner or sbes that are external to the browser uh and they are trying to scan run synthetic sessions and scan uh the website um the main disadvantages of this group uh is that uh in some cases in many cases we we encountered uh B detection mechanisms G uh showed some of them um that implemented in order to detect scanners um and the second advantage that that in in case of session sampling um um the scanner May Miss uh the scanner may miss uh the execution of the malicious code uh the last group uh runtime Solutions we are talking about uh uh JavaScript services that are loaded as

part of the page together with the page they are running on real session on in the same context um they have the ability to detect suspicious behaviors like interaction of uh malicious scripts with sensitive Fields uh different anomalies and other uh suspicious indicator s uh they are running in real time and in runtime uh and this is why they are considered a very effective one of the more effective type of solution uh against mcart um that's it thank you very much hope thanks for listening hope you enjoyed that's it