Category Archives: backdoor

STOMP 2 DIS: Brilliance in the (Visual) Basics

Throughout January 2020, FireEye has continued to observe multiple targeted phishing campaigns designed to download and deploy a backdoor we track as MINEBRIDGE. The campaigns primarily targeted financial services organizations in the United States, though targeting is likely more widespread than those we’ve initially observed in our FireEye product telemetry. At least one campaign targeted South Korean organizations, including a marketing agency.

In these campaigns, the phishing documents appeared to be carefully crafted and leveraged some publicly-documented — but in our experience uncommon and misunderstood — TTPs, likely in an effort to decrease detection of the malicious documents’ macros. The actor also used a self-hosted email marketing solution across multiple campaigns. Notably, the payload delivered in these campaigns leveraged a packer previously affiliated with a commonly-tracked threat actor, an overlap that we will explore later.

This blog post will review the theme of these campaigns and their targets, the adversary’s unique tradecraft, the MINEBRIDGE C++ backdoor, some potential attribution overlaps, and importantly — the threat actor’s love of rap music.

Targeting and Lure Detail

While we first identified MINEBRIDGE samples in December, we observed our first phishing campaigns relating to this activity in early January 2020. Email addresses used to send phishing messages were associated with domains that appear to have been registered specifically for this purpose within a few weeks of the activity — and were thematically consistent with the content of the phishing messages.

Additionally, the actor(s) responsible are likely using a self-hosted email marketing solution called Acelle. Acelle adds extended email headers to messages sent via the platform in the format of X-Acelle-<variable>. The messages observed across campaigns using these TTPs have included a “Customer-Id” value matching “X-Acelle-Customer-Id: 5df38b8fd5b58”. While that field remained consistent across all observed campaigns, individual campaigns also shared overlapping “X-Acelle-Sending-Server_Id” and “X-Acelle-Campaign-Id” values. All of the messages also included a “List-Unsubscribe” header offering a link hosted at 45.153.184.84 suggesting that it is the server hosting the Acelle instance used across these campaigns. The sample table for one campaign below illustrates this data:

Timestamp

Sender

Subject

x-acelle-subscriber-id

x-acelle-sending-server-id

x-acelle-customer-id

x-acelle-campaign-id

1/7/20 16:15

info@rogervecpa.com

tax return file

25474792e6f8c

5e14a2664ffb4

5df38b8fd5b58

5e14a2664ffb4

1/7/20 15:59

info@rogervecpa.com

tax return file

22e183805a051

5e14a2664ffb4

5df38b8fd5b58

5e14a2664ffb4

1/7/20

info@rogervecpa.com

tax return file

657e1a485ed77

5e14a2664ffb4

5df38b8fd5b58

5e14a2664ffb4

1/7/20 16:05

info@rogervecpa.com

tax return file

ddbbffbcb5c6c

5e14a2664ffb4

5df38b8fd5b58

5e14a2664ffb4

The URLs requested by the malicious documents and serving the final MINEBRIDGE payloads delivered in each of these campaigns provide additional overlap across campaigns. In all observed cases, the domains used the same bullet-proof hosting service. The URI used to download the final payload was “/team/invest.php” or, in one case, “/team/rumba.php”. Perhaps the most fun overlap, however, was discovered when trying to identify additional artifacts of interest hosted at similar locations. In most cases a GET request to the parent directory of “/team/” on each of the identified domains served up the lyrics to rap group Onyx’s “Bang 2 Dis” masterpiece. We will refrain from sharing the specific verse hosted due to explicit content.

One of the more notable characteristics of this activity was the consistency in themes used for domain registration, lure content, similarities in malicious document macro content, and targeting. Since first seeing these emails, we’ve identified at least 3 distinct campaigns.

Campaign #1: January 7, 2020 – Tax Theme
  • Emails associated with this campaign used the CPA themed domain rogervecpa.com registered in late November and the subject line “Tax Return File” with IRS related text in the message body.
  • The attached payload was crafted to look like an H&R Block related tax form.
  • Observed targeting included the financial sector exclusively.

Campaign #2: January 8, 2020 – Marketing Theme
  • Emails associated with this campaign used the same CPA themed domain rogervecpa.com along with pt-cpaaccountant.com, also registered late November.
  • The subject line and message body offered a marketing partnership opportunity to the victim.
  • The attached payload used a generic theme enticing users to enable macro content.
  • Observed targeting focused on a South Korean marketing agency.

Campaign #3: January 28, 2020 – Recruiting Theme
  • Emails associated with this campaign were sent from several different email addresses, though all used the recruiting-themed domain agent4career.com which was registered on January 20, 2020.
  • The subject line and message body referenced an employment candidate with experience in the financial sector.
  • The attached payload masqueraded as the resume of the same financial services candidate referenced in the phishing email.
  • Observed targeting included the financial sector exclusively.

Quit Stepping All Over My Macros

The phishing documents themselves leverage numerous interesting TTPs including hiding macros from the Office GUI, and VBA stomping.

VBA stomping is a colloquial term applied to the manipulation of Office documents where the source code of a macro is made to mismatch the pseudo-code (hereto referred to as "p-code") of the document. In order to avoid duplicating research and wasting the reader’s time, we will instead reference the impressive work of our predecessors and peers in the industry. As an introduction to the concept, we first recommend reading the tool release blog post for EvilClippy from Outflank. The security team at Walmart has also published incredible research on the methodology. Vesselin Bontchev provides a useful open source utility for dumping the p-code from an Office document in pcodedmp. This tool can be leveraged to inspect the p-code of a document separate from its VBA source. It was adopted by the wider open source analysis toolkit oletools in order to detect the presence of stomping via comparison of p-code mnemonics vs keyword extraction in VBA source.

That is a whole lot of quality reading for those interested. For the sake of brevity, the most important result of VBA stomping as relevant to this blog post is the following:

  • Static analysis tools focusing on VBA macro source extraction may be fooled into a benign assessment of a document bearing malicious p-code.
  • When VBA source is removed, and a document is opened in a version of Office for which the p-code was not compiled to execute, a macro will not execute correctly, resulting in potential failed dynamic analysis.
  • When a document is opened under a version of Office that uses a VBA version that does not match the version of Office used to create the document, VBA source code is recompiled back into p-code.
  • When a document is opened in Office and the GUI is used to view the macro, the embedded p-code is decompiled to be viewed.

The final two points identify some interesting complications in regard to leveraging this methodology more broadly. Versioning complexities arise that toolkits like EvilClippy leverage Office version enumeration features to address. An actor’s VBA stomped document containing benign VBA source but evil p-code must know the version of Office to build the p-code for, or their sample will not detonate properly. Additionally, if an actor sends a stomped document, and a user or researcher opens the macro in the Office editor, they will see malicious code.

Our actor addressed the latter point of this complication by leveraging what we assess to be another feature of the EvilClippy utility, wherein viewing the macro source is made inaccessible to a user within Office by modifying the PROJECT stream of the document. Let’s highlight this below using a publicly available sample we attribute to our actors (SHA256: 18698c5a6ff96d21e7ca634a608f01a414ef6fbbd7c1b3bf0f2085c85374516e):

Document PROJECT stream:

ID="{33C06E73-23C4-4174-9F9A-BA0E40E57E3F}"
Document=ThisDocument/&H00000000
Name="Project"
HelpContextID="0"
VersionCompatible32="393222000"
CMG="A3A1799F59A359A359A359A3"
DPB="87855DBBA57B887C887C88"
GC="6B69B1A794A894A86B"
[Host Extender Info]
&H00000001={3832D640-CF90-11CF-8E43-00A0C911005A};VBE;&H00000000
[Workspace]
ThisDocument=0, 0, 0, 0, C
Module1=26, 26, 388, 131, Z

The above PROJECT stream has been modified. Within the PROJECT stream workspace, a module is referenced. However, there is no module defined. We would expect the unmodified PROJECT stream of this document prior to utilization of a tool to modify it to be as follows:

ID="{33C06E73-23C4-4174-9F9A-BA0E40E57E3F}"
Document=ThisDocument/&H00000000
Module=”Module1”
Name="Project"
HelpContextID="0"
VersionCompatible32="393222000"
CMG="A3A1799F59A359A359A359A3"
DPB="87855DBBA57B887C887C88"
GC="6B69B1A794A894A86B"
[Host Extender Info]
&H00000001={3832D640-CF90-11CF-8E43-00A0C911005A};VBE;&H00000000
[Workspace]
ThisDocument=0, 0, 0, 0, C
Module1=26, 26, 388, 131, Z

It is interesting to note that we initially identified this actor only performing this manipulation on their malicious documents—avoiding any versioning complexities--without actually stomping the p-code to mismatch the VBA source. This seems like an odd decision and is possibly indicative of an actor assessing what “works” for their campaigns. The above malicious document is an example of them leveraging both methodologies, as highlighted by this screenshot from the awesome publicly available web service IRIS-H Digital Forensics:

We can see that the documents VBA source is a blank Sub procedure definition. A quick glance at the p-code identifies both network- based indicators and host- based indicators we can use to determine what this sample would do when executed on the proper Office version. When we attempt to open the macro in the GUI editor, Office gets angry:

For analysts looking to identify this methodology holistically, we recommend the following considerations:

  • The GUI hiding functionality results in an altered project stream wherein a module exists, but there is no module, class, or baseclass defined in the stream. This is a potential static detection.
  • While the macro source is no longer present, there are still static strings present in Module1 in this sample which may indicate Windows APIs leveraged. This is a potential static detection.

  • Utilities like the previously mentioned oletools can do all of this detection for you. If you identify false negatives, false positives, or bugs, the open source project maintainers respond to them regularly like the superheroes that they are:

