Section 4 – Mitigate identity threats part 1 of 2

Last part was a blast, let’s see how long this one will be as it’s about Identity!

Just like you can see from the picture above, Identity is every where and it could be the same Identity for all the services that are connected with your Azure AD user object.

One key fits them all but that gives more reasons to secure it accordingly. Let’s start moving on to see just this!

Identify and remediate security risks related to events for Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra

Find those inactive users

This is always the best approach for any environment, why should you leave Inactive users in your environments. Nobody is using them and probably they have pre-defined password, not MFA etc.

Just find and remove them or at least block from accessing anything and absolutely the easiest hassle free way to go is Access reviews. It works for Guests and Internal users. Perfection!

You just need to have Azure AD Premium P2 licenses for it.

How you can determinate inactive accounts with API calls

Here is an excellent script. It will find any external users that have no static group membership or application assignments and makes a clear report from the findings

Now when that’s of the way, we can go to see logs and remediation actions.

Different Logs

Azure AD stores reports and security signals for a defined period of time. When it comes to risk information that period may not be long enough.

Report / Signal	Azure AD Free	Azure AD Premium P1	Azure AD Premium P2
Audit logs	7 days	30 days	30 days
Sign-ins	7 days	30 days	30 days
Azure AD MFA usage	30 days	30 days	30 days
Risky sign-ins	7 days	30 days	30 days

Storing logs over 30 days

Storing your logs over 30 days should be enable, it will help to see the historical events and maybe you have compliance reason that you need to do so.

You can access diagnostics logs from the following location https://entra.microsoft.com/#view/Microsoft_Azure_Monitoring/DiagnosticsLogsBlade/queryInputs~/%7B%22id%22%3A%22%2Fproviders%2Fmicrosoft.aadiam%22%7D

And you can have these destination for your logs

Log Analytics

Once you have added the logs to a longer retention store, you could query them with Log Analytics queries.

Once enabled you’ll find access to Log Analytics in the Azure portal > Azure AD > Log Analytics. The following tables are of most interest to Identity Protection administrators:

• AADRiskyUsers – Provides data like the Risky users report in Identity Protection.
• AADUserRiskEvents – Provides data like the Risk detections report in Identity Protection.
• RiskyServicePrincipals – Provides data like the Risky workload identities report in Identity Protection.
• ServicePrincipalRiskEvents – Provides data like the Workload identity detections report in Identity Protection.

Because collecting data in a Log Analytics workspace costs money, you should only gather the categories you need for each service. The amount of data in resource logs varies greatly between services.

You may also wish to avoid collecting platform metrics from Azure resources because this information is already collected in Metrics. Configure your diagnostic data to gather metrics only if you require metric data in the workspace for more advanced log searches.

Granular filtering of resource logs is not possible with diagnostic settings. Some logs in a specific category may be required but not others. You could also eliminate any unnecessary columns from the data. In these circumstances, employ workspace transformations to filter out unnecessary logs.

Storage account

You can also use Storage account to retain the logs, you can select what logs are needed and the retention amount in days.

Consider changing the retention policy to 0 and either utilizing Azure Storage Lifecycle Policy or using a scheduled operation to erase your data from storage. 

If you’re archiving data, you normally want it to be kept for more than 365 days.

If you select a retention policy larger than zero, the logs are assigned an expiration date at the time of storage. You can’t change the date on those logs once they’ve been saved.

Limitations for different destinations

Destination	Requirements
Log Analytics workspace	The workspace doesn’t need to be in the same region as the resource being monitored.
Storage account	Don’t use an existing storage account that has other, non-monitoring data stored in it so that you can better control access to the data. If you’re archiving the activity log and resource logs together, you might choose to use the same storage account to keep all monitoring data in a central location. To send the data to immutable storage, set the immutable policy for the storage account as described in Set and manage immutability policies for Azure Blob Storage. You must follow all steps in this linked article including enabling protected append blobs writes. The storage account needs to be in the same region as the resource being monitored if the resource is regional. Diagnostic settings can’t access storage accounts when virtual networks are enabled. You must enable Allow trusted Microsoft services to bypass this firewall setting in storage accounts so that the Azure Monitor diagnostic settings service is granted access to your storage account. Azure DNS zone endpoints (preview) and Azure Premium LRS (locally redundant storage) storage accounts are not supported as a log or metric destination.
Event Hubs	The shared access policy for the namespace defines the permissions that the streaming mechanism has. Streaming to Event Hubs requires Manage, Send, and Listen permissions. To update the diagnostic setting to include streaming, you must have the ListKey permission on that Event Hubs authorization rule. The event hub namespace needs to be in the same region as the resource being monitored if the resource is regional. Diagnostic settings can’t access Event Hubs resources when virtual networks are enabled. You must enable Allow trusted Microsoft services to bypass this firewall setting in Event Hubs so that the Azure Monitor diagnostic settings service is granted access to your Event Hubs resources.
Partner integrations	The solutions vary by partner. Check the Azure Monitor partner integrations documentation for details.

