Microsoft

Traditional security solutions often operate in a one-size-fits-all alert model that treats every detection equally, regardless of how important the asset is. But not all assets are equal. Critical assets are systems governing access, identity, or sensitive data. They are essential to an organization’s operations and security, for example, domain controllers, cloud connectivity gateways, key management servers, and others. If attackers compromise these assets, business continuity suffers at great scale. As these systems typically have less routine activity, any alert on them is far more significant.

Threat actors specifically target these high-value systems, meaning that even weaker signals need to be properly investigated. With short-staffed SOC teams, it has historically been a challenge to respond to these types of signals effectively. Given assets like domain controllers are the backbone to an organization’s daily operations, protecting critical infrastructure means proactively stopping adversaries before they inflict damage. So how do security solutions help SOC teams effectively protect critical assets while ensuring business continuity?

To help security teams meet this challenge, Microsoft Defender developed automatic attack disruption: a built-in self-defense capability that identifies & disrupts multi-domain attacks in near real time to prevent further damage across the organization. We recently announced how we protect domain controllers against ransomware as the latest attack disruption innovation.

Behind the scenes, attack disruption uses a critical asset framework to achieve this outcome. This framework is developed from the latest threat research and tested internally within Microsoft’s security infrastructure to provide the context needed to differentiate true threats from noise for critical assets, empowering organizations to act decisively when it matters most. Using the native integration between Microsoft Defender for Endpoint and Microsoft Security Exposure Management, we can automatically identify critical assets in your environment and apply deep contextual insights based on each asset’s unique threat profile to disrupt attacks accordingly.

This blog post dives into how this framework drives real impact, its core components, innovative methodology, and how it helps ensure that organizations are proactive and efficient in their defense strategy specifically for critical asset protection.

Real world impact

By applying the critical asset framework, Microsoft Defender was able to disrupt attacks targeting high-value assets several days earlier in the kill chain in 40% of triggered incidents. This early intervention significantly reduces attacker dwell time, helping prevent impact and limit damage. Additionally, in another 40% of incidents, risk-based contextual insights transformed weak signals into clear, actionable disruption opportunities. These were unique incidents, false negatives in the past, that are now being surfaced and mitigated for the first time.

Neutralizing a human-operated attack on a global enterprise’s domain controller

In this scenario, a global enterprise was running multiple endpoint detection & response vendors in their environment, including Microsoft Defender for Endpoint. The organization was targeted by an advanced, human-operated attack on their domain controllers. Only Microsoft’s solution was able to stop the attack thanks to Defender’s early detection and disruption capabilities. The threat was neutralized before any damage could be inflicted, demonstrating the necessity of automatic attack disruption in the fight against ransomware. Meanwhile, critical assets onboarded to the other vendor were impacted.

Attack story showing automatic attack disruption saving domain controllers onboarded to Microsoft Defender for Endpoint whereas those onboarded to a different EDR solution were encrypted.

Core principles for protecting critical assets

Now that you’ve seen how effective attack disruption is for protecting critical assets, let’s take a look at the core principles shaping our framework:

Prioritization and classification: By classifying assets based on their criticality and role we ensure that disruption actions are triggered precisely where they matter most. With fewer benign events on critical systems, every detection is more likely to reflect a genuine threat, enabling faster, more targeted responses that directly enhance client security and operational confidence.
Proactive, real-time defense: Our context-driven approach enables early detection and disruption of threats, often stopping attacks days before they can cause significant harm.
Adaptive and scalable: Although our initial focus has been on domain controllers, the framework is designed to be flexible and protect a variety of other critical assets such as cloud connectivity solutions and publicly connected devices, based on each asset’s unique behavioral context.

We take these principles and translate them into actionable detection and disruption actions tailored to protect critical assets from the sophisticated and persistent threats that they frequently face.

Under the hood of critical asset protection

Asset classification: Our process starts by analyzing each asset’s role and criticality using Microsoft Security Exposure Management to identify and prioritize critical assets, guiding every disruption decision along the way.
Detector integration and management:
Targeted detector selection: We have engineered a specialized set of detectors most relevant to high-value assets, guided by extensive asset-specific threat research. This ensures each critical asset is protected by detectors selected specifically for the threats it faces.
Automated quality evaluation: Our system continuously assesses each detector’s signal-to-noise ratio and overall impact, deploying only those that meet our strict standards.
Integrated security platform: A dedicated module orchestrates every step – from generating alerts and enriching them with context to automatically triggering the right containment or remediation action via one streamlined workflow.
Contextual disruption execution: When a detector triggers on a critical asset, our framework immediately enriches the alert with detailed contextual telemetry. This enriched data is leveraged in several powerful ways. For example, events are correlated to accurately identify any impacted users – even when initial detections lack clear user data (such as when a malicious payload runs under the SYSTEM account via a service, where our framework traces the creator of the service). The framework also assesses remote activity to capture additional related entities, applying tailored threat lists specific to each asset type. These examples demonstrate how our context-driven approach transforms raw detections into precise, actionable intelligence that enable targeted responses like user containment and soon, IP containment for critical assets.

Where we’re heading

As the threat landscape evolves, we continue investing in attack disruption’s ability to protect critical assets. Our roadmap includes:

Scaling through AI-driven behavioral coverage: We’re shifting from a detector-centric approach to an AI-driven model that continuously learns from vast volumes of telemetry and behavioral patterns. We’re shifting the framework to identify and disrupt threats dynamically, improving precision, expanding coverage, and adapting faster than static rules ever could.
Extending asset coverage: Beyond domain controllers, upcoming iterations will include additional high-value assets such as Entra Connect Sync servers, internet-facing servers, SQLs servers, and more – providing comprehensive protection across your organization’s critical infrastructure.
Deepening integration: This innovation has been made possible through the integration between Microsoft Defender for Endpoint and Microsoft Security Exposure Management, which provides advanced asset classification. Our ongoing partnership ensures we continue to innovate and deliver tailored solutions that address unique client needs.

Conclusion

The ability to protect critical assets represents a paradigm shift in cybersecurity, moving from reactive alerting to proactive, context-aware disruption that prioritizes not just alerts, but the assets themselves. By recognizing that not all assets carry the same risk, our approach ensures that protection efforts are focused where they matter most, enabling true end-to-end defense. By integrating advanced asset classification and context-driven intelligence into our security platform, we’re not only protecting critical systems like domain controllers but also empowering customers with decisive, actionable insights.

As we continue to innovate, our commitment remains clear: to deliver intelligent, effective security solutions that safeguard your most vital assets against even the most advanced threats.

Learn more

Explore these resources to stay updated on the latest automatic attack disruption capabilities and how we protect critical assets:

Learn more about Microsoft Defender for Endpoint.
Read our latest security blog on how we protect against ransomware attacks using domain controllers.
Read about the new containment features.
Learn how attack disruption safeguards your domain controllers in this video.
Check out our latest infographic.
Read about automatic attack disruption.

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 Discover how automatic attack disruption protects critical assets while ensuring business continuity appeared first on Microsoft Security Blog.

In today’s cyberthreat landscape, even seconds of delay can mean the difference between stopping a cyberattack or falling victim to ransomware. One major cause of delayed response is understanding threat actor attribution, which is often slowed by inaccurate or incomplete data as well as inconsistencies in naming across platforms. This, in turn, can reduce confidence, complicate analysis, and delay response. As outlined in the National Institute of Standards and Technology’s (NIST) guidance on threat sharing (SP 800-1501), aligning how we describe and categorize cyberthreats can improve understanding, coordination, and overall security posture.

That’s why we are excited to announce that Microsoft and CrowdStrike are teaming up to create alignment across our individual threat actor taxonomies. By mapping where our knowledge of these actors align, we will provide security professionals with the ability to connect insights faster and make decisions with greater confidence.

Read about Microsoft and Crowdstrike’s joint threat actor taxonomy

Names are how we make sense of the threat landscape and organize insights into known or likely cyberattacker behaviors. At Microsoft, we’ve published our own threat actor naming taxonomy to help researchers and defenders identify, share, and act on our threat intelligence, which is informed by the 84 trillion threat signals that we process daily. But the same actor that Microsoft refers to as Midnight Blizzard might be referred to as Cozy Bear, APT29, or UNC2452 by another vendor. Our mutual customers are always looking for clarity. Aligning the known commonalities among these actor names directly with peers helps to provide greater clarity and gives defenders a clearer path to action.

Introducing a collaborative reference guide to threat actors

Microsoft and CrowdStrike are publishing the first version of our joint threat actor mapping. It includes:

• A list of common actors tracked by Microsoft and CrowdStrike mapped by their respective taxonomies.
• Corresponding aliases from each group’s taxonomy.

This reference guide serves as a starting point, a way to translate across naming systems so defenders can work faster and more efficiently, especially in environments where insights from multiple vendors are in play. This reference guide helps to:

• Improve confidence in threat actor identification.
• Streamline correlation across platforms and reports.
• Accelerate defender action in the face of active cyberthreats.

This effort is not about creating a single naming standard. Rather, it’s meant to help our customers and the broader security community align intelligence more easily, respond faster, and stay ahead of threat actors.

Looking ahead

This initial taxonomy mapping is a collaboration between Microsoft and CrowdStrike. Google/Mandiant and Palo Alto Networks Unit 42 will also be contributing to this effort. We look forward to sharing updates from those collaborations in the near future. Security is a shared responsibility, requiring community-wide efforts to improve defensive measures. We are excited to be teaming up with CrowdStrike and we look forward to others joining us on this journey.

Read the taxonomy mapping from Microsoft and Crowdstrike

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.

1SP 800-150, Guide to Cyber Threat Information Sharing, NIST Computer Security Research Center. October 2016.

The post Announcing a new strategic collaboration to bring clarity to threat actor naming appeared first on Microsoft Security Blog.

In today’s evolving cyber threat landscape, threat actors are committed to advancing the sophistication of their attacks. The increasing adoption of essential security features like multifactor authentication (MFA), passwordless solutions, and robust email protections has changed many aspects of the phishing landscape, and threat actors are more motivated than ever to acquire credentials—particularly for enterprise cloud environments. Despite these evolutions, social engineering—the technique of convincing or deceiving users into downloading malware, directly divulging credentials, or more—remains a key aspect of phishing attacks.

Implementing phishing-resistant and passwordless solutions, such as passkeys, can help organizations improve their security stance against advanced phishing attacks. Microsoft is dedicated to enhancing protections against phishing attacks and making it more challenging for threat actors to exploit human vulnerabilities. In this blog, I’ll cover techniques that Microsoft has observed threat actors use for phishing and social engineering attacks that aim to compromise cloud identities. I’ll also share what organizations can do to defend themselves against this constant threat.

While the examples in this blog do not represent the full range of phishing and social engineering attacks being leveraged against enterprises today, they demonstrate several efficient techniques of threat actors tracked by Microsoft Threat Intelligence. Understanding these techniques and hardening your organization with the guidance included here will help contribute to a significant part of your defense-in-depth approach.

Pre-compromise techniques for stealing identities Modern phishing techniques attempt to defeat authentication flows Adversary-in-the-middle (AiTM)

Today’s authentication methods have changed the phishing landscape. The most prevalent example is the increase in adversary-in-the-middle (AiTM) credential phishing as the adoption of MFA grows. The phish kits available from phishing-as-a-service (PhaaS) platforms has further increased the impact of AiTM threats; the Evilginx phish kit, for example, has been used by multiple threat actors in the past year, from the prolific phishing operator Storm-0485 to the Russian espionage actor Star Blizzard.

Evilginx is an open-source framework that provides AiTM capabilities by deploying a proxy server between a target user and the website that the user wishes to visit (which the threat actor impersonates). Microsoft tracked Storm-0485 directing targets to Evilginx infrastructure using lures with themes such as payment remittance, shared documents, and fake LinkedIn account verifications, all designed to prompt a quick response from the recipient. Storm-0485 also consistently uses evasion tactics, notably passing initial links through obfuscated Google Accelerated Mobile Pages (AMP) URLs to make links harder to identify as malicious.

Figure 1. Example of Storm-0485’s fake LinkedIn verify account lure

To protect against AiTM attacks, consider complementing MFA with risk-based Conditional Access policies, available in Microsoft Entra ID Protection, where sign-in requests are evaluated using additional identity-driven signals like IP address location information or device status, among others. These policies use real-time and offline detections to assess the risk level of sign-in attempts and user activities. This dynamic evaluation helps mitigate risks associated with token replay and session hijacking attempts common in AiTM phishing campaigns.

Additionally, consider implementing Zero Trust network security solutions, such as Global Secure Access which provides a unified pane of glass for secure access management of networks, identities, and endpoints.

Device code phishing

Device code phishing is a relatively new technique that has been incorporated by multiple threat actors into their attacks. In device code phishing, threat actors like Storm-2372 exploit the device code authentication flow to capture authentication tokens, which they then use to access target accounts. Storm-1249, a China-based espionage actor, typically uses generic phishing lures—with topics like taxes, civil service, and even book pre-orders—to target high-level officials at organizations of interest. Microsoft has also observed device code phishing being used for post-compromise activity, which are discussed more in the next sections.

At Microsoft, we strongly encourage organizations to block device code flow where possible; if needed, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.

OAuth consent phishing

Another modern phishing technique is OAuth consent phishing, where threat actors employ the Open Authorization (OAuth) protocol and send emails with a malicious consent link for a third-party application. Once the target clicks the link and authorizes the application, the threat actor gains access tokens with the requested scopes and refresh tokens for persistent access to the compromised account. In one OAuth consent phishing campaign recently identified by Microsoft, even if a user declines the requested app permissions (by clicking Cancel on the prompt), the user is still sent to the app’s reply URL, and from there redirected to an AiTM domain for a second phishing attempt.

Figure 2. OAuth app prompt seeks account permissions

