Title:
Defending against cryptojacking with Microsoft Defender for Endpoint and Intel
TDT
URL: https://www.microsoft.com/security/blog/2021/04/26/defending-against-cryptojacking-with-microsoft-defender-for-endpoint-and-intel-tdt/
Date Published
(MM/dd/YYYY): 04/26/2021
Overview:

With cryptocurrency mining on the rise, Microsoft and Intel have partnered
to deliver threat detection technology to enable EDR capabilities in Microsoft
Defender for Endpoint.

—————————————————————-

Title:
Non-interactive logins: minimizing the blind spot
URL: https://techcommunity.microsoft.com/t5/azure-sentinel/non-interactive-logins-minimizing-the-blind-spot/ba-p/2287932
Published On (MM/dd/yyyy): 04/25/2021
Overview:

Special thanks to   for
collaborating on this blog post with me! 

 

In this blog post, we will review the new Azure Sentinel data streams for
Azure Active Directory non-interactive, service principal, and managed identity
logins. We will also share the new security content we built and updated in the
product, which includes analytics rules for the detection part and workbooks to
assist our customers to deal with this blind spot.

 

The shift to the cloud and the rise of automation tasks and
service-to-service integration have contributed to a dramatic increase in the
use of managed applications, service principals, and managed identities.

These new security objects perform login activity which is not captured in
Azure Active Directory’s traditional sign-in logs.

The updated Azure Active Directory data connector now brings these important
sign-in events into Azure sentinel.

 What are
non-interactive logins?

Non-interactive user sign-ins are sign-ins that were performed by a client
app or an OS component on behalf of a user. Like interactive user sign-ins,
these sign-ins are done on behalf of a user. Unlike interactive user sign-ins,
these sign-ins do not require the user to supply an Authentication factor.
Instead, the device or client app uses a token or code to authenticate or
access a resource on behalf of a user. In general, the user will perceive these
sign-ins as happening in the background of the user’s activity. 

Some activity that is captured in these logs:

• A client app uses an OAuth 2.0 refresh token to get an
  access token.
• A client uses an OAuth 2.0 authorization code to get an
  access token and refresh token.
• A user performs single sign-on (SSO) to a web or
  Windows app on an Azure AD joined PC.
• A user signs in to a second Microsoft Office app while
  they have a session on a mobile device using FOCI (Family of Client IDs).

 

Why is it so
important to monitor and detect activities in this area?

 

Some examples that highlight why it’s so important to collect, and get
visibility into these logs as part of your detections and hunting:

 

1. SolarWinds
   campaign – As part of our learning on the SolarWinds
   campaign investigation, we used these logs in the hunting phase to check
   if the malicious actor used a sensitive app to gain “Data Access”.

 ————————————————————————-

Title:
Best practices for leveraging Microsoft 365 Defender API’s – Episode Two
URL: https://techcommunity.microsoft.com/t5/microsoft-365-defender/best-practices-for-leveraging-microsoft-365-defender-api-s/ba-p/2198820
Published On (YYYY-dd-MM):2021-26-04
Overview:

In the previous episode we provided recommendations about how to use the Microsoft 365 Defender API
and, specifically, how
to optimize the Advanced hunting query.

In this
episode we will demonstrate use cases detailing how to access the API data and use this information in other products. 

One of the most common uses of the API is for visualization in PowerBI. This provides the capability to analyze, visualize, and share
your data with others quickly and easily.

If you are not familiar with PowerBi, we suggest you visit the Microsoft PowerBi web site, and download PowerBI desktop. 

We already documented how to use PowerBI to create custom
reports using  
Microsoft Defender for Endpoint APIs connection to Power BI –
Windows security | Microsoft Docs. 

——————————————————————–

Title:
Best practices for leveraging Microsoft 365 Defender API’s – Episode Three
URL: https://techcommunity.microsoft.com/t5/microsoft-365-defender/best-practices-for-leveraging-microsoft-365-defender-api-s/ba-p/2290463
Published On (YYYY-dd-MM):2021-26-04
Overview:

In the previous episode, we
described how you
can easily use PowerBi to represent Microsoft 365
data in a visual format. In this episode, we will explore another way
you can interact with the Microsoft 365 Defender
API. We will describe how to automate
data analysis and hunting using Jupyter notebook.

 Automate your hunting queries 

While hunting and conducting investigations on a
specific threat or IOC, you may want to use multiple queries to obtain wider
optics on the possible threats or IOCs in your network. You
may also want to leverage queries that are used by
other hunters and use it as a pivot point to perform deep
analysis and find anomalous behaviors. You can find a
wide variety of examples in our Git repository where various queries related to
the same campaign or attack technique are shared.  

In scenarios such as this, it is sensible to
leverage the power of automation to run the queries rather than running
individual queries one-by-one.  

This is where Jupyter Notebook is
particularly useful. It takes in a JSON file with hunting queries as input and
executes all the queries in sequence. The results are saved in a
.csv file that you can analyze and share. 

 ————————————————————————

