Unveiling YGS-Packer: A Novel Android Spyware Family Leveraging iApp Frameworks and Native ClassLoader Hijacking

Abstract

This report details the discovery of the YGS-2026 malware family, a sophisticated Android information stealer first identified in early 2026. The malware employs a unique multi-layer obfuscation strategy, including Unreal Engine 4 asset inflation to bypass scanners and a custom native-layer decryption engine ("slky" algorithm). Notably, it weaponizes the iApp rapid development framework to execute dynamic Lua-based payloads, enabling real-time surveillance capabilities such as silent camera capture, keylogging via Accessibility Services, and direct MySQL data exfiltration. The findings reveal a bridge between amateur development tools and professional-grade anti-forensic techniques. This report mainly contains Forensic Intelligence Report: [YGS-2026-01] and Forensic Intelligence Report: [YGS-2026-02].

Forensic Intelligence Report: [YGS-2026-01]

Subject: Analysis of Obfuscated "PUBG Tool" Spyware

Threat Category: Trojanized Utility / Information Stealer

Target Platform: Android (ARMv8/ARMv7/x86)

Security Level: Confidential / Forensic Investigation

Author: Apich Organization Security Team

DOI: 10.5281/zenodo.18320725

1. Executive Summary

A detailed forensic investigation has been conducted on a malicious Android application masquerading as a game optimization utility ("PUBG Tool"). The application utilizes a multi-stage, native-backed execution chain to deploy a covert spying payload. The malware leverages social engineering (UE4 decoy assets), native-layer decryption, and runtime ClassLoader hijacking to bypass traditional static analysis and Play Protect heuristics.

2. Threat Infrastructure & Social Engineering

The attacker employs several layers of deception to maintain a low profile on the victim's device:

2.1. The "Fake Front" (UE4 Decoy)

The application package contains significant directory structures associated with Unreal Engine 4 (UE4).

2.2. Command & Control (C2)

3. Technical Analysis of the Infection Chain

3.1. Stage I: The Java Loader (c.b.a.a.g)

The loader acts as the primary coordinator. Its main responsibilities include:

3.2. Stage II: Native Decryption (libygsiyu.so)

Static analysis of the native layer reveals a sophisticated decryption engine written in C++ (Clang/LLVM).

3.3. Stage III: Memory Hijacking & Execution

The malware employs a "Hot-Swap" technique via Method u():

4. Payload Analysis (Internal lib.so)

Based on string extraction from the native engine, the decrypted lib.so is a container for the iApp (iyu) source code, including:

5. Indicators of Compromise (IoCs)

5.1. Network Indicators

5.2. Host-Based Indicators (HBIs)

File/Directory PathClassification
assets/lib.soEncrypted Malicious Payload
lib/arm64-v8a/libygsiyu.soNative Decryption Engine (YGS-Packer)
/data/data/[pkg]/files/_RunDex_/Working directory for decrypted DEX
[ExternalStorage]/.../log.txtMalware Execution Log

6. Technical Deep Dive: Attack & Surveillance Tactics

6.1. Persistence via Accessibility Service Hijacking

The presence of ays_service.myu indicates the use of the Android Accessibility Suite as a primary attack vector.

6.2. The "Mirror" Surveillance Logic (Camera & Audio)

The lib.so payload contains logic to interface with the android.hardware.camera2 API and the MediaRecorder class.

6.3. Dynamic Code Execution (The Lua-Java Bridge)

The use of libluajava.so represents a high-tier threat level.

6.4. Data Exfiltration Protocol

The exfiltration process is designed to look like standard telemetry:

  1. Packaging: Stolen data (SMS, Contacts, Photos) is compressed into a temporary .dat or .tmp file.

  2. Encryption: The data is encrypted using the same slky algorithm found in the native layer to prevent Network Intrusion Detection Systems (NIDS) from seeing the stolen content.

  3. POST Request: The data is sent via an HTTP POST request to bu84.com/config.php with a fake User-Agent string mimicking a common web browser or the UE4 engine's update service.

7. Forensic Summary of Targeted Data

