What to Do If You Clicked a Phishing Link: A Step-by-Step Recovery Guide

If you have just clicked a phishing link, stop interacting with the page. Do not enter more information, approve a sign-in, download a file, paste a command, or call a number shown on the page.

Then take these immediate actions:

1. Report it now. If this happened at work, contact IT or security through your approved reporting channel. Do not wait for symptoms.

2. Write down exactly what happened. Include the time, device, browser, message sender, information entered, prompts approved, and anything downloaded or run.

3. Preserve the message. Do not delete the email or chat. The original content, link, and headers help responders find other recipients and block the campaign.

4. Use a known-clean device for sensitive changes. If you downloaded a file or ran a command, do not reset passwords on the potentially affected device.

5. Follow the correct branch below. Clicking a link, entering a password, granting access, and executing code require different responses.

Speed matters, but panic does not help. Verizon's 2025 Data Breach Investigations Report put the median time to click a phishing link at 21 seconds and the median time to report at 28 minutes. That gap gives an attacker time to use stolen access. Early reporting can turn a serious attempt into a contained event.

What You’ll Learn

• How to judge the likely exposure based on what happened after the click

• What the person who clicked should do during the first 30 minutes

• How IT should contain affected accounts, sessions, mailboxes, and devices

• Why changing a password may not remove an attacker

• How reporting workflows and realistic training can shorten the next response

First, Identify What Happened After the Click

The phrase “clicked a phishing link” covers several technically different incidents. Before choosing a remedy, identify the last action that occurred. When in doubt, report the more serious branch. A responder can reduce the scope after reviewing the evidence.

The page loaded, but you entered nothing

This is usually the lowest-risk branch. A normal page visit can expose your IP address, browser and device details, approximate location, and the fact that the address or phone number behind a uniquely tracked link is active. It may also trigger more targeted messages.

A page view does not normally give an attacker control of a fully patched device by itself. Browser exploits and drive-by downloads exist, but they are not the most likely outcome of an ordinary credential-phishing campaign. Do not assume malware was installed solely because a page appeared.

Close the page, report the message, and tell the responder that you did not type, download, approve, or run anything. Check the browser's downloads list and notification permissions. If a file downloaded automatically, move to the download branch even if you did not open it.

You entered personal, payment, or recovery information

Names, addresses, phone numbers, dates of birth, card details, account numbers, security questions, and recovery codes can support fraud even when no password was entered.

Report the exact fields you submitted. Contact the card issuer or bank through a verified number if payment or banking data was involved. Ask what monitoring, replacement, or transaction controls are appropriate. Change security questions or account recovery details if the same answers protect real accounts. Expect follow-up calls and messages that reference the information you disclosed. Verify new requests through a separate trusted channel.

You entered a username or password

Treat the credential as exposed even if the page displayed an error, you never clicked “Submit,” or you deleted the text before leaving. A malicious page can capture keystrokes or transmit field contents before a form is formally submitted.

From a clean device, go directly to the legitimate service, change the password, and sign out other sessions. If you reused that password anywhere else, change those accounts too, starting with email, identity-provider, password-manager, financial, cloud, and administrator accounts. Tell IT which password was exposed and whether it was used for a work account.

Do not stop at the password change. Session tokens, consent grants, new MFA methods, forwarding rules, and malware can preserve access. The responder checks later in this guide address those paths.

You completed MFA or signed in through the fake page

A convincing page may relay your login to the real service in real time. This adversary-in-the-middle, or AiTM, flow can collect the password, prompt for MFA, and steal the resulting session cookie. The cookie may contain evidence that MFA was already satisfied, allowing the attacker to reuse the session without asking for the password or code again.

This branch requires an immediate password reset and explicit session revocation. Deny any new MFA prompts. IT should review sign-in logs, refresh tokens, registered authentication methods, devices, mailbox activity, and sensitive transactions. Microsoft documented one AiTM campaign in which follow-on payment fraud began as little as five minutes after credential and session theft. That was an observed campaign case, not a universal average, but it shows why reporting cannot wait.

