Google threat hunters spotted yet another Chinese state-sponsored espionage group that for years had burrowed into systems belonging to government and private organizations to steal data across academia, medicine, military, cybersecurity and foreign policy. 

Google Threat Intelligence Group discovered the previously unknown threat group UNC6508, which targeted organizations in the United States and Canada, in late 2025 but traced its earliest known compromise back to September 2023. 

The revelation mirrors an alarming pattern of Chinese espionage groups dropping backdoors into critical infrastructure to pre-position for potential sabotage, intercept research and steal data with national security implications. These groups working at the behest of China’s government, including UNC6508, operated in stealth for years before authorities or researchers discovered their activity.

“We don’t know the full extent or impact of the campaign,” Patrick Whitsell, senior security engineer at GTIG, told CyberScoop. Researchers said the threat group intruded a medical research university in September 2023, stole credentials and communications, and remained active on the institution’s systems through November 2025 when it was discovered.

Google said it confirmed multiple victims compromised with INFINITERED, a custom backdoor the threat group deployed on targeted networks to steal administrative credentials after it exploited externally facing REDCap (Research Electronic Data Capture) servers.

Researchers still don’t know how UNC6508 gained initial access to the REDCap servers. Google said the survey and database software, which was created at Vanderbilt University and issued multiple patches for critical remote-code execution vulnerabilities throughout 2023, is widely used across the medical research community. 

“Given the breadth of the threat actor’s intelligence collection criteria and their ability to remain undetected within compromised networks for more than a year, we assess the known victims likely represent only a fraction of a larger campaign,” Whitsell said. “We also assess that this highly capable threat actor will remain active and continue to be a threat to the defense, technology and medical industries for the foreseeable future.”

Google said the campaign targeted clinical providers, academic medical centers and U.S. military health institutions, demonstrating advanced capabilities from a threat group that doesn’t currently overlap with any other publicly known groups.

The threat group abused domain compliance rules to steal data, a technique that doesn’t rely on malware or living-off-the-land tools, and routed traffic through U.S.-based IPs to blend in with legitimate traffic, researchers said.

“We have some evidence to suggest this is a large threat group with multiple sub-teams, but this is not confirmed,” Whitsell said.

Like other previously identified China state-sponsored espionage groups, UNC6508 remains active.

Google said it disrupted some of UNC6508’s known infrastructure by disabling an Gmail account it used to exfiltrate data, notified the affected organizations and helped remediate compromises before it published research on UNC6508’s activities.

Whitsell said several unconfirmed instances of compromise remain under investigation.

The post Google exposes China espionage group that’s been lurking in networks undetected since 2023 appeared first on CyberScoop.

Google’s Threat Intelligence Group has been tracking the cyberespionage group as UNC6508 since early 2025.

The post Chinese Hackers Target Medical, Military, and AI Research in North America appeared first on SecurityWeek.

The attackers had access to a senior executive’s email account for 150 days and exfiltrated data for months.

The post Hackers Target Global Stock Exchange in Espionage Operation appeared first on SecurityWeek.

Moscow’s agents are building fake companies, recruiting middlemen and deploying cyber spies and hackers who gather information that could be used to attack key infrastructure.

The post Russian Spies Are Aggressively Seeking Western Technology as Sanctions Bite, Officials Say appeared first on SecurityWeek.

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.

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.

A Chinese national allegedly involved in a massive, pandemic-era attack spree that compromised nearly 13,000 U.S. organizations was extradited from Italy to the United States and formally charged in federal court, the Justice Department said Monday.

Xu Zewei and his co-conspirators are accused of exploiting a string of zero-day vulnerabilities in Microsoft Exchange Server to steal research on COVID-19 vaccines, treatment and testing during the initial wave and subsequent height of the pandemic.

His alleged crimes, directed by China’s intelligence services, were part of a broader espionage campaign known as HAFNIUM, which targeted infectious disease experts, law firms, universities, defense contractors and policy think tanks, according to an indictment filed against Xu and Zhang Yu, who remains at large. 

The China state-sponsored threat group behind those attacks against Microsoft customers, and many other vendors’ customers since, is now more widely known as Silk Typhoon.

