We recently announced a new feature that we'd been working towards for quite some time called Script Watch. Allowing you to be quickly notified of new JavaScript dependencies that appear anywhere on your site, Script Watch was a major step forward in the fight against Magecart and similar attacks. Now, to continue pushing back against attacks like these, and arm sites with the tools they need, we're introducing Data Watch.


If you want the background on Script Watch and Magecart style attacks, you should check out our launch blog post Introducing Script Watch: Detect Magecart style attacks, fast! That covers all of the basic details you will need about Magecart attacks and other risks that sites can face from hostile script injection, but here, I'm going to dive straight into explaining our latest feature, Data Watch!

Some background

In the Script Watch launch blog post, I talked about how a Magecart attack typically starts with hostile script finding its way into your website. This can be via an XSS attack in your application, but more commonly, from all of the attacks I've looked at, it can be via a compromised 3rd-party dependency including the malicious code. This puts Script Watch at a bit of a disadvantage and it is something I pointed out in the launch blog post. If you have a 3rd party dependency and they start to include additional JavaScript inside their normal payload, Script Watch isn't going to detect that because it's an existing dependency, not a new dependency. Now sure, I've seen attacks where the existing dependency is used as a bootstrap to pull in new dependencies, but it's not always going to be the case. In the most recent Magecart attacks, the entire attack payload is injected as obfuscated JS into the existing dependency. In order to defend against attacks like these, where existing dependencies are compromised, we have Subresource Integrity, or SRI. I have an introductory blog post on SRI, along with cryptojacking and Magecart specific blog posts that detail the use of SRI, but not all sites are using it. This means that Script Watch is a great starting point, but it's no silver bullet.

The real objective

If we think about it, injecting hostile JS into your page isn't really the end goal of these attacks. Sure, having JS in the page gives attackers the ability to do almost anything, but certainly in the case of Magecart, there's a more important step in their attack that they need to succeed: getting the data out.

Injecting a JS credit card skimmer onto your payments page is great for the attackers, but it's absolutely worthless unless they can actually exfiltrate the credit card data they've just skimmed. They need to send it to a 'drop server', a location setup by the attackers to gather all of their stolen data. This is where Data Watch comes in!

Whilst Script Watch is monitoring and alerting you about new JS dependencies that are appearing on your site, Data Watch will be monitoring and alerting you about new locations that your site is sending data to. This means that Script Watch and Data Watch now compliment each other very well. Script Watch will alert you to new JS dependencies finding their way onto your site and Data Watch can alert you even if an existing JS dependency is compromised and it tries to start sending data to a new location!

An example

RiskIQ have done some awesome research into Magecart and specifically the British Airways incident is a good one to look at in the context of Data Watch. You can read the full RiskIQ Report, Inside the Magecart Breach of British Airways: How 22 Lines of Code Claimed 380,000 Victims, but I'm going to pull the important points out here.

British Airways had an existing JS dependency on their site:


This existing dependency was modified by the attackers to include some malicious JS, but Script Watch is not going to detect it because it's an existing and expected dependency. The attackers added the following malicious JS to the file:

source: RiskIQ

This JS is skimming data from #paymentForm and sending it to a drop server at the following location:


This is where Data Watch would kick in! Even though you have an expected JS dependency on your page, and even though that JS dependency was compromised and still ran on the page, the attackers still have to get their data out, and this is where we catch them, at the point of exfiltrating their stolen data. You'd now get an alert that your site is sending data to a new location and you can even see which pages on your site are sending data to that new location. If your payment pages are suddenly being very talkative to a new, external location, it's time to start investigating, fast!

Data Watch is not a silver bullet

I said it in the Script Watch blog post and I said it further up in this very blog post, even using Script Watch and Data Watch together, there's always a chance that someone creative will find a way. What we can say for sure though, is that you'll be right up there with some of the best, and easiest to deploy, detection possible. Groups like Magecart are highly motivated and highly focused, but the combination of Script Watch and Data Watch would have detected and alerted the site operators for all of the recent Magecart attacks that I've looked at that made headlines using either a form submit or, frequently, an XHR to exfiltrate data. For something that can take literally minutes to setup and costs as little as $49.99/mo, I'm really proud of what we've created.

Getting started

Just like with Script Watch, Data Watch is now available for any customer on a mid-tier plan or higher, and all of our Enterprise customers, at no additional cost. Data Watch does not require additional reports to be sent and as a result, using it will not change your current monthly cost in any way!

We've created a new documentation page to cover the basics of Data Watch and how to get started and as with Script Watch, we've created a discount code to give you 50% off your first month if you're a new customer subscribing or if you're an existing customer than needs to upgrade their plan to get access to Data Watch: DATAWATCH