Unmasking ‘iP64’ - An Ad Fraud Exploit Targeting Apple’s iCloud Private Relay Infrastructure and Costing Advertisers an estimated $65+ Million

Over the last few months, Pixalate’s AFAC (Ad Fraud and Compliance) research team has investigated invalid traffic (“IVT,” or ad fraud) in connection with iCloud Private Relay IP Addresses. Pixalate, in conjunction with Basis Technologies, has uncovered a widespread potential exploit - dubbed “iP64” - that Pixalate estimates may cost advertisers over $65 million in 2022 in the U.S. alone.

Our findings, presented in this post, show how ad fraudsters appear to be exploiting an unquestioning trust of Apple’s iCloud Private Relay IP Addresses - aided by the opacity of the ad tech supply chain. Pixalate is calling this ad fraud scheme iP64 because of the way in which apparent fraudsters seem to be inserting iCloud Private Relay IPv6 and IPv4 addresses into ad requests to masquerade the true source of the traffic. 

Pixalate first reported on this phenomenon in August 2022, noting that 90% of purported iCloud Private Relay (iCPR) traffic may actually be invalid — i.e., traffic that is only pretending to be protected by iCPR.

Table of Contents:

• Key Takeaways
• How 'iP64' came to be
• Apple’s claims about iCloud Private Relay fraud security
• Accounting for Apple’s “Hide My IP” 
• What does the iP64 ad fraud exploit look like?
• SPO + Basis Technologies Collaboration
• Solutions: How the digital ad industry can mitigate ad fraud from iP64
  
  

Key Takeaways:

• Pixalate estimates that the iP64 ad fraud exploit may cost U.S. advertisers $65+ million in 2022. To see how we arrived at this estimate, visit here.
• According to Pixalate’s data, 21% of Safari traffic claims to come from iCloud Private Relay (iCPR) IPs - but more than 90% of that appeared to be spoofed.
• Ad fraudsters may be trying to take advantage of misplaced scope of trust in the safety of iCloud Private Relay IP addresses.
• Based on Pixalate’s observations, a common method of iCloud Private Relay exploitation appears to be the fraudulent insertion of iCPR IPv6 and IPv4 addresses into digital advertising bid requests. Pixalate has dubbed this ad fraud scheme “iP64.”
• The main defense against this attack may be to consider blocking all iCloud Private Relay IP addresses for the moment, while building an understanding of the Supply Chains that deliver most of the iCPR traffic, and work with impacted sellers.
• We believe that fraudsters might be using the iP64 method with the expectation that iCPR IP ranges are often automatically marked as safe by ad tech companies (stemming from trust in Apple’s brand and its repeated assertions of iCPR security).
  
  

How ‘iP64’ came to be

Pixalate believes the factors that contributed to the emergence of iP64 are as follows: 

1. Apple made assertions that all iCloud Private Relay traffic is safe from fraud. Apple publishes a list of IP address ranges that are used by iCPR and Hide My IP (more details below), and have made claims about the security of iCPR, including: “Websites that use IP addresses to enforce fraud prevention and anti-abuse measures can trust that connections through Private Relay have been validated at the account and device level by Apple.” These assertions may have encouraged the ad industry to include iCPR addresses in “allow lists.” 
2. Programmatic advertising has a complex supply chain in which bid requests typically go through multiple intermediaries (“hops”). This means that most companies involved in the supply chain do not have direct access to the device to verify the “declared” IP address.
3. Fraudsters appear to have taken advantage of the above two facts to mask fraudulent activity (like spoofing data centers, targeting certain domains, etc). They can potentially insert an Apple-published iCPR IP address on an ad request, likely to make the entities looking at the request think that the request is safe and/or blindly trust the request simply because it’s from an iCPR IP address.

Apple’s claims about iCloud Private Relay fraud security

Apple has asserted that iCloud Private Relay traffic is safe from fraud. However, Pixalate has not found any guidance from Apple regarding its definition of “fraud” in this context. 

For example, in the Developer page Prepare Your Network: 

