Everybody Gets One: QtBot Used to Distribute Trickbot and Locky

Posted on by Brandon Levene

Introduction
The most common Locky and Trickbot affiliates are being distributed via shared malspam campaigns. Unit 42 and external malware researchers believe the payloads are geo-targeted. Previously, geo-targeting was controlled by a relatively simplistic VBA script which utilized GeoIP lookup services and parsed the country code to determine the compromised host’s location. With this information, the VBA script would enter a loop checking for the presence of the country codes: UK, IE, AU, GB, LU, or BE and, if any of those country codes was present, URIs to serve Trickbot were selected for download and execution. If this check failed, Locky would be served instead.
Recently, Unit 42 researcher Brad Duncan observed Necurs malspam campaigns distributing Microsoft Office documents that were abusing DDE. These documents load an intermediate downloader which we have tagged in AutoFocus as “QtBot”. QtBot replaces the previously discussed VBA and features a robust anti-analysis suite to protect itself. This new downloader is responsible for loading the final payload, either Locky or Trickbot, again based on GeoIP. Palo Alto Networks has observed more than 4 million unique sessions with QtBot activity since October 19th, 2017.

The Lure
The malicious DDE documents are included as attachments to malspam lures like the one below (seen 10/24/2017):
QtBot_1

Figure 1. Shows an example email lure with a malicious document that uses DDE to deliver a payload.

Typically, these lures are very simple. Most of the observed lures fall either within the “Financial Statement” category (Invoice, Billing, Receipt) or “File Transfer” category (efax, file scan). This campaign relies on the user to download the attachment, open it, and click through several dialog boxes. The attached document, bb92218314ffdc450320f1d44d8a2fe163c585827d9ca3e9a00cb2ea0e27f0c9, contains the following DDE object:
[URL Defanged]


Network Traffic
Let’s examine the network traffic. Immediately following the user’s click-throughs of three dialog boxes, the following HTTP GET request is issued. Interestingly, its likely this initial command and control server is simply a compromised webhost running a vulnerable version of PLESK as can be seen by the X-Powered-By header in the HTTP response.
QtBot_2

Figure 2. DDE downloads a base64 blob for execution. Also, an interesting note: this initial server hosting the  scriptlet is using PLESK and is likely compromised.

The base64 blob decodes to the following [URLs defanged]:

The entire list is iterated over until a valid download location is found (this can be observed in the cmd.exe window which is spawned in the background by the initial DDE execution). Once a live command and control server responds, the QtBot binary (798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120) is downloaded in the clear.

QtBot_3

Figure 3. Download of the QtBot downloader, with the executable in the clear. Note that the Content-Type doesn’t match.

Once the QtBot binary has been downloaded, its executed from the user’s %temp% directory using the PowerShell directive Start-Process which can be seen in the decoded base64 blob included in the code block above. When QtBot is started, it initially performs a connectivity check to the legitimate domain, ds.download.windowsupdate[.]com, via an HTTP POST request.

QtBot_4

Figure 4. Downloader component issues a request to an innocuous domain as a connectivity check.

Finally, once the connectivity check passes, QtBot will beacon back to its command and control server using an HTTP POST request with an RC4 encrypted payload and await a response which is encrypted with the same RC4 key. The User-Agent “Windows-Update-Agent” in the connectivity check, initial check-in, and final payload delivery are all identical.
For the network traffic below, we will use the QtBot sample, d97be402740f6a0fc70c90751f499943bf26f7c00791d46432889f1bedf9dbd2, as at the time of analysis the command and control server was still live and serving geo specific payloads.
In cases where the geolocation matches a set list (we believe this list is likely identical to the earlier VBA discussed in the Introduction section), we will see the traffic below.

QtBot_5

Figure 5. The downloader Trojan posts data back to the command and control server. This likely determines geolocation based targeting, this request led to the download of Trickbot as we used a UK based exit point. Trickbot download can be seen in Figure 6.  Note the user-agent header is identical to that of the connectivity check in Figure 4.

Due to the host being within the UK, we received an encrypted Trickbot payload. The decrypted Trickbot observed in the request below is 4fcee2679cc65585cc1c1c7baa020ec262a2b7fb9b8dc7529a8f73fab029afad.

QtBot_6

Figure 6. Payload downloaded by the intermediate downloader. In this case, Trickbot.

In the following figures, we see a host POST data back to the C2 and receive a slightly different response. This is because the host is in a location not specifically targeted for Trickbot delivery. Thus, we expect to see a different download location and likely a Locky payload.
QtBot_7

Figure 7.  The downloader Trojan posts data back to the command and control server. This likely determines geolocation based targeting, this request led to the download of Locky as we used a CA based exit point. Locky download can be seen in Figure 8.

Below we see a different payload from a different location due to the server’s response. In this case the payload is an encrypted Locky binary. This decrypted binary is 9d2ce15fd9112d52fa09c543527ef0b5bf07eb4c07794931c5768e403c167d49.
QtBot_8

Figure 8. Payload downloaded by the intermediate downloader. In this case, Locky.

With the network behavior laid out from initial execution to payload delivery, lets take a closer look at the intermediate downloader, QtBot.

QtBot Analysis
The QtBot downloader is a Windows executable file that decrypts an importless stub into memory. This payload is later injected into msiexec.exe using common techniques.  The payload then decrypts the second stage shellcode and injects it into a newly spawned svchost.exe process.  This svchost.exe acts as the handler for the final payload.
When QtBot initially executes, a new thread is created which is responsible for process scanning. This process scanning is used to identify analysis tools and, if any are found, terminate the malware’s further execution. This check is periodically repeated on a loop. Process hashes are calculated by lower casing the process name, calculating the crc32 of the result, and XORing the crc32 value with 0x2e5d47c8.  The XOR value appears to change on a regular basis, thus the hashes below only apply to 798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120. The following hash values are checked against running processes:

The payload then creates randomly generated numerical mutex along with the registry key “HKCU\Software\QtProject”. This registry key has been used in the past by legitimate Qt framework software and is not strictly to be considered malicious on its own.
Once the mutex and registry string are created, the malware uses RC4 with a hardcoded key to decrypt numerous strings which are reproduced below (note these strings are from 798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120):

The hardcoded RC4 Key, 0x7A3C5B7CB7FCE715702AA0F4F4EC0935E759FD3B7B6BCC70159D61CF42814B81, is reused throughout this campaign to encrypt and decrypt network communications.
QtBot includes a function which checks for the keyboard layouts common to former USSR countries, if any are found, execution is terminated. This routine is shown below:
QtBot_9

Figure 9. Keyboard layout checks in order to prevent infection of former USSR countries.

For persistence, a temp file is generated with a randomly generated name and stored in %APPDATA%\Local\Temp\ in a randomly named folder.
This randomly generated value is used for the folder name and is stored in the registry key “HKCU\Software\QtProject” in the value “0FAD2D5E”. The malware stores additional encrypted data in this key:
“0FAD2D5E” – Random Value + Unicode temp file name + length of data blob
“0FAD2D5EDZCW” – RC4 Encrypted C2 Domain
Successful malware communications use a format string like the one below:

When this is filled in, it would look similar to the following:

Some of these values are unknown, though we are able to speculate the nature of their meanings.  We believe they are as follows:
"rep" – communication attempt repetitions from a single host
"bid" – binary identification; this value is stored in registry value "0FAD2D5E" and is RC4
encrypted and base64 encoded before sending
"ver" – likely versioning information
"cam" – campaign name
"cis" – unknown hardcoded value
"lvl" – system integrity level
"adm" – if the malware has administrative privileges
"bit" – unknown
"osv" – operating system version
"osb" – operating system build
"tmt" – timeout in seconds

Similarities to Andromeda
Existing analysis of the Andromeda loader and bot reveals some commonalities between Andromeda and QtBot.  The most apparent similarities of these two families are the running process hash check  used for anti-analysis, host infection denylisting based on language identifiers returned from GetKeyboardLayout, separate infection and task reports for C2 reporting, and code injection target, msiexec.exe.  At this time due to the seemingly major updates to the base Andromeda, which is still active, we are referring to this particular family as a new entity and have created a separate identifier in Autofocus, QtBot, to help users differentiate.

Conclusion
While geographic location specific malware delivery is not a new phenomenon, the combination of two previously disparate malware family affiliates utilizing unified malspam campaigns and droppers is an interesting shift in tactics. QtBot protects itself and the decision tree by which targeting is established and offers a significantly more robust anti-analysis package to stymie analysts.
Palo Alto Networks has observed more than 4 million unique sessions with QtBot behaviors which can be seen with the QtBot tag in AutoFocus. Customers using Wildfire are protected from this threat.
Palo Alto Networks would like to thank researchers at Proofpoint, who identifies this threat as "QtLoader", for first bringing these campaigns to our attention.

IOCs
798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120 – QtBot
d97be402740f6a0fc70c90751f499943bf26f7c00791d46432889f1bedf9dbd2 – QtBot used for payload differentiation screenshots
bb92218314ffdc450320f1d44d8a2fe163c585827d9ca3e9a00cb2ea0e27f0c9 – DDE Dropper
9d2ce15fd9112d52fa09c543527ef0b5bf07eb4c07794931c5768e403c167d49 – Locky
4fcee2679cc65585cc1c1c7baa020ec262a2b7fb9b8dc7529a8f73fab029afad – Trickbot
hXXp://hobystube[.]net – Locky Download Location
hXXp://kengray[.]com – Trickbot Download Location
hXXp://fetchstats[.]net – QtBot C2
hXXp://toundlefa[.]net – QtBot C2
hXXp://aurea-art[.]ru/incrHG32
hXXp://castellodimontegioco[.]com/incrHG32
hXXp://nl.flipcapella[.]com/incrHG32
hXXp://dotecnia[.]cl/incrHG32
hXXp://christakranzl[.]at/incrHG32
hXXp://burka[.]ch/JHhdg33
hXXp://celebrityonline[.]cz – URI varies based on payload

Tracking Subaat: Targeted Phishing Attack Leads to Threat Actor's Repository

Posted on by Unit 42

In mid-July, Palo Alto Networks Unit 42 identified a small targeted phishing campaign aimed at a government organization. While tracking the activities of this campaign, we identified a repository of additional malware, including a web server that was used to host the payloads used for both this attack as well as others. We’ll discuss how we discovered it, as well as possible attribution towards the individual behind these attacks.

 

The Initial Attack

Beginning on July 16, 2017, Unit 42 observed a small wave of phishing emails targeting a US-based government organization. We observed a total of 43 emails with the following subject lines:

  • Invention
  • Invention Event

Within the 43 emails we observed, we found that three unique files were delivered, which consisted of two RTFs and a Microsoft Excel file. Both RTFs exploited CVE-2012-0158 and acted as downloaders to ultimately deliver the QuasarRAT malware family. The downloaders made use of the same shellcode, with minor variances witnessed between them. Additionally, the RTFs made use of heavy obfuscation within the documents themselves, making it more difficult to extract the embedded shellcode.

The Microsoft Excel file contained malicious macros that resulted in dropping and subsequently executing Crimson Downloader. The Excel document contained a UserForm that in turn contained three text boxes. The embedded payload was hex-encoded and split between these three text boxes. The malicious macro extracted this information from the text boxes, dropped it to a specific location, and eventually executed the Crimson Downloader payload.

Detailed information about these malware samples may be found in the appendix of this blog.

A curious aspect of this campaign is the use of Crimson Downloader in this email campaign. To date, we have not widely seen Crimson Downloader being used: in fact, we have only seen 123 unique instances of this malware family being used to date. Readers may recall a previous blog post from March 2016 that discussed Crimson Downloader. That blog post discussed relationships with both Operation Transparent Tribe and Operation C-Major, which were both targeted campaigns that made use of Crimson Downloader aimed at diplomatic and political targets. The connections we observed in this research leads us to believe there might be a connection between this most recent activity we observed and those campaigns. However, there is not enough evidence to say so decisively.

 

Expanding the Scope from the Original Attacks

When looking at the various malware samples encountered as we analyzed this campaign, we identified a total of three hosts/IP addresses, as shown in the following chart:

5.189.157[.]215 Crimson Downloader connects to this IP address.
115.186.136[.]237 QuasarRAT connects to this IP address.
subaat[.]com (Resolves to 23.92.211[.]186) RTFs download QuasarRAT from this host.

 

Starting with the first IP address that was used by Crimson Downloader, we can see that this address appears to be located in Germany and is almost exclusively associated with this malware family. Based on our telemetry, this IP address has exclusively been used to communicate with Crimson Downloader. We observed a total of 16 unique Crimson Downloader samples starting in May of this year.

Moving onto the second IP address of 115.186.136[.]237, we see that this IP address belongs to a Pakistan-based Internet Service Provider (ISP), based in Islamabad, that services both residential and commercial customers.

The subaat[.]com domain has historic WHOIS information from early 2016 that references a Pakistani location, as seen in the image below. Additionally, it uses pkwebhost[.]net for its DNS, which is a Pakistan-based hosting provider.

Subaat_1

Figure 1 Historical WHOIS information for subaat[.]com from early 2016

The references to Pakistan in conjunction with the use of Crimson Downloader, which has historically been associated with Pakistan actors, is certainly interesting.

The RTFs we observed in the original email campaign downloaded QuasarRAT from http://subaat[.]com/files/sp.exe. Checking this host led us to discover that directory listings were enabled. We were able to discover a large repository of malware on this open server.

Subaat_2

Figure 2 Open directory listing of subaat[.]com

Since beginning this research, this domain has been suspended by the hosting provider. However, it returned in mid-August, hosting both a malicious APK and a known instance of QuasarRAT.

Subaat_3

Figure 3 Subaat returns after suspension

In total, we found 84 unique malware payloads hosted on this server, in addition to a number of miscellaneous scripts. The chart below shows the malware families we identified:

Subaat_4

Figure 4 Malware families identified in web server repository

As we can see from the above chart, a wealth of different malware families were stored on this web server. Many of these malware families are considered to be commodity malware, or widely used by criminals. Palo Alto Networks has reported on many of these families in the past, including LuminosityLink, QuasarRAT, and DarkComet to name a few. The large number of commodity malware families paints a very different picture from the original attack that made use of Crimson Downloader, which is not a widely used malware.

A full list of SHA256 hashes associated with these samples may be found in the appendix.

One thing that caught our eye was the large number of LuminosityLink malware samples stored on this server. Looking at the embedded configuration settings for these samples, we see that they are all similar. The following example shows one of these configurations. A script written in a previous blog post was used to generate the output below, it can be downloaded here.

Subaat_5

Figure 5 Embedded configuration within LuminosityLink sample

The email address shown above is used to register a customer’s copy of LuminosityLink. All samples using this registered builder contain this email address. We found all 20 of the identified LuminosityLink samples contained this same email address. The primary domain shown above is registered to 115.186.136[.]237, which is the IP address used by QuasarRAT for Command and Control (C2) communications. Looking at other samples found within the web server repository, we identified a number of malware families communicating with this IP address, including the following:

  • QuasarRAT
  • LuminosityLink
  • Meterpreter
  • NJRAT
  • RevengeRAT
  • RemcosRAT

We also discovered that the email address discussed above was being used by an account on the popular HackingForum web forum service. The account in question that claims to own this email address is none other than ‘Subaat’.

Subaat_6

Figure 6 Subaat user mentioning the hotmail email address on HackForums

Looking at this user’s profile below, we can see their posting history: a total of 14 posts in the past two years. We also see a date of birth of 2/24/1990, stating that the individual is 27 years old.

Subaat_7

Figure 7 Subaat profile information

A quick look at the posting history indicates that this person was inactive starting around December 2016, but returned to posting in early July of this year. This is in line with the campaign witnessed against a US-based government organization that took place on July 16th. The posts look to be related to various Office exploit builders and crypters. This again is in line with both the campaign we witnessed as well as the various malware we identified on subaat[.]com.

Subaat_8

Figure 8 Subaat posting history

A Look Behind the Scenes

Looking at logs for the subaat webserver between July 1st and July 20th shows the IP address of 115.186.136[.]237 uploading and interacting with a number of malicious files. We found interactions with a total of 64 unique files during this period. Below is a chart showing the attacker at this IP address interacting with some of the more popular malware families that have been identified.

Subaat_9

Figure 9 Interaction between attacker and web server

As we can see from the chart above, a spike of activity took place in the July 11th to July 16th timeframe. This again is consistent with the email campaign that took place in the midst of this period. A number of malware families have been used by this specific attacker, and many of them are configured to communicate with 115.186.136[.]237 as the C2.


Conclusion

What started out as a simple look into what appeared to be a targeted phishing campaign turned into much more. By the end of this research endeavor, we have identified a server hosting a large number of malware samples that has been primarily used by one specific IP address. This IP address not only interacted with this web server, but also acted as a C2 server for many of these malware families. While looking at malware associated with this actor, we discovered an email address that is tied to a user account on HackForums that has a name consistent with the domain used to host the actor’s malware.

We saw similarities this campaign and both the Operation Transparent Tribe and Operation C-Major campaigns. Additionally, there is marginal evidence that suggests that the attacker may be based in Pakistan, which is again in line Operation Transparent Tribe. However, the overall evidence is not conclusive, and there is insufficient proof to say decisively that this is the same threat actor.

Palo Alto Networks customers are protected by this threat in a number of ways:

  • All identified samples are flagged as malicious within the Palo Alto Networks platform
  • All domains identified within this research have been appropriately marked as malicious
  • Traps correctly identified and blocks the exploits using CVE-2012-0158 and CVE-2017-0199


Appendix

Analysis of Malicious RTF Documents

The two identified samples that were used in a campaign against a US-based government organization has the following SHA256 hashes:

0ade053b355eca7ae1fccea01fe14ff8d56a9d1703d01b3c00f7a09419357301
9a57f96a3fd92b049494807b6f99ffcd6bb9eb81f4f5b352d4b525ad32fac42d

These samples varied in size greatly, however, the underlying shellcode was consistent. One notable difference observed in one of the samples (0ade05…) was the inclusion of injecting the shellcode into a newly spawned instance of svchost.exe.

When the shellcode begins, it will start by loading a number of functions that are used to inject code into svchost.exe. The following Python code demonstrates how this hashing function operates:

Subaat_10

Figure 10 Python code demonstrating API hashing technique #1

The shellcode continues to decrypt a blob of data using a 4-byte XOR key of 0x8F51F053. This blob contains a series of important strings, such as the URL and filename, as well as functions that will be used to download the payload.

After this blob is decrypted, flow control proceeds to this blob’s code, where the shellcode will load multiple libraries and functions using a specific hashing algorithm.

The shellcode continues download a file to the %TEMP% directory from the following URL:

  • http://subaat[.]com/files/sp.exe

The shellcode proceeds to execute this newly downloaded file prior to exiting.

 

Analysis of Malicious Excel Documents

The identified sample that was used in a campaign against a US-based government organization has the following SHA256 hash:

e3243674aa3661319903a8c0e1edde211f1ffdeed53b305359d3390808007621

When this sample is initially executed, it will attempt to run a malicious macro that is embedded within the file. This macro begins by determining where a dropped file will reside. It will attempt to find the following folders residing within a user’s profile path:

  • /Documents
  • /Downloads
  • /AppData

Subaat_11

Figure 11 Macro determining file path

The payload itself is stored within text boxes in a user form within the Excel document. This data is extracted and hex-decoded. The three blobs of data are concatenated to form a proper PE32 executable.

Subaat_12

Figure 12 Macro loading data from text boxes

A quick look at the included user form gives us a better view as to how this data is stored.

Subaat_13

Figure 13 Embedded user form with three text boxes

The following example Python code demonstrates the hex-decoded data shown in the highlighted text box above.

Subaat_14

Figure 14 Python code hex-decoding the stored data

After this data is properly handled, the macro will drop this file with an extension of .scr to the designated file path. It is then executed in a new process. This newly spawned process is an instance of the Crimson Downloader malware family.

 

SHA256 Hashes

c4c478c5486a09ac06e657ace2c1edb00cc690a2ff3558598e07687aa149df71

6b6ff0bef244732e90e7a8c200bcd1d8db6f58fe4da68889eb847eb1b6458742

07cb90288ae53643a4da291863df6c9be92bfd56b953073e30b7c28c777274fc

66ef8f3660902cba0ca9bebd701d322aff1d5a13de0cf63cf3f1b8841e08efc6

20c949ca25fed25918e524dde67ffe44efb1c974a5ed68d519b77354303c4916

