5 posts tagged with "remote-control"

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 8, 2026 weekly sync.
Ticket. CIV-89: Fanatics / OpenBet Locator — spoofing testing updates.

What we tested​

The Tennessee half of the Fanatics remote-access retest: HopToDesk remote control on Android against the Fanatics TN app (OpenBet Locator), with the remote operator driving the in-state device.

What happened​

• ⚠️ Remote-control session established. HopToDesk connected and the remote operator had full control of the Android device — the session itself was not blocked.
• ✓ Place Bet button hidden from the remote operator. Bets could not be placed remotely without local (in-person) interaction on the device.

Why it matters​

A partial outcome. The remote-access tool was not detected or blocked outright, but the wagering action was withheld from the remote session, so the fraud could not be completed remotely. The protection is not consistent across states and tools, though: on Fanatics MI this week, TeamViewer screen mirroring allowed full remote betting from Tennessee. An attacker who can supply even brief local interaction — or who finds a tool/state combination without the hidden-button behaviour — may still get through.

Cross-reference​

• Fanatics MI (OpenBet) — GPS simulator + TeamViewer screen mirroring undetected, bets placed from Tennessee (CIV-89) — the Michigan half of the same retest, where remote betting did succeed.
• Fanatics MI (OpenBet) — HopToDesk undetected on Android; TeamViewer + AnyDesk blocked (June 2, CIV-64) — HopToDesk on Android in Michigan a cycle earlier, where it slipped through at install and during an active session.

OpenBet profile → · June 8 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-79: Fanatics — Mac-to-Android remote control (OpenBet).

What we tested​

A cross-platform variant of the remote-control fraud pattern: a tool allowing a Mac laptop to remotely control an Android phone from a different network was used to place bets on Fanatics (OpenBet). The phone sat inside the permitted state; the controlling Mac did not.

What happened​

• ✗ OpenBet did not detect the remote-control session during a sustained test.
• ✗ Bets were placed on Fanatics through the remotely-controlled Android device.

Why it matters​

This extends the week's remote-control gap beyond macOS↔macOS to a desktop→mobile path. The same "proxy device inside the state" risk applies: a user outside a licensed state bets through a device that is physically in-state. Confirming the gap on a third integration (after Radar/Underdog and XPoint/Bet365 NJ) makes it a campaign-level concern rather than a single-vendor quirk.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — the origin finding for this campaign.
• Radar / Underdog DFS — remote screen control via Tailscale undetected for 20+ minutes (CIV-81).
• GeoComply / Bally Bet NJ — the same class of remote-control attack blocked ✓ (CIV-82) — direct contrast.

OpenBet profile → · 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 →