You can prevent employees from providing consent to specific apps or categories of apps that are not approved by your organization by configuring app consent policies to restrict user consent operations. For example, configure policies to allow user consent only to apps requesting low-risk permissions with verified publishers, or apps registered within your tenant.

Device join phishing

Finally, it’s worth highlighting recent device join phishing operations, where threat actors use a phishing link to trick targets into authorizing the domain-join of an actor-controlled device. Since April 2025, Microsoft has observed suspected Russian-linked threat actors using third-party application messages or emails referencing upcoming meeting invitations to deliver a malicious link containing valid authorization code. When clicked, the link returns a token for the Device Registration Service, allowing registration of the threat actor’s device to the tenant. You can harden against this type of phishing attack by requiring authentication strength for device registration in your environment.

Lures remain an effective phishing weapon

While both end users and automated security measures have become more capable at identifying malicious phishing attachments and links, motivated threat actors continue to rely on exploiting human behavior with convincing lures. As these attacks hinge on deceiving users, user training and awareness of commonly identified social engineering techniques are key to defending against them.

Impersonation lures

One of the most effective ways Microsoft has observed threat actors deliver lures is by impersonating people familiar to the target or using malicious infrastructure spoofing legitimate enterprise resources. In the last year, Star Blizzard has shifted from primarily using weaponized document attachments in emails to spear phishing with a malicious link leading to an AiTM page to target the government, non-governmental organizations (NGO), and academic sectors. The threat actor’s highly personalized emails impersonate individuals from whom the target would reasonably expect to receive emails, including known political and diplomatic figures, making the target more likely to be deceived by the phishing attempt.

Figure 3. Star Blizzard file share spear-phishing email QR codes

We have seen threat actors regularly iterating on the types of lure links incorporated into their attacks to make social engineering more effective. As QR codes have become a ubiquitous feature in communications, threat actors have adopted their use as well. For example, over the past two years, Microsoft has seen multiple actors incorporate QR codes, encoded with links to AiTM phishing pages, into opportunistic tax-themed phishing campaigns.

The threat actor Star Blizzard has even leveraged nonfunctional QR codes as a part of a spear-phishing campaign offering target users an opportunity to join a WhatsApp group: the initial spear-phishing email contained a broken QR code to encourage the targeted users to contact the threat actor. Star Blizzard’s follow-on email included a URL that redirected to a webpage with a legitimate QR code, used by WhatsApp for linking a device to a user’s account, giving the actor access to the user’s WhatsApp account.

Use of AI

Threat actors are increasingly leveraging AI to enhance the quality and volume of phishing lures. As AI tools become more accessible, these actors are using them to craft more convincing and sophisticated lures. In a collaboration with OpenAI, Microsoft Threat Intelligence has seen threat actors such as Emerald Sleet and Crimson Sandstorm interacting with large language models (LLMs) to support social engineering operations. This includes activities such as drafting phishing emails and generating content likely intended for spear-phishing campaigns.

We have also seen suspected use of generative AI to craft messages in a large-scale credential phishing campaign against the hospitality industry, based on the variations of language used across identified samples. The initial email contains a request for information designed to elicit a response from the target and is then followed by a more generic phishing email containing a lure link to an AiTM phishing site.

Figure 4. One of multiple suspected AI-generated phishing email in a widespread phishing campaign

AI helps eliminate the common grammar mistakes and awkward phrasing that once made phishing attempts easier to spot. As a result, today’s phishing lures are more polished and harder for users to detect, increasing the likelihood of successful compromise. This evolution underscores the importance of securing identities in addition to user awareness training.

Phishing risks continue to expand beyond email

Enterprise communication methods have diversified to support distributed workforce and business operations, so phishing has expanded well beyond email messages. Microsoft has seen multiple threat actors abusing enterprise communication applications to deliver phishing messages, and we’ve also observed continued interest by threat actors to leverage non-enterprise applications and social media sites to reach targets.

Teams phishing

Microsoft Threat Intelligence has been closely tracking and responding to the abuse of the Microsoft Teams platform in phishing attacks and has taken action against confirmed malicious tenants by blocking their ability to send messages. The cybercrime access broker Storm-1674, for example, creates fraudulent tenants to create Teams meetings to send chat messages to potential victims using the meeting’s chat functionality; more recently, since November 2024, the threat actor has started compromising tenants and directly calling users over Teams to phish for credentials as well. Businesses can follow our security best practices for Microsoft Teams to further defend against attacks from external tenants.

Leveraging social media

Outside of business-managed applications, employees’ activity on social media sites and third-party communication platforms has widened the digital footprint for phishing attacks. For instance, while the Iranian threat actor Mint Sandstorm primarily uses spear-phishing emails, they have also sent phishing links to targets on social media sites, including Facebook and LinkedIn, to target high-profile individuals in government and politics. Mint Sandstorm, like many threat actors, also customizes and enhances their phishing messages by gathering publicly available information, such as personal email addresses and contacts, of their targets on social media platforms. Global Secure Access (GSA) is one solution that can reduce this type of phishing activity and manage access to social media sites on company-owned devices.

Post-compromise identity attacks

In addition to using phishing techniques for initial access, in some cases threat actors leverage the identity acquired from their first-stage phishing attack to launch subsequent phishing attacks. These follow-on phishing activities enable threat actors to move laterally within an organization, maintain persistence across multiple identities, and potentially acquire access to a more privileged account or to a third-party organization.

You can harden your environment against internal phishing activity by configuring the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients as well as by educating users to be wary of unsolicited documents and to report suspected phishing messages.

AiTM phishing crafted using legitimate company resources

Storm-0539, a threat actor that persistently targets the retail industry for gift card fraud, uses their initial access to a compromised identity to acquire legitimate emails—such as help desk tickets—that serve as templates for phishing emails. The crafted emails contain links directing users to AiTM phishing pages that mimic the federated identity service provider of the compromised organization. Because the emails resemble the organization’s legitimate messages, lead to convincing AiTM landing pages, and are sent from an internal account, they could be highly convincing. In this way, Storm-0539 moves laterally, seeking an identity with access to key cloud resources.

Intra-organization device code phishing

In addition to their use of device code phishing for initial access, Storm-2372 also leverages this technique in their lateral movement operations. The threat actor uses compromised accounts to send out internal emails with subjects such as “Document to review” and containing a device code authentication phishing payload. Because of the way device code authentication works, the payloads only work for 15 minutes, so Microsoft has seen multiple waves of post-compromise phishing attacks as the threat actor searches for additional credentials.

Figure 5. Storm-2372 lateral movement attempt contains device code phishing payload Defending against credential phishing and social engineering

Defending against phishing attacks begins at the primary gateways: email and other communication platforms. Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365, or the equivalent for your email security solution, to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.

A holistic security posture for phishing must also account for the human aspect of social engineering. Investing in user awareness training and phishing simulations is critical for arming employees with the needed knowledge to defend against tried-and-true social engineering methods. Training can also help when threat actors inevitably refine and improve their techniques. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.

Hardening credentials and cloud identities is also necessary to defend against phishing attacks. By implementing the principles of least privilege and Zero Trust, you can significantly slow down determined threat actors who may have been able to gain initial access and buy time for defenders to respond. To get started, follow our steps to configure Microsoft Entra with increased security.

As part of hardening cloud identities, authentication using passwordless solutions like passkeys is essential, and implementing MFA remains a core pillar in identity security. Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals. Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA. Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.

Finally, a Security Service Edge solution like Global Secure Access (GSA) provides identity-focused secure network access. GSA can help to secure access to any app or resource using network, identity, and endpoint access controls.

Among Microsoft Incident Response cases over the past year where we identified the initial access vector, almost a quarter incorporated phishing or social engineering. To achieve phishing resistance and limit the opportunity to exploit human behavior, begin planning for passkey rollouts in your organization today, and  at a minimum, prioritize phishing-resistant MFA for privileged accounts as you evaluate the effect of this security measure on your wider organization. In the meantime, use the other defense-in-depth approaches I’ve recommended in this blog to defend against phishing and social engineering attacks.

Stay vigilant and prioritize your security at every step.

Recommendations

Several recommendations were made throughout this blog to address some of the specific techniques being used by threat actors tracked by Microsoft, along with essential practices for securing identities. Here is a consolidated list for your security team to evaluate.

• Configure Microsoft Entra with increased security.
• Use the Microsoft Authenticator app for passkeys and MFA.
• Strengthen privileged accounts with phishing resistant MFA.
• Complement MFA with risk-based Conditional Access policies, where sign-in requests are evaluated using additional identity-driven signals like IP address location information or device status, among others. Implementing Microsoft Entra ID Protection with these policies can automatically block or challenge access based on indicators like unfamiliar sign-in patterns or potential token theft attempts. When combined with Global Secure Access (GSA), organizations can extend this protection by enforcing Conditional Access decisions at the network layer to help secure access to any app or resource.
• Only allowing MFA and passkey registrations from trusted locations and devices.
• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365.
• Use attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, to run realistic attack scenarios in your organization for educating users.
• Use Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.
• Block device code flow where possible; if needed, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Configure app consent policies to restrict user consent operations. For example, configure policies to allow user consent only to apps requesting low-risk permissions with verified publishers, or apps registered within your tenant.
• Require authentication strength for device registration in your environment.
• Follow our security best practices for Microsoft Teams.
• Configure the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients.

At Microsoft, we are accelerating security with our work on the Secure by Default framework. Specific Microsoft-managed policies are enabled for every new tenant and raise your security posture with security defaults that provide a baseline of protection for Entra ID and resources like Office 365.

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 Defending against evolving identity attack techniques appeared first on Microsoft Security Blog.

In this blog you will hear directly from Corporate Vice President and Deputy Chief Information Security Officer (CISO) for AI, Yonatan Zunger, about how to build a plan to deploy AI safely. This blog is part of a new ongoing series where our Deputy CISOs share their thoughts on what is most important in their respective domains. In this series you will get practical advice, forward-looking commentary on where the industry is going, things you should stop doing, and more.

How do you deploy AI safely?

As Microsoft’s Deputy CISO for AI, my day job is to think about all the things that can go wrong with AI. This, as you can imagine, is a pretty long list. But despite that, we’ve been able to successfully develop, deploy, and use a wide range of generative AI products in the past few years, and see significant real value from them. If you’re reading this, you’ve likely been asked to do something similar in your own organization—to develop AI systems for your own use, or deploy ones that you’ve acquired from others. I’d like to share some of the most important ways that we think about prospective deployments, ensure we understand the risks, and have confidence that we have the right management plan in place.

This is way more than can fit into a single blog, so this post is just the introduction to a much wider set of resources. In this post, I’ll articulate the basic principles we use in our thinking. These principles are meant to be applicable far beyond Microsoft, and indeed most of them scope far beyond AI—they’re really methods for safely adopting any new technology. Because principles on their own can be abstract, I’m releasing this with a companion video in which I work through a detailed example, taking a hypothetical new AI app (a tool to help loan officers do their jobs at a bank) through this entire analysis process to see how it works.

Watch the video to see a real-life example on how to deploy AI safely

We have even deeper resources coming soon intended to help teams and decision makers innovate safely that will build on this content. Meanwhile, if you want to learn about how Microsoft applies these ideas to safe AI deployment in more detail, you can learn about the various policies, processes, frameworks, and toolboxes we built for our own use on our Responsible AI site.

Basic principles

What does “deploying safely” mean? It doesn’t mean that nothing can go wrong; things can always go wrong. In a safe deployment, you understand as many of the things that can go wrong as possible and have a plan for them that gives you confidence that a failure won’t turn into a major incident, and you know that if a completely unexpected problem arises, you’re ready to respond to that as well.

It also means that you haven’t limited yourself to very specific kinds of problems, like security breaches or network failures, but are just as prepared for privacy failures, or people using the system in an unexpected way, or organizational impacts. After all, there’s no surer guarantee of disaster than a security team saying “that sounds like a privacy problem” while the privacy team says “that sounds like a security problem” and neither team dealing with it. As builders of systems, we need to think about the ways in which our systems might fail, and plan for all of those, where “the systems” includes not just the individual bits of software, but the entire integrated system that they’re a part of—including the people who use them and how they’re used.

These ideas probably sound familiar, because they’re the basics we learned at the start of our careers, and are the same concepts that underlie everything from the National Institute of Standards and Technology (NIST) Risk Management Framework to Site Reliability Engineering. If I had to state them as briefly as possible, the basic rules would be:

1. Understand the things that might go wrong in your system, and for each of those things, have a plan. A “plan” could mean anything from changing how the system works to reduce the impact of a risk, to making the failure of some component no big deal because the larger system compensates for it, to simply knowing that you’ll be able to detect it and have the flexibility and tools to respond when it does.
2. Analyze the entire system, including the humans, for any type of thing that could go wrong. Your “system” means the entire business process that uses it, including the people, and “things that might go wrong” includes anything that could end up with you having to respond to it, whether it’s a security breach or your system ending up on the front page of the paper for all the wrong reasons.
   • Tip: Whether you’re using AI software that you bought or building your own systems, you’re always the builder of your own business processes. Apply your safety thinking to the complete end-to-end process either way.
3. You think about what could go wrong from the day you get the idea for the project and do it continuously until the day it shuts down. Planning for failure isn’t an “exercise”; it’s the parallel partner to designing the features of your system. Just as you update your vision of how the system should work every time you find a new use case or see customer needs changing, you update your vision of how the system might fail whenever it or the situation changes.

You implement these three principles through a fourth one:

4. Make a written safety plan: a discussion of these various risks and your plan for each. Don’t forget to include a brief description of what the system is and what problem it’s meant to solve, or the plan will be illegible to future readers, including yourself.

If your role is to review systems and make sure they’re safe to deploy, that safety plan is the thing you should look at, and the question you need to ask is whether that plan covers all the things that might go wrong (including “how we’ll handle surprises”) and if the proposed solutions make sense. If you need to review many systems, as CISOs so often do, you’ll want your team to create standard forms, tools, and processes for these plans—that is, a governance standard, like Microsoft does for Responsible AI.