“Xu will now answer for his alleged role in HAFNIUM, a group responsible for a vast intrusion campaign directed by China’s Ministry of State Security that compromised more than 12,700 U.S. organizations,” Brett Leatherman, assistant director of the FBI’s Cyber Division, said in a statement.

“He is one of many contractors the Chinese government uses to obscure its hand in cyber operations, and others who do the same face the same risk,” he added.

Xu allegedly committed the attacks while working for Shanghai Powerock Network, one of many companies that conducted attacks for China’s various intelligence services, according to court records.

Italian authorities arrested Xu at the United States’ request in Milan in July. His capture underscores a window of opportunity U.S. officials and allies can take when nation-state attackers travel to countries that cooperate with the United States.

Italy extradited Xu to the United States Saturday but didn’t release his extradition orders until Monday, Simona Candido, his attorney in Italy, told CyberScoop.

Officials said Monday marked Xu’s first appearance in the U.S. District Court for the Southern District of Texas. He is currently being held at a federal prison in Houston.

“We have pursued this moment across years and continents, and the message this office sends today is the same one we sent when we first unsealed this indictment: we will work to protect the American people,” John G.E. Marck, acting U.S. attorney for the Southern District of Texas, said in a statement.

Xu allegedly worked under the direction of China’s Ministry of State Security’s Shanghai State Security Bureau to break into U.S. organizations’ networks, steal data and implant webshells for persistent remote access. Officials also accuse Xu of stealing information regarding U.S. policymakers and government agencies from a global law firm with offices in Washington. 

Microsoft first warned customers about the HAFNIUM campaign in March 2021. The FBI and Cybersecurity and Infrastructure Security Agency followed soon after with a joint advisory about the widespread compromise of Microsoft Exchange Server. 

“Today’s law enforcement action demonstrates the real-world consequences of this state-led activity, which is fueled by a vast network of private companies operating under the direction of the Chinese government,” Aaron Shraberg, senior team lead of global intelligence at Flashpoint, told CyberScoop.

“Extraditing these individuals from countries in coordination with international law enforcement demonstrates a united stance on these actions, and the importance of bringing real-world consequences to China’s notorious targeting of not just the American people and their businesses, but individuals globally as well,” Shraberg added.

Xu is charged with conspiracy to commit wire fraud; two counts of wire fraud; conspiracy to cause damage to and obtain information by unauthorized access to protected computers, to commit wire fraud, and to commit identity theft; two counts of obtaining information by unauthorized access to protected computers; two counts of intentional damage to a protected computer; and aggravated identity theft. 

The 34-year-old faces up to 62 years in prison for his alleged crimes.

The post Chinese national extradited to US for pandemic-era Silk Typhoon attacks appeared first on CyberScoop.

The recent FBI-led operation to knock Russian government hackers off routers sought to topple an especially insidious and threateningly contagious cyberespionage campaign, top bureau cyber official Brett Leatherman told CyberScoop.

Researchers, along with U.S. and foreign government agencies, revealed details of the campaign this week by which APT28 — also known as Forest Blizzard or Fancy Bear, and attributed to Russia’s Main Intelligence Directorate of the General Staff (GRU) — compromised more 18,000 TP-Link routers and infiltrated more than 200 organizations worldwide. 

The compromise of routers used in small and home offices prompted the takedown operation, Operation Masquerade, which involved sending commands to the routers to reset Domain Name System (DNS) settings to prevent the hackers from exploiting that access.

“What’s unique to me in this one is that when you change the internet settings in a router like they did, it propagates to all the devices in your house,” Leatherman, assistant director of the FBI’s cyber division, said. “All those devices now, once they’re connected to that Wi-Fi, are getting the malicious IP addresses that they are then routing their traffic through, and it gives the Russian GRU tremendous access to the content offered through a router itself.”

“The difficulty in an attack like this is that it’s virtually invisible to the end users,” he said. “Actors were not deploying malware like we often see. And so when you think about endpoint detection on your computer or something like that, it’s not seeing that activity because they don’t have to. They’re using the tools on the router itself to capture your internet traffic and extend it  throughout the house, and so traditional tools that detect that activity [are] just not there.”