Decoding those logs

So, now you have those logs, what should you do with them? You can find the Sign-in and Audit logs under Users

Or under Monitoring & health inside Entra portal

If we look the user under Sign-in logs, you can in example see the authentication details

And the Conditional access policy user has triggered and the result of the policy

And to dig even further, I will cover more on the Conditional access in the next Section of this series.

See more from Learn on what is inside the sign-in logs

Revoking users

In a case of a suspected breach, you can revoke the users sessions, multi-factor authentications and revoke their tokens.

Revoking sessions and reset password

If you are doing it manually, you can reset their password and revoke sessions.

Revoking MFA sessions

Revoking tokens and devices

What happens for access is revoked?

After admins have completed the preceding procedures, the user will be unable to obtain fresh tokens for any Azure Active Directory-connected application. The period between revocation and the user losing access is determined on how the application grants access:

• The user loses access to programs that employ access tokens when the token expires.
• Existing sessions for applications that employ session tokens stop as soon as the token expires. If the program is set to do so, it will automatically terminate any open sessions for the user whose disabled state is synced to the application. The length of time depends on how frequently the application and Azure AD are synchronized.

Continuous access evaluation (CAE)

CAE working principle is simple, it will evaluate your access, it will do this by using Critical Event Evaluation by using these triggers:

• User Account is deleted or disabled
• Password for a user is changed or reset
• Multi-factor authentication is enabled for the user
• Administrator explicitly revokes all refresh tokens for a user
• High user risk detected by Azure AD Identity Protection

I will cover CAE in the upcoming posts to this series.

See more on CAE from Learn

Exporting logs

To access logs you need to have one of the following roles:

• Global Administrator
• Security Administrator
• Security Reader
• Global Reader
• Reports Reader

You two view that you can use, current and the Preview one

Formats

You can export these logs in JSON or CSV

JSON

You use use JSON format, maybe it will suit you better than CSV

CSV

And is CSV, note that you can download Authentication details only as CSV.

Report suspicious activity (Preview)

I bet you have seen those Authenticator prompts “No, its not me” but have you ever feel a need to press it?

If not, this is what it looks like.

Bummer, so that’s it, nothing just request denied. Let’s enable it and see the difference.

If a user receives an authentication request that they did not initiate, they can flag it as suspicious. When utilizing the Microsoft Authenticator app or making voice calls, you have access to this control. Reporting questionable activity increases the user’s risk. The user may be blocked if they are subject to risk-based Conditional Access restrictions.

And this is what it will look like for the user.

And in the logs. This indicates a user received an unexpected multifactor authentication that the user did not initiate. This suggests a possible password compromise.

After this you can do the following actions based on the situation

If you Dismiss user risk, it will only take action on the current risk not future ones.

So here we have a nice bridge to the next Topic …

Identify and remediate security risks related to Azure AD Identity Protection events

What are risks?

Risk can be calculated in two different ways—in real time or offline—at the level of the user and sign-in.

The likelihood that an authentication request isn’t allowed by the identity owner is represented by a sign-in risk. It is possible to identify risky behavior for a user that is not connected to a specific malicious sign-in but rather to the user themselves.

It could take up to 10 minutes for real-time detections to appear in reporting. It could take up to 48 hours for offline detections to appear in reporting.

Microsoft has Premium and nonpremium detections. Here is a list of the nonpremium ones.

Nonpremium sign-in risk detections

Risk detection	Detection type	Description
Additional risk detected	Real-time or Offline	This detection indicates that one of the premium detections was detected. Since the premium detections are visible only to Azure AD Premium P2 customers, they’re titled “additional risk detected” for customers without Azure AD Premium P2 licenses.
Anonymous IP address	Real-time	This risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN). These IP addresses are typically used by actors who want to hide their sign-in information (IP address, location, device, and so on) for potentially malicious intent.
Admin confirmed user compromised	Offline	This detection indicates an admin has selected ‘Confirm user compromised’ in the Risky users UI or using riskyUsers API. To see which admin has confirmed this user compromised, check the user’s risk history (via UI or API).
Azure AD threat intelligence	Offline	This risk detection type indicates user activity that is unusual for the user or consistent with known attack patterns. This detection is based on Microsoft’s internal and external threat intelligence sources.

Nonpremium user risk detections

