+>[!IMPORTANT]

+> Your users must be on the Current Channel to access Copilot. To learn more, see [update channels for Microsoft 365 Apps](/deployoffice/updates/overview-update-channels#current-channel-overview).

+> We previously stated that support for the Monthly Enterprise Channel was available for Microsoft 365 Copilot. As we continue to make frequent product updates and enhancements during the early access program, the time between updates in the Monthly Enterprise Channel limits Microsoft's ability to provide an optimum Copilot experience on desktop clients. Going forward, users in the early access program must be on the Current Channel to receive Copilot updates when they become available. We expect support in the Monthly Enterprise Channel in the future.

+

+ - Microsoft Fabric

+ - Azure portal

+- Microsoft Fabric

+- Azure portal

+If you're using Outlook on the web and you get a **Mailbox couldn't be found for** error, the account that you used to connect to Outlook on the web doesn't have an Exchange Online license and therefore, no mailbox is associated with the account.

+1. Open the [Microsoft 365 admin center](https://admin.microsoft.com/adminportal/home#/homepage). In the left nav pane, in the **Users** section, select **Active users**, and then select the user who is seeing the error.

+1. In the user page that opens, go to the **Licenses and Apps** section, select the appropriate **Location** value, and assign a license that contains Exchange Online (expand **Apps** to see its details).

+This command creates the domain in Azure Active Directory but does not associate it with the publicly registered domain. That comes when you prove that you own the publicly registered domain to Microsoft 365 for enterprises.

+Once this is enabled, group owners can provide group members with the ability to create folders, rename folders, copy, move, and delete messages by navigating to the group from Outlook > **Settings** > **Edit Group** > and selecting the option **All members will be able to create, edit, move, copy, and delete mail folders and rules within the group**. Group level member permission is handled by group owners.

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+

+ - For DAP, the partner tenant user must be a member of the admin agent group.

+ - For GDAP, the partner tenant user must be a member of a security group that has been granted GDAP permissions to the applicable workload associated with the task.

+

+Loop components created in Teams and Outlook are backed by a .loop (earlier versions of Loop-created .fluid) file stored in the creator's OneDrive. A file being in OneDrive means that users can create, discover, and manage Loop components (.loop files) as easily as any Office document.

+A third-party graph export API solution is also available for Loop components that supports both raw export and an HTML offline format.

+ > This policy has previously been titled **Create and view Loop files in Loop**.

+> There are limited [security and compliance capabilities](/microsoft-365/loop/loop-compliance-summary) available specifically for the Loop app.

+## eDiscovery support for Loop content stored in Loop workspaces

+Loop content (pages and components) created in the Loop app are discoverable and have eDiscovery workflow support using the Microsoft Purview tool. As mentioned above, these files are stored in [Syntex repository services](https://devblogs.microsoft.com/microsoft365dev/introducing-syntex-repository-services-microsoft-365-superpowers-for-your-app/) and are available for search and collection, and render in review for both eDiscovery (Standard) and eDiscovery (Premium). The HTML offline export format is supported on eDiscovery (Premium). You can also download and re-upload the files to any OneDrive to view them in their native format.

+A third-party graph export API solution is also available for Loop pages and components that supports both raw export and an HTML offline format.

+## Device Tagging

+Mobile Device Tagging is now available in Public Preview. This feature enables bulk tagging the mobile devices during onboarding by allowing the admins to set up tags via Intune. Admin can configure the device tags through Intune via configuration policies and push them to userΓÇÖs devices. Once the user installs and activates Defender, the client app passes the device tags to the Security Portal. The Device tags appear against the devices in the Device Inventory.

+This configuration is available for both the enrolled (MDM) devices as well as unenrolled (MAM) devices. For more information, see [Device Tagging (MDM)](/microsoft-365/security/defender-endpoint/android-configure#device-tagging) and [Device Tagging (MAM)](/microsoft-365/security/defender-endpoint/android-configure-mam#device-tagging).

+It includes several admin controls to offer flexibility, such as the ability to configure the feature from within the Microsoft Intune admin center. Admins can also enable privacy controls to configure the data that is sent by Defender for Endpoint from Android devices. For more information, see [network protection](/microsoft-365/security/defender-endpoint/android-configure).

+>[!Important]

+>This feature is in Public Preview. The following information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

+## Device Tagging

+Mobile Device Tagging is now available in Public Preview. This feature enables bulk tagging the mobile devices during onboarding by allowing the admins to set up tags via Intune. Admin can configure the device tags through Intune via configuration policies and push them to userΓÇÖs devices. Once the User installs and activates Defender, the client app passes the device tags to the Security Portal. The Device tags appear against the devices in the Device Inventory. For more information, read [Configure Device Tagging](/microsoft-365/security/defender-endpoint/ios-configure-features#device-tagging).

+### 20230809.1

+ Title: Alert classification for malicious exchange connectors

+description: Alert grading recipients from malicious exchange connectors activity and protect their network from malicious attack.

+keywords: incidents, alerts, investigate, analyze, response, correlation, attack, machines, devices, users, identities, identity, mailbox, email, 365, microsoft, m365

+ms.mktglfcycl: deploy

+ms.sitesec: library

+ms.pagetype: security

+f1.keywords:

+ - NOCSH

+ms.localizationpriority: medium

+audience: ITPro

+ - m365-security

+ - tier2

+search.appverid:

+ - MOE150

+ - MET150

+# Alert classification for malicious exchange connectors

+**Applies to:**

+- Microsoft 365 Defender

+Threat actors use compromised exchange connectors for sending out spam and phishing emails in bulk to unsuspecting recipients by masquerading legitimate emails. Since the connector is compromised, the emails would usually be trusted by the recipients. These kinds of phishing emails are common vectors for phishing campaigns, and business email compromise (BEC) scenario. Hence, such emails need to be monitored heavily due to the likelihood of successful recipients' compromises being high.

+This playbook helps in investigating instances where malicious connectors are setup/deployed by malicious actors. Accordingly, they take necessary steps to remediate the attack and mitigate the security risks arising from it. The playbook helps in classifying the alerts as either true positive (TP) or false positive (FP). If alerts are TP, the playbook lists necessary recommended actions for remediating the attack. This playbook is available for security teams who review, handle/manage, and grade the alerts.

+Following are the results of using a playbook:

+- Determination of the alert as malicious (TP) or benign (FP).

+- If malicious, remediate/remove the malicious connector from the environment.

+## Exchange connectors

+Exchange connectors are a collection of instructions that customize the way your email flows to and from your Microsoft 365 or Office 365 organization. Usually, most Microsoft 365 and Office 365 organizations don't need connectors for regular mail flow.

+Connectors are used to route mail traffic between remote email systems and Office 365 (O365) or O365, and on-premises email systems.

+## Malicious Exchange connectors

+Attackers may compromise an existing exchange connector or compromise an admin, and set up a new connector by sending phish or spam/bulk emails.

+The typical indicators of a malicious connector can be found when looking at email traffic and its headers. For example, when email traffic is observed from a connector node with a mismatch in P1 (header sender) and P2 (envelope sender) sender addresses along with no information on Sender's AccountObjectId.

+This alert tries to identify such instances of mail flow, wherein the mail sending activity seems suspicious adding to that relevant information on sender is unavailable.

+## Playbook workflow

+You must follow the sequence to identify malicious exchange connectors:

+- Identify which accounts are sending emails:

+ - Do accounts appear to be compromised?

+- Identify the connector relaying on emails to check:

+ - If the connector is supposed to send out high volume emails?

+ - If the connector was modified or created recently?

+- Are emails going to internal email addresses?

+ - Are emails going to external addresses (Spray and pray spam)?

+ - Are emails going to external addresses belonging to customers or vendors (supply chain type attack)?

+- Check if the FROM header and Envelope Sender domains are the same or different.

+## Investigating malicious connectors

+This section describes the steps to investigate an alert and remediate the security risk due to this incident.

+- Determine whether the connector demonstrates bad (malicious) behavior.

+ - Look for events indicating unusual mail traffic and identify, whether any new exchange connector was added recently.

+ - For mail traffic observed, determine if the email accounts are compromised by inspecting whether the accounts are responsible for unusual mail traffic.

+ - Look for mail content containing malicious artifacts (bad links/attachments).

+ - Look for domains that are not part of your environment.

+- Determine the email accounts are not compromised. Identify the connector that was recently added or modified in the environment.

+- Look for:

+ - Field values in the P1 sender (email header sender) and P2 sender (envelope sender), and check whether there's a mismatch.

+ - Empty values in the SenderObjectId field.

+- Use telemetry data to note:

+ - The NetworkMessageId (Message ID) of the emails that were sent from the malicious connector.

+ - The connector creation date, last modified date, and last modified by date.

+ - The IP address of the connector from where the email traffic is observed.

+## Advanced hunting queries

+You can use [advanced hunting](/microsoft-365/security/defender/advanced-hunting-overview?) queries to gather information related to an alert and determine whether the activity is suspicious.

+Ensure you have access to the following tables:

+|Table Name|Description|

+|||

+|EmailEvents| Contains information related to email flow.|

+|CloudAppEvents|Contains audit log of user activities.|

+|IdentityLogonEvents|Contains login information for all users.|

+## References

+AHQs samples for reference:

+- Run this KQL to check new connector creation.

+ ```KQL

+ //modify timeWindow to modify the lookback.

+ let timeWindow = now(-7d); let timeNow = now();

+ CloudAppEvents

+ | where Timestamp between (timeWindow .. timeNow)

+ | where isnotempty(AccountObjectId)

+ | where ActionType == "New-InboundConnector"

+ | mvexpand property = RawEventData.Parameters

+ | extend ConnectorName = iff(property.Name == "Name", property.Value, ""),

+ IsEnabled = iff((property.Name == "Enabled" and property.Value == "True"),

+ true, false)

+ | where isnotempty( ConnectorName) or IsEnabled

+ | project-reorder ConnectorName, IsEnabled

+ ```

+- Run this KQL to check the volume of events from the alerted connector with time window of before and after the alerts.

+ ```KQL

+ //modify timeWindow to modify the lookback.

+ let timeWindow = now(-7d); let timeNow = now();

+ let connectorOperations = pack_array("Set-OutboundConnector",

+ "New-OutboundConnector", "Set-InboundConnector", "New-InboundConnector");

+ let mailThreshold = 100; //define threshold for inspection and filtering

+ let myConnector= //use this code block to specify relevant connector(s)

+ CloudAppEvents

+ | where Timestamp between (timeWindow .. timeNow)

+ | where ActionType has_any (connectorOperations)

+ | mv-expand property = RawEventData.Parameters

+ | where property.Name == "Name"

+ | summarize by ConnectorName=tostring(property.Value)

+ ;

+ EmailEvents

+ | where isnotempty( toscalar (myConnector))

+ | where Timestamp between (timeWindow .. timeNow)

+ | where isnotempty( SenderObjectId) and isnotempty( Connectors)

+ | where Connectors in (toscalar (myConnector))

+ | summarize MailCount = dcount(NetworkMessageId) by Connectors,

+ SenderObjectId, bin(Timestamp, 1h)

+ | where MailCount >= mailThreshold

+ ```

+- Run this KQL to check whether emails are being sent to external domains.

+ ```KQL

+ //modify timeWindow to modify the lookback.

+ let timeWindow = now(-7d); let timeNow = now();

+ EmailEvents

+ | where Timestamp between (timeWindow .. timeNow)

+ | where isnotempty( SenderObjectId)

+ | extend RecipientDomain= split(RecipientEmailAddress, "@")[1]

+ | where (SenderFromDomain != RecipientDomain) or (SenderMailFromDomain

+ != RecipientDomain)

+ | where EmailDirection !in ("Intra-org" , "Inbound") //comment this line to

+ look across all mailflow directions

+ ```

+ - If sent to external domains, who else in the environment is sending similar emails (Could indicate compromised user if recipient is unknown domain).

+ ```KQL

+ //modify timeWindow to modify the lookback.

+ let timeWindow = now(-7d); let timeNow = now();

+ let countThreshold= 100; //modify count threshold accordingly

+ EmailEvents

+ | where Timestamp between (timeWindow .. timeNow)

+ | where isnotempty( SenderObjectId)

+ | extend RecipientDomain= split(RecipientEmailAddress, "@")[1]

+ | where (SenderFromDomain != RecipientDomain) or (SenderMailFromDomain

+ != RecipientDomain)

+ | where EmailDirection !in ("Intra-org" , "Inbound")

+ | summarize MailCount= dcount(NetworkMessageId) by SenderObjectId,

+ SenderFromAddress, SenderMailFromAddress , bin(Timestamp, 1h)

+ | where MailCount > countThreshold

+ ```

+ - Check the mail content for bad behavior

+ - Look at URLs in the email or email having attachments.

+## AHQ considerations

+Following are the AHQ considerations for protecting the recipients from malicious attack.

+- Check for admin logins for those who frequently manage connectors from unusual locations (generate stats and exclude locations from where most successful logins are observed).

+- Look for login failures from unusual locations.

+ ```

+ //modify timeWindow to modify the lookback.

+ let timeWindow = now(-7d); let timeNow = now();

+ let logonFail= materialize (

+ IdentityLogonEvents

+ | where Timestamp between (timeWindow .. timeNow)

+ | where isnotempty(AccountObjectId)

+ | where Application != "Active Directory"

+ | where ActionType == "LogonFailed"

+ | where ISP != "Microsoft Azure"

+ | summarize failedLogonCount=count(), LatestTime = max(Timestamp),

+ EarliestTime = min(Timestamp) by AccountObjectId, Application, ISP,

+ CountryCode, bin(Timestamp, 60s)

+ | where failedLogonCount > 100);

+ // let hasLogonFails = isnotempty(toscalar (logonFail));

+ let logonFailUsers = materialize ( logonFail | distinct AccountObjectId |

+ take 100);

+ let hasLogonFails = isnotempty(toscalar (logonFailUsers));

+ let logonSuccess=

+ IdentityLogonEvents

+ | where hasLogonFails

+ | where Timestamp between (timeWindow .. timeNow)

+ | where AccountObjectId in (logonFailUsers)

+ | where Application != "Active Directory"

+ | where ISP != "Microsoft Azure"

+ | where ActionType == "LogonSuccess"

+ | project SuccessTime= Timestamp, ReportId, AccountUpn, AccountObjectId,

+ ISP, CountryCode, Application;

+ logonFail

+ | join kind = innerunique logonSuccess on AccountObjectId, ISP, Application

+ | where SuccessTime between (LatestTime .. (LatestTime + 10s))

+ | summarize arg_min(SuccessTime, ReportId), EarliestFailedTime=min

+ (EarliestTime), LatestFailedTime=max(LatestTime), failedLogonCount=

+ take_any(failedLogonCount), SuccessLogonCount=count(), ISPSet=

+ make_set(ISP), CountrySet=make_set(CountryCode), AppSet=make_set

+ (Application) by AccountObjectId, AccountUpn

+ | project-rename Timestamp=SuccessTime

+ ```

+## Recommended actions

+Once it's determined that the observed alert activities are part of TP, classify those alerts and perform the actions below:

+- Disable or remove the connector that was found to be malicious.

+- If the admin account was compromised, reset the admin's account credentials. Also, disable/revoke tokens for the compromised admin account and enable multi-factor authentication for all admin accounts.

+- Look for suspicious activities performed by the admin.

+- Check for other suspicious activities across other connectors in the environment.

+## See also

+- [Overview of alert classification](alert-grading-playbooks.md)

+- [Investigate alerts](investigate-alerts.md)

+ Title: Alert classification for password spray attacks

+description: Alert classification guide for password spray attacks coming to review the alerts and take recommended actions to remediate the attack and protect your network.

+keywords: incidents, alerts, investigate, analyze, response, correlation, attack, devices, users, 365, microsoft, m365, password, spray, alert classification, alert grading, cloud apps, password spray, password spray attack

+ms.mktglfcycl: deploy

+ms.sitesec: library

+ms.pagetype: security

+f1.keywords:

+ - NOCSH

+ms.localizationpriority: medium

+audience: ITPro

+ - m365-security

+ - tier2

+search.appverid:

+ - MOE150

+ - met150

+# Alert classification for password spray attacks

+**Applies to:**

+- Microsoft 365 Defender

+Threat actors use innovative ways to compromise their target environments. One type of attack gaining traction is the password spray attack, where attackers aim to access many accounts within a network with minimal effort. Unlike traditional brute force attacks, where threat actors try many passwords on a single account, password spray attacks focus on guessing the correct password for many accounts with a limited set of commonly used passwords. It makes the attack particularly effective against organizations with weak or easily guessable passwords, leading to severe data breaches and financial losses for organizations.

+Attackers use automated tools to repeatedly attempt to gain access to a specific account or system using a list of commonly used passwords. Attackers sometimes abuse legitimate cloud services by creating many virtual machines (VMs) or containers to launch a password spray attack.

+This playbook helps investigate cases where suspicious behavior is observed as indicative of a password spray attack. This guide is for security teams like the security operations center (SOC) and IT administrators who review, handle/manage, and classify the alerts. This guide helps in quickly classifying the alerts as either [true positive (TP) or false positive (FP)](investigate-alerts.md) and, in the case of TP, take recommended actions to remediate the attack and mitigate the security risks.

+The intended results of using this guide are:

+- You've identified the alerts associated with password spray attempts as malicious (TP) or false positive (FP) activities.

+- You've taken the necessary actions to remediate the attack.

+## Investigation steps

+This section contains step-by-step guidance to respond to the alert and take the recommended actions to protect your organization from further attacks.

+### 1. Investigate the security alerts

+ - **Are the alerted sign-in attempts coming from a suspicious location?** Check sign-in attempts from locations other than those typical for impacted user accounts. Multiple sign-in attempts from one or many users are helpful indicators.

+### 2. Investigate suspicious user activity

+ - **Are there unusual events with uncommon properties?** Unique properties for an impacted user, like unusual ISP, country/region, or city, might indicate suspicious sign-in patterns.

+ - **Is there a marked increase in email or file-related activities?** Suspicious events like increased attempts in mail access or send activity or an increase in uploading of files to SharePoint or OneDrive for an impacted user are some signs to look for.

+ - **Are there multiple failed sign-in attempts?** A high number of failed sign-in attempts from various IPs and geographic locations by an impacted user might indicate a password spray attack.

+ - **Identify the ISP from the sign-in activity of an impacted user.** Check for sign-in activities by other user accounts from the same ISP.

+

+ - **Inspect any recent modifications in your environment:**

+ - Changes in Office 365 applications like Exchange Online permission, mail auto-forwarding, mail redirection

+ - Modifications in PowerApps, like automated data transmission configuration through PowerAutomate

+ - Modifications in Azure environments, like Azure portal subscription changes

+ - Changes to SharePoint Online, like the impacted user account gaining access to multiple sites or files with sensitive/confidential/company-only content

+

+ - **Inspect the impacted account's activities that occur within a short time span on multiple platforms and apps.** Audit events to check the timeline of activities, like contrasting the user's time spent reading or sending email followed by allocating resources to the user's account or other accounts.

+### 3. Investigate possible follow-on attacks

+**Inspect your environment for other attacks involving impacted user accounts** as attackers often perform malicious activities after a successful password spray attack. Consider investigating the following possibly suspicious activities:

+- [Multi-factor authentication (MFA)](/microsoft-365/admin/security-and-compliance/multi-factor-authentication-microsoft-365)-related attacks

+ - Attackers use **MFA fatigue** to bypass this security measure that organizations adopt to protect their systems. **Check for multiple MFA requests raised by an impacted user account.**

+ - Attackers might perform **MFA tampering** using an impacted user account with elevated privileges by disabling MFA protection for other accounts within the tenant. **Check for suspicious admin activities performed by an impacted user.**

+- Internal phishing attacks

+ - Attackers might use an impacted user account to send internal phishing mails. **Check suspicious activities like email forwarding or creation of inbox manipulation or inbox forwarding rules.** The following playbooks can guide you to further investigate email events:

+ - [Classifying alerts for suspicious email forwarding activity](alert-grading-playbook-email-forwarding.md)

+ - [Classifying alerts for suspicious inbox forwarding rules](alert-grading-playbook-inbox-forwarding-rules.md)

+ - [Classifying alerts for suspicious inbox manipulation rules](alert-grading-playbook-inbox-manipulation-rules.md)

+ - **Check whether the user received other alerts before the password spray activity.** Having these alerts indicate that the user account might be compromised. Examples include impossible travel alert, activity from infrequent country/region, and suspicious email deletion activity, among others.

+## Advanced hunting queries

+[Advanced hunting](/microsoft-365/security/defender/advanced-hunting-overview) is a query-based threat hunting tool that lets you inspect events in your network and locate threat indicators.

+Use these queries to gather more information related to the alert and determine whether the activity is suspicious.

+Ensure you have access to the following tables:

+- [AadSignInEventsBeta](advanced-hunting-aadsignineventsbeta-table.md)

+- [CloudAppEvents](advanced-hunting-cloudappevents-table.md)

+- [DeviceEvents](advanced-hunting-deviceevents-table.md)

+- [EmailEvents](advanced-hunting-emailevents-table.md)

+- [EmailUrlInfo](advanced-hunting-emailurlinfo-table.md)

+- [IdentityLogonEvents](advanced-hunting-identitylogonevents-table.md)

+- [UrlClickEvents](advanced-hunting-urlclickevents-table.md)

+Use this query to identify password spray activity.

+```kusto

+IdentityLogonEvents

+| where Timestamp > ago(7d)

+| where ActionType == "LogonFailed"

+| where isnotempty(RiskLevelDuringSignIn)

+| where AccountObjectId == <Impacted User Account Object ID>

+| summarize TargetCount = dcount(AccountObjectId), TargetCountry = dcount(Location), TargetIPAddress = dcount(IPAddress) by ISP

+| where TargetCount >= 100

+| where TargetCountry >= 5

+| where TargetIPAddress >= 25

+```

+Use this query to identify other activities from the alerted ISP.

+```kusto

+CloudAppEvents

+| where Timestamp > ago(7d)

+| where AccountObjectId == <Impacted User Account Object ID>

+| where ISP == <Alerted ISP>

+| summarize count() by Application, ActionType, bin(Timestamp, 1h)

+```

+Use this query to identify sign-in patterns for the impacted user.

+```kusto

+IdentityLogonEvents

+| where Timestamp > ago(7d)

+| where AccountObjectId == <Impacted User Account Object ID>

+| where ISP == <Alerted ISP>

+| where Application != "Active Directory"

+| summarize SuccessCount = countif(ActionType == "LogonSuccess"), FailureCount = countif(ActionType == "LogonFailed") by ISP

+```

+Use this query to identify MFA fatigue attacks.

+```kusto

+AADSignInEventsBeta

+| where Timestamp > ago(1h)

+//Error Code : 50088 : Limit on telecom MFA calls reached

+//Error Code : 50074 : Strong Authentication is required.

+| where ErrorCode in ("50074","50088")

+| where isnotempty(AccountObjectId)

+| where isnotempty(IPAddress)

+| where isnotempty(Country)

+| summarize (Timestamp, ReportId) = arg_max(Timestamp, ReportId), FailureCount = count() by AccountObjectId, Country, IPAddress

+| where FailureCount >= 10

+```

+Use this query to identify MFA reset activities.

+```kusto

+let relevantActionTypes = pack_array("Disable Strong Authentication.","system.mfa.factor.deactivate", "user.mfa.factor.update", "user.mfa.factor.reset_all", "core.user_auth.mfa_bypass_attempted");

+CloudAppEvents

+AlertInfo

+| where Timestamp > ago(1d)

+| where isnotempty(AccountObjectId)

+| where Application in ("Office 365","Okta")

+| where ActionType in (relevantActionTypes)

+| where RawEventData contains "success"

+| project Timestamp, ReportId, AccountObjectId, IPAddress, ActionType

+CloudAppEvents

+| where Timestamp > ago(1d)

+| where ApplicationId == 11161

+| where ActionType == "Update user."

+| where isnotempty(AccountObjectId)

+| where RawEventData has_all("StrongAuthenticationRequirement","[]")

+| mv-expand ModifiedProperties = RawEventData.ModifiedProperties

+| where ModifiedProperties.Name == "StrongAuthenticationRequirement" and ModifiedProperties.OldValue != "[]" and ModifiedProperties.NewValue == "[]"

+| mv-expand ActivityObject = ActivityObjects

+| where ActivityObject.Role == "Target object"

+| extend TargetObjectId = tostring(ActivityObject.Id)

+| project Timestamp, ReportId, AccountObjectId, ActivityObjects, TargetObjectId

+```

+Use this query to find new email inbox rules created by the impacted user.

+```kusto

+CloudAppEvents

+| where AccountObjectId == <ImpactedUser>

+| where Timestamp > ago(21d)

+| where ActionType == "New-InboxRule"

+| where RawEventData.SessionId in (suspiciousSessionIds)

+```

+## Recommended actions

+Once you determine that the activities associated with this alert are malicious, classify those alerts as TP and take these actions for remediation:

+1. Reset the user's account credentials.

+2. Revoke access tokens of the compromised account.

+3. Use number matching in Microsoft Authenticator to mitigate MFA fatigue attacks.

+4. Apply the principle of least privilege. Create accounts with minimum privilege required to complete tasks.

+5. Configure blocking based on the sender's IP address and domains if the artifacts are related to email.

+6. Block URLs or IP addresses (on the network protection platforms) that were identified as malicious during the investigation.

+## See also

+- [Overview of alert classification](alert-grading-playbooks.md)

+- [Investigate alerts](investigate-alerts.md)

+ Title: Alert classification playbooks

+description: Review the alerts for well-known attacks and take recommended actions to remediate the attack and protect your network.

+keywords: incidents, alerts, investigate, analyze, response, correlation, attack, machines, devices, users, identities, identity, mailbox, email, 365, microsoft, m365, alert classification, alert grading, classify alert

+search.appverid: met150

+ms.mktglfcycl: deploy

+ms.sitesec: library

+ms.pagetype: security

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+audience: ITPro

+- m365-security

+- tier2

+- autoir

+- admindeeplinkDEFENDER

+# Alert classification playbooks

+**Applies to:**

+- Microsoft 365 Defender

+Alert classification playbooks allow you to methodically review and quickly classify the alerts for well-known attacks and take recommended actions to remediate the attack and protect your network. Alert classification will also help in properly classifying the overall incident.

+As a security researcher or security operations center (SOC) analyst, you must have access to the Microsoft 365 Defender portal so that you can:

+- Assess and review the generated alerts and associated incidents. See [investigate alerts](investigate-alerts.md).

+- Search your tenant's security signal data and check for potential threats and suspicious activities. See [advanced hunting](advanced-hunting-overview.md).

+> [!NOTE]

+> You can provide feedback to Microsoft about true positive and false positives alerts, not only at the end of the investigation, but also during the investigation process. This can help Microsoft with future analysis and classification of security events.

+## Microsoft Defender for Office 365

+[Microsoft Defender for Office 365](/microsoft-365/security/office-365-security/defender-for-office-365) safeguards your organization against malicious threats posed by email messages, links (URLs), and collaboration tools. Defender for Office 365 includes:

+- Threat protection policies

+ Define threat-protection policies to set the appropriate level of protection for your organization.

+- Reports

+ View real-time reports to monitor Defender for Office 365 performance in your organization.

+- Threat investigation and response capabilities

+ Use leading-edge tools to investigate, understand, simulate, and prevent threats.

+- Automated investigation and response capabilities

+ Save time and effort investigating and mitigating threats.

+Defender for Office 365 alerts can be classified as:

+- True positive (TP) for confirmed malicious activity.

+- False positive (FP) for confirmed non-malicious activity.

+> [!NOTE]

+> Microsoft 365 Defender portal [https://security.microsoft.com](https://security.microsoft.com) brings together functionality from existing Microsoft security portals. The Microsoft 365 Defender portal emphasizes quick access to information, simpler layouts, and bringing related information together for easier use.

+## Microsoft Defender for Cloud Apps

+[Microsoft Defender for Cloud Apps](/defender-cloud-apps) is a Cloud Access Security Broker (CASB) that supports various deployment modes including log collection, API connectors, and reverse proxy. It provides rich visibility, control over data travel, and sophisticated analytics to identify and combat cyberthreats across all your Microsoft and third-party cloud services.

+Defender for Cloud Apps natively integrates with leading Microsoft solutions and is designed with security professionals in mind. It provides simple deployment, centralized management, and innovative automation capabilities.

+The Defender for Cloud Apps framework includes the capability to protect your network against cyberthreats and anomalies, detects unusual behavior across cloud apps to identify ransomware, compromised users or rogue applications. It enables the analysis of high-risk usage and can remediate automatically to limit the risk to your organization.

+Defender for Cloud Apps alerts can be classified as:

+- TP for confirmed malicious activity.

+- Benign true positive (B-TP) for suspicious but not malicious activity, such as a penetration test or other authorized suspicious action.

+- FP for confirmed non-malicious activity.

+## Alert classification playbooks

+See these playbooks for steps to more quickly classify alerts for the following threats:

+- [Suspicious email forwarding activity](alert-grading-playbook-email-forwarding.md)

+- [Suspicious inbox manipulation rules](alert-grading-playbook-inbox-manipulation-rules.md)

+- [Suspicious inbox forwarding rules](alert-grading-playbook-inbox-forwarding-rules.md)

+- [Suspicious IP addresses related to password spray activity](alert-grading-password-spray.md)

+- [Password spray attacks](alert-grading-password-spray-attack.md)

+See [Investigate alerts](investigate-alerts.md) for information on how to examine alerts with the Microsoft 365 Defender portal.

+ Title: Alert classification for suspicious IP address related to password spraying activity

+description: Alert classification for suspicious IP address related to password spraying activity to review the alerts and take recommended actions to remediate the attack and protect your network.

+keywords: incidents, alerts, investigate, analyze, response, correlation, attack, devices, users, 365, microsoft, m365, password, spray, alert classification, alert grading, cloud apps, suspicious IP, classify alert

+ms.mktglfcycl: deploy

+ms.sitesec: library

+ms.pagetype: security

+f1.keywords:

+ - NOCSH

+ms.localizationpriority: medium

+audience: ITPro

+ - m365-security

+ - tier2

+search.appverid:

+ - MOE150

+ - met150

+# Alert classification for suspicious IP addresses related to password spray attacks

+**Applies to:**

+- Microsoft 365 Defender

+Threat actors use password guessing techniques to gain access to user accounts. In a password spray attack, the threat actor might resort to a few of the most used passwords against many different accounts. Attackers successfully compromise accounts using password spraying since many users still utilize default and weak passwords.

+This playbook helps you investigate instances where IP addresses have been labeled risky or associated with a password spray attack, or suspicious unexplained activities were detected, such as a user signing in from an unfamiliar location or a user getting unexpected multi-factor authentication (MFA) prompts. This guide is for security teams like the security operations center (SOC) and IT administrators who review, handle/manage, and classify the alerts. This guide helps in quickly classifying the alerts as either [true positive (TP) or false positive (FP)](investigate-alerts.md) and, in the case of TP, take recommended actions to remediate the attack and mitigate the security risks.

+The intended results of using this guide are:

+- You've identified the alerts associated with password-spray IP addresses as malicious (TP) or false positive (FP) activities.

+- You've taken the necessary action if IP addresses have been performing password spray attacks.

+## Investigation steps

+This section contains step-by-step guidance to respond to the alert and take the recommended actions to protect your organization from further attacks.

+### 1. Review the alert

+Here's an example of a password spray alert in the alert queue:

+This means there's suspicious user activity originating from an IP address that might be associated with a brute-force or password spray attempt according to threat intelligence sources.

+### 2. Investigate the IP address

+- Look at the [activities](microsoft-365-security-center-defender-cloud-apps.md) that originated from the IP:

+ - **Is it mostly failed attempts to sign in?**

+ - **Does the interval between attempts to sign in look suspicious?** Automated password spray attacks tend to have a regular time interval between attempts.

+ - **Are there successful attempts of a user/several users signing in with [MFA](/microsoft-365/admin/security-and-compliance/multi-factor-authentication-microsoft-365) prompts?** The existence of these attempts might indicate that the IP isn't malicious.

+ - **Are legacy protocols used?** Using protocols like POP3, IMAP, and SMTP might indicate an attempt to perform a password spray attack. Finding `Unknown(BAV2ROPC)` in the user agent (Device type) in the [Activity log](/defender-cloud-apps/activity-filters#ip-address-insights) indicates use of legacy protocols. You can refer to the example below when looking at the Activity log. This activity must be further correlated to other activities.

+ :::image type="content" source="../../media/alert-grading-playbook-password-spray/fig2-password-spray-alert.png" alt-text="Screenshot of Microsoft Defender 365 interface showing the Device type." lightbox="../../media/alert-grading-playbook-password-spray/fig2-password-spray-alert.png":::

+ _Figure 1. The Device type field shows `Unknown(BAV2ROPC)` user agent in Microsoft 365 Defender._

+ - **Check the use of anonymous proxies or the Tor network.** Threat actors often use these alternative proxies to hide their information, making them difficult to trace. However, not all use of said proxies correlate with malicious activities. You must investigate other suspicious activities that might provide better attack indicators.

+ - Is the IP address coming from a virtual private network (VPN)? Is the VPN trustworthy? **Check if the IP originated from a VPN and review the organization behind it by using tools** like [RiskIQ](https://community.riskiq.com/learn-more/enterprise).

+ - **Check other IPs with the same subnet/ISP.** Sometimes password spray attacks originate from many different IPs within the same subnet/ISP.

+- **Is the IP address common for the tenant?** Check the Activity log to see if the tenant has seen the IP address in the past 30 days.

+- **Search for other suspicious activities or alerts that originated from the IP in the tenant.** Examples of activities to look out for might include email deletion, forwarding rules creation, or file downloads after a successful attempt to sign in.

+- **Check the IP address' risk score** by using tools like RiskIQ.

+### 3. Investigate suspicious user activity after signing in

+Once a suspicious IP is recognized, you can review the accounts that signed in. It's possible that a group of accounts were compromised and successfully used to sign in from the IP or other similar IPs.

+Filter all successful attempts to sign in from the IP address around and shortly after the time of the alerts. Then search for malicious or unusual activities in such accounts after signing in.

+- User account activities

+ **Validate that the activity in the account preceding the password spray activity is not suspicious.** For example, check if there's anomalous activity based on common location or ISP, if the account is utilizing a user-agent that it didn't use before, if any other guest accounts were created, if any other credentials were created after the account signed in from a malicious IP, among others.

+- Alerts

+ **Check whether the user received other alerts preceding the password spray activity.** Having these alerts indicate that the user account might be compromised. Examples include impossible travel alert, activity from infrequent country/region, and suspicious email deletion activity, among others.

+- Incident

+ **Check whether the alert is associated with other alerts that indicate an incident.** If so, then check whether the incident contains other true positive alerts.

+## Advanced hunting queries

+[Advanced hunting](/microsoft-365/security/defender/advanced-hunting-overview) is a query-based threat hunting tool that lets you inspect events in your network and locate threat indicators.

+Use this query to find accounts with attempts to sign in with the highest risk scores that came from the malicious IP. This query also filters all successful attempts to sign in with corresponding risk scores.

+```kusto

+let start_date = now(-7d);

+let end_date = now();

+let ip_address = ""; // enter here the IP address

+AADSignInEventsBeta

+| where Timestamp between (start_date .. end_date)

+| where IPAddress == ip_address

+| where isnotempty(RiskLevelDuringSignIn)

+| project Timestamp, IPAddress, AccountObjectId, RiskLevelDuringSignIn, Application, ResourceDisplayName, ErrorCode

+| sort by Timestamp asc

+| sort by AccountObjectId, RiskLevelDuringSignIn

+| partition by AccountObjectId ( top 1 by RiskLevelDuringSignIn ) // remove line to view all successful logins risk scores

+```

+Use this query to check if the suspicious IP used legacy protocols in attempts to sign in.

+```kusto

+let start_date = now(-8h);

+let end_date = now();

+let ip_address = ""; // enter here the IP address

+AADSignInEventsBeta

+| where Timestamp between (start_date .. end_date)

+| where IPAddress == ip_address

+| summarize count() by UserAgent

+```

+Use this query to review all alerts in the last seven days associated with the suspicious IP.

+```kusto

+let start_date = now(-7d);

+let end_date = now();

+let ip_address = ""; // enter here the IP address

+let ip_alert_ids = materialize (

+ AlertEvidence

+ | where Timestamp between (start_date .. end_date)

+ | where RemoteIP == ip_address

+ | project AlertId);

+AlertInfo

+| where Timestamp between (start_date .. end_date)

+| where AlertId in (ip_alert_ids)

+```

+Use this query to review account activity for suspected compromised accounts.

+```kusto

+let start_date = now(-8h);

+let end_date = now();

+let ip_address = ""; // enter here the IP address

+let compromise_users =

+ materialize ( AADSignInEventsBeta

+ | where Timestamp between (start_date .. end_date)

+ | where IPAddress == ip_address

+ | where ErrorCode == 0

+ | distinct AccountObjectId);

+CloudAppEvents

+ | where Timestamp between (start_date .. end_date)

+ | where AccountObjectId in (compromise_users)

+ | summarize ActivityCount = count() by AccountObjectId, ActivityType

+ | extend ActivityPack = pack(ActivityType, ActivityCount)

+ | summarize AccountActivities = make_bag(ActivityPack) by AccountObjectId

+```

+Use this query to review all alerts for suspected compromised accounts.

+```kusto

+let start_date = now(-8h); // change time range

+let end_date = now();

+let ip_address = ""; // enter here the IP address

+let compromise_users =

+ materialize ( AADSignInEventsBeta

+ | where Timestamp between (start_date .. end_date)

+ | where IPAddress == ip_address

+ | where ErrorCode == 0

+ | distinct AccountObjectId);

+let ip_alert_ids = materialize ( AlertEvidence

+ | where Timestamp between (start_date .. end_date)

+ | where AccountObjectId in (compromise_users)

+ | project AlertId, AccountObjectId);

+AlertInfo

+| where Timestamp between (start_date .. end_date)

+| where AlertId in (ip_alert_ids)

+| join kind=innerunique ip_alert_ids on AlertId

+| project Timestamp, AccountObjectId, AlertId, Title, Category, Severity, ServiceSource, DetectionSource, AttackTechniques

+| sort by AccountObjectId, Timestamp

+```

+## Recommended Actions

+1. [Block the attacker's IP address.](/azure/active-directory/conditional-access/block-legacy-authentication)

+2. Reset user accounts' credentials.

+3. Revoke access tokens of compromised accounts.

+4. [Block legacy authentication.](/azure/active-directory/conditional-access/howto-conditional-access-policy-block-legacy)

+5. [Require MFA for users](/microsoft-365/business-premium/m365bp-turn-on-mfa) if possible to [enhance account security](/azure/active-directory/authentication/tutorial-enable-azure-mfa) and make account compromise by a password spray attack difficult for the attacker.

+6. Block the compromised user account from signing in if needed.

+## See also

+- [Overview of alert classification](alert-grading-playbooks.md)

+- [Classifying password spray attacks](alert-grading-password-spray-attack.md)

+- [Investigate alerts](investigate-alerts.md)

+- Active [threat actors](/microsoft-365/security/intelligence/microsoft-threat-actor-naming) and their campaigns