Open-source framework ROADtools is being misused by threat actors for cloud intrusions. Learn how to identify its malicious use.
The post Paved With Intent: ROADtools and Nation-State Tactics in the Cloud appeared first on Unit 42.
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.
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.
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).
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:
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.
| Category | Example configuration options | Description |
| Communication and transport | transport, ws_transport, heart_beat, ews_url, keywords | Controls how the malware communicates with C2 infrastructure, including HTTP and WebSocket transports, Exchange Web Services (EWS) email-based C2, heartbeat intervals, and connection parameters |
| Execution and injection | inject_mode, delegate_enabled, live_in_scrcons, modules | Defines how the malware executes and persists in memory, including process injection techniques (inject/remote/zombify/combined/single), module loading, and process hosting strategies |
| Security bypass | amsi_bypass, wldp_bypass, etw_bypass, antidump_methods, hinder_enabled | Configures evasion techniques to avoid detection by security tools, including bypasses for Antimalware Scan Interface (AMSI), Windows Lockdown Policy (WLDP), Event Tracing for Windows (ETW), and anti-debugging/anti-dump protections |
| Data exfiltration timing | send_hour_min, send_hour_max, send_on_weekend, max_send_chunk, send_times_max | Controls when and how collected data is exfiltrated, including working hours restrictions (8:00 AM – 8:00 PM default), weekend behavior, chunk sizes, retry limits, and rate limiting to blend with normal network traffic |
| Task management | task_time_limit, task_max_store_time, solve_threads, max_solve_tries, max_deadlock_ivl | Manages execution of received tasks/commands, including timeouts, thread pool sizing, retry logic, deadlock detection, and task queuing/storage parameters |
| File collection | autos_patterns, autos_folders, autos_min_fsize, autos_max_fsize, autos_max_size, autos_file_ivl | Configures automated file harvesting, including target file patterns, folder paths to scan, file size filters (min/max), total collection limits, and scanning intervals for continuous collection operations |
| System state | working_dir, agent_uuid, hostname, botID, start_attempts, was_shutdown, first_sysinfo_do | Maintains agent identity and operational state, including unique identifiers, working directories, startup tracking, shutdown flags, and initial reconnaissance behavior |
| Monitoring | keylog_enabled, keylog_size, autos_do_scrshot, autos_do_steal, autos_scrs_ivl, max_total_peeps, peep_rules | Controls active surveillance capabilities, including keylogging (buffer size, flush intervals), screenshot capture, credential theft, Messaging Application Programming Interface (MAPI) email monitoring, and configurable monitoring rules/intervals. |
This configuration exposes three internal communication mechanisms:
There are also three different communication protocols for external communication:
They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.
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:
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.
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:
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.
For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:
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:
| Kernel outgoing MsgType | MsgType reason | Module(s) | Kernel incoming MsgType | Kernel actions |
| TASK | – Issue task to worker | Worker | TASK_RESULT | – Response message is logged by the Kernel – Result file is created with results of the task |
| CHECK | – Only the leader can send this – Request new tasks from remote C2 | Bridge | CHECK_RESULT | – If the C2 has tasks, the Kernel creates a task file – Can also receive alternate C2 URLs that are added to the stored configuration |
| SYN | – Target module needs to request a new config | Bridge, Worker | GET_CONFIG | – Kernel sends its configuration to the requesting module |
| (Worker thread – PEEP) | – Configuration-based | Worker | PEEP | – PEEP result file is written unless it has reached its configured max PEEP number |
| SEND | – Send result file to be forwarded to C2 | Bridge | SEND_RESULT | – Result file is deleted |
| (Worker thread – KEYL) | – Configuration-based | Worker | KEYLOG | – Writes keylog data to keylog output file |
| (Multiple Filesystem Worker threads) | – Configuration-based | Worker | AUTOS | – Writes AUTO data to AUTOS output files |
The configuration specifies an external communication method from the available communication modes
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:
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.
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:
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:
The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:
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.
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:
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.
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.
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.
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:
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.
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.
| Task | Description |
| kernel | A list of commands to be executed by the Kernel module |
| delegate | Send command via Named pipe to targeted Kernel module |
| modules | Handles the list of agents maintained by the Kernel module list – List modules in the agents list clear – Clear list of agents add – Add an agent to the list by ID remove – Remove an agent from the list by ID |
| autoslist | Gets list of hashes and files collected by autos |
| autosget | Sends all of the autos files to requesting module and deletes autos files |
| autosdel | Deletes all autos files |
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.
| Optional OS features Installed AV AMSI provider Security packages AppLocker setting Logical drives USB devices Network adapters ARP tables Network connections Network shares RDP hints Running processes Loaded modules (current process) | Pipe list Active windows Recent documents Outlook downloads Recent items OS info System Boot events Hardware info User info Local users Logon sessions User profiles Special folders Explorer Run command history | Explorer typed paths Explorer search history Environment variables UAC settings Internet settings DNS cache Network PowerShell versions WSUS settings Installed software Hot patches Update history Services Drivers |
Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.
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.
To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:
Strengthen Microsoft Defender for Endpoint configuration
Strengthen Microsoft Defender Antivirus configuration
Strengthen operating environment configuration
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.
| Tactic | Observed activity | Microsoft Defender coverage |
| Execution | Execution of malware components | Microsoft Defender Antivirus – Kazuar (OA, OB) – KazuarModule – KazuarLoader – ShadowLoader – ToxicDust Microsoft Defender for Endpoint – Secret Blizzard actor activity detected |
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:
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.
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.
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.
| Indicator | Type | Description |
| 69908f05b436bd97baae56296bf9b9e734486516f9bb9938c2b8752e152315d4 | SHA-256 | hpbprndiLOC.dll – Kazuar Loader |
| c1f278f88275e07cc03bd390fe1cbeedd55933110c6fd16de4187f4c4aaf42b9 | SHA-256 | Decrypted Kernel Module |
| 6eb31006ca318a21eb619d008226f08e287f753aec9042269203290462eaa00d | SHA-256 | Decrypted Bridge Module |
| 436cfce71290c2fc2f2c362541db68ced6847c66a73b55487e5e5c73b0636c85 | SHA-256 | Decrypted Worker Module |
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.
Hackers linked to Russia’s military intelligence units are using known flaws in older Internet routers to mass harvest authentication tokens from Microsoft Office users, security experts warned today. The spying campaign allowed state-backed Russian hackers to quietly siphon authentication tokens from users on more than 18,000 networks without deploying any malicious software or code.
Microsoft said in a blog post today it identified more than 200 organizations and 5,000 consumer devices that were caught up in a stealthy but remarkably simple spying network built by a Russia-backed threat actor known as “Forest Blizzard.”
How targeted DNS requests were redirected at the router. Image: Black Lotus Labs.
Also known as APT28 and Fancy Bear, Forest Blizzard is attributed to the military intelligence units within Russia’s General Staff Main Intelligence Directorate (GRU). APT 28 famously compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.
Researchers at Black Lotus Labs, a security division of the Internet backbone provider Lumen, found that at the peak of its activity in December 2025, Forest Blizzard’s surveillance dragnet ensnared more than 18,000 Internet routers that were mostly unsupported, end-of-life routers, or else far behind on security updates. A new report from Lumen says the hackers primarily targeted government agencies—including ministries of foreign affairs, law enforcement, and third-party email providers.
Black Lotus Security Engineer Ryan English said the GRU hackers did not need to install malware on the targeted routers, which were mainly older Mikrotik and TP-Link devices marketed to the Small Office/Home Office (SOHO) market. Instead, they used known vulnerabilities to modify the Domain Name System (DNS) settings of the routers to include DNS servers controlled by the hackers.
As the U.K.’s National Cyber Security Centre (NCSC) notes in a new advisory detailing how Russian cyber actors have been compromising routers, DNS is what allows individuals to reach websites by typing familiar addresses, instead of associated IP addresses. In a DNS hijacking attack, bad actors interfere with this process to covertly send users to malicious websites designed to steal login details or other sensitive information.
English said the routers attacked by Forest Blizzard were reconfigured to use DNS servers that pointed to a handful of virtual private servers controlled by the attackers. Importantly, the attackers could then propagate their malicious DNS settings to all users on the local network, and from that point forward intercept any OAuth authentication tokens transmitted by those users.
DNS hijacking through router compromise. Image: Microsoft.
Because those tokens are typically transmitted only after the user has successfully logged in and gone through multi-factor authentication, the attackers could gain direct access to victim accounts without ever having to phish each user’s credentials and/or one-time codes.
“Everyone is looking for some sophisticated malware to drop something on your mobile devices or something,” English said. “These guys didn’t use malware. They did this in an old-school, graybeard way that isn’t really sexy but it gets the job done.”
Microsoft refers to the Forest Blizzard activity as using DNS hijacking “to support post-compromise adversary-in-the-middle (AiTM) attacks on Transport Layer Security (TLS) connections against Microsoft Outlook on the web domains.” The software giant said while targeting SOHO devices isn’t a new tactic, this is the first time Microsoft has seen Forest Blizzard using “DNS hijacking at scale to support AiTM of TLS connections after exploiting edge devices.”
Black Lotus Labs engineer Danny Adamitis said it will be interesting to see how Forest Blizzard reacts to today’s flurry of attention to their espionage operation, noting that the group immediately switched up its tactics in response to a similar NCSC report (PDF) in August 2025. At the time, Forest Blizzard was using malware to control a far more targeted and smaller group of compromised routers. But Adamitis said the day after the NCSC report, the group quickly ditched the malware approach in favor of mass-altering the DNS settings on thousands of vulnerable routers.
“Before the last NCSC report came out they used this capability in very limited instances,” Adamitis told KrebsOnSecurity. “After the report was released they implemented the capability in a more systemic fashion and used it to target everything that was vulnerable.”
TP-Link was among the router makers facing a complete ban in the United States. But on March 23, the U.S. Federal Communications Commission (FCC) took a much broader approach, announcing it would no longer certify consumer-grade Internet routers that are produced outside of the United States.
The FCC warned that foreign-made routers had become an untenable national security threat, and that poorly-secured routers present “a severe cybersecurity risk that could be leveraged to immediately and severely disrupt U.S. critical infrastructure and directly harm U.S. persons.”
Experts have countered that few new consumer-grade routers would be available for purchase under this new FCC policy (besides maybe Musk’s Starlink satellite Internet routers, which are produced in Texas). The FCC says router makers can apply for a special “conditional approval” from the Department of War or Department of Homeland Security, and that the new policy does not affect any previously-purchased consumer-grade routers.
Login