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

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/

[Palo Alto Networks Research Center]

Endpoint Protection for SCADA and ICS Environments? Traps Has Your Back

Information technology (IT) administrators have been quick to adopt new security solutions, but operational technology (OT) administrators are forced to proceed cautiously, in order to prevent compromising process performance or unwanted downtime. These concerns can result in deliberately leaving software unpatched, antivirus (AV) signatures outdated, technologies disjointed, or security solutions left out entirely.

Even organizations that can successfully deploy fully updated antivirus solutions on fully patched systems still find themselves struggling to prevent advanced attacks. The lack of protection against new attacks, impacted system performance, and high rates of false positives leave these organizations vulnerable, often to sophisticated, never-before-seen attacks.

Organizations can no longer rely on fragmented legacy solutions or point solutions to defend critical infrastructure. The result is a dire need for improved security in ICS/SCADA environments – security that can prevent advanced attacks effectively without impacting system performance and can communicate across the environment.

Palo Alto Networks Traps advanced endpoint protection combines multiple layers of prevention to protect endpoints before they are compromised.

  • Traps integration with WildFire cloud-based threat analysis service allows for automated prevention against known malware; local analysis via machine learning enables the automatic prevention of unknown malware and prevents a wide variety of exploit techniques, whether a machine is offline or online, on-premise or off; and cloud-based threat analytics permits rapid detection and automated prevention of unknown threats.
  • With trusted publisher execution restrictions, executables that are signed by trusted publishers are quickly identified as “unknown good.”
  • Flexibility to customize systems exposure with policies that restrict specific execution scenarios can control what is or is not allowed to run based on the executable files hash, eliminating unnecessary analysis and minimizing the security footprint.
  • Malicious process control prevents the launch of applications that can be used for malicious purposes.

As part of the Palo Alto Networks Next-Generation Security Platform, Traps enables bi-directional information-sharing to deliver consistent protections across the organization’s endpoints, data centers, firewalls, public and private clouds and SaaS environments.

Learn More about Traps advanced endpoint protection:

[Palo Alto Networks Research Center]

Pulling the Brake on the Magnitude EK Train

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.

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.

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.

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

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.

[Palo Alto Networks Research Center]

Ewind – Adware in Applications’ Clothing

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:

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-720×1184-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:

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.

and

[Palo Alto Networks Research Center]

Gearing Up for the Collegiate Cyber Defense Competition

It’s that time of the year when we get to root for our alma mater or favorite college competing in the Collegiate Cyber Defense Competition (CCDC). This year, Palo Alto Networks is supporting all 10 regional competitions, and the national competition, through the donation of our next-generation firewall, which CCDC teams will use to defend their networks. The Academy Team has set up a Moodle training course for competing teams to learn how to deploy and configure our next-generation firewall to defend their competition networks. Currently, there are more than 800 participants from CCDC teams on our Moodle training site. We also have teamed with the Network Development Group to provide CCDC competing teams with access to our NETLAB+ VM-100 lab pod. Teams are accessing these resources now to prepare for this competition.

Just like the “Sweet 16,” the winning team at each of the regional competitions goes on to compete in the National CCDC, where the winning team is crowned the national champion. This year, the national competition will take place from April 13 to 15, 2017 in the Henry B. Gonzalez Convention Center in San Antonio, Texas.

The national CCDC website includes the mission of the program and a brief description of the competition framework: “CCDC competitions ask student teams to assume administrative and protective duties for an existing “commercial” network – typically a small company with 50+ users, 7 to 10 servers, and such common internet services as a web server, email server and e-commerce site.

Each team begins the competition with an identical set of hardware and software and is scored on its ability to detect and respond to outside threats; maintain the availability of existing services, such as mail servers and web servers; respond to business requests, such as the addition or removal of additional services; and balance security needs against business needs. Throughout the competition an automated scoring engine is used to verify the functionality and availability of each team’s services on a periodic basis, and traffic generators continuously feed simulated user traffic into the competition network.  A volunteer red team provides the “external threat” all internet-based services face and allows the team members to match their defensive skills against live opponents.

