Legitimate hosting services, such as SharePoint, OneDrive, and Dropbox, are widely used by organizations for storing, sharing, and collaborating on files. However, the widespread use of such services also makes them attractive targets for threat actors, who exploit the trust and familiarity associated with these services to deliver malicious files and links, often avoiding detection by traditional security measures.

Importantly, Microsoft takes action against malicious users violating the Microsoft Services Agreement in how they use apps like SharePoint and OneDrive. To help protect enterprise accounts from compromise, by default both Microsoft 365 and Office 365 support multi-factor authentication (MFA) and passwordless sign-in. Consumers can also go passwordless with their Microsoft account. Because security is a team sport, Microsoft also works with third parties like Dropbox to share threat intelligence and protect mutual customers and the wider community.

In this blog, we discuss the typical attack chain used in campaigns misusing file hosting services and detail the recently observed tactics, techniques, and procedures (TTPs), including the increasing use of certain defense evasion tactics. To help defenders protect their identities and data, we also share mitigation guidance to help reduce the impact of this threat, and detection details and hunting queries to locate potential misuse of file hosting services and related threat actor activities. By understanding these evolving threats and implementing the recommended mitigations, organizations can better protect themselves against these sophisticated campaigns and safeguard digital assets.

Attack overview

Phishing campaigns exploiting legitimate file hosting services have been trending throughout the last few years, especially due to the relative ease of the technique. The files are delivered through different approaches, including email and email attachments like PDFs, OneNote, and Word files, with the intent of compromising identities or devices. These campaigns are different from traditional phishing attacks because of the sophisticated defense evasion techniques used.

Since mid-April 2024, we observed threat actors increasingly use these tactics aimed at circumventing defense mechanisms:

• Files with restricted access: The files sent through the phishing emails are configured to be accessible solely to the designated recipient. This requires the recipient to be signed in to the file-sharing service—be it Dropbox, OneDrive, or SharePoint—or to re-authenticate by entering their email address along with a one-time password (OTP) received through a notification service.
• Files with view-only restrictions: To bypass analysis by email detonation systems, the files shared in these phishing attacks are set to ‘view-only’ mode, disabling the ability to download and consequently, the detection of embedded URLs within the file.

An example attack chain is provided below, depicting the updated defense evasion techniques being used across stages 4, 5, and 6:

Initial access

The attack typically begins with the compromise of a user within a trusted vendor. After compromising the trusted vendor, the threat actor hosts a file on the vendor’s file hosting service, which is then shared with a target organization. This misuse of legitimate file hosting services is particularly effective because recipients are more likely to trust emails from known vendors, allowing threat actors to bypass security measures and compromise identities. Often, users from trusted vendors are added to allow lists through policies set by the organization on Exchange Online products, enabling phishing emails to be successfully delivered.

While file names observed in these campaigns also included the recipients, the hosted files typically follow these patterns:

• Familiar topics based on existing conversations
  • For example, if the two organizations have prior interactions related to an audit, the shared files could be named “Audit Report 2024”.
• Familiar topics based on current context
  • If the attack has not originated from a trusted vendor, the threat actor often impersonates administrators or help desk or IT support personnel in the sender display name and uses a file name such as “IT Filing Support 2024”, “Forms related to Tax submission”, or “Troubleshooting guidelines”.
• Topics based on urgency
  • Another common technique observed by the threat actors creating these files is that they create a sense of urgency with the file names like “Urgent:Attention Required” and “Compromised Password Reset”.

Defense evasion techniques

Once the threat actor shares the files on the file hosting service with the intended users, the file hosting service sends the target user an automated email notification with a link to access the file securely. This email is not a phishing email but a notification for the user about the sharing action. In scenarios involving SharePoint or OneDrive, the file is shared from the user’s context, with the compromised user’s email address as the sender. However, in the Dropbox scenario, the file is shared from no-reply@dropbox[.]com. The files are shared through automated notification emails with the subject: “<User> shared <document> with you”. To evade detections, the threat actor deploys the following additional techniques:

• Only the intended recipient can access the file
  • The intended recipient needs to re-authenticate before accessing the file
  • The file is accessible only for a limited time window
• The PDF shared in the file cannot be downloaded

These techniques make detonation and analysis of the sample with the malicious link almost impossible since they are restricted.

Identity compromise

When the targeted user accesses the shared file, the user is prompted to verify their identity by providing their email address:

Next, an OTP is sent from no-reply@notify.microsoft[.]com. Once the OTP is submitted, the user is successfully authorized and can view a document, often masquerading as a preview, with a malicious link, which is another lure to make the targeted user click the “View my message” access link.

This link redirects the user to an adversary-in-the-middle (AiTM) phishing page, where the user is prompted to provide the password and complete multifactor authentication (MFA). The compromised token can then be leveraged by the threat actor to perform the second stage BEC attack and continue the campaign.

Recommended actions

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Enable Conditional Access policies in Microsoft Entra, especially risk-based access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP address location information, and device status, among others, are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices, Azure trusted IP address requirements, or risk-based policies with proper access control. If you are still evaluating Conditional Access, use security defaults as an initial baseline set of policies to improve identity security posture.
• Implement continuous access evaluation.
• Implement Microsoft Entra passwordless sign-in with FIDO2 security keys.
• Turn on network protection in Microsoft Defender for Endpoint to block connections to malicious domains and IP addresses.
• Implement Microsoft Defender for Endpoint – Mobile Threat Defense on mobile devices used to access enterprise assets.
• Leverage Microsoft Edge to automatically identify and block malicious websites, including those used in this phishing campaign, and Microsoft Defender for Office 365 to detect and block malicious emails, links, and files. Monitor suspicious or anomalous activities in Microsoft Entra ID Protection. Investigate sign-in attempts with suspicious characteristics (such as the location, ISP, user agent, and use of anonymizer services). Educate users about the risks of secure file sharing and emails from trusted vendors.

Appendix

Microsoft Defender XDR detections

Microsoft Defender XDR raises the following alerts by combining Microsoft Defender for Office 365 URL click and Microsoft Entra ID Protection risky sign-ins signal.

• Risky sign-in after clicking a possible AiTM phishing URL
• User compromised through session cookie hijack
• User compromised in a known AiTM phishing kit

Hunting queries

Microsoft Defender XDR 

The file sharing events related to the activity in this blog post can be audited through the CloudAppEvents telemetry. Microsoft Defender XDR customers can run the following query to find related activity in their networks: 

Automated email notifications and suspicious sign-in activity

By correlating the email from the Microsoft notification service or Dropbox automated notification service with a suspicious sign-in activity, we can identify compromises, especially from securely shared SharePoint or Dropbox files.

let usersWithSuspiciousEmails = EmailEvents
    | where SenderFromAddress in ("no-reply@notify.microsoft.com", "no-reply@dropbox.com") or InternetMessageId startswith "<OneTimePasscode"
    | where isnotempty(RecipientObjectId)
    | distinct RecipientObjectId;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

Files share contents and suspicious sign-in activity

In the majority of the campaigns, the file name involves a sense of urgency or content related to finance or credential updates. By correlating the file share emails with suspicious sign-ins, compromises can be detected. (For example: Alex shared “Password Reset Mandatory.pdf” with you). Since these are observed as campaigns, validating that the same file has been shared with multiple users in the organization can support the detection.

let usersWithSuspiciousEmails = EmailEvents
    | where Subject has_all ("shared", "with you")
    | where Subject has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password")
    | where isnotempty(RecipientObjectId)
    | summarize RecipientCount = dcount(RecipientObjectId), RecipientList = make_set(RecipientObjectId) by Subject
    | where RecipientCount >= 10
    | mv-expand RecipientList to typeof(string)
    | distinct RecipientList;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

BEC: File sharing tactics based on the file hosting service used

To initiate the file sharing activity, these campaigns commonly use certain action types depending on the file hosting service being leveraged. Below are the action types from the audit logs recorded for the file sharing events. These action types can be used to hunt for activities related to these campaigns by replacing the action type for its respective application in the queries below this table.

OneDrive or SharePoint: The following query highlights that a specific file has been shared by a user with multiple participants. Correlating this activity with suspicious sign-in attempts preceding this can help identify lateral movements and BEC attacks.

let securelinkCreated = CloudAppEvents
    | where ActionType == "SecureLinkCreated"
    | project FileCreatedTime = Timestamp, AccountObjectId, ObjectName;
let filesCreated = securelinkCreated
    | where isnotempty(ObjectName)
    | distinct tostring(ObjectName);
CloudAppEvents
| where ActionType == "AddedToSecureLink"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive for Business")
| extend FileShared = tostring(RawEventData.ObjectId)
| where FileShared in (filesCreated)
| extend UserSharedWith = tostring(RawEventData.TargetUserOrGroupName)
| extend TypeofUserSharedWith = RawEventData.TargetUserOrGroupType
| where TypeofUserSharedWith == "Guest"
| where isnotempty(FileShared) and isnotempty(UserSharedWith)
| join kind=inner securelinkCreated on $left.FileShared==$right.ObjectName
// Secure file created recently (in the last 1day)
| where (Timestamp - FileCreatedTime) between (1d .. 0h)
| summarize NumofUsersSharedWith = dcount(UserSharedWith) by FileShared
| where NumofUsersSharedWith >= 20