The above methodology creates questions regarding potential efficiency problems for scaling any sizable campaign using it. While tools like EvilClippy provide the means to create difficult to detect malicious documents that can potentially sneak past some dynamic and static detections, their payloads have the additional burden of needing to fingerprint targets to enable successful execution. While actors with sufficient resources and creativity can no doubt account for these requirements, it is relevant to note that detections for these methodologies will likely yield more targeted activity. In fact, tertiary review of samples employing these techniques identified unrelated activity delivering both Cobalt Strike BEACON and POSHC2 payloads.

We recently expanded our internal FireEye threat behavior tree to accommodate these techniques. At the time of publication, the authors were unable to directly map the methods – PROJECT stream manipulation and VBA stomping – to existing techniques in the MITRE ATT&CK Matrix™ for Enterprise. However, our team submitted these as contributions to the ATT&CK knowledge base prior to publication and will make additional data available for ATT&CK Sightings.

Crossing The Bridge of Khazad-dûm: The MINEBRIDGE Infection Chain

Successful detonation of the previously detailed malicious document results in creation of “uCWOncHvBb.dll” via a call to URLDownloadToFileA to the URL hxxps://marendoger[.]com/team/rumba.php. The returned MINEDOOR packed MINEBRIDGE sample is saved in the executing users AppData directory (Eg: C:\Users\username\AppData\Roaming\uCWOncHvBb.dll), and then subsequent execution of the DllRegisterServer export via invocation of “regsvr32.exe /s %AppData%\uCWOncHvBb.dll” occurs:

This will result in a ZIP file being retrieved from the URL hxxps://creatorz123[.]top/~files_tv/~all_files_m.bin using the Windows API URLDownloadToFileW. The ZIP file is written to %TEMP%, unzipped to the newly created directory %AppData%\Windows Media Player, and then deleted:

The ZIP file contains legitimate files required to execute a copy of TeamViewer, listed in the file creation area of the IOC section of this post. When a file named TeamViewer.exe is identified while unzipping, it is renamed to wpvnetwks.exe:

After completing these tasks, uCWOncHvBb.dll moves itself to %AppData%\Windows Media Player\msi.dll. The phishing macro then closes the handle to msi.dll, and calls CreateProcessA on wpvnetwks.exe, which results in the renamed TeamViewer instance side-loading the malicious msi.dll located alongside it. The malware ensures its persistence through reboot by creating a link file at %CISDL_STARTUP%\Windows WMI.lnk, which points to %AppData%\Windows Media Player\wpnetwks.exe, resulting in its launch at user logon.

The end result is a legitimate, though outdated (version 11, compiled on September 17, 2018, at 10:30:12 UTC), TeamViewer instance hijacked by a malicious sideloaded DLL (MINEBRIDGE).

MINEBRIDGE is a 32-bit C++ backdoor designed to be loaded by an older, unpatched instance of the legitimate remote desktop software TeamViewer by DLL load-order hijacking. The backdoor hooks Windows APIs to prevent the victim from seeing the TeamViewer application. By default, MINEBRIDGE conducts command and control (C2) communication via HTTPS POST requests to hard-coded C2 domains. The POST requests contain a GUID derived from the system’s volume serial number, a TeamViewer unique id and password, username, computer name, operating system version, and beacon interval. MINEBRIDGE can also communicate with a C2 server by sending TeamViewer chat messages using a custom window procedure hook. Collectively, the two C2 methods support commands for downloading and executing payloads, downloading arbitrary files, self-deletion and updating, process listing, shutting down and rebooting the system, executing arbitrary shell commands, process elevation, turning on/off TeamViewer's microphone, and gathering system UAC information.

MINEBRIDGE’s default method of communication is sending HTTPS POST requests over TCP port 443. This method of communication is always active; however, the beacon-interval time may be changed via a command. Before sending any C2 beacons, the sample waits to collect the TeamViewer generated unique id (<tv_id>) and password (<tv_pass>) via SetWindowsTextW hooks.

This specific sample continuously sends an HTTP POST request over TCP port 443 with the URI ~f83g7bfiunwjsd1/g4t3_indata.php to each host listed below until a response is received.

  • 123faster[.]top
  • conversia91[.]top
  • fatoftheland[.]top
  • creatorz123[.]top
  • compilator333[.]top

The POST body contains the formatted string uuid=<guid>&id=<tv_id>&pass=<tv_pass>&username=<user_name>&pcname=<comp_name>&osver=<os_version>&timeout=<beacon_interval> where <guid> is a GUID derived from the system's volume serial number and formatted using the format string %06lX-%04lX-%04lX-%06lX. Additionally, the request uses the hard-coded HTTP User-Agent string "Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_1 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0 Mobile/15B150 Safari/604.1"

After a response is received, it's processed for commands. A single response may contain multiple commands. For each command executed, the sample sends an HTTPS POST request over TCP port 443 indicating success or failure. The sample responds to the commands below.

Command

Description

drun

Download and execute an executable from a URL provided in the command. File saved to %TEMP%\<32_rand_chars>.exe.

rundll_command

Download a custom XOR-encoded and LZNT1 compressed DLL from a URL provided in the command and save to %TEMP%\<32_rand_chars>. Decode, decompress, and load the DLL in memory and call its entrypoint.

update_command

Move sample file to <sample_name>.old and download a new version of itself to <sample_name> where <sample_name> is the name of this sample (i.e., msi.dll). Relaunch the hosting TeamViewer application with command-line argument COM1_. Delete <sample_name>.old.

restart_command

Relaunch the hosting TeamViewer application with command-line argument COM1_.

terminate_command

Terminate the hosting TeamViewer application.

kill_command

Create and execute the self-deleting batch script tvdll.cmd to delete all unzipped files as well as the sample file. Terminate the hosting TeamViewer application.

poweroff_command

Shutdown the system.

reboot_command

Reboot the system.

setinterval_command

Update the C2 beacon-interval time.

After executing all commands in the response, the sample sleeps for the designated C2 beacon-interval time. It repeats the process outlined above to send the next C2 beacon. This behavior repeats indefinitely.

The self-deleting batch script tvdll.cmd contains the following content where <renamed_TeamVeiwer> is the renamed TeamViewer executable (i.e., wpvnetwks.exe) and <sample_name> is the name of this sample (i.e., msi.dll).

@echo off
ping 1.1.1.1 -n 1 -w 5000 > nul
goto nosleep1
:redel1
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep1
attrib -a -h -s -r %~d0%~p0TeamViewer_Resource_en.dll
del /f /q %~d0%~p0TeamViewer_Resource_en.dll
if exist  "%~d0%~p0TeamViewer_Resource_en.dll" goto redel1
goto nosleep2
:redel2
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep2
attrib -a -h -s -r %~d0%~p0TeamViewer_StaticRes.dll
del /f /q %~d0%~p0TeamViewer_StaticRes.dll
if exist  "%~d0%~p0TeamViewer_StaticRes.dll" goto redel2
goto nosleep3
:redel3
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep3
attrib -a -h -s -r %~d0%~p0TeamViewer_Desktop.exe
del /f /q %~d0%~p0TeamViewer_Desktop.exe
if exist  "%~d0%~p0TeamViewer_Desktop.exe" goto redel3
goto nosleep4
:redel4
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep4
attrib -a -h -s -r %~d0%~p0TeamViewer.ini
del /f /q %~d0%~p0TeamViewer.ini
if exist  "%~d0%~p0TeamViewer.ini" goto redel4
goto nosleep5
:redel5
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep5
attrib -a -h -s -r %~d0%~p0<sample_name>
del /f /q %~d0%~p0<sample_name>
if exist  "%~d0%~p0<sample_name>" goto redel5
goto nosleep6
:redel6
ping 1.1.1.1 -n 1 -w 750 > nul
:nosleep6
attrib -a -h -s -r %~d0%~p0<renamed_TeamVeiwer>
del /f /q %~d0%~p0<renamed_TeamVeiwer>
if exist  "%~d0%~p0<renamed_TeamViewer>" goto redel6
attrib -a -h -s -r %0
del /f /q %0

Possible Connection to Another Intrusion Set

The identified MINEBRIDGE samples have been packed within a loader we call MINEDOOR. Since Fall 2019, we’ve observed a group publicly tracked as TA505 conducting phishing campaigns that use MINEDOOR to deliver the FRIENDSPEAK backdoor. The combination of MINEDOOR and FRIENDSPEAK has also been publicly discussed using the name Get2.

The limited overlap in tactics, techniques, and procedures (TTPs) between campaigns delivering MINEBRIDGE and those delivering FRIENDSPEAK may suggest that MINEDOOR is not exclusive to TA505. Recent campaigns delivering FRIENDSPEAK have appeared to use spoofed sender addresses, Excel spreadsheets with embedded payloads, and campaign-specific domains that masquerade as common technology services. Meanwhile, the campaigns delivering MINEBRIDGE have used actor-controlled email addresses, malicious Word documents that download payloads from a remote server, and domains with a variety of themes sometimes registered weeks in advance of the campaign. The campaigns delivering MINEBRIDGE also appear to be significantly smaller in both volume and scope than the campaigns delivering FRIENDSPEAK. Finally, we observed campaigns delivering MINEBRIDGE on Eastern Orthodox Christmas when Russian-speaking actors are commonly inactive; we did not observe campaigns delivering FRIENDSPEAK during the week surrounding the holiday and language resources in the malware may suggest TA505 actors speak Russian.

It is plausible that these campaigns represent a subset of TA505 activity. For example, they may be operations conducted on behalf of a specific client or by a specific member of the broader threat group. Both sets of campaigns used domains that were registered with Eranet and had the registrant location “JL, US” or “Fujian, CN,” however this overlap is less notable because we suspect that TA505 has used domains registered by a service that reuses registrant information.

Post-compromise activity would likely reveal if these campaigns were conducted by TA505 or a second threat group, however, FireEye has not yet observed any instances in which a host has been successfully compromised by MINEBRIDGE. As such, FireEye currently clusters this activity separately from what the public tracks as TA505.

Acknowledgments

