Endpoint Discovery - Navigating your way through unmanaged devices
Published Apr 13 2021 08:50 AM 47.6K Views
Microsoft

Today (June 22nd), we released into GA a new set of capabilities for Microsoft Defender for Endpoint that empower organizations to discover and secure network devices and unmanaged endpoints. This is especially critical in the new global hybrid working environment, which exposes the most challenging cybersecurity landscape we’ve ever encountered. This blog provides more information on the unmanaged endpoint discovery feature while an additional blog provides more information on how to configure the network device discovery feature.

 

The challenge – unmanaged endpoints

In recent years, the efficacy of Endpoint Protection (EPP) and Endpoint Detection and Response (EDR) platforms has continued to increase. With the rise of unified SIEM and XDR (extended detection and response) solutions, like Microsoft 365 Defender, the level of efficacy that our customers are benefiting from continues to improve. To fully utilize these solutions to defend your environment, it's critical to have full visibility of all the devices in your organization. You can't protect what you can't see!

 

David Weston, Microsoft Director of Enterprise and OS Security, advises:   

 

“The riskiest threat is the one you don’t know about. Unmanaged devices are literally one of your weakest links. Smart attackers go there first. With work-from-home, the threat has grown exponentially, making discovering and applying security controls to these devices mission critical.” 

 

There have been many examples where unmanaged devices were exploited and led to a breach, such as the Equifax breach. In this case the breach originated via an unpatched vulnerability on an internet-facing server. This might have been easily addressed except for the fact that the server was unmanaged--no one knew it needed patching. Those responsible for the security profiles and policies of these devices were basically unaware of its existence. 

 

Unmanaged endpoint discovery in Microsoft Defender for Endpoint

To address scenarios like this we’re adding unmanaged endpoint discovery to Microsoft Defender for Endpoint to help customers discover and secure unmanaged endpoints on their corporate network. This will help detect and report upon any device seen on a corporate network that can be onboarded and secured by Microsoft Defender for Endpoint.

 

As part of this new functionality, two forms of discovery are provided including Standard and Basic. For public preview all tenants will initially have Basic discovery configured which uses unicast or broadcast network events captured by the onboarded devices to discover unmanaged endpoints. Basic discovery uses the SenseNDR.exe binary for passive network data collection and no network traffic will be initiated. On May 10, unless otherwise configured by the tenant, we will automatically switch from Basic to our recommended form of discovery which is called Standard discovery. This is an active discovery method where managed devices actively probe the network to identify unmanaged devices. From here the interfaces on discovered devices are leveraged to collect threat, vulnerability and metadata used for device fingerprinting. Standard discovery builds a deeper more complete picture of the discovered devices than Basic mode and and allows for vulnerability assessments.  Once you have enabled this process the amount of network traffic is minimal, up to 5k of traffic is generated per discovered device and the frequency of this process is only once every 3 weeks after initial discovery or when certain characteristics of the managed device change.  For example if the name of the device that is doing the scanning changes then this is an indication that the environment the device exists in may have changed and so the standard discovery probing will be initiated.

 

When you go to Microsoft 365 security console you will see two new tiles available. The first shows “Devices to onboard” and will present all devices seen in the last 30 days. We also check whether the device has been seen more than just once over a 3-day period. This prevents a recommendation appearing to onboard a device that was plugged onto the network once, then won’t be seen again.

 

Picture1.jpg

 

The second tile is “Discovered devices in my network” and will be broken down into device types.

 

Picture2.jpg

 

Once discovered, the devices will appear in the Device Inventory. Clicking the button to “View recently discovered devices” will take you straight to where we have a new set of filters available where you can apply criteria relevant to these new devices, as shown in the screenshot below:

 

Picture3.jpg

 

This data is then used as part of the security recommendations within threat and vulnerability management. You can go to the Security recommendations  section under Vulnerability management and type “Onboard” into the Search box to see discovered devices eligible for onboarding:

Picture4.jpg

 

Once you know about these devices, you can start to onboard them into Defender for Endpoint. This empowers you to close the unmanaged endpoint gap in your environment which is an easy target for attackers. By using the remediation options presented as part of the Security Recommendations, you can open a ticket in Microsoft Endpoint Manager to remediate and onboard the device.

 

