Non-interactive logins: minimizing the blind spot

This article is contributed. See the original author and article here.

Special thanks to @edilahav 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:

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”.

I’m sharing a Tweet from one of our senior security researchers from the days of the investigation:

2. CISA alert – Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments

Relevant part from the doc:

“Audit the creation and use of service principal and application credentials. Sparrow will detect modifications to these credentials. Look for unusual application usage, such as dormant or forgotten applications being used again. Audit the assignment of credentials to applications that allow non-interactive sign-in by the application. Look for unexpected trust relationships that have been added to Azure AD. (Download the last 30 days of non-interactive sign-ins from the Azure portal or use Azure Sentinel.)”

What is the benefit of collecting these new log streams into Azure Sentinel?

Azure Sentinel is a cloud-native SIEM that offers rich security content around these new log streams to bring security value to customers that enable it.

Some of the content we offer:

Analytics Rules

@shainw from the MSTIC team updated 24 analytics rules that perform correlations of non-interactive logins with traditional logins and search for anomalies and suspicious activities.