FireEye would like to thank all the dedicated authors of open source tooling and research referenced in this blog post. Further, FireEye would like to thank TeamViewer for their collaboration with us on this matter. The insecure DLL loading highlighted in this blog post was resolved in TeamViewer 11.0.214397, released on October 22, 2019, prior to the TeamViewer team receiving any information from FireEye. Additionally, TeamViewer is working to add further mitigations for the malware’s functionality. FireEye will update this post with further data from TeamViewer when this becomes available.

Indicators of Compromise (IOCs)

Suspicious Behaviors
  • Process lineage: Microsoft Word launching TeamViewer
  • Directory Creation: %APPDATA%\Windows Media Player
  • File Creation:
    • %APPDATA%\Windows Media Player\msi.dll
    • %APPDATA%\Windows Media Player\msi.dll.old
    • %APPDATA%\Windows Media Player\tvdll.cmd
    • %APPDATA%\Windows Media Player\wpvnetwks.exe
    • %APPDATA%\Windows Media Player\TeamViewer_Resource_en.dll
    • %APPDATA%\Windows Media Player\TeamViewer_StaticRes.dll
    • %APPDATA%\Windows Media Player\TeamViewer_Desktop.exe
    • %APPDATA%\Windows Media Player\TeamViewer.ini
    • %CSIDL_STARTUP%\Windows WMI.lnk
    • %CSIDL_PROFILE%\<dll_name>.xpdf
    • %TEMP%\<32 random characters>
    • %TEMP%\<32 random characters>.exe
    • %TEMP%\~8426bcrtv7bdf.bin
  • Network Activity:
    • HTTPS Post requests to C2 URLs
    • User-Agent String: "Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_1 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0 Mobile/15B150 Safari/604.1"

C2 Domains

  • 123faster[.]top
  • conversia91[.]top
  • fatoftheland[.]top
  • creatorz123[.]top
  • compilator333[.]top
Download Domains
  • neurogon[.]com
  • tiparcano[.]com
  • seigortan[.]com
  • marendoger[.]com
  • badiconreg[.]com
Sender Domains
  • pt-cpaaccountant[.]com
  • rogervecpa[.]com
  • agent4career[.]com
  • bestrecruitments[.]com
Phishing Documents

MD5

SHA256

01067c8e41dae72ce39b28d85bf923ee

80e48391ed32e6c1ca13079d900d3afad62e05c08bd6e929dffdd2e3b9f69299

1601137b84d9bebf21dcfb9ad1eaa69d

3f121c714f18dfb59074cbb665ff9e7f36b2b372cfe6d58a2a8fb1a34dd71952

1c883a997cbf2a656869f6e69ffbd027

de7c7a962e78ceeee0d8359197daeb2c3ca5484dc7cf0d8663fb32003068c655

2ed49bd499c9962e115a66665a6944f6

b8f64a83ad770add6919d243222c62471600e64789264d116c560b7c574669ec

3b948368fe1a296f5ed18b11194ce51c

999d4f434bbc5d355656cc2a05982d61d6770a4c3c837dd8ec6aff8437ae405a

4148281424ff3e85b215cd867746b20c

9812123d2367b952e68fa09bd3d1b3b3db81f0d3e2b3c03a53c21f12f1f4c889

54f22fbc84f4d060fcbf23534a02e5f6

7b20e7e4e0b1c0e41de72c75b1866866a8f61df5a8af0ebf6e8dbd8f4e7bdc57

5a3d8348f04345f6687552e6b7469ac1

77a33d9a4610c4b794a61c79c93e2be87886d27402968310d93988dfd32a2ccf

607d28ae6cf2adb87fcb7eac9f9e09ab

f3917832c68ed3f877df4cd01635b1c14a9c7e217c93150bebf9302223f52065

9ba3275ac0e65b9cd4d5afa0adf401b4

18698c5a6ff96d21e7ca634a608f01a414ef6fbbd7c1b3bf0f2085c85374516e

9becd2fd73aa4b36ad9cd0c95297d40b

30025da34f6f311efe6b7b2c3fe334f934f3f6e6024e4d95e8c808c18eb6de03

9cce3c9516f0f15ce18f37d707931775

bf0adb30ca230eee6401861e1669b9cfeaa64122cc29c5294c2198f2d82f760e

9faf9e0c5945876c8bad3c121c91ea15

88c4019e66564ad8c15b189b903276910f9d828d5e180cac30f1f341647278fc

a37e6eeb06729b6108649f21064b16ef

e895dc605c6dcaf2c3173b5ec1a74a24390c4c274571d6e17b55955c9bd48799

ab8dc4ba75aad317abb8ee38c8928db0

212793a915bdd75bede8a744cd99123e2a5ac70825d7b2e1fc27104276a3aafd

b8817253288b395cb33ffe36e0072dc9

ba013420bd2306ecb9be8901db905b4696d93b9674bd7b10b4d0ef6f52fbd069

cb5e5d29f844eb22fecaa45763750c27

4ff9bfde5b5d3614e6aa753cacc68d26c12601b88e61e03e4727ee6d9fe3cdc2

cffda37453e1a1389840ed6ebaef1b0d

c9f6ba5368760bf384399c9fd6b4f33185e7d0b6ea258909d7516f41a0821056

dc0e1e4ec757a777a4d4cc92a8d9ef33

ac7e622e0d1d518f1b002d514c348a60f7a7e7885192e28626808a7b9228eab6

e5c7e82670372e3cf8e8cab2c1e6bc17

eba3c07155c47a47ee4d9b5201f47a9473255f4d7a6590b5c4e7b6e9fc533c08

f93062f6271f20649e61a09c501c6c92

3f4f546fba4f1e2ee4b32193abcaaa207efe8a767580ab92e546d75a7e978a0b

MINEBRIDGE/MINEDOOR Samples

MD5

SHA256

05432fc4145d56030f6dd6259020d16c

182ccc7f2d703ad732ffee0e1d9ae4ae5cf6b8817cc33fd44f203d31868b1e97

0be9911c5be7e6dfeaeca0a7277d432b

65ead629a55e953b31668aac3bd373e229c45eb1871d8466f278f39ebcd5d26b

0dd556bf03ecb42bf87d5ea7ce8efafe

48f6810e50d08c2631f63aae307a7724dba830430f5edd4b90b4b6a5b3c3ca85

15edac65d5b5ed6c27a8ac983d5b97f6

03ff2b3067aa73ecd8830b6b0ea4f7cfa1c7476452b26227fb433265e7206525

1e9c836f997ddcbd13de35a0264cf9f1

23da418912119a1358c9a1a4671ba60c396fff4c4de225fe6a225330147549a7

21aa1066f102324ccc4697193be83741

86d839e1d741445f194965eee60d18bd292bec73e4889089e6caf9877581db12

22b7ddf4983d6e6d84a4978f96bc2a82

fc39cb08cae90c661e00718e2a0051b5de3dcb7cddde919b9ffd2d79bf923d1f

2333fbadeea558e57ac15e51d55b041c

57671d5154e707da0ee6139485f45a50fa9221852ebb65781d45a2660da7d0cb

2b9961f31e0015cbcb276d43b05e4434

e41b89869c2b510c88acd1ed9fd4a6dfe89222a81c6c1241a69af3b7f812f712

2c3cb2132951b63036124dec06fd84a8

b6dbb902125e7bf6f6701b654cbff4abaf2e853441cf34045ac19eff5ed8ce84

4de9d6073a63a26180a5d8dcaffb9e81

7b1d4774176976ffcb2075889557f91a43c05fb13f3bc262bbaec4d7a0a827e6

505ff4b9ef2b619305d7973869cd1d2b

abb05ba50f45742025dd4ebff2310325783da00fb7bc885783e60a88c5157268

52d6654fe3ac78661689237a149a710b

d6a0e62fe53116c9b5bccd2a584381e2ca86e35490d809ce1900603d5e6b53eb

53e044cd7cea2a6239d8411b8befb4b7

6e76d648d446e6a70acdd491f04c52d17f9f0e1ef34890c6628c4f48725b47c8

5624c985228288c73317f2fa1be66f32

99559a5f06b0279ed893d2799b735dae450a620f6cea2ea58426d8b67d598add

598940779363d9f4203fbfe158d6829b

1358b0ccae9dbb493228dc94eb5722c8d34c12227a438766be83df8c1c92a621

60bdea2c493c812428a8db21b29dd402

383c86deed8797e0915acf3e0c1b6a4142c2c5ecb5d482517ed2ade4df6f36fd

681a77eba0734c0a17b02a81564ae73f

0aaa66dc983179bffdb181079f3b786b6cd587c38c67ba68b560db0bd873278a

6b7d9268c7000c651473f33d088a16bd

6e39ffecab4ca0bd7835a2e773ebfc3f6d909a0a680f898e55f85ed00728666d

6d6f50f7bba4ae0225e9754e9053edc0

ddf33eff293ffc268dfd0a33dddef97aefe9e010ec869dc22c221d197eb85740

6de77c1b4e8abaaf304b43162252f022

8f50ddc1519e587597882a6bd0667653c36a8064b56ee5ff77665db2faf24710

7004fadfa572d77e24b33d2458f023d1

cccd6b46f950caec5effdd07af339be78691974fec5f25d923932b35edb95c4a

71988460fd87b6bff8e8fc0f442c934b

8167d41ad30f5d451791878815e479965b2f5213231f26819ecaf4fcc774ab12

722981703148fa78d41abbae8857f7a2

a3070ee10dd5bcd65a45b72848c926db2602e5297641452edff66e7133cdce9c

818f7af373d1ec865d6c1b7f59dc89e5

cbe4b73c0c95c207ccde9d9bd80f541cf90cad18ba5abc3fe66a811ead1601c2

832052b0f806f44b92f6ef150573af81

e162a70a6e27fe23379d3a17a3a727d85a94b79416d81ec3b4ea80d329e96830

836125ae2bed57be93a93d18e0c600e8

0fbde653bef4642626f2996a41a15a635eb52cd31eacce133d28301b902d67df

