Old worms on new hooks — XSS as phishing’s hook, line, and sinker

If you already know what XSS is, skip ahead to ‘Weaponising HTML attachments.’ Otherwise, the boring stuff first.

What is cross-site scripting (XSS)?

Cross-site scripting (XSS) is a web security vulnerability that lets an attacker compromise the interactions users have with a vulnerable application. It lets an attacker circumvent the same-origin policy, which is designed to keep different websites segregated from each other. Normally XSS lets an attacker masquerade as a victim user, carry out any action that user can perform, and access any of that user’s data. If the victim has privileged access, the attacker may gain full control over the application’s functionality and data.

How does XSS work?

It works by manipulating a vulnerable site so that it returns malicious JavaScript to users. When that code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application.

Weaponising HTML attachments with XSS

Recently I watched XSS used successfully in a phishing attack. Rather than scanning web pages for vulnerabilities, threat actors are now just sending you the web page as an attachment — loaded with browser-friendly embedded XSS scripts to undress your local defences. Any technique from an XSS cheat sheet can be used to launch these attacks.

It’s a great way past local defences: by delivering the page as a file and dressing it up as an incoming attachment notification, the attacker sidesteps the browser protections that would normally get in the way.

So don’t threaten me with a good investigation

As a forensic investigator I’m always watching for new phishing techniques, and this one was worth writing about. It arrived as an email with an HTML attachment that looked like a legitimate notification — and instantly fooled the user.

Here’s the shape of it. The threat actor does something that looks normal, like inlining a graphic — say, a small purple square:

src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnPjxyZWN0IHdpZHRoPSc1MCcgaGVpZ2h0PSc1MCcgc3R5bGU9J2ZpbGw6ICNiMGI7JyAvPjwvc3ZnPg=="

That base64 decodes to a harmless purple square. What’s not harmless: the same trick can embed a base64-encoded <script></script> inside another base64 blob — and no AV is going to double-decode it. Say it with me: bypass.

Binary Large Object time

Base64 something like this:

<script>//<![CDATA[
        …code… MAKE ME A BLOB …code…
    //]]>
</script>

… and you’re pooched. XSS is such an old vulnerability that most people don’t care about it anymore — modern browsers defend against code injection. But if the code is already embedded, hidden XSS can use a series of Unicode characters to conceal malicious code inside an image vector generated client-side.

Whew — that was fun.