The Blog Notification That Was a Vishing Scam

Every authentication check on this email passed, and every one of them was telling the truth. SPF passed. DKIM passed. DMARC passed under a strict reject policy. The message arrived from comment-reply[@]wordpress[.]com, and it genuinely did come from WordPress.com. There was no spoofed sender, no lookalike domain, no forged header, nothing for a reputation engine to flag. It was a real blog notification. It was also a scam.

The recipient, a university faculty member, was subscribed to blog notifications the way millions of people are. What landed in the inbox looked like any other automated alert announcing activity on a WordPress.com blog. The blog was a free WordPress.com subdomain, convenxtechs.wordpress[.]com, and the post had been published by an account handle, pp.jameson8757, with no connection to the reader. The notification template was authentic. The content it carried was not.

The Infrastructure Was Real, So Nothing Flagged

This is the part that makes the case worth studying. There was no infrastructure to blame. The mail originated on WordPress.com's own sending hosts (smtp3-4.bur.wordpress[.]com), carried a valid DKIM signature for d=wordpress.com under the automattic1 selector, and passed a second DKIM check on an intermediate Exchange Online relay hop it transited on the way in. DMARC passed with header.from=wordpress.com under a published policy of p=reject, the strongest enforcement a domain can advertise. Composite authentication passed with reason 100, and the ARC chain validated across both hops.

That is a flawless, fully aligned authentication record. It says who sent the mail and confirms the body was not tampered with in transit. It does not, and cannot, judge whether the words inside are honest. Sender Policy Framework validates the sending server. DomainKeys Identified Mail (see the DMARC specification at RFC 7489) validates message integrity and domain alignment. Neither one reads intent.

The mechanic is elegant in its simplicity. The attacker did not break WordPress.com or bypass anything. They used it exactly as designed. They created a free blog, published a post whose body was a fabricated billing notice, and let the platform's own new-post notification pipeline email that post to subscribers. The abuse rode entirely on first-party infrastructure. To every technical control between the blog and the inbox, this was a routine transactional notification doing precisely its job.

The Payload Was a Phone Number

Open the message and there was no attachment and no credential-harvesting link. The post body posed as a transactional notice. It told the reader that a recent purchase request for Bitcoin had been successfully submitted, and that a previous transaction of USD 767.69 had reached a limit. Beneath that sat a Billing Support block listing a callback phone number, +1 863-329-9954, and an invitation to call about the charge.

That number was the entire attack. This is telephone-oriented attack delivery, a callback scam built on manufactured financial urgency. The email is not the payload. It is the doorway. A reader alarmed by an unexpected Bitcoin charge picks up the phone, and a live operator on the other end walks them toward a payment, a remote-access session, or a credential handover, with no email artifact left behind for anyone to inspect. Because the message contains no malicious URL and no weaponized file, signature and reputation engines have nothing to detonate or block.

See Your Risk: find out how many threats your gateway is missing

Attackers keep reaching for the phone because the economics of trust favor it. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names pretexting, most of it business email compromise, as the top social-engineering incident type, with a median transaction of roughly 50,000 dollars. The report also finds phishing present in 15 percent of breaches. The FBI's 2023 Internet Crime Report tallies business email compromise losses near 2.9 billion dollars for the year and counts tech-support and call-center impersonation among the costliest fraud categories it tracks. A fake billing-support callback is engineered to reach exactly that endgame.

Mapping to MITRE ATT&CK

The tradecraft lines up cleanly with the MITRE ATT&CK framework:

• T1566.002 Phishing: Spearphishing via Service covers the delivery, a lure routed to the target through a legitimate third-party service (WordPress.com blog notifications) rather than direct attacker infrastructure.
• T1598 Phishing for Information covers the callback pretext, a benign-looking notice designed to pull the target into a live phone conversation where the real information gathering and manipulation happen.

Indicators of Compromise

Detection and What to Watch For

Static gateways were never going to catch this. The infrastructure is genuine, the authentication is perfect under a reject policy, and there is no link to a spoofed portal or attachment to sandbox. Detection has to move to behavior and intent. The signal here is a content-versus-template mismatch. A new-blog-post notification is not supposed to carry financial transaction language, a dollar amount, and a phone-callback instruction. When a template built to say someone commented on a blog suddenly reads like a billing dispute, that contradiction is the tell.

This is where our Adaptive AI adds a layer that reputation and authentication miss. Themis, the analyst engine on the IRONSCALES platform, reads the relationship between what a message claims to be and what it actually asks the reader to do, and flags the intent mismatch even when every server-level check comes back green. That judgment draws on 35,000+ security professionals across 17,000+ organizations, cross-tenant visibility a single mailbox cannot see. For building the same reflex across a team, CISA's guidance on stopping phishing at the recognition stage is a solid reference: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one, and NIST's working definition of phishing at https://csrc.nist.gov/glossary/term/phishing keeps the vocabulary precise.

The Takeaway

A green DMARC pass under a reject policy proves one thing only, that WordPress.com sent its own mail cleanly. It says nothing about whether the words inside were true. The uncomfortable lesson of this case is that a trusted platform's notification pipeline is itself an attack surface, and authentication cannot referee content it was never built to read. When the sender is real, the infrastructure is legitimate, and the only thing the message wants is for you to dial a number it handed you, the authentication result is the least interesting fact on the screen. Treat unsolicited billing alerts and support callback numbers as hostile until independently verified, confirm any charge through the vendor's real channel rather than the one in the email, and pair that habit with behavioral detection. That is the same discipline that blunts business email compromise when the next impostor comes calling.