SilverFox-style loader chain: Panasonic shells, Alibaba OSS carriers, and a Sauron backdoor

ainstaller-86533005.exe is wearing a Panasonic jacket, and the fit is almost too good.

Inspect the file metadata and everything points at PPcNotif.Provider.RequiredApp.exe, Panasonic PC Notification, version 1.10510.0.0. Spin it up and the visible application code is coherent. There is command dispatch, notification IPC, GUI startup, Panasonic device logic, and a mutex for the app. If you stop at the front door, you see legitimate OEM-shaped software.

The malicious path starts in the basement before the Panasonic dispatcher gets the wheel. On execution, the binary allocates a new RWX buffer, copies an encoded stage from its own image, decodes it twice, peels a heap payload with a 19-byte XOR key, and jumps into the loader.

From there, the sample becomes a stack of borrowed coats: Alibaba OSS staging, image-named encrypted carriers, signed side-load hosts, protected DLLs, an RPC Task Scheduler module, a sparse bridge PE, a Philips-branded side-load cluster, and a final rundll32.dat!Edge export that implements Sauron service behavior.

The sample source for this writeup is the public Triage task 260619-v47g4ah12k (opens in new tab). The first family clues were thin: Joe Sandbox produced a Gh0stRAT-family signature hit late in the chain, and a VirusTotal community comment from LingGao tied ainstaller-86533005.exe to SilverFox. Those clues are pivots. The chain still has to stand on bytes.

---

Sample context

Why the SilverFox-style label fits

External reporting puts this sample near SilverFox/Winos tooling while leaving operator attribution unresolved.

Huorong's September 2024 SilverFox variant report (opens in new tab) is the strongest public overlap. Their chain describes Alibaba OSS-hosted a.gif, b.gif, c.gif, d.gif, s.dat, and s.jpg, a five-byte EOF trailer format, TrueSightKiller driver material, RPC Task Scheduler creation through NdrClientCall3, later drops.jpg staging, 360 security product checks, and a final backdoor export named Edge.

Picus's medical-software Silver Fox report (opens in new tab) gives a second public neighbor: trojanized Philips DICOM viewer material, Alibaba OSS staging, image-named encrypted payloads, TrueSightKiller, RPC task scheduling through \pipe\atsvc, and later FOM-* module downloads.

ThreatBook's WinOS ecosystem report (opens in new tab) frames SilverFox as a malware-as-a-service toolkit ecosystem with fuzzy actor boundaries. Fortinet's Winos4.0 analysis (opens in new tab) describes Winos4.0 as a modular framework rebuilt from Gh0stRAT and used in Silver Fox campaigns. MITRE ATT&CK (opens in new tab) tracks Gh0st RAT as public remote-access tool code used by multiple groups.

The Gh0stRAT-family sandbox hit has value as lineage gravity. The loader grammar carries the weight: Alibaba OSS, image-named carriers, five-byte trailer extraction, signed side-load hosts, AV-prep material, RPC task creation, and a late Edge backdoor stage.

---

Chain overview

Static chain:

ainstaller-86533005.exe
  -> staged buffer at 0x140086f2e
  -> decoded heap payload
  -> hxxps://jun616[.]oss-cn-beijing[.]aliyuncs[.]com/tad
  -> a.gif / b.gif / c.gif / d.gif / s.dat / s.jpg
  -> signed UxEnhanceHost + UxEnhance64.dll + msadox.tb + adoresd.dat
  -> msadox.tb RC4 shellcode
  -> adoresd.dat trailer-XOR adoresd.dll
  -> adoresd.dll!DelegateEnSerialization
  -> populated Ux bridge module

Runtime-ordered continuation, with static review of each artifact:

populated Ux bridge module
  -> D1IQf1.exe + XPSPLOG.dll + image.png + thumbs.db
  -> image.dll prep/dropper stage
  -> rundll32.dat!Edge / Sauron

Chain summary:

1. The Panasonic host is the wrapper.
2. The loader decodes itself into executable heap memory.
3. Static code reconstructs an Alibaba OSS staging URL.
4. The remote objects are image-named encrypted carriers.
5. s.jpg contains a compressed VirtuOne RPC scheduled-task DLL.
6. a.gif and b.gif form a signed Tencent Ux side-load pair.
7. msadox.tb and adoresd.dat carry shellcode and a sparse bridge DLL.
8. The populated bridge is tied to a later 26nn / drops pivot.
9. Runtime order then reaches a Philips side-load cluster.
10. image.png decodes to a protected prep/dropper DLL.
11. thumbs.db decodes to rundll32.dat, whose Edge export implements Sauron behavior.

