As part of Cybersecurity Awareness month, we asked Deepwatch engineers for helpful tips and tricks to help practitioners be more aware of their environment. In this blog, they shine a light on Microsoft’s logging mechanism.
Microsoft, as a part of their larger security play, have started to consolidate efforts around their products, and strengthen what they offer. As such, their logging mechanism acts more like a funnel for their capability set. A rudimentary illustration looks something like this:
The logs/detections funnel up the “stack” and data is enriched/stripped, correlated/aggregated, adding context as it moves up the “stack”. This allows for automated correlation in the backend, and faster response times by the analyst.
Example Search of Defender Logs
index=<defender log location> sourcetype="ms*"
| stats values(source) as source, values(serviceSource) AS serviceSource,
values(detectionSource) AS detectionSource, by index, sourcetype
Microsoft 365 Defender
Microsoft 365 appears to be the aggregator of all aggregators within the Microsoft ecosystem. It appears to aggregate and correlate incidents from each of the serviceSources at the top of the food chain. This allows analysts to easily correlate events from Product A, to events that occur in Product B and Product C.
As an example, if Microsoft Defender for Endpoint detected a malicious payload on Host A under the context of User A, and later saw the device User A uses for Multi-Factor Authentication (MFA) being updated, this would be correlated within Microsoft 365 Defender. Microsoft 365 Defender allows Microsoft to correlate among multiple products and stitch together disparate log sources to garner a more complete picture. Analysts benefit from correlation, enrichment, and aggregation of each of the serviceSources. [Ref 1]
NOTE: Our testing initially was limited, so the extent of the enrichment and correlation is not currently known.
serviceSource
serviceSources are used to aggregate detectionSources under a single product and enrich where applicable. Specifically in Microsoft Defender for Endpoint, additional host information is enriched within the context of the serviceSource “Microsoft Defender For Endpoint”, as well as a few additional data points.
To borrow from the above example, multiple detectionSources could have identified the malicious payload with different detections. While different detection mechanisms, they all live within the Endpoint product line. These appear to be tied together by the field “incidentId”.
The “incidentId” appears to be applied across all log sources, and is presumed that this is applied within the backend of Microsoft, after detections make it to Microsoft 365.
Microsoft eases the analyst burden by having all of the detectionSources roll-up to a serviceSource that has defined logic on the backend to aggregate and correlate appropriately.
One thing to note that was interesting, is within the context of the serviceSource, all “null” values from the detectionSource were stripped and did not exist within the serviceSource logs.
Examples of serviceSources that we have observed:
- Microsoft365Defender (the aggregator of all serviceSources)
- MicrosoftCloudAppSecurity
- MicrosoftDefenderForIdentity
- MicrosoftDefenderForOffice365
- AADIdentityProtection
- MicrosoftDefenderForEndpoint
NOTE: These are the serviceSources we observed, a complete list can be found in [Ref 2].
detectionSource
detectionSources are the mechanism in which the threat was identified. Microsoft Defender for Endpoint as an example has approximately seven different detectionSources. This allows Microsoft to group their detections within a specific product (e.g. AV, ATP, etc.). It also allows Microsoft the ability to granularly detect threats, without affecting the other products capabilities.
Continuing the previous example, three different detectionSources identified the Host threat:
- SmartScreen from a pure Heuristic and Reputation based approach
- ATP from a behavioral perspective
- CustomerTI from shared Threat Intel from other security products.
While they all have their place, each of these mechanisms operate a bit differently from the other.
Each detectionSource and subsequent unique detection is identified by the field “alertId”.
The detectionSources that we observed are as follows:
- CustomDetection – A detection created within the platform by the customer
- CustomerTI – Third Party Integrations that share Threat Intelligence, and other data
- MTP – Microsoft Threat Protection – An aggregate of different products
- Windows DefenderATP – The Endpoint, Detection and Response (EDR) component of Microsoft Defender for Endpoint
- Windows DefenderAV – The NextGenAV component of Microsoft Defender for Endpoint
- Windows Defender SmartScreen – Heuristic and reputation based checks before executing unknown files/apps
- AutomatedInvestigation – Performs remediation actions based on the level granted to the device group
There are additional logs that are available through “Advanced Threat Hunting”. These logs in particular are more technical in nature and contain more detailed information related to the detection. This can assist during the course of an investigation.
Conclusion:
It appears that the main objective of Microsoft 365 Defender is to build on previous information and correlate as much as possible. The “higher” in the stack the incident/detection is, the more events will be correlated and less technical information is available. The “lower” end of the stack is more granular and technical information, but less correlation occurs. In a SIEM, these can be tied together with “alertId” and “incidentId” depending on where you want to view the information.
Reference 1: Overview of Microsoft 365
Reference 2: Breakdown of serviceSource and detectionSource
Reference 3: Microsoft Defender for Endpoint Information
Reference 4: Alert Resource type
↑
Share