Is This QRSAFE?™Annual Field Report · 2025
Looked at on its own, 2025 felt like steady-state. Looked at against what came next, it was the year the apparatus assembled. This report walks through the patterns that started in 2025 and broke into the open in 2026.
Section I
2025 produced 64 high-confidence catches out of 823 URLs analysed — about 7.8%. 18 of those were flagged by ten or more engines, the kind of consensus that closes the "false positive" argument.
The volume curve in 2025 is uneven. The first half of the year produced a thin trickle: 6 catches in March, 3 in May, 0 in April or June. Then July ticked up to 8, August jumped to 14, and the second half held a roughly four-to-fifteen-per-month cadence. That is the curve of a platform finding its first real users — but it is also, we now think, the curve of attackers starting to standardise QR delivery for kits that had been email-only.
Section II
In hindsight the dominant story of 2025 is the slow appearance of Adversary-in-the-Middle phishing kits in QR form. The signature: an algorithmically-generated subdomain on a forgettable base domain (.sa.com, .es, .ru, .click, .sbs), a path that mimics a corporate document portal, and the victim's real email address Base64-encoded in the fragment so the landing page can auto-personalise on render.
These were not opportunistic phishing pages. They were targeted attacks delivered at the speed of a sticker.
Each of these caught users at a different company, in a different city, scanning a different physical QR. The infrastructure was identical. We are featuring 3 of the strongest BEC examples below; over the full year the pattern was a significant share of the 18 ten-engine catches.
Section III
These are the strongest 2025 examples of fragment-encoded corporate phishing arriving via QR. URLs are defanged; the VirusTotal links are live.
hxxps[://]smartconcil[.]sbs#ZmVpbGljaWEuY2hvb0B0YW5jaG9uZ2dyb3VwLmNvbQ==Targeted phishing with the victim's email Base64-encoded in the URL fragment — a fingerprint of the modern BEC kit. The .sbs TLD is consistently among the most-abused in registry takedown reports.
hxxps[://]kraftsdigitale[.]de/r74l2My/#Xmaja[.]grozdanovska@flix[.]comA .de domain hosting a credential-harvest landing page, with the recipient's email pre-filled in the fragment so the form auto-populates "this is for you." The named target is a flix.com (FlixBus) employee.
hxxps[://]demeanor832[.]jorviaxi[.]com/categorization96/$ron[.]griffis@boneandjoint[.]orgAlgorithmically generated subdomain hosting a credential-collection page. The dollar sign separator and target email at the end are signatures of the "Tycoon"-family Adversary-in-the-Middle kit.
Section IV
The non-BEC catches of 2025 are a smaller and stranger category. Two are recurring sightings of the WannaCry kill-switch domain — still flagged by major AV products as a known-bad reference indicator. One is an early Steam Community typosquat that, in hindsight, was the warning shot for the gaming-credential campaign that scaled up in 2026.
hxxps[://]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com/WannaCry kill-switch domain reappearing in 2025. Likely a security-research lab or CTF participant; the engine count is high because most major AV products keep the kill-switch as a "known-bad" reference indicator.
hxxps[://]gfrg[.]zafmvuvfjhyu[.]sa[.]com/cllascio[.]php?342d363837343734373037333361326632663734363537333734326537333735376136393661366636663265363137303730326636623736346234303638353337363539373333343733373232662dGenerated subdomain on .sa.com — a long-running mass-phishing infrastructure pattern. The hex blob in the query string is a per-target token used by the kit to load the right brand template.
hxxps[://]ctmwhwwwtest[.]forum[.]esquelesquad[.]rip/?url=https%3A%2F%2Fjuggler%2Emilanosolutions%2Eit%2Ecom%2FlmUc29Yg%2F%23Fkardos[.]norbert@trans-sped[.]huA .rip-domain redirector forwarding to an .it.com lookalike with a Hungarian logistics employee's email in the fragment. Two-hop indirection like this is meant to defeat naive URL allow-listing.
hxxps[://]amazon[.]package-delivery[.]com/H7O3rVTfidY9MVc9?/orders/confirmClassic "fake Amazon order confirmation" lure delivered via QR. The sub-subdomain trick — "amazon" prepended to an attacker-owned base domain — is the most common mistake humans make when reading URLs at a glance.
hxxps[://]steamcommurinity[.]com/613013246479Steam Community typosquat — note the "muRInity" instead of "muNIty." Reads correctly to a casual eye and routes the victim through a fake Steam login. This was the early-warning signal of a campaign that would scale dramatically in 2026.
Section V
The single 2025 entry we point to most often when we explain the 2026 explosion is steamcommurinity.com — a Steam Community typosquat, scanned in Charlotte in March, flagged by seven engines. It was a single catch, easy to miss in the monthly noise.
Eleven months later, in April 2026, we caught stleamcommuunity.com — same brand, same target audience, twenty-two engines, multiple scans worldwide, and two clear sister domains hosted on the Roblox-impersonation infrastructure described in the 2026 report.
The lesson for anyone running a small QR-defence pipeline of their own: the first catch in a family is rarely loud. Look for the typo, watch for it again, and you have a six-month head start on the cluster.
Note on authorship. The narrative in this report was drafted with AI assistance from real production data — every catch, stat, and VirusTotal link is verbatim from the IsThisQRSafe pipeline. The numbers and case files are not AI generated; only the prose around them is.
Sourcing & Methodology
All catches in this report are real entries from the IsThisQRSafe production database. Each is a URL submitted by a real user who scanned a QR code with the camera-or-upload flow on web or mobile, then ran through VirusTotal's 90+ engine analysis. We define a "catch" as a URL flagged by three or more independent engines as malicious — a threshold that filters single-engine false positives while remaining sensitive enough to catch newly-stood-up phishing infrastructure.
Coarse location, when shown, is captured only when a user voluntarily shares it after seeing a malicious verdict — a privacy-preserving design choice that keeps location off our servers for the ~99% of scans that turn out to be safe. Locations are reverse-geocoded to the nearest city and discarded after the case file is published.