Microsoft has documented an active malware campaign that uses counterfeit software download pages to compromise organizations across multiple industries. The sites imitate trusted products, including Microsoft Edge, Kaspersky, Razer and other common utilities. A user receives the expected-looking installer while malicious code establishes persistence, weakens security controls and communicates with attacker infrastructure.
Microsoft observed affected devices primarily in China-based operations of multinational organizations and among Chinese-speaking users. The affected sectors include healthcare, manufacturing, technology, logistics, government, education and gaming. Microsoft links the activity with moderate confidence to the publicly reported Silver Fox ecosystem, but has not attributed it to a nation-state actor.
Why blocking one installer hash is not enough
The campaign's look-alike pages deliver archives whose filenames remain stable while the contents and hashes change between downloads. That server-side regeneration reduces the value of a response based only on a single file hash. Microsoft recommends correlating the download page and delivery host, hunting for the campaign's behavioral patterns and applying application-control and tamper-protection policies.
After execution, Microsoft observed randomized payload locations, recurring scheduled tasks, SYSTEM-level actions, process injection and attempts to add broad Microsoft Defender exclusions. Follow-on components deleted volume shadow copies, interfered with Windows Update and used non-standard ports for command and control. The campaign also attempted SMB access to additional hosts.
In a subset of environments, Microsoft detected interactive hands-on-keyboard activity and contained affected devices and accounts. Full eradication still required responder action. These observations establish a real compromise path, but they do not prove that every organization lost credentials or that every system visiting a counterfeit page was successfully infected.
The account-recovery trap
Once an endpoint has persistent malware and interactive attacker activity, it cannot be trusted to generate, receive or display replacement credentials. Resetting a password in the same browser may expose the new value through keylogging, screen capture, injected processes or an existing session. Reusing the same mailbox for recovery can also preserve an attacker's path back into the account.
The correct scope is evidence-based. Responders should identify which user and service accounts were active, which browsers and password managers were unlocked, which network shares were reachable and which API keys, SSH keys or recovery files were stored locally. Reachability creates a reason to investigate and rotate; it is not proof that every reachable secret was stolen.
A clean recovery sequence
- Isolate the device and affected identity. Stop ordinary use, restrict the account and revoke active sessions without coordinating from the suspected endpoint.
- Preserve telemetry. Retain download history, referrer URLs, endpoint alerts, scheduled tasks, process trees, network events and identity logs.
- Hunt behavior, not filenames alone. Check the patterns and detection guidance in Microsoft's current report because regenerated archives can evade static hash lists.
- Scope lateral movement and hands-on activity. Review SMB access, administrative logons, new accounts, remote services and changes to security tooling.
- Rebuild or reimage before reuse. When SYSTEM execution, process injection or persistent tasks occurred, restore from known-good sources and validate security controls.
- Establish clean recovery authorities. Verify a separate device, identity, mailbox and MFA method before generating replacement values.
- Rotate in dependency order. Replace identity-provider and recovery controls first, then privileged, service, API, SSH and lower-impact credentials.
- Validate the new trust state. Monitor replacement credentials, confirm sessions remain revoked and verify that the old recovery channel cannot regain control.
Deliver replacements without creating another durable copy
Incident teams should record who authorized a replacement and who received it, while keeping the plaintext password, token or recovery code out of email and chat history. Recipient identity should be confirmed through a separately established channel before the value is released.
Secretus can provide a one-time delivery path for a replacement secret once the sender, recipient and receiving device have been verified as clean. It cannot compensate for an infected browser, a malicious extension, an attacker-controlled identity or incomplete endpoint remediation.
Independent context and attribution limits
Atos Threat Research separately documented a 2026 Silver Fox campaign that used a trojanized AnyDesk installer and techniques designed to weaken endpoint visibility. That research provides independent context for the broader fake-installer pattern, but it does not independently confirm Microsoft's exact victim set. The Silver Fox association in Microsoft's report remains a moderate-confidence assessment.
What remains unknown
Microsoft has not named the affected organizations, published a complete victim count or stated which credentials or data were accessed in each environment. Public evidence does not establish a nation-state sponsor. It also does not show that the legitimate vendors whose brands were imitated suffered a compromise of their own software or infrastructure.