Lesson 12 — Investigating DeviceEvents

Learning objectives

After completing this lesson, you should be able to investigate broader endpoint activity using Defender for Endpoint telemetry.

• Explain what DeviceEvents records.
• Interpret ActionType and AdditionalFields.
• Investigate Defender Antivirus and security-control activity.
• Analyse USB, SmartScreen, exploit protection and device-control events.
• Correlate DeviceEvents with the dedicated endpoint telemetry tables.

The problem this solves

Not every useful endpoint event belongs in DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents or DeviceLogonEvents.

DeviceEvents captures many of the additional actions that complete the investigation story.

Why DeviceEvents matters

DeviceEvents often contains the supporting evidence that explains a detection or control action.

It may reveal whether Defender blocked malware, a USB device was connected or a security setting changed.

Timestamp

The timestamp shows when the action occurred.

Correlate it with alerts, process execution and related endpoint activity.

DeviceName

DeviceName identifies the endpoint where the event occurred.

Review the device risk, importance and related incidents.

ActionType

ActionType identifies the specific event recorded in DeviceEvents.

Because the table contains many event categories, this is usually the first field an analyst should examine.

ReportId

ReportId helps distinguish and correlate individual records.

Use it with DeviceName and Timestamp when working with related events.

AdditionalFields

AdditionalFields contains event-specific data, commonly represented as JSON.

Its contents vary depending on the ActionType.

Parsing AdditionalFields

AdditionalFields commonly contains JSON data that should be parsed before analysis.

Use parse_json() in KQL, then extract the properties relevant to the ActionType.

Why schema varies

DeviceEvents stores many different event families.

The properties available in AdditionalFields can differ significantly between USB, antivirus, SmartScreen and security-control events.

Defender Antivirus activity

DeviceEvents can contain antivirus detections and remediation actions.

Review whether malware was detected, blocked, quarantined or removed.

Detection versus remediation

A malware detection confirms that Defender identified a threat.

Remediation events show whether the threat was successfully blocked, quarantined or removed.

Quarantine actions

Quarantine isolates suspicious files from normal use.

Confirm the file, device, user and whether execution occurred before quarantine.

Malware removal

Removal events may indicate successful remediation.

Continue investigating for persistence, credential theft or related activity that may have occurred earlier.

SmartScreen activity

SmartScreen evaluates websites, downloads and application reputation.

Blocked or warned activity can reveal risky downloads or user interaction with suspicious content.

Blocked downloads

A blocked download may prevent the payload from reaching disk.

Check browser, email and network activity to understand how the user reached the destination.

Exploit protection

Exploit protection events can show when memory or application protections were triggered.

Correlate the event with the affected process and alert context.

Attack Surface Reduction

ASR-related activity may appear when a rule audits, warns or blocks behaviour.

Review the rule, initiating process, user and whether the behaviour was expected.

Device control

Device control events can show whether removable devices or peripherals were allowed, audited or blocked.

This is useful for investigating policy enforcement and data-transfer risk.

USB activity

USB events may identify device insertion, removal or access.

AdditionalFields may contain serial numbers, vendor details, product identifiers or device classes.

USB serial numbers

A serial number can help identify the same removable device across multiple endpoints.

Search for repeated use and correlate with users and file activity.

Printer and peripheral controls

Device control may also apply to printers and other peripheral classes.

Review the policy action and whether the activity aligns with business requirements.

Firewall activity

Some firewall and network protection events may appear in DeviceEvents.

Correlate them with DeviceNetworkEvents to understand the process and destination involved.

Network protection

Network protection can block access to malicious or low-reputation destinations.

Review the destination, process, user and whether related downloads occurred.

Security setting changes

DeviceEvents can record changes to Defender or endpoint-security configuration.

Unexpected changes may indicate administration, deployment or tampering.

Tamper Protection context

Tamper Protection helps prevent unauthorised changes to Defender settings.

Review blocked or attempted configuration changes with the initiating process and account.

Sensor and health activity

Sensor or health-related events can explain gaps in endpoint telemetry.

Check whether the device was reporting normally during the investigation window.

Miscellaneous endpoint actions

DeviceEvents can include actions that do not fit dedicated telemetry tables.

Always interpret them using the ActionType description and available AdditionalFields.

InitiatingProcessFileName

Many DeviceEvents records include the process associated with the action.

This can reveal whether a browser, script engine, management tool or unknown binary triggered the event.

InitiatingProcessCommandLine

The command line may expose arguments, URLs, file paths and scripts.

Use it to understand the purpose of the initiating process.

Initiating process account

Account fields identify the user or security context associated with the event.

Determine whether the account was expected to perform the action.

Process context still matters

Even when ActionType looks clear, the initiating process can change the interpretation.

A security tool and an unknown script modifying the same setting do not mean the same thing.

Pivot to DeviceProcessEvents

Investigate the process associated with the DeviceEvents record.

Review its command line, parent process, user, hash and child processes.

Pivot to DeviceNetworkEvents

Check whether the process communicated externally or laterally.

This can connect a control event with a malicious destination or payload source.

Pivot to DeviceFileEvents

Review files created, modified or accessed around the event.

This is especially useful for USB, antivirus and download investigations.

Pivot to DeviceRegistryEvents

Check whether security settings or persistence mechanisms changed in the registry.

This can connect a DeviceEvents record with deeper configuration activity.

Pivot to DeviceLogonEvents

Review which user or service account was active when the event occurred.

This helps establish responsibility and session context.

Pivot to the Device Timeline

The timeline places DeviceEvents alongside process, network, file, registry and logon activity.

Use it to reconstruct the complete sequence.

Common mistake

A common mistake is reading ActionType but ignoring AdditionalFields.

The extra JSON properties often contain the most useful event-specific evidence.

Another common mistake

Do not investigate DeviceEvents without process and timeline context.

The same action can be normal administration, security enforcement or attacker behaviour.

Best practices

• Read ActionType first.
• Parse AdditionalFields.
• Review the initiating process and user.
• Correlate with dedicated endpoint tables.
• Use the Device Timeline for chronology.
• Search for the same ActionType across devices.

Agent Foskett takeaway

DeviceEvents is the glue that connects many endpoint investigations.

It helps analysts investigate Defender actions, USB activity, SmartScreen, exploit protection, device control and security changes that complete the endpoint story.