Risk detection	Detection type	Description
Additional risk detected	Real-time or Offline	This detection indicates that one of the premium detections was detected. Since the premium detections are visible only to Azure AD Premium P2 customers, they’re titled “additional risk detected” for customers without Azure AD Premium P2 licenses.
Leaked credentials	Offline	This risk detection type indicates that the user’s valid credentials have been leaked. When cybercriminals compromise valid passwords of legitimate users, they often share those credentials. This sharing is typically done by posting publicly on the dark web, paste sites, or by trading and selling the credentials on the black market. When the Microsoft leaked credentials service acquires user credentials from the dark web, paste sites, or other sources, they’re checked against Azure AD users’ current valid credentials to find valid matches. For more information about leaked credentials, see Common questions.
Azure AD threat intelligence	Offline	This risk detection type indicates user activity that is unusual for the user or consistent with known attack patterns. This detection is based on Microsoft’s internal and external threat intelligence sources.

And the Premium ones. Only Azure AD Premium P2 customers can see premium detections. The premium detections are still sent to customers without Azure AD Premium P2 licenses, but they will be labeled “additional risk detected”

Premium sign-in risk detections

Risk detection	Detection type	Description
Atypical travel	Offline	This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. The algorithm takes into account multiple factors including the time between the two sign-ins and the time it would have taken for the user to travel from the first location to the second. This risk may indicate that a different user is using the same credentials. The algorithm ignores obvious “false positives” contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of the earliest of 14 days or 10 logins, during which it learns a new user’s sign-in behavior.
Anomalous Token	Offline	This detection indicates that there are abnormal characteristics in the token such as an unusual token lifetime or a token that is played from an unfamiliar location. This detection covers Session Tokens and Refresh Tokens. NOTE: Anomalous token is tuned to incur more noise than other detections at the same risk level. This tradeoff is chosen to increase the likelihood of detecting replayed tokens that may otherwise go unnoticed. Because this is a high noise detection, there’s a higher than normal chance that some of the sessions flagged by this detection are false positives. We recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user. If the location, application, IP address, User Agent, or other characteristics are unexpected for the user, the tenant admin should consider this risk as an indicator of potential token replay.
Token Issuer Anomaly	Offline	This risk detection indicates the SAML token issuer for the associated SAML token is potentially compromised. The claims included in the token are unusual or match known attacker patterns.
Malware linked IP address	Offline	This risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server. This detection matches the IP addresses of the user’s device against IP addresses that were in contact with a bot server while the bot server was active. This detection has been deprecated. Identity Protection will no longer generate new “Malware linked IP address” detections. Customers who currently have “Malware linked IP address” detections in their tenant will still be able to view, remediate, or dismiss them until the 90-day detection retention time is reached.
Suspicious browser	Offline	Suspicious browser detection indicates anomalous behavior based on suspicious sign-in activity across multiple tenants from different countries in the same browser.
Unfamiliar sign-in properties	Real-time	This risk detection type considers past sign-in history to look for anomalous sign-ins. The system stores information about previous sign-ins, and triggers a risk detection when a sign-in occurs with properties that are unfamiliar to the user. These properties can include IP, ASN, location, device, browser, and tenant IP subnet. Newly created users will be in “learning mode” period where the unfamiliar sign-in properties risk detection will be turned off while our algorithms learn the user’s behavior. The learning mode duration is dynamic and depends on how much time it takes the algorithm to gather enough information about the user’s sign-in patterns. The minimum duration is five days. A user can go back into learning mode after a long period of inactivity. We also run this detection for basic authentication (or legacy protocols). Because these protocols don’t have modern properties such as client ID, there’s limited telemetry to reduce false positives. We recommend our customers to move to modern authentication. Unfamiliar sign-in properties can be detected on both interactive and non-interactive sign-ins. When this detection is detected on non-interactive sign-ins, it deserves increased scrutiny due to the risk of token replay attacks.
Malicious IP address	Offline	This detection indicates sign-in from a malicious IP address. An IP address is considered malicious based on high failure rates because of invalid credentials received from the IP address or other IP reputation sources.
Suspicious inbox manipulation rules	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection looks at your environment and triggers alerts when suspicious rules that delete or move messages or folders are set on a user’s inbox. This detection may indicate: a user’s account is compromised, messages are being intentionally hidden, and the mailbox is being used to distribute spam or malware in your organization.
Password spray	Offline	A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been successfully performed. For example, the attacker is successfully authenticated, in the detected instance.
Impossible travel	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection identifies user activities (is a single or multiple sessions) originating from geographically distant locations within a time period shorter than the time it takes to travel from the first location to the second. This risk may indicate that a different user is using the same credentials.
New country	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection considers past activity locations to determine new and infrequent locations. The anomaly detection engine stores information about previous locations used by users in the organization.
Activity from anonymous IP address	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection identifies that users were active from an IP address that has been identified as an anonymous proxy IP address.
Suspicious inbox forwarding	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection looks for suspicious email forwarding rules, for example, if a user created an inbox rule that forwards a copy of all emails to an external address.
Mass Access to Sensitive Files	Offline	This detection is discovered by Microsoft Defender for Cloud Apps. This detection looks at your environment and triggers alerts when users access multiple files from Microsoft SharePoint or Microsoft OneDrive. An alert is triggered only if the number of accessed files is uncommon for the user and the files might contain sensitive information

