6 posts tagged with "teamviewer"

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

What we tested. Bet Saracen Arkansas, Radar browser-based deployment. Driven sessions via AnyDesk and TeamViewer.

What happened. Radar effectively restricted both active sessions — wagering outside permitted borders was prevented during tool operation.

Why it matters. This is one of the few positive Radar results we have. Sales conversations should be honest: AnyDesk + TeamViewer are detected at Saracen AR. The narrative is "Radar catches the obvious ones but misses the adjacent ones."

Cross-reference (same test cycle, less positive).

• Pre-loaded Windows "Remote Screen Sharing" triggered account restriction silently — false-positive RDP flag, high support-ticket risk.
• Cross-Boundary Validation passed: attempts to wager from Oklahoma uniformly blocked across all test cases.
• 350m+ from border: high success rates. 100m: Mac 44% pass rate; Windows users hit persistent lockout after a single failure with atypical fraud_jumped_single_device flag.

Action. Add HopToDesk, iPhone screen mirroring, RustDesk, VNC, MS Teams remote-control to the Radar test scope per the May 11 Betting Hero plan — these are the adjacent tools that distinguish "catches the obvious" from "is a compliance product."

Radar profile →