Title:
March Ahead with Azure Purview: Access management in Azure Purview – Part 3
URL: https://techcommunity.microsoft.com/t5/azure-purview/march-ahead-with-azure-purview-access-management-in-azure/ba-p/2262722
Date Published
(MM/dd/YYYY): 04/22/2021
Overview:

Hopefully, you have read my previous blog posts about Azure Purview access
management Part 1 and Part 2 to find about Azure Purview control plane and data
plane roles and tasks. In this post, I will cover the following topic:

 

• Overview of dashboards and roles required to extend
  your M365 Sensitivity Labels to Azure Purview.

 

By extending M365 Sensitivity Labels to Azure Purview you can
automatically assign labels to files and database columns in Azure Purview.

——————————————————————

We have a new Azure Purview bog for your consideration. Please remember that
Azure Purview is a unified data governance service, and security is one of its
pillars.

Title:
Azure Purview resource set pattern rules available in Public Preview
URL: https://techcommunity.microsoft.com/t5/azure-purview/azure-purview-resource-set-pattern-rules-available-in-public/ba-p/2275399
Date Published (MM/dd/YYYY):
04/21/2021
Overview:

​At-scale data
processing systems typically store a single table in a data lake as multiple
files. This concept is represented in Azure Purview by using resource sets. A
resource set is a single object in the data catalog that represents a large
number of assets in storage. To learn more, see the resource set documentation.

 

When scanning a storage account, Azure Purview uses a
set of defined patterns to determine if a group of assets is a resource set. In
some cases, Azure Purview’s resource set grouping may not accurately reflect
your data estate. Resource set pattern rules allow you to customize or override
how Azure Purview detects which assets are grouped as resource sets and how
they are displayed within the catalog.

 

Pattern rules are currently supported in public preview
in the following source types:

• Azure Data Lake Storage Gen2
• Azure Blob Storage
• Azure Files

To learn more on how to create resource set pattern
rules, see our step-by-step
how-to documentation!

———————————————————————–

Title:
eDiscovery in Microsoft 365 One Stop Shop Resource Page
URL: https://techcommunity.microsoft.com/t5/security-compliance-identity/ediscovery-in-microsoft-365-one-stop-shop-resource-page/ba-p/2262529
Date Published
(MM/dd/YYYY): 04/21/2021
Overview:

Welcome to the eDiscovery in Microsoft 365 One Stop Shop Resource
Page!

 

We built this page to help you easily find all relevant content and
resources relating to the compliance solutions in Microsoft 365. Please
bookmark this page for future reference as we will update it on an ongoing
basis.

 

 Original
release date: April 26, 2021

A software supply chain attack—such as the recent SolarWinds Orion
attack—occurs when a cyber threat actor infiltrates a software vendor’s network
and employs malicious code to compromise the software before the vendor sends
it to their customers. The compromised software can then further compromise
customer data or systems.

To help software vendors and customers defend against these attacks, CISA
and the National Institute for Standards and Technology (NIST) have released Defending
Against Software Supply Chain Attacks. This new interagency
resource provides an overview of software supply chain risks and
recommendations. The publication also provides guidance on using NIST’s Cyber
Supply Chain Risk Management (C-SCRM) framework and the Secure Software
Development Framework (SSDF) to identify, assess, and mitigate risks.

CISA encourages users and administrators to review Defending
Against Software Supply Chain Attacks and implement its recommendations.

 

 Forescout Research Labs, partnering with JSOF Research, disclose NAME:WRECK, a set of nine vulnerabilities affecting four popular TCP/IP stacks (FreeBSD, Nucleus NET, IPnet and NetX). These vulnerabilities relate to Domain Name System (DNS) implementations, causing either Denial of Service (DoS) or Remote Code Execution (RCE), allowing attackers to take target devices offline or to take control over them.

The widespread use of these stacks and often external exposure of vulnerable DNS clients lead to a dramatically increased attack surface. This research is further indication that the community should fix DNS problems that we believe are more widespread than what we currently know.

This research uncovered vulnerabilities on very popular stacks:

1. Nucleus NET is part of the Nucleus RTOS. The Nucleus RTOS website mentions that more than 3 billion devices use this real-time operating system, such as ultrasound machines, storage systems, critical systems for avionics and others. The most common device types running Nucleus RTOS include building automation, operational technology and VoIP.

2. FreeBSD is widely known to be used for high-performance servers in millions of IT networks and is also the basis for other well-known open-source projects, such as firewalls and several commercial network appliances. The most common device types on Device Cloud running FreeBSD include computers, printers and networking equipment.

3. NetX is usually run by the ThreadX RTOS. Typical applications include medical devices, systems-on-a-chip and several printer models. ThreadX was known to have 6.2 billion deployments in 2017, with mobile phones (probably in baseband processors), consumer electronics and business automation being the most common product categories. The most common device types running ThreadX include printers, smart clocks and energy and power equipment in Industrial Control Systems.

