Nothing to Click, Nothing to Scan, One Phone Number

The email that landed in a senior recipient's mailbox at a regional commercial bank contained nothing an automated control could take apart. No link. No attachment. No embedded image, no QR code, no tracking pixel, no HTML form. Three lines of body text, a subject line quoting a dollar amount, and one phone number.

The subject read An order for $449.70 is being activated at the moment. The body was laid out as a four-field pseudo-receipt: Product MacBook, Amount $449.70 USD, Payment Method PayPal, Order Status Pending. Processing, it said, would complete within 24 hours. If the recipient had not authorized the purchase, there was exactly one way to stop it, and that was to call (828) 372-5130.

That is the whole attack. Nothing to detonate, nothing to rewrite, nothing to fetch and score. The payload was a person willing to pick up the phone.

The Object-Centric Model Has Nothing to Examine

Most of the inspection stack that stands between an inbox and an attacker is built around objects. URL rewriting needs a URL. Detonation needs a file. Domain reputation needs infrastructure to look up, and content-disarm tooling needs active content to strip. Remove all of it, and a large part of the pipeline reports clean because it was never handed anything to judge.

That is the design behind telephone-oriented attack delivery, the callback pattern that usually shows up with an object attached, an invoice rendered as an image or a passwordless PDF carrying a support hotline. This message did not bother with the object. It is vishing in the purest form the medium allows: the email is only a delivery note for a phone number, and every consequential step happens on the call, where no email control has visibility.

Strip the objects out and what remains for a defender to reason about is the text itself. Fortunately, the text was careless.

The Lure Argued With Itself Four Times

A MacBook for $449.70 is the first problem. No configuration Apple sells has ever carried that price, and the number is precise enough to look like a real total while being far too low to be one. Fake-order scams price the fictional purchase to provoke a call, and the tension between plausible-looking cents and an implausible headline figure is the seam.

The second problem is everything the receipt does not say. There is no order number, no merchant name, no shipping address, no partial account reference. A genuine payment confirmation is dense with identifiers, because identifiers are what make it useful. This one carried a product category, a total, a payment brand, and a status, which is precisely the set of fields a recipient needs to feel alarmed and none of the fields they would need to verify anything independently.

Third, a real notice from a payment provider comes from the payment provider. This one came from an organizational mailbox with no relationship to consumer retail.

Fourth, and most telling, the footer did not match the message above it. The signature block at the bottom carried public-sector education boilerplate belonging to the sending account's own organization, sitting underneath a consumer-order pretext. That is the fingerprint of a template composed inside a hijacked account, where the attacker types a new body and never clears the automatic signature the mailbox appends. As a smaller note in the same direction, the callback number is formatted as a North American one while the mailbox it arrived from sits with a government agency in Southeast Asia.

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

The Signature Was Real. The Mailbox Was Borrowed.

The authentication story here is the part worth slowing down on, because it is the opposite of what a callback scam usually looks like.

At the originating hop, everything passed. SPF passed on a Google Workspace sending address. DKIM passed with a valid signature belonging to the sending organization's own domain. DMARC passed on an aligned header From. Composite authentication resolved as a pass at the highest confidence value the receiving stack assigns (compauth=pass reason=100). This message was not spoofed at the protocol level in any sense. The sending domain genuinely signed it.

An SPF failure does appear later in the header chain, and it is worth naming so it is not misread. It sits at the recipient's own content-disarm relay, the hop where the bank's gateway forwarded the message onward. Forwarding breaks SPF by design, because the final hop presents an IP address the sending domain never listed. Under RFC 7489, the useful question is whether an aligned identifier authenticated at the origin, and one did. Reading that late failure as spoofing would invert the actual finding.

What that means operationally is that the abused account was almost certainly under someone else's control. The organization behind it is a bystander here, not an adversary, and its domain is left out of the indicator table below for that reason. Blocking it would punish a public agency and would not touch the attacker, who needs only the next compromised mailbox. This is why account takeover protection belongs on both sides of the relationship: a takeover somewhere else in the world becomes a reputation-clean sending platform aimed at you.

What Actually Caught It

With no link to score and no file to open, the verdict had to come from behavior and context. Themis, our Adaptive AI analyst, flagged the message at 90 percent confidence and labeled it as a vishing attempt against a high-value recipient. The incident was resolved as phishing automatically.

The reasoning available to a behavioral model is the same reasoning a careful analyst would use. A consumer order confirmation is not the kind of mail this recipient receives from this correspondent. A phone number as the sole call to action, with no self-service path, is anomalous in transactional mail. A pretext and a signature block that describe two unrelated organizations do not co-occur in legitimate correspondence. None of those signals are objects. All of them are relationships.

The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and phishing in 15 percent of them. A zero-payload callback lure is that statistic in its most stripped-down form, since the human is not merely one factor in the chain, the human is the entire chain.

Mapping to MITRE ATT&CK

• T1566 Phishing covers the delivery, with neither the attachment nor the link sub-technique applying, because the message contains neither.
• T1566.004 Phishing: Spearphishing Voice covers the intended second stage, where the recipient initiates the call and the real interaction begins.
• T1078 Valid Accounts covers the delivery platform, a legitimate third-party mailbox sending authenticated mail on its owner's behalf without the owner's intent.

Indicators of Compromise

The Takeaway

A clean verdict on a message with no objects in it is not a finding. It is a measurement of what the message failed to provide, and an attacker who understands that will keep providing nothing.

Three things follow. First, treat a phone number that is the only path forward as an indicator in its own right, the same way a fresh domain or an executable attachment would be, because in this class of attack the number is the infrastructure. Second, weigh internal coherence: a price that cannot be real, a receipt without identifiers, and a footer describing a different line of business are all detectable without leaving the message body. Third, keep authentication in its lane. SPF, DKIM, and DMARC establish that a domain authorized a message. They say nothing about who is currently sitting in the mailbox, and a takeover somewhere in the world converts a reputable sender into someone else's delivery platform. CISA's phishing guidance (https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one) and NIST's definition of phishing (https://csrc.nist.gov/glossary/term/phishing) are both useful anchors for building that habit into training.