86d60bce47c9bb6017e3da26cab50dcf

6c134908ad74dfa1468a1166e7d9244695f1ffeff68bfd4eec4b35820b542b8a

8919458aec3dcc90563579a76835fc54

aad0537924bacddd0d5872f934723e765dbb182f2804c6f594f9b051937495ec

8d7e220af48fceee515eb5e56579a709

3eefa7072344e044c0a6abb0030f3f26065bf6a86bb50ea38473dd7ac73904fb

91b8ec04d8b96b90ea406c7b98cc0ad6

0520e68a4b73c3b41e566cf07be54e1f1cb59c59c303fe3390e0687f9af1a58a

959eb0696c199cbf60ec8f12fcf0ea3c

ccb5f8734befd6ab218513e16a57679a8fb43b2732e19233ee920d379045e318

95ec5e8d87111f7f6b2585992e460b52

3f8e38ccf71f122b65fdc679db13e3de3bb4b4fc04b8ab6f955d02e0bca10fae

9606cf0f12d6a00716984b5b4fa49d7d

f4f062fd7b98365ed6db993b1da586dd43e5cdcc2f00a257086734daf88c9abb

9f7fed305c6638d0854de0f4563abd62

6c5f72ddf0262838a921107520cdc12ba8e48dbafab4a66732a350095dd48e9f

a11c0b9f3e7fedfe52b1fc0fc2d4f6d1

d35ac29ea6e064b13d56f6a534022f253cf76b98e10a7ea1cbfa086eefd64f4b

a47915a2684063003f09770ba92ccef2

7b16ce0d2443b2799e36e18f60fe0603df4383b1a392b0549c3f28159b1ca4d4

a917b2ec0ac08b5cde3678487971232a

8578bff803098bf5ca0d752d0a81f07659688a32cbfc946728e5ab0403f5c4ba

ad06205879edab65ed99ed7ff796bd09

d560f8717f4117d011f40c8880081d02d1455a41c93792e1600799d3e5ee9421

ad910001cb57e84148ef014abc61fa73

c9a6f7b0603779690c1d189850403f86608a3c5e1cd91e76fd31c4f119ae256b

b1ce55fca928cf66eaa9407246399d2c

c6214ec7909ce61d6ec3f46f5a7ec595d8cc8db48965c5baee8a346632cbe16d

b9249e9f1a92e6b3359c35a8f2a1e804

0695e5e49a297c980b96f76bf10e5540de188d6a6a162e38f475418d72a50032

bd6880fb97faceecf193a745655d4301

23840c587e4e9588b3d0795d4d76a4f3d4d5b2e665ce42dde0abcd1e0a2ba254

be2597a842a7603d7eb990a2135dab5e

6288d3de1f1aa05fa0a5f0c8eb9880d077f034fc79fc20f87cbfcc522aa803cb

cf5470bfe947739e0b4527d8adb8486a

6357fdb8f62948d489080b61caf135e6aaba32dcdb7dc49b0efafef178b3b54f

d593b7847ec5d18a7dba6c7b98d9aebf

5df3a6afb1a56fa076c6db716d5a050455158941ec962546a8799fc80ccfa573

d7ee4ffce21325dfe013b6764d0f8986

92e94482dee75261c8ebdcbb7ace382a097cca11bcdc675bbe2d7b3f67525f84

de4d7796006359d60c97a6e4977e4936

ee8ba1c5329d928d542bfa06eec2c0a3e3b97dcc20382ddbc27bc420ceaeb677

e0069cd3b5548f9fd8811adf4b24bf2e

6046d6aed3f4ee2564d6be540d46bcdc0bebce11a1ced4b9ddbfa1a41084411c

e1ea93fa74d160c67a9ff748e5254fe0

92c10ef23209e09abb17e41d67301f0e3f7d9e7ddfc7c1a66140c4986d72bee7

ea15d7944c29f944814be14b25c2c2b1

5898b41ca4f4777ad04d687f93548129ccb626d2f5e6e100b0a037c3d40a7444

f22a4abd5217fa01b56d064248ce0cc5

858b4070f8b83aa43fd6a5189a8ed226ce767a64972db893e36550a25b20be94

f3cb175e725af7f94533ecc3ff62fa12

5a5385df469459cd56f6eecbf4b41b8c75aa17220c773501eaec22731f3a41bb

f6533e09a334b9f28136711ea8e9afca

9136c36ccd0be71725e8720a6cfdbdd38d7eea3998228c69ed4b52e78ba979c4

f7daaea04b7fe4251b6b8dabb832ee3a

6abd90d718113482a5bcd36e35b4ea32c469f94fc2cfb9c1c98214efbf64c352

fb1555210d04286c7bcb73ca57e8e430

36da56815dc0c274fc8aacdfffbc4d5e500025ccd1147cad513d59b69ab9557d

 

Winnti APT Group targeted Hong Kong Universities

Winnti Group has compromised computer systems at two Hong Kong universities during the Hong Kong protests that started in March 2019.

Hackers from the China-linked Winnti group have compromised computer systems at two Hong Kong universities during the Hong Kong protests that started in March 2019.

Researchers from ESET discovered the attacks in November 2019 when they spotted the ShadowPad launcher malware samples on multiple devices at the two universities. The launchers were discovered two weeks after Winnti malware infections were detected in October 2019.

“In November 2019, we discovered a new campaign run by the Winnti Group against two Hong Kong universities. We found a new variant of the ShadowPad backdoor, the group’s flagship backdoor, deployed using a new launcher and embedding numerous modules.” reads the analysis published by ESET. “The Winnti malware was also found at these universities a few weeks prior to ShadowPad.”

The Winnti group was first spotted by Kaspersky in 2013, but according to the researchers the gang has been active since 2007.

The experts believe that under the Winnti umbrella there are several APT groups, including  Winnti, Gref, PlayfullDragon, APT17, DeputyDog, Axiom, BARIUM, LEADPassCV, Wicked Panda, and ShadowPad.

Experts discovered samples from both ShadowPad and Winnti at the universities that were containing campaign identifiers and C&C URLs with the names of the universities, a circumstance that indicates a highly targeted attack.

“One can observe that the C&C URL used by both Winnti and ShadowPad complies to the scheme [backdoor_type][target_name].domain.tld:443 where [backdoor_type] is a single letter which is either “w” in the case of the Winnti malware or “b” in the case of ShadowPad.” continues the report.

“From this format, we were able to find several C&C URLs, including three additional Hong Kong universities’ names. The campaign identifiers found in the samples we’ve analyzed match the subdomain part of the C&C server, showing that these samples were really targeted against these universities.”

One can observe that the C&C URL used by both Winnti and ShadowPad complies to the scheme [backdoor_type][target_name].domain.tld:443 where [backdoor_type] is a single letter which is either “w” in the case of the Winnti malware or “b” in the case of ShadowPad.

Analyzing the C&C URL format experts determined that hackers targeted three additional Hong Kong universities. 

The ShadowPad multi-modular backdoor employed in the attacks against the Hong Kong universities was referencing 17 modules focused on info-stealing that were used to collect information from infected systems.

“In contrast, the variants we described in our white paper didn’t even have that module embedded.” continues the report.

Winnti shadowPad

Unlike previous variants of the ShadowPad backdoor detailed in ESET white paper on the arsenal of the Winnti Group, this launcher is not obfuscated using VMProtect, instead it used XOR-encryption rather than the typical RC5 key block encryption algorithm.

Other technical details are reported in the ESET’s analysis, including Indicators of Compromise (IoCs).

Pierluigi Paganini

(SecurityAffairs – APT, hacking)

The post Winnti APT Group targeted Hong Kong Universities appeared first on Security Affairs.

Fortinet removed hardcoded SSH keys and database backdoors from FortiSIEM

The vendor Fortinet has finally released security patches to remove the hardcoded SSH keys in Fortinet SIEM appliances.

Fortinet has finally released security updates to remove the hardcoded SSH keys in Fortinet SIEM appliances.

Recently Andrew Klaus, a security specialist from Cybera, discovered a hardcoded SSH public key in Fortinet’s Security Information and Event Management FortiSIEM that can be used by attackers to the FortiSIEM Supervisor. 

The expert discovered that the Fortinet devices share the same SSH key for the user ‘tunneluser‘, and it is stored in plain text.

“FortiSIEM has a hardcoded SSH public key for user “tunneluser” which is the same between all installs. An attacker with this key can successfully authenticate as this user to the FortiSIEM Supervisor.” reads the security advisory. “The unencrypted key is also stored inside the FortiSIEM image. While the user’s shell is limited to running the /opt/phoenix/phscripts/bin/tunnelshell script, SSH authentication still succeeds.”

Fortinet published a security advisory for the issue that is tracked as CVE-2019-17659.

The vulnerability could be exploited by attackers to trigger a condition of denial of service. 

“A use of hard-coded cryptographic key vulnerability in FortiSIEM may allow a remote unauthenticated attacker to obtain SSH access to the supervisor as the restricted user “tunneluser” by leveraging knowledge of the private key from another installation or a firmware image.” reads the advisory.

The user ‘tunneluser‘ only runs in a restricted shell that lets only that user create tunnel connections from the supervisor to the originating IP.

On January 15, Fortinet released a patch that removed the hardcoded public key in FortiSIEM.

Fortinet urges customers to install the patch for CVE-2019-17659, or restrict the access to FortiSIEM’s “tunneluser” port (19999). Users would upgrade to FortiSIEM version 5.2.7 and above.

Fortinet also addressed another issue in Fortinet’s FortiSIEM, tracked as CVE-2019-16153, that is related to the presence of a hardcoded password in the FortiSIEM database component. The flaw could be exploited by attackers to access the device database via the use of static credentials.

“A hard-coded password vulnerability in the FortiSIEM database component may allow attackers to access the device database via the use of static credentials.” reads the advisory published by Fortinet.

