Since January 2026, Microsoft has observed Russian state threat actor Star Blizzard evolve their detection evasion capabilities through large-scale phishing campaigns, the use of accounts on compromised websites, and a novel malware delivery technique that Microsoft tracks as “RedFlick”. These changes represent a notable shift in the actor’s operational tradecraft and support ongoing cyberespionage activity targeting Ukrainian individuals and institutions as well as international non-government organizations (NGOs), Western think tanks, governments, and other organizations associated with international policy—particularly those with a nexus in supporting Ukraine.

As part of this evolution, Star Blizzard adopted RedFlick, a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actor’s custom backdoor, CosmicPulse. This technique is a notable departure from the actor’s previous use of ClickFix-based infection chains which required victims to complete multiple actions before CosmicPulse could be installed. By contrast, the RedFlick infection flow only requires a single user interaction, reducing friction in the compromise process. Combined with the actor’s shift toward large-scale phishing operations during the same period, these changes likely improve Star Blizzard’s ability to reach more targets, evade detection, and increase the likelihood of successful compromise.

This blog provides updated technical analysis of Star Blizzard’s tactics, techniques, and procedures (TTPs) observed throughout 2026, building on our 2025 and 2023 blogs. It details the actor’s evolving phishing, persistence, and malware delivery techniques, and provides recommendations, indicators of compromise (IOCs), detections, and hunting guidance to help organizations identify and defend against RedFlick-related activity. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with recommendations and mitigations to secure their accounts.

Star Blizzard TTPs observed in 2026

Star Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as subordinate to the Russian Federal Security Service Centre (FSB) Centre 18. Star Blizzard periodically overhauls their TTPs to avoid detection, often in response to public exposure of the actor’s campaigns that have involved targeted social engineering through messaging apps and credential theft. Since Google Threat Intelligence Group published its report on Star Blizzard’s COLDCOPY malware in October 2025, Microsoft observed the actor refine their initial access and evasive techniques to include:

• Moving away from targeted spear phishing to large-scale initial contact phishing campaigns
• Using compromised websites to create accounts to send phishing emails
• Updating malware deployment to facilitate the installation of a CosmicPulse downloader

As of the writing of this blog, the RedFlick campaigns have targeted Ukrainian individuals and institutions, as well as international NGOs, think tanks, governments, and financial institutions that have supported Ukraine politically or financially. Microsoft has observed this activity affect over 100 organizations primarily in the United States and United Kingdom, consistent with Star Blizzard’s longstanding targeting priorities.

Microsoft continues to observe some previously reported Star Blizzard phishing techniques throughout 2026; however, the TTPs discussed in this blog have been associated primarily with the actor’s new larger-scale phishing campaigns.

Larger-scale initial contact phishing

Microsoft previously reported on Star Blizzard’s spear-phishing campaigns observed during 2023-2024. During these operations, the actor continued to rely on their conventional TTPs such as initiating email contact with targets before sending a follow-up containing a malicious link, to actor-controlled/compromised infrastructure purposed for credential theft, while impersonating known political or diplomatic figures to lure victims into responding.

In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns. The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actor’s adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool. The progression of these campaigns is summarized in the following timeline, including examples of Star Blizzard’s phishing subject lines, targeting details, and the malware delivery methods observed across each campaign:

• January
  • “Повідомлення про результати податкової перевірки” (Notice of tax audit results) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• February
  • “списання з Вашого рахунку за оплату штрафу” (Debiting from your account for payment of a fine) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• March
  • “Invitation to an IISS [Private Roundtable/Closed-Door Discussion] on European Security” – Initial contact campaign targeting government officials, security researchers, academia, media, and NGOs. Respondents received a RedFlick lure attachment.
  • “Invitation to a Closed CES Roundtable Discussion” – Initial contact campaign targeting US and Europe technology-sector organizations. Respondents received a RedFlick lure attachment.
  • “Atlantic Council Closed-Door Strategic Discussion” – Initial contact campaign targeting government officials, foreign policy practitioners, security researchers, academia, media, and NGOs. Respondents received a link to DarkSword iOS backdoor installation.