Advanced hunting has also been improved to allow you to query these devices and export data with whatever columns you like:

 

DeviceInfo 

| where Timestamp > ago(7d)

| summarize arg_max(Timestamp, *) by DeviceId

| where OnboardingStatus == 'Can be onboarded'

| distinct Timestamp, DeviceName, DeviceId, OSPlatform, OSDistribution, OSVersion, ReportId

 

“Timestamp” and “ReportId” lets you run this as a custom detection. For example, you could write a rule to generate an alert whenever a device is connected to a certain subnet.

 

We have also exposed “Onboarding Status” in the API and in the connector for Azure Sentinel, to provide visibility into security tooling you might have in place.

 

Enabling discovery

You will see that endpoint discovery is enabled on your tenant through a banner that appears in Device inventory . This banner will be available until the automatic switch from Basic to Standard discovery occurs on July 19th, giving you the option to easily spot and switch over to Standard discovery as soon as you are ready.

 

ED 02.jpg

 

If you don’t want Standard discovery to be automatically enabled on July 19, you also have the option to go to Device discovery  in settings and select Basic discovery to ensure the automatic change doesn’t occur.

 

ED 03.jpg

 

Controlling discovery

Although we recommend using Standard discovery, there may be conditions that justify applying controls to the discovery process. When Standard discovery actively probes the network, it uses two PowerShell scripts. These PowerShell scripts are Microsoft signed, and are executed from the following location: 

 

C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\*.ps

 

If you are using other security tooling in your environment, there is a possibility these scripts could cause alerts to be raised in those tools. To avoid this situation, we suggest adding the path the scripts are run from to the allow list within your tooling. We also provide customization capabilities around which devices will perform Standard discovery and thus run the scripts. When you enable Standard discovery, the default mode is that all managed Windows 10 devices perform this task. To change this you can leverage a tagging feature which enables you to restrict the execution of the Standard discovery process to only certain devices in your environment.

 

ED 04.jpg

 

One caveat: we only recognize tags that have been applied to the device through the portal (or via the API). You cannot utilize tags that have been set via the registry on the device.

 

You may also have situations where devices are set up as honeypots or have certain networks where you have specific monitoring in place. You can exclude these from Standard discovery and can configure this through the Exclusions tab in Device discovery. There, you can specify either a specific IP address or a subnet to exclude from the Standard discovery mode, although we will still gather details of devices through the passive discovery available in Basic discovery.

 

ED 05.jpg

 

Discovering the right devices

One important aspect to this functionality is ensuring it discovers the correct devices. You don't want to take your laptop home and then see all your smart devices, TVs, gaming consoles, etc., showing up in the device inventory list. Not only does it clutter the inventory, but there are also privacy implications from discovering personal, at home devices.

 

The good news: there is built-in logic to prevent this, and a level of control to define what networks this discovery process runs against. The logic was designed to differentiate between corporate networks and non-corporate networks, to avoid discovery of private or public devices not controlled by the organization. Strict conditions are in place to ensure such devices won’t be discovered and presented in the portal.

 

The system differentiates between corporate and non-corporate networks by correlating common network interfaces identifiers among Microsoft Defender for Endpoint onboarded devices.

 

To add an extra layer of control, the following screenshot displays the Monitored networks tab within Device discovery settings which makes discovered networks visible and enables you to specifically whether to include or exclude them.

 

ED 06.jpg 

 

Disabling…if you really must!

Finally, if you decide that our new endpoint discovery capability isn't for you, a switch is available in the Advanced settings page in the Microsoft Defender Security Center that allows you to disable the feature (under “Endpoints” in the settings in the Microsoft 365 security center) . While this isn’t recommended, we recognize some organizations may require due diligence to be performed before taking advantage of the feature.

 

 Picture10.jpg

 

We’re excited to offer you this new functionality and thank you for your interest in the unmanaged endpoint discovery feature. You will gain enhanced visibility of your estate, and the power to close down a vector of attack that attackers increasingly take advantage of.

 

We encourage you to join us in the public preview program. This program lets you test new features in their early phases and captures your feedback that will influence the final product. For those not already enrolled in the program, we encourage you to participate by turning on preview features.

 

Once enrolled, we welcome your feedback. More information about this feature and our broader range of unmanaged devices capabilities can be found in the Microsoft Defender for Endpoint product documentation.

 

 

