Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations. Over time, Kazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet ecosystem designed to enable persistent, covert access to target environments.

This upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection. The threat actor has historically targeted organizations in the government and diplomatic sector in Europe and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for the purpose of obtaining information supporting Russia’s foreign policy and military objectives.

While many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and restricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also maintains flexible tasking, data staging, and multiple fallback channels for command and control (C2). Understanding this architecture helps defenders move beyond single sample analysis and instead focus on the behaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing, working directory staging, and periodic exfiltration.

Kazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior reporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today. This blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot ecosystem composed of three distinct module types, each with clearly defined roles. Together, these components distribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad tasking while minimizing opportunities for detection.

Delivery

Kazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the encrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound to the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the intended host.

In another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes the loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute the Kazuar modules.

Module types

There are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality contained in each type and how they interact with each other.

This diagram shows the general interactions between a set of modules on a single host. Each infected host needs to have all three modules to create the full P2P network:

Note: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal module and thread names, message types, configuration keys, or mode/flag values). 

Type: Kernel

The Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages communication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the Kernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the Unit 42 write-up and include standard checks such as:

• Checking for running processes containing analysis tools
• Checking for canary files on the desktop
• Checking the loaded process for sandbox-related DLLs

Module configuration

Once these checks are passed, the Kernel module sets up the environment based on numerous configuration options. Previous versions of Kazuar have used separate files containing the configuration information, but these are now embedded in the samples and have significantly increased the number of configurations available to the malware family. 

The configuration set can vary across 150 different configuration types, C2 communication infrastructures, or tasking options generally defined by eight functional categories. Any operational configuration in use can be updated at any time from the C2 server. The following table contains some examples and descriptions of the categories.

This configuration exposes three internal communication mechanisms:

• Window Messaging
• Mailslot
• Named pipes

There are also three different communication protocols for external communication:

• Exchange Web Services (EWS)
• HTTP
• WebSockets (WSS)

They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.

Leadership election

One of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In this architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on behalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple infected hosts.

There are several conditions that determine whether a new leader needs to be elected among participating Kernel modules:

1. There currently is no leader.
2. The leader announces it is shutting down.
3. The leader announces it is logging off.
4. If an election does not result in a leader due to an error, a new election will be called.

Elections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it announces itself as the leader and tells all other Kernel modules to set SILENT.

Only the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks through the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and delegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT mode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the maintained agent list.

With the hierarchy established, the work can be done. Several threads and communication types are initialized to perform the work and communicate between modules.

REMO thread

The REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages with other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-<Bot version>, which results in a pipe path such as \\.\pipe\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through additional strings passed into the name-building function, but this pattern is the default. This channel lets the leader target specific client Kernel modules when delegating work.

Messages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:

• Request another Kernel module’s logs
• Assign tasks to a client Kernel module

Because only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the other Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task to the appropriate client Kernel module through this channel.

MSGW thread

For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:

• Window Messaging [default selection]
  • Registers a hidden window
• Mailslot
  • Registers a Mailslot

Based on its initial configuration, Kazuar selects one of these communication types to listen for incoming communication, with the default being Windows Messaging.

Window Messaging setup

This technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is simply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.

This allows other processes to look up the window by ClassName and use several different APIs to send a message to that window. When the window receives a message, the WindProc is executed to parse it and carry out the requested action.

Mailslot setup

The Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The configuration can optionally append an additional identifier (empty by default), which allows deployments to create distinct Mailslot namespaces when needed.

The string is hashed and used as the name to create the Mailslot: \\.\mailslot\<generated hash>.

A thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it finds one, it parses the incoming message.

Message types

Regardless of what message delivery system is selected, the message is parsed by the same handler function. For the Kernel module, this message parsing function has numerous expected communication messages, since it controls all the modules execution flows.

The following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate a message, and what the Kernel does when it receives each message:

SEND thread

The configuration specifies an external communication method from the available communication modes

• HTTP [default selection]
• Web Socket Server (WSS)
• Exchange Web Server (EWS)

These configurations can be changed at any point when the C2 sends a new configuration, or a change communication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the SEND actions to occur with the default timer being every hour. There are also working timers that can install a blackout period on communications to blend in with the target environment.

Note: Only the elected Kernel leader can perform the following actions:

• If the Kernel has task results 
  • Read in the task file
  • Send SEND message to Bridge with the task result file
• Get new tasks from Bridge
  • Send CHECK message to Bridge

Table 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and recorded as tasks by the Kernel.

There is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the Kernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a certain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.

SOLV thread

This thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread performs several functions related to the current task list:

• Loop through the list of current tasks
  • Check if aborted flag is true
    • Issue TaskKill message to the worker (Window Messaging)
    • Remove task from task list
  • Check if task has exceeded the configured max working time for task
    • Issue TaskKill message to the worker (Window Messaging)
    • Set aborted flag for task to true
    • Remove task from task list
