26 posts tagged with "rdp"

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-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

Remote desktop detection retest on bet365 Michigan and BetRivers Michigan (both XPoint) — RustDesk and the commercial RDP stack (HopToDesk, AnyDesk, TeamViewer).

What happened​

• ✓ HopToDesk, AnyDesk, TeamViewer — detected and blocked before a bet could be placed on both Michigan integrations. This is a key difference from prior cycles — XPoint did improve commercial RDP detection.
• ⚠️ RustDesk — blocked, but with timing and install nuance.
  • The prior launch-order identification lag (June 2 finding) was not reproduced under rigorous retest.
  • Session was blocked at the first interval check — approximately 290 seconds (~4.5 minutes) later.
  • RustDesk is detected only while actively running — not when merely installed. A player can have RustDesk on their device without triggering an alert until a session starts.

Why it matters​

Commercial RDP detection on Michigan deployments is materially better than historical baselines — worth citing in competitive conversations. The RustDesk result is improved but not clean: a ~4.5-minute active- session window and silent tolerance of a installed-but-idle copy still leave residual exposure, especially vs GeoComply's real-time mid-session blocks on comparable vectors.

Pennsylvania BetRivers deployments still show undetected native iOS and Tailscale paths in the same test window (June 23 advanced spoofing review, CIV-88).

Cross-reference​

• bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64).
• Bet365 MI (Radar / XPoint) — full validation (May 26, CIV-63).

Xpoint 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-54: Locance (LocationSmart) — full validation.

What we tested​

Integration validation of Locance (LocationSmart) on Luxury Casino Ontario — cross-border movement between Ontario and Quebec, remote access (TeamViewer, AnyDesk, HopToDesk on desktop and Android), VPN usage across Mac / Android / iOS, and near-border location accuracy on iOS.

What happened​

Area	Result	Notes
Cross-border play (ON ↔ QC)	✗ Non-compliant	Wagering was possible for multiple kilometres across the provincial boundary in both directions with no friction.
Remote access (TeamViewer, AnyDesk, HopToDesk)	✗ Undetected	Gameplay continued with active remote control on desktop and Android solutions with little to no friction.
VPN — Mac	✓ Detected	VPN / proxy usage was identified; platform access denied.
VPN — Android	✗ Undetected	Active VPN tunneling was not blocked; user authenticated and wagered.
VPN — iOS	⚠️ Blocked, no UX	Access was denied with VPN enabled, but no error message or troubleshooting guidance was shown.
Near-border UX (iOS)	✗ Poor accuracy	~100–150 m from the border the app placed the user in Quebec despite a physical Ontario location.

Why it matters​

Locance failed on the two vectors regulators care about most on a border-adjacent Ontario deployment: jurisdictional containment (cross- border play for kilometres) and remote session control (three major RDP tools undetected). VPN handling is inconsistent across platforms — Android is fully open, iOS blocks silently — which is both a compliance gap and an operator-support problem. The near-border mis-location suggests geofence accuracy degrades exactly where enforcement should be strictest.

Cross-reference​

• Locance / Luxury Casino Ontario — remote-access block fails on retry (June 8, CIV-53) — prior retest on the same operator; retry-fragile remote block.
• Locance Ontario — KYC gap + detection rules exposed in API (June 2, CIV-53) — compliance finding on the same provider from the prior cycle.

Locance profile → · June 16 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 8, 2026 weekly sync.
Ticket. CIV-53: Locance (LocationSmart) Ontario — remote access retest.

What we tested​

A remote-access retest of Locance (LocationSmart) on Luxury Casino Ontario, with the tester operating from Tennessee. Two angles: desktop remote access (TeamViewer & AnyDesk) and GPS location spoofing (iAnyGo).

What happened​

