Agent Foskett Academy • Lesson 28 • Creating New Evidence Fields with extend

Creating New Evidence Fields with extend

Real investigations often need more than the original columns returned by a table.
Defenders may need to extract a sender domain, convert text to lowercase, calculate time differences, classify risky activity or create cleaner evidence fields for reporting.

This is where extend becomes useful. It allows analysts to create new columns from existing evidence, without changing the original data.

In this Agent Foskett Academy lesson, you will learn how defenders use the KQL extend operator to enrich Microsoft Defender XDR and Microsoft Sentinel investigations with clearer, more useful evidence fields.

Agent Foskett Academy lesson explaining how to use extend in KQL investigations
Lesson overview

Learn how extend helps defenders create new evidence fields that make investigations easier to read, filter and explain.

Understand extend
Create calculated fields
Enrich investigation evidence
🎯 extend helps you turn raw telemetry into useful evidence.
Use it when you need to create a new field, normalise values, classify activity or make investigation output easier to understand.
Review Lesson 27 →

Why extend matters

The extend operator creates a new calculated column in your query results.

This is useful when the evidence exists, but it is not displayed in the way an investigator needs it.

Defenders can use extend to create sender domains, clean usernames, calculate time gaps, classify risky events and prepare cleaner evidence before using project, summarize, join or order by.
Create cleaner fieldsBuild new fields from existing telemetry so the evidence is easier to read and explain.
Normalise investigation dataConvert values to lowercase, strings, numbers or dates so filtering and grouping works more reliably.
Prepare evidence for analysisCreate fields that can be reused later in summarize, join, where, project and timeline investigations.

Investigation scenario

Agent Foskett is investigating suspicious email and sign-in activity.

The raw telemetry contains useful values, but some of them are buried inside longer fields. Email addresses contain domains, sign-in records contain location details and timestamps need to be converted into investigation-friendly fields.

The investigation needs a way to create clean evidence fields before filtering, grouping and reporting the results.

Step 1 — Create a new sender domain field

Start with a common email investigation example: create a new field that extracts the domain from the sender address.
extend-sender-domain.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
EmailEvents
| where Timestamp > ago(30d)
| extend SenderDomain = tostring(split(SenderFromAddress, "@")[1])
| project Timestamp, SenderFromAddress, SenderDomain, RecipientEmailAddress, Subject
| sort by Timestamp desc

Step 2 — Normalise values with tolower()

Use extend to create a lowercase version of a field so matching and grouping becomes cleaner.
extend-normalise-values.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
DeviceProcessEvents
| where Timestamp > ago(7d)
| extend LowerCommandLine = tolower(ProcessCommandLine)
| where LowerCommandLine has_any ("powershell", "encodedcommand", "downloadstring")
| project Timestamp, DeviceName, FileName, LowerCommandLine, InitiatingProcessFileName
| sort by Timestamp desc

Step 3 — Create a risk label with case()

extend can also create simple labels that make investigation output easier to review.
extend-risk-label.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
SigninLogs
| where TimeGenerated > ago(14d)
| extend RiskLabel = case(
    RiskLevelDuringSignIn == "high", "High risk sign-in",
    RiskLevelDuringSignIn == "medium", "Medium risk sign-in",
    "Review if unusual"
)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, RiskLevelDuringSignIn, RiskLabel

What extend does

The extend operator adds a calculated column to each row returned by the query.

It does not permanently change the original Microsoft Defender XDR or Sentinel data. It only creates a new field inside the query result.
Original evidenceThe existing field, such as a user, sender, subject, command line, IP address or timestamp.
New calculated fieldThe new column created from an expression, conversion, split, case statement or calculation.
Cleaner investigation outputThe result becomes easier to filter, summarise, sort, join and explain to another analyst or client.

extend vs project

extend adds a new field while keeping the other columns available for the next part of the query.

project chooses which fields appear in the final output.

A common pattern is to use extend first to create useful evidence fields, then use project later to display the clean result.
Use extend whenYou want to create, convert, calculate or label a new field during the investigation.
Use project whenYou want to choose the final columns and remove clutter from the output.
Investigation benefitYou can build evidence step by step, then present only the fields that matter.

Step 4 — Summarise using an extended field

Once a useful field has been created, use it in summarize to find repeated patterns.
summarise-using-extend.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
EmailEvents
| where Timestamp > ago(30d)
| extend SenderDomain = tostring(split(SenderFromAddress, "@")[1])
| summarize EmailCount = count(), Recipients = dcount(RecipientEmailAddress) by SenderDomain
| sort by EmailCount desc

Common investigation uses

Email investigationsCreate sender domains, normalised subjects, suspicious keyword labels and phishing evidence fields.
Identity investigationsCreate location fields, risk labels, user domains, app categories and sign-in review fields.
Endpoint huntingCreate lower-case command lines, file extension fields, parent process labels and suspicious execution markers.

Common mistakes

Extending too lateCreate useful fields before summarize, join or filtering when those fields are needed later in the query.
Forgetting type conversionUse tostring(), todatetime(), toint() or tolower() when the value needs to be converted before filtering or grouping.
Overwriting useful fieldsAvoid reusing an existing column name unless you intentionally want to replace that value in the query result.

What you learned

extend creates new fieldsYou learned how to create calculated columns from existing Microsoft security telemetry.
Cleaner evidence helps investigationsYou learned how new fields can make filtering, grouping and reporting easier.
extend works with other operatorsYou learned how extend supports project, summarize, where, sort and real-world investigation workflows.
Next lesson: Combining Evidence Fields for Better Hunting
Now that you can create new evidence fields with extend, the next step is learning how to combine those fields into richer investigation logic.
Back to Academy →

Related Agent Foskett Academy lessons

Choosing Useful Columns Review how project helps defenders choose the final fields that matter.
Extracting Evidence with extract() Review how defenders pull specific indicators out of longer strings and fields.

Continue learning with Advanced Multi-Value Investigations with mv-apply, KQL Threat Hunting Guide and Microsoft Security.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD

Creating New Evidence Fields with extend

Agent Foskett Academy Lesson 28 teaches defenders how to use the KQL extend operator to create calculated evidence fields from Microsoft Defender XDR and Microsoft Sentinel telemetry.

Learn KQL extend for Microsoft Defender XDR and Sentinel

This lesson explains how extend supports security investigations by creating sender domains, normalised values, risk labels and cleaner evidence fields for filtering, summarising and reporting.