• “All connections that use Private Relay validate that the client is an iPhone, iPad, or Mac and that the customer has a valid iCloud+ subscription. Private Relay enforces several anti-abuse and anti-fraud techniques, such as single-use authentication tokens and rate-limiting. This is designed to ensure only valid Apple devices and accounts in good standing are allowed to use Private Relay.” 

• “Traditional fraud detection that relies solely on IP addresses might need to be updated to ensure legitimate users are not impacted. Consider treating these addresses like larger carrier grade NAT or enterprise IP addresses to better account for this type of traffic, since many Private Relay users may be assigned to a single relay IP address.”

And in iCloud Private Relay Overview:

• “Built-in fraud prevention: An important part of Private Relay is enforcing several anti-abuse and anti-fraud techniques as users connect. Additionally, the Relay IP address assigned to users will remain stable during a browsing session, making sure websites see a consistent address. The combination of stable Relay IP addresses and fraud prevention is intended to provide websites with added trust when seeing connections from Private Relay users.”

• “Relay access and fraud prevention: Private Relay is designed to ensure only valid Apple devices and accounts in good standing are allowed to use the service. Websites that use IP addresses to enforce fraud prevention and anti-abuse measures can trust that connections through Private Relay have been validated at the account and device level by Apple.”

The absence of cautionary language accompanying these statements seems to encourage companies to blindly trust the iCloud Private Relay IP Address ranges as being fraud-free in all contexts. This messaging suggests that Apple may not have factored into the architecture (or its associated messaging) the role of the programmatic ad supply chain, including the reality that most participating entities are not in a position to establish direct connections to the end-user device.

Fraudsters appear to be inserting iCPR IP addresses to bid requests with expectations that a number of companies will blindly follow Apple’s guidance and add iCPR IP address ranges to their “allow lists.” According to Pixalate’s research, advertisers appear to be falling into this trap at an increasing and alarming rate. Pixalate has measured the rate of iP64 growing from ~10% in February 2022 to ~20% in August 2022 for iOS and MacOS X Safari traffic, and we project it will reach ~25% by December 2022.

Accounting for Apple’s “Hide My IP”

“Hide My IP” is a free privacy service provided by Apple that claims to automatically hide the end-user’s IP address from “known trackers” on iOS 15+. Hide My IP uses the iCloud Private Relay infrastructure (including the same IP addresses).

Pixalate verified we were not flagging legitimate iCloud Private Relay/”Hide My IP” traffic as invalid by:

1. Checking for IP address stability during a browser session. According to Apple (screenshot below), iCloud Private Relay IP addresses “assigned to users will remain stable during a browsing session.” This means the IP address will remain consistent for legitimate iCloud Private Relay and Hide My IP users during the same browsing session.
   
   However, Pixalate’s data science team studied the obfuscated traffic and found that for 67% of the traffic, the IP address rotated at least twice during the same browsing session, and it rotated at least three times in 50% of the traffic.Apple's direction regarding expected Relay IP Address behavior.
2. Checking for Pixalate on the tracker list. Pixalate is on the tracker list. Entities on the list will see iCPR IP addresses if Hide My IP or iCloud Private Relay are active on an end-user device.

What does the iP64 ad fraud exploit look like?

Pixalate took a closer look at the traffic that claimed to be from iCPR or Hide My IP sources and, as discussed in the earlier post, identified discrepancies between IPs detected on the device on ad delivery and what was declared in the bid request.

Distribution of traffic associated with iCPR IP Addresses

When we analyzed the individual sources of masked IP (Declared but not Detected Traffic), we could see that in many cases those devices demonstrated bot-like behavior, in addition to hiding behind the apparently falsely-declared iCPR IP addresses.

In the following example, Pixalate detected that the end-user device’s true IP came from T-Mobile, but the declared IP was from iCloud Private Relay. 

True IPs demonstrate T-Mobile source

Regardless of whether Pixalate detected IPv4, IPv6, or both, from a user, we would see a mix of IPv4 and IPv6 iCPR addresses being declared in the ad request.

Pixalate has also detected end-user device IPs seen behind declared iCPR addresses belonging to known data centers from organizations such as Amazon AWS. In the below examples, Pixalate observed AWS data center IPs rotate through multiple websites while declaring to originate from iCPR. 

Firefox requests claiming to have iCPR IPs

