6 posts tagged with "macos-screen-sharing"

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