Agent Foskett Academy • SOC Analyst Academy • Module 5 • Lesson 42 • Email & Phishing: From Message to Compromise

Lesson 42 — The Display Name Was Familiar — The Domain Wasn't

The user recognised the sender immediately.

“Accounts Manager — Contoso Supplies.”

The name was familiar. The signature looked right. The request sounded like something the supplier might genuinely send.

But Agent Foskett stopped looking at the name and looked at the address behind it.

accounts@contoso-supplies-payments.com

Almost right is sometimes the most important clue in the investigation.

The display name is what the sender wants the user to see. The domain is evidence the SOC can investigate.

Investigate the Sender Back to SOC Analyst Academy

Agent Foskett investigating display name impersonation and sender domain evidence

The name matched. The domain didn't.

Separate the visual identity presented to the user from the technical identity recorded in Microsoft 365 telemetry.

✓ Check the actual sender

✓ Compare sender domains

✓ Review authentication

✓ Scope the impersonation

Case briefing

WHAT THE USER SAW From: Accounts Manager — Contoso Supplies Subject: Updated payment instructions Professional signature Correct supplier branding Urgent business request ↓ WHAT MICROSOFT 365 RECORDED SenderFromAddress accounts@contoso-supplies-payments.com SenderFromDomain contoso-supplies-payments.com ↓ THE DISPLAY NAME WAS FAMILIAR THE DOMAIN WASN'T

Investigation objective

Identify display-name impersonation by separating the identity presented in the message from the sender address, sender domain and authentication evidence recorded by Microsoft 365.

Investigator's rule

Never let a familiar display name close the identity question. It is presentation, not proof of sender identity.

Stage 1 — retrieve the message evidence

12345678910111213

EmailEvents
| where Timestamp > ago(7d)
| where Subject =~ "Updated payment instructions"
| project Timestamp,
          NetworkMessageId,
          SenderDisplayName,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromAddress,
          SenderMailFromDomain,
          RecipientEmailAddress,
          DeliveryLocation

Read past the display name

The display name explains why the recipient may have trusted the message. The sender address and domain provide stronger technical pivots for the investigation.

Preserve the message identifier

Capture the NetworkMessageId so sender, URL and other message telemetry can be correlated without relying on a potentially reused subject.

Stage 2 — compare the claimed identity with the technical identity

Evidence	Observed	Question
Display name	Accounts Manager — Contoso Supplies	Is this merely a familiar label?
From address	accounts@contoso-supplies-payments.com	Is this an address the supplier actually uses?
From domain	contoso-supplies-payments.com	Does this domain belong to the claimed organisation?
MailFrom domain	Investigate telemetry	Does the envelope sender add useful context?
Business request	Change payment details	Does the request increase potential impact?

Similar is not the same

Attackers often rely on users recognising the shape of a domain rather than reading it carefully. Added words, hyphens and alternative domains can create convincing visual similarity.

Do not assume ownership

A domain that resembles a supplier's name is not automatically controlled by that supplier. Establish ownership and expected business use through approved validation methods.

Stage 3 — check authentication without over-trusting it

123456789101112

let MessageId = "<NETWORK-MESSAGE-ID>";
EmailEvents
| where NetworkMessageId == MessageId
| project Timestamp,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromDomain,
          AuthenticationDetails,
          ThreatTypes,
          DetectionMethods,
          DeliveryAction,
          DeliveryLocation

A deceptive domain can authenticate correctly

If the attacker controls the domain, SPF, DKIM and DMARC may succeed for that domain. Authentication can tell you the message was authorised by a domain without proving that the domain represents the organisation being impersonated.

Ask the alignment question

Which domain authenticated, and is that the identity the user believed they were communicating with? That distinction is central to impersonation investigations.

Stage 4 — inspect the message URLs

123456789

let MessageId = "<NETWORK-MESSAGE-ID>";
EmailUrlInfo
| where NetworkMessageId == MessageId
| project Timestamp,
          NetworkMessageId,
          Url,
          UrlDomain
| order by Timestamp asc

Does the URL support the story?

Compare the URL domain with the claimed organisation and sender domain. An unrelated destination can strengthen the impersonation hypothesis.

