Private Relay, Public Risk: Apple’s Network Reputation in Fraud Ecosystems
MacOS in Fraud Operations
In underground communities, macOS has gained a strong reputation as the preferred environment for online fraud. Underground forum users often claim that “banking fraud works better on Mac,” believing that traffic from Apple devices appears more legitimate to banks and online merchants. As a result, transactions made through macOS are viewed as less likely to trigger security checks or account restrictions.
One underground forum member described in detail how they configured their Mac environment for fraud-related activity:
Example of an underground operator explaining why macOS is favored in fraud operations.
“I use a MacBook with Safari 26.1. It is perfect for multi-profile work because cookies stay isolated with no need to extract or manage them manually. I use two routers, one running VLESS USA and the second connected over Wi-Fi to distribute SOCKS traffic and block leaks. Google DNS does not expose European servers. I stopped using anti-detect browsers1. I worked with many virtual environments before, but Apple is the best. I have used Mac for four years, manage about thirty profiles, and switch SOCKS routes with Keenetic in a few clicks. It is stable, clean, and reliable.”
Examples like this show why macOS is valued among fraud operators. Its architecture isolates browser sessions, reduces cross-profile contamination, and produces a consistent environment that lowers detection risk. Many actors believe it is more trustworthy and stable than anti-detect browsers or Windows-based setups.
As detection systems become more advanced, fraud actors look for environments that closely mimic legitimate user behavior. MacOS fits this role because it provides consistent device fingerprints, strong privacy defaults, and a network reputation that helps its traffic appear genuine. Some operators add that even when they do not own Apple hardware, they can still access Apple’s trusted network signals by running macOS through VMware and enabling iCloud Private Relay inside the virtual machine.
macOS Virtual Machine in VMware Workstation.
Our research identified an underground guide that builds directly on this idea. It explains how to run macOS on a Windows computer using virtualization in order to access iCloud Private Relay, Apple’s encrypted proxy service. According to the author, this setup routes activity through Apple’s trusted network and makes it appear as if the traffic originates from a real Apple device while keeping the operator’s infrastructure hidden.
iCloud Private Relay Overview
iCloud Private Relay is a privacy feature introduced by Apple to protect user data and browsing activity. When enabled, it hides the user’s IP address and encrypts DNS requests made through Safari. Instead of connecting directly to websites, traffic is routed through two relay servers: one operated by Apple and one operated by a separate partner. This design prevents websites and network providers from identifying a user’s real location or tracking their behavior.
In legitimate use, Private Relay protects users against tracking, fingerprinting, and network-level surveillance. Even Apple cannot link a subscriber’s identity to their browsing activity.
Layered Virtualization Structure
Within underground communities, however, this same capability is being reinterpreted as an evasion technique. Actors believe that connections routed through Apple’s network inherit a high level of trust, making them less likely to trigger fraud checks or manual review.
iCloud Private Relay Configuration in Safari
A threat actor under the moniker “Мамкин Кардер” published a detailed guide showing how to run a fully functional macOS environment on a standard Windows computer to gain access to iCloud Private Relay. The method allows operators to make their activity appear to originate from a legitimate Apple device while their real infrastructure remains hidden.
Virtualized macOS and iCloud Private Relay Setup
The guide outlines how to build a functional macOS environment on a Windows host using virtualization tools. The goal is to replicate the behavior of a real Apple device and enable iCloud Private Relay, while keeping all activity isolated inside a virtual machine.
According to the instructions, the operator installs VMware Workstation Player, applies VMware Unlocker to allow macOS installation, loads a macOS image into a new virtual machine, and completes the initial setup. After macOS is running, the user signs in with an Apple ID, enables iCloud Private Relay, and performs all activity through Safari so that traffic is routed through Apple’s encrypted proxy network.
macOS Virtual Machine Setup Process
The guide’s author claims that the virtualized macOS environment behaves similarly to a real Apple device, with Safari traffic sent through Apple’s relay servers and the resulting network appearance resembling Apple-originated traffic. Because the virtual machine is separated from the Windows host, browsing activity inside macOS does not interact with the underlying system.
The guide presents this method as a way to work with the network characteristics of macOS without owning Apple hardware. Some actors believe that combining virtualization with Apple’s trusted network reputation may help reduce scrutiny during online operations, although the guide provides no evidence or tested results to support these claims.
Example of a Telegram post where actors advise using macOS.
“Hi all, choosing a laptop for work. If it is for carding2, pick Mac because its fingerprints match real Apple devices. For routine tasks like collecting fullz3 using a Mac is inconvenient.”
To reduce detection risk, the guide instructs users to restore the virtual machine to a clean state before each session. Some actors combine this with a VPN running on the Windows host to control the apparent geographic source of the macOS traffic. When a VPN is active, iCloud Private Relay inherits the host VPN’s location.
The guide also includes operational recommendations designed to strengthen anonymity:
- Use a dedicated non-personal Apple ID to avoid attribution.
- Disable unnecessary services such as Bluetooth.
- Ensure the macOS VM time zone matches the VPN location to avoid mismatches.
- Perform all browsing inside Safari, since Private Relay only protects Safari traffic.
Recommendations
- Reassess Fraud Risk: Financial institutions should reassess any practice that automatically assigns low fraud risk to traffic coming from iCloud Private Relay.
- Elevated Scrutiny for High-Risk Actions: Sessions using Private Relay should be evaluated with elevated scrutiny, particularly for critical actions such as authentication, account recovery, and high-value transactions. This is due to the feature hiding the user’s true IP address and being usable in virtualized environments, signaling high anonymity.
- Treat Egress IPs as High-Anonymity Endpoints (Tor Equivalent): Financial institutions should treat Apple’s Private Relay egress IP ranges as high-anonymity, shared exit points, equivalent to a Tor exit node. These IPs, whose list is publicly published by Apple4, must be scored separately from trusted Apple-origin traffic and should not be considered trusted customer identifiers, as they carry traffic from many unrelated users, including potential threat actors.
Don’t forget
to Visit
Our Solutions
Read More1Tools that spoof device fingerprints and browsing environments
2An underground slang term for compromised payment cards fraud
3An underground slang term for full set of PII
4https://mask-api.icloud.com/egress-ip-ranges.csv
About the Author(s)
Anton Vilenskiy is a Cyber Threat Intelligence Analyst at Q6 Cyber. Anton’s background includes a BBA in Management and MA in Supply Chain Logistics from Kazan National Research Technological University.