UNC7017 Used Brief Update Tampering to Deliver Malware

Software supply-chain attacks do not always require a poisoned build pipeline or a backdoor embedded in an official release. The investigation by Google Threat Intelligence and Mandiant describes a different model: an adversary briefly altered remote update configuration files, delivered malware to systems checking for updates during those windows, and then restored the legitimate content.

The activity targeted AOMEI Technology’s update infrastructure between April and July 2026. Mandiant attributes the campaign to the threat cluster it tracks as UNC7017. The research describes a multi-stage chain involving the CROSSROAD downloader, the SHINYROAD backdoor, legitimate administration software used in the execution flow, and later Adaptix C2 activity disguised as Nitro PDF tooling.

The central defensive lesson is that a clean vendor endpoint observed after an incident does not prove that the endpoint was never exposed. In this case, the delivery infrastructure could appear normal minutes after an affected client had already downloaded and executed a malicious payload.

How the short-lived compromise worked

AOMEI Backupper and AnyViewer use background components, including Backupper.exe and ABNotify.exe, to retrieve update and notification instructions. Under normal conditions, the update process reads a configuration file named down_html.ini. That file specifies an update version, an expected MD5 value, and the location of upgrade-now.zip. A separate file, Notifycfg.ini, controls notification content and can direct the local notification process to execute programs in the application directory.

According to Mandiant and Google Threat Intelligence, UNC7017 modified both files during tightly bounded exposure periods. The observed windows lasted between five and ten minutes:

• May 28: 05:40–05:50 UTC
• July 16: 08:33–08:39 UTC
• July 20: 10:35–10:40 UTC

During an active window, down_html.ini redirected the client from AOMEI’s normal update location to attacker-controlled or third-party storage. The actor also changed the version fields and checksum value so that the client accepted the substituted archive. The notification configuration was altered to force execution of the unpacked file, identified as upgrade-now.exe.

When the window ended, the configuration files were restored. A client that checked before or after the interval received authentic content, while a client polling during the interval could receive the malicious archive. This timing undermined point-in-time scanning, live URL checks, and retrospective review of the vendor’s files.

Payload progression: CROSSROAD to SHINYROAD

The first major payload was CROSSROAD, a 64-bit Windows downloader written in C and tracked by Mandiant as a distinct malware family. It was delivered inside upgrade-now.zip. The loader performed environment checks, staged a secondary payload, established persistence, and attempted to remove evidence of its own presence.

CROSSROAD checked whether its path contained the string “AOMEI” and acquired the host’s public network location through external DNS and HTTP reflection services. In some execution paths, it stopped its primary payload activity when the derived country code was China. It also used a named mutex to prevent multiple concurrent instances.

The loader then retrieved a secondary archive, observed under names including component.zip and en.zip, into a temporary location before extracting files under the user’s local application data directory. It created a scheduled task named RadminComponentRuntime, configured to run a Radmin-related executable with the --runtimechk argument every three hours. CROSSROAD subsequently used a child process and an alternate data stream operation to delete its original executable.

The staged package contained a Radmin 3.x administration bundle and the SHINYROAD framework. Mandiant reported that SHINYROAD did not provide its own persistence; it relied on the scheduled task created by CROSSROAD.

Execution began when a legitimate, signed Radmin executable loaded an unsigned library named BlkScrDl.dll through DLL search-order hijacking. The library located config.zip, placed its contents in shared memory, and registered another component as an in-process COM server. That component, RuntimeComponent.dll, extracted encrypted data from memory and decrypted metadata.dat using ChaCha20 with an HMAC-SHA256-derived key and initialization vector.

The decrypted material consisted of compiled Python bytecode executed by an embedded PocketPy interpreter. Earlier SHINYROAD variants communicated over raw TCP, while the research describes later C2 connectivity over TCP port 443. The framework generated a host-specific identifier using the hostname and username, supported encrypted communications, and could generate randomized traffic intended to complicate network-based identification. The report also describes interactive remote shell capability and in-memory extension loading.

Infrastructure changes and credential coercion

UNC7017 changed delivery infrastructure during the campaign. Early CROSSROAD samples used Alibaba Cloud Object Storage. Later activity moved to vendor-themed domains such as storage-data[.]com, promotion[.]storage-data[.]com, and aomei[.]storage-data[.]com. During the July 20 window, the initial archive was hosted in a public Google Cloud Storage bucket, while subsequent payload retrieval and C2 activity continued to use the actor’s other infrastructure.

Mandiant assessed that this blend of dedicated domains and reputable cloud services complicated simple domain-based blocking. The use of public storage also created a path around controls focused primarily on newly registered domains.

The July 20 configuration introduced a separate risk. UNC7017 replaced a legitimate promotional banner with an invisible one-by-one-pixel window that referenced a remote file through a WebDAV UNC path. The observed resource used the IP address 8[.]210[.]84[.]56. Google Threat Intelligence and Mandiant assessed that this could coerce an endpoint into sending NetNTLMv2 authentication material without visible user interaction.

This means that blocking execution of the downloaded binary would not necessarily eliminate the campaign’s risk. The notification mechanism itself could be abused for credential coercion.

Later-stage activity and masquerading

In mid-July, telemetry identified Adaptix C2 activity after SHINYROAD deployment. The payloads were presented as Nitro PDF promotional or scanning utilities, including NitroPromotion.exe. A scheduled task named NitroRuntime launched the executable through hidden PowerShell, and a library named Eztwain4.dll was sideloaded from a Nitro-themed directory.

The reported Adaptix beacon destination was 8[.]210[.]84[.]56:6800. Earlier SHINYROAD communications were associated with 8[.]218[.]65[.]184, including TCP port 41397. These indicators should be treated as campaign-specific findings from the report, not as a complete description of all infrastructure used by UNC7017.

Mandiant also reported timestomping in an early CROSSROAD sample, with fabricated 2024 compilation dates. That behavior, self-deletion, use of alternate data streams, signed Radmin binaries, and Nitro-themed filenames all complicate conventional file-based investigations.

Victimology and attribution

Telemetry identified affected organizations in IT services, telecommunications, higher education, and related sectors across Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye, and the United States. The researchers cautioned that this list is not necessarily exhaustive. Because any system polling the update service during a tampering window could have received the malicious instructions, the campaign’s victimology was considered opportunistic and potentially broader than the directly identified organizations.

Google Threat Intelligence and Mandiant attribute the activity to UNC7017. That is the research organization’s attribution assessment. The supplied research does not provide a CVE associated with this incident, and the attack did not depend on exploiting a software vulnerability in the AOMEI client. Instead, it abused legitimate update and notification workflows after server-side configuration tampering.

What organizations should do now

Organizations using affected AOMEI products should investigate endpoints rather than relying on the vendor’s later restoration of legitimate server files. Mandiant reported that AOMEI took corrective action after notification, but server-side remediation does not remove payloads already delivered to clients.

• Hunt for persistence. Review scheduled tasks named RadminComponentRuntime and NitroRuntime. Investigate executions of Radmin components with --runtimechk and hidden PowerShell launches involving Nitro-themed files.
• Inspect application directories. Examine AOMEI Tmphtml and html directories for unexpected archives or executables. Review %LOCALAPPDATA%\Radmin for BlkScrDl.dll, RuntimeComponent.dll, config.zip, and metadata.dat. Also inspect Nitro-themed directories for Eztwain4.dll and NitroPromotion.exe.
• Preserve historical evidence. Do not validate an alert only by visiting the current vendor URL. Preserve cached configuration files, endpoint telemetry, proxy records, and firewall logs covering the exact time of the alert. The research specifically identifies AOMEI temporary and HTML directories as important evidence locations.
• Use the supplied indicators carefully. File hashes, mutexes, scheduled-task names, shared-memory identifiers, domains, IP addresses, and YARA rules in the Mandiant report can support retrospective searches. Defenders should validate matches against legitimate signed Radmin and Nitro files to avoid treating abused support binaries as inherently malicious.
• Restrict outbound credential exposure. Block external SMB and WebDAV where operationally feasible, especially outbound TCP 445, and investigate requests to external UNC resources. This reduces exposure to forced-authentication techniques.
• Monitor updater behavior. Alert when trusted background update processes spawn unsigned children, write executables into application web or temporary directories, contact unexpected destinations, or trigger scheduled-task creation.

Software vendors should cryptographically sign both update packages and remote configuration files. A cleartext checksum supplied by an unsigned configuration file is not sufficient to establish authenticity. Clients should pin update destinations to approved vendor infrastructure, reject arbitrary cloud-storage redirects, and restrict embedded handlers to secure web protocols rather than permitting file:// or WebDAV paths. Update functions should also be separated from promotional notification systems so that advertising content cannot initiate local execution.

Conclusion

The UNC7017 campaign demonstrates how a short-lived alteration to update metadata can have a long-lived effect on endpoints. The compromise window may disappear from the vendor’s servers, while scheduled tasks, sideloaded libraries, encrypted payloads, and C2 components remain active on systems that polled at the wrong moment.

For defenders, the appropriate response is retrospective and behavioral: investigate the endpoint, correlate telemetry to the precise polling period, and treat trusted update software as a process to monitor rather than an automatic exception. For vendors, signed configuration, strict destination controls, origin integrity monitoring, and separation of update and promotional logic are essential safeguards.

Sources

Technical findings and indicators are from Google Threat Intelligence and Mandiant’s investigation of ephemeral supply-chain tampering.