The Phishing Kit Left Its Comment Tags in the Body

A payment confirmation for a Citi Diamond Preferred Mastercard reached the chairman and chief executive of a small, privately held consumer-services company. Almost all of it was real. The card copy, the account and bill-payment links, the contact and security and privacy links in the footer, the App Store and Google Play badges beneath them: every one of those destinations resolved to a genuine Citi, Citibank, Apple or Google property and scanned clean, because none of them had been touched.

One block in the middle of that message was fabricated. Somebody had grafted an extra section titled "Statement and Disbursements Disclosure" into the body of an otherwise authentic notice, given it a single button reading View Draft Contract, and sent the whole assembly through Amazon SES from a domain that has nothing to do with any bank.

The Receipt Was Written for Another Cardholder

The borrowed content was not a generic template pulled off a brand's public site. It was somebody's actual receipt. The greeting named a cardholder who does not work at the target company, and the confirmation number, 3981, referred to a payment the target never made on an account the target does not hold. Whoever assembled this reused one real transactional notice whole, personalization included, without editing either field.

That is the sharpest tell in the message and it costs nothing to check. Most of the links needed no scrutiny at all, because they were genuinely the issuer's. The two fields that identified a specific human being were both wrong, and they sat above the fold, before any link was in play.

The 2024 Verizon Data Breach Investigations Report puts the human element in 68% of breaches and puts pretexting, mostly business email compromise, at the top of the social-engineering categories. A message assembled like this one leaves a person as the last control standing, and one concrete question, does this receipt belong to me, is a better use of their attention than auditing a dozen destinations.

The Kit Forgot to Clean Up After Itself

Three artifacts in the raw source gave it away, and all three were the kit's own construction showing through.

The first was a comment left in the HTML, plainly labelled as the end of an injected content block, sitting precisely where the grafted section stopped and the genuine template resumed. It was a build marker nobody was meant to read, and nobody removed it.

The second was an image alt attribute on the logo in the footer. Instead of describing the logo it contained a raw templating placeholder, reading ##victimrealdomain##, a merge token that should have been replaced at send time with the target's domain and was not. A real issuer's transactional mail does not carry a slot for the reader's own domain in the first place, so its presence is direct proof that an automated tool built this message from a template.

The third was what happened where that same merge did fire. Inside the injected block the fake document was named for the recipient's own company domain, followed by a payment-disbursement-disclosure label. The block's footer described itself as a system notification from that domain, and the copyright line beneath it named the domain again. Same variable, two substitutions out of three.

No bank prints your own company domain inside its own notice to you, and no bank ships a build comment.

The Signature Belonged to a Stranger

The authentication results were unambiguous. SPF passed on the envelope sender. DKIM passed twice, once for the sending domain and once for Amazon's own signing domain. DMARC passed with an action of none, aligned to the domain in the From header, and Microsoft's composite authentication returned a pass with a reason code of 100. Nothing was spoofed and no lookalike domain was involved.

The domain that all of this validated was a generic-sounding commercial name registered roughly eight years earlier, privacy-shielded registrant, sending through an Amazon SES region in the western United States. It had no relationship to Citi at any level. That is a property of the standard rather than a failure of it: RFC 7489 aligns the From header against a verified signature, so it can only ever tell you that the domain in the header really sent the mail. It has no opinion about the artwork inside. The question that resolves a message like this one is not whether the domain passed, but whether the domain that passed has any plausible relationship to the brand in the artwork.

Domain age worked in the attacker's favor for the same reason. Reputation heuristics are tuned to catch registrations minutes or hours old, and eight years of history sails past them.

See Your Risk: Calculate how many threats your SEG is missing

Two Hops Between the Button and the Destination

The View Draft Contract button did not point anywhere obviously suspicious. It pointed at a Mandrill click tracker, the transactional click-redirect service, with the true destination sitting in a base64-encoded parameter further along the URL. Decoded, it resolved to a subdomain of a marketing-styled domain registered roughly eight months earlier through a European registrar, to a registrant organization in Peru.

The scanner verdict on that final destination came back mixed rather than confirmed malicious, and no end goal was established for the landing page. The evidence that this was an attack is the identity mismatch and the kit artifacts, not a verdict. A click-tracker hostname is an absence of information rather than a reassurance, which is why URL and payload attack protection has to resolve the encoded destination before it has anything to score.

What stopped it was the combination of who received it and what one link did. Our Adaptive AI tagged the mailbox as a VIP recipient and the content analysis named the injected button's link specifically, among the dozen that were fine. The message was quarantined and mitigated, and a human analyst later confirmed the phishing classification rather than dismissing it as a marketing false positive, the easy wrong answer on mail this clean.

The Merge Engine Is the Fingerprint

The generalizable finding is not the artwork, which was flawless, or the authentication, which passed on every axis. It is that a templating engine leaves traces, and those traces are cheap to look for once you know their shape.

Three of them belong in a triage habit. Build comments and section markers left in delivered HTML, because a production mail system does not annotate its own output for the reader. Placeholder tokens that never fired, usually wrapped in doubled delimiters and sitting in an attribute rather than in visible text, which is why they survive a visual review. And any appearance of the reader's own organization by domain inside a notice claiming to come from a third party, because a genuine sender already knows who it is and has no reason to tell you who you are.

None of the three requires a redirect or a verdict. The NIST definition of phishing turns on a message impersonating a trusted entity, and these artifacts are that impersonation failing out loud at the seams. Pair them with CISA's phishing guidance for the organizational half.

The kit did the analyst's work in this case by leaving its seams showing. It will not always be that careless, and the identity mismatch stood on its own regardless. But when the seams are visible, they are the fastest conclusive evidence in the message.

Indicators of Compromise

MITRE ATT&CK Mapping