Premium user risk detections

Risk detection	Detection type	Description
Possible attempt to access Primary Refresh Token (PRT)	Offline	This risk detection type is detected by Microsoft Defender for Endpoint (MDE). A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, Windows Server 2016, and later versions, iOS, and Android devices. A PRT is a JSON Web Token (JWT) that’s specially issued to Microsoft first-party token brokers to enable single sign-on (SSO) across the applications used on those devices. Attackers can attempt to access this resource to move laterally into an organization or perform credential theft. This detection will move users to high risk and will only fire in organizations that have deployed MDE. This detection is low-volume and will be seen infrequently by most organizations. However, when it does occur it’s high risk and users should be remediated.
Anomalous user activity	Offline	This risk detection baselines normal administrative user behavior in Azure AD, and spots anomalous patterns of behavior like suspicious changes to the directory. The detection is triggered against the administrator making the change or the object that was changed.
User reported suspicious activity	Offline	This risk detection is reported by a user who denied a multifactor authentication (MFA) prompt and reported it as suspicious activity. An MFA prompt that wasn’t initiated by the user may mean that the user’s credentials have been compromised.

Credentials are processed immediately after they have been found, normally in multiple batches per day.

Microsoft discovers credentials that have been compromised in a number of locations, including:

• Public paste sites like pastebin.com and paste.ca, where criminals frequently upload such information. Most criminals search for stolen credentials here as their initial port of call.
• police departments.
• Research on the dark web is being done by other Microsoft organizations.

Password hashes are necessary for risk detections, such as those for leaked credentials, to work. Implement password hash synchronization with Azure sync tools to enable PHS.

See more from my previous posts.

Identity protection

You access Identity protection from https://entra.microsoft.com/#view/Microsoft_AAD_IAM/IdentityProtectionMenuBlade/~/Overview

From there you will see the protection and reporting panes

How to use protection

You have three different menus, User risk, Sign-in risk and MFA Auth policy that you can use to protect your users

Microsoft advises the risk policy configurations shown below:

User risk policy

When user danger is high, demand a safe password update. Before the user can change their password and mitigate their risk, Azure AD MFA is necessary.

Sign-in risk policy

When the sign-in risk level is Medium or High, you should require Azure AD MFA. This will allow users to authenticate their identity by using one of their registered authentication methods, reducing the sign-in risk.

But wait there is more.

Workload identity risk detections

An identity that gives an application or service principal access to resources, sometimes in the context of a user, is known as a workload identity. These user identities for workloads are distinct from regular user accounts in that they:

• Multi-factor authentication is not possible.
• frequently lack an official lifespan process.
• They must keep their passwords or secrets somewhere.

You need the following to enable Workload risks:

• Workload Identities Premium licensing: You can view and acquire licenses on the Workload Identities blade in the Azure portal.
• One of the following administrator roles assigned
  • Global Administrator
  • Security Administrator
  • Security Operator
  • Security Reader

Microsoft detects risks on workload identities across sign-in behavior and offline indicators of compromise.

