Same Wrapper, Different Payloads: A Technical Analysis of the Xiang Corp Crypter Cluster

Executive Summary

A clustered set of malicious Windows executables, all presenting as a Microsoft Firewall component and packed with ASPack 2.12, initially appeared to belong to a single malware family.

However, once execution crossed the unpacking boundary and the payloads were reconstructed in memory, that assumption no longer held. Analysis revealed that the same outer wrapper was used to deliver multiple distinct second-stage payloads, including Amadey, HijackLoader, Cobalt Strike, HelloKitty ransomware, Remcos RAT, SmokeLoader, Vidar, and Rhadamanthys.

The key finding is that, in clusters shaped by shared crypter infrastructure, wrapper-level indicators are not sufficient to identify the underlying malware.

Overview

This analysis was performed by Zenyard Agent on a clustered set of samples without prior labeling or analyst-provided context, demonstrating how automated unpacking and memory reconstruction can reveal payload-level distinctions not visible at the wrapper layer.

Zenyard Agent analyzed a clustered set of malicious Windows executables that shared a consistent outer wrapper and forged metadata associated with a Microsoft Firewall component. The analysis was produced from a set of Windows PE samples without prior context, labeling, or human analyst involvement. 

The samples exhibited a common outer executable structure used to deliver multiple distinct second-stage payloads. Recovered payloads included Amadey and HijackLoader, while cluster-level observations linked the same wrapper pattern to additional commodity malware and intrusion tooling. The wrapper also contained artifacts that could support an incorrect association with Gh0st RAT if analysis were limited to static metadata and packer characteristics.

This report focuses on three findings: the shared wrapper architecture, divergence in unpacked payloads, and the attribution risk introduced when crypter infrastructure is treated as payload identity.

Shared Wrapper Infrastructure

Across the analyzed cluster, execution began from a common first-stage wrapper designed to impersonate a legitimate Windows component while concealing a variable second-stage payload.

The wrapper repeatedly presented the same version-information values, including ProductName “Microsoft Firewall,” CompanyName “Xiang Corporation,” FileVersion “1.00.0007,” and a timestamp of 0x46c597d8 (2007-08-17). These values provided a stable visual identity across samples while reducing the usefulness of superficial file inspection. The timestamp was also consistent with known ASPack-era artifacts.

The outer PE exposed a minimal import table consisting of GetProcAddress, GetModuleHandleA, LoadLibraryA, and _CIcos. This limited static visibility and shifted functional resolution to runtime. The presence of _CIcos links execution to msvbvm60.dll, contributing to a less suspicious profile while obscuring the behavior that follows unpacking.

Execution begins through an offcut control-transfer sequence that interrupts linear disassembly and redirects execution into unpacking logic:

0x00409000: 90           NOP
0x00409001: 60           PUSHAD
0x00409002: E8 03000000  CALL 0x40900a
0x00409007: E9 EB045D45  JMP ...

Following this sequence, the wrapper dynamically resolves additional APIs, allocates memory using VirtualAlloc, and reconstructs the embedded payload into a newly executable region. In these samples, the most meaningful boundary is not the original PE on disk, but the reconstructed payload that appears in memory after execution passes the unpacking stage.

Payload Divergence

Static clustering at the wrapper layer suggests a uniform campaign. Post-unpack analysis does not support that conclusion.

Memory reconstruction reveals multiple structurally distinct second-stage payloads delivered through the same outer executable framework. In representative subsets, the recovered payloads align with Amadey and HijackLoader. At the cluster level, the same wrapper pattern is also associated with Cobalt Strike, HelloKitty ransomware, Remcos RAT, SmokeLoader, Vidar, and Rhadamanthys.

This divergence is significant. In this cluster, the wrapper identifies shared delivery infrastructure, but does not reliably indicate malware family, operator, or downstream objective.

Observed Payload Variant: Amadey

In one subset of the analyzed samples, the reconstructed second stage is consistent with Amadey Loader, preceded by anti-analysis and decryption logic.

Before payload handoff, the unpacking chain accesses the Kernel Processor Control Region (KPCR) at 0xffdff1ac. User-mode access to this region is unusual and is commonly associated with execution-environment checks. The unpacker also executes a repeated PRNG-dependent loop that incorporates runtime state and code-relative memory reads into token or address derivation. This behavior reduces the reliability of static analysis and simplified emulation, as key values are only derived during execution.

Once reconstructed, the payload exhibits network behavior consistent with Amadey Loader, including HTTP POST requests to /index.php, /gate.php, and /tasks.php. These artifacts support classification of the payload independently of the outer wrapper.

Observed Payload Variant: HijackLoader

In another subset of the cluster, the same outer wrapper delivers a structurally different second-stage payload.

The memory-resident payload is recovered as a fully formed executable of approximately 466 KB, with build characteristics consistent with Visual Studio 2017. The most distinctive feature is a writable section named .c2r associated with import-related data. This is not a standard PE convention and aligns with known HijackLoader (IDAT Loader) structural patterns.

In this subset, the .c2r section provides a stronger family indicator than any outer-layer metadata present in the wrapper. The recovered structure supports classification of the payload as HijackLoader, while the wrapper remains consistent across the broader Xiang Corp cluster.

Attribution Considerations

The analyzed cluster highlights a recurring attribution failure mode. Shared crypter infrastructure can produce stable static artifacts that are mistakenly treated as indicators of malware family.

External telemetry associated this cluster with Gh0st RAT, likely due to the presence of Chinese-language resources, the forged vendor string “Xiang Corporation,” ASPack usage, and memory characteristics overlapping with older packed specimens. These signals originate from the wrapper layer and do not reflect the identity of the reconstructed payloads.

Recovered payloads in representative subsets align with Amadey and HijackLoader, not with a recovered Gh0st RAT core. The wrapper artifacts are therefore insufficient for reliable attribution.

The Xiang Corp wrapper should be treated as shared crypter infrastructure. In this cluster, wrapper-level indicators are useful for identifying a distribution or concealment layer, but not for identifying malware family or operator.

Detection Opportunities

The Xiang Corp cluster reinforces the limitations of detection approaches that rely on hashes, version-information fields, or packer identity without post-unpack inspection.

More reliable signals are observed at the behavioral and memory level. Processes that allocate executable or writable-executable memory using VirtualAlloc and transfer execution into that region are of particular interest, especially when originating from a PE with a minimal import footprint. Post-unpack memory inspection and reconstruction of PE structures provide significantly stronger classification signals than static analysis of the original file.

Additional indicators include anti-analysis behavior such as user-mode reads in the KPCR range (0xffdff000 to 0xffdfffff). Trust decisions should not rely on metadata fields such as CompanyName or ProductName, but instead on validated signatures, execution policies, and runtime behavior.

Where crypter reuse is suspected, analysis should separate the wrapper layer, which reflects distribution or concealment, from the payload layer, which determines functionality and likely operational intent.

Conclusion

Analysis of the Xiang Corp cluster identified a shared ASPack-based wrapper used to deliver multiple distinct second-stage payloads. Although the wrapper presented consistent metadata and packing characteristics, these indicators did not reliably identify the malware carried within the samples.

The decisive insight emerged only after post-unpack analysis and memory reconstruction, which revealed clear divergence in payload structure and behavior.

The key lesson is that, in clusters shaped by shared crypter infrastructure, wrapper-level indicators should not be treated as a substitute for payload identification. Reliable classification requires inspection beyond the outer layer, including memory reconstruction and behavioral analysis.

Appendix A: Representative Wrapper Characteristics

Appendix B: YARA Rules

rule Zenyard_XiangCorp_ASPack_Wrapper {
    meta:
        description = "Detects a Xiang Corp ASPack wrapper variant used for malware delivery"
        author = "Zenyard Agent"
        date = "2026-03-15"
    strings:
        $aspack_ep  = { 60 E8 03 00 00 00 E9 EB 04 }
        $company    = "Xiang Corporation" wide
        $fake_name  = "Microsoft Firewall" wide
        $vb6_rt     = "msvbvm60.dll" ascii
    condition:
        uint16(0) == 0x5A4D and
        $aspack_ep and
        ($company or $fake_name) and
        $vb6_rt
}

rule Zenyard_Unpacked_HijackLoader_C2R {
    meta:
        description = "Detects unpacked payloads with a writable .c2r section consistent with HijackLoader"
        author = "Zenyard Agent"
        date = "2026-03-15"
    strings:
        $sec_c2r = ".c2r" ascii
    condition:
        uint16(0) == 0x5A4D and
        math.entropy(0, filesize) > 6.0 and
        pe.number_of_sections >= 5 and
        for any i in (0..pe.number_of_sections - 1): (
            pe.sections[i].name == ".c2r" and
            pe.sections[i].characteristics & pe.SECTION_MEM_WRITE
        )
}