Kusto Sentinel Tables

Introduction

For threat hunters, having a comprehensive understanding of these tables is crucial to identifying, investigating, and mitigating potential security threats. Each table in Microsoft Defender Advanced Hunting provides unique insights into various aspects of an organization’s environment—such as device activity, user behavior, network connections, and email threats. By correlating data across these tables, threat hunters can uncover patterns, detect anomalies, and trace the pathways of potential attacks. This approach enables proactive threat detection and enhances the ability to respond effectively to incidents, ensuring the security and integrity of the organization’s systems and data.

On pivoting

There are many tables in Defender and it is possible to pivoting between the tables. In threat hunting, “pivoting” refers to the process of using a specific piece of information or data point, such as a DeviceId, UserId, or FileHash, to navigate across different data sources or tables. The goal is to correlate events and uncover related details that might help in tracking down a threat.

For example, if you discover a suspicious process on a device, you can use the DeviceId to “pivot” to other tables, like DeviceNetworkEvents to check for unusual network activity or DeviceLogonEvents to see if unauthorized access occurred on that same device. It’s like following breadcrumbs across a connected web of data to piece together the story of how a threat might have unfolded.

Think of it as a detective chasing leads to unravel the bigger picture—it’s a cornerstone of effective threat hunting!

For instance, say you have a DeviceId. Armed with this id you can basically take any table in the graph below and move between the other tables depicted:

graph TD
    Start[Start: Searching for DeviceId] --> A[DeviceEvents]
    A --> B[DeviceProcessEvents]
    A --> C[DeviceFileEvents]
    A --> D[DeviceLogonEvents]
    A --> E[DeviceNetworkEvents]
    A --> F[DeviceRegistryEvents]
    A --> G[DeviceInfo]
    D --> G
    E --> G
    B --> F
    G --> H[AlertInfo]
    F --> H
    B --> H
    C --> H
    H --> I[AlertEvidence]
    P[CloudAppEvents] --> G

Similarly, you can do the same using, say, the UserID:

graph TD
    Start[Start: Searching for UserId] --> A[DeviceLogonEvents]
    Start --> B[IdentityLogonEvents]
    A --> C[IdentityInfo]
    B --> C
    C --> D[AlertInfo]
    D --> E[AlertEvidence]
    Start --> F[UrlClickEvents]
    F --> G[EmailEvents]
    G --> H[EmailAttachmentInfo]
    G --> I[EmailUrlInfo]
    C --> J[CloudAppEvents]
    J --> D

These are just two examples, think of all the possibilities that opens up when you start joining resultsets on other pivotpoints to connect data!