A double-entry attack manipulates the payment flow by presenting a fake form or error message before sending the customer to the real page. This can capture payment data on the first attempt while preserving the appearance of a normal checkout process. It is a practical web-skimming pattern, not a compliance term.
Expanded Definition
A double-entry attack is a web-skimming technique that inserts a deceptive first interaction into a payment journey, typically by showing a counterfeit form, warning, or error message before redirecting the user to the legitimate checkout page. The intent is to collect cardholder data or other payment details during the first pass while keeping the transaction looking normal to the customer and to the merchant.
Unlike straightforward phishing, the deception is embedded inside the site flow itself, so the user may believe they are retrying a failed payment or completing a routine verification step. In practice, this makes the attack harder to spot than a static fake login page because the malicious content appears only at a specific moment in the checkout sequence. The technique is best understood as a skimming pattern rather than a formal compliance category, and usage in the industry is still evolving around naming conventions. For general skimming and intrusion technique context, defenders often compare it with patterns described in the MITRE ATT&CK Enterprise Matrix. The most common misapplication is treating it as a user error issue, which occurs when teams miss the injected page logic and only investigate failed payment retries.
Examples and Use Cases
Implementing payment fraud controls rigorously often introduces more friction in checkout and incident triage, requiring organisations to weigh user experience against earlier detection of page tampering.
- A customer enters card details into a fake error page, then is redirected to the real gateway, leaving the merchant with a clean-looking checkout and a stolen payment payload.
- A compromised JavaScript tag intercepts the first submission attempt, copies form values, and then allows the legitimate payment request to continue so the transaction completes normally.
- A malicious overlay prompts the shopper to “verify” payment details after a decline message, capturing the same credentials the legitimate page would have accepted on retry.
- A third-party analytics or marketing script is modified to inject skimming code only on checkout URLs, making the attack sporadic and harder to reproduce in testing.
- Security teams correlate unusual checkout anomalies with threat reporting and operational indicators from CISA cyber threat advisories to determine whether the flow has been altered rather than merely failing.
Why It Matters for Security Teams
Double-entry attacks matter because they exploit trust in the payment journey itself, not just the browser or endpoint. When teams focus only on perimeter controls, they can miss the injected page logic, compromised script chain, or abused tag manager that makes the attack effective. This is especially important for ecommerce, fintech, and any environment that processes card data in a browser session, because the first visible sign may be customer complaints or payment disputes rather than a security alert.
Defenders need to understand where checkout content is sourced, how third-party scripts are governed, and how integrity is monitored across the client-side stack. Controls inspired by NIST SP 800-53 Rev 5 Security and Privacy Controls are often relevant for configuration management, monitoring, and access restrictions around web assets. Organisationally, the term becomes operationally unavoidable only after payment fraud, customer compromise, or dispute investigation reveals that the checkout flow itself was the attack surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Protects data in transit and at rest, relevant when checkout data is intercepted in-browser. |
| NIST SP 800-53 Rev 5 | CM-5 | Restricts unauthorized changes, fitting injected checkout logic and altered page content. |
Monitor payment flows for tampering and ensure sensitive data is protected during submission.
Related resources from NHI Mgmt Group
- Who is accountable when recovery controls fail during a double-extortion attack?
- How should security teams close gaps in SaaS-native attack paths before attackers move from entry to lateral access?
- How should security teams reduce identity-based attack paths when credentials, tokens, and API keys are the primary entry point?
- Why does Agentic AI make NHI attack surface expand so significantly?
