Introducing WhiteBear

As a part of our Kaspersky APT Intelligence Reporting subscription, customers received an update in mid-February 2017 on some interesting APT activity that we called WhiteBear. Much of the contents of that report are reproduced here. WhiteBear is a parallel project or second stage of the Skipper Turla cluster of activity documented in another private intelligence report “Skipper Turla – the White Atlas framework” from mid-2016. Like previous Turla activity, WhiteBear leverages compromised websites and hijacked satellite connections for command and control (C2) infrastructure. As a matter of fact, WhiteBear infrastructure has overlap with other Turla campaigns, like those deploying Kopiluwak, as documented in “KopiLuwak – A New JavaScript Payload from Turla” in December 2016. WhiteBear infected systems maintained a dropper (which was typically signed) as well as a complex malicious platform which was always preceded by WhiteAtlas module deployment attempts. However, despite the similarities to previous Turla campaigns, we believe that WhiteBear is a distinct project with a separate focus. We note that this observation of delineated target focus, tooling, and project context is an interesting one that also can be repeated across broadly labeled Turla and Sofacy activity.

From February to September 2016, WhiteBear activity was narrowly focused on embassies and consular operations around the world. All of these early WhiteBear targets were related to embassies and diplomatic/foreign affair organizations. Continued WhiteBear activity later shifted to include defense-related organizations into June 2017. When compared to WhiteAtlas infections, WhiteBear deployments are relatively rare and represent a departure from the broader Skipper Turla target set. Additionally, a comparison of the WhiteAtlas framework to WhiteBear components indicates that the malware is the product of separate development efforts. WhiteBear infections appear to be preceded by a condensed spearphishing dropper, lack Firefox extension installer payloads, and contain several new components signed with a new code signing digital certificate, unlike WhiteAtlas incidents and modules.

The exact delivery vector for WhiteBear components is unknown to us, although we have very strong suspicion the group spearphished targets with malicious pdf files. The decoy pdf document above was likely stolen from a target or partner. And, although WhiteBear components have been consistently identified on a subset of systems previously targeted with the WhiteAtlas framework, and maintain components within the same filepaths and can maintain identical filenames, we were unable to firmly tie delivery to any specific WhiteAtlas component. WhiteBear focused on various embassies and diplomatic entities around the world in early 2016 – tellingly, attempts were made to drop and display decoy pdf’s with full diplomatic headers and content alongside executable droppers on target systems.

Technical Details

The WhiteBear platform implements an elaborate set of messaging and injection components to support full presence on victim hosts. A diagram helps to visualize the reach of injected components on the system.

The WhiteBear binary loader maintains several features including two injection methods for its (oddly named) “KernelInjector” subsystem, also named by its developer– Standart– WindowInject (includes an unusual technique for remotely placing code into memory for subsequent thread execution)

Loader runtime flow

The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes if it is already present while logging the message “IsLoaderAlreadyWork +”. The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes. If it is already present while logging the message “IsLoaderAlreadyWork +”, it extracts the resource BINARY 201. This resource contains a wide string name of processes to inject into (i.e. “explorer.exe”).

Where the “%x” parameter is replaced with the values 0xFFFFFFFF 0xEEEEEEEE 0xDDDDDDDD, or if it has successfully obtained the user’s SID:
\.pipeWinsock2CatalogChangeListener-%02x%02x-%01x
With “%x” parameters replaced with numbers calculated from the current date and a munged user SID.

The pipe is used to communicate with the target process and the transport module; the running code also reads its own image body and writes it to the pipe. The loader then obtains the payload body from resource BINARY 202. It finds the running process that matches the target name, copies the buffer containing the payload into the process, then starts its copy in the target process.

WhiteBear Main module/orchestrator

The main module has no exports, only a DllMain entry which spawns one thread and returns. The main module maintains multiple BINARY resources that include executable, configurations, and encryption data:

Values 104 – 111 are encrypted with the RSA private key (resource 101) and compressed with bzip2.4. The RSA key is stored with header stripped in a format similar to Microsoft’s PVK; the RSA PRIVATE KEY header is appended by the loader before reading the keys into the encryption code. Resource 109 points to a registry location called “external storage”, built-in resources are called “PE Storage”.

In addition to storing code, crypto resources, and configuration data in PE resources, WhiteBear copies much of this data to the victim host’s registry. Registry storage is located in the following keys. Subkeys and stored values listed below:
[HKCUSOFTWAREMicrosoftWindowsCurrentVersionExplorerScreenSaver]
[HKCUSOFTWAREMicrosoftWindows NTCurrentVersionExplorerScreenSaver]

Finally, if the main WhiteBear module fails to use registry storage, it uses “FS Storage” in file %TEMP%KB943729.log. The module reads all of its data and binary components from one of the storages and then verifies the integrity of data (RSA+bzip2 compression+signature).

The module maintains functionality which is divided into a set of subsystems that are loosely named by the developers:
• result queue
• task queue
• message processing system
• autorun manager
• execution subsystem
• inject manager
• PEStorage
• local transport manager/internal transport channel

It creates the following temporary files:
%TEMP%CVRG72B5.tmp.cvr
%TEMP%CVRG1A6B.tmp.cvr
%TEMP%CVRG38D9.tmp.cvr

%TEMP%~DF1E05.tmp contains the updated body of the loader during an update.

Every day (as specified by local time) the main module restarts the transport subsystem which includes:
• message processing
• named pipe transport (“NPTransport”)

If the registry/file storage is empty, the module performs a ‘migration’ of hardcoded modules and settings to the storage location. This data is encrypted with a new RSA key (which is also stored in the registry).