The above examples also show purported iCPR traffic coming from the Firefox browser, which is impossible given iCPR is only available on Safari.

Other than these simple examples, Pixalate measured other bot-like behaviors associated with these IP addresses that purported to be masked using iCPR IP addresses.

By using a Pixalate-created D3 graph to map out the connections between the masked iCPR impressions and the various domains seen in the traffic, Pixalate confirmed that the iP64 ad fraud exploit often impacts small groups of popular domains. When aggregating results across the iCPR addresses associated with iP64, bot-like clusters around a particular group of popular domains appear. 

Top Affected Domains:

• eonline.com
• mlb.com
• nbcnews.com
• yahooinc.com
• weather.com
• investing.com
• espn.com
• usatoday.com
• wenxuecity.com
  
  

Bot-like behavior from purported iCPR sources

The D3 graph above shows a subset of iCPR IP addresses associated with iP64 (blue dots) and the domains they have visited (orange dots). This small cluster of domains are often the only domains visited by traffic coming from these iCPR IP addresses. This behavior is consistent with what is observed commonly in “bot rings.”

SPO + Basis Technologies Collaboration

One of the partners Pixalate worked with in this investigation was Basis Technologies. Together, Pixalate and Basis worked closely to break down the distribution of the misrepresented iCPR traffic across various sellers. Because it is difficult for buyers to identify iCPR IP addresses at bid request time, this seller analysis helped to work with the relevant traffic sources and address the problem.

We then analyzed the Supply Path Optimization (SPO) data to match iP64 traffic to sellers that appeared anywhere in the Supply Chain. Pixalate’s research team parsed the OpenRTB Supply Chain Object (SCO) from the bid request and viewed the traffic from a Supply Path perspective. In doing this, Pixalate found further correlation of this potentially fraudulent iCPR traffic going through certain sellers more than others.

In addition, looking at the SPO data, we found that traffic from a given user looked different when certain sellers were in the chain. An iCPR IP address would be declared when they were in the chain, and a normal IP address declared for the same user when such sellers were not in the chain - even when the impressions came in around the same time. This suggests that these sellers were impacted by iP64 more than others.

SPO analysis where only certain paths from a device claimed iCPR

This analysis – and insights gleaned therefrom – enabled Basis to work with those sellers to further examine and block this misrepresented traffic. 

Solutions: How the digital ad industry can mitigate ad fraud from iP64

What is the best defense against this form of IVT? As discussed above, the challenge with this exploit is that bid requests in programmatic advertising often traverse through a chain of entities, and most of the entities after the first hop do not have direct access to the end-user’s device and its IP address. In other words, in most cases, they are not able to directly confirm, at bid request time, whether the end-user device’s actual IP address truly is an iCloud Private Relay IP address. 

We believe that the best way to fight this type of IVT is to have a good understanding of the Supply Chain, analyze the sources of this form of IVT and work with those sellers to reduce potentially misrepresented traffic. Given the low volume of legitimate iCloud Private Relay users detected by Pixalate (1-2% of all Safari traffic as of August 2022), a potential near-term solution may be to add iCPR IP addresses to “block lists.” While this approach may result in blocking real iCPR users - true adoption numbers appear to be low enough that, in the near term, most companies would not see any material impact (other than IVT reductions). This path should be used based on the overall traffic composition and impact.

For more data related to this exploit (top iCPR IVT IPs, top associated data center IPs, and top pub domains impacted) download the list for free today.

If you have further questions on this post, about iCloud Private Relay in general, or our Supply Chain analysis capabilities, please reach out to us using this contact form.

Disclaimer

Pixalate is neither asserting nor assigning culpability with our research and insights. Is it Pixalate’s belief that our readers may be interested in learning more about apparent ad fraud related to iCloud Private Relay IP Addresses. Pixalate’s opinions expressed herein are just that, opinions, which means that they are neither facts nor guarantees. In the context of the apparent ad fraud discussed herein, and per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes;” and “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.” Finally, brands, logos, and trademarks specified in this blog posting and related media are utilized merely for referential purposes, and such brands, logos, and trademarks remain the property of their respective registrants and owners, as applicable.