Forum Discussion
Why there is no Signature status for the new process in the DeviceProcessEvent table?
According to the schema, there is only field for checking the initiating (parent) process digital signature, named InitiatingProcessSignatureStatus. So we have information if the process that initiated the execution is signed. However, in many security use-cases it is important to know if the spawned (child) process is digitally signed.
Let's assume that Winword.exe (signed) executed unsigned binary - this is definitely different situation than Winword.exe executing some signed binary (although both may be suspicious, or legitimate).
I feel that some valuable information is not provided, and I'd like to know the reason. Is it related to the logging performance? Or some memory structures, that are present only for the already existing process?
2 Replies
At the moment, this is simply how the schema is designed. In DeviceProcessEvents, Microsoft exposes signature metadata for the initiating process through InitiatingProcessSignerType and InitiatingProcessSignatureStatus, but there is no equivalent built-in field for the newly created process. The same table does, however, include the child process identifiers and hashes such as FileName, FolderPath, SHA1, and SHA256. (Microsoft Learn)
So your observation is valid: the table gives you direct signature status for the parent/initiator, but not for the spawned process itself. Microsoft’s public schema documentation does not currently provide an explicit reason for that design choice. Based on the schema structure, the most likely explanation is that certificate/signature validation for files is handled separately rather than being embedded into every process creation event, but that is an inference, not something Microsoft states outright. (Microsoft Learn)
The practical workaround is to enrich DeviceProcessEvents with DeviceFileCertificateInfo. That table is specifically meant for file signing certificate information and includes fields such as IsSigned, IsTrusted, Signer, Issuer, and SHA1. Microsoft also notes that this table is populated from certificate verification activities performed on files on endpoints. (Microsoft Learn)
So in your example, if winword.exe launches another binary, you can use the child process SHA1 from DeviceProcessEvents and join it with DeviceFileCertificateInfo to determine whether the spawned executable is signed and trusted. That gives you the distinction you are looking for, even though it is not exposed as a native column in DeviceProcessEvents. (Microsoft Learn)
If your goal is detection engineering, I would say this is less a limitation of telemetry availability and more a limitation of schema convenience. The data appears to exist in Defender XDR, but it is split across tables instead of being surfaced directly on the child process event. (Microsoft Learn)
If you want, I can also draft a short reply version for the forum plus a sample KQL join query.
Thank you.
when I tried to match the data, I stumbled upon a problem - the binaries for IntiatingProcess (parent) reported with Signature Status of "Unsigned", when matched by file path and SHA1 to the DeviceFileCertificateInfo seem to be properly signed... Maybe my KQL logic is wrong.
Please post your solution.DeviceProcessEvents | where InitiatingProcessSignatureStatus == "Unsigned" | summarize by ParentFile=tolower(InitiatingProcessFolderPath), InitiatingProcessSignatureStatus, InitiatingProcessSignerType, InitiatingProcessSHA1 | join DeviceFileCertificateInfo on $left.InitiatingProcessSHA1 == $right.SHA1 | project Filename=ParentFile, IsReportedSigned=InitiatingProcessSignatureStatus, SHA1, IsSigned, Signer