• ✗ Remote access (TeamViewer & AnyDesk, desktop) — block did not hold. An initial geolocation check showed an error when the tester attempted to access a Luxury Casino Ontario session remotely from Tennessee. However, after a single retry, access was granted and bets were placed — the block did not hold on the second attempt.
• ⚠️ GPS location spoofing (iAnyGo) — blocked only indirectly. Location spoofing was blocked, but not by GPS-anomaly detection: Luxury Casino requires a Canadian internet connection (via VPN) to load, and that VPN was detected as a proxy. The GPS spoof itself did not trigger any detection.

Why it matters​

Two shallow, retry-fragile defences:

1. The remote-access block is not durable. A single retry defeats it, which is effectively no protection against a persistent attacker — the first error reads as transient rather than a hard stop.
2. The GPS spoof went undetected on its own merits. The only thing that stopped it was the proxy flag on the required Canadian VPN. Remove or launder that dependency (e.g. a residential Canadian connection) and the GPS spoof is unguarded.

Both findings are relevant for competitive positioning against operators considering Locance in Ontario.

Cross-reference​

• Locance (LocationSmart) Ontario — real-money deposit with no identity check + detection rules exposed in API (June 2, CIV-53) — the prior-cycle finding on the same provider and ticket.
• Locance full validation is in progress this cycle (CIV-54) — see What's Next in the June 8 weekly sync.

Locance profile → · June 8 weekly sync →

Source. June 8, 2026 weekly sync.
Ticket. CIV-89: Fanatics / OpenBet Locator — spoofing testing updates.

What we tested​

Follow-up testing this week extended our remote-access findings on Fanatics to additional methods and states. On the Fanatics MI app (OpenBet Locator) we exercised three vectors: an iOS resigned app, a GPS simulator, and TeamViewer screen mirroring of the iOS device — with the controlling operator located in Tennessee.

What happened​

• ✓ iOS Resigned App — detected. Geolocation failed as expected. However, the error message returned blank, making it difficult to identify the specific detection trigger.
• ✗ GPS Simulator — not detected. The tester logged into the Michigan app, placed bets, and launched and played casino games — all from Tennessee.
• ✗ TeamViewer screen mirroring (iOS, MI) — not detected. Full remote control of the iOS device was achieved via TeamViewer; real-money bets were placed on the Michigan app from Tennessee.

Why it matters​

Two independent vectors — a GPS simulator and TeamViewer screen mirroring — each let an out-of-state user place real-money bets on Fanatics MI from Tennessee. The resigned-app check fired, but the blank error message is itself a UX/diagnostic gap: it confirms a block without surfacing the reason, which makes triage and rule attribution harder. A sophisticated fraudster only needs one of the two undetected paths to wager from outside the licensed state.

Cross-reference​

• Fanatics TN (OpenBet) — HopToDesk remote session connects but the Place Bet button is hidden (CIV-89) — the Tennessee half of the same retest campaign.
• Fanatics MI (OpenBet) — GPS spoofing hardware detected ✓ (May 26, CIV-48) — direct contrast: a hardware GPS-spoofing accessory was caught on Fanatics MI in the prior cycle, but this software GPS simulator was not.
• Fanatics TN (OpenBet) — TeamViewer screen sharing bypass (May 19) — the same TeamViewer screen-mirroring gap previously seen in Tennessee, now confirmed in Michigan.

OpenBet profile → · June 8 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-64: MI advanced spoofing retest.

What we tested​

During advanced spoofing retests near the Michigan–Canada border, the team tested several remote-control applications on Android against the Fanatics MI app (OpenBet), plus iOS screen sharing for comparison.

What happened​

• ✗ HopToDesk — NOT detected at installation or during an active remote session on Android. Bets were placed consistently while a remote user was in control.
• ✓ TeamViewer — detected and blocked.
• ✓ AnyDesk — detected and blocked.
• ✓ iOS FaceTime screen sharing — detected near the border.

Why it matters​

This is a known detection gap for a specific tool, not a blanket failure: the two most common remote-access apps (TeamViewer, AnyDesk) are caught, and FaceTime screen sharing is caught on iOS — but HopToDesk slips through entirely on Android. A sophisticated fraudster who identifies this specific gap can use it to circumvent geolocation checks on Fanatics in Michigan while the obvious tools stay blocked.

