The US Department of Labor (DOL) has been on a journey to consolidate their identity systems and modernize authentication to applications. In this blog post, I’ll describe the benefits they’re gaining from supplementing personal identity verification (PIV) cards with device-bound passkeys implemented through the Microsoft Authenticator app and from adding risk signals to Microsoft Entra Conditional Access policies.

To review how Microsoft Entra ID can help your department or agency meet federal cybersecurity requirements, while reducing complexity and improving the user experience, visit Microsoft Entra ID: Enhancing identity security for US agencies.

Adopting Microsoft Entra ID as a centralized identity system

Like many organizations, DOL first used Entra ID (then called Azure Active Directory) when they adopted Microsoft 365. At that time, they were maintaining multiple identity technologies, including on-premises Active Directory, Active Directory Federation Services, and Ping Federate. This fragmented strategy required users to authenticate to different applications using different identity systems.

With the help of their Identity, Credential, and Access Management (ICAM) group, DOL worked to consolidate all their identity systems to Entra ID. They chose Entra ID because it supports the necessary protocols (such as SAML and OIDC) to deliver a single sign-on (SSO) experience for most of their applications. This effort, which took about a year, included reaching out to application owners and encouraging them to move their applications off of Kerberos, ideally by adopting MSAL (Microsoft Authentication Library), so their applications could easily integrate with Entra ID.

Integrating applications with Entra ID makes it possible to strengthen security by applying Conditional Access policies to them. DOL at first applied simple Conditional Access policies that only allowed access to applications from hybrid-joined Government Furnished Equipment (GFE devices). The COVID-19 pandemic accelerated their adoption of additional features, such as enforcing device compliance through Microsoft Intune and reporting device risk to other security services through integration with Microsoft Defender for Endpoint. Policies could then make access decisions based on device risk, such as only granting access to applications from devices with “low risk” or “no risk.”

For an introduction to Microsoft Entra Conditional Access, visit our documentation.

Upleveling static Conditional Access policies to risk-based Conditional Access policies

In 2022, when new regulations required government agencies to apply more stringent cybersecurity standards to protect against sophisticated online attacks, DOL decided to strengthen their Zero Trust implementation with phishing-resistant authentication and dynamic risk-based Conditional Access policies. Both would help them enforce the Zero Trust principle of least privilege access.

Microsoft Entra ID Protection capabilities made it possible for Conditional Access policies to assess sign-in risk and user risk, in addition to device risk, before granting access. Policies would tolerate different levels of user risk depending on whether the user signs in as a ‘privileged user’ or as a ‘regular user.’ Access for users deemed high-risk would always be blocked. Privileged users with low or medium risk would also be blocked. Regular users with low risk would have to reauthenticate within a set period of time, while users with medium risk would have to reauthenticate more frequently.

For more in-depth information on risk-based Conditional Access policies, visit our documentation.

Adding a layer of security for privileged users

A subset of DOL employees may operate as a ‘privileged user’ for some tasks and as a ‘regular user’ for others. To access less sensitive applications such as Microsoft 365, these employees sign in as a ‘regular user’ using a government-issued PIV card or Windows Hello for Business from their GFE device. To access highly sensitive applications and resources, or to execute sensitive tasks, they must sign in using a separate account that has privileged access rights.

Previously, the DOL assigned usernames, passwords, and basic multifactor authentication to privileged accounts, but this still left some risk of credential theft from phishing attacks. Since the most important accounts to secure are those with administrative rights, DOL chose to make privileged accounts more secure with phishing-resistant authentication, specifically, with device-bound passkeys in the Microsoft Authenticator app. This is faster and less expensive to support than issuing employees users a second PIV card and a second GFE device.

Privileged users only need to install the Microsoft Authenticator app on their government-issued cell phone. They don’t have to visit a special portal to provision and onboard their passkey. They simply sign in for the first time on their mobile phone using a Temporary Access Pass and set up their passkey in one fast, frictionless workflow. As an added benefit, passkeys also reduce the time to authenticate to DOL applications. According to Microsoft testing, signing in with a passkey is eight times faster than using a password and traditional multifactor authentication.¹

After DOL finishes deploying passkeys for their privileged users, they plan to roll out passkeys to the rest of their workforce as a secondary authentication method that complements other passwordless methods such as Windows Hello for Business and certificate-based authentication (CBA).

