Beginning September 1, 2026, Microsoft will begin rolling out passkeys as the default authentication experience in Microsoft Entra ID. As the rollout reaches each organization, users enabled for SMS or voice authentication will automatically be enabled for passkeys, and the next time they perform multifactor authentication, they’ll be prompted to register a passkey.

Following this transition, on February 1, 2027, Microsoft will retire Microsoft-provided telecom delivery for SMS and voice authentication and will no longer offer SMS and voice as a native Microsoft Entra capability. Organizations that still require SMS or voice authentication methods will have the option to choose one of our telecom partners through the Microsoft Security Store. Customers will be responsible for any associated telecom-related costs charged by the telecom partners.

We strongly recommend moving users to passkeys or another phishing-resistant authentication method as soon as possible.

Why stronger authentication matters in the AI era

Authentication methods that use SMS or voice rely on shared secrets or channels that attackers increasingly intercept, phish, or manipulate. Passkeys use public-key cryptography rather than shared secrets, making them phishing-resistant by design. They also provide a faster, simpler sign-in experience for users.

The case for moving beyond SMS and voice is no longer just that attackers intercept or socially engineer these methods. The threat environment has changed in speed, scale, and sophistication. Microsoft Threat Intelligence has observed AI-enabled phishing campaigns reaching click-through rates as high as 54%, compared with roughly 12% for more traditional campaigns, making stolen passwords and phishable second factors an urgent risk.¹ At the same time, tactics such as SIM swapping and multifactor authentication bypass have become more accessible and repeatable.

An AI-powered cyberattack can use a compromised identity to automate discovery, privilege escalation, and lateral movement much faster than a human attacker working manually. This is why phishing-resistant authentication methods are so important.

By making passkeys the default authentication experience, organizations reduce reliance on phishable authentication methods and strengthen protection against credential theft and phishing.

Still need SMS or voice? Select a telecom provider in Microsoft Security Store 

Today, Microsoft provides the telecom delivery behind SMS and voice authentication natively within Entra ID. As part of this transition, we’ll step back from providing that native telecom delivery to encourage phishing-resistant methods as the standard for everyone.

For most organizations, the recommended path is simple: move users to passkeys at no additional cost.  

If you have a regulatory, technical, or business requirement to keep SMS or voice, you’ll be able to select, configure, and manage a third-party telecom provider through the Microsoft Security Store—a partner marketplace where you can contract directly with supported carriers. 

On September 18, 2026, we’ll share information on supported providers, deployment guidance, and technical documentation with pricing and commercial terms available through the Microsoft Security Store.

How to prepare

Start planning your transition now so you can select the deployment approach that best fits your organization and ensure your users are prepared for upcoming changes to their sign-in experience.

1. Identify users who still use SMS or voice. Review your authentication method policy and identify which users or groups are enabled for SMS or voice authentication.
2. Plan your passkey rollout. Enable passkeys and select the types that best fit your users’ devices and workflows. Microsoft Entra ID supports:
   • Synced passkeys, such as passkeys stored in platform credential managers like iCloud Keychain and Google Password Manager.
   • Device-bound passkeys, such as Microsoft Authenticator passkeys, Entra passkey on Windows, and FIDO2 security keys.
3. Use a registration campaign to drive adoption. Microsoft Entra ID can help organizations move users at scale by prompting them to register a passkey during multifactor authentication sign-in.
4. Prepare user communications. Tell affected users what’s changing, when they’ll see a passkey registration prompt, and how to complete registration on their device.

For step-by-step guidance on planning, deploying, and managing passkeys, see our Microsoft Learn documentation and passkey deployment guide. 

• aka.ms/passkeybydefault
• Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID

If regulated, technical, or operational scenarios still require SMS or voice:

1. Identify and document affected user segments.
2. Starting October 30, 2026, select and configure a supported telecom provider through the Microsoft Security Store.
3. Test your configuration with a pilot group before any broad rollout.

Timeline

Note: The dates outlined in this post apply to Microsoft Entra ID in the public cloud only. Support for other cloud environments will follow on a separate timeline, with additional guidance and dates to be announced in advance.

SMS and voice have served their purpose well, bringing multifactor authentication to billions of users who otherwise would have had none. But the threat environment has evolved beyond their capabilities, and we need to evolve with it.

We’re making passkeys the default in Entra ID because they work better for users and worse for cyberattackers. We’re trying to make this transition as predictable as possible with clear dates, fallback options during migration, and recovery that doesn’t depend on phishable credentials anymore.

Learn more at aka.ms/passkeybydefault 

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 2025.

The post Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID appeared first on Microsoft Security Blog.

At Microsoft we encompass these security requirements, along with threat knowledge and operational frameworks in our Secure Future Initiative (SFI), to guide what a well-defended cloud service looks like. But defining the requirements is only the start. Meeting them means continuously evaluating our live services against them, at AI speed.  

That is why Microsoft built a multi-agent AI system that proactively evaluates and hardens our cloud infrastructure—matching the speed, scale, depth, and quality needed for our unique hyper-scale production environments. This system is purpose-built to evaluate Microsoft’s own cloud services against our stringent security requirements and make our infrastructure harder to compromise. While this is an internal capability and not available as a customer-facing product or service, the insights and patterns we develop through this work will inform how we improve our products over time. This system complements existing tools in Microsoft’s security ecosystem. For example, this system incorporates code-level vulnerabilities, including from systems like codename MDASH and adds configuration, identity, network, and runtime context, to assess overall service security posture. 

A modern AI architecture for proactive defense 

Vulnerabilities don’t just live in code. They emerge from the interplay between how a service is built, configured, deployed, and connected. Consider a cloud service where the application code passes every security review, the identity configuration follows least-privilege policy, and the network rules restrict inbound traffic as designed. Individually, each component is compliant. The system evaluates the service as a whole and may find that a combination of a permissive service-to-service trust relationship, a token scope that grants broader access than the service requires, and a deployment configuration that exposes an internal API to an adjacent network tier creates a composite vulnerability that no single-component review would surface.

At its core, the system employs a multi-tier agent hierarchy: orchestration agents for workflow management, analysis agents that specialize in security reasoning and are grounded in Microsoft’s threat intelligence—including emerging patterns and threat actor activity—and evidence-gathering agents that investigate across code repositories, infrastructure definitions, identity configurations, runtime settings, network topologies, and live resource states.  

The result of this multi-stage analysis is a comprehensive security understanding of each service that goes beyond what any single analysis method can provide on its own. Compared to traditional human-led security reviews that take weeks, the system compresses the same depth of analysis into hours. 

How it works: The system follows a multi-stage analysis pipeline, where each stage builds on the one before it:

1. Profiles each service architecture to understand components, data flows, trust boundaries, risk exposure, and more. 
2. Enumerates applicable security controls based on SFI requirements across identity, network, tenant isolation, engineering systems, and detection domains. 
3. Verifies control implementations against real-world code, configurations, and cloud resources. 
4. Evaluates defense-in-depth coverage to help ensure layered protections exist across all control domains. 
5. Identifies where controls are missing, misconfigured, or brittle, and maps the compensating controls that determine whether a gap is exploitable in practice. 
6. Produces compensating controls and durable fix recommendations for immediate-risk reduction while driving lasting remediation. 
7. Continuously learns and improves by incorporating feedback from security reviewers and service teams, and by tapping into Microsoft’s evolving threat intelligence to adapt to new patterns. 

Core design principles  

The analysis pipeline is shaped by four principles that determine how the system reasons about security: 

1. Frontier-ready architecture

The system is built with modular model interfaces that can take advantage of new frontier capabilities as they emerge. New models, enhanced planning, and execution capabilities can be integrated behind stable agent interfaces—preserving existing tooling, orchestration, knowledge, pipelines, reporting, and governance.  

2. Compositional risk reasoning

The system uses “what-if” agentic ideation to reason compositionally about risk. It explicitly explores how individual security gaps can chain together into multi-step attack paths. For example, a minor misconfiguration in identity, combined with a seemingly unrelated network exposure, and a missing data encryption control, might together enable a serious breach. Modern attacks are often complex sequences rather than single bugs, and the system is designed to help identify and analyze them. By running diverse models and large-scale reasoning trials in parallel, the system explores an expansive space of scenarios that traditional static analysis or single-scan tools would miss. 

3. Service-specific adaptation

Cloud services aren’t one-size-fits-all, so security analysis shouldn’t be either. Rather than applying a fixed checklist, the system builds a service-specific understanding of each service it analyzes. It profiles the service in depth—identifying its components, mapping data flows, locating trust boundaries, and determining which security controls should apply given that service’s unique architecture and risk profile. If a service uses a novel pattern, a microservices architecture spanning multiple codebases, or an agent-to-agent communication model, the system adapts its analysis to account for those patterns. This adaptive approach, guided by current SFI requirements, means that the system can tackle emerging cloud paradigms that don’t fit traditional security checklists.

4. Defense-in-depth evaluation

A key focus area for SFI is layered defense. The system asks two questions: “What vulnerabilities exist?” and “Where does this service lack multiple lines of defense?”. It evaluates whether critical security domains have overlapping, robust controls, and it flags any missing or brittle layers—even if no immediate exploit is identified.

For example, the system will highlight a scenario where a service might have a weak network segmentation or an overly permissive admin role—even in the absence of a known attack—because those gaps mean a single failure could lead to a compromise.

This forward-looking, “assume breach” analysis embodies the Zero Trust and defense-in-depth principles reinforced by SFI. In an era when AI-assisted attackers can enumerate systems faster and chain together weaknesses more systematically, ensuring redundant safeguards is increasingly critical.  

The assurance tree: SFI in action 

At the core of the system are the SFI engineering and security principles: a structured body of security requirements shaped by years of hardening the Microsoft infrastructure. These requirements guide what the system evaluates, how it reasons about risk, and the recommendations generated. When security expectations evolve—whether to address a new class of threats or incorporate lessons from remediation—the system’s reasoning evolves with them. The assurance tree is how we express these requirements: a structured, hierarchical map of security controls that the system expects a service to have in place, tailored to that service’s usage and design.

As the system profiles a cloud service, it generates an assurance tree tailored to that service. At the top level of the tree are the fundamental security domains, that map to the SFI pillars. Each of these domains is recursively decomposed into more granular controls and sub-controls tailored to the service. For instance, Identity security decomposes into controls for password policies, OAuth token handling, and MFA enforcement—down to verifying that the service’s code correctly validates a JSON Web Token’s issuer and expiration. The assurance tree guides the system’s evidence-gathering agents to verify that thousands of expected controls are in place and effective—or to identify where something is missing. 

This approach turns security from an open-ended hunt into a systematic verification of the SFI requirements: the system is essentially asking, “Have all the security measures that should protect this service been properly implemented?”. Crucially, it goes further—considering how individual gaps might combine, helping to ensure that even combinations of missing controls are identified and addressed. 

Proven results: From theory to practice 

