{ "id": "cfccb387-fc4a-4b76-ab09-9cf75c52e97d", "created_at": "2026-05-19T02:02:13.494685Z", "updated_at": "2026-10-20T09:12:38.529516Z", "deleted_at": null, "sha1_hash": "5d5d25c09afa56059b0547dae67cb9dd2786cfeb", "title": "Kazuar: Anatomy of a nation-state botnet", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1773320, "plain_text": "Kazuar: Anatomy of a nation-state botnet\r\nBy Microsoft Threat Intelligence\r\nPublished: 2026-05-14 · Archived: 2026-05-19 02:01:11 UTC\r\nKazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under\r\nconstant development for years and continues to evolve in support of espionage-focused operations. Over time,\r\nKazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet\r\necosystem designed to enable persistent, covert access to target environments.\r\nThis upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence\r\ncollection. The threat actor has historically targeted organizations in the government and diplomatic sector in\r\nEurope and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for\r\nthe purpose of obtaining information supporting Russia’s foreign policy and military objectives.\r\nWhile many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid\r\ndetection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and\r\nstealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and\r\nrestricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also\r\nmaintains flexible tasking, data staging, and multiple fallback channels for command and control (C2).\r\nUnderstanding this architecture helps defenders move beyond single sample analysis and instead focus on the\r\nbehaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing,\r\nworking directory staging, and periodic exfiltration.\r\nKazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior\r\nreporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today.\r\nThis blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot\r\necosystem composed of three distinct module types, each with clearly defined roles. Together, these components\r\ndistribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad\r\ntasking while minimizing opportunities for detection.\r\nDelivery\r\nKazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the\r\nencrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound\r\nto the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the\r\nintended host.\r\nIn another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes\r\nthe loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute\r\nthe Kazuar modules.\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 1 of 18\n\nFigure 1. Example delivery chain: a dropper deploys a lightweight .NET loader and supplies the\r\ndecrypted Kazuar payload for in-memory execution.\r\nModule types\r\nThere are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality\r\ncontained in each type and how they interact with each other.\r\nThis diagram shows the general interactions between a set of modules on a single host. Each infected host needs to\r\nhave all three modules to create the full P2P network:\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 2 of 18\n\nFigure 2. Overview of Kernel, Bridge, and Worker module interactions on a single host, showing\r\ninternal IPC and external C2 routing through the Bridge.\r\nNote: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal\r\nmodule and thread names, message types, configuration keys, or mode/flag values). \r\nType: Kernel\r\nThe Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages\r\ncommunication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the\r\nKernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the\r\nUnit 42 write-up and include standard checks such as:\r\nChecking for running processes containing analysis tools\r\nChecking for canary files on the desktop\r\nChecking the loaded process for sandbox-related DLLs\r\nModule configuration\r\nOnce these checks are passed, the Kernel module sets up the environment based on numerous configuration\r\noptions. Previous versions of Kazuar have used separate files containing the configuration information, but these\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 3 of 18\n\nare now embedded in the samples and have significantly increased the number of configurations available to the\r\nmalware family. \r\nThe configuration set can vary across 150 different configuration types, C2 communication infrastructures, or\r\ntasking options generally defined by eight functional categories. Any operational configuration in use can be\r\nupdated at any time from the C2 server. The following table contains some examples and descriptions of the\r\ncategories.\r\nCategory\r\nExample configuration\r\noptions\r\nDescription\r\nCommunication\r\nand transport\r\ntransport, ws_transport,\r\nheart_beat, ews_url,\r\nkeywords\r\nControls how the malware communicates with\r\nC2 infrastructure, including HTTP and\r\nWebSocket transports, Exchange Web Services\r\n(EWS) email-based C2, heartbeat intervals, and\r\nconnection parameters\r\nExecution and\r\ninjection\r\ninject_mode,\r\ndelegate_enabled,\r\nlive_in_scrcons,\r\nmodules\r\nDefines how the malware executes and persists\r\nin memory, including process injection\r\ntechniques\r\n(inject/remote/zombify/combined/single),\r\nmodule loading, and process hosting strategies\r\nSecurity bypass\r\namsi_bypass,\r\nwldp_bypass,\r\netw_bypass,\r\nantidump_methods,\r\nhinder_enabled\r\nConfigures evasion techniques to avoid\r\ndetection by security tools, including bypasses\r\nfor Antimalware Scan Interface (AMSI),\r\nWindows Lockdown Policy (WLDP), Event\r\nTracing for Windows (ETW), and anti-debugging/anti-dump protections\r\nData exfiltration\r\ntiming\r\nsend_hour_min,\r\nsend_hour_max,\r\nsend_on_weekend,\r\nmax_send_chunk,\r\nsend_times_max\r\nControls when and how collected data is\r\nexfiltrated, including working hours restrictions\r\n(8:00 AM – 8:00 PM default), weekend\r\nbehavior, chunk sizes, retry limits, and rate\r\nlimiting to blend with normal network traffic\r\nTask\r\nmanagement\r\ntask_time_limit,\r\ntask_max_store_time,\r\nsolve_threads,\r\nmax_solve_tries,\r\nmax_deadlock_ivl\r\nManages execution of received\r\ntasks/commands, including timeouts, thread\r\npool sizing, retry logic, deadlock detection, and\r\ntask queuing/storage parameters\r\nFile collection autos_patterns,\r\nautos_folders,\r\nautos_min_fsize,\r\nautos_max_fsize,\r\nConfigures automated file harvesting, including\r\ntarget file patterns, folder paths to scan, file size\r\nfilters (min/max), total collection limits, and\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 4 of 18\n\nautos_max_size,\r\nautos_file_ivl\r\nscanning intervals for continuous collection\r\noperations\r\nSystem state\r\nworking_dir,\r\nagent_uuid, hostname,\r\nbotID, start_attempts,\r\nwas_shutdown,\r\nfirst_sysinfo_do\r\nMaintains agent identity and operational state,\r\nincluding unique identifiers, working\r\ndirectories, startup tracking, shutdown flags, and\r\ninitial reconnaissance behavior\r\nMonitoring\r\nkeylog_enabled,\r\nkeylog_size,\r\nautos_do_scrshot,\r\nautos_do_steal,\r\nautos_scrs_ivl,\r\nmax_total_peeps,\r\npeep_rules\r\nControls active surveillance capabilities,\r\nincluding keylogging (buffer size, flush\r\nintervals), screenshot capture, credential theft,\r\nMessaging Application Programming Interface\r\n(MAPI) email monitoring, and configurable\r\nmonitoring rules/intervals.\r\nTable 1. Configuration options\r\nThis configuration exposes three internal communication mechanisms:\r\nWindow Messaging\r\nMailslot\r\nNamed pipes\r\nThere are also three different communication protocols for external communication:\r\nExchange Web Services (EWS)\r\nHTTP\r\nWebSockets (WSS)\r\nThey typically contain redundant or fallback communications to maintain access in the event of the failure of a\r\nsingle point of contact.\r\nLeadership election\r\nOne of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In\r\nthis architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on\r\nbehalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple\r\ninfected hosts.\r\nThere are several conditions that determine whether a new leader needs to be elected among participating Kernel\r\nmodules:\r\n1. There currently is no leader.\r\n2. The leader announces it is shutting down.\r\n3. The leader announces it is logging off.\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 5 of 18\n\n4. If an election does not result in a leader due to an error, a new election will be called.\r\nElections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel\r\nmodule has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it\r\nannounces itself as the leader and tells all other Kernel modules to set SILENT.\r\nFigure 3. Kernel leadership election overview showing a single active leader and multiple client\r\nKernel modules operating in SILENT mode\r\nOnly the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks\r\nthrough the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and\r\ndelegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT\r\nmode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the\r\nmaintained agent list.\r\nWith the hierarchy established, the work can be done. Several threads and communication types are initialized to\r\nperform the work and communicate between modules.\r\nREMO thread\r\nThe REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages\r\nwith other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-\u003cBot version\u003e, which results in\r\na pipe path such as \\\\.\\pipe\\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through\r\nadditional strings passed into the name-building function, but this pattern is the default. This channel lets the leader\r\ntarget specific client Kernel modules when delegating work.\r\nMessages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:\r\nRequest another Kernel module’s logs\r\nAssign tasks to a client Kernel module\r\nBecause only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the\r\nother Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task\r\nto the appropriate client Kernel module through this channel.\r\nMSGW thread\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 6 of 18\n\nFor Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:\r\nWindow Messaging [default selection]\r\nRegisters a hidden window\r\nMailslot\r\nRegisters a Mailslot\r\nBased on its initial configuration, Kazuar selects one of these communication types to listen for incoming\r\ncommunication, with the default being Windows Messaging.\r\nWindow Messaging setup\r\nThis technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is\r\nsimply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.\r\nThis allows other processes to look up the window by ClassName and use several different APIs to send a message\r\nto that window. When the window receives a message, the WindProc is executed to parse it and carry out the\r\nrequested action.\r\nMailslot setup\r\nThe Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The\r\nconfiguration can optionally append an additional identifier (empty by default), which allows deployments to create\r\ndistinct Mailslot namespaces when needed.\r\nFigure 4. Example IPC message type identifiers used for inter-module communication within the\r\nbotnet.\r\nThe string is hashed and used as the name to create the Mailslot: \\\\.\\mailslot\\\u003cgenerated hash\u003e.\r\nA thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it\r\nfinds one, it parses the incoming message.\r\nMessage types\r\nRegardless of what message delivery system is selected, the message is parsed by the same handler function. For\r\nthe Kernel module, this message parsing function has numerous expected communication messages, since it\r\ncontrols all the modules execution flows.\r\nThe following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate\r\na message, and what the Kernel does when it receives each message:\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 7 of 18\n\nKernel\r\noutgoing\r\nMsgType\r\nMsgType reason Module(s)\r\nKernel incoming\r\nMsgType\r\nKernel actions\r\nTASK\r\n– Issue task to\r\nworker\r\nWorker TASK_RESULT\r\n– Response\r\nmessage is logged\r\nby the Kernel\r\n– Result file is\r\ncreated with results\r\nof the task\r\nCHECK\r\n– Only the leader\r\ncan send this\r\n– Request new\r\ntasks from\r\nremote C2\r\nBridge CHECK_RESULT\r\n– If the C2 has\r\ntasks, the Kernel\r\ncreates a task file\r\n– Can also receive\r\nalternate C2 URLs\r\nthat are added to\r\nthe stored\r\nconfiguration\r\nSYN\r\n– Target module\r\nneeds to request a\r\nnew config\r\nBridge,\r\nWorker\r\nGET_CONFIG\r\n– Kernel sends its\r\nconfiguration to the\r\nrequesting module\r\n(Worker\r\nthread –\r\nPEEP)\r\n– Configuration-based\r\nWorker PEEP\r\n– PEEP result file is\r\nwritten unless it has\r\nreached its\r\nconfigured max\r\nPEEP number\r\nSEND\r\n– Send result file\r\nto be forwarded\r\nto C2\r\nBridge SEND_RESULT\r\n– Result file is\r\ndeleted\r\n(Worker\r\nthread –\r\nKEYL)\r\n– Configuration-based\r\nWorker KEYLOG\r\n– Writes keylog\r\ndata to keylog\r\noutput file\r\n(Multiple\r\nFilesystem\r\nWorker\r\nthreads) \r\n– Configuration-based\r\nWorker AUTOS\r\n– Writes AUTO\r\ndata to AUTOS\r\noutput files\r\nTable 2. Message types\r\nSEND thread\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 8 of 18\n\nThe configuration specifies an external communication method from the available communication modes\r\nHTTP [default selection]\r\nWeb Socket Server (WSS)\r\nExchange Web Server (EWS)\r\nThese configurations can be changed at any point when the C2 sends a new configuration, or a change\r\ncommunication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the\r\nSEND actions to occur with the default timer being every hour. There are also working timers that can install a\r\nblackout period on communications to blend in with the target environment.\r\nFigure 5. External communication (SEND) configuration, including transport selection, timers, and\r\nblackout/heartbeat controls.\r\nNote: Only the elected Kernel leader can perform the following actions:\r\nIf the Kernel has task results \r\nRead in the task file\r\nSend SEND message to Bridge with the task result file\r\nGet new tasks from Bridge\r\nSend CHECK message to Bridge\r\nTable 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and\r\nrecorded as tasks by the Kernel.\r\nThere is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the\r\nKernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a\r\ncertain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.\r\nSOLV thread\r\nThis thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread\r\nperforms several functions related to the current task list:\r\nLoop through the list of current tasks\r\nCheck if aborted flag is true\r\nIssue TaskKill message to the worker (Window Messaging)\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 9 of 18\n\nRemove task from task list\r\nCheck if task has exceeded the configured max working time for task\r\nIssue TaskKill message to the worker (Window Messaging)\r\nSet aborted flag for task to true\r\nRemove task from task list\r\nRead in all task files from the working directory\r\nIf the task is new\r\nAdd task to task list\r\nType: Bridge\r\nThe Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader\r\nKernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own\r\nWorker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module\r\nfor communication. It typically has the same default configuration as the Kernel module but does contain a few\r\ndifferent operations that set up the initial infection.\r\nThe Bridge module initializes its core object with basic metadata and instantiates two supporting components that\r\nprovide the module’s primary functionality:\r\nServer Communication module\r\nTask Handling module\r\nThe module registers handlers for two system-level events. These handlers define how the module should respond\r\nwhen specific system events occur:\r\nSystemEvents.SessionEnded\r\nSystemEvents.PowerModeChanged\r\nWhen an event is triggered, the corresponding handler function is invoked, allowing the module to determine the\r\nappropriate action for that event. Events are typically ignored unless they require explicit handling.\r\nThe module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on\r\nits initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows\r\nMessaging as the IPC mechanism used for communication between modules. Once the setup steps is completed,\r\nthe module is ready to proxy communication between the leader Kernel module and the C2 server.\r\nType: Worker\r\nThe initial Worker configuration mirrors the structure of other module configurations and follows the same overall\r\nlayout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the\r\nIPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows\r\nMessaging; further details on the window setup are described below.\r\nDuring initialization, the Worker configuration instantiates several objects responsible for the module’s primary\r\nfunctionality. Each object is executed within its own named thread. These components include:\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 10 of 18\n\nTask Solver\r\nHandles task tracking\r\nPeep\r\nHooks windows events\r\nHas a max number of windows to hook set by the configuration\r\nKeylogger\r\nFilesystem\r\nGINFO – Gather system info\r\nGFIL – Gather file listings\r\nRecent files\r\nDesktop\r\nMalware working directory\r\nGHOO – Window information\r\nGMAP – Gather MAPI info\r\nEmail information\r\nData collected by these components is aggregated, encrypted, and written to the malware’s working directory,\r\nwhere it is staged for subsequent exfiltration to the C2 server.\r\nBotnet operations\r\nWith the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady\r\nstate operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection\r\nacross participating modules while maintaining a deliberately low observable footprint. Worker modules execute\r\ntasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file,\r\nwindow, and user activity data according to defined schedules and limits.\r\nModule-to-module messaging\r\nWhen one module needs to communicate with another, all required information is assembled into a structured\r\nmessage packet. Multiple packet formats are defined, with the specific format determined by the message type and\r\nintended action.\r\nThese message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured,\r\nschema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize,\r\ntransmit, and parse messages through standard library functions.\r\nMessages destined for the Bridge module include additional fields that describe how the request should be\r\nforwarded to the remote C2 infrastructure. These fields specify transport level details, including the external\r\ncommunication mechanism to be used.\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 11 of 18\n\nFigure 6. Protobuf-based message structure used to route requests between modules and describe\r\nhow the Bridge should forward traffic to C2.\r\nFigure 7. Additional message fields and transport parameters that influence delivery method (e.g.,\r\nHTTP vs. EWS) and destination module.\r\nThe TransportType field can specify one of three supported communication methods. The default transport is\r\ntypically HTTP, using the C2 URLs in the default configuration.\r\nWhen sending a message, the dispatch function examines the contents of the message packet to determine the\r\nappropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes\r\nthe packet to the intended module.\r\nFor example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its\r\nExchange communication component to encapsulate the data and deliver it to the remote C2 server via email.\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 12 of 18\n\nFigure 8. Example routing flow when TransportType is set to EWS, where the Bridge encapsulates\r\ndata and delivers it to C2 via email-based communication.\r\nMessages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel\r\nmodule based on their configuration.\r\nFigure 9. High-level module messaging map showing how the Kernel leader coordinates Worker\r\ntasking and uses the Bridge module for external C2 communications.\r\nWorking directory\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 13 of 18\n\nKazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations\r\nacross modules. This directory is defined through configuration and is consistently referenced using fully qualified\r\npaths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by\r\nfunction, isolating tasking, collection output, logs, and configuration material into distinct locations. This design\r\nallows the malware to decouple task execution from data storage and exfiltration, maintain operational state across\r\nrestarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external\r\ninfrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally\r\nuntil explicitly forwarded to the C2 infrastructure through the Bridge module.\r\nWithin this working directory, Kazuar maintains separate storage locations for the following functional data types:\r\nPeeps\r\nAutos\r\nFiles\r\nHashes\r\nResult files\r\nTask files\r\nConfig files\r\nCommon wordlist\r\nCommon exe\r\nLogs\r\nKeylogger\r\nThis structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across\r\nleadership changes or reboots, and blend malicious activity into routine file system usage.\r\nModule tasks\r\nThe list of commands available for the Worker modules to perform is extensive and has many features, from\r\narbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42\r\nblog.\r\nThe Kernel module task handler has a few additional functions that handle commands issued from the leader\r\nKernel module.\r\nTask Description\r\nkernel A list of commands to be executed by the Kernel module\r\ndelegate Send command via Named pipe to targeted Kernel module\r\nmodules\r\nHandles the list of agents maintained by the Kernel module list – List modules in the\r\nagents list clear – Clear list of agents add – Add an agent to the list by ID remove –\r\nRemove an agent from the list by ID\r\nautoslist Gets list of hashes and files collected by autos\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 14 of 18\n\nautosget Sends all of the autos files to requesting module and deletes autos files\r\nautosdel Deletes all autos files\r\nTable 3. Module tasks\r\nSystem info gathering\r\nSystem info gathering is often enabled by default in the configuration. This causes an initial collection of system\r\ninformation when the agent starts up. This task collects an extensive amount of information about the system and\r\nits user.\r\nOptional OS features\r\nInstalled AV\r\nAMSI provider\r\nSecurity packages\r\nAppLocker setting\r\nLogical drives\r\nUSB devices\r\nNetwork adapters\r\nARP tables\r\nNetwork connections\r\nNetwork shares\r\nRDP hints\r\nRunning processes\r\nLoaded modules (current\r\nprocess)\r\nPipe list\r\nActive windows\r\nRecent documents\r\nOutlook downloads\r\nRecent items\r\nOS info\r\nSystem Boot events\r\nHardware info\r\nUser info\r\nLocal users\r\nLogon sessions\r\nUser profiles\r\nSpecial folders\r\nExplorer Run command\r\nhistory\r\nExplorer typed paths\r\nExplorer search history\r\nEnvironment variables\r\nUAC settings\r\nInternet settings\r\nDNS cache\r\nNetwork PowerShell\r\nversions\r\nWSUS settings\r\nInstalled software\r\nHot patches\r\nUpdate history\r\nServices Drivers\r\nTable 4. List of system info gathered\r\nScreenshots are also taken through various methods and saved for exfiltration both automatically through the\r\nconfiguration or when a task is issued.\r\nWho is Secret Blizzard?\r\nThe United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to\r\nCenter 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer\r\nNetwork Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the\r\ntechnical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security\r\nvendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.\r\nSecret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs,\r\nembassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard\r\nfocuses on gaining long-term access to systems for intelligence collection using extensive resources such as\r\nmultiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During\r\nintrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 15 of 18\n\nseeks out information of political importance with a particular interest in advanced research that might impact\r\ninternational political issues.\r\nMitigation and protection guidance\r\nTo harden networks against the Secret Blizzard activity listed above, defenders can implement the following:\r\nStrengthen Microsoft Defender for Endpoint configuration\r\nMicrosoft Defender XDR customers can implement attack surface reduction rules to harden an environment\r\nagainst techniques used by threat actors.\r\nBlock execution of potentially obfuscated scripts.\r\nBlock process creations originating from PSExec and WMI commands\r\nBlock executable files from running unless they meet a prevalence, age, or trusted list criterion\r\nBlock abuse of exploited vulnerable signed drivers.\r\nEnable network protection in Microsoft Defender for Endpoint.\r\nEnsure that tamper protection is enabled in Microsoft Defender for Endpoint.\r\nRun endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can\r\nblock malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when\r\nMicrosoft Defender Antivirus is running in passive mode.\r\nConfigure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take\r\nimmediate action on alerts to resolve breaches, significantly reducing alert volume.\r\nStrengthen Microsoft Defender Antivirus configuration\r\nTurn on PUA protection in block mode in Microsoft Defender Antivirus.\r\nTurn on  cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus\r\nproduct to cover rapidly evolving threat actor tools and techniques.\r\nTurn on Microsoft Defender Antivirus real-time protection.\r\nStrengthen operating environment configuration\r\nEncourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies\r\nand blocks malicious websites, including phishing sites, scam sites, and sites that host malware.\r\nImplement PowerShell execution policies to control conditions under which PowerShell can load\r\nconfiguration files and run scripts.\r\nTurn on and monitor PowerShell module and script block logging.\r\nMicrosoft Defender detections\r\nMicrosoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates\r\ndetection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated\r\nprotection against attacks like the threat discussed in this blog.\r\nTactic  Observed activity  Microsoft Defender coverage \r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 16 of 18\n\nExecution Execution of malware components\r\nMicrosoft Defender Antivirus\r\n– Kazuar (OA, OB)\r\n– KazuarModule\r\n– KazuarLoader\r\n– ShadowLoader\r\n– ToxicDust\r\nMicrosoft Defender for Endpoint\r\n– Secret Blizzard actor activity detected\r\nMicrosoft Security Copilot\r\nMicrosoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered\r\ncapabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and\r\ngenerate device summaries, hunting queries, and incident reports.\r\nCustomers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform\r\nsecurity tasks efficiently:\r\nThreat Intelligence Briefing agent\r\nPhishing Triage agent\r\nThreat Hunting agent\r\nDynamic Threat Detection agent\r\nSecurity Copilot is also available as a standalone experience where customers can perform specific security-related\r\ntasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security\r\nCopilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins\r\nto meet unique security needs.\r\nThreat intelligence reports\r\nMicrosoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires\r\nlicense for at least one Defender XDR product) to get the most up-to-date information about the threat actor,\r\nmalicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection\r\ninformation, and recommended actions to prevent, mitigate, or respond to associated threats found in customer\r\nenvironments.\r\nActor profile: Secret Blizzard\r\nMicrosoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft\r\nDefender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the\r\nMicrosoft Defender portal to get more information about this threat actor.\r\nIndicators of compromise\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 17 of 18\n\nIndicator Type Description\r\n69908f05b436bd97baae56296bf9b9e734486516f9bb9938c2b8752e152315d4\r\n \r\nSHA-256hpbprndiLOC.dll\r\n– Kazuar Loader\r\nc1f278f88275e07cc03bd390fe1cbeedd55933110c6fd16de4187f4c4aaf42b9\r\nSHA-256Decrypted\r\nKernel Module\r\n6eb31006ca318a21eb619d008226f08e287f753aec9042269203290462eaa00d\r\nSHA-256Decrypted\r\nBridge Module\r\n436cfce71290c2fc2f2c362541db68ced6847c66a73b55487e5e5c73b0636c85\r\nSHA-256Decrypted\r\nWorker Module\r\nReferences\r\nOver the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)\r\n COMmand \u0026 Evade: Turla’s Kazuar v3 Loader\r\nRussia’s FSB malign activity: factsheet\r\nHunting Russian Intelligence “Snake” Malware\r\nLearn more\r\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat\r\nIntelligence Blog.\r\nTo get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly\r\nTwitter), and Bluesky.\r\nTo hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat\r\nlandscape, listen to the Microsoft Threat Intelligence podcast.\r\nSource: https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nhttps://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/\r\nPage 18 of 18", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/" ], "report_names": [ "kazuar-anatomy-of-a-nation-state-botnet" ], "threat_actors": [ { "id": "8aaa5515-92dd-448d-bb20-3a253f4f8854", "created_at": "2024-06-19T02:03:08.147099Z", "updated_at": "2026-10-20T02:00:10.235896Z", "deleted_at": null, "main_name": "IRON HUNTER", "aliases": [ "ATK13 ", "Belugasturgeon ", "Blue Python ", "CTG-8875 ", "ITG12 ", "KRYPTON ", "MAKERSMARK ", "Pensive Ursa ", "Secret Blizzard ", "Turla", "UAC-0003 ", "UAC-0024 ", "UNC4210 ", "Venomous Bear ", "Waterbug " ], "source_name": "Secureworks:IRON HUNTER", "tools": [ "Carbon-DLL", "ComRAT", "Kazuar", "KopiLuwak", "LightNeuron", "Mosquito", "Nautilus", "Neuron", "Penquin", "PoisonFrog", "PyFlash", "STOCKSTAY", "Skipper", "Snake", "Tavdig", "TinyTurla", "Tunnus" ], "source_id": "Secureworks", "reports": null }, { "id": "d5156b55-5d7d-4fb2-836f-861d2e868147", "created_at": "2023-01-06T13:46:38.557326Z", "updated_at": "2026-10-20T02:00:07.048047Z", "deleted_at": null, "main_name": "Gamaredon Group", "aliases": [ "DEV-0157", "Blue Otso", "BlueAlpha", "PRIMITIVE BEAR", "Shuckworm", "Trident Ursa", "UAC-0010", "Winterflounder", "ACTINIUM", "G0047", "IRON TILDEN", "Aqua Blizzard", "Actinium" ], "source_name": "MISPGALAXY:Gamaredon Group", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "a97cf06d-c2e2-4771-99a2-c9dee0d6a0ac", "created_at": "2022-10-25T16:07:24.349252Z", "updated_at": "2026-10-20T02:00:17.352641Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "ATK 13", "Belugasturgeon", "Blue Python", "CTG-8875", "G0010", "Group 88", "ITG12", "Iron Hunter", "Krypton", "Makersmark", "Operation Epic Turla", "Operation Moonlight Maze", "Operation Penguin Turla", "Operation Satellite Turla", "Operation Skipper Turla", "Operation Turla Mosquito", "Operation WITCHCOVEN", "Pacifier APT", "Pensive Ursa", "Popeye", "SIG15", "SIG2", "SIG23", "Secret Blizzard", "TAG-0530", "Turla", "UNC4210", "Venomous Bear", "Waterbug" ], "source_name": "ETDA:Turla", "tools": [ "ASPXSpy", "ASPXTool", "ATI-Agent", "AdobeARM", "Agent.BTZ", "Agent.DNE", "ApolloShadow", "BigBoss", "COMpfun", "Chinch", "Cloud Duke", "CloudDuke", "CloudLook", "Cobra Carbon System", "ComRAT", "DoublePulsar", "EmPyre", "EmpireProject", "Epic Turla", "EternalBlue", "EternalRomance", "GoldenSky", "Group Policy Results Tool", "HTML5 Encoding", "HyperStack", "IcedCoffee", "IronNetInjector", "KSL0T", "Kapushka", "Kazuar", "KopiLuwak", "Kotel", "LOLBAS", "LOLBins", "LightNeuron", "Living off the Land", "Maintools.js", "Metasploit", "Meterpreter", "MiamiBeach", "Mimikatz", "MiniDionis", "Minit", "NBTscan", "NETTRANS", "NETVulture", "Neptun", "NetFlash", "NewPass", "Outlook Backdoor", "Penquin Turla", "Pfinet", "PowerShell Empire", "PowerShellRunner", "PowerShellRunner-based RPC backdoor", "PowerStallion", "PsExec", "PyFlash", "QUIETCANARY", "Reductor RAT", "RocketMan", "SMBTouch", "SScan", "Satellite Turla", "SilentMoon", "Sun rootkit", "TTNG", "TadjMakhal", "Tavdig", "TinyTurla", "TinyTurla Next Generation", "TinyTurla-NG", "Topinambour", "Tunnus", "Turla", "Turla SilentMoon", "TurlaChopper", "Uroburos", "Urouros", "WCE", "WITCHCOVEN", "WhiteAtlas", "WhiteBear", "Windows Credential Editor", "Windows Credentials Editor", "Wipbot", "WorldCupSec", "XTRANS", "certutil", "certutil.exe", "gpresult", "nbtscan", "nbtstat", "pwdump" ], "source_id": "ETDA", "reports": null }, { "id": "61940e18-8f90-4ecc-bc06-416c54bc60f9", "created_at": "2022-10-25T16:07:23.659529Z", "updated_at": "2026-10-20T02:00:12.225693Z", "deleted_at": null, "main_name": "Gamaredon Group", "aliases": [ "Actinium", "Aqua Blizzard", "Armageddon", "Blue Otso", "BlueAlpha", "Callisto", "DEV-0157", "G0047", "Iron Tilden", "Operation STEADY#URSA", "Primitive Bear", "SectorC08", "Shuckworm", "Trident Ursa", "UAC-0010", "UNC530", "Winterflounder" ], "source_name": "ETDA:Gamaredon Group", "tools": [ "Aversome infector", "BoneSpy", "DessertDown", "DilongTrash", "DinoTrain", "EvilGnome", "FRAUDROP", "Gamaredon", "GammaDrop", "GammaLoad", "GammaSteel", "Gussdoor", "ObfuBerry", "ObfuMerry", "PlainGnome", "PowerPunch", "Pteranodon", "Pterodo", "QuietSieve", "Remcos", "RemcosRAT", "Remote Manipulator System", "Remvio", "Resetter", "RuRAT", "SUBTLE-PAWS", "Socmer", "UltraVNC" ], "source_id": "ETDA", "reports": null }, { "id": "81bd7107-6b2d-45c9-9eea-1843d4b9b308", "created_at": "2022-10-25T15:50:23.320841Z", "updated_at": "2026-10-20T02:00:07.077032Z", "deleted_at": null, "main_name": "Gamaredon Group", "aliases": [ "Gamaredon Group", "IRON TILDEN", "Primitive Bear", "ACTINIUM", "Armageddon", "Shuckworm", "DEV-0157", "Aqua Blizzard", "NastyShrew" ], "source_name": "MITRE:Gamaredon Group", "tools": [ "QuietSieve", "Pteranodon", "Remcos", "PowerPunch" ], "source_id": "MITRE", "reports": null }, { "id": "a97fee0d-af4b-4661-ae17-858925438fc4", "created_at": "2023-01-06T13:46:38.396415Z", "updated_at": "2026-10-20T02:00:05.458632Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "Group 88", "Pacifier APT", "IRON HUNTER", "MAKERSMARK", "G0010", "UAC-0024", "Waterbug", "Uroburos", "TAG_0530", "Popeye", "SIG23", "UNC4210", "UAC-0144", "Pfinet", "Secret Blizzard", "UAC-0003", "TURLA RELIC", "VENOMOUS Bear", "KRYPTON", "Hippo Team", "ATK13", "ITG12", "Blue Python" ], "source_name": "MISPGALAXY:Turla", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "af0d5085-bbd0-4945-a6c1-c7233372b8f4", "created_at": "2026-09-17T02:00:03.761958Z", "updated_at": "2026-10-20T02:00:08.371231Z", "deleted_at": null, "main_name": "IRON TILDEN", "aliases": [ "ACTINIUM ", "Aqua Blizzard ", "Armageddon", "Blue Otso ", "BlueAlpha ", "Dancing Salome ", "Gamaredon", "Gamaredon Group", "Hive0051 ", "Primitive Bear ", "Shuckworm ", "Trident Ursa ", "UAC-0010 ", "UNC530 ", "WinterFlounder " ], "source_name": "Secureworks:IRON TILDEN", "tools": [ "Pterodo" ], "source_id": "Secureworks", "reports": null }, { "id": "d11c89bb-1640-45fa-8322-6f4e4053d7f3", "created_at": "2022-10-25T15:50:23.509601Z", "updated_at": "2026-10-20T02:00:08.980938Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "Turla", "IRON HUNTER", "Group 88", "Waterbug", "WhiteBear", "Krypton", "Venomous Bear", "Secret Blizzard", "BELUGASTURGEON" ], "source_name": "MITRE:Turla", "tools": [ "PsExec", "nbtstat", "ComRAT", "netstat", "certutil", "KOPILUWAK", "IronNetInjector", "LunarWeb", "Arp", "Uroburos", "PowerStallion", "Kazuar", "Systeminfo", "LightNeuron", "Mimikatz", "Tasklist", "LunarMail", "HyperStack", "NBTscan", "TinyTurla", "Penquin", "LunarLoader" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1779156133, "ts_updated_at": 1792487558, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/5d5d25c09afa56059b0547dae67cb9dd2786cfeb.pdf", "text": "https://archive.orkl.eu/5d5d25c09afa56059b0547dae67cb9dd2786cfeb.txt", "img": "https://archive.orkl.eu/5d5d25c09afa56059b0547dae67cb9dd2786cfeb.jpg" } }