On this page
A caller says your bank account is being emptied and asks you to read out a one-time code to stop it. A search advertisement takes you to a familiar payroll login. A message opens a genuine provider’s permissions screen and asks you to approve an unfamiliar app. These incidents require different containment steps, even though each can begin with a convincing impersonation.
Stop using the contact details supplied in the suspicious message. Reach the institution through its verified app, saved address or independently obtained telephone number, report the incident and secure the affected access from a trusted device. If a payment has left, request the available fraud response immediately; changing a password alone does not recall a transfer or necessarily terminate every form of access.
The FBI’s 2025 IC3 report, pages 7–8, records 191,561 phishing/spoofing complaints and $215,843,126 in associated reported losses. Phishing/spoofing was the largest named crime category by complaint count. These figures are not the total cost of every incident that started with phishing: an ensuing fraud may be classified under a different primary crime type.
Identify what the attacker actually obtained
The word “hacked” is too broad to guide a response. Record what you entered, approved or installed and what changed afterwards. Do not return to a malicious page to recreate the event. Existing browser history, messages and provider logs can help establish the sequence without exposing the account again.
| What happened? | Evidence to preserve | Containment issue to raise |
|---|---|---|
| You entered credentials on a counterfeit login page | Full URL, message or advertisement, time, browser history and password-reset notices. | Reset exposed credentials, address reuse and review active sessions through the genuine provider. |
| You disclosed a code or approved an unexpected authentication request | Code notification, call or chat timeline, login alerts and account-change records. | Report that authentication was induced; review devices, sessions and recovery settings. |
| You granted an unfamiliar application access | Application name or identifier, consent time, permissions and available audit logs. | Revoke the application or token permissions; a password change alone may leave access intact. |
| You installed remote-access software | Installer source, application name, connection times and affected-device details. | Contain remote access with competent help; preserve relevant records before destructive cleanup. |
| Your phone service unexpectedly stopped | Carrier notices, service-loss time and subsequent reset or login events. | Contact the carrier independently and investigate a possible SIM change alongside account security. |
Why fake bank support can defeat a normal security routine
A fraudster may know your name, recent details or the appearance of a genuine bank alert. Caller ID can be spoofed. The demand is often framed as protection: “cancel this transaction”, “verify the investigation” or “move funds to safety”. The code you are asked to read may actually approve a login, password reset or new payment.
The FBI’s 25 November 2025 account-takeover alert describes financial-institution impersonation, fake websites and stolen authentication codes. It recommends independent contact with the institution and rapid reporting of fraudulent transfers. Its contemporaneous figures differ from the later annual report’s account-takeover snapshot; they should not be joined into a year-on-year comparison or treated as identical populations.
Keep MFA enabled, but do not approve unexpected prompts or share codes with an incoming caller. The presence of MFA on an account does not prove that the account cannot be compromised. For business payment instructions, use an established verification process and a known contact, especially after changed bank details; our invoice-fraud response guide covers that separate workflow.
A legitimate login screen can still lead to malicious access
The FBI’s 1 September 2026 consent-phishing alert adds an important distinction to the 2025 report. An attacker-controlled application may direct a user to a real provider’s authorization page. The problem is then the permissions granted to the app, rather than a counterfeit password field. Access can persist through an authorization token after the user changes their password.
Check the application’s identity, requested permissions and business purpose before granting access. After suspected consent phishing, ask the provider or your security team to identify and revoke the malicious application access and assess the affected data. Preserve the consent and audit records where available. Removing a suspicious email while leaving the authorization in place does not address this mechanism.
This is a later alert, checked for the current guidance in this article; its campaign observations are not added to the report’s 2025 complaint totals.
Contain the incident without losing the timeline
- Reach the real institution. Report which account or payment is affected, what you disclosed and when. Ask what immediate restrictions and recall or reversal processes are available. Keep the case reference.
- Secure the access path. From a trusted device, address exposed passwords, recovery settings, sessions and malicious application permissions. If a corporate device or account is involved, coordinate with the security team rather than resetting everything independently.
- Preserve existing records. Keep original messages, native emails with headers, login alerts, transaction records and relevant logs. Avoid deleting the account or factory-resetting a device before considering necessary evidence preservation.
- Check connected services. A compromised email account may allow resets elsewhere. Review payment beneficiaries, withdrawal addresses, forwarding rules and recovery details relevant to the incident.
- Report accurately. Use the official complaint and law enforcement channels that apply. Separate confirmed unauthorized actions from suspicious activity still being investigated.
Urgency does not require a finished forensic report before notifying the bank. Give the essential identifiers first, then supplement the record. Conversely, a rapid notification should not become a substitute for preserving the evidence needed to examine responsibility later.
An authentication event does not settle responsibility
A record showing a correct password or code was used establishes an authentication event. It does not, by itself, explain who operated the account, what the customer was told, whether the payment instruction was altered or what controls the provider applied. A useful evidence file compares the customer’s account, the attacker’s messages and the institution’s records on one timeline.
Distinguish a payment the customer personally made under deception from a transfer initiated after unauthorized access. Also distinguish the bank payment from any later conversion into cryptocurrency. These facts can affect the analysis of consent, causation and available remedies, but no automatic refund entitlement follows from the label “phishing”. The applicable law, contract, payment type and conduct of the parties require separate assessment.
If the trail reaches a Turkish bank, exchange or other Turkey-connected asset, the legal and forensic recovery framework explains the next questions. For an overseas IC3 submission, use our international reporting guide; reporting does not itself freeze an account.
Sources and data limits
Primary sources: 2025 IC3 Annual Report, pages 7–8, 12 and 59–62; the official account-takeover alert; employee self-service website impersonation alert; and the 2026 consent-phishing alert. Sources checked on 20 October 2026. Complaint categories and descriptors are explained in our full IC3 statistics analysis. These records describe reported incidents, not global prevalence or the legal outcome of an individual claim.
