Malware Isn't Always Flashy: Sometimes It's Just a Scan from Xerox_359523

It started like any other Thursday morning.

I was sifting through emails, the usual flood of newsletters, invoices, and automated reports, when one particular message caught my eye. It looked harmless enough: a standard notification from a Xerox Scanner, the kind you might expect after scanning a document in an office.

The subject line was simple: "Scanned from Xerox_359523" And there was an attachment: DOC217_5825.svg.

Now, the place I was at has a Xerox printer. At first glance, there was nothing outwardly suspicious. No spelling mistakes. No bizarre formatting. No urgent requests to click anything.

But there was one problem:

I hadn't scanned anything.

That tiny inconsistency was enough to trigger alarm bells. Over the years, I've learned that real threats often hide behind boring, everyday formats, not flashy warnings.

Instead of deleting the email or brushing it aside, I decided to dig deeper. Together with my business partner at Code Guardian, we launched a full investigation: analyzing the email headers, inspecting the attachment, tracking the mail flow, and trying to uncover the attacker's intent.

What we found was much more sophisticated than your average spam. Let's dig into how these kinds of attacks work, how to analyze them and what lessons to learn from them.

First: Why an SVG File is Dangerous

At first glance, an SVG (Scalable Vector Graphics) file seems harmless. It's a standard file format for pictures, often used for logos, icons, and simple illustrations on websites. Under the hood, though, an SVG is more than just an image.

An SVG is actually a text file written in XML. Because of this, it can include not only graphic definitions, but also embedded scripts, such as JavaScript. This means that an SVG file isn't just capable of displaying images: it can execute code inside a browser if improperly handled.

This is a subtle but important shift in attack techniques. Instead of sending an obvious .exe file or a shady .zip, attackers are using file types we trust, like images, to sneak malicious code past email filters and into inboxes.

All in all: receiving a mysterious file masquerading as a scanned document I hadn't scanned, in a suspicious SVG-format, was enough to trigger our curiosity. Let's dig into what we did to analyze it.

Step 1: Investigating the Email headers

Before opening any attachment, the first thing we did was take a close look at the email headers. Email headers are like the envelope of an email: they show where the message really came from, how it traveled through different servers, and whether anything looks out of place.

Normally, you wouldn't see these details in your inbox view. You need to view the full headers to see the underlying metadata:

• Sender IP addresses
• Mail servers involved
• Authentication results (SPF, DKIM, DMARC)
• Timestamps and server hops

In this case, something interesting showed up almost immediately.

The email was sent using mailgun, a legitimate email-sending service often used by web applications, and unfortunately, sometimes abused by attackers to make malicious emails look more trustworthy.

The email wasn't sent directly though, but had passed through a computer at an American university.

Why would an attacker do this? Why compromise infrastructure at a university, instead of just sending the email directly?

There are a few important reasons.

First, universities are attractive targets because they typically have very open network environments. Unlike corporations, which often tightly control outgoing email and network traffic, universities prioritize accessibility and academic freedom. This makes them a perfect place for attackers to find undersecured servers, workstations, or misconfigured email systems to hijack.

Second, using a legitimate server makes the email more believable. Emails that originate from known, reputable domains, like a university, are less likely to be flagged by spam filters. Many organizations automatically trust emails coming from educational institutions, especially when SPF (Sender Policy Framework) records are either too permissive or not properly checked.

Third, it helps bypass blacklists and reputation checks. IP addresses associated with universities are usually considered "clean" and not listed on common spam or abuse blacklists. By relaying their attack through a trusted IP, attackers can dramatically increase the chances that their malicious email lands directly in the target's inbox.

In short:

Using compromised, reputable infrastructure is about stealth, trust, and deliverability.

And in this case, it worked: the email made it past automated filters without raising any immediate technical warnings.

Next, let's dig into the contents of the attachment and find out just how malicious this SVG was.

Step 2: Scanning the attachment

With the email headers confirming our suspicions, we moved on to the next logical step: scanning the attachment. Before opening it manually, we first uploaded the SVG file to VirusTotal, a popular platform that aggregates results from dozens of antivirus engines and security tools. VirusTotal allows you to quickly check whether a file is already known to be malicious, without exposing yourself to the risk of running it locally.

The results were immediate and decisive.

Multiple engines flagged the SVG file as dangerous, with detections ranging from Trojan droppers to credential stealers. Some vendors classified it under generic malware categories, while others provided more specific warnings about redirect behavior and exploit attempts.

This initial scan confirmed what we already suspected:

This wasn't just spam. It was an active malware delivery attempt. Armed with this confirmation, we decided to dig even deeper and manually inspect the SVG file to understand exactly what it was trying to do.

Step 3: Dissecting the SVG. What's Hiding Inside?

