A first look at the misuse and abuse of the IPv4 transfer market

By on 21 Jul 2020

Category: Tech matters

Tags: , ,

Blog home

The depletion of unallocated IPv4 addresses combined with the slow transition to IPv6 has led to the emergence of the secondary market for transfers of IPv4 addresses.

In 2009, the first documented transfer took place within the ARIN region. Since then, IPv4 transfers have become a viable solution for acquiring IPv4 address space (Figure 1).

The number of IP addresses involved in intra- and inter-RIR transfers.
Figure 1 — The number of IP addresses involved in intra- and inter-RIR transfers.

Regional Internet Registries (RIRs) have responded to the emergence of the IPv4 market by establishing policies that aim to safeguard the accuracy of registered IP blocks and provide oversight and transparency on how organizations trade them.

Read: APNIC services to help your IPv4 transfers

However, there have been multiple reported attempts to exploit the transfer market as part of malicious operations — such as the hijacking of dormant address space and spamming — which, judging by exchanges between operators in mailing lists and messaging boards, is of concern for network operators.

In our recent paper, my colleagues and I at Lancaster University, Simula Metropolitan, and the University College London, sought to shed light on the misuse and abuse of the IPv4 transfer market and understand how malicious actors target it.

How we did it

Our overall approach, summarized in Figure 2, aimed to correlate IP transfer reports with reports of malicious activity.

To collect the list of IP transfers, we compiled the reports published by each RIR between 12 October 2009 and 24 August 2019. To understand malicious activities connected to the transfer prefixes, we synthesized an array of datasets including blacklists, honeypot traces, and reports on prefix hijackers. We used a large array of data sources on malicious activities to address the shortage of longitudinal data on cyber attacks and misbehaviour and to explore distinct types of exploits. Consequently, the data covered spamming, malware, phishing, unsolicited scans, distribution of unwanted programs and illegal content, Command and Control (C&C) botnet servers, and IP prefix hijacking.

While the reported IP transfers provide only organization names, malicious data on prefix hijacking and C&C/bulletproof hosters are encoded at the level of Autonomous Systems (ASes). Therefore, to study the involvement of such malicious ASes in the transfer market we needed to map organization names to AS Numbers (ASNs).

For 48% of the transfers, we could match the organization names to ASNs using historical whois data. We mapped an additional 23% of transfers to ASNs by detecting permanent changes in the ASNs that originate a transferred prefix in the BGP routing data when such changes correlated with the reported transfer date.

Overview of method and datasets used to analyze malicious activity correlated with IPv4 transfers.
Figure 2 — Overview of our method and datasets used to analyse malicious activity correlated with IPv4 transfers.

An AS that has part of its address space blacklisted is not necessarily malicious. For example, botnet operators often exploit cloud platforms to deploy malware on short-lived virtual machines to evade detection. Similarly, broadband providers may have large parts of the address space blacklisted because end users who are not security-aware may have their personal computers infected.

To identify potentially legitimate ASes with a disproportionately high fraction of their addresses blacklisted, we adapted techniques for the identification of Internet hypergiants and large providers. Consequently, we created a dataset of filtered ASes without those legitimate networks to prevent skewing of our results.

A significant percentage of transferred prefixes appear as blacklisted

We compared the malicious activity emanating from transferred and non-transferred prefixes as reflected by the IP blacklist reports. Almost 40% of the blacklisted transferred prefixes that are routed — that is, visible in the BGP tables of RouteViews and RIPE RIS, have at least one blacklist report — compared to only 6% of the non-transferred routed prefixes (Figure 3).

Distribution of transferred and non-transferred prefixes with blacklist reports.
Figure 3 — Distribution of transferred and non-transferred prefixes with blacklist reports.

Although the blacklisting activity does not originate uniformly across the address space, breaking down the IP space into /24 prefixes results in a similar conclusion: transferred /24 sub-prefixes are six times more likely to be blacklisted compared to non-transferred prefixes. Moreover, transferred prefixes are disproportionately represented in the blacklist for every type of malicious activity, as shown in Figure 4.

Transferred prefixes are disproportionately represented in blacklists for every type of malicious activity.
Figure 4 — Transferred prefixes are disproportionately represented in blacklists for every type of malicious activity.

When do the transferred IP addresses get blacklisted?

We also explored the dynamics between malicious activity and IP transfers. Since the date in transfer reports may not be the exact date when the prefix routing changed, we used the date when the BGP origin ASN changed as a reference transfer date.

Figure 5 shows that only 50% of the reported transfer dates coincided with the date of BGP origin change. Interestingly, more than 20% of the transfers involved ASNs mapped to different organizations than that reported.

Date of BGP origin change compared to the reported transfer date.
Figure 5 — Date of BGP origin change compared to the reported transfer date.

In addition to finding the effective transfer date, it’s important to determine if the transferred prefixes were actually used to address Internet-facing devices before and after the transfer. If a prefix got deployed only after the transfer, inevitably it could get blacklisted only after the transfer.

To this end, we analysed prefixes with IPs encountered in longitudinal IP census lists before and after the effective transfer date only. For these active prefixes, we compared the timing of blacklisting to the transfer date.

As shown in Figure 6, the number of blacklisted IPs peaks within a year of the transfer date for all types of malicious activity. We also found that ASes that are both sellers and buyers of prefixes are twice as likely to have their address space blacklisted, compared to sellers and buyers alone.

Figure 6 — Blacklist reports per type of malicious activity for transferred IPs, compared to the transfer date.

Next steps

Our findings show that the ASes involved in the transfer market exhibit consistently higher malicious behaviour compared to the rest of the ASes, even when we account for factors such as business models and network span.

We do recognize that our findings are likely to be a lower bound of malicious activity from within transferred IP addresses since a number of transactions may occur without being reported to the RIRs.

As part of our future work, we plan to extend our analysis to non-reported IPv4 transfers and develop predictive techniques for blacklisting based on the monitoring of the IPv4 transfer market. We believe that these insights can inform the discussion and development of RIR policies regarding IPv4 transfers, and help operators and brokers conduct better-informed due-diligence to avoid the misuse of the transferred address space or unintentionally support malicious actors.

This research is supported by the 2019 RIPE NCC Community Projects Fund.

Vasileios Giotsas is a researcher at Lancaster University. His work focuses on systems security and resilience, distributed systems, and measurement and analysis of Internet protocols.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.