One of the ‘Microsoft Defender for Cloud Apps’ core functionalities is the ‘Cloud Discovery’ feature which helps organizations to identify Shadow IT usage in their environment.
Imagine the scenario where business-critical data leaks out from the organization to an unmanaged cloud application. Or suddenly, there is a growing number of users using an application that is considered a ‘high risk’ based on application reputation.
In both scenarios, Microsoft Defender for Cloud Apps (MDA) can save your day to detect both activities and further admin can block access or set controls to the application. To identify the traffic, MDA needs network data that can be ingested from Defender for Endpoint (MDE), firewall, or proxy servers.
The most common approach I’ve seen, and easiest to deploy, is to ingest network-related data from devices through MDE integration. In some, but more rare scenarios, I’ve seen data integrations from firewalls & proxies. The latter is useful if the ecosystem contains a variety of operating systems because MDE integration brings data only from W10 or later OS at the time of writing.
During the last year, I wrote about how to manage discovered applications, and what are the possibilities with Defender for Cloud Apps (MDA). In this blog, the focus is mainly on native apps aka desktop applications. Kudos to my colleague Sakari Pajulampi whose help in this was exceptional.
Setting up the Scene
A prerequisite for blocking the applications is integration between Defender for Cloud Apps (MDA) & Defender for Endpoint (MDE), more of that here. Also, it’s worth mentioning that blocking with MDA-MDE works only with Windows 10 or later operating systems based on the MS docs.
One thing to consider is MDA ‘Scoped Profiles’. If you leverage this new feature you can block applications based on MDE device groups, including servers. Blocking works with Windows Server OS versions that fulfill prerequisites.
Defender for Endpoint can block what Microsoft deems (or you define) as malicious IPs/URLs, through Windows Defender SmartScreen for Microsoft browsers, and through Network Protection for non-Microsoft browsers or calls made outside of a browser.
If you would like to have more information on how Web Threat Protection, Web Content Filtering & Custom Indicators are working together I encourage you to read my blog about it.
Use Case
The use case came from a client where they have a need to block certain application usage on Windows devices (10/11) when traffic is identified by MDE & MDA. All devices are AAD Joined / Hybrid Device Joined, Intune enrolled, and Defender for Endpoint configured. The goal was to test MDA & MDE capabilities and not to enforce restrictions from Microsoft Endpoint Manager (Intune).
Caveats
This chapter contains caveats that are good to know before getting started with blocking discovered applications. The items are collected from various Microsoft Docs sources (MDA & MDE documentation) and based on my own experience.
At the end of March 2022, Microsoft announced in preview MDA ‘Scoped Profiles’ which leverages MDE device groups when blocking the applications. It gives more granularity to the app blocking configurations.
Defender for Endpoint can block what Microsoft deems as malicious IPs/URLs, through Windows Defender SmartScreen for Microsoft browsers, and through Network Protection for non-Microsoft browsers or calls made outside of a browser.
By creating indicators for IPs and URLs or domains, you can now allow or block IPs, URLs, or domains based on your own threat intelligence. You can also warn users (aka Soft Block) with a prompt if they open a risky app. The prompt won’t stop them from using the app but you can provide a custom message and links to a company page that describes appropriate usage of the app. Users can still bypass the warning and continue to use the app if they need
- The enforcement ability is based on Defender for Endpoint’s custom URL indicators.
- By default, apps and domains marked as ‘Unsanctioned‘ in Defender for Cloud Apps, will be blocked for all endpoint devices in the organization.
- Any organizational scoping that was set manually on indicators that were created by Defender for Cloud Apps before the release of this feature will be overridden by Defender for Cloud Apps.
- The required scoping should be set from the Defender for Cloud Apps experience using the scoped profiles experience.
- It takes up to two hours after you tag an app as ‘Unsanctioned‘ for app domains to propagate to endpoint devices.
- In most of the cases, domain information has been synced pretty fast (in minutes) but I’ve seen cases where this has taken as long as 12 hours because of an error in the backend.
- Currently, full URLs are not supported for unsanctioned apps.
- Therefore, when unsanctioned apps are configured with full URLs, they are not propagated to Defender for Endpoint and will not be blocked.
- For example,
google.com/driveis not supported, whiledrive.google.comis supported.
- In-browser notifications vary between different browsers.
Configuration & Results
As you can see from the picture below, some of the applications are marked as unsanctioned. If all prerequisites are met these applications will be blocked from the endpoints. I’m also leveraging the new feature (scoped profiles) there so I can force blocking based on the MDE device groups.
The results are simulating user experience and are based on the configuration above. The outcome is defined in the table as follows.
App Name: Tested application name
The browser or process-based traffic: During tests, both 1p & 3p browsers were tested. Also, URIs were initiated from PowerShell (Invoke-WebRequest) to simulate traffic with other tools to the blocked URIs
Native app traffic detected: This indicates was MDA able to detect traffic from the native app in the same manner as from the browser
Native app block: The column indicates what’s the end-user experience when the admin blocks the app from MDA
Notes: Additional information
| App Name | Browser (1p/3p) or process-based traffic | Native App traffic detected in MDA | Native App Block | Notes |
| Dropbox | detected & blocked | Yes | blocked | Usage of the app is not blocked but sync is blocked. When you add new files to the Dropbox folder those are not synced and you will receive an error |
| Telegram | detected & blocked | Yes | partially | Even though access is blocked through the browser to all telegram URIs, a user is able to download the app from the MS store. After installation app works as expected. Blocking works when service IP ranges (or hashes) are added to MDE as custom indicators. Adding hashes doesn’t work basically because when the app is updated hash will be updated also. |
| Discord | detected & blocked | partially | blocked | The native app is blocked without any additional configuration |
| WeTransfer | detected & blocked | Yes | blocked | No app is available, the service is web-based. Add-in for chrome is available but chrome doesn’t allow installing the add-in |
| Bittorrent | detected & blocked | partially | partially | The app breaks totally when policy hits on the device. One URI needs to be added manually to the MDE config (btweb.trontv.com). Note: MDA app catalog contains 27 different Torrent applications |
Summary
Managing the discovered ‘Shadow IT’ applications can be a painful task. On average organization, end-users are using more than 1000 applications (based on Microsoft reports) that are not managed by their own IT department.
Defender for Cloud Apps together with Defender for Endpoint offers a great toolset for monitoring & blocking unwanted/risky applications from the environment but it’s not a silver bullet for the challenge.
Also, when considering blocking torrent applications there are many of them available. MDA app catalog contains 27 different torrent applications which were all blocked in this example case.
In this particular case, the goal was to test and demonstrate how blocking works by leveraging MDA – MDE integration and with Windows 10 or later devices.
If blocking of applications needs to be 100% bulletproof with browser and native applications and on all platforms then this combination would not fit your needs. Together with Microsoft Endpoint Manager ‘Attack Surface Rules aka ASR’ & Azure AD Conditional Access, you can achieve a lot more if the scenario above is not feasible in your scenario. Another consideration is that MDA is mainly designed for browser-based apps but native apps are supported better all the time (a totally different situation than a few years ago).
References
Defender for Cloud Apps – Cloud Discovery Deep Diver
Extending MCAS Cloud Discovery into the Managing of Shadow IT
Until next time!
Sam's Corner 