To explore phishing-resistant authentication methods available with Microsoft Entra, explore the video series Phishing-resistant authentication in Microsoft Entra ID.

Using “report-only” mode in Conditional Access as a modeling tool

Every organization that modernizes their identity strategy and authentication methods, as DOL did, strengthens security, improves flexibility, and reduces costs. Using a modern, deeply integrated security toolset will also provide valuable new insights. For example, you can use Conditional Access as a modeling and planning tool. By running policies in report-only mode, you can better understand your environment, investigate user behavior to uncover risk scenarios not visible to the human eye, and model solutions for those scenarios. This helps you decide which controls to apply to close any security gaps you discover.

DOL rolled out risk-based Conditional Access policies, in report-only mode, that enforce the use of passkeys by privileged users. In the activity reports, they observed employees signing in with their privileged accounts, then visiting portals that they should access as regular users, not as admins. DOL then adjusted their policies to block such behavior.

Running risk-based policies in report-only mode exposed behavior that DOL could then use policies to control. It also helped them to uncover inconsistencies and redundancies that reflected unaddressed technical debt; for example, policies that collided. Their goal is to consolidate and simplify their static policies into fewer, more comprehensive risk-based policies that block dangerous or unauthorized behavior while allowing employees to sign in faster and more securely to get their work done.

To learn more about Conditional Access report-only mode, visit our documentation.

Looking ahead

So far, DOL has integrated more than 200 applications with Entra ID for SSO. The team is still in the monitoring phase as they work to consolidate Conditional Access policies and ensure compliance with security requirements, such as the use of passkeys for accessing high-value assets. Not only are they reducing the number of policies they must maintain, but their logs are also cleaner, and it’s easier to find insights.

DOL’s future plans include implementing attestation, which will ensure that employees use a genuine version of the Authenticator app published by Microsoft before registering a passkey. They’re also investigating joining devices to Entra ID so they can centrally manage them from the cloud for easier deployment of updates, policies, and applications. This will also allow them to use policy to enforce enrollment in Windows Hello for Business, further advancing their transition to phishing-resistant authentication.

Learn more

Learn more about Microsoft Entra ID.

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.

¹Convincing a billion users to love passkeys: UX design insights from Microsoft to boost adoption and security, Sangeeta Ranjit and Scott Bingham. December 12, 2024.

The post US Department of Labor’s journey to Zero Trust security with Microsoft Entra ID appeared first on Microsoft Security Blog.

UPDATE (February 14, 2025): Within the past 24 hours, Microsoft has observed Storm-2372 shifting to using the specific client ID for Microsoft Authentication Broker in the device code sign-in flow. More details below.

Executive summary:

Today we’re sharing that Microsoft discovered cyberattacks being launched by a group we call Storm-2372, who we assess with moderate confidence aligns with Russia’s interests and tradecraft. The attacks appear to have been ongoing since August 2024 and have targeted governments, NGOs, and a wide range of industries in multiple regions. The attacks use a specific phishing technique called “device code phishing” that tricks users to log into productivity apps while Storm-2372 actors capture the information from the log in (tokens) that they can use to then access compromised accounts. These tokens are part of an industry standard and, while these phishing lures used Microsoft and other apps to trick users, they do not reflect an attack unique to Microsoft nor have we found any vulnerabilities in our code base enabling this activity.

Microsoft Threat Intelligence Center discovered an active and successful device code phishing campaign by a threat actor we track as Storm-2372. Our ongoing investigation indicates that this campaign has been active since August 2024 with the actor creating lures that resemble messaging app experiences including WhatsApp, Signal, and Microsoft Teams. Storm-2372’s targets during this time have included government, non-governmental organizations (NGOs), information technology (IT) services and technology, defense, telecommunications, health, higher education, and energy/oil and gas in Europe, North America, Africa, and the Middle East. Microsoft assesses with moderate confidence that Storm-2372 aligns with Russian interests, victimology, and tradecraft.  

In device code phishing, threat actors exploit the device code authentication flow to capture authentication tokens, which they then use to access target accounts, and further gain access to data and other services that the compromised account has access to. This technique could enable persistent access as long as the tokens remain valid, making this attack technique attractive to threat actors.

