Mirai-like Botnet One Year Review and a New Website!

In February 2017, I started my passive honeypot and began listening for all incoming network traffic. As the months passed, I saw numerous exploit attempts, constant port scans, and other suspicious traffic. It wasn’t until October that, with the help of Dr. Neal Krawetz, I started cataloging Mirai-like botnet traffic specifically.

What does Mirai-like mean?

Incoming scans from Mirai-like botnets have a very distinct fingerprint in the network traffic generated by infected hosts. The TCP sequence number will always equal the IP address of the target device. This intentional behavior is documented in the original Mirai source code, shown in the snippet below:

Snippet of Mirai source code

Typically, the target IP address is encoded in decimal (numeric) format. As the target IP changes, the Sequence Number of the traffic coming from the infected host will change accordingly as shown in the example below:

Example showing TCP Sequence Number = Destination IP address

Your logs may vary and instead record the sequence number in hexadecimal format. Either way, once converted to an IP address, the pattern is clearly established.

Dr. Krawetz shared his thoughts on this technique, “This is actually kind of brilliant. Each bot slings out packets and doesn’t store any information. When a response comes back, the botnet can identify the sender by the sequence number. ”

Once the fingerprint of the Mirai-like botnet was established, I was able to review the IP addresses found my logs for further patterns. Late in October 2017, I shared my findings of a botnet consisting of EnGenius routers.

Instead of continuing to isolate specific devices in the botnet and the volume of traffic generated, I began cataloging new unique IP addresses while noting the network provider (ASN) and country they came from. This allowed me to gauge the growth rate and estimate the size of active botnets. Subsequently, I started sharing my Mirai-like botnet statistics daily on Twitter.

One Year of Data Collected

New unique IP addresses seen Mirai-like botnet from 2017-02-19 to 2018-02-19

Reviewing the entire dataset I collected, the overall Mirai-like botnet volume averaged around 500 new unique IP addresses per day in March 2017 and steadily declined until September 2017. After this point, a surge in botnet activity was observed. The most new unique IP addresses I saw in a single day was 1,384 on November 29.

The explosion in activity was largely attributed to the Satori botnet which enslaved devices in Argentina, Egypt, Colombia, and Tunisia. This botnet grew exponentially after a zero day exploit was used to target Huawei HG532 routers. Numerous devices from Japan were also found after a UPnP exploit targeting Realtek devices was used.

During the height of the activity between November 22nd and December 7th, those countries accounted for a large share of the new unique IP addresses found.

New Unique IPs seen in Mirai-like botnet from 2017-11-22 to 2017-12-07 by Country

Similarly, network providers (ASNs) from Colombia, Egypt, and Argentina combined for 39% of all new unique IP addresses seen during this time period.

New Unique IPs seen in Mirai-like botnet from 2017-11-22 to 2017-12-07 by ASN

Growing Pains

The challenge of collecting and sharing the Mirai-like botnet data every day quickly became apparent. A publicly shared Google Sheet was not a long term option, so I asked my Twitter followers for assistance building a proper solution.

Alex Rhodes rose to the challenge and offered his time and expertise to build a database backend to store the data. He also designed and implemented a website for sharing the botnet data. Alex is software engineer in the aerospace industry and is currently working towards a Master’s degree in Cybersecurity at Syracuse University.

The new website is easy to configure and manage and I’m truly grateful for the finished product Alex has delivered.

Mirai.BadPackets.net

New website: mirai.badpackets.net

The new website offers filtering options for every field, including IP Address, Country, ASN, and date range. It also expands on the features formerly offered in the spreadsheet, including the following lookups:

IP address (DomainTools)
ASN (Hurricane Electric BGP Toolkit)
Shodan
Censys
ZoomEye

In addition to the main page, which is updated daily, we can also filter by the top ASN and country for a specified time period. Using this, we can review the all-time leaders for the entire year of Mirai-like botnet data collected.

China dominated the count of unique IPs seen with 27,672. India and Brazil both had over 10,000 unique IPs each. Japan and Argentina were close behind with over 9,000 unique IPs each. Russia and the United States were also among the top 10 countries with 7,801 and 5,045 unique IPs, respectively.

Top 10 Country

Continuing the trend, network providers China Telecom and China Unicom led in total overall volume, combining for a total of 23,243 unique IPs seen. Coming in third place was Telefonica de Argentina with 7,576 unique IPs. Rounding out the top five network providers in unique IPs seen was Rostelecom (Russia) with 5,407 and Tigo Colombia with 3,301.

Top 10 ASN

During the one year of data collection, I saw botnet traffic from 179 of the 195 recognized countries in the world. IP addresses registered to 5,581 unique network providers (ASNs) were also observed. It was clear that Mirai-like botnet activity was truly worldwide phenomenon.

Closing Remarks

The unique IPs seen by my honeypot is only a tiny fraction of those participating in active botnets. In the case with Satori botnet, other security researchers estimate the total size peaked around 650,000 infected devices.

The data provided via the new website will remain free and open to the public. I will continue to update it daily with my latest available data.

Follow me on Twitter to receive my daily Mirai-like botnet statistics update of new unique IPs seen, top ten countries and top five ASNs seen in the Mirai-like botnet.

How to find cryptojacking malware

Cryptojacking malware continues to spread across the web, largely due to the popularity of Coinhive. Since Coinhive’s launch in September 2017, numerous cryptojacking clones have come about.