Cross-reference​

• XPoint / bet365 MI — RustDesk evades detection when launched after the geolocation client (CIV-64) — the desktop half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full validation: iOS FaceTime + Windows RDP undetected (May 26) — direct contrast: FaceTime screen sharing is caught here on Fanatics, but went undetected on Bet365 MI.

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 →

Source. June 2, 2026 weekly sync.
Ticket. CIV-64: MI advanced spoofing retest.

What we tested​

RustDesk remote access against bet365 MI (XPoint) on both Windows and macOS, varying the launch order of RustDesk relative to the XPoint geolocation client.

What happened​

• ✓ RustDesk launched before XPoint → flagged immediately.
• ✗ RustDesk opened after XPoint was already active → undetected on both Windows and macOS. Over 50 consecutive location checks passed with the remote tool running.
• Detection only resumed once the XPoint client was manually rebooted.

Why it matters​

The behaviour points to a one-time startup scan for prohibited software rather than real-time monitoring. The vulnerability stems from a predictable initialization sequence: an adversary who recognises the pattern can bypass desktop geolocation on bet365 MI simply by activating remote access after launch — a repeatable, low-effort gap that leaves a notable regulatory exposure open for the duration of a session.

Cross-reference​

• OpenBet / Fanatics MI — HopToDesk undetected on Android (CIV-64) — the mobile half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full integration validation (May 26) — prior multi-issue cycle on the same operator.
• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — second XPoint remote-access gap, different mechanism.

Xpoint profile → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

A full integration validation of Bet365 Michigan — Radar for the mobile app, XPoint for the web client. Covered: near-border behaviour, cross-state jurisdiction handling, two RDP attack paths (iOS, Windows), and post-failure UX.

What happened​

Area	Result	Notes
Near Canadian border (Belle Isle)	✗ Inconsistent at 200–1,000 m from the border. Betting slip continued to load but functioned unreliably — suggests an insufficient buffer zone.
Detroit ↔ Canada cross-border	✗ An erroneous jurisdiction alert fired on the betting slip, incorrectly telling the user wagering is restricted to New Jersey residents while on Bet365 MI.
iOS FaceTime RDP	✗ Undetected. A tester in Massachusetts placed bets remotely on a device located in Michigan with no issues.
Windows RDP	✗ Undetected. A tester in Massachusetts placed wagers on both the sportsbook and casino via a Windows device located in Michigan.
UX — post-VPN-detection recovery	✗ Persistent application glitches after a VPN-detection event. Tester unable to resume wagering; forced restart of the app required to restore functionality.

Why it matters​

This validation lands five separate issues on a single operator in a single test cycle:

1. Two compliance failures on the same border — buffer-zone unreliability + a flatly wrong jurisdiction message. Either could be cited as a regulator-facing defect.
2. Two undetected RDP paths — iOS (FaceTime) and Windows — both spanning multi-state remote sessions. RDP is the textbook remote-betting fraud vector and both paths went uncaught.
3. The UX recovery loop is broken even when detection does fire. A user who triggers a VPN block cannot recover without restarting the app, and receives no guidance on how to do so.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26) — third undetected RDP path on Bet365 in two weeks (NJ and MI, two geo providers).
• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes (May 19).
• Bet365 MI (Radar) — GPS simulator bypass, restriction not re-applied on re-entry (May 19) — distinct prior gap on the same operator.

Radar profile → · Xpoint profile → · May 26 weekly sync →

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

What we tested​

Whether FaceTime screen sharing — Apple's built-in feature for mirroring one device's screen to another over the network — would be detected when initiated at the start of a wagering session on Fanatics West Virginia (OpenBet Locator).

What happened​

• ✓ Detection fired immediately at session start.
• ✓ Result: account or device was blocked, preventing the wagering session from continuing.

Why it matters​