007e4b308a69d6c3dba5a01f754a63231b996f1a68ff43ec9b5906f583f0fc6b

f7d2f547d5ab07abf59f97fb069288d682a20bc9614642777d11c7db76b36f39

20e368b0d0288b968fed7193c965a7c7ecf3e731eb93a4cbd4420242fad7ce8c

9ddc4ba7a8025598b6a8344c5537af3e2ae6e6db8356dcbfc9ad86b84dee87af

95c00b3de53c0b5742c182f9221a3086bf046ad8da57c915e8c0b6dc5180fd7f

0804202f46dc94768820cb0915b8d2b36602575ac78e526ea7f518e584069242

914b6f21297ebb81621b6da00edcda59b4c1fdd06329ed7a587c9a9b09915583

2a73231d0480f7481737256a8dca6b2549db982cc10f1761c2a267eb85dcaca4

67d4ab365f1630e750aee300f14fbfc940ea235647014030bd56c4127933834b

41efb2f1cb81160539058d8fc2ca8c037692803dcb8b332c660233bffe5bf874

e51b8bf7cc72b47c8ee59056fabd2af1795152d8df33967949d2d2a0996cc51b

4c6f7aafc2e4d8b0b7e7f21cbb102e02dc314eeb2f8e754f59ea471f58cabda0

3a664210955a82d961480adcc914456931325268ccf26c09d0275ca1d2ff35f1

5cc14c2bc185121391a7c43e3e65ced4697274e93fe42f28f20c067dde7e9f1d

f19480d36453da029247fbd066c7f0c1b28912bbefafd052b1d4ee9a64eb9e31

6bbb87f05d9d987a3df3bb585de3f2fad5d5cd3f11a0e3c4587255c55a9fe2a5

75da69e466183b0d004719d32f779cd5b7849a6dac0b6303e11db543c0ddec32

a0a2edcd19a581aeba3de5bbca21065425fbf34fd1a798269ff99bd8af8bf847

2c34565535a0f90b469f0e100d9027190d3cd812bd824aa6af73b4884690a395

50c4f3d3335daf84d507ed2663a411d2ce39e9def172ddbaf7ade0f2ce0f2736

a8445387cb7e4bc79da34d371eedf50f265e145ce8f48c64aeff2690ed7f8b10

7218bc4e9b8817eff678422a9125a852c3f66ecf275aa691433dd8cd4910f66d

106938bff25de67513acc809c4c77b2aa9e9974ec8bf4d20bad154015abc77be

85116c4f9695bf15fe3fdcb20cff8634971e39c2b97b1a159446fa6cdf05e913

253bb91003a8c295a70240206605542147d7b9fdc2d26ac999772b3b78db3a80

2d5abd4cc322d5802617d6a1cd3fc22403052e2711bf6bd76976ab7d1cea45cf

e0d6e8584f2d3d6d807ad2fe9d2fccc792635e8e3ab0132f3b5dedc0394019c9

625f30d4abd89b94c1f732463202c51cd9424a1bcbf2e72a9779773c0f82f93c

6807c25ead1c377c975c84a214da8a68482623658369a02ce56b531d6f38a5b6

dfb984ea975ca992e1a0f9a6d30a41057edd36b170704b7831f609f44f80ad8d

ed9fb1d8c36fb60c808006ae63908980a259cb73ed44adf19856ea6c239d1eab

1f286fff72a562cd327985a1b57316364710f2cbfeedc46d12dc8d21b4611ecb

4da2fd94b4f21a346ebfa5d8793dd60a1d4200dfe6b91517a70aed4c0b59a4d4

983bc61d569839558e2a2ef2a53174efe45be4e65da991268ce1926beb4e3505

7b1ab4513788ef4b6628911ba6ed6362eb357b66d18f6988fb4ceffb20ee1d91

8c93d054d4ef93f695da9693f6de538e269b39320c934428f27cc22ef6b2d89e

cd873eaded83861c4f59bfb5c902b43bfd7f5ecb13eccc385498ad9564085e97

e63f0ab5413b0013d79c57f8132c21c0c9397c88caa01edbb4fbe6c2db4932a0

24bc5f9aa78d91d6c8641b90cac6d3c3e7ddf4b30a992a9129d73c5edb04f80f

89ac4eeaecd38fcb2eb8e0bacd156b6133a6093f44622f7d82e22493a69cafb7

07abc1eb421baffe4f894406c1435b3daf8d1dcfba53d8e4e8f584cf72d08110

2941360679ea485798e324e3538c358cf6cba65959ebf28df9fd4a5492bf2888

dbac3abbaaea59c8287d3ed47cac07aeca952a3620eda4559c2bf0f3f611d52e

efca910066b59ca833c7291d07f18922cf5e3e2301c5fd95b7acd50f195fc580

a331276b9810ebc131daf883887a0ba8ab0fb5e6ea4671b12249c1be1755fce8

31d94441009e7ea50d880e1dcc9e09890f1139bce9edc847b05f2c5ac355695e

c3eeb0677dcbfe4edb6cca9c5bac34ae80a5906b76676548ef0e5110f3ddd4c3

e68ea3c3c9bb0d5b0d4f940b0cbbfb6913a47bb6f345b54f487241fc4eec4b31

83810647cd0c398ad05dec63c41756bf5fbfd1b0658379753c157e7b1f45aed3

dfb4f62c609be0295ef1c4fcd59c5897fbd0ad40a82d00a93e7f3bdadcc1d320

23180df75c5b9293f3743ea27c09ce471f1f5541cd668ac22c16e41f1ff7b4da

ef09065b95d0ea2e02384828e5616fc6f9ededadb2b4719078904c50d2ed4307

923818d36ff1fd94829424847ac20ab7d77432b133cdb5cb1a1be87ec0e1b617

4cbc47fe5d82145265e8dbc9e81ab6afa9a0a4f3c6dd8c15ce2af09584278517

670e45f3e2fbb635df00790d90a5cf8bc950440a935b38c2bb71f0c463c24b3b

2551d883d3e66a3e7bcabc052be2e503808df570c03d816ddfb83bf6e686a5f6

712a8fa4308de2ba1a83545e96539092215c75bfa8b63b33ee1a739cc6522873

7e09b6d96d7034f1ac5947355dba360cc49f53d4c0c89aab05c1ef6cc2d0a213

801bb690dd2ecd3877b014030dfca40f3b7d964fdb8e1ab1252352212e24f777

fae9b4a92277e227f6122794ef366dba49c045add9569e9a0d8fc66196c5c787

2bfbd56ee421b8aab3dd3d1f9e9a2d512556a4e0440c8f04e94d6ad5b584e43c

35bc123df7bfc8f9239af3fa14350091c513e7b1d42b93a8dca39e131c48c052

87d122b7b99735689713ff51650b6a331d9c4d7f7617fc15b7e07b0225b60c2a

0b2a6225d209783672900d1b8e0b19957cb924f0111d0be347dead9520ad745a

5f3845a1e3d2f3d09c3ffff4a71e04f61d995aae54311d4c9ab88ff65803d131

5c361d57ac83936d08c4a93208142b7397d6074bbf6e24cb6cee0e3e3e5351b3

ea35cf979b358c1661b4b1b9465a700925bdf4ba227989b47127270e32345f29

44963748c947e0f5d21d353e6e5ceb3b6a64fd0b4ad28540ab47bdf2422e9523

1d4f20832e641a1cedd598e187614b78ba3d5930c6dcd71e367b254664cb9b2e

050123edd0d9ea5acf32314aa500467211d8f204f57627abc42937fe11f04382

4c806d18ba1cac5d83be7c05f43697d5124b910d2de8264cdff1d8f186a0a7dd

aec031e3747b00be2b0cc3a1d910ae18ada65452f3e70425cae86fe24d2996d4

5ac984bb11b989ef745c35dd2418eb5bd26a6bba291cf2ba7235bf46d3400260

0ade053b355eca7ae1fccea01fe14ff8d56a9d1703d01b3c00f7a09419357301

e3243674aa3661319903a8c0e1edde211f1ffdeed53b305359d3390808007621

9a57f96a3fd92b049494807b6f99ffcd6bb9eb81f4f5b352d4b525ad32fac42d

7bad7cbc32e83b8dfc4f6c95824ea45dcee2330de44d84c9bc551f99e6ca6faa

341403284158723f1f94897d257521a73fcfc8049b786f5004f60a063fb074f2

f68a169670bb3dc3bd0a2dc83120d34f59d7f4dacfdc98dbbd86931cdd4f7392

579c669bd8ec8dd393a836c6c27c86e40e8048fa5efbcfc03e027e69298f0e6a

19df2d2460be2f22f73ea7992470c5369599fba290c0f3dbc613ad35dc3ba18a

692997349c017c627c8779816bc41840dd7867b0c4d3bec99638bfba159675bc

c0658b5aa4e9bc2433557e65ad20ded6f91b3441dac72cb8c2ea7e1f2e43e05e

 

IP Addresses

5.189.157[.]215

115.186.136[.]237

 

Domains

subaat[.]com

hassanusauae786.hopto[.]org

Threat Brief: Information on Bad Rabbit Ransomware Attacks

Posted on by Unit 42

This Unit 42 blog post provides an update on the threat situation surrounding the Bad Rabbit ransomware attacks.

 

Attack Overview

Bad Rabbit is a ransomware attack that, at the time of this writing, appears to primarily be affecting countries in Eastern Europe. While not spreading as widely as the Petya/NotPetya attacks, reports indicate that where Bad Rabbit has hit, it has caused severe disruption. The Ukrainian CERT has issued an alert on Bad Rabbit.

As detailed below, Bad Rabbit gains initial entry by posing as an Adobe Flash update. Once inside a network it spreads by harvesting credentials with the Mimikatz tool as well as using hard coded credentials.

Bad Rabbit is similar to Petya/NotPetya insofar as it encrypts the entire disk.

We are not aware of any reports of successful recovery after paying the ransom.

Because the initial attack vector is through bogus updates, Bad Rabbit attacks can be prevented by only getting Adobe Flash updates from the Adobe web site.

 

Reconnaissance

This attack does not appear to be targeted. Therefore, there appears to be little reconnaissance as part of this attack.

 

Delivery/Exploitation

According to ESET, the initial infection vector for Bad Rabbit is through a fake Adobe Flash update that is offered up from compromised websites. Proofpoint researcher Darien Huss‏ has reported this fake update was hosted at 1dnscontrol[.]com. Reports differ on whether this is delivered through social engineering that convinces the user to install the fake update or if it is delivered silently through unpatched vulnerabilities (i.e. “drive-by” installs).

 

Lateral Movement

Once inside a network, Bad Rabbit propagates itself to other systems. Reports indicate that it harvests credentials using Mimikatz and Maarten van Dantzig reports it also uses common hardcoded credentials to spread.

 

Command and Control (C2)

At this time, we have no information on command and control for Bad Rabbit.

 

Conclusion

Bad Rabbit is not as widespread of an attack as Petya/NotPetya but is causing severe disruptions where it is occurring. It is similar to Petya/NotPetya in terms of the impact of a successful attack. However, it is a different attack with different malware.

We will update this blog with new information as it becomes available.

For information on how Palo Alto Networks products prevent Bad Rabbit, please see our Palo Alto Networks Protections Against Bad Rabbit Ransomware Attacks blog post.

As always if you have any questions, please come to the Threat & Vulnerability Discussions on our Live Community.

 

Version Summary

October 24, 2017 2:30 p.m. PT

  • Initial Publication

2 Minute Threat Brief: Browser Cryptocurrency Mining

Posted on by Eila Shargh

Cybercriminals have embraced the anonymous nature of cryptocurrency as a new preferred method of profit. Unit 42 released details about attackers hijacking web browsers to mine for compute resources and exchange for cryptocurrency. With the increasing value of cryptocurrency, such as bitcoin and Ethereum, and a better business model with higher returns than malware- and exploit-type attacks, it’s no surprise these types of attacks are becoming more commonplace.

How It Works

Cybercriminals will compromise a website and abuse a legitimate tool on that site to gain access to the compute resources of site visitors’ systems. Using this access, attackers will essentially steal compute resources and exchange them for cryptocurrency credit. This all occurs without the users’ consent or knowledge throughout the duration of their site visits.

The malicious activity itself doesn’t cause long-term damage to systems, and ends as soon as users leave the malicious or compromised site. Additionally, the site will still provide users with its normal, intended functionality. However, users likely experience a noticeable slowdown in system performance.

How to Defend Against It

If you believe your system is being affected by this type of attack, leaving the site or closing your browser will, in most cases, end the attack. Additionally, you should practice good cybersecurity hygiene. This means avoiding unfamiliar websites, clicking on links or downloading attachments from unknown email senders, keeping products updated with the latest security patches, enabling multi-factor authentication, and using reputable security products.

BadPatch

Posted on by Tomer Bar

Introduction

In April 2017, in collaboration with Clearsky, Palo Alto Networks Unit 42 published an article about our research into targeted attacks in the Middle East. In that research we discussed two new malware families we named KASPERAGENT and MICROPSIA.

Since then, we have continued our research into the Command and Control (C2) infrastructure associated with KASPERAGENT and MICROPSIA. This ongoing research lead us to a new Middle Eastern campaign. Our findings from this new campaign include C2 infrastructure, new attack methods, four types of malware (including Android malware), a system for management of stolen victim data and some detail of the actors.

It is notable that our research has shown that this newly-identified attack campaign dates back to at least June 2012, over five years ago.

In this blog, we outline the results of our research into this new campaign so far.

 

Finding the New Campaign

Our discovery of this new campaign begins where our previous KASPERAGENT and MICROPSIA research left off.

Pivoting from Previous KASPERAGENT and MICROPSIA Research
One of the C2 servers we observed in our earlier KASPERAGENT and MICROPSIA research was mailsinfo[.]com. The first IP address that this domain resolved to from about mid-May 2015 through October-November 2015 was 148.251.135[.]117.

We used passive DNS (pDNS) and found the server mail.pal4u[.]net on 148.251.135[.]117 starting mid-May 2015. We also found other servers on this IP address. We do not believe this necessarily gives a link between campaigns found on this IP address as it appears to be shared by multiple unrelated third parties. However, the nature of activity and some malware artifacts on this IP address does suggest a possible link to the Gaza Hackers group.

 

C2 Infrastructure

As we followed our leads from the previous KASPERAGENT and MICROPSIA research and dug into the server mail.pal4u[.]net on 148.251.135[.]117 that research led us to find the C2 infrastructure of this new campaign.

Digging into Pal4u
The WHOIS for pal4u[.]net appears to be a Palestinian hosting company. The DNS records for pal4u[.]net gives us, in addition to the “WWW” hostname, the Name Servers (NS) “NS1” and “NS2” and additional IP address 195.154.216[.]74.

We found six additional domains that used palu4u[.]net as NS, and which all shared the same historic IP address 195.154.216[.]74 (Figure 2). From the seven total domains, we observed six as malware Command & Control (C2), exfiltration, malware download servers, and/or in associated malware code:

Pal4u[.]net

Pal2me[.]net

Pay2earn[.]net

Shop8d[.]net

Ts4shope[.]net

pal4news[.]net

We only found one of the seven domains associated with this IP, ads4market[.]net, not associated with malware activity. We did not find any legitimate activity or content associated with these six domains during the period of associated registration.

badpatch_1

Figure 1- C2 domain links

While there is historic WHOIS for pal2me[.]net and shop8d[.]net, research into the registrant information suggests this is related to the ISP rather than the actors using the site for C2.

We also found the DNS RNAME “a.faris.live[.]com” was used, but this also seems to be related to the host ISP rather than the site owner.

Understanding that we were looking at a collection of linked malware C2 servers, we started to look into the attacks methods and malware that used this infrastructure.

 

Attack Methods

We observed initial attacks using this infrastructure were against victims via spear phishing. However, for the first time in any known Gaza Hackers-linked campaign, we also found a limited use of vulnerability exploits – RTF exploit CVE-2012-0158 documented by Citizenlab (Part 3 – “The Curious Case of the Shared Exploit”). The attackers used the RTF exploit to download their “BadPatch” Windows malware from hacked WordPress site wp.piedslibres[.]com/wp/wp-includes/js/Next.scr.

SHA256 d759dcbebee18a65fda434ba1da5d348c16d9d3775fe1652a1dacf983ffc93b8
First seen 2015-05-13
Filename لمستجدات.doc , (Developments.doc)

 

We found a second attack sample that used the same exploit, that also downloaded the same malware from the compromised server.

Filename 6660491190525a7413b683b91a6c8b0082aa71e6dd6291d11ec26e1e3cf55a57
First seen 2015-06-15
Filename تسنيم.doc (Tasneem.doc – the military organization of Fatah (political Palestinian movement))

 

In most of the attacks we observed the malware will display a blank Microsoft Word decoy file, or a Microsoft Word file with error message:

"An error occurred, please try your request again later".

We did observe some variations in this attack. The first malware sample that we identified (compiled on 12 June 2012) dropped an Adobe Flash decoy file (Figure 2):

SHA256 92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812

badpatch_2

Figure 2- Adobe Flash decoy

Samples typically employ decoy filenames tailored to the spear-phished target:

SHA256 30282a807c2ee27b0d1dda310e41487f5018bc5fc5df8af6c13d08df34f2b6df
Filename عاجل جدا وسري جدا.gz (Very urgent and very confidential. Gz)

 

SHA256 cc8020c36156c7e5c8cfbbb32bc8d7f03536510f4e3b38b22e0abdb9ad90c90e
Filename ,اسماء المستحقين للمالية.scr (The names of the beneficiaries of Finance. scr)

 

SHA256 1a65e43afaaff90b4124cbef21fadc319f10fba4843d09837219400b0dbcc285
Filename الهباش يتحدى حماس الاعتراف.scr (Habash defies Hamas recognition.scr)

 

SHA256 2c64a3d6b896ee1b58b9cf55531b7256de45025d60b1f4be764b385de087b52f
Filename Statement of Account-ARABBANK.exe

 

Malware Analysis

We collected 148 malware samples in this campaign, using the C2 servers that we identified, and grouped them into four categories:

  1. Microsoft Visual Basic Malware – exfiltrates data via SMTP (port 26), and HTTP.
  2. Autoit malware – early versions also used SMTP for exfiltration, but mainly HTTP.
  3. Autoit downloader & dropper (downloads and executes the Autoit malware)
  4. Android malware – exfiltration via HTTP (first seen December 2015)

Microsoft Visual Basic malware

Upon infection the malware copies itself to %appdata%\microsoft\microsoft [0-9]{9-15}\dwm.exe (9-15 digits in directory name “Microsoft”), and adds a link to the malware executable in the startup folder for persistence.

These variants include system information collection (operating system, computer name), keylogger output, and browser password collection from Internet Explorer, Chrome and Firefox.

Keylogger and system info exfiltration is done via HTTP Post:

lms/getdata.php?myAction=add_line&macName=…$&computer_id=App.EXEName&mac_address=…&dns_domain=nnn&domain=bbb&content2=$FRESH:%20%20ESC%20pango2012ENTR&ver=3&mac_time=tt&patch_user_id=mgh2&patch_group_id=Label1(2).Caption

File exfiltration is done via SMTP port 26, with the SMTP credentials hardcoded encrypted in the malware code. Some mailbox examples:

user: sender_b@pal4u[.]net
password: sender@123

ubuntu_net@pal4u[.]net

ubuntu_send@pal4u[.]net

badpatch_3

Figure 3- SMTP encryption settings

The list of files for exfiltration are written to the malware folder as “sysfiles.txt”. A file “1.done” is generated with content "done" after successful exfiltration. The file “mac.txt” contains the computer MAC address. Some versions exfiltrate recent files, others collect and exfiltrate files matching a hardcoded extension list:

*.xls;*.xlsx;*.pdf;*.mdb;*.rar;*.zip*.doc;*.docx

AutoIt Malware
We observed a shift from Visual Basic to  AutoIt malware in this campaign around March 2016. AutoIt is a freeware BASIC-like scripting language designed for automating the Windows GUI and general-purpose scripting.

This malware achieves persistence by writing to “%appdata%\Microsoft\Windows\Start Menu\Programs\Startup\Microsoft.lnk" using the WScript object.