These first four rules aren’t specific to AI at all; these are general principles of safety engineering, and you could apply them to anything from ordinary cloud software deployments to planning a school field trip. The hard part that we’ll cover in later materials is how best to identify the way things could go wrong (including when radically new technologies are involved) and build mitigation plans for them. The second rule will repeatedly prove to be the most important, as problems in one component are very often solved by changes in another component—and that includes the people.

Watch the video for guidance for safe AI deployment AI-specific principles

When it comes to building AI systems, we’ve uncovered a few rules that are exceptionally useful. The most important thing we’ve learned is that error is an intrinsic part of how AI works; problems like hallucination or prompt injection are inherent, and if you need a system that deterministically gives the right answer all the time, AI is probably not the right tool for the job. However, you already know how to build reliable systems out of components that routinely err: they’re called “people” and we’ve been building systems out of them for millennia.

The possible errors that can happen in any analysis, recommendation, or decision-making step (human or AI) are:

• Garbage in, garbage out, also known as GIGO—if the input data is bad, the output will be, too.
• Misinterpreted data—if the data provided doesn’t have exactly the same meaning as the analysis expects, situations where they differ can cause subtle but dangerous errors. For example, if analysis of a loan applicant received a number it thought was “mean duration of continuous employment over the past five years,” but was actually receiving “mean duration of each job over the past five years,” it would produce extremely wrong results for consultants and other people who stack short-term jobs.
• Hallucination, also known as false positives—the analysis introduces information not supported by the grounding data.
• Omission, also known as false negatives—the analysis leaves out some critical caveat or context that changes the meaning of the data.
• Unexpected preferences—every summary or recommendation chooses some aspects of the input to emphasize and prioritize over others (that’s the whole point of a summary); are the factors it prioritizes the ones you wanted it to?

We can combine these to add some AI-specific rules:

5. Reason about the safety of AI components by imagining “what would happen if I replaced the AI with a room full of well-intentioned but inexperienced new hires?” Don’t think of the AI like a senior person—think of it like a new hire fresh out of school, enthusiastic, intelligent, ready to help, and occasionally dumb as a rock. Build safety into your process by considering what you’d do for humans in the same place—for example, having multiple sets of (AI or human) eyes on key decisions. This doesn’t mean “human in the loop” at every stage; instead, find the moments where it would make sense for more experienced eyes to step in and check before proceeding.
6. Expect testing to take much more of your time, and coding to take less of your time, than with traditional software. It’s very easy to build AI software that works right in the two cases that you thought of, but much harder to make sure it works right when real user inputs are involved. Build extensive libraries of test cases, including intended uses, things confused users might do, and things threat actors might do; the line between functionality and security testing will be fuzzy. In general, you should think of AI development as a “prototype-break-fix” cycle rather than a “develop-test-ship” cycle.

And some more rules that apply to any analysis, recommendation, or decision-making stage, whether it’s human or AI. (This similarity goes to the heart of Rule 5; it shouldn’t be surprising that humans and AI require similar mitigations!)

7. Accompany decision-making criteria with a suite of test cases, validated by having multiple people evaluate the test cases per the criteria and tweaking the criteria until they agree with each other and your intent. This is a good way to make sure that your written criteria (whether they be guidelines for human raters or AI metaprompts) are understood in line with your intentions. It’s a good idea for the policy writers to provide a bunch of the test cases themselves, because things get lost in translation even between them and the engineering team; you can also use AI to help extend a list of test cases, then manually decide what the expected outputs for each should be. Having multiple reviewers independently decide on expectations is a good way to detect when your intentions weren’t clear even to yourself.
8. Monitor and cross-check decision making. Send some random subset of decisions to multiple (human or AI) reviewers in parallel and monitor inter-rater agreement as a way of measuring if the stated criteria are clear enough to produce consistent answers. Automatically escalate disagreements, as well as “high impact” cases (for example, large-value bank loan decisions) to more experienced people. Simultaneously, log carefully and monitor for the “revealed preferences” of your decision system, to ensure that they align with your intended preferences.
9. Present information carefully. Whenever information transits a people boundary—whether this is AI outputs being presented to a human for a decision, or data collected by one team flowing to analysis run by another team—you have a high risk of misinterpretation. Invest heavily here in clarity: in very sharp and rigorous API definition if it’s machine-to-machine, or in extremely clear user experience if it’s machine-to-human. After all, if you’re running an expensive AI decision to help people and then the information is lost in translation, you aren’t getting any value out of it at all—and people will blame AI for the resulting human errors.

The deepest insight is: novel technologies like AI don’t fundamentally change the way we design for safety; they simply call on us to go back to basic principles and execute on them well.

Safe AI deployment: Watch the video Learn more

You can find a detailed worked example of how to apply these ideas in this video. You can learn more about our responsible AI practices at our Responsible AI site, and about our best practices for avoiding overreliance in our Overreliance Framework.

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 How to deploy AI safely appeared first on Microsoft Security Blog.

I believe we’re at the beginning of something extraordinary.

Today’s AI agents are already impressive—they’re helping software engineers write code, assisting site reliability teams in troubleshooting systems, and handling a variety of analytical tasks. Yet, as capable as these specialized agents are becoming, we’re just beginning to glimpse their potential. The next wave of changes is approaching fast, bringing capabilities that will transform how we work across a wide variety of fields.

At Microsoft, we believe the next 12–24 months will fundamentally change the AI agent space. Instead of simply responding to requests, agentic systems will start working independently, spotting problems, suggesting solutions, and carrying context across conversations. The difference might seem small at first, but you’ll notice it when your agent starts to proactively help you solve problems rather than just follow instructions.

To support this future, we need to evolve the identity standards that underpin how agents access data and act across connected systems—from APIs, code repositories, and data warehouses, to productivity tools, enterprise systems, and sensitive business processes. It starts with OAuth 2.

What’s changing?

At Microsoft, we’re building a robust and sophisticated set of agents. Recently, we launched the public preview of our new Conditional Access Optimizer Agent. It’s a multi-functional AI agent that:

Analyzes an organization’s Conditional Access policies

Identifies security gaps

Recommends policy improvements and simplifications

Deploys new policies in pilot mode

Ensures new users and apps are protected

We’ve also been extensively investing in agents for developer and operations workflows, such as the SWE and SRE agents to help teams boost their productivity when writing and maintaining their applications. As new AI-driven scenarios are introduced, we anticipate an emerging flood of rich, smart, multi-functional, and autonomous agents.

AI agents will augment and amplify the capabilities of an organization. Marketing agents could propose full digital marketing campaign plans, refine and update them based on feedback, and then when the plans are approved, execute them end-to-end. Engineering agents could autonomously create specifications for new features, as well as start to build and test them with minimal human interactions. You might’ve already seen some of these experiences at this year’s Microsoft Build conference. We could see all kinds of agents helping people to manage compliance, onboard new employees, or even run parts of their IT operations more efficiently.

But here’s the thing: today’s OAuth 2 standards weren’t built for the world of AI agents. Some existing efforts, like RFC 9396 – OAuth 2.0 Rich Authorization Requests, set some of the fundamental ideas in motion, but we believe we need a more scalable solution for AI-first scenarios.

Why OAuth 2 needs an update

OAuth 2 works well for today’s task-focused agents that act on behalf of a user. But as agents become more autonomous and capable, a new set of authorization requirements surfaces. Agents need much more granular permissions, and they need to be dynamic, easily revokable, yet auditable. They need to be able to interact securely with other agents across different trust boundaries, as well as handle scenarios where the ownership of an agent changes on the fly. To enable these capabilities, we need to drive a set of changes to existing standards to support them, unlocking the ability of enterprises to adopt them while maintaining compliance and confidence in the security of their data.

Here’s what we think needs to change:

Recognize Agent IDs as first-class actors: Agents need to be distinct from clients. They should have their own identity in the OAuth model. When an agent registers with an IDP, it should be able to register as an agent, not a client. When an agent accesses a resource, it should be able to represent that it is an agent. When a computer-using agent accesses a resource through a client, we need a standards-based approach to represent this interaction.

A yellow square with a black and white logo

AI-generated content may be incorrect.

Have a standard model for granting agents their own permissions: Agents should be able to act with their own defined set of privileges—not just proxy a user’s rights.

Make agent actions transparent and traceable: We need a clear way to distinguish when an agent is acting:

On behalf of a user

On its own behalf

On behalf of another agent or a chain of agents

This is critical for forensics, policy enforcement, and trust.

A diagram of a computer process

AI-generated content may be incorrect.

Enable permission discovery and delegation: Agents should be able to discover the permissions required to perform a task and request them—either directly from the user, from an upstream agent, or through a chain of upstream agents ultimately linked to the user.

A diagram of a process

AI-generated content may be incorrect.

Support for fine-grained, resource specific, least-privilege access: We need updates to the OAuth scopes model to support common approaches to identifying a specific subset of resources a user can delegate access to. For example:

A collection or container of resources, such as all photos from last week

A node in a hierarchy of resources, such as all files in the /taxinfo directory

A specific class or category of resource, like high business impact or confidential

A query, such as SELECT * FROM my_emails WHERE sender LIKE ‘%@microsoft.com’

A specific resource, like {customer_ID, 12345}

We believe this set of targeted updates will give users and organizations the controls, visibility, specificity, and granularity necessary to realize the incredible transformative potential of AI agents.

Let’s build this together

We’re excited about the future of AI agents. But we also know that to get there, we need to evolve the standards that make secure delegation possible.

We’re looking forward to working with our partners in the broader OAuth community, the Model Context Protocol (MCP), and Agent-to-Agent (A2A) protocol steering committees, as well as the machine identity ecosystem to define the right path forward. Microsoft’s recent work in helping shape a more robust authorization specification for MCP together with the broader security community and Anthropic is just the beginning.

If you’re attending Identiverse in Las Vegas next week, I hope you’ll reserve a seat for the AI Agents and the Future of Identity roundtable discussion on Wednesday at 7:15 a.m. with breakfast. You can also drop by the booth or request a meeting at Identiverse with Microsoft Security.

Let’s make sure the next generation of AI agents is not just powerful—but secure, trustworthy, and standards-based.

• Alex
  P.S.: If you’re working in this space, I’d love to hear from you! Drop a note in the comments below.

Footer of post:

Read more on AI agent innovation from Microsoft Security

Microsoft extends Zero Trust to secure the agentic workforce | Microsoft Security Blog

Announcing Microsoft Entra Agent ID: Secure and manage your AI agents | Microsoft Community Hub

Microsoft unveils Microsoft Security Copilot agents and new protections for AI | Microsoft Security Blog

Microsoft Entra Conditional Access optimization agent – Microsoft Entra ID | Microsoft Learn

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

⁠Microsoft Entra News and Insights | Microsoft Security Blog

⁠⁠Microsoft Entra blog | Tech Community

⁠Microsoft Entra documentation | Microsoft Learn

Microsoft Entra discussions | Microsoft Community 

The post The future of AI agents—and why OAuth must evolve appeared first on Microsoft Security Blog.

Executive summary:

Void Blizzard is a new threat actor Microsoft Threat Intelligence has observed conducting espionage operations primarily targeting organizations that are important to Russian government objectives. These include organizations in government, defense, transportation, media, NGOs, and healthcare, especially in Europe and North America. They often use stolen sign-in details that they likely buy from online marketplaces to gain access to organizations. Once inside, they steal large amounts of emails and files. In April 2025, Microsoft Threat Intelligence observed Void Blizzard begin using more direct methods to steal passwords, such as sending fake emails designed to trick people into giving away their login information.

We thank our partners at Netherlands General Intelligence and Security Service (AIVD) and the Netherlands Defence Intelligence and Security Service (MIVD) for the collaboration on investigating Void Blizzard (also known as LAUNDRY BEAR). You can read their statement here. We also thank our partners at the US Federal Bureau of Investigation for their continued collaboration on investigating Void Blizzard targeting.

Microsoft Threat Intelligence Center has discovered a cluster of worldwide cloud abuse activity conducted by a threat actor we track as Void Blizzard (LAUNDRY BEAR), who we assess with high confidence is Russia-affiliated and has been active since at least April 2024. While Void Blizzard has a global reach, their cyberespionage activity disproportionately targets NATO member states and Ukraine, indicating that the actor is likely collecting intelligence to help support Russian strategic objectives. In particular, the threat actor’s prolific activity against networks in critical sectors poses a heightened risk to NATO member states and allies to Ukraine in general.

Void Blizzard’s cyberespionage operations tend to be highly targeted at specific organizations of interest to the Russian government, including in government, defense, transportation, media, non-governmental organizations (NGOs), and healthcare sectors primarily in Europe and North America. The threat actor uses stolen credentials—which are likely procured from commodity infostealer ecosystems—and collects a high volume of email and files from compromised organizations.

In April 2025, Microsoft Threat Intelligence Center observed Void Blizzard evolving their initial access techniques to include targeted spear phishing for credential theft. While Void Blizzard’s tactics, techniques, and procedures (TTPs) are not unique among advanced persistent threat actors or even Russian nation state-sponsored groups, the widespread success of their operations underscores the enduring threat from even unsophisticated TTPs when leveraged by determined actors seeking to collect sensitive information.

In this report, we share our analysis of Void Blizzard’s targeting and TTPs, with the goal of enabling the broader community to apply specific detections and mitigation guidance to disrupt and protect against Void Blizzard’s operations. We extend our gratitude to our partners at the Netherlands General Intelligence and Security Service (AIVD), the Netherlands Defence Intelligence and Security Service (MIVD), and the US Federal Bureau of Investigation for their collaboration in investigating and raising awareness on Void Blizzard activity and tooling to help organizations disrupt and defend against this threat actor.

Void Blizzard targets

