AdTech cookie sync code hijacked to propagate Bitcoin scam popups outside of the advertising server
February 21 got off to a rude start as more than 450 publishers, AdTech partners and enterprise sites served phishing-related popups to millions of users around the world. While this incident leveraged the digital advertising supply chain to rapidly propagate and execute client-side redirect and malware attacks, it did not execute through ad servers. Rather, the incident used one AdTech provider’s cookie-syncing URL—which helps sync individual identities used in targeted advertising—to perpetrate the attack, thereby compromising every partner relationship and ruining the consumer experience.
Coined Electrum-3PC (Electrum) by The Media Trust’s Digital Security and Operations (DSO) team, the incident spread rapidly—bypassing multiple creative blockers—resulting in more than 24,000 detections in 4 hours. The DSO isolated the incident to one compromised supply side platform (SSP, which helps publishers manage their advertising inventory) and notified them and our affected publisher and AdTech clients of the issue. Due to the incident’s broad reach, DSO brought it to the attention of the TAG Threat Exchange so that additional publishers could remediate their environments.
Electrum-3PC: How it works
The incident involved media publishers—national and local news, lifestyle and sports, weather and finance—several premium AdTech providers, and a handful of ecommerce sites. Detected across six continents, the incident primarily affected consumers in Australia, Brazil, Canada, Russia, United States and throughout most of Europe.
The key components of the incident involved the use of heavily obfuscated code to fingerprint user devices and then redirect users to popups referencing Electrum, an open source Bitcoin wallet. [Figure 1]
[Figure 1: Digital supply chain flow for cookie-sync enabled attack]
The SSP’s cookie sync URL was hijacked. Script deobfuscation reveals the device fingerprinting and initial redirect to “ipfs-hosting[.]tk/redirect.php”. [Figure 2]
[Figure 2: Deobfuscated code reveals checks and redirect]
The simplistic code:
- Checks the device user agent for the words “Microsoft” or “Mac OS”
- Identifies the browser/OS used in HTTP requests
- Confirms access to the browser’s local storage
Upon passing the checks, the user is redirected to “ipfs-hosting[.]tk/redirect.php”. Devoid of content, this URL redirects the user to another URL, “electrum-4.github[.]io/electrum.html”. The “electrum” URL clearly states its intention to serve popups. [Figure 3]
[Figure 3: Electrum URL detailing popup activity]
Once again, the user agent is checked to see if it contains “Windows” or “Mac OS” which determines the specific popup action: [Figure 4]
- Windows: Pop up is executed via the JavaScript alert() method. Upon clicking “OK”, the user is automatically redirected to “electrum-4.github[.]io/electrum.html”.
- Mac OS: Pop up is executed via the JavaScript prompt() method. The user is asked to copy and paste the redirect URL.
[Figure 4: Pop ups served to users based on the device user agent]
Analyzing and shutting down the attack
GitHub and GitLab are becoming popular resources to host malvertising schemes due to the ease of creating static campaign landing pages. In this scenario, it’s likely the attackers cloned the legitimate Electrum GitHub repository with a similar name and then created a backdoor to steal the Bitcoin.
Client-side scanning enabled quick detection of the anomalous code. Our DSO team isolated the attack to the cookie-sync URL used by a mid-size SSP, not to a specific creative or campaign. As a result, any company using this SSP’s cookie sync was impacted. The DSO provided this information to the affected SSP, and within a few hours the URL was updated and the code removed from the GitHub page.
Third-party code as a malware vector
Few understand that approximately 90% of the code rendering the user experience is not provided by the actual website being operated. Today’s websites rely on third parties to provide the engaging and dynamic experience that consumers expect. In fact, many third parties call on additional resources (fourth, fifth, nth parties) to help execute their intended function. The problem is that website operators have no insight into third-party code activity as it only executes in the user’s browser, which is outside the website operator’s control. This is how third-party code was responsible for more than 20,000 distinct attacks in 2020 .
In the Electrum incident, the AdTech vendor is a known partner; however the code is behaving in an unauthorized manner.
How to avoid Electrum-3PC and similar third-party vendor risks
This recent large-scale incident is the latest in a series of cookie sync-enabled malware affecting publishers since late 2020. While a short-lived incident, thankfully, Electrum highlights two significant facts: first, it serves as an example of how one incident can affect hundreds of publishers to harm millions of users. Second, AdTech code executing outside ad delivery is not protected by creative blockers.
A publisher’s best defense is to adopt continuous, client-side scanning to supplement creative blocking tools. Behavioral and code-based analysis expertise examines the code’s function and relevance to the page. Not only will client-side scanning detect anomalous page code, but it also can identify zombie code from defunct or unwanted technology providers, which can be blocked at the server or via a direct request to the code owner to remove it from execution chains.
INDICATORS OF COMPROMISE
https[:]//ipfs-hosting[.]tk/redirect.php
https[:]//electrum-4.github[.]io/electrum.html