19 Comments
Deleted
Not applicable

Hello everyone .

A very good article publication that confirms the great work of Microsoft teams that provide high-end products adapted to the changing situation in the world in the security layer!

Congratulations on your luck.     

Copper Contributor

good one.  Detailed explanation about new feature "discovery"

thanks. 

Copper Contributor

This is a very good introduction of the new features and these features are very much needed and helpful. Microsoft is really top class in security

Silver Contributor

This type of information needs to be included in the official Docs.microsoft.com site where it is a lot more discoverable. I have spent the last 30 minutes trying to find documentation about this new functionality.

Copper Contributor

Is this already available? I turned on the "Standard" discovery, but still do not see any additional machines appearing.

Feature was turned on almost a week ago, and tried several reboots. The network discovered was "private" so I switched it to a monitored network several times, but still no data.

Microsoft

@Dean Gross this is published in Docs, you can find it here: Device discovery overview | Microsoft Docs

Brass Contributor

Highly anticipated feature, and fantastic blog to explain it, @Steve Newby ! Thank you.

 

A quick question about exclusions: will the scan honor a /16 subnet exclusion? It's much easier to set a /16 exclusion than numerous /23 exclusions.

Microsoft

@Jose Camacaro Latouche  yes it will.  However I would just question why you are excluding such a big range?

Brass Contributor

@Steve Newby , thanks!

The first applicable scenario I am reviewing is Wireless networks for "unmanageable" BYOD.

Microsoft

Unmanaged endpoints were found in the device inventory, but in the settings, I'm missing the tab of "Monitored networks". Any reason for this?

Microsoft

@JBL615 It should be available for users with administrative privileges 

Copper Contributor

Please provide the actual names of the two PowerShell scripts. We do not want this folder to be fully unmonitored in case of PS scripts.

Microsoft

@Aleksanteri Numminen thanks for your feedback

Can you please share your feedback through the "Give Feedback" option in the portal? Consider also selecting "You can contact me about this feedback", so we can contact you directly for more details.

 

Thanks!

Ron

Copper Contributor

The Microsoft Defender Security Console is the worst enterprise ssecurity product that I've used yet, and the Device Discovery and Monitored Networks are basically enabling this product to act as a virus. It's ironic. 

I have no desire to collect a list of all of the machines when my users visit a coffee shop, especially when there is no option to delete junk data from the console. Further, I have to protect my users in that, higher risk environment (the coffee shop). So, showing me all of my users’ home devices, which I won’t ever control is generally pointless and clutters up my console from seeing data that I need to act on.

 

The Device Discovery Settings simply don't work. Mine is set to Basic and Selected tags, but machines without the selected tags are being discovered and even onboarded! This is happening even for machines that aren't in our Azure tenant, and I have no access to them. So, I can't offboard them and cant delete them from the console. This is another disctraction from the endpoints that I manage and need to protect and clean up.

 

Device Discovery returns incorrect information (e.g. shows Workgroup for domain joined Windows 10 machines). 

 

Why is the setting to disable/turn off Device Discovery not on Device Discovery settings page?? SMH. Tip for others: it's in Settings > Endpoints > Advanced Features > way down the page.

 

If Monitored Networks was an explicit, assigned list, then it would be helpful, but as is noted on the Monitored Networks settings page and its supported documentation, “If less than 50 networks are identified as corporate networks, then list will show up to 50 networks with the most onboarded device.” So, while there is some partial truth in that I can control networks after discovery, I do not have control before discovery. I cannot limit discovery exclusively to my corporate network and nothing more. And again, I have no ability to clean up devices from the console. So, when three of my users visit a coffee shop, that network is monitored until I identify that and go in to ignore it. And my console is cluttered with all of the discovered mobile and desktop machines that connect in that coffee shop from the time it was discovered until I see it and tell it to ignore it. And, with all of the other junk in my console, how long would it be until I noticed this? Network discovery should absolutely have an option to turn off, and only be an assigned/explicit list!

 

The entire Defender/ATP/Security console is far too early for usage. I suggest that anyone who finds this before deciding to implement Defender as your AV solution to look elsewhere until 2025 or so when maybe this product will be ready to use. PS. it will probably have a different name then since...Microsoft.

Microsoft

