Conditional Access configuration for AzureAD accounts is important. With Conditional Access you can protect easy accounts, block outdated protocols and create more security cases to protect corporate data. An important part of Conditional Access is the usage of break-glass accounts. In this blog post the way to monitor break-glass/ emergency accounts with Microsoft Sentinel. 

What is a break-glass account?

Emergency access accounts or break glass accounts are an important part of the recovery plan inside the corporate organization. These accounts are privileged and should only be used when the normal admin accounts can’t sign in. For example; issues with the ADConnect sync or Conditional Access lock-out.

These accounts are important to help when you locking yourself out of access with Conditional Access policies, service outages, or federation services issues.

Break-glass accounts have now MFA protection. In this case it is more and more important to protect and monitor the accounts for each event.

In this blog the process to monitor break-glass accounts with Microsoft Sentinel based on the usage of an Analytic Rule.

The emergency access accounts should not be associated with any individual user in the organization. Make sure that your accounts are not connected with any employee-supplied mobile phones, hardware tokens that travel with individual employees, or other employee-specific credentials. This precaution covers instances where an individual employee is unreachable when the credential is needed. Another important part is the usage of the cloud-only accounts that use the *.onmicrosoft.com domain and not federated or synchronized from an on-premises environment.

NOTE: This blog is not explaining the best practices and steps for setting up the account with the best possible protection. For recommendations see: Manage emergency access admin accounts – Azure AD | Microsoft Docs

Microsoft Sentinel

Microsoft Sentinel is the cloud-native SIEM and SOAR solutions from Microsoft based on intelligent security analytics and threat intelligence. With the use of custom data connectors and built-in connectors it is easy to import data. For example; the Azure AD sign-in connector for importing AzureAD events into the Microsoft Sentinel workspace.

Prerequisites

The following prerequisites are needed for monitoring the Break Glass accounts.

  • Microsoft Sentinel
    • Log Analytics Workspace
  • Connect Azure Active Directory connector
    • P1/ P2 license required for export sign-in data to Microsoft Sentinel
  • Emergency account configured.
  • Break-glass account Object ID

Connect Azure Active Directory Sentinel connector

The built-in connector Azure Active Directory is the default built-in connector to collect data from Azure Active Directory. The following events are supported:

  • Sign-in Logs
  • Non-interactive user sign-in logs
  • Service principal sign-in logs
  • Managed Identity sign-in logs
  • Audit logs
  • Provisioning logs

Note: An Azure Active Directory P1 or P2 license is required to ingest sign-in logs into Microsoft Sentinel. Any Azure AD license (Free/O365/P1/P2) is sufficient to ingest the other log types.

For connecting the connector.

  1. In Microsoft Sentinel, select Data connectors from the navigation menu.
  2. From the data connectors gallery, select Azure Active Directory
  3. Mark both checkboxes Sign-in Logs / Audit logs and if needed any other log types. 
  4. Now the data source is connected. To view the latest state. Go to the Azure Active Directory data connectors page and view the data received and connected data types. Or run the following KQL query:

SigninLogs
| take 1000
| sort by TimeGenerated

Prepare the analytic rule

After the data is completed it is possible to create an analytics rule for sending alerts for any activity based on the break-glass accounts. For creating a new analytics rule.

  1. Open Microsoft Sentinel with minimal Contributor permissions
  2. From the Microsoft Sentinel panel open the Analytics blade under the Configuration section.
  3. Create a new scheduled query rule

Fill in the following details:

  • Name: fill in own naming, example: Break-Glass account usage
  • Description: Explanation of the rule
  • Tactics: Based on MITRE ATT&CK Framework: Initial Access, Credential Access, Privilege Escalation
  • Severity: High
  • Status: Enabled

Next;  The Rule logic configuration. First the KQL detection rule. The KQL uses the SigninLogs table with extending of the IP address and UserPrincipalName. Detection is based on the AzureAD object-id to minimalize the naming changes.

SigninLogs
| project UserId,UserPrincipalName, Location, SourceSystem, TimeGenerated, IPAddress
| where UserId == 'object-id'
| extend AccountCustomEntity = UserPrincipalName
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

Replace the value UserID/Object-ID with the Break-Glass object ID. For getting the Object-ID. Open Azure AD -> Users -> “Name of Break-Glass account” -> Copy the Object ID from the Identity details.

For the query scheduling run the query every 5 minutes with a lookup for the last 5 minutes of data. Or change the timings if needed for any specific environment.

Make sure the incident creations is activated for the analytics rule.

Simulate the alert creation

Now simulate the specific alert configuration. To trigger an alert, you need to sign in to the Azure portal to simulate the break-glass usage. For a testing purpose, sign in with the usage of a different IP (If you have whitelisted corporate networks).

With the result: incident created inside Microsoft Sentinel with the needed information and Analytics Rule naming.

And the Microsoft Sentinel investigation view:

 

Conclusion

Microsoft Sentinel is a simple and effective way to pay extra attention to the break-glass sign-ins. Of course, you need to protect the break-glass accounts with the highest protection way. For configuring Azure AD emergency/ break-glass accounts read the best practices from Microsoft.

Manage emergency access accounts in Azure AD