ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 5 • Choosing Useful Columns

Choosing Useful Columns

Filtering helps you find the right rows.

But once you have the right rows, you still need to make the results readable.

Microsoft security tables can contain many columns. Some are useful for the investigation. Others may not matter at that moment. The project operator helps defenders choose only the fields they need to see.

In this lesson, you will learn how to use project to remove clutter, focus on important evidence and make Microsoft Defender XDR and Sentinel investigations easier to understand.

The goal is simple:

Show the evidence that matters.

Start Lesson 5 Back to Academy
Agent Foskett Academy lesson explaining how to choose useful KQL columns
Lesson overview

Learn how to use project to remove clutter and display the fields that matter during Microsoft security investigations.

Plain-English project introduction
Choosing useful output columns
Making investigation results readable
🧠 project helps investigators focus on the evidence.
Filtering finds the right rows. Project chooses the useful columns so defenders can read the story clearly.
View KQL Hunting Guide →

Why useful columns matter

Microsoft security tables often contain a lot of fields. When every column is shown, the investigation can become difficult to read. Choosing useful columns helps defenders focus on the evidence that answers the question.
Remove clutter Project hides fields that are not needed, making the results easier to scan and understand.
Focus the investigation Useful columns help answer who, what, when, where and how during an investigation.
Make results readable Readable output helps defenders explain findings to technical and non-technical people.

The project operator

The project operator tells KQL which columns to display. Instead of showing everything, you choose the columns that matter for the investigation.
project-basic-example.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
EmailEvents
| take 20
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject
Plain-English translation:

Show me 20 email events, but only display the timestamp, sender, recipient and subject.

Choosing columns for email investigations

When investigating email, defenders usually want to see who sent the message, who received it, what the subject was, when it arrived and what happened to it.
email-useful-columns.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
EmailEvents
| where Timestamp > ago(24h)
| project Timestamp, SenderFromAddress, SenderFromDomain, RecipientEmailAddress, Subject, DeliveryAction
| take 50
SenderFromAddressShows who the message claims to be from.
RecipientEmailAddressShows which mailbox received the message.
DeliveryActionShows whether the message was delivered, blocked, junked or otherwise handled.

Choosing columns for sign-in investigations

When investigating identity activity, useful columns usually help answer who signed in, from where, to which application and whether the sign-in succeeded.
signin-useful-columns.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ResultType
UserPrincipalNameShows which user account was involved in the sign-in activity.
IPAddress and LocationHelp identify where the sign-in appeared to come from.
AppDisplayNameShows which application the sign-in was attempting to access.

Choosing columns for endpoint investigations

Endpoint investigations often focus on device name, process name, command line, user and timestamp. These fields help explain what ran and where it ran.
endpoint-useful-columns.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
DeviceProcessEvents
| where Timestamp > ago(24h)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
FileNameShows the process or executable involved in the event.
ProcessCommandLineShows how the process was launched, which can reveal suspicious commands or scripts.
InitiatingProcessFileNameShows the parent process that started the activity.

Combining filters and project

A common investigation pattern is to filter the rows first, then project the useful columns. This keeps the query focused and the results readable.
filter-then-project.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
EmailEvents
| where Timestamp > ago(24h)
| where Subject contains "invoice"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction
Plain-English translation:

Find recent email with invoice in the subject, then only show the fields that help me understand the email.

Project does not change the original data

The project operator changes what your query displays. It does not delete or change the original Microsoft security data.
It changes the viewProject controls the output of your query so the results are easier to work with.
It does not delete columnsThe original telemetry still contains all available fields. You are only choosing what to display.
It supports investigation clarityGood column selection can make findings clearer when explaining an incident.

Beginner mistakes with project

Choosing columns is simple, but there are a few common mistakes that can make investigations harder to follow.
Removing too muchIf you hide important fields too early, you may lose context while reading results.
Forgetting timestampsMost investigations need a time column so you can understand the order of activity.
Not thinking about the questionChoose columns that help answer the investigation question, not just columns that look interesting.

Investigator mindset

Project is not just about making a table smaller. It is about deciding which evidence helps explain the activity.
What fields prove what happened?Choose columns that show the event, user, device, time, sender, recipient or action.
What fields help me pivot?Keep fields that may help the next query, such as user names, IP addresses, message IDs, URLs or device names.
What fields help me explain it?Readable results make it easier to communicate findings to clients, managers or other defenders.
The logs already know the story.
Project helps defenders display the parts of that story that matter most.
Continue Learning

What you learned

In this lesson, you learned how to use project to make KQL investigation results easier to read and understand.
project chooses columnsThe project operator controls which fields appear in your query results.
Useful columns answer questionsGood column choices help explain who, what, when, where and how.
Readable output supports better investigationsCleaner results help defenders pivot, explain findings and avoid drowning in unnecessary fields.

Next lesson coming soon

The next Agent Foskett Academy lesson will build on project and show how to sort KQL results using order by, so defenders can understand timelines and see the newest or oldest activity first.
Lesson 6 — Sorting and Understanding Results Learn how order by helps defenders read timelines, find recent activity and understand investigation flow.
Keep building the investigation After choosing useful columns, the next step is sorting the results so the sequence of activity makes sense.

Continue learning with Agent Foskett Academy, Microsoft Defender KQL Threat Hunting Guide, EmailEvents KQL Guide, KQL Email Spoofing, Microsoft Security and the GEMXIT Security Review.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Choosing Useful Columns

Agent Foskett Academy Lesson 5 teaches defenders how to choose useful columns in KQL using project inside Microsoft Defender XDR and Microsoft Sentinel investigations.

Learn KQL project for Microsoft Defender XDR

KQL project helps defenders remove clutter, focus on useful fields and make investigation results easier to read across Microsoft security telemetry.

KQL for Security Investigations

Choosing useful columns helps defenders investigate EmailEvents, UrlClickEvents, DeviceProcessEvents, DeviceNetworkEvents, SigninLogs, AuditLogs, suspicious sign-ins, DMARC failures, phishing emails, endpoint behaviour and Microsoft security telemetry.