Security teams that subscribe to threat feeds get lists of known malicious domains, IPs, and file signatures that they can leverage to blacklist and prevent attacks from those sources.
Using network traffic analysis that recognizes suspicious communications, data breach reports that identify attack techniques, decoys designed to draw out and study attacks, monitoring of attacker forums, and third-party data research, security experts compile threat feeds as actionable portraits of the threat landscape.
But the ultimate value of those lists is increasingly limited, because today’s client-side attacks are deeply dynamic. Client-side scripts used in attacks can be highly targeted, and each request can return a different random response. Meanwhile, threat feeds still utilize crawling and sampling, which simply cannot flag that dynamic behavior. If a business faces a targeted client-side attack and is only protected by a client-side security strategy that relies on threat feeds alone, the attack will not be recognized.
Businesses require more automated and incisive protections to reliably defend against client-side attacks that hide within their browser supply chains and compromise their website users’ data. Because recognized vulnerabilities are added to threat feeds manually, protections are only as effective as those entering and executing upon the data are vigilant and accurate. Where reports simply name the domains that attackers utilize, attackers can just as simply switch to a new domain (in a matter of minutes) to evade blacklist protections.
Unfortunately, some incidents demonstrate how threat feeds can allow even known threats to fall through the cracks until it’s too late.
A case in point: The guyacave[.]fr client-side attack
Recently, our security researcher detected a client-side attack using the domain guyacave[.]fr to serve a script that skims personal identifiable information (PII). The shocking part: this script has been active and affecting users of a particular website since August 2022. We alerted this and other sites of the attack, and advise all site security team members reading this to check for activity from this script and block this domain.
Digging into records of this attack, though, we were again shocked to learn that we weren’t the first to discover it. That credit goes to security vendor Avast, which announced the threat in November 2022 and stated that it had protected almost 17,000 global users from the skimming attack.
The guyacave[.]fr attack script has been fully known for more than two years, but threat feeds still have never been updated to address the threat. A check of VirusTotal finds that only 13 out of 96 security vendors have flagged the domain as malicious. After two full years, businesses with security teams that dutifully maintain and update their threat feeds as best they can remain blind to this documented risk, and may be exposing their site users’ data because of it.
Modern threats require modern responses
Aside from the challenges of keeping a blacklist of threat sources accurate and up-to-date, threat feeds simply can’t address the most critical vulnerabilities threatening organizations today. Specifically, threat feeds do nothing to mitigate zero-day vulnerabilities, social engineering attacks, or other potential exploits that call for active real-time interventions.
They can’t protect browser sessions from existing patching vulnerabilities, nor help security teams prioritize vulnerability risks. And because threat feeds are open source and subject to human error, false positives are as possible as unflagged dangers.
The guyacave[.]fr script does a few clever things. It uses the Math.random() function to avoid detection by signature-based security methods. It leverages the display:none function to hide actual payment forms and show users false ones instead. It includes functions capable of stealing session cookies and other sensitive browser-stored data. That said, even if this same script attempted a client-side attack from another unknown domain, more modern detection capabilities could sniff it out and block those activities in progress.
The better security technique is to load client-side scripts into a proxy environment, and perform robust detection to understand whether the payload of those scripts contains any suspicious or clearly malicious functions. Questionable scripts can be closely observed, and scripts that exhibit dangerous behavior can be shut down before their operations can do any harm. Domains that those scripts access can then be added to threat feeds to bolster and share threat awareness, but certainly not as a first or only line of defense.