Within a few months, the system has enabled Microsoft security engineering teams to proactively harden our cloud services. It generates findings and recommendations which our security engineering teams then validate and implement. Because the system evaluates the whole service in context and reasons about the severity and exploitability of each issue before surfacing it, its findings have proven high quality and actionable: more than 90% have been confirmed as genuine security issues by our security engineers, enabling proactive action to improve security posture. Just as important as the volume and precision of findings is their nature. Many issues the system discovers are nuanced, cross-domain vulnerabilities that wouldn’t have been caught by traditional methods. For example, the system has uncovered security gaps that only become apparent when considering code, configuration, and cloud resources together—the kind of issue that isolated scans or compliance checklists could overlook.  

This capability allows us to enhance how we do security reviews. Traditionally, a deep security review of a complex service might span weeks of effort by multiple domain experts. The system can achieve a thorough review in a matter of hours—allowing teams to assess more services, more frequently.

The path forward: Applying these principles in your environment

If you are responsible for security at your organization, the key question is whether your defenses are keeping pace. AI models will continue to evolve. The organizations that are hardest to compromise will be the ones that have layered, verified controls already in place—not the ones that react fastest after something is found.

Based on what we have learned from building and operating this system, here are three principles any organization can apply now:

1. Go beyond code scanning to system-level discovery. The most consequential issues emerge not from a single bug, but from how factors including code, configuration, identity, and network interact in production. Collect rich signals across these domains and evaluate your services as composed systems, not isolated components. Prioritize composite attack paths over individual findings. 
2. Move beyond known vulnerability patterns to proactive defensive controls. Traditional scanning asks, “Is there a known bug here?” Proactive hardening asks, “Does this service have comprehensive controls and layered defenses?” Reason about not just vulnerabilities, but controls, and how defense-in-depth coverage can improve protection before a specific exploit is discovered. 
3. Integrate AI to drive proactive prevention at machine speed. The same AI capabilities that accelerate vulnerability discovery can be applied to continuously evaluate whether security controls are correctly implemented, layered effectively, and working as intended. Organizations that adopt AI-powered proactive evaluation will identify and close gaps faster than those relying solely on periodic manual review. 

For deeper guidance on implementing AI-powered defense for an AI-accelerated threat landscape, customers can review Secure Now guidance for AI‑powered security and proactive defense. Any customer with a Microsoft Entra ID can access it. Microsoft Security customers will also have access to capabilities that enable them to assess their exposure and take action. 

Moving forward, we will share more about how we are scaling our response operations to match machine speed and how SFI’s engineering practices are evolving for this new reality.

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. 

The post Protecting Microsoft at AI speed: How SFI proactively hardens our cloud   appeared first on Microsoft Security Blog.

There are more than 500 million monthly active players¹ across Xbox consoles, PC, handheld, and more through Xbox cloud gaming. They’re the folks who come to mind when people refer to “gaming culture.” But they’re not really the whole story. Globally, more than 3 billion people engage with gaming.² The majority of these people are gamers, but the number also includes developers working for independent gaming studios, engineers supporting the Xbox platform, and the security and operations professionals that support them all.

In my role as Deputy CISO for Gaming at Microsoft, it’s this much larger, much more complex community that I have to take into account. My team and I aren’t tasked solely with protecting consoles or player accounts. We’re safeguarding intellectual property (IP), live operations, and the trust of billions of interactions. We’re also partnering on risks that range from cheating and monetization exploits to supply chain vulnerabilities and regulatory compliance for child safety and privacy.

Gaming isn’t really a single culture, but rather a culture of cultures—each with their own risk factors to account for. At the heart of gaming is the player experience—their need for seamless access, low latency, and frictionless, immersive experiences. This goes hand-in-hand with privacy and safety in a world where cyberattackers could target well-known players. But aside from those basic needs, players form their own tribes, and a diverse, global player base requires a different approach—which makes securing gaming unique. You don’t approach it like you might traditional enterprise. Studios operate with creative autonomy, platforms demand global scale and low latency, and players expect frictionless experiences. That diversity makes gaming vibrant while also creating unique security challenges.

Each culture comes with its own security risks

Let’s first take a look at the risks that most often appear with each of the overlapping cultures that make up the world of gaming:

Platforms, underpinning services like Xbox Game Pass and Xbox Cloud Gaming, require centralized infrastructure with high availability. Here, security must integrate seamlessly with identity systems and Microsoft-wide standards without slowing down gameplay. But platforms face a number of distinct risks.

The complexity of platforms makes them a rich target for financially-motivated cyberattackers seeking to take over top accounts—or send targeted messages to individuals in an environment where they aren’t expecting phishing, which can threaten both ecosystem trust and commercial strategy. And because platforms serve as the connective tissue between devices, we have to pay special attention to weaknesses in integration points.

We also contend with fraud and abuse in commerce systems, where bad actors attempt to manipulate in-game economies or exploit payment flows. These persistent cyberthreats require layered defenses, real-time monitoring, and rapid responses.

Game development studios, whether they are AAA giants, indie teams, or sole developers, thrive on flexibility. Their environments are highly individualized and frequently blend proprietary tools with third-party assets and co-development with partners. My job is to make sure they can innovate securely—balancing their creative freedom with governance and compliance timelines. But this flexibility introduces risks that look very different from experienced by centralized platforms.

On the plus side, studios’ independence creates smaller failure domains, leaving them free to make their own choices and experiment with new tools, partners and engineering practices, without putting the broader platform and peer studios at risk. But reputation, regulatory liability, and cyberattacker interest can’t be firewalled off so easily. So, we need to establish a baseline of controls and detect anomalies early, closing down blind spots—despite fragmented development environments and third-party risk from studios that rely on external contractors, middleware providers, and asset marketplaces.

And some of the cyberattacks are the same: Without tight identity governance, credential sprawl can create highly-privileged accounts that become prime targets for threat actors. Studios operate under tight deadlines and with small margins, so we need empathy for their desire to make things easier—and to avoid security checks when under milestone pressure—despite the risk those actions could cause to production.

It’s also important to note that the driving factor for many threat actors targeting studios is the incredibly high value of unreleased IP. For the same reason, social engineering and insider threats are a constant risk for studios.

Studio Central Teams provide shared IT and infrastructure support. They’re the bridge between creative teams and operational security, ensuring that artists, producers, and marketers work in environments that are both productive and resilient. But that role comes with its own set of risks, which are often hidden in the complexity of shared services.

When central teams support diverse projects, maintaining consistent security baselines across cloud resources, build servers, and collaboration tools becomes difficult. Failing to maintain security consistency can lead to configuration drift—where a single misconfigured storage bucket or firewall rule can expose critical assets. But because central teams manage shared infrastructure, they are risk-averse to changes, including some critical security patches, that could cause cascading production failures.

These central teams can be security’s best partners for implementing strong monitoring and segmentation—but also need to be governed to avoid insider risk and toxic combinations of overlapping permissions.

Collaboration over control

Security in gaming isn’t about imposing rules. It’s more about partnership. I work closely with Temi Adabambo, General Manager for Gaming Security, Microsoft, and Eric Mourinho, Chief Architect, Microsoft, to co-develop secure environments and shared tooling. Governance is a dialogue. We collaborate between platform teams, studio IT, security architects, and technical directors in game studios. That’s how we manage exception handling, cross-team dependencies, and the tension between creative speed and security rigor.

One of the advantages of the Microsoft environment is the access it grants us to a security ecosystem that scales globally. In gaming, we build upon that foundation, adapting it for the unique needs of developers, platforms, and players:

• Identity and access management: We use Microsoft Entra ID to secure identities across Xbox Live, Game Pass, and studio environments. Shared identity systems allow frictionless sign-in for players while enforcing strong authentication for developers and partners.
• Compliance and governance: We rely on a combination of tools and processes to manage sensitive data and meet regulatory obligations across environments like public cloud infrastructure and bespoke studio setups. This includes Microsoft Purview for data classification and compliance monitoring, Microsoft Defender for Cloud for policy enforcement and resource hardening, Entra ID for identity governance, and Microsoft Sentinel for audit and reporting. Together, these capabilities help us maintain visibility, enforce standards, and respond quickly to compliance exceptions without slowing down development.
• Threat intelligence and detection: With Microsoft Defender for Cloud, Microsoft Sentinel, and proprietary Microsoft tooling, we gain visibility into cyberthreats across platforms and supply chains. These tools allow us to detect anomalies, respond quickly, and share intelligence across teams without slowing down creative workflows.
• Secure development lifecycles: We embed security into game development through automated code scanning, vulnerability management, and secure build pipelines, helping studios ship faster without sacrificing safety.

These are enterprise-grade capabilities, adapted to the needs of the global gaming culture of cultures. They allow us to protect billions of interactions while enabling the creativity that defines this industry. 

Looking ahead 

Gaming will only grow more complex. But I see that as an opportunity. Security presents challenges, but in facing those challenges head-on, we are constantly refining our practices, products, and player experiences. When we design for resilience, we protect not just games but the communities that help them thrive.

For Microsoft, that means treating gaming security as an ever-evolving system—one that changes with each new iteration of technology, player expectations, and the creative heartbeat of the industry.

Security teams and their families are gamers too. Visit the Xbox Wire and our recent blog post for Safer Internet Day to learn more about how we keep players and communities safe and secure at Xbox.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

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 FY25 Fourth Quarter Earnings Conference Call  

²Microsoft to acquire Activision Blizzard to bring the joy and community of gaming to everyone, across every device 

The post Securing the gaming culture of cultures appeared first on Microsoft Security Blog.

Passwords remain a major source of risk; they’re difficult to manage and easy to steal. Along with weaker forms of multifactor authentication, they’re also highly vulnerable to phishing: AI-powered campaigns drive click-through rates as high as 54%.¹ In response, Microsoft is expanding passkey adoption across our ecosystem. We’re reducing reliance on legacy authentication and strengthening account recovery so it won’t become a backdoor for cyberattackers.

Passkey adoption continues to grow industry wide

Passkey adoption is accelerating: FIDO Alliance estimates 5 billion passkeys already in use worldwide.² Across Microsoft’s consumer services, including OneDrive, Xbox, and Copilot, hundreds of millions of users sign in with passkeys every day.

There are many reasons to choose passkeys as the standard authentication method over passwords. Sign-in success rates are significantly higher than with passwords, and exposure to credential-based attacks is significantly lower.³ Organizations and individual users alike prefer the simpler, more secure sign-in experience passkeys offer.⁴

Inside Microsoft, we’ve eliminated weaker authentication methods and rolled out phishing-resistant authentication, covering 99.6% of users and devices in our environment.⁵ It’s made signing in a lot simpler: no codes to enter, no extra prompts to manage, just a straightforward experience for everyone.

Product updates across sign-in and recovery

Across Microsoft, we’ve been steadily building passkey support into every layer of the identity experience from consumer accounts to enterprise access with Microsoft Entra, and from device-based authentication like Windows Hello to Microsoft’s password manager. This work ensures people can create and use passkeys wherever they sign in, with a consistent, phishing-resistant experience across devices, apps, and environments.