Void Blizzard primarily targets NATO member states and Ukraine. Many of the compromised organizations overlap with past—or, in some cases, concurrent—targeting by other well-known Russian state actors, including Forest Blizzard, Midnight Blizzard, and Secret Blizzard. This intersection suggests shared espionage and intelligence collection interests assigned to the parent organizations of these threat actors. Since mid-2024, Microsoft Threat Intelligence has observed Void Blizzard targeting the following industry verticals, many resulting in successful compromises:

• Communications/Telecommunications
• Defense Industrial Base
• Healthcare
• Education
• Government agencies and services
• Information technology
• Intergovernmental organizations
• Media
• NGOs
• Transportation

Void Blizzard regularly targets government organizations and law enforcement agencies, particularly in NATO member states and especially in countries that provide direct military or humanitarian support to Ukraine. Within Ukraine, Void Blizzard has successfully compromised organizations in multiple sectors, including education, transportation, and defense. In October 2024, Void Blizzard compromised several user accounts at a Ukrainian aviation organization that had been previously targeted by Russian General Staff Main Intelligence Directorate (GRU) actor Seashell Blizzard in 2022. This targeting overlap reflects Russia’s long-standing interest in this organization and, more broadly, in aviation-related organizations since Russia’s invasion of Ukraine in 2022. In 2023, another GRU actor, Forest Blizzard, targeted a prominent aviation organization in Ukraine, and since at least August 2024, it has conducted increasing password spray attacks against several NATO member states’ air traffic control providers.

Tools, tactics, and procedures Initial access

Void Blizzard conducts opportunistic yet targeted high-volume cyberoperations against targets of intelligence value to the Russian government. Their operations predominately leverage unsophisticated techniques for initial access such as password spray and using stolen authentication credentials. Microsoft assesses that Void Blizzard procures cookies and other credentials through criminal ecosystems. These credentials are then used to gain access to Exchange and sometimes SharePoint Online for information collection.

In April 2025, we identified a Void Blizzard adversary-in-the-middle (AitM) spear phishing campaign that targeted over 20 NGO sector organizations in Europe and the United States. The threat actor used a typosquatted domain to spoof the Microsoft Entra authentication portal. Use of a typosquatted domain to spoof Microsoft Entra authentication was a newly observed initial access tactic for this threat actor. This new tactic suggests that Void Blizzard is augmenting their opportunistic but focused access operations with a more targeted approach, increasing the risk for organizations in critical sectors.

In this campaign, the threat actor posed as an organizer from the European Defense and Security Summit and sent emails containing messages with a PDF attachment that lured targets with a fake invitation to the Summit.

Figure 1. Phishing email body

The attachment contained a malicious QR code that redirected to Void Blizzard infrastructure micsrosoftonline[.]com, which hosts a credential phishing page spoofing the Microsoft Entra authentication page. We assess that Void Blizzard is using the open-source attack framework Evilginx to conduct the AitM phishing campaign and steal authentication data, including the input username and password and any cookies generated by the server. Evilginx, publicly released in 2017, was the first widely available phishing kit with AitM capabilities.

Figure 2. PDF attachment with malicious QR code Figure 3. Credential phishing page on actor infrastructure Post-compromise activity

Despite the lack of sophistication in their initial access methods, Void Blizzard has been effective in gaining access to and collecting information from compromised organizations in critical sectors.

After gaining initial access, Void Blizzard abuses legitimate cloud APIs, such as Exchange Online and Microsoft Graph, to enumerate users’ mailboxes, including any shared mailboxes, and cloud-hosted files. Once accounts are successfully compromised, the actor likely automates the bulk collection of cloud-hosted data (primarily email and files) and any mailboxes or file shares that the compromised user can access, which can include mailboxes and folders belonging to other users who have granted other users read permissions.

In a small number of Void Blizzard compromises, Microsoft Threat Intelligence has also observed the threat actor accessing Microsoft Teams conversations and messages via the Microsoft Teams web client application. The threat actor has also in some cases enumerated the compromised organization’s Microsoft Entra ID configuration using the publicly available AzureHound tool to gain information about the users, roles, groups, applications, and devices belonging to that tenant.

Mitigation and protection guidance

Microsoft Threat Intelligence recommends organizations that are most likely at risk, primarily those in critical sectors including government and defense, to implement the following recommendations to mitigate against Void Blizzard activity:

Hardening identity and authentication

• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluate the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
• Require multifactor authentication (MFA). While certain attacks attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Microsoft Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop attackers.

Hardening email security

• Manage mailbox auditing to ensure actions performed by mailbox owners, delegates, and admins are automatically logged. New mailboxes should already have this feature turned on by default.
• Run a non-owner mailbox access report in the Exchange Admin Center to detect unauthorized access onto a mailbox.

Hardening against post-compromise activity

• If a breach or compromise via commodity info stealer is suspected, ensure that any accounts that may have been accessed by that machine have their credentials rotated in addition to removing the malware. Given the widespread use of infostealers in attacks, organizations should immediately respond to infostealer activity and mitigate the risk of credential theft to prevent follow-on malicious activity.
• Conduct an audit search in the Microsoft Graph API for anomalous activity.
• Create Defender for Cloud Apps anomaly detection policies.
• Prevent, detect or investigate possible token theft activity by reviewing mitigation techniques.
• If you suspect password spray activity against your organization’s networks, you can refer to this guide for password spray investigation.

Microsoft Defender XDR detections

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

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

Microsoft Defender for Endpoint

The following alert indicates threat actor activity related to Void Blizzard. Note, however, that this alert can be also triggered by Void Blizzard activity that is not related to the activity covered in this report.

• Void Blizzard activity

The following alerts might indicate credential theft activity related to Void Blizzard utilizing commodity information stealers or conducting password spraying techniques. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Information stealing malware activity
• Password spraying

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Password Spray
• Unfamiliar Sign-in properties
• Atypical travel
• Suspicious behavior: Impossible travel activity

Microsoft Defender for Cloud Apps

The following Microsoft Defender for Cloud Apps alerts can indicate associated threat activity. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Impossible travel
• Activity from suspicious IP addresses
• Unusual activities (by user)

Microsoft Defender for Cloud

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• AzureHound tool invocation detected
• Communication with possible phishing domain
• Communication with suspicious domain identified by threat intelligence

Microsoft Entra ID Protection

The following Microsoft Entra ID Protection risk detections inform Entra ID user risk events and can indicate associated threat activity, including unusual user activity consistent with known attack patterns identified by Microsoft Threat Intelligence research. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Anomalous Token (sign-in) (RiskEventType: anomalousToken)
• Password spray (RiskEventType: passwordSpray)
• Anomalous Token (user) (RiskEventType: anomalousToken)
• Attacker in the Middle (RiskEventType: attackerinTheMiddle)
• Activity from Anonymous IP address (RiskEventType: anonymizedIPAddress)
• Microsoft Entra threat intelligence (sign-in): (RiskEventType: investigationsThreatIntelligence)
• Suspicious API Traffic (RiskEventType: suspiciousAPITraffic)

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

Microsoft Defender Threat Intelligence

• Void Blizzard

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 find related Void Blizzard spear phishing activity related to this threat in their networks by running the following queries.

Possible phishing email targets

The following query can help identify possible email targets of Void Blizzard’s spear phishing attempts

EmailEvents | where SenderFromDomain in~ ("ebsumrnit.eu") | project SenderFromDomain, SenderFromAddress, RecipientEmailAddress, Subject, Timestamp

Communication with Void Blizzard domain

The following query can help surface devices that might have communicated with Void Blizzard’s spear phishing domain:

let domainList = dynamic(["micsrosoftonline.com", "outlook-office.micsrosoftonline.com"]); union ( DnsEvents | where QueryType has_any(domainList) or Name has_any(domainList) | project TimeGenerated, Domain = QueryType, SourceTable = "DnsEvents" ), ( IdentityQueryEvents | where QueryTarget has_any(domainList) | project Timestamp, Domain = QueryTarget, SourceTable = "IdentityQueryEvents" ), ( DeviceNetworkEvents | where RemoteUrl has_any(domainList) | project Timestamp, Domain = RemoteUrl, SourceTable = "DeviceNetworkEvents" ), ( DeviceNetworkInfo | extend DnsAddresses = parse_json(DnsAddresses), ConnectedNetworks = parse_json(ConnectedNetworks) | mv-expand DnsAddresses, ConnectedNetworks | where DnsAddresses has_any(domainList) or ConnectedNetworks.Name has_any(domainList) | project Timestamp, Domain = coalesce(DnsAddresses, ConnectedNetworks.Name), SourceTable = "DeviceNetworkInfo" ), ( VMConnection | extend RemoteDnsQuestions = parse_json(RemoteDnsQuestions), RemoteDnsCanonicalNames = parse_json(RemoteDnsCanonicalNames) | mv-expand RemoteDnsQuestions, RemoteDnsCanonicalNames | where RemoteDnsQuestions has_any(domainList) or RemoteDnsCanonicalNames has_any(domainList) | project TimeGenerated, Domain = coalesce(RemoteDnsQuestions, RemoteDnsCanonicalNames), SourceTable = "VMConnection" ), ( W3CIISLog | where csHost has_any(domainList) or csReferer has_any(domainList) | project TimeGenerated, Domain = coalesce(csHost, csReferer), SourceTable = "W3CIISLog" ), ( EmailUrlInfo | where UrlDomain has_any(domainList) | project Timestamp, Domain = UrlDomain, SourceTable = "EmailUrlInfo" ), ( UrlClickEvents | where Url has_any(domainList) | project Timestamp, Domain = Url, SourceTable = "UrlClickEvents" ) | order by TimeGenerated desc Microsoft Sentinel

The Microsoft blog Web Shell Threat Hunting with Azure Sentinel provides hunting queries and techniques for Sentinel-specific threat hunting. Several hunting queries are also available below. 

NOTE: Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. While these queries are not specific to threat actors, they can help you stay vigilant and safeguard your organization from phishing attacks. These queries search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potentially related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

If a query provides high value insights into possible malicious or otherwise anomalous behavior, you can create a custom detection rule based on that query and surface those insights as custom alerts. To do this in the Defender XDR portal, run the query in the Advanced hunting page and select Create detection rule. To do this in the Sentinel portal, use hunting capabilities to run and view the query’s results, then select New alert rule > Create Microsoft Sentinel alert.

Campaign with suspicious keywords

In this detection, we track emails with suspicious keywords in subjects.

let PhishingKeywords = () {pack_array("account", "alert", "bank", "billing", "card", "change", "confirmation","login", "password", "mfa", "authorize", "authenticate", "payment", "urgent", "verify", "blocked");}; EmailEvents | where Timestamp > ago(1d) | where EmailDirection == "Inbound" | where DeliveryAction == "Delivered" | where isempty(SenderObjectId) | where Subject has_any (PhishingKeywords())

Determine successfully delivered phishing emails to Inbox/Junk folder

This query identifies threats which got successfully delivered to Inbox/Junk folder.

EmailEvents | where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder") | 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 | extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

Successful sign-in from phishing link

This content is employed to correlate with Microsoft Defender XDR phishing-related alerts. It focuses on instances where a user successfully connects to a phishing URL from a non-Microsoft network device and subsequently makes successful sign-in attempts from the phishing IP address.

let Alert_List= dynamic([ "Phishing link click observed in Network Traffic", "Phish delivered due to an IP allow policy", "A potentially malicious URL click was detected", "High Risk Sign-in Observed in Network Traffic", "A user clicked through to a potentially malicious URL", "Suspicious network connection to AitM phishing site", "Messages containing malicious entity not removed after delivery", "Email messages containing malicious URL removed after delivery", "Email reported by user as malware or phish", "Phish delivered due to an ETR override", "Phish not zapped because ZAP is disabled"]); SecurityAlert | where AlertName in~ (Alert_List) //Findling Alerts which has the URL | where Entities has "url" //extracting Entities | extend Entities = parse_json(Entities) | mv-apply Entity = Entities on ( where Entity.Type == 'url' | extend EntityUrl = tostring(Entity.Url) ) | summarize Url=tostring(tolower(take_any(EntityUrl))), AlertTime= min(TimeGenerated), make_set(SystemAlertId, 100) by ProductName, AlertName // matching with 3rd party network logs and 3p Alerts | join kind= inner (CommonSecurityLog | where DeviceVendor has_any ("Palo Alto Networks", "Fortinet", "Check Point", "Zscaler") | where DeviceProduct startswith "FortiGate" or DeviceProduct startswith "PAN" or DeviceProduct startswith "VPN" or DeviceProduct startswith "FireWall" or DeviceProduct startswith "NSSWeblog" or DeviceProduct startswith "URL" | where DeviceAction != "Block" | where isnotempty(RequestURL) | project 3plogTime=TimeGenerated, DeviceVendor, DeviceProduct, Activity, DestinationHostName, DestinationIP, RequestURL=tostring(tolower(RequestURL)), MaliciousIP, SourceUserName=tostring(tolower(SourceUserName)), IndicatorThreatType, ThreatSeverity, ThreatConfidence, SourceUserID, SourceHostName) on $left.Url == $right.RequestURL // matching successful Login from suspicious IP | join kind=inner (SigninLogs //filtering the Successful Login | where ResultType == 0 | project IPAddress, SourceSystem, SigniningTime= TimeGenerated, OperationName, ResultType, ResultDescription, AlternateSignInName, AppDisplayName, AuthenticationRequirement, ClientAppUsed, RiskState, RiskLevelDuringSignIn, UserPrincipalName=tostring(tolower(UserPrincipalName)), Name = tostring(split(UserPrincipalName, "@")[0]), UPNSuffix =tostring(split(UserPrincipalName, "@")[1])) on $left.DestinationIP == $right.IPAddress and $left.SourceUserName == $right.UserPrincipalName | where SigniningTime between ((AlertTime - 6h) .. (AlertTime + 6h)) and 3plogTime between ((AlertTime - 6h) .. (AlertTime + 6h))

Phishing link click observed in network traffic

The purpose of this content is to identify successful phishing links accessed by users. Once a user clicks on a phishing link, we observe successful network activity originating from non-Microsoft network devices.