• Read in all task files from the working directory
  • If the task is new
    • Add task to task list

Type: Bridge

The Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader Kernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own Worker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module for communication. It typically has the same default configuration as the Kernel module but does contain a few different operations that set up the initial infection.

The Bridge module initializes its core object with basic metadata and instantiates two supporting components that provide the module’s primary functionality:

• Server Communication module
• Task Handling module

The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:

• SystemEvents.SessionEnded
• SystemEvents.PowerModeChanged

When an event is triggered, the corresponding handler function is invoked, allowing the module to determine the appropriate action for that event. Events are typically ignored unless they require explicit handling.

The module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on its initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows Messaging as the IPC mechanism used for communication between modules. Once the setup steps is completed, the module is ready to proxy communication between the leader Kernel module and the C2 server.

Type: Worker

The initial Worker configuration mirrors the structure of other module configurations and follows the same overall layout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the IPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows Messaging; further details on the window setup are described below.

During initialization, the Worker configuration instantiates several objects responsible for the module’s primary functionality. Each object is executed within its own named thread. These components include:

• Task Solver
  • Handles task tracking
• Peep
  • Hooks windows events
  • Has a max number of windows to hook set by the configuration
• Keylogger
• Filesystem
  • GINFO – Gather system info
  • GFIL – Gather file listings
    • Recent files
    • Desktop
    • Malware working directory
  • GHOO – Window information
  • GMAP – Gather MAPI info
    • Email information

Data collected by these components is aggregated, encrypted, and written to the malware’s working directory, where it is staged for subsequent exfiltration to the C2 server.

Botnet operations

With the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady state operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection across participating modules while maintaining a deliberately low observable footprint. Worker modules execute tasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file, window, and user activity data according to defined schedules and limits.

Module-to-module messaging

When one module needs to communicate with another, all required information is assembled into a structured message packet. Multiple packet formats are defined, with the specific format determined by the message type and intended action.

These message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured, schema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize, transmit, and parse messages through standard library functions.

Messages destined for the Bridge module include additional fields that describe how the request should be forwarded to the remote C2 infrastructure. These fields specify transport level details, including the external communication mechanism to be used.

The TransportType field can specify one of three supported communication methods. The default transport is typically HTTP, using the C2 URLs in the default configuration.

When sending a message, the dispatch function examines the contents of the message packet to determine the appropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes the packet to the intended module.

For example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its Exchange communication component to encapsulate the data and deliver it to the remote C2 server via email.

Messages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel module based on their configuration.

Working directory

Kazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations across modules. This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by function, isolating tasking, collection output, logs, and configuration material into distinct locations. This design allows the malware to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally until explicitly forwarded to the C2 infrastructure through the Bridge module.

Within this working directory, Kazuar maintains separate storage locations for the following functional data types:

• Peeps
• Autos
• Files
• Hashes
• Result files
• Task files
• Config files
• Common wordlist
• Common exe
• Logs
• Keylogger

This structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across leadership changes or reboots, and blend malicious activity into routine file system usage.

Module tasks

The list of commands available for the Worker modules to perform is extensive and has many features, from arbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42 blog.

The Kernel module task handler has a few additional functions that handle commands issued from the leader Kernel module.

System info gathering

System info gathering is often enabled by default in the configuration. This causes an initial collection of system information when the agent starts up. This task collects an extensive amount of information about the system and its user.

Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.

Who is Secret Blizzard?

The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer Network Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the technical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security vendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.

Secret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs, embassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard focuses on gaining long-term access to systems for intelligence collection using extensive resources such as multiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During intrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard seeks out information of political importance with a particular interest in advanced research that might impact international political issues.

Mitigation and protection guidance

To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:

Strengthen Microsoft Defender for Endpoint configuration

• Microsoft Defender XDR customers can implement attack surface reduction rules to harden an environment against techniques used by threat actors.
  • Block execution of potentially obfuscated scripts.
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block abuse of exploited vulnerable signed drivers.
• Enable network protection in Microsoft Defender for Endpoint.
• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• 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.
• 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.

Strengthen Microsoft Defender Antivirus configuration

• Turn on PUA protection in block mode in Microsoft Defender Antivirus.
• Turn on  cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Strengthen operating environment configuration

• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Implement PowerShell execution policies to control conditions under which PowerShell can load configuration files and run scripts.
• Turn on and monitor PowerShell module and script block logging.

Microsoft Defender detections

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

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Secret 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.

Indicators of compromise

References

• Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)
• 🇷🇺 COMmand & Evade: Turla’s Kazuar v3 Loader
• Russia’s FSB malign activity: factsheet
• Hunting Russian Intelligence “Snake” Malware

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 Kazuar: Anatomy of a nation-state botnet 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.

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.

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.

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.

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.

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.

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.

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.

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

Indicators of compromise

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 on 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 New Russia-affiliated actor Void Blizzard targets critical sectors for espionage appeared first on Microsoft Security Blog.

Active since at least 2021, this subgroup within Seashell Blizzard has leveraged opportunistic access techniques and stealthy forms of persistence to collect credentials, achieve command execution, and support lateral movement that has at times led to substantial regional network compromises. Observed operations following initial access indicate that this campaign enabled Seashell Blizzard to obtain access to global targets across sensitive sectors including energy, oil and gas, telecommunications, shipping, arms manufacturing, in addition to international governments. We assess that this subgroup has been enabled by a horizontally scalable capability bolstered by published exploits that allowed Seashell Blizzard to discover and compromise numerous Internet-facing systems across a wide range of geographical regions and sectors. Since early 2024, the subgroup has expanded its range of access to include targets in the United States and United Kingdom by exploiting vulnerabilities primarily in ConnectWise ScreenConnect (CVE-2024-1709) IT remote management and monitoring software and Fortinet FortiClient EMS security software (CVE-2023-48788). These new access operations built upon previous efforts between 2021 and 2023 which predominantly affected Ukraine, Europe, and specific verticals in Central and South Asia, and the Middle East.

Microsoft Threat Intelligence assesses that while some of the subgroup’s targeting is opportunistic, its compromises cumulatively offer Seashell Blizzard options when responding to Russia’s evolving strategic objectives. Since April 2022, Russia-aligned threat actors have increasingly targeted international organizations that are either geopolitically significant or provide military and/or political support to Ukraine. In addition to establishing access to these targets outside Ukraine, we assess that the subgroup has likely enabled at least three destructive cyberattacks in Ukraine since 2023 (see below discussion of Seashell Blizzard for more information about their activities against Ukraine).  

Seashell Blizzard’s far-reaching access operations pose a significant risk to organizations within the group’s strategic purview. Despite the commodity nature of this subgroup’s exploitation patterns, notable shifts within the actor’s post-compromise tradecraft are reflected within the subgroup’s activities, which may carry over to other aspects of Seashell Blizzard’s more traditional operations and carry more significant implications for auditing during incident response. 

Microsoft Threat Intelligence tracks campaigns launched by Seashell Blizzard as well as this subgroup, and when able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. As part of our continuous monitoring, analysis, and reporting on the threat landscape, we are sharing our research on this campaign’s activity to raise awareness of the observed TTPs and to educate organizations on how to harden their attack surfaces against this and similar activity. 

Who is Seashell Blizzard?

Seashell Blizzard is a high-impact threat actor linked to the Russian Federation that conducts global activities on behalf of Russian Military Intelligence Unit 74455 (GRU). Seashell Blizzard’s specialized operations have ranged from espionage to information operations and cyber-enabled disruptions, usually in the form of destructive attacks and manipulation of industrial control systems (ICS). Active since at least 2013, this threat actor’s prolific operations include destructive attacks such as KillDisk (2015) and FoxBlade (2022), supply-chain attacks (MeDoc, 2017), and pseudo-ransomware attacks such as NotPetya (2017) and Prestige (2022), in addition to numerous other specialized disruptive capabilities. Seashell Blizzard is assessed to be highly skilled at enabling broad and persistent access against priority computer networks, which sometimes gives the group significant tenure for future potential follow-on activity.

Due to their specialization in computer network exploitation (CNE) and expertise targeting critical infrastructure such as ICS and supervisory control and data acquisition systems (SCADA), Seashell Blizzard’s operations have frequently been leveraged during military conflicts and as an adaptable element during contentious geopolitical events. Historically, some of Seashell Blizzard’s operations may be considered part of a spectrum of retaliatory actions sometimes used by the Russian Federation. Since Russia’s invasion of Ukraine in 2022, Seashell Blizzard has conducted a steady stream of operations complementing Russian military objectives. The threat actor’s longstanding strategic targets in the region have included critical infrastructure such as energy and water, government, military, transportation and logistics, manufacturing, telecommunications, and other supportive civilian infrastructure.

Since at least April 2023, Seashell Blizzard has increased targeting of military communities in the region, likely for tactical intelligence gain. Their persistent targeting of Ukraine suggests Seashell Blizzard is tasked to obtain and retain access to high-priority targets to provide the Russian military and Russian government a range of options for future actions.

Seashell Blizzard’s network intrusions leverage diverse tradecraft and typically employ a range of common publicly available tools, including Cobalt Strike and DarkCrystalRAT. Network intrusions linked to the threat actor have affected multiple tiers of infrastructure, showcasing Seashell Blizzard’s abilities to target end users, network perimeters, and vertical-specific systems leveraging both publicly available and custom exploits and methods.