Dropbox: The following query highlights that a file hosted on Dropbox has been shared with multiple participants.

CloudAppEvents
| where ActionType in ("Added users and/or groups to shared file/folder", "Invited user to Dropbox and added them to shared file/folder")
| where Application == "Dropbox"
| where ObjectType == "File"
| extend FileShared = tostring(ObjectName)
| where isnotempty(FileShared)
| mv-expand ActivityObjects
| where ActivityObjects.Type == "Account" and ActivityObjects.Role == "To"
| extend SharedBy = AccountId
| extend UserSharedWith = tostring(ActivityObjects.Name)
| summarize dcount(UserSharedWith) by FileShared, AccountObjectId
| where dcount_UserSharedWith >= 20

Microsoft Sentinel

Microsoft Sentinel customers can use the resources below to find related activities similar to those described in this post:

The following query identifies files with specific keywords that attackers might use in this campaign that have been shared through OneDrive or SharePoint using a Secure Link and accessed by over 10 unique users. It captures crucial details like target users, client IP addresses, timestamps, and file URLs to aid in detecting potential attacks:

let OperationName = dynamic(['SecureLinkCreated', 'AddedToSecureLink']);
OfficeActivity
| where Operation in (OperationName)
| where OfficeWorkload in ('OneDrive', 'SharePoint')
| where SourceFileName has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password", "paycheck", "bank statement", "bank details", "closing", "funds", "bank account", "account details", "remittance", "deposit", "Reset")
| summarize CountOfShares = dcount(TargetUserOrGroupName), 
            make_list(TargetUserOrGroupName), 
            make_list(ClientIP), 
            make_list(TimeGenerated), 
            make_list(SourceRelativeUrl) by SourceFileName, OfficeWorkload
| where CountOfShares > 10

Considering that the attacker compromises users through AiTM,  possible AiTM phishing attempts can be detected through the below rule:

• Possible AiTM Phishing Attempt

In addition, customers can also use the following identity-focused queries to detect and investigate anomalous sign-in events that may be indicative of a compromised user identity being accessed by a threat actor:

• Signins From VPS Providers
• Signins from Nord VPN Providers
• Successful Signin From Non-Compliant Device

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post File hosting services misused for identity phishing appeared first on Microsoft Security Blog.

As stated in the MSRC blog, given the reality of threat actors that are well resourced and funded by nation states, we are shifting the balance we need to strike between security and business risk – the traditional sort of calculus is simply no longer sufficient. For Microsoft, this incident has highlighted the urgent need to move even faster.

If the same team were to deploy the legacy tenant today, mandatory Microsoft policy and workflows would ensure MFA and our active protections are enabled to comply with current policies and guidance, resulting in better protection against these sorts of attacks.

Microsoft was able to identify these attacks in log data by reviewing Exchange Web Services (EWS) activity and using our audit logging features, combined with our extensive knowledge of Midnight Blizzard. In this blog, we provide more details on Midnight Blizzard, our preliminary and ongoing analysis of the techniques they used, and how you may use this information pragmatically to protect, detect, and respond to similar threats in your own environment.

Using the information gained from Microsoft’s investigation into Midnight Blizzard, Microsoft Threat Intelligence has identified that the same actor has been targeting other organizations and, as part of our usual notification processes, we have begun notifying these targeted organizations.

It’s important to note that this investigation is still ongoing, and we will continue to provide details as appropriate.

Midnight Blizzard

Midnight Blizzard (also known as NOBELIUM) is a Russia-based threat actor attributed by the US and UK governments as the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs) and IT service providers, primarily in the US and Europe. Their focus is to collect intelligence through longstanding and dedicated espionage of foreign interests that can be traced to early 2018. Their operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection.

Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Midnight Blizzard’s espionage and intelligence gathering activities leverage a variety of initial access, lateral movement, and persistence techniques to collect information in support of Russian foreign policy interests. They utilize diverse initial access methods ranging from stolen credentials to supply chain attacks, exploitation of on-premises environments to laterally move to the cloud, and exploitation of service providers’ trust chain to gain access to downstream customers. Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection. OAuth is an open standard for token-based authentication and authorization that enables applications to get access to data and resources based on permissions set by a user.

Midnight Blizzard is tracked by partner security vendors as APT29, UNC2452, and Cozy Bear.

Midnight Blizzard observed activity and techniques

Initial access through password spray

Midnight Blizzard utilized password spray attacks that successfully compromised a legacy, non-production test tenant account that did not have multifactor authentication (MFA) enabled. In a password-spray attack, the adversary attempts to sign into a large volume of accounts using a small subset of the most popular or most likely passwords. In this observed Midnight Blizzard activity, the actor tailored their password spray attacks to a limited number of accounts, using a low number of attempts to evade detection and avoid account blocks based on the volume of failures. In addition, as we explain in more detail below, the threat actor further reduced the likelihood of discovery by launching these attacks from a distributed residential proxy infrastructure. These evasion techniques helped ensure the actor obfuscated their activity and could persist the attack over time until successful.

Malicious use of OAuth applications

Threat actors like Midnight Blizzard compromise user accounts to create, modify, and grant high permissions to OAuth applications that they can misuse to hide malicious activity. The misuse of OAuth also enables threat actors to maintain access to applications, even if they lose access to the initially compromised account. Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment. The actor created additional malicious OAuth applications. They created a new user account to grant consent in the Microsoft corporate environment to the actor controlled malicious OAuth applications. The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.

Collection via Exchange Web Services

Midnight Blizzard leveraged these malicious OAuth applications to authenticate to Microsoft Exchange Online and target Microsoft corporate email accounts.

Use of residential proxy infrastructure

As part of their multiple attempts to obfuscate the source of their attack, Midnight Blizzard used residential proxy networks, routing their traffic through a vast number of IP addresses that are also used by legitimate users, to interact with the compromised tenant and, subsequently, with Exchange Online. While not a new technique, Midnight Blizzard’s use of residential proxies to obfuscate connections makes traditional indicators of compromise (IOC)-based detection infeasible due to the high changeover rate of IP addresses.

Defense and protection guidance

Due to the heavy use of proxy infrastructure with a high changeover rate, searching for traditional IOCs, such as infrastructure IP addresses, is not sufficient to detect this type of Midnight Blizzard activity. Instead, Microsoft recommends the following guidance to detect and help reduce the risk of this type of threat:

Defend against malicious OAuth applications

• Audit the current privilege level of all identities, users, service principals, and Microsoft Graph Data Connect applications (use the Microsoft Graph Data Connect authorization portal), to understand which identities are highly privileged. Privilege should be scrutinized more closely if it belongs to an unknown identity, is attached to identities that are no longer in use, or is not fit for purpose. Identities can often be granted privilege over and above what is required. Defenders should pay attention to apps with app-only permissions as those apps may have over-privileged access. Additional guidance for investigating compromised and malicious applications.
• Audit identities that hold ApplicationImpersonation privileges in Exchange Online. ApplicationImpersonation allows a caller, such as a service principal, to impersonate a user and perform the same operations that the user themselves could perform. Impersonation privileges like this can be configured for services that interact with a mailbox on a user’s behalf, such as video conferencing or CRM systems. If misconfigured, or not scoped appropriately, these identities can have broad access to all mailboxes in an environment. Permissions can be reviewed in the Exchange Online Admin Center, or via PowerShell:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers

• Identify malicious OAuth apps using anomaly detection policies. Detect malicious OAuth apps that make sensitive Exchange Online administrative activities through App governance. Investigate and remediate any risky OAuth apps.
• Implement conditional access app control for users connecting from unmanaged devices.
• Midnight Blizzard has also been known to abuse OAuth applications in past attacks against other organizations using the EWS.AccessAsUser.All Microsoft Graph API role or the Exchange Online ApplicationImpersonation role to enable access to email. Defenders should review any applications that hold EWS.AccessAsUser.All and EWS.full_access_as_app permissions and understand whether they are still required in your tenant. If they are no longer required, they should be removed.
• If you require applications to access mailboxes, granular and scalable access can be implemented using role-based access control for applications in Exchange Online. This access model ensures applications are only granted to the specific mailboxes required.

Protect against password spray attacks

• Eliminate insecure passwords.
• Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
• Reset account passwords for any accounts targeted during a password spray attack. If a targeted account had system-level permissions, further investigation may be warranted.
• Detect, investigate, and remediate identity-based attacks using solutions like Microsoft Entra ID Protection.
• Investigate compromised accounts using Microsoft Purview Audit (Premium).
• Enforce on-premises Microsoft Entra Password Protection for Microsoft Active Directory Domain Services.
• Use risk detections for user sign-ins to trigger multifactor authentication or password changes.
• Investigate any possible password spray activity using the password spray investigation playbook.

Detection and hunting guidance

By reviewing Exchange Web Services (EWS) activity, combined with our extensive knowledge of Midnight Blizzard, we were able to identify these attacks in log data. We are sharing some of the same hunting methodologies here to help other defenders detect and investigate similar attack tactics and techniques, if leveraged against their organizations. The audit logging that Microsoft investigators used to discover this activity was also made available to a broader set of Microsoft customers last year.