Detection name	Detection type	Description
Azure AD threat intelligence	Offline	This risk detection indicates some activity that is consistent with known attack patterns based on Microsoft’s internal and external threat intelligence sources.
Suspicious Sign-ins	Offline	This risk detection indicates sign-in properties or patterns that are unusual for this service principal. The detection learns the baselines sign-in behavior for workload identities in your tenant in between 2 and 60 days, and fires if one or more of the following unfamiliar properties appear during a later sign-in: IP address / ASN, target resource, user agent, hosting/non-hosting IP change, IP country, credential type. Because of the programmatic nature of workload identity sign-ins, we provide a timestamp for the suspicious activity instead of flagging a specific sign-in event. Sign-ins that are initiated after an authorized configuration change may trigger this detection.
Admin confirmed account compromised	Offline	This detection indicates an admin has selected ‘Confirm compromised’ in the Risky Workload Identities UI or using RiskyServicePrincipals API. To see which admin has confirmed this account compromised, check the account’s risk history (via UI or API).
Leaked Credentials	Offline	This risk detection indicates that the account’s valid credentials have been leaked. This leak can occur when someone checks in the credentials in public code artifact on GitHub, or when the credentials are leaked through a data breach. When the Microsoft leaked credentials service acquires credentials from GitHub, the dark web, paste sites, or other sources, they’re checked against current valid credentials in Azure AD to find valid matches.
Malicious application	Offline	This detection indicates that Microsoft has disabled an application for violating our terms of service. We recommend conducting an investigation of the application.
Suspicious application	Offline	This detection indicates that Microsoft has identified an application that may be violating our terms of service, but hasn’t disabled it. We recommend conducting an investigation of the application.
Anomalous service principal activity	Offline	This risk detection baselines normal administrative service principal behavior in Azure AD, and spots anomalous patterns of behavior like suspicious changes to the directory. The detection is triggered against the administrative service principal making the change or the object that was changed.

Investigate

The risky users and risky sign-ins reports allow for downloading the most recent 2500 entries, while the risk detections report allows for downloading the most recent 5000 records.

For the period shown at the top of the report, each report opens with a list of all detections. Depending on the administrator’s option, columns can be added to or removed from each report. The data can be downloaded by administrators in either CSV or JSON format. The filters located at the top of the report can be used to filter reports.

Framework

To begin their investigation into any suspicious activity, organizations can use the frameworks listed below. Investigations may necessitate speaking with the user in question, reviewing the sign-in logs, or reviewing the audit logs, to name a few steps.

• Examine the logs to see if the suspicious activity is normal for the given user.
  • Examine the user’s previous activities, including at least the following properties, to determine if they are typical for the given user.
  • Is the application device registered or compliant?
  • Location – Is the user traveling to a different location or using multiple devices?
  • User agent string IP address
  • If you have access to additional security tools, such as Microsoft Sentinel, look for corresponding alerts that may indicate a larger problem.

Contact the user to confirm that they recognize the sign-in. Methods such as email and Teams may be vulnerable.

Confirm the data you have, such as:

• IP address
• Application
• Device
• Location

Threat intelligence detections

Follow these steps to investigate an Azure AD Threat Intelligence risk detection:

• The sign-in came from an unusual IP address:
  • Confirm whether or not the IP address exhibits suspicious behavior in your environment.
  • Is the IP causing a high number of failures for a specific user or group of users in your directory?
  • Is the IP traffic coming from an unexpected protocol or application, such as Exchange legacy protocols?
  • If the IP address corresponds to a cloud service provider, make sure no legitimate enterprise applications are running from the same IP address.

• Password spray was used to attack this account:
  • Check that no other users in your directory are the victims of the same attack.
  • Do other users have sign-ins with atypical patterns similar to the detected sign-in in the same time frame? Password spray attacks may exhibit unusual patterns in the following areas:
  • Application Protocol IP/ASN Ranges of User Agent Strings
  • Sign-in frequency and timing

Remediation

All active risk detections contribute to the calculation of the user’s risk level. The user risk level is an indicator (low, medium, high) of the probability that the user’s account has been compromised.

PowerShell to Risky APIs

The following will used to query https://learn.microsoft.com/en-us/graph/api/resources/identityprotectionroot?view=graph-rest-1.0

• Microsoft.Graph.Authentication
• Microsoft.Graph.Identity.SignIns

The PowerShell modules are still in Preview.

Graph

And you can also use Microsoft graph to Interact with the following:

• List risky detections using PowerShell
• List risky users using PowerShell
• Confirm users compromised using PowerShell
• Dismiss risky users using PowerShell

Did you know that you can also simulate risks, see this Learn article from Microsoft

And finally now when you know where you can find those Risk policies, you need to know that you can migrate them to Conditional Access.

By doing this you will get the following benefits:

• Improved diagnostic data integration
• Report-only mode support Graph API
• Use additional Conditional Access features in the policy, such as sign-in frequency

And maybe you guessed, then to Conditional access … in the next part of this section

Closure

Some things to remember for the test from this section

Identify and remediate security risks related to events for Azure AD

• Different logs have different retention ages
• How to store logs on different solutions
• How to remediate users when they are compromised
• What features you can use to prevent or protect
• Not for the test but for your own environment, report suspicious activity as high-risk

Identify and remediate security risks related to Azure AD Identity Protection

• What are risks
• What are Premium and nonpremium detections
• How risk policies work and what is the difference
• What are workloads and why you should protect them
• How to use API to list and remediate

Link to main post