Monitor Emergency Accounts with Microsoft Sentinel

In Azure, like any other cloud vendor, the shared responsibility model means that both Microsoft and you have a role to play in ensuring high service availability.

Suppose we’re taking the identity platform (the Azure AD). In that case, It’s essential that you prevent being accidentally locked out of your Azure AD organization because you can’t sign in or activate another user’s account as an administrator. You can mitigate the impact of accidental lack of administrative access by creating emergency access accounts in your organization. Emergency access accounts are highly privileged and not assigned to specific individuals.

Emergency access accounts are limited to emergency or break glass account scenarios where standard administrative accounts can’t be used. It’s recommended that you maintain a goal of restricting emergency account use only when necessary.

TIP: an emergency access account is a highly privileged cloud-only Azure AD user account that we’ll use only in emergencies. 

More about Manage emergency access admin accounts – Azure AD

Current Activities

Before creating a Playbook and Analytic Rule, we can check current actions with a short query via Logs. From Microsoft Sentinel, open Logs and type the simple query. The following query will show the emergency accounts that made the recent action.

SigninLogs 
| where UserDisplayName == “Emergency Accounts”

You can add more parameters such as and UserPrincipalName == “sos@domain.com”

Or to add the following lines and check for a failed login.

SigninLogs
| extend failedlogons = tostring(ResultType)
| where failedlogons != 50055;

You can play with KQL queries and add many parameters and switches.

Create and Configure Playbook

The Microsoft Sentinel Playbook can be created before or after the Analytics rule. The analytic rule required the Playbook to automate the actions once an incident appears on Microsoft Sentinel Incidents.

If you don’t have a Playbook, you need to create one, and once you’ve been making a Logic App, you need to go to Logic App designer and create a flow for the following resources:

  • Microsoft Sentinel alert triggered.
  • Incident
  • Entities
  • Action

To create a playbook, go to the Microsoft Sentinel portal and choose Playbook and choose Add Playbook. Then you will create a Logic App, and you can make the flow from there.

Create and Configure Playbook

Once you’ve created a playbook with the flow, you can go to the Analytic rule and put everything together.

Create and Configure Analytic Rule

From Analytics tule, let’s create a simple query that checks the relevant emergency accounts’ actions. The query is based on the account values, such as the user display name, object id, or principal name. The value can be any available account value.

The user values exist on the Azure AD user properties.

Create and Configure Analytic Rule

Once you’ve got the account values, you can create a query to identify the user actions. I searched for both Identity and the UserId values in this example and then added the Project to show the relevant results.

// Check SOS Account Status 
SigninLogs 
| where UserDisplayName == “Emergency Accounts” and UserId == “127346a5-4df6-4d1b-940a-4c29d407801c” // Check Account by two values
| project TimeGenerated, UserDisplayName, IPAddress, Location = tostring(LocationDetails.city) , Description=tostring(ResultDescription), Browser = tostring(DeviceDetail.browser)
You can add the entities to the query to allow an investigation option once you’ve got an incident.
| extend AccountCustomEntity = UserDisplayName
| extend IPCustomEntity = IPAddress
We need to take the query and put it on the analytics rule to create an analytics rule. Create the query with the Scheduled query rule from the Azure Sentinel portal.
On the rule query option, add the following query.
// Check SOS Account Status 
SigninLogs 
| where Identity == “Emergency Accounts” and UserId == “127346a5-4df6-4d1b-940a-4c29d407801c” // Check Account by two values
| project TimeGenerated, UserDisplayName, IPAddress, Location = tostring(LocationDetails.city) , Description=tostring(ResultDescription), Browser = tostring(DeviceDetail.browser)
| extend AccountCustomEntity = UserDisplayName
| extend IPCustomEntity = IPAddress.
TIP: you can simulate to check the query and show if you’ve some results
Azure Sentinel

Once the Analytics rule has been defined, we can simulate the access for the SOS account.

Simulate SOS Access

To check the analytic rule and the Playbook, we need to access the SOS account from any browser, and once you connect with the SOS account, we can check the Microsoft Sentinel portal if we’ve got some incidents.

There are a few alerts for accessing the SOS account from the Incident, and from here, we can investigate the access and actions made, including detailed information.

From the investigation, we drill down to the event and related information.

Besides, you will receive an email in your mailbox about this Incident.

In conclusion, the SOS account is critical and must be monitored and notified if someone touches him. With the Microsoft Sentinel analytic rule and Playbook, you can monitor the SOS account and notify if someone tries to access it. The investigation can be done from the Logs with KQL or the Incident with the analysis.

More Microsoft Sentinel posts

Manage emergency access admin accounts – Azure AD | Microsoft Docs

Monitor Emergency Accounts in with Azure Sentinel