The phishing attack identified in this blog masquerades as Microsoft Teams meeting invitations delivered through email. When targets click the meeting invitation, they are prompted to authenticate using a threat actor-generated device code. The actor then receives the valid access token from the user interaction, stealing the authenticated session.

Because of the active threat represented by Storm-2372 and other threat actors exploiting device code phishing techniques, we are sharing our latest research, detections, and mitigation guidance on this campaign to raise awareness of the observed tactics, techniques, and procedures (TTPs), educate organizations on how to harden their attack surfaces, and disrupt future operations by this threat actor. Microsoft uses Storm designations as a temporary name given to an unknown, emerging, or developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the threat actor behind the activity.

Microsoft Threat Intelligence Center continues to track campaigns launched by Storm-2372, and, when able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. Microsoft is also tracking other groups using similar techniques, including those documented by Volexity in their recent publication.

How does device code phishing work?

A device code authentication flow is a numeric or alphanumeric code used to authenticate an account from an input-constrained device that does not have the ability to perform an interactive authentication using a web flow and thus must perform this authentication on another device to sign-in. In device code phishing, threat actors exploit the device code authentication flow.

During the attack, the threat actor generates a legitimate device code request and tricks the target into entering it into a legitimate sign-in page. This grants the actor access and enables them to capture the authentication—access and refresh—tokens that are generated, then use those tokens to access the target’s accounts and data. The actor can also use these phished authentication tokens to gain access to other services where the user has permissions, such as email or cloud storage, without needing a password. The threat actor continues to have access so long as the tokens remain valid. The attacker can then use the valid access token to move laterally within the environment.

Storm-2372 phishing lure and access

Storm-2372’s device code phishing campaign has been active since August 2024. Observed early activity indicates that Storm-2372 likely targeted potential victims using third-party messaging services including WhatsApp, Signal, and Microsoft Teams, falsely posing as a prominent person relevant to the target to develop rapport before sending subsequent invitations to online events or meetings via phishing emails.

The invitations lure the user into completing a device code authentication request emulating the experience of the messaging service, which provides Storm-2372 initial access to victim accounts and enables Graph API data collection activities, such as email harvesting.

On the device code authentication page, the user is tricked into entering the code that the threat actor included as the ID for the fake Teams meeting invitation.

Post-compromise activity

Once the victim uses the device code to authenticate, the threat actor receives the valid access token. The threat actor then uses this valid session to move laterally within the newly compromised network by sending additional phishing messages containing links for device code authentication to other users through intra-organizational emails originating from the victim’s account.

Additionally, Microsoft observed Storm-2372 using Microsoft Graph to search through messages of the account they’ve compromised. The threat actor was using keyword searching to view messages containing words such as username, password, admin, teamviewer, anydesk, credentials, secret, ministry, and gov. Microsoft then observed email exfiltration via Microsoft Graph of the emails found from these searches.

February 14, 2025 update:

Within the past 24 hours, Microsoft has observed Storm-2372 shifting to using the specific client ID for Microsoft Authentication Broker in the device code sign-in flow. Using this client ID enables Storm-2372 to receive a refresh token that can be used to request another token for the device registration service, and then register an actor-controlled device within Entra ID. With the same refresh token and the new device identity, Storm-2372 is able to obtain a Primary Refresh Token (PRT) and access an organization’s resources. We have observed Storm-2372 using the connected device to collect emails.

The actor has also been observed to use proxies that are regionally appropriate for the targets, likely in an attempt to further conceal the suspicious sign in activity.

While many of the mitigations and queries listed below still apply in this scenario, alerts involving anomalous token or PRT activity surrounding close-in-time device registrations may also be a useful method for identifying this shift in technique. Additionally, enrollment restrictions – limiting the user permissions that can enroll devices into your Microsoft Entra ID environment – can also help to address this attack behavior.

Attribution

The actor that Microsoft tracks as Storm-2372 is a suspected nation-state actor working toward Russian state interests. It notably has used device code phishing to compromise targets of interest. Storm-2372 likely initially approaches targets through third-party messaging services, posing as a prominent individual relevant to the target to develop rapport before sending invites to online events or meetings. These invites lure the user into device code authentication that grants initial access to Storm-2372 and enables Graph API data collection activities such as email harvesting.

Storm-2372 targets include government, NGOs, IT services and technology, defense, telecommunications, health, higher education, and energy/oil and gas in Europe, North America, Africa, and the Middle East.