With VirusTotal confirming the file was malicious, we moved on to manual inspection to understand how it worked and what it tried to do. We opened the SVG file in a secure environment and quickly noticed it didn't contain any image data at all. Instead, it was packed with JavaScript, and not the readable kind.

The raw SVG file

The first thing to notice are the poetic-looking comments like:

These are completely unrelated to the functionality of the file and serve no technical purpose. Instead they are added as filler content, likely to confuse heuristic-base scanners. They create a sense of artistic value, which is in line with image formats. These sentences return nothing on popular search engines and are likely AI-generated.

Next, the <foreignObject>-tag is normally used to embed HTML-content in an SVG-image. This allows, for example, to overlay rich text or interactive elements on top a vector diagram or map. In this case however, it's used for more sinister purposes.

Within the <body>-tag (after another line of poetic nonsense), a variable is defined: merimo. Below that, we find the real payload.

The next <script>-tag contains a base64-encoded payload, embedded directly in the file. There is no external request, and the script has been inlined visually with 100% width and height, likely to occupy the entire view in the browser if rendered.

Step 4: Decoding and Analyzing the Base64 Payload

Decoding base64 is easy: just copy paste the encoded lines in a decoder, and you'll find the original code. What we found was a block of obfuscated code.

The decoded payload

Obfuscation is a method to deliberately make code difficult to read or understand, both for humans and automated analysis tools. Attackers use it to hide the real intent of their scripts, often by renaming variables to meaningless strings, inserting junk characters, or encoding values in ways that require custom decoding logic.

To the untrained eye, the code might look broken or random. But once decoded, it executes like any other script. Let's look at the techniques used in this file.

String reversal and junk removal

The attacker first reverses the encoded string and removes irrelevant characters like x, q, z, m, and v. These characters serve no functional purpose. They're added purely to confuse pattern-based scanners and slow down manual analysis.

let cibeme = str.split("").reverse().join("");
let kariye = cibeme.replace(/[xqzmv]/g, "");

Encoded characters with math

After cleaning, the string is split on dashes and each part is parsed as a hexadecimal number. The attacker then applies a simple formula (subtract 7, divide by 3) and converts the result to a character:

let pakete = kariye.split("-")
  .map(hex => String.fromCharCode((parseInt(hex, 16) - 7) / 3))
  .join("");

This is a classic obfuscation trick: using arbitrary math operations to obscure character values.

Dynamic redirect

The decoded string is stored in a variable and used to redirect the user's browser:

window.location.href = pecolo + merimo;

Here we see the merimo-variable from the original SVG file return. Even though it's just an empty string, it makes the code slightly more modular, and could be used in the main SVG to customize the payload.

Fallback click bait

If the automatic redirect fails, the script looks for an invisible link element (#sahice), sets its target, and makes it visible:

const vihecu = document.getElementById("sahice");
if (vihecu) {
  vihecu.href = pecolo;
  vihecu.style.display = "block";
}

This is a fallback tactic. In case the redirect is blocked, a user might still click the link manually.

In the end, the de-obfuscated code revealed a redirect to a malicious domain:

The malicious URL

Note the email-address at the end of the URL: This suggests the SVG wasn't generic. It was dynamically generated per recipient, likely to track who interacted with the file or to personalize the final payload. It's a clear sign that this wasn't random noise. Even if automated, this attack showed structure, intent, and tooling behind the scenes.

Step 5: Losing the trail

Once we had decoded the payload, we ended up with a long and clearly randomized URL pointing to a .com domain that looked... off.

At this point, we knew what we were dealing with: a malware delivery URL generated dynamically via obfuscated JavaScript. The next step would have been simple:

• Run the URL through VirusTotal to see if it had been flagged.
• Use a browserless screenshot tool to visually inspect the page in a sandbox, without actually visiting it.

But we made one mistake:

We called it a night.

By the time we returned two days later to finish the analysis, the page was already offline.

This isn't uncommon. Malware infrastructure is often spun up and torn down within hours, especially when attackers use automation or rotate through compromised hosting providers.

So, unfortunately, we'll never know exactly what the final payload was. But we saw enough in the script structure, the VirusTotal verdict, and the redirection logic to confirm: this was a deliberate attempt to compromise a system through a simple, trusted file type.

Final thoughts

This wasn't a zero-day. It wasn't a headline-grabbing attack. It was quiet, subtle, and wrapped in the skin of everyday office life, and that's exactly what makes it dangerous.

We often focus on the big breaches and exotic exploits, but the truth is:

Most real-world compromises begin with something as boring as a scanned document.

At Code Guardian, we believe security teams should spend less time chasing alerts and more time understanding tactics like these: because context beats noise, every time.