• April
  • “Closed-Door Online Session on Global Capital Allocation & M&A” – Initial contact campaign targeting international financial organizations and researchers. Respondents received a RedFlick lure attachment.
• May
  • “Future of Peace Operations Forum – A Closed Strategic Dialogue” – Initial contact campaign targeting diplomatic and multilateral organizations. Respondents received a RedFlick lure attachment.
  • “Future of Liberty Forum” – Initial contact campaign targeting employees of a US-based think tank. Respondents received a RedFlick lure attachment.
• June
  • “Invitation to the MAMA Summit on the Current Situation Surrounding the Ukrainian Crisis” – Initial contact campaign targeting incumbent/former diplomatic staff. Respondents received a RedFlick lure attachment.
  • “Invitation to the Chatham House London Conference 2026 – 9 July 2026” – Initial contact campaign targeting think tanks, NGOs, and national parliamentary. Respondents received a RedFlick lure attachment.
• July
  • “Thought you might find this USUBC roundtable of interest” – Initial contact campaign targeting think tanks, NGOs, and Ukraine civil society. Respondents received a RedFlick lure attachment.
  • “Інформація щодо тимчасового відключення водопостачання” (Information about temporary water supply shutdown) – Targeted Kyiv-based hotels with an attached RedFlick lure.
• August
  • “Payment Advice Note from 06.08.2026” – Targeted employees of an international financial organization with an attached RedFlick lure.

Once a recipient responds to the initial phishing email, Star Blizzard typically sends a follow-up message containing a password-protected RAR or ZIP archive. The archive contains files that initiate the RedFlick infection flow. The password is included as an image in the follow-up email shown in Figure 1, along with additional examples of Star Blizzard follow-up emails below:

Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide. The earliest campaigns, observed between January and February, targeted unspecified users of the Ukraine email provider Ukr.net. These emails impersonated Ukrainian authorities and were themed as notifications of a tax audit or outstanding fine.

Beginning in March 2026, Star Blizzard expanded targeting outside of Ukraine. Subsequent campaigns frequently used lures themed as invitations to conferences or events purportedly organized by a reputable think tank or NGO. Microsoft also observed the actor target multiple individuals within the same organization, with phishing emails often crafted to appear as internal communications originating from the targeted organization itself. The actor’s shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities.

The large-scale campaigns have demonstrated capabilities previously unassociated with Star Blizzard. For example, a campaign observed in mid-August 2026 employed steganography to conceal identifiers. Throughout 2026, Star Blizzard has also continued to develop additional operational capabilities. Notably, ProofPoint reported in March that the actor had targeted vulnerable Apple iOS devices to deploy the DarkSword backdoor.

Creating accounts on compromised websites

Since March 2026, Star Blizzard has made another notable change to their TTPs to support the higher-volume phishing operations, using accounts created on compromised websites to send phishing emails to targets. This change coincided with the actor’s shift to larger-scale phishing campaigns and has been observed almost exclusively in support of these operations. Previously, the actor would create accounts on free email services (predominantly using Protonmail and Microsoft consumer accounts) to impersonate an individual that would be well known to the prospective target, whether it was a political figure, academic, or former diplomat. In the large-scale campaigns, Star Blizzard has used accounts created on websites hosted on CPanel and WordPress, using the same account name across multiple website domains. Microsoft Threat Intelligence assesses with high confidence that these websites have been compromised by Star Blizzard for this purpose.

Updating malware delivery and installation TTPs

Between January and August 2026, Microsoft observed multiple waves of Star Blizzard phishing campaigns alongside notable changes in the actor’s initial access TTPs, particularly the use of RedFlick scheduled tasks. During this period, Microsoft observed three significant shifts in the threat actor’s delivery techniques.

