Microsoft Sentinel SOC 101: How to Detect and Mitigate Login Attempts Using Legacy Auth with Microsoft Sentinel
Authoritarian
Get this entire series in a free, downloadable eBook https://aka.ms/SentinelSOC101
Legacy authentication is a term that refers to the use of basic authentication methods that do not support modern security features such as multi-factor authentication (MFA) or passwordless authentication. Examples of legacy authentication protocols include POP, IMAP, SMTP, and basic authentication for web applications. Legacy authentication poses a significant security risk, as it makes it easier for attackers to compromise user accounts using brute force, password spraying, or phishing attacks.
Microsoft Entra ID is a cloud-based identity and access management service that provides single sign-on and MFA for cloud and hybrid applications. Microsoft Entra ID supports both modern and legacy authentication protocols, but recommends disabling legacy authentication to improve the security and user experience of your organization.
Microsoft Sentinel is a cloud-native security information and event management (SIEM) solution that helps organizations collect, analyze, and respond to security data from various sources. Microsoft Sentinel can help you detect and mitigate login attempts using legacy authentication by ingesting and querying the sign-in logs from Microsoft Entra ID, creating alerts or incidents based on custom rules or analytics, and taking appropriate actions to resolve them.
In this post, I will discuss how to use Microsoft Sentinel to detect and mitigate login attempts using legacy authentication with Microsoft Entra ID. We will also provide some best practices and recommendations for managing legacy authentication in your organization.
Detect Login Attempts Using Legacy Authentication with Microsoft Sentinel
To detect login attempts using legacy authentication with Microsoft Sentinel, you need to collect and analyze the sign-in logs from Microsoft Entra ID. The sign-in logs contain information about the user, application, device, location, and risk level of each sign-in attempt. The sign-in logs can be ingested into Microsoft Sentinel by using the built-in Microsoft Entra ID connector, which is available from the Content Hub (currently displayed as the Azure Active Directory solution.)
Once the connector is enabled, you can use Kusto Query Language (KQL) to query the sign-in logs in the Logs page of the Microsoft Sentinel portal. The sign-in logs are stored in the SigninLogs table in the Log Analytics workspace.
To detect login attempts using legacy authentication, you need to filter the sign-in logs by the ClientApp column, which shows the type of client application used for each sign-in attempt. You can use the Add filters option in the Logs page to select one or more legacy authentication protocols from the ClientApp list. Alternatively, you can use a KQL query like this:
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Browser", "Exchange ActiveSync", "IMAP4", "Mobile Apps and Desktop clients", "Other clients", "POP3", "SMTP")
This query returns all sign-in attempts using legacy authentication protocols in the last 30 days. You can modify the query parameters according to your needs.
You can use this query as a baseline to detect login attempts using legacy authentication by applying filters or conditions based on your criteria. For example, you can use the following query to get a list of users who have used legacy authentication in the last 30 days:
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Browser", "Exchange ActiveSync", "IMAP4", "Mobile Apps and Desktop clients", "Other clients", "POP3", "SMTP")
| summarize count() by UserPrincipalName
| order by count_ desc
This query groups and counts the sign-in attempts by user principal name (UPN), which is usually the same as the user’s email address, and orders them by descending order.
You can also use this query as a basis to create alerts or incidents in Microsoft Sentinel when login attempts using legacy authentication are detected. For example, you can use the following query to create an alert when a user who has not used legacy authentication for more than 90 days uses it again:
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Browser", "Exchange ActiveSync", "IMAP4", "Mobile Apps and Desktop clients", "Other clients", "POP3", "SMTP")
| summarize arg_max(TimeGenerated, *) by UserPrincipalName
| project UserPrincipalName, TimeGenerated
| join kind=leftouter (
externaldata(displayName:string,lastSignInDateTime:datetime)
[@"https://graph.microsoft.com/v1.0/users?$select=displayName,signInActivity"]
with(format="json", ingestionMapping=[{"column":"displayName","path":"displayName"},{"column":"lastSignInDateTime","path":"signInActivity/lastSignInDateTime"}])
on $left.UserPrincipalName == $right.displayName
)
on UserPrincipalName
| project UserPrincipalName, TimeGenerated, lastSignInDateTime
| where lastSignInDateTime < ago(90d)
| extend AccountCustomEntity = UserPrincipalName
This query joins the SigninLogs table with an external data source from the Microsoft Graph API, which returns the displayName and lastSignInDateTime properties for all users. The lastSignInDateTime property shows the last time the user signed in interactively. The query then filters out users who have signed in using legacy authentication within the last 90 days, and assigns the UserPrincipalName column to the AccountCustomEntity field, which is used by Microsoft Sentinel to identify the entity involved in the alert. You can then use the Analytics page of the Microsoft Sentinel portal to create a scheduled rule based on this query, and configure the alert details, trigger conditions, and response actions.
Mitigate Login Attempts Using Legacy Authentication with Microsoft Sentinel
To mitigate login attempts using legacy authentication with Microsoft Sentinel, you need to take appropriate actions to resolve the alerts or incidents that are generated by the detection queries. Depending on the context and severity of the situation, you may need to perform one or more of the following actions:
Investigate the source and cause of the login attempt. You can use the Investigation page of the Microsoft Sentinel portal to view the details and timeline of the alert or incident and explore the related entities and events. You can also use the Hunting page of the Microsoft Sentinel portal to run custom queries or notebooks to further analyze the data and find additional evidence or indicators of compromise.
Block or disable legacy authentication for the user account. You can use the Microsoft Entra ID portal or PowerShell to block sign-in or disable legacy authentication for the user account that is involved in the alert or incident. This can prevent further unauthorized access or misuse of the account. You can also use automation rules or playbooks in Microsoft Sentinel to perform these actions automatically or semi-automatically based on predefined conditions or triggers.
Reset or revoke the credentials of the user account. You can use the Microsoft Entra ID portal or PowerShell to reset the password or revoke the refresh tokens of the user account that is involved in the alert or incident. This can invalidate any existing sessions or tokens that are associated with the account. You can also use automation rules or playbooks in Microsoft Sentinel to perform these actions automatically or semi-automatically based on predefined conditions or triggers.
Notify or educate the user or owner of the user account. You can use email, phone, or other communication channels to notify or educate the user or owner of the user account that is involved in the alert or incident. This can help them understand the security risks and implications of using legacy authentication and encourage them to follow best practices and policies for their accounts.
Best Practices and Recommendations for Managing Legacy Authentication in Microsoft Entra ID
To prevent or reduce login attempts using legacy authentication with Microsoft Entra ID, we recommend following some of these best practices and recommendations for managing legacy authentication in your organization:
Define and enforce a policy for legacy authentication management. This policy should specify how legacy authentication is enabled, disabled, monitored, and audited in your organization. The policy should also define what constitutes a legitimate use case for legacy authentication and how long it should be allowed before migration.
Implement a process for legacy authentication migration. This process should ensure that users and applications that rely on legacy authentication are identified and migrated to modern authentication methods that support MFA or passwordless authentication. The process should also ensure that users and applications that do not require legacy authentication are blocked from using it.
Monitor and review legacy authentication activity and usage regularly. This activity should involve collecting and analyzing sign-in logs, audit logs, and directory attributes from Microsoft Entra ID to identify and report any login attempts using legacy authentication protocols. The activity should also involve taking corrective actions to block, disable, reset, or revoke any user accounts that use legacy authentication unnecessarily or suspiciously.
Educate and train users and administrators on legacy authentication security and hygiene. This education should involve raising awareness and providing guidance on how to enable and use MFA or passwordless authentication for their accounts, review consented applications, report phishing attempts, and follow security policies and best practices for their accounts.
Summary
Login attempts using legacy authentication are a common security challenge that organizations face when using Microsoft Entra ID as their identity and access management service. By using Microsoft Sentinel as their SIEM solution, organizations can detect and mitigate login attempts using legacy authentication by ingesting and querying sign-in logs from Microsoft Entra ID, creating alerts, and responding to exposed policy violations.
[Want to discuss this further? Hit me up on Twitter or LinkedIn]
[Subscribe to the RSS feed for this blog]
[Subscribe to the Weekly Microsoft Sentinel Newsletter]
[Subscribe to the Weekly Microsoft Defender Newsletter]
[Subscribe to the Weekly Azure OpenAI Newsletter]
[Learn KQL with the Must Learn KQL series and book]
[Learn AI Security with the Must Learn AI Security series and book]
Thats a good article, I removed the Browser and Mobile Apps and Desktop clients from the query, and got almost no results :-)
I was excited to see that you were using a graph call in the externaldata command, but unfortunately, I'm getting a generic error. It seems that there may be permission/access issues?
Any help would be greatly appreciated.
Some aspects of the query had errors so the results are not complete
If the issue persists, please open a support ticket. Request id: 4023391c-1840-429d-ad9d-0a4a07110e3f