Star Blizzard RedFlick and CosmicPulse: A Defensive Phishing Explainer

Start with the evidence boundary

Microsoft attributes the activity to Star Blizzard and describes the actor as a Russian state threat actor. Microsoft’s report also points to a CISA advisory that assesses Star Blizzard as subordinate to the Russian Federal Security Service Centre 18. That is the attribution boundary used here: it is a sourced assessment, not an independent conclusion by this article. The reviewed material does not establish a new actor identity, a universal geographic campaign, or an India-specific operation. [1][2]

The campaign-scope wording requires equal care. Microsoft says RedFlick activity targeted Ukrainian individuals and institutions, international NGOs, think tanks, governments, and financial institutions associated with support for Ukraine, and that it observed the activity affect over 100 organizations primarily in the United States and United Kingdom. “Affected” is Microsoft’s term. It should not be rewritten as 100 confirmed breaches, 100 unique victims, or a rate that can be applied to all organizations. The source also does not prove that every target opened a lure or that every opened lure produced a backdoor. [1]

What Microsoft observed changing in 2026

Microsoft says that since January 2026 it observed Star Blizzard move beyond exclusively targeted spear-phishing toward larger-scale initial-contact campaigns. The report describes campaigns ranging from tens to hundreds of messages, at least 13 distinct large-scale campaigns since January, and the use of accounts on compromised WordPress- and cPanel-hosted websites to send messages. Microsoft says those accounts were used mainly to support the higher-volume operations and assesses with high confidence that the websites had been compromised for that purpose. [1]

The lure themes changed while the social-engineering pattern remained recognizable. Microsoft lists tax-audit and fine notices in January and February, then conference, roundtable, policy, finance, diplomatic, civil-society, hotel water-shutdown, and payment-advice themes through August. In several campaigns, the first contact was designed to elicit a response rather than immediately deliver a file. Microsoft says a follow-up then supplied a password-protected RAR or ZIP archive, with the password shown as an image in the message. A defensive inference is that a plausible conversation and a password image should not be treated as proof of legitimacy. [1]

How the RedFlick delivery chain works

In the Microsoft-described chain, the archive exposes a shortcut file disguised as a PDF or another document. Earlier 2026 observations included a VHDX lure, a hidden directory, a decoy PDF, and an MSI installer obtained through a script-assisted stage. A later July pattern used a password-protected RAR nested inside a ZIP, an LNK file, and a PDF that concealed encoded content used to reach the installer. [1]

Microsoft contrasts RedFlick with earlier ClickFix chains. ClickFix required victims to complete multiple actions, while the RedFlick flow was observed reducing the interaction to a single user action before scheduled tasks and remote stages took over. Microsoft describes LNK-triggered execution, hidden Windows processes, MSI installation, PowerShell or command-shell activity, and a Control Panel applet-style DLL that downloads and installs CosmicPulse. The practical conclusion is to inspect the parent-child process chain and the reason for each downloaded installer, rather than rely only on file extensions or the decoy’s visible content. [1]

Why scheduled tasks deserve priority review

Microsoft reports that an MSI installer observed in April created three scheduled tasks that masqueraded as ordinary network components: “Internet Quality Test Connection,” “Network Configuration Manager,” and “System Health Monitor.” The first could send a UTF-16 and Base64-encoded string containing the network or computer name and username to command-and-control infrastructure, and could invoke a remote DLL. The second supported WebDAV-related activity. The third used control.exe to reach a remote path and execute the next stage. [1]

The next stage was a CosmicPulse downloader presented as a Control Panel applet. Microsoft says the downloader installs a Python-based CosmicPulse backdoor, also publicly known in earlier reporting as NOROBOT or BAITSWITCH. The report says CosmicPulse changed in small ways to evade existing signatures while retaining the same capabilities and purpose described in earlier reporting. For a defender, that means a single malware name or hash is not a complete control. Task creation, unusual use of control.exe, WebDAV paths, remote DLL execution, Python launch context, and endpoint-to-website connections should be correlated. [1]

Recognize the social and identity signals

Microsoft says the campaigns continued to impersonate trusted contacts and sometimes used names of real people or organizations in the local part of an email address rather than the registered domain. CISA’s earlier advisory describes related Star Blizzard tradecraft involving researched contacts, impersonated accounts, fake event invitations, credential theft, and session-cookie abuse. The combined lesson is to validate the sender and the context through a previously established channel, not through a number supplied in the message. [1][2]

Identity protection must cover both passwords and sessions. CISA reported that Star Blizzard used credential-harvesting infrastructure and session cookies in earlier spear-phishing activity; Microsoft recommends phishing-resistant authentication, Conditional Access, and continuous evaluation in the 2026 defensive guidance. These controls reduce the value of a phished password, but no control makes a suspicious message harmless by itself. If an account may have been exposed, review active sessions, forwarding rules, registered devices, authentication methods, and application access according to the organization’s approved response process. [1][2]

Build a layered prevention stack

Microsoft’s recommendations span email, identity, browser, endpoint, and network controls. The report calls for phishing-resistant authentication, Conditional Access, advanced anti-phishing inspection, Safe Links, Safe Attachments, SmartScreen-capable browsers, network protection, real-time antivirus protection, cloud-delivered protection, and automatic sample submission. It also recommends EDR in block mode and automated investigation and remediation where the operating model permits it. These are controls to configure and validate, not guarantees of prevention. [1]

The controls should be tested as a chain. Email filtering should be checked against archive and attachment handling; link inspection should be checked at click time; identity policies should distinguish managed devices, risky sign-ins, and high-impact accounts; endpoint policy should record or block unusual scripts, installers, and signed system utilities; and network policy should limit outbound connections that are not needed for the business. Microsoft also recommends Zero-hour auto purge so newly acquired intelligence can remove messages that reached mailboxes. [1]

A useful design principle is to make one missed signal less consequential. If a lure reaches a mailbox, a second control should challenge the sign-in. If a user opens a decoy, endpoint telemetry should expose the process tree. If a scheduled task is created, task-change auditing should make it visible. If a token is stolen, session and device policy should shorten its useful life or trigger review. This layered interpretation is an inference from Microsoft’s control set, not a claim that the report observed every control failing or succeeding. [1]

Detect the chain without overfitting to one indicator

Microsoft publishes Defender detections for Trojan:Script/RedFlick and Backdoor:Python/CosmicPulse, along with indicators and Defender XDR hunting queries. The report says the published queries have a seven-day lookback and that older activity may require a wider retained-log window. A useful hunt therefore starts with the detections but extends to process ancestry, scheduled-task creation, LNK and MSI execution, suspicious PowerShell or command-shell children, WebDAV-related paths, control.exe launching a remote applet, and unusual outbound connections. A match is an investigation lead, not automatic proof of successful compromise. [1]

The task names Microsoft recorded are valuable pivots, but exact-name searches can miss renamed tasks and create false positives. Compare task XML or command details with the system baseline, creator account, creation time, signer, file location, and expected software owner. Join endpoint evidence with mail telemetry and identity logs: a suspicious archive delivery, a new task, an unusual sign-in, and mailbox-rule change within one time window provide more context than any single artifact. Preserve the original event times and the log source used for each conclusion. [1][2]

Microsoft’s indicators include infrastructure and file-level clues that can change. Treat published IPs, domains, hashes, and detection names as time-bounded intelligence, enrich them through the organization’s approved process, and avoid turning an indicator list into a public blocklist or a statement about a person. CISA’s advisory also warns, in effect, that indicator lists are not exhaustive. Detection coverage should be maintained through behavior and identity telemetry as well as static matches. [1][2]

Respond proportionately when a signal appears

A suspicious invitation without execution evidence is a message-handling event. A created task with a matching installer or downloader is a higher-confidence endpoint lead. A confirmed detection, abnormal outbound connection, or identity anomaly may require coordinated endpoint and account containment. [1]

For a potentially affected account, identity responders should review sessions, tokens, authentication methods, registered devices, forwarding rules, and connected applications, then apply the organization’s revocation and credential-reset process from a trusted administrative path. For a potentially affected endpoint, responders should isolate or restrict it according to safety and business requirements, capture relevant telemetry, and determine whether rebuild or other authorized remediation is needed. Do not infer that password reset alone closes a session-cookie or persistence path. [1][2]

Communication should separate facts from hypotheses. Record the message timestamp, recipient, sender domain, attachment type, user action, endpoint alert, task details, network evidence, identity activity, and response action. State what is observed, what is inferred from Microsoft’s documented behavior, and what remains unknown. Microsoft says it directly notifies customers it sees as targeted or compromised; that notification practice does not mean a reader has been notified, targeted, or compromised. [1]

India context without an unsupported targeting claim

The reviewed Microsoft report identifies Ukrainian interests and primarily United States and United Kingdom organizations in its affected-organization statement. It does not establish India targeting, an Indian victim total, or a specific Indian organization’s compromise. Indian organizations can still use the technical lessons where they operate Windows endpoints, hosted mail, identity services, or policy and civil-society functions, but applicability comes from their assets and exposure, not from a claim that Microsoft observed an India campaign. [1]

For teams in India, the appropriate operational question is whether the organization can identify who owns mail filtering, identity policy, endpoint response, scheduled-task auditing, and incident evidence retention. Sector, contractual, privacy, and reporting duties should be checked through the responsible security, legal, and compliance functions. [1][2]

Known unknowns remain material: the complete target set, the number of successful executions, the number of compromised organizations, the data accessed, the duration of any persistence, and any downstream impact. Microsoft’s “over 100 organizations” statement cannot answer those questions. A disciplined assessment should update scope only when local telemetry, provider evidence, or a directly communicated notification supports the change. [1][3]