The data in the registry is prepended with a 0xC byte header. The maximum size of each registry item is 921,600 bytes; if the maximum size is exceeded, it is split into several items. The format of the header is shown below:
[4:service DWORD][4:chunk index][4:chunk size including header]

Every time the orchestrator module is loaded it validates that the storage area contains the appropriate data and that all of the components can be decrypted and validated. If these checks fail the module reinstalls a configuration from the resource “REINSTALL”.

Pipe Transport

The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. Every packet is expected to be at least 6 bytes and contain the following header: [4:ID][2:command]

The “LocalTransport manager” handles named pipe communication and identifies if the packet received is designated to the current instance or to someone else (down the route). In the latter scenario the LocalTansport manager re-encrypts the packet, serializes it (again), and pushes the packet via a named pipe on the local network to another hop, (NullSessionPipes). This effectively makes each infected node a packet router.

The Autorun manager subsystem is responsible for tracking the way that the malicious module starts in the system and it maintains several different methods for starting automatically (shown below):LinkAutorun The subsystem searches for a LNK file in the target directory, changes the path to “cmd.exe” and the description to ‘ /q /c start “” “%s” && start “” “%s” ‘TaskScheduler20Autorun The subsystem creates the ITaskService (works only on Windows Vista+) and uses the ITaskService interface to create a new task with a logon triggerStartupAutorun The subsystem creates a LNK file in %STARTUP%ScreenSaverAutorun The subsystem installs as a current screensaver with a hidden windowHiddenTaskAutorun The subsystem creates the task ITaskScheduler (works only on pre-Vista NT). The task trigger start date is set to the creation date of the Windows directoryShellAutorun Winlogon registry [HKCUSoftwareMicrosoftWindows NTCurrentVersionWinlogon] Shell=”explorer.exe, …”

File Uninstallation is done in a discreet manner. The file is filled with zeroes, then renamed to a temporary filename before being deleted

This transport library does not appear on disk in its PE format. It is maintained as encrypted resource 107 in the orchestrator module, then decrypted and loaded by the orchestrator directly into the memory of the target process. This C2 interaction module is independent, once started, it interacts with the orchestrator using its local named pipe.

To communicate with its C2 server, the transport library uses the system user agent or default “Mozilla/4.0 (compatible; MSIE 6.0)”.

Before attempting a connection with its configured C2 server, the module checks if the victim system is connected to Internet by sending HTTP 1.1 GET / requests to the following servers (this process stops after the first successful connection):
• update.microsoft.com
• microsoft.com
• windowsupdate.microsoft.com
• yahoo.com
• google.com

If there is no Internet connection available, the module changes state to, “CANNOT_WORK” and notifies the peer by sending command “7” over the local pipe.

The C2 configuration is obtained from the main module with the command “5”. This checks whether the module complies with the schedule specified in the C2 settings (which includes inactivity time and the interval between connections). The C2 interaction stages have interesting function names and an odd misspelling, indicating that the developer may not be a native English speaker (or may have learned the English language in a British setting):
“InternetRelations::GetInetConnectToGazer”
“InternetRelations::ReceiveMessageFromCentre”
“InternetRelations::SendMessageToCentre”
“PipeRelations::CommunicationTpansportPipe”

The module writes the encrypted log to %TEMP%CVRG38D9.tmp.cvr The module sends a HTTP 1.0 GET request through a randomly generated path to the C2 server. The server’s reply is expected to have its MD5 checksum appended to the packet. If C2 interaction fails, the module sends the command “10” (“NO_CONNECT_TO_GAYZER”) to the orchestrator.

Unusual WhiteBear Encryption

The encryption implemented in the WhiteBear orchestrator is particularly interesting. We note that the resource section is encrypted/decrypted and packed/decompressed with RSA+3DES+BZIP2. This implementation is unique and includes the format of the private key as stored in the resource section. 3DES is present in Sofacy and Duqu2 components, however they are missing in this Microsoft-centric RSA encryption technique. The private key format used in this schema and RSA crypto combination with 3DES is (currently) unique to this threat actor.

The private key itself is stored as a raw binary blob, in a format similar to the one Microsoft code uses in PVK format. This format is not officially documented, but its structures and handling are coded into OpenSSL. This private key value is stored in the orchestrator resources without valid headers. The orchestrator code prepends valid headers and passes the results to OpenSSL functions that parse the blob.

Most WhiteBear samples are signed with a valid code signing certificate issued for “Solid Loop Ltd”, a once-registered British organization. Solid Loop is likely a phony front organization or a defunct organization and actors assumed its identity to abuse the name and trust, in order to attain deceptive code-signing digital certificates.

Targeting and Victims

WhiteBear targets over the course of a couple years are related to government foreign affairs, international organizations, and later, defense organizations. The geolocation of the incidents are below:

Europe

South Asia

Central Asia

East Asia

South America

Conclusions

WhiteBear activity reliant on this toolset seems to have diminished in June 2017. But Turla efforts continue to be run as multiple subgroups and campaigns. This one started targeting diplomatic entities and later included defense related organizations. Infrastructure overlap with other Turla campaigns, code artifacts, and targeting are consistent with past Turla efforts. With this subset of 2016-2017 WhiteBear activity, Turla continues to be one of the most prolific, longstanding, and advanced APT we have researched, and continues to be the subject of much of our research. Links to publicly reported research are below.

I agree to provide my email address to “AO Kaspersky Lab” to receive information about new posts on the site. I understand that I can withdraw this consent at any time via e-mail by clicking the “unsubscribe” link that I find at the bottom of any e-mail sent to me for the purposes mentioned above.