//Finding MDO Security alerts and extracting the Entities user, Domain, Ip, and URL. let Alert_List= dynamic([ "Phishing link click observed in Network Traffic", "Phish delivered due to an IP allow policy", "A potentially malicious URL click was detected", "High Risk Sign-in Observed in Network Traffic", "A user clicked through to a potentially malicious URL", "Suspicious network connection to AitM phishing site", "Messages containing malicious entity not removed after delivery", "Email messages containing malicious URL removed after delivery", "Email reported by user as malware or phish", "Phish delivered due to an ETR override", "Phish not zapped because ZAP is disabled"]); SecurityAlert |where ProviderName in~ ("Office 365 Advanced Threat Protection", "OATP") | where AlertName in~ (Alert_List) //extracting Alert Entities | extend Entities = parse_json(Entities) | mv-apply Entity = Entities on ( where Entity.Type == 'account' | extend EntityUPN = iff(isempty(Entity.UserPrincipalName), tostring(strcat(Entity.Name, "@", tostring (Entity.UPNSuffix))), tostring(Entity.UserPrincipalName)) ) | mv-apply Entity = Entities on ( where Entity.Type == 'url' | extend EntityUrl = tostring(Entity.Url) ) | summarize AccountUpn=tolower(tostring(take_any(EntityUPN))),Url=tostring(tolower(take_any(EntityUrl))),AlertTime= min(TimeGenerated)by SystemAlertId, ProductName // filtering 3pnetwork devices | join kind= inner (CommonSecurityLog | where DeviceVendor has_any ("Palo Alto Networks", "Fortinet", "Check Point", "Zscaler") | where DeviceAction != "Block" | where DeviceProduct startswith "FortiGate" or DeviceProduct startswith "PAN" or DeviceProduct startswith "VPN" or DeviceProduct startswith "FireWall" or DeviceProduct startswith "NSSWeblog" or DeviceProduct startswith "URL" | where isnotempty(RequestURL) | where isnotempty(SourceUserName) | extend SourceUserName = tolower(SourceUserName) | project 3plogTime=TimeGenerated, DeviceVendor, DeviceProduct, Activity, DestinationHostName, DestinationIP, RequestURL=tostring(tolower(RequestURL)), MaliciousIP, Name = tostring(split(SourceUserName,"@")[0]), UPNSuffix =tostring(split(SourceUserName,"@")[1]), SourceUserName, IndicatorThreatType, ThreatSeverity,AdditionalExtensions, ThreatConfidence)on $left.Url == $right.RequestURL and $left.AccountUpn == $right.SourceUserName // Applied the condition where alert trigger 1st and then the 3p Network activity execution | where AlertTime between ((3plogTime - 1h) .. (3plogTime + 1h))

Suspicious URL clicked

This query correlates Microsoft Defender for Office 365 signals and Microsoft Entra ID identity data to find the relevant endpoint event BrowerLaunchedToOpen in Microsoft Defender ATP. This event reflects relevant clicks on the malicious URL in the spear phishing email recognized by Microsoft Defender for Office 365.

// Some URLs are wrapped with SafeLinks // Let's get the unwrapped URL and clicks AlertInfo | where ServiceSource =~ "Microsoft Defender for Office 365" | join ( AlertEvidence | where EntityType =="Url" | project AlertId, RemoteUrl ) on AlertId | join ( AlertEvidence | where EntityType =="MailMessage" | project AlertId, NetworkMessageId ) on AlertId // Get the unique NetworkMessageId for the email containing the Url | distinct RemoteUrl, NetworkMessageId | join EmailEvents on NetworkMessageId // Get the email RecipientEmailAddress and ObjectId from the email | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId | join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId // get the UserSid of the Recipient | extend OnPremSid = AccountSID | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid // Get the Url click event on the recipient device. | join kind = inner (DeviceEvents | where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl) | project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl, InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName ) on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid | distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId, OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName | sort by UrlDeviceClickTime desc

Anomalies in MailItemAccess by GraphAPI

This query looks for anomalies in mail item access events made by Graph API. It uses standard deviation to determine if the number of events is anomalous.

let starttime = 30d; let STDThreshold = 2.5; let allMailAccsessByGraphAPI = CloudAppEvents | where ActionType == "MailItemsAccessed" | where Timestamp between (startofday(ago(starttime))..now()) | where isnotempty(RawEventData['ClientAppId'] ) and RawEventData['AppId'] has "00000003-0000-0000-c000-000000000000" | extend ClientAppId = tostring(RawEventData['ClientAppId']) | extend OperationCount = toint(RawEventData['OperationCount']) | project Timestamp,OperationCount , ClientAppId; let calculateNumberOfMailPerDay = allMailAccsessByGraphAPI | summarize NumberOfMailPerDay =sum(toint(OperationCount)) by ClientAppId,format_datetime(Timestamp, 'y-M-d'); let calculteAvgAndStdev=calculateNumberOfMailPerDay | summarize avg=avg(NumberOfMailPerDay),stev=stdev(NumberOfMailPerDay) by ClientAppId; calculteAvgAndStdev | join calculateNumberOfMailPerDay on ClientAppId | sort by ClientAppId | where NumberOfMailPerDay > avg + STDThreshold * stev | project ClientAppId,Timestamp,NumberOfMailPerDay,avg,stev

The post New Russia-affiliated actor Void Blizzard targets critical sectors for espionage appeared first on Microsoft Security Blog.

Over the past year, Microsoft observed the persistent growth and operational sophistication of Lumma Stealer, an infostealer malware used by multiple financially motivated threat actors to target various industries. Our investigation into Lumma Stealer’s distribution infrastructure reveals a dynamic and resilient ecosystem that spans phishing, malvertising, abuse of trusted platforms, and traffic distribution systems. These findings underscore the importance of collaborative efforts to disrupt cybercrime. Microsoft, partnering with others across industry and international law enforcement, recently facilitated a disruption of Lumma infrastructure.

Lumma Stealer (also known as LummaC2) is a malware as a service (MaaS) offering that is capable of stealing data from various browsers and applications such as cryptocurrency wallets and installing other malware. Microsoft Threat Intelligence tracks the threat actor who developed and maintains the Lumma malware, command-and-control (C2) infrastructure, and the Lumma MaaS as Storm-2477. Affiliates who pay Storm-2477 for the service and operate their own Lumma campaigns access a panel to build the malware binary and manage the C2 communications and stolen information. We have observed ransomware threat actors like Octo Tempest, Storm-1607, Storm-1113, and Storm-1674 using Lumma Stealer in campaigns.

Unlike earlier infostealers that relied heavily on bulk spam or exploits, Lumma Stealer exemplifies a shift toward multi-vector delivery strategies. Its operators demonstrate resourcefulness and proficiency in impersonation tactics. The Lumma Stealer distribution infrastructure is flexible and adaptable. Operators continually refine their techniques, rotating malicious domains, exploiting ad networks, and leveraging legitimate cloud services to evade detection and maintain operational continuity. This dynamic structure enables operators to maximize the success of campaigns while complicating efforts to trace or dismantle their activities.

The growth and resilience of Lumma Stealer highlights the broader evolution of cybercrime and underscores the need for layered defenses and industry collaboration to counter threats. In this blog post, we share our analysis of Lumma Stealer and its infrastructure and provide guidance on how users and organizations can protect themselves from this threat. Microsoft remains committed to sharing insights, developing protections, and working with partners across industries to disrupt malicious ecosystems and safeguard users worldwide.

Figure 1. Heat map detailing global spread of Lumma Stealer malware infections and encounters across Windows devices. Lumma Stealer delivery techniques

Lumma Stealer leverages a broad and evolving set of delivery vectors. Campaigns often combine multiple techniques, dynamically adapting to evade detection and increase infection success rates. Delivery infrastructure is designed to be ephemeral, shifting rapidly across domains, platforms, and geographies to avoid takedowns.

• Phishing emails: Lumma Stealer emails impersonate known brands and services to deliver links or attachments. These campaigns involve expertly crafted emails designed to evoke urgency, often masquerading as urgent hotel reservation confirmations or pending cancellations. The emails lead victims to cloned websites or malicious servers that deploy the Lumma payload to the targets’ environment.

• Malvertising: Threat actors inject fake advertisements into search engine results, targeting software-related queries such as “Notepad++ download” or “Chrome update.” Clicking these poisoned links leads users to cloned websites that closely mimic legitimate vendors but instead deliver the Lumma Stealer.
• Drive-by download on compromised websites: Threat actors were observed compromising groups of legitimate websites, typically through a particular vulnerability or misconfiguration. They modify site content by inserting malicious JavaScript. The JavaScript runs when sites are visited by unsuspecting users, leading to delivery of a payload, intermediary script, or displaying further lures to convince users to perform an action.
• Trojanized applications: In many campaigns, cracked or pirated versions of legitimate applications are bundled with Lumma binaries and distributed through file-sharing platforms. These modified installers often contain no visible payload during installation, executing the malware silently post-launch.
• Abuse of legitimate services and ClickFix: Public repositories like GitHub are abused and populated with scripts and binaries, often disguised as tools or utilities. A particularly deceptive method involves fake CAPTCHA pages, commonly observed in the ClickFix ecosystem. Targets are instructed to copy malicious commands into their system’s Run utility under the pretense of passing a verification check. These commands often download and execute Lumma directly in memory, using Base64 encoding and stealthy delivery chains.
• Dropped by other malware: Microsoft Threat Intelligence observed other loaders and malware such as DanaBot delivering Lumma Stealer as an additional payload.

All these mechanisms reflect threat actor behavior that prioritizes abuse of user trust, manipulation of legitimate infrastructure, and multi-layered distribution chains designed to evade both technical and human defenses. The following sections discuss some examples of campaigns where the mentioned distribution methods were used to deliver Lumma Stealer.

Drive-by download campaign leveraging EtherHiding and ClickFix to deliver Lumma

In early April 2025, Microsoft observed a cluster of compromised websites leveraging EtherHiding and ClickFix techniques to install Lumma Stealer. EtherHiding is a technique that involves leveraging smart contracts on blockchain platforms like Binance Smart Chain (BSC) to host parts of malicious code. Traditional methods of blocking malicious code, such as IP or domain blocking or content-based detections, are less effective against EtherHiding because the code is embedded in the blockchain. Meanwhile, in the ClickFix technique, a threat actor attempts to take advantage of human problem-solving tendencies by displaying fake error messages or prompts that instruct target users to fix issues by copying, pasting, and launching commands that eventually result in the download of malware.

Figure 2. Attack flow for ClickFix to Lumma Stealer

In this campaign, the JavaScript injected into compromised websites directly contacted BSC to retrieve the ClickFix code and lure, which was then presented to the target. Users needed to click the “I’m not a robot” prompt, at which point a command was copied into their clipboard. Users were then instructed to paste and launch this command via the Windows Run prompt. The command downloaded and initiated further code using mshta from check.foquh[.]icu.

Figure 3. Compromised website used EtherHiding and ClickFix techniques to present a fake CAPTCHA lure to visitors Figure 4. Snippet of the injected JavaScript after Base64 decoding. It implements the EtherHiding technique and communicates with data-seed-prebsc-1-s1.bnbchain[.]org to fetch ClickFix code. Figure 5. This fake verification page is the final part of the ClickFix technique. It instructs users how to launch a malicious command. The command was silently copied into their clipboard during the previous step when they clicked “I’m not a robot”. Email campaign targeting organizations in Canada to deliver Lumma Stealer

On April 7, 2025, Microsoft Threat Intelligence observed an email campaign consisting of thousands of emails targeting organizations in Canada. The emails used invoice lures for a fitness plan or an online education platform. The emails’ subject lines were personalized to include recipient-specific details such as “Invoice for [recipient email]”. Notably, the attack chain utilized multiple tools available for purchase on underground forums for traffic filtering and social engineering.

The emails contained URLs leading to the Prometheus traffic direction system (TDS) hosted on numerous compromised sites. The TDS in turn, redirected users to the attacker-controlled website binadata[.]com that hosted the ClickFix social engineering framework. Like the previous campaign, targets were instructed to click a “I’m not a robot” prompt and run malicious code via a multi-step process. The malicious code was an mshta command that downloaded and executed JavaScript from the IP address 185.147.125[.]174. The JavaScript ran a PowerShell command that downloaded more PowerShell code, which finally downloaded and launched a Lumma Stealer executable. Notably, Xworm malware was also bundled into this executable.

Figure 6. Attack flow for ClickFix leading to Lumma Stealer targeting users in Canada Figure 7. Fitness plan subscription themed email lure Figure 8. Screenshot of the ClickFix landing after Prometheus TDS redirection Lumma Stealer malware analysis

The core Lumma Stealer malware is written in a combination of C++ and ASM. The malware author designed it as a MaaS offering. Threat actors can access the panel to build the malware binary and manage the C2 communications and stolen information. The core binary is obfuscated with advanced protection such as low-level virtual machine (LLVM core), Control Flow Flattening (CFF), Control Flow Obfuscation, customized stack decryption, huge stack variables, and dead codes, among others. These techniques are implemented on the critical functions to make static analysis difficult, as these can cause tools like Hex-Rays’ IDA fail to produce equivalent decompiled codes. In addition, most of the critical APIs are implemented via low-level syscalls and Heavens Gate Technology.

Lumma Stealer is designed to steal from browsers based on Chromium and Mozilla technology, including Microsoft Edge. In addition, it has the capability to install other malware or plugins, including Clipboard stealer plugin and coin miners, either by downloading to disk or directly in memory.

Process injection and process hollowing

Lumma loader may use process hollowing to inject its malicious payload into legitimate system processes like msbuild.exe, regasm.exe, regsvcs.exe, and explorer.exe. This technique enables execution under the guise of a trusted binary to bypass behavioral detection and endpoint monitoring tools.

Information-stealing capabilities