You approved an OAuth app or entered a device code

Some modern phishing flows do not steal a password at all. They persuade the user to grant an app permission to read mail, access files, or act on the user's behalf. Others give the user a device code and direct them to a legitimate sign-in page, where approving the code authorizes the attacker's session.

Changing the password may not remove this access. Report the app name, permissions, code, and screen you saw. IT must revoke the grant or device authorization, revoke sessions, review sign-ins, and inspect activity performed through the authorized app.

A file downloaded or you opened an attachment

A downloaded file is not the same as an executed file. Report both the filename and whether you opened it, enabled macros, mounted an image, installed an application, or bypassed a security warning.

On a managed work device, contact IT and follow its instructions. If the organization uses endpoint detection and response (EDR), responders may be able to isolate the device while keeping it visible for evidence collection. Pulling the network cable or switching off the device too soon can remove that visibility.

On an unmanaged personal device, disconnect from networks if you opened or executed suspicious content, then seek qualified help. Use a different, known-clean device for password changes.

You pasted or ran a command from a “verification” page

Fake CAPTCHA and ClickFix attacks tell users to press a key combination, open the Run dialog or terminal, paste content from the clipboard, and execute it. The page may claim this verifies that the visitor is human, fixes a browser error, or opens a protected document. The command is the infection step.

If you ran such a command, presume the endpoint may be compromised. Stop using it for email, banking, authentication, or password changes. On a managed device, call IT and let the responder isolate it through the approved tooling. On a personal device, disconnect it from networks. The response should include endpoint investigation and may require reimaging under organizational policy.

You clicked the link on a phone

The same decision tree applies on a phone. A page view alone is different from installing an app, approving a configuration profile, entering a password, granting accessibility or device-administration permission, or submitting payment data.

Report the device type and every action taken. Remove suspicious notification permissions. If you installed an app or profile, do not simply delete it and assume the issue is resolved. Work with IT or the platform's official support guidance to review permissions, device management, account sessions, and signs of unauthorized access.

What the Person Who Clicked Should Do in the First 30 Minutes

The employee's job is not to conduct a forensic investigation. It is to stop further interaction, create a precise handoff, and protect exposed access while the security team contains the wider incident.

1. Stop at the last action and do not test the link again

Close the tab. Do not click “unsubscribe,” retry the login, complete another CAPTCHA, or revisit the page to collect screenshots. Do not forward the live link to colleagues over ordinary chat or email. If responders need the URL, they can extract it safely from the original message.

2. Report it through a trusted route

Use the email reporting button, service desk number, security hotline, or incident channel your organization publishes. If the suspicious message contains a phone number for support, do not use it. Look up the internal contact independently.

Say plainly: “I clicked a suspected phishing link.” Add whether you entered credentials, completed MFA, granted app access, downloaded or opened a file, pasted a command, or submitted payment data. Accurate disclosure helps the team choose the right containment steps. It should not be treated as a confession.

The UK's National Cyber Security Centre advises organizations to avoid a blame culture around phishing. Punishing people for clicking discourages reporting and removes one of the earliest warning signals available to defenders.

3. Record a short incident timeline

Capture what you remember without returning to the malicious site:

• When the message arrived and when you clicked

• The sender name and address or phone number

• The device, operating system, browser, and network used

• What the page claimed to be

• Every field you typed into

• Any MFA prompts, app permissions, device codes, or browser permissions approved

• Filenames downloaded and whether they were opened

• Commands copied, pasted, or executed

• Warnings dismissed or security controls disabled

• Any unusual account messages, calls, or transactions afterward

If you already have a safe screenshot, preserve it. Do not delay reporting to create perfect documentation.

4. Protect exposed accounts from a clean device

If you entered a password, use a different trusted device to go directly to the real service. Change the password to a unique one and use the service's option to sign out other sessions. Report the exposure before changing a managed work credential when possible, because the security team may need to coordinate log collection and containment.

Change reused passwords next. Start with the email account that can reset other accounts, then identity providers, password managers, financial services, cloud storage, social media, and work tools. Never follow a password-reset link sent in an unexpected message. Open the real app or type the known address yourself.

5. Respond to financial or identity exposure

If you submitted card or bank details, call the institution using a number from its official app, website, or the back of the card. Ask about blocking the card, reversing pending payments, adding alerts, and monitoring the account.

If you disclosed identity information, recovery codes, tax data, or government identifiers, follow the applicable local identity-theft guidance. Be cautious of “recovery experts” who contact you after the incident. Fraudsters often follow one scam with another.

6. Handle the device according to how it is managed

For a managed endpoint, keep the device available and contact IT. Follow instructions about network connectivity, shutdown, and evidence preservation. EDR-based containment is usually more useful than an employee improvising.

For an unmanaged device on which suspicious code was executed, disconnect it from Wi-Fi, Ethernet, and Bluetooth connections that could expose other systems. Do not use it to reset credentials. A basic antivirus scan may be useful, but a clean result does not prove that an infostealer or unauthorized access never occurred.

What IT and Security Should Do in the First Hour

The responder should treat the employee's report as a starting signal, not as a complete severity assessment. Contain the identity and campaign quickly, preserve evidence, then adjust the scope as facts improve.

1. Establish the facts without blame

Use a short structured intake:

Do not make the employee repeat the story to several teams while the attacker acts. Assign an incident owner, timestamp the known events, and separate confirmed facts from assumptions.

2. Preserve and neutralize the phishing message

Acquire the original message with headers, URLs, attachments, sender information, and delivery metadata. Preserve it according to the organization's evidence policy. Do not rely only on a screenshot.

Search the mail environment for matching sender addresses, domains, subjects, URLs, attachment hashes, reply-to values, and message identifiers. Identify delivered messages, recipients, clicks, reports, and removals. Block relevant indicators and purge confirmed malicious messages where tooling and policy permit.

Check whether the compromised account sent the same lure internally or externally. A trusted account can give the campaign a second wave with much higher credibility.

3. Contain the identity, not just the password

For exposed credentials, reset the password and revoke active sessions and refresh tokens. These are separate actions. Confirm that revocation covers browser, desktop, mobile, and application sessions relevant to the identity provider.

Then review:

• Recent successful and failed sign-ins, source IPs, locations, user agents, devices, and authentication details

• Risk detections, impossible-travel signals, unusual token use, legacy authentication, and new applications

• Registered MFA methods, phone numbers, passkeys, security keys, recovery codes, and trusted devices

• OAuth and enterprise-app consent grants, especially mail, files, contacts, directory, and offline access

• Newly assigned roles, group memberships, delegated permissions, and application credentials

• Password resets, recovery-detail changes, and help-desk interactions

Do not automatically dismiss a sign-in because it used MFA. In an AiTM incident, a stolen cookie can represent an already authenticated session.

4. Check the mailbox for persistence and fraud preparation

Compromised email accounts are valuable because they contain conversations, invoices, password resets, and the social context needed for business email compromise.

Microsoft's compromised-email remediation guidance recommends reviewing mailbox settings in addition to resetting credentials and revoking sessions. Check for:

• Inbox rules that delete, move, mark as read, or hide messages in Junk, RSS, Notes, Archive, or another folder

• External forwarding at the mailbox, SMTP, transport-rule, and tenant levels

• Delegated mailbox access and send-as or send-on-behalf permissions

• Changed signatures, automatic replies, contacts, and safe-sender lists

• Suspicious messages in Sent, Deleted, Drafts, and hidden or rarely viewed folders

• Searches for invoices, payroll, banking details, password resets, customer data, or executive conversations

Remove confirmed malicious persistence and record what was found before changing it. Look for conversations in which the attacker altered payment instructions or attempted to move a discussion to a private channel.

5. Isolate and investigate affected endpoints

If the user only viewed a credential page and entered nothing, endpoint isolation may not be necessary. If a file was opened, a command ran, a security warning was bypassed, or telemetry shows suspicious execution, isolate the endpoint through EDR.

Review browser downloads and history, process trees, script interpreters, command-line activity, persistence mechanisms, new services, scheduled tasks, browser extensions, credential-store access, outbound connections, and security-control tampering. Hunt for infostealer behavior and determine whether credentials, cookies, browser databases, wallet data, or files were collected.

Extend the hunt to other endpoints and identities when the same indicators appear elsewhere. Unit 42's 2026 incident-response research reported that the fastest quarter of investigated intrusions reached data exfiltration in 72 minutes. That dataset is not a universal clock for every company, but it supports fast containment when execution or valid-account abuse is plausible.

Cleaning versus reimaging should follow evidence, device criticality, and organizational policy. Confirmed execution by an infostealer often justifies a rebuild and broader secret rotation. A page view with no execution does not automatically justify wiping a device.

6. Scope business and data impact

Identity and endpoint containment are not the end of the investigation. Determine what the attacker could access and what actions occurred:

• Email, file, chat, CRM, source-code, HR, payroll, and financial systems reached

• Messages read, searches performed, and files viewed or downloaded

• New forwarding, sharing, delegation, or public links created

• Payments, bank-detail changes, gift-card requests, or password resets initiated

• Other employees, customers, vendors, or partners contacted

• Privileged actions or lateral movement attempted

• Regulated, contractual, personal, or confidential data exposed

Validate sensitive requests out of band using a known number or an established business process. Do not rely on the potentially compromised mailbox to confirm its own instructions.

Notify finance, legal, privacy, leadership, insurance, affected partners, or law enforcement when the evidence and response plan require it. Preserve decision records and reporting deadlines. Avoid declaring a breach before the facts support that conclusion, but do not let terminology delay containment.

Why Changing the Password May Not Remove the Attacker

A password is only one way an attacker can maintain access.

A stolen session cookie can survive the original login. The attacker may replay a browser session in which MFA was already completed. Resetting the password without revoking sessions can leave that session active, depending on the service and token type.

Refresh tokens can generate new access tokens. Revoke refresh tokens and active sessions through the identity provider rather than assuming a password change invalidates everything immediately.

OAuth grants authorize an application. If a user approved a malicious app, remove its consent and credentials. Review what data it accessed and whether it retained offline access.

Device-code phishing authorizes the attacker's device. The user signs in on a legitimate page, but the code belongs to the attacker. Revoke the resulting session and investigate the sign-in rather than treating the legitimate domain as proof that nothing happened.

Attackers can add their own recovery paths. Review MFA methods, phone numbers, passkeys, security keys, devices, app passwords, recovery details, roles, and delegated permissions.

Mailbox rules can keep fraud invisible. An attacker may hide replies, forward mail, or delete warnings while operating through another session.

Malware can steal the new password. If an infostealer remains on the device, resetting a credential from that device can hand the replacement to the attacker.

MFA is still important. The lesson is to choose stronger methods and contain the entire identity. Phishing-resistant FIDO2/WebAuthn security keys and passkeys bind authentication to the legitimate site, making proxy phishing harder than it is with SMS, one-time codes, or approval prompts. Prioritize these methods for administrators, executives, finance teams, developers, and other high-impact roles.

Verify Recovery Over the Next 24 Hours

Containment is a hypothesis until the organization verifies it.

Recheck sign-in activity after session revocation. Confirm that expected devices and applications can authenticate and that suspicious sources cannot. Review new risk signals, user agents, locations, downloads, mailbox actions, and consent events. Keep enhanced monitoring in place for a period proportionate to the exposure.

Confirm that:

• The exposed password is replaced everywhere it was reused

• Active sessions and refresh tokens were revoked

• Only legitimate MFA and recovery methods remain

• Unauthorized app grants, devices, roles, and delegated permissions are removed

• Mailbox rules, forwarding, signatures, and automatic replies are clean

• The endpoint investigation is complete and any rebuild has restored trusted configuration

• Financial instructions and sensitive transactions have been verified independently

• Data access and exfiltration questions have documented answers

• Anyone who received phishing from the account has been warned through a trusted channel

Document the incident timeline, affected assets, evidence, containment actions, owners, and unresolved questions. Record why the team chose to monitor, clean, or reimage the endpoint. If the account sent messages to customers or suppliers, coordinate communications so recipients know which requests to disregard and how to verify future contact.

Common Recovery Mistakes That Give Attackers More Time

Waiting to see whether anything happens. Many account-takeover actions look ordinary at first. Report based on the exposure, not on visible damage.

Hiding the click. Fast, accurate reporting is more useful than a perfect record created too late.

Changing only the password. Sessions, grants, mailbox rules, authentication methods, and malware need separate checks.

Resetting from the affected device. If suspicious code ran, use a known-clean device so the replacement credential is not captured.

Trusting MFA as proof of safety. Review the authentication method and session evidence. Deny unexpected prompts and move high-risk users toward phishing-resistant methods.

Deleting the message. The original email helps responders search, block, purge, and preserve evidence.

Revisiting the malicious page. Employees should not investigate a live URL from production devices.

Immediately disconnecting every managed endpoint. Let IT use EDR isolation when possible so the device remains observable.

Blaming the reporter. A punitive response teaches other employees to stay silent during the next incident.

Reduce the Next Incident’s Time to Report

The goal is not to promise that nobody will click again. It is to make the next suspicious interaction easier to report and faster to contain.

Give employees a one-click reporting route and a short, searchable “I clicked” playbook. When measuring security awareness training effectiveness, track report rate and time-to-report alongside simulation failure rate. A low click rate is less useful if real incidents remain unreported for hours.

Use training at the point of error to explain the specific clue or behavior involved. Rehearse credential phishing, OAuth consent, device-code prompts, fake CAPTCHAs, QR codes, voice calls, and hybrid attacks. Keep exercises psychologically safe and give credit for correct reporting.

Pair human controls with technical ones. Brightside's guide to reducing employee cybersecurity risk exposure makes the same layered case: use phishing-resistant MFA, conditional access, rapid token revocation, restricted user consent, mailbox-forwarding audits, mail filtering, browser and endpoint protection, tested response playbooks, and out-of-band payment verification.

The NCSC's phishing guidance includes a layered-defense example in which 1,800 malicious emails were narrowed to one detected infection through filtering, employee behavior, patching, and monitoring. The useful lesson is not that clicks are harmless. It is that a click does not have to become a major breach when reporting and technical controls work together.

7 Best AI-Powered Cybersecurity Training Platforms for Employees

No training platform can replace identity controls, endpoint security, email defenses, or incident response. For the post-click problem described in this guide, useful selection criteria include realistic AI-era simulations, an easy reporting workflow, adaptive or point-of-error follow-up, program automation, integrations, and clear measurement of reporting behavior.

The following alphabetical shortlist is not a universal ranking. Product packaging changes, and some capabilities depend on plan or integration choices. Verify requirements directly with each vendor.

Adaptive Security

Adaptive Security focuses on social engineering shaped by generative AI. Its public materials describe simulations across email, voice, SMS, and deepfake video, plus personalized learning based on employee role, risk, and behavior. It fits organizations that want executive-impersonation and multi-channel scenarios to sit near the center of the program.

Pros

• Broad AI-era simulation coverage, including voice and deepfake scenarios

• Role- and behavior-based learning paths

• Custom training and simulation creation

Cons

• Buyers should validate which multi-channel and deepfake capabilities are included in the proposed package

• Its AI-threat emphasis may be broader than a compliance-first buyer needs