Identity alerts and protection

Microsoft Entra ID Protection has several relevant detections that help organizations identify these techniques or additional activity that may indicate anomalous activity that needs to be investigated. The use of residential proxy network infrastructure by threat actors is generally more likely to generate Microsoft Entra ID Protection alerts due to inconsistencies in patterns of user behavior compared to legitimate activity (such as location, diversity of IP addresses, etc.) that may be beyond the control of the threat actor.

The following Microsoft Entra ID Protection alerts can help indicate threat activity associated with this attack:

• Unfamiliar sign-in properties – This alert flags sign-ins from networks, devices, and locations that are unfamiliar to the user.
• Password spray – 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 has successfully authenticated in the detected instance.
• Threat intelligence – This alert 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.
• Suspicious sign-ins (workload identities) – This alert indicates sign-in properties or patterns that are unusual for the related service principal.

XDR and SIEM alerts and protection

Once an actor decides to use OAuth applications in their attack, a variety of follow-on activities can be identified in alerts to help organizations identify and investigate suspicious activity.

The following built-in Microsoft Defender for Cloud Apps alerts are automatically triggered and can help indicate associated threat activity:

• App with application-only permissions accessing numerous emails – A multi-tenant cloud app with application-only permissions showed a significant increase in calls to the Exchange Web Services API specific to email enumeration and collection. The app might be involved in accessing and retrieving sensitive email data.
• Increase in app API calls to EWS after a credential update – This detection generates alerts for non-Microsoft OAuth apps where the app shows a significant increase in calls to Exchange Web Services API within a few days after its certificates/secrets are updated or new credentials are added.
• Increase in app API calls to EWS – This detection generates alerts for non-Microsoft OAuth apps that exhibit a significant increase in calls to the Exchange Web Serves  API. This app might be involved in data exfiltration or other attempts to access and retrieve data.
• App metadata associated with suspicious mal-related activity – This detection generates alerts for non-Microsoft OAuth apps with metadata, such as name, URL, or publisher, that had previously been observed in apps with suspicious mail-related activity. This app might be part of an attack campaign and might be involved in exfiltration of sensitive information.
• Suspicious user created an OAuth app that accessed mailbox items – A user that previously signed on to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

The following Microsoft Defender XDR alert can indicate associated activity:

• Suspicious user created an OAuth app that accessed mailbox items – A user who previously signed in to a medium- or high-risk session created an OAuth application that was used to access a mailbox using sync operation or multiple email messages using bind operation. An attacker might have compromised a user account to gain access to organizational resources for further attacks.

Related hunting queries

February 5, 2024 update: A query that was not working for all customers has been removed.

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

• Find MailItemsAccessed or SaaS actions performed by a labeled password spray IP

CloudAppEvents 
| where Timestamp between (startTime .. endTime) 
| where isnotempty(IPTags) and not(IPTags has_any('Azure','Internal Network IP','branch office')) 
| where IPTags has_any ("Brute force attacker", "Password spray attacker", "malicious", "Possible Hackers") 

Microsoft Sentinel customers can use the following analytic rules to find related activity in their network.

• Password spray attempts – This query helps identify evidence of password spray activity against Microsoft Entra ID applications.
• OAuth application being granted full_access_as_app permission – This detection looks for the full_access_as_app permission being granted to an OAuth application with Admin Consent. This permission provides access to Exchange mailboxes via the EWS API and could be exploited to access sensitive data. The application granted this permission should be reviewed to ensure that it is necessary for the application’s function.
• Addition of services principal/user with elevated permissions – This rule looks for a service principal being granted permissions that could be used to add a Microsoft Entra ID object or user account to an Admin directory role.
• Offline access via OAuth for previously unknown Azure application – This rule alerts when a user consents to provide a previously unknown Azure application with offline access via OAuth. Offline access will provide the Azure app with access to the resources without requiring two-factor authentication. Consent to applications with offline access should generally be rare.

Microsoft Sentinel customers can also use this hunting query:

• OAuth apps reading mail both via GraphAPI and directly – This query returns OAuth Applications that access mail both directly and via Graph, allowing review of whether such dual access methods follow expected user patterns.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:

• Midnight Blizzard
• Midnight Blizzard credential attacks
• Threat overview: Cloud identity abuse
• Techniques profile: Password spray attacks

February 13, 2024 minor update: Updated guidance in “Defend against malicious OAuth applications” section with clearer wording and links to additional resources.

The post Midnight Blizzard: Guidance for responders on nation-state attack appeared first on Microsoft Security Blog.

Generative AI will empower individuals and organizations to increase productivity and accelerate their work, but these tools can also be susceptible to internal and external risk. Attackers are already using AI to launch, scale, and even automate new and sophisticated cyberattacks, all without writing a single line of code. Machine learning demands have increased as well, leading to an abundance of workload identities across corporate multicloud environments. This makes it more complex for identity and access professionals to secure, permission, and track a growing set of human and machine identities.

Adopting a comprehensive defense-in-depth strategy that spans identity, endpoint, and network can help your organization be better prepared for the opportunities and challenges we face in 2024 and beyond. To confidently secure identity and access at your organization, here are five areas worth prioritizing in the new year:

1. Empower your workforce with Microsoft Security Copilot.
2. Enforce least privilege access everywhere, including AI apps.
3. Get prepared for more sophisticated attacks.
4. Unify access policies across identity, endpoint, and network security.
5. Control identities and access for multicloud.

Our recommendations come from serving thousands of customers, collaborating with the industry, and continuously protecting the digital economy from a rapidly evolving threat landscape.

Microsoft Entra

Learn how unified multicloud identity and network access help you protect and verify identities, manage permissions, and enforce intelligent access policies, all in one place.

Explore Microsoft Entra

Priority 1: Empower your workforce with Microsoft Security Copilot

This year generative AI will become deeply infused into cybersecurity solutions and play a critical role in securing access. Identities, both human and machine, are multiplying at a faster rate than ever—as are identity-based attacks. Sifting through sign-in logs to investigate or remediate identity risks does not scale to the realities of cybersecurity talent shortages when there are more than 4,000 identity attacks per second.¹ To stay ahead of malicious actors, identity professionals need all the help they can get. Here’s where Microsoft Security Copilot can make a big difference at your organization and help cut through today’s noisy security landscape. Generative AI can meaningfully augment the talent and ingenuity of your identity experts with automations that work at machine-speed and intelligence.

Based on the latest Work Trend Index, business leaders are empowering workers with AI to increase productivity and help employees with repetitive and low value tasks.² Early adopters of Microsoft Security Copilot, our AI companion for cybersecurity teams, have seen a 44% increase in efficiency and 86% increase in quality of work.³ Identity teams can use natural language prompts in Copilot to reduce time spent on common tasks, such as troubleshooting sign-ins and minimizing gaps in identity lifecycle workflows. It can also strengthen and uplevel expertise in the team with more advanced capabilities like investigating users and sign-ins associated with security incidents while taking immediate corrective action. 

To get the most out of your AI investments, identity teams will need to build a consistent habit of using their AI companions. Once your workforce becomes comfortable using these tools, it is time to start building a company prompt library that outlines the specific queries commonly used for various company tasks, projects, and business processes. This will equip all current and future workers with an index of shortcuts that they can use to be productive immediately.

How to get started: Check out this Microsoft Learn training on the fundamentals of generative AI, and subscribe for updates on Microsoft Security Copilot to be the first to hear about new product innovations, the latest generative AI tips, and upcoming events.

Priority 2: Enforce least privilege access everywhere, including AI apps

One of the most common questions we hear is how to secure access to AI apps—especially those in corporate (sanctioned) and third-party (unsanctioned) environments. Insider risks like data leakage or spoilage can lead to tainted large language models, confidential data being shared in apps that are not monitored, or the creation of rogue user accounts that are easily compromised. The consequences of excessively permissioned users are especially damaging within sanctioned AI apps where users who are incorrectly permissioned can quickly gain access to and manipulate company data that was never meant for them.

Ultimately, organizations must secure their AI applications with the same identity and access governance rules they apply to the rest of their corporate resources. This can be done with an identity governance solution, which lets you define and roll out granular access policies for all your users and company resources, including the generative AI apps your organization decides to adopt. As a result, only the right people will have the right level of access to the right resources. The access lifecycle can be automated at scale through controls like identity verification, entitlement management, lifecycle workflows, access requests, reviews, and expirations. 

To enforce least privilege access, make sure that all sanctioned apps and services, including generative AI apps, are managed by your identity and access solution. Then, define or update your access policies with a tool like Microsoft Entra ID Governance that controls who, when, why, and how long users retain access to company resources. Use lifecycle workflows to automate user access policies so that any time a user’s status changes, they still maintain the correct level of access. Where applicable, extend custom governance rules and user experiences to any customer, vendor, contractor, or partner by integrating Microsoft Entra External ID, a customer identity and access management (CIAM) solution. For high-risk actions, require proof of identity in real-time using Microsoft Entra Verified ID. Microsoft Security Copilot also comes with built-in governance policies, tailored specifically for generative AI applications, to prevent misuse.