Lumma Stealer targets a comprehensive set of user data using a specialized collection routine for each type of data. These capabilities have evolved over time, and Microsoft Threat Intelligence has recently observed that the instructions for the target credentials are specified in the configuration file retrieved from the active C2 server. The configuration file is divided into several parts: the “ex” section that pertains to the target list of apps for cryptocurrency wallets and extensions, and “c” sections that pertain to the list of applications and configuration details for browsers, user file’s locations, and other applications.

• Browser credentials and cookies: Lumma Stealer extracts saved passwords, session cookies, and autofill data from Chromium (including Edge), Mozilla, and Gecko-based browsers.
• Cryptocurrency wallets and extensions: Lumma Stealer actively searches for wallet files, browser extensions, and local keys associated with wallets like MetaMask, Electrum, and Exodus.
• Various applications: Lumma Stealer targets data from various virtual private networks (VPNs) (.ovpn), email clients, FTP clients, and Telegram applications.  
• User documents: Lumma Stealer harvests files found on the user profiles and other common directories, especially those with .pdf, .docx, or .rtf extensions.
• System metadata: Lumma Stealer collects host telemetry such as CPU information, OS version, system locale, and installed applications for tailoring future exploits or profiling victims.

Figure 9. Lumma Stealer configuration file C2 communication

Lumma Stealer maintains a robust C2 infrastructure, using a combination of hardcoded tier 1 C2s that are regularly updated and reordered, and fallback C2s hosted as Steam profiles and Telegram channels that also point to the tier 1 C2s. The Telegram C2, if available, is always checked first, while the Steam C2 is checked only when all the hardcoded C2s are not active. To further hide the real C2 servers, all the C2 servers are hidden behind the Cloudflare proxy.

While Lumma Stealer affiliates share the tier 1 C2s, there is a capability to add a personal tier 1 C2 domain for an extra cost. The diagram below shows an overview of the Lumma Stealer infrastructure. All traffic is encrypted by HTTPS.

Figure 10. Lumma Stealer C2 communication

Different types of obfuscation are applied to each set of C2 servers. For example, the hardcoded list of C2s, and including the Telegram fallback C2 URL are protected with ChaCha20 crypto, while the Steam profile fallback C2 URL is encrypted using custom stack-based crypto algorithm that can change on each version of Lumma malware.

We have identified up to six versions of Lumma Stealer, and while each of these versions focuses on improving techniques to evade antivirus detections, there are also several changes in the C2 communication protocol and formats such as the C2 domains, URI path, POST data, and others. The core Lumma malware stores the build date as part of the embedded configuration to keep track of improvements, but in our investigation, we tracked major changes using the labels “version 1” through “version 6”.

Lumma Stealer keeps track of the active C2 for sending the succeeding commands. Each command is sent to a single C2 domain that is active at that point. In addition, each C2 command contains one or more C2 parameters specified as part of the POST data as form data. The parameters are:  

• act: Indicates the C2 command. Note: This C2 parameter no longer exists in Lumma version 6.
• ver: Indicates C2 protocol version. This value is always set to 4.0 and has never changed since the first version Lumma.
• lid (for version 5 and below)/uid (for version 6): This ID identifies the Lumma client/operator and its campaign.
• j (for version 5 and below )/cid (for version 6): This is an optional field that identifies additional Lumma features.
• hwid: Indicates the unique identifier for the victim machine.
• pid: Used in SEND_MESSAGE command to identify the source of the stolen data. A value of 1, indicates it came from the Lumma core process.

The following are some of the most common Lumma Stealer C2 commands and associated parameters:

• PING / LIFE: Initial command to check if the C2 is active. Note: This command does not exist in version 6.
  • act=life
• RECEIVE_MESSAGE: Command to download the stealer’s configuration. As noted above, this contains the specifications on the list of targets.
  • version 3 and below: act=recive_message&ver=4.0&lid=[<lid_value>]&j=[<j_value>]
  • version 4 and 5: act=receive_message&ver=4.0&lid=[<lid_value>]&j=[<j_value>]
  • version 6: uid=<uid_value>&cid=[<cid_value>]
• SEND_MESSAGE: Command to send back stolen data in chunks. The C2 parameters are specified as individual section in the whole POST data. The fields included are act=send_message, hwid, pid, lid/uid, and j/cid. The act field was removed in version 6.
• GET_MESSAGE: Command to download the second configuration. This configuration contains information about the plugins and additional malware to install on the target systems. We have observed that in most cases this command will respond with valid but empty records “[]”, meaning nothing to download. So far, we have observed Lumma Stealer installing an updated version of the Clipboard stealer plugin and coin miners.
  • versions 5 and below: act=get_message&ver=4.0&lid=[<lid_value>]&j=[<j_value>]&hwid=<hwid_value>
  • version 6: uid=<uid_value>&cid=[<cid_value>]&hwid=<hwid_value>

Microsoft Digital Crimes Unit (DCU) engineered tools that identify and map the Lumma Stealer C2 infrastructure. As part of the disruption announced on May 21, Microsoft’s DCU has facilitated the takedown, suspension, and blocking of approximately 2,300 malicious domains that formed the backbone of the Lumma Stealer infrastructure.  More details of this operation are presented in the DCU disruption announcement.

Recommendations

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

Strengthen Microsoft Defender for Endpoint configuration

• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Enable network protection in Microsoft Defender for Endpoint.
• Turn on web protection.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.    
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
  • Block JavaScript or VBScript from launching downloaded executable content
  • Block process creations originating from PSExec and WMI commands
  • Block credential stealing from the Windows local security authority subsystem
  • Block use of copied or impersonated system tools

Strengthen operating environment configuration

• Require multifactor authentication (MFA). While certain attacks such as adversary-in-the-middle (AiTM) phishing attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
• Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Encourage users to use Microsoft Edge with Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable Network Level Authentication for Remote Desktop Service connections.
• Enable Local Security Authority (LSA) protection to block credential stealing from the Windows local security authority subsystem.
• AppLocker can restrict specific software tools prohibited within the organization, such as reconnaissance, fingerprinting, and RMM tools, or grant access to only specific users.

Detection details

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

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Behavior:Win32/LuammaStealer
• Trojan:JS/LummaStealer
• Trojan:MSIL/LummaStealer
• Trojan:Win32/LummaStealer
• Trojan:Win64/LummaStealer
• TrojanDropper:Win32/LummaStealer
• Trojan:PowerShell/Powdow
• Trojan:Win64/Shaolaod
• Behavior:Win64/Shaolaod
• Behavior:Win32/MaleficAms
• Behavior:Win32/ClickFix
• Behavior:Win32/SuspClickFix
• Trojan:Win32/ClickFix
• Trojan:PowerShell/ClickFixObfus
• Behavior:Win32/RegRunMRU
• Trojan:HTML/FakeCaptcha
• Trojan:Script/SuspDown

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity:

• Suspicious command in RunMRU registry
• Possible Lumma Stealer activity
• Information stealing malware activity
• Suspicious PowerShell command line
• Use of living-off-the-land binary to run malicious code
• Possible theft of passwords and other sensitive web browser information
• Suspicious DPAPI Activity
• Suspicious mshta process launched
• Renamed AutoIt tool
• Suspicious phishing activity detected
• Suspicious implant process from a known emerging threat
• A process was injected with potentially malicious code
• Process hollowing detected
• Suspicious PowerShell download or encoded command execution
• A process was launched on a hidden desktop

Microsoft Defender for Office 365

Microsoft Defender for Office 365 identifies and blocks malicious emails. These alerts, however, can also be triggered by unrelated threat activity:

• A potentially malicious URL click was detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email reported by user as malware or phish

Defender for Office 365 also detects and blocks Prometheus TDS, EtherHiding patterns, ClickFix landing pages.

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

Microsoft Defender Threat Intelligence

• Storm-1865 phishing campaigns over vendor platforms lead to payment data theft and fraudulent charges
• Lumma Stealer
• Malvertising campaign leads to info stealers hosted on GitHub
• ClickFix technique leverages clipboard to run malicious commands

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:

ClickFix commands execution

Identify ClickFix commands execution.

DeviceRegistryEvents | where ActionType =~ "RegistryValueSet" | where InitiatingProcessFileName =~ "explorer.exe" | where RegistryKey has @"\CurrentVersion\Explorer\RunMRU" | where RegistryValueData has "✅" or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^") and RegistryValueData matches regex "[\u0400-\u04FF\u0370-\u03FF\u0590-\u05FF\u0600-\u06FF\u0E00-\u0E7F\u2C80-\u2CFF\u13A0-\u13FF\u0530-\u058F\u10A0-\u10FF\u0900-\u097F]") or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1")) or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList") or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell") and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content") or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

DPAPI decryption via AutoIT or .NET Framework processes

Identify DPAPI decryption activity originating from AutoIT scripts .NET Framework processes.

DeviceEvents | where ActionType == "DpapiAccessed" | where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe" or InitiatingProcessImageFilePath has "\\windows\\microsoft.net\\framework\\" or InitiatingProcessFileName =~ "powershell.exe" | where (AdditionalFields has_any("Google Chrome", "Microsoft Edge") and AdditionalFields has_any("SPCryptUnprotect")) | extend json = parse_json(AdditionalFields) | extend dataDesp = tostring(json.DataDescription.PropertyValue) | extend opType = tostring(json.OperationType.PropertyValue) | where dataDesp in~ ("Google Chrome", "Microsoft Edge", "Chromium", "Opera", "Opera GX", "IMAP Password", "Brave Browser", "AVG Secure Browser") and opType =~ "SPCryptUnprotect" | project Timestamp, ReportId, DeviceId, ActionType, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, AdditionalFields, dataDesp, opType

Sensitive browser file access via AutoIT or .NET Framework processes

Identify .NET Framework processes (such as RegAsm.exe, MSBuild.exe, etc.) accessing sensitive browser files.