---

Phase 1: Panasonic shell, staged loader

The visible Panasonic application code is a plausible host:

• Command dispatcher at 0x14001ce90
• Handlers for -isMatchStaticRequirement, -register, and -unregister
• GUI startup at 0x14001ca00
• Mutex PanasonicPcNotification_ProviderRequiredApp_MultipleInstancePreventer_MutexName
• Named pipe prefix \\.\pipe\PanasonicPcNotification.Pipe.Request.
• Panasonic device checks through SetupAPI and device IOCTLs

The malicious loader starts before that visible dispatcher.

At 0x1400038e6, the executable calls:

VirtualAlloc(NULL, 0xce59, 0x1000, 0x40)

It copies 0xce59 bytes from VA 0x140086f2e, then jumps into the allocated buffer. The staged buffer goes through two decoder layers. The second decoder starts with key 0x38, walks 0xce0d bytes, XORs each byte, and feeds the decoded byte back into the key.

The fully decoded stage then copies 0xae05 bytes from offset 0x2d and XOR-decodes them with:

4@e!c!bSL2AeimnwyD4x

That yields the heap payload.

The heap payload brings the real loader behavior:

• PEB/export walking for dynamic API resolution
• Timing and environment checks through QueryPerformanceCounter, Sleep, rdtsc, VirtualAllocExNuma, mutex probes, process checks, heap pressure, and COM/object probes
• ntdll.dll!NtTraceEvent patched with a single 0xc3 byte
• Defender exclusion commands launched through ShellExecuteA and powershell.exe
• WinINet download logic through InternetOpenA, InternetOpenUrlA, InternetReadFile, and InternetCloseHandle
• Elevated relaunch helper using ShellExecuteExA with verb runas
• Hidden VBS helper named checktime.vbs under a generated \Users\Public\ subdirectory

That is the first split between costume and chain. The Panasonic app gives the sample a respectable front door. The staged loader has already moved through the basement.

---

Phase 2: `jun616` and the image carriers

The first staging URL is built from static code and marker bytes.

A configuration helper reads the current executable, searches for marker */& at file offset 0x410, copies bytes after the marker, and feeds encoded fragments through a Caesar-style decoder:

ykkgj://                         -> hxxps://
ale616                           -> jun616
.fjj-te-svzazex.rczpletj.tfd/    -> .oss-cn-beijing[.]aliyuncs[.]com/
kru                              -> tad

The reconstructed URL is:

hxxps://jun616[.]oss-cn-beijing[.]aliyuncs[.]com/tad

That tad object acts as the shelf index for the remote payload set.

The image extensions are camouflage. The recovered code treats these files as opaque byte carriers. JPEG markers, PNG chunks, EXIF, DCT work, and LSB games are noise here. The tail matters.

The carrier grammar is simple and weirdly durable:

[payload_start_dword_le][xor_seed_byte]

The four bytes before EOF give the payload start offset. The final byte gives the XOR seed. The decoder XORs from payload_start to EOF-5, incrementing the key for each byte.

This grammar shows up again later in image.png, thumbs.db, and drops.jpg. The actors can repaint file names all day; this five-byte tail keeps squeaking.

---

Phase 3: `s.jpg` and RPC Task Scheduler creation

The decoded s.jpg file is shellcode carrying VirtuOne metadata and an aPLib-compressed block. Decompression recovers:

VirtuOne builds a local Task Scheduler RPC binding:

The DLL contains Task Scheduler XML with a logon trigger, a one-minute repeating time trigger, group principal S-1-5-32-545, HighestAvailable run level, a hidden task setting, and command/working-directory fields supplied by the caller.

Caller-side code in the heap payload maps the s.jpg payload, receives a function pointer, converts generated ASCII strings to UTF-16, and calls the recovered function pointer with wide-string arguments.

The fixed task machinery is inside RPCScheduleTask.dll. The concrete task name, command, working directory, and arguments are caller-generated values.

This overlap is loud. Huorong documented the same s.jpg pattern: shellcode, compressed DLL, RPC Task Scheduler logic, and NdrClientCall3.

---

Phase 4: Ux side-loading and the `adoresd.dll` bridge

The first side-load bundle comes from the a.gif through d.gif set.

The host is a signed Tencent UxEnhanceHost executable that imports these UxEnhance64.dll exports:

?EnableUxEnhance@@YA_NXZ
?DisableUxEnhance@@YA_NXZ