How to get started: Read the guide to securely govern AI and other business-critical applications in your environment. Make sure your governance strategy abides by least privilege access principles.

Priority 3: Get prepared for more sophisticated attacks

Not only are known attacks like password spray increasing in intensity, speed, and scale, but new attack techniques are being developed rapidly that pose a serious threat to unprepared teams. Multifactor authentication adds a layer of security, but cybercriminals can still find ways around it. More sophisticated attacks like token theft, cookie replay, and AI-powered phishing campaigns are also becoming more prevalent. Identity teams need to adapt to a new cyberthreat landscape where bad actors can automate the full lifecycle of a threat campaign—all without writing a single line of code.

To stay safe in today’s relentless identity threat landscape, we recommend taking a multi-layered approach. Start by implementing phishing-resistant multifactor authentication that is based on cryptography or biometrics such as Windows Hello, FIDO2 security keys, certificate-based authentication, and passkeys (both roaming and device-bound). These methods can help you combat more than 99% of identity attacks as well as advanced phishing and social engineering schemes.⁴ 

For sophisticated attacks like token theft and cookie replay, have in place a machine learning-powered identity protection tool and Secure Web Gateway (SWG) to detect a wide range of risk signals that flag unusual user behavior. Then use continuous access evaluation (CAE) with token protection features to respond to risk signals in real-time and block, challenge, limit, revoke, or allow user access. For new attacks like one-time password (OTP) bots that take advantage of multifactor authentication fatigue, educate employees about common social engineering tactics and use the Microsoft Authenticator app to suppress sign-in prompts when a multifactor authentication fatigue attack is detected. Finally, for high assurance scenarios, consider using verifiable credentials—digital identity claims from authoritative sources—to quickly verify an individual’s credentials and grant least privilege access with confidence. 

Customize your policies in the Microsoft Entra admin center to mandate strong, phishing resistant authentication for any scenario, including step up authentication with Microsoft Entra Verified ID. Make sure to implement an identity protection tool like Microsoft Entra ID Protection, which now has token protection capabilities, to detect and flag risky user signals that your risk-based CAE engine can actively respond to. Lastly, secure all internet traffic, including all software as a service (SaaS) apps, with Microsoft Entra Internet Access, an identity-centric SWG that shields users against malicious internet traffic and unsafe content.  

How to get started: To quick start your defense-in-depth campaign, we’ve developed default access policies that make it easy to implement security best practices, such as requiring multifactor authentication for all users. Check out these guides on requiring phishing-resistant multifactor authentication and planning your conditional access deployment. Finally, read up on our token protection, continuous access evaluation, and multifactor authentication fatigue suppression capabilities.

Priority 4: Unify access policies across identity, endpoint, and network security

In most organizations, the identity, endpoint, and network security functions are siloed, with teams using different technologies for managing access. This is problematic because it requires conditional access changes to be made in multiple places, increasing the chance of security holes, redundancies, and inconsistent access policies between teams. Identity, endpoint, and network tools need to be integrated under one policy engine, as neither category alone can protect all access points.

By adopting a Zero Trust security model that spans identity, endpoint, and network security, you can easily manage and enforce granular access policies in one place. This helps reduce operational complexity and can eliminate gaps in policy coverage. Plus, by enforcing universal conditional access policies from a single location, your policy engine can analyze a more diverse set of signals such as network, identity, endpoint, and application conditions before granting access to any resource—without making any code changes. 

Microsoft’s Security Service Edge (SSE) solution is identity-aware and is delivering a unique innovation to the SSE category by bringing together identity, endpoint, and network security access policies. The solution includes Microsoft Entra Internet Access, an SWG for safeguarding SaaS apps and internet traffic, as well as Microsoft Entra Private Access, a Zero Trust Network Access (ZTNA) solution for securing access to all applications and resources. When you unify your network and identity access policies, it is easier to secure access and manage your organization’s conditional access lifecycle.

How to get started: Read these blogs to learn why their identity-aware designs make Microsoft Entra Internet Access and Microsoft Entra Private Access unique to the SSE category. To learn about the different use cases and scenarios, configuration prerequisites, and how to enable secure access, go to the Microsoft Entra admin center. 

Priority 5: Control identities and access for multicloud

Today, as multicloud adoption increases, it is harder than ever to gain full visibility over which identities, human or machine, have access to what resources across your various clouds.  Plus, with the massive increase in AI-driven workloads, the number of machine identities being used in multicloud environments is quickly rising, outnumbering human identities 10 to 1.⁵ Many of these identities are created with excessive permissions and little to no governance, with less than 5% of permissions granted actually used, suggesting that a vast majority of machine identities are not abiding by least privilege access principles. As a result, attackers have shifted their attention to apps, homing in on workload identities as a vulnerable new threat vector. Organizations need a unified control center for managing workload identities and permissions across all their clouds.

Securing access to your multicloud infrastructure across all identity types starts with selecting the methodology that makes sense for your organization. Zero Trust provides an excellent, customizable framework that applies just as well to workload identities as it does to human identities. You can effectively apply these principles with a cloud infrastructure entitlement management (CIEM) platform, which provides deep insights into the permissions granted across your multicloud, how they are used, and the ability to right size those permissions. Extending these controls to your machine identities will require a purpose-built tool for workload identities that uses strong credentials, conditional access policies, anomaly and risk signal monitoring, access reviews, and location restrictions.

Unifying and streamlining the management of your organization’s multicloud starts with diagnosing the health of your multicloud infrastructure with Microsoft Entra Permissions Management, which will help you discover, detect, right-size, and govern your organization’s multicloud identities. Then, using Microsoft Entra Workload ID, migrate your workload identities to managed identities where possible and apply strong Zero Trust principles and conditional access controls to them.

How to get started: Start a Microsoft Entra Permissions Management free trial to assess the state of your organization’s multicloud environment, then take the recommended actions to remediate any access right risks. Also, use Microsoft Entra Workload ID to assign conditional access policies to all of your apps, services, and machine identities based on least privilege principles.

Our commitment to continued partnership with you

It is our hope that the strategies in this blog help you form an actionable roadmap for securing access at your organization—for everyone, to everything.

But access security is not a one-way street, it is your continuous feedback that enables us to provide truly customer-centric solutions to the identity and access problems we face in 2024 and beyond.  We are grateful for the continued partnership and dialogue with you—from day-to-day interactions, to joint deployment planning, to the direct feedback that informs our strategy. As always, we remain committed to building the products and tools you need to defend your organization throughout 2024 and beyond.

Learn more about Microsoft Entra, or recap the identity at Microsoft Ignite blog.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report, Microsoft. October 2023. 

²Work Trend Index Annual Report: Will AI Fix Work? Microsoft. May 9, 2023.

³Microsoft unveils expansion of AI for security and security for AI at Microsoft Ignite, Vasu Jakkal. November 15, 2023.

⁴How effective is multifactor authentication at deterring cyberattacks? Microsoft.

⁵2023 State of Cloud Permissions Risks report now published, Alex Simons. March 28, 2023.

The post 5 ways to secure identity and access for 2024 appeared first on Microsoft Security Blog.

In attacks observed by Microsoft Threat Intelligence, threat actors launched phishing or password spraying attacks to compromise user accounts that did not have strong authentication mechanisms and had permissions to create or modify OAuth applications. The threat actors misused the OAuth applications with high privilege permissions to deploy virtual machines (VMs) for cryptocurrency mining, establish persistence following business email compromise (BEC), and launch spamming activity using the targeted organization’s resources and domain name.

Microsoft continuously tracks attacks that misuse of OAuth applications for a wide range of malicious activity. This visibility enhances the detection of malicious OAuth applications via Microsoft Defender for Cloud Apps and prevents compromised user accounts from accessing resources via Microsoft Defender XDR and Microsoft Entra Identity Protection. In this blog post, we present cases where threat actors compromised user accounts and misused OAuth applications for their financially driven attacks, outline recommendations for organizations to mitigate such attacks, and provide detailed information on how Microsoft detects related activity:

• OAuth applications to deploy VMs for cryptomining
• OAuth applications for BEC and phishing
• OAuth applications for spamming activity
• Mitigation steps
• Detections for related techniques
• Hunting guidance

OAuth applications to deploy VMs for cryptomining

Microsoft observed the threat actor tracked as Storm-1283 using a compromised user account to create an OAuth application and deploy VMs for cryptomining. The compromised account allowed Storm-1283 to sign in via virtual private network (VPN), create a new single-tenant OAuth application in Microsoft Entra ID named similarly as the Microsoft Entra ID tenant domain name, and add a set of secrets to the application. As the compromised account had an ownership role on an Azure subscription, the actor also granted ‘Contributor’ role permission for the application to one of the active subscriptions using the compromised account.

The actor also leveraged existing line-of-business (LOB) OAuth applications that the compromised user account had access to in the tenant by adding an additional set of credentials to those applications. The actor initially deployed a small set of VMs in the same compromised subscriptions using one of the existing applications and initiated the cryptomining activity. The actor then later returned to deploy more VMs using the new application. Targeted organizations incurred compute fees ranging from 10,000 to 1.5 million USD from the attacks, depending on the actor’s activity and duration of the attack.

