What are the signs that a website may have been compromised by e-skimming malware?

How to recognise an e-skimming compromise when the site still looks normal

The most important clue is often that nothing looks obviously broken to the shopper. E-skimming malware is designed to blend into a legitimate checkout flow, so defenders need to look for subtle changes in page structure, script loading, and payment behaviour rather than waiting for visible defacement. In practice, the strongest indicators are configuration drift and unauthorised code injection on pages that handle payment data.

What usually changes in the page, script, or payment flow

Unexpected modifications to checkout pages are a common sign, especially when the changes were not part of an approved release. That can include new JavaScript, altered inline scripts, unfamiliar third-party tags, or code that appears only on payment or account pages. A comparison against the known-good build or approved vendor list often shows the difference faster than a visual inspection.

Payment flow anomalies matter too. If a page suddenly starts loading code from an unfamiliar domain, sending form data to an unexpected endpoint, or behaving differently across browsers or devices, treat that as suspicious. The compromise may not break the checkout process, because the malware only needs to copy cardholder data or personal details while leaving the customer experience intact.

In many incidents, the injected script is short-lived, renamed, or obfuscated, which makes change detection more useful than manual browsing. Tracking script inventory, integrity checks, and release provenance helps separate legitimate ecommerce change from malicious tampering. For defenders who want a broader control baseline, CIS Controls v8 is a useful reference for inventory, logging, and malware-defence discipline.

What to inspect beyond the page itself

Look for behaviour that does not match approved infrastructure or vendor expectations. That includes unexplained changes in payment widgets, new references to external libraries, unusual use of tag managers, altered content delivery patterns, and code that appears only after specific user actions such as entering payment details. If the site is part of a modern commerce stack, the compromise may also hide inside a third-party dependency rather than the merchant’s own codebase.

Operationally, defenders should compare what is live against what was approved: the deployed asset list, the checkout page source, script hashes, and the vendor access paths used to publish changes. The point is not to prove the attacker’s intent from a single artifact, but to establish whether the active page is still the one that was reviewed and released. For teams building a stronger malware-detection and response baseline, CIS Controls v8 also supports monitoring, access control, and secure configuration practices that reduce dwell time.

Risk and Threat Considerations

E-skimming is dangerous precisely because it can remain invisible to ordinary users and even to site owners for a long time. The attacker’s objective is usually silent interception of payment or personal data, so the business may keep functioning while data is being exfiltrated in the background.

Failure mechanism: The malware is inserted into a trusted page or dependency, then captures form data before it reaches legitimate payment systems. Because the checkout still appears to work, the compromise is often discovered only after fraud reports, code review, or external detection.

Impact: Exposure can include card data, customer identifiers, and regulatory or contractual fallout. The longer the injected code stays live, the larger the blast radius, especially on high-traffic checkout pages or in environments where multiple sites reuse the same scripts or vendor tooling.

Practitioner Guidance

What to verify: Verify the current checkout source against the last approved deployment, including script tags, tag-manager changes, and third-party references. If the live page differs from the approved baseline, treat it as a security event first and a release issue second.

What to prioritise: Prioritise any change that can touch payment form fields, session data, or outbound script loading. Those are the points where a small code change can create a large data-loss problem, even when the page still appears functional.

Common mistake: Do not rely on visual review alone. E-skimming is built to evade casual inspection, so a page that “looks fine” is not evidence that the checkout path is clean.

Practitioner takeaway: The decisive question is not whether the site looks compromised, but whether the live checkout path still matches the approved code and dependency chain.

Related resources from NHI Mgmt Group

• What are the signs that a website or endpoint has been quietly compromised for malware delivery?
• What actions should I take if my OAuth tokens are compromised?
• What makes Shai Hulud 2.0 different from a normal npm malware event?
• What are the signs that a notebook environment has been compromised by malware and cryptomining activity?