Data CategoryExtraction MethodFrequency
User IdentityIMEI, IMSI, SIM Serial via TelephonyManagerOnce per Boot
CommunicationSMS interception and Call Log scrapingReal-time
EnvironmentalBackground Mic Recording and Front Camera SnapshotsTrigger-based
CredentialsKeylogging via Accessibility ServicesContinuous

8. Concluding Analyst Note

The YGS-packer family is a classic example of "Living off the Land" in Android. By using a legitimate framework (iApp) and legitimate libraries (UE4, LuaJava), the attacker creates a noise-floor that hides the signal of the malware. The transition from Java to Native C++ for the core decryption is the "Gordian Knot" intended to stop 99% of automated analysis tools.

The [YGS-2026-01] threat is a high-risk spyware variant. It is recommended that any device containing the libygsiyu.so or libluajava.so signatures be considered fully compromised.

9. Technical Appendix

  1. Original Filename: 刷 刀 体 质.apk

  2. SHA-256 Hash: f04990c4f191a8890d35a28f7aa4b5db3965ae18053ba9c1bf554a6719112657

  3. MD-5 Hash: 74acf9985cf93b8c7d78c2b0ea679b64

  4. SHA-1 Hash: 9b3311985120b00bb95048496eefbdaff762f5dd

  5. Recieve Method: User Report

  6. Link: https://www.virustotal.com/gui/file/f04990c4f191a8890d35a28f7aa4b5db3965ae18053ba9c1bf554a6719112657/detection

10. Summarize

1. File Signatures & Masquerade

The app uses a dual-masquerade technique to hide its true purpose:

 

2. Payload Inventory (The lib/ folder)

The app utilizes "Library-as-Payload" storage to hide DEX files from standard scanners.

It uses Java Protector or Unpacker to protect the payloads.

FilenameTypeDetected Logic / Responsibility
lengtong.dexJava DEXData Access: Filesystem manipulation (AndroidData.java) and binary patching (HexEdit.java).
lengtong2.dexJava DEXPersistence/Protection: Numbered classes (C0005.java) suggest a custom unpacker or string decrypter.
classes2.dexJava DEXSurveillance: Contains ADRT (Android Remote Debugger Tool) for LogCat monitoring.
Compression.dexJava DEXExfiltration Prep: Uses Zip4j for archiving and potentially encrypting stolen data.

3. Decoy Mechanism ("slky")

4. Behavioral Hypotheses

Based on the modules found, the execution flow is likely:

  1. Boot: Main iApp activity starts.

  2. Unpack: lengtong2.dex is loaded to decrypt configuration.

  3. Monitor: classes2.dex starts a background thread to watch system logs (ADRT).

  4. Steal: lengtong.dex identifies target files in /sdcard/Android/data/.

  5. Exfiltrate: Compression.dex zips findings and transmits them via iApp's built-in network handlers.

C2 Infrastructure Intelligence Report

Report ID: C2-2026-0120-YGS

Author: Apich Organization Security Team

Classification: High-Risk / Active Surveillance Cluster

Primary Target Region: Mainland China / Hong Kong

1. Architectural Overview

The infrastructure utilizes a Tiered Proxy-to-Backend model. This design ensures that if the front-end domain (docq.cn) is flagged, the central database and payload repository (107.151.212.80) remain hidden and reusable under different domain aliases.

TierComponentIdentityTechnical Role
Tier 1The Maskdocq.cnActs as the initial contact point. Routes traffic through Alibaba Cloud (US) to bypass regional domestic monitoring.
Tier 2The Controllerht.bu84.com"Heartbeat" (HT) server. Manages persistent connections from infected devices using IIS 10.0.
Tier 3The Vault107.151.212.80:3306Exposed MySQL database. Stores exfiltrated LogCat data, contacts, and device metadata.

2. Forensic Attribution (WHOIS Analysis)

The registration data reveals a strong link to the Fujian/Wuhan gray-market ecosystem, a known hub for the development of "iApp" modification tools and game injectors.

3. Detected Vulnerabilities. in C2

The attackers have made several critical "Amateur-Hour" errors that can be exploited:

This vulnerability poses a significant risk of sophisticated cyberattacks, which could result in the mass exfiltration and disclosure of Personally Identifiable Information (PII).

Noticeably, the attacker uses phpMyAdmin v5.2.0-rc.1 and MySQL v8.0.39 which both have many known critical security vulnerabilities.

4. Correlation with APK Analysis

The "modular" DEX files we found earlier are designed to feed this specific infrastructure:

5. Defensive Infrastructure: The "China-Only" Gatekeeper

Our attempts to reach the command infrastructure revealed a high degree of operational security (OPSEC).

Appendix

Acknowledgement

Sample Submission

This malware sample was submitted by Xiaoru Zhang (Apich Organization) on January 19, 2026, at 23:12 CST.

Related malware sample YGS-2026-02 was submitted by Xiaoru Zhang (Apich Organization) on January 20, 2026, at 23:12 CST.

Analysis Timeline

Reporting & Coordination

The initial report was submitted to the TSRC on January 20, 2026, at 13:43 CST, with subsequent revisions finalized at 17:29 and 17:59 CST. Due to mailing system errors and latency, multiple copies of the reports were resubmitted again to the TSRC on January 21, 2026, using various methods (including mailing and wechat official accounts of TSRC, e.g.); however, no response has been received yet till the publishing of these reports. Thus, the reports are formally submitted to CNCERT on January 21, 2026, at 21:44 CST.

Conclusion of Internal Operations

With the release of this acknowledgement, the Apich Organization Security Team has officially concluded its primary internal tasks regarding sample YGS-2026-01. However, we remain committed to supporting the ongoing efforts of the TSRC and CNCERT.

Furthermore, our team will continue to actively monitor and track all future variants within the YGS malware family.

Special Thanks

We would like to extend our sincere gratitude to all members and external contributors who provided invaluable assistance throughout this analysis.

Personal Acknowledgement

The authors acknowledge the diligent administrative support recieved from the Physics Olympic Coaching Team of Jinan Zhensheng Middle School. Also, special thanks is given to Zining Li, Xiaoru Zhang and Yinxian Li for their continuous support and understanding of this investigation.

Forensic Intelligence Report: [YGS-2026-02]

Subject: Analysis of Modular iApp-Lua Surveillance Variant ("Huji Assistant")

Threat Category: Modular Dropper / Identity Spyware

Target Platform: Android (ARMv8/ARMv7/x86)

Security Level: High-Priority / Forensic Investigation

Reference Case: Similar in architecture and behavior to DOI: 10.5281/zenodo.18320725

Author: Apich Organization Security Team

DOI: 10.5281/zenodo.18320725

1. Executive Summary

Forensic analysis of sample YGS-2026-02 (labeled: 戸 籍 开 道 助 手 .apk) reveals a highly modularized surveillance tool utilizing the iApp (ygsiyu) framework. This variant represents a strategic shift from the gaming-themed masquerade of YGS-2026-01 toward a government-themed social engineering lure. By mimicking a "Resident Registration Assistant," the threat actor seeks to justify broad permission requests to facilitate the exfiltration of sensitive Personally Identifiable Information (PII).

The file structure of YGS-2026-02 above reveals a sophisticated, multi-engine payload architecture that combines script-based agility with native-level system access. The presence of the BeanShell (bsh) directory is a critical discovery; BeanShell is a Java source interpreter that allows the malware to execute "scripted" Java code dynamically without needing to compile new DEX files, providing a stealthy alternative to the Lua engine. This is complemented by the rc4加解密.dex module, which contains the ADRTLogCatReader Smali classes. This confirms that the malware's primary surveillance mechanism is focused on "Logcat scraping"—capturing system-wide logs to intercept sensitive data like one-time passwords (OTPs), private tokens, and app-to-app communications that are often inadvertently leaked to the Android log buffer.

Furthermore, the inventory of the /lib directory proves a "nested payload" strategy designed to defeat simple static analysis. By bundling secondary JAR files like yecian.jar and CmZ6NzczSVRN.jar alongside specialized native libraries, the threat actor has built a toolkit that is framework-agnostic. The smali_lib structure shows that even the "cryptography" module is actually a container for the example.application4 namespace, a likely intentional use of generic "boilerplate" naming to hide malicious intent within seemingly harmless sample code. This tiered structure—Lua for logic, BeanShell for dynamic Java execution, and ADRT for log surveillance—marks this variant as a highly versatile and dangerous evolution of the YGS malware family.

2. Relationship to YGS-2026-01

The two samples share a common genetic lineage, suggesting they originate from the same development cluster in the Fujian/Wuhan region.

3. Payload Inventory & Component Analysis

The /lib directory of YGS-2026-02 contains several specialized modules not found in the initial variant, indicating an upgrade in cryptographic capabilities.

ComponentFile TypeFunctional ClassificationForensic Significance
rc4加解密.dexDalvik ExecutableCrypto EngineDedicated RC4 module for decrypting secondary payloads and obfuscating C2 traffic.
yecian.jarJava ArchiveExfiltration ManagerOrchestrates the collection and transmission of device metadata and user logs.
CmZ6NzczSVRN.jarJava ArchiveSurveillance PluginLikely handles specific identity-theft hooks related to the "Huji" lure.
sign.jarJava ArchiveIntegrity CheckerFacilitates self-updates and verifies the signature of dynamically loaded modules.

Analysis of the trojanized assets assets/res/gx.mp3 and assets/res/.ant.dat reveals that the malware is not a static payload but an active IDE-Worm. These files contain Yu Code (iApp scripting language) rather than media data, designed to infect the victim developer's local environment and any future projects they create.

Infection & Persistence Mechanism

The malware executes a recursive search across the device's external storage specifically targeting the directory structure of the iApp Development Environment (%iApp/ProjectApp/).

Dynamic C2 Fallback (DGA-Lite)

The .ant.dat component acts as a Resilience Module. It is programmed to scrape a public "Jimdo" blog page (antstudio.jimdofree[.]com) to retrieve new Command & Control (C2) instructions.

Variable (Encoded)Decoded ValueFunctional Purpose
c (btoo)http://docq.cn/files/edk88kePrimary C2 Payload Drop-point
sss.bmcom.zhendongTargeted Package/Namespace
ur (reconstructed)https://antstudio.jimdofree.com/test/virusDead-Drop Resolver for C2 migration

Threat Actor Attribution Indicators

The naming conventions (antstu, ygsiyu) and the use of Jimdo as a dead-drop resolver are consistent with "Ant Studio" development clusters. This group specializes in creating "Constructor" kits that automate the creation of malware, allowing low-skill actors to deploy high-impact surveillance tools.

4. Security Impact & Risk Assessment

The discovery of YGS-2026-02 confirms that the threat actor is running a concurrent, multi-vector campaign. The use of a dedicated RC4 cryptographic module represents a critical escalation, significantly increasing the risk of dark-attack vectors and unauthorized data disclosure.

5. Technical Appendix

  1. Original Filename: 戸 籍 开 道 助 手 .apk

  2. SHA-256 Hash: e90e20470814090d4d5c697d1860d76c412ea649978c6fa09d3b86de52d9d2cf

  3. MD-5 Hash: c32cdda5d3aea27f0a8a2c5aeb2cf452

  4. SHA-1 Hash: 75a86ea825faffb6a96c5ce3d277c5c822568e9d

  5. Recieve Method: User Report

  6. Link: https://www.virustotal.com/gui/file/e90e20470814090d4d5c697d1860d76c412ea649978c6fa09d3b86de52d9d2cf/detection

  7. Behavioral Results: The behavioral results below reveal an aggressive and highly repetitive file-system propagation and exfiltration staging pattern typical of iApp-based malware. The application systematically iterates through nearly every standard Android media and system directory (DCIM, Download, Movies, Pictures, etc.) to write a functional iApp source file (mian.iyu) and an MP3 asset (gx.mp3), suggesting a worm-like self-replication or a mechanism to ensure persistence even if the main APK is removed. The presence of libygsiyu.so and libluajava.so in memory confirms the active use of the iApp engine to orchestrate these actions.

  1. Network: On the network front, the malware establishes a clear command-and-control (C2) link to docq.cn (47.89.9.97) via port 80, while simultaneously utilizing TLS-encrypted traffic (likely for data exfiltration) to Cloudflare-backed IPs. The specific JA3 fingerprints and the SNI for www.googleapis.com indicate an attempt to blend in with legitimate Google background services to evade network-level detection. The deletion of userencryption.xml is particularly concerning, as it suggests the malware may be actively tampering with device encryption settings or clearing its own traces after a successful payload delivery, pointing to a high-risk compromise of the device's security integrity.

  1. Process: The process execution and service activity logs confirm that this sample is a high-privilege escalation threat designed for total device takeover. The execution of the su (SuperUser) command indicates an immediate attempt to gain root access, allowing the malware to bypass all Android sandbox restrictions. By hooking into the Accessibility Service, the app gains the ability to intercept keystrokes, read on-screen content (such as 2FA codes), and simulate user touches, while the activation of the Audio Service suggests background eavesdropping or call recording capabilities. The start of the com.iapp.app.run.mian activity with the specific intent parameter {"key": "OpenFilexmlui", "value": "zyj.iyu"} is the "smoking gun" for the execution of its primary malicious logic. This indicates that the iApp engine is loading a secondary, likely encrypted, UI/script file named zyj.iyu. Combined with the masquerade as a Google Games Service, this behavioral profile depicts a sophisticated Trojan that leverages administrative privileges and accessibility hooks to maintain persistence and conduct silent surveillance under the guise of a legitimate system process.

  1. Runtime: The runtime telemetry confirms that the malware's execution core is built on a highly dynamic Lua-Java bridge, which it uses to manipulate system-level behavior while evading static signature detection. By loading the luajava and ygsiyu (iApp) modules into memory, the application establishes a runtime environment capable of invoking native Android APIs directly from interpreted scripts. The invocation of android.os.SystemProperties.get indicates an active fingerprinting phase, where the malware retrieves sensitive device metadata—such as the IMEI, build version, or root status—to tailor its payload or detect analysis environments (anti-sandboxing). Simultaneously, the repeated calls to androidx.appcompat.app.AppCompatDialog and com.android.internal.policy.impl.PhoneWindow methods reveal a sophisticated UI overlay and hijacking strategy. By controlling dialog visibility (show, dismiss) and enforcing persistence (setCancelable(false), setCanceledOnTouchOutside(false)), the malware can create non-dismissible windows or "blocking" screens to facilitate social engineering or prevent user interference during a root-level attack. Furthermore, the inclusion of Conscrypt OpenSSL classes (OpenSSLCipher$Mode and Padding) within the invoked methods suggests that the Lua script is actively managing its own encrypted communication channel, likely to wrap exfiltrated data in a secondary layer of encryption before it is sent to the docq.cn C2 server.

  1. Crypto: The observation of javax.crypto.Cipher.doFinal combined with the presence of multiple hardcoded 128-bit AES keys provides definitive proof of the malware's cryptographic strategy for payload protection and data exfiltration. The use of the AES algorithm indicates a shift from the simple XOR "red herrings" found in the static analysis toward a robust, industry-standard encryption scheme managed at the Java runtime. These keys—specifically the sequences beginning with 32 E7 B3 and 41 B1 D0—likely serve as the master keys for decrypting the secondary iApp scripts (zyj.iyu) or for wrapping exfiltrated PII before it is transmitted over the network. The diversity of the observed keys suggests a multi-layered encryption architecture: one key may be dedicated to local file-system persistence (such as the written gx.mp3 or mian.iyu files), while others facilitate the secure handshake with the C2 infrastructure (docq.cn). By invoking doFinal directly, the malware completes the transformation of raw system data or intercepted Accessibility logs into encrypted blobs that are indistinguishable from legitimate HTTPS traffic. For forensic purposes, these extracted hex strings are the "Golden Keys"—they can be used to retroactively decrypt any local assets or intercepted packets, potentially revealing the plaintext configuration of the "Huji Assistant" campaign.

  1. Environment Detection: The systematic lookup of these specific system properties confirms a highly developed anti-analysis and environment-awareness suite. By querying qemu.hw.mainkeys and persist.sys.ui.hw, the malware is actively checking for "hardware" signatures that distinguish a physical device from an emulator or sandbox environment. The lookups for debug.layout and viewroot.profile_rendering further suggest the malware monitors whether developer tools or layout inspectors are active, allowing it to "go dark" or execute benign dummy code if it detects a researcher’s presence. This environmental fingerprinting is a tactical prerequisite for its more aggressive actions. By verifying the absence of a debugger through these system flags, the malware ensures it is safe to proceed with the su escalation and the deployment of its AES-encrypted payloads. In a forensic context, this confirms that YGS-2026-02 is not a generic script-kiddie tool, but a professional-grade surveillance variant designed to remain dormant in automated testing environments while successfully compromising the high-value personal data of real-world users.

6. Updates

1. Technical Discovery: The "Hydra" Protection Layer

The malware uses a Multi-Stage Native Unpacker designed to thwart static analysis and environment modification (like re-signing).

2. Payload Decryption Analysis: lib.so

2.1 Intelligence Overview

The investigation has successfully penetrated the first two defensive layers of the "burden" loading mechanism. Current intelligence confirms the following cryptographic parameters:

2.2 Technical Difficulties & Logic Gaps

The automated decryption workflow (LLM-Agent Pipeline) has reached a state of stasis due to the following "Black Box" dependencies:

  1. JNI Opaque Calls: The slky routine breaks static analysis by offloading cryptographic hashing to the Android Java API (java.security.MessageDigest). Without the specific algorithm (MD5 vs. SHA) and the runtime "salt" string, the seed for the final XOR cannot be predicted.

  2. State-Dependent Shuffling: The final decryption key is mutated via a Fisher-Yates style shuffle that is sensitive to the exact length and byte-sum of the input strings. A single-bit difference in the JNI return value results in a completely divergent XOR stream.

  3. Anti-Analysis Environment: The presence of ptrace checks and /proc/self/status monitoring prevents standard debuggers from attaching to the process to inspect the slky return buffer.

2.3 Proposed Resolution: The Frida-Based "Ghost" Hook

To bypass the complexity of the slky math, the Apich Security Team recommends a dynamic "Man-in-the-Middle" (MitM) approach using Frida. By intercepting the routine at the "Exit Point" rather than reversing the "Entry Logic," we can extract the final key material.

Execution Strategy:

2.4 Advanced Evasion: Hardware-Level Sandboxing

To successfully execute the Frida-based "Ghost" Hook, the environment must bypass multi-stage anti-analysis checks that specifically target virtualized environments and debugging frameworks.

2.4.1 The "Real Machine" Requirement

Modern iApp payloads often query the hardware abstraction layer (HAL) to detect emulators. To counter this, a Real Machine Sandbox (RMS) is mandatory.

2.4.2 Bypassing Heuristic "Tracer" Detection

The slky routine is protected by checks that monitor the /proc/self/status and /proc/self/maps files for strings like frida, gum-js, or a non-zero TracerPid.

Advanced Frida Stealth Techniques:

  1. Instruction Patching (The "Skip"): Instead of hiding Frida, use Frida to patch the anti-debug function in memory. Find the code that calls exit() or abort() upon detecting a debugger and replace it with NOP (No-Operation) instructions or a RET (Return).

  2. Kernel-Level Masking (KPROBES): For sophisticated samples, use a custom kernel (like KernelSU) that can hide the "su" binary and the "frida-server" process from the user-space entirely.

  3. D-Bus Protocol Obfuscation: Standard Frida communication uses the D-Bus protocol on a fixed port. Compiling a custom version of Frida with a modified string for the D-Bus communication prevents "String Scanning" detection.

2.4.3 Dynamic Context Recovery

The goal of the RMS is to reach the "Decryption Threshold"—the point where the app believes it is safe and executes asendn.

The Strategy for the Analysis Team:

3. Structural Analysis: The iApp/Ant Studio Framework

The malware is built on the iApp (Ant Studio) development framework, common in Chinese-origin grayware and Trojans.

4. Technical Discovery: The "Ghost Server" Backdoor

The malware utilizes an embedded web server to turn the infected device into a remote-controlled terminal.

5. Decoded Indicators of Compromise (IOCs)