Since February 2022, Seashell Blizzard has generally taken three approaches to their network intrusions:

• Targeted: Seashell Blizzard has frequently used tailored mechanisms to access targets, including scanning and exploitation of specific victim infrastructure, phishing, and modifying legitimate functionality of existing systems to either expand network access or obtain confidential information.
• Opportunistic: Seashell Blizzard has increasingly used broad exploitation of Internet-facing infrastructure and distribution of malware implants spread through trojanized software to achieve scalable but indiscriminate access. In cases where a resulting victim is identified as strategically valuable, Microsoft Threat Intelligence has observed the threat actor conducting significant post-compromise activities.
• Hybrid: Seashell Blizzard has very likely gained access to target organizations using a limited supply-chain attack narrowly focused within Ukraine, an operation that was recently mitigated by the Computer Emergency Response Team of Ukraine (CERT-UA). Other hybrid methods have included compromise of regional managed IT service providers, which often afforded regional or vertical-specific access to diverse targets.

Seashell Blizzard overlaps with activity tracked by other security vendors as BE2, UAC-0133, Blue Echidna, Sandworm, PHANTOM, BlackEnergy Lite, and APT44.

Attribution assessment

Microsoft Threat Intelligence assesses that the initial access subgroup is linked to Seashell Blizzard. Despite the subgroup’s opportunistic tactics, we are able to distinguish this subgroup due to its consistent use of distinct exploits, tooling, infrastructure, and late-stage methods used to establish persistence. Moreover, our longstanding forensic investigation uncovered distinct post-compromise activities, a part of which incorporated specific operational capabilities and resources chiefly utilized by Seashell Blizzard. We have also observed the initial access subgroup to pursue access to an organization prior to a Seashell Blizzard-linked destructive attack.

Scope of operations and targeting trends

Microsoft Threat Intelligence assesses that Seashell Blizzard uses this initial access subgroup to horizontally scale their operations as new exploits are acquired and to sustain persistent access to current and future sectors of interest to Russia. This subgroup conducts broad operations against a variety of sectors and geographical areas. In 2022, its primary focus was Ukraine, specifically targeting the energy, retail, education, consulting, and agriculture sectors. In 2023, it globalized the scope of its compromises, leading to persistent access within numerous sectors in the United States, Europe, Central Asia, and the Middle East. It frequently prioritized sectors that either provided material support to the war in Ukraine or were geopolitically significant. In 2024, while the exposure of multiple vulnerabilities likely offered the subgroup more access than ever, it appeared to have honed its focus to the United States, Canada, Australia, and the United Kingdom.

This subgroup’s historical pattern of exploitation has also led to the compromise of globally diverse organizations that appear to have limited or no utility to Russia’s strategic interests. This pattern suggests the subgroup likely uses an opportunistic “spray and pray” approach to achieving compromises at scale to increase the likelihood of acquiring access at targets of interest with limited tailored effort. In cases where a strategically significant target is compromised, we have observed significant later post-compromise activity. The geographic focus of the subgroup frequently transitions between broad campaigns against multiple geographic targets and a narrow focus on specific regions or countries, demonstrating the subgroup’s flexibility to pursue unique regional objectives.

Initial access subgroup opportunistically compromises perimeter infrastructure using published CVEs

Since late 2021, Seashell Blizzard has used this initial access subgroup to conduct targeted operations by exploiting vulnerable Internet-facing infrastructure following discovery through direct scanning and, more uniquely, use of third-party internet scanning services and knowledge repositories. These exploitation efforts are followed by an operational lifecycle using a consistent set of TTPs to support persistence and lateral movement, which have incrementally evolved to become more evasive over time. Microsoft Threat Intelligence has identified at least three distinct exploitation patterns and operational behaviors linked to this subgroup, which are described in more detail below:

To date, at least eight vulnerabilities common within specific categories of server infrastructure typically found on network perimeters of small office/home office (SOHO) and enterprise networks have been exploited by this subgroup:

• Microsoft Exchange (CVE-2021-34473)
  • Zimbra Collaboration (CVE-2022-41352)
  • OpenFire (CVE-2023-32315)
  • JetBrains TeamCity (CVE-2023-42793)
  • Microsoft Outlook (CVE-2023-23397)
  • Connectwise ScreenConnect (CVE-2024-1709)
  • Fortinet FortiClient EMS (CVE-2023-48788)
  • JBOSS (exact CVE is unknown)

In nearly all cases of successful exploitation, Seashell Blizzard carried out measures to establish long-term persistence on affected systems. This persistent access is noted in at least three cases to have preceded select destructive attacks attributed to Seashell Blizzard, highlighting that the subgroup may periodically enable destructive or disruptive attacks.