Multiple domains can matter

A message may arrive from one domain and send the user to another. Preserve both as investigation pivots rather than collapsing them into one indicator.

Stage 5 — look for the same sender pattern elsewhere

123456789101112

EmailEvents
| where Timestamp > ago(7d)
| where SenderFromDomain =~ "contoso-supplies-payments.com"
| summarize
    Messages=count(),
    Recipients=dcount(RecipientEmailAddress),
    Subjects=make_set(Subject, 20)
    by SenderFromAddress,
       SenderFromDomain
| order by Messages desc

One message or a campaign?

If the same sender domain reached multiple employees, the investigation may need to expand from individual triage to campaign scoping.

Look for variation

Related messages may use different subjects, display names or sender addresses while sharing the same domain or URL infrastructure.

Stage 6 — understand the social-engineering technique

ATTACKER CONTROLS Display name: Accounts Manager — Contoso Supplies Sender domain: contoso-supplies-payments.com Message branding: Copied from legitimate supplier Business request: "Please use our new banking details" ↓ USER RECOGNISES THE NAME ↓ USER MAY NOT INSPECT THE DOMAIN ↓ VISUAL TRUST BECOMES THE ATTACK PATH

The technique exploits recognition

The attacker does not need to perfectly clone every technical detail if the recipient sees a familiar name and acts before checking the underlying identity.

Business context changes severity

A suspicious newsletter and a request to change supplier banking details can contain similar identity clues but create very different potential business impact.

Stage 7 — build the evidence chain

DISPLAY NAME Familiar supplier identity ↓ ACTUAL FROM ADDRESS Different address than expected ↓ SENDER DOMAIN Look-alike / unverified domain ↓ AUTHENTICATION May legitimately pass for that domain ↓ URL EVIDENCE Destination requires investigation ↓ RECIPIENT SCOPE Determine whether others were targeted ↓ SOC VERDICT Based on the complete evidence chain, not the familiar name

Stage 8 — write the investigation finding

SOC FINDING The message presented a display name associated with a known supplier, but Microsoft 365 telemetry showed that it originated from a different domain. The sender domain requires validation and should not be treated as belonging to the claimed supplier based on visual similarity alone. Authentication results must be interpreted against the domain that actually authenticated rather than the organisation the recipient believed had sent the message. The sender domain and message URLs should be used to scope related messages and determine whether additional users were targeted.

Lesson 42 key takeaways

A display name is presentation, not proof of identity.
Always inspect the actual sender address and sender domain.
A look-alike domain can be more convincing because it is almost correct.
Do not assume a similar-looking domain belongs to the claimed organisation.
SPF, DKIM and DMARC may pass for a domain controlled by an attacker.
Ask which domain authenticated, not merely whether authentication passed.
Compare sender-domain evidence with embedded URL domains.
Use shared sender domains and URLs to scope related messages.
Business context can materially change the risk of impersonation.
Build the verdict from technical evidence, not visual familiarity.

Module 5 — Email & Phishing: From Message to Compromise

Lesson 42 separated visual trust from sender identity. In Lesson 43 the investigation moves beyond the message itself, because this time the user clicked the link.

Next: Lesson 43 — The Link Was Clicked

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise

Follow phishing evidence from message delivery through clicks, credential exposure, mailbox activity and campaign scope.

← Previous lesson

Lesson 41 — The Email Looked Legitimate at First Start phishing triage with sender, authentication and delivery evidence.

✅ Current lesson

Lesson 42 — The Display Name Was Familiar — The Domain Wasn't Separate visual trust from sender identity.

Next lesson →

Lesson 43 — The Link Was Clicked Follow a message into URL-click and endpoint evidence.

Display name impersonation investigation in Microsoft Defender XDR

Lesson 42 of the Agent Foskett SOC Analyst Academy teaches SOC analysts how to investigate display-name impersonation by comparing the visible sender identity with SenderFromAddress, SenderFromDomain, SenderMailFromDomain, authentication results and URL evidence.

Investigating look-alike sender domains with KQL

Use EmailEvents and EmailUrlInfo in Microsoft Defender XDR Advanced Hunting to separate visual trust from technical sender identity and scope related phishing messages.