let browserDirs = pack_array(@"\Google\Chrome\User Data\", @"\Microsoft\Edge\User Data\", @"\Mozilla\Firefox\Profiles\"); let browserSensitiveFiles = pack_array("Web Data", "Login Data", "key4.db", "formhistory.sqlite", "cookies.sqlite", "logins.json", "places.sqlite", "cert9.db"); DeviceEvents | where AdditionalFields has_any ("FileOpenSource") // Filter for "File Open" events. | where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe" or InitiatingProcessImageFilePath has "\\windows\\microsoft.net\\framework\\" or InitiatingProcessFileName =~ "powershell.exe" | where (AdditionalFields has_any(browserDirs) or AdditionalFields has_any(browserSensitiveFiles)) | extend json = parse_json(AdditionalFields) | extend File_Name = tostring(json.FileName.PropertyValue) | where (File_Name has_any (browserDirs) and File_Name has_any (browserSensitiveFiles)) | project Timestamp, ReportId, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, File_Name Learn more

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

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

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

The post Lumma Stealer: Breaking down the delivery techniques and capabilities of a prolific infostealer appeared first on Microsoft Security Blog.

Microsoft’s 2025 Work Trend Index

Read more ↗

Agentic AI transformation is giving rise to the Frontier Firm—a new type of organization characterized by on-demand intelligence and a workforce where humans and agents work in tandem. According to Microsoft’s 2025 Work Trend Index, we expect every organization will be on their journey to becoming a Frontier Firm within the next two to five years. 

And as AI transforms every aspect of our lives and unlocks unprecedented possibilities, it must be grounded in security—starting with a Zero Trust foundation to protect the workforce and a new generation of Frontier Firms. 

Microsoft is committed to helping customers build a strong security foundation from the start. At Microsoft Build 2025, we’re taking important steps to secure the agentic workforce.

Secure and manage agent identities with Microsoft Entra

Security starts with identity. Identity-based cyberattacks have consistently been one of the top threat vectors since the cloud era. The number of password cyberattacks has increased to approximately 7,000 password attacks per second, and identity-based cyberattacks now account for nearly 80% of breaches.1 Identity is the new perimeter and Microsoft Entra, with more than 900 million monthly active users today, plays a pivotal role in securing all identities in the agentic era. 

We are excited to introduce Microsoft Entra Agent ID, which extends identity management and access capabilities to AI agents. Now, AI agents created within Microsoft Copilot Studio and Azure AI Foundry are automatically assigned identities in a Microsoft Entra directory—analogous to etching a unique VIN into every new car and registering it before it leaves the factory—centralizing agent and user management in one solution. 

Agentic AI is gaining momentum for its ability to combine large language models with reasoning to deliver real outcomes. As we scale autonomous capabilities, identity becomes critical—robust authentication, access provisioning, fine-grained authorization, and governance are essential. Microsoft Entra Agent ID is a huge step in delivering industry thought leadership with a tangible solution. 

—Frank Dickson, Group Vice President of Security and Trust, IDC Partnering with ServiceNow and Workday

And as AI agents increasingly join and reshape the workforce, it’s crucial that workforce systems tap into Microsoft Entra’s expanded identity capabilities for agents. That’s why we are excited to partner with leading providers like ServiceNow and Workday. As part of this, we’ll integrate Microsoft Entra Agent ID with the ServiceNow AI Platform and the Workday Agent System of Record. This will allow for automated provisioning of identities for future digital employees.

Learn more about Microsoft Entra Agent ID Secure data and compliance for AI agents with Microsoft Purview 

With the adoption of generative AI apps and models—and now agents—other types of risks beyond identity have emerged such as data oversharing and leaks, new AI-specific vulnerabilities and cyberthreats, and non-compliance with stringent regulatory requirements.  

To give organizations the tools needed to help secure and govern AI agents, Microsoft Purview data security and compliance controls is now extended to:

• Any custom-built AI app with the new Microsoft Purview software development kit (SDK).
• Enabled natively for AI agents built within Azure AI Foundry and Copilot Studio.

This means that AI agents can now inherently benefit from Microsoft Purview’s robust data security and compliance capabilities. Developers can leverage these controls to help reduce the risk of their AI applications oversharing or leaking data, and to support compliance efforts, while security teams gain visibility into AI risks and mitigations. This integration improves AI data security and streamlines compliance management for development and security teams.

Learn more about Microsoft Purview Proactively secure agents with Microsoft Defender 

Finally, to help developers address critical AI risks, Microsoft Defender now integrates AI security posture management recommendations and runtime threat protection alerts directly into Azure AI Foundry. This integration reduces the tooling gap between security and development teams so developers can proactively mitigate AI application risks and vulnerabilities from within the development environment and more quickly reduce surface area risk—empowering developers to enhance the security of AI applications. 

Learn more about Microsoft Defender

These announcements underscore our commitment to providing comprehensive security and governance for AI, with technology built on the security lessons of the past and in line with our Secure Future Initiative principles. By embedding identity, security, and governance for agents into Microsoft’s agent-building spaces with seamless integration with Microsoft Entra, Microsoft Purview, and Defender, we are helping organizations innovate more securely with AI.  

More details can be found on Tech Community.

1 Microsoft Digital Defense Report 

The post Microsoft extends Zero Trust to secure the agentic workforce appeared first on Microsoft Security Blog.

In this blog, you’ll learn more about how the Microsoft Secure Future Initiative (SFI)—a real-world case study on Zero Trust—aligns with Zero Trust strategies. We’ll share key updates from the April 2025 SFI progress report and practical Zero Trust guidance to help you strengthen your organization’s security posture. Whether you’re looking to enhance protection, reduce risk, or future-proof your environment, this blog offers actionable insights to support your journey toward a more secure future.

Get started with the Zero Trust security model

The Zero Trust security model offers longstanding, proven benefits. Zero Trust minimizes the attack surface and makes it significantly harder for cyberattackers to gain illicit access, whether from outside or inside an organization’s network. Zero Trust is also great at securing hybrid and remote work environments, helping to facilitate secure modernization efforts. Microsoft strongly believes in these benefits and works diligently to share resources, insights, and tools like Zero Trust workshops with customers. As Microsoft innovates in the Zero Trust space, it shares insights with the technology industry and its customers.

In November of 2023, we launched the Secure Future Initiative—a multiyear effort to revolutionize the way we design, build, test, and operate our products and services in order to achieve the highest security standards. In May 2024, Microsoft expanded the Secure Future Initiative to include six engineering pillars and 28 aligned objectives. Engineering owners were assigned to each pillar and established an initial body of work to advance each objective, articulated as standards and measured as key results. In many cases, these objectives and standards are stringent applications of Zero Trust for Microsoft’s unique requirements as a leading hyper-scale cloud operator, provider of cloud services and products, and as a major enterprise target for bad actors.

Zero Trust Workshop

A comprehensive technical guide to help customers and partners adopt a Zero Trust strategy and deploy security solutions end-to-end to secure their organizations. Learn more.

Zero Trust: What it means for you

Zero Trust assumes cyberattackers can come from anywhere—inside or outside your network. This means that you must “never trust, always verify.” In practice, it also means every access request must be authenticated, authorized, and continuously validated—giving you greater confidence that only the right people and devices can connect to your resources.

How Microsoft helps you put Zero Trust into action

• Proven guidance and collaboration: We align with the National Institute of Standards and Technology (NIST), The Open Group, the Cybersecurity and Infrastructure Security Agency (CISA), MITRE, and others, helping our customers benefit from industry-standard frameworks and best practices.
• End-to-end deployment support: From planning to rollout, Microsoft experts, tools, and partner ecosystem guide customers through each of our six security pillars: identities, endpoints, applications, infrastructure, network, and data.
• AI-ready security: We’ve extended Zero Trust to cover AI workloads and models, embedding Microsoft solutions and governance controls at every layer, so our customers can innovate confidently.

With this comprehensive approach from Microsoft, customers don’t just learn the principles—they gain the ability to apply them across their environment to help reduce risk, simplify operations, and accelerate secure modernization.

Learnings from the Secure Future Initiative for your Zero Trust journey

Microsoft processes more than 84 trillion security signals every day—from devices and endpoints to cloud services and applications—giving us robust visibility into emerging cyberthreats and attack patterns.1 By integrating data and insights with a “never trust, always verify” approach, the Secure Future Initiative at Microsoft builds on established Zero Trust strategies—turning architecture into practical implementation. Insights from this experience can enable you to expedite your Zero Trust implementations. 

Key insights from SFI

The journey Microsoft has gone on while implementing the Secure Future Initiative surfaced these practical lessons: use them to accelerate your own security improvements.

Read the April 2025 Secure Future Initiative updates Lesson 1: Set priorities and measure progress 

Based on our priorities, we developed six pillars and 28 objectives to help us focus on what truly matters. You can do likewise: analyze your top risks, then group them into a set of measurable objectives. This gives your team a clear roadmap and helps prioritize efforts that move the needle.

Lesson 2: Align culture with security goals

We learned that tools alone don’t stick—people do. The Secure Future Initiative’s emphasis on culture, clear security objectives, ongoing training, and individual performance goals creates accountability. Translate this by embedding security accountability into every role and offering continuous, role-based training.

Lesson 3: Strengthen security governance

With SFI, integrating Deputy CISOs from key product and functional areas into the Governance Council has advanced security as a core part of development. That makes it more than just a checkpoint, enabling earlier risk mitigation and improved resilience at scale. You can evolve your approach to governance in step with your growth and key functional areas to ensure visibility and accountability. This will help you accelerate Zero Trust maturity and stay ahead of emerging cyberthreats.

Lesson 4: You can’t protect what you can’t see 

With the Secure Future Initiative, currently, more than 99% of network devices are logged in a central repository for full lifecycle management. These devices use centralized authentication and audit trails, are configured with Access Control Lists (ACLs) for IPv4/v6 to restrict lateral movement and have safeguards in place to prevent key compromise or abuse. Apply this by developing an inventory of your own environment and implementing isolation, monitoring and secure operations. 

Lesson 5: Share learnings and build feedback loops

The Secure Future Initiative is a living case study—sharing progress, learnings, and best practices through reports and blogs. You can also adopt a similar mindset: document what works, share internally and externally (where appropriate), and continuously refine your Zero Trust journey based on your own real-world experiences.

Build secure by design, secure by default, and secure operations

The Secure Future Initiative embeds three foundational principles into everything we do, and you can too:

• Secure by design: Incorporate threat modeling and risk assessments at the earliest planning phases.
• Secure by default: Enable guardrails and policies out of the box so users—and cyberattackers—can’t easily disable them.
• Secure operations: Continuously monitor, test, and iterate on defenses as cyberthreats evolve.

Download our Secure by design: A UX toolkit to integrate these checklists into your development pipelines today.

Key customer takeaways from the April 2025 Secure Future Initiative report

You can learn more about the progress we have made improving our security posture in the April 2025 progress report.  

Below are learnings from that report, and examples of how you can improve your security posture by applying the Zero Trust framework and principles.

1. Protect identities and secrets

Validate controls with attack simulations: Use red team exercises or breach-and-attack-simulation tools to test your identity protections (multifactor authentication, conditional access, just-in-time privilege). Identify gaps, then tune policies and workflows to close them.

2. Protect tenants and isolate production systems

Map and limit lateral paths: Graph your environment’s trust relationships (subscriptions, resource groups, service connections). Pinpoint where a cyberattacker could “hop,” then apply micro-segmentation, just-in-time network access, or privileged identity management to contain any breach.

3. Protect networks

Inventory, monitor, and segment: Ensure every device, virtual machine, and service is inventoried and sending telemetry. Lock down network flows with Zero Trust network policies and micro-segmentation. Use continuous monitoring to detect misconfigurations before they become vulnerabilities.

4. Protect engineering systems

Enforce secure build pipelines: Assign clear code-ownership and integrate security gates into your continuous integration/continuous delivery (CI/CD) pipeline. Adopt infrastructure-as-code templates with embedded guardrails and automatically remediate any drift from your security baseline.

5. Monitor and detect threats

Test your detection end-to-end: Regularly run realistic cyberattack simulations (for example, breach-and-attack-simulation, purple team exercises) across all clouds and on-premises environments. Validate that alerts fire correctly and that your security operations center (SOC) workflows drive timely investigation and response.

6. Accelerate response and remediation

Automate patching at scale: Implement automated operating system (OS) and application updates (Microsoft has deployed automated operating system upgrades to 86% of our first-party Virtual Machine Scale Sets (VMSS)-based services, resulting in more than 91 million upgrades in 2024). Shift left on vulnerability management: integrate scanning and patch-orchestration into your DevOps pipelines.

By adopting these practices, you can harden your Zero Trust posture, reduce risk, and accelerate secure modernization—no matter where you are on your journey.

Additional resources and action items

Get started on your Zero Trust journey: Visit the Microsoft Zero Trust webpage, access the Zero Trust Adoption Framework in the Microsoft Zero Trust guidance center, and download the self-serve Zero Trust Workshop Assessment today.

Read the April 2025 report from the Secure Future Initiative and visit the Microsoft Secure Future Initiative page for more information and resources.

Talk to our experts: Connect through your Microsoft account team or submit a request on the Microsoft Security contact page.

Work with a trusted partner: Use the Microsoft Solution Partner directory to find specialists who can help you deploy and optimize your strategy.

Join the community: Get direct access to engineers and early insights via the Security Tech Community and Customer Connection Program.

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.

1Microsoft unveils Microsoft Security Copilot agents and new protections for AI, March 24, 2025.

The post ​​How the Microsoft Secure Future Initiative brings Zero Trust to life appeared first on Microsoft Security Blog.

Since April 2024, the threat actor that Microsoft Threat Intelligence tracks as Marbled Dust has been observed exploiting user accounts that have not applied fixes to a zero-day vulnerability (CVE-2025-27920) in the messaging app Output Messenger, a multiplatform chat software. These exploits have resulted in collection of related user data from targets in Iraq. Microsoft Threat Intelligence assesses with high confidence that the targets of the attack are associated with the Kurdish military operating in Iraq, consistent with previously observed Marbled Dust targeting priorities.

Microsoft Threat Intelligence assesses with moderate confidence that Marbled Dust conducts reconnaissance to determine whether their targets are Output Messenger users and chooses this attack vector based on that knowledge. Successful exploitation allows the threat actor to deliver multiple malicious files and exfiltrate data from targets.

Upon discovering the Output Messenger zero-day vulnerability (CVE-2025-27920), Microsoft notified Srimax, the developer of the messaging app, who issued a software update. Microsoft also identified a second vulnerability in Output Messenger (CVE-2025-27921) for which Srimax has also released a patch; however, Microsoft has not observed exploitation of this second vulnerability. We acknowledge Srimax for their collaboration and for addressing both vulnerabilities.

In this blog, we present details on how Marbled Dust uses the Output Messenger zero-day exploit in the attack chain of this campaign. We also share mitigation and protection guidance, and detection details and hunting queries. Microsoft Threat Intelligence recommends users upgrade Output Messenger to its latest version to address the vulnerability leveraged by Marbled Dust.

Who is Marbled Dust?

Microsoft Threat Intelligence assesses that Marbled Dust operates as a Türkiye-affiliated espionage threat actor. Marbled Dust targets entities in Europe and the Middle East, particularly government institutions and organizations that likely represent counter interests to the Turkish government, as well as targets in the telecommunications and information technology sectors. Marbled Dust overlaps with activity tracked by other security vendors as Sea Turtle and UNC1326.

In previous campaigns, Marbled Dust was observed scanning targeted infrastructure for known vulnerabilities in internet-facing appliances or applications and exploiting these vulnerabilities as a means of gaining initial access to target infrastructure providers. They were also observed using access to compromised DNS registries and/or registrars to reset the DNS server configuration of government organizations in various countries to intercept traffic, enabling them to log and reuse stolen credentials.

This new attack signals a notable shift in Marbled Dust’s capability while maintaining consistency in their overall approach. The successful use of a zero-day exploit suggests an increase in technical sophistication and could also suggest that Marbled Dust’s targeting priorities have escalated or that their operational goals have become more urgent.

Output Messenger zero-day

Microsoft security researchers identified the zero-day vulnerability exploited by Marbled Dust. This directory traversal vulnerability (CVE-2025-27920) in the Output Messenger Server Manager application could allow an authenticated user to upload malicious files into the server’s startup directory. Marbled Dust exploited this vulnerability to save the malicious file OMServerService.vbs to the startup folder.

The Output Messenger Server Manager application provides the server owner with the option to enable an output drive, allowing users to upload and download files from the server. Once this is enabled, any user can upload files to the server. By default, these files are stored at C:\Program Files\Output Messenger Server\OfflineMessages\Temp\1\File on the server. Once a user is authenticated, they can upload a file and replace the “name” value in the request with their directory traversal string, for example, name=”../../../../../../../../../../ProgramData/Microsoft/Windows/Start Menu/Programs/StartUp/OMServerService.vbs.

In the Output Messenger architecture, the client and server communicate to provide messaging, file sharing, and other collaborative features. When the client is launched, it connects to the server and sends user credentials to the server for validation before the server authenticates the user. Messages sent from the client are forwarded to the server, which acts as a relay. When a file is shared via the client, it can either be directly transferred to another user or stored on the server for later retrieval.

Once Marbled Dust gains access to the Output Messenger server, the threat actor can leverage Output Messenger system architecture to gain indiscriminate access to the communications of every user, steal sensitive data and impersonate users, which could lead to operational disruptions, unauthorized access to internal systems, and widespread credential compromise.

Attack chain

The attack chain begins with Marbled Dust gaining access to the Output Messenger Server Manager application as an authenticated user. While we currently do not have visibility into how Marbled Dust gained authentication in each instance, we assess that the threat actor leverages DNS hijacking or typo-squatted domains to intercept, log, and reuse credentials, as these are techniques leveraged by Marbled Dust in previously observed malicious activity.

Marbled Dust uses this foothold in a single victim to collect the user’s Output Messenger credentials and exploit the CVE-2025-27920 vulnerability, a directory traversal attack in the Output Messenger Server Manager application that allows an authenticated user to drop malicious files to the server’s startup directory. Marbled Dust drops the malicious files OM.vbs and OMServerService.vbs to the Output Messenger server startup folder and drops the malicious file OMServerService.exe to the server’s Users/public/videos directory.

Marbled Dust then uses OMServerService.vbs to call OM.vbs, which is passed to OMServerService.exe as an argument. At the time of reporting, file OM.vbs was not available for analysis. OMServerService.exe, on the other hand, is a GoLang backdoor masquerading as the legitimate file of the same name. GoLang is particularly effective in this case because it is not sensitive to OS versions. In some cases, OMServerService.exe is observed connecting to a hardcoded domain, api.wordinfos[.]com, for data exfiltration.

Figure 1. The Marbled Dust attack chain

On the client side, the installer extracts and executes both the legitimate file OutputMessenger.exe and OMClientService.exe, another GoLang backdoor that connects to a Marbled Dust command-and-control (C2) domain. This backdoor first performs a connectivity check via GET request to the C2 domain api.wordinfos[.]com. If successful, a second GET request is sent to the same C2 containing hostname information to uniquely identify the victim. The response from the C2 is then directly executed using the command “cmd /c” which instructs the Windows command prompt to run a specific command and then terminate.

In at least one case, a victim device with the Output Messenger client software was observed connecting to an IP address attributed to Marbled Dust likely for data exfiltration, as these connections coincide with the threat actor issuing commands to collect files with varying file extensions to a RAR file on the desktop. This connection to the Marbled Dust-attributed IP address is frequently accomplished using plink—the command-line version of the PuTTY SSH client for Windows.

Mitigations

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Strengthen operating environment configuration

• Ensure that Output Messenger is updated to a version that is not affected by the vulnerability:
  • Version 2.0.63 for Windows
  • Version 2.0.62 for Server
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product.
• Create Defender for Cloud Apps anomaly detection policies.
• Use a vulnerability management system, such as Microsoft Defender Vulnerability Management, to manage vulnerabilities, weaknesses, and remediation efforts across your environment’s operating systems, software inventories, and network devices.
•  Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• 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.
• Organizations can also use Microsoft Defender External Attack Surface Management (EASM), a tool that continuously discovers and maps digital attack surface to provide an external view of your online infrastructure. EASM leverages vulnerability and infrastructure data to generate Attack Surface Insights, reporting that highlights key risks to a given organization.
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion   

Strengthen Microsoft Defender for Endpoint configuration

• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Enable network protection in Microsoft Defender for Endpoint.
• Turn on web protection.
• Run Endpoint Detection and Response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.    
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.   

Microsoft Defender XDR detections

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

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

Microsoft Defender for Endpoint

Alerts with the following title in the security center can indicate threat activity on your network:

• Marbled Dust activity group

Microsoft Defender for Cloud

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Traffic detected from IP addresses recommended for blocking
• Communication with suspicious domain identified by threat intelligence

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

Microsoft Defender Threat Intelligence

• Marbled Dust actor profile

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 and component search Microsoft Defender XDR component search

Microsoft Defender XDR customers can search for Output Messenger components in their environment through the XDR portal Intel explorer components search function.

Navigate to Intel Explorer. Search for “output messenger”. On the summary tab, scroll down to “Components on IP” and click the View all selection at the bottom to display the full results. Note: the results of the search may not include the version of the Output Messenger component.

Microsoft Defender XDR advanced hunting queries

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

OMServerService.vbs script

Surface devices that possess the OMServerService.vbs file that attempts to launch the Marbled Dust GoLang backdoor.

DeviceFileEvents | where FileName == "OMServerService.vbs" | where FolderPath has @"/ProgramData/Microsoft/Windows/Start Menu/Programs/StartUp/" | project Timestamp, DeviceName, InitiatingProcessFileName, FolderPath, FileName, AdditionalFields

Marbled Dust C2

Surface devices that might have communicated with Marbled Dust C2.

let domainList = dynamic(["api.wordinfos.com"]); union ( DnsEvents | where QueryType has_any(domainList) or Name has_any(domainList) | project TimeGenerated, Domain = QueryType, SourceTable = "DnsEvents" ), ( IdentityQueryEvents | where QueryTarget has_any(domainList) | project Timestamp, Domain = QueryTarget, SourceTable = "IdentityQueryEvents" ), ( DeviceNetworkEvents | where RemoteUrl has_any(domainList) | project Timestamp, Domain = RemoteUrl, SourceTable = "DeviceNetworkEvents" ), ( DeviceNetworkInfo | extend DnsAddresses = parse_json(DnsAddresses), ConnectedNetworks = parse_json(ConnectedNetworks) | mv-expand DnsAddresses, ConnectedNetworks | where DnsAddresses has_any(domainList) or ConnectedNetworks.Name has_any(domainList) | project Timestamp, Domain = coalesce(DnsAddresses, ConnectedNetworks.Name), SourceTable = "DeviceNetworkInfo" ), ( VMConnection | extend RemoteDnsQuestions = parse_json(RemoteDnsQuestions), RemoteDnsCanonicalNames = parse_json(RemoteDnsCanonicalNames) | mv-expand RemoteDnsQuestions, RemoteDnsCanonicalNames | where RemoteDnsQuestions has_any(domainList) or RemoteDnsCanonicalNames has_any(domainList) | project TimeGenerated, Domain = coalesce(RemoteDnsQuestions, RemoteDnsCanonicalNames), SourceTable = "VMConnection" ), ( W3CIISLog | where csHost has_any(domainList) or csReferer has_any(domainList) | project TimeGenerated, Domain = coalesce(csHost, csReferer), SourceTable = "W3CIISLog" ), ( EmailUrlInfo | where UrlDomain has_any(domainList) | project Timestamp, Domain = UrlDomain, SourceTable = "EmailUrlInfo" ), ( UrlClickEvents | where Url has_any(domainList) | project Timestamp, Domain = Url, SourceTable = "UrlClickEvents" ) | order by TimeGenerated desc

Executable file or launch script (requires Microsoft Defender XDR)

Identify devices that might have the executable file or launch script present as part of this activity.

DeviceFileEvents | where FileName == "OM.vbs" or FileName == "OMServerService.exe" | where FolderPath has @"c:\users\public\videos\" | project Timestamp, DeviceName, InitiatingProcessFileName, FolderPath, FileName, AdditionalFields

Marbled Dust VBS script file hashes (requires Microsoft Defender XDR)

Search for the file hashes associated with the Marbled Dust VBS script files used in this activity.

let fileHashes = dynamic(["1df959e4d2f48c4066fddcb5b3fd00b0b25ae44f350f5f35a86571abb2852e39", "2b7b65d6f8815dbe18cabaa20c01be655d8475fc429388a4541eff193596ae63"]); union ( DeviceFileEvents | where SHA256 in (fileHashes) | project Timestamp, FileHash = SHA256, SourceTable = "DeviceFileEvents" ), ( DeviceEvents | where SHA256 in (fileHashes) | project Timestamp, FileHash = SHA256, SourceTable = "DeviceEvents" ), ( DeviceImageLoadEvents | where SHA256 in (fileHashes) | project Timestamp, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents" ), ( DeviceProcessEvents | where SHA256 in (fileHashes) | project Timestamp, FileHash = SHA256, SourceTable = "DeviceProcessEvents" ) | order by Timestamp desc Indicators of compromise IndicatorTypeDescriptionFirst seenLast seenhxxps://api.wordinfos[.]comDomainC24/5/20245/12/2025 Learn more

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

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

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

The post Marbled Dust leverages zero-day in Output Messenger for regional espionage appeared first on Microsoft Security Blog.

Microsoft launched its Cybersecurity Governance Council in 2024, and with it, named a group of deputy chief information security officers that ensure comprehensive oversight of the company’s cybersecurity risk, defense, and compliance. These leaders work in tandem with product and engineering leaders across the company to create accountability and advance cybersecurity protection for Microsoft, our customers, and the industry.

In this second part of our series, we’ll introduce three more of these leaders and share more about their background, their role, and their priorities.

• Terrell Cox, Vice President for Privacy and Compliance and Deputy Chief Information Security Officer for Microsoft Security Products Division.
• Ilya Grebnov, Distinguished Engineer and Deputy Chief Information Security Officer, Business Applications.
• Damon Becknel, Vice President and Deputy Chief Information Security Officer, Regulated Industries.

Q: How did you get your start in cybersecurity?

Terrell Cox: “It began with Public Key Infrastructure (PKI) work on Windows Server 2003. What hooked me to cybersecurity was the challenge of taking powerful security tools like encryption and making them usable and approachable. Later, AI and threat detection became natural extensions of that ‘accessible security’ mission.” 

Damon Becknel: “While I was a United States Army Officer, I attended a course at Quantico, the U.S. Marine Corps base outside of Washington D.C. During that time, we toured various government agencies, and I had a long conversation with a researcher on a hacking tool that was fairly point and click. That really caught my attention and opened my eyes. This introduction fueled my choice for my master’s degree, as part of my research had me working on techniques for what we now call hunting. My interest solidified when I led U.S. Military Academy cadets as interns inside the National Security Agency for a summer, and it’s driven my career choices since.”

Ilya Grebnov: “I initially began my career as a coding-focused individual contributor. However, I naturally gravitated towards threat modeling and security reviews. As a result, my colleagues began to assume that I was responsible for this area, leading it to become my official role. I embraced these responsibilities, which ultimately defined my current position.”

Q: What does your team do, and how do you work with others across the company?

Terrell Cox: “I’m part of the Microsoft Security division, where we deliver security, management, and privacy products. My dual focus includes serving as Deputy Chief Information Security Officer for our products and leading privacy, compliance, and risk efforts. Separately, my team oversees infrastructure used company-wide to ensure we respect customer data rights. We’re essentially the backbone of Microsoft’s privacy operations.” 

Damon Becknel: “I’m part of the Microsoft Security division, and my job is to help the divisions of Microsoft ensure they, our products, and our services are compliant with all these various regulations. To do that I adopt the best practices from our customers in regulated industries like banking and healthcare. I provide guidance to teams on how to follow those regulations so we can ensure our products and services are compliant now and built in from the beginning. This also helps us be a better partner to our customers in these regulated industries by providing the security they need when they buy something from us.”

Ilya Grebnov: “I’m part of the Microsoft Cloud and AI division, and my team is responsible for compliance, security, quality, and other cross-group initiatives. Given our heavy focus on platform engineering, much of our work involves defining standards and assisting with their adoption. Many engineers within our group also know me personally, which facilitates trust and effective collaboration across the group.”

Q: Security is a team sport at Microsoft—how do you emphasize awareness and accountability within your organization?

Terrell Cox: “By making security everyone’s key performance indicator. Senior leadership has set the tone, but mid-level managers operationalize it. For example, when engineering teams see security requirements as innovation multipliers and not obstacles, that’s cultural success. We also ‘shine lights’ on risks through transparent reporting. People naturally step up when their metrics are there for everyone to see.” 

Damon Becknel: “Actions speak louder than words. Communication is important, but more important is creating a safe space for that communication. Whether I’m sharing updates, or my team is setting commitments and holding ourselves to them, it’s critical everyone feels they can be vulnerable and admit mistakes, because mistakes are a necessary part of the learning process.”

Ilya Grebnov: “Security relies on clear prioritization and effective collaboration. Our team aims to set high standards within both Microsoft and the broader industry, aligning objectives accordingly. Due to our scale, this is primarily a process matter. If engineers perceive conflicting priorities or lack awareness, it indicates a communication issue, not a technical one.”

Q: What are some of the biggest cybersecurity misconceptions that you encounter?

Terrell Cox: “Believing you can wall yourself off in today’s connected world. Threat actors don’t play by rules, so defense must be proactive, not containment based. That’s why we treat every team, from finance spotting phishing invoices to human resources securing onboarding docs, as frontline defenders.”

Damon Becknel: “The notion that the next best thing is going to solve all our problems.”

Ilya Grebnov: “Contrary to popular misconceptions, hackers typically operate as professionals rather than mere publicity seekers. Understanding that these actors often view their activities as employment, sometimes even state-sponsored, requires us to rethink our defensive strategies. Given their high level of skill and sophisticated resources, our defensive measures must be equally robust.”

Q: How does your approach to security enable rather than inhibit innovation?

Terrell Cox: “Security isn’t about shackling innovation—it’s about focusing it. When engineering teams see compliance as core to their mission and not an add-on, that’s when breakthroughs happen. You want durable solutions? Embrace the tension, because good security doesn’t limit what you build—it builds trust that lets you go further.” 

Damon Becknel: “I liken it to playing football, where basic skills are required before adding a Hail Mary play. You can’t go straight into Hail Mary plays without the ability to block, tackle, throw, and run. You have to do the basics over and over until they are second nature. In an enterprise, security needs to be one of those basics that is practiced every day, and using new technologies to build upon those basics make us better.”

Ilya Grebnov: “Critical and immediate threats are prioritized. For non-critical tasks, my team evaluates work against innovation to find a balanced approach. And we prefer central or standard solutions instead of quick fixes. Since our team handles all aspects of customer trust, we use prioritization frameworks to maintain this balance.”

Security as the operational backbone

These leaders underscore that cybersecurity success hinges on rigorous process discipline, not just technology.

Terrell’s product and privacy focus, Damon’s compliance rigor, and Ilya’s engineering standards reveal the need for, and benefits of, proactive trust-building. By redefining cyberattackers as persistent professionals and prioritizing fundamentals, they exemplify how security enables innovation.

Stay tuned as we continue to share profiles of Microsoft’s deputy chief information security officers, outlining their mission to pioneer strategies that redefine trust, resilience, and innovation in a world where security enables progress for all.

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 Meet the Deputy CISOs who help shape Microsoft’s approach to cybersecurity: Part 2 appeared first on Microsoft Security Blog.