Exploitation patterns

We have observed the initial access subgroup using three specific exploit patterns:

Deployment of remote management and monitoring (RMM) suites for persistence and command and control (February 24, 2024 – present)

In early 2024, the initial access subgroup began using RMM suites, which was a novel technique used by Seashell Blizzard to achieve persistence and command and control (C2). This was first observed when the subgroup exploited vulnerabilities in ConnectWise ScreenConnect (CVE-2024-1709) and Fortinet FortiClient EMS (CVE-2023-48788). The subgroup then deployed RMM software such as Atera Agent and Splashtop Remote Services. The use of RMM software allowed the threat actor to retain critical C2 functions while masquerading as a legitimate utility, which made it less likely to be detected than a remote access trojan (RAT). While these TTPs have been used by other nation-state threat actors since at least 2022, including by Iranian state actor Mango Sandstorm, the Seashell Blizzard initial access subgroup’s specific techniques are considered distinct.

During the first weeks of this exploitation pattern, the initial access subgroup primarily targeted organizations in Ukraine, the United States, Canada, the United Kingdom, and Australia. It is highly likely that Seashell Blizzard conducted post-compromise activity at only a limited number of organizations that were part of this initial victim pool. For these organizations, Seashell Blizzard conducted preliminary credential access through multiple means and deployed at least one custom utility to facilitate remote access and tunneling (see the section on ShadowLink below for more information).

Both CVE-2024-1709 and CVE-2023-48788 provided the ability to launch arbitrary commands on a vulnerable server. Following exploitation, the subgroup used two methods of payload retrieval to install RMM agents on affected servers:

• Retrieval of Atera Agent installers from legitimate agent endpoints – Commonly observed on exploited ScreenConnect servers, Seashell Blizzard used resulting command execution to retrieve Atera installers via Bitsadmin and curl from legitimate installation URLs hosted by Atera.

• Retrieval of Atera Agent from actor-controlled infrastructure – During exploitation of CVE-2023-48788 between April 9 and April 10, 2024, Seashell Blizzard retrieved remote agent installers from actor-controlled virtual private server (VPS) infrastructure.

Following installation of RMM software, Seashell Blizzard uses the native functionality of the agents to deploy secondary tools to help credential acquisition, data exfiltration, and upload of custom utilities to facilitate more robust access to compromised systems.

Seashell Blizzard likely uses three primary methods of credential access:

• Registry-based credential access via reg.exe:

• Credential access via renamed procdump:

• Since RMM agents typically afford an interactive graphical interface, native credential access mechanisms common via task manager were likely also carried out. In addition, credential access via Taskmanager UI by LSASS process dumping was likely also employed.

During Seashell Blizzard intrusions, we observed rclone.exe deployed to affected servers and subsequently used to carry out data exfiltration using an actor-supplied configuration file.

Among a subgroup of victims, Seashell Blizzard carried out unique post-compromise activity, indicating that the threat actor sought more durable persistence and direct access. In these cases, Seashell Blizzard deployed OpenSSH with a unique public key, allowing them to access compromised systems using an actor-controlled account and credential, in addition to a unique persistence and assured C2 method known to Microsoft Threat Intelligence as ShadowLink.

ShadowLink facilitates persistent remote access by configuring a compromised system to be registered as a Tor hidden service. This is achieved using a combination of Tor service binaries and a unique actor-defined Tor configuration file (referred as the ‘torrc’) configuring the system for remote access. Systems compromised with ShadowLink receive a unique .onion address, making them remotely accessible via the Tor network. This capability allows Seashell Blizzard to bypass common exploit patterns of deploying a RAT, which commonly leverages some form of C2 to actor-controlled infrastructure that are often easily audited and identified by network administrators. Instead, by relying on Tor hidden services, the compromised system creates a persistent circuit to the Tor network, acting as a covert tunnel, effectively cloaking all inbound connections to the affected asset and limiting exposures from both the actor and victim environment.

ShadowLink contains two primary components: a legitimate Tor service binary and a torrc which contains requisite configurations for the Tor hidden services address—specifically, port-forwarding for common services such as Remote Desktop Protocol (RDP) and SecureShell (SSH) Protocol. Commonly, Seashell Blizzard has utilized ShadowLink to redirect inbound connections to the Tor hidden service address to ports for RDP (3389). ShadowLink persisted via a system service:

Microsoft Threat Intelligence has also observed Forest Blizzard, a separate GRU actor, leveraging similar Tor-based capabilities in their operations.

Web shell deployment for persistence and C2 (late 2021 – present)