Storm-1283 looked to maintain the setup as long as possible to increase the chance of successful cryptomining activity. We assess that, for this reason, the actor used the naming convention [DOMAINNAME]_[ZONENAME]_[1-9] (the tenant name followed by the region name) for the VMs to avoid suspicion.  

One of the ways to recognize the behavior of this actor is to monitor VM creation in Azure Resource Manager audit logs and look for the activity “Microsoft.Compute/virtualMachines/write” performed by an OAuth application. While the naming convention used by the actor may change in time, it may still include the domain name or region names like “east|west|south|north|central|japan|france|australia|canada|korea|uk|poland|brazil”

Microsoft Threat Intelligence analysts were able to detect the threat actor’s actions and worked with the Microsoft Entra team to block the OAuth applications that were part of this attack. Affected organizations were also informed of the activity and recommended further actions.

OAuth applications for BEC and phishing

In another attack observed by Microsoft, a threat actor compromised user accounts and created OAuth applications to maintain persistence and to launch email phishing activity. The threat actor used an adversary-in-the-middle (AiTM) phishing kit to send a significant number of emails with varying subject lines and URLs to target user accounts in multiple organizations. In AiTM attacks, threat actors attempt to steal session tokens from their targets by sending phishing emails with a malicious URL that leads to a proxy server that facilitates a genuine authentication process.

We observed the following email subjects used in the phishing emails:

• <Username> shared “<Username> contracts” with you.
• <Username> shared “<User domain>” with you.
• OneDrive: You have received a new document today
• <Username> Mailbox password expiry
• Mailbox password expiry
• <Username> You have Encrypted message
• Encrypted message received

After the targets clicked the malicious URL in the email, they were redirected to the Microsoft sign-in page that was proxied by the threat actor’s proxy server. The proxy server set up by the threat actor allowed them to steal the token from the user’s session cookie. Later, the stolen token was leveraged to perform session cookie replay activity. Microsoft was able to confirm during further investigation that the compromised user account was flagged for risky sign-ins when the account was used to sign in from an unfamiliar location and from an uncommon user agent.

For persistence following business email compromise

In some cases, following the stolen session cookie replay activity, the actor leveraged the compromised user account to perform BEC financial fraud reconnaissance by opening email attachments in Microsoft Outlook Web Application (OWA) that contain specific keywords such as “payment” and “invoice”. This action typically precedes financial fraud attacks where the threat actor seeks out financial conversations and attempts to socially engineer one party to modify payment information to an account under attacker control.

Later, to maintain persistence and carry out malicious actions, the threat actor created an OAuth application using the compromised user account. The actor then operated under the compromised user account session to add new credentials to the OAuth application.  

For email phishing activity

In other cases, instead of performing BEC reconnaissance, the threat actor created multitenant OAuth applications following the stolen session cookie replay activity. The threat actor used the OAuth applications to maintain persistence, add new credentials, and then access Microsoft Graph API resource to read emails or send phishing emails.

At the time of analysis, we observed that threat actor created around 17,000 multitenant OAuth applications across different tenants using multiple compromised user accounts. The created applications mostly had two different sets of application metadata properties, such as display name and scope:

• Malicious multitenant OAuth applications with the display name set as “oauth” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.read; people.read” and access to Microsoft Graph API and read emails.
• Malicious multitenant OAuth applications with the display name set as “App” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.send” and access to Microsoft Graph API to send high volumes of phishing emails to both intra-organizational and external organizations.

In addition, we observed that the threat actor, before using the OAuth applications to send phishing emails, leveraged the compromised user accounts to create inbox rules with suspicious rule names like “…” to move emails to the junk folder and mark them as read. This is to evade detection by the compromised user that the account was used to send phishing emails.

Based on the email telemetry, we observed that the malicious OAuth applications created by the threat actor sent more than 927,000 phishing emails. Microsoft has taken down all the malicious OAuth applications found related to this campaign, which ran from July to November 2023.

OAuth applications for spamming activity

Microsoft also observed large-scale spamming activity through OAuth applications by a threat actor tracked as Storm-1286. The actor launched password spraying attacks to compromise user accounts, the majority of which did not have multifactor authentication (MFA) enabled. We also observed the user agent BAV2ROPC in the sign-in activities related to the compromised accounts, which indicated the use of legacy authentication protocols such as IMAP and SMTP that do not support MFA.

We observed the actor using the compromised user accounts to create anywhere from one to three new OAuth applications in the targeted organization using Azure PowerShell or a Swagger Codegen-based client. The threat actor then granted consent to the applications using the compromised accounts. These applications were set with permissions like email, profile, openid, Mail.Send, User.Read and Mail.Read, which allowed the actor to control the mailbox and send thousands of emails a day using the compromised user account and the organization domain. In some cases, the actor waited for months after the initial access and setting up of OAuth applications before starting the spam activity using the applications. The actor also used legitimate domains to avoid phishing and spamming detectors.

In previous large-scale spam activities, we observed threat actors attempting to compromise admin accounts without MFA and create new LOB applications with high administrative permissions to abuse Microsoft Exchange Online and spread spam. While the activity of the actor then was limited due to actions taken by Microsoft Threat Intelligence such as blocking clusters of the OAuth applications in the past, Storm-1286 continues to try new ways to set a similar high-scale spamming platform in victim organizations by using non-privileged users.

Mitigation steps

Microsoft recommends the following mitigations to reduce the impact of these types of threats.

Mitigate credential guessing attacks risks

A key step in reducing the attack surface is securing the identity infrastructure. The most common initial access vector observed in this attack was account compromise through credential stuffing, phishing, and reverse proxy (AiTM) phishing. In most cases the compromised accounts did not have MFA enabled. Implementing security practices that strengthen account credentials such as enabling MFA reduced the chance of attack dramatically.

Enable conditional access policies

Conditional access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies for User and Sign-in Risk, device compliance and trusted IP address requirements. If your organization has a Microsoft-Managed Conditional Access policy, make sure it is enforced.

Ensure continuous access evaluation is enabled

Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Enable security defaults

While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.

Enable Microsoft Defender automatic attack disruption

Microsoft Defender automatic attack disruption capabilities minimize lateral movement and curbs the overall impact of an attack in its initial stages.

Audit apps and consented permissions

Audit apps and consented permissions in your organization ensure applications are only accessing necessary data and adhering to the principles of least privilege. Use Microsoft Defender for Cloud Apps and its app governance add-on for expanded visibility into cloud activity in your organization and control over applications that access your Microsoft 365 data. 

Educate your organization on application permissions and data accessible by applications with respective permissions to identify malicious apps. 

Enhance suspicious OAuth application investigation with the recommended approach to investigate and remediate risky OAuth apps.

Enable “Review admin consent requests” for forcing new applications review in the tenant.

In addition to the recommendations above, Microsoft has published incident response playbooks for App consent grant investigation and compromised and malicious applications investigation that defenders can use to respond quickly to related threats.

Secure Azure Cloud resources

Deploy MFA to all users, especially for tenant administrators and accounts with Azure VM Contributor privileges. Limit unused quota and monitor for unusual quota increases in your Azure subscriptions, with an emphasis on the resource’s originating creation or modification. Monitor for unexpected sign-in activity from IP addresses associated with free VPN services on high privilege accounts. Connect Microsoft Defender for Cloud Apps connector to ARM or use Microsoft Defender for ARM

With the rise of hybrid work, employees might use their personal or unmanaged devices to access corporate resources, leading to an increased possibility of token theft. To mitigate this risk, organizations can enhance their security measures by obtaining complete visibility into their users’ authentication methods and locations. Refer to the comprehensive blog post Token tactics: How to prevent, detect, and respond to cloud token theft. 

Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links upon time of click and delete sent mail in response to newly acquired threat intelligence. Turn on Safe Attachments policies to check attachments in inbound emails. 

Detections for related techniques

Leveraging its cross-signal capabilities, Microsoft Defender XDR alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, Microsoft Defender for Cloud, and Microsoft Entra ID Protection to detect the techniques covered in the attack through the attack chain. Each product can provide a different aspect for protection to cover the techniques observed in this attack:

Microsoft Defender XDR

Microsoft Defender XDR detects threat components associated with the following activities:

• User compromised in AiTM phishing attack
• User compromised via a known AiTM phishing kit
• BEC financial fraud-related reconnaissance
• BEC financial fraud

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors for Microsoft 365 and Azure, Microsoft Defender XDR raises the following alerts:

• Stolen session cookie was used
• Activity from anonymous IP address
• Activity from a password-spray associated IP address
• User added or updated a suspicious OAuth app
• Risky user created or updated an app that was observed creating a bulk of Azure virtual machines in a short interval
• Risky user updated an app that accessed email and performed email activity through Graph API
• Suspicious creation of OAuth app by compromised user
• Suspicious secret addition to OAuth app followed by creation of Azure virtual machines
• Suspicious OAuth app creation
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app-related activity by compromised user
• Suspicious user signed into a newly created OAuth app
• Suspicious addition of OAuth app permissions
• Suspicious inbox manipulation rule
• Impossible travel activity
• Multiple failed login attempts

App governance

App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Online administrative activities along with other threat detection alerts. Activity related to this campaign triggers the following alerts:

• Entra Line-of-Business app initiating an anomalous spike in virtual machine creation
• OAuth app with high scope privileges in Microsoft Graph was observed initiating virtual machine creation
• Suspicious OAuth app used to send numerous emails

To receive this alert, turn on app governance for Microsoft Defender for Cloud Apps.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• User restricted from sending email
• Email sending limit exceeded

Microsoft Defender for Cloud

Microsoft Defender for Cloud detects threat components associated with the activities outlined in this article with the following alerts:

• Azure Resource Manager operation from suspicious proxy IP address
• Crypto-mining activity
• Digital currency mining activity
• Suspicious Azure role assignment detected
• Suspicious creation of compute resources detected
• Suspicious invocation of a high-risk ‘Execution’ operation by a service principal detected
• Suspicious invocation of a high-risk ‘Execution’ operation detected
• Suspicious invocation of a high-risk ‘Impact’ operation by a service principal detected

Microsoft Entra Identity Protection

Microsoft Entra Identity Protection detects the threats described with the following alerts:

• Anomalous Token
• Unfamiliar sign-in properties
• Anonymous IP address
• Verified threat actor IP
• Atypical travel

Hunting guidance

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following query to find related activity in their networks:

OAuth application interacting with Azure workloads

let OAuthAppId = <OAuth app ID in question>;
CloudAppEvents
| where Timestamp >ago (7d)  
| where AccountId == OAuthAppId 
| where AccountType== "Application"
| extend Azure_Workloads = RawEventData["operationName"]
| distinct Azure_Workloads by AccountId

Password spray attempts

This query identifies failed sign-in attempts to Microsoft Exchange Online from multiple IP addresses and locations.

IdentityLogonEvents
| where Timestamp > ago(3d)
| where ActionType == "LogonFailed" and LogonType == "OAuth2:Token" and Application == "Microsoft Exchange Online"
| summarize count(), dcount(IPAddress), dcount(CountryCode) by AccountObjectId, AccountDisplayName, bin(Timestamp, 1h)

Suspicious application creation

This query finds new applications added in your tenant.

CloudAppEvents
| where ActionType in ("Add application.", "Add service principal.")
| mvexpand modifiedProperties = RawEventData.ModifiedProperties
| where modifiedProperties.Name == "AppAddress"
| extend AppAddress = tolower(extract('\"Address\": \"(.*)\",',1,tostring(modifiedProperties.NewValue)))
| mvexpand ExtendedProperties = RawEventData.ExtendedProperties
| where ExtendedProperties.Name == "additionalDetails"
| extend OAuthApplicationId = tolower(extract('\"AppId\":\"(.*)\"',1,tostring(ExtendedProperties.Value)))
| project Timestamp, ReportId, AccountObjectId, Application, ApplicationId, OAuthApplicationId, AppAddress

Suspicious email events

NOTE: These queries need to be updated with timestamps related to application creation time before running.

//Identify High Outbound Email Sender
EmailEvents 
| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId)
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| sort by UniqueEmailSentCount desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender sent more than the threshold
//| take 100 //Optional, return only top 100
 
//Identify Suspicious Outbound Email Sender
EmailEvents 
//| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId, 
    DetectionMethods,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId),
    SuspiciousEmailCount = dcountif(NetworkMessageId,isnotempty(DetectionMethods))
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| extend SuspiciousEmailPercentage = SuspiciousEmailCount/UniqueEmailSentCount * 100 //Calculate the percentage of suspicious email compared to all email sent
| sort by SuspiciousEmailPercentage desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender suspicious email percentage is more than the threshold
//| take 100 //Optional, return only top 100

//Identify Recent Emails Sent by Restricted Email Sender
AlertEvidence
| where Title has "User restricted from sending email"
| project AccountObjectId //Identify the user who are restricted to send email
| join EmailEvents on $left.AccountObjectId == $right.SenderObjectId //Join information from Alert Evidence and Email Events
| project
    Timestamp,
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    SenderIPv4,
    Subject,
    UrlCount,
    AttachmentCount,
    DetectionMethods,
    AuthenticationDetails, 
    NetworkMessageId
| sort by Timestamp desc 
//| take 100 //Optional, return only first 100

BEC recon and OAuth application activity

//High and Medium risk SignIn activity
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode==0
| where RiskLevelDuringSignIn >= 50
| project
    AccountUpn,
    AccountObjectId,
    SessionId,
    RiskLevelDuringSignIn,
    ApplicationId,
    Application

//Oauth Application creation or modification by user who has suspicious sign in activities
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode == 0
| where RiskLevelDuringSignIn >= 50
| project SignInTime=AccountUpn, AccountObjectId, SessionId, RiskLevelDuringSignIn, ApplicationId, Application
| join kind=leftouter (CloudAppEvents | where Timestamp > ago(7d)
| where ActionType in ("Add application.", "Update application.", "Update application – Certificates and secrets management ")
| extend appId = tostring(parse_json(RawEventData.Target[4].ID))
| project
    Timestamp,
    ActionType,
    Application,
    ApplicationId,
    UserAgent,
    ISP,
    AccountObjectId,
    AppName=ObjectName,
    OauthApplicationId=appId,
    RawEventData ) on AccountObjectId
| where isnotempty(ActionType)

 
//Suspicious BEC reconnaisance activity 
let bec_keywords = pack_array("payment", "receipt", "invoice", "inventory"); 
let reconEvents = 
    CloudAppEvents
    | where Timestamp >ago (7d)
    | where ActionType in ("MailItemsAccessed", "Update")
    | where AccountObjectId in ("<Impacted AccountObjectId>")
    | extend SessionId = tostring(parse_json(RawEventData.SessionId))
    | project
        Timestamp,
        ActionType,
        AccountObjectId,
        UserAgent,
        ISP,
        IPAddress,
        SessionId,
        RawEventData;
reconEvents;
let updateActions = reconEvents
    | where ActionType == "Update" 
    | extend Subject=tostring(RawEventData["Item"].Subject)
    | where isnotempty(Subject)
    | where Subject has_any (bec_keywords)
    | summarize UpdateCount=count() by bin (Timestamp, 15m), Subject, AccountObjectId, SessionId, IPAddress;
updateActions;
let mailItemsAccessedActions = reconEvents 
    | where ActionType == "MailItemsAccessed" 
    | extend OperationCount = toint(RawEventData["OperationCount"])
    | summarize TotalCount = sum(OperationCount) by bin (Timestamp, 15m), AccountObjectId, SessionId, IPAddress;
mailItemsAccessedActions;
 
//SignIn to newly created app within Risky Session
AADSignInEventsBeta
| where Timestamp >ago (7d) 
| where AccountObjectId in ("<Impacted AccountObjectId>") and 
SessionId in ("<Risky Session Id>")
| where ApplicationId in ("<Oauth appId>") // Recently added or modified App Id
| project
    AccountUpn,
    AccountObjectId,
    ApplicationId,
    Application,
    SessionId,
    RiskLevelDuringSignIn,
    RiskLevelAggregated,
    Country

// To check suspicious Mailbox rules
CloudAppEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours, usually before spam emails sent
| where AccountObjectId in ("<Impacted AccountObjectId>")
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox", "Set-TransportRule", "New-TransportRule", "Enable-InboxRule", "UpdateInboxRules")
| where isnotempty(IPAddress)
| mvexpand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
| project Timestamp, ReportId, ActionType, AccountObjectId, IPAddress, ISP, RuleName

// To check any suspicious Url clicks from emails before risky signin by the user
UrlClickEvents
| where Timestamp between (start .. end) //Timestamp around time proximity of Risky signin by user
| where AccountUpn has "<Impacted User’s UPN or Email address>" and ActionType has "ClickAllowed"
| project Timestamp,Url,NetworkMessageId

// To fetch the suspicious email details
EmailEvents
| where Timestamp between (start .. end) //Timestamp lookback to be increased gradually to find the email received
| where EmailDirection has "Inbound"
| where RecipientEmailAddress has "<Impacted User’s UPN or Email address>" and NetworkMessageId == "<NetworkMessageId from UrlClickEvents>"
| project SenderFromAddress,SenderMailFromAddress,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount
    
    
// To check if suspicious emails sent for spamming (with similar email subjects, urls etc.)
EmailEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours upto 24 hours or more
| where EmailDirection in ("Outbound","Intra-org")
| where SenderFromAddress has "<Impacted User’s UPN or Email address>"  or SenderMailFromAddress has "<Impacted User’s UPN or Email address>"
| project RecipientEmailAddress,RecipientObjectId,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount,NetworkMessageId

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Analytic rules:

• Phishing Link Execution Observed
• Possible AiTM Phishing Attempt Against AAD
• Successful Signins from a Phishing Link
• Signin Password Spray
• Malicious Inbox Rule
• BEC Mailbox Rule

Hunting queries:

• Open Email Link
• Creation of an anomalous number of resources
• Creation of expensive computes in Azure

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Threat actors misuse OAuth applications to automate financially driven attacks appeared first on Microsoft Security Blog.

