Full Report
A novel skimming attack has been observed by Jscramber, using the Stripe API to steal payment information by injecting malicious scripts into pages
Analysis Summary
# Incident Report: Stripe API Payment Skimming Campaign
## Executive Summary
This report details a sophisticated payment skimming campaign discovered by Jscrambler that specifically targets e-commerce merchants utilizing the Stripe API for payment processing. Attackers injected malicious JavaScript directly into checkout pages to intercept and steal credit card details in real-time before they reached Stripe's secure processing environment. Ultimately, researchers identified 49 compromised merchants, highlighting a significant risk to the supply chain of third-party scripts reliance.
## Incident Details
- **Discovery Date:** April 2, 2025 (Based on publication date)
- **Incident Date:** Ongoing at time of reporting; specific start date not provided.
- **Affected Organization:** E-commerce merchants utilizing Stripe for payment processing (specific organizations not disclosed).
- **Sector:** E-commerce / Retail (Payment Processing focus).
- **Geography:** Global (Implied due to broad adoption of Stripe).
## Timeline of Events
### Initial Access
- **Date/Time:** Unknown (Ongoing attack campaign).
- **Vector:** Direct injection of malicious JavaScript into e-commerce checkout pages.
- **Details:** The script was designed to execute on the client-side during the payment entry phase.
### Lateral Movement
- *Not explicitly described; the attack appears focused on data exfiltration from the client-side checkout interaction.*
### Data Exfiltration/Impact
- **Details:** Attackers captured credit card details as customers entered them into the checkout forms.
- **Exfiltration:** The stolen data was silently transmitted to attacker-controlled domains.
### Detection & Response
- **Detection:** Identified by cybersecurity researchers at Jscrambler through an independent investigation following the initial report.
- **Response Actions:** The advisory was published to alert the public and affected parties about the threat. (Specific merchant response actions are not detailed).
## Attack Methodology
- **Initial Access:** Injection of malicious JavaScript into third-party vendor scripts or directly onto merchant checkout pages.
- **Persistence:** *Not explicitly detailed, but assumed to be maintained through the malicious script residing on the checkout page.*
- **Privilege Escalation:** *N/A (Client-side script injection, not system compromise).*
- **Defense Evasion:** The malware mimics legitimate functions, making detection challenging compared to traditional rogue payment forms.
- **Credential Access:** Interception of plaintext credit card details entered by users on the checkout form.
- **Discovery:** *N/A (Focus is on direct skimming).*
- **Lateral Movement:** *Not applicable to this phishing/skimming vector.*
- **Collection:** Real-time gathering of input fields pertaining to credit card information.
- **Exfiltration:** Transmission of collected data to attacker-controlled infrastructure.
- **Impact:** Financial fraud resulting from stolen payment data.
## Impact Assessment
- **Financial:** Potential for significant direct financial loss/fraud for victims whose payment details were stolen. Costs potentially incurred by merchants for incident response and remediation.
- **Data Breach:** Compromise of sensitive payment card information (PCI data).
- **Operational:** Disruption to customer trust; requirement for merchants to audit and potentially replace third-party scripts.
- **Reputational:** Damage to the reputation of affected merchants and potentially Stripe due to perceived weakness in the payment processing integration layer.
## Indicators of Compromise
*Note: Specific IOCs (URLs/IPs) were not provided in the snippet and must be obtained from the full Jscrambler advisory.*
- **Network indicators:** Attacker-controlled domains used for exfiltration (Defanged placeholders: `hxxp://attacker_domain[dot]com`).
- **File indicators:** Malicious JavaScript payload residing on checkout pages.
- **Behavioral indicators:** Unsolicited network connections originating from the checkout page during form submission, targeting external, unusual endpoints.
## Response Actions
- **Containment:** Merchants need to immediately review and potentially disable third-party scripts loaded on checkout pages until verified as clean.
- **Eradication:** Removal of the malicious JavaScript injection from all affected frontend code.
- **Recovery:** Verification with Stripe to ensure no further compromise exists in the integration architecture; notifying affected customers as required by law.
## Lessons Learned
- **Key Takeaways:** Relying heavily on third-party scripts introduces supply chain risk directly into sensitive areas like payment processing pages.
- **What could have been done better:** Merchants should strictly adhere to Content Security Policies (CSP) to limit where JavaScript can load from and what connections it can make, especially on payment pages. Stronger runtime application self-protection (RASP) on client-side interactions could also aid detection.
## Recommendations
- Implement strict Content Security Policies (CSP) that whitelist only essential, trusted domains for script loading on payment pages.
- Utilize Subresource Integrity (SRI) checks for all third-party JavaScript libraries.
- Increase monitoring and alerting on real-time client-side POST requests made from payment forms, specifically looking for traffic destined for unknown external domains.
- Where possible, funnel all sensitive payment data through client-side libraries *provided directly by Stripe* (e.g., Stripe Elements) rather than custom integration code that handles raw input.