Author: Boldizsar Bencsath

About the APK:

The APK file, that was investigated by Crowd Strike and us is actually corrupt, unzipping yields two warnings and a CRC Error.

$ unzip 6f7523d3019fa190499f327211e01fcb.apk
Archive: 6f7523d3019fa190499f327211e01fcb.apk
warning [6f7523d3019fa190499f327211e01fcb.apk]: 1 extra byte at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 1
(attempting to re-compensate)
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
inflating: AndroidManifest.xml
inflating: classes.dex
extracting: res/drawable-hdpi/dmk.png
extracting: res/drawable-hdpi/ic_launcher.png
extracting: res/drawable-mdpi/fon_1.jpg
extracting: res/drawable-mdpi/fon_2.png
extracting: res/drawable-mdpi/fon_3.png
extracting: res/drawable-mdpi/ic_action_search.png
extracting: res/drawable-mdpi/ic_launcher.png
extracting: res/drawable-mdpi/panel_2.gif
extracting: res/drawable-mdpi/panel_4.png
extracting: res/drawable-mdpi/panel_5.png
extracting: res/drawable-mdpi/panel_6.png
extracting: res/drawable-mdpi/panel_7.png
extracting: res/drawable-mdpi/warnings.png bad CRC 73cded37 (should be 902e9cdb)
file #19: bad zipfile offset (local header sig): 660433
(attempting to re-compensate)
extracting: res/drawable-xhdpi/ic_launcher.png
extracting: res/drawable-xxhdpi/ic_launcher.png
inflating: res/layout/activity_reg_form.xml
inflating: res/layout/byleten.xml
inflating: res/layout/dan_dmk.xml
inflating: res/layout/dan_meteo.xml
inflating: res/layout/dan_vr_2.xml
inflating: res/layout/meteo_podg_form.xml
inflating: res/layout/o_avtope_form.xml
inflating: res/layout/pomow_form.xml
inflating: res/layout/promt.xml
extracting: resources.arsc

In this form, it is not possible to install the APK, trying so results in the phone yielding the following error message:
$ adb install 6f7523d3019fa190499f327211e01fcb.apk
Failed to install 6f7523d3019fa190499f327211e01fcb.apk: Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION: Failed to parse /data/app/vmdl135131206.tmp/base.apk: AndroidManifest.xml]

From the error messages we suspected, that an extra byte somehow ended up in the APK file.
The repair process consisted of finding and removing an extra byte from the file “warnings.png”. By changing only this byte and getting a valid APK file, this might be the original file. After repair, we got the following file.
$ sha256sum REPAIRED.apk
5b6ea28333399a73475027328812fb42259c12bb24b6650e5def94f4104f385e REPAIRED.apk

$ unzip -vt REPAIRED.apk
Archive: REPAIRED.apk
testing: META-INF/MANIFEST.MF OK
testing: META-INF/CERT.SF OK
testing: META-INF/CERT.RSA OK
testing: AndroidManifest.xml OK
testing: classes.dex OK
testing: res/drawable-hdpi/dmk.png OK
testing: res/drawable-hdpi/ic_launcher.png OK
testing: res/drawable-mdpi/fon_1.jpg OK
testing: res/drawable-mdpi/fon_2.png OK
testing: res/drawable-mdpi/fon_3.png OK
testing: res/drawable-mdpi/ic_action_search.png OK
testing: res/drawable-mdpi/ic_launcher.png OK
testing: res/drawable-mdpi/panel_2.gif OK
testing: res/drawable-mdpi/panel_4.png OK
testing: res/drawable-mdpi/panel_5.png OK
testing: res/drawable-mdpi/panel_6.png OK
testing: res/drawable-mdpi/panel_7.png OK
testing: res/drawable-mdpi/warnings.png OK
testing: res/drawable-xhdpi/ic_launcher.png OK
testing: res/drawable-xxhdpi/ic_launcher.png OK
testing: res/layout/activity_reg_form.xml OK
testing: res/layout/byleten.xml OK
testing: res/layout/dan_dmk.xml OK
testing: res/layout/dan_meteo.xml OK
testing: res/layout/dan_vr_2.xml OK
testing: res/layout/meteo_podg_form.xml OK
testing: res/layout/o_avtope_form.xml OK
testing: res/layout/pomow_form.xml OK
testing: res/layout/promt.xml OK
testing: resources.arsc OK
No errors detected in compressed data of REPAIRED.apk.