We’ve designed these policies based on our deep knowledge of the current cyberthreat landscape to help our customers strengthen their security baseline, and we’ll adapt them over time to keep the security bar high. These policies are part of a broader initiative to strengthen security, which includes key engineering advances.

This blog post explains why we decided to create these policies, how they work, how they differ from security defaults, and what Microsoft Entra customers can expect as we roll them out.

Microsoft Entra Conditional Access

Increase protection without compromising productivity.

Try for free

Buckle up, we’re going for a ride. I have a great security story to share—about multifactor authentication, seat belts, radical ideas, and the pit of success.

Ten years ago, in 2013, we had just started the identity security team and had a radical idea: We changed the policy in our Microsoft account ecosystem (the consumer identity system behind things like Outlook.com, Skype, Xbox, and OneDrive) to require multifactor authentication factors for every single account. Today, 100 percent of consumer Microsoft accounts older than 60 days have multifactor authentication—and it’s been this way for 10 years. We give accounts 60 days to meet this policy requirement, then we block sign-ins until the user adds a strong authentication factor.

This move caused a huge stir. Many of the teams within Microsoft that relied on consumer identity were convinced multifactor authentication would add too much friction. They feared users would hate it. Pundits predicted catastrophe, but by virtually all metrics, the multifactor authentication requirement was a smashing success. Because we could safely challenge suspicious sign-ins, Microsoft account hacking plummeted by more than 80 percent, and good user recovery increased from 57 percent to 81 percent when accounts were hacked.

Securing an email or phone number to use as a multifactor authentication factor raised costs for fraudsters enough that synthetic account creation plummeted by 99 percent. Before we enacted this policy, users who forgot their passwords recovered their accounts at a rate of only 16 percent. Under the new policy, unaided password recovery jumped to more than 90 percent. And the policy didn’t drive customers away. In fact, the multifactor authentication policy had such a positive effect on integrity, security, and recoverability that customer retention improved by more than 5 percent. Good security reduces friction.

When Microsoft account joined forces with the team responsible for Microsoft Entra ID (formerly Azure Active Directory) late in 2014, we sought to replicate the success of this consumer-focused program. But we found the going much harder in the commercial space because we weren’t in control of account policies—customers were. Not only did identity admins fear user friction the way we had, but they were also grappling with budget constraints and talent shortages, as well as security and technical backlogs (none of this has gotten easier!). If we wanted to help our enterprise customers adopt multifactor authentication, we’d need to do more.

We tried all kinds of promotional campaigns. We offered the same kind of risk-based multifactor authentication challenges we used to protect our consumer users in a commercial product, Microsoft Entra ID Protection (formerly Azure AD Identity Protection). Disappointingly, these efforts barely moved the needle. When Nitika Gupta (Principal Group Product Manager, Microsoft) and I presented monthly multifactor authentication usage rates at Microsoft Ignite in 2017, it was just 0.7 percent of monthly active users. And we calculated this metric with lenience, counting users who carry a multifactor authentication claim from any source—on-premises federation, third-party providers, or Microsoft Entra multifactor authentication.

To make progress, we needed another radical idea, so in 2018, we made multifactor authentication available at no additional cost for all customers at all license levels. Even trial accounts included multifactor authentication. Over the next year—now that price wasn’t a barrier—multifactor authentication adoption rates only increased to 1.8 percent. At this rate, unless something changed, we wouldn’t reach 100 percent adoption for another 50 years. It was time to get even more radical.

So, in 2019, we came up with “security defaults,” which provides on-by-default multifactor authentication, and applied it to all new tenants. More than 80 percent of new tenants leave security defaults turned on, protecting tens of millions of users. Combining this uptick with pandemic-driven changes in work increased our multifactor authentication utilization to more than 25 percent. We were getting somewhere.

Our next move, starting in 2022, was to extend security defaults to existing tenants, often simpler, smaller customers, who haven’t touched their security settings. We’ve approached this carefully to minimize customer disruption. We’re still rolling out the program, but it has already protected tens of millions more users. More than 94 percent of existing tenants we’ve rolled security defaults out to have kept them enabled.

In just the past year, we’ve turned on security defaults for almost seven million new and existing tenants. These tenants experience 80 percent fewer compromises than tenants without security defaults. Today, security defaults drive more than half of today’s multifactor authentication usage in Microsoft Entra ID, and we’ve driven overall multifactor authentication utilization up to just over 37 percent.

But our goal is 100 percent multifactor authentication. Given that formal studies show multifactor authentication reduces the risk of account takeover by over 99 percent, every user who authenticates should do so with modern strong authentication.¹ In a world where digital identity protects virtually every digital and physical assets and makes virtually all online experiences possible—and in a year when we’ve blocked more than 4,000 password attacks per second—we need to do more to drive multifactor authentication adoption. And so now, we’re kicking off the next radical idea.

Auto-rollout of Conditional Access policies

In the early 1960’s, if you wanted seat belts in your car, you could certainly have them. You just had to go to the store, buy some webbing and a buckle, figure out where to drill holes, and install the backing plates. Unsurprisingly, virtually no one did that. After 1965, when all manufacturers were required to install seat belts in all models, traffic injuries plummeted. And now, your car owes its safety rating in part to the annoying ding-ding-ding of the dashboard should you forget to buckle up. This approach—of making a secure posture easy to get into and hard to get out of—is sometimes called the “pit of success.”

Similarly, in the early days of cloud identity, if you wanted multifactor authentication for your accounts, you could certainly have it. You just had to pick a vendor, deploy the multifactor authentication service, configure it, and convince all your users to use it. Unsurprisingly, virtually no one did that. But when we applied the “pit of success” philosophy for consumer accounts in 2013 with multifactor authentication on by default, and for enterprise accounts in 2019 with security defaults, account compromise plummeted as multifactor authentication usage went up. And we’re incredibly excited about the next step in the journey: the automatic roll-out of Microsoft-managed Conditional Access policies.

Today, many customers use security defaults, but many others need more granular control than security defaults offer. Customers may not be in a position to disable legacy authentication for certain accounts (a requirement for security defaults), or they may need to make exceptions for certain automation cases. Conditional Access does a great job here, but often customers aren’t sure where to start. They’ve told us they want a clear policy recommendation that’s easy to deploy but still customizable to their specific needs. And that’s exactly what we’re providing with Microsoft-managed Conditional Access policies.

Microsoft-managed Conditional Access policies provide clear, self-deploying guidance. Customers can tune the policies (or disable them altogether), so even the largest, most sophisticated organizations can benefit from them. Over time, we’ll offer policies tailored to specific organizations, but we’re starting simple.

Because enabling multifactor authentication remains our top recommendation for improving your identity secure posture, our first three policies are multifactor authentication-related, as summarized in the table below:

Pay lots of attention to the first policy. It’s our strong recommendation—and a policy we’ll deploy your behalf—that multifactor authentication protect all user access to admin portals such as https://portal.azure.com, Microsoft 365 admin center, and Exchange admin center. Please note that while you can opt out of these policies, teams at Microsoft will increasingly require multifactor authentication for specific interactions, as they already do for certain Azure subscription management scenarios, Partner Center, and Microsoft Intune device enrollment.

You can view the policies and their impact using the new policy view user experience, which includes a policy summary, alerts, recommended actions, and a policy impact summary. You can also monitor them using sign-in and audit logs. You can customize the policies by excluding users, groups, or roles that you want to be exceptions, such as emergency and break glass accounts. If you require more extensive customizations, you can clone a policy and then make as many changes as you want.

We’ll begin a gradual rollout of these policies to all eligible tenants starting next week. We’ll notify you in advance, of course. Once the policies are visible in your tenant, you’ll have 90 days to review and customize (or disable) them before we turn them on. For those 90 days, the policies will be in report-only mode, which means Conditional Access will log the policy results without enforcing them.

The Conditional Access policies you need, based on the latest cyberthreat information

As with security defaults, we’ve carefully considered the managed policies we’re rolling out automatically. We want the experience to feel like consulting directly with Microsoft’s identity security team, as though we examined your environment and said, based on everything we’ve learned from securing thousands of customers, “These are the policies you need.”

What’s more, we’ll keep improving the policies over time. Our eventual goal is to combine machine learning-based policy insights and recommendations with automated policy rollout to strengthen your security posture on your behalf with the right controls. In other words, as the cyberthreat landscape evolves, we’d not only recommend policy changes based on the trillions of signals we process every day, but we’d also safely apply them for you ahead of bad actors.

Not only will the seat belts already be in your car, but we’ll also help you fasten them to keep everyone safer. That way, you can keep your eyes on the road ahead.

Learn more

Learn more about Microsoft Entra Conditional Access.

The auto-rollout of Conditional Access policies is just one initiative we’re taking to strengthen your security. Learn about engineering advances we’re making in a recent memo to all Microsoft engineers from Charlie Bell, Executive Vice President, Microsoft Security.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and  X (formerly known as “Twitter”) (@MSFTSecurity) for the latest news and updates on cybersecurity.

All statistics listed throughout this blog are based on Microsoft internal data.

¹How effective is multifactor authentication at deterring cyberattacks? Microsoft.

The post Automatic Conditional Access policies in Microsoft Entra streamline identity protection appeared first on Microsoft Security Blog.