The disruption operation is in line with the cyber strategy the Trump administration published last month, with its emphasis on going on offense against malicious hackers and protecting critical infrastructure, Leatherman said.

The FBI understands its role in implementing that strategy, he said, and worked with the Office of the National Cyber Director and other agencies in developing it. The White House has kept the public and Capitol Hill in the dark about strategy implementation, however.

“We’ve got a long track record of leveraging unique authorities and capabilities to counter these actors, to impose costs, and through the 56 field offices to really defend critical infrastructure,” Leatherman said. “That’s part of our DNA, really. And so we want to make sure that we continue to align that in the most scalable and agile way we can, to align with the priorities of the strategy itself.”

Leatherman traced how Operation Masquerade — the success of which he credited to the FBI’s Boston offices and partnerships with the private sector and foreign governments — fits into a series of disruptions aimed at Russian government hackers dating back to 2018.

That’s when the bureau took on the VPNFilter botnet by seizing a domain used to communicate with infected routers. In 2022, the FBI took on the Cyclops Blink botnet, and in 2024, Operation Dying Ember went after another botnet.

“”Over the course of those four operations, while the adversary continued to evolve in their tradecraft, so did we,” Leatherman said. “We moved from just sinkholing domains to actually taking steps that block them at the door of these routers, pulled any capability off of those routers so they were no longer able to collect the sensitive information, and then prohibited them from getting back in.”

The post Inside the FBI’s router takedown that cut off APT28’s ‘tremendous access’ appeared first on CyberScoop.

Executive summary

Forest Blizzard, a threat actor linked to the Russian military, has been compromising insecure home and small-office internet equipment like routers, then modifying their settings in ways that turn them into part of the actor’s malicious infrastructure. The threat actor then hides behind this legitimate but compromised infrastructure to spy on additional targets or conduct follow-on attacks. Microsoft Threat Intelligence is sharing information on this campaign to increase awareness of the risks associated with insecure home and small-office internet routing devices and give users and organizations tools to mitigate, detect, and hunt for these threats where they might be impacted. 

Since at least August 2025, the Russian military intelligence actor Forest Blizzard, and its sub-group tracked as Storm-2754, has conducted a large-scale exploitation of vulnerable small office/home office (SOHO) devices to hijack Domain Name System (DNS) requests and facilitate the collection of network traffic. For nation-state actors like Forest Blizzard, DNS hijacking enables persistent, passive visibility and reconnaissance at scale.

By compromising edge devices that are upstream of larger targets, threat actors can take advantage of less closely monitored or managed assets to pivot into enterprise environments. Microsoft Threat Intelligence has identified over 200 organizations and 5,000 consumer devices impacted by Forest Blizzard’s malicious DNS infrastructure; telemetry did not indicate compromise of Microsoft-owned assets or services.

Forest Blizzard, which primarily collects intelligence in support of Russian government foreign policy initiatives, has also leveraged its DNS hijacking activity to support post-compromise adversary-in-the-middle (AiTM) attacks on Transport Layer Security (TLS) connections against Microsoft Outlook on the web domains. This activity enables the interception of cloud-hosted content, impacting numerous sectors including government, information technology (IT), telecommunications, and energy—all usual targets for this actor.

While the number of organizations specifically targeted for TLS AiTM is only a subset of the networks with vulnerable SOHO devices, Microsoft Threat Intelligence assesses that the threat actor’s broad access could enable larger-scale AiTM attacks, which might include active traffic interception. Targeting SOHO devices is not a new tactic, technique, or procedure (TTP) for Russian military intelligence actors, but this is the first time Microsoft has observed Forest Blizzard using DNS hijacking at scale to support AiTM of TLS connections after exploiting edge devices.

In this blog, we share our analysis of the TTPs used by Forest Blizzard in this campaign to illustrate how threat actors leverage this attack surface. We’re also outlining mitigation and protection recommendations to reduce exposure from compromised SOHO devices, as well as Microsoft Defender detection and hunting guidance to help defenders identify and investigate related malicious activity. It’s important for organizations to account for unmanaged SOHO devices—particularly those used by remote and hybrid employees—since compromised home and small‑office network infrastructure can expose cloud access and sensitive data even when enterprise environments and cloud services themselves remain secure.

