When “Trusted” Isn’t Safe: Attackers Are Now Weaponizing Legitimate Cloud Infrastructure

by Source Defense

Attackers no longer need to compromise your network to steal payment data. They just need an account on the same cloud platform your developers use.

The New Face of Magecart: Legitimate Services as Attack Infrastructure

Source Defense Threat Research recently identified a Magecart variant using a legitimate Vercel subdomain (m-stripe.vercel.app) to collect and exfiltrate payment data. The campaign impersonated Stripe functionality and used familiar JavaScript objects (like latepointPaymentsStripeAddon, cardNumber, cardExpiry, and cardCvc) to harvest data from live checkout sessions.

The payload was hosted entirely within Vercel’s own cloud environment. To most security tools, it looked like safe, first-party traffic. This is the evolution of Magecart: from third-party compromise to first-party impersonation. It exploits the same core weakness of client-side JavaScript trust, but hides behind the same infrastructure legitimate developers use.

Why This Matters: The Trust Model Is Breaking

When attackers operate from trusted cloud domains, traditional controls fail:

• Allowlists and CSPs treat domains like vercel.app, github.io, and firebaseapp.com as safe by default.
• SRI can verify file integrity but not intent. An attacker’s code can be “authentic” and malicious at the same time.
• Network and perimeter controls can’t detect exfiltration if it’s happening inside authorized browser sessions.

The result is operational: even your approved tech stack can become an attack vector. For CISOs and IT Managers, that means “trusted domain” can no longer equal “trusted code.”

Compliance Lens: This Is Exactly What PCI DSS 4.0.1 Targeted

The PCI Council added requirements 6.4.3 and 11.6.1 precisely because of these blind spots:

• 6.4.3 requires organizations to inventory, authorize, and assure the integrity of every script running on payment pages.
• 11.6.1 mandates continuous monitoring of page content and headers to detect unauthorized changes.

Static scans and point-in-time audits won’t meet these objectives. As both Coalfire and VikingCloud have confirmed, compliance now depends on runtime visibility. Seeing what scripts do as users execute them.

The abuse of Vercel-hosted subdomains illustrates why: this skimmer would have passed code reviews, CSP checks, and vulnerability scans, yet still exfiltrated live cardholder data in real time.

What Traditional Defenses Miss

CSP and SRI were designed for a simpler web. In today’s dynamic environment:

• CSP depends on static allowlists that can’t distinguish legitimate functionality from a malicious script hiding on an approved domain.
• SRI verifies file integrity, but not malicious behavior—attackers can host their own “clean” file on a trusted domain.
• Crawler-based scanning tools miss inline or dynamically injected scripts that only execute during real user sessions.

As the Verizon Payment Security Report confirms, 40% of payment-page scripts have access to personal or payment data, and the average checkout page loads more than 18 scripts, many from cloud platforms attackers now exploit.

Why Behavior-Based Monitoring Works

Behavior-based monitoring closes this gap by evaluating what scripts do, not just where they come from. Source Defense continuously analyzes script execution in real time, detecting and blocking unauthorized data collection, even when the script originates from an allowed or cloud-hosted domain.

In technical terms, it provides:

• Runtime behavioral analysis of both first- and third-party scripts.
• Automated detection and blocking of new or unapproved communication endpoints.
• Real-time visibility into newly observed subdomains and script behaviors.

This approach directly supports PCI DSS 6.4.3 and 11.6.1 compliance and has been independently validated by Coalfire and VikingCloud as meeting those controls when configured correctly.

Action Steps for CISOs and Security Teams

1. Reassess trust assumptions
   Treat subdomains of major cloud hosts (Vercel, GitHub, Firebase, etc.) as untrusted until verified.
2. Validate PCI DSS 4.0.1 readiness
   Confirm that monitoring extends to runtime behavior, not just static script inventories.
3. Test your detection tools
   Simulate a benign skimmer hosted on a trusted domain to measure visibility and response.
4. Document visibility gaps
   Include client-side telemetry and behavioral analytics in your third-party and supply chain risk assessments.
5. Engage behavior-based controls
   Implement a continuous monitoring solution capable of detecting and blocking script-level exfiltration in real time.

The Larger Trend

The exploitation of legitimate cloud services isn’t a niche issue. It’s a preview of where client-side attacks are headed. As attackers leverage the same infrastructure used by your developers, the defensive perimeter has effectively shifted into the browser. The organizations that adapt first by combining compliance visibility with behavior-based detection will be the ones that maintain both security and trust in their digital payment flows.

Learn more or request access to the QSA dashboard at www.sourcedefense.com.

PCI DSS 4.0 makes client-side security a priority.

Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.

Download the Guide