The post Monitor Emergency Accounts with Azure Sentinel will discuss the importance of emergency accounts (break-glass) and monitor Azure Sentinel’s use.
In Azure, like any other cloud vendor, the shared responsibility model means that both Microsoft and you have a role to play in ensuring high service availability.
Suppose we’re taking the identity platform (the Azure AD). In that case, It’s essential that you prevent being accidentally locked out of your Azure AD organization because you can’t sign in or activate another user’s account as an administrator.
You can mitigate the impact of accidental lack of administrative access by creating emergency access accounts in your organization. Emergency access accounts are highly privileged, and they are not assigned to specific individuals.
Emergency access accounts are limited to emergency or break glass account scenarios where standard administrative accounts can’t be used. It’s recommended that you maintain a goal of restricting emergency account use only when it is necessary.
TIP: an emergency access account is a highly privileged cloud-only Azure AD user account that we’ll use only in emergency actions. 
More about Manage emergency access admin accounts – Azure AD

Current Activities

Before creating a Playbook and Analytic Rule, we can check current actions with a short query via Logs. From Azure Sentinel, open Logs and type the simple query. The following query will show the emergency accounts that made the recent action.

SigninLogs 
| where UserDisplayName == “Emergency Accounts”

You can add more parameters such as and UserPrincipalName == “sos@domain.com”
Or to add the following lines and check for a failed login.

SigninLogs
| extend failedlogons = tostring(ResultType)
| where failedlogons != 50055;

You can play with KQL queries and add many parameters and switches.

Create and Configure Playbook

The Azure Sentinel Playbook can be created before or after the Analytics rule. The analytic rule required the Playbook to automate the actions once an incident appears on Azure Sentinel Incidents.
If you don’t have a Playbook, you need to create one, and once you’ve been making a Logic App, you need to go to Logic App designer and create a flow for the following resources:

  • Azure Sentinel alert triggered.
  • Incident
  • Entities
  • Action

To create a playbook, go to the Azure Sentinel portal and choose Playbook and choose Add Playbook. Then you will create a Logic App, and from there, you can make the flow.
Create and Configure Playbook




Once you’ve created a playbook with the flow, you can go to the Analytic rule and put everything together.

Create and Configure Analytic Rule

From Analytics tule, let’s create a simple query that checks the relevant emergency accounts’ actions. The query is based on the account values, such as the user display name, object id, or principal name. The value can be any available account value.
The user values exist on the Azure AD user properties.
Create and Configure Analytic Rule
Once you’ve got the account values, you can create a query to identify the user actions. I searched for both Identity and the UserId values in this example and then added the Project to show the relevant results.

// Check SOS Account Status 
SigninLogs 
| where UserDisplayName == “Emergency Accounts” and UserId == “127346a5-4df6-4d1b-940a-4c29d407801c” // Check Account by two values
| project TimeGenerated, UserDisplayName, IPAddress, Location = tostring(LocationDetails.city) , Description=tostring(ResultDescription), Browser = tostring(DeviceDetail.browser)
You can add the entities to the query to allow an investigation option once you’ve got an incident.
| extend AccountCustomEntity = UserDisplayName
| extend IPCustomEntity = IPAddress
We need to take the query and put it on the analytics rule to create an analytics rule. Create the query with the Scheduled query rule from the Azure Sentinel portal.
On the rule query option, add the following query.
// Check SOS Account Status 
SigninLogs 
| where Identity == “Emergency Accounts” and UserId == “127346a5-4df6-4d1b-940a-4c29d407801c” // Check Account by two values
| project TimeGenerated, UserDisplayName, IPAddress, Location = tostring(LocationDetails.city) , Description=tostring(ResultDescription), Browser = tostring(DeviceDetail.browser)
| extend AccountCustomEntity = UserDisplayName
| extend IPCustomEntity = IPAddress.
TIP: you can simulate to check the query and show if you’ve some results
Azure Sentinel



Once the Analytics rule has been defined, we can simulate the access for the SOS account.

Simulate SOS Access

To check the analytic rule and the Playbook, we need to access the SOS account from any browser, and once you connect with the SOS account, we can check the Azure Sentinel portal if we’ve got some incidents.
There are few alerts for accessing the SOS account from the Incident, and from here, we can investigate the access and actions made, including detailed information.


From the investigation, we drill down to the event and related information.


Besides, you will receive an email to your mailbox about this Incident.
In conclusion, the SOS account is critical and must be monitored and notified if someone touches him. With the Azure Sentinel analytic rule and Playbook, you can monitor the SOS account and notify if someone tries to access it. The investigation can be done from the Logs with KQL or from the Incident with the analysis.
More Azure Sentinel posts
Manage emergency access admin accounts – Azure AD | Microsoft Docs

You may also like...

Leave a Reply

error: Content is Protected !!
%d bloggers like this: