What to Do After a Vishing Call Succeeds: First-Hour Response Guide

Somewhere in the middle of a phone call, or a few minutes after hanging up, it clicks: that wasn’t IT. That wasn’t a legitimate account recovery process. That was someone talking you through handing over access.

That instant, not the call itself, is when the clock most people never see actually starts running. In the strongest documented vishing campaigns, attackers have completed data searching, staging, and theft in under an hour, with extortion demands landing within 30 minutes of the attacker logging off, according to Mandiant’s Google Threat Intelligence Group. Palo Alto Networks’ Unit 42 separately found that the fastest quarter of 2025 intrusions reached exfiltration in 72 minutes. Different datasets, different methodologies, both pointing the same direction: whatever window you have, it’s shorter than it feels.

This guide isn’t telling you that every successful vishing call ends in a headline-grade breach. Most don’t. It’s telling you what to do with the window that’s still open, whether the caller got a one-time code, a live login, remote access to your machine, or something more direct.

What You’ll Learn

• How to end the call and make the right first move in the first few minutes
• How to identify which branch applies to what actually happened on the call
• What IT/security needs to contain for MFA, sessions, and remote access
• How to confirm the access is actually gone
• Which reporting and rehearsal habits shorten the next incident’s response time

Stop the Call First

Before anything technical, end the call.

• Hang up. Don’t explain why, and don’t negotiate an exit. You don’t owe the caller a graceful goodbye, and drawing it out only gives them more material to work with.
• Don’t call back on any number the caller gave you, even to “double-check” who they were. If it was a spoofed or attacker-controlled line, calling it back just confirms you’re engaged and worth another attempt.
• Don’t keep talking to “see what they’re actually after.” It feels like intelligence-gathering. It’s really just handing over more time and more detail.
• Write down what was said and done while it’s fresh. Note the time, what the caller claimed to be, what you typed or approved, and anything you installed. This record is exactly what IT will need in the next step, and memory of a stressful call degrades fast.
• Report it immediately, through your organization’s real reporting channel, not one the caller mentioned or suggested. If you’re not sure what that channel is, that’s worth fixing before this happens to someone else, but for now, go to IT or security directly.

Identify What Actually Happened on the Call

The right response depends on what the caller actually got you to do, not on the fact that a vishing call succeeded in general terms. Before reacting, work out which of these applies. More than one can apply to the same call.

• You approved a one-time code or an MFA prompt, or you typed credentials into a page the caller walked you through in real time.
• You installed or authorized a remote-access or screen-sharing tool at the caller’s direction.
• You authorized an app, browser extension, or “connected service” the caller framed as a required security step.
• You took a direct financial or data action: wired funds, purchased gift cards, changed banking or payroll details, or sent files.

Each of these needs a different first move. Treating all of them as “well, I’ll just change my password” is exactly the mistake that leaves an attacker in place.

You Approved an MFA Prompt or Logged In Live

Some of the most damaging documented vishing campaigns run on this branch, and it’s the one most likely to be underestimated, because nothing about it looks like typing a password into an obviously fake page.

Here’s the mechanism, based on Google Threat Intelligence Group’s reporting on the “BlackFile” extortion campaign (tracked as UNC6671): the caller walks you to a look-alike login page and relays what you type to the real service in real time. When the genuine MFA challenge arrives, you approve it, because as far as you can tell, you’re completing a normal sign-in. The attacker is now authenticated as you, and in the same session, often registers their own MFA method for durable access. GTIG’s reporting notes that the campaign’s pretext, usually a claimed mandatory security or passkey migration, “provides a logical cover for any subsequent security alerts generated during the compromise.” In other words, if something looks slightly off afterward, the story you were told already explains it away.

Ordinary MFA fatigue, or “push bombing,” works differently: an attacker who already has your password spams approval requests, hoping you tap yes out of annoyance (the 2022 Uber breach, where a contractor eventually approved a flood of unsolicited prompts, is the canonical example). Here, there’s no spam. There’s one request, and it looks completely legitimate because the attacker is relaying it live. For a deeper technical breakdown of this relay mechanism against SSO providers, see our guide on how vishing attacks bypass Okta MFA. Both are full compromise. Neither is worse than the other in terms of what you should do next.

If this is your branch:

• Report immediately. Don’t attempt to reset your own password from the same device or session you just used on the call.
• Tell IT/security exactly what you approved and roughly when, including what the login page looked like if you remember it.
• Expect IT/security to treat this as an active identity compromise, not a routine password-reset request. That means full containment, covered below, including a check for any MFA method registered around the time of the call.

You Installed or Authorized Remote Access

This branch doesn’t exist in email-based phishing guides, because it’s specific to a live phone call: a caller who talks you into a screen-share, or into installing a remote-support tool like Quick Assist, AnyDesk, or Zoho Assist, “to fix the issue” or “verify the problem.”

Mandiant’s Google Threat Intelligence Group has documented this exact pattern in an ongoing campaign against U.S. law firms and professional-services firms, attributed to the group tracked as UNC3753 (also known as Silent Ransom Group). The chain runs from a screen-share to an installed remote-access tool, then a pivot into other connected systems, then rapid document harvesting. In the cases Mandiant documented, that sequence completed in under an hour, with extortion emails arriving in some cases within 30 minutes of the attacker disconnecting.

If this is your branch:

• Don’t just uninstall the tool and consider it handled. Removing the software doesn’t tell you whether it was already used to access files or move data, and it can also disturb evidence IT needs.
• Tell IT exactly what tool was installed, when, and what you remember the caller doing or asking you to click while connected.
• For a managed device with endpoint detection and response (EDR) tooling, let IT isolate it through that tooling rather than pulling the network cable yourself. Isolating properly preserves the telemetry that shows what actually happened; yanking the connection can lose it.
• For an unmanaged or personal device, disconnect it from the network and treat it as compromised until someone qualified says otherwise.

Given the documented timeline above, this is not a “get to it after lunch” cleanup task. Treat it with the same urgency as the MFA branch.

You Authorized an App or Moved Money or Data

These two situations need less space here, since their response patterns are already well documented elsewhere.

If you authorized an app or connected service: note its name and publisher if you can recall it, and report it. IT/security will need to review the account’s OAuth and connected-app grants and revoke anything unrecognized.

If you wired funds, bought gift cards, changed banking or payroll details, or sent sensitive files: contact the relevant financial institution immediately, in addition to reporting internally. This branch is more time-sensitive than the identity branches above in a different way; banks and payment processors sometimes have a narrow window to reverse or flag a transaction, and that window is measured in minutes, not the “first hour” this guide is built around.

Locking Down the Account: Sessions and MFA

If your situation involves a compromised identity (the MFA/live-login branch, or any branch where credentials or a session may have been exposed), there’s one correction worth stating plainly, because it’s the single most consequential gap in common advice: resetting your password does not remove an attacker who’s holding a live session or who has registered their own MFA method. Sessions and access tokens need to be explicitly revoked, and any MFA method added around the time of the call needs to be found and removed. Skip those steps, and a password reset only gives the attacker a new password to go with the access they already have.

In practice, IT/security’s containment checklist covers:

• Explicit session and refresh-token revocation, separate from and in addition to the password reset
• A review of registered MFA methods and devices for anything unfamiliar
• An audit of mailbox rules, forwarding settings, and OAuth/connected-app consent grants, since attackers commonly use these for persistence after the initial access

Our phishing link recovery guide covers this containment work in detail already, walking through the session-revocation and persistence-check mechanics branch by branch. Treat this section as the summary and that guide as the reference for exactly how each step is done.

Mistakes That Give the Attacker More Time

A few patterns show up repeatedly in these incidents, and each one hands the attacker more of the window this guide is about:

• Continuing the call to “figure out what they actually want.” By the time you’re wondering that, you’ve already told them more than you meant to.
• Calling back on a number the caller provided, thinking it confirms or denies their legitimacy. It confirms nothing; it’s their number.
• Hiding that it happened, or downplaying it, to avoid looking careless. The delay this creates is exactly what a fast-moving attacker is counting on.
• Uninstalling a remote-access tool without telling IT first. It feels responsible. It actually removes evidence before anyone’s had a chance to look at it.
• Waiting for a clearer signal before reporting, especially when the pretext itself explained away any doubt. The BlackFile campaign’s “mandatory migration” story is designed to do exactly this: give you a reason to dismiss anything that feels wrong afterward.
• Treating “nothing seems to have happened yet” as proof nothing will. Given how fast these campaigns move once access is established, “nothing yet” is not the same as “nothing coming.”

Confirming the Access Is Actually Gone

Containment isn’t done the moment the obvious symptom disappears. Before considering this closed, confirm:

• Active sessions and recent sign-in activity have been checked after revocation to confirm it actually took effect
• No unrecognized MFA method remains registered on the account
• Any remote-access tool has been fully removed and the endpoint checked for what it accessed while installed
• OAuth grants and mailbox rules are clean, if either was in play
• Monitoring continues for a defined window afterward rather than stopping the moment the immediate symptom clears

Rehearsing This Before It Happens for Real

Everything above assumes you already recognized, mid-call or shortly after, that something was wrong. That recognition is the hinge the entire first hour depends on, and it’s not something you can count on happening automatically under real pressure, on a real call, from someone who sounds exactly like they’re supposed to.

Brightside’s AI vishing simulator is built to make that recognition automatic before it matters. It runs live, adaptive phone calls using the same categories of pretext described throughout this guide: an urgent IT/security migration, an MFA reset request, a remote-access ask. Employees practice noticing and hanging up under conditions that resemble the real thing rather than a slide about what vishing is. Voice Attack mode runs the call alone; Hybrid Attack pairs it with a tracked phishing email, matching how attackers increasingly combine channels. Custom voice cloning is self-service, so a team can rehearse against a familiar-sounding voice, such as a manager’s or an executive’s, rather than a generic actor. For the broader, organization-wide training program this rehearsal sits inside, see our complete guide to training employees against AI voice scams.

The other half of the equation is making the report itself frictionless. Brightside’s Report Phishing add-on for Gmail and Google Workspace is a useful illustration of what that should feel like: one click, encrypted delivery to the security team, no guessing which inbox or ticket queue to use. The add-on itself handles reported email rather than phone calls, but the underlying idea, an internal reporting channel with zero friction and zero guesswork, applies just as much to “I think I just got vished” as it does to a suspicious email. If your organization’s vishing reporting path takes more thought than that, closing that gap does more for your first-hour response than almost anything else in this guide.

Brightside trains and rehearses. It doesn’t detect, block, or respond to a vishing call in progress, and it isn’t part of the technical steps your IT/security team runs once a call has already succeeded. What it changes is how quickly someone recognizes they’re in this guide’s territory in the first place, which is the one variable that determines how much of the first hour you actually get to use.

Vishing Response FAQs

What if I’m not sure whether the call was actually a vishing attempt?

Report it anyway, through your real reporting channel. A false alarm costs a few minutes of someone’s time. A real one that goes unreported costs the containment window this guide is built around. Let IT/security make the determination; that’s their job, not yours.

Is approving an MFA prompt during a phone call worse than typing my password into a fake page?

They’re different mechanisms, not different severities. Live-relayed credential theft and a phone-guided MFA approval both end with the attacker authenticated as you. Both call for session revocation and an MFA-method check in addition to a password reset.

What should I do if I already uninstalled the remote-access tool before telling IT?

Tell IT anyway, including what was installed and roughly when it happened. Uninstalling the tool doesn’t tell anyone whether it was used to access or move something first, and that’s exactly what IT needs to check.

How long does it realistically take an attacker to act after a successful vishing call?

In documented campaigns, theft has occurred in under an hour, with extortion sometimes arriving within 30 minutes of the attacker disconnecting. Treat the first hour as the window that matters, not “sometime today.”

Should I still report it if nothing seems to have happened afterward?

Yes. The absence of an obvious symptom isn’t proof that nothing happened; it’s often just proof that no one’s checked yet. Reporting is what lets IT/security actually verify that, instead of you guessing.