26 posts tagged with "rdp"

Source. May 19, 2026 weekly sync.
Ticket. CIV-59: Fanatics — OpenBet Locator | adv spoofing.

What we tested​

Remote-control testing against the Fanatics Tennessee (OpenBet Locator) deployment, comparing two screen-mirroring tools:

1. TeamViewer — desktop remote control, tester in NY driving a device located in TN.
2. FaceTime — same setup, Apple's native screen-sharing.

What happened​

• TeamViewer: not detected. The NY tester placed bets on the TN platform via TeamViewer screen mirroring with no error, restriction, or session interruption.
• FaceTime: detected and blocked correctly. Same operator, same jurisdiction, same testing setup — but the FaceTime session was identified and blocked.

Why it matters​

OpenBet Locator's RDP coverage is inconsistent by tool, not by operator or by platform. Some screen-mirroring tools are caught (FaceTime, droidVNC-NG at Fanatics NJ this week), others are not (TeamViewer here, HopToDesk + iPhone mirroring from May 5).

This is the same structural pattern we documented in earlier weeks: the remedial-action classes claim screen-share detection, but the detection runs against a fixed list of known signatures rather than generalising. Any RDP tool not in that list sails through.

Cross-reference​

• HopToDesk + iPhone screen mirroring at Fanatics TN (May 5) — earlier finding, same operator, same kind of gap.
• droidVNC-NG blocked and named at Fanatics NJ (this week) — positive counter-example, same operator footprint.
• Bet365 NJ (Radar) Tailscale + RealVNC undetected for 25 minutes (this week) — comparable bypass on a different provider.

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

What we tested. Fanatics Sportsbook TN deployment (full OpenBet Locator Protect Suite, live since Dec 2025). Drove remote sessions via HopToDesk on Android and iPhone screen mirroring on iOS, from outside Tennessee.

What happened. Both tools bypassed Locator's RDP detection. Out-of-state wagering succeeded on both platforms.

Three more gaps from the same test cycle (May 5 weekly).

• No state border buffer zones — players within 50m of the boundary experience frequent state-switching, persistent page refreshes, and inability to finalise cash-out.
• No IP-change monitoring — IP address changes during active sessions are not flagged. A critical spoofing indicator is missed.
• VPN restriction false positives — aggressive VPN blocks fire on legitimate corporate-network users, increasing support overhead.

Why it matters. Four distinct compliance gaps in a single Fanatics TN test, all in the flagship US deployment. This is the single strongest sales asset against a bundled-OpenBet platform pitch. Pair with the prior border- jumping finding and the TQJ-churn data point.

OpenBet profile → · SDK comparison →

Source. May 5, 2026 weekly sync.

The finding​

The pre-loaded Windows Remote Desktop Connection app (labelled "Remote Screen Sharing" in the OS) triggers Radar account restrictions without notifying the user.

Why it matters​

This is a false-positive RDP flag: the app is present on virtually every Windows install, and is not running an active remote session. Triggering account restrictions silently from its mere presence is the worst case for support teams — the user has no idea what failed, no suggested resolution path, and no diagnostic message.

Cross-reference (same test cycle)​

On the same operator + same week, AnyDesk and TeamViewer were correctly restricted during active sessions (positive result). So the detector posture is: detects two real RDP tools, false-positives on one pre-installed Windows app it shouldn't flag. The RDP class is where Radar is most inconsistent.

Radar profile → · May 5 weekly sync →

What we tested. RSI Delaware deployment (newly live, April 2026), iOS device localised to DE, driven remotely via FaceTime RDP from a Michigan host. Both casino and sportsbook flows.

What happened. No RDP detection. The MI-based user successfully placed remote wagers on the DE platform across both products.

Cross-reference. The same gap was previously confirmed at the RSI AZ deployment (Jan 2026 migration from GeoComply). Two operators, two regions, same SDK gap — this is structural.

Related RSI DE findings (same test cycle).

• Account SUSPENDED on DE-MD border crossing before any spoofing attempt was made.
• Near-border pass/fail points inconsistent, erroneous failures even moving away from the boundary.
• Static/mobile toggling required at MD + DE borders — major UX friction vs GeoComply's seamless PA.
• macOS install requests access to documents folder (known security concern).
• AnyDesk installed (but not running) silently blocks betting — false positive RDP flag.
• Mac CPU spikes 0.5% → 16% at 1-minute intervals during poker.

Xpoint profile →