DNS hijacking attack chain: From compromised devices to AiTM and other follow-on activity

The following sections provide details on Forest Blizzard’s end-to-end attack chain for this campaign, from initial access on vulnerable SOHO routers to actor-controlled DNS resolution and AiTM activity.

Edge router compromise

Forest Blizzard gained access to SOHO devices then altered their default network configurations to use actor-controlled DNS resolvers. This malicious re-configuration resulted in thousands of devices sending their DNS requests to actor-controlled servers.

Typically, endpoint devices obtain network configuration settings from edge devices through Dynamic Host Configuration Protocol (DHCP). Exploiting SOHO devices requires minimal investment while providing wide visibility on compromised devices, allowing the actor to collect DNS traffic and passively observe DNS requests, which could facilitate follow-on collection activity as described in the next section.

DNS hijacking

Forest Blizzard is almost certainly using the dnsmasq utility to perform DNS resolution and provide responses while listening on port 53 for DNS queries. The dnsmasq utility is a legitimate tool that provides lightweight network services widely used in home routers or smaller networks. Among its services are DNS forwarding and caching and a DHCP server, which collectively enable upstream DNS query forwarding and IP address assignment on a local network.

Adversary-in-the-middle attacks

Microsoft Threat Intelligence has observed AiTM attacks related to the initial access campaign. Although they target different endpoints, both are Transport Layer Security (TLS) AiTM attacks, allowing the threat actor to collect data being transmitted.

In most cases, the DNS requests appear to have been transparently proxied by the actor’s infrastructure, resulting in connections to the legitimate service endpoints without interruption. However, in a limited number of compromises, the threat actor spoofed DNS responses for specifically targeted domains to force impacted endpoints to connect to infrastructure controlled by the threat actor.

The actor-controlled malicious infrastructure would then present an invalid TLS certificate to the victim, spoofing the legitimate Microsoft service. If the compromised user ignored warnings about the invalid TLS certificate, the threat actor could then actively intercept the underlying plaintext traffic—potentially including emails and other customer content— within the TLS connection. Since Forest Blizzard does not always conduct AiTM activity after achieving initial access through DNS hijacking, the actor is likely using it selectively against targets of intelligence priority post-compromise:

• AiTM attack against Microsoft 365 domains: Microsoft observed Forest Blizzard conducting follow-on AiTM operations against a subset of domains associated with Microsoft Outlook on the web.
• AiTM attack against specific government servers: Microsoft identified separate AiTM activity targeting non-Microsoft hosted servers in at least three government organizations in Africa, during which Forest Blizzard intercepted DNS requests and conducted follow-on collection.

Possible post-compromise activities

Forest Blizzard’s DNS hijacking and AiTM activity allows the actor to conduct DNS collection on sensitive organizations worldwide and is consistent with the actor’s longstanding remit to collect espionage against priority intelligence targets. Although we have only observed Forest Blizzard utilizing their DNS hijacking campaign for information collection, an attacker could use an AiTM position for additional outcomes, such as malware deployment or denial of service.

Mitigation and protection guidance

Microsoft recommends the following mitigation steps to protect against this Forest Blizzard activity:

Protection against DNS hijacking

• Enforce domain-name-based network access controls using Zero Trust DNS (ZTDNS) on Windows endpoints to ensure that devices only resolve DNS through trusted servers.
• Block known or malicious domains to prevent DNS-based attacks, and maintain detailed DNS logs to monitor, investigate, and gain insight into anomalous DNS traffic.
• Follow best practices for enhancing network security for cloud computing environments.
• Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based threats.
• Avoid using home router solutions in corporate environments.

Protection against AiTM and credential theft

• 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’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. 
• Strictly enforce multifactor authentication (MFA) and apply Conditional Access policies, particularly for privileged and high‑risk accounts, to reduce the impact of credential compromise. Use passwordless solutions like passkeys in addition to implementing MFA.
  • 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.
• Implement continuous access evaluation and implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication. We recommend requiring multi-factor authentication on Medium or above risky sign-ins. 
• Follow best practices for recovering from systemic identity compromises outlined by Microsoft Incident Response.

