ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Email Security • Reply-To Fraud • Microsoft Defender XDR

The Reply-To Address Told The Real Story

The email had no subject.

It promised a MoneyGram donation gift and a cash prize of €520,000. The sender appeared to be one person, but the message told the recipient to reply to a completely different Gmail account.

Agent Foskett did not reply. He opened the evidence instead.

Discuss email security Back to briefings
Agent Foskett Microsoft Defender XDR Reply-To email investigation
Briefing summary

A crude prize scam still teaches a serious investigation lesson. The visible sender was not the reply destination. The attacker did not need the victim to click a link. They only needed the victim to answer the wrong mailbox.

No Subject
Unexpected €520,000 Prize
From Address = One Identity
Reply-To = Different Mailbox

The email was bad, but the tactic was real

Not every phishing email is technically clever. Some are simple, direct and designed to move the conversation away from the protected mailbox.
The subject was missing A blank subject is not proof of compromise, but it is a useful clue. Legitimate prize, payment and donation notices normally provide a reference, context or case number.
The promise was impossible The message claimed the recipient had received a MoneyGram donation gift and a cash prize of €520,000. Unexpected money is one of the oldest social engineering hooks.
The reply path mattered most The attacker wanted the recipient to reply to a different Gmail address. That reply path is where the fraud would continue.

The evidence in plain sight

The body was short, but the identity mismatch was enough to start the case.
Visible sender The message appeared to come from Alfredo Tiska Garcia using an address at sanbernardo.cl. That was the identity presented to the mailbox.
Requested reply destination The body instructed the recipient to reply to drbene779@gmail.com. That was not the same person, organisation or domain.
Operational goal The attacker was not asking for a click. The goal was to start a conversation where fees, identity documents or bank details could be requested later.

Why Reply-To matters

Users often trust the display name. Defenders compare the display name, From, Reply-To, Return-Path and authentication evidence.
From is the identity claim The From address is what the sender wants the recipient to recognise. Attackers can use it to create trust, confusion or curiosity.
Reply-To is the conversation path Reply-To can redirect the user response to another mailbox. That matters when the attacker wants the conversation to continue outside the claimed sender identity.
Return-Path is transport evidence Return-Path and envelope sender values can help analysts understand where bounces and transport-level handling were directed.

The first Defender XDR question

Agent Foskett starts by finding the message and reviewing sender identity, delivery outcome and authentication evidence.
reply-to-case-start.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
EmailEvents
| where Timestamp > ago(30d)
| where Subject == "" or isempty(Subject)
| where SenderFromAddress has "sanbernardo.cl"
    or SenderMailFromAddress has "sanbernardo.cl"
    or AuthenticationDetails has "sanbernardo.cl"
| project
    Timestamp,
    NetworkMessageId,
    SenderFromAddress,
    SenderMailFromAddress,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    DeliveryAction,
    DeliveryLocation,
    AuthenticationDetails

What Defender can tell you quickly

Even before reading the raw headers, Microsoft Defender XDR can help establish how the message entered the environment.
Who received it? RecipientEmailAddress shows the mailbox exposed to the message and helps determine whether the email was isolated or part of a wider campaign.
Was it delivered? DeliveryAction and DeliveryLocation help determine whether the message reached the inbox, went to junk, was blocked or was removed later.
Did authentication help? AuthenticationDetails can show SPF, DKIM, DMARC and composite authentication signals that explain why the message was trusted or challenged.

Search for the scam language

When the sender is disposable, the wording can become the strongest pivot.
moneygram-prize-language.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
EmailEvents
| where Timestamp > ago(30d)
| where Subject == "" or Subject has_any ("gift", "donation", "cash", "prize", "MoneyGram")
| where AdditionalFields has_any ("Moneygram", "520,000", "donation gift", "cash prize")
    or AuthenticationDetails has_any ("Moneygram", "520,000", "donation gift", "cash prize")
| project
    Timestamp,
    NetworkMessageId,
    SenderFromAddress,
    SenderMailFromAddress,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    DeliveryAction,
    DeliveryLocation

Important analyst note

Reply-To is a header. Depending on licensing, data source and investigation view, it may be easier to confirm in message headers, Threat Explorer, email entity details or submitted email analysis than directly in EmailEvents.
Do not rely on one field If Reply-To is not visible in your hunting table, open the message entity or original headers. The absence of a convenient column is not the absence of evidence.
Preserve the message If the email is still available, preserve headers before deletion or remediation removes context that could help the investigation.
Document the mismatch Record the visible From identity and the Reply-To destination. That mismatch explains the social engineering path.

Compare sender domains at scale

