An email arrived with the subject VINRA TARADO 54, carrying a tidy twenty-row table of numbers under the headings NO / NUMBER / CODE / DATE / VALUE / GROUP. The rows count up in sequence. The dates count up in sequence. The values are noise. It is a document-shaped object with no document inside it, and its only job is to look like something worth opening.
The table is not the payload. Above it sits one hosted image with an image map stretched across the whole thing:
<img src="https://s3.ap-south-1.amazonaws.com/scholeducatnop1/NUMBER1.png"
usemap="#pugbewqkfr">
<map name="pugbewqkfr">
<area href=".../NUMBER1.html#cl/201835_md/600/66097/1419/1686/8403"
coords="1,0,695,1640" shape="rect">
<area href=".../NUMBER1.html#un/201835_md/600/66097/1419/1686/8403"
coords="237,1648,300,1658" shape="0">
</map>
A 695×1640 rectangle is not a link, it is the entire visible message. There is no text to hover over, no anchor to inspect, nothing to read before tapping. On a phone it is unmissable.
The second region is 63 pixels wide: the unsubscribe. It carries the same identifier as the first and differs only in the cl/ versus un/ prefix. Unsubscribing reports exactly what clicking reports — that the address is real and someone is reading it.
The redirector is 187 bytes
The linked page has no content at all:
<!DOCTYPE HTML>
<html lang="en-US">
<script>document.location.href =
'Https://bilujshbds689jksjbxgtiopksd7.buy--viagra-online.com/'
+ window.location.href.split('#')[1];</script>
</html>
It reads the part of its own URL after the # and appends it to a hard-coded destination. The destination is pharmaceutical spam rather than credential theft — nothing on the far end asks for a password.
Why that one line is the interesting part
A URL fragment — everything after the # — is never transmitted to the server. It is a client-side construct, and the browser strips it before the request goes out.
email --> NUMBER1.html#cl/201835_md/600/66097/1419/1686/8403
\______________________________________/
fragment: never leaves the browser
S3 sees --> GET /scholeducatnop1/NUMBER1.html
a static file. no query. no identity. no campaign.
the page's script reads the fragment locally, rebuilds the real URL
--> bilujshbds689jksjbxgtiopksd7.buy--viagra-online.com
/cl/201835_md/600/66097/1419/1686/8403
Amazon's access log for that object shows a series of hits on a static HTML file. No per-recipient identifier ever touches their infrastructure, because the recipient's own browser performs the join between the anonymous file and the tracking value.
This is the part worth carrying away, and it is not really about phishing. Putting an identifier in the fragment removes it from every server-side log on the path — the host's, the CDN's, the proxy's — while leaving it fully available to script running in the page.
The same property that makes analytics vendors keep session state in fragments is what makes this campaign's hosting look inert under inspection.
The mail authenticated perfectly
The tempting read is that a message like this must be forged. It was not:
dkim = pass d=<redacted>.20251104.gappssmtp.com s=20251104 spf = pass 209.85.220.69 designated as a permitted sender dmarc = pass (p=NONE sp=NONE)
The signature is a Google Workspace DKIM key belonging to the sending institution's own tenant, and the message was relayed through Google's authorized outbound infrastructure. That key is held inside Google's servers and only signs authenticated sends from that tenant. It cannot be forged from outside.
So this was not a spoof. Someone is signed in to that mailbox and sending from it.
Authentication proves the channel, never the intent. SPF, DKIM and DMARC answer one question — did this message really leave the infrastructure it claims to have left. A compromised account passes all three, perfectly, every time, because nothing about it is forged.
Which makes "it passed DMARC" a poor safety signal. Here, passing is exactly what got it into the inbox rather than the spam folder; it was reclassified later, on content and destination reputation, not on authentication.
Worth noting separately: the domain publishes -all on its SPF record, which declares that anything not on the list should be rejected, while its DMARC policy is p=none, which asks receivers to do nothing about failures. That combination is common and mostly harmless — but it means the reports that would reveal this activity are being generated and, evidently, not acted on.
What this does to abuse reporting
File a report against the bucket and a reviewer sees a 187-byte HTML file being fetched. No recipient list, no campaign identifier, no volume signature — nothing separating it from a stub somebody forgot to delete. The abusive behaviour is real, but it is not inside the artefact being reported.
The layers also fail independently. Remove the S3 object and the destination keeps serving whatever else feeds it; remove the domain and the bucket becomes a harmless stub. Reporting one is not reporting the other.
| Layer | What it is | Who can act |
|---|---|---|
| Sender | A compromised Google Workspace mailbox at an educational institution | The institution's IT — this is an intrusion, not a filtering problem |
| Redirector | AWS S3, ap-south-1, bucket scholeducatnop1 | AWS abuse |
| Destination | buy--viagra-online.com, behind Cloudflare on a wildcard subdomain | Cloudflare abuse |
The subdomain bilujshbds689jksjbxgtiopksd7 carries no meaning. A wildcard DNS record resolves anything, so each campaign burns a fresh one and no individual name is worth blocking.
What I did not do
I did not request the final URL. That path contains the tracking identifier, so fetching it is precisely the click-confirmation the campaign exists to harvest — it would mark the address as live and attentive. The destination was characterised instead by requesting the bare domain with the identifier stripped, which answers "what is this" without answering "is this person real".
Both facts needed were available without it: the destination is hard-coded in the JavaScript, and the fragment's role is visible in the same line.
Nothing was executed. The redirector was retrieved as text and read. Its script never ran.
Confidence
| Claim | Confidence |
|---|---|
| Image map covers the full message; the tracking identifier is carried in the fragment; the redirector is 187 bytes of JavaScript | High. Directly observed in the raw message and the fetched file. |
| The sending mailbox is compromised, not spoofed | High. Directly observed. DKIM passes against the institution's own Workspace key, relayed through Google's authorized infrastructure. |
| S3's access logs contain no per-recipient identifier | High, by construction. Fragments are not transmitted. I have not seen Amazon's logs, but the mechanism does not permit it. |
| The destination is pharmaceutical spam rather than credential phishing | Moderate. Inferred from the domain and a bare-root fetch. I did not follow the tracked path, so I have not seen what a real click renders. |
Remaining gaps
No sandbox detonation. Rendering the tracked URL in an isolated browser would show what a recipient actually sees, and whether the destination varies by identifier. That belongs on a disposable host, off this infrastructure, and has not happened.
No campaign scoping. One message is one sample. Whether the same bucket serves other lures, or this identifier format appears elsewhere, is unexamined.
The institution has not been notified at the time of writing. They have an active intrusion and their tenant's reputation is being spent on spam delivery.