callback phishing email with no url or attachment evaded gateway scanning and reached users
Fixes callback phishing mail with no URL or attachment evading gateway scanning by adding content, sender, and process controls for phone based lures. Use when users receive callback scam mail that contains only text and a phone number. Not for URL based phishing handled by link scanning.
TL;DR
Stop looking for a payload that is not there and detect the lure itself: tune content rules for the callback pattern, a billing or subscription scare, a reference number, and an urgent phone instruction, train the service desk and users to treat unsolicited callback numbers as untrusted, and publish the real support numbers users should call instead. The gateway missed the mail because its scanners grade links and files, and this message deliberately carries neither.
callback phishing email with no url or attachment evaded gateway scanning and reached usersUse this when
- Users received a scam mail whose only call to action is to phone a number.
- The message has no URL, no attachment, and passes link and file scanning cleanly.
- The text uses a fake invoice, subscription renewal, or account charge story.
Not for this skill when
- The message contains a shortened or obfuscated URL as well. Normal URL controls apply first.
- The phone number belongs to a legitimate vendor notification. Verify through the vendor account portal before treating it as a scam.
Steps
- Collect several samples and list the repeated phrases, the phone numbers, and the story elements they share. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: a pattern list for the campaign is written from real samples
- Create or tune a content rule that scores the combination: callback instruction plus invoice story plus an external sender, and route matches to quarantine or a warning banner, not silent delivery. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the rule is saved in test or audit mode with the pattern elements listed
- Run the rule in audit mode against recent mail for a day and review false matches, especially real vendor receipts. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: audit results show the rule catching samples without hitting normal vendor mail
- Promote the rule to active for high scoring matches and add the known scam numbers to your block list where the gateway supports number based entries. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the active rule shows enforcement enabled and the numbers are listed
- Brief users and the service desk with one clear instruction: never call a number from an unsolicited billing mail; use the number on the official site or card. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the briefing is published and the service desk script is updated
Why it happens
Callback phishing moves the crime off the mail system entirely: the message is just text, and the credential or payment theft happens on a phone call with a confident operator. Scanners built to detonate links and files see a clean, boring message. Detection therefore has to move to language patterns, sender context, and human process, which feels less technical but is the only layer where this lure actually exists.
Variants and edge cases
callback phishing email no url no attachment evaded gateway scanning
The payload free wording that explains the miss.
phone number phishing vishing email invoice scam detection rule
The vishing variant naming the phone channel.
callback scam email reached users how to block text only phish
The plain language variant for smaller teams.
Compatibility: Exchange Online mail flow rules and Defender policies, gateway content filtering, security awareness guidance.
Edge cases to check:
- Rotate attention to the phone numbers: they change per campaign, so phrase patterns outlast number blocks.
- Legitimate callback mail exists from some vendors; an external banner plus user guidance handles the grey zone better than a hard block.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_tACTj73EUqysC1iZDR8Xvw