A different Reply-To is suspicious in this case, but sender-domain mismatch can also reveal wider impersonation patterns.
sender-domain-mismatch-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| where Timestamp > ago(30d)
| extend SenderFromDomain = tostring(split(SenderFromAddress, "@")[1])
| extend SenderMailFromDomain = tostring(split(SenderMailFromAddress, "@")[1])
| where isnotempty(SenderFromDomain)
| where isnotempty(SenderMailFromDomain)
| where SenderFromDomain != SenderMailFromDomain
| summarize
    Messages = count(),
    Recipients = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromDomain, SenderMailFromDomain, DeliveryAction, DeliveryLocation, ThreatTypes
| order by Messages desc

The fraud path if the user replies

There may be no malicious URL. The payload is the conversation.
Stage 1: curiosity The user replies to ask whether the prize is real. That confirms the mailbox is active and the person is engaged.
Stage 2: invented process The scammer introduces forms, verification steps, courier arrangements, tax clearance or anti-money-laundering language.
Stage 3: extraction The victim is asked for fees, identity documents, bank details or more personal information. The fake prize never arrives.

Check whether anyone clicked anyway

This sample was reply-driven, but analysts should still check for URL evidence across similar messages.
related-url-impact-check.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let SuspiciousMessages =
    EmailEvents
    | where Timestamp > ago(30d)
    | where SenderFromAddress has "sanbernardo.cl"
        or Subject has_any ("gift", "donation", "cash", "prize", "MoneyGram")
    | project NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject;
EmailUrlInfo
| join kind=inner SuspiciousMessages on NetworkMessageId
| project
    Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    Url,
    UrlDomain

Hunt for user interaction

If links existed, UrlClickEvents can help determine whether the user interacted and what Defender recorded.
url-click-impact-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
let SuspiciousMessages =
    EmailEvents
    | where Timestamp > ago(30d)
    | where SenderFromAddress has "sanbernardo.cl"
        or Subject has_any ("gift", "donation", "cash", "prize", "MoneyGram")
    | project NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject;
UrlClickEvents
| join kind=inner SuspiciousMessages on NetworkMessageId
| project
    Timestamp,
    AccountUpn,
    RecipientEmailAddress,
    SenderFromAddress,
    Subject,
    Url,
    ActionType,
    Workload
| order by Timestamp desc

Agent Foskett moment

The email did not need to be polished. It only needed one person to reply.
The user saw free money The human hook was simple: a huge amount of money and urgency. The message was designed to trigger curiosity before logic.
The analyst saw routing intent The key clue was not the prize. It was the instruction to continue the conversation with a different mailbox.
The case was in the headers From, Reply-To, Return-Path and authentication results told the real story before any response was sent.

Questions every analyst should ask

Reply-to fraud is simple, but the investigation discipline is the same.
Who did the message claim to be from? Check display name, From address, sender domain and whether the organisation or person makes sense.
Where did the message want the user to reply? Compare Reply-To with From. A different mailbox is not automatically malicious, but in a prize or payment lure it is a major clue.
Was there any user impact? Check delivery, clicks, replies, mailbox forwarding rules and any follow-up messages from the same campaign.

Related investigations

The DMARC Failure Was The First Clue Follow a sender authentication investigation where DMARC failure exposed a trust problem.
The Email Passed SPF, DKIM and DMARC — Why Did Composite Authentication Still Fail? Understand why authentication passing does not always mean Defender should trust a message.
The Link Said USPS — The URL Told A Different Story Investigate how visible link text can hide a completely different destination.
The User Reported The Email — But It Was Already Gone Learn how Defender telemetry can explain what happened after a suspicious email disappeared.
AuthenticationDetails Explained Understand how Microsoft Defender records SPF, DKIM, DMARC and composite authentication evidence.
EmailEvents KQL Guide Build practical Defender XDR email investigations using sender, recipient, delivery and threat fields.
The email promised €520,000.
But the Reply-To address showed where the scam really wanted the conversation to go.
Contact GEMXIT

Final thought

Reply-To is small, but it can completely change the story.
At GEMXIT We help organisations investigate Microsoft Defender XDR, phishing, spoofing, Microsoft 365 email security and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not only ask what the email says. Ask where the attacker wants the user to go next: a link, an attachment, a phone number or a reply address.
Develop IT. Protect IT. The prize was fake. The Reply-To clue was real. GEMXIT PTY LTD | GEMXIT UK LTD

The Reply-To Address Told The Real Story

This Agent Foskett investigation explains how a suspicious cash prize email used a mismatched Reply-To address to move the victim into a fraudulent conversation.

Microsoft Defender XDR Reply-To Email Investigation

EmailEvents, AuthenticationDetails, SenderFromAddress, SenderMailFromAddress, DeliveryAction, DeliveryLocation, EmailUrlInfo and UrlClickEvents can help defenders reconstruct suspicious email investigations.

Reply-To Fraud, SPF, DKIM, DMARC And Composite Authentication

Reply-To mismatches can reveal social engineering, impersonation, suspicious sender identity, fake prize scams, advance fee fraud and business email compromise patterns.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026