The issue affects FortiSIEM 5.2.5 and below, it could be addressed by upgrade systems to FortiSIEM 5.2.6 or above.

The issue was reported to Fortinet by the independent security researcher Srour Ganoush, “CERT CYBERPROTECT” and “Chris Armstrong from CSCI, Inc.

Pierluigi Paganini

(SecurityAffairs – Fortinet, hacking)

The post Fortinet removed hardcoded SSH keys and database backdoors from FortiSIEM appeared first on Security Affairs.

Apple says no to unlocking shooter’s phone; AG and Trump lash back

Attorney General Barr and President Trump are demanding Apple unlock the mass shooter's iPhone. Apple replies: You can't break just 1 phone.

LOWKEY: Hunting for the Missing Volume Serial ID

In August 2019, FireEye released the “Double Dragon” report on our newest graduated threat group: APT41. A China-nexus dual espionage and financially-focused group, APT41 targets industries such as gaming, healthcare, high-tech, higher education, telecommunications, and travel services.

This blog post is about the sophisticated passive backdoor we track as LOWKEY, mentioned in the APT41 report and recently unveiled at the FireEye Cyber Defense Summit. We observed LOWKEY being used in highly targeted attacks, utilizing payloads that run only on specific systems. Additional malware family names are used in the blog post and briefly described. For a complete overview of malware used by APT41 please refer to the Technical Annex section of our APT41 report.

The blog post is split into three parts, which are shown in Figure 1. The first describes how we managed to analyze the encrypted payloads. The second part features position independent loaders we observed in multiple samples, adding an additional layer of obfuscation. The final part is about the actual backdoor we call LOWKEY, which comes in two variants, a passive TCP listener and a passive HTTP listener targeting Internet Information Services (IIS).


Figure 1: Blog post overview

DEADEYE – RC5

Tracking APT41 activities over the past months, we observed multiple samples that shared two unique features: the use of RC5 encryption which we don’t encounter often, and a unique string “f@Ukd!rCto R$.”. We track these samples as DEADEYE.

DEADEYE comes in multiple variants:

  • DEADEYE.DOWN has the capability to download additional payloads.
  • DEADEYE.APPEND has additional payloads appended to it.
  • DEADEYE.EXT loads payloads that are already present on the system.

DEADEYE.DOWN

A sample belonging to DEADEYE.DOWN (MD5: 5322816c2567198ad3dfc53d99567d6e) attempts to download two files on the first execution of the malware.

The first file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20170730.jpg. The command and control (C2) server response is first RC5 decrypted with the key “wsprintfA” and then RC5 encrypted with a different key and written to disk as <MODULE_NAME>.mui.

The RC5 key is constructed using the volume serial number of the C drive. The volume serial number is a 4-byte value, usually based on the install time of the system. The volume serial number is XORed with the hard-coded constant “f@Ukd!rCto R$.” and then converted to hex to derive a key of up to 28 bytes in length. The key length can vary if the XORed value contains an embedded zero byte because the lstrlenA API call is used to determine the length of it. Note that the lstrlenA API call happens before the result is converted to hex. If the index of the byte modulo 4 is zero, the hex conversion is in uppercase. The key derivation is illustrated in Table 1.

Volume Serial number of C drive, for example 0xAABBCCDD

F          ^          0xAA

=          0xCC

uppercase

@         ^          0xBB

=          0xFB

lowercase

U          ^          0xCC

=          0x99

lowercase

k          ^          0xDD

=          0xB6

lowercase

d          ^          0xAA

=          0xCE

uppercase

!           ^          0xBB

=          0x9A

lowercase

r           ^          0xCC

=          0xBE

lowercase

C          ^          0xDD

=          0x9E

lowercase

t           ^          0xAA

=          0xDE

uppercase

o          ^          0xBB

=          0xD4

lowercase

(0x20)   ^          0xCC

=          0xEC

lowercase

R          ^          0xDD

=          0x8F

lowercase

$          ^          0xAA

=          0x8E

uppercase

.           ^          0xBB

=          0x95

lowercase

Derived key CCfb99b6CE9abe9eDEd4ec8f8E95

Table 1: Key derivation example

The second file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20160204.jpg. The C2 response is RC5 decrypted with the key “wsprintfA” and then XORed with 0x74, before it is saved as C:\Windows\System32\wcnapi.mui.


Figure 2: 5322816c2567198ad3dfc53d99567d6e download

The sample then determines its own module name, appends the extension mui to it and attempts to decrypt the file using RC5 encryption. This effectively decrypts the file the malware just downloaded and stored encrypted on the system previously. As the file has been encrypted with a key based on the volume serial number it can only be executed on the system it was downloaded on or a system that has the same volume serial number, which would be a remarkable coincidence.

An example mui file is the MD5 hash e58d4072c56a5dd3cc5cf768b8f37e5e. Looking at the encrypted file in a hex editor reveals a high entropy (7.999779/8). RC5 uses Electronic Code Book (ECB) mode by default. ECB means that each code block (64 bit) is encrypted independent from other code blocks. This means the same plaintext block always results in the same cipher text, independent from its position in the binary. The file has 792933 bytes in total but almost no duplicate cipher blocks, which means the data likely has an additional layer of encryption.

Without the correct volume serial number nor any knowledge about the plaintext there is no efficient way to decrypt the payload e58d4072c56a5dd3cc5cf768b8f37e5e with just the knowledge of the current sample.

DEADEYE.APPEND

Fortunately searching for the unique string “f@Ukd!rCto R$.“ in combination with artifacts from RC5 reveals additional samples. One of the related samples is DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), which has been previously analyzed by Kaspersky (https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/). This sample is different because it is protected with VMProtect and has the obfuscated binary appended to it. The embedded binary starts at offset 3287552 which can be seen in Figure 3 with the differing File Size and PE Size.


Figure 3: A look at the PE header reveals a larger file size than PE size

The encrypted payload has a slightly lower entropy of 7.990713 out of 8. Looking at the embedded binary in a hex editor reveals multiple occurrences of the byte pattern 51 36 94 A4 26 5B 0F 19, as seen in Figure 4. As this pattern occurs multiple times in a row in the middle of the encrypted data and ECB mode is being used, an educated guess is that the plaintext is supposed to be 00 00 00 00 00 00 00 00.


Figure 4: Repeating byte pattern in 37e100dd8b2ad8b301b130c2bca3f1ea

RC5 Brute Forcer

With this knowledge we decided to take a reference implementation of RC5 and add a main function that accounts for the key derivation algorithm used by the malware samples (see Figure 5). Brute forcing is possible as the key is derived from a single DWORD; even though the final key length might be 28 bytes, there are only 4294967296 possible keys. The code shown in Figure 5 generates all possible volume serial numbers, derives the key from them and tries to decrypt 51 36 94 A4 26 5B 0F 19 to 00 00 00 00 00 00 00 00. Running the RC5 brute forcer for a couple of minutes shows the correct volume serial number for the sample, which is 0xc25cff4c.

Note if you want to run the brute forcer yourself
The number of DWORDs of the key in the reference implementation we used is represented by the global c, and we had to change it to 7 to match the malware’s key length of 28 bytes. There were some issues with the conversion because in the malware a zero byte within the generated key ultimately leads to a shorter key length. The implementation we used uses a hard-coded key length (c), so we generated multiple executables with c = 6, c = 5, c = 4… as these usually only ran for a couple of minutes to cover the entire key space. All the samples mentioned in the Appendix 1 could be solved with c = 7 or c = 6.


Figure 5: Main function RC5 brute forcer

The decrypted payload belongs to the malware family POISONPLUG (MD5: 84b69b5d14ba5c5c9258370c9505438f). POISONPLUG is a highly obfuscated modular backdoor with plug-in capabilities. The malware is capable of registry or service persistence, self-removal, plug-in execution, and network connection forwarding. POISONPLUG has been observed using social platforms to host encoded command and control commands.

We confirmed the findings from Kaspersky and additionally found a second command and control URL hxxps://steamcommunity[.]com/id/oswal053, as mentioned in our APT 41 report.

Taking everything into account that we learned from DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), we decided to take another look at the encrypted mui file (e58d4072c56a5dd3cc5cf768b8f37e5e). Attempts to brute force the first bytes to match with the ones of the decrypted POISONPLUG payload did not yield any results.

Fortunately, we found additional samples that use the same encryption scheme. In one of the samples the malware authors included two checks to validate the decrypted payload. The expected plaintext at the specified offsets for DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff) is shown in Table 2.

Offset

Expected byte after decryption

0

0x48

1

0x8B

0x3C0

0x48

0x3C1

0x83

Table 2: Byte comparisons after decrypting in DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

Applying these constraints to our brute forcer and trying to decrypt mui file (e58d4072c56a5dd3cc5cf768b8f37e5e) once more resulted in a low number of successful hits which we could then manually check. The correct volume serial number for the encrypted mui is 0x243e2562. Analysis determined the decrypted file is XMRig miner. This also explains why the dropper downloads two files. The first, <MODULE_NAME>.mui is the crypto miner, and the second C:\Windows\System32\wcnapi.mui, is the configuration. The decrypted mui contains another layer of obfuscation and is eventually executed with the command x -c wcnapi.mui. An explanation on how the command was obtained and the additional layer of obfuscation is given in the next part of the blog post.

For a list of samples with the corresponding volume serial numbers, please refer to Appendix 1.

Additional RC4 Layer

An additional RC4 layer has been identified in droppers used by APT41, which we internally track as DEADEYE. The layer has been previously detailed in a blog post by ESET. We wanted to provide some additional information on this, as it was used in some of the samples we managed to brute force.

The additional layer is position independent shellcode containing a reflective DLL loader. The loader decrypts an RC4 encrypted payload and loads it in memory. The code itself is a straight forward loader with the exception of some interesting artifacts identified during analysis.