When students enter their competition area, they are told they are replacing an IT staff that was fired for negligence and incompetence. As a result, the clients and servers on their networks may be infected with malware and/or configured insecurely, allowing easy access to external attackers. The CCDC competitions last for 20 hours spread over two to three days. The winner of the competition is the team that can keep its services up the longest and scores the highest points for correctly answering the business “injects.”

The competition is organized into color-coded teams. The Blue Team is the student team consisting of five to eight students, two of which can be graduate students; there are multiple such teams in each competition. The Red Team provides the external threat for the Blue Team. Red Team members are usually professional penetration testers. Last year Raphael Mudge, the developer of Armitage for Metasploit, was a Red Team member at the Northeast CCDC. The White Team provides the referees for the competition and generates the business tasks for the Blue Team. At the end of the competition, the White Team determines the winner based on up-time and business inject points. The Orange Team provides customers with whom the Blue Team interacts. The Black Team is responsible for setting up the competition environment for the Blue Team.

Representatives from our Academy and Delivery teams will be at all 10 regional CCDCs in addition to the National CCDC. They will provide technical advice to the competition teams, information about our college internship opportunities, and information about our great academy program. Additionally, Rinki Sethi, our Senior Director of Information Security, will be a member of the White Team at the Midwest CCDC.

Here is the CCDC competition schedule:

  1. Rocky Mountain CCDC, March 10–11, Regis University, Denver, Colo.
    • Regis University
    • Colorado State University
    • Brigham Young University
    • Utah Valley University
    • Southern Utah University
    • LDS Business College
    • Front Range Community College
    • USAF Academy
    • University of New Mexico
    • University of Nebraska/ Kearney
  1. Northeast CCDC, March 17–19, RIT Rochester, N.Y.
    • Champlain College
    • Harvard University
    • Northeastern University
    • Rochester Institute of Technology
    • Syracuse University
    • University at Buffalo
    • University of Maine
    • University of New Hampshire
    • Utica College
    • Westchester Community College
  1. Midwest CCDC, March 17–18, Moraine Valley Community College, Palos Hills, Ill.
    • Participating teams to be announced.
  1. Southwest CCDC, March 17–19, University of Tulsa, Tulsa, Okla.
    • Participating teams to be announced.
  1. Pacific Rim CCDC, March 24–26, Highline College, Des Moines, Wash.
    • Central Washington University
    • Clover Park Technical College
    • Columbia Basin College
    • Green River College
    • Lewis & Clark College
    • Peninsula College
    • Spokane Falls Community College
    • The Evergreen State College
    • University of Idaho
    • University of Washington, Bothell
    • University of Washington, Seattle
    • University of Washington, Tacoma
    • Western Washington University
    • Whatcom Community College
  1. Western Regional CCDC, March 24–26, Cal Poly Pomona, Pomona, Calif.
    • Arizona State University
    • UC Berkley
    • Cal Poly Pomona
    • CSU Northridge
    • CSU San Bernardino
    • Stanford University
    • UC Riverside
    • University of Advancing Technology
  1. At Large CCDC, March 24–26, Online
    • Participating teams to be announced.
  1. Mid Atlantic CCDC, March 30–April 1, John Hopkins University, Laurel, Md.
    • Participating teams to be announced
  1. North Central CCDC, March 30–31 Dakota State University, Madison, S.D.
    • Participating teams to be announced.
  1. Southeast CCDC, April 5–6 Kennesaw State University, Kennesaw, Ga.
    • Participating teams to be announced.
  1. National CCDC, April 13–15, Henry B. Gonzalez Convention Center, San Antonio, Texas
    • The winners from the 10 regional CCDCs.

[Palo Alto Networks Research Center]

English
Exit mobile version