It attempts to detect if it is being run in a Virtual Machine (VM) using a WMI query for disk drive name, BIOS, and motherboard:

  1. Checks for processes “VBoxService.exe", "VBoxTray.exe", "VMwareTray.exe"
  2. WMI query on Win32_DiskDrive, looking for "VBOX HARDDISK","QEMU HARDDISK","VMWARE VIRTUAL IDE HARD DRIVE", "VMware Virtual S SCSI Disk Device"
  3. WMI query on Win32_BIOS "Found Vbox BIOS version"
  4. WMI query on Win32_Baseboard “Found VMware-style motherboard”, "440BX Desktop Reference Platform". Name="Base Board"

The malware deletes Chrome and Firefox cached password files, requiring the user to re-enter site passwords, affording the keylogger the opportunity to capture them.

The malware can be instructed to kill the malware process by Process ID, or by hardcoded name.

It can update itself by downloading and executing a newer version:

h__p://m103.pay2earn[.]net/public/versions/["svchost" & $i & ".zip] (where i=1 to 7).

The new version is saved at %appdata%\Microsoft\updte\svchost.scr.

Environment data exfiltration via POST
It will perform a WMI query to enumerate installed security products.

It stores data in log files:

Specific attacker username stored at %appdata%\Microsoft\updte\usu.log

MAC address %appdata%\Microsoft\updte\mac.log

Errors are logged at  %appdata%\Microsoft\updte\log.log

This data is exfiltrated along with Operating System version and architecture using HTTP POST:

h__p://m103.pay2earn[.]net/devices/settings

/devices/settings?mac_address=<macAddress>&content=%20Start%20Downloader%20majdTest%201/2017Anti%20Type:%20%20%20OS%20Version%20=%20WIN_7%20|%20X64

h__p://m103.pay2earn[.]net/logs/new

/logs/new?name=<computerName>$&computer_id=App.EXEName&mac_address=<macAddress>&content=$%20Start%20Downloader%20%20majdTest%201/2017&patch_username=majd

Screenshots via SMTP

The malware takes screenshots on the victim computer, exfiltrating them using SMTP (port 26) as “GDIPlus_Image1.jpg” and “GDIPlus_Image2.jpg”.

The SMTP configuration is saved as encrypted RC4 strings, decrypted with password !@#$%^&*()

 

badpatch_4

Figure 4- SMTP RC4 encrypted strings init

Mail is sent, in this example, using the string "Start Downloader majdTest 1/2017".

 

badpatch_5

Figure 5- SMTP mail sending function

The emails are sent from an email address at the C2 server, to a recipient address on the same server. Decrypted example:

smtpserver:  m103.pay2earn[.]net

fromname:    sn@m103.pay2earn[.]net

fromaddress: sn@m103.pay2earn[.]net

toaddress:   asf@m103.pay2earn[.]net

username:    sn@m103.pay2earn[.]net

password:    sn_$_2016

We observed a single variant using an obfuscated AutoIt script (5c6e531738c1380ec09c1ec0f1438cee5077e6cbade8af87710b8be2f0aaaac7). Another outlier variant was keylogger-only, supporting intercepting only Arabic and English characters (42adec426addf3fd0c6aff406b46fa82d901f5a9bed7758a243458961349a362).

Autoit downloader / dropper
This simple component downloads and executes malware from the C2 server (e.g. pal4u[.]net or m103.pay2earn[.]net).

SHA256: 2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

This downloader example also displays a decoy file (bbb.docx):

SHA256: 2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

Android Malware
The actors do not miss the opportunity to also collect data from the Android devices of their targets.

As well as the typical ability to update the malware, this Android malware collects and exfiltrates device files, SMS messages, voice calls, and can also be used to remotely record sound or video using the device. A follow-up blog will examine this malware in detail.

 

Records Management System and Victims

The threat actors have developed their own, custom system to manage the data exfiltrated by their victims, "نظام إدارة السجلات" (“Records Management System”). Server logon requires 2-Factor authentication (2FA).

badpatch_6

badpatch_7

Figure 7- RMS SMS 2FA

Figure 6- RMS Logon Screen

During the course of our research, we observed a newly introduced bug in their authentication. Navigating directly to the page “sms.php” bypassed the initial password entry requirement, taking us directly to the SMS verification page (Figure 6).

Further, we discovered that navigating directly to “/lms/index.php” no longer redirects the user to login.php, but instead granted authenticated access to the system.

 

figure 8

Figure 8- Records Management System

This allowed us to enumerate the victims contacting the exfiltration server (Figure 9,) through March 2016.

 

badpatch_9

Figure 9- Victims by country

As reflects the nature of campaign, we notice a small overall number of victims. That the majority of victims appear domestic is also not unusual in such campaigns, although we also noted the actor infecting their own test machines in some cases (Figure 10).

badpatch_10

Figure 10- Testing Logs

 

The Adversary

We find some hints in sample filenames, Microsoft Visual Project directory names, and HTTP POST parameters, suggesting the names of some of the actors involved in this campaign, and a possible link to an official Gaza Bureau.

S:\sh\work files from shaaban\4shopfiles tajas\shop8d\Project1.vbp

C:\Documents and Settings\HADJYOUB.HADJ-1065B94515\Bureau\cm\Project1.vbp

Possible nickname strings that we observed include:

Shaaban, Hadjyoub, OMR, mgh2, rashed, Shady, majd , f2b, jno, ajr , hmg, vip, 2ta, asf, h2m, mag

Naming

The actors appear to name this malware “Patch”:

"\2014-03-17\exe\gaza\Project1.vbp"
V:\Batch Versions\

In Arabic, “P” and “B” are phonetically similar, leading to common B/P misspellings.

Embedded strings:

"Old - update patch and check anti-virus.. "
"PatchNotExit-- Check Version"
"PatchNotExit-- download now"
"PatchNotExit-- Version Patch"

Server communication parameters:

lms/getdata.php?myAction=add_line&macName=…$&computer_id=App.EXEName&mac_address=…&dns_domain=nnn&domain=bbb&content2=$FRESH:%20%20ESC%20pango2012ENTR&ver=3&mac_time=tt&patch_user_id=mgh2&patch_group_id=Label1(2).Caption

The “patch_user_id” parameter appears to refer to the individual actor managing this victim.

 

Age of Campaign

The oldest sample we observed has a compile date of 12 June 2012. The C2 server linked to that sample, pal2me[.]net, was also first registered on the same date. This campaign has been running for at least more than five years, and continues to this date.

 

Development Over Time

The oldest sample we observed (above) supported exfiltration of victim data using email (technique is detailed in the malware analysis section):

92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812
C:\Users\Shady\Desktop\only email with slide show\Project1.vbp

Keylogger functionality is introduced:

106deff16a93c4a4624fe96e3274e1432921c56d5a430834775e5b98861c00ea
E:\work here\ready kl send recent files\Project1.vbp

New keylogger version:

17a4126fb1fb19885d78c82271464d82af8618b7d1b7d8901666c1121ddb2ba1
D:\000 work\21.3 GB\newSpoofKL\Project1.vbp

New file exfiltration test version (details are in the malware analysis section):

9a8acd988089e7f9dd04f971374f766db519e854d42e8052b0d98b4c9c6b67e4
Y:\My Work\VB 6\Get Files\GFiles 14-09-2015 - Working tst only\Project1.vbp

Visual Basic versions, new downloader:

224b5af4ca4de234f03408487f075f0d638826cb6f65944a3e8dcbaac4372e79
Q:\newPatch\downloader\exe site\shop\Project1.vbp

Downloader version 2.8:

d906118fb36a0cc4e83121d4d606ad685645252e8e0791f793057499d8751bf0
J:\dowloader 2 8\downloader\site\Project1.vbp

Version M103, pointing at the currently-live C2 server m103.pay2earn[.]net. Current server registration dates to 8 February 2016, the compile date of this malware was 31 March 2016.

Sha256 - d9253c808d83ace06f885479e0807246a29cb9967ea0d0855f5a3802825b13db
W:\newPatch\exe vb m103 30 3 2016\Project1.vbp

Conclusion

Diligence in investigating infrastructure associated with a previously documented campaign, led us to another possibly unrelated campaign, crossing paths in hosting.

This allowed us to uncover a previously unknown C2 and exfiltration infrastructure, associated malware, and the first time that we’ve observed this group using exploits.

The simplicity of the malware and relative unsophistication of C2, exfiltration and stolen data management belies the demonstrated fact that this very targeted, low-volume campaign has been working fine for these actors for five years, and continues today.

 

Coverage

Palo Alto Networks customers are protected from this threat in the following ways:

  1. WildFire accurately identifies all malware samples related to this operation as malicious.
  2. Traps prevents this threat on endpoints, based upon WildFire prevention.
  3. Domains used by this operation have been flagged as malicious in Threat Prevention.

AutoFocus users can view malware related to this attack using the “BadPatch” tag.

IOCs can be found in the appendices of this report.

 

Appendix I – Hashes

1a0c0a0c74d085d6e90c5d96517926218fc55cc161f5c1e5dbb897f40d1f5164

26e3d2dd7b70701aff8552889c899b7915b06f0b979a4766076681dd01abd978

16c151ffe5e439a9383900738b4f8938cd33ba1781b62d8e2ee0686336a7145c

9a4ed995dfd9d468715dfe4906265059aa3bb1e0d6ceb547e84001661a023a9d

f1e616aecf6205daaf6c55898f86092055fe85a3825837c688c2e7545f6efb7e

db829b0d7396feaef2a4555b9d4fdf1b00d287dad93585e1c6c54f9cee0e9d4f

abaf5a7d82e6db68fb73af18bf1f5e37b200f04dcc6e34da98ad044d9f411022

04b8b48a795bcfe2b7344c2bbc409e85641e412c35ff490e7ae074e7d48698f7

668b4c01e0493dc2b8b3a1b7134ce3811ef1449c2807ef6ca1c0b8356b90a2ed

342de173d65d604e0935808b1d6a617060602c86e543bdf1c4c650812dec3883

6180311025913c26ff8ac90b57b3fad61e21cdd896ea8b26a5ee14e6e663f6bb

1d2a85a88153061ea17c6eeb9394f1d969ed6f0db526c7ddf79919676d4ca012

3bb663567994bae2da06ea84a75b5205b7fa38dd8253ab326bfa4c50a90939ac

4a1a5456123ef756956cc1d9a53f44dab040421700edf051f21671abe7e61d69

47ecddb2f7f7242a3fd6cf9d08715512644f3ca199e779f737762150765b3027

32667a9bfb24f505f351804d8516e2f5cf7f88ba6ef4de4db4463234ba4a3ea1

68cd91e61a1bd6b5a1f39e45920c887be9603e85ca4e03b156cdc7acbe66f7c7

56904fea473c40b9cf39de854a81896e8ba8f2bc1415101e69c25c065eb9773e

0274e5f807a951cc68c0fd5af3fc9fa7b8a7305609da8144dacf69d0d39a23a4

3ce1ad8a7f90404bdfc8157689742448ff675d094767a10c9cdf1e08ce068c55

acc351ce2d3bf1bacb10bf379c6575fdb98e7c0fc2c69d20a7a7e3cf34615ae1

19c25fa8a43b9da08fb5a78c03c554f23c0635ce618e789296fd35d748603fd4

9e87eff7c42c077486531d6a178cab830c19aa787a18bc7ba5334a682cf82312

1d4d3ad6a1330ada787c11dcf39bcf4864745aa440bfe1a45291f82b5467849f

01d08050e532145ebb08398c51ac387979d34526918b8b21d0a3d0bed1ba3487

b3847e10df393052222da931a96bedacf6d862e3470256dfb234a93947a23e82

71015d0586123eac15c36aa4747fb60d03e671d5b5b4608818258320e33512e7

c0e24060684d376068acdb40636392eb5627b410f9cb67428008415d288cb7f9

0be090f3b01713a28f5bc94feb41f07ccd2814e0c7a58f5226242f96e80baaec

20d337997e2a79015aa711bda443d2c0248959f15f007ec469839c7fa4418b9b

ef6e26502bb160be3154d7a34a461bbbc1bf8eaf3142c64658d14707836badec

40929deab63f001f99973dffe6674e8bf0347f5dc30b5fb2d38e00667b90be7b

584de1b855adaabc329639d09c77512a5f05099ecd629698b04893ac58fba01c

90a86513076a32328e654f241226f454a5b39d76ea1a3119432aa9bb4253f775

799c5a2dd25f180b4d4dda72da8da55bc6a99e2f01068880d7e3b58f8687242a

6bbfd7f427458a485946d09318260cc484191a7d2e6f20dc0c143065716ff378

8c01e58a2523297599342e38b6f8559b67d82bc790963b7a96802f30d337f295

f8b022d3be92bf893b92ea235dd171443ac61330d008a0a786a0af940f2c98a7

6ed9b8b0c478e30bc4f25bfcae3652b3937d735457b41146286173c54f3d5779

28fb8f3858df045f3a1979f66ac9793f89f42324fcac8339f9f0fb7e566dbf16

802a39b22dfacdc2325f8a839377c903b4a7957503106ce6f7aed67e824b82c2

224b5af4ca4de234f03408487f075f0d638826cb6f65944a3e8dcbaac4372e79

39655262901bc4a35867fa458a6025aa1175613c57ef51336412c32ca61715a1

d49c16c0aacdb700f5afab86b20640a85c01d31b81c854c6a49eb62b8af68b68

99ea3a10ea564b980a10e969b9b70fdef9be0b53ea4dee331cac7ebbdef65c47

a6c0ef11f8d3f12215a9d2d4d461f0eb92f4f305bdd32c2bb3e3a7196f8bb26d

8b322ebd9dfae74c531f70a32b7d5689c394c6e5455575de53cc8984f7ebdbe5

4c3a6c5a8a7a03581bf337dfb7572fb919a7d0414179019836b909e5e40921dc

48845b4d384665b2078b1b4ed55a29fc4b2634e38d2c05ee29fb7a24e5a5c7f2

3984d2400880e2f87f0c0e0e9d8f0e8e4b81971b53f66d840d1733a1cba6ccb1

b9eb60c690b19a13da8717c4ba60e2bf9c4cda92fb9a723bed6011b08ea1b0ca

1b6282350a25f9e362c68d359277746bc5039a0532e05375b06e9688622df6ba

ca2e49411ca8c2f8071bc5e12a8266444db7c1a7d0651d9fa9422970024f2150

5c6e531738c1380ec09c1ec0f1438cee5077e6cbade8af87710b8be2f0aaaac7

ecd6fa73cf527025792c4f1ee13acbd1c1219217f6da5aed2aaed11ea8453393

fc06a74968ad0db68f26fa5e306a279728617fde7f3b8a8ddfb449f02bbac2c9

934e56b74a5ca093857042c5b0371661134d29ea405d444bd2d602c74c20b9d2

4c4d9e0062225311584fbf25b79e2a5b9a98dc2a3a43e736621082d8a92f18fe

5e1173cc0c8226881a5fa21e6811e96db732c4ee9dfa2d3455c650d4522fe732

e4400d9f128bf9ba924d94f1c87cfe882cc324d607ffdcbb03aaad6cdf71d2ef

1dec4ec17c7bfe5abc9bb0a885e4cc5a2e5ab6a9676bb9f445402b84599ec915

2f9eedcdda4f28ca08ece26a58e859062a6c0b9cf7f319b3eaa8d9f034c76d20

ef03d20595daa112f7652a11f2f7c2cac37216dae9bbd1aa87e482fd204c858e

4246159ae6234697ed015c8c222ce053a7eaf83e2960d1c49339e72184be7e40

b9440d29e2104cc3411c71c5db504dbc043c77aee24154ac68409df97c5eff49

a33bccaa7d2d3797f25edfae846f1e7757b50633b374f8ce1faf7a5934784817

3c55a81f460804e2e39a1d3dc556fa5a93fe7ce8c139f8b68f1e5ca98f62875c

0a376070679f6a31b2f6aaef23747f930544ab77ad01d30007f6d0ccf2bead60

cdf964200bb9130c09d1bfd17677e2da5808c179a2cd6d49fa32780df1b5b92a

92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812

e73dd4c69a9a9fedd40c290bad68115e3645e74d1d68af0d7fe77ef7c0c5e875

e7fb8bf35fb9bfa2f20fcc293939aad71d5fc39af36defb5150e2f394bb1500e

cd933c6cc8450135deacd61a51e1b425ff7516cac078b92fe1b6f602e4c39e53

025ab87dc729cbf284104a8c9872b63e486ad8af9aef422906743feb0db04224

42adec426addf3fd0c6aff406b46fa82d901f5a9bed7758a243458961349a362

78301ce0bb93dea81f4d70ebb224cc076e7f1e4c38b65afbbc1ad8d4c4882893

5ea75fcdd2be820efdddc411fce9b6d277b66d3356ab8f79bcf542a4ce9fdfa0

c595e47f8e50e8f0ffdc3258f2dcc9411150c3ea00709341c6d4e42d578e46ae

201642c6d1341127aa0137e20db8a3d2da0412fb06ff14eae0c61f6174a44045

fedf49896daa893608deaec7b36a4acb8fbedf7363788c35a6c0431ad0fadca9

22ff8ce9840bae9c9c9aa107e689ec287abb93d585a469c442b295146b9c10c2

30aa9b1c18bb494a01817b5fc0f7418efe2022e7335e815d96dcb8c1fe63e8e8

830cb27f0c584d55267a4e0f6ddcb00c53ce1906946f5d490a26729d38d12057

7370c81abf55a39918a537d1e49a51d74df2042883d11062383038367c864087

d9253c808d83ace06f885479e0807246a29cb9967ea0d0855f5a3802825b13db

ffea93677d1c404900ea5ba20631625ea2e28a22c3af02155c747f2f25429885

a25abe1c21bec0c0259270aa2333ee1d1b6a327a356f5434c42558143a252afe

ce606c710aa001b09f0b51b78bf8675d8b1be4d99714b1a3b9ca245865fec508

98f57b4693bbe9d469821f5433004edafe6ddf8964fa1ef1465ee73fbce24e0c

18c84b6f7e58b2867ec6f3e7c7998ac6901fd485d503d32c8fabff93744574d1

9b2c33764252c2bf807c837d80bffc21eeab87e7129c2d3e9b9b7a1eeee2de84

24a9c57bb4cbb3d1b89c4e7affad599d431de4f007d4c54a4da25a8a2ba4f116

17a4126fb1fb19885d78c82271464d82af8618b7d1b7d8901666c1121ddb2ba1

278dba3857367824fc2d693b7d96cef4f06cb7fdc52260b1c804b9c90d43646d

2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

5b84e8ad40e018b5d87a464e67173eebe2b268e816d9bb864f1d0f1441bebc7c

f52e47c6b0916655d7e8868bd79904e8825fdf98624d8c42192cae808543b0a5

c4f0ec52ce768f2ba36e4954e2afca3ef7ef46d757070a861cc6609d256a3fe1

3d59703fb58265b07ae1cb26750baba733e304f5540a6824329b7ff6f7ab3efe

b02585dd5399047daf3bccd9d7ed5cc69b0fc23b4709e9270c9f09f67c0a23bc

d18e84f86d7a8cfd246baa1684517d69e411780f9da6b8e3ddb99a61c8d0947a

c4fd31ab40e6cb2ebf75d5dc81045ebc38a8825def3f1696a539c32e5ec5b353

9c6b8eb7c007abc681ceb67da5b1c7533055bb9985236abb46ec6f7e0b14e03e

f1e8a5cb9c019dd649564efe4157a90a6f980fd1f0f75c596f20c02e08462373

8443d7bbd02bed691ba1ce55ea0660601c5f10256cbfafd410de41ab2cd4d047

ade725bed78f8a8f0c9a612ee22ea716e3caeacbe16726f9726b39d74e5f3c18

a94e82793f458b81707e005ba1298022a6b7ca0c07869884750d121a06401689

3466d46a970b77cd14cf5c6c8587f522c9b823c8b28abf87a66b07e32041e5c1

d906118fb36a0cc4e83121d4d606ad685645252e8e0791f793057499d8751bf0

9a8acd988089e7f9dd04f971374f766db519e854d42e8052b0d98b4c9c6b67e4

122f4d69497a162a942d8f400dabbe93ae0a326a022886bf6c9c45d23c299f96

ce98ab10089a9ef089941e48fe4cdf1af5c8a3df358f870d933668bbfb2f330e

a713f5c0089a5ef9b2da40fa8cfe06aad73cc836f337c772b1c7d30d70a6c5ed

7fd71102743bf9212b96368597be396a1a22a49a1ec011f1c607533bdefc94bb

46f3afae22e83344e4311482a9987ed851b2de282e8127f64d5901ac945713c0

