Execution via Shell_TrayWnd

We found some PlugX variants embedding a fourth file in the SFX RAR. This new file is an executable and is runned after all the files have been extracted on the system.

$ unrar l sample.bin
...
Setup=HP.EXE
...
 Attributes      Size    Date   Time   Name
----------- ---------  -------- -----  ----
    ..A....    514568  01-08-14 21:23  HPCustPartic.exe
    ..A....      3584  21-03-15 01:35  HPCustPartUI.dll
    ..A....    121612  26-03-15 17:35  HPCustPartUI.dui
    ..A....     32768  21-03-15 01:34  HP.exe     

The main purpose of this binary is to create a new registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\AppKey\18\ShellExecute and make it point to the second binary (HPCustPartic.exe).

The AppKey key is used to define which application should be executed when special keyboard keys are pressed. Number 18 correspond the key APPCOMMAND_LAUNCH_APP2, which usually is the calculator key.

After setting the registry key, the application just sends a WM_APPCOMMAND message to the Shell_TrayWnd window with APPCOMMAND_LAUNCH_APP2 parameter, making explorer.exe think that the special key has been pressed and launch the HPCustPartic.exe binary.
We found 3 different binaries using this method, each one with a different debug string:

D:\My2013\SController(2.5)(GF-2)(HTTPOnly)\Start\Release\Start.pdb
D:\My2014\SController(5.3)(CX)(Avast)(Nod32)\Start\Release\Start.pdb
G:\My2014\SController(5.3)(CX)(Avast)\Start\Release\Start.pdb

The SController project name was also found in the first PlugX v2 samples.

Variant of PlugX v1

We recently found several samples of the first PlugX version with some differences from the original:

  • A new layer of shellcode obfuscation (multiple layers of SUB and XOR)
  • A new configuration size: 0x170c
  • New embedded binaries in the final DLL, with a curious string “KingOfPhantom0308_20140826”

These new points made us think that the source code of first version might have been sold or given to another developper, who made some improvements.
There was also a funny bug in the earlier samples we observed: the last string of the configuration file (last 0x200 bytes) was not padded with null bytes, effectively disclosing some uninitialized memory:

00001500: 0000 0000 0000 0000 0000 0000 4d00 6500  ............M.e.
00001510: 6400 6900 6100 4300 6500 6e00 7400 6500  d.i.a.C.e.n.t.e.
00001520: 7200 2e00 6500 7800 6500 0000 0000 2b00  r...e.x.e.....+.
00001530: 5001 2b00 4500 4f00 5c00 4400 6500 7300  P.+.E.O.\.D.e.s.
00001540: 6b00 7400 6f00 7000 5c00 4d00 6100 6b00  k.t.o.p.\.M.a.k.
00001550: 6500 7200 0000 4800 0300 0000 8ce3 7377  e.r...H.......sw
00001560: c863 4b1c 1807 fa76 9c01 2b00 0000 2b00  .cK....v..+...+.
00001570: 1e00 0000 7cfd 1800 0b00 5c00 e4fd 1800  ....|.....\.....
00001580: 88fa 7277 a8fe 1800 9cfd 1800 3f62 7477  ..rw........?btw
00001590: 4462 7477 9063 4b1c a8fe 1800 88fa 7277  Dbtw.cK.......rw
000015a0: e4fd 1800 74fd 1800 9afa 7277 d4fe 1800  ....t.....rw....
000015b0: d571 7877 b450 206b feff ffff 1cff 1800  .qxw.P k........
000015c0: 90fe 1800 3400 00c0 dcfd 1800 3f62 7477  ....4.......?btw
000015d0: 4462 7477 d063 4b1c 3400 00c0 90fe 1800  Dbtw.cK.4.......
000015e0: 1cff 1800 b4fd 1800 0200 0000 50fe 1800  ............P...
000015f0: d571 7877 b450 206b feff ffff 4462 7477  .qxw.P k....Dbtw
00001600: 9622 ed76 c622 ed76 da1e 2b48 08a5 5600  .".v.".v..+H..V.
00001610: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001620: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001630: 0000 0000 0000 0000 0000 0000 0100 0000  ................
00001640: 1800 0000 d000 0000 90fe 1800 0000 0000  ................
00001650: 0000 0000 0000 0000 54fe 1800 187e 7477  ........T....~tw
00001660: 0000 0000 0000 0000 0000 0000 6832 2f00  ............h2/.
00001670: e000 fa76 6832 2f00 0000 0000 e000 fa76  ...vh2/........v
00001680: 70fe 1800 7825 ed76 e000 fa76 0200 0000  p...x%.v...v....
00001690: c8fe 1800 3b24 ed76 0000 0000 4224 ed76  ....;$.v....B$.v
000016a0: 721e 2b48 ecf9 5b00 a4f9 5b00 204a 5c00  r.+H..[...[. J\.
000016b0: 7800 7800 08a5 5600 5e1e 2b48 dcf9 5b00  x.x...V.^.+H..[.
000016c0: 9cf9 5b00 7911 2575 0000 0000 6832 2f00  ..[.y.%u....h2/.
000016d0: 80fe 1800 0000 0000 78ff 1800 2341 f776  ........x...#A.v
000016e0: f2c4 de3e feff ffff 4224 ed76 1223 ed76  ...>....B$.v.#.v
000016f0: d000 0000 08a5 5600 0000 0000 0100 0000  ......V.........
00001700: 1cff 1800 0000 0000 20ff 1800            ........ ...

The new embedded binaries are:

  • DLLs (32 bits and 64 bits versions) to bypass UAC using sysprep.exe and CRYPTBASE.dll (DLL hijacking)
  • A 64 bits executable to hide a service by removing it from the doubly linked list SERVICE_RECORD in services.exe, the 32 bits equivalent being directly integrated in the PlugX DLL

Looking for these kind of PlugX versions on VT led us to an interesting discover: a builder for this specific variant:

maker

 

This builder allows creating PlugX samples with various loading methods.
One of the built binaries is a full debug version, showing some interesting strings:

  • The project name is Maker (H:\FAST\生成器\Maker\Release\Maker.pdb), which links to the string found in the leaked memory of the configuration (Desktop\Maker)
  • The name of the service hiding part: CXHide::HdSvc, CXHide::HdSvcFor5x, CXHide::HdSvcFor6x

The builder also embeds various binaries to perform shellcode ciphering and/or obfuscation:

  • bmd_rc4.exe: encrypts/decrypts a file using RC4
  • a tool to encode a binary in a C header file (equivalent of xxd -i)
  • random_shellcode.exe: a tool to add an arbitrary number a layers of SUB and XOR to a shellcode
  • ScLdr: a tool to perform various PlugX-based operations on an input file: ciphering (using v1 algo), creating the loader, adding a xor layer, etc.
  • a bunch of PlugX loaders and DLLs to be populated by the configuration created in the tool

New shellcode obfuscation

Some of the latest PlugX samples we analyzed (with the latest encryption algorithm described by JPCert) showed a new obfuscation method of the main shellcode.
Instead of the traditional junk code made of conditional jumps and useless instructions, the new one makes huge use of FPU instructions:

This is a simple XOR layer to hide the old ADD/XOR/SUB encryption:

The rest of the shellcode is unchanged.