Both exports resolve to the same protected entry.

Loaded UxEnhance64.dll memory closes the bridge. The native attach path gates on edx == 1, then builds:

RC4 key:  3d e2 3f 7a d2 83 a1 f7
Marker:   bb e6 36 23 33 96 3b 89

It reads sibling msadox.tb, searches for the marker, copies the bytes after it, initializes RC4, and decrypts the tail.

That shellcode opens adoresd.dat, reads the five-byte trailer, and applies the same incrementing-XOR carrier decode. Runtime trailer bytes:

d0 05 00 00 f8

That gives payload start 0x5d0 and seed 0xf8.

The decoded payload is a large sparse PE:

The shellcode manually maps adoresd.dll, resolves DelegateEnSerialization, and calls it with a context pointer.

Then the bridge performs its best haunted-building routine. Earlier memory snapshots show a sparse mapped image with a protected .bTM section. Later snapshots show the same image with formerly empty sections populated while .bTM remains stable. The bridge is the chain's staging cathedral: lots of empty space, one locked room, and then every pew fills with code.

---

Phase 5: the populated bridge and `26nn`

The populated Ux bridge image contains the next major transition:

• Registry marker strings: Software\ODBDC, revbs
• Defender exclusion scheduled-task template for task name Task1
• Follow-on OSS fragments: hxxps://26nn[.]oss, -cn-hangzhou[.]ali, [.]yuncs[.]com/drops
• Code-referenced GetData user-agent material

The Triage-retained packet capture confirms TLS SNI for both OSS hosts:

jun616[.]oss-cn-beijing[.]aliyuncs[.]com
26nn[.]oss-cn-hangzhou[.]aliyuncs[.]com

The Triage capture gives host-level TLS SNI. Cleartext object paths are absent from that capture. Triage runtime summaries record the later request:

hxxps://26nn[.]oss-cn-hangzhou[.]aliyuncs[.]com/drops.jpg
User-Agent: GetData

The saved Triage PCAP-derived /drops.jpg object is available and decodes cleanly with the same five-byte trailer grammar.

Decoded drops.jpg is x64 shellcode-style material with:

• kernel32.dll
• runas
• .lnk
• .dat
• .exe
• SOFTWARE\JDBCC
• GetData
• 360tray.exe
• 360sd.exe
• 360safe.exe
• Q360SafeMonClass
• CreateToolhelp32Snapshot
• Process32First
• Process32Next
• MessageBoxA

A separate Triage-retained mapped PE32+ DLL from the same later phase has SHA-256 12845df5f905fe5345829b2aca546ba8eecbd84f1a2924993b076a5d33bd1307 and contains additional 360 security-tool strings such as 360Tray.exe, 360Safe.exe, LiveUpdate360.exe, and 360sd.exe. The byte tie or loader path from decoded drops.jpg shellcode to that mapped PE remains an evidence need, so we keep it scoped as a separate later-phase artifact.

The later phase has a familiar SilverFox flavor: 360 checks, more shellcode staging, and another cloud object pretending to be an image.

---

Phase 6: Philips side-load cluster

Runtime order places a new side-load cluster after the populated Ux bridge:

C:\Program Files (x86)\D1IQf1\D1IQf1.exe
C:\Program Files (x86)\D1IQf1\XPSPLOG.dll
C:\Program Files (x86)\D1IQf1\image.png
C:\Program Files (x86)\D1IQf1\thumbs.db

Artifacts:

D1IQf1.exe imports XPSPLOG.dll ordinals 2, 3, 4, 6, 7, and 8. r2 xrefs show direct calls to all imported ordinals plus additional indirect calls through loaded thunks.

The protected handoff through XPSPLOG remains bounded at instruction level. The D1 cluster artifacts and their decoded internals are confirmed.

`image.png` to `image.dll`

The image.png carrier uses the same five-byte trailer grammar:

trailer: d0 05 00 00 6e
start:   0x5d0
seed:    0x6e

It decodes to:

image.dll
SHA-256: 96aee41363c08acf6a6230d1dda5f7e7dae9f78952993b70a9c8c4949c81bb22
Export: PhilipsCoInitialize

A rebuilt populated image.dll snapshot shows the prep/dropper stage:

• Defender Task1 scheduled-task template
• Windows Update disablement body
• Add-MpPreference -ExclusionPath 'C:\ProgramData','C:\Users','C:\Program Files (x86)' -Force
• icacls command builders
• Full D1 bundle path table for D1IQf1.exe, image.png, thumbs.db, and XPSPLOG.dll
• File-table writer for the D1 bundle artifacts
• Path check/decode/write path for C:\Windows\Temp\ranchserv.jpg

Triage-retained mapped-image snapshots show image.dll materializing in phases. Snapshot A to B populates .text, .rdata, .data, and .az* while .k]\ remains unchanged. Snapshot B to C materializes the D1 path table. Snapshot C to D changes one byte in .data. The stable strings stay stable. The protected .k]\ section acts like the dispatcher/materializer room.

The ranchserv.jpg material comes from the earlier s.dat decode and is a signed TrueSight anti-rootkit driver. File materialization is confirmed. Driver execution remains an open evidence need pending a concrete service-load or driver-load callsite.

Triage process telemetry during this phase recorded:

cmd.exe /c vssadmin delete shadows /all /quiet

Absence gates across the Triage-retained D1 host memory pages and rebuilt images found zero ASCII or UTF-16LE vssadmin / delete shadows strings. That makes the command a runtime observation with an unrecovered generator or callsite.

The Philips cluster is where the Picus public neighbor becomes useful. Picus documented Silver Fox public-sector campaigns using trojanized Philips DICOM software, Alibaba OSS, a.gif through d.gif, s.dat, s.jpeg, TrueSightKiller, RPC task scheduling, and later FOM-* modules. Our case starts in a Panasonic host, reaches Philips material later, and lands in the same staging neighborhood.

---

Phase 7: `thumbs.db` to `rundll32.dat!Edge`

The thumbs.db carrier also uses the five-byte trailer grammar:

trailer: 90 09 00 00 45
start:   0x990
seed:    0x45

Decoded output:

A Triage-retained mapped image from runtime has the same PE core with changed config fields:

Static review of rundll32.dat!Edge shows Sauron service behavior:

• Uses HKCU\SOFTWARE\Sauron
• Copies itself to C:\Windows\svchost.exe when the Sauron key is absent
• Creates and starts service Sauron
• Deletes marker files such as C:\del, C:\tzfz, C:\1.ini, C:\2.ini, c:\xxxx.ini, and C:\xxxx.inst.ini
• Checks security and analysis tool names
• Writes cleanup batch content
• Launches cleanup, firewall-off, BOOTSECT, marker-file, taskkill, downloader, and service paths
• Uses downloader templates:
  • hxxp://%s/upx.rar
  • hxxp://%s/%d.dll
  • hxxp://%s/ip.txt

The Gh0stRAT-family label has practical value here. Public reporting ties SilverFox/Winos tooling to Gh0stRAT-derived RAT lineages, and this final stage behaves like a service-backed remote-access component with downloader and command-launch paths.

The strongest supported runtime config material for this case is:

47[.]239[.]170[.]54
gqsqoq[.]net

The Joe Sandbox-reported 47[.]238[.]95[.]170:7089 remains a sandbox-report lead until matching packet bodies, decoded payload bytes, or mapped config material promote it.

---

Parallel D1-style branch

A second D1-style branch appears in Triage-retained runtime evidence:

C:\Program Files (x86)\2GfN8\ULR23.exe

The Triage-retained second XPSPLOG.dll is nearly identical to the D1 XPSPLOG.dll:

This branch supports reuse of the same protected carrier set under a second randomized host path. Extra claims stay tied to retained bytes from that branch.

---

What made this sample painful

The sample is layered in a way that punishes single-source analysis.

The static file gives the first loader and URL construction. The recovered remote objects give the carriers. The side-loaded Ux path becomes clear from Triage-retained loaded memory. The bridge begins sparse, then populates itself in memory. The D1 stage uses protected dispatch through ordinal exports. image.dll has stable strings only after runtime population. rundll32.dat carries one config in the decoded carrier and a changed config in the Triage-retained mapped image.

The defensive summary is simple. The research path is swamp ballet.

The recurring design choices are:

• Signed host, protected side-loaded DLL
• Opaque carrier file beside the DLL
• Five-byte EOF trailer for payload extraction
• Incrementing XOR or RC4 transform
• Manual mapping into memory
• Defender and AV-prep commands around the payload
• Cloud object storage used as the payload shelf
• Randomized local directories and filenames
• Late-stage config mutation in mapped memory

Those mechanics matter more than the bucket names. Buckets churn. Carrier grammar tends to leave fingerprints.

---

Detection and hunting notes

Carrier grammar

Hunt for image-named or data-named files where the last five bytes can be interpreted as:

[payload_start_dword_le][xor_seed_byte]

Then attempt incrementing-XOR decode from payload_start to EOF-5. Look for:

• MZ
• Shellcode entry patterns such as near jumps
• High-entropy protected PE material
• Exports such as Edge, PhilipsCoInitialize, DelegateEnSerialization, or task-registration functions

This family of carrier logic appeared across:

a.gif
b.gif
c.gif
d.gif
s.jpg
image.png
thumbs.db
drops.jpg

Side-load bundles

High-signal local groupings:

UxEnhanceHost / UxEnhance64.dll / msadox.tb / adoresd.dat
D1IQf1.exe / XPSPLOG.dll / image.png / thumbs.db

The Ux bundle is especially strong when UxEnhance64.dll is adjacent to msadox.tb and adoresd.dat, and the DLL imports only KERNEL32.dll!ReadFile.

The D1 bundle is strong when a signed Philips/Speech Processing Solutions host loads protected XPSPLOG.dll and sits beside image.png and thumbs.db.

RPC scheduled task creation

Cover Task Scheduler RPC alongside command-line schtasks.exe:

86D35949-83C9-4044-B424-DB363231FD0C
ncacn_np
\pipe\atsvc
NdrClientCall3
HighestAvailable
S-1-5-32-545

Defender and prep commands

Strings and command bodies observed across populated stages include:

Task1
Add-MpPreference -ExclusionPath 'C:\ProgramData','C:\Users','C:\Program Files (x86)' -Force
Exclusions\Paths
icacls
Alibaba SecurityHealth

Backdoor service artifacts

For the decoded rundll32.dat!Edge stage:

HKCU\SOFTWARE\Sauron
Sauron
C:\Windows\svchost.exe
hxxp://%s/upx.rar
hxxp://%s/%d.dll
hxxp://%s/ip.txt
C:\del
C:\tzfz
C:\1.ini
C:\2.ini
c:\xxxx.ini
C:\xxxx.inst.ini

Network pivots

---

MITRE ATT&CK mapping

---

IOC summary

Hashes

Network

Host indicators

---

Research scope

The static chain is strong from the outer executable through the Ux bridge and into decoded D1 artifacts. Several later runtime items remain scoped:

• /drops.jpg is bridge-correlated. The bridge has code-referenced 26nn / drops fragments and GetData material; Triage runtime summaries record the matching request; the saved Triage PCAP-derived object bytes decode as documented.
• vssadmin delete shadows is runtime-observed. Absence gates found zero generator strings in the reviewed D1 pages and rebuilt images.
• 47[.]238[.]95[.]170:7089, /f.dat, and FOM-* are sandbox-report leads. Treat 47[.]238[.]95[.]170:7089 as a Joe Sandbox lead until byte evidence promotes it.
• ranchserv.jpg file materialization is confirmed; driver execution needs loader-path evidence.
• The protected XPSPLOG handoff into image.png and thumbs.db is bounded by imported ordinal calls and decoded artifacts.
• The VirtuOne task structure is confirmed; concrete task fields are caller-generated.
• The parallel D1-style branch is supported by the Triage-retained second XPSPLOG.dll and second image.png carrier evidence.

Keep that boundary intact. It separates a defensible teardown from a tidy story. The loader has plenty of masks. The byte trail is still visible.

---

Conclusion

ainstaller-86533005.exe is a layered SilverFox-style loader chain wrapped in a Panasonic host.

The sample moves through an early in-memory loader, reconstructs an Alibaba OSS staging URL, retrieves image-named encrypted carriers, builds a signed Ux side-load bundle, decrypts a bridge DLL through RC4 and trailer-XOR payloads, reaches a Philips side-load cluster, and lands at rundll32.dat!Edge, which implements Sauron service/backdoor behavior.

Huorong's SilverFox report gives the clearest public overlap: cloud-storage rhythm, image-carrier names, five-byte trailer format, TrueSightKiller material, RPC Task Scheduler machinery, and late drops.jpg / Edge flavor. Picus adds the Philips and medical-themed tradecraft. ThreatBook and Fortinet give the family context: WinOS/Winos4.0 sits in a Gh0stRAT-derived ecosystem used across multiple campaigns.

I would label it SilverFox / Winos-style ecosystem alignment with a Gh0stRAT-family late-stage signal.

For detection, chase the grammar over the costume: Alibaba OSS plus image-named carriers plus five-byte trailer XOR plus signed side-load hosts plus RPC task creation plus late Edge export.

That constellation is the fingerprint. File names can change.