As mentioned in the blog post by ESET, the encrypted payload is prepended with a header. It contains the RC4 encryption key and two fields of variable length, which have previously been identified as file names. These two fields are encrypted with the same RC4 encryption key that is also used to decrypt the payload. The header is shown in Table 3.

Header bytes

Meaning

0 15

RC4 key XOR encoded with 0x37

16 19

Size of loader stub before the header

20 23

RC4 key size

24 27

Command ASCII size (CAS)

28 31

Command UNICODE size (CUS)

32 35

Size of encrypted payload

36 39

Launch type

40 (40 + CAS)

Command ASCII

(40 + CAS) (40 + CAS + CUS)

Command UNICODE

(40 + CAS + CUS) (40 + CAS + CUS + size of encrypted payload)

Encrypted payload

Table 3: RC4 header overview

Looking at the payloads hidden behind the RC5 layer, we observed, that these fields are not limited to file names, instead they can also contain commands used by the reflective loader. If no command is specified, the default parameter is the file name of the loaded payload. In some instances, this revealed the full file path and file name in the development environment. Table 4 shows some paths and file names. This is also how we found the command (x -c wcnapi.mui) used to launch the decrypted mui file from the first part of the blog post.

MD5 hash

Arguments found in the RC4 layer

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\Inner-Loader\x64\Release\Inner-Loader.dll

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\SK3.x\x64\Release\SK3.x.exe

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

UserFunction.dll

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

ProcTran.dll

c11dd805de683822bf4922aecb9bfef5

E:\code\PortReuse\iis-share\2.5\IIS_Share\x64\Release\IIS_Share.dll

c11dd805de683822bf4922aecb9bfef5

UserFunction.dll

c11dd805de683822bf4922aecb9bfef5

ProcTran.dll

Table 4: Decrypted paths and file names

LOWKEY

The final part of the blog post describes the capabilities of the passive backdoor LOWKEY (MD5: 8aab5e2834feb68bb645e0bad4fa10bd) decrypted from DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff). LOWKEY is a passive backdoor that supports commands for a reverse shell, uploading and downloading files, listing and killing processes and file management. We have identified two variants of the LOWKEY backdoor.

The first is a TCP variant that listens on port 53, and the second is an HTTP variant that listens on TCP port 80. The HTTP variant intercepts URL requests matching the UrlPrefix http://+:80/requested.html. The + in the given UrlPrefix means that it will match any host name. It has been briefly mentioned by Kaspersky as “unknown backdoor”.

Both variants are loaded by the reflective loader described in the previous part of the blog post. This means we were able to extract the original file names. They contain meaningful names and provide a first hint on how the backdoor operates.

HTTP variant (MD5: c11dd805de683822bf4922aecb9bfef5)
E:\code\PortReuse\iis-share\2.5\IIS_Share\x64\Release\IIS_Share.dll

TCP variant (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)
E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\SK3.x\x64\Release\SK3.x.exe

The interesting parts are shown in Figure 6. PortReuse describes the general idea behind the backdoor, to operate on a well-known port. The paths also contain version numbers 2.5 and v1.3-53. IIS_Share is used for the HTTP variant and describes the targeted application, DeviceIOContrl-Hook is used for the TCP variant.


Figure 6: Overview important parts of executable path

Both LOWKEY variants are functionally identical with one exception. The TCP variant relies on a second component, a user mode rootkit that is capable of intercepting incoming TCP connections. The internal name used by the developers for that component is E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe.


Figure 7: LOWKEY components

Inner-Loader.dll

Inner-Loader.dll is a watch guard for the LOWKEY backdoor. It leverages the GetExtendedTcpTable API to retrieve all processes with an open TCP connection. If a process is listening on TCP port 53 it injects NetAgent.exe into the process. This is done in a loop with a 10 second delay. The loader exits the loop when NetAgent.exe has been successfully injected. After the injection it will create a new thread for the LOWKEY backdoor (SK3.x.exe).

The watch guard enters an endless loop that executes every 20 minutes and ensures that the NetAgent.exe and the LOWKEY backdoor are still active. If this is not the case it will relaunch the backdoor or reinject the NetAgent.exe.

NetAgent.exe

NetAgent.exe is a user mode rootkit that provides covert communication with the LOWKEY backdoor component. It forwards incoming packets, after receiving the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00, to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}.

The component works by hooking the NtDeviceIoControlFile API. It does that by allocating a suspiciously large region of memory, which is used as a global hook table. The table consists of 0x668A0 bytes and has read, write and execute permissions set.

Each hook table entry consists of 3 pointers. The first points to memory containing the original 11 bytes of each hooked function, the second entry contains a pointer to the remaining original instructions and the third pointer points to the function hook. The malware will only hook one function in this manner and therefore allocates an unnecessary large amount of memory. The malware was designed to hook up to 10000 functions this way.

The hook function begins by iterating the global hook table and compares the pointer to the hook function to itself. This is done to find the original instructions for the installed hook, in this case NtDeviceIoControlFile. The malware then executes the saved instructions which results in a regular NtDeviceIoControlFile API call. Afterwards the IoControlCode is compared to 0x12017 (AFD_RECV).

If the IoControlCode does not match, the original API call results are returned.

If they match the malware compares the first 12 bytes of the incoming data. As it is effectively a TCP packet, it is parsing the TCP header to get the data of the packet. The first 12 bytes of the data section are compared against the hard-coded byte pattern: FF FF 01 00 00 01 00 00 00 00 00 00.

If they match it expects to receive additional data, which seems to be unused, and then responds with a 16 byte header 00 00 00 00 00 91 03 00 00 00 00 00 80 1F 00 00, which seems to be hard-coded and to indicate that following packets will be forwarded to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}. The backdoor component (SK3.x.exe) receives and sends data to the named pipe. The hook function will forward all received data from the named pipe back to the socket, effectively allowing a covert communication between the named pipe and the socket.

SK3.x.exe

SK3.x.exe is the actual backdoor component. It supports writing and reading files, modification of file properties, an interactive command shell, TCP relay functionality and listing running processes. The backdoor opens a named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} for communication.

Data received by the backdoor is encrypted with RC4 using the key “CreateThread“ and then XORed with 0x77. All data sent by the backdoor uses the same encryption in reverse order (first XOR with 0x77, then RC4 encrypted with the key “CreateThread“). Encrypted data is preceded by a 16-byte header which is unencrypted containing an identifier and the size of the following encrypted packet.

An example header looks as follows:
00 00 00 00 00 FD 00 00 10 00 00 00 00 00 00 00

Bytes

Meaning

00 00 00 00 00

unknown

FD 00

Bytes 5 and 6 are the command identifier, for a list of all supported identifiers check Table 6 and Table 7.

00

unknown

10 00 00 00

Size of the encrypted packet that is send after the header

00 00 00 00

unknown

Table 5: Subcomponents of header

The backdoor supports the commands listed in tables Table 6 and Table 7. Most commands expect a string at the beginning which likely describes the command and is for the convenience of the operators, but this string isn't actively used by the malware and could be anything. For example, KILL <PID> could also be A <PID>. Some of the commands rely on two payloads (UserFunction.dll and ProcTran.dll), that are embedded in the backdoor and are either injected into another process or launch another process.

UserFunction.dll

Userfunction.dll starts a hidden cmd.exe process, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} and forwards all received data from the pipe to the standard input of the cmd.exe process. All output from the process is redirected back to the named pipe. This allows interaction with the shell over the named pipe.

ProcTran.dll

The component opens a TCP connection to the provided host and port, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} and forwards all received data from the pipe to the opened TCP connection. All received packets on the connection are forwarded to the named pipe. This allows interaction with the TCP connection over the named pipe.

Identifier

Arguments

Description

0xC8

<cmd> <arg1> <arg2>

Provides a simple shell, that supports the following commands, dir, copy, move, del, systeminfo and cd. These match the functionality of standard commands from a shell. This is the only case where the <cmd> is actually used.

0xC9

<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects UserFunction.dll into the process, which is an interactive shell that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00000}. The backdoor will then forward incoming data to the named pipe allowing for communication with the opened shell. If no PID is provided, the `cmd.exe` is launched as child process of the backdoor process with input and output redirected to the named pipe Microsoft Ole Object {30000-7100-12985-00001-00001}

0xCA

<cmd> <arg1> <arg2>

Writes data to a file. The first argument is the <file_name>, the second argument is an offset into the file

0xCB

<cmd> <arg1> <arg2>
<arg3>

Reads data from a file. The first argument is the <file_name>, the second argument is an offset into the file, the third argument is optional, and the exact purpose is unknown

0xFA

-

Lists running processes, including the process name, PID, process owner and the executable path

0xFB

<cmd> <arg1>

Kills the process with the provided process id (PID)

0xFC

<cmd> <arg1> <arg2>

Copies the files CreationTime, LastAccessTime and LastWriteTime from the second argument and applies them to the first argument. Both arguments are expected to be full file paths. The order of the arguments is a bit unusual, as one would usually apply the access times from the second argument to the third

0xFD

-

List running processes with additional details like the SessonId and the CommandLine by executing the WMI query SELECT Name,ProcessId,SessionId,CommandLine,ExecutablePath FROM Win32_Process

0xFE

-

Ping command, the malware responds with the following byte sequence 00 00 00 00 00 65 00 00 00 00 00 00 06 00 00 00. Experiments with the backdoor revealed that the identifier 0x65 seems to indicate a successful operation, whereas 0x66 indicates an error.

Table 6: C2 commands

The commands listed in Table 7 are used to provide functionality of a TCP traffic relay. This allows operators to communicate through the backdoor with another host via TCP. This could be used for lateral movement in a network. For example, one instance of the backdoor could be used as a jump host and additional hosts in the target network could be reached via the TCP traffic relay. Note that the commands 0xD2, 0xD3 and 0xD6 listed in Table 7 can be used in the main backdoor thread, without having to use the ProcTran.dll.

Identifier

Arguments

Description

0x105

<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects ProcTran.dll into the process, which is a TCP traffic relay component that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00001}. The commands 0xD2, 0xD3 and 0xD6 can then be used with the component.