Since late 2021, the Seashell Blizzard initial access subgroup has primarily deployed web shells following successful exploitation to maintain footholds and achieve the ability to execute commands necessary to deploy secondary tooling to assist lateral movement. To date, this exploit pattern remains its predominant persistence method. Beginning in mid-2022, this pattern of exploitation enabled unique post-compromise activities against organizations in Central Asia and Europe, which were likely intended to further Russia’s geopolitical objectives and preposition against select strategic targets.

Exploitation of Microsoft Exchange and Zimbra vulnerabilities

Microsoft Threat Intelligence has identified at least two web shells consistently deployed by this initial access subgroup. While web shells can be deployed using a variety of methods, they are most often deployed following the exploitation of vulnerabilities allowing remote code execution (RCE) or achieving some level of arbitrary file upload. In the case of the initial access subgroup, we have observed web shells deployed following exploitation of vulnerabilities in Microsoft Exchange (CVE-2021-34473) and Zimbra (CVE-2022-41352). In cases where RCE is available, the initial access subgroup routinely retrieves web shells from actor-controlled infrastructure. This infrastructure can be either legitimate but compromised websites or dedicated actor infrastructure.

We observed the following web shell retrieval commands being used:

Microsoft Threat Intelligence has identified a web shell that we assess as exclusive to the initial access subgroup and is associated with the previously mentioned web shell retrieval patterns. Detected as LocalOlive, this web shell is identified on compromised perimeter infrastructure and serves as the subgroup’s primary means of achieving C2 and deploying additional utilities to compromised infrastructure. Written in ASPX supporting C#, the web shell carries sufficient yet rudimentary functionality to support the following secondary activities:

• Upload and download files
• Run shell commands
• Open a port (default port is set to TCP 250)

Figure 6. LocalOlive web shell def.aspx

On October 24, 2022, the initial access subgroup successfully exploited CVE-2022-41352. This Zimbra Collaborative vulnerability allows a threat actor to deploy web shells and other arbitrary files by sending an email with a specially crafted attachment, effectively exploiting an arbitrary file-write vulnerability. The initial access subgroup leveraged this vulnerability to deliver a primitive web shell to affected servers, allowing for execution of arbitrary commands.

Emails were sent from the following actor-controlled addresses:

• akfcjweiopgjebvh@proton.me
• ohipfdpoih@proton.me
• miccraftsor@outlook.com
• amymackenzie147@protonmail.ch
• ehklsjkhvhbjl@proton.me
• MirrowSimps@outlook.com

Figure 7. Web shell used during Zimbra exploitation

Reconnaissance and fingerprinting

After deploying web shells, the initial access subgroup then executes specific sequential commands below likely used to fingerprint and attribute victim networks; these patterns of behavior may indicate that either operators are quick to capitalize on compromises or the possible use of automation following successful exploitation.

Tunneling utilities deployment

When Seashell Blizzard identifies targets of likely strategic value, it often furthers its network compromise by deploying tunneling utilities such as Chisel, plink, and rsockstun to established dedicated conduits into affected network segments.

When Chisel is deployed, it often followed multiple naming conventions, including:

• MsChSoft.exe
• MsNan.exe
• Msoft.exe
• Chisel.exe
• Win.exe
• MsChs.exe
• MicrosoftExchange32.exe
• Desk.exe
• Sys.exe

For example, the initial access subgroup has used the following tunneling commands:

When rsockstun is deployed, it has used naming conventions such as Sc.exe.

Tunneling launch

When establishing tunnels, the initial access subgroup has routinely established reverse tunnels to exclusive VPS actor-owned infrastructure, including:

Note that these IP addresses are relevant within or around the timeframes enumerated in the table above. Some IP addresses may no longer be used by Seashell Blizzard at the time of this writing but are provided for historical and forensic understanding.

Modification of infrastructure to expand network influence through credential collection (late 2021 – 2024)

In targeted operations where the initial access subgroup is likely seeking network access, Microsoft Threat Intelligence has observed subsequent malicious modifications to network resources including Outlook Web Access (OWA) sign-in pages and DNS configurations.

Modifying network resources allows Seashell Blizzard to passively gather relevant network credentials, which may be used to expand the actor’s access to sensitive information and widen its access to target networks in general. Notably, the infrastructure associated with this unique technique is sometimes also used in the two prior exploitation patterns, highlighting the versatility of late-stage infrastructure which may not always be limited to distinct patterns of exploitation.

Modification of web access sign-in portals

The initial access subgroup uses rogue JavaScript inserted into otherwise legitimate sign-in portals. This malicious JavaScript collects and sends clear text usernames and passwords to actor-controlled infrastructure as they are submitted in real time by users of the affected organization. We assess that this method has likely afforded the subgroup credentials to support lateral movement within several organizations.

Microsoft Threat Intelligence has tracked the following actor-controlled infrastructure linked to this unique credential collection method when modifying legitimate OWA sign-in pages:

• hwupdates[.]com
• cloud-sync[.]org
• 103.201.129[.]130

Modification of DNS configurations

Microsoft Threat Intelligence assesses with moderate confidence that the initial access subgroup has modified DNS A record configurations for select targets. While the purpose of these modifications is unclear, due to the nature of affected systems, it is possible that they may have been purposed to intercept credentials from critical authentication services.

Conclusion

Given that Seashell Blizzard is Russia’s cyber tip of the spear in Ukraine, Microsoft Threat Intelligence assesses that this access subgroup will continue to innovate new horizontally scalable techniques to compromise networks both in Ukraine and globally in support of Russia’s war objectives and evolving national priorities. This subgroup, which is characterized within the broader Seashell Blizzard organization by its near-global reach, represents an expansion in both the geographical targeting conducted by Seashell Blizzard and the scope of its operations. At the same time, Seashell Blizzard’s far-reaching, opportunistic access methods likely offer Russia expansive opportunities for niche operations and activities that will continue to be valuable over the medium term.

Mitigation and protection guidance

To harden networks against the Seashell Blizzard activity listed above, defenders can implement the following:

Strengthen operating environment configuration

• Utilize 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.
• Require multifactor authentication (MFA). While certain attacks such as 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 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.
• Enable Network Level Authentication for Remote Desktop Service connections.
• Enable AppLocker to restrict specific software tools prohibited within the organization, such as reconnaissance, fingerprinting, and RMM tools, or grant access to only specific users.

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 content from email client and webmail 
  • 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

Strengthen Microsoft Defender Antivirus configuration

• Turn on cloud-delivered protection in Microsoft Defender Antivirus, or the equivalent for your antivirus product, to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants. 
• Enable Microsoft Defender Antivirus scanning of downloaded files and attachments.
• Enable Microsoft Defender Antivirus real-time protection.
• Turn on PUA protection in block mode in Microsoft Defender Antivirus 

Strengthen Microsoft Defender for Office 365 configuration

• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable Zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Invest in advanced anti-phishing solutions that monitor incoming emails and visited websites. Microsoft Defender for Office 365 merges incident and alert management across email, devices, and identities, centralizing investigations for email-based threats.
• Configure Microsoft Defender for Office 365 to recheck links on click.
• Use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns. Run spear-phishing (credential harvest) simulations to train end-users against clicking URLs in unsolicited messages and disclosing credentials.

Strengthen Microsoft Defender for Identity configuration

• Prevent clear text credential exposure.
• Reduce lateral movement paths that may be used by attackers.
• Identify legacy components that may introduce security vulnerabilities.

Microsoft Defender XDR detections

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects this threat as the following malware: 

• HackTool:Win64/ShadowLink.A!dha
• HackTool:Win64/ShadowLink.B!dha
• Exploit:Python/CVE-2024-1709
• Rnasom:Win32/Inc.MA
• BackDoor:PHP/Remoteshell.V
• Trojan:Win32/LocalOlive.A!dha
• Trojan:Win32/LocalOlive.B!dha
• Trojan:Win32/LocalOlive.C!dha

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Seashell Blizzard activity group

The following alerts might also indicate threat activity related to this threat. Note, however, these alerts also can be triggered by unrelated threat activity.

• Possible Seashell Blizzard activity
• Suspicious Atera installation via ScreenConnect
• Suspicious command execution via ScreenConnect
• Suspicious sequence of exploration activities
• CredentialDumpingViaEsentutlDetector
• Suspicious behavior by cmd.exe was observed
• SQL Server login using xp_cmdshell
• Suspicious port scan activity within an RDP session
• Suspicious connection to remote service
• Suspicious usage of remote management software
• New local admin added using Net commands
• Sensitive data was extracted from registry
• Suspicious Scheduled Task Process Launched
• Potential human-operated malicious activity
• Compromised account conducting hands-on-keyboard attack
• Sensitive file access for possible data exfiltration or encryption
• Possible Fortinet FortiClientEMS vulnerability exploitation
• Possible target of NTLM credential theft
• Possible exploitation of ProxyShell vulnerabilities
• Possibly malicious use of proxy or tunneling tool
• Hidden dual-use tool launch attempt

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.

• Communication with suspicious domain identified by threat intelligence
• Suspicious PowerShell Activity Detected
• Detected suspicious combination of HTA and PowerShell
• Detected encoded executable in command line data
• Detected obfuscated command line

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 Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence to get more information about this threat actor.

Microsoft Defender Threat Intelligence

• Seashell Blizzard
• Seashell Blizzard uses new ShadowLink variant
• Seashell Blizzard exploiting vulnerabilities to install Atera Agent for post-compromise activities
• Seashell Blizzard launches destructive attack against local Ukrainian government, Storm-1512 takes credit
• Credential Theft via Modification of Outlook Web Access (OWA) Login Pages
• Seashell Blizzard Targeting Zimbra Servers Using Malicious Email Attachment
• Seashell Blizzard Uses TOR Hidden Services on Targets for Persistence and Evasion

Hunting queries  

Microsoft Defender XDR

The following sample queries let you 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 potential PowerShell-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.

ScreenConnect

Surface the possible exploitation of ScreenConnect to launch suspicious commands.

DeviceProcessEvents
   | where InitiatingProcessParentFileName endswith "ScreenConnect.ClientService.exe"
   | where (FileName in~ ("powershell.exe", "powershell_ise.exe", "cmd.exe") and
            ProcessCommandLine has_any ("System.DirectoryServices.ActiveDirectory.Domain", "hidden -encodedcommand", "export-registry", "compress-archive", "wget -uri", "curl -Uri", "curl -sko", "ipconfig /all", "& start /B", "start msiexec /q /i", "whoami", "net user", "net group", "localgroup administrators", "dsquery", "samaccountname=", "query session", "adscredentials", "o365accountconfiguration", "-dumpmode", "-ssh", "o           or (FileName =~ "wget.exe" and ProcessCommandLine contains "http")
           or (FileName =~ "mshta.exe" and ProcessCommandLine contains "http")
           or (FileName =~ "curl.exe" and ProcessCommandLine contains "http")
           or ProcessCommandLine has_all ("powershell", "-command", "curl")
           or ProcessCommandLine has_any ("E:jscript", "e:vbscript", "start msiexec /q /i")
           or ProcessCommandLine has_all ("reg add", "DisableAntiSpyware", @"\Microsoft\Windows Defender")
           or ProcessCommandLine has_all ("reg add", "DisableRestrictedAdmin", @"CurrentControlSet\Control\Lsa")
           or ProcessCommandLine has_all ("vssadmin", "delete", "shadows")
           or ProcessCommandLine has_all ("vssadmin", "list", "shadows")
           or ProcessCommandLine has_all ("wmic", "process call create")
           or ProcessCommandLine has_all ("wmic", "delete", "shadowcopy")
           or ProcessCommandLine has_all ("wmic", "shadowcopy", "call create")
           or ProcessCommandLine has_all ("wbadmin", "delete", "catalog")
           or ProcessCommandLine has_all ("ntdsutil", "create full")
           or (ProcessCommandLine has_all ("schtasks", "/create") and not(ProcessCommandLine has "shutdown"))
           or (ProcessCommandLine has "nltest" and ProcessCommandLine has_any ("domain_trusts", "dclist", "all_trusts"))
           or (ProcessCommandLine has "lsass" and ProcessCommandLine has_any ("procdump", "tasklist", "findstr"))
           or FileName in~ ("tasklist.exe", "ssh.exe", "icacls.exe", "certutil.exe", "calc.exe", "bitsadmin.exe", "accesschk.exe", "mshta.exe",
                                      "winrm.exe", "dsquery.exe", "makecab.exe", "hh.exe", "pcalua.exe", "regsvr32.exe",
                                      "cmstp.exe", "esentutl.exe", "dnscmd.exe", "gpscript.exe", "msdt.exe", "msra.exe", "odbcconf.exe")
   | where not(ProcessCommandLine has_any ("servicedesk.atera.com", "support.csolve.net", "lt.tech-keys.com", "certutil  -hashfile"))

FortiClient EMS log capture

If you believe your FortiClient has been exploited before patching, this query may help with further investigation.

According to Horizon3 research, the C:\Program Files (x86)\Fortinet\FortiClientEMS\logs log file can be examined to identify malicious activity. Run the following query to surface devices with this log file for further investigation. 

DeviceFileEvents
| where FileName contains @"C:\Program Files (x86)\Fortinet\FortiClientEMS\logs"
| distinct DeviceName

Additionally, Horizon3 noted that this SQL vulnerability could allow for remote code execution (RCE) using the xp_cmdshell functionality of Microsoft SQL Server. The SQL logs can also be examined for evidence of xp_cmdshell being leveraged to spawn a Windows command shell.

According to Microsoft research, the following query could help surface exploitation activity related to this vulnerability. 

DeviceProcessEvents
| where InitiatingProcessFileName == "sqlservr.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_any ("webclient", "downloadstring", "http", "https", "downloadfile")
| where InitiatingProcessCommandLine has_all ("sqlservr.exe", "-sFCEMS")

Tor service

Find services associated with Tor. 

DeviceEvents
| where ActionType == 'ServiceInstalled'
| extend JSON = parse_json(AdditionalFields)
| where JSON.ServiceName has 'tor'

YARA rule

Use the following Yara rule to find malicious JavaScript inserted into OWA sign-in pages.   

rule injected_cred_logger_owa {  
strings:  
$owa = "