Friday Cyber Briefing • Microsoft Defender XDR • Email Security • Refund Scam
The Email Came From Zoho... But Claimed To Be Amazon
The platform looked legitimate.
The footer was real. The sender appeared to use Zoho Invoice. The message was formatted like a normal payment notification.
But the story claimed an Amazon Gift Card purchase had been verified.
Then came the refund phone number.
The platform was trusted.
The message was not.
Trusted Platform Abuse
The alert was not about a fake Amazon domain. It was about a legitimate invoice platform being used to deliver a false payment story.
Check sender and platform context
Validate the business story
Investigate authentication and delivery
The invoice looked normal. The story did not.
The email was not loud. It was clean, simple and designed to make the recipient react before thinking.
Payment receivedThe subject and layout suggested a completed transaction, reducing the chance the user would question the message.
Amazon Gift Card claimThe content claimed a gift card purchase had been verified, even though the delivery platform was Zoho Invoice.
Refund phone numberThe goal was not necessarily a click. The goal was to make the recipient call the attacker.
Why this works
Attackers do not always need to spoof a brand directly. Sometimes they abuse a platform defenders already trust.
The platform has reputationInvoice and SaaS platforms often have good sender reputation, proper authentication and familiar templates.
The content carries the scamThe suspicious part may live inside the message body, not the domain, SPF result or DKIM result.
The action is emotionalA fake payment creates urgency. The user is pushed toward the refund number before they validate the invoice.
Find suspicious payment received emails
Start with the subject and sender context, then pivot to authentication and delivery details.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
EmailEvents
| where Timestamp > ago(30d)
| where Subject has_any ("Payment Received", "invoice", "payment")
| project Timestamp, RecipientEmailAddress, SenderFromAddress, SenderMailFromAddress, Subject, DeliveryAction, ThreatTypes, NetworkMessageId
| order by Timestamp desc
Inspect Zoho Invoice sender patterns
A legitimate sender service does not prove that the business message is legitimate.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
EmailEvents | where Timestamp > ago(30d) | where SenderFromAddress has "zoho" or SenderMailFromAddress has "zoho" | project Timestamp, RecipientEmailAddress, SenderFromAddress, SenderMailFromAddress, Subject, EmailAuthenticationResults, AuthenticationDetails, NetworkMessageId | order by Timestamp desc
Review URLs connected to the message
Even when the scam is phone-driven, invoice emails often include platform links worth reviewing.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
EmailUrlInfo
| where Timestamp > ago(30d)
| where Url has_any ("zoho", "invoice", "payment")
| project Timestamp, NetworkMessageId, Url, UrlDomain
| join kind=inner (
EmailEvents | project NetworkMessageId, RecipientEmailAddress, Subject, SenderFromAddress
) on NetworkMessageId
| order by Timestamp desc
Check whether anyone clicked
If the email reached users, UrlClickEvents helps determine whether the message became user interaction.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
UrlClickEvents
| where Timestamp > ago(30d)
| where Url has_any ("zoho", "invoice", "payment")
| project Timestamp, AccountUpn, Url, ActionType, IsClickedThrough, NetworkMessageId
| order by Timestamp desc
What the investigation revealed
The email was not suspicious because Zoho existed. It was suspicious because the story did not match the platform.
The sender and claim did not matchA Zoho Invoice notification claiming an Amazon Gift Card purchase created the first business-context mismatch.
The refund number matteredThe attacker was trying to move the victim away from email controls and into a phone conversation.
Authentication was not the finish linePassing authentication would only prove the message came through the platform. It would not prove the invoice story was real.
Investigation lessons
Modern phishing analysis must combine email authentication, platform context and human business logic.
Do not trust the platform aloneTrusted SaaS delivery does not make a message trustworthy. It only changes the investigation path.
Validate the storyAsk whether the recipient expected the invoice, recognises the sender and understands the payment.
Watch for phone-based scamsNot every phishing email wants a click. Refund scams often try to move the attack to a phone call.
Related Agent Foskett investigations
This briefing connects naturally to email authentication, invoice scams, DMARC failures and phishing investigation workflows.
The Invoice Wasn't An Email. It Was A Calendar InviteA payment story delivered through an unexpected channel.
Investigating EmailEventsStart with sender, recipient, subject, delivery and message identifiers.
Investigating EmailAuthenticationResultsUnderstand why authentication is evidence, not a final verdict.
Investigating AuthenticationDetailsReview SPF, DKIM, DMARC and composite authentication context.
Email Spoofing Detection GuideCompare visible sender identity with authentication and delivery evidence.
Building Complete Phishing InvestigationsConnect message, URL, click and response evidence.
Final thought
The scam did not need to break the platform. It only needed to borrow its trust.
The Logs Already Knew.The sender, subject, platform, authentication and message story were all separate clues. Together, they changed the case.
The mismatch matteredZoho Invoice and Amazon Gift Card did not belong in the same payment story without explanation.
The phone number changed the intentThis was not just an invoice notification. It was a refund scam designed to start a conversation.