To make passkeys more accessible, we’re expanding where and how people can use them:

• Synced passkeys and passkey profiles in Microsoft Entra ID make it easier to scale passwordless sign-in across diverse environments. We’re expanding flexibility in cloud passkey management, including support for larger and more complex policies, and transitioning tenants to a unified passkey profile model.
• Entra passkeys on Windows make it simple for users to create and use device-bound passkeys directly on personal or unmanaged Windows devices using Windows Hello, and will be generally available in late May 2026.
• Passkeys for Microsoft Entra External ID will be generally available late May 2026, so your customer-facing applications can offer a more seamless, consumer-grade sign-in experience.
• Passkey-preferred authentication in Microsoft Entra ID (preview) detects registered methods and prompts the strongest one first. If a passkey is registered, that’s what the user sees—immediately. 
• On the consumer side, with Microsoft Password Manager, users can now save and sync passkeys across devices signed in with their Microsoft account, with support for iOS and Android rolling out soon through Microsoft Edge. 

Account recovery also plays a critical role in maintaining the integrity of identity systems. Historically, it’s been vulnerable to cyberattackers who try to hijack the recovery process, for example by impersonating legitimate users and requesting new credentials.

Microsoft Entra ID account recovery, generally available today, strengthens security for recovery flows by enabling users to regain access to their accounts through a robust identity verification process. Users can regain access after losing all authentication methods by using government-issued ID and biometric face checks. At general availability, we are expanding our identity verification ecosystem with two new partners—1Kosmos and CLEAR1—joining our existing partners Au10tix, IDEMIA, and TrueCredential. 

Removing phishable credentials from user accounts

Strengthening authentication is important, but reducing risk means eliminating phishable credentials entirely. Microsoft is continuing to phase out legacy methods and move users toward phishing-resistant authentication. Starting in January 2027, security questions will be removed as a password reset option in Microsoft Entra ID due to their susceptibility to guessing and social engineering.

The rationale is straightforward: improving strong methods while removing weak ones shrinks the attack surface. This is increasingly urgent as AI agents act on behalf of users. If an identity is compromised, cyberattackers can leverage those agents to access systems, execute workflows, and operate within existing permissions. Organizations need to address this risk quickly.

A more secure and usable future

Last year, Microsoft joined dozens of organizations in taking the Passkey Pledge, a commitment to accelerating the adoption of phishing-resistant authentication and to moving beyond passwords. Since then, we’ve seen meaningful progress, from hundreds of millions of better-protected consumer accounts to large-scale deployments across organizations like our own.

What once felt like a long-term shift is finally gaining real momentum: authentication is becoming simpler, safer, and passwordless.

For a more in-depth perspective on how cyberattackers try to bypass authentication through fallback methods and recovery flows—and how to address those gaps—read our companion post.

Getting started

Organizations that want to strengthen their identity security posture can enable passkeys for their users and extend policy protections across both sign-in and recovery scenarios.

Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

Individuals can create and use passkeys for their personal accounts for better security and convenience.

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 2025.

²FIDO Alliance reports mainstream global usage on World Passkey Day. FIDO Alliance, 2026.

³Synced passkeys and high assurance account recovery, Microsoft Entra blog. December 16, 2025.

⁴FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025, FIDO News Center. May 1, 2025.

⁵Microsoft Security and Future Initiative (SFI) Progress Report—November 2025.

The post World Passkey Day: Advancing passwordless authentication appeared first on Microsoft Security Blog.

AI has quickly become a powerful tool misused by threat actors, who use it to slip into the tiniest crack in your defenses. They use AI to automate and launch password attacks and phishing attempts at scale, craft emails that seem to come from people you know, manufacture voicemails and videos that impersonate people, join calls, request IT support, and reset passwords. They even use AI to rewrite AI agents on the fly as they compromise and traverse your network.

To stay ahead in the coming year, we recommend four priorities for identity security leaders:

1. Implement fast, adaptive, and relentless AI-powered protection.
2. Manage, govern, and protect AI and agents.
3. Extend Zero Trust principles everywhere with an integrated Access Fabric security solution.
4. Strengthen your identity and access foundation to start secure and stay secure.

Secure Access Webinar

Enhance your security strategy: Deep dive into how to unify identity and network access through practical Zero Trust measures in our comprehensive four-part series.

Sign up for the webinar

1. Implement fast, adaptive, and relentless AI-powered protection

2026 is the year to integrate AI agents into your workflows to reduce risk, accelerate decisions, and strengthen your defenses.

While security systems generate plenty of signals, the work of turning that data into clear next steps is still too manual and error-prone. Investigations, policy tuning, and response actions require stitching together an overwhelming volume of context from multiple tools, often under pressure. When cyberattackers are operating at the speed and scale of AI, human-only workflows constrain defenders.

That’s where generative AI and agentic AI come in. Instead of reacting to incidents after the fact, AI agents help your identity teams proactively design, refine, and govern access. Which policies should you create? How do you keep them current? Agents work alongside you to identify policy gaps, recommend smarter and more consistent controls, and continuously improve coverage without adding friction for your users. You can interact with these agents the same way you’d talk to a colleague. They can help you analyze sign-in patterns, existing policies, and identity posture to understand what policies you need, why they matter, and how to improve them.

In a recent study, identity admins using the Conditional Access Optimization Agent in Microsoft Entra completed Conditional Access tasks 43% faster and 48% more accurately across tested scenarios. These gains directly translate into a stronger identity security posture with fewer gaps for cyberattackers to exploit. Microsoft Entra also includes built-in AI agents for reasoning over users, apps, sign-ins, risks, and configurations in context. They can help you investigate anomalies, summarize risky behavior, review sign-in changes, remediate and investigate risks, and refine access policies.

The real advantage of AI-powered protection is speed, scale, and adaptability. Static, human-only workflows just can’t keep up with constantly evolving cyberattacks. Working side-by-side with AI agents, your teams can continuously assess posture, strengthen access controls, and respond to emerging risks before they turn into compromise.

2. Manage, govern, and protect AI and agents 

Another critical shift is to make every AI agent a first-class identity and govern it with the same rigor as human identities. This means inventorying agents, assigning clear ownership, governing what they can access, and applying consistent security standards across all identities.

Just as unsanctioned software as a service (SaaS) apps once created shadow IT and data leakage risks, organizations now face agent sprawl—an exploding number of AI systems that can access data, call external services, and act autonomously. While you want your employees to get the most out of these powerful and convenient productivity tools, you also want to protect them from new risks.

Fortunately, the same Zero Trust principles that apply to human employees apply to AI agents, and now you can use the same tools to manage both. You can also add more advanced controls: monitoring agent interaction with external services, enforcing guardrails around internet access, and preventing sensitive data from flowing into unauthorized AI or SaaS applications.

With Microsoft Entra Agent ID, you can register and manage agents using familiar Entra experiences. Each agent receives its own identity, which improves visibility and auditability across your security stack. Requiring a human sponsor to govern an agent’s identity and lifecycle helps prevent orphaned agents and preserves accountability as agents and teams evolve. You can even automate lifecycle actions to onboard and retire agents. With Conditional Access policies, you can block risky agents and set guardrails for least privilege and just in time access to resources.

To govern how employees use agents and to prevent misuse, you can turn to Microsoft Entra Internet Access, included in Microsoft Entra Suite. It’s now a secure web and AI gateway that works with Microsoft Defender to help you discover use of unsanctioned private apps, shadow IT, generative AI, and SaaS apps. It also protects against prompt injection attacks and prevents data exfiltration by integrating network filtering with Microsoft Purview classification policies.

When you have observability into everything that traverses your network, you can embrace AI confidently while ensuring that agents operate safely, responsibly, and in line with organizational policy.

3. Extend Zero Trust principles everywhere with an integrated Access Fabric security solution

There’s often a gap between what your identity system can see and what’s happening on the network. That’s why our next recommendation is to unify the identity and network access layers of your Zero Trust architecture, so they can share signals and reinforce each other’s strengths through a unified policy engine. This gives you deeper visibility into and finer control over every user session.

Today, enterprise organizations juggle an average of five different identity solutions and four different network access solutions, usually from multiple vendors.¹ Each solution enforces access differently with disconnected policies that limit visibility across identity and network layers. Cyberattackers are weaponizing AI to scale phishing campaigns and automate intrusions to exploit the seams between these siloed solutions, resulting in more breaches.²

An access security platform that integrates context from identity, network, and endpoints creates a dynamic safety net—an Access Fabric—that surrounds every digital interaction and helps keep organizational resources secure. An Access Fabric solution wraps every connection, session, and resource in consistent, intelligent access security, wherever work happens—in the cloud, on-premises, or at the edge. Because it reasons over context from identity, network, devices, agents, and other security tools, it determines access risk more accurately than an identity-only system. It continuously re‑evaluates trust across authentication and network layers, so it can enforce real‑time, risk‑based access decisions beyond first sign‑in.

Microsoft Entra delivers integrated access security across AI and SaaS apps, internet traffic, and private resources by bringing identity and network access controls together under a unified Zero Trust policy engine, Microsoft Entra Conditional Access. It continuously monitors user and network risk levels. If any of those risk levels change, it enforces policies that adapt in real time, so you can block access for users, apps, and even AI agents before they cause damage.

Your security teams can set policies in one central place and trust Entra to enforce them everywhere. The same adaptive controls protect human users, devices, and AI agents wherever they move, closing access security gaps while reducing the burden of managing multiple policies across multiple tools.

4. Strengthen your identity and access foundation to start secure and stay secure

To address modern cyberthreats, you need to start from a secure baseline—anchored in phishing‑resistant credentials and strong identity proofing—so only the right person can access your environment at every step of authentication and recovery.

A baseline security model sets minimum guardrails for identity, access, hardening, and monitoring. These guardrails include must-have controls, like those in security defaults, Microsoft-managed Conditional Access policies, or Baseline Security Mode in Microsoft 365. This approach includes moving away from easily compromised credentials like passwords and adopting passkeys to balance security with a fast, familiar sign-in experience. Equally important is high‑assurance account recovery and onboarding that combines a government‑issued ID with a biometric match to ensure that no bad actors or AI impersonators gain access.

Microsoft Entra makes it easy to implement these best practices. You can require phishing‑resistant credentials for any account accessing your environment and tailor passkey policies based on risk and regulatory needs. For example, admins or users in highly regulated industries can be required to use device‑bound passkeys such as physical security keys or Microsoft Authenticator, while other worker groups can use synced passkeys for a simpler experience and easier recovery. At a minimum, protect all admin accounts with phishing‑resistant credentials included in Microsoft Entra ID. You can even require new employees to set up a passkey before they can access anything. With Microsoft Entra Verified ID, you can add a live‑person check and validate government‑issued ID for both onboarding and account recovery.

Combining access control policies with device compliance, threat detection, and identity protection will further fortify your foundation. 