Microsoft Defender detection and hunting guidance

Microsoft Defender customers can refer to the following list of applicable detections. 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 Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report. Microsoft tracks the specific component of Forest Blizzard associated with this activity as Storm-2754.

• Forest Blizzard Actor activity detected
• Storm-2754 activity

Entra ID Protection

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

• Microsoft Entra threat intelligence (sign-in) (RiskEventType: investigationsThreatIntelligence)

Hunting

Because initial compromise and DNS modification occur at the router-level, the following hunting recommendations focus on detecting post-compromise behavior.

Modifications to DNS settings

In identified activity, Forest Blizzard’s compromise of an infected SOHO device resulted in the update of the default DNS setting on connected Windows machines.

• Identifying unusual modifications to DNS settings can be an identifier for malicious DNS hijacking activity.
• Resetting the DNS settings and addressing vulnerable SOHO devices can resolve this activity, though these actions will not remediate an attacker who has managed to steal user credentials in follow-on AiTM activity.

Post-compromise activity

Forest Blizzard’s post-compromise AiTM activity could enable the actor to operate in the environment as a valid user. Establishing a baseline of normal user activity is important to be able to identify and investigate potentially anomalous actions. For Entra environments, Microsoft Entra ID Protection provides two important reports for daily activity monitoring:

• Risky sign-in reports surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
• Risky user reports surfaces user accounts that might have been compromised, such as a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel.

Defenders can surface highly suspicious or successful risky sign-ins using the following advanced hunting query in the Microsoft Defender XDR portal:

AADSignInEventsBeta 
| where RiskLevelAggregated == 100 and (ErrorCode == 0 or ErrorCode == 50140) 
| project Timestamp, Application, LogonType, AccountDisplayName, UserAgent, IPAddress 

After stealing credentials, Forest Blizzard could potentially carry out a range of activity against targets as a legitimate user. For Microsoft 365 environments, the ActionType “Search” or “MailItemsAccessed” in the CloudAppEvents table in the Defender XDR portal can provide some information on user search activities, including the Microsoft Defender for Cloud Apps connector that surfaces activity unusual for that user.

CloudAppEvents
| where AccountObjectId == " " // limit results to specific suspicious user accounts by adding the user here
| where ActionType has_any ("Search", "MailItemsAccessed")

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: Forest Blizzard
• Activity profile: SOHO router compromise leads to DNS hijacking and adversary-in-the-middle attacks

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.

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 SOHO router compromise leads to DNS hijacking and adversary-in-the-middle attacks appeared first on Microsoft Security Blog.

Russian state-sponsored attackers compromised more than 18,000 routers spread across more than 120 countries to gain deeper access to sensitive networks for a large-scale espionage campaign before it was recently neutralized, researchers and authorities said Tuesday.

Forest Blizzard, also known as APT28 and Fancy Bear, exploited known vulnerabilities to steal credentials for thousands of TP-Link routers globally. The threat group, which is attributed to Russia’s Main Intelligence Directorate of the General Staff (GRU) Military Unit 26165, hijacked domain name system settings and stole additional credentials and tokens via redirected traffic, the Justice Department said.

The threat group established an expansive espionage network by intruding systems of more than 200 organizations, impacting at least 5,000 consumer devices, Microsoft Threat Intelligence said in a report. 

Operation Masquerade, a collaborative takedown operation led by the FBI, aided by federal prosecutors, the National Security Division’s National Security Cyber section, Lumen’s Black Lotus Labs and Microsoft Threat Intelligence, involved a series of commands designed to reset DNS settings and prevent the threat group from further exploiting its initial means of access. 

“GRU actors compromised routers in the U.S. and around the world, hijacking them to conduct espionage. Given the scale of this threat, sounding the alarm wasn’t enough,” Brett Leatherman, assistant director of the FBI’s cyber division, said in a statement. “The FBI conducted a court-authorized operation to harden compromised routers across the United States.”

Forest Blizzard’s widespread campaign involved adversary-in-the-middle attacks against domains mimicking legitimate services, including Microsoft Outlook Web Access. This allowed attackers to intercept passwords, OAuth tokens, credentials for Microsoft accounts, and other services and cloud-hosted content. 