Using the btoo (Byte-to-Object) decryption logic found in the scripts, we have successfully unmasked the "plain text" values that the malware uses to hide its operational hub.

Encoded DecimalDecoded ValueRole in Malware
55 51 52 54 50 56 51 56 55734628387The QQ Group ID. This is the primary command and control (C2) hub for the "Ant Studio" developers.
-26 -72 -87 ...温馨提示"Warm Reminder" — Used as the title for fake system popups.
-28 -72 -117 ...下载更新"Download Update" — The button text used to trick users into installing more malicious stages.

6. Defensive Infrastructure: The "China-Only" Gatekeeper

Our attempts to reach the command infrastructure revealed a high degree of operational security (OPSEC).

C2 Infrastructure Intelligence Report

Report ID: C2-2026-0120-YGS

Author: Apich Organization Security Team

Classification: High-Risk / Active Surveillance Cluster

Primary Target Region: Mainland China / Hong Kong

1. Architectural Overview

The infrastructure utilizes a Tiered Proxy-to-Backend model. This design ensures that if the front-end domain (docq.cn) is flagged, the central database and payload repository (107.151.212.80) remain hidden and reusable under different domain aliases.

TierComponentIdentityTechnical Role
Tier 1The Maskdocq.cnActs as the initial contact point. Routes traffic through Alibaba Cloud (US) to bypass regional domestic monitoring.
Tier 2The Controllerht.bu84.com"Heartbeat" (HT) server. Manages persistent connections from infected devices using IIS 10.0.
Tier 3The Vault107.151.212.80:3306Exposed MySQL database. Stores exfiltrated LogCat data, contacts, and device metadata.

2. Forensic Attribution (WHOIS Analysis)

The registration data reveals a strong link to the Fujian/Wuhan gray-market ecosystem, a known hub for the development of "iApp" modification tools and game injectors.

3. Detected Vulnerabilities. in C2

The attackers have made several critical "Amateur-Hour" errors that can be exploited:

This vulnerability poses a significant risk of sophisticated cyberattacks, which could result in the mass exfiltration and disclosure of Personally Identifiable Information (PII).

Noticeably, the attacker uses phpMyAdmin v5.2.0-rc.1 and MySQL v8.0.39 which both have many known critical security vulnerabilities.

4. Correlation with APK Analysis

The "modular" DEX files we found earlier are designed to feed this specific infrastructure:

5. Defensive Infrastructure: The "China-Only" Gatekeeper

Our attempts to reach the command infrastructure revealed a high degree of operational security (OPSEC).

Appendix

Acknowledgement

Sample Submission

The malware sample YGS-2026-01 was submitted by Xiaoru Zhang (Apich Organization) on January 19, 2026, at 23:12 CST.

Related malware sample YGS-2026-02 was submitted by Xiaoru Zhang (Apich Organization) on January 20, 2026, at 23:12 CST.

Analysis Timeline (YGS-2026-01 and YGS-2026-02)

Reporting & Coordination

The initial report was submitted to the TSRC on January 20, 2026, at 13:43 CST, with subsequent revisions finalized at 17:29 and 17:59 CST. Due to mailing system errors and latency, multiple copies of the reports were resubmitted again to the TSRC on January 21, 2026, using various methods (including mailing and wechat official accounts of TSRC, e.g.); however, no response has been received yet till the publishing of these reports. Thus, the reports are formally submitted to CNCERT on January 21, 2026, at 21:44 CST.

Conclusion of Internal Operations

With the release of this acknowledgement, the Apich Organization Security Team has officially concluded its primary internal tasks regarding sample YGS-2026-02. However, we remain committed to supporting the ongoing efforts of the TSRC and CNCERT.

Furthermore, our team will continue to actively monitor and track all future variants within the YGS malware family.

Special Thanks

We would like to extend our sincere gratitude to all members and external contributors who provided invaluable assistance throughout this analysis.

Personal Acknowledgement

The authors acknowledge the diligent administrative support recieved from the Physics Olympic Coaching Team of Jinan Zhensheng Middle School. Also, special thanks is given to Zining Li, Xiaoru Zhang and Yinxian Li for their continuous support and understanding of this investigation.