Unleash The Power Of DeviceTvmInfoGathering
The DeviceTvmInfoGathering table in Defender XDR is one of the understudied tables of Defender For Endpoint. With only the small amount of four listings from Alex Verboon on kqlsearch.com before researching this table. This blog explores the uncovered potential of this table, because this will help you a lot to get quick insights into the configuration Defender For Endpoint on your devices!
While the table serves little detection value, it is extremely useful to get insights into the Defender For Endpoint configuration of your devices. This allows you to easily check settings across all your devices.
The categories that are included are:
Table Contents
The table is very straightforward, with only 6 columns. The column AdditionalFields, however, can contain more than 80 columns. Each of these subfields reflects an MDE setting.
| Column name | Data type | Description |
|---|---|---|
Timestamp | datetime | Date and time when the record was generated |
LastSeenTime | datetime | Date and time when the service last saw the device |
DeviceId | string | Unique identifier for the device in the service |
DeviceName | string | Fully qualified domain name (FQDN) of the device |
OSPlatform | string | Platform of the operating system running on the device. This indicates specific operating systems, including variations within the same family, such as Windows 10 and Windows 7. |
AdditionalFields | dynamic | Additional information about the entity or event |
Source: Microsoft Docs
The MDE settings are reflected in True/False, numbers or other categories. These particular settings are saved in the DeviceTvmInfoGatheringKB table, which contains the metadata for Microsoft Defender Vulnerability Management assessment events data collected in the DeviceTvmInfoGathering table.
Defender Rollout
Do you remember the CrowdStrike outage from a few months ago? Well, Microsoft has a solution to gradually rollout updates to devices. Their updates are released in different release rings. Using the DeviceTvmInfoGathering table and KQL you can find how this is configured across your fleet for AvPlatform, AvSignature and AvEngine rings. The KQL function below creates a pie chart that shows the distribution of rings across all your devices.
let SignatureRingDistribution = (RingName:string) {
DeviceTvmInfoGathering
| extend AvSignatureRing = tostring(parse_json(AdditionalFields).AvSignatureRing),
AvPlatformRing = tostring(parse_json(AdditionalFields).AvPlatformRing),
AvEngineRing = tostring(parse_json(AdditionalFields).AvEngineRing)
| summarize TotalDevices = dcount(DeviceId) by column_ifexists(RingName, "AvSignatureRing")
| extend RingDescription = case(
column_ifexists(RingName, "AvSignatureRing") == "1", "Beta Channel - Prerelease",
column_ifexists(RingName, "AvSignatureRing") == "2", "Current Channel (Preview)",
column_ifexists(RingName, "AvSignatureRing") == "3", "Current Channel (Staged)",
column_ifexists(RingName, "AvSignatureRing") == "4", "Current Channel (Broad)",
column_ifexists(RingName, "AvSignatureRing") == "5", "Not Configured",
column_ifexists(RingName, "AvSignatureRing") == "6", "Critical: Time Delay",
"Unknown")
| project RingDescription, TotalDevices
| render piechart
};
//SignatureRingDistribution("AvPlatformRing")
SignatureRingDistribution("AvSignatureRing")
//SignatureRingDistribution("AvEngineRing")
ASR Configuration
Another usecase for the DeviceTvmInfoGathering table is to gain insights into how ASR is configured across all your devices. The query below gets the last event for each device and displays a column for each ASR rule.
DeviceTvmInfoGathering
| summarize arg_max(Timestamp, DeviceId, DeviceName, AdditionalFields) by DeviceId
| extend ASRConfig = AdditionalFields.AsrConfigurationStates
| evaluate bag_unpack(ASRConfig)
The results of this query can be found in the image below. This makes it easy to recognize devices that do not have ASR properly configured. Additionally, you can add filters or visualisations to tailor the results to your needs.
Antivirus Scans
The last use case for this blog is getting the status of the Antivirus Scans performed on your device. The KQL function AVScanResults() collects this information, the function uses two input variables DeviceIdInput and AvScanType. DeviceIdInput is the DeviceId from the device you want to list results, the AvScanType can be either Quick, Full or Custom. This allows you to quickly get insights into the state of the latest antivirus scan and when it was performed. For advanced usage you could use logic apps to trigger a new antivirus scan when the first attempt failed.
// AvScanType can be: Quick, Custom or Full
let AVScanResults = (DeviceIdInput:string, AvScanType:string) {
DeviceTvmInfoGathering
| where DeviceId == DeviceIdInput
| extend AvScanResults = extractjson("$", tostring(AdditionalFields.AvScanResults))
| mv-expand todynamic(AvScanResults)
| extend Results = AvScanResults[AvScanType]
| extend ScanStatus = extractjson("$.ScanStatus", tostring(Results)),
ErrorCode = extractjson("$.ErrorCode", tostring(Results)), Timestamp = extractjson("$.Timestamp", tostring(Results))
| where isnotempty(ScanStatus)
| project DeviceId, DeviceName, ScanStatus, Timestamp, ErrorCode, AvScanResults
};
AVScanResults("70da955b16e5717fc3xxxxxxxxxxxxx", "Full")
Different antivirus scan options with MDE:
| Scan type | Description |
|---|---|
| Quick scan (recommended) | A quick scan looks at all the locations where there could be malware registered to start with the system, such as registry keys and known Windows startup folders. Quick scans also run on mounted removable devices, such as USB drives. A quick scan helps provide strong protection against malware that starts with the system and kernel-level malware, together with always-on real-time protection, which reviews files when they’re opened and closed, and whenever a user navigates to a folder.In most cases, a quick scan is sufficient and is the recommended option for scheduled scans. Starting with the December 2023 (4.18.2311.x.x) release of Platform Update, you have the option to scan all files and directories that are excluded from real-time protection using contextual exclusions are scanned during a quick scan. |
| Full scan | A full scan starts by running a quick scan and then continues with a sequential file scan of all mounted fixed disks and removable/network drives (if the full scan is configured to do so).A full scan can take a few hours or days to complete, depending on the amount and type of data that needs to be scanned.When a full scan begins, it uses the security intelligence definitions installed at the time the scan starts. If new security intelligence updates are made available during the full scan, another full scan is required in order to scan for new threat detections contained in the latest update.Because of the time and resources involved in a full scan, in general, we don’t recommend scheduling full scans. |
| Custom scan | A custom scan runs on files and folders that you specify. For example, you can choose to scan a USB drive or a specific folder on your device’s local drive. |
Source: Microsoft Docs
Questions? Feel free to reach out to me on any of my socials.