Support your identity and network access priorities with Microsoft

The plan for 2026 is straightforward: use AI to automate protection at speed and scale, protect the AI and agents your teams use to boost productivity, extend Zero Trust principles with an Access Fabric solution, and strengthen your identity security baseline. These measures will give your organization the resilience it needs to move fast without compromise. The threats will keep evolving—but you can tip the scales in your favor against increasingly sophisticated cyberattackers.

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.

¹Secure employee access in the age of AI report, Microsoft.

²Microsoft Digital Defense Report 2025.

The post Four priorities for AI-powered identity and network access security in 2026 appeared first on Microsoft Security Blog.

Phishing actors are exploiting complex routing scenarios and misconfigured spoof protections to effectively spoof organizations’ domains and deliver phishing emails that appear, superficially, to have been sent internally. Threat actors have leveraged this vector to deliver a wide variety of phishing messages related to various phishing-as-a-service (PhaaS) platforms such as Tycoon2FA. These include messages with lures themed around voicemails, shared documents, communications from human resources (HR) departments, password resets or expirations, and others, leading to credential phishing.

This attack vector is not new but has seen increased visibility and use since May 2025. The phishing campaigns Microsoft has observed using this attack vector are opportunistic rather than targeted in nature, with messages sent to a wide variety of organizations across several industries and verticals. Notably, Microsoft has also observed a campaign leveraging this vector to conduct financial scams against organizations. While these attacks share many characteristics with other credential phishing email campaigns, the attack vector abusing complex routing and improperly configured spoof protections distinguishes these campaigns. The phishing attack vector covered in this blog post does not affect customers whose Microsoft Exchange mail exchanger (MX) records point to Office 365; these tenants are protected by native built-in spoofing detections.

Phishing messages sent through this vector may be more effective as they appear to be internally sent messages. Successful credential compromise through phishing attacks may lead to data theft or business email compromise (BEC) attacks against the affected organization or partners and may require extensive remediation efforts, and/or lead to loss of funds in the case of financial scams. While Microsoft detects the majority of these phishing attack attempts, organizations can further reduce risk by properly configuring spoof protections and any third-party connectors to prevent spoofed phish or scam messages sent through this attack vector from reaching inboxes.

In this blog, we explain how threat actors are exploiting these routing scenarios and provide observations from related attacks. We provide specific examples—including technical analysis of phishing messages, spoof protections, and email headers—to help identify this attack vector. This blog also provides additional resources with information on how to set up mail flow rules, enforce spoof protections, and configure third-party connectors to prevent spoofed phishing messages from reaching user inboxes.

Spoofed phishing attacks

In cases where a tenant has configured a complex routing scenario, where the MX records are not pointed to Office 365, and the tenant has not configured strictly enforced spoof protections, threat actors may be able to send spoofed phishing messages that appear to have come from the tenant’s own domain. Setting strict Domain-based Message Authentication, Reporting, and Conformance (DMARC) reject and SPF hard fail (rather than soft fail) policies and properly configuring any third-party connectors will prevent phishing attacks spoofing organizations’ domains.

This vector is not, as has been publicly reported, a vulnerability of Direct Send, a mail flow method in Microsoft 365 Exchange Online that allows devices (like printers, scanners), applications, or third-party services to send email without authentication using the organization’s accepted domain, but rather takes advantage of complex routing scenarios and misconfigured spoof protections. Tenants with MX records pointed directly to Office 365 are not vulnerable to this attack vector of sending spoofed phishing messages.

As with most other phishing attacks observed by Microsoft Threat intelligence throughout 2025, the bulk of phishing campaigns observed using this attack vector employ the Tycoon2FA PhaaS platform, in addition to several other phishing services in use as well. In October 2025, Microsoft Defender for Office 365 blocked more than 13 million malicious emails linked to Tycoon2FA, including many attacks spoofing organizations’ domains. PhaaS platforms such as Tycoon2FA provide threat actors with a suite of capabilities, support, and ready-made lures and infrastructure to carry out phishing attacks and compromise credentials. These capabilities include adversary-in-the-middle (AiTM) phishing, which is intended to circumvent multifactor authentication (MFA) protections. Credential phishing attacks sent through this method employ a variety of themes such as voicemail notifications, password resets, HR communications, among others.

Microsoft Threat Intelligence has also observed emails intended to trick organizations into paying fake invoices, potentially leading to financial losses. Generally, in these spoofed phishing attacks, the recipient email address is used in both the “To” and “From” fields of the email, though some attacks will change the display name of the sender to make the attack more convincing and the “From” field could contain any valid internal email address.

Credential phishing with spoofed emails

The bulk of phishing messages sent through this attack vector uses the same lures as conventionally sent phishing messages, masquerading as services such as Docusign, or communications from HR regarding salary or benefits changes, password resets, and so on. They may employ clickable links in the email body or QR codes in attachments or other means of getting the recipient to navigate to a phish landing page. The appearance of having been sent from an internal email address is the most visible distinction to an end user, often with the same email address used in the “To” and “From” fields.

Email headers provide more information regarding the delivery of spoofed phishing emails, such as the appearance of an external IP address used by the threat actor to initiate the phishing attack. Depending on the configuration of the tenant, there will be SPF soft or hard fail, DMARC fail, and DKIM will equal none as both the sender and recipient appear to be in the same domain. At a basic level of protection, these should cause a message to land in a spam folder, but a user may retrieve and interact with phishing messages routed to spam. The X-MS-Exchange-Organization-InternalOrgSender will be set to True, but X-MS-Exchange-Organization-MessageDirectionality will be set to Incoming and X-MS-Exchange-Organization-ASDirectionalityType will have a value of “1”, indicating that the message was sent from outside of the organization. The combination of internal organization sender and incoming directionality is indicative of a message spoofed to appear as an internal communication, but not necessarily indicative of maliciousness. X-MS-Exchange-Organization-AuthAs will be set to Anonymous, indicating that the message came from an external source.

The Authentication-Results header example provided below illustrates the result of enforced authentication. 000 is an explicit DMARC failure. The resultant action is either reject or quarantine. The headers shown here are examples of properly configured environments, effectively blocking phishing emails sent through this attack vector:

spf=fail (sender IP is 51.89.59[.]188) smtp.mailfrom=contoso.com; dkim=none (message not signed) header.d=none;dmarc=fail action=quarantine header.from=contoso.com;compauth=fail reason=000

spf=fail (sender IP is 51.68.182[.]101) smtp.mailfrom= contoso.com; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=contoso.com;

Any third-party connectors—such as a spam filtering service, security solution, or archiving service—must be configured properly or spoof detections cannot be calculated correctly, allowing phishing emails such as the examples below to be delivered. The first of these examples indicate the expected authentication failures in the header, but no action is taken due to reason 905, which indicates that the tenant has set up complex routing where the mail exchanger record (MX record) points to either an on-premises Exchange environment or a third-party service before reaching Microsoft 365:

spf=fail (sender IP is 176.111.219[.]85) smtp.mailfrom= contoso.com; dkim=none (message not signed) header.d=none;dmarc=fail action=none header.from= contoso.com;compauth=none reason=905

The phishing message masquerades as a notification from Microsoft Office 365 informing the recipient that their password will soon expire, although the subject line appears to be intended for a voicemail themed lure. The link in the email is a nested Google Maps URL pointing to an actor-controlled domain at online.amphen0l-fci[.]com.

The second example also shows the expected authentication failures, but with an action of “oreject” with reason 451, indicating complex routing and that the message was delivered to the spam folder.

spf=softfail (sender IP is 162.19.129[.]232) smtp.mailfrom=contoso.com; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=contoso.com;compauth=none reason=451

This email masquerades as a SharePoint communication asking the recipient to review a shared document. The sender and recipient addresses are the same, though the threat actor has set the display name of the sender to “Pending Approval”. The InternalOrgSender header is set to True. On the surface, this appears to be an internally sent email, though the use of the recipient’s address in both the “To” and “From” fields may alert an end user that this message is not legitimate.

The nested Google URL in the email body points to actor-controlled domain scanuae[.]com. This domain acts as a redirector, loading a script that constructs a URL using the recipient’s Base64-encoded email before loading a custom CAPTCHA page on the Tycoon2FA domain valoufroo.in[.]net. A sample of the script loaded on scanuae[.]com is shown here:

The below example of the custom CAPTCHA page is loaded at the Tycoon2FA domain goorooyi.yoshemo.in[.]net. The CAPTCHA is one of many similar CAPTCHAs observed in relation to Tycoon2FA phishing sequences. Clicking through it leads to a Tycoon2FA phish landing page where the recipient is prompted to input their credentials. Alternatively, clicking through the CAPTCHA may lead to a benign page on a legitimate domain, a tactic intended to evade detection and analysis.

Spoofed email financial scams

Microsoft Threat Intelligence has also observed financial scams sent through spoofed emails. These messages are crafted to look like an email thread between a highly placed employee at the targeted organization, often the CEO of the organization, an individual requesting payment for services rendered, or the accounting department at the targeted organization. In this example, the message was initiated from 163.5.169[.]67 and authentication failures were not enforced, as DMARC is set to none and action is set to none, a permissive mode that does not protect against spoofed messages, allowing the message to reach the inbox on a tenant whose MX record is not pointed to Office 365.

Authentication-Results	spf=fail (sender IP is 163.5.169[.]67) smtp.mailfrom=contoso.com; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=contoso.com;compauth=fail reason=601

The scam message is crafted to appear as an email thread with a previous message between the CEO of the targeted organization, using the CEO’s real name, and an individual requesting payment of an invoice. The name of the individual requesting payment (here replaced with “John Doe”) appears to be a real person, likely a victim of identity theft. The “To” and “From” fields both use the address for the accounting department at the targeted organization, but with the CEO’s name used as the display name in the “From” field. As with our previous examples, this email superficially appears to be internal to the organization, with only the use of the same address as sender and recipient indicating that the message may not be legitimate. The body of the message also attempts to instill a sense of urgency, asking for prompt payment to retain a discount.

Most of the emails observed as part of this campaign include three attached files. The first is the fake invoice requesting several thousand dollars to be sent through ACH payment to a bank account at an online banking company. The name of the individual requesting payment is also listed along with a fake company name and address. The bank account was likely set up using the individual’s stolen personally identifiable information.

The second attachment (not pictured) is an IRS W-9 form that lists the name and social security number of the individual used to set up the bank account. The third attachment is a fake “bank letter” ostensibly provided by an employee at the online bank used to set up the fraudulent account. The letter provides the same banking information as the invoice and attempts to add another layer of believability to the scam.

Falling victim to this scam could result in significant financial losses that may not be recoverable as the funds will likely be moved quickly by the actor in control of the fraudulent bank account.  

Mitigation and protection guidance

Preventing spoofed email attacks

The following links provide information for customers whose MX records are not pointed to Office 365 on how to configure mail flow connectors and rules to prevent spoofed emails from reaching inboxes.