0xD2

<arg1> <arg2>

Opens a connection to the provided host and port, the first argument is the host, the second the port. On success a header with the identifier set to 0xD4 is returned (00 00 00 00 00 D4 00 00 00 00 00 00 00 00 00 00). This effectively establishes a TCP traffic relay allowing operators to communicate with another system through the backdoored machine.

0xD3

<arg1>

Receives and sends data over the connection opened by the 0xD2 command. Received data is first RC4 decrypted with the key “CreateThread“ and then single-byte XOR decoded with 0x77. Data sent back is directly relayed without any additional encryption.

0xD6

-

Closes the socket connection that had been established by the 0xD2 command

0xCF

-

Closes the named pipe Microsoft Ole Object {30000-7100-12985-00000-00001} that is used to communicate with the injected ProcTran.dll. This seems to terminate the thread in the targeted process by the 0x105 command

Table 7: C2 commands TCP relay

Summary

The TCP LOWKEY variant passively listens for the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00 on TCP port 53 to be activated. The backdoor then uses up to three named pipes for communication. One pipe is used for the main communication of the backdoor, the other ones are used on demand for the embedded payloads.

  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} main communication pipe
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} named pipe used for interaction with the TCP relay module ProcTran.dll
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} named pipe used for the interactive shell module UserFunction.dll

Figure 8 summarizes how the LOWKEY components interact with each other.


Figure 8: LOWKEY passive backdoor overview

Appendix

MD5 HASH

Correct Volume Serial

Dropper Family

Final Payload Family

2b9244c526e2c2b6d40e79a8c3edb93c

0xde82ce06

DEADEYE.APPEND

POISONPLUG

04be89ff5d217796bc68678d2508a0d7

0x56a80cc8

DEADEYE.APPEND

POISONPLUG

092ae9ce61f6575344c424967bd79437

0x58b5ef5c

DEADEYE.APPEND

LOWKEY.HTTP

37e100dd8b2ad8b301b130c2bca3f1ea

0xc25cff4c

DEADEYE.APPEND

POISONPLUG

39fe65a46c03b930ccf0d552ed3c17b1

0x24773b24

DEADEYE.APPEND

POISONPLUG

5322816c2567198ad3dfc53d99567d6e

-

DEADEYE.DOWN

-

557ff68798c71652db8a85596a4bab72

0x4cebb6e9

DEADEYE.APPEND

POISONPLUG

64e09cf2894d6e5ac50207edff787ed7

0x64fd8753

DEADEYE.APPEND

POISONPLUG

650a3dce1380f9194361e0c7be9ffb97

0xeaa61f82

DEADEYE.APPEND

POISONPLUG

7dc6bbc202e039dd989e1e2a93d2ec2d

0xa8c5a006

DEADEYE.APPEND

LOWKEY

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

0x9438158b

DEADEYE.APPEND

LOWKEY

904bbe5ac0d53e74a6cefb14ebd58c0b

0xde82ce06

DEADEYE.APPEND

POISONPLUG

c11dd805de683822bf4922aecb9bfef5

0xcab011e1

DEADEYE.APPEND

LOWKEY.HTTP

d49c186b1bfd7c9233e5815c2572eb98

0x4a23bd79

DEADEYE.APPEND

LOWKEY

e58d4072c56a5dd3cc5cf768b8f37e5e

0x243e2562

None - encrypted data

XMRIG

eb37c75369046fb1076450b3c34fb8ab

0x00e5a39e

DEADEYE.APPEND

LOWKEY

ee5b707249c562dc916b125e32950c8d

0xdecb3d5d

DEADEYE.APPEND

POISONPLUG

ff8d92dfbcda572ef97c142017eec658

0xde82ce06

DEADEYE.APPEND

POISONPLUG

ffd0f34739c1568797891b9961111464

0xde82ce06

DEADEYE.APPEND

POISONPLUG

Appendix 1: List of samples with RC5 encrypted payloads

Government Sector in Central Asia Targeted With New HAWKBALL Backdoor Delivered via Microsoft Office Vulnerabilities

FireEye Labs recently observed an attack against the government sector in Central Asia. The attack involved the new HAWKBALL backdoor being delivered via well-known Microsoft Office vulnerabilities CVE-2017-11882 and CVE-2018-0802.

HAWKBALL is a backdoor that attackers can use to collect information from the victim, as well as to deliver payloads. HAWKBALL is capable of surveying the host, creating a named pipe to execute native Windows commands, terminating processes, creating, deleting and uploading files, searching for files, and enumerating drives.

Figure 1 shows the decoy used in the attack.


Figure 1: Decoy used in attack

The decoy file, doc.rtf (MD5: AC0EAC22CE12EAC9EE15CA03646ED70C), contains an OLE object that uses Equation Editor to drop the embedded shellcode in %TEMP% with the name 8.t. This shellcode is decrypted in memory through EQENDT32.EXE. Figure 2 shows the decryption mechanism used in EQENDT32.EXE.


Figure 2: Shellcode decryption routine

The decrypted shellcode is dropped as a Microsoft Word plugin WLL (MD5: D90E45FBF11B5BBDCA945B24D155A4B2) into C:\Users\ADMINI~1\AppData\Roaming\Microsoft\Word\STARTUP (Figure 3).


Figure 3: Payload dropped as Word plugin

Technical Details

DllMain of the dropped payload determines if the string WORD.EXE is present in the sample’s command line. If the string is not present, the malware exits. If the string is present, the malware executes the command RunDll32.exe < C:\Users\ADMINI~1\AppData\Roaming\Microsoft\Word\STARTUP\hh14980443.wll, DllEntry> using the WinExec() function.

DllEntry is the payload’s only export function. The malware creates a log file in %TEMP% with the name c3E57B.tmp. The malware writes the current local time plus two hardcoded values every time in the following format:

<Month int>/<Date int> <Hours>:<Minutes>:<Seconds>\t<Hardcoded Digit>\t<Hardcoded Digit>\n

Example:

05/22 07:29:17 4          0

This log file is written to every 15 seconds. The last two digits are hard coded and passed as parameters to the function (Figure 4).


Figure 4: String format for log file

The encrypted file contains a config file of 0x78 bytes. The data is decrypted with an 0xD9 XOR operation. The decrypted data contains command and control (C2) information as well as a mutex string used during malware initialization. Figure 5 shows the decryption routine and decrypted config file.


Figure 5: Config decryption routine

The IP address from the config file is written to %TEMP%/3E57B.tmp with the current local time. For example:

05/22 07:49:48 149.28.182.78.

Mutex Creation

The malware creates a mutex to prevent multiple instances of execution. Before naming the mutex, the malware determines whether it is running as a system profile (Figure 6). To verify that the malware resolves the environment variable for %APPDATA%, it checks for the string config/systemprofile.


Figure 6: Verify whether malware is running as a system profile

If the malware is running as a system profile, the string d0c from the decrypted config file is used to create the mutex. Otherwise, the string _cu is appended to d0c and the mutex is named d0c_cu (Figure 7).


Figure 7: Mutex creation

After the mutex is created, the malware writes another entry in the logfile in %TEMP% with the values 32 and 0.

Network Communication

HAWKBALL is a backdoor that communicates to a single hard-coded C2 server using HTTP. The C2 server is obtained from the decrypted config file, as shown in Figure 5. The network request is formed with hard-coded values such as User-Agent. The malware also sets the other fields of request headers such as:

  • Content-Length: <content_length>
  • Cache-Control: no-cache
  • Connection: close

The malware sends an HTTP GET request to its C2 IP address using HTTP over port 443. Figure 8 shows the GET request sent over the network.


Figure 8: Network request

The network request is formed with four parameters in the format shown in Figure 9.

Format = "?t=%d&&s=%d&&p=%s&&k=%d"


Figure 9: GET request parameters formation

Table 1 shows the GET request parameters.

Value

Information

T

Initially set to 0

S

Initially set to 0

P

String from decrypted config at 0x68

k

The result of GetTickCount()

Table 1: GET request parameters

If the returned response is 200, then the malware sends another GET request (Figure 10) with the following parameters (Figure 11).

Format = "?e=%d&&t=%d&&k=%d"


Figure 10: Second GET request


Figure 11: Second GET request parameters formation

Table 2 shows information about the parameters.

Value

Information

E

Initially Set to 0

T

Initially set to 0

K

The result of GetTickCount()

Table 2: Second GET request parameters

If the returned response is 200, the malware examines the Set-Cookie field. This field provides the Command ID. As shown in Figure 10, the field Set-Cookie responds with ID=17.

This Command ID acts as the index into a function table created by the malware. Figure 12 shows the creation of the virtual function table that will perform the backdoor’s command.


Figure 12: Function table

Table 3 shows the commands supported by HAWKBALL.

Command

Operation Performed

0

Set URI query string to value

16

Unknown

17

Collect system information

18

Execute a provided argument using CreateProcess

19

Execute a provided argument using CreateProcess and upload output

20

Create a cmd.exe reverse shell, execute a command, and upload output

21

Shut down reverse shell

22

Unknown

23

Shut down reverse shell

48

Download file

64

Get drive geometry and free space for logical drives C-Z

65

Retrieve information about provided directory

66

Delete file

67

Move file

Table 3: HAWKBALL commands

Collect System Information

Command ID 17 indexes to a function that collects the system information and sends it to the C2 server. The system information includes:

  • Computer Name
  • User Name
  • IP Address
  • Active Code Page
  • OEM Page
  • OS Version
  • Architecture Details (x32/x64)
  • String at 0x68 offset from decrypted config file

This information is retrieved from the victim using the following WINAPI calls:

Format = "%s;%s;%s;%d;%d;%s;%s %dbit"

  • GetComputerNameA
  • GetUserNameA
  • Gethostbyname and inet_ntoa
  • GetACP
  • GetOEMPC
  • GetCurrentProcess and IsWow64Process


