Do not give an unverified crypto support contact remote control of a device that holds wallet access. Verify the request through an independently opened official support channel. If an untrusted session already occurred, end that access and use a separate trusted device to protect affected accounts; then assess what was exposed. Closing one support conversation does not establish that device access, saved logins and wallet keys are all safe.
The software brand does not identify the person using it
Remote-support tools have legitimate uses. A familiar installer or recognizable app name does not prove that a caller represents your wallet or exchange. The FTC's technical-support warning describes impersonators obtaining access through invented problems and urgent repair claims. Start with the contact's origin: did you open the official ticket yourself, and does the request appear there?
A transaction hash, your public address or a copied ticket number is not proof of the contact's authority. Someone can learn these from information you already shared. Do not continue to an installation just because the person correctly repeats the amount you are missing. Our fake support guide covers identity checks; the decision here is narrower: whether to grant access to the actual device and what to investigate afterwards.
If access is active, stop the session before opening more secrets
End the remote session and disconnect the affected device from the network if you cannot confidently stop the access. Do not open the wallet's recovery screen to demonstrate the issue. Move account-protection work to a separate trusted device. If you cannot determine what was installed or allowed, seek qualified technical help rather than following more instructions from the same contact.
Preserve the chat, claimed identity, times and any payment identifiers without keeping the remote session open for evidence. A computer used for multiple roles may also contain email, password-manager sessions and exchange logins. Record which of those were accessible. An application reporting that a connection ended answers one question; it does not reconstruct what the other person viewed or copied during the session.
| What happened | Question to investigate | Protective next step | What not to conclude |
|---|---|---|---|
| A request arrived but you granted nothing | Was the contact genuine? | Verify through the official channel | Receiving a message alone proves a stolen wallet |
| You showed the screen | What private information was visible? | Record visible secrets and sensitive records | View-only necessarily kept all information private |
| You granted remote control | What actions and files were accessible? | End access and arrange device assessment | A closed chat ended every permission |
| Persistent access was configured | Can the contact reconnect without a new prompt? | Review that tool's unattended-access controls | Closing the current window removed persistence |
| Wallet secrets were displayed or entered | Does someone else now control the keys? | Protect remaining funds from a trusted environment | Changing the wallet app password changes the seed |
| An exchange session was used | Are logins or API credentials exposed? | Use official account-security controls | Removing the remote app revokes account sessions |
A remote-access session and saved access are different
AnyDesk's unattended-access documentation describes a mode that can permit later connections without a person accepting each request, subject to the configured platform and permissions. Its saved-login mechanism can also use tokens. If such access was set up during the encounter, investigate it explicitly rather than assuming that the visible session was the only permission created.
The same documentation distinguishes stopping new saved-login tokens from invalidating existing ones: clearing the option to issue them does not itself clear previously issued tokens. Use the software's current documented controls, or have a trusted technician remove unwanted access. This is a product-specific example, not a universal menu for every remote tool. Platform restrictions also differ; do not assume that an Android screen-sharing prompt describes a desktop session.
Trace three possible outcomes without treating them as identical
In a fictional first case, you receive a request to install a remote tool but refuse and open official support yourself. There is no evidence of a remote session merely from that request. Save enough information to report the impersonation. Do not let a second stranger turn the warning into a paid recovery emergency when no wallet compromise has been established.
In a second case, the contact viewed your screen while a wallet address and order page were visible, but you did not open a recovery phrase. That still calls for an exposure review, including whether remote control or file access was granted. It does not justify inventing certainty that a seed was stolen. Describe exactly what you know, what was possible and what remains unverified.
In a third case, the contact made you reveal recovery words or import them into a page. Treat the key exposure as a separate priority. Resetting an exchange password or uninstalling the remote tool does not change those wallet keys. Use a trusted environment to protect remaining assets and obtain help if unsure. Keep the old wallet records for investigation, but do not rely on a clean-looking balance screen as proof that the exposed secret is safe.
Protect accounts from a trusted environment
- End untrusted access and preserve the communication record.
- Use a separate trusted device to reach official account-security pages.
- Protect affected email and exchange accounts, reviewing active sessions and credentials as appropriate.
- List any wallet secrets actually displayed, entered or accessible and handle that exposure separately.
- Arrange assessment of the affected device and remove unwanted persistent access using verified instructions.
- Keep transaction hashes and support records, and report theft or fraud through the appropriate official channels.
The FBI's support-scam guidance recommends preserving records, protecting accounts and checking the device. New Zealand's FMA also documents an exchange impersonation case involving remote access. Neither an official-looking logo nor a recovery promise establishes that the person can reverse a transfer. No outcome or reimbursement is guaranteed by making a report.
Avoid paying another contact to validate an alleged recovery. Our crypto recovery scam explainer describes that follow-up risk. If you were investigating an ordinary no-account swap, return to its order evidence through the official site from a trusted environment. Account cleanup, device cleanup and reconciliation of the original payment remain separate tasks; completing one does not silently complete the others.
FAQ
What are remote access scam red flags?
An unverified contact may combine urgent wallet warnings with a request to control your device or reveal secrets. Check the request in an independently opened official support channel before granting anything.
What should I do after a remote access scam?
End the access, use a separate trusted device to protect affected accounts, and assess the device and any exposed wallet secrets. Preserve records without leaving the untrusted session running.
What does a remote desktop scam involve?
It uses an invented support role to obtain access or payments. The remote tool can be legitimate software; that does not authenticate the person asking to use it.