From ClickFix to VHDX

In mid-January 2026, Microsoft observed the use of a malicious Virtual Hard Disk v2 (VHDX), delivered through a phishing email containing a password-protected ZIP file. The VHDX file ships a malicious LNK file disguised as a PDF document, alongside a hidden directory containing a BAT script and a legitimate decoy PDF.

When the victim opens the LNK file, conhost.exe is launched in a hidden window and cmd.exe is subsequently spawned to execute the embedded BAT script:

The BAT file opens the decoy PDF and invokes SSH.exe with PermitLocalCommand enabled, ultimately downloading and executing a remotely hosted MSI installer:

In multiple campaigns, Microsoft observed an MSI installer creating a scheduled task that uses control.exe to download and execute a remotely hosted CosmicPulse downloader masquerading as a Control Panel applet (CPL). Unlike earlier campaigns that relied on ClickFix lures and user interaction, this approach relies on compiling the CosmicPulse downloader as a Control Panel applet DLL.

The shift from interactive user execution to remote execution and masquerading as a CPL item highlights an evolution in both persistence and defense evasion techniques.

CosmicPulse downloader

The Control Panel applet DLL is a downloader with the sole purpose of downloading and installing a version of CosmicPulse, a malicious Python backdoor, on the target device. The downloader is also known publically as NOROBOT or BAITSWITCH.

Similar to previous versions, this downloader downloads, persists, and executes a version of CosmicPulse on the infected device. Upon execution, it downloads two ZIP files and stores them on disk. It then writes an encrypted AES key to the HKEY_CURRENT_USER\Software\Classes\.mollis registry key. One ZIP file contains a Python 3.8 64-bit package and a Python file that serves as the CosmicPulse bootstrapper. The bootstrapper reads the encrypted key from the registry, recovers it using an embedded key in AES-ECB mode, and then uses the recovered key to decode the CosmicPulse payload (also known as YESROBOT) contained in the second ZIP file. The below image shows the process of the CosmicPulse installation.

Since January 2026, Microsoft has observed the CosmicPulse backdoor going through various little changes to circumvent existing signatures. However, the capabilities and purpose of this backdoor remain the same as described in previous articles.

Persistence through multiple scheduled tasks

In April 2026, Microsoft observed Star Blizzard changing persistence tactics to include RedFlick scheduled tasks. Whereas a malicious MSI file installed a single scheduled task in January—by April, the actor’s MSI installer created three scheduled tasks masquerading as legitimate network components, each with their own purpose. The TTPs have overlaps with the spear-phishing campaigns reported by the Digital Security Lab Ukraine (DLUA) in June 2026. In at least one incident, Microsoft has observed either the first or third task deploying an instance of CosmicPulse on the infected machine.

Task 1 – Registration beaconing and dynamic DLL execution task

The first task masquerades as a legitimate Internet Quality Test Connection task. The scheduled command serves two purposes. First, it sends a UTF-16 and Base64-encoded string containing the network or computer name and the username of the infected device to the C2 server. Thereby, it exfiltrates basic information about the infected host.

Second, an attacker-controlled DLL can be executed remotely through invoking Control_RunDLL from Shell32.dll. Microsoft was unable to obtain a variant of this payload. The task uses a WebDAV UNC path to access the remote payload, allowing the resource to be retrieved over HTTP rather than through a conventional SMB network share.

Task 2 – Supporting task

The second installed task, named Network Configuration Manager, supports the WebDAV-based execution used by the other tasks. The invoked command causes Windows to treat the UNC-style path as a WebDAV resource and process it through the WebDAV redirector and associated WebClient functionality.

Through WebDAV, Windows applications can interact with a remote web resource as though it is a file or folder path while the underlying communication is performed using HTTP/HTTPS rather than conventional SMB. The task therefore prepares the WebDAV client functionality required by the other scheduled tasks.

Task 3 – CosmicPulse downloader execution

The third installed task, named System Health Monitor, uses control.exe to access a remote path hosted on the hardcoded C2 server and execute the next stage.

Hiding payloads in PDF files

In July 2026, Microsoft observed another change in Star Blizzard’s delivery techniques, this time involving a multistage execution chain.

The phishing email contains a password-protected RAR archive nested inside a ZIP file. After the archive is opened, it exposes an LNK file.

When executed, the LNK file uses conhost.exe and curl to download a PDF from an actor-controlled server:

After downloading the PDF, the command runs a second PowerShell payload. This payload searches the PDF for the magic header cAB, extracts the subsequent 208 bytes of Base64-encoded data, and executes the decoded command through PowerShell. The resulting conhost command, shown below, attempts to download and install another MSI file:

As in previous campaigns, the Python installer contains obfuscated PowerShell code. When executed, the code attempts to create two additional scheduled tasks. The first scheduled task again serves as a helper task, consistent with the supporting tasks observed in previous campaigns. The second scheduled task attempts to download and execute a CPL applet again.

Star Blizzard’s shift from ClickFix-based delivery chains to VHDX files, expanded use of scheduled tasks for persistence, and concealment of payloads within PDF files demonstrate the actor’s continued ability to adapt their delivery methods in response to evolving defenses. The actor’s recent use of PDFs to conceal payloads further illustrates efforts to bypass layered defenses through increasingly complex execution chains. Taken together, these changes demonstrate Star Blizzard’s continued efforts to streamline malware deployment, reduce required user interaction, and improve operational scalability while maintaining its longstanding espionage objectives.

Defending against Star Blizzard and RedFlick-related activity

Microsoft Threat Intelligence advises organizations that are most likely at risk—primarily those in government, NGOs, or think tanks adjacent to Ukraine policy or support—to implement the following recommendations to mitigate against Star Blizzard activity.

Protecting against Star Blizzard phishing

As previously reported, Star Blizzard’s success relies on sophisticated, targeted phishing lures that trick users into engaging with the actor by impersonating trusted contacts. While Star Blizzard has changed their overall TTPs, the actor continues to employ the same phishing patterns against users:

• Star Blizzard continues to impersonate trusted contacts that users or organizations would expect an email from. Star Blizzard also continues using email from free providers such as Proton @proton[.]me, particularly in Evilginx spear-phishing operations observed throughout 2026. However, despite the actor’s recent shift toward leveraging compromised legitimate websites that impersonate real individuals associated with a target’s organization, users can still remain vigilant for other Star Blizzard TTPs, several of which have been observed in previous campaigns:
  • Star Blizzard continues to make initial contact with a target by sending an email, usually without an attachment.
  • If a user engages, Star Blizzard will follow up with an email with an attachment. In this particular campaign, it has been an archive file such as a RAR or ZIP.
  • The email sender contains names of actual persons and organizations they belong to—however, the organization is not within the root or registered domain itself but in the username or local part of the email address. This should draw a red flag to the email’s authenticity. When in doubt, directly contact the person you think sent the email using a previously established and trusted contact method such as known email address or phone number.
  • The emails in these RedFlick campaigns are often sent in bulk.
• To best mitigate against this activity, Microsoft suggests the following policies to strengthen network environments against Star Blizzard phishing operations:
  • Using phishing resistant authentication methods.
  • Lockdown account access using Conditional Access policies.
  • Use advanced anti-phishing solutions like Microsoft Defender for Office 365 that monitor and scan incoming emails and visited websites.
  • Turn on Safe Links and Safe Attachments for Office 365.

Microsoft also recommends the following mitigations to reduce the impact of this threat

• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable Conditional Access policies. Conditional Access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Turn on Microsoft Defender Antivirus real-time protection.
• Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the application’s consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
• Microsoft Defender customers can turn on attack surface reduction rules to prevent common attack techniques:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
• Utilize Windows Firewall, Windows Firewall with Advanced Security, or an enterprise firewall/filtering solution to help prevent or restrict outbound SSH connection attempts to external or public networks that are not essential for business.

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: Star Blizzard
• Tool profile: CosmicPulse
• Activity profile: New Star Blizzard spearphishing campaign targets WhatsApp accounts
• Threat overview: Evolving phishing threats

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 advanced hunting queries to find related activity in their networks:

Conhost.exe invokes curl

The following query will detect the use of conhost.exe to launch curl to download a decoy PDF from an actor-controlled server, which Star Blizzard used in July 2026. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "conhost.exe"
| where ProcessCommandLine has "curl"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, DeviceId, ProcessId, ProcessUniqueId, InitiatingProcessUniqueId

Invoke SSH to launch local command line

The following query will detect the invocation of SSH to initiate a local command prompt, which Star Blizzard used in January 2026 to download and execute a remotely hosted MSI installer. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "ssh.exe"
| where ProcessCommandLine has "PermitLocalCommand=yes"
| where ProcessCommandLine has "LocalCommand=cmd.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, ProcessId, InitiatingProcessId, ReportId

Persistence through scheduled tasks

The following query will detect Star Blizzard’s uniquely named scheduled tasks that attempt to masquerade as legitimately-named tasks, used for persistence by Star Blizzard in April 2026.

union isfuzzy=true
(
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields
, RegistryKey = tostring(dynamic(null)), RegistryValueName = tostring(dynamic(null))
, SourceTable = "DeviceProcessEvents"
, ProcessId, AccountName, AccountDomain, AccountSid
)
,
(
DeviceEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields, RegistryKey, RegistryValueName
, SourceTable = "DeviceEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)
,
(
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueData has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or InitiatingProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType
, ProcessCommandLine = InitiatingProcessCommandLine, AdditionalFields = ""
, RegistryKey, RegistryValueName
, SourceTable = "DeviceRegistryEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)

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.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
    by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and file hash indicators of compromise using ASIM

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
    or DstDomain has_any (ioc_domains)
    or Url has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
    by SrcIpAddr, DstIpAddr, DstDomain, Url, Dvc, EventProduct, EventVendor

Indicators of compromise

References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-341a
• https://www.zscaler.com/blogs/security-research/coldriver-updates-arsenal-baitswitch-and-simplefix
• https://dslua.org/publications/spearphishing-via-fake-urc-2026-invitations-targets-ukrainian-csos/
• https://cloud.google.com/blog/topics/threat-intelligence/new-malware-russia-coldriver
• https://x.com/threatinsight/status/2037560142880006266

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 Star Blizzard refines phishing and malware delivery with the RedFlick technique appeared first on Microsoft Security Blog.

Midnight Blizzard has been stealing Microsoft account credentials via compromised Wi-Fi networks at hospitality organizations.

The post Russian State APT Linked to Recent Public Wi-Fi Gateway Hacking appeared first on SecurityWeek.

Open-source framework ROADtools is being misused by threat actors for cloud intrusions. Learn how to identify its malicious use.

The post Paved With Intent: ROADtools and Nation-State Tactics in the Cloud appeared first on Unit 42.

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

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

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

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

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.

Hackers linked to Russia’s military intelligence units are using known flaws in older Internet routers to mass harvest authentication tokens from Microsoft Office users, security experts warned today. The spying campaign allowed state-backed Russian hackers to quietly siphon authentication tokens from users on more than 18,000 networks without deploying any malicious software or code.

Microsoft said in a blog post today it identified more than 200 organizations and 5,000 consumer devices that were caught up in a stealthy but remarkably simple spying network built by a Russia-backed threat actor known as “Forest Blizzard.”

How targeted DNS requests were redirected at the router. Image: Black Lotus Labs.

Also known as APT28 and Fancy Bear, Forest Blizzard is attributed to the military intelligence units within Russia’s General Staff Main Intelligence Directorate (GRU). APT 28 famously compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.

Researchers at Black Lotus Labs, a security division of the Internet backbone provider Lumen, found that at the peak of its activity in December 2025, Forest Blizzard’s surveillance dragnet ensnared more than 18,000 Internet routers that were mostly unsupported, end-of-life routers, or else far behind on security updates. A new report from Lumen says the hackers primarily targeted government agencies—including ministries of foreign affairs, law enforcement, and third-party email providers.

Black Lotus Security Engineer Ryan English said the GRU hackers did not need to install malware on the targeted routers, which were mainly older Mikrotik and TP-Link devices marketed to the Small Office/Home Office (SOHO) market. Instead, they used known vulnerabilities to modify the Domain Name System (DNS) settings of the routers to include DNS servers controlled by the hackers.

As the U.K.’s National Cyber Security Centre (NCSC) notes in a new advisory detailing how Russian cyber actors have been compromising routers, DNS is what allows individuals to reach websites by typing familiar addresses, instead of associated IP addresses. In a DNS hijacking attack, bad actors interfere with this process to covertly send users to malicious websites designed to steal login details or other sensitive information.

English said the routers attacked by Forest Blizzard were reconfigured to use DNS servers that pointed to a handful of virtual private servers controlled by the attackers. Importantly, the attackers could then propagate their malicious DNS settings to all users on the local network, and from that point forward intercept any OAuth authentication tokens transmitted by those users.

DNS hijacking through router compromise. Image: Microsoft.

Because those tokens are typically transmitted only after the user has successfully logged in and gone through multi-factor authentication, the attackers could gain direct access to victim accounts without ever having to phish each user’s credentials and/or one-time codes.

“Everyone is looking for some sophisticated malware to drop something on your mobile devices or something,” English said. “These guys didn’t use malware. They did this in an old-school, graybeard way that isn’t really sexy but it gets the job done.”

Microsoft refers to the Forest Blizzard activity as using DNS hijacking “to support post-compromise adversary-in-the-middle (AiTM) attacks on Transport Layer Security (TLS) connections against Microsoft Outlook on the web domains.” The software giant said while targeting SOHO devices isn’t a new tactic, this is the first time Microsoft has seen Forest Blizzard using “DNS hijacking at scale to support AiTM of TLS connections after exploiting edge devices.”

Black Lotus Labs engineer Danny Adamitis said it will be interesting to see how Forest Blizzard reacts to today’s flurry of attention to their espionage operation, noting that the group immediately switched up its tactics in response to a similar NCSC report (PDF) in August 2025. At the time, Forest Blizzard was using malware to control a far more targeted and smaller group of compromised routers. But Adamitis said the day after the NCSC report, the group quickly ditched the malware approach in favor of mass-altering the DNS settings on thousands of vulnerable routers.

“Before the last NCSC report came out they used this capability in very limited instances,” Adamitis told KrebsOnSecurity. “After the report was released they implemented the capability in a more systemic fashion and used it to target everything that was vulnerable.”

TP-Link was among the router makers facing a complete ban in the United States. But on March 23, the U.S. Federal Communications Commission (FCC) took a much broader approach, announcing it would no longer certify consumer-grade Internet routers that are produced outside of the United States.

The FCC warned that foreign-made routers had become an untenable national security threat, and that poorly-secured routers present “a severe cybersecurity risk that could be leveraged to immediately and severely disrupt U.S. critical infrastructure and directly harm U.S. persons.”

Experts have countered that few new consumer-grade routers would be available for purchase under this new FCC policy (besides maybe Musk’s Starlink satellite Internet routers, which are produced in Texas). The FCC says router makers can apply for a special “conditional approval” from the Department of War or Department of Homeland Security, and that the new policy does not affect any previously-purchased consumer-grade routers.