We recently introduced Target’s cybersecurity tool “Merry Maker” and open sourced the framework to help others protect against digital skimming. Here’s a deep dive into how the solution works and how we built it.
When beginning to design the system, we first looked for the advantages that we as defenders have when dealing with this kind of threat. First, the attacker’s code must be visible to the browser and, by extension, us. Second, to complete their attack they need to exfiltrate data. Third, the skimming code is frequently obfuscated or contains signatures unique to malicious scripts and rules can be written to detect this.
How Merry Maker Works
And, finally, additional detections can be added via Typescript. This allows for more advanced detections to be created.
Running that source results in thousands of events being generated. All of them are brought back and stored, and rules can be created to run against any of them. If a rule hits, an alert is fired. Merry Maker supports three different alert types:
- Basic, which are displayed in the UI
Merry Maker also supports utilizing Indicators of Compromise (IOCs) and will monitor the traffic it sees for known digital skimming domains. These are managed through the UI and enable the user to easily add domains to this “watch list.” These can be from an intel provider or from publicly available lists.
How We Built Merry Maker
Merry Maker has four main components:
- JS Scope (headless browser)
- Scanner (Rules)
- Job Handler
Merry Maker is built to mimic the behavior of real users as they navigate a site: searching for a product, adding it to the cart, entering payment details, and submitting the order. All client-side code that runs during those steps can only be fully executed in a real browser. JS Scope depends on Puppeteer to drive a headless browser with the addition of pre-injected scripts to hook native function calls. JS Scope gives us a better understanding into the behavior of client-side code beyond static analysis. Every hooked function call, web request, response, cookie, and other relevant calls are captured and analyzed in near real-time.
JS Scope events are sent over a message bus to be consumed by the Job Coordinator and Scanner. The Scanner will inspect the event and determine which rules need to be run. A single event may be scheduled to be inspected by more than one rule.
For example, a web request may be run through an IOC Rule, Unknown Domain Rule, and a Yara Rule. When a rule alerts on an event, it is immediately sent to the Job Coordinator and forwarded to the preconfigured endpoints (Kafka, Web hook, SMS). All these actions take place while the site is being scanned, instead of waiting for the scan to complete.
What Does Merry Maker Look Like?
In order to understand the functions of Merry Maker, let’s also walk through the UI in detail to share what each view represents and where a user can go to find specific information.
The Dashboard view presents the current state and health of the system. Here users can quickly see the most recent alerts, active and recently run scans, and the number of events in the queue.
The Alerts view lists all recorded Rule Alerts with event source attribution.
The Sites view lists all monitored sites and their Active status. Users can manage existing site records, delete, and create new sites.
The IOCs view allows users to manage active IOCs used in alerting for various rule types.
The Allow List feature prevents alerting on false positives and stops rules from inspecting known events.
Here is an example of an HTTP GET request captured during a scan. This data is used to alert on the domain, URI, and headers based on the available rules.
Merry Maker has provided an extra layer of security and assurance for our guests as they shop online, and in open sourcing this project, it’s our hope that the rest of the security community can benefit from the framework and what we’ve learned.
Click here to access the Merry Maker open source project.
Click here to read an introduction to Merry Maker.