Mitigation and protection guidance

To harden networks against the Storm-2372 activity described above, defenders can implement the following:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins.
• If suspected Storm-2372 or other device code phishing activity is identified, revoke the user’s refresh tokens by calling revokeSignInSessions. Consider setting a Conditional Access Policy to force re-authentication for users.
• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 

The following best practices further help improve organizational defenses against phishing and other credential theft attacks:

• Require multifactor authentication (MFA). While certain attacks such as device code phishing attempt to evade MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop attackers.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects malicious activity associated with this threat through the following alerts:

• This email has traits consistent with phishing
• This HTML has traits consistent with phishing

Microsoft Entra ID Protection

The following Microsoft Entra ID Protection risk detections inform Entra ID user risk events and can indicate associated threat activity, including unusual user activity consistent with known attack patterns identified by Microsoft Threat Intelligence research:

• Activity from Anonymous IP address (RiskEventType: anonymizedIPAddress)
• Microsoft Entra threat intelligence (sign-in): (RiskEventType: investigationsThreatIntelligence)

Hunting queries

Microsoft Defender XDR

The following query can help identify possible device code phishing attempts:

let suspiciousUserClicks = materialize(UrlClickEvents
    | where ActionType in ("ClickAllowed", "UrlScanInProgress", "UrlErrorPage") or IsClickedThrough != "0"
    | where UrlChain has_any ("microsoft.com/devicelogin", "login.microsoftonline.com/common/oauth2/deviceauth")
    | extend AccountUpn = tolower(AccountUpn)
    | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
//Check for Risky Sign-In in the short time window
let interestedUsersUpn = suspiciousUserClicks
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
let suspiciousSignIns = materialize(AADSignInEventsBeta
    | where ErrorCode == 0
    | where AccountUpn in~ (interestedUsersUpn)
    | where RiskLevelDuringSignIn in (10, 50, 100)
    | extend AccountUpn = tolower(AccountUpn)
    | join kind=inner suspiciousUserClicks on AccountUpn
    | where (Timestamp - ClickTime) between (-2min .. 7min)
    | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignIn, SessionId, IPAddress, Url
);
//Validate errorCode 50199 followed by success in 5 minute time interval for the interested user, which suggests a pause to input the code from the phishing email
let interestedSessionUsers = suspiciousSignIns
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
let shortIntervalSignInAttemptUsers = materialize(AADSignInEventsBeta
    | where AccountUpn in~ (interestedSessionUsers)
    | where ErrorCode in (0, 50199)
    | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId
    | where ErrorCodes has_all (0, 50199)
    | distinct AccountUpn);
suspiciousSignIns
| where AccountUpn in (shortIntervalSignInAttemptUsers)

This following query from public research surfaces newly registered devices, and can be a useful in conjunction with anomalous or suspicious user or token activity:

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend ApplicationId_ = tostring(ActivityObjects[0].ApplicationId)
| extend ServiceName_ = tostring(ActivityObjects[0].Name)
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend DeviceId = tostring(parse_json(tostring(parse_json(tostring(RawEventData.ModifiedProperties))[6].NewValue))[0])
| extend DeviceObjectId_ = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[0].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, ServiceName_, DeviceName, DeviceId, DeviceObjectId_, UserPrincipalName

Microsoft Sentinel

Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. While these queries are not specific to threat actors, they can help you stay vigilant and safeguard your organization from phishing attacks:

• Campaign with suspicious keywords
• Determine Successfully Delivered Phishing Emails to Inbox/Junk folder.
• Successful Signin from Phishing Link
• Phishing link click observed in Network Traffic
• Suspicious URL clicked Anomaly of MailItemAccess by GraphAPI
• OAuth Apps accessing user mail via GraphAPI
• OAuth Apps reading mail both via GraphAPI and directly
• OAuth Apps reading mail via GraphAPI anomaly

References

• https://www.blackhillsinfosec.com/dynamic-device-code-phishing/
• https://www.huntress.com/blog/oh-auth-2-0-device-code-phishing-in-google-cloud-and-azure
• https://github.com/secureworks/family-of-client-ids-research?tab=readme-ov-file#which-client-applications-are-compatible-with-each-other

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://x.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 Storm-2372 conducts device code phishing campaign appeared first on Microsoft Security Blog.

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.