Protecting identities and access is critical. As our work and lives become increasingly digital, cyberattacks are becoming more frequent and more sophisticated, affecting organizations of every size, in every industry, and in every part of the world. In the last 12 months, we saw an average of more than 4,000 password attacks per second, an almost threefold increase from the 1,287 attacks per second we saw the previous year.² We’re also seeing far more sophisticated attacks, including ones that manage to evade critical defenses, such as multifactor authentication, to steal access tokens, impersonate a rightful user, and gain access to critical data.

To help organizations protect their ever-evolving digital estates, we’ve been expanding beyond managing directories and authenticating users to securing and governing access for any identity to any app or resource. Today, we’re thrilled to announce the next milestone in our vision of making it easy to secure access with two new products: Microsoft Entra Internet Access and Microsoft Entra Private Access. We’re adding these capabilities to help organizations instill trust, not only in their digital experiences and services but in every digital interaction that powers them.

Secure access to any app or resource, from anywhere

Flexible work arrangements and the resulting increase in cloud workloads are straining traditional corporate networks and legacy network security approaches. Using VPNs to backhaul traffic to the legacy network security stack weakens security posture and damages the user experience while using siloed solutions and access policies leaves security gaps.

Microsoft Entra Internet Access is an identity-centric Secure Web Gateway that protects access to internet, software as a service (SaaS), and Microsoft 365 apps and resources. It extends Conditional Access policies with network conditions to protect against malicious internet traffic and other threats from the open internet. For Microsoft 365 environments, it enables best-in-class security and visibility, along with faster and more seamless access to Microsoft 365 apps, so you can boost productivity for any user, anywhere. Microsoft 365 scenarios in Microsoft Entra Internet Access are in preview today, and you can sign up for the preview of capabilities for all internet traffic and SaaS apps and resources that will be available later this year.

Microsoft Entra Private Access is an identity-centric Zero Trust Network Access that secures access to private apps and resources. Now any user, wherever they are, can quickly and easily connect to private apps—across hybrid and multicloud environments, private networks, and data centers—from any device and any network. Now in preview, Microsoft Entra Private Access reduces operational complexity and cost by replacing legacy VPNs and offers more granular security. You can apply Conditional Access to individual applications, and enforce multifactor authentication, device compliance, and other controls to any legacy application without changing those applications.

Together, Internet Access and Private Access, coupled with Microsoft Defender for Cloud Apps, our SaaS security-focused cloud access security broker, comprise Microsoft’s Security Service Edge (SSE) solution. We’ll continue to evolve our SSE solution as an open platform that delivers the flexibility of choice between solutions from Microsoft and our partners. Pricing for Microsoft Entra Internet Access and Microsoft Entra Private Access will be available when those products reach general availability.

Figure 1. Microsoft’s Security Service Edge (SSE) solution.

Neither identity nor network security alone can protect the breadth of access points and scenarios that modern organizations require. That’s why, as cyberattacks get more sophisticated, we’re adding identity-centric network access to our cloud identity solutions. We’re converging controls for identity and network access so you can create unified Conditional Access policies that extend all protections and governance to all identities and resources. With a single place to safeguard and verify identities, manage permissions, and enforce intelligent access policies, protecting your digital estate has never been easier.

Microsoft Azure Active Directory is becoming Microsoft Entra ID

When we introduced Microsoft Entra in May of 2022, it included three products: Microsoft Azure Active Directory (Azure AD), Microsoft Entra Permissions Management, and Microsoft Entra Verified ID.¹ We later expanded the Microsoft Entra family with Microsoft Entra ID Governance and Microsoft Entra Workload ID.³ Today, Microsoft Entra protects any identity and secures access to any resource—on-premises, across clouds, and anywhere in between—with a product family that unifies multicloud identity and network access solutions.

To simplify our product naming and unify our product family, we’re changing the name of Azure AD to Microsoft Entra ID. Capabilities and licensing plans, sign-in URLs, and APIs remain unchanged, and all existing deployments, configurations, and integrations will continue to work as before. Starting today, you’ll see notifications in the administrator portal, on our websites, in documentation, and in other places where you may interact with Azure AD. We’ll complete the name change from Azure AD to Microsoft Entra ID by the end of 2023. No action is needed from you.

Figure 2. With the name change to Microsoft Entra ID, the standalone license names are changing. Azure AD Free becomes Microsoft Entra ID Free. Azure AD Premium P1 becomes Microsoft Entra ID P1. Azure AD Premium P2 becomes Microsoft Entra ID P2. And our product for customer identities, Azure AD External Identities, becomes Microsoft Entra External ID. SKU and service plan name changes take effect on October 1, 2023.

More innovations in Microsoft Entra

Today we’d also like to highlight other innovations in the Microsoft Entra portfolio that strengthen defenses against attackers who are becoming more adept at exploiting identity-related vulnerabilities such as weak credentials, misconfigurations, and excessive access permissions.

Prevent identity takeover in real time

Several exciting changes to Microsoft Entra ID Protection (currently Azure AD Identity Protection) help IT and identity practitioners prevent account compromise. Instead of reactively revoking access based on stale data, ID Protection uses the power of advanced machine learning to identify sign-in anomalies and anomalous user behavior and then block, challenge, or limit access in real time. For example, it may trigger a risk-based Conditional Access policy that requires high-assurance and phishing-resistant authentication methods for accessing sensitive resources.

A new dashboard demonstrates the impact of the identity protections that organizations deploy with a comprehensive snapshot of prevented identity attacks and the most common attack patterns. On the dashboard, you can view simple metric cards and attack graphs that show risk origins, security posture over time, types of current attacks, as well as recommendations based on risk exposure, while highlighting the business impact of enforced controls. With these insights, you can further investigate your organization’s security posture in additional tools and applications for enhanced recommendations.

Figure 3. New Microsoft Entra ID Protection dashboard.

Automate access governance

An important part of securing access for any identity to any app is ensuring that only the right identities have the right access at the right time. Some organizations only realize they need to take this approach when they fail a security audit. Microsoft Entra ID Governance, now generally available, is a complete identity governance solution that helps you comply with organizational and regulatory security requirements while increasing employee productivity through real-time, self-service, and workflow-based app entitlements.⁴

ID Governance automates the employee identity lifecycle to reduce manual work for IT and provides machine learning-based insights about identities and app entitlements. Because it’s cloud-delivered, it scales to complex cloud and hybrid environments, unlike traditional on-premises identity governance point solutions. It supports cloud and on-premises apps from any provider, as well as custom-built apps hosted in the public cloud or on-premises. Our global system integrator partners—including Edgile, a Wipro company, EY, KPMG, and PwC—started helping with the planning and deployment of ID Governance on July 1, 2023.

Figure 4. New Microsoft Entra ID Governance dashboard.

Personalize and secure access to any application for customers and partners

As we announced at Microsoft Build 2023, new developer-centric capabilities in Microsoft Entra External ID are now in preview. External ID is an integrated identity solution for external users, including customers, patients, citizens, guests, partners, and suppliers. It offers rich customization options, Conditional Access, identity protection, and support for social identity providers. Using our comprehensive developer tools, even those developers who have little to no identity experience can create personalized sign-in and sign-up experiences for their applications within minutes.

Simplify identity verification with Microsoft Entra Verified ID

Since we announced the general availability of Microsoft Entra Verified ID last summer, organizations around the world have been reinventing business processes, such as new employee onboarding, around this new, simpler way of verifying someone’s identity.⁵ For example, we recently announced that millions of LinkedIn members will be able to verify their place of work using a Verified ID credential.⁶ At the 2023 Microsoft Build event, we launched the Microsoft Entra Verified ID SDK so that developers can quickly add a secure digital wallet to any mobile application. The app can then store and verify a wide range of digital ID cards.

Microsoft Entra: Secure access for a connected world

You can see our expanded Microsoft Entra product family in Figure 5. Visit the Microsoft Entra website to learn more.

Figure 5. The Microsoft Entra family of identity and network access products.

We’re committed to building a more secure world for all and making life harder for threat actors, easier for admins, and more secure for every user. As part of that commitment, we’ll keep expanding Microsoft Entra to provide the broadest possible coverage along with a flexible and agile model where people, organizations, apps, and even smart things can confidently make real-time access decisions.

Encourage your technical teams to dive deeper into these announcements by attending the Tech Accelerator event on July 20, 2023, on the Microsoft Tech Community.

Microsoft Entra

Meet the family of multicloud identity and access products.

Learn more

Learn more

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and Twitter (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Secure access for a connected world—meet Microsoft Entra, Joy Chik and Vasu Jakkal. May 31, 2022.

²Microsoft internal data.

³Do more with less—Discover the latest Microsoft Entra innovations, Joy Chik. October 19, 2022.

⁴Microsoft Entra ID Governance is generally available, Joseph Dadzie. June 7, 2023.

⁵Microsoft Entra Verified ID now generally available, Ankur Patel. August 8, 2022.

⁶LinkedIn and Microsoft Entra introduce a new way to verify your workplace, Joy Chik. April 12, 2023.

The post Microsoft Entra expands into Security Service Edge and Azure AD becomes Microsoft Entra ID appeared first on Microsoft Security Blog.