• These links provide information on how to properly configure mail flow with connectors:
  • Manage mail flow using a third-party cloud service with Exchange Online
  • Configure mail flow using connectors in Exchange Online
  • Mail flow rules (transport rules) in Exchange Online
  • Enhanced filtering for connectors in Exchange Online
• These links provide information on configuring SPF, DKIM, and DMARC:
  • Email authentication in cloud organizations
  • Set up SPF to identify valid email sources for your custom cloud domains
  • Set up DKIM to sign mail from your cloud domain
  • Set up DMARC to validate the From address domain for cloud senders
• The following links provide more in-depth information on Direct Send:
  • Introducing more control over Direct Send in Exchange Online
  • Direct Send vs sending directly to an Exchange Online tenant

Mitigating AiTM phishing attacks

Microsoft Threat Intelligence recommends the following mitigations, which are effective against a range of phishing threats.

• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Microsoft 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links used in phishing and other attacks.
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attack tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants
• Configure Microsoft Entra with increased security.
• Pilot and deploy phishing-resistant authentication methods for users.
• Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.

Mitigating threats from phishing actors begins with securing user identity by eliminating traditional credentials and adopting passwordless, phishing-resistant MFA methods such as FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator passkeys.

Microsoft recommends enforcing phishing-resistant MFA for privileged roles in Microsoft Entra ID to significantly reduce the risk of account compromise. Learn how to require phishing-resistant MFA for admin roles and plan a passwordless deployment.

Passwordless authentication improves security as well as enhances user experience and reduces IT overhead. Explore Microsoft’s overview of passwordless authentication and authentication strength guidance to understand how to align your organization’s policies with best practices. For broader strategies on defending against identity-based attacks, refer to Microsoft’s blog on evolving identity attack techniques.

If Microsoft Defender alerts indicate suspicious activity or confirmed compromised account or a system, it’s essential to act quickly and thoroughly. Below are recommended remediation steps for each affected identity:

1. Reset credentials – Immediately reset the account’s password and revoke any active sessions or tokens. This ensures that any stolen credentials can no longer be used.
2. Re-register or remove MFA devices – Review users MFA devices, specifically those recently added or updated.
3. Revert unauthorized payroll or financial changes – If the attacker modified payroll or financial configurations, such as direct deposit details, revert them to their original state and notify the appropriate internal teams.
4. Remove malicious inbox rules – Attackers often create inbox rules to hide their activity or forward sensitive data. Review and delete any suspicious or unauthorized rules.
5. Verify MFA reconfiguration – Confirm that the user has successfully reconfigured MFA and that the new setup uses secure, phishing-resistant methods.

Microsoft Defender XDR detections

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 Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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.

• Actor profile: Storm-1747
• Technique profile: Adversary-in-the-middle credential phishing

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

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

Finding potentially spoofed emails:

EmailEvents
| where Timestamp >= ago(30d)
| where EmailDirection == "Inbound"
| where Connectors == ""  // No connector used
| where SenderFromDomain in ("contoso.com")  // Replace with your domain(s)
| project Timestamp, NetworkMessageId, InternetMessageId, SenderMailFromAddress,
          SenderFromAddress, SenderDisplayName, SenderFromDomain, SenderIPv4,
          RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation

Finding more suspicious, potentially spoofed emails:

EmailEvents
| where EmailDirection == "Inbound"
| where Connectors == ""  // No connector used
| where SenderFromDomain in ("contoso.com", "fabrikam.com") // Replace with your accepted domains
| where AuthenticationDetails !contains "SPF=pass" // SPF failed or missing
| where AuthenticationDetails !contains "DKIM=pass" // DKIM failed or missing
| where AuthenticationDetails !contains "DMARC=pass" // DMARC failed or missing
| where SenderIPv4 !in ("") // Exclude known relay IPs
| where ThreatTypes has_any ("Phish", "Spam") or ConfidenceLevel == "High" // 
| project Timestamp, NetworkMessageId, InternetMessageId, SenderMailFromAddress,
          SenderFromAddress, SenderDisplayName, SenderFromDomain, SenderIPv4,
          RecipientEmailAddress, Subject, AuthenticationDetails, DeliveryAction

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.

The below hunting queries can also be found in the Microsoft Defender portal for customers who have Microsoft Defender XDR installed from the Content Hub, or accessed directly from GitHub.

• Spoof and impersonation phish detections
• Spoof attempts with auth failure

