You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: defender-xdr/advanced-hunting-best-practices.md
+13-2Lines changed: 13 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -199,7 +199,18 @@ The [summarize operator](/azure/data-explorer/kusto/query/summarizeoperator) agg
199
199
200
200
Process IDs (PIDs) are recycled in Windows and reused for new processes. On their own, they can't serve as unique identifiers for specific processes.
201
201
202
-
Usually, the only way to uniquely identify a process on a specific device was by combining its process ID with its process creation time, along with the device identifier (either `DeviceId` or `DeviceName`). While this approach is still valid, there’s a more direct method using the `ProcessUniqueId` field. Both methods yield unique process instances, but as a best practice we recommend using `ProcessUniqueId` when available, as it simplifies queries and eliminates the need to handle PID reuse scenarios.
202
+
Typically, the only way to uniquely identify a process on a specific device was by combining its process ID with its process creation time, along with the device identifier (either `DeviceId` or `DeviceName`). For instance, the following example query finds processes that access more than 10 IP addresses over port 445 (SMB), possibly scanning for file shares.
203
+
204
+
```kusto
205
+
DeviceNetworkEvents
206
+
| where RemotePort == 445 and Timestamp > ago(12h) and InitiatingProcessId !in (0, 4)
207
+
| summarize RemoteIPCount=dcount(RemoteIP) by DeviceName, InitiatingProcessId, InitiatingProcessCreationTime, InitiatingProcessFileName
208
+
| where RemoteIPCount > 10
209
+
```
210
+
211
+
The above query summarizes by both `InitiatingProcessId` and `InitiatingProcessCreationTime` so that it looks at a single process, without mixing multiple processes with the same process ID.
212
+
213
+
This approach is still valid, especially for non-Windows systems. However, in Windows, there’s a more direct method using the `ProcessUniqueId` field. While both the previous method and the one discussed below yield unique process instances, as a best practice we recommend using `ProcessUniqueId` when available, as it simplifies queries and eliminates the need to handle PID reuse scenarios.
203
214
204
215
This query demonstrates how to use the `ProcessUniqueId` and `InitiatingProcessUniqueId` fields to link a specific parent process to its child processes. By matching each child’s `InitiatingProcessUniqueId` to the parent’s `ProcessUniqueId`, it isolates only those child processes launched by that exact parent instance, even if process IDs get reused over time.
205
216
@@ -230,7 +241,7 @@ DeviceProcessEvents
230
241
Timestamp
231
242
```
232
243
233
-
The query summarizes by both `InitiatingProcessId` and `InitiatingProcessCreationTime` so that it looks at a single process, without mixing multiple processes with the same process ID.
244
+
Likewise, the query summarizes by both `InitiatingProcessId` and `InitiatingProcessCreationTime` so that it looks at a single process, without mixing multiple processes with the same process ID.
234
245
235
246
:::image type="content" source="/defender/media/best-practice-unique-processid.png" alt-text="Screenshot of sample query results for getting unique processes in the Microsoft Defender portal." lightbox="/defender/media/best-practice-unique-processid-tb.png":::
0 commit comments