a7c30a18a3840a97c1ce0130b55ef3f514952233dfcc8662a9e66c6029f95ba9

86ede9ee62785fb11f4c6c95937d6d5bc6bb16c0d3b90ffeeab719b59f7d4e61

30282a807c2ee27b0d1dda310e41487f5018bc5fc5df8af6c13d08df34f2b6df

f36048ea70f70c4adde2d93819e7aa8652ab2761e598cafb1ea871b6730dbad3

cf53fc8c9ce4e5797cc5ac6f71d4cbc0f2b15f2ed43f38048a5273f40bc09876

8f82649ca0e9d1d48ec58a9e2e8431ddda0dc62db1a6d2cd9ec29afa7d59abc3

358b0d6fc23b4984b51deb81ce89c110582e1730bd1eb163f633e1ed9e3388ee

89bb38d54a80b460ea2744b7c5af02a1823939b55990ccd31c06d7ef040d29f3

4a2ef9663f0d5fdfa551e3d31af6dbcffdc78ea02c0fb963b5486daee78421bc

27752bbb01abc6abf50e1da3a59fefcce59618016619d68690e71ad9d4a3c247

fc7558abd0b196a2c070db98268ed00dff186d609e23a93c03640dcc478db2eb

46dd5deda642d4a8cf628d865483e82279cce2846106b830d45b64e1e19727dd

5c47ed83e47f1bdde8c1ebc3d6193fef190c3934fb2239e84950ae5c073eb808

cc8020c36156c7e5c8cfbbb32bc8d7f03536510f4e3b38b22e0abdb9ad90c90e

39b825e400ea17215d6efc5ae425759bbfd3cd8569451680fbf782cfedbec0c5

050610cfb3d3100841685826273546c829335a5f4e2e4260461b88367ad9502c

08b32da8995ae094bfb703d7d975c3816cf04c075c32281e51158164d76cd655

24fe39572ee425e30c018947a1422342479a3d664d1a8d2ab28cef656394073a

1a65e43afaaff90b4124cbef21fadc319f10fba4843d09837219400b0dbcc285

087941d80baca00501739abf0b8450dce723733ea8866589fa9779481e7a6cfb

285998bce9692e46652529685775aa05e3a5cb93ee4e65d021d2231256e92813

c9c4263ac3287aa48d8cf03fdbb32a179cfd8c08d1c1a39696d8c932603e8df9

bc8b240c89304c12dce75076f9fcc2859f48ec01347f9cc0a4cb9fbcb77ed089

2349d745d84db772d97c599e6150ff4585a69d915deb6d6e6601e412651164f3

2941f75da0574c21e4772f015ef38bb623dd4d0c81c263523d431b0114dd847e

69424f5e0bd974271f367fae04179de4efe233d56ad81840a3c3936eaa244502

a793a401277b307c3b056a725672d81b71492cb564d6db2445a9c30724f61d72

68ba2fa76ef3b3c905f26dae3c75a6b5e165b4246cb4f574c07ad70013b265ae

b2d203b927507176606a6616ba8b8729050ecaff0790a9deb37df32caab7d613

2c64a3d6b896ee1b58b9cf55531b7256de45025d60b1f4be764b385de087b52f

a1a5abab16c9de1c69c4a7e731c0f13c9bb8ce90dab15546807cae039c7f9385

ece76fdf7e33d05a757ef5ed020140d9367c7319022a889923bbfacccb58f4d7

106deff16a93c4a4624fe96e3274e1432921c56d5a430834775e5b98861c00ea

 

Appendix 2 – IOCs

Pal4u[.]net

Pal2me[.]net

Pay2earn[.]net

Shop8d[.]net

Ts4shope[.]net

pal4news[.]net

ads4market[.]net

wp.piedslibres[.]com (hijacked legitimate site)

Threat Brief: Drive-by Mining - Adapting an Old Attack to Mine Cryptocurrencies

Posted on by Unit 42

On January 2, 2017, one Bitcoin was worth US $985.56.

By October 16, 2017, that same Bitcoin was worth US $ 5,707.40: a 579% increase in value in ten and a half months.

By comparison, Ethereum has gone from US $8.15 per ether on January 2, 2017 to US $342.83 per ether on October 16, 2017: a jump of 4,206%.

Cryptocurrencies are big money these days and seemingly getting bigger by the day.

And if we’ve learned one thing about cybercriminals, they follow the money.

So, it’s not surprising to see that cybercrime is turning its attention to cryptocurrencies.

In our latest research, “Unauthorized Coin Mining in the Browser”, Unit 42 researchers show how cybercriminals have taken an old tactic, hijacking web browsers without the users consent or knowledge (commonly called a “drive -by attack”), and adapted it to make money in the increasingly lucrative cryptocurrencies markets.

Before, drive-by attacks focused on abusing a browser’s legitimate download capabilities to download malware onto the victim’s system without their consent or knowledge. These new drive-by attacks focus on hijacking the computational resources of the victim’s computer to “mine” cryptocurrency on behalf of the attackers.

The focus of these attacks is to use the victim’s web browser to access the computational resources of their system. The attackers accomplish this through abuse of a legitimate tool by placing it on malicious or compromised websites and running it in the victim’s browser without his or her consent or knowledge when they visit the site. The tool is designed to “mine” cryptocurrencies, that is it earns credit in the cryptocurrency in exchange for computing power that is used to power the cryptocurrencies’ digital infrastructure. This tool has a legitimate use: sites can and do notify users that they’re using the site visitors’ resources in this way to support the site, typically as a substitute for ads on the site. But in this case, the attacker actually gets the credit that the victim’s computational resources earns without the visitors’ consent or knowledge making it a malicious attack.

Put simply, the net result is that the victim’s computer slows down (sometimes significantly) while on the malicious or compromised website. And while the computer is impacted like this, the attacker is earning money. The attacker steals the victims computing resources and translates it into a cryptocurrency like Bitcoin.

This new kind of attack tells us that at least some cybercriminals are starting to view theft of victim’s computing power to translate into cryptocurrencies as a better business proposition than the traditional practice of loading malware on the victim’s system through drive-by downloads.

And our research shows that this isn’t an isolated event. Our researchers analyzed over 1,000 of sites and what they found was very telling.

  1. According to Alexa, 5 of these sites ranked in the top 2K of sites, 29 sites in top 10K and 155 sites in top 1 million.
  2. While many of these sites can be dated back to 2013, we saw steady level to the number of sites until October 2017:  then we saw 502 (63%) of these domains spring up suddenly.
  3. We found these malicious and compromised sites resolved to 47 different counties with the majority being in the United States.
  4. The greatest number of victims we could identify come from the Eastern United States with the Western United States in second. Europe and Asia Pacific came in third and fourth respectively.
  5. In terms of the domains where we found these malicious and compromised sites, .download and .bid domains accounted for the majority, comprising more than 35% of these sites. .com and .review tied for 3rd with 13% of the sites each.

The good news is that these attacks are more like denial of service attacks: they don’t do lasting harm to your system and they end when you leave the site.

The bad news is that these are harder to defend against than typical drive-by download attacks. Where drive-by download attacks usually exploit unpatched vulnerabilities, the root of these attacks is that they abuse otherwise legitimate functionality: you can’t prevent them by being fully patched.

Security products that take a comprehensive, layered approach can help prevent these attacks. And if you think your system is being affected by one of these attacks, you can, in most cases, end the attack by either leaving the site or closing the browser.

Most of all, this latest development shows how a changing economic landscape in turn changes the cybercrime landscape. Loading malware through drive-by downloads is so 2012: in 2017 it’s about drive-by mining attacks to earn cryptocurrencies.

Unauthorized Coin Mining in the Browser

Posted on by Wei Xu

Cryptocurrencies have taken the world by storm. From the biggest player Bitcoin to newcomers such as Monero and Ethereum, cryptocurrency mining has become a hot industry due in part to powerful, dedicated mining hardware or by utilizing graphics cards’ parallel computing power. Recently, browser coin mining has taken off, for a lot of different reasons. Although the computing power per instance is much less than dedicated hardware provides, being able to utilize many users on various sites more than make up for it. There is  already some media coverage on this, such as BBC, and malwarebytes. While we do not consider crypto-currency mining inside browsers malicious by itself, often such mining is going on without the end user’s consent or even knowledge that makes this practice shady and despicable.

Coinhive, one of the more popular browser-mining services out there offers site owners a piece of JavaScript for easy integration. Site owners use site visitors’ CPU time to mine XMRs (Moneros) for Coinhive, and Coinhive pays out 70% of mined value to site owners. A new player, crypto-loot  emerged recently which offers similar services but pays out 88% of revenue.

Coinhive Integration

On the official Coinhive homepage, we found detailed documentation on how to integrate the mining scripts onto any given website. Owners can use the easy version:

or more complicated version that gives control over how the end user's CPU time should be used, e.g. how many threads, should the mining throttle.

Higher thread number and/or lower throttle number will result in more CPU usage in client's browser. With higher CPU occupation percentage, end users will likely experience sluggish behavior and poor experience on the websites.

Tracking Coinhive Integrations

We have been tracking the inclusion of Coinhive mining script (coinhive.min.js) for a week in our PANDB unknown feed. The number of URLs leading to the download of such similar scripts is astounding. Since we started tracking, we have seen anywhere from 6K unique URLs to over 10K in one single day.

Overall, we have seen over 35,119 unique URLs associated with coinhive.min.js. Across these URLs, there are a total of 144 IPs and 1,025 hostnames. Based on our observation, the appearance of these scripts can be clearly divided into three categories – standalone, voluntary, and compromised.

Standalone Hosting

URLs like this one,

hxxp://gkiqfnjtwmj[.]bid/vhyk.php%3fr=1507428652%26v=3%26ilznfamx=1322781%26zptrfkmy=%26djpsicdr=%26adymouss=%26ruxhztvq=http://cricfree[.]cc/stream2watch/bt2.php%26s=1536%2c864%2c1.83%2c2810.88%2c1581.1200000000001

always hosts the following content:

It is worth noting that such URLs are always belong to a jibberish[.]bid domain, with a long trailing set of parameters. Of the 35,119 URLs we collected, 33,188, or 94.5% are of this category. In addition, there are 612 URLs leading to the same set of .bid domains, but with much shorter URLs, like hxxp://www.pudptxanhspld[.]bid/static/robots.txt, or even the domain itself: hxxp://www.pudptxanhspld[.]bid/.

The fact that robots.txt is hosting the exact same content as any other longer URLs with seemingly random parameters leads us to speculate that the domain will serve the same coin-mining content to all visitors, ignoring the request parameters or paths. It is interesting to speculate: why did our customer visit such weird, long, random URLs in the first place?

We give some of our speculations later in this blog.

After removing the .bid domains, we are left with 1,342 URLs, or 3.8% of the corpus. The remaining can be further categorized into the following three groups:

Voluntary: Crypto-mining related sites

We found multiple URLs related to coin/crypto/mining keywords. Some of these are forums discussing crypto-mining, while others are introducing the concept. Regardless of the purpose of the websites, we did not find any evidence that such sites are asking user's consent to mine XMRs.

Voluntary: Monetization

This category includes sites that obviously want to include coin-mining scripts to monetize. Examples of these include video/porn sites such as

xmoviesforyou[.]com
www.webze[.]tv

While they do provide their normal service to the visitors, browsing these sites do not pop up any sort of warning of coin-mining behavior for the user. A script snippet embedded in such sites can be found here:

What is more interesting is that by searching across the whole URL corpus for coinhive.min.js downloads, we found URLs such as the below

hxxp://avditmiohvtq[.]bid/y.htm%3fr=1507583452%26v=3%26jfbakqer=2246476%26ipgznbkx=%26bwxtoxtb=%26oghaenqv=%26hsvxkzhp=http://www.xmoviesforyou[.]com/2017/10/momsincontrol-rebecca-rhiannon-ryder-pussy-is-international.html%26s=1280%2c800%2c2%2c2560%2c1600

which includes xmoviesforyou[.]com as part of the URL almost like a referrer parameter. We verified that the below is indeed a valid URL leading to a subpage in the porn site.

hxxp://www.xmoviesforyou[.]com/2017/10/momsincontrol-rebecca-rhiannon-ryder-pussy-is-international.html

That site does include coinhive.min.js, but at the time of our verification prior to publishing, the inclusion is directly from https://coinhive[.]com/lib/coinhive.min[.]js and the whole page does not include any references to a suspicious .bid domain/URL. We speculate that the porn website URL may have included an iframe leading to the .bid domain, which then triggers the download of coinhive.min.js. However, this mechanism may have been later abandoned in favor of direct inclusion.

 

Compromised/Injected Integration

Another group of sites seem to have fallen victims of malicious script injection into their vulnerable servers. We found that www.livetruemoney[.]com uses up 100% of user's CPU time. Upon closer investigation, we found that this site is hosting multiple copies of coinhive.min.js, toward the top and bottom of the page. A similar situation happens in www.comptesofficiels[.]com/, where the snippet is injected outside of <body> tag (a common symptom for injected content), as follows:

It is quite possible that crypto-mining has become a new injection attack in addition to traditional exploit kits redirections.

Finally, we have also seen some typo-squatting/phishing domains serving coinhive.min.js. Examples include analytics-google[.]net/track.php, and www-bank[.]ru.

Actor/Mining Configuration Analysis

According to our observation, coin mining integration scripts are rarely obfuscated, which means we can extract the anonymous 'site key' and their configurations easily. Per Coinhive's documentation, the 'site key' is a unique identifier to indicate which beneficiary will be paid, therefore, the attacker has no incentive to garble this field. Here are some interesting stats about the actors and their configurations.

Actor distribution

CoinMining_1

There is a clear winner at the top - ID t3z562mp2zg1lia7rujy19d67woezmjj claiming 35,742 over 36,842 of all the IDs we were able to retrieve. Surprisingly, querying a website source code search engine like publicWWW only returns 13 results (mostly .bid domains). The remote second and third sites scored 370 and 119 occurrences respectively, along with 8 other IDs topping 10 occurrences. A large number (146) of IDs only have 1 appearance in our dataset, and these are possibly category 2 or 3 in our integration scenarios described above – mining would benefit themselves rather than a campaign owner.

Unsurprisingly, site key owner t3z562mp2zg1lia7rujy19d67woezmjj has all the .bid URLs pointing to this payee. In addition, there are URLs such as

http://216.21.13[.]11/s%3fcid=5100604%26iuid=1619927385%26ts=1507160862%26ps=3429657830%26pw=2413%26

also using the same site key. Passive DNS analysis reveals that this IP actually was mapped to serve.popads[.]net, so it is interesting that this particular advertising network may have led to crypto-mining behavior.

In this chart, a special case sitekey stands out. There are 151 sites using it, and it is a predefined variable in previous scripts (as opposed to hardcoded string) so without dynamic analysis we are not able to retrieve its real content. We looked at a few samples and it seems that most sites using the sitekey variable are serving mining script to benefit themselves.

We found only six out of the entire URL population making more than one call to coinhive.Anonymous function (which means they could possibly be compromised by two different adversaries/serving two different payees at the same time). Upon closer inspection, all the calls actually have the same site key, so in summary we did not find evidence of one site serving more than one beneficiary. We did, however, find out that one site, lottoipros[.]com, is attempting to obfuscate its site key by using simple Unicode encoding:

Clearly, the site owner/injector is aware of the risks of exposing its key and is trying to hide from public scrutiny. If this trend continues, it will become harder to use static analysis to detect crypto-mining sites.

Configuration Distribution

The dominant Actor ID t3z562mp2zg1lia7rujy19d67woezmjj uses default configuration across all of observed URLs, so we exclude this actor from this analysis to prevent skew. We also exclude the 142 sites that use mineropts that go almost hand-in-hand with sites using sitekey as their site key.

This left us with 827 valid data points. Among these most sites only use 1 thread by default; however, some sites use as many as 4 threads to maximize mining speed.

Thread count Number of sites
default (1) 772
1 28
2 7
3 1
4 19

 

After the default setting which disables throttling the most popular option is to set it at 0.5, so that the CPU would idle 50% of the time. It is sufficient to say that most sites are not giving user’s CPU any break at all by disabling throttling.

Throttle setting Number of sites
default (0) 772
0.5 28
0.2 25
0.7 19
0.9 10
other values combined 35

Hosting domain analysis

In this section, we show some hosting domain stats, including PassiveDNS and Whois data analysis.

The TLD distribution for domains hosting coinhive.min.js is shown below. For brevity, we aggregated all TLDs having less than 20 entries into others category.

CoinMining_2

Clearly, the top suspects are .download and .bid domains, taking more than 35% of the total share of 1,025 domains. As expected, typically notorious TLDs like .xyz and .win is also listed.

Alexa rank distribution

We checked all associated domains against the current Alexa traffic ranking. The results are astonishing - there are 5 sites in top 2K, 29 sites in top 10K and 155 sites in top 1 million. We sample a few highest-ranking sites and show it here:

Site Alexa Rank
uptobox[.]com 771
123movies[.]co 963
cinecalidad[.]to 1026
watchfree[.]to 1892
sugklonistiko[.]gr 1910

 

At the time of the writing, we can no longer observe coinhive.min.js on their sites.

The highest ranked .bid domain, llxyyocfgfg[.]bid is ranked at 3380 at the time of this writing. We have attached all these IOCs and their rankings at the end of this blog for the community's benefits.

pDNS analysis

We looked up these domains in our passive DNS (pDNS) database. 794 domains were found with records among the 1026 domains in total. We found that the first DNS query to many domains dates back to the launch date of our pDNS in 2013. Examples include uptobox[.]com, torrent[.]cd, and tiexue[.]net. This means these websites have been active for a long time. Some of them are quite popular based on their Alexa ranking. So, the potential impact of Coinhive can be high in both time and space. We also found that the first DNS query to 502 (63%) domains happened in October 2017. Based on the figure below, we can clearly see the emerging trend of these domains.

CoinMining_3

We further investigated the DNS query pattern of these domains. In particular, the following graph shows the number of DNS queries to these website per hour. Interestingly, we found that some domains exhibit very similar patterns. Although the start time and amount of traffic are slightly different, the overall pattern of traffic is very much similar in shape. This is another indicator that these domains potentially belong to the same campaign launched by the same owner.

CoinMining_4

In addition, we analyzed the distribution of IPs to which these domains were resolved. We identified 1,172 IPs in total, located in 47 different countries with the majority being in US. Below is the figure showing the country-level distribution of these IPs.

CoinMining_5

Whois analysis

Through querying public Whois server as well as Domaintools, we obtained 861 valid whois records of 1,025 domains. Below we break the results down by registrant/emails and their registration dates.

  • Registrant/Emails: Not much can be learned due to the fact that most (521) are privacy protected by WhoisGuard. In the remaining registrants, there are also fake ones such as Administrator and Private Person. After removing the useless entries, we are only left with 80 different registrants, with no more than one registrant appearing more than 3 times. All the .bid domains are privacy protected. Since WhoisGuard service is not free (around $3/year), the .bid campaign actors are probably earning enough profit to offset this cost.
  • Registration date: To better present details in registration date, we separate domains with different TLDs:

CoinMining_6

For .bid domains that we were able to retrieve whois information, most are registered after 10/01/2017 but spanning across multiple days, showing that the campaign is very recent and it has a rotating number of domains refreshing every day.

CoinMining_7

In contrast, most .download domains were registered within 3 days of 09/14-09/16, 2017, with only a handful added on later. This looks to be a different campaign than the .bid ones. We see similar registration trending on .review domains (87 out of 103 are registered on the 3rd, 7th, and 8th of October 2017).

CoinMining_8

Finally, after we exclude the suspected campaign domains (.bid, .download, .review, .top, .win), the registration dates are extremely spread out from as early as 2001 to the current date. These domains are most likely either embracing the new crypto-mining monetization fever, or compromised by attackers to take advantage of their established reputation and high-volume visitors.

Victim analysis

The URLs we crawled to detect crypto-miner presence comes from our PANDB cloud log. In this section, we analyze the demographics of visitors to such sites to shed some insights on their real-world impact.

CoinMining_9

This figure shows the general geographic distribution of visitors to crypto-mining sites. While the US clearly dominates in total visiting counts, Europe and Asia Pacific is not too far behind. This graph indicates a broad spectrum of victims all across the globe.

After breaking down visits site-by-site, we found that the most visited sites generally align with their Alexa ranking, with over 40K visits* to the 123moviews[.]co:

CoinMining_10