Below are the queries using Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Detect network IP and domain indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["162.19.196.13", "163.5.221.110", "51.195.94.194", "51.89.59.188"]);
let ioc_domains = dynamic(["2fa.valoufroo.in.net", "valoufroo.in.net", "integralsm.cl", "absoluteprintgroup.com"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect web sessions IP and file hash indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["162.19.196.13", "163.5.221.110", "51.195.94.194", "51.89.59.188"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect domain and URL indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

// file hash list - imFileEvent
// Domain list - _Im_WebSession
let ioc_domains = dynamic(["2fa.valoufroo.in.net", "valoufroo.in.net", "integralsm.cl", "absoluteprintgroup.com"]);
_Im_WebSession (url_has_any = ioc_domains)

Spoofing attempts from specific domains

// Add the list of domains to search for.
let DomainList = dynamic(["2fa.valoufroo.in.net", "valoufroo.in.net", "integralsm.cl", "absoluteprintgroup.com"]); 
EmailEvents 
| where TimeGenerated > ago (1d) and DetectionMethods has "spoof" and SenderFromDomain in~ (DomainList)
| project TimeGenerated, AR=parse_json(AuthenticationDetails) , NetworkMessageId, EmailDirection, Subject, SenderFromAddress, SenderIPv4, ThreatTypes, DetectionMethods, ThreatNames  
| evaluate bag_unpack(AR)  
| where column_ifexists('SPF','') =~ "fail" or  column_ifexists('DMARC','') =~ "fail" or column_ifexists('DKIM','') =~ "fail" or column_ifexists('CompAuth','') =~ "fail"
| extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0])
| extend Account_0_Name = Name
| extend Account_0_UPNSuffix = UPNSuffix
| extend IP_0_Address = SenderIPv4

Indicators of compromise

References

• https://www.mimecast.com/threat-intelligence-hub/microsoft-direct-send-abuse/
• https://www.proofpoint.com/us/blog/email-and-cloud-threats/attackers-abuse-m365-for-internal-phishing
• https://www.varonis.com/blog/direct-send-exploit

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky. To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Phishing actors exploit complex routing and misconfigurations to spoof domains appeared first on Microsoft Security Blog.

What happened?

What began as a routine onboarding turned into a covert operation. In this case, four compromised user accounts were discovered connecting PiKVM devices to employer-issued workstations—hardware that enables full remote control as if the threat actor were physically present. This allowed unknown third parties to bypass normal access controls and extract sensitive data directly from the network. With support from Microsoft Threat Intelligence, we quickly traced the activity to the North Korean remote IT workforce known as Jasper Sleet.

DART quickly pivoted from proactive threat hunting to full-scale investigation, leveraging numerous specialized tools and techniques. These included, but were not limited to, Cosmic and Arctic for Azure and Active Directory analysis, Fennec for forensic evidence collection across multiple operating system platforms, and telemetry from Microsoft Entra ID protection and Microsoft Defender solutions for endpoint, identity, and cloud apps. Together, these tools and capabilities helped trace the intrusion, contain the threat, and restore operational integrity.

How did Microsoft respond?

Once the scope of the compromise was clear, DART acted immediately to contain and disrupt the cyberattack. The team disabled compromised accounts, restored affected devices to clean backups, and analyzed Unified Audit Logs—a feature of Microsoft 365 within the Microsoft Purview Compliance Manager portal—to trace the threat actor’s movements. Advanced detection tools, including Microsoft Defender for Identity and Microsoft Defender for Endpoint, were deployed to uncover lateral movement and credential misuse. To blunt the broader campaign, Microsoft also suspended thousands of accounts linked to North Korean IT operatives.

What can customers do to strengthen their defenses?

This cyberthreat is challenging, but it’s not insurmountable. By combining strong security operations center (SOC) practices with insider risk strategies, companies can close the gaps that threat actors exploit. Many organizations start by improving visibility through Microsoft 365 Defender and Unified Audit Log integration and protecting sensitive data with Microsoft Purview Data Loss Prevention policies. Additionally, Microsoft Purview Insider Risk Management can help organizations identify risky behaviors before they escalate, while strict pre-employment vetting and enforcing the principle of least privilege reduce exposure from the start. Finally, monitor for unapproved IT tools like PiKVM devices and stay informed through the Threat Analytics dashboard in Microsoft Defender. These cybersecurity practices and real-world strategies, paired with proactive alert management, can give your defenders the confidence to detect, disrupt, and prevent similar attacks.

What is the Cyberattack Series?

In our Cyberattack Series, customers discover how DART investigates unique and notable attacks. For each cyberattack story, we share:

• How the cyberattack happened.
• How the breach was discovered.
• Microsoft’s investigation and eviction of the threat actor.
• Strategies to avoid similar cyberattacks.

DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.

Learn more

To learn more about DART capabilities, please visit our website, or reach out to your Microsoft account manager or Premier Support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report.

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.

¹AI Fuels Mistrust Between Employers and Job Candidates; Recruiters Worry About Fraud, Candidates Fear Bias

The post Imposter for hire: How fake people can gain very real access appeared first on Microsoft Security Blog.

This evolution demands a fundamental shift in Identity Threat Detection and Response (ITDR). It’s no longer simply about protecting users; it requires consistent, comprehensive protection for every piece of the identity fabric, whether human or non-human, on-premises or in the cloud, from Microsoft or another vendor.

ITDR for the modern enterprise

Successful identity security practices understand that seams in protection are the real enemy of identity security. A unified approach between identity and security teams is a necessity  and our unique perspective as both a leading identity and security provider allow us to further streamline the flow of contextual insights, actions, and workflows across these groups, minimizing the potential for gaps or oversight.

While both identity and security teams play critical roles in ITDR, it is just one piece of their overall charter and goal. For security operations center (SOC) professionals their core mission remains to prevent, detect, and respond to cyberthreats that could impact their organization’s security and business continuity. On a day-to-day basis, identity and security teams proactively harden their security posture, triage and investigate incoming alerts, and, when a true cyberthreat is confirmed, coordinate a rapid and effective response. Within this broader mission, ITDR resents a critical but focused subset. For instance, identity security posture recommendations are essential but only one piece of broader security hardening.

Similarly, identity alerts offer invaluable insights needed to detect anomalous identity activity, but they must be understood in the context of the overall cyberattack. And while identity response actions such as revoking sessions or enforcing multifactor authentication are critical to stop attacks, they must be coordinated with other response actions across endpoints and other domains to block lateral movement.

True defense requires enriching identity signals and delivering them in context as part of a unified threat picture, enabling coordinated response across domains, and continuously improving posture to stay ahead of evolving cyberthreats.

This blog explores how Microsoft is reimagining identity security to meet these challenges head-on—empowering defenders with the clarity, context, and control they need to stay ahead of identity-based threats.

Enriched and insightful: Building the foundation for identity security

Identity security starts with ensuring your environment is protected as a foundation. Visibility across your organization’s unique fabric of interconnected identities, infrastructure, and applications is what enables SOC teams to detect cyberthreats earlier, respond faster, and reduce risk across the board. Because in today’s identity-driven cyberthreat landscape, partial visibility is no longer an option. To meet this challenge, organizations need sensors for on-premises infrastructure and integrations with cloud-based identity solutions to pull in insights from the entirety of their identity fabric.

Understanding this, Microsoft is proud to offer one of the widest sets of dedicated sensors for on-premises identity infrastructure. Domain controllers, Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Microsoft Entra ID Connect each serve a distinct purpose within on-premises identity footprint and our dedicated sensors are purpose built to monitor and detect anomalies within their specific activity or configurations.

Additionally, I am excited to announce the general availability of the unified identity and endpoint sensors we unveiled at Microsoft Ignite in 2024. This amazing milestone makes it even easier for new Microsoft Defender for Identity customers to activate identity protections on qualifying domain controllers and start benefiting from identity-specific visibility, posture recommendations, alerts, and automatic attack disruption capabilities within the Defender experience.

Our protections don’t end on-premises, however. Defender’s native integration with Microsoft Entra ID empowers the SOC with real-time visibility into Entra identity activity, risk level, and seamless integration into Zero Ttrust policies through Conditional Access and user containment. And because identity fabrics are rarely homogenous, Microsoft also supports other cloud identities like Okta, offering unified visibility, posture insights, and ITDR capabilities across platforms.

The raw data into cloud and on-premises accounts is important but to be truly insightful it needs to be enriched. To do this we are shifting the paradigm from account-centric to identity-centric. This means correlating information across accounts, platforms, and environments to reveal an identity’s true footprint. With an understanding of how multiple accounts map back to a single identity, the SOC can more accurately investigate and respond to cyberthreats.

This enriched view is especially critical when dealing with privileged identities. Integrations with Privileged Access Management (PAM) solutions further empower security organizations to monitor and protect high-value identities.   

All of this is in addition to the native extended detection and response (XDR) correlation done by Microsoft Defender that automatically links identity signals with insights from other security domains, giving security teams a unified threat picture, breaking down silos, and improving response efficiency. From the Identity page in the Defender portal, SOC analysts can see related devices, applications, and alerts—creating a connected view of the threat landscape. These relationships are also exposed in Advanced Hunting, allowing defenders to query across domains and uncover patterns that would otherwise remain hidden. And because Microsoft extends protections to AI agents, service accounts, third-party identities and more, it can use behavioral signals to detect drift and enforce policy—an area where many competitors simply can’t match.

Context is everything

Microsoft Defender delivers deep, enriched visibility into your unique identity fabric. But the true magic lies in how this intelligence is operationalized within the SOC experience. Defender and Microsoft Entra work together generate identity alerts, which get correlated into broader security incidents within Microsoft Defender XDR, giving analysts a unified view of threat activity across endpoints, identities, and cloud resources. Similarly, identity-posture recommendations are part of Microsoft’s Exposure Management strategy, where they are surfaced alongside other risk signals to help teams proactively reduce their attack surface. And when a threat is confirmed, automatic attack disruption can dynamically contain not only the compromised user but also the devices and sessions associated with the attack. This contextualization turns the powerful insights into decisive action. And in today’s threat landscape it’s not just about seeing more—it’s about responding smarter, faster.

Getting started

New Defender for Identity customers interested in activating the unified sensor can learn more, including how to deploy, within our documentation here. Existing customers that have already deployed the Defender for Identity sensors do not need to do anything at this time, stay tuned for migration guidance in the coming months.  

Learn more about Microsoft ITDR solutions.

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.

¹State of Multicloud Security Risk, Microsoft, 2024.

The post Harden your identity defense with improved protection, deeper correlation, and richer context appeared first on Microsoft Security Blog.

Recognizing these risks, Microsoft’s Secure Future Initiative (SFI) has strengthened default security by design, but defenders must continue to follow security baseline recommendations and leverage customer-facing security capabilities to stay ahead of evolving threats. In alignment with the MITRE ATT&CK framework, Microsoft Threat Intelligence continually updates threat matrices to map the evolving tactics and techniques targeting cloud environments. While some of our previous work has focused on Kubernetes and containerized workloads at the compute layer of the cloud stack, this blog shifts the lens to the data storage layer—specifically, Azure Blob Storage.

Therefore, in this blog, we outline some of the unique threats associated with the data storage layer, including relevant stages of the attack chain for Blob Storage to connect these risks to actionable Azure Security controls and applicable security recommendations. We also provide threat detections to help contain and prevent Blob Storage threat activity with Microsoft Defender for Cloud’s Defender for Storage plan. By understanding the unique threats facing Azure Blob Storage and implementing targeted security controls, organizations can better safeguard their most critical workloads and data repositories against evolving attacker tactics.

How Azure Blob Storage works

Azure Storage supports a wide range of options for handling exabytes of blob data from many sources at scale. Blobs store everything from checkpoint and model files for AI to parquet datasets for analytics. These blobs are organized into containers, which function like folders grouping sets of blobs. A single storage account can contain an unlimited number of containers, and each container can store an unlimited number of blobs.

Blob Storage also supports HPC, backup, and disaster recovery scenarios for more resiliency and business continuity, like backing up on-premises resources or Infrastructure as a Service (IaaS) virtual machine-hosted SQL Server data. Azure Data Lake Storage offers specific optimizations well suited for file system and analytics workloads such as hierarchical namespace and fast atomic operations. Blob storage also supports public access scenarios such as download for static files—not all files are accessible for download over internet.

Azure Storage fulfils the cloud shared responsibility model through best practices across identity and access management, secure networking, data protection, and continuous monitoring. It supports best practices that help defend across the attack chain when implemented as part of both a cloud-native identity and access management solution such as Microsoft Entra ID, and a cloud-native application protection platform such as Defender for Cloud. Azure Storage integrates with both, allowing least-privilege access through Entra role-based access control (RBAC) and fine-grained Entra Azure attribute-based access control (ABAC).

Azure Storage safeguards data in transit with network protections such as network security perimeter, private endpoint/Private Link and virtual networks, and encryption for data in transit via TLS. It uses service-side encryption (SSE) to automatically encrypt all Azure Storage resources persisted to the cloud, including blobs and object metadata, and cannot be disabled. While Storage automatically encrypts all data in a storage account at the service level using 256-bit AES encryption (one of the strongest block ciphers available), it is also possible to enable 256-bit AES encryption at the infrastructure level for double encryption to protect against a scenario where one of the encryption algorithms or keys might be compromised.

Azure Storage integrates with Azure Backup and Microsoft Defender for ransomware and malware protection. Azure Storage also supports a wide range of data protection scenarios, such as preventing deletion or modification of accounts and blobs through immutability settings and enabling recovery from data deletion or overwrites through soft delete and versioning.  

A look at the attack chain

To help defenders apply appropriate controls and our recommendations against various threat scenarios across the attack chain, we take a closer look at the progression.

Reconnaissance

Threat actors enumerate Blob Storage to identify publicly exposed data and credentials that they can leverage later in the attack chain. Common tactics include DNS and HTTP header probing to scan for valid *.blob.core.windows.net subdomains. Threat actors can now also use language models to generate plausible storage account or container names to make brute-forcing more effective.

Enumeration tools like Goblob have long been made available on GitHub, and threat actors can extend this type of capability misusing other tools on GitHub like QuickAZ, which combines storage enumeration with other Azure reconnaissance capabilities. Threat actors may also try to leverage PowerShell-based scanners easily accessible to brute-force prefix and suffix combinations for hours using permutation dictionary scripts. They can also turn to dedicated indexers cataloging tens of thousands of publicly exposed containers.  

When sensitive credentials, such as storage account keys, shared access signatures (SAS), or Microsoft Entra ID principal credentials are discovered in source code repositories or configuration files (including version histories), threat actors can more easily gain an initial foothold. Storage account keys are particularly high risk if they grant full read, write, and delete access to storage resources. With these credentials, threat actors can escalate privileges, move laterally, or proceed directly to exfiltrate data.

Resource development

Threat actors try to exploit misconfigured or missing identity controls to create malicious resources in Blob Storage in furtherance of their operations and targeting. They may attempt to leverage Azure Blob Storage to host spoofed versions of legitimate Microsoft sign-in pages to make it more challenging for potential victims to discern based on an inspection of the SSL certificates alone.

Threat actors may attempt to place malicious executables or macro-enabled documents in containers left open to anonymous access or secured by weak or compromised SAS. This could lead to victims downloading harmful content directly from those blob URLs.

Since Blob Storage often stores machine learning training datasets, threat actors may exploit it for data poisoning by injecting mislabeled or malicious samples to skew model behavior and produce incorrect predictions.

Initial access

A single misconfigured endpoint could expose sensitive information. Theoretically, a threat actor could attempt to exploit blob-triggered Azure Functions using Event Grid that process files in storage containers, or Azure Logic Apps that automate file transfers from external sources like FTP servers, to gain entry to downstream workflows linked to Azure Storage—if those workflows rely on misconfigured or insufficiently secured authentication mechanisms. This could allow an attacker to maliciously trigger trusted automation or hijack event routing to escalate privileges or move laterally within the environment.

Persistence

If a threat actor gains access to an environment through Blob Storage, they may attempt to establish a long-term foothold by manipulating identity and access configurations that are resilient to standard remediation efforts such as key rotations or password resets. These techniques may include assigning built-in roles or custom roles with elevated privileges to identities under their control, generating SAS with broad permissions and extended expiration periods, modifying container-level access policies to permit anonymous read access, enabling Secure File Transfer Protocol (SFTP) on storage accounts, or leveraging soft-delete capabilities to conceal malicious payloads by uploading, deleting, and later restoring blobs.

Threat actors frequently abuse legitimate tools such as AADInternals to establish backdoors and persist, enabling access to both cloud and hybrid resources. Additionally, frameworks like AzureHound are extensively leveraged to identify privileged escalation paths from enumerated Azure resources.

Defense evasion

Threat actors may attempt to evade detection by tampering with Blob Storage networking and logging configurations—loosening or deleting firewall rules, adding overly permissive IP address ranges or virtual network (VNet) rules, creating unauthorized private endpoints, distributing requests across regions, or disabling diagnostic logging.

Credential access

Threat actors may attempt to obtain Blob Storage credentials through several vectors, including token and key extraction, cloud shell persistence abuse, and exposure through misconfigurations. For token and key extraction, threat actors with access to Entra ID tokens may reuse refresh tokens to obtain new access tokens, or invoke privileged management APIs (for example, listKeys) to extract primary and secondary storage account keys. These keys may grant full data-plane access and bypass identity-based controls. For cloud shell persistence abuse, because Azure Cloud Shell stores session data within a hidden blob container within the user’s storage account, threat actors with access may retrieve cached credentials, command history, or configuration files containing sensitive information. Finally, for exposure through misconfiguration, if secure transfer is not enforced or network access controls are overly permissive, shared keys or SAS tokens may be exposed in transit or through public endpoints. This includes keys and tokens found in exposed or compromised endpoints or code-repositories. These credentials can then possibly be reused by threat actors to access or exfiltrate data.

Discovery

After gaining a foothold in Azure, threat actors might map Blob Storage to locate valuable data and understand defensive settings. To uncover blob containers unintentionally exposed publicly, they could enumerate the broader cloud estate—querying subscriptions, resource groups, and storage account inventories. After identifying accounts, threat actors could probe deeper: listing containers and blobs, inspecting metadata, and retrieving configuration details such as firewall rules, logging targets, immutability policies, and backup schedules. This would enable them to identify where sensitive data resides and assess which controls can be bypassed or disabled to facilitate collection, exfiltration, or destruction.

Lateral movement

When a new blob is added to a container, Azure can trigger Azure Functions, Logic Apps, or other workflows. If a threat actor controls the source container and an Event Grid subscription is configured, they may upload specially crafted files that trigger downstream compute resources running under managed identities, which may have elevated permissions to move laterally into other services.

If Azure Functions store their code in Azure Storage and threat actors gain write access, they may attempt to replace the code with malicious files. When the function is triggered by a blob event, HTTP request or timer, it could run malicious code under the function’s identity, potentially granting access to other resources.

Threat actors may also target automated data pipelines or third-party integrations that trust blob-based inputs. Enterprises often use Azure Data Factory and Azure Synapse Analytics to copy and transform data from Azure Blob Storage. These pipelines typically authenticate to Blob using managed identities, service principals, SAS tokens, or account keys, and may connect over managed private endpoints. If an attacker can modify data in a source container, they may influence downstream processing or gain access to services that trust the pipeline’s identity, enabling further lateral movement.

Collection

If blob containers are misconfigured, threat actors may be able to list and download large volumes of data directly from storage. If access is obtained, they may copy or export sensitive files into a staging container they control, using Storage operations like StartCopy, SyncCopy, or CopyBlob through AzCopy or the Azure Storage REST API to stay within Azure and evade detection. They may compress or encrypt the data cache internally as well before attempting to exfiltrate it.

Command and control

Blob Storage can be abused to distribute malware if the account or credentials are compromised. Threat actors may try to use Blob Storage as a covert beacon channel, where malware running on compromised hosts periodically polls for new blobs or metadata updates containing command payloads. After infecting a target, malware might send HEAD or GET requests to the Azure blob’s REST API, retrieving metadata without downloading the file content. If malware parses these headers as communication channels, it may send exfiltrated data back by writing separate metadata updates. Threat actors could embed new commands within metadata fields, meaning the blob’s content remains unchanged while the metadata plane acts as a persistent, stealthy command-and-control (C2) server. 

Additionally, threat actors may attempt to exploit object replication to propagate payloads across environments. If a replication policy is successfully configured, any new blobs added to a compromised source container are automatically copied to a trusted destination container—turning it into a distribution hub and enabling supply chain–style attacks.

Exfiltration

If threat actors gain access to the environment, they might leverage Azure-native tools like Azure Storage Explorer or AzCopy to exfiltrate data at scale—exploiting Azure’s high bandwidth and trusted domains to evade detection. 

For instance, they could enable static website hosting and copy sensitive blobs into the publicly accessible $web container. Disabling anonymous access on the storage account-level offers no protection here, because the $web container always remains publicly accessible. In another scenario, threat actors could exfiltrate data into a separate Azure subscription they control, using Microsoft’s internal network as a covert transport layer to bypass controls. 

Threat actors could also embed exfiltration logic within Azure Functions, Logic Apps, or Automation runbooks, disguising them as legitimate maintenance tasks and throttling transfers to stay below volume or rate thresholds.

Third-party integrations can also lead to indirect exposure if the integrated products are compromised. For example, in 2023, defenders whose environments had MOVEit Transfer application connected to Blob Storage for file transfers or archiving partially contained a zero-day vulnerability, which was later attributed in a tweet by Microsoft to Lace Tempest (known for ransomware operations and running the Clop extortion site).

Impact

If threat actors obtain high privilege roles, storage account keys, or broadly scoped SAS tokens, they can cause extensive damage—for example, issuing mass DeleteBlob or DeleteContainer operations, overwriting objects including with empty content, or re-encrypting data by reuploading modified content or writing new content to blobs. With the necessary privileges, threat actors can also modify file contents or metadata, change access tiers, and remove legal holds. In many scenarios, simply reading or exfiltrating data can result in long-term impact, even without immediate disruption—such as in cases of espionage.

Recommendations

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

Apply zero trust principles to Azure Storage.

Business asset security depends on the integrity of the privileged accounts that administer your IT systems. Refer to our FAQ for answers on securing privileged access. Learn to enable the Azure identity management and access control security best practices, such as ensuring separate user accounts and mail forwarding for Global Administrator accounts. Follow best practices for using Microsoft Entra role-based access control.

Implement our security recommendations for Blob Storage.

• Data protection
• Identity and access management
• Networking
• Logging and monitoring

Monitor the Azure security baseline for Storage and its recommendations using Defender for Cloud.

Microsoft Defender for Cloud periodically analyzes the security state of your Azure resources to identify potential security vulnerabilities and then provides security recommendations on how to address them. For more information, see Review your security recommendations.

Enable Microsoft Defender for Storage.

Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Its alerts detect and prevent top cloud storage threats, including sensitive data exfiltration, data corruption, and malicious file uploads. For more information, see Understand security threats and alerts in Microsoft Defender for Storage.

You don’t need to enable diagnostic logs for analysis. Defender for Storage also detects suspicious activities from entities without identities that access your data using misconfigured and overly permissive SAS. These SAS might be leaked or compromised.

Sensitive data threat detection considers the sensitivity of the data at risk, quickly identifying and addressing the most significant risks. It also detects exposure events and suspicious activities on resources containing sensitive data. Learn more about sensitive data threat detection.

Enable Defender for Storage via built-in policy. Monitor compliance states to detect if an attacker attempts to tamper with Defender for Storage to evade defenses, and automatically respond with alerts and recovery tasks.

• Enable malware scanning.

Malware scanning in Defender for Storage detects in near real-time and mitigates a wide variety of malware threats either by scanning blobs automatically when blobs are being frequently uploaded or modified, or on-demand for proactive security, incident response, integrating partner data, and securing data pipelines and machine learning datasets.

You can store scan results using index tags, which can be used by applications to automate workflows. Microsoft Defender for Cloud also generates relevant security alerts in the portal, so you can configure automations or export them to Microsoft Sentinel or another SIEM. You can also send results to an Event Grid for automating response and create an audit trail with Log Analytics.

Scanning supports automated remediation through built-in soft deletion of malicious blobs discovered during scanning, blocking access, quarantining and forwarding clean files.

Enable Defender Cloud Security Posture Management (CSPM).

Enabling the CSPM plan extends CSPM capabilities that are automatically enabled as part of Defender for Cloud to offer extra protections for your environment such as cloud security explorer, attack path analysis, and agentless scanning for machines.  

• Use sensitive data discovery.

The Sensitive data discovery component of CSPM identifies sensitive resources and their related risks, then helps prioritize and remediate those risks using the Microsoft Purview classification engine.

Use the cloud security checklist as a structured approach for securing your Azure cloud estate.

This checklist provides security guidance for those managing the technology infrastructure that supports all the workload development and operations hosted on Azure. To help ensure your workloads are secure and aligned with the Zero Trust model, use the design review checklist for security. We also provide complementary guidance on applying security practices and DevSecOps controls in a security development lifecycle.

Enable threat protection for AI services.

Blob Storage is often used to store training datasets for Azure Machine Learning. Because data poisoning is among the most severe machine learning threats, it is critical to scan uploads before they ever enter your pipeline to prevent targeted poisoning attacks.

Microsoft Defender XDR detections

Microsoft Defender for Cloud

When Defender for Storage is enabled, the following alerts in Defender for Cloud may indicate Azure Blob Storage threat activity. Note that other alerts apply to Azure Files.

Some of these alerts will not work if sensitive data threat detection is disabled. Some alerts may be relevant to secondary stages of the attack chain or only be an indication of a penetration test in your organization.

Reconnaissance

• Publicly accessible storage containers successfully discovered
• Publicly accessible storage containers unsuccessfully scanned
• Access from a known suspicious IP address to a sensitive blob container
• Access from a Tor exit node to a sensitive blob container
• Access from a suspicious IP address
• Unusual data exploration in a storage account

Resource Development

• Phishing content hosted on a storage account
• Suspicious external access to an Azure storage account with overly permissive SAS token 
• Suspicious external operation to an Azure storage account with overly permissive SAS token 
• Unusual SAS token was used to access an Azure storage account from a public IP address

Initial Access

• Access from a known suspicious application to a sensitive blob container
• Access from a suspicious application
• Access from an unusual location to a sensitive blob container
• Access from an unusual location to a storage account
• Authenticated access from a Tor exit node
• Unusual unauthenticated access to a storage container
• Unusual unauthenticated public access to a sensitive blob container 

Discovery

• Unusual access inspection in a storage account 

Lateral Movement

• Unusual application accessed a storage account 
• Malicious blob was downloaded from a storage account (with malware scanning add-on enabled)

Collection

• The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access
• The access level of a sensitive storage blob container was changed to allow unauthenticated public access 

Command and control

• Potential malware uploaded to a storage account
• Malicious file uploaded to storage account (with malware scanning add-on enabled; this alert may be an indication that a threat actor intentionally uploaded malware or that a legitimate user unintentionally uploaded a malicious file)

Exfiltration

• Unusual amount of data extracted from a sensitive blob container
• Unusual amount of data extracted from a storage account 
• Unusual number of blobs extracted from a sensitive blob container 

Impact

• Unusual deletion in a storage account 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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.

Microsoft Defender Threat Intelligence

• Threats targeting or leveraging Azure Blob Storage

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to Microsoft plugins such as for either Microsoft Defender XDR or Microsoft Sentinel.

MITRE ATT&CK Techniques observed

This threat exhibits the use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

T1593.002 Search Open Websites/Domains: Search Engines | Threat actors may use search engines and advanced querying (for example, site:*.blob.core.windows.net) to discover exposed Blob Storage accounts.

T1594 Search Victim-Owned Websites | Threat actors might look for storage accounts of a victim enterprise by searching its websites. Victim-owned website pages might be stored on a storage account or contain links to retrieve data stored in a storage account. The links contain the URL of the storage and provide an entry point into the account.

T1595.003 Active Scanning: Wordlist Scanning | Threat actors might attempt to locate publicly accessible cloud storage accounts or containers by iteratively trying different permutations or using target-specific wordlists to discover storage endpoints that can be probed for vulnerabilities or misconfigurations.

T1596 Search Open Technical Databases | Threat actors might search public databases for publicly available storage accounts that can be used during targeting.

T1596.001 Search Open Technical Databases: DNS/Passive DNS | Threat actors might search for DNS data for valid storage account names that could become potential targets by querying nameservers using brute-force techniques to enumerate existing storage accounts in the wild or searching through centralized repositories of DNS query responses.

Resource Development

T1583.004 Acquire Infrastructure: Server | If threat actors exploit weak or misconfigured identity controls, Blob Storage could be misused as attacker-controlled infrastructure for hosting malicious payloads, phishing, or C2 scripts.

Initial Access

T1566.001 Phishing: Spearphishing Attachment | Blob Storage could host malicious attachments for spear phishing if threat actors leverage compromised SAS tokens or misconfigured anonymous access.

T1566.002 Phishing: Spearphishing Link | Blob Storage could be misused as a publicly accessible host for spear-phishing links if anonymous or misconfigured containers exist.

T1078.004 Valid Accounts: Cloud Accounts | Threat actors could gain an account-like foothold in Blob Storage if they compromise SAS or storage account keys or successfully take control of a Microsoft Entra ID principal account that holds roles or permissions over Blob Storage. 

Persistence

T1098.001 Account Manipulation: Additional Cloud Credentials | To maintain access even if compromised credentials are revoked, threat actors may try to exploit Blob Storage’s Role-Based Access Control (RBAC) by modifying permissions on identity objects, like Microsoft Entra ID security principals. They may also create high-privilege SAS tokens with long expiry, modify container access levels to allow anonymous reads, or provision SFTP accounts that bypass key rotation.

Defense Evasion

T1562.011 Impair Defenses: Disable or Modify Tools | Threat actors can try to disable, suppress, or modify Defender for Storage scanning features.

T1562.007 Impair Defenses: Disable or Modify Cloud Firewall | Threat actors may try to disable, modify, or reconfigure Blob Storage’s firewall and virtual network rules—such as by granting exceptions for trusted services through managed identities, establishing private endpoints, or leveraging geo-replication—to mask access channels and maintain persistent, covert access even if primary credentials are revoked. 

Credential Access

T1528 Steal Application Access Token | Threat actors may compromise Blob Storage by stealing OAuth-based application access tokens (including refresh tokens) or by leveraging subscription-level privileges to query management APIs and extract primary and secondary storage account keys. While compromised tokens enable impersonation of legitimate users with constrained, renewable privileges, keys grant unrestricted data-plane access that bypasses identity-based controls. Possession of either credential type can lead to full access to blob containers, facilitating data compromise and lateral movement across the cloud environment.

T1003 OS Credential Dumping | Threat actors might dump Cloud Shell profiles and session history—stored in blob containers of an Azure Storage account—to extract sensitive credentials such as OAuth tokens, API keys, or other authentication secrets. While these credentials differ from traditional OS password hashes, their extraction is analogous to conventional credential dumping because threat actors can use them to impersonate legitimate users and gain unauthorized, persistent access to Blob Storage, facilitating lateral movement and data compromise.

T1040 Network Sniffing | Threat actors might passively intercept network traffic destined for Blob Storage when unencrypted protocols are allowed, exposing shared keys, SAS tokens, or API tokens that could then be used to gain unauthorized access to the blob data plane. By exploiting cloud-native traffic mirroring tools, a threat actor could intercept and analyze the network data flowing to and from the virtual machines interacting with Blob Storage.

Discovery

T1580 Cloud Infrastructure Discovery | Blob Storage could be enumerated post-compromise to list subscriptions, resource groups, or container names that are not externally visible.

T1619 Cloud Storage Object Discovery | Blob Storage could be enumerated post-compromise to find specific blob data and configuration details, such as by call listing APIs to inventory objects or use control-plane access to retrieve firewall rules, logging, and backup policies.

Lateral Movement

T1021.007 Remote Services: Cloud Services | Threat actors might manipulate Blob Storage to trigger a compute service, such as Azure Functions, after placing a malicious blob in a monitored container. This automatic execution chain lets attackers pivot from the compromised container to the compute resource, potentially infiltrating additional components.

Collection

T1074.002 Data Staged: Remote Data Staging | Blob Storage could be used as a “staging area” if permissions are overly broad.

T1530 Data from Cloud Storage Object | Blob Storage could be abused to retrieve or copy data directly from containers if they are misconfigured, publicly accessible, or if keys or SAS tokens are obtained. This might include selectively downloading stored files.

Command and Control

T1105 Ingress Tool Transfer | Threat actors might upload and store malicious programs or scripts in Blob Storage after compromising the storage account or its credentials, leverage automatic synchronization to “fan out” malicious payloads across hosts that regularly pull from blob containers, and facilitate ongoing C2 to enable additional compromise and lateral movement. By merging malicious uploads with normal blob usage, threat actors could stealthily distribute harmful tools to multiple hosts simultaneously, reinforcing both C2 and lateral movement.

Exfiltration

T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage | Blob Storage may facilitate data exfiltration if permissions are overly permissive or credentials (for example, account keys, SAS tokens) are compromised. Threat actors may abuse the “static website” feature to expose blob containers through public web endpoints or use tools like AzCopy to transfer stolen data.

T1030 Data Transfer Size Limits | A threat actor might deliberately constrain the packet sizes of Blob Storage data to remain below established thresholds by transferring it in fixed-size chunks rather than as entire blobs.

T1020 Automated Exfiltration | Threat actors might embed exfiltration routines in predefined automation processes in Blob Storage to evade detection.

T1537 Transfer Data to Cloud Account | Threat actors might transfer Blob Storage data to another cloud account that is under their control by using internal APIs and network paths that evade detection mechanisms focused on external data transfers.

Impact

T1485 Data Destruction | Blob Storage could be compromised or misused for data destruction, where a threat actor deletes or overwrites blob data for impact.

T1486 Data Encrypted for Impact | Blob Storage could be targeted by ransomware if threat actors obtain privileged access or compromise keys.

T1565 Data Manipulation | Threat actors might insert, delete, or modify Blob Storage data to compromise data integrity and influence outcomes by altering blob contents or metadata, disrupting business processes, distorting organizational insights, or concealing malicious activities.

References

• https://attack.mitre.org/
• https://cyberdom.blog/azure-blob-storage-powershell-scanning-script/
• https://grayhatwarfare.medium.com/how-to-search-for-open-amazon-s3-buckets-and-their-contents-https-buckets-grayhatwarfare-com-577b7b437e01
• https://www.bleepingcomputer.com/news/security/ransomware-gangs-now-abuse-microsoft-azure-tool-for-data-theft/
• https://www.progress.com/moveit
• https://x.com/MsftSecIntel/status/1665537730946670595

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Inside the attack chain: Threat activity targeting Azure Blob Storage appeared first on Microsoft Security Blog.

What happened?

The cases we’re examining in detail spanned two parts—Reactive 1 and Reactive 2. Reactive 1 began when a retail customer received a Microsoft Defender Experts alert titled “Possible web shell installation.” The Investigation revealed a malicious ASPX file on their SharePoint server, linked to vulnerabilities CVE-2025-49706 and CVE-2025-49704. These allowed cyberattackers to spoof identities and inject remote code.

Reactive 2 started with a single compromised identity. Cyberattackers gained persistence by abusing self-service password reset features and mapped the organization’s identity structure using Microsoft Entra ID and Microsoft Graph API. The issue escalated access using Azure Virtual Desktop and Remote Desktop Protocol (RDP), deployed tools like PsExec and SQL Server Management Studio, and maintained control using Teleport, Azure CLI, and Rsocx proxy. Credential manipulation and directory exploration followed, confirmed by Entra ID risk events. The Detection and Response Team (DART) again provided expert support to contain and analyze the threat.

In both cases, the customer engaged DART quickly, which helped validate the scope of the compromise and assess cyberattacker activity and persistence mechanisms.

How did Microsoft respond?

DART swiftly addressed the two security incidents by executing a comprehensive set of actions aimed at restoring control, containing cyberthreats, and reinforcing long-term resilience. The team began by reclaiming identity systems—both on-premises and cloud—through Active Directory takeback and Entra ID isolation. It neutralized threat actor access by deprivileging compromised accounts, revoking tokens, and identifying persistence mechanisms like Teleport and multifactor authentication (MFA) device registration. Malicious web shells were detected and removed within hours, showcasing rapid containment capabilities.

To investigate and remediate the incidents, Microsoft deployed proprietary forensic tools across critical infrastructure, enabling root cause analysis and operational recovery. The team also guided the affected organization through security configuration enhancements aligned with Zero Trust principles, including MFA enforcement. Threat intelligence from Defender and Microsoft Sentinel confirmed systemic identity compromise, prompting patching of vulnerable systems and a phased mass password reset with user identity re-attestation. Additionally, reverse engineering of ransomware revealed targeted attacks on ESXi directories, informing further mitigation strategies.

What can customers do to prepare?

In the case of Reactive 1, we recommended critical security actions to fortify on-premises SharePoint environments and minimize exposure to known vulnerabilities, something we recommend for all customers. Customers can reduce their risk by deploying endpoint detection and response (EDR) across all devices, conducting regular vulnerability scans, and strengthening identity and access controls. Centralized logging and threat intelligence should also be implemented, along with preserving evidence and maintaining a robust incident response plan. Tools to monitor behavioral anomalies, suspicious processes, and malware indicators are increasingly necessary to protect against today’s threat actors.

Patching promptly—especially for known exploited vulnerabilities—remains a key defense for customers. Regular security hygiene practices—like enforcing MFA across all accounts, removing inactive credentials, and applying least privileged access principles—can improve defenses in real time as threats change fast.

Secure your spot

Ready to strengthen your security strategy for the AI era? Register now for Microsoft Secure, on September 30, to explore the latest AI-first solutions. Then, join us at Microsoft Ignite—November 17–21 in San Francisco, CA or online—to deep dive into more innovations, connect with industry experts, experience hands-on labs, and earn certifications.

What is the Cyberattack Series?

With our Cyberattack Series, customers discover how DART investigates unique and notable cyberattacks. For each cyberattack story, we share:

• How the cyberattack happened
• How the security compromise was discovered
• Microsoft’s investigation and eviction of the threat actor
• Strategies to avoid similar cyberattacks

While retail customers were the target of cyberattackers this time, these incidents serve as a stark reminder that proactive patching, identity segmentation, and continuous monitoring are essential security practices to defend against modern cyber threats for all customers. DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.

Learn more with Microsoft Security

To learn more about DART capabilities, please visit our website, or reach out to your Microsoft account manager or premier support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report.

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.

¹Retail Cybersecurity Statistics: Market Data Report 2025 

The post Retail at risk: How one alert uncovered a persistent cyberthreat​​ appeared first on Microsoft Security Blog.