At Microsoft, we are committed to putting customers’ security first through a comprehensive security stack delivering protection from chip to the cloud. For example, we continuously innovate endpoint protection, whether through the Microsoft Defender Advanced Threat Protection suite of industry-leading, innovative technologies or through industry-wide platform-security-based initiatives like the recently announced range of Secured-core PCs. Secured-core PCs combine identity, virtualization, operating system, hardware, and firmware protection technologies to enable highly secure and trustworthy devices. Central to the success of these technologies is the necessity for tamper-evident computing, meaning that violations of security guarantees must be observed and reported. System Guard runtime attestation — which runs in a secure hardware-backed enclave when virtualization-based security (VBS) is enabled, a default setting in Secured-core PCs — exposes a cryptographically generated statement of proof that a device has booted with the expected security properties and continues to maintain a healthy state at runtime. It works in concert with Microsoft Defender ATP to ensure that any activities attempting to tamper with strong security technologies are identified and made visible to security operations center (SOC) teams. In this post, we’ll introduce the System Guard session report as exposed via Microsoft Defender ATP’s advanced hunting capabilities and demonstrate how an enterprise can leverage these reports to: Improve the security posture of the organization vis-à-vis firmware-level threats Ensure that any deviation from expected posture is readily identified and can be investigated. Introduction to the device boot attestation schema The System Guard boot-time attestation (session) report contains a set of boot-time claims that reflect the security feature enablement posture at boot. As these claims are not expected to change for the duration of the boot session, devices onboarded to Microsoft Defender ATP expose the attestation data to the Microsoft Defender ATP cloud at periodic intervals, starting within a few moments post-boot. (Note that, because an active Internet connection is required to perform effective attestation, Microsoft Defender ATP attempts to attest periodically to ensure that as and when connectivity becomes available, attestation takes place.) These reports are exposed as a JSON array in the AdditionalFields of the MiscEvents table and can be exposed using the following advanced hunting query: MiscEvents | where ActionType == “DeviceBootAttestationInfo” This will return each row in the MiscEvents table that matches the ActionType of DeviceBootAttestationInfo with the boot attestation data itself in the AdditionalFields column. We can then extract that data using the parse_json() function. MiscEvents | where ActionType == "DeviceBootAttestationInfo" | extend AdditionalFieldData = parse_json(AdditionalFields) The following is a sample session report. A full description of each of the fields that appear in this report follows at the end of this post. { "TpmMachineId": "cecede4a6c4d2f727ec410cc7fcfeb78af3c4eef6c1900796496f672dec80466", "SystemGuardSecurityLevel": 250, "TpmVersion": 2.0, "ReportValidityStartTime": "2019-10-23T17:58:52Z", "ReportExpirationTime": "2019-10-27T18:03:52Z", "ValidationResult": "Success", "IsBootDebuggingOff": true, "IsKernelDebuggingOff": true, "IsTestSigningOff": true, "IsFlightSigningOff": true, "IsDriverCodeIntegrityEnforced": true, "IsElamDriverLoaded": true, "IsSecureBootOn": true, "IsIommuOn": true, "IsVsmOn": true, "IsHvciOn": false, "Pcr0Hash": "6d59d8eafb7ea21b1ca2b38556fd1a1d1c04f396ec8c9b47c0c8c8f0e7933f95", "WindowsBootManagerHash": "3f3145060fdd412d6f194ac70b303a5e606e28ad9d0d0dd22d6f4c2bf1d0b800", "WindowsOSLoaderHash": "691b9983d974be58ba149a07977dd64c86c50e8bc90f090a2d163dc2dfcd22ea", "ElamDriverHash": "832bc1d12f0e771e114bb135509c76005c0904a45ac204f56f510f2715d347a0", "ElamDriverPath": "\\WINDOWS\\system32\\drivers\\wd\\WdBoot.sys", "ElamDriverSigner": "Microsoft Windows Early Launch Anti-malware Publisher" } Understanding the System Guard security level The SystemGuardSecurityLevel is defined by us at Microsoft and is indicative of the systems security posture as derived from an aggregated set of claims — higher values depict a strengthened platform security posture. This allows for quick analysis around posture without needing to sift through individual property values (although this option is available too). A score of 0 effectively means that little trust can be placed in the Trusted Computing Base (TCB) of the device. Low scores can be due to a number of reasons, such as not having a working TPM for attestation or the base security properties being affected in some other fashion. On the opposite side of the scale, a score of 700 shows that the machine booted with all the necessary security features available on our platforms today. A Secured-core PC can expect to achieve a security level of 700. (Combining such a device with Microsoft Defender ATP makes for an optimal configuration!) The following advanced hunting query can be used as a basis for determining which machines are candidates for improvement: // Establish a baseline SystemGuardSecurityLevel and show the machines that are below that baseline let TargetSecurityLevel = 700; MiscEvents | where EventTime >= ago(30d) | where ActionType == "DeviceBootAttestationInfo" | extend AdditionalFieldData = parse_json(AdditionalFields) | project ComputerName, ReportTime = todatetime(AdditionalFieldData.ReportValidityStartTime), CurrentSecurityLevel = toint(AdditionalFieldData.SystemGuardSecurityLevel), AdditionalFieldData.ReportValidityStartTime | where CurrentSecurityLevel < TargetSecurityLevel | summarize arg_max(ReportTime, CurrentSecurityLevel) by ComputerName This query results in an output like this: In the above example, the query lists all machines that have a security level below the intended baseline of 700, which we encourage customers to strive for enterprise-wide. Since the DeviceBootAttestationInfo data is generated on each boot, we then take the latest of all returned reports in the table and only display that value. Building custom alerts As suggested, core to the success of attestation is the ability to speedily identify deviations. Microsoft Defender ATP customers can write queries that identify such deviations that may be of interest in their environments based on the properties exposed in the attestation reports. Our next example is a custom query that identifies machines exhibiting a drop in SystemGuardSecurityLevel across boot sessions: // Goal: Find machines in the last N days where the SystemGuardSecurityLevel value NOW is less than it was BEFORE // Step 1: Get a list of all security levels in the system where the level is not null let SecurityLevels = MiscEvents | where ActionType == "DeviceBootAttestationInfo" | extend AdditionalFieldData = parse_json(AdditionalFields) | project MachineId, EventTime, SystemGuardSecurityLevel = toint(AdditionalFieldData.SystemGuardSecurityLevel), ReportId | where isnotnull(SystemGuardSecurityLevel); // Step 2: Get the *latest* record for *each* machine from the SecurityLevels table let LatestLevelsPerMachine = SecurityLevels | summarize arg_max(EventTime, SystemGuardSecurityLevel) by MachineId | project MachineId, LatestSystemGuardSecurityLevel=SystemGuardSecurityLevel, LatestEventTime=EventTime; // Step 3: Join the two tables together where the LatestSystemGuardSecurityLevel is LESS than the SystemGuardSecurityLevel let MachinesExhibitingSecurityLevelDrop = LatestLevelsPerMachine | join ( SecurityLevels ) on MachineId | project-away MachineId1 | where LatestSystemGuardSecurityLevel < SystemGuardSecurityLevel | summarize arg_max(EventTime, LatestSystemGuardSecurityLevel, SystemGuardSecurityLevel, LatestEventTime, ReportId) by MachineId; MachinesExhibitingSecurityLevelDrop This query can be converted into a custom detection rule that can raise an alert at a severity level appropriate for the organization: All further instances will be raised to the SOC via the Microsoft Defender ATP interface: Enabling Zero Trust Zero Trust Networking scenarios can be enabled via Azure Active Directory Conditional Access policies. For example, enterprises can create a Conditional Access policy to deny a user access to resources or SaaS service from a machine that is not compliant with a risk policy. Thus, using the alert defined earlier, a machine that exhibits a drop in SystemGuardSecurityLevel would trigger a Microsoft Defender ATP alert. In turn, this elevates the machine’s risk profile, and, because the device is no longer compliant with the Microsoft Intune compliance policy, Azure AD Conditional Access would block users on the machine from accessing other network resources. Advanced use cases The examples above mostly focus on the use of the SystemGuardSecurityLevel property. The attestation report, however, includes claims that may be useful in advanced scenarios. For example, a sophisticated attack could modify the UEFI Secure Boot signing keys on the device to enable a bootkit to run without Secure Boot verification failing. The UefiSigners field lists the signers used to verify the current EFI boot applications (as extended into the TPM’s PCR[7]). Deviations from the normal could indicate tampering of these signing keys that might warrant further investigation by the SOC. Conclusion We hope that this blog post serves as a window into the level of insight that Microsoft Defender ATP provides into the security technologies enabled by Secured-core PCs and System Guard, and what’s possible for enterprises in terms of establishing trust in the application of these capabilities While the current attestation info schema exposed by Microsoft Defender ATP is full-featured and useful, we’ll look into opportunities for making further attestation claims available that may be of use to customers down the line. The System Guard runtime attestation session report is available in advanced hunting to all Microsoft Defender ATP customers running Windows 10, version 1809 or Windows Server 2019. All examples above are available in our Github repository. David Kaplan (@depletionmode) and Matt Egen (@FlyingBlueMonki) Microsoft Defender ATP team Appendix Attestation report data in AdditionalInfo column Refer to the following table for a full list of the data from the System Guard boot-time attestation (session) report that you can leverage using advanced hunting. This data is returned as a JSON array in the AdditionalInfo column of the miscellaneous events (MiscEvents) table for events with DeviceBootAttestationInfo as the ActionType value. Attribute Data type Description TpmMachineId string Unique machine ID derived from the Attestation Identity Key (AIK). This ID changes if the AIK changes, such as when keys are cleared from TPM. SystemGuardSecurityLevel int A value from 0 to 700 that reflects the overall device security level based on the state of boot properties as attested by System Guard: · 0: TPM, AIK, UEFI secure boot, ELAM, or other critical features are missing or turned off. This value also applies if the device is set to boot in safe mode or WinPE, or has debugging or test modes turned on · 100: No Virtualization-based security · 200: HVCI and IOMMU off · 250: HVCI off · 300: IOMMU off · 400: DTRM off · 500: DTRM on · 700: Critical features present and turned on. SMM attestation monitoring turned on (or disabled on ARM) TpmVersion string Version of Trusted Platform Module (TPM) on the device ReportValidityStartTime datetime Date and time that marks when the boot attestation report is considered valid. The attestation report should not be considered valid before this time. ReportExpirationTime datetime Expiration of the boot attestation report. This is automatically set to four days from validity start date. However, a new attestation report should automatically replace existing reports on device reboot. ValidationResult int Result of validation of the cryptographically signed boot attestation report. 0 means the report is valid, while any other value indicates validity errors. IsBootDebuggingOff boolean Indicates whether boot debugging is on or off. This should be off on secure devices. IsKernelDebuggingOff boolean Indicates whether kernel debugging is on or off. This should be off on secure devices. IsTestSigningOff boolean Indicates whether test signing at boot is on or off. This should be off on secure devices. IsFlightSigningOff boolean Indicates whether flight signing at boot is on or off. This should be off on secure devices IsDriverCodeIntegrityEnforced boolean Indicates whether the device booted with driver code integrity enforcement IsElamDriverLoaded boolean Indicates whether the device booted with the Early Launch Antimalware (ELAM) driver loaded IsSecureBootOn boolean Indicates whether the device booted with Secure Boot on IsIommuOn boolean Indicates whether the device booted with IOMMU on IsVsmOn boolean Indicates whether the device booted in virtual secure mode, i.e. with virtualization-based security (VBS) on. IsHvciOn boolean Indicates whether the device booted with hypervisor-protected code integrity (HVCI) Pcr0Hash string Cryptographic hash used by TPM for the PCR0 register, covering measurements for the Authenticated Code Module (ACM) and BIOS/UEFI modules WindowsBootManagerHash string Cryptographic hash of the Windows Boot Manager WindowsOSLoaderHash string Cryptographic hash of the Windows OS Loader ElamDriverHash string Cryptographic hash of the Windows Defender Early Launch Antimalware (ELAM) driver ElamDriverPath string Path to the Windows Defender Early Launch Antimalware (ELAM) driver binary file ElamDriverSigner string Signer of the Windows Defender Early Launch Antimalware (ELAM) driver binary file UefiSigners string List of signing keys used to verify the EFI boot applications, showing the GUID of the signature owner and the signature digest
