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 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'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 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:

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:

Example “letters only” domains:

Example “other” domains:

All domains were registered to a “Mohammad Khezri” of Iran. A reverse WHOIS search on 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

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 – “Stay Warm Whenever and Wherever”

While this one is clearly a well-thought-out spoof, cryptojacking is no laughing matter. - 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

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:

uBlock Origin

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.


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 – 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 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:

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:

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 and 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 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 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 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

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

Neither did the copy from September 18, 2017 10:06:54 GMT: copy of

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: and

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 “” They are also known as “Poney Telecom” and “Scaleway” in other references.

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’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:

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’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 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.”


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.


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

This was noted in my previous post as 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.

How to stop a SIP attack with a wordsmith gotcha

Over the last six months, I’ve noticed almost 6,000 Session Initiation Protocol (SIP) attacks coming from Online SAS (AS12876) network. These attacks were typically seen coming in on the default SIP port which is UDP port 5060.

While the attacks poured in, I was frequently using the Abuse Report Form for Online SAS, which was very easy to use. After confirming my abuse requests, I would wait to receive a follow up from Online SAS or their customer directly.  Typically within 24 – 48 hours I’d receive a response and confirm the attacks have stopped. However in one case the attacks didn’t stop and continued for twelve straight days.

On August 7, I reported IP address and received the following update from Online SAS on August 9:

Dear Sir or Madam,

Your abuse number 183740 is now closed.

Here is a comment left by our customer:

sent the complaint to this client for checking about this issue and resolving


This was not resolved, so I sent another follow up to take corrective action. On August 10, the following message was received:

Dear Sir or Madam,

Your abuse number 183966 is now closed.

Here is a comment left by our customer:

sent the complaint to this client for checking about this issue and resolving


Yet again the attacks did not cease, so I sent another abuse request on August 14. The next day I received the following:

Dear Sir or Madam,

Your abuse number 184423 is now closed.

Here is a comment left by our customer:

sent the complaint to this client for checking about this issue and resolving


Sadly the attacks persisted with fervent vigor, so I decided a new approach was needed. On August 19, I sent in a new abuse request for stating, “If you are a cybercriminal, please respond ‘sent the complaint to this client for checking about this issue and resolving’ to this message”

The very same day, I received the following update:

Dear Sir or Madam,

Your abuse number 184747 is now closed.

Here is a comment left by our customer:

service is suspended for set on rescue mode


After this I confirmed no further SIP attacks from were seen!

Large-scale ongoing RDP attack campaign and Global Layer B.V. (AS49453) decries as “fake abuse”

A little over a month ago I reported an ongoing RDP attack campaign coming from Global Layer B.V. (AS49453) and their lone upstream peer Regionalnaya Kompaniya Svyazi Ltd. (AS57028) to their abuse team.

On July 11, an unnamed Global Layer Abuse Desk representative responded:

Our customer has already been informed to take action in this matter.

However, the RDP attacks from their network continued and I followed up again on August 6, receiving the following response:

The IP in question has been blocked and customer informed.

Unfortunately this was not case and the  attacks continued to pour in, so I sent daily updates requesting comment why action had not been taken.  I even offered to help them update their firewalls to nullroute the offending customer.

Global Layer

On August 10, I received a follow-up from the Global Layer Abuse Desk:

I suggest you stop sending us fake abuses. We first of all blocked the IP in question and that vps was terminated days ago.
It’s not possible you are getting any more complaints from our network. So check again.

So I checked again and found a massive, ongoing RDP attack campaign coming from their network.  I noted the prefixes announced by AS49453 and their direct associate AS57028 and reviewed my firewall logs accordingly. I was astonished to find 2,940 RDP attacks, as of this writing.

IP  address RDP attacks logged 1123 368 308 134 131 128 118 101 95 69 59 53 40 33 26 18 15 14 13 13 11 11 9 8 7 7 7 5 4 2 2 2 1 1 1 1 1 1

The raw data with timestamps is available here.  Note that a very small percentage of the  attacks were also SSH and are included above.

So how many times has this “fake” abuse been logged on AbuseIPDB?

EDIT:  Due to a “Data Loss Incident” at AbuseIPDB on 08/08/2017, the reported totals below won’t match the current total reports.  The totals below were noted from before the incident occurred.

AbuseIPDB report URL AbuseIPDB total reports 325 196 189 112 102 163 3 217 18 97 41 28 29 79 34 12 0 67 32 40 22 2 10 12 102 126 3 12 5 3 5 1 14 2 3 0 92 39

Based on the reports above, I feel it’s safe to conclude this network abuse is very real. How long will AS49453’s BGP peers let this abuse continue unabated?