Brightside AI

Brightside AI is a Swiss security awareness platform with interactive courses, phishing simulations, live AI vishing simulations, and coordinated voice-plus-email scenarios. Its relevant differentiator for this guide is the Report Phishing add-on for Gmail and Google Workspace. It sends the employee-selected message to the security team with original headers, distinguishes reported simulations from real reports, and credits employees who correctly report a test.

Brightside can trigger follow-up training after a failed simulation and track delivery, opening, clicking, credential entry, and reporting. It does not filter inbound mail or perform real-time breach response. Its value is rehearsal and closing the reporting loop.

Pros

• Email, AI vishing, and hybrid simulation workflows

• One-click Gmail reporting tied to simulation results

• Point-of-error follow-up after simulation failures

Cons

• Reporting add-on is centered on Gmail and Google Workspace

• Not an email gateway, endpoint product, or incident-response service

Hoxhunt

Hoxhunt emphasizes adaptive phishing simulations, positive reinforcement, and reporting behavior. Simulations adjust to the participant, while automated remedial approaches can target repeat clickers or employees who are not developing reporting habits. It fits organizations that want an ongoing program with less manual assignment than static campaigns.

Pros

• Adaptive simulation difficulty and personalized learning

• Strong focus on reporting as a positive employee behavior

• Automated remedial-training options

Cons

• Buyers should confirm support for the non-email attack channels in their threat model

• A continuous adaptive program may be more than a basic compliance deployment requires

Keepnet Labs

Keepnet Labs offers a broad human-risk platform that includes phishing simulation, awareness training, email reporting, and incident-response-oriented workflows. Its fit here is the connection between employee reports and security-team handling rather than training in isolation. Organizations considering Keepnet should map its modules and integrations to their existing mail and SOC processes.

Pros

• Broad suite spanning simulation, training, reporting, and human-risk operations

• Multi-channel social-engineering coverage

• Relevant fit for organizations that want reporting and response workflow in the same program

Cons

• A broad modular suite can require careful scoping and implementation

• Feature availability and response depth should be confirmed for the selected package

KnowBe4

KnowBe4 combines a large training library, simulated phishing, risk scoring, reporting tools, and program automation. Its AIDA agents use risk and behavioral data to personalize phishing tests, assign training, and automate remedial actions. This makes KnowBe4 a practical option for large or compliance-heavy programs that want a mature content and administration suite.

Pros

• Extensive localized training and simulation content

• AIDA automation for personalized phishing and remedial training

• Broad reporting, assessment, and human-risk capabilities

Cons

• Packaging is tiered, so buyers need to distinguish included capabilities from add-ons

• The breadth of the platform can be more complex than a small team needs

Proofpoint

Proofpoint Security Awareness combines phishing, SMS, and USB simulations with assessments, adaptive learning, and people-risk information. Its strongest fit is for organizations already using Proofpoint's email-security products, where real attack and privilege context can inform which people receive targeted simulations and training. PhishAlarm supports employee reporting, while risk-based groups and learning paths automate follow-up.

Pros

• Simulations informed by large-scale threat intelligence

• People-risk context based on attacks, behavior, role, and privilege

• Reporting and targeted follow-up integrated with the wider Proofpoint product set

Cons

• The deepest value may depend on other Proofpoint products and integrations

• Buyers should map package differences carefully

SoSafe

SoSafe builds its human-risk platform around behavioral science, personalized training, gamification, and adaptive simulations. Its public product information describes multi-channel simulations, automated monitoring, and delivery in more than 30 languages. It is a strong candidate for European and multinational organizations that need broad accessibility and localized employee experiences.

Pros

• Behavior-science and habit-building approach

• Adaptive simulations and personalized learning

• Broad language support for international workforces

Cons

• Buyers should verify the exact channels, integrations, and residency terms needed for their deployment

• Organizations focused mainly on deep technical incident-response workflows may need complementary tooling