Hi @jayreg, thanks for reaching out and sharing your feedback. Device discovery is specifically designed to not discover devices that are on public networks (e.g.: local coffee shop), or even private ones like your home network. If you’re experience is different, we’d love to investigate this with you. I’ll send you a message via Tech Community requesting some info so we can take a look, log any bugs we find, etc.

 

Please note that while we discover and add ​unprotected devices to device inventory these devices are not onboarded which means they have become protected by MDE. Protected would mean MDE’s EPP and EDR capabilities have been activated on the device and there is no product functionality to make this happen automatically for a completely unmanaged device. If it appears that devices have been automatically onboarded the devices must have been managed by another Microsoft product. There are some automation cases for scenarios like that. For instance, if the device was already managed​ and protected by Microsoft Defender for Cloud it can be automatically onboarded to MDE. More info on the onboarding process and the cases where we have some automation can be found here  https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/onboarding.

 

Thank again for the feedback!

 

Chris Hallum

Senior Product Marketing Manager

Microsoft Corporation

Copper Contributor

Thanks for the reply, @Chris Hallum

 

"Device discovery is specifically designed to not discover devices that are on public networks (e.g.: local coffee shop), or even private ones like your home network."
That is definitely not my experience. It added my home network, presummably because I was doing Autopilot testing at home and onboarding those devices, but it still isn't a corporate network. The text I pasted above from the Monitored Networks page disagrees with your statement as well, and I believe is the reason why my home network was added. I don't see why the same wouldn't apply for coffee shops when a few of my users are all on that network. I stupidly deleted my home network instead of clicking Ignore, but I'm happy to help your team investigate it, assuming I can do so with Device Discovery turned off. I have zero intension of re-enabling it again! 

 

"If it appears that devices have been automatically onboarded the devices must have been managed by another Microsoft product."
Perhaps. 
The only automated enrollment that I saw in the link you provided was tDefender for Cloud, which sounds like it has to be deployed on a server. That is definitely not the case in our envirnoment. 
For all I know, those are machines owned by spouses of our staff, and which are managed by another tenant. I doubt that since they're "Workgroup" computers. However, my corporate, domain-joined devices were discovered as being in the "Workgroup" domain instead of our corporate domain. So, who knows if that's accurate on those machines. There's really so many problems with Device Discovery. Back to the enrolled mystery machines... I have no idea how they got there. They aren't in Azure. The Security console has no information about the signed-in user ("No user logged in") or how they were onboarded. One has an IP address suggesting it was on our corporate network (which shouldn't onboard them without being managed), but others have 192.168.x.x addresses. Worst of all is because I have no idea what/where/whose machine it is, then I have no access to it and can't offboard it because there's no option in the Security console to offboard machines (like the Retire feature in Intune). We need options to delete, retire, and I'm starting to think a block function is necessary for mystery machines. They aren't our corporate machines, aren't under my management, and are cluttering up my view for things that need my attention.

Copper Contributor

On the device discovery: there seems to a bug on wireless component of a device. on monthly base I run a report of the not onboarded devices, 
But after analyzing the wireless mac-address is redrawed.  seems a bug.

For example: 00-15-5D-BD-EE-FB -> is in the export of the advanced hunting: FB-EE-BD-5D-15-00

kind regards

quinzy

 

Microsoft

Hi @quinzy, Thank you for your feedback

We'll be happy to reach out for more details about the issue you are facing. Please visit the Device Inventory page and leave us a feedback through the "Give feedback" button. Make sure you mark "You can contact me about this feedback" and we'll reach out soon.

 

Copper Contributor

ok, seems to be solved now :) The export was from previous year by advanced hunting query. 

DeviceInfo
| where OnboardingStatus !="Onboarded"
| project DeviceName, DeviceId, OSPlatform, OSBuild, OnboardingStatus, DeviceCategory, DeviceType, Timestamp
| join kind=inner (DeviceNetworkInfo | distinct DeviceId, MacAddress) on DeviceId
| join kind=inner (DeviceNetworkEvents | distinct DeviceId, LocalIP) on DeviceId
| project-away DeviceId1, DeviceId2
| where LocalIP contains "x.x"
if I see it back, I will contact you
kind regards
Quinzy




Version history
Last update:
‎Jul 12 2021 01:24 AM
Updated by: