Case Studies

Working the Queue: APT-Q-27 Malware Targets Web3 Customer Support

Mar 25, 2026 | Updated Mar 25, 2026 | 24 min read

1inch and zeroShadow uncovers an active APT-Q-27 campaign targeting web3 customer support teams via live chat. Full malware analysis, IOCs, and detection rules included.

Someone is knocking on your customer support queue right now. They look like a frustrated user, confused, polite, asking for help with a transaction. They send a link. It looks like a screenshot.

This is not a hypothetical.

Over the last few weeks our partners at 1inch started seeing unusual activity in their support queue. Multiple help requests, different accounts, rotating IPs, all following the same pattern: a shortlink, presented as an image. They recognised it, investigated it, and rather than quietly moving on, shared what they found. No breach, no incident. Just a team paying attention and doing the right thing.

What they handed zeroShadow was a sophisticated, multi-stage malware campaign directed specifically at customer support staff. The attackers weren't looking for an open port or a vulnerable dependency. They were looking for a person having a normal day at work. We tracked the tooling, mapped the infrastructure, and traced the campaign to activity we suspect is linked to APT-Q-27, a financially motivated threat group with a documented history of targeting the gambling and cryptocurrency sectors globally.

The full technical picture is below. If you run a web3 company with any kind of customer facing support function, it is worth your time.

Who is APT-Q-27?

APT-Q-27, also tracked as GoldenEyeDog, is a financially motivated threat group assessed to originate from China. Active since at least 2022, the group has predominantly targeted the gambling and cryptocurrency sectors, with activity most extensively documented across Asia but with infrastructure and lure content indicating a broader global reach.

Their tooling is well developed, their infrastructure long-lived, and their operations consistent enough to have attracted attention from multiple threat intelligence organisations. Prior campaigns relied heavily on watering hole sites and trojanised software downloads.

The activity documented in this report represents a shift in approach, with the group moving away from passive lures and directly engaging targets through live customer support channels.

Malware Summary

This report documents the analysis of a multi-stage malware campaign targeting support staff. Victims were delivered a malicious executable disguised as a photograph, which retrieved a second-stage loader from an AWS S3 dead drop.

This loader fetched a six-file implant package from a second S3 dead drop, deploying it under a path impersonating the Windows Update cache. The package was executed via DLL sideloading against a legitimate signed binary, ultimately producing a persistent backdoor in memory through a four-stage decryption chain.

The final implant communicates with 37 hardcoded C2 servers over TCP port 15628. Some of the infrastructure was offline at time of analysis, limiting full dynamic analysis of certain components – however, actionable IoCs and TTPs were captured successfully.

Tricking the Support Agent

The attack starts with a link sent through a customer support chat. The link appears to point to a screenshot, the kind a customer might share when reporting a problem. The URL contains the word Google, which most people would associate with a trusted service. Clicking it downloads a file whose name reads like a photo. On most Windows computers, the part of the filename that would identify it as a program is hidden from view by default. Nothing about this looks unusual to someone having a normal day at work.

The file itself uses an obscure format called .pif, a type of executable that Windows will run like any other program but that most people have never heard of and would not recognise as a threat. Once opened, it displays what looks like a broken webpage error, reinforcing the idea that the link simply did not work. In the background, unseen, it has already begun installing malware. The image below shows exactly how this file looks when it arrives on a Windows desktop.

We have also identified samples from this campaign uploaded to malware sandboxes which confirm that on execution, an image file was opened in Microsoft Paint. This is designed to give the impression that the link was simply broken, while the malware runs silently in the background.

System administrators should ensure file extensions are visible on all workstations. This is a default Windows setting that takes a minute to change. With it enabled, this file would have displayed as photo2025060268jpg.exe, not a jpg.

Execution Flow

The infographic below shows the full end to end execution flow identified during analysis.

Technical Analysis

Loader Variant 1 - Feedback.exe

Feedback.exe is a reasonably sophisticated custom loader designed to deliver further stages of malware to the victim through S3 repositories, failing that, it attempts to install legitimate software. Note that throughout the report, class, function, and methods have been renamed to aid with understanding the malware, the original names were heavily obfuscated; each name is representative of what the function(s) actually does.

Initial Execution

When executed, the first action is an anti-debug check. The binary calls the Win32 API IsDebuggerPresent and additionally performs a stack trace inspection, examining the call stack to determine whether execution is occurring within a debugger context. If either check returns positive, the malware shows a console window and exits without performing any malicious activity. If both checks pass, execution continues into the main operational loop.

Following the anti-debug checks and console hiding, Main_Orchestrator introduces an initial random delay of between one and five seconds before proceeding. This jitter is consistent with beacon interval randomisation used to evade timing-based sandbox detection.

The main worker object is then instantiated and the Run method is called, passing the process command line arguments. On success, a further random delay of between three and ten seconds is applied before the method concludes. On failure, this delay drops to 500 milliseconds, allowing faster retries.

Any exception thrown during execution is silently caught and suppressed, the process waits two seconds and then calls Environment.Exit(0), terminating cleanly without producing a crash dump or error state.

String Obfuscation

All strings within the binary are protected by a custom runtime encryption scheme. The binary's string heap is entirely empty, there are no readable strings are present in the .NET metadata, and static analysis tools that rely on the #US heap to recover string literals will find nothing of value. Every string used during execution is decrypted on demand by a centralised decryption routine, which takes an integer index and returns the plaintext value only at the moment it is needed.

The decryption routine uses a 128-entry key table generated from two hardcoded seeds (0x1f01079f and 0x87c6cd1c), implementing a custom bit-stream codec to recover each string. Decrypted values are cached in a ConcurrentDictionary so that each string is only decrypted once per process lifetime, with subsequent calls served from memory via TryGetValue.

The result is that no plaintext strings, including URLs, registry key paths, file paths, or command strings, exist anywhere in the binary on disk.

Beyond the string encryption scheme, certain high-value strings carry an additional layer of encoding. The C2 dead drop URL is stored as a double-Base64 encoded value within the encrypted string table.

After the decryption routine returns, the result is itself a Base64 string which must be decoded a second time to recover the plaintext URL:

• Encrypted index: -129073428
• First layer: YUhSMGNITTZMeTloZDNObmIzVjFMbk16TG1Gd0xYTnZkWFJvWldGemRDMHhMbUZ0WVhwdmJtRjNjeTVqYjIwdmVTNTBlSFE9
• Second Layer: aHR0cHM6Ly9hd3Nnb3V1LnMzLmFwLXNvdXRoZWFzdC0xLmFtYXpvbmF3cy5jb20veS50eHQ=
• Final Decode: https://awsgouu.s3.ap-southeast-1.amazonaws.com/y.txt
  

The binary has additionally been processed by a custom obfuscator.

All class and method names have been stripped of any semantic meaning, and control flow is disrupted throughout with junk instruction chains, sequences of NOT and NEG operations with no effect on program state, and dead branches that are never executed.

The combined effect is that automated analysis produces little usable output, and manual reverse engineering requires significant effort to separate legitimate logic from noise.

Network Communications

Upon successful initialisation, the malware resolves its C2 URL at runtime through the double-Base64 decoding chain described above, then issues an HTTP GET request to the S3 dead drop at https://awsgouu.s3.ap-southeast-1.amazonaws.com/y.txt. This file acts as a payload manifest, a remotely updatable list of URLs from which the second-stage components will be downloaded, allowing the operator to rotate infrastructure without modifying the implant. The captured contents of y.txt are shown below:

• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/crashreport[.]dll
• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/yyext[.]log
• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/vcruntime140[.]dll
• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/updat[.]exe
• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/image[.]jpg
• hxxps[://]awsgouu[.]s3[.]ap-southeast-1[.]amazonaws[.]com/msvcp140[.]dll

All outbound requests carry a static set of HTTP headers designed to blend with legitimate browser traffic. The Referer header is hardcoded to https://update.microsoft.com and the Accept-Language header is set to en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7, impersonating a browser with both English and Chinese language preferences. A rotating User-Agent string further mimics legitimate browser behaviour.

The manifest response is parsed with notable flexibility, the malware accepts newline, comma, semicolon, and pipe-delimited URL lists, supports inline comments prefixed with # or //, and will automatically prefix bare hostnames with https://. URLs within the manifest may themselves be Base64 encoded, adding a further layer of indirection to the payload delivery chain.

If the S3 endpoint is unreachable or returns an empty response, the malware falls back to a hardcoded list of legitimate Microsoft VC++ redistributable URLs hosted on Microsoft's own CDN. From a network monitoring perspective this presents as entirely benign, a standard installer fetching a legitimate Microsoft package, while the actual payload delivery fails silently with no indication that a second-stage download was attempted.

The captured domains are below:

• https://update.microsoft.com
• https://aka.ms/vs/17/release/vc_redist.x64.exe
• https://download.microsoft.com/download/9/3/F/93FCF1E7-E6A4-478B-96E7-D4B285925B00/vc_redist.x64.exe\

Staging And Payload Delivery

Prior to any network activity, the malware creates a staging directory under the current user's AppData folder at %LOCALAPPDATA%\Microsoft\WindowsUpdate\Cache\WU_{date}_{guid}@27\, where the date component reflects the current date and the GUID component is an 8-character random identifier generated at runtime.

The directory is created with Hidden and NotContentIndexed attributes, suppressing it from Explorer views and Windows Search. The path deliberately impersonates the Windows Update cache directory, a location that generates legitimate traffic and is commonly excluded from security monitoring.The structure is fairly consistent across executions:

WU _ YYYYMMDD _ Random 8 int string @27

The campaign tag @27 is hardcoded into the directory name format string and is present in every installation regardless of target or date. This provides a valid hunting signature; as no legitimate Windows Update cache directory will contain this suffix.

Once the staging directory exists, the malware downloads the payload manifest from the S3 dead drop and begins fetching the listed components concurrently, with up to ten simultaneous downloads gated by a semaphore.

Downloads are staggered with delays between each to avoid generating a burst of simultaneous connections.

The downloaded components, updat.exe, vcruntime140.dll, msvcp140.dll, crashreport.dll, yyext.log, and image.jpg are written directly into the staging directory. Delivery is sequenced deliberately: DLL components are written and any VC++ redistributable installation completes before updat.exe is launched, ensuring its dependencies are in place before execution begins. image.jpg is what’s shown to the victim in Microsoft Paint displaying the mock 503 error.

Due to the S3 bucket being down at time of writing we couldn’t fully replicate this, although some of the samples were available elsewhere and will be covered later in this report.

Persistence And Execution

Once the payload components are in place, the malware writes a value to HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run pointing to updat.exe in the staging directory. The value name is SystemUpdats, a deliberate misspelling of the legitimate SystemUpdate that is nonetheless convincing at a glance in a registry listing. As with the staging directory path, this provides a high-fidelity detection opportunity: no legitimate software uses this value name.

The malware checks whether the Run key value already exists before writing it, making the persistence installation idempotent, repeated executions will not generate additional registry writes or overwrite an existing entry. A corresponding /uninstall command is implemented to delete the value on demand, suggesting the malware is designed for controlled deployment and clean removal by the operator.

updat.exe is launched via ProcessStartInfo with UseShellExecute set to true and the working directory set to the staging directory rather than a system path. This is the mechanism by which DLL side-loading is achieved, when updat.exe initialises, Windows resolves vcruntime140.dll and msvcp140.dll from the working directory first, loading the malicious copies dropped alongside it rather than the legitimate system versions. The malicious vcruntime140.dll subsequently loads crashreport.dll, which decrypts yyext.log into memory and executes the final implant.

Launching via shell execute rather than direct process creation also breaks the parent-child process relationship that EDR tooling uses to attribute child processes to their spawning application.

The malware waits three seconds after launch and considers execution successful if updat.exe is still running or exited with code zero.

Arguments Table

During dynamic analysis, we also identified various arguments being decrypted at runtime, shown below with the corresponding behaviours.

Loader Variant 2 - photo2025060268jpg.exe

Background information provided by the client infers that the initial access vector for this campaign is a .NET 4.8 downloader compiled on 2nd June 2025. The filename photo2025060268jpg.exe is constructed to resemble an image file, exploiting the tendency of users to associate the jpg substring with benign picture files. The binary carries a valid Sectigo Extended Validation code signing certificate issued to Meizhou Fisherman Network Technology Co., Ltd., a Chinese entity, lending it a superficial appearance of legitimacy that would pass casual inspection and some automated security controls.

The binary shares the same custom obfuscation framework as Feedback.exe, along with basic feature parity, making it more like a variant of Feedback.exe rather than a supplementation. The string protection scheme is identical in implementation, a centralised decryption routine backed by a ConcurrentDictionary cache, a 128-entry key table generated via the same linear congruential generator (multiplier 0x343FD, addend 0x269EC3), and the same stack trace anti-tamper mechanism that detects debugger or reflective invocation contexts. All meaningful strings are absent from the binary on disk, they are decrypted at runtime. High-value strings carry an additional layer of double Base64 encoding, matching the same scheme documented in Feedback.exe where the C2 dead drop URL requires two successive Base64 decode passes to recover. The binary's error handling strings are in Russian ("Ошибка"/”Error”), consistent with a Russian-speaking developer or target environment.

Upon execution the binary resolves its C2 dead drop URL through the double Base64 chain, producing the plaintext manifest address https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/A.txt.

This again follows the same pattern as Feedback.exe's use of y.txt on a separate S3 bucket in the ap-southeast-1 region, both are single-letter manifest filenames hosted on AWS S3, suggesting a consistent infrastructure naming convention across the campaign.

Below is the contents of A.txt, many of the files shown match what y.txt was showing:

• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/LogManager.dll
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/commonbase.dll
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerMainModule.dll
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.edskv
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.txt
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/image.jpg
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.exe
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/msvcp140.dll
• https://myvideomanagerentry.s3.ap-northeast-1.amazonaws.com/vcruntime140.dll

Full dynamic analysis of the post-network execution path was not possible at time of writing due to the S3 bucket being offline, preventing recovery of the staging directory path format, file extension handling logic, and HTTP request headers. Furthermore, using simulated networks failed due to errors around the malware checking for a valid SSL/TLS certificate

The rest of this report will cover what malware was identified in y.txt rather than A.txt because it’s what could be recovered at time of writing, but many of the samples appear to overlap.

Legitimate Binary - Updat.exe

updat.exe is not malicious in itself. It is a legitimate component of the YY platform, a Chinese social and live streaming application developed by Guangzhou Duowan Technology, specifically the yyexternal.exe loader, which is responsible for initialising YY's external plugin system. The binary is legitimately signed by Guangzhou Jinhong Network Media Co, Ltd. via a DigiCert/GlobalSign code signing chain, and the PDB path embedded in the binary confirms it was built directly from Duowan's own build infrastructure at E:\DUOWAN_BUILD\yypublish_build\.

The attacker's use of this binary is entirely passive. Because updat.exe explicitly imports MSVCP140.dll and VCRUNTIME140.dll as dependencies, Windows will search the application's working directory for these DLLs before falling back to System32. By dropping malicious copies of both DLLs into the same staging directory and launching updat.exe with that directory as its working directory, the attacker guarantees their DLLs are loaded in place of the legitimate Visual C++ runtime components. The legitimate YY binary executes normally, it simply loads the wrong DLLs.

This technique serves two purposes. First, the process running on the victim machine is a validly signed, legitimate executable, which will pass signature verification checks and is unlikely to attract attention in a process listing. Second, because the binary is not modified in any way, its hash will match the legitimate YY binary if submitted to threat intelligence platforms, potentially misleading automated analysis into classifying the execution chain as benign.

DLL - crashreport.dll

crashreport.dll is the malicious component loaded via the side-load chain. It is unsigned, compiled on 12th March 2026, two days before the campaign was observed, and exports a single function: InitBugReport. This function is called automatically when the DLL loads and contains the entire malicious payload delivery mechanism.

Reverse engineering InitBugReport revealed a straightforward execution chain. The function first locates yyext.log in the same directory by building the path using GetModuleFileNameW and strrchr. It then reads the file into a VirtualAlloc'd buffer, decrypts it in place, makes the buffer executable via VirtualProtect, and calls it directly as a function pointer.

The decryption routine is a three-operation byte cipher applied to every byte of yyext.log:

• ADD 0x52
• ADD 0x25
• XOR 0x62

All three operations are performed on unsigned bytes with truncation, making the effective transformation ((byte + 0x77) & 0xFF) ^ 0x62. The key constants are hardcoded in the function at addresses 0x100021c4 through 0x100021cc. This was confirmed by static analysis and verified dynamically, a breakpoint on the call dword ptr [ebp-4] instruction at 0x704D226D in x32dbg allowed the decrypted buffer to be inspected at runtime and dumped from memory at address 0x01190000.

Shellcode - yyext.log

The decrypted payload is raw x86 shellcode, not a PE, it begins with E9 46 04 00 00 (a JMP to offset 0x44b) and has no MZ header. This avoids memory scanning tools that look for injected PE files.

The shellcode employs several standard position-independent techniques. It resolves its own base address via a call/pop sequence and uses process environment block (PEB) walking (fs:[0x30]) to locate loaded modules in memory without importing any functions directly. API resolution is performed entirely by hash, the shellcode walks each module's export table and computes a hash of each function name, comparing against hardcoded target hashes. The hash function was identified from the characteristic imul hash, hash, 0x83 instruction pattern and the confirmed hash 0x1ab9b854 matching kernel32.dll.

After resolving its required APIs, the shellcode locates a compressed payload blob embedded at offset 0x6e3 within its own body. This blob is 0x2748f bytes (approximately 160KB) and has entropy consistently above 7.8, consistent with compressed data. The shellcode decompresses this blob using RtlDecompressBuffer with compression type 0x0002 (LZNT1 - Windows native compression), writing the output to a freshly allocated buffer. Decompression was performed statically using the Python lznt1 library, producing 163,840 bytes beginning with 4d5a9000, a valid MZ PE header.

DLL - Final.Stage

Extracting data from a debugger at runtime can often go wrong, so to ensure we had the right program, it was worth pulling the filehash, which matched to a DLL on Virustotal , proving that the final stage program that was extracted is a valid file.

The decompressed PE is itself UPX packed. After unpacking, the final implant is a 32-bit DLL of 340,992 bytes, unsigned, with a compile timestamp of 6 July 2023.

Static analysis of the unpacked implant reveals a backdoor module. The malware maintains a hardcoded list of 37 C2 server IP addresses encrypted with a 16-byte rolling XOR cipher, all communicating over TCP port 15628. Infrastructure analysis suggests a predominantly Asian hosting footprint.

String Encryption

All meaningful strings within the binary are encrypted using a rolling XOR cipher. This prevents static analysis tools from identifying C2 addresses, registry keys, and other indicators through simple string searches.

The algorithm XORs each byte of the ciphertext with a byte from a 16-byte key, cycling through the key using modulo 16 indexing:

The extracted 16 byte XOR key is shown below:

The screenshot below shows the location in the binary where the XOR key is located:

Decrypted strings follow a structured format using the delimiter |#$| separating a tag identifier from the payload value, a working example shown below - a full list of IOCs are provided at the end of the report:

After decryption, the binary reveals 37 hardcoded C2 server addresses, all using TCP port 15628. This non-standard port is not associated with any common legitimate service and should be treated as a high-confidence network IoC.

Execution Flow

The malware follows a clearly defined multi-stage execution flow. The entry point is the DLL export, which triggers the initialisation routine. An orchestration function manages the malware's execution as it builds its C2 list, decrypts and validates its configuration, performs user access control checks, and installs services.

Before it performs any actions, the malware checks if it has launched in the context of an Administrator:

0x20 = SECURITY_BUILTIN_DOMAIN_RID, 0x220 = DOMAIN_ALIAS_RID_ADMINS, this is the standard way to check if the current token is in the local Administrators group.

If it's not in the Administrator context, it’ll relaunch the process in an elevated context.

In addition, the malware attempts to kill the user access control (UAC) processes via the Windows registry:

Specifically, the below paths are set to 0 where they’d normally be values above 0.

• EnableLUA = 0: turns UAC off entirely at the system level
• ConsentPromptBehaviorAdmin = 0: elevate silently, no prompt ever shown
• PromptOnSecureDesktop = 0: removes the secure desktop switch during UAC prompts

Next, the malware determines whether it has already been installed as a service by attempting to open the registry key for the service and query its Start value, a value that only exists if the service has previously been registered with Windows:

If both calls succeed the key exists, the malware is already installed, and this is not the first run. If either call fails the key is absent and this is a first launch. If the service isn’t already installed, the malware constructs a hidden destination path under the user's AppData directory, then creates it with attributes designed to conceal it from casual browsing:

It then locates its own executable on disk and copies itself to the hidden location:

It then writes registry persistence entries to survive reboots, launches the copied executable, and cleans up. On the next run the service key will exist and the malware will take the service execution path instead.

Once registered as a service, the service main function begins by registering itself with the Windows Service Control Manager under the name "Windows Eventn" and setting a control handler to respond to stop and pause commands:

It then performs an OS version check to determine which execution path to take:

On pre-Vista systems it enters a thread-based loop, repeatedly spawning a beacon thread and waiting for it to complete:

On Vista and above it instead permanently disables UAC then launches a copy of itself into the interactive user session via token duplication:

Regardless of OS version, the following watchdog loop then runs indefinitely, checking every 1.5 seconds whether the payload process is still alive and relaunching it if not:

The dual execution path indicates the malware was designed to operate across a wide range of Windows versions including legacy XP deployments. The UAC disablement is scoped to Vista and above because UAC did not exist in earlier versions.

Note On Analysis Limitations

How exactly the IP’s are used and how the threat actor communicates to the final stage DLL is currently unknown, as the y.txt file pulled earlier was missing an executable that isn’t currently on Virustotal, meaning that even though this DLL can run (entirely in memory, no file artefact is left behind), it has no meaningful way to allow infostealing or hands-on-keyboard operations from the threat actor.

Considering the attacker can send commands through Feedback.exe, and the DLL is run through a sideload and unpacked shellcode, there could be a link there.

Furthermore, some of the IP addresses identified from the final stage DLL are over six years old, showing that this infrastructure has been around for a long time, each one hosting malicious executables, DLLs, backdoors, and infostealers – though there are no meaningful ways to tie any of those samples specifically to this campaign, given their age.

Attribution

We assess with moderate confidence that this campaign is linked to APT-Q-27, also tracked as GoldenEyeDog, a financially motivated threat group with a documented history of targeting the crypto and gambling sectors globally. This is not a definitive attribution.

Tooling

The final stage backdoor was identified by multiple vendors as the Farfli family, consistently associated with APT-Q-27 in prior reporting. The execution chain mirrors the architecture documented by CyStack in February 2026 almost point for point: a signed .NET dropper retrieving a payload manifest from an AWS S3 dead drop, DLL sideloading via a legitimate YY platform binary, shellcode decryption from an encrypted log file, and in-memory execution of a UPX-packed PE.

Infrastructure

Of the 37 publicly routable C2 IPs hardcoded in the final stage DLL, several sit on AS152194 (CTG Server Limited, Hong Kong), an ASN independently linked to APT-Q-27 infrastructure by LCSC-IE in June 2025. Three of those IPs geo-resolve to Los Angeles but route through the same ASN, consistent with deliberate geolocation obfuscation. All C2 communication occurs over TCP port 15628, a non-standard port that appears consistently across multiple independent APT-Q-27 investigations.

Tactics

Specific behavioural overlaps with documented APT-Q-27 activity include: a staging directory path containing the hardcoded @27 suffix, the Windows Eventn service name, simultaneous zeroing of three UAC registry keys, and browser data clearing targeting Chinese-language browsers including 360, Sogou and QQ. EV code signing certificate abuse using a Chinese-registered entity also mirrors patterns seen in prior campaigns linked to this group.

Limitations

Both S3 buckets were offline at time of analysis, limiting dynamic analysis of the loader variants. The @27 staging path string, while a strong indicator, cannot be independently verified as a deliberate group self-reference. Russian language error strings in one loader are assessed as a developer artefact in an outsourced component rather than an attribution indicator.

References

CyStack: Analysis of Suspected Malware Linked to APT-Q-27 Targeting Financial Institutions, February 2026.

QiAnXin Threat Intelligence Centre: Tracking the Recent Activities of APT-Q-27, November 2024.

LCSC-IE: APT-Q-27 Silver Fox Operations, Additional Technical Hunt and Infrastructure Correlation, June 2025

Detection And Mitigation

Host Detection

• Alert on simultaneous setting of ConsentPromptBehaviorAdmin, EnableLUA, and PromptOnSecureDesktop to 0 within the same registry transaction or short time window
• Monitor for creation of Windows services with names closely resembling but not matching known Windows service names (fuzzy matching on "Windows Event*")
• Monitor SetFileAttributesA calls setting attribute value 7 (HIDDEN|SYSTEM|READONLY) on newly created directories in user profile paths
• Alert on DuplicateTokenEx followed by SetTokenInformation(TokenSessionId) followed by CreateProcessAsUserA, this sequence is the Session 0 bypass fingerprint
• Monitor for processes with explorer.exe as parent that were not initiated by user interaction

Network Detection

• Block and alert on all outbound connections to TCP port 15628
• Add all 37 C2 IP addresses from NETWORK - C2 IPS to network blocklists and SIEM watchlists, note that some of this infrastructure has been observed in reporting dating back over six years
• Alert on any outbound connection to the 143.92.x.x and 27.124.x.x IP ranges on non-standard ports
• Monitor for beaconing patterns: regular outbound connections at ~1.5 second intervals to the same destination

Memory Detection

• Scan for the XOR key bytes 0A EA 11 39 89 0A EC 31 26 97 10 1A 4C 3E 4B 9A in process memory
• Scan for the delimiter string |#$| in process memory, present in decrypted config buffers
• Enumerate named kernel objects and alert on handles to file mappings with suspicious names
  

Indicators Of Compromise (IOCs)

Samples

Network - Dead Drops

Network - Payload Delivery

Network - C2 Ips

Rules

The below rules were created with limited focus on the IoCs, as these can easily be rotated out of the binaries, instead they focus on the overall behaviours the malware performs.

# SIGMA RULE 1: UAC permanent disablement via registry

# All three UAC keys are set to 0 in the same registry transaction or short window.

Title: Campaign: UAC Permanent Disablement via Registry

id: a1b2c3d4-e5f6-7890-abcd-ef1234567890

Status: stable

Description: Detects simultaneous disablement of all three UAC controls via registry writes, behaviour consistent with the campaign backdoor's privilege escalation routine.

References:

- https://attack.mitre.org/techniques/T1548/002/

Author: Analyst

Date: 2026/03/20

Tags:

- attack.defense_evasion

- attack.privilege_escalation

- attack.t1548.002

Logsource:

category: registry_set

product: windows

Detection:

selection_enablelua:

TargetObject|contains: '\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA'

Details: 'DWORD (0x00000000)'

selection_consent:

TargetObject|contains: '\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin'

Details: 'DWORD (0x00000000)'

selection_securedesktop:

TargetObject|contains: '\Microsoft\Windows\CurrentVersion\Policies\System\PromptOnSecureDesktop'

Details: 'DWORD (0x00000000)'

timeframe: 30s

condition: all of selection_*

Falsepositives:

- None expected — no legitimate software sets all three to zero simultaneously

level: critical

# SIGMA RULE 2: DLL sideload via updat.exe launched from staging directory

# updat.exe is a legitimate YY platform binary. When launched with a working directory set to a non-standard AppData path it is being used for sideloading.

Title: Campaign: updat.exe Launched from AppData Staging Directory

id: e5f6a7b8-c9d0-1234-efab-345678901234

Status: stable

Description: Detects the campaign DLL sideload technique where updat.exe is launched with a working directory under AppData, causing Windows to load malicious vcruntime140.dll and msvcp140.dll from the staging directory instead of System32.

References:

- https://attack.mitre.org/techniques/T1574/002/

Author: Analyst

Date: 2026/03/20

Tags:

- attack.defense_evasion

- attack.t1574.002

Logsource:

category: process_creation

product: windows

Detection:

selection:

Image|endswith: '\updat.exe'

CurrentDirectory|contains:

- '\AppData\Local\Microsoft\WindowsUpdate\Cache\'

condition: selection

Falsepositives:

- Legitimate YY platform installations, however legitimate installs would not use a WindowsUpdate cache path as working directory

level: high

# SIGMA RULE 3: Persistence via SystemUpdats run key

# Feedback.exe writes a Run key value named "SystemUpdats", a deliberate misspelling of "SystemUpdate".

Title: Campaign: Persistence Run Key SystemUpdats

id: a7b8c9d0-e1f2-3456-abcd-567890123456

status: stable

Description: Detects the campaign persistence run key "SystemUpdats", a deliberate misspelling of SystemUpdate written by Feedback.exe to HKCU Run.

references:

- https://attack.mitre.org/techniques/T1547/001/

Author: Analyst

Date: 2026/03/20

Tags:

- attack.persistence

- attack.t1547.001

Logsource:

category: registry_set

product: windows

Detection:

selection:

TargetObject|contains:

- '\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SystemUpdats'

condition: selection

Falsepositives:

- None, this value name does not exist in any legitimate software

Level: critical

# SIGMA RULE 4: Outbound connection to TCP/15628

# All 37 C2 servers communicate on TCP port 15628

Title: Campaign: Outbound TCP/15628 C2 Communication

Id: b8c9d0e1-f2a3-4567-bcde-678901234567

Status: stable

Description: Detects outbound TCP connections on port 15628, the hardcoded C2 port used by all 37 backdoor C2 servers. This port has no known legitimate use.

References:

- https://attack.mitre.org/techniques/T1071/

Author: Analyst

Date: 2026/03/13

Tags:

- attack.command_and_control

- attack.t1071

Logsource:

category: network_connection

product: windows

Detection:

selection:

DestinationPort: 15628

Initiated: 'true'

condition: selection

Falsepositives:

- Extremely unlikely, port 15628 has no known legitimate service association

level: high