Figure 13: System information

The collected system information is concatenated together with a semicolon separating each field:

WIN732BIT-L-0;Administrator;10.128.62.115;1252;437;d0c;Windows 7 32bit

This information is encrypted using an XOR operation. The response from the second GET request is used as the encryption key. As shown in Figure 10, the second GET request responds with a 4-byte XOR key. In this case the key is 0xE5044C18.

Once encrypted, the system information is sent in the body of an HTTP POST. Figure 14 shows data sent over the network with the POST request.


Figure 14: POST request

In the request header, the field Cookie is set with the command ID of the command for which the response is sent. As shown in Figure 14, the Cookie field is set with ID=17, which is the response for the previous command. In the received response, the next command is returned in field Set-Cookie.

Table 4 shows the parameters of this POST request.

Parameter

Information

E

Initially set to 0

T

Decimal form of the little-endian XOR key

K

The result of GetTickCount()

Table 4: POST request parameters

Create Process

The malware creates a process with specified arguments. Figure 15 shows the operation.


Figure 15: Command create process

Delete File

The malware deletes the file specified as an argument. Figure 16 show the operation.


Figure 16: Delete file operation

Get Directory Information

The malware gets information for the provided directory address using the following WINAPI calls:

  • FindFirstFileW
  • FindNextFileW
  • FileTimeToLocalFileTime
  • FiletimeToSystemTime

Figure 17 shows the API used for collecting information.


Figure 17: Get directory information

Get Disk Information

This command retrieves the drive information for drives C through Z along with available disk space for each drive.


Figure 18: Retrieve drive information

The information is stored in the following format for each drive:

Format = "%d+%d+%d+%d;"

Example: "8+512+6460870+16751103;"

The information for all the available drives is combined and sent to the server using an operation similar to Figure 14.

Anti-Debugging Tricks

Debugger Detection With PEB

The malware queries the value for the flag BeingDebugged from PEB to check whether the process is being debugged.


Figure 19: Retrieve value from PEB

NtQueryInformationProcess

The malware uses the NtQueryInformationProcess API to detect if it is being debugged. The following flags are used:

  • Passing value 0x7 to ProcessInformationClass:


Figure 20: ProcessDebugPort verification

  • Passing value 0x1E to ProcessInformationClass:


Figure 21: ProcessDebugFlags verification

  • Passing value 0x1F to ProcessInformationClass:


Figure 22: ProcessDebugObject

Conclusion

HAWKBALL is a new backdoor that provides features attackers can use to collect information from a victim and deliver new payloads to the target. At the time of writing, the FireEye Multi-Vector Execution (MVX) engine is able to recognize and block this threat. We advise that all industries remain on alert, though, because the threat actors involved in this campaign may eventually broaden the scope of their current targeting.

Indicators of Compromise (IOC)

MD5

Name

AC0EAC22CE12EAC9EE15CA03646ED70C

Doc.rtf

D90E45FBF11B5BBDCA945B24D155A4B2

hh14980443.wll

Network Indicators

  • 149.28.182[.]78:443
  • 149.28.182[.]78:80
  • http://149.28.182[.]78/?t=0&&s=0&&p=wGH^69&&k=<tick_count>
  • http://149.28.182[.]78/?e=0&&t=0&&k=<tick_count>
  • http://149.28.182[.]78/?e=0&&t=<int_xor_key>&&k=<tick_count>
  • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)

FireEye Detections

MD5

Product

Signature

Action

AC0EAC22CE12EAC9EE15CA03646ED70C

FireEye Email Security

FireEye Network Security

FireEye Endpoint Security

FE_Exploit_RTF_EQGEN_7

Exploit.Generic.MVX

Block

D90E45FBF11B5BBDCA945B24D155A4B2

FireEye Email Security

FireEye Network Security

FireEye Endpoint Security

Malware.Binary.Dll

FE_APT_Backdoor_Win32_HawkBall_1

APT.Backdoor.Win.HawkBall

Block

Acknowledgement

Thank you to Matt Williams for providing reverse engineering support.

iBackDoor: High-Risk Code Hits iOS Apps

Introduction

FireEye mobile researchers recently discovered potentially “backdoored” versions of an ad library embedded in thousands of iOS apps originally published in the Apple App Store. The affected versions of this library embedded functionality in iOS apps that used the library to display ads, allowing for potential malicious access to sensitive user data and device functionality. NOTE: Apple has worked with us on the issue and has since removed the affected apps.

These potential backdoors could have been controlled remotely by loading JavaScript code from a remote server to perform the following actions on an iOS device:

  • Capture audio and screenshots
  • Monitor and upload device location
  • Read/delete/create/modify files in the app’s data container
  • Read/write/reset the app’s keychain (e.g., app password storage)
  • Post encrypted data to remote servers
  • Open URL schemes to identify and launch other apps installed on the device
  • “Side-load” non-App Store apps by prompting the user to click an “Install” button

The offending ad library contained identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the potentially backdoored ad library: version codes 5.3.3 to 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2] – version 7.0.5 – the potential backdoors are not present. It is unclear whether the potentially backdoored versions of the ad library were released by adSage or if they were created and/or compromised by a malicious third party.

As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015.

While we have not observed the ad server deliver any malicious commands intended to trigger the most sensitive capabilities such as recording audio or stealing sensitive data, affected apps periodically contact the server to check for new JavaScript code. In the wrong hands, malicious JavaScript code that triggers the potential backdoors could be posted to eventually be downloaded and executed by affected apps.

Technical Details

As shown in Figure 1, the affected mobiSage library included two key components, separately implemented in Objective-C and JavaScript. The Objective-C component, which we refer to as msageCore, implements the underlying functionality of the potential backdoors and exposed interfaces to the JavaScript context through a WebView. The JavaScript component, which we refer to as msageJS, provides high-level execution logic and can trigger the potential backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

Figure 1: Key components of backdoored mobiSage SDK

In the remainder of this section, we reveal internal details of msageCore, including its communication channel and high-risk interfaces. Then we describe how msageJS is launched and updated, and how it can trigger the backdoors.

Backdoors in msageCore

Communication channel

MsageCore implements a general framework to communicate with msageJS via the ad library’s WebView. Commands and parameters are passed via specially crafted URLs in the format adsagejs://cmd&parameter. As shown in the reconstructed code fragment in Figure 2, msageCore fetches the command and parameters from the JavaScript context and inserts them in its command queue.

Figure 2: Communication via URL loading in WebView

To process a command in its queue, msageCore dispatches the command, along with its parameters, to a corresponding Objective-C class and method. Figure 3 shows portions of the reconstructed command dispatching code.

Figure 3: Command dispatch in msageCore

At-risk interfaces

Each dispatched command ultimately arrives at an Objective-C class in msageCore. Table 1 shows a subset of msageCore classes and the corresponding interfaces that they expose.

msageCore Class Name

Interfaces

MSageCoreUIManagerPlugin

- captureAudio:

- captureImage:

- openMail:

- openSMS:

- openApp:

- openInAppStore:

- openCamera:

- openImagePicker:

- ...

MSageCoreLocation

- start:

- stop:

- setTimer:

- returnLocationInfo:webViewId:

- ...

MSageCorePluginFileModule

 

- createDir

- deleteDir:

- deleteFile:

- createFile:

- getFileContent:

- ...

MSageCoreKeyChain

- writeKeyValue:

- readValueByKey:

- resetValueByKey:

MSageCorePluginNetWork

- sendHttpGet:

- sendHttpPost:

- sendHttpUpload:

- ...

MSageCoreEncryptPlugin

- MD5Encrypt:

- SHA1Encrypt:

- AESEncrypt:

- AESDecrypt:

- DESEncrypt:

- DESDecrypt:

- XOREncrypt:

- XORDecrypt:

- RC4Encrypt:

- RC4Decrypt

- ...

Table 1: Selected interfaces exposed by msageCore

The selected interfaces reveal some of the key capabilities exposed by the potential backdoors in the library. They expose the potential ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

Beyond the selected interfaces, the ad library potentially exposed users to additional risks by including logic to promote and install “enpublic” apps as shown in Figure 4. As we have highlighted in previous blogs [footnotes 3, 4, 5, 6, 7], enpublic apps can introduce additional security risks by using private APIs in certain versions of iOS. These private APIs potentially allow for background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations. Apple has addressed a number of issues related to enpublic apps that we have brought to their attention.

Figure 4: Installing “enpublic” apps to bypass Apple App Store review

We can see how this ad library functions by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

Figure 5: Capturing audio with duration and threshold

Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

Figure 6: Reading the keychain in the kSecClassGenericPassword class

Remote control in msageJS

msageJS contains JavaScript code for communicating with a remote server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

Figure 7: The file layout of msageJS

The command execution interface is constructed as follows:

          adsage.exec(className, methodName, argsList, onSuccess, onFailure);

The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

adsage.exec("MSageCoreUIManager", "captureAudio", ["Hey", 10, 40],  onSuccess, onFailure);

Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

Figure 8: Base64 encoded JavaScript component in Zip format

When msageJS is launched, it sends a POST request to hxxp://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9.

Figure 9: Server response to msageJS update request via HTTP POST

Enterprise Protection

To ensure the protection of our customers, FireEye has deployed detection rules in its Network Security (NX) and Mobile Threat Prevention (MTP) products to identify the affected apps and their network activities.

For FireEye NX customers, alerts will be generated if an employee uses an infected app while their iOS device is connected to the corporate network. FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users will receive on-device notifications of the risky app and IT administrators receive email alerts.

Conclusion

In this blog, we described an ad library that affected thousands of iOS apps with potential backdoor functionality. We revealed the internals of backdoors which could be used to trigger audio recording, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these potential backdoors in ad libraries could be controlled remotely by JavaScript code should their ad servers fall under malicious actors’ control.

[2] http://www.adsage.cn/
[3] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html
[4] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html
[5] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html
[6] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html
[7] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell