10 posts tagged with "tailscale"

Source. June 30, 2026 weekly sync.
Ticket. CIV-94: FanDuel NJ — Remote screen control blocked (GeoComply).

What we tested​

The same Mac-to-Mac remote screen-sharing attack that succeeded on BetRivers PA / XPoint during the same test cycle:

• Tailscale — two Macs on the same private network over the internet.
• macOS screen sharing — out-of-state Mac drives an in-state Mac via Finder, with full remote control and no local presence required on the host.

Operator: FanDuel New Jersey, a GeoComply desktop (PLC) deployment.

What happened​

• ✓ Detection fired immediately. The session was blocked under the "Blocked Software" rule before any wager could be placed.
• ✓ No bets were possible through the remote session.

Why it matters​

This is a clean, same-week, same-method contrast:

Operator	Geo provider	Tailscale Mac RDP	Result
BetRivers PA	XPoint	Mac-to-Mac via Finder	✗ Undetected — 1-hour FaceTime + sustained Mac RDP (June 30)
FanDuel NJ	GeoComply (PLC)	Mac-to-Mac via Tailscale	✓ Blocked immediately — Blocked Software rule

The attack uses entirely off-the-shelf, legal tools. Catching it in real time on FanDuel NJ while XPoint misses the identical pattern on BetRivers PA is a concrete compliance advantage for GeoComply in operator conversations this week.

Cross-reference​

• BetRivers PA (XPoint) — CIV-88 retest: FaceTime 1 hour + Tailscale Mac RDP undetected (June 30) — competitor gap on the same vector.
• GeoComply / Bally Bet NJ — Tailscale remote control blocked at login + mid-session (June 2, CIV-82) — prior GeoComply win on the same attack class.

Detection matrix → · June 30 weekly sync →

Source. June 30, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — advanced spoofing review (retest).

What we tested​

Two additional spoofing checks from the June 23 CIV-88 cycle, confirmed during the week ending June 30:

1. FaceTime RDP — sustained session duration
2. Tailscale Mac-to-Mac RDP — detection reliability

Both against BetRivers Pennsylvania (XPoint).

What happened​

1. FaceTime RDP — 1-hour confirmed session

• ✗ A tester in New Jersey remotely controlled an iPhone in Pennsylvania via Apple's built-in FaceTime screen sharing.
• ✗ The session ran for a full hour — bets placed continuously on both sportsbook and casino throughout.
• ✗ No block or interruption at any point.

This confirms the initial FaceTime gap is not a brief window at login — it is an open, sustained exposure for the full session duration.

2. Tailscale Mac RDP — detection failed

• ✗ Two Macs paired under one Tailscale account.
• ✗ An out-of-state device initiates remote control of an in-state (PA) host via native macOS screen sharing (Finder).
• ✗ No local interaction required on the host — the remote connector receives full control.
• ✗ The geolocation check passes against the host's in-state position.

Why it matters​

Both retests deepen the Pennsylvania compliance picture from June 23:

• FaceTime — the gap is now quantified as hour-long, not transient. Any operator conversation about "we catch it eventually" is contradicted by a full session of uninterrupted wagering.
• Tailscale + macOS — the same unattended desktop-control pattern that GeoComply blocked on FanDuel NJ the same week remains undetected on BetRivers PA / XPoint.

Cross-reference​

• BetRivers PA (XPoint) — initial CIV-88 advanced spoofing (June 23).
• GeoComply / FanDuel NJ — same Tailscale Mac RDP method blocked immediately (June 30, CIV-94) — direct same-method, same-week contrast.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73).

Xpoint profile → · June 30 weekly sync →

Source. June 23, 2026 weekly sync.
Ticket. CIV-91: Wind Creek Bethlehem PA — environment compliance updates.

What we tested​

Full integration testing of Wind Creek Casino Online PA (Radar) across iOS, Android, and browser. Results delivered June 19.

What happened​

Test	Result	Detail
RDP — iOS FaceTime & iPhone Mirroring	✗ Non-compliant	Not detected. User outside PA (TN) remotely controls an in-state iPhone and places bets. In-state user must log in first; remote user controls the screen from there.
RDP — Android DroidVNC + Tailscale	✗ Non-compliant	Not detected. Remote user in an excluded state places bets on a PA Android device using DroidVNC and Tailscale together.
VPN — Android (Turbo VPN)	✗ Non-compliant	Not detected on Android. User logged in, placed bets, and played casino with VPN active.
VPN — iOS	✓ Compliant	VPN detected at login and mid-session.
RDP — Android (TeamViewer, AnyDesk, HopToDesk)	✓ Compliant	Detected at login or interval check.
Fake location — Android (FLA)	✓ Compliant	Detected before and during a gaming session.
Cross-border into exclusion state	✓ Compliant	User fails geolocation at or just past the border (~90 m buffer).
Rooted Android + mocked location	⚠️ Compliant*	User fails for mock location / jurisdiction errors. Root itself not detected, but mocked location is caught. With GPS JoyStick the failure took longer — suggesting IP mismatch or low confidence score rather than direct root detection.

UX issues — new user flow & deposit​

Operator-side friction observed during the same test cycle (not Radar detection failures, but worth tracking):

• Android Galaxy S16 deposit loop: debit card deposit failed and sent the user into a loop — account flagged for Wind Creek approval with no timeline and no clear prompt. User attempted 3 times before abandoning.
• ID verification false positive: notification asked user to close any app using the camera (triggered by screen recording). User bypassed by restarting the app — screen recording continued undetected.
• No autofill for address, phone, or email on either platform.
• Deposit methods limited to PayPal, Venmo, and debit card only.

Why it matters​

Three undetected vectors on the same Radar deployment while the "standard toolkit" checks pass — native iOS screen sharing, Android DroidVNC + Tailscale, and Android VPN. The compliant iOS VPN handling directly contrasts with the undetected iOS RDP gap.

Cross-reference​

• BetRivers PA (XPoint) — advanced spoofing review (June 23, CIV-88) — parallel Pennsylvania operator testing.
• Underdog DFS (Radar) — Tailscale undetected (June 2, CIV-81).

Radar profile → · June 23 weekly sync →

Source. June 23, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — advanced spoofing review.

What we tested​

Advanced spoofing checks on BetRivers Pennsylvania (XPoint), building on the June 16 compliance analysis.

What happened​

1. Tailscale + Mac RDP — undetected

Two Macs on the same Tailscale account. Mac1 (out of state) connects to Mac2 (in PA) using macOS built-in screen sharing via Finder. Mac2 user does not need to be present — the remote user gets full control.

2. Rooted Android + mocked location — undetected (retested on mobile network)

Same non-compliant result on mobile connection. Setup uses Magisk with a renamed manager to avoid detection, root partially hidden. Key nuance: the mock location app (FakeGPS) is technically visible to BetRivers, but a custom low-level module suppresses the mock-location flag before BetRivers can read it — which is why it gets through. A second rooted device lost its integrity status and needs troubleshooting.

3. FaceTime RDP — undetected after local auth

The in-state person must physically handle the phone to log in and enter the 2FA code. Once logged in, the remote user takes full control — requires brief cooperation from the in-state user at the start, but no presence after that.

Why it matters​

All three vectors succeeded in a follow-up cycle. The Magisk module path defeats the SDK's mock-location signal at the OS layer — not merely by hiding the spoofing app. The Tailscale + macOS pattern delivers fully unattended desktop control, which is the highest-risk RDP class on Pennsylvania deployments this month.

Cross-reference​

• BetRivers PA (XPoint) — initial compliance analysis (June 16, CIV-88).
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73).

Xpoint profile → · June 23 weekly sync →

Source. June 16, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — compliance analysis.

What we tested​

A compliance analysis of BetRivers Pennsylvania (XPoint) covering native iOS remote-control methods, Tailscale + macOS native screen sharing, rooted Android with mock-location concealment, and a baseline suite of standard remote-access tools, IP-change detection, Android fake location apps (FLA), and a resigned iOS app.

What happened​

Vector	Result	Notes
Native iOS RDP (FaceTime + iPhone Mirroring)	✗ Undetected	Remote operator in an out-of-state location placed bets on the in-state Pennsylvania iOS device.
Tailscale + macOS native RDP	✗ Undetected	Mesh VPN tunneling combined with built-in macOS screen sharing was not flagged.
Rooted Android + concealed mock location	✗ Undetected	Root state and hidden mocked coordinates both went unnoticed; bets and gameplay succeeded from an exclusion state.
TeamViewer, AnyDesk, HopToDesk	✓ Blocked	Standard commercial remote-access utilities were identified and suppressed.
IP change detection	✓ Blocked	IP-based relocation checks fired as expected.
Android fake location apps (FLA)	✓ Blocked	Geolocation manipulation frameworks were detected before wagering.
Resigned iOS app	✓ Blocked	Tampered iOS binary was rejected.

Why it matters​

Three high-impact vectors — iOS screen sharing, Tailscale-based macOS RDP, and root-concealed mock location — all succeeded on the same operator while the "standard toolkit" checks passed. That pattern suggests detection tuned to known commercial RDP signatures and common FLA tools, but blind to native OS remote-control channels and Magisk-level telemetry suppression. The iOS and Tailscale gaps are especially material given prior undetected Tailscale findings on other XPoint deployments.

Cross-reference​

• BetRivers PA (XPoint) — advanced spoofing review: Tailscale macOS RDP, Magisk mock-location suppression, FaceTime handoff (June 23, CIV-88) — follow-up cycle on the same operator and ticket.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73) — same Tailscale class of attack, different state.
• Bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64) — another XPoint desktop RDP gap in the same test window.

Xpoint profile → · June 16 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-82: Bally Bet NJ — Remote screen control blocked (GeoComply).

What we tested​

The remote-screen-control fraud pattern: one person physically in the permitted state (New Jersey) hands full control of their screen to someone in an entirely different location, who places all the bets. The person in-state does nothing themselves.

Stack used:

• macOS Native Screen Sharing — Apple's built-in remote-desktop feature, driving Mac #1 from Mac #2.
• Tailscale — a networking tool that puts both Macs on the same private network over the internet, so Screen Sharing works as if they were side by side.

Operator: Bally Bet NJ, a GeoComply-integrated deployment.

What happened​

• ✓ Blocked at login. The attempt was stopped before any wager, with the error Blocked_software.
• ✓ Blocked mid-session. Detection also fired during an active session — not only at startup — so a session that began clean could not be handed off to a remote controller later.

Why it matters​

This is a clean, real-time win on the exact vector that three competitor integrations missed in the same test cycle. Regulators require operators to prevent geolocation fraud; catching remote screen control in real time — at login and mid-session — reduces operator liability and is a concrete, demonstrable compliance advantage for the GeoComply value proposition. The attack used entirely off-the-shelf, legal tools, which is exactly what makes the competitor gaps below material.

Cross-reference​

• Radar / Underdog DFS — same Tailscale remote-control method undetected for 20+ minutes (CIV-81).
• OpenBet / Fanatics — Mac-to-Android remote control undetected, bets placed (CIV-79).
• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26, CIV-73) — the finding that prompted this expanded testing campaign.

Detection matrix → · June 2 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-81: Underdog DFS — Remote screen control via Tailscale (Radar).

What we tested​

The same remote-screen-control pattern that GeoComply blocked on Bally Bet NJ this week: a tool lets one person take full control of another person's computer screen from a completely different location. The person physically in the permitted state does nothing — the remote user places all the bets. Here the target was Underdog DFS, running on Radar.

Stack: a Tailscale tunnel linking the two machines, driven through built-in screen-sharing.

What happened​

• ✗ The session lasted over 20 minutes with active remote control in use.
• ✗ Radar did not detect or block it. Bets could be placed freely throughout.

Why it matters​

This is a clear fraud and compliance gap. A user outside a licensed state can bet through a "proxy" device inside the state, with no exotic configuration — the attack uses off-the-shelf, legal tools. Operators running this integration carry regulatory exposure if the method is used by real fraudsters.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — the origin finding that prompted this expanded campaign.
• OpenBet / Fanatics — Mac-to-Android remote control undetected (CIV-79) — same gap, third integration.
• GeoComply / Bally Bet NJ — the same Tailscale remote-control attack blocked at login and mid-session ✓ (CIV-82) — direct contrast on the identical vector.

Radar profile → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-73: Bet365 NJ — Remote Desktop via macOS Screen Sharing (XPoint).

What we tested​

A common fraud pattern: one computer remotely controls another computer in a different location to place bets. We tested whether Bet365's geolocation provider could detect this when the operator runs on XPoint (Bet365 NJ).

Stack used:

• Tailscale — a networking tool that connects two computers over the internet as if they were on the same local network.
• macOS Screen Sharing — Apple's built-in remote-desktop feature, driven through the Tailscale link.

What happened​

• ✗ Tester accessed Bet365 NJ from a different physical location through the macOS↔macOS remote session.
• ✗ XPoint failed to detect this remote-access method. Bets were placed without interruption.

Why it matters​

This is a clean compliance gap on a vector specifically targeted by remote-betting fraud. The bypass uses entirely off-the-shelf, legal tools — Tailscale and a feature already built into macOS — with no exotic configuration.

Follow-up testing across Radar, OpenBet, and GeoComply-integrated clients has been requested to scope whether this is XPoint-specific or a broader macOS RDP detection gap across providers.

Cross-reference​

• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes — same operator, different geo provider, same Tailscale-based attack pattern.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19) — second XPoint integration where Tailscale-based RDP is unreliably detected.

Xpoint profile → · May 26 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-69: Bet365 NJ — RDP Testing on Android.

What we tested​

Remote desktop access against the Bet365 New Jersey Radar deployment, using:

• Tailscale (mesh VPN) to bring the controlling Mac and the controlled Android device onto the same overlay network despite being on physically separate networks.
• RealVNC to drive the Android device from the Mac.

The tester then placed real-money bets through the remote session.

What happened​

• 25+ minutes of continuous, real-money betting through the remote session.
• Zero interruptions, timeouts, or restrictions.
• Radar's geolocation checks did not detect the remote session at any point — neither at session start, nor at any of the periodic re-checks during the session.

Why it matters​

Tailscale + RealVNC is a credible, easily-assembled remote-access setup. The fact that it went completely undetected for 25 minutes suggests Radar's RDP signal detection at Bet365 NJ either does not exist for this combination, or does not run frequently enough to matter.

Combined with the Bet365 MI GPS-simulator bypass on the same week, this is the second confirmed spoof method against a Bet365 / Radar deployment in a single test cycle.

Cross-reference — RDP across providers this week​

Operator	Provider	Tool	Result
Bet365 NJ	Radar	Tailscale + RealVNC	✗ Undetected (this finding)
RSI BetRivers NJ	XPoint	Tailscale	✗ Inconsistent
DraftKings DFS NJ	Radar	Zoom / AnyDesk / TeamViewer	✗ Inconsistent
Fanatics TN	OpenBet	TeamViewer	✗ Undetected
Fanatics TN	OpenBet	FaceTime	✓ Blocked
Fanatics NJ	OpenBet	droidVNC-NG	✓ Blocked and named

Radar leads the failure list this week with two distinct RDP bypasses on two distinct operators.

Radar profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-73: BetRivers NJ — RDP via macOS.

What we tested​

Remote desktop access against the RSI BetRivers New Jersey XPoint deployment, driven from macOS via Tailscale. Two distinct attack methods were exercised:

1. Brief one-time approval — first-touch remote-session setup requires a single approval prompt at the controlled device.
2. Fully unattended — no prompt, no human interaction required at the controlled device after initial enrolment.

What happened​

• Most cases: not detected. XPoint failed to flag Tailscale-based remote access in the majority of runs, allowing bets to be placed from a physically separate location.
• When detection did trigger: inconsistent and trivially bypassable. Detection events did not persist — logging out and back in cleared the restriction and the session continued.
• Both attack methods confirmed. Both the one-time-approval path and the fully-unattended path placed bets successfully.

Why it matters​

This is the second cross-state confirmation of XPoint's RDP detection gap, alongside the FaceTime RDP failure at RSI Delaware (Apr 7). The gap is structural, not state-specific — RSI deployments in multiple states (AZ, DE, NJ) all show the same pattern.

Combined with the Bet365 NJ Tailscale + RealVNC bypass on Radar this week, both challenger providers running NJ sportsbooks are blind to Tailscale- driven remote sessions.

Cross-reference​

• RSI Delaware (XPoint) — FaceTime RDP not detected — same cross-region pattern, different RDP tool.
• Fanatics NJ (OpenBet) — droidVNC-NG RDP blocked and named — OpenBet handles a comparable RDP-on-Android vector at the same operator footprint.

XPoint profile → · May 19 weekly sync →