$ jarsigner -verbose -verify REPAIRED.apk

s 2215 Thu Feb 28 18:33:46 CET 2008 META-INF/MANIFEST.MF
2268 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.SF
1714 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.RSA
sm 6108 Thu Feb 28 18:33:46 CET 2008 AndroidManifest.xml
sm 543000 Thu Feb 28 18:33:46 CET 2008 classes.dex
sm 7047 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/dmk.png
sm 1703 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/ic_launcher.png
sm 68364 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_1.jpg
sm 153893 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_2.png
sm 182654 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_3.png
sm 311 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_action_search.png
sm 1853 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_launcher.png
sm 2241 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_2.gif
sm 4420 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_4.png
sm 450 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_5.png
sm 1448 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_6.png
sm 551 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_7.png
sm 25089 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/warnings.png
sm 2545 Thu Feb 28 18:33:46 CET 2008 res/drawable-xhdpi/ic_launcher.png
sm 4845 Thu Feb 28 18:33:46 CET 2008 res/drawable-xxhdpi/ic_launcher.png
sm 4356 Thu Feb 28 18:33:46 CET 2008 res/layout/activity_reg_form.xml
sm 20332 Thu Feb 28 18:33:46 CET 2008 res/layout/byleten.xml
sm 10584 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_dmk.xml
sm 20852 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_meteo.xml
sm 10208 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_vr_2.xml
sm 2772 Thu Feb 28 18:33:46 CET 2008 res/layout/meteo_podg_form.xml
sm 2076 Thu Feb 28 18:33:46 CET 2008 res/layout/o_avtope_form.xml
sm 2944 Thu Feb 28 18:33:46 CET 2008 res/layout/pomow_form.xml
sm 952 Thu Feb 28 18:33:46 CET 2008 res/layout/promt.xml
sm 13296 Thu Feb 28 18:33:46 CET 2008 resources.arsc

s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

• Signed by “EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US”
  Digest algorithm: SHA1
  Signature algorithm: SHA1withRSA, 2048-bit key

jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2035-07-17) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

 

About the RC4/encryption key:

By decompiling and manually “refactoring” the encryption algorithm, we discovered a “textbook” RC4 implementation as the encryption routine, which uses the hard-coded key as a first-part to the encryption key, with the second-part coming as a parameter from the function call:

Analyzing the XAgent linux sample, which also contained this RC4 key, we did not found an RC4 implementation, but a simple XOR based encryption routine:

We found one function call, which used the encryption key from the APK as input, but surprisingly, it was not used as key parameter, but input parameter.

For checking HTTP GET and POST messages a different XOR based check routine can be found, and a Base64-like encoding. After decoding, the XOR based routine checks the http result’s body. It xors the 4-11 bytes with the first 4 bytes as a key. It then should be equal to a hardcoded value (7 bytes) which the sample uses to check whether the recv succeeded or not.

These XAgent linux samples are very similar to a Windows version that has been found in november, 2013 (5f6b2a0d1d966fc4f1ed292b46240767f4acb06c13512b0061b434ae2a692fa1).

Recommended yara for the linux versions:
rule sofacy_xagent {
meta:
author = "AKG"
description = "Sofacy - XAgent"
strings:
service = "ksysdefd"x1 = "AgentKernel"
x2 = "Cryptor"x3 = "AgentModule"
x4 = "ChannelController"x5 = "RemoteKeylogger"
a1 = "UNCORRECT DISPLAY NAME"a2 = "Keylogger started"
a3 = "Keylog thread exit"a4 = "Keylogger yet started"
condition:
service or (2 of (x)) or (2 of ($a))
}

Background