We only log a query when customer(s) using the same device visits the site for the first time in a TTL window. This does not count duplicate visits to the same site within a short timeframe. Therefore, the visits estimations are a lower bound.

Summary

As AdGuard has pointed out, the use of coinhive or similar mining services is itself not a malicious activity, it is how they are used that makes the sites malicious. Unfortunately, for the sites that we were able to observe engaging in crypto-mining activities, none of them has prompted the user with any sort of warning, let alone providing the kill switch for mining. With Bitcoin soaring over $5K (at time of writing), we can only expect more of such services spawning from everywhere. To protect yourself from this fast-growing threat, we recommend two options:

  • Palo Alto Networks is blocking URLs hosting the Coinhive JavaScript files through PANDB, which can be enforced as part of the malware category, as these scripts are consuming system resources without the users’ knowledge or consent.
  • In addition, popular browser plugins such as Adblock plus or Adguard will also block such mining scripts. Combine it with our firewall solution, you can rest assured that your previous CPU time and electricity is not exploited by sneaky scripts.
  • Users interested in top-ranked .bid, .download, and .website Domains hosting Coinhive script files included in this analysis can access them here.

Palo Alto Networks Unit 42 Vulnerability Research September and October 2017 Disclosures

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have discovered vulnerabilities that have been addressed by Microsoft in their September and October security update releases.

CVE Vulnerability Name Affected Products Researcher
CVE-2017-8567 Microsoft Office Remote Code Execution Microsoft Excel for Mac 2011 Jin Chen
CVE-2017-8749 Internet Explorer Memory Corruption Vulnerability Internet Explorer 10, Internet Explorer 11 Hui Gao
CVE-2017-11793 Scripting Engine Memory Corruption Vulnerability Internet Explorer 9, Internet Explorer 10, Internet Explorer 11 Hui Gao
CVE-2017-11822 Internet Explorer Memory Corruption Vulnerability Internet Explorer 9, Internet Explorer 11 Hui Gao

For current customers with a Threat Prevention subscription, Palo Alto Networks has also released IPS signatures providing proactive protection from these vulnerabilities. Traps, Palo Alto Networks advanced endpoint protection, can block memory corruption based exploits of this nature.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

OilRig Group Steps Up Attacks with New Delivery Documents and New Injector Trojan

Posted on by Robert Falcone

Unit 42’s ongoing research into the OilRig campaign shows that the threat actors involved in the original attack campaign continue to add new Trojans to their toolset and continue their persistent attacks in the Middle East. When we first discovered the OilRig attack campaign in May 2016, we believed at the time it was a unique attack campaign likely operated by a known, existing threat group. As we have progressed in our research and uncovered additional attack phases, tooling, and infrastructure as discussed in our recent posting “Striking Oil: A Closer Look at Adversary Infrastructure”, it has become apparent that the threat group responsible for the OilRig attack campaign is likely to be a unique, previously unknown adversary. Additionally, others have been referring to the group responsible for the OilRig campaign itself as the OilRig group as well. To that end, we are elevating the OilRig attack campaign to be known as the OilRig group.

In July 2017, we observed the OilRig group using a tool they developed called ISMAgent in a new set of targeted attacks. The OilRig group developed ISMAgent as a variant of the ISMDoor Trojan. In August 2017, we found this threat group has developed yet another Trojan that  they call ‘Agent Injector’ with the specific purpose of installing the ISMAgent backdoor. We are tracking this tool as ISMInjector. It has a sophisticated architecture and contains anti-analysis techniques that we have not seen in previous tools developed by this threat group. The complex structure and inclusion of new anti-analysis techniques may suggest that this group is increasing their development efforts in order to evade detection and gain higher efficacy in their attacks.

The Attack

On August 23, 2017, we observed OilRig targeting an organization within the United Arab Emirates government. The attack involved a spear-phishing email that had a subject of “Importan Issue” and two Zip archives attached, as seen in Figure 1. Note that “Important” is misspelled in the sample as shown below.

Oilriginjector_1

Figure 1 Delivery email that contains two Zip archives that contain the malicious delivery documents

The message body in the attack email contains an image that is hosted on a remote server. As shown in Figure 2, hovering over the image shows that the URL link is to an image hosted at “www.cdnakamaiplanet[.]com” which we have reason to believe is an adversary owned domain. It is likely that the image was embedded to track if the recipient opened the email or not.

Oilriginjector_2

Figure 2 URL associated with image included in delivery email

Another interesting facet of this attack is that the email addresses in the “To” and “From” fields are from addresses from the same domain. Our initial assumption was that the email address in the “From” field was likely spoofed. Additional analysis of the email headers revealed that it did not contain a list of external email servers used to deliver the message as expected from a spoofed email; instead, we discovered the following string within the email headers:

Client=OWA;Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.04;

This string in the header suggests that the OilRig actor is likely to have used the targeted organization’s Outlook Web Access (OWA) to send the phishing email using Firefox 36.

Using information from our research in the Striking Oil blog, we know the OilRig group has conducted credential harvesting campaigns specifically by emulating OWA login sites. Based on that research and this observation, we postulate that the OilRig group gathered credentials to a legitimate user’s OWA account and logged into the user’s account to send phishing attacks to other individuals within the same, targeted organization. Also, Firefox 36 was released in February 2015; since this email was sent August 2017, we believe it suggests the actors are using an outdated version of Firefox to log into the target organization’s OWA.

The Delivery

The August 23, 2017 phishing attack contained two Zip archives to the email, “Issue-doc.zip” and “Issue-doc1.zip”. Each Zip attachment contains one file, with “Issue.doc” within “Issue-doc.zip” and “Issue.dot” within “Issue-doc1.zip”. The “Issue.doc” and “Issue.dot” files are both malicious documents that will attempt to run in Microsoft Word.

Issue.doc is a Word document that contains a malicious macro that the actors attempt to trick the victim into executing by instructing the user to click the Enable Content button as shown in Figure 3. We track this malicious delivery document as ThreeDollars.

Oilriginjector_3

Figure 3 Malicious “ThreeDollars” Microsoft Word Document

Once enabled, the macro reads in the initial document, searches the data for a delimiter of "###$$$" to find the base64 encoded payload then writes the encoded payload to the file %APPDATA%\Base.txt. The following shows a hexdump of the delimiter followed by the encoded payload:

The macro runs a PowerShell command that will decode the contents of the %APPDATA%\Base.txt file and save it to the file %PUBLIC%\Libraries\servicereset.exe, which it will then execute. The “servicereset.exe” file is a new tool in OilRig’s arsenal that we call ISMInjector, which we will discuss in detail in the next section.

Issue.dot is a file that attempts to exploit CVE-2017-0199 Microsoft Word Office/WordPad Remote Code Execution Vulnerability using the following code:

As displayed by the code example above, Index.dot file attempts to load a malicious exploit document hosted at “msoffice-cdn[.]com”, which is the same URL that hosted the exploit document used in an attack that ClearSky published on August 28, 2017. By correlating artifacts found in Index.dot, we discovered another sample attempting to exploit CVE-2017-0199 used in a separate attack, this time using “office365-management[.]com” as the C2 domain.

The resulting payload from this related delivery document is an ISMAgent Trojan that is configured to use “msoffice365update[.]com” as its C2 server. Please reference our previous blog on ISMAgent for more information on this Trojan.

ISMInjector

Ultimately, the payload delivered by ThreeDollars is a new tool that we track as ISMInjector. As its name suggests, ISMInjector is a Trojan that is responsible for injecting a Trojan into another process. The payload embedded within the ISMInjector sample delivered in this attack is a variant of the ISMAgent backdoor that we had discussed in detail in our blog discussing a targeted attack on a Saudi Arabian technology company.

At face value, ISMInjector is obfuscated with the off-the-shelf SmartAssembly .NET obfuscator created by red-gate.com. The first execution of ISMInjector starts by copying itself to %localappdata%\srvBS.txt and enables persistent access to the system. The code achieves persistence by referencing two resources that contain commands the code will execute by running them within a command prompt process, as seen in the following screenshot:

Oilriginjector_4

The two resources that contain commands that ISMInjector uses for persistence are named “Tsk1” and “Tsk2”. The specific commands within each of these resources are within Table 1. At a high level, the“Tsk1” command creates a scheduled task named “ReportHealth” that is meant to run a payload saved to "%localappdata%\srvHealth.exe” every 4 minutes. The “Tsk2” command creates a scheduled task that runs every 2 minutes that is responsible for saving the payload to srvHealth.exe. This task saves the payload to this location using the “certutil” command to decode the original payload saved to “srvBS.txt”.

Resource Name Resource Value
Tsk1 SchTasks /Create /SC MINUTE /MO 4 /TN \"ReportHealth\" /TR \"%localappdata%\\srvHealth.exe\" /f
Tsk2 SchTasks /Create /SC MINUTE /MO 2 /TN \"LocalReportHealth\" /TR \"cmd.exe /c certutil -decode %localappdata%\\srvBS.txt %localappdata%\\srvHealth.exe && schtasks /DELETE /tn LocalReportHealth /f && del %localappdata%\\srvBS.txt\""

Table 1 Resources in ISMInjector containing commands for persistence

Subsequent executions of the ISMInjector sample from srvHealth.exe will execute its functional code. ISMInjector’s functional code is split into two different embedded modules named Inner.dll and Joiner.dll that work in conjunction to inject an embedded ISMAgent payload into another process. The two modules, which we will refer to as Joiner and Inner, have the following debug paths, which suggest the author of these modules refer to this Trojan as “Agent Injector”:

  • C:\Users\J-Win-10\Desktop\Agent Injector\PolicyConverter\Inner\obj\Release\Inner.pdb
  • C:\Users\J-Win-10\Desktop\Agent Injector\PolicyConverter\Joiner\obj\Release\Joiner.pdb

The main function within the ISMInjector assembly uses the Joiner module to construct the final payload and the Inner module to inject the final payload into a process. Figure 4 shows the ISMInjector’s main function that uses the two modules to carry out its injection process before exiting.

Oilriginjector_5

Figure 4 ISMInjector's main function uses methods within the Joiner and Inner modules

The Joiner module contains four resources named P11, P12, P21 and P22, which are all 35840 bytes of binary data. It reads the P11 and P12 resources and saves them to a variable, effectively concatenating them together. The module uses the same logic to concatenate the P21 and P22 resources together, and finally concatenates the P11+P12 variable with the P21+P22 variable, which results in the construction of a binary executable.

The ISMInjector code then calls the "LoadDll" method within the Inner module, providing the string "Run", the payload constructed by the Joiner module, and a path to the "RegAsm.exe" executable as arguments, as seen in Figure 4.

The LoadDLL method constructs an embedded assembly, using the same method as the Joiner module used to construct the final payload. However, the Inner module creates another module that is used to actually perform the code injection. To create this embedded module, the Inner module references two resources named D1 and D2 and concatenates them together. The resulting .NET assembly has a class called "ClsV2" that has a method named "Run", which is called in the LoadDll function call shown in Figure 4. The "Run" method within the “ClsV2” class is invoked to execute the payload.

The "Run" method calls functions that has a state machine that dictates the actions taken. At a high level, these state machines attempt to create a process and inject the constructed payload into the newly created process. The use of state machines complicates analysis efforts because it makes the flow of execution jump around in a non-sequential fashion.

Table 2 contains the path through the state machines that ISMInjector uses to create a remote process, inject its embedded payload then run the payload. Each row of the table contains the current state, a description of the activities performed within that state, as well as the next state that will be set and run. The state values jump around dramatically, which requires an analyst to also jump around the code to determine its functionality. This is an interesting anti-analysis technique we have not seen the OilRig actors use in their other tools.

State Description Next

State
19 Initializes array 10
10 Initializes array 6
6 Initializes array 3
3 Initializes array 14
14 Initializes array 15
15 Initializes array 16
16 Initializes array 12
12 Initializes array 18
18 Initializes array 8
8 Initializes array 25
25 Initializes array 1
1 Initializes array 4
4 Resolves the CreateProcessA function 21
21 Resolves the SetThreadContext function 26
26 Resolves the GetThreadContext function 17
17 Resolves the ReadProcessMemory function 27
27 Resolves the WriteProcessMemory function 24
24 Resolves the NtUnmapViewOfSection function 7
7 Resolves the VirtualAllocEx function 0
0 Resolves the ResumeThread function 23
23 Formats a text string as "{0}", which is the path to the “RegAsm.exe” executable 5
5 Instantiates a STARTUPINFO structure 22
22 Instantiates a PROCESS_INFORMATION structure 11
11 Sets the size (cb field) of the STARTUPINFO structure 20
20 Enters another state machine to handle the execution of a process 29
Enter sub-state machine
7 Concatenates the path to the “RegAsm.exe” with a space and a second string, which in this sample is empty 37
37 Calls the CreateProcessA function using the concatenated string created in previous state. The CREATE_SUSPENDED flag is used in this API function call to create the process in a suspended state. 44
44 Creates a variable to store the process’ ImageBase 19
19 Creates a thread CONTEXT structure 14
14 Sets the first index in the context structure to 65538, which sets the ContextFlags value in the structure to CONTEXT_INTEGER 10
10 Checks the value of IntPtr.Size to determine x86 or x64 process. 27 or 23
27 Calls GetThreadContext to get the context of the suspended thread in the newly created and suspended process. It then stores the EBX register in the suspended thread into a variable 23
23 Calls ReadProcessMemory to read EBX+8 in the suspended process to get the base address of the process. It then creates a variable to store the SizeOfImage from the PE header of the payload it intends to inject into the process 22
22 Creates a variable to store the SizeOfHeaders value from the PE header of the payload it intends to inject into the process 25
25 Calls VirtualAllocEx to create a new buffer in the suspended process at the base address of the process 41
41 It calls WriteProcessMemory to write the PE header of the payload to the buffer created at the base address of the suspended process. 31
31 Enters a loop in the state machine to effectively write the embedded payload section by section to the allocated buffer. Does so by setting a counter to 0 that will be compared to NumberOfSections in each iteration of the loop 45
45 Sets a variable for the VirtualAddress of the PE section 29
29 Sets a variable for the SizeOfRawData of the PE section 28
28 Sets a variable for the PointerToRawData of the PE section 2
2 If SizeOfRawData variable is 0 it moves onto the next section by going to state 30, else it goes to state 20 30 or 20
30 Increments counter to compare to NumberOfSections 38 (same as 45)
20 Creates a byte array with a size of SizeOfRawData for the SectionData 21
21 Copies bytes from the embedded payload to the SectionData buffer 36
36 Writes the SectionData buffer to the correct VirtualAddress within the remote process memory.  If WriteProcessMemory succeeds, it continues in the loop by going to state 30. Otherwise, after all the sections are written to the remote process, state 13 is chosen 30 or 13
13 Sets a variable to store the new base address of the payload copied into the remote process memory. 18
18 Sets the EIP value within the CONTEXT structure to store the AddressOfEntryPoint of the injected payload 0
0 Checks to see if the process is x86 or x64 based on the inPtr size being 4. 16 (x86) or 33 (x64)
16 or 33 Calls SetThreadContext using the CONTEXT structure with the new entrypoint to the injected payload and calls ResumeThead to run the suspended thread. This effectively runs the injected payload in the process space of RegAsm.exe. End of sub-state machine
Resumes initial state machine
29 Ends the function by returning End

 Table 2 State machines used by ISMInjector to inject and execute its payload in another process

The executable injected into the RegAsm.exe process is a variant of the ISMAgent Trojan, which is very similar in behavior to the ISMAgent payload discussed in our previous blog. This ISMAgent payload is configured to use “cdnmsnupdate[.]com” as its C2 server using both HTTP and DNS tunneling channels.

It appears the OilRig group may have simply repurposed the injection code from an open source file called DynamicCallRunPE.cs, which is available on GitHub and Codegists.  The actors did not use this code without modification; instead, they used state machines as an obfuscation technique to disguise the injection code.

The path that ISMInjector takes through the state machine and the activities are almost identical to the activities carried out in the DynamicCallRunPE.cs code. It is also possible that this portion of the ISMInjector was obfuscated by a crypter that the threat actors used to further complicate analysis.

Infrastructure

Beginning with the initial phishing email, we discovered a significant infrastructure for this attack wave that also showed relationships to previous Oilrig attack campaigns both from an infrastructure perspective and shared code.

Much like previous Oilrig attacks, the C2 domains used typo-squatting techniques in order to attempt to evade detection. The image embedded within the phishing email is hosted on cdnakamaiplanet[.]com, which resolves to 82.102.14.216. As with other OilRig attacks, this IP is not reused to resolve to any other domain. However, two other IPs on the same /24 netblock are found to be used as C2s. 82.102.14.222 is found to resolve to Microsoft-publisher[.]com, which we observed as a C2 for our initial ISMAgent finding. 82.102.14.246 resolves to adpolioe[.]com, hich appears to be a typo-squatted domain that also hosts a sample of ISMAgent at hxxp://82.102.14[.]246/webdav/aws.exe. This sample’s C2 is cdnmsnupdate[.]com which turns out to be the C2 server for three other samples, one ISMAgent and two of them being ISMAgentInjector. Reverse resolution of this domain provides us the IP 74.91.19.122, which again is not used for any other domain resolution. Another IP on the same /24 is found at 74.91.19.108 resolving to msoffice365update[.]com which happens to be the C2 domain for the ISMAgent payload delivered by the malicious document exploiting CVE-2017-1099 mentioned earlier in this blog.

As previously discussed, the .dot file attempting to exploit CVE-2017-0199 uses msoffice-cdn[.]com as a C2 to retrieve additional malicious code. Reverse resolution of this domain shows an IP of 185.162.235.121, which shares a /24 netblock with 185.162.235.29. This IP resolves to office365-management[.]com which is the C2 for a secondary .dot file we were able to collect in this attack wave. In figure 5 below you can see the OilRig infrastructure for ISMInjector that our research uncovered.

isminjector copy

Figure 5 OilRig infrastructure for ISMInjector

Conclusion

The OilRig group continues to target organizations in the Middle East, in this instance targeting the government of the United Arab Emirates. They continue to use the ISMAgent Trojan as the final payload in their attacks, this time in conjunction with a custom injector Trojan to assist with delivery and execution. The injector Trojan was obfuscated using a known crypter and used state-machines as an anti-analysis technique to complicate its process to inject the payload into another process. The use of crypters and anti-analysis techniques suggests that the threat actors are increasing their efforts to evade security products to successfully compromise its targets.

As our research continues to expand into the OilRig group, we are continuously discovering new infrastructure which directly overlaps with previously used infrastructure. With the addition of the reuse of tools, similar attack protocols, as well as consistent victimology, we have strong confidence that the original OilRig attack campaign is indeed a single, unique, and previously unknown threat group that will hereby be referred to as the OilRig group.

Palo Alto Networks customers are protected from ISMInjector, ISMAgent and ThreeDollars by the following:

  • All ISMInjector, ISMAgent and ThreeDollars samples are marked with a malicious verdict in WildFire
  • AutoFocus customers can track these malware families via:

Indicators of Compromise

ThreeDollars SHA256

119c64a8b35bd626b3ea5f630d533b2e0e7852a4c59694125ff08f9965b5f9cc

ISMInjector SHA256

33c187cfd9e3b68c3089c27ac64a519ccc951ccb3c74d75179c520f54f11f647

ISMAgent SHA256

74f61b6ff0eb58d76f4cacfb1504cb6b72684d0d0980d42cba364c6ef28223a8

ISMAgent C2

cdnmsnupdate[.]com

Related CVE-2017-0199 SHA256

66358a295b8b551819e053f2ee072678605a5f2419c1c486e454ab476c40ed6a

Related CVE-2017-0199 Domains

msoffice-cdn[.]com

office365-management[.]com

Additional Hashes

f92ab374edd488d85f2e113b40ea8cb8baf993f5c93c12455613ad3265f42b17 (CVE-2017-0199)

fcad263d0fe2b418db05f47d4036f0b42aaf201c9b91281dfdcb3201b298e4f4 (ISMInjector)

0ccb2117c34e3045a4d2c0d193f1963c8c0e8566617ed0a561546c932d1a5c0c (ThreeDollars)

a9f1375da973b229eb649dc3c07484ae7513032b79665efe78c0e55a6e716821 (ISMAgent)

963f93824d87a56fe91283652eab5841e2ec538c207091dbc9606b962e38805d (ISMAgent)

Additional Domains

ntpupdateserver[.]com

cdnakamaiplanet[.]com

msoffice365update[.]com

adpolioe[.]com

Microsoft-publisher[.]com

Threat Brief: Understanding Kernel APC Attacks

Posted on by Unit 42

In the months since the WanaCrypt0r/WannaCry and the Petya/NotPetya attacks, security researchers have delved into the nuts and bolts these incidents and the malware involved.

One key thing that research into these security incidents shows is that these attacks used a relatively new and unknown technique called kernel APC attacks as part of their toolkit.

Kernel APC attacks occur in a way that increases the “stealth” factor and makes standard detection and prevention very difficult. And kernel APC attacks do this while still maximizing the power and control that the code has on the target system.

While kernel APC attacks aren’t well known and can be hard to understand, their proven success in WanaCrypt0r/WannaCry and the Petya/NotPetya make them an important threat to understand because proven attack techniques are quickly adopted widely. And understanding is a first step to prevention.

To understand what makes kernel APC attacks so dangerous, it’s important to understand what they are.

The kernel is the heart of the operating system. When talking about operating systems with security permissions and controls like Windows or UNIX/Linux, the kernel operates with the highest level of control. Because of this, attacks against the kernel are used to gain complete control over a system, generally as part of an “elevation or privilege” (EoP) or “privilege escalation” attack. Typically, attacks against the kernel are used in conjunction with code execution attacks so that an attacker can target a limited privilege user but ultimately gain full control over the system.

Privilege escalation attacks against the kernel have been around for some time and are well-known and can be well protected against.

Kernel APC attacks however are a different class of attack. These don’t attack the kernel to gain privileges. Instead kernel APC attacks already have kernel privileges and use them to further carry out their attack. In this case by making legitimate programs execute malicious code rather than their own legitimate code.

Kernel APC attacks do this using their control over the kernel to redirect APCs: “Asynchronous Procedure Calls”. APCs can basically be thought of as places in line for the CPU that the kernel gives access to. In a kernel APC attack, the attacker gives a legitimate program’s place in line to the attacker’s code.

The crux of what makes this attack technique so important is how the technique uses this level of control to have legitimate programs run illegitimate commands. It’s easier to detect and prevent illegitimate programs (malware) from executing commands. But when legitimate programs execute illegitimate commands, it’s harder to detect and prevent: it’s not always clear whether a command is legitimate or not, and interfering with commands from legitimate programs can have significant (sometimes catastrophic) unintended consequences. And finally because of ways that kernel APC attacks are carried out, it doesn’t leave the usual fingerprints you find after an attack making detection harder still.

Taken altogether, these make kernel APC attacks an effective and sophisticated technique. And while this technique alone isn’t solely responsible for the damaging power of WanaCrypt0r/WannaCry and Petya/NotPetya it is certainly an important contributing factor.

Perhaps more importantly, it’s a piece of those attacks that has escaped relative notice outside of some specialized parts of the research community.

New effective attack techniques that escape notice are always inviting for other copycat attackers. A good way to defend against this is to understand and be aware of the thread: forewarned is forearmed.

If you want a more detailed understanding of kernel APC attacks as they occurred in WanaCrypt0r/WannaCry, two good resources are Microsoft’s MMPC blog “WannaCrypt ransomware worm targets out-of-date systems” and Countercept’s “DOUBLEPULSAR Usermode Analysis: Generic Reflective DLL Loader”.

2 Minute Threat Brief: FreeMilk Conversation Hijacking Spear Phishing Campaign

Posted on by Eila Shargh

Unit 42 released details about a new spear phishing campaign called FreeMilk that uses a relatively new attack technique that can be highly effective. This is the kind of technique that is likely to be aimed at high value targets. Targets of these attacks are likely to be individuals with access to valuable or sensitive information such as members on a Board of Directors, C-level executives, military and political personnel, or those with compromising information such as journalists or activists. Individuals close to those previously mentioned could also be used as part of the attack campaign such as an executive assistant to a CEO or even friends or family.

How it Works

Phishing attacks are broad, leveraging email messages crafted around common, generalized topics in order to trick recipients into opening an email message and its attachments. Attackers will cast a wide net, with no regard to who the victims are, hoping that a decent percentage of attacks are successful.

Spear phishing, like the name implies, is a more targeted form of phishing which incorporates a theme directly related to the target. Using this approach, victims are more inclined to trust the sender, and open the email message and any attachments resulting in the success of the attack.

FreeMilk is an advanced spear phishing attack campaign that, instead of using a theme to lure targets into downloading a malicious attachment, hijacks an in-progress email conversation.

Simply explained:

  • Alice (A) and Bob (B), are having an ongoing email conversation.
  • The attacker, Charlie (C) will carry out an attack, likely using some form of credential theft, in order to gain control to Alice’s email account.
  • Using Alice’s email account, Charlie sends an email containing a malicious attachment that appears to be relevant to the ongoing email conversation between Alice and Bob.
  • Bob receives the email, and thinking it’s from Alice, opens the malicious attachment and the attack is successful.

FreeMilk_featured

Figure 1 Conversation Hijacking to Deliver Malware

How to Defend Against It

Unit 42 observed this specific attack taking advantage of a vulnerability in Microsoft Office, which has a patch available. To protect against FreeMilk and attacks alike, ensure your systems and devices are updated with the latest operating systems and security patches.

Additionally, multiple layers of security for devices and networks create additional layers of protection to prevent against these types of attacks. For example, multi-factor authentication would prevent an attacker from abusing stolen credentials, hindering their ability to access an email account and successfully complete the FreeMilk attack campaign.

Threat Brief: Conversation Hijacking Spear Phishing

Posted on by Unit 42

Spear Phishing is a specific attack technique that has become widely used in the past few years. In our new research blog “FreeMilk: A Highly Targeted Spear Phishing Campaign”, our Unit 42 research team has discovered an attack campaign that takes spear phishing targeting to the next level by hijacking in-progress email conversations. While these are not broad attacks, they represent an escalation in attacker spear phishing techniques in a way that makes it even more important than ever to have a prevention framework in place.

Standard phishing attacks are broad attacks that use general email messages to carry out the attacks. Standard phishing attacks aren’t personalized: they use very common themes or lures in a generalized way in conjunction with a large enough pool of targets. The idea is that by chance some percentage of the phishing emails will look legitimate enough to the recipient to be successful.

Basically, standard phishing attacks rely on the law of averages for its success. As such, it’s a suitable tactic when an attacker cares less about who falls for it than how many fall for it.

A good example of a generalized phishing campaign is the Blank Slate Campaign we wrote about in March 2017. This attack campaign was so generalized that the attackers didn’t even bother with any theme or lure: they simply sent blank messages with malicious attachments for the recipient to open.

Spear phishing is a more refined and focused version of phishing. Instead of using generalized themes or lures, spear phishing uses themes or lures that are in some way relevant or appropriate for the target recipient. For example, a spear phishing attack could use email messages about military exercises sent to military or government targets like we saw with our recent research into CMSTAR Trojan attacks. Because the malicious email has a context for the target, he or she is more likely to trust it and open the email message and any attachments.

Spear phishing focuses on the quality of the theme and lure where standard phishing focuses on quantity. Spear phishing is a suitable tactic when an attacker cares about who falls for it. Where a phishing attack campaign may send malicious emails out to thousands or tens of thousands of targets, a spear phishing campaign my send out just one malicious email to one target. Sometimes, when that target is a high-value target this attack can also be referred to as ‘Whaling”.

In our new research, our Unit 42 research team has found an attack that takes the refining of spear phishing one step further. Rather than simply using a theme or lure that is relevant to the target, the attackers behind these attacks use an email conversation that’s in progress to carry out their attack.

You can see an image of how this works below in Figure 1.

FreeMilk_1

Figure 1 Conversation Hijacking to Deliver Malware

How this works is that two users, Alice (A) and Bob (B) are carrying on an email conversation. A shown in the top figure, an attacker, Charlie (C), carries out an attack that enables him to gain complete control of Alice’s email account, most likely through some form of credential theft. Once Charlie has access to Alice’s email account, he then finds email conversations between Alice and Bob, his ultimate target. When he finds one that is still in progress, he crafts a malicious attack email that seems to be relevant to the ongoing email conversation and sends it to Bob as shown in the bottom figure. If Charlie was successful in crafting the attack email to seem legitimate enough, Bob will open the email and any attachments and the attack will succeed.

Unlike phishing or even general spear phishing, this is a highly sophisticated, labor intensive, focused attack. Carrying out a successful conversation hijacking spear phishing attack requires knowing someone that the ultimate target is communicating with, compromising that person’s account, identifying an ongoing email conversation with the ultimate target, crafting an email to appear part of that ongoing email conversation and finally sending it. Even then there’s no guarantee of success since the target may somehow recognize the attack or have sufficient prevention controls in place to prevent the attack from succeeding.

Given all those points, this isn’t an attack that many of us need to worry about. But those out there who are in positions that might make them a high value target do need to be concerned about this. Whether you’re on the board of directors for an organization, a CEO/CFO/CSO, entrusted with important military or political information, are a journalist, or an activist/dissident, this is a kind of attack that you could face. And like with all targeted attacks, you don’t have to be the ultimate target of the attack campaign to be a target: this is a tactic that can be used as part of a broader attack campaign. For example, if you are the executive assistant for a CEO, you could be the target of an attack like this (“Bob” in our scenario above) so that you in turn are used to carry out an attack (“Alice” in our scenario above) against your CEO (who then becomes “Bob” in our scenario above).

Because of the nature of the attack, unless you verify each and every email you receive, it’s unlikely that you’ll necessarily be able to spot and thwart an attack. In this case, your best means of protection lies in prevention. And prevention here is really focused on two things.

First, keeping your systems and devices fully up-to-date with the latest software and security updates. The specific attack our Unit 42 research team has seen using this technique relied on an attack against a vulnerability in Microsoft Office for which a patch is available. If an attacker tried to carry this attack out against a target that was patched for this vulnerability, it would fail.

Second, using security on your systems, devices and networks that provides multiple layers of protection can help prevent attacks.

Conversation hijacking spear phishing isn’t a threat everyone faces, but for those who do it represents a significant escalation in terms of sophistication and social engineering of spear phishing attacks. It also takes spear phishing attacks to a level that makes it nearly impossible to distinguish an attack email from a legitimate email. And so technological prevention controls (patching, robust security) are even more for effective prevention.

FreeMilk: A Highly Targeted Spear Phishing Campaign

Posted on by Juan Cortes

In May 2017, Palo Alto Networks Unit 42 identified a limited spear phishing campaign targeting various individuals across the world. The threat actor leveraged the CVE-2017-0199 Microsoft Word Office/WordPad Remote Code Execution Vulnerability with carefully crafted decoy content customized for each target recipient. Our research showed that the spear phishing emails came from multiple compromised email accounts tied to a legitimate domain in North East Asia. We believe that the threat actor hijacked an existing, legitimate in-progress conversation and posed as the legitimate senders to send malicious spear phishing emails to the recipients as shown below in Figure 1.

FreeMilk_1

Figure 1 Conversation Hijacking to Deliver Malware

Upon successful exploitation, the malicious document delivered two malware payloads PoohMilk and Freenki.

The targeted victims in this campaign we identified include:

  • a bank based in the Middle East
  • trademark and intellectual property service companies based in Europe
  • an international sporting organisation
  • individuals with indirect ties to a country in North East Asia

In past activity that we believe is linked to this same threat actor, dissidents and others were also likely targeted. We named this campaign “FreeMilk” after the words found in the malwares’ PDB path string.

Malicious Document

The threat actor leveraged Microsoft Word CVE-2017-0199 vulnerability which is popularly used in both targeted and non-targeted attacks at present. The malicious document sends out the following beacon to a compromised website server as shown in Figure 2.

Figure 2. Malicious Word document callback beacon

The C2 server responds with a Base64 encoded PowerShell script which in turn downloads two fake image files that contain embedded PE binaries and a JavaScript file which extracts the embedded PE binaries onto the victim host as shown in Figure 3. The extracted PE payloads are what we label as PoohMilk and Freenki.

Original File SHA256

(Original File Name)

 Download URL Extracted Payload SHA256

(Saved File Name)

 Description
1893af524edea4541c317df288adbf17ae4fcc3a30d403331eae541281c71a3c

(udel_ok.ipp)

 http://old.jrchina[.]com/btob_asiana/udel_ok.ipp - JavaScript to extract and run the payload
64ef80e7639c8c5dddf239883617e6740c6b3589f995d11314d36ab64fcfc54c

(appach01.jpg)

 http://old.jrchina[.]com/btob_asiana/appach01.jpg 7f35521cdbaa4e86143656ff9c52cef8d1e5e5f8245860c205364138f82c54df

(Windows-KB275122-x86.exe)

 Fake image extracts to Freenki downloader
40572e1fc37f4376fdb2a33a6c376631ff7bc00b1e64538a0385bc1e09a85574

(appach02.jpg)

 http://old.jrchina[.]com/btob_asiana/appach02.jpg 35273d6c25665a19ac14d469e1436223202be655ee19b5b247cb1afef626c9f2

(Windows-KB271854-x86.exe)

 PoohMilk loader

Figure 3. Downloaded files and extracted payloads

PoohMilk Loader Analysis

Our analysis shows that PoohMilk is the first stage loader. After a successful exploitation, it sets persistence in the registry with the appropriate command line argument to execute the second stage payload, in this case, Freenki. The following registry key-value pair in Figure 4 is used.

FreeMilk_2

Figure 4. Registry key value set for the second stage payload by PoohMilk

In addition to setting up the next stage, PoohMilk attempts to read and parse a file named "wsatra.tmp" in the user’s temp folder. If found, it reads its contents hoping to identify a path which is then searched in order to identify any file with an LNK extension, the same path is then searched for files with a ZIP extension. The exact reason why it looks for *.lnk files is unclear. However, if it finds a *.zip file, it extracts its contents and copies the data to a file under the user's temp folder. Using the following filename format:

"%s\\Rar0tmpExtra%d.rtf"

Where the '%d' is taken from the return value of a call to the Windows API GetTickCount(). It then continues to execute this file with the Windows API ShellExecuteW().

The following PDB paths in Figure 5 were found from PoohMilk loader samples.

Figure 5. PDB paths found from PoohMilk samples

It was observed that the threat actor consistently delivers different malware payloads together with PoohMilk loader. We assume this is an attempt to lower the chance of payload malware getting exposed to the security research community as it can hide its malicious behaviour when being analysed by automated analysis systems without the proper command line argument.

Freenki Downloader Analysis

Freenki has two main purposes. The first is to collect host information and the other is to serve as a second stage downloader. Each of these will be explained in detail in the following section.

Freenki depends on the right command line argument being passed to execute any of its interesting code, if no arguments are passed it simply exits. Freenki accepts three arguments which are described below:

  • console : It sets up persistence in the registry by using the current path of where the sample is being executed from and appending the parameter ‘help’:
    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\
    • key name: runsample
    • key value: “[CURRENT_EXECUTION_PATH] help”
  • help: This argument allows the malware to execute its main function which beacons to its C2. Further details in the next section.
  • sample: This argument allows the malware to set up persistence and communicate with its C2. Synonymously as if we were to call the malware with the argument console followed by help.

The first thing Freenki does is collect the host’s MAC address. This is converted to a hex-string and is appended to each request to its C2. This value is likely to be used as an ID to identify the victim to the attacker. It is important to note that each request is postfix with an additional identifier followed by the MAC address. The following IDs are used and all request are made with a HTTP POST method, and between each beacon the malware sleeps for 25 seconds.

  • 0x30 = Initial communication made to the C2. The malware loops over sending this initial request until the C2 responds with a HTTP OK (200) status with additional data.
  • 0x31 = This identifier is used to send host information. Below are the details collected.
    • Username
    • ComputerName
    • Retrieves the file version of kernel32.dll
    • Determines whether the process is running in x64, based on the Windows API function IsWow64Process() return value
    • Collects all Ethernet MAC addresses
    • Attempts to perform a WMI query to get: ComputerName, Model and Manufacturer
    • Collects all running processes

Figure 6 shows what the data looks like before encoding, more on this later

FreeMilk_3

Figure 6. Host information collected by Freenki (before encoding)

  • 0x34 = This identifier is used when the malware attempts to take a screenshot of the victim computer. The malware only collects a total of three screenshot before moving on.
  • 0x32 = This identifier is used to retrieve a secondary C2 server. The data is received encoded and then parsed to get the new C2 address. More on this in the secondary payload delivery section.
  • 0x33 = The malware sends this identifier prior to parsing the decoded secondary C2.
  • 0x35 = This identifier is used after it executes the secondary payload. The malware sends back the secondary C2 used to download the payload.

The malware uses the same algorithm to decode and encode most of its data. The initial C2 and hard coded User-Agent string are encoded and can be decoded using the code snippet in Figure 7. It is not a new method, but is worth noting that Freenki uses SSE instructions to decode its data.

Figure 7. Python script to decode Freenki’s encoded data

We mentioned that one of the identifiers the malware uses gives it the capability to retrieve a secondary C2 address.  A somewhat important note is the author uses the Windows API InternetOpenUrl(), therefore the secondary C2 address comes appended with either HTTP, HTTPS or FTP.  Using the secondary C2 address the malware attempts to download another payload. This payload is expected to be greater than 100 bytes and to begin with the ASCII values: ‘PNGF’. This secondary payload has two encoding layers. One is solely used in this part of the code and the second is the same encoding discussed previously which is used throughout the malware’s code. Once decoded, the malware writes the secondary payload to the users %temp% folder with a pseudo-random name. Then using the Windows API ShellExecuteW() and a hard-coded argument ‘abai’, the malware executes the decoded payload (Figure 8).

FreeMilk_4

Figure 8. Secondary payload is executed with argument ‘abai’

Links to Previous Campaigns

Phishing campaign disguised as Hancom update

In multiple occasions, we observed the PoohMilk loader discussed in this blog being used to load another remote administration tool we call N1stAgent (Figure 9, detailed analysis available in Appendix B).

SHA256 Compile Date Original File Name Malware Family
1163da8c37ad9ba98d59b921ba8cf8e54bfc1282712cf754f4ff82b63f8e6027 2017-06-01 05:10:53 Windows-KB276133-x86.exe N1stAgent RAT
ba5905c2fe46bd6734973139e759ba405fd193c2342dfcac396e9d529b57821b 2017-06-01 05:17:06 Windows-KB251952-x86.exe PoohMilk Loader

Figure 9: N1stAgent and PoohMilk loader set

N1stAgent is not widely used and appears to be solely used in targeted attacks. It is well known for its first appearance made in the phishing campaign in January 2016. N1stAgent was delivered via phishing emails disguised as Hancom’s security patch.

Watering hole on anti-government media website

In August 2016, visitors to an anti-government media website operated by defectors in United Kingdom were targeted by watering hole attack with CVE-2016-0189 Microsoft Internet Explorer exploit. The exploit code attempted to deliver Freenki (Figure 10) as payload malware.

SHA256 Download URL
99c1b4887d96cb94f32b280c1039b3a7e39ad996859ffa6dd011cf3cca4f1ba5 http://www.ethanpublishing[.]com/ethanpublishing/phpcms/templates/default/member/pub/jquery_min_2.2.6.js

Figure 10. Freenki downloaded from the watering hole incident

Conclusion

The FreeMilk spear phishing campaign is still ongoing, and is a campaign with a limited but wide range of targets in different regions. The threat actor tried to stay under the radar by making malware that only executes when a proper argument is given, hijacked an existing email conversation and carefully crafted each decoy document based on the hijacked conversation to make it look more legitimate. We were not able to identify the second stage malware delivered via Freenki downloader during the campaign. We did notice some C2 infrastructure overlap with other cases previously mentioned by TALOS and a private researcher. However, we are not conclusive about these connections as the C2 domains were compromised websites and there were several months between the incidents.

  • AutoFocus customers can identify this, and other samples related to it using the BigPooh, Freenki, PoohMilk and N1stAgent tags
  • WildFire and Traps properly classify the samples described in this report as malicious.

Appendix A: Indicators of Compromise

a50543919c52ccaea40155ce35aa791bc86bd634240fb51922827223aca5c88a

201b876bcb97f6c8972cc677bdf1e3e2b2f069ae2ec4653db8af4797884efa30

35273d6c25665a19ac14d469e1436223202be655ee19b5b247cb1afef626c9f2

ba5905c2fe46bd6734973139e759ba405fd193c2342dfcac396e9d529b57821b

0f82ea2f92c7e906ee9ffbbd8212be6a8545b9bb0200eda09cce0ba9d7cb1313

34478d6692f8c28332751b31fd695b799d4ab36a8c12f7b728e2cb99ae2efcd9

7f35521cdbaa4e86143656ff9c52cef8d1e5e5f8245860c205364138f82c54df

99c1b4887d96cb94f32b280c1039b3a7e39ad996859ffa6dd011cf3cca4f1ba5

1893af524edea4541c317df288adbf17ae4fcc3a30d403331eae541281c71a3c

1163da8c37ad9ba98d59b921ba8cf8e54bfc1282712cf754f4ff82b63f8e6027

ef40f7ddff404d1193e025081780e32f88883fa4dd496f4189084d772a435cb2

old.jrchina[.]com

foodforu.heliohost[.]org

www.ethanpublishing[.]com

discgolfglow[.]com

Appendix B: N1stAgent Analysis

Sample properties:

SHA256 1163da8c37ad9ba98d59b921ba8cf8e54bfc1282712cf754f4ff82b63f8e6027
File Name Windows-KB276133-x86.exe
File Size 302,080
Timestamp 2017-06-01 05:10:53
Import Hash 3d3f31627c09d1e68647b2a66491efb3
PDB Path F:\Backup\2nd\Agent\Release\Agent.pdb

N1stAgent requires specific arguments to execute successfully. Some samples check only for one argument and others check for three different arguments where each one is either executing the malware, sets a startup key and runs the malware or installs the malware as a service. Service installation was not working in our found samples because the author seems to be forgotten to install the service with arguments. Here is an example of a sample which supports three arguments:

Argument Description
help Run the malware

 
333 Add a startup method and run the malware

Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\#

Name: Defender Update

Path: <current filename> help
usage Installs itself as a service

- Display name: Windows Normai TCP?IP ICMP Service

- Service Name: icmphosts

- Description: Provides support for the ICMP over TCP/IP service and ARP name resolution for clients on the network, therefore enabling users to Network, print, and log on to the network. If this service is stopped, these functions might be unavailable. If this service is disabled, any services that explicitly depend on it will fail to start.

Figure B-1. N1stAgent supported arguments

Connection to C2

The agent will try to read its configuration from a file in %APPDATA% with the file extension “.DAT”. The file is encoded with simple one byte XOR and will be decoded when read. If these files do not exist on the system it will skip them and continue to connect to a configured IP address which is a web server. It will try to connect to the web server three times and each time it will send a GET request to download a file from the server which contains an additional IP address. The configuration which defines the web server information is encrypted with XOR and contains these three values:

  • Server IP address
  • Hostname
  • File name for the GET request

FreeMilk_5

Figure B-2. N1stAgent C2 connection

If the connection does not work or if the server is down it will try to connect to another predefined IP address which is also stored encrypted in the binary. It will connect to the server, send its network adapter address and wait for commands from the server.

If the server responds back with the command ID 19899003 then it will contain a new IP address where the agent should connect to and then the agent will finally reveal its backdoor functionality.

The backdoor functionality supports basically 3 functions. First feature is remote shell (command “sm”) which emulates cmd.exe on the remote host. This feature is interesting because the code is copy pasted from Wine command program source code.

FreeMilk_6

Figure B-3. “Wine Cmd” in N1stAgent

The second feature is the file manager (command “fm”) which supports the basic file features like list-, move-, delete-, set date time-, upload- and download files.

The third feature (command “gm”) is a function which lets the remote attacker change the configuration. For example, he can create the configuration files in %APPDATA% directory which contain additional IP addresses where the malware should connect to in future.

Threat Actors Target Government of Belarus Using CMSTAR Trojan

Posted on by Josh Grunzweig

Palo Alto Networks Unit 42 has identified a series of phishing emails containing updated versions of the previously discussed CMSTAR malware family targeting various government entities in the country of Belarus.

We first reported on CMSTAR in spear phishing attacks in spring of 2015 and later in 2016.

In this latest campaign, we observed a total of 20 unique emails between June and August of this year that included two new variants of the CMSTAR Downloader. We also discovered two previously unknown payloads. These payloads contained backdoors that we have named BYEBY and PYLOT respectively.

CMSTAR_1

Figure 1 Diagram of the attack sequence

Phishing Emails

Between June and August of this year, we observed a total of 20 unique emails being sent to the following email addresses:

Email Address Description
press@mod.mil[.]by Press Service of the Ministry of Defense of the Republic of Belarus
baranovichi_eu@mod.mil[.]by Baranovichi Operational Management of the Armed Forces
modmail@mod.mil[.]by Ministry of Defense of the Republic of Belarus
admin@mod.mil[.]by Ministry of Defense of the Republic of Belarus
itsc@mod.mil[.]by Unknown. Likely used by Ministry of Defense of the Republic of Belarus
mineuvs@mod.mil[.]by Minsk Operational Administration of the Armed Forces
inform@mod.mil[.]by Unknown. Likely used by Ministry of Defense of the Republic of Belarus
uporov_milcoop@mod.mil[.]by Unknown. Likely used by Ministry of Defense of the Republic of Belarus
video@gpk.gov[.]by State Border Committee of the Republic of Belarus
armscontrol@mfa.gov[.]by International Security and Arms Control Department, Ministry of Foreign Affairs
ablameiko@mia[.]by Unknown. Likely used by the Ministry of Internal Affairs of the Republic of Belarus

 

These emails contained a series of subject lines, primarily revolving around the topic of Запад-2017 (‘West-2017’), also known in English as Zapad 2017. Zapad 2017 was a series of joint military exercises conducted by the Armed Forces of the Russian Federation and the Republic of Belarus, held from September 14th to 20th in 2017.

The full list of subject lines is as follows:

  • Fwd:Подготовка к Запад-2017 [Translation: Fwd:Preparing for the West-2017]
  • выпуск воспитанников [Translation: graduation]
  • К Запад-2017 [Translation: To West-2017]
  • Запад-2017 [Translation: West-2017]

An example of some of the previously mentioned emails may be seen below.

CMSTAR_2

Figure 2 Phishing email sent to Belarus government (1/2)

CMSTAR_3

Figure 3 Phishing email sent to Belarus government (2/2)

Decoy Documents

We observed that the attachments used in these emails contained a mixture of file types. RTF documents, Microsoft Word documents, and a RAR archive. The RAR archive contained a series of images, a decoy document, and a Microsoft Windows executable within it. The executable has a .scr file extension, and is designed to look like a Windows folder, as seen below:

CMSTAR_4

Figure 4 Payload disguising itself as a Microsoft Windows folder

The rough translation of the folder and file names above are ‘Preparations for large-scale West-2017 exercises in this format are being held for the first time.’ Within the actual folder, there are a series of JPG images, as well as a decoy document with a title that is translated to ‘Thousands of Russian and Belarusian military are involved in the training of the rear services.’

CMSTAR_5

Figure 5 Embedded images and decoy document within RAR

The decoy document contains the following content:

CMSTAR_6

Figure 6 Decoy document within RAR

The other RTF and Word documents used additional decoy documents, which can be seen below.

CMSTAR_7

Figure 7 Decoy document with translation (1/2)

CMSTAR_8

Figure 8 Decoy document with translation (2/2)

While we observed different techniques being used for delivery, all attachments executed a variant of the CMSTAR malware family. We observed minor changes between variants, which we discuss in the CMSTAR Variations and Payloads section of the blog post.

The Word documents, which we track as Werow, employ malicious macros for their delivery. More information about these macros may be found in the Appendix of the blog post. Additionally, we have included a script that extracts these embedded payloads that can also be found in the Appendix.

The RTF documents made use of CVE-2015-1641. This vulnerability, patched in 2015, allows attackers to execute malicious code when these specially crafted documents are opened within vulnerable instances of Microsoft Word. The payload for these samples is embedded within them and obfuscated using a 4-byte XOR key of 0xCAFEBABE. We have included a script that can be used to extract the underlying payload of these RTFs statically that can be found in the Appendix.

The SCR file mentioned previously drops a CMSTAR DLL and runs it via an external call to rundll32.exe.

CMSTAR Variations and Payloads

In total, we observed three variations of CMSTAR in these recent attacks against Belarusian targets. The biggest change observed between them looks to be minor modifications made to the string obfuscation routine. A very simple modification to the digit used in subtraction was modified between the variants, as shown below:

CMSTAR_9

Figure 9 String obfuscation modifications between CMSTAR variants

The older variation, named CMSTAR.A, was discussed in a previous blog post entitled, “Digital Quartermaster Scenario Demonstrated in Attacks Against the Mongolian Government.”

The CMSTAR.B variant was witnessed using both a different mutex from CMSTAR.A, as well as a slightly modified string obfuscation routine. The mutexes used by CMSTAR ensure that only one instance of the malware runs at a time. The CMSTAR.C variant used the same mutex as CMSTAR.B, however, again used another slightly modified string obfuscation routine. We found all CMSTAR variants using the same obfuscation routine when I payload was downloaded from a remote server. We have included a tool to extract mutex and C2 information from all three CMSTAR variants, as well as a tool to decode the downloaded payload: both may be found in the Scripts section.

An example of CMSTAR downloading its payload may be found below:

CMSTAR_10

Figure 10 Example HTTP download by CMSTAR

When expanding the research to identify additional CMSTAR.B and CMSTAR.C variants, we identified a total of 31 samples. Of these 31 samples, we found two unique payloads served from three of the C2 URLS—One of which was downloaded from a sample found in the phishing attacks previously described. Both payloads contained previously unknown malware families. We have named the payload found in the email campaign PYLOT, and the malware downloaded from the additional CMSTAR samples BYEBY.

Both malware families acted as backdoors, allowing the attackers to execute commands on the victim machine, as well as a series of other functions. More information about these individual malware families may be found in the appendix.

Conclusion

During the course of this research, we identified a phishing campaign consisting of 20 unique emails targeting the government of Belarus. The ploys used in these email and decoy documents revolved around a joint strategic military exercise of the Armed Forces of the Russian Federation and the Republic of Belarus, which took place between September 14th and September 20th of this year. While looking at the emails in question, we observed two new variants of the CMSTAR malware family. Between the samples identified and others we found while expanding our research scope, we identified two previously unknown malware families.

Palo Alto customers are protected from this threat in the following ways:

  • Tags have been created in AutoFocus to track CMSTAR, BYEBY, and PYLOT
  • All observed samples are identified as malicious in WildFire
  • Domains observed to act as C2s have been flagged as malicious
  • Traps 4.1 identifies and blocks the CVE-2015-1641 exploit used in these documents
  • Traps 4.1 blocks the macros used in the malicious Word documents

A special thanks to Tom Lancaster for his assistance on this research.

Appendix

Werow Macro Analysis

The attacker used the same macro dropper all of the observed Microsoft Word documents we analyzed for this campaign. It begins by building the following path strings:

  • %APPDATA%\d.doc
  • %APPDATA%\Microsoft\Office\WinCred.acl

The ‘d.doc’ path will be used to store a copy of the Word document, while the ‘WinCred.acl’ will contain the dropped payload, which is expected to be a DLL.

CMSTAR_11

Figure 11 Macro used to drop CMSTAR

Werow uses rudimentary obfuscation to hide and re-assemble the following strings:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WinCred
  • rundll32 %APPDATA%\Microsof\Office\WinCred.acl ,WinCred

These strings will be used at the end of the macro’s execution to ensure persistence via the Run registry key.

The malware proceeds to read an included overlay within the original Word document from a given offset. This data is decoded using and XOR operation, as well as an addition operation. It can be represented in Python as follows:

Once this overlay is decoded, it is written to the ‘WinCred.acl’ file and loaded with the ‘WinCred’ export. A script has been provided in the Scripts section that, in conjunction with oletools, can statically extract the embedded DLL payload from these documents.

RTF Shellcode Analysis

The RTF documents delivered in this attack campaign appear to be created by the same builder. All of the RTF files attempt to exploit CVE-2015-1641 to execute shellcode on the targeted system. Please reference https://technet.microsoft.com/en-us/library/security/ms15-033.aspx for more information.

The shellcode executed after successful exploitation begins by resolving the API functions it requires by enumerating the API functions within loaded modules in the current process. It then builds the following list of values:

CMSTAR_12

The shellcode then enumerates the API functions, subjects them to a ROR7 hashing routine and XORs the resulting hash with 0x10ADBEEF. It uses the result of this arithmetic to compare with the list of values above to find the API functions it requires to carry out its functionality.

ROR7 ROR7^0x10ADBEEF API Func
1a22f51 110f91be WinExec
741f8dc4 64b2332b WriteFile
94e43293 84498c7c CreateFileA
daa7fe52 ca0a40bd UnmapViewOfFile
dbacbe43 cb0100ac SetFilePointer
ec496a9e fce4d471 GetEnvironmentVariableA
ff0d6657 efa0d8b8 CloseHandle

 

After resolving the API functions, the shellcode then begins searching for the embedded payload and decoy within the initial RTF file. It does so by searching the RTF file for three delimiters, specifically 0xBABABABABABA, 0xBBBBBBBB and 0xBCBCBCBC, which the shellcode uses to find the encrypted payload and decoy. The shellcode then decrypts the payload by XOR'ing four bytes at at time with the key 0xCAFEBABE, and decrypts the decoy by XOR'ing four bytes at a time using the key 0xBAADF00D. Here is a visual representation of the delimiters and embedded files:

CMSTAR_delimiters

After decrypting the payload, it saves the file to the following location:

%APPDATA%\Microsoft\Office\OutL12.pip

The shellcode then creates the following registry key to automatically run the payload each time the system starts:

Software\Microsoft\Windows\CurrentVersion\Run : Microsoft

The shellcode saves the following command to this autorun key, which will execute the OutL12.pip payload, specifically calling its 'WinCred' exported function:

rundll32.exe
"%APPDATA\Roaming\Microsoft\Office\OutL12.pip",WinCred

The shellcode will then overwrite the original delivery document with the decrypted decoy contents and open the new document.

PYLOT Analysis

This malware family was named via a combination of the DLLs original name of ‘pilot.dll’, along with the fact it downloads files with a Python (.py) file extension.

PYLOT begins by being loaded as a DLL with the ServiceMain export. It proceeds to create the following two folders within the %TEMP% path:

  • KB287640
  • KB887209

PYLOT continues to load and decode an embedded resource file. This file contains configuration information that is used by the malware throughout its execution. The following script, written in Python, may be used to decode this embedded resource object:

Looking at the decoded data, we see the following:

CMSTAR_13

Figure 12 Decoded embedded configuration information

The malware continues to collect the following information from the victim computer:

  • Computer name
  • IP addresses present on the machine
  • MAC addresses
  • Microsoft Windows version information
  • Windows code page identifier information

This information is used to generate a unique hash for the victim machine. PYLOT then begins entering its C2 handler routine, where it will use HTTP for communication with the remote host.

Data sent to the remote C2 server is encrypted using RC4 with the previously shown key of ‘BBidRotnqQpHfpRTi8cR.’ It is then further obfuscated by base64-encoding this encrypted string. An example of this HTTP request containing this data can be seen below.

 

CMSTAR_14

Figure 13 HTTP request made by PYLOT to remote server

The decrypted data sent in the request above is as follows. Note that all of this custom data format has not been fully identified, however, we’re able to see various strings, including the embedded configuration string of ‘fGAka0001’, as well as the victim hash of ‘100048048.’

CMSTAR_15

Figure 14 Decrypted data sent by PYLOT to remote server

The base64-encoded string at the end of the data contains the collected victim machine information from earlier, separated by a ‘|’ delimiter.

The remote C2 server responds using the same data format. An example response can be seen below.

CMSTAR_16

Figure 15 Response from remote C2 server

The decoded data at the end of the response contains various URIs to be used by the malware to receive commands, as well as other information that has yet to be fully researched.

A number of commands have been identified within PYLOT, including the following:
• Download batch script
• Run batch script
• Delete file
• Rename file
• Execute file
• Download file
• Upload file

BYEBY Analysis

BYEBY was named based on a string within the malware itself. Most strings found within this malware are concatenated to 6 characters. One such example was an instance where a debug string contained ‘BYE BY’, which was likely a concatenated form of the phrase ‘BYE BYE’.

This malware is loaded as a DLL, with an export name of ServiceMain. When the malware is initially loaded, it begins by checking to see if it is running within either of the following paths:

  • [SYSTEM32]\svchost.exe
  • [SYSTEM32]\rundll32.exe

If it finds itself not running in either location, it will immediately exit. This is likely a technique used to bypass various sandboxing systems. Should it find itself running as svchost.exe, it will write the current timestamp and a value of ‘V09SS010’ (Base64 Decoded: ‘WORKMN’) to a file named ‘vmunisvc.cab’ within the user’s local %TEMP% folder. This file acts as a lot file and is written to frequently throughout the malware’s execution.

When the malware runs within the context of svchost.exe, it bypasses the installation routines and immediately enters the C2 handler.

When BYEBY is run within the context of rundll32.exe, it expects itself to be running for the first time. As such, it will register itself as a service with a name of ‘VideoSrv.’ After this service is created, BYEBY proceeds to enter it’s C2 handler function in a new thread.

BYEBY uses TLS for network communication, connecting to the following host on port 443:

  • oeiowidfla22[.]com

After the initial connection is established, BYEBY will collect the following system information and upload it to the remote C2:

  • Hostname
  • IP Address
  • Embedded String of 'WinVideo'
  • Major Windows Version
  • Minor Windows Version
  • Embedded String of '6.1.7603.16000'

The malware is configured to accept a number of commands. These appear to be Base64-encoded strings that, when decoded, provide their true meaning. Only the beginning of the commands are checked. The Base64-decoded strings have been included for the benefit of the reader.

  • aGVsbG8h [Decoded: hello!]
  • R09PREJZ [Decoded: GOODBY]
  • TElTVCBE [Decoded: LIST D]
  • U1RBUlRD [Decoded: STARTC]
  • Q09NTUFO [Decoded: COMMAN]
  • VFJBTlNG [Decoded: TRANSF]
  • RVhFQ1VU [Decoded: EXECUT]

A mapping of commands and their descriptions has been provided:

Command Description
aGVsbG8h Authenticate with the remote C2 server.
R09PREJZ Close socket connection with remote server.
TElTVCBE List drives on the victim machine.
U1RBUlRD Start an interactive shell on the victim machine.
Q09NTUFO Execute a command in the interactive shell
VFJBTlNG Upload or download files to the victim machine.
RVhFQ1VU Execute command in a new process.

Scripts

We created multiple scripts during the course of our research. We are sharing them here to assist other researchers or defenders that encounter this malware.

extract_cmstar_doc.py – Script to extract the embedded CMSTAR payload from Word documents.

extract_cmstar_rtf.py– Script to extract the embedded CMSTAR payload from RTFs.

extract_cmstar_strings.py – Script to identify possible mutex and C2 strings from CMSTAR variants.

decode_cmstar_payload.py – Script to decode a payload downloaded by CMSTAR.

Indicators of Compromise

CMSTAR Variants Identified in Phishing Campaign

65d5ef9aa617e7060779bc217a42372e99d59dc88f8ea2f3b9f45aacf3ba7209

2a0169c72c84e6d3fa49af701fd46ee7aaf1d1d9e107798d93a6ca8df5d25957

4da6ce5921b0dfff9045ada7e775c1755e6ea44eab55da7ccc362f2a70ce26a6

2008ec82cec0b62bdb4d2cea64ff5a159a4327a058dfd867f877536389a72fb6

cecd72851c265f885ff02c60cbc3e6cbf1a40b298274761f623dfa44782a01f8

d8c0f8ecdeceba83396c98370f8f458ea7f7a935aabbcc3d41b80d4e85746357

2c8267192b196bf8a92c8b72d52096e46e307fa4d4dafdc030d3e0f5b4145e9e

2debf12b1cb1291cbd096b24897856948734fa62fd61a1f24d379b4224bda212

79b30634075896084135b9891c42fca8a59db1c0c731e445940671efab9a0b61

b0065fc16ae785834908f024fb3ddd4d9d62b29675859a8e737e3b949e85327a

16697c95db5add6c1c23b2591b9d8eec5ed96074d057b9411f0b57a54af298d5

6843d183b41b6b22976fc8d85e448dcc4d2e0bd2c159e6d966bfd4afa1cd9221

3c3efa89d1dd39e1112558af38ba656e048be842a3bedb7933cdd4210025f791

b2bebb381bc3722304ab1a21a21e082583bf6b88b84e7f65c4fdda48971c20a2

09890dc8898b99647cdc1cceb97e764b6a88d55b5a520c8d0ea3bfd8f75ed83b

fd22973451b88a4d10d9f485baef7f5e7a6f2cb9ce0826953571bd8f5d866c2a

CMSTAR Download Locations in Phishing Campaign

http://45.77.60[.]138/YXza9HkKWzqtXlt.dat
http://45.77.60[.]138/mePVDjnAZsYCw5j.dat
http://45.77.60[.]138/UScHrzGWbXb01gv.dat
http://45.76.80[.]32/tYD7jzfVNZqMfye.dat
http://45.77.60[.]138/liW0ecpxEWCfIgU.dat
http://45.77.60[.]138/ezD19AweVIj5NaH.dat
http://45.77.60[.]138/jVJlw3wp379neaJ.dat
http://108.61.175[.]110/tlhXVFeBvT64LC9.dat
http://45.77.60[.]138/HJDBvnJ7wc4S5qZ.dat
http://45.77.60[.]138/JUmoT4Pbw6U2xcj.dat
http://108.61.175[.]110/oiUfxZfej29MAbF.dat
http://45.77.60[.]138/cw1PlY308OpfVeZ.dat
http://45.77.60[.]138/VFdSKlgCAZD7mmp.dat
http://45.77.60[.]138/c2KoCT5OHcVwGi7.dat
http://45.77.60[.]138/3kK24dXFYRgM6Ac.dat
http://45.77.60[.]138/WsEeRyHEhLO1kUm.dat

PYLOT SHA256

7e2c9e4acd05bc8ca45263b196e80e919ff60890a872bdc0576735a566369c46

PYLOT C2

wait.waisttoomuchmind[.]com

BYEBY SHA256

383a2d8f421ad2f243cbc142e9715c78f867a114b037626c2097cb3e070f67d6

BYEBY C2

oeiowidfla22[.]com

CMSTAR.B SHA256

8609360b43498e296e14237d318c96c58dce3e91b7a1c608cd146496703a7fac

f0f2215457200bb3003eecb277bf7e3888d16edcf132d88203b27966407c7dc3

aecf53a3a52662b441703e56555d06c9d3c61bddf4d3b23d9da02abbe390c609

960a17797738dc0bc5623c74b6f8a5d74375f6d18d20ba18775f26a43898bae6

e37c045418259ecdc07874b85e7b688ba53f5a7dc989db19d7e8c440300bd574

75ea6e8dfaf56fb35f35cb043bd77aef9e2c7d46f3e2a0454dff0952a09c134f

a65e01412610e5ed8fde12cb78e6265a18ef78d2fd3c8c14ed8a3d1cef17c91d

7170b104367530ae837daed466035a8be719fdb17423fc01da9c0ded74ca6ad1

13acddf9b7c2daafd815cbfa75fbb778a7074a6f90277e858040275ae61a252b

625ed818a25c63d8b2c264d0f5bd96ba5ad1c702702d8ffaa4e0e93e5f411fac

a56cd758608034c90e81e4d4f1fe383982247d6aeffd74a1dd98d84e9b56afdf

a4b969b93f7882ed2d15fd10970c4720961e42f3ae3fced501c0a1ffa3896ff5

e833bbb79ca8ea1dbeb408520b97fb5a1b691d5a5f9c4f9deabecb3787b47f73

8e9136d6dc7419469c959241bc8745af7ba51c7b02a12d04fec0bc4d3f7dcdf0

CMSTAR.B Download Locations

http://108.61.175[.]110/tlhXVFeBvT64LC9.dat
http://104.238.188[.]211/gl7xljvn3fqGt3u.dat
http://45.77.60[.]138/c2KoCT5OHcVwGi7.dat
http://108.61.175[.]110/gkMmqVvZ7gGGxpY.dat
http://108.61.175[.]110/z_gaDZyeZXvScQ6.dat
http://108.61.175[.]110/bDtzGVtqgiJU9PI.dat
http://45.77.60[.]138/liW0ecpxEWCfIgU.dat
http://45.77.60[.]138/JUmoT4Pbw6U2xcj.dat
http://108.61.175[.]110/oiUfxZfej29MAbF.dat
http://108.61.103[.]123/jvZfZ0gdTWtr46y.dat
http://108.61.103[.]123/06JcD5jz5dSHVAy.dat
http://108.61.103[.]123/nj3dsMMpyQQDBF3.dat
http://108.61.103[.]123/fHZvWtBGlFvs2Nr.dat
http://45.77.60[.]138/w57E8dktKb9UQyV.dat

CMSTAR.C SHA256

85e06a2beaa4469f13ca58d5d09fec672d3d8962a7adad3c3cb74f3f9ef1fed4

b8ef93227b59e6c8d3a1494b4860d15be819fae17b57fd56bfff9a51b7972ff0

9e6fdbbc2371ac8bc6db3b878475ed0b0af8950d50a4652df688e778beb87397

4e38e627ae21f1a85aa963ca990a66cf75789b450605fdca2f31ee6f0f8ab8f2

f4ff0ca7f2ea2a011a2a4615d9b488b7806ff5dd61577a9e3a9860f2980e7fc0

8de3fa2614b1767cfd12936c5adf4423ef25ea60800fa170752266e0ca063274

38197abde967326568e101b65203c2efa75500e5f3c084b6dd08fd1ba1430726

726df91a395827d11dc433854b3f19b3e28eac4feff329e0bdad93890b03af84

5703565ec64d72eb693b9fafcba5951e937c8ee38829948e9518b7d226f81c10

d0544a3e6d1b34b8b4e976c7fc62d4500f28f617e2f549d9a3e590b71b1f9cc5

2a8e5551b9905e907da7268aba50fcbc526cfd0549ff2e352f9f4d1d71bf32a7

d7cd6f367a84f6d5cf5ffb3c2537dd3f48297bd45a8f5a4c50190f683b7c9e90

8f7294072a470b886791a7a32eedf0f0505aaecec154626c6334d986957086e4

6419255d017b217fe984d3439694eb96806d06c7ea41a422298650969028c08c

CMSTAR.C Download Locations

http://45.77.58[.]49/54xfapkezW64xDE.dat
http://45.77.58[.]49/54xfapkezW64xDE.dat
http://45.77.62[.]181/naIXl13kqeV7Y2j.dat
http://45.77.58[.]160/9EkCWYA3OtDbz1l.dat
http://45.77.58[.]160/8h5NPYB5fAn301E.dat
http://45.77.58[.]160/9EkCWYA3OtDbz1l.dat
http://45.77.60[.]138/3kK24dXFYRgM6Ac.dat
http://45.77.60[.]138/ezD19AweVIj5NaH.dat
http://45.77.60[.]138/VFdSKlgCAZD7mmp.dat
http://45.77.60[.]138/HJDBvnJ7wc4S5qZ.dat
http://45.77.60[.]138/jVJlw3wp379neaJ.dat
http://45.77.60[.]138/YXza9HkKWzqtXlt.dat
http://45.77.60[.]138/UScHrzGWbXb01gv.dat
http://45.77.60[.]138/WsEeRyHEhLO1kUm.dat

Striking Oil: A Closer Look at Adversary Infrastructure

Posted on by Robert Falcone

While expanding our research into the TwoFace webshell from this past July, we were able to uncover several IP addresses that logged in and directly interfaced with the shell we discovered and wrote about. Investigating deeper into these potential adversary IPs revealed a much larger infrastructure used to execute the attacks. We found the infrastructure was segregated into different functions for specific malicious objectives. We found some sites that were set up as credential harvesters (likely used in phishing attacks), a compromised system that was used to interact with a TwoFace webshell to hide the actor’s location, and finally systems that interact with TwoFace webshell-compromised systems to provide command and control direction of those compromised systems.

In addition to uncovering the attack infrastructure for this adversary, we were able to determine a significant link between the operators of the set of attacks involving TwoFace and another attack campaign we have published on in detail: OilRig.

Spoofing Sites and Credential Harvesters

We observed the IP address 137.74.131[.]208 interacting with the TwoFace webshell as described in our previous blog. Our investigation of the passive DNS entries for this IP revealed a potential link to a credential harvesting campaign carried out by the threat group behind the TwoFace webshell attacks. Looking into passive DNS entries for the IP gave us the following domain resolutions:

  • owa-insss-org-ill-owa-authen[.]ml
  • webmaiil-tau-ac-il[.]ml
  • mail-macroadvisorypartners[.]ml
  • webmail-tidhar-co-il[.]ml
  • my-mailcoil[.]ml
  • logn-micrsftonine-con[.]ml
  • so-cc-hujii-ac-il[.]ml

These domain names, on initial inspection, appear to be emulating legitimate webmail login portals, indicating that these are likely to be credential harvesters. We confirmed this as seen below:

Strikingoil_1

Figure 1a. Example of a credential harvester

Strikingoil_2

Figure 1 b. Example of a credential harvester

Our further examination revealed that these credential harvesters were crafted to be exact replicas of the legitimate sites they were purporting to be. This is a common tactic deployed by adversaries leveraging credential harvesters to increase the chance that a user will input their credentials and decrease suspicion of nefarious activity.

Breaking down the intended targeting for these credential harvesters reveals interesting target grouping.

  • owa-insss-org-ill-owa-authen[.]ml is likely intended to mimic the INSSS or the Institute of National Security Studies, a thinktank for Israel’s national security agenda.
  • webmaiil-tau-ac-il[.]ml is likely intended to mimic Tel Aviv University, the largest university in Israel.
  • mail-macroadvisorypartners[.]ml is likely intended to mimic Macro Advisory Partners, a prominent strategic consulting firm that has published insights into the Israel region.
  • webmail-tidhar-co-il[.]ml is likely intended to mimic the Tidhar Group, an Israeli based real estate and property management company.
  • my-mailcoil[.]ml is likely intended to mimic Bezeq International’s webmail application. Bezeq International is an Israeli based telecommunications company providing consumer and enterprise services.
  • so-cc-hujii-ac-il[.]ml is likely intended to mimic the Hebrew University of Jerusalem which is the second oldest university in Israel.

Each of these organizations appear to be either Israeli based or have strong Israeli connections and interests. Credential harvesters in general are not uncommon, but it is significant to have a grouping of region and company specific harvesters. This grouping leads us to believe that this adversary is likely to have had a specific mission to accomplish, which involved breaching specific organizations. This is in contrast to more generic credential harvesting by targeting common applications such as Gmail or Facebook.

The relationship between the credential harvesters hosted on 137.74.131[.]208 and the interaction with TwoFace is still unclear at this time. We do know the operator of TwoFace had access to both TwoFace and these spoofing sites. And it is highly unlikely that it is a coincidence that these specifically designed spoofing sites were on the same infrastructure as TwoFace when both target the same geopolitical region.

Additional Webshells

By analyzing additional TwoFace samples, as well as the traffic seen associated with TwoFace, we were able to find additional webshells used by this threat group. The additional webshells show that this threat group does not solely rely on TwoFace when deploying a webshell on a compromised web server.

RunningBee

A second IP of high interest seen interacting with the TwoFace webshell was 192.155.x.x, which is owned by SoftLayer. This IP resolves to a domain owned by the Ministry of Oil of a nation-state in the Middle East. The use of this IP is interesting as there are only two possibilities as to why this specific IP would be directly interfacing with the TwoFace shell: either it is the adversary themselves, or it has been compromised and is being used as part of the adversary infrastructure.

Based upon additional telemetry found in AutoFocus, we believe it is highly likely that this IP was indeed compromised and added to the adversary infrastructure. The telemetry revealed that this IP was not only used to interact directly with the TwoFace shell discussed in our previous blog, but also used to upload post-exploitation tools to another shell hosted on a Middle Eastern educational institution. We have named this second webshell “RunningBee”.

RunningBee is a webshell that requires an actor to enter a password before running commands or uploading files to the webserver much like TwoFace. However, the shell itself is different from a UI and code perspective. The samples of RunningBee that we identified requires the password “NeshaNesha12” for interaction. This is notable because this same password was mentioned in Cylance’s Operation Cleaver report as a password for webshells used by one of the members of that operation.

Strikingoil_3

Figure 2 RunningBee webshell

Investigating RunningBee activity revealed that the 192.155.x.x IP uploaded at least four additional tools to that compromised system with RunningBee on it, as seen in Table 1. Please reference the 'Post-exploitation Tools SHA256' section at the end of this blog for full hashes of the tools mentioned throughout in this blog.

Date Uploaded SHA256 Filenames Tool
10/06/2016, 02/19/2017 3b08535b4add194... PsExec.exe, kb-11.exe PsExec
02/19/2017 28a0db561ff5a52... kb.exe Mimikatz
02/19/2017 450ebd66ba67bb4... Local.exe Local.Exe of Microsoft Windows NT Resource Kit
02/19/2017 5b7eb534a852c18... kbs.exe Mimikatz


Table 1 Post-exploitation tools found on RunningBee

The uploaded files were common examples of tools often found during the post-exploitation phase.

  • Psexec – a lightweight application part of the SysInternals package designed to execute processes on other systems and allow for interactive console access
  • Mimikatz – an open source tool designed to extract and use credential information from Windows systems
  • local.exe – a command line tool part of the NT Resource Kit to view members of local groups on remote servers or domains

Our analysis showed the specific hashes of these tools were placed on multiple other sites also containing TwoFace related webshells, leading us to believe that they are related to one specific adversary.

Based on the post-exploitation tools uploaded to RunningBee and common IP addresses interacting with the shells, we found four other related webshells hosted on webservers belonging to organizations in the Middle East. The tools listed in Table 2 include the same tools that were uploaded to RunningBee such as PsExec, Mimikatz and Local.exe. In addition to these tools, we also discovered the existence of the remote connection tool known as PuTTY Link (plink) and a custom Microsoft IIS (Internet Information Services) web server backdoor that we track as RGDoor. We believe the threat actors may have used plink to connect to additional systems on the compromised network after obtaining legitimate credentials using a tool such as mimikatz. RGDoor is an HTTP module that the threat actors are likely loading into the IIS web server to maintain an additional, backup access point should the compromised organization detect and remediate the installed webshell (e.g. TwoFace, RunningBee) from the server.

SHA256 Filename Tool Shells IP addresses uploading
744e0ce108598aa... S64.exe 1 138.201.209.162
bb9b4e088eb9910... z64.exe 1 89.163.206.0
28a0db561ff5a52... mom64.exe Mimikatz 2 137.74.131.208
6e623311768f1c4... s64.exe 3, 4 51.254.50.153, 212.16.80.102, 37.59.229.231, 91.121.237.227
3b08535b4add194... ps.exe PsExec 3, 4 51.254.50.153
6ae32cd3b5a8a1d... pl.exe PuTTY Link 3, 4 51.254.50.153, 91.121.237.227, 37.59.229.231, 176.9.164.252
450ebd66ba67bb4... Local.exe Local.Exe of Microsoft Windows NT Resource Kit 3 91.121.237.227
d3b03c0da854102... O6.exe Mimikatz 1 92.222.209.48, 94.23.172.49
5ead94f12c30743... O64.exe Mimikatz 1 92.222.209.51
caf5f9791ab3049... i64.exe 1 138.201.209.182, 5.39.59.97, 91.121.237.224
497e6965120a7ca... HTTPParser.dll RGDoor 1 5.39.59.97

 

Table 2 Post-exploitation tools and associated IPs

Figure 3 Visualization of relationships of webshell and tools

LittleFace

As we reported in our TwoFace blog, the TwoFace shell was unique in that it was actually two webshells, where after initial authentication to a loader webshell, a secondary webshell with additional functionality was unpacked and made accessible to the operator. After gathering additional TwoFace loader shells, we noticed that some of these TwoFace loaders contained an embedded shell that differed from the TwoFace payload we originally found and published in our previous blog. This different shell, which we call LittleFace, contains much less functionality and is relatively simple compared to its TwoFace payload counterpart. LittleFace also differs from the previous TwoFace payloads as once it is saved to the system, it no longer requires authentication.

The LittleFace shell does not display a web-based user interface like most webshells. Instead, it is a webshell that allows the threat actor to pass commands to Windows command prompt by issuing HTTP POST requests with the desired command within the “c” field of the posted data, as seen in the following code block that is the command handler on the webshell. The webshell will receive the commands embedded in the HTTP POST requests and hand them off to another function (“r” function in the following code block) for processing.

The LittleFace shell will execute the command (‘r’ function seen in code block above) by creating a “cmd.exe” process and writing the desired command to the process’ standard input. The result of the command is provided back to the actor directly within the HTTP response to the POST request.

OilRig Link

While examining each of the tools that were found on the compromised sites, one specific sample of Mimikatz showed evidence of a potential relationship with the OilRig campaign.

As detailed in our April 2017 blog "OilRig Actors Provide a Glimpse into Development and Testing Efforts", we were able to track an entity that appeared to be testing and iterating through different variations and versions of tools associated with the OilRig campaign. This same entity was found submitting a specific sample of Mimikatz a day after testing multiple Helminth samples. We observed actors uploading this specific sample of Mimikatz to the TwoFace webshell hosted at the Saudi education institution mentioned earlier in this blog, leading us to believe that there is a likely relationship between the OilRig campaign and the TwoFace campaign. The extent of this relationship is unknown at this time. While we cannot be absolutely certain that this is the same adversary in both attacks, we are able to ascertain that this specific entity does have access to OilRig tools and also has access to a very specific sample of Mimikatz only found in this attack infrastructure.

Expanding on the possible relationship between TwoFace and OilRig, examining the tactical overlap of both attacks may also provide additional data points to link them. Specifically, significant targeting overlap exists with both attacks, with multiple organizations in multiple nation states throughout the Middle East region being targeted either as a final target or added as part of the attack infrastructure. One possible scenario of how TwoFace and OilRig are used in conjunction could be where the adversary uses the ClaySlide documents to deliver Helminth, which is then used as an initial landing point or beachhead into the target’s network. From there, the adversary may use the initial ingress point and its corresponding permissions to install the TwoFace webshell on accessible systems. Additional post-exploitation tools such as the ones we discovered may then have been uploaded to the now compromised systems via the TwoFace file upload function.

Conclusion

As we have continued our research into operations in the Middle East, we are beginning to uncover more and more overlaps between the various adversary groups and campaigns outlined by us and others in the public domain. In this incident, we were able to follow a trail starting from a single webshell to a bevy of compromised sites, credential harvesters, post-exploitation tools, and even an operational overlap with what we originally thought was an unrelated attack campaign. The Middle East region has proven to be a hotbed of threat activity in recent times, with continued acceleration of pacing as well as development in the tactics and techniques used. There is no indication that this type of threat activity will cease, but with continued discovery of the adversary’s playbooks, implementation of strong security policies, and effective deployment of technology, we can make it far less worthwhile for the adversary to execute their attacks.

Post-exploitation Tools SHA256 Hashes

28a0db561ff5a525bc2696cf98d96f443f528afe63c5097c5e0ccad071fcb8c2
744e0ce108598aaa8994f211e00769ac8a3f05324d3f07f7705277b9af7a7497
caf5f9791ab3049811e16971b4673ec6d4baf35ffaadd7486ea4c5e318d10696
6ae32cd3b5a8a1dbb5464372ded370f31802fd1f5031795b43d662c64fc5b301
3b08535b4add194f5661e1131c8e81af373ca322cf669674cf1272095e5cab95
450ebd66ba67bb46bf18d122823ff07ef4a7b11afe63b6f269aec9236a1790cd
5b7eb534a852c187eee7eb729056082eec7a028819191fc2bc3ba4d1127fbd12
6e623311768f1c419b3f755248a3b3d4bf80d26606a74ed4cfd25547a67734c7
497e6965120a7ca6644da9b8291c65901e78d302139d221fcf0a3ec6c5cf9de3
d3b03c0da854102802c21c0fa8736910ea039bbe93a140c09689fc802435ea31
5ead94f12c307438e6475e49f02bedaee0cd09ce6cebb7939f9a2830f913212c
bb9b4e088eb99100156f56bbd35a21ff7e96981ffe78ca9132781e9b3f064f44

Credential Harvesting Domains

owa-insss-org-ill-owa-authen[.]ml
webmaiil-tau-ac-il[.]ml
mail-macroadvisorypartners[.]ml
webmail-tidhar-co-il[.]ml
my-mailcoil[.]ml
logn-micrsftonine-con[.]ml
so-cc-hujii-ac-il[.]ml

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow