SVGs: the hacker’s canvas

Table of contents

Overview

Phishing delivery mechanism

Reusable kits, disposable domains

Detecting and mitigating the activity

Indicators of compromise

Overview

Over the past year, Phishguard observed an increase in phishing campaigns leveraging Scalable Vector Graphics (SVG) files as initial delivery vectors, with attackers favoring this format due to its flexibility and the challenges it presents for static detection.

SVGs are an XML-based format designed for rendering two-dimensional vector graphics. Unlike raster formats like JPEGs or PNGs, which rely on pixel data, SVGs define graphics using vector paths and mathematical equations, making them infinitely scalable without loss of quality. Their markup-based structure also means they can be easily searched, indexed, and compressed, making them a popular choice in modern web applications.

However, the same features that make SVGs attractive to developers also make them a highly flexible - and dangerous - attack vector when abused. Since SVGs are essentially code, they can embed JavaScript and interact with the Document Object Model (DOM). When rendered in a browser, they aren’t just images - they become active content, capable of executing scripts and other manipulative behavior. In other words, SVGs are more than just static images; they are also programmable documents.

The security risk is underestimated, with SVGs frequently misclassified as innocuous image files, similar to PNGs or JPEGs - a misconception that downplays the fact that they can contain scripts and active content. Many security solutions and email filters fail to deeply inspect SVG content beyond basic MIME-type checks (a tool that identifies the type of a file based on its contents), allowing malicious SVG attachments to bypass detection.

We’ve seen a rise in the use of crafted SVG files in phishing campaigns. These attacks typically fall into three categories:

• Redirectors - SVGs that embed JavaScript to automatically redirect users to credential harvesting sites when viewed

• Self-contained phishing pages - SVGs that contain full phishing pages encoded in Base64, rendering fake login portals entirely client-side

• DOM injection & script abuse - SVGs embedded into trusted apps or portals that exploit poor sanitisation and weak Content Security Policies (CSPs), enabling them to run malicious code, hijack inputs, or exfiltrate sensitive data

Given the capabilities highlighted above, attackers can now use SVGs to:

• Gain unauthorized access to accounts

• Create hidden mail rules

• Phish internal contacts

• Steal sensitive data

• Initiate fraudulent transactions

• Maintain long-term access

Our telemetry shows that manufacturing and industrial sectors are taking the brunt of these SVG-based phishing attempts, contributing to over half of all targeting observed. Financial services follow closely behind, likely due to SVG’s ability to easily facilitate the theft of banking credentials and other sensitive data. The pattern is clear: attackers are concentrating on business sectors that handle high volumes of documents or frequently interact with third parties.

Phishing delivery mechanism

SVGs as redirectors to external phishing sites

In this method, the SVG file contains embedded JavaScript that triggers an immediate redirect when the image is rendered in a browser, as outlined below:

• The SVG is either attached directly to an email, or hosted on trusted cloud services like Dropbox, Google Drive, or OneDrive

• The file names are crafted to look mundane and legitimate (e.g., “voicemail_vrecording.svg” “invoice_April.svg”, “document_review_2025.svg”)

• Once opened, the script inside the SVG executes – typically triggering a redirect to a credential-harvesting login page that often impersonates legitimate and widely used services, such as Microsoft 365, Google Workspace, or Adobe

• The SVG appears as a legitimate image, serving as a decoy, but behind the scenes it functions as a scripted launcher for an external phishing site

• Since the payload is hosted remotely, the attacker can update the phishing page in real-time without modifying the SVG itself, making this technique the perfect springboard for attackers

Often, legitimate services are abused in order for this attack chain to work effectively. Lightweight, serverless functions such as Cloudflare Workers, or AWS Lambda are used in these attacks, since they are globally accessible, highly scalable, serve static content and code, and even double as a legitimacy-spoofing mechanism.

In order to appear legitimate, the SVG file acts as the initial delivery mechanism, containing obfuscated JavaScript that starts a chained redirect. This redirect begins with a URL, such as hxxps://[8-char hex].[32-char hex].workers.dev/?qrc=[encodedString], as shown in the JavaScript below.

In this example, the “qrc” parameter contains a Base64-encoded version of the target’s email address, which threat actors often include for a variety of reasons (e.g., tracking target engagement, pre-populating the email field on fake login pages, credential pairing to link usernames to stolen passwords). Once the SVG script executes, the unsuspecting user is presented with a Cloudflare Turnstile challenge, requiring interaction (likely to prevent access by automated scanners) and then redirected to a second domain - hxxps://rhanksharborpartners[.]club/?fclwuuwo - with the target’s email address appended to the query string.

Self-contained phishing pages via Base64-encoded HTML

This approach goes a step further, where users are typically lured via email attachments or links to externally hosted .svg files, often disguised as ordinary documents. Rather than redirecting to an external site, the SVG itself contains the entire phishing page, base64-encoded within the file:

• The SVG embeds encoded HTML and CSS that when rendered in a browser displays a fake login interface

• When rendered, JavaScript contained in the SVG decodes and injects the full phishing page directly into the DOM. This technique doesn't require an external URL, making it much harder to detect with basic link analysis or reputation-based tools

• The browser displays a login form impersonating a legitimate brand (e.g., Office 365)

• The user enters their credentials

• The form silently POSTs the credentials to a server controlled by the attacker

SVGs injecting malicious code into the host page (DOM clobbering / Script injection)

This technique leverages the fact that SVGs, when ebedded into HTML via <img>, <iframe>, or even inline <svg> tags, can interact with the DOM of the parent page, depending on how they are included and served.

Here’s how it typically works:

• A malicious SVG is embedded directly into a legitimate website or email landing page (especially if user-uploaded images are allowed)

• The SVG contains <script> tags or event handlers (such as onload or onclick) that execute JavaScript when the SVG is parsed and rendered

• If Content Security Policy (CSP) is weak or absent - a common scenario in internal portals and legacy apps - an SVG can:

  • Steal cookies

  • Keylog inputs from nearby form fields

  • Inject rogue elements into the DOM (e.g., iframes, overlays, fake login fields)

  • Exfiltrate sensitive data or tokens present in the browser context

In one observed case, an SVG file embedded in an email included a <script> tag. When the file was rendered - either by opening it directly in a browser or embedded into an unsandboxed page - it assigned a value to the window.location JavaScript property (which represents the URL of the current page), thereby triggering a redirect. In this instance, the redirect pointed to hxxps://tyksh0fd4btyksh0fd4b.csnjoight[.]com/xmqDSFa1/$sales@[target email domain].

Visiting the URL triggers a script that uses document.write to inject a second script directly into the page. The injected script executes immediately and is then removed – a known tactic used by attackers to evade static analysis. It performs anti-analysis and anti-debugging checks; if such tools are detected, the user is redirected to legitimate sites like bestbuy[.]com or target[.]com. Once human interaction is confirmed, the script proceeds to load external libraries (jQuery, Cloudflare Turnstile, CryptoJS), likely a red herring to divert attention; their inclusion creates the appearance of legitimate functionality, intended to distract from the script's true purpose and underlying malicious behavior.

After solving the Turnstile challenge, the script first sends a HTTP GET request. If the response equals “0”, it proceeds to send a POST request that includes the Turnstile token in the form data. If the POST request succeeds, the page reloads, this is where the actor can add more malicious content. However, if the GET response is anything other than “0”, or the POST request fails, a fake page is displayed instead, like the one shown below:

The script contained several obfuscated strings encoded using specific invisible Unicode characters. Each character was directly matched to one of these values to reconstruct a binary string, which was then split into 8-character segments (8-bit binary), converted to bytes, and finally decoded into ASCII to reveal the hidden string, which is the intended output for the script and main functionality.

The backend doesn’t just serve static content based on criteria like request headers, IP address, or user agent. In several instances, the differing responses suggest backend polymorphism, where server-side logic randomises JavaScript payloads per session or request to evade signature-based detection. During the investigation, five separate requests returned five distinct sets of obfuscated JavaScript, each using entirely different variable names and callback domains.

Reusable kits, disposable domains

SVG file reuse & kit fingerprints

Numerous instances of SVGs with identical JavaScript payloads were observed, differing only in filenames and Base64-encoded parameters. Additionally, file naming conventions often included dynamic elements like [New Received FAX -REF[number].svg]. These are strong indications of a shared phishing kit or Phishing-as-a-Service (PhaaS) offering.

Infrastructure observations

Domains serving second-stage phishing pages are often burner domains, registered recently or reused across multiple targets. However, some are hosted on longstanding but compromised WordPress sites, allowing them to bypass threat intelligence feeds by leveraging ‘benign’ historical domain reputation.

It is worth highlighting that numerous SVG samples exhibit the previously mentioned redirector pattern, often with slight variations but near-identical behavior - a strong indicator of a shared phishing kit. In one example, the SVG contained encrypted JavaScript that decrypted client-side and redirected the browser to hxxp://test.excellencesinfo[.]com/#[target email address], where the appended address may be used for tracking the victim, pre-filling login forms, or credential pairing. The domain itself is newly registered - as is often the case - and likely expendable, aligning with a broader pattern of low-reputation infrastructure observed across multiple campaigns. These minor cosmetic differences - changing filenames, tweaking parameters - point to a templated approach where attackers reuse the same core payloads across different targets with minimal effort.

Detecting and mitigating the activity

Cloudflare Email Security have deployed a targeted set of detections specifically aimed at malicious emails that leverage SVG files for credential theft and malware delivery. These detections inspect embedded SVG content for signs of obfuscation, layered redirection, and script-based execution chains. They analyze these behaviors in context - correlating metadata, link patterns, and structural anomalies within the SVG itself.

These high-confidence SVG detections are currently deployed in our email security product, and are augmented by continuous threat hunting to identify emerging techniques involving SVG abuse. We also leverage machine learning models trained to evaluate visual spoofing, DOM manipulation within SVG tags, and behavioral signals associated with phishing or malware staging.

Below is a sampling of our current SVG-based detection rules, alongside a summary of the threats they’re designed to catch:

Attachment.Qbot.Svg_JavaScript

Detects SVGs containing JavaScript that initiates a request to download a .zip or redirect to a webpage - a classic Qbot delivery method.

Attachment.SVG.JavaScript.HTML_Script

Catches SVGs that contain JavaScript but lack any legitimate image or text content - usually a strong sign it exists purely to execute code.

Attachment.SVG.Javascript_Dom_Write

Flags SVGs using JavaScript to manipulate the DOM (e.g. document.write) - commonly abused to inject malicious HTML or scripts on render.

Indicators of compromise

SHA256

Links

Common subject lines