Recently, Crowdstrike has published details about a malicious Android APK file, named poprd30.apk or Попр-Д30.apk. It seems that the malware was created by the Fancy Bear group for tracking Ukrainian field artillery units (more info on this can be found here: https://www.crowdstrike.com/wp-content/brochures/FancyBearTracksUkrainianArtillery.pdf). The corresponding APK is identified by the MD5 hash 6f7523d3019fa190499f327211e01fcb on a related blog site https://www.crowdstrike.com/blog/danger-close-fancy-bear-tracking-ukrainian-field-artillery-units/. However, not much technical details have been given by CrowdStrike on the attack. During discussions on the topic, Jeffrey Carr initiated discussions with us and has sent some questions on if the case is real and how exactly the attack works, in particular, how the malware could have been used in military conflicts.

We carried out only a short investigation on the topic. Our goal was to uncover more technical details about the attack and to confirm the existence of the backdoor in the particular APK file.

Highlights

• We can confirm that the APK file known by the MD5 hash 6f7523d3019fa190499f327211e01fcb contains a backdoor that tries to communicate with a remote server.
• The server IP in the sample is http://69.90.132[.]215/
• The malicious APK does not use GPS to get exact location of the infected phone, it does not even ask for GPS-level position information.
• We note, however, that some location information can be collected by the malicious APK, mainly related to the actual base station used by the phone and the WiFi status.
• The implant in the malicious APK has similarities to the X-Agent implants of the Fancy Bear / APT28 / Sofacy group described in former reports, but this is not necessarily  an evidence on the relationship as such similarities can be faked.
• We uncovered two interesting items: the malware authors put the German word “nichts” as a string in the code, as well, they made a typo “phone standart.”

Details

In February 2015, Trend Micro posted details about an iOS espionage app possibly related to the Pawn Storm  / Sofacy / APT28 / Fancy Bear group. The technical details can be found at http://blog.trendmicro.com/trendlabs-security-intelligence/pawn-storm-update-ios-espionage-app-found/. Figure 5 of the Trend Micro document shows possible URL GET parameters used by the malicious code:

In the poprd30.apk code very similar items can be found related to the malicious communications:

By looking into BuildConfig it seems that one recompiled this APK modified Androdi Debug Key.

As one can see, strings in the APK file are very similar to those in the X-Agent implant, and have the same common goal: make the HTTP request similar to normal HTTP GET requests with common parameters. However, this similarity alone is not enough to state that the authors are the same, because it is very easy to copy this scheme.

Also, observe the initial value for the SERVER_ANSWER variable. It is “nichts,” which means “nothing” in German. We don’t know why a german word was used here. Note that this value is not used in the code, it stands only as a default value. That means, if no value is received from the server, then the corresponding function will return this value instead of the information received from the server. In the RegG.java file, which has the similar SERVER_ANSWER value it is set to ‘{ “no_jobs”, “or”, “error” };’ for default value. Setting a default value generally helps developers to find out if the data transmission was successful in the parts of the code not close to the transmission itself. One can simply check if the answer is still the default value, and if it is, it can be sure that the transmission was not successfull without complicated routines. However, in this APK we found no reference for checking if the SERVER_ANSWER has not been changed, and we don’t have clear idea why these two default values were used in the code.

Commands

Communication routines are spread across multiple classes: DataConstructor, DataExtractor, Reg, RegG, RegP, RegPBin. The main handling of the commands is in MainService. It is not entirely clear why there are multiple copies of some data and routines.

The malware sends basic info about the phone to the attacker as shown below:

byte[] arrayOfByte = Base64.encode((“<pre><font size=4 color=green><br>CMD 101 success</font>” + “<font size=4 color=blue><br>GoogleAccounts: ” + str1 + “<br>Device ID: ” + str2 + “<br>Model: ” + Build.MODEL + “<br>Manufacturer: ” + Build.MANUFACTURER + “<br>Phone standart: ” + str4 + “<br>Country: ” + str5 + “<br>MCC & MNC: ” + str6 + “<br>Base station: ” + str3 + “<br>Android version: ” + str7 + “<br>Android SDK: ” + m + “</font></pre>”).getBytes(), 0);

The malware can receive the following commands:

• Commands 103 105 108: stop itself
• Command 100 : Send SMS History /commands are self-explanatory/
• Command 101: Collect “all” information about the phone and send
• Command 102: GetCallDetails (Call history)
• Command 104: FetchContacts
• Command 106: GetAppList
• Command 107: GetWifiStatus (is any WiFi network available, what identifier, what MAC address, speed, etc.)
• Command 109: Browser history and bookmarks
• Command 110: Mobile data usage
• Command 111: Folders and files from sdcard directory
• Command 112: File download (SDcard) for command
• Command 101 – Gets GSM network LAC, CID info or base station info (coordinates) if CDMA, andorid version, google accounts, device id, etc.

Command 101 has a typo “phone standart” which should be “standard” both in English and German.

 

For command 101, it is important to note that it can provide location related information. In case of GSM , the base station related information can provide some (not so accurate) location information. Similarly, in case of CDMA, base station information is related to location, but it is not accurate either. In addition to the base station, WiFi information can also help an adversary to find out the approximate location of the phone, but it is nowhere close to accurate detection of the real location of the phone.

We have not seen any GPS related commands in the code, not even the original “D30 guidance” functionality. Most likely, the APK does not use GPS data. To be even more precise, the application Manifest information does not contain any requests related to GPS level locality permissions; it asks for  ACCESS_COARSE_LOCATION only, which relates to the base station/WiFi based location information.

 

Encryption – RC4

The malware uses communications encrypted by RC4, encoded by Base64 (or very similar – we did not check it carefully), and CRC for error checking. These are very common, but the most important thing is the RC4 implementation and the key in use, which can be proved to be similar to the older X-Agent implants.

The corresponding RC4 key is also visible in the java byte code format:

In hex, the encryption key is 3B C6 73 0F 8B 07 85 c0 74 02 FF CC DE C7 04 FE 72 F1 5F 5E C3 56 B8 D8 78 75 50 E8 B1 D1 FA 59 5D 55 EC 83 10 A1 33 35

Note: Rc4 keys can be arbitrary length, and implementation is very easy, hence it is used many times.On the other hand, RC4 is not secure enough for real crypto operations.

Conclusions

In our investigations, we tried to check if the APK indicated in the CrowdStrike report had backdooor connectivity. We can confirm, that this APK file has malicious functionality and can be used to collect intelligence from the users of the applet. Some additional technical details were discusssed. We (and probably CrowdStrike, too) had no access to the original, unmodified APK file.

UPDATE1

Some linux X-Agent versions used exactly the same RC4 key, see this screenshot:

 

The criminals behind the malware delivery system for GameOver Zeus have a new trick. Encrypting their EXE file so that as it passes through your firewall, webfilters, network intrusion detection systems and any other defenses you may have in place, it is doing so as a non-executable “.ENC” file. If you are in charge of network security for your Enterprise, you may want to check your logs to see how many .ENC files have been downloaded recently.

Gary Warner wrote a blogpost over it, and shared some files and information with us. The question was, how the .enc file is decoded and used.

The droppers sent out through emails are pretty small, around 10-18 kb. These droppers have an obfuscation layer, so hard to directly analyze them. However, with volatility it was relatively easy with procexedump to extract a small, 5k downloader that actually connects to a server to download the related .enc file, decrypt and decompress it, and execute.

The encrypted files look like this at the beginning:

0000000000: 5A 5A 50 00 E7 31 0E 1E │ 02 17 0E 50 58 87 0E D1 ZZP ç1♫▲☻↨♫PX┼♫Ń
0000000010: 5C 87 3E AC A7 87 0E EB │ 58 BF 23 52 58 C7 0A 6B \┼>¬§┼♫ëXż#RXÇ◙k
0000000020: 41 87 E6 53 54 89 11 53 │ E2 89 0E E7 51 4A 2F EB A┼ćST%◄Sâ%♫çQJ/ë
0000000030: 58 86 42 9E 79 D3 66 3A │ 2B 87 2E 23 2A E8 69 21 X┼BžyÓf:+┼.#*či!
0000000040: 39 EA 0E 73 3B E6 60 3D │ 37 F3 2E 53 3A E2 2E 21 9ę♫s;ć`=7ó.S:â.!

ZZP\0 is a magic string, then a compressed and encrypted part is stored (here: 0xE7 0x31…)

After downloading the .enc file the dropper checks the magic:

.text:00971450 cmp byte ptr [esi], 5Ah
.text:00971453 jnz short loc_9714D2
.text:00971455 cmp byte ptr [esi+1], 5Ah
.text:00971459 jnz short loc_9714D2
.text:0097145B cmp byte ptr [esi+2], 50h
.text:0097145F jnz short loc_9714D2
.text:00971461 cmp [esi+3], bl
.text:00971464 jnz short loc_9714D2
.text:00971466 shl eax, 2
.text:00971469 push eax ; dwBytes
.text:0097146A push 8 ; dwFlags

… and does the decryption….
.text:0097149C loc_97149C: ; CODE XREF: start+455j
.text:0097149C xor [esi+ecx*4], eax
.text:0097149F mov edi, [ebp+78h+Buffer]
.text:009714A2 inc ecx
.text:009714A3 shr edi, 2
.text:009714A6 cmp ecx, edi
.text:009714A8 jb short loc_97149C


eax stores the encryption key, which is 32 bits long.
The executable stores its configuration in a compressed form, but in cleartext.

0000001000: 85 B0 00 64 63 6D 73 73 │ 65 72 76 00 69 63 65 73 •° dcmsserv ices
0000001010: 2E 63 6F 6D 02 00 0C 00 │ 2F 69 6D 61 67 65 80 73 .com☻ ♀ /image?s
0000001020: 2F 73 74 6F 72 69 01 1C │ 08 6C 69 64 00 18 70 64 /stori☺∟◘lid ↑pd
0000001030: 66 2E 18 65 6E 63 0D B4 │ 0F 00 B8 37 B8 0A 1E 01 f.↑enc♪´☼ ¸7¸◙▲☺
0000001040: 0E 02 00 06 65 6C 65 63 │ 00 74 72 69 63 69 61 6E ♫☻ ♠elec trician
0000001050: 73 00 64 75 62 6C 69 6E │ 69 72 20 65 6C 61 6E 64 s dublinir eland
0000001060: 04 78 2F 77 00 70 2D 63 │ 6F 6E 74 65 6E 00 74 2F ♦x/w p-conten t/
0000001070: 75 70 6C 6F 61 64 00 73 │ 2F 32 30 31 34 2F 30 16 upload s/2014/0▬
0000001080: 31 22 70 02 6B 01 03 6B │ 00 00 00 00 00 00 00 00 1"p☻k☺♥k

The compression here is RtlDecompressBuffer standard windows call.

rtldecompressbuffer_dword_972000 = (int (__stdcall *)(_DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD))GetProcAddress(v9, "RtlDecompressBuffer");

It is called like this:
rtldecompressbuffer_dword_972000(0x102u, v11, 1024, &unk_974000, 256, &v36);

0x102 stands for: 0x100 for max compression level, 0x02 for LZNT1 compression algorithm.

If you don’t have LZNT1 related code at hand, you might use the tool available at the following address: http://reboot.pro/files/file/121-lznt1-tools-bootmgrntfs/
It does not work for all the samples, but works most of the time.

So decompressed config looks like this:

0000000000: 64 63 6D 73 73 65 72 76 │ 69 63 65 73 2E 63 6F 6D dcmsservices.com
0000000010: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000020: 2F 69 6D 61 67 65 73 2F │ 73 74 6F 72 69 65 73 2F /images/stories/
0000000030: 73 6C 69 64 65 73 2F 70 │ 64 66 2E 65 6E 63 00 00 slides/pdf.enc
0000000040: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000050: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000060: B8 37 B8 1E 00 00 00 00 │ 02 00 00 00 65 6C 65 63 ¸7¸▲ ☻ elec
0000000070: 74 72 69 63 69 61 6E 73 │ 64 75 62 6C 69 6E 69 72 triciansdublinir
0000000080: 65 6C 61 6E 64 2E 63 6F │ 6D 00 00 00 2F 77 70 2D eland.com /wp-
0000000090: 63 6F 6E 74 65 6E 74 2F │ 75 70 6C 6F 61 64 73 2F content/uploads/
00000000A0: 32 30 31 34 2F 30 31 2F │ 70 64 66 2E 65 6E 63 00 2014/01/pdf.enc
00000000B0: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
00000000C0: 00 00 00 00 00 00 00 00 │ 00 00 00 00 B8 37 B8 1E ¸7¸▲
00000000D0: 00 01 00 00 02 00 00 00 │ ☺ ☻

The 32-bits xor code used for encryption is stored 0x60 bytes after the beginning of this buffer, that means, for both servers it is 0b8 0x37 0xb8 0x1e.
This should be used cyclically on the .enc file to get the compressed file , which again is compressed with RTLCompressBuffer call.

So how to make a universal decoder for .enc files?

Let’s check this one:

0000000000: 5A 5A 50 00 5F 8D B8 53 │ E2 A7 B8 1D B8 37 B8 9C ZZP _Ť¸S⧸↔¸7¸ś
0000000010: BC 37 88 E1 47 37 B8 A6 │ B8 0F 95 1F B8 77 BC 26 Ľ7?áG7¸|¸☼•▼¸wĽ&
0000000020: A1 37 60 1E B4 39 A7 1E │ 02 39 B8 AA B1 FA 99 A6 ˇ7`▲´9§▲☻9¸Ş+út|
0000000030: B8 36 F4 D3 99 63 D0 77 │ CB 37 98 6E CA 58 DF 6C ¸6ôÓtcĐwË7?nĘXßl

I’m cheating and telling you that it will be decrypted to

0000000000: E7 BA 00 4D 5A 90 00 03 │ 00 00 00 82 04 00 30 FF çş MZ? ♥ '♦ 0˙
0000000010: FF 00 00 B8 00 38 2D 01 │ 00 40 04 38 19 00 D8 00 ˙ ¸ 8-☺ @♦8↓ Ř
0000000020: 0C 0E 1F 00 BA 0E 00 B4 │ 09 CD 21 B8 00 01 4C CD ♀♫▼ ş♫ ´○Í!¸ ☺LÍ

Where B8->00 53->4D E2->5A A7->90 is the transformation.
4D 5A is the standard PE header, and for all the .enc files, the next byte was 0x90. Before the MZ header, the compression magic always contains a 0x00 byte. So we have 4 fixed bytes. Hence let’s calculate the key:

1st byte: 0xB8 xor 0x00 = 0xb8
2nd byte: 0x53 xor 0x4D = 0x1E
3rd byte: 0xE2 xor 0x5A = 0xb8
4th byte: 0xA7 xor 0x90 = 0x37

Remember the config file? The key was B8 37 B8 1E, this is just a rotated version of it with 2 bytes shift as you know, the magic starts with two additional bytes.

So as these bytes are currerntly constants, it’s evident to create a generic decryptor too for the .enc files, that works without the hard coded key, only with the .enc files. After decrypting, of course, you have to run RTLDecompressBuffer to get the actual executable.
Note, there is another small encryption routine in the 5k dropper, we did not fully investigate what it codes:

.text:00971000 encrypt_sub_971000 proc near ; CODE XREF: start+4AFp
.text:00971000
.text:00971000 arg_0 = dword ptr 4
.text:00971000 arg_4 = byte ptr 8
.text:00971000 arg_8 = dword ptr 0Ch
.text:00971000
.text:00971000 mov ecx, [esp+arg_8]
.text:00971004 test ecx, ecx
.text:00971006 jz short loc_971029
.text:00971008 movzx eax, [esp+arg_4]
.text:0097100D imul eax, 1010101h
.text:00971013 mov edx, ecx
.text:00971015 push ebx
.text:00971016 push edi
.text:00971017 mov edi, [esp+8+arg_0]
.text:0097101B shr ecx, 2
.text:0097101E rep stosd
.text:00971020 mov ecx, edx
.text:00971022 and ecx, 3
.text:00971025 rep stosb
.text:00971027 pop edi
.text:00971028 pop ebx
.text:00971029
.text:00971029 loc_971029: ; CODE XREF: encrypt_sub_971000+6j
.text:00971029 mov eax, [esp+arg_0]
.text:0097102D retn
.text:0097102D encrypt_sub_971000 endp

(copied from cef76fa7b4b30f76c7b6d2eefa30d944 sample)