iOS FaceTime is a credible remote-control vector: it ships on the device, requires no third-party tools, and gives the remote party a real-time view of the screen with light interaction. OpenBet catching it at session start is exactly the moment where this defence is cheapest and least disruptive — before any bets, before any state changes.

This is the same week as the Bet365 MI validation where iOS FaceTime RDP went undetected while a user in Massachusetts placed bets on a device in Michigan. Same vector, two operators, opposite outcomes — clear evidence that FaceTime detection is a vendor / integration choice and is implementable today.

Cross-reference​

• Bet365 MI (Radar / XPoint) — iOS FaceTime + Windows RDP undetected (May 26) — direct counter-example on the same vector this same week.
• Fanatics NJ (OpenBet) — droidVNC-NG RDP blocked and named (May 19) — adjacent positive case on the Android side of the same vendor.

OpenBet profile → · May 26 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-75: Saracen AR — Radar Verify app retest, full competitor validation.

What we tested​

Retest, since May 19, 2026, of how Radar behaves on Bet Saracen Arkansas when the Remote Desktop Connection (RDC) client is merely present on the Windows host — i.e. installed but not actively driving a remote session.

Setup:

• Windows 10, with RDC pre-installed, later upgraded in-place to Windows 11.
• No active remote-desktop session at the time of testing.

What happened​

• ✗ Presence of RDC is no longer enough to block the app. This contradicts the April 19 finding, which had previously recorded pre-installed RDC as sufficient grounds for Radar to refuse access.
• ✗ The system does block access whenever the app is launched, even with no remote session running in the background.
• ✗ Block fires with no explanatory error. Users see no recovery guidance — they cannot wager and they cannot tell why.

Why it matters​

Two distinct issues stacked on one another:

1. Detection regression. The April 19 baseline (presence of RDC blocks the app) no longer holds — a measurable loosening of Radar's posture between cycles. Worth confirming whether this is intentional or a regression.
2. UX-as-compliance failure. Even when the block fires, it does so silently. A legitimate user with RDC installed on their PC (a common configuration in any IT-managed environment) is permanently locked out with no signal as to what is wrong. This is significant UX friction and a customer-support amplifier.

Cross-reference​

• Bet Saracen AR (Radar) — resigned iOS app placed bets from MI (May 19) — distinct prior compliance gap at the same operator.
• Bet Saracen AR (Radar) — Oxylabs + Location Guard combination blocked (May 19).

Radar profile → · May 26 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-70: BetFanatics — RDP Testing on Android via DroidVNC.

What we tested​

Remote desktop access against the Fanatics New Jersey (OpenBet Locator) deployment, configured as:

• droidVNC-NG running on the controlled Android device.
• RealVNC Viewer on the controlling device.
• Tailscale mesh-VPN linking the two over the public internet.

This is the same kind of setup that bypassed Bet365 NJ (Radar) and RSI BetRivers NJ (XPoint) earlier this week — Tailscale + a VNC tool.

What happened​

• Immediately blocked. The session was refused at the compliance check.
• Error message named the app. The error explicitly identified droidVNC-NG as the remote-control application in use, rather than surfacing a generic "session blocked" string.

Why it matters​

This is the cleanest compliance-UX outcome we recorded this week. Two things matter:

1. The detection worked. A real RDP-style attack on Android was identified and refused at session start — no bets placed, no prolonged exposure window.
2. The error message did something useful. Naming the specific remote-control application means:
   • The player knows what to uninstall to get back into compliance.
   • The operator's support team gets a clear signal in the logs.
   • The compliance audit trail is self-documenting.

Contrast with Radar's generic "Account Locked" string on DraftKings DFS NJ this week, which says nothing about what triggered the block or how to recover.

Cross-reference — RDP this week​

OpenBet is the only provider with an unambiguous RDP positive this cycle:

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

OpenBet's coverage is not uniformly good — TeamViewer slipped past at Fanatics TN — but where it triggers, it triggers cleanly.

OpenBet profile → · May 19 weekly sync →