Microsoft insists company-owned assets or services were not compromised as part of the campaign.

The threat group targeted network edge devices, including TP-Link and MicroTik routers, opportunistically before it identified sensitive targets of intelligence interest to the Russian government, including people in the military, government and critical infrastructure sectors. 

Victims, according to researchers, include government agencies and organizations in the IT, telecom and energy sectors. Lumen identified other victims associated with Afghanistan’s government and others linked to foreign affairs and national law enforcement agencies in North Africa, Central America and Southeast Asia. An unnamed European country’s national identity platform was also impacted, the company said.

Lumen did not find evidence of any compromised U.S. government agencies as part of this campaign, but warned that the activity poses a grave national security threat.

While the full scope of Forest Blizzard’s accomplishments remain under investigation, researchers are confident the bleeding of sensitive information has stopped. 

“The campaign has ceased,” Danny Adamitis, distinguished engineer at Black Lotus Labs, told CyberScoop. “We have observed a gradual decline in communications associated with this infrastructure over the past several weeks.”

Lumen said it observed widespread router exploitation and DNS redirection beginning in August, the day after the United Kingdom’s National Cyber Security Centre published a malware analysis report about a tool used to steal Microsoft Office credentials. The U.K.’s NCSC on Tuesday published details about APT28’s DNS hijacking campaign, including indicators of compromise.

The Justice Department and FBI, acting on a court order, remediated compromised routers in the United States after collecting evidence on Forest Blizzard’s activity. The FBI said Russia’s GRU weaponized routers owned by Americans in more than 23 states to steal sensitive government, military and critical infrastructure information.

The post Feds quash widespread Russia-backed espionage network spanning 18,000 devices appeared first on CyberScoop.

A Chinese cyberespionage group has shifted its gaze back to Europe after years of focusing on other parts of the world, Proofpoint research published Wednesday found.

The surge began in mid-2025, with a bevy of issues bubbling up between China and Europe, the company said. Proofpoint labels the government-linked group TA416, but other companies track it as Twill Typhoon, Mustang Panda or other names.

“This renewed focus most heavily targeted individuals or mailboxes associated with diplomatic missions and delegations to NATO and the EU,” Proofpoint’s Mark Kelly and Georgi Mladenov wrote. “TA416’s return to European government targeting occurred during heightened EU–China tensions over trade, the Russia–Ukraine war, and rare earths exports, and commenced immediately following the 25th EU–China summit.”

Separately, the same group took up targeting the Middle East in March after the start of the conflict in Iran, something it had never been spotted doing before, Proofpoint found.

“This aligns with a trend observed by Proofpoint of some state-aligned threat actors shifting targeting toward Middle Eastern government and diplomatic entities in the aftermath of the war,” the firm said. “This likely reflects an effort to gather regional intelligence on the status, trajectory, and broader geopolitical implications of the conflict.”

TA416 was active in Europe in 2022 and 2023, coinciding with the onset of the Ukraine-Russia war, but stepped away from the continent afterward, according to the researchers. Its focus turned to Southeast Asia, Taiwan and Mongolia for a couple years.

The group’s focus on Europe through early 2026 used a variety of web bug and malware delivery methods, including setting up reconnaissance by dangling lures about Europe sending troops to Greenland. It also included phishing emails about humanitarian concerns, interview requests and collaboration proposals, Proofpoint said.

“During this period, TA416 repeatedly altered its initial infection chains while maintaining a consistent goal of loading the group’s customized PlugX backdoor via DLL sideloading triads,” the researchers wrote.

Proofpoint’s is not the only report of late about Chinese cyberespionage groups targeting Europe, with another focused on LinkedIn solicitations to NATO and European institutions.

The post European-Chinese geopolitical issues drive renewed cyberespionage campaign appeared first on CyberScoop.

A cyberattack that an Iranian hacking group said it carried out against medical device manufacturer Stryker might mark Tehran’s first significant cyber action since the start of the joint U.S.-Israel conflict.

But even that may have been a happy accident for Iranian hackers in what has been a low buzz of activity during that timeframe, with the attackers striking paydirt by happenstance rather than on purpose.