Organizations in the Healthcare and Government sectors are in the top three most affected for all three stacks. If we conservatively assume that 1% of the more than 10 billion deployments discussed above are vulnerable, we can estimate that at least 100 million devices are impacted by NAME:WRECK.

The details of these vulnerabilities are described in our technical report and will be presented at Black Hat Asia 2021.

Helping the community to fix DNS vulnerabilities

Disclosing these vulnerabilities to vendors provides much-needed information and education on the impacted products and continues the dialogue in the research community:

1. We urge developers of TCP/IP stacks that have yet to be analyzed to take the anti-patterns available in our technical report, check their code for the presence of bugs and fix them. To help with this process, we are releasing open-source code developed for the Joern static analysis tool. This code formalizes the anti-patterns we identified, allowing researchers and developers to automatically analyze other stacks for similar vulnerabilities.

2. We invite researchers, developers and vendors to reach out to us if they are interested in a set of small proof-of-concept crashing network packets for the identified anti-patterns. These packets can be used to automatically test intrusion detection rules.

3. We realized that many vulnerabilities exist because RFC documents are either unclear, ambiguous or too complex. To help prevent such issues from reappearing in the future, we have submitted to the IETF an informational RFC draft where we list the anti-patterns we identified and how to avoid them while implementing a DNS client or server.

Recommended Mitigation

Complete protection against NAME:WRECK requires patching devices running the vulnerable versions of the IP stacks. FreeBSD, Nucleus NET and NetX have been recently patched, and device vendors using this software should provide their own updates to customers.

However, patching devices is not always possible, and the required effort changes drastically depending upon whether the device is a standard IT server or an IoT device.

Given the challenges of patching, we also recommend the following mitigation strategy:

1. Discover and inventory devices running the vulnerable stacks. Forescout Research Labs has released an open-source script that uses active fingerprinting to detect devices running the affected stacks. The script is updated constantly with new signatures to follow the latest development of our research. Forescout customers using eyeSight can also automatically identify devices using FreeBSD, Nucleus RTOS, ThreadX or VxWorks.

2. Enforce segmentation controls and proper network hygiene to mitigate the risk from vulnerable devices. Restrict external communication paths, and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched.

3. Monitor progressive patches released by affected device vendors and devise a remediation plan for your vulnerable asset inventory, balancing business risk and business continuity requirements.

4. Configure devices to rely on internal DNS servers as much as possible and closely monitor external DNS traffic since exploitation requires a malicious DNS server to reply with malicious packets.

5. Monitor all network traffic for malicious packets that try to exploit known vulnerabilities or possible 0-days affecting DNS, mDNS and DHCP clients. Anomalous and malformed traffic should be blocked, or its presence should be at least alerted to network operators. To exploit NAME:WRECK vulnerabilities, an attacker should adopt a similar procedure for any TCP/IP stack. This means that the same detection technique used to identify exploitation of NAME:WRECK will also work to detect exploitation on other TCP/IP stacks and products that we could not yet analyze. In addition, Forescout eyeInspect customers that enabled the threat detection SD script delivered as part of AMNESIA:33 can detect exploitation of NAME:WRECK.

For more information, visit our NAME:WRECK resources page

 

Microsoft has released security updates: Exchange Server 2013,  Exchange Server 2016,  Exchange Server 2019

Vulnerabilities addressed in the April 2021 security updates were responsibly reported to Microsoft by a security partner. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.

These vulnerabilities affect Microsoft Exchange Server. Exchange Online customers are already protected and do not need to take any action.

For additional information, please see the Microsoft Security Response Center (MSRC) blog. More details about specific CVEs can be found in Security Update Guide (filter on Exchange Server under Product Family).

Forr details go here

Released: April 2021 Exchange Server Security Updates – Microsoft Tech Community

Title:
Secure unmanaged devices with Microsoft Defender for Endpoint now
URL: https://www.microsoft.com/security/blog/2021/04/13/secure-unmanaged-devices-with-microsoft-defender-for-endpoint-now/
Date Published
(MM/dd/YYYY): 04/13/2021
Overview:

New Microsoft Defender for Endpoint capabilities let organizations discover
and secure unmanaged workstations, mobile devices, servers, and network
devices.

Title: Network device
discovery and vulnerability assessments
URL: https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/network-device-discovery-and-vulnerability-assessments/ba-p/2267548
Published On (YYYY-dd-MM):2021-13-04

.

Title: Endpoint
Discovery – Navigating your way through unmanaged devices
URL: https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/endpoint-discovery-navigating-your-way-through-unmanaged-devices/ba-p/2248909
Published On (YYYY-dd-MM):2021-13-04
Overview:

Earlier today, we announced 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.

 

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.

 

 

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

 

 

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:

 

 

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:

 

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, Device
Name, 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 May 10th, giving you the option to easily spot and switch over to
Standard discovery as soon as you are ready.

 

 

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

 

 

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:ProgramDataMicrosoftWindows
Defender Advanced Threat ProtectionDownloads*.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.

 

 

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.

 

 

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.

 

 

 

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.

 

 

 

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.