You Let a Fake Refund Agent Control Your Computer. What Needs Securing Now?
A practical recovery sequence after a refund scam involved remote access: stop the session, separate device and account risks, contact payment providers, and preserve useful records.

You have ended the call, but you cannot tell whether the person is still inside the computer. They asked you to install a support tool, open your bank account, and return a refund they said was too large. Now the supposed invoice looks suspicious, and every unfamiliar icon feels threatening.
The useful next step is not to guess whether “everything is hacked.” Separate four questions: is access still active, which accounts were exposed, did money move, and what device changes need checking? Each question has a different owner and a different response.
The FTC’s tech-support scam guidance describes remote-access requests and refund pretexts involving familiar company names. This is a response guide for someone who already granted access. If you only received an invoice and never called, clicked, installed, or shared anything, your exposure is different; our unexpected-receipt guide covers that earlier stage.
First: break the caller’s control
Stop the remote-support session and end the phone conversation. If you cannot confidently end the connection, disconnect the affected computer from the network while you seek trusted help. Do not keep the caller connected so they can explain how to undo their own actions.
Use another trusted device or telephone for urgent bank contact and account recovery. That could mean your own unaffected phone or an established workplace support route. Avoid entering new passwords into a device while you are unsure whether the stranger can still see or control it.
A workplace computer needs the organization’s IT or security team promptly. Tell them about the remote tool and the accounts opened. Do not factory-reset it, delete logs, or remove business applications on your own before they advise you; their response may require evidence and coordination you cannot provide alone.
Write a short account of actions, not a theory
Record the approximate start and end times, the invoice or message that prompted the call, the support application you remember, and what the caller asked you to do. Note uncertainty plainly. “I do not know whether file transfer was enabled” is better than deciding that no files could have been accessed.
Did you allow screen viewing only, approve control, enter a password, reveal a code, open a financial account, upload an identity document, or authorize a payment? Describe each action separately. Do not reconnect to the caller or reinstall anything just to reconstruct the sequence.
| Observed action | Who should know | Important distinction |
|---|---|---|
| Remote application installed or access approved | Trusted technical support or workplace IT | A legitimate tool can be used by an illegitimate operator |
| Password or sign-in code disclosed | The real account provider | Removing software does not secure an exposed account by itself |
| Bank account opened during the session | Your bank’s fraud team | The caller’s screen demonstration is not an independent transaction record |
| Gift-card codes or money sent | The relevant issuer or payment service | Device cleanup does not reverse that transfer |
| Work files or customer information visible | Your organization’s incident contact | Personal account recovery is not the whole workplace response |
Check the alleged refund with the bank, not the screen
A caller may have shown a credit and insisted you return an overpayment. The apparent balance on a screen they controlled is not enough to establish a real debt. Open the bank’s genuine app on a trusted device or call through a known number.
Explain the remote-access session, the alleged refund, and any payment you made. Ask the bank to establish the actual transaction status. If a genuine unexpected credit exists, let the institution explain the proper handling; do not create a new payment to the caller’s nominated recipient.
For money already sent, provide the amount, time, recipient, and reference. Ask about available intervention or dispute options promptly. Do not conceal the fact that you approved a transfer after deception, or describe a card purchase as unauthorized when that is not what happened. The provider needs the real sequence.
The FTC’s recovery guidance distinguishes cards, bank transfers, gift cards, cryptocurrency, and other payment methods. Different routes require different contacts. Fast reporting is worthwhile, but it is not a promise that funds can be recovered.
Secure accounts independently of the computer cleanup
From a trusted device, change exposed passwords through the real providers. Address reused passwords on other accounts. Give priority to the email account used for recovery and financial or workplace accounts involved in the session.
Review available sign-in activity, active sessions, recovery methods, and multifactor-authentication settings. If you cannot regain access, follow the service’s official recovery process. A password change is not evidence that every account setting or existing session has been reviewed.
Microsoft’s phishing-response guidance recommends recording the incident, changing affected and reused passwords, using multifactor authentication, and notifying relevant workplace or financial contacts. Apply the corresponding official instructions for the services you actually use.
Do not share a fresh verification code with a supposed investigator who calls about the incident. An accurate description of your earlier loss does not authenticate a new contact. Call the actual institution back using its established route.
Arrange device recovery without buying a second emergency
A remote-support application is not automatically malware. Its normal purpose does not make this session safe, either. The assessment needs to consider who used it, what permissions were granted, and whether other software or settings changed.
For a personal Windows computer, Microsoft’s unwanted-software guidance covers removing unwanted applications, updating security intelligence, running a full scan, and using an offline scan. A trusted technician can help decide whether those steps are sufficient or a reset is appropriate. Follow your device vendor’s current instructions for another operating system.
A clean scan is useful evidence, not proof that no information was viewed or copied during an authorized remote session. Conversely, an unfamiliar program name alone does not establish that every personal file was stolen. Keep device findings separate from assumptions about data exposure.
Do not download a cleanup package from the original caller or a private account offering guaranteed recovery. Choose assistance through an established provider, and understand the proposed work before granting another person access.
If identity documents or work information were involved
List the particular documents or identifiers disclosed. Use IdentityTheft.gov for US guidance matched to that exposure. A driver’s-license image, Social Security number, and ordinary email address do not all call for identical action.
For business information, report to the responsible internal contact rather than deciding on your own that no notification is necessary. The organization can assess its obligations and determine what records it needs. Keep customer details out of public posts asking for help.
What counts as a useful stopping point?
You have a stronger position when the untrusted session is ended, exposed accounts have been reviewed, payment providers have the relevant reports, and device recovery has a documented plan. Keep case references and follow-up instructions together so that a new message can be checked against a real open case.
Report the original impersonation through the relevant company’s official channel and ReportFraud.ftc.gov. If a stranger then promises to recover everything for a fee, our recovery-scam guide explains the next trap. You do not need a dramatic diagnosis to act: you need a factual record and a separate, trusted route for each problem.
Found a factual error or a source that has changed?
Send a correction →