Cybersecurity firms, threat intelligence trackers and critical infrastructure owners have been fighting to separate the noise about proclaimed attacks out of Iran, and the warnings and threats related to the conflict, from what is actually happening and poses any significant danger.

“Everybody is scrambling right now,” said Alex Orleans, a long-time Iran threat analyst and head of threat intelligence at Sublime Security. Others said the nascent nature of the conflict is making assessments difficult.

“What we see is quite difficult to quantify or characterize about whether there’s been an increase or decrease,” said Saher Naumaan, senior threat researcher at Proofpoint. “I think since we’re only a couple weeks into the conflict, and the regular cadence of Iranian actors isn’t very consistent, necessarily, we don’t have enough data points or enough time to really judge.”

Signs of activity

In the early days of the conflict, there were indications that physical attacks on Iran might have hampered Iranian retaliatory efforts or other cyber activity, as those who would carry out cyberattacks were probably “hiding in bunkers,” Orleans said, and as Iran suffered internet outages.

In recent days, however, the Stryker attack and other indicators suggest that Iranian cyber activity could be heating up.

“For several days following the outbreak of the conflict, there was a noted decrease in cyber threat activity emanating from Iran,” a group of industry information and sharing analysis centers warned Wednesday. “However, there are signs of life in Iranian offensive cyber operations.”

The Stryker attack stands out for both the size and location of the target, a Michigan-based medical device manufacturer with more than $25 billion in revenue in 2025.

But both Orleans and Sergey Shykevich, threat intelligence group manager at Check Point Research, said the attack has the hallmarks of an opportunistic one rather than a deliberate, focused one. The group claiming credit for the attack, Handala — a Ministry of Intelligence-linked outfit — is known more for seizing advantage of weaknesses they happen upon rather than doggedly pursuing particular targets.

Notably, Stryker is also the class of a military vehicle used by U.S. forces. That military connection, even if confused with the medical device manufacturer, could possibly explain why the company was a target.

Still, “it was a much higher-profile attack than we expected from Handala,” Shykevich said. “Unfortunately, it’s possible to define it as a relatively big success for them.”

There have been reports of other cyber activity that might be connected to the conflict. Albania said the email system of its parliament had been targeted, with Iranian hackers taking credit. There was the targeting of cameras from Iran-linked infrastructure in countries that Iran then launched missiles into. Poland said it was looking into whether Iran was behind an attempted cyberattack on a nuclear research facility.

Some of the claims don’t match reality. “There are many hacktivist groups that are very active in Telegram, but actually they don’t have any significant successes,” Shykevich said.

There are other cyber-related developments in the conflict, too, like espionage, the proliferation of artificial intelligence-fueled misinformation and the possibility of Russia or China helping out in cyberspace on Iran’s behalf, even if some experts doubt the likelihood of the latter.

How effective any of it has been is still unclear. Stryker, for instance, said the attack mainly affected its internal networks, although there were signs it might be affecting communications at hospitals, too.

But the damage might be beside the point. Orleans said the attacks could be psychological in nature, aimed at producing fear abroad and affirming hackers’ standing with domestic leaders in Iran during the conflict.

Even low-level defacement or distributed denial-of-service attacks can play a role.

“Coming into work and finding an Iranian flag on your workstation would be a little bit  disconcerting, because they’re letting you know that, ‘I can reach out and touch you,’” said Sarah Cleveland, senior director of federal strategy at ExtraHop and a former cyber officer in the U.S. Air Force.

Possible follow-up impacts

While primarily known as a medical supply company, Stryker has received sizable contracts with the military for hospital equipment and surgical supplies, for example. It is unclear whether the hackers intended to use Stryker’s military connection to exploit government systems.

The Pentagon has long warned of increased, complex cyberattacks against the defense industrial base, a vast network of companies — with disparate levels of cybersecurity — that the military relies on for advanced weaponry to basic stretchers. The DIB is often seen by adversaries as a backdoor into military systems.

While he did not directly address the Stryker hack, the Army’s principal cyber adviser, Brandon Pugh, outlined some of the challenges to the DIB and the service’s part in trying to protect it during a webinar Thursday in response to a question on the topic.

He said adversaries “right or wrong” see companies “as an extension of the military” and that they believe an attack on private industry would have a secondary impact on the armed forces.

“Some are very large, sophisticated multinational companies,” he said, noting that security needs across the DIB aren’t universal. “Others are very small companies that are lucky to have a director of IT, let alone a sophisticated cyber team, and I think that’s where it’s really important to lean into.”

Pugh said that agencies across the federal government have been working with the DIB to boost its resilience to attacks, and that the Army’s cyber effort emphasizes entrenching cybersecurity from the beginning of the acquisition process.

“Cyber can’t be an afterthought — not saying it is,” Pugh added. “I’d say the Army does a great job here, but making sure it’s never forgotten and is always considered along that way.”

Matt Tait, the CEO and president of MANTECH, said in response to a question about the Stryker attack and DIB protections that defending against such incidents includes leveraging government agreements and access, such as with the NSA, and quickly sharing information following an attack.

“To me, it’s about real time information sharing,” he said. “You need real time information sharing when you’re getting attacked to be able to actually share that information with the rest of industry, as well as with government, because they can actually share that information across” federal cybersecurity entities.

“If you want to do mission focused technology work, this is the world you have to live in, and that you should be sharing this information on a real time basis,” he added. “24 hours later, 48 hours later, I call that ambulance chasing. That’s too far after the fact from a cyber perspective.”

The post Stryker attack highlights nebulous nature of Iranian cyber activity amid joint U.S.-Israel conflict appeared first on CyberScoop.

Two years ago, it was revealed that Chinese hackers had compromised at least ten U.S. telecoms, giving them broad access to phone data affecting nearly all Americans. Since then, public officials charged with responding to the campaign and bolstering the nation’s cyber defenses have reported a common problem.

Many of their constituents struggle to understand why the hacks – carried out by a group called Salt Typhoon – should rank among their top concerns, or how it impacts their day to day lives.

Some state and federal officials worry that this lack of interest is depriving policymakers the public pressure needed to build momentum for stronger action to improve the nation’s telecommunications cybersecurity.

Mike Geraghty, the CISO and director of the New Jersey Cybersecurity and Communications Cell, said New Jersey is the nation’s most densely populated state, with a high concentration of critical infrastructure and a major telecommunications footprint. For that reason, a campaign like Salt Typhoon should, in theory, be of strong interest to Garden State residents.

“However, if you talk to a person on the street in New Jersey, they’’ll say who cares that the Chinese are looking at – you know – what numbers I call?” he said Wednesday at the Billington State and Local Cybersecurity Summit. “It has a big role to play in my job, but trying to get people to understand what that means for New Jersey is really difficult.”

Congress hasn’t passed comprehensive privacy legislation in decades. Meanwhile, cyberattacks that expose sensitive data are widespread, and U.S. companies routinely collect and sell customers’ personal information. Some officials speculate that, taken together, these trends have left Americans numb to data theft and data-for-profit–so additional breaches feel like just another drop in the bucket.

Mischa Beckett, deputy chief information security officer and director of cyber threat intelligence at GDIT, said Salt Typhoon’s focus on telecom data can feel like an abstract threat to many Americans. By contrast, other Chinese hacking campaigns like Volt Typhoon suggest potential damage to water plants and electric grids that are easier to grasp.

“It’s maybe a little bit easier to write off a loss of data..and move on, as unfortunate but no big deal,” said Beckett. “I think that case is much harder to make when we’re talking about pre-positioning and critical infrastructure, things that touch all of our lives every day.”

Last year, a former intelligence official at the Office of the Director of National Intelligence told CyberScoop that a lack of outrage from the public following the Salt Typhoon attacks was dampening momentum for broader regulation or reforms to telecom cybersecurity.

“We can’t accept this level of espionage on our networks,” said Laura Galante who led the Cyber Threat Intelligence Integration Center under the Biden administration. “If you had 50 Chinese [Ministry of State Security] spies or contractors sitting inside a major [telecom company’s] building, they would be walked out and it would be a full-scale effort. That’s in broad strokes what has happened, but the access was digital.”

The post Officials worry Salt Typhoon apathy is killing momentum for tougher telecom security rules appeared first on CyberScoop.