The tool I’ve chosen to locate them with is PublicWWW. This is a search engine that indexes the entire source code of websites. I previously offered a comparison of their dataset versus other providers in my discussion of Coinhive malware specifically.

In this post, I detail how to find websites containing Coinhive, Crypto-Loot, CoinImp, and deepMiner in PublicWWW.

Let’s jump in and see how many sites with cryptojacking malware we can find!

Coinhive

Before we review some of the knock-offs, let’s look at the most synonymous name with cryptojacking, Coinhive. Finding this malware is relatively easy and various queries can be used to locate it. The original Coinhive JavaScript library used in cryptojacking is “coinhive.min.js” and we can start by simply searching for that. It’s important to search for the entire name in quotes to ensure an exact match is returned by PublicWWW.

PublicWWW search for "coinhive.min.js"

Using this query, we find 34,474 sites. While this may seem like an astounding number,  it’s only a modest increase since I wrote about the 30,000 sites found back in November 2017.

While this list of sites is great for an overview of sites with Coinhive malware, we can dig even deeper into PublicWWW’s dataset to extract the Coinhive site key used on each site. This can be done using regex to extract the site key as a snippet: “coinhive.min.js” snipexp:|CoinHive.Anonymous\(‘?(\w{32})’|i

PublicWWW search for "coinhive.min.js" snipexp:|CoinHive.Anonymous\('?(\w{32})'|i

Once the Coinhive site key is extracted, we can export the results and correlate which sites are part of a cryptojacking campaign. This correlation of a small number of Coinhive site keys to hundreds and even thousands of websites was documented in my previous post.

Recently I found a large cryptojacking campaign targeting 5,451 WordPress sites. In each case, the JavaScript containing Coinhive was hidden via obfuscation.

Example site found in WordPress cryptojacking campaign
The obfuscated JavaScript code is illegible and must be deobfuscated first to be human-readable.

While PublicWWW can’t search within the deobfuscated JavaScript itself, we can find a way to work around it.

PublicWWW search for sites found in large WordPress cryptojacking campaign.

To search for the affected sites, the following query, graciously crafted for me by VriesHd,  was used:

“[\”(k” “\\x43\\x72\\x79\\x70\\x74\\x6f\\x6e\\x69\\x67\\x68\\x74\\x57\\x41\\x53\\x4d\\x57\\x72\\x61\\x70\\x70\\x65\\x72” snipexp:|(var _0x[0-z]{4}=)|

This query searches for the JavaScript function name used for the obfuscated code and then regex to extract a snippet of that name. This is useful to correlate the function name, such as “var _0xb70e” to the Coinhive site key used. Six unique keys were found to be used in this cryptojacking campaign:

Coinhive site key (function name)
DhGEVUgOoquJP68XByYLFs0nRVV4gq4J (0xb70e)
bbgnHTSmMLKUMaQzNa3Yfoul34A3cACd (0xbcba,0xe2f6)
hg9mNsA2DPkqe1F9yCUyWXggnDyrPqVW (0x1b00)
T6Oy0x11TMdeZRjy684Xow4GNBpb07SK (0xf80b)
OQoqVYH65ER2Eg2xcmoVtv4qrcHP2Z7G (0xe4d0,0xb765,0xcc28)
VW8fWIsg9hjn47qBdmb0jImf7pDHmU28 (0x8f35)

In some cases the same Coinhive site key was associated to multiple functions, shown above.

Crypto-Loot

Crypto-Loot has steadily remained as one the most popular alternatives to Coinhive since its inception. Similar to Coinhive, Crypto-Loot doesn’t require any user interaction and can run steathlity in the background.

This is a prominent feature on Crypto-Loot’s marketing page, in addition to DDoS protection which is provided by Cloudflare.

Crypto-Loot is advertised to run secretly in the background while protected from DDoS attacks by Cloudflare.

Crypto-Loot uses two domain names for their cryptojacking operations:
crypto-loot.com
cryptoloot.pro

These domains can be queried in PublicWWW to locate the affected sites, and similar to the Coinhive, we can use regex to extract the site key used in each using this query: “CryptoLoot.Anonymous” snipexp:|CryptoLoot.Anonymous\(‘?(\w{44})’|i

PublicWWW search for  "CryptoLoot.Anonymous" snipexp:|CryptoLoot.Anonymous\('?(\w{44})'|i

Searching for strictly the two domains used, we find a total of 2,057 sites with Crypto-Loot present.

CoinImp

CoinImp is a relatively new player in the cryptojacking game, however a large increase in the number of sites where it has been seen has been found recently.

CoinImp uses four domain names for their cryptojacking operations:
coinimp.com
www.hashing.win
www.freecontent.bid
webassembly.stream

Interestingly, the reference to “www.hashing.win” previously found in CoinImp’s documentation was quietly removed sometime after 2017-12-20 and replaced with “www.freecontent.bid” as the illustrative example.

Screenshot captured of CoinImp's documentation page on 2017-12-20.
Screenshot captured of CoinImp’s documentation page on 2017-12-20.

Coincidentally, the most used CoinImp domain name, www.hashing.win, has been found by PublicWWW on a whopping 3,745 sites.

PublicWWW search for www.hashing.win

Since this was surprising number, I manually reviewed numerous sites and found that CoinImp had already been removed or another form of cryptojacking malware, such as Coinhive, had been placed. This leads me to believe the cryptojacking campaign perpetrator was using a short-lived method to place the CoinImp code.

Totaling the four CoinImp domain names used, we find a total of 4,119 sites.

Minr

Early in December 2017, I discovered a new form of cryptojacking malware called Minr. What differentiated this from the others is that it provided built-in obfuscation for its users. This wasn’t required however and many sites I found didn’t bother to use it.

Example site containing Minr malware
Example of a site containing Minr malware.

In addition, the domain names used by Minr were innocuous looking. The domain names also frequently changed, so anytime I shared an update it quickly became out of date.

Minr malware domains used on 2018-01-29

The domains used by Minr a week ago (shown above) have again have changed.

As of this writing, the active domains used by Minr in cryptojacking operations are:
cnt.statistic.date
cdn.static-cnt.bid
ad.g-content.bid
cdn.jquery-uim.download

Totaling the four Minr domain names currently used today, we find a total of 692 sites.

deepMiner

Unlike the other cryptojacking providers, deepMiner is self-hosted JavaScript. This means the code used to mine cryptocurrency is not hosted by a third-party service provider and instead placed directly on the website or domain controlled by the cryptojacking campaign operator. The repository of deepMiner’s source code can be found on GitHub.

While this might appear to be a roadblock in our search for sites containing, deepMiner, there is still a way to locate it. The secret in locating deepMiner lies in locating the function required for it to run, shown in the snippet below:

deepMiner code snippet

Now that we have this information, we can simply search PublicWWW for “deepMiner.Anonymous” to locate the affected websites.

PublicWWW search for "deepMiner.Anonymous"

This leads us to find 2,160 sites using deepMiner for cryptojacking purposes.

One site I found using deepMiner was a fake Chrome update website that advised users not to close the page. Meanwhile cryptojacking was happening in the background consuming 100% CPU of my test machine.

Fake Chrome update website running deepMiner malware
No, Chrome really isn’t updating.

Statistics Comparison

Coinhive remains the market leader for cryptojacking malware. However, many clones it inspired are showing exponential growth rates.

Websites found running Crypto-Loot, CoinImp, deepMiner, and Minr malware.

The four Coinhive clones discussed were found on a total of 9,028 websites. CoinImp had the largest market share at roughly 45% while Minr had the smallest at nearly 8%. Crypto-Loot and deepMiner shared the remaining portions at nearly 23% a piece.

Websites found running Coinhive and other cryptojacking malware.

However when compared to Coinhive by itself, the other cryptojacking malware providers only account for a modest 18% market share. I would expect Coinhive to remain in the top spot for the foreseeable future.

Closing Remarks

Coinhive is clearly the market leader when it comes to cryptojacking malware as it’s been found on nearly 40,000 websites.

For Chrome users, I recommend using a dedicated extension, minerBlock, to block cryptojacking malware. A Firefox version of this extension is available as well.

The cryptojacking malware discussed in this post is only a portion of what’s currently found in the wild. New variants are discovered frequently, which I share frequently on Twitter. You can also browse the CoinBlockerLists, which is constantly updated by ZeroDot1, where you can find hundreds of domains tied to cryptojacking malware.

The statistics shared in this post were generated from data provided by PublicWWW on 2018-02-07. They are subject to change as PublicWWW regularly updates their index.

Cryptojacking: 2017 Year-End Review

In 2017, we witnessed the rise of cryptojacking malware. A common target was compromised websites and their unsuspecting visitors.

How Cryptojacking Works
How cryptojacking works illustration by the European Union Agency for Network and Information Security (ENISA).

Cryptojacking begins after Coinhive or other malicious JavaScript cryptocurrency mining scripts are embedded in a compromised website. Unsuspecting visitors then begin mining the cryptocurrency Monero (XMR) in their browser.

This process is very intensive and can use all the CPU resources of the victim’s device. This leads to higher energy usage, rapid battery drain in mobile devices, and can cause damage from overheating.

Many well-known websites were compromised in 2017 with cryptojacking malware.

Showtime Networks

Coinhive found on Showtime's website
For an entire weekend in September, subscribers of Showtime’s video streaming website, Showtime Anytime, were subjected to cryptojacking.

Back in September, I was the first to document the cryptojacking incident of CBS’ Showtime Networks’ websites. Coinhive malware was found to be present on video streaming site ShowtimeAnytime.com for three straight days.

Showtime has refused to comment as to why the code appeared on their websites. While the Coinhive code was found in a New Relic code block, the company’s spokesman denied any responsibility in the matter.

Politifact 

Politifact's website hacked to run Coinhive malware
Hackers embedded Coinhive on Politifact’s website after compromising one of their AWS servers.

On October 13, Coinhive was found on the political fact-checking website Politifact. A compromised JavaScript library was found to be injecting the cryptojacking malware. The malicious code remained on the site for at least four hours before it was removed.

In a statement provided to The Wall Street Journal, PolitiFact Executive Director Aaron Sharockman stated, “Hackers were able to install their script on the fact-checking website after discovering a misconfigured cloud-computing server.”

UFC Fight Pass

UFC Fight Pass hosting Coinhive malware
The cryptojacking of UFC’s Fight Pass website went viral on Reddit as multiple users confirmed the presence of Coinhive.

Early in November, numerous users reported the subscription video streaming service of the UFC, dubbed Fight Pass, was running cryptojacking malware. A UFC.tv customer saved a copy of the source code (above) where Coinhive was found. However, in a statement released to me (below), the UFC denied the code was ever present on their website.

UFC statement regarding cryptojacking allegations

Crucial Memory and Everlast Worldwide

Coinhive found on the website of Crucial Memory

Coinhive on Everlast's website
The cryptojacking of Crucial Memory and Everlast’s website was due a compromised live help chat widget.

On Thanksgiving Day, I found a large cryptojacking campaign of 1,400+ websites. The two most nobables sites were of Crucial Memory and Everlast Worldwide. Normally you would never associate these two brands together,  however both their websites shared a similar embedded code — a live chat widget provided by LiveHelpNow. LiveHelpNow stated one of their CDN servers was compromised and injected with the cryptojacking malware Coinhive.

Globovisión and Movistar

Google Tag Manager was used to inject Coinhive on Globovision's website

Google Tag Manager was used to inject Coinhive on Movistar's website
Google Tag Manager was used to inject Coinhive on Movistar’s and Globovisión website.

In two separate incidents, I found Coinhive was injected into the websites of Globovisión and Movistar using Google Tag Manager. Movistar stated that Coinhive was not put on their website by a hacker, but instead was due to “an internal error” while they were conducting “pre-production tests.” No statement was provided by Globovisión on why the cryptojacking malware appeared on their site on November 15.

Chrome extension “Archive Poster”

Archive Poster Chrome extension infected with cryptojacking malware
Multiple users reported the cryptojacking behavior of the “Archive Poster” extension.

Cryptojacking was not limited to websites in 2017 as we saw Chrome extensions also being affected. One such extension, Archive Poster, remained on the Chrome Web Store for days while silently cryptojacking an unknown portion of their 100,000+ users.

Despite multiple user reports, Google’s response lacked any initiative to remove the malware infected extension. After I reported the issue to them, it was finally pulled.

Other sources of cryptojacking found

Coinhive is not the only the JavaScript cryptocurrency miner available for use. Many clones have popped up in its wake. Using PublicWWW, I was able to find how many websites were using a copycat.

JavaScript cryptocurrency miners
Non-Coinhive JavaScript cryptocurrency miners found on 2017-12-24.

One of the up-and-coming Coinhive knockoffs, Minr, offers built-in obfuscation and uses multiple domain names to evade detection.

Domains used by Minr malware change frequently.

Other notable cryptojacking malware discoveries in 2017

— Being found on nearly 2,500 ecommerce websites
— Masquerading as a jQuery file on 4,000 websites
— Concealed with hidden browser window mining
— Even a Starbucks WiFi provider was found running Coinhive

Heading into 2018, the question remains how to stop the spread of cryptojacking malware. Luckily we have seen anti-mining browser extensions, such as No Coin and MinerBlock, developed to help curb the threat. Another popular ad blocker, uBlock Origin, blocks most cryptojacking scripts now as well. Many anti-malware applications, such as Malwarebytes, have started blocking the effects of cryptojacking.

Cryptojacking malware Coinhive found on 30,000+ websites

Since first going mainstream with The Pirate Bay and Showtime, cryptojacking has quickly become a favorite revenue stream for cybercriminals. Cryptojacking typically begins after Coinhive (JavaScript code) is embedded on a compromised website. Unsuspecting visitors then begin mining the cryptocurrency Monero (XMR) in their browser.

How Cryptojacking Works
How cryptojacking works illustration by the European Union Agency for Network and Information Security (ENISA).

The longer the Coinhive script stays on a compromised site, in addition to the amount/duration of visitors, directly correlates to the profitably of the cryptojacking session. However, the operating cost is still nearly zero for the threat actor (hacker) planting the script. The processing burden of Coinhive is solely laid upon the client (end user). This leads to rapid battery drain and higher energy costs for the afflicted devices.

So how many websites have Coinhive embedded in them? This answer varies depending on the search engine used. To test, I searched for the name of the Coinhive JavaScript library, “coinhive.min.js” via four search engines: Censys, PublicWWW, Shodan, and ZoomEye. The following amount of Coinhive sites were found on 2017-11-04

Censys: 1,640
PublicWWW: 30,611
Shodan: 941
ZoomEye: 474

Since PublicWWW presented the most results, I chose their dataset to analyze. I began cataloging the domain names found by extracting the Coinhive Site Key from each site. Once this was completed, I was able to correlate a single site key to multiple Coinhive infested sites.

NOTE: I also used my own tools to independently verify the PublicWWW results. I felt confident in the data they provided after I had scanned the top  11,000 Coinhive infected sites myself and correlated the results.

The amount of websites tied to one Coinhive Site Key was somewhat astounding. This correlation was also recently noted by security researcher, Willem de Groot. He found 2,496 infected online stores, of which 85% were linked to only two Coinhive accounts.

The most used Coinhive Site Key I found was:
M1p4TkON5Kvu3hk5ePbaBnl7WwsF8bhK

This one key was used on 4,722 sites. Almost all of the sites used the top-level domain “.ir” (ccTLD for Iran). Most of the domain names were four characters long consisting of only random numbers or three characters long consisting of only random words.

Example “numbers only” domains:
1906.ir
3394.ir
8424.ir

Example “letters only” domains:
uag.ir
fuv.ir
bdy.ir

Example “other” domains:
baidu.ir
billionaire.ir
daytona.ir

All domains were registered to a “Mohammad Khezri” of Iran. A reverse WHOIS search on DomainTools.com shows 6,040 domains are registered to him. These domains appeared to be parked using service called DNS4.IR that uses Coinhive to monetize the traffic.

Other individual Coinhive Site Keys were associated to a large amount of domain names. Site keys that were found on 100+ domains are shown below. I sampled the content of a handful of sites found for each key. I also looked for trends in the Nameservers (NS) used for each domain. This allowed me to get a general idea of the “theme” of each Coinhive Site Key used.

Coinhive Site Keys found on 100+ domains organized by total domains associated.

Overall, the bulk of the sites were either compromised websites or parked domains. The third-most used key no longer appeared to be actively engaged in cryptojacking and simply redirected to Bing.com.

The range of compromised sites varied greatly due to the sheer volume. Some notable and humorous sites that I encountered included:

Papa John’s Pizza – Puebla, Mexico

Papa John's Pizza - Puebla, Mexico

National  Association of Doctors

National  Association of Doctors

In addition to Coinhive, a fake online pharmacy was found on their website.

National  Association of Doctors fake online pharmacy

Deposit Insurance of VietNam – Vietnamese equivalent of the FDIC

Vietnamese equivalent of the FDIC, Deposit Insurance of VietNam

Ortel Communications (AS23772) – Large ISP in India

Ortel Communications

MacbookWarmer.com – “Stay Warm Whenever and Wherever”

MacbookWarmer.com

While this one is clearly a well-thought-out spoof, cryptojacking is no laughing matter.

MacbookWarmer.com - About

A PublicWWW search shows 4,260 WordPress sites are running Coinhive. A “weather widget” plugin was recently banned from the WordPress plugin repository, however other cryptojacking plugins are still available for site operators to utilize.

Various techniques have been used to spread the Coinhive infestation further, from Android apps to an open Amazon S3 bucket of Politifact.com.

Coinhive is not the only JavaScript miner available for cryptojacking use. Many competitors have popped up in its wake. Using PublicWWW, I found JSECoin was in a distant second place behind Coinhive on 905 websites.

Non-Coinhive Miners Pie Chart

Non-Coinhive JavaScript cryptocurrency miners found on PublicWWW:
JSEcoin: 905
Crypto-Loot: 123
AFMiner: 77
ProjectPoi (PPoi): 50
Coinhave: 43
Coinerra: 11
MineMyTraffic: 3
Papoto: 1

It’s clear the cryptojacking frenzy will continue into the near future. To protect yourself from cryptocurrency mining scripts while browsing, I recommend using any of the following Chrome extensions:

minerblock
uBlock Origin
ScriptSafe

Many anti-malware applications also block cryptojacking scripts, such as Malwarebytes and Avast.

A request has been made to Google Developers to add functionality in Chrome itself to block malicious JavaScript usage. Anyone can comment to share their feedback with Google here.

In the meantime, I will continue to monitor reports of cryptojacking while reviewing new Coinhive sites found daily.

For the latest updates on this topic, follow me on Twitter @bad_packets.

EnGenius routers found in Mirai-like botnet

EnGenius routers were recently found in a Mirai-like botnet with a distinct network traffic fingerprint. Locating this botnet subset was a joint effort between myself and Dr. Neal Krawetz.

EnGenius logo

This Mirai-like botnet traffic was fingerprinted after a distinct pattern in the packets received was identified by Dr. Krawetz. While the source port was usually randomized, the TCP sequence number was always the same. However, it wasn’t just any static number, it was the destination IP address of the bot’s target.

This behavior was previously noted in a LinkedIn post about IDS rules used to block Mirai scans. This is expected, per the snippet of source code of Miari shown below.

Snippet of Mirai source code

I found 85,100 unique IP addresses used by devices in Mirai-like botnet since 2/18/2017. AS4134 (China Telecom) had most unique IPs with 10,972 seen.

IP addresses seen in Mirai-like botnet by ASN since 2017-02-18

This destination IP address was found to be encoded in of each incoming packet’s sequence number. The example log snippet below illustrates how this is extracted.

PROTO=TCP
SRC=194.132.237.47
DST=72.193.175.65
SPT=49795
DPT=23
SEQ=0x48c1af41

In this case the TCP sequence number, written as hex, is 0x48c1af41. When we convert this value from hex to an IP address, we get 72.193.175.65 – which is the destination (target) IP address.

Your logs may vary and instead record the sequence number in decimal format. In the example above, the decimal version of the SEQ = 1220652865 which converts to 72.193.175.65 just the same.

The fingerprint is best illustrated when the target IP address changes as shown below:

TCP Sequence Number = Destination IP

Once the fingerprint of botnet was established, I was able to review the IP addresses found in my logs for further patterns. After reviewing a handful of devices coming from IP addresses in the United States , I noticed a trend in the type of devices. Each was an Engenius ESR300 or ESR600 router.

EnGenius ESR300 router

Both router models are listed on the Engenius website as a “Discontinued Product” and the latest firmware was released on 5/23/2016.

EnGenius Firmware Screenshot

Combining the botnet data from Dr. Krawetz, I independently confirmed 81 of 130 EnGenius routers known to be participating in the botnet.

All incoming traffic from the EnGenius routers was on TCP port 23/2323 (telnet). The highest-volume attackers are shown below and the raw data is available here.

EnGenius Botnet - Top Attackers

The majority of the attacks occurred between 8/25/2017 and 8/29/2017. The type of attack was a SYN flood. This first network traffic from an EnGenius router was observed on 6/15/2017. The raw data of all traffic I observed is available here.

Attacks from EnGenius routers came from all over the world. Most however came from networks in the United States. Both AS11796 (Airstream Communications) and AS13370 (LocalTel Communications) had the most with 12 unique IP address in the EnGenius router botnet.

EnGenius Routers found by ASN with more than one unique IP address
EnGenius Routers found by ASN with more than one unique IP address

The majority of EnGenius routers found had the same ports open to the internet:

TCP 80 (HTTP)
UDP 5060 (SIP)
TCP 8081 (HTTP)
TCP 9000 (HTTP)
TCP 10000 (HTTP)

So how easy is it for the average user to access the administrator interface of these routers? Not surprisingly, very easy. The router’s default credentials are quickly found in the user manual.

EnGenius default credentials

But if what you want to take a more “challenging” approach to locate the default creds? Look no further than the JavaScript file loaded when you visit the router’s login page:

Locating the EnGenius default credentials

This file describes all the functions of the router in addition to providing the default credentials:

“Please enter user name and password.”
“The default account is admin/admin.”

If you looking for an even more challenging method to gain access to an EnGenius router, a remote code execution exploit PoC was published by Zero Science Lab earlier this year in which they stated:

EnGenius EnShare suffers from an unauthenticated command injection vulnerability. An attacker can inject and execute arbitrary code as the root user via the ‘path’ GET/POST parameter parsed by ‘usbinteract.cgi’ script.

I was able to confirm this method was viable for some, but not all of the EnGenius routers found in the botnet. Since it’s very easy to gain root access to EnGenius routers, it presents a clear avenue for any malicious party to add them to their botnet.

I contacted EnGenius with my findings and their customer service team replied that my case “has been escalated to the engineering team.” I haven’t received further communication from EnGenius and will update this post if I hear back.

In the meantime, Dr. Krawetz advises:

For network administrators who want to detect infected hosts from this new botnet: Look for SYN packets where tcp.seq==ip.dst.

If you see a match, then the ip.src denotes an infected address. Either the device at that address is infected, or something behind that NAT router is infected.

Coinhive miner found on official Showtime Network websites in latest case of cryptojacking

Another case of “cryptojacking” was recently found on two official Showtime Network websites:

showtime.com

showtimeanytime.com

This was first reported by Twitter user @SkensNet on September 23 at 9:10 PM GMT. No statement from Showtime Networks or CBS Corporation has been given yet as to why the Coinhive cryptocurrency miner has appeared on their websites.

Showtime Anytime Logo

This could be simply found by viewing the source code of https://www.showtime.com/ and  https://www.showtimeanytime.com/ in any browser:

Coinhive found on Showtime's website

Coinhive is JavaScript library that can be embedded into any website. Once a user visits the website, they unwittingly start mining the cryptocurrency Monero. This can put a tremendous load on the CPU of anyone who visits a website with the Coinhive miner on it.

Catalin Cimpanu of BleepingComputer.com recently published an article describing the nefarious uses of Coinhive and how it’s rapidly becoming a favorite tool among malware developers:

In the few days that have passed after it launched, Coinhive has spread to almost all corners of the malware community.

First, we saw it embedded inside a popular Chrome extension named SafeBrowse, where the Coinhive code was added to run in Chrome’s background and mine Monero at all times the browser was running.

Then, we saw Coinhive embedded in typosquatted domains. Someone registered the twitter.com.com domain name and was loading the Coinhive JS library on the page. Users who mistyped the Twitter URL and ended up on the page would mine Monero for the site’s owner.

This would happen for only a few seconds until the user realized he was on the bad page, but that would be enough for the site’s owner to generate a profit. In time and with more of these domains in hand, the owner of all those mistyped site URLs would make a nice profit.

So how did this even end up on the official Showtime Networks websites?

High CPU usage detected!
60% CPU usage was observed sitting idle at the https://www.showtimeanytime.com/ homepage as the Coinhive miner slowly chugged away.

The answer is not clear yet, however Coinhive did recently appear on The Pirate Bay website and was quickly found by TorrentFreak. Other users of the site also noticed and took their outcry to thepiratebay subreddit . The Coinhive miner was later removed by The Pirate Bay operators, who released the following statement:

As you may have noticed we are testing a Monero javascript miner. This is only a test. We really want to get rid of all the ads. But we also need enough money to keep the site running.

Since the answer is not clear yet when the Coinhive miner was implemented on the Showtime Anytime website, I reviewed a cached copy saved by Google and the latest copy saved by Archive.org.

The copy saved by Google on September 21, 2017 21:31:06 GMT did not appear to have the Coinhive javascript code:

Google's cached copy of ShowtimeAnytime.com

Neither did the Archive.org copy from September 18, 2017 10:06:54 GMT:

Archive.org copy of ShowtimeAnytime.com

MalwareBytes users have noted that Coinhive is now detected and blocked. I verified this by visiting the Showtime Anytime website with active protection enabled.

Malwarebytes detects Coinhive

MalwareBytes blocked the outbound connection  before the cryptocurrency mining could begin.

9/25 Update: Both official Showtime Network websites have the Coinhive miner: showtime.com and showtimeanytime.com.

9/26 Update: The Coinhive script was removed from Showtime Network websites around 4:45 PM GMT on 9/25. No statement yet from Showtime/CBS regarding this incident.

9/29 Update: Showtime/CBS continues to decline providing any statement regarding this incident.

This is a developing story, check back for updates.

Ongoing, large-scale SIP attack campaign coming from Online SAS (AS12876)

A month ago, I wrote a brief, half-humorous post about stopping a SIP attack. However, the unfunny truth is I have collected enough evidence documenting an ongoing, large-scale SIP attack campaign coming from ONLINE SAS (AS12876) more commonly known as “online.net.” They are also known as “Poney Telecom” and “Scaleway” in other references.

online.net

In the last few months, I’ve logged over 8,000 SIP attacks from IP addresses residing in AS12876’s network. The SIP attacks came from 401 unique IP addresses, documented here. An additional 6,000 non-SIP attacks were logged for grand total over 14,000, detailed here.

This led me to send countless abuse reports via Online.net’s Abuse Report Form. Their response was always a message saying here’s a “comment left by our customer” and that the request, was “now closed.”

Some common responses received were similar to this one:

Hello,
this seems that our server has an issue or it has been hacked, I am waiting for my account to be unblocked to check server or reinstall it

Other comments were received from what appeared to be resellers:

Hello Sir,
I am really sorry for this issue, I have forward this abuse email to my client and warning him that if he do not stop this, I will turn off server
So please accept my apologize Sir
Sincerely Yours,

Some  appeared to come from the “Scaleway Team” directly:

No answer from customer, account has been suspended by the Scaleway Team.

Unfortunately due to the sheer volume of the attacks coming from 401 unique IP addresses, I couldn’t continue using their abuse form which only allows reporting a single IP only each time.

Instead I contacted Online.net’s abuse team directly. I provided logs of the numerous attacks from hundreds of devices on their network. I did not hear back from them. Communication was only done on a per-IP basis through their abuse form.

I decided to dig a little deeper into the attacks themselves. To do this, I completed a packet capture on a tiny sample of the incoming SIP attacks.

SIPVicious Attack

The capture showed the attacks being performed by a device running SIPVicious.

SIPVicious
SIPVicious logo created by Sandro Gauci of Enable Security.

So what is SIPVicious? Back in March 2014, Cisco issued a Security Activity Bulletin detailing SIPVicious and how it can be used:

SIPVicious is a Session Initiation Protocol (SIP) auditing tool that has been observed to be used in increasing reconnaissance attacks against IP and VoIP phones and PBX systems.

SIPVicious is used as an auditing tool for scanning phone systems by performing INVITE scans silently. However, attackers could use this feature to perform INVITE scans with a call command to determine weak passwords to connect to a particular phone host on the PBX telephony network. Access to such hosts could allow attackers to make free phone calls through a successful connection.

The tool could also be used to scan the IP or VoIP telephony network. Due to a flaw in the processing of SIP messages by the telephony device firmware, an attacker could use any number or any SIP address in the INVITE message to scan random networks to determine availability of live hosts. The attacker could initiate an INVITE session and determine a successful detection by receiving a phone ring as a response. This detection could allow the attacker to conduct further attacks such as host spoofing to make phone calls using the detected IP phone identity.

Threatpost reported SIPVicious attacks much earlier in 2011, stating that:

Though its name suggests otherwise, the Sipvicious program is a mainstream auditing tool for VoIP systems. The tool is intended to aid administrators in evaluating the security of their SIP-based servers and devices.

Rick Moy, the founder of NSS Labs, said the latest attacks seem designed to create a base from which attackers can make VoIP calls from the victim’s phone or VoIP infrastructure. Those calls might be used to rack up charges on premium rate numbers controlled by the attackers, or as part of voice phishing (vishing) scams that target unwitting consumers.

Moy said the attack shows that even “good tools’ can be used for malicious purposes.

Attacks on VoIP infrastructure are becoming more common and are often traced back to underlying vulnerabilities in VoIP infrastructure. To date, there have been some arrests. In December, authorities in Romania disrupted a criminal group that was accused of hacking VoIP servers and using them to place bogus calls to premium numbers.

SIPVicious can still be obtained from GitHub and the Kali Linux Git Repository. However it has not been updated by the original creator, Sandro Gauci, for almost five years.

I compared the IP addresses that I logged SIP attacks from with the total number of AbuseIPDB reports, shown in the chart below. There were over 6,800 AbuseIPDB  reports for those 401 unique IP addresses, however there wasn’t much correlation with the 8,000 SIP attacks I logged, especially for the highest volume offenders.

Due to this, I highlighted everything above the 95th percentile in red, above the 75th percentile in yellow, and everything below in green for each column.

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Attacks Logged vs. AbuseIPDB Reports

Next I charted unique IPs on the default SIP port only (UDP/TCP 5060) and grouped by ASN. This was because I had way too much data, so I had to exclude non-default port SIP attacks.

Most SIP attacks came from AS12876

It’s clear most of the SIP attacks on the internet originate from AS12876’s network.

Do you see any SIP traffic from AS12876’s ranges in your logs? Are your VoIP servers properly secured?

Is your PRTG server leaking your SNMP community string? Mine was!

I recently had a lengthy discussion with Paessler’s Technical Support Team Manager regarding a leak of my SNMP community string. The conclusion reached was this behavior is actually expected, per the default configuration of PRTG. If you’re not familiar with PRTG, it’s an enterprise network monitoring application created by Paessler AG.

PRTG logo

I became aware of the leak after reviewing my firewall logs and finding the unexpected incoming SNMP traffic from my Remote Probe. I found the traffic occurring every day at the same time, roughly 2:50 PM local time, with three packets sent each time.

Unusual SNMP traffic

I fired up my packet capture machine and re-routed the incoming SNMP traffic to it. Upon inspecting the traffic in Wireshark I found each packet was an SNMP get-next-request which contained my community string for all to see.

Wireshark screenshot

So one might stop at this point and ask, why am I not using SNMPv3 instead of SNMPv2c? This was a calculated choice I made, given that my SNMP traffic is only flowing on a segmented portion of my LAN and never should be traversing the internet.

At this point I contacted Paessler’s Security Team to share my findings. Unfortunately I didn’t make much headway and was soon escalated to Technical Support Team Manager after I sent a follow up to Paessler’s CEO, Dirk Paessler.

After much discussion back and forth it was finally discovered my off-site Remote Probe was sending the SNMP traffic due to it inheriting the default “Advanced Network Analysis — System Information” permissions from my Local Probe (Core Server).

I was a bit dismayed at this fact, since I had diligently turned off the other default settings for “Unusual Detection” and “Similar Sensors Detection” when I configured my PRTG installation.

However the horror didn’t stop there. I found the “System Information” feature was enabled by default for all my devices, due to the permission inheritance. While this may be a useful feature in some cases, I found my SNMP community string had been broadcast daily to every device I monitored. This included external websites, public DNS servers, and other devices outside my LAN.

So how can this be prevented? I recommend always turning off Unusual Detection, Similar Sensors Detection, and now System Information as well when configuring PRTG. These settings are found under Advanced Network Analysis section and can be configured at the “Root” level, as shown below.

PRTG configuration

If any of these features are desired, they can be enabled at the group and/or individual device level.

Per my recommendations, Paessler has updated their documentation regarding the System Information feature, found here. The following note is now included:

Note: The feature System Information is enabled by default. To retrieve the data, PRTG will automatically use Credentials for Windows Systems and Credentials for SNMP Devices as defined in the Device Settings or as inherited from a parent object like the Root group. Please consider this when you monitor devices outside the local network, especially when using SNMP v1 or v2c that do not provide encryption.

Is your PRTG installation leaking?

RIPE NCC releases new policy proposal for abuse contact validation

Today, RIPE NCC released a policy proposal update to ripe-563, better known as Abuse Contact Management in the RIPE Database. According to Marco Schmidt, Policy Development Officer at RIPE NCC, “The goal of this proposal is to give the RIPE NCC a mandate to regularly validate ‘abuse-c:’ information and to follow up in cases where contact information is found to be invalid.”

RIPE NCC

So what are the exact changes being proposed?

The current Abuse Contact Information policy states:

The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders’ networks.

The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.

The proposed Abuse Contact Information policy states:

The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behaviour originating in the resource holders’ networks.

The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.

The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. If no valid reply is received by RIPE NCC within two weeks (including if the email bounces back), the “abuse-mailbox:” contact attribute will be marked as invalid.

In cases where the “abuse-mailbox:” contact attribute is invalid, the RIPE NCC will follow up with the resource holder and attempt to correct the issue.

I particularly found one note in the “Rationale” section for “Arguments opposing the proposal” interesting, which states:

If organisations are not cooperative, the RIPE NCC ultimately has the possibility to close their RIPE NCC membership and deregister their Internet number resources.

I’m curious as to why this wasn’t the number one reason listed for “Arguments supporting the proposal” instead. If this was the case, would we still see blatant disregard to abuse complaints or claims of “fake abuse” from network operators in the RIPE NCC Service Region?

Other arguments supporting the proposal currently include:

  • Accurate and validated information in the RIPE Database is essential to establish a trusted and transparent environment in which all network operators can operate safely.
  • The lack of reliable accurate and validated information in the database negatively impacts legitimate uses of the RIPE Database, including:
  • Validating “abuse-c:” information is essential to ensure the efficiency of the abuse reporting system.

This proposal will now go through a four-week “Discussion Phase” allowing RIPE NCC community members to provide feedback. Once this phase is completed, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal.

Amcrest releases firmware update to correct constant cloud server connection issue

Back in May, I published a report on the latest firmware update from Amcrest resulting in a constant connection to cloud servers even for non-cloud customers.  I have verified the newest firmware from Amcrest has corrected the issue.

Amcrest

After speaking with Alen from Amcrest Cloud Support, I confirmed the expected behavior is the cameras will stop attempting to connect to their cloud servers two hours after powering up.

I updated my Amcrest IP2M-841 and IP3M-943 cameras to the latest version, V2.520.AC00.18.R and V2.400.AC01.15.R  respectively. I patiently waited two hours and confirmed the connection to the cloud servers ceased.

The only connection I observed the cameras making to the internet was to 54.84.228.44.

dh.amcrestsecurity.com

This was noted in my previous post as dh.amcrestsecurity.com where the camera reads the file “readbinfile.html” as some sort of firmware check.

While it took two months to correct this issue, I still commend Amcrest for taking the matter seriously and updating their firmware.