Top 10 Financial Services Cyber Threats: What Attacks Banks and How to Stop Them

Banks, insurers, payment firms and crypto platforms are attacked by people who want money quickly, and most of the losses come from a short list of repeat techniques rather than from novel exploits. This page ranks the ten threats that most often turn into losses, regulatory findings or outages for financial institutions, with a real incident for each where one is documented, what to detect and what to fix first. The ranking is an editorial judgement based on government advisories (CISA, FBI, Europol), regulator expectations (DORA, NYDFS Part 500, the SWIFT Customer Security Programme) and the incidents in the NHI Mgmt Group breach database. It is written for security leads, fraud and financial crime teams, and executives who need a short list to test their programme against. For who is behind these attacks, read the Threat Actors Targeting Financial Services Guide; for the obligations, the Financial Services Cyber Regulation Map.

The Top 10 at a glance

The order weighs how often each threat appears in advisories and incidents against the size of the loss. A crypto exchange will put item 6 higher (signing infrastructure is its payment system); a retail bank will often put item 5 first by volume of cases. Use the list as a starting point for your own threat assessment under NIST CSF 2.0 ID.RA-03 (internal and external threats are identified and recorded), not as a fixed ranking.

1. Help desk and identity social engineering

The threat: attackers phone the IT service desk posing as an employee, ask for a password or MFA reset, and register their own device. Variants include SIM swapping to intercept one-time codes and MFA fatigue (ATT&CK T1621 Multi-Factor Authentication Request Generation). CISA and the FBI's advisory AA23-320A on Scattered Spider describes this exact sequence: help desk impersonation, SIM swaps and push bombing, followed by registering attacker-controlled MFA, adding a federated identity provider, installing legitimate remote management tools and, in some cases, deploying ALPHV ransomware.

Why finance is exposed: large outsourced service desks, high staff turnover in contact centres and pressure to resolve access problems quickly. One reset of a privileged identity gives the attacker the identity provider, and from there every SaaS and cloud console.

What to detect: MFA method registrations from new devices or countries shortly after a help desk ticket; new federation trusts or identity providers added to the tenant; remote management tools appearing on endpoints that do not normally run them (T1219 Remote Access Tools).

How to fix: verify callers through an out-of-band step that does not rely on knowledge an attacker can buy (call back on the HR number, manager approval, or a video check against the badge photo), hold privileged resets for a second approver, and move administrators to phishing-resistant MFA. See the Help Desk Identity Verification Policy Template and the Account Recovery and Help Desk Security Guide.

2. Ransomware and data extortion

The threat: encryption of servers and hypervisors (T1486 Data Encrypted for Impact) combined with theft of data for a leak site. Many groups now skip encryption and extort with stolen data alone. Entry usually comes through valid accounts on VPNs and remote desktop gateways without MFA (T1133 External Remote Services) or an unpatched internet-facing appliance (T1190).

Why finance is exposed: customer services, trading and payments have hard availability expectations, and regulators expect firms to stay within impact tolerances for important business services. A firm that cannot restore identity infrastructure cannot restore anything else.

What to detect: mass file renames, shadow copy and backup deletion, new domain admin group members (T1098 Account Manipulation), bulk outbound transfers to cloud storage before encryption.

How to fix: MFA on every remote access path, immutable and offline backups (NIST SP 800-53 CP-9), separate administration accounts and a rehearsed rebuild of Active Directory and the cloud identity provider. See the Recovering IAM and PAM After Ransomware or Domain Compromise guide and the Ransomware Data Leak Site Listing Playbook.

3. Business email compromise and payment redirection

The threat: a compromised or look-alike mailbox asks finance staff, corporate clients or a supplier to change bank details or approve an urgent transfer. After takeover, attackers create inbox rules to hide replies and send internal phishing from the trusted account (T1534 Internal Spearphishing). Business email compromise has been one of the highest loss categories in every recent FBI Internet Crime Complaint Center (IC3) annual report.

Why finance is exposed: banks are hit twice: as targets (their own treasury and payments teams) and as the receiving bank for funds stolen from their customers, which raises mule account and authorised push payment questions.

What to detect: new inbox forwarding or deletion rules, sign-ins from anonymising infrastructure followed by mailbox searches for "invoice" or "wire", and changes to payee bank details within days of a new email thread.

How to fix: verify every bank detail change by calling a number already on file, require dual approval above a threshold, disable external auto-forwarding, and publish DMARC at p=reject. See the Business Email Compromise Awareness for Finance Teams Guide, the Invoice Redirection and Supplier Bank Detail Fraud Guide and the Authorised Push Payment (APP) Fraud Guide.

4. Deepfake and synthetic identity fraud

The threat: generated voice and video used to impersonate executives on calls, and generated or manipulated identity documents and selfies used to open accounts. In the Arup deepfake fraud, a fake chief financial officer on a video call triggered transfers of HK$200 million. Synthetic identities, built from a mix of real and invented data, are used to open accounts that later act as mules or default on credit.

Why finance is exposed: remote onboarding and remote approvals are now normal, and both rely on a face or a voice that can be faked.

What to detect: payment instructions that arrive through a call or meeting rather than the normal workflow; onboarding sessions with signs of camera injection, reused face images or device fingerprints across many applications; new accounts that receive and forward funds within hours.

How to fix: no payment is authorised on the strength of a call alone; use injection attack detection and liveness checks in remote identity proofing (NIST SP 800-53 IA-12 Identity Proofing); share mule indicators with peers. See the Executive Deepfake and CEO Fraud Guide, the Synthetic Identity Fraud Guide and the Top 10 KYC Bypass Techniques.

5. Account takeover of customers

The threat: credential stuffing with passwords leaked from other sites (T1110.004), infostealer logs that include session cookies, phishing kits that relay one-time codes in real time, and mobile banking trojans that overlay the bank's app. Once inside, attackers add a payee, raise limits and move money, or change the phone number to block recovery.

Why finance is exposed: every customer account holds money or credit, and the bank usually carries refund liability or reputational cost even when the customer was phished.

What to detect: spikes in failed logins from many addresses for many usernames, new device enrolment followed by payee creation, phone number or email changes followed quickly by high-value transfers.

How to fix: offer passkeys, bind sessions to devices, apply step-up authentication on payee changes and limit increases, and check passwords against breach corpora. See the Account Takeover Prevention Guide, the Password Spraying and Credential Stuffing Defence Guide and the Android Banking Trojans Guide.

6. Payment system and SWIFT compromise

The threat: intruders who reach the payment switch, SWIFT interface or core banking system issue fraudulent messages or approve fraudulent card transactions (T1657 Financial Theft). CISA advisory AA20-239A on the North Korean BeagleBoyz describes FASTCash attacks on payment switch application servers since 2016, enabling simultaneous ATM cash-outs in more than 30 countries in one incident, and SWIFT abuse including the 2016 theft of 81 million US dollars from Bangladesh Bank. Europol reports that the Carbanak and Cobalt campaigns hit more than 100 financial institutions in 40 countries for losses of around one billion euros. For crypto platforms the equivalent is the signing path: the Bybit hack of February 2025, attributed by the FBI to North Korea's TraderTraitor activity, took around 1.5 billion US dollars after a developer's cloud session tokens were abused to tamper with wallet software.

What to detect: payment messages outside business hours or normal corridors, logins to payment servers from non-jump hosts, changes to transaction authorisation logic, and mismatches between messages sent and the bank's own confirmations.

How to fix: AA20-239A recommends MFA on payment switch servers, isolating payment infrastructure, mutual TLS to payment engines, logging and baselining switch transactions, and validating card cryptograms (ARQC and ARPC). SWIFT users must meet the mandatory Customer Security Controls Framework and attest annually. See the Crypto exchange breaches guide for the signing-path lessons.

7. Third-party and supply chain compromise

The threat: attackers compromise a managed service provider, software supplier, data platform or outsourced operations team and use that trusted access to reach many firms at once (T1199 Trusted Relationship, T1195 Supply Chain Compromise). In the Snowflake breach, credentials stolen by infostealers from accounts without MFA unlocked data warehouses at around 165 customer organisations.

Why finance is exposed: heavy concentration on a few cloud, core banking and market data providers. The EU Digital Operational Resilience Act (DORA) responds to this with a register of information on ICT third-party arrangements and direct oversight of designated critical ICT third-party providers; the European Supervisory Authorities published the first list of designated providers in November 2025.

What to detect: supplier accounts logging in outside contracted hours or from new locations, data exports by integration users, and dormant supplier accounts becoming active.

How to fix: MFA and network restrictions on every supplier and integration account, contract clauses for incident notification, exit plans for critical services, and inventory of every connection (NIST SP 800-53 SA-9 External System Services, SR-3). See the Third-Party Risk Management Guide and the Top 10 Third-Party Risk Mistakes.

8. Cloud misconfiguration and leaked machine credentials

The threat: over-privileged workload roles, exposed storage, and API keys or access keys in code repositories. In the Capital One breach, an attacker obtained temporary credentials for the role a web application firewall ran under (commonly attributed to request forgery against the instance metadata service, T1552.005) and copied data on about 106 million people from cloud storage (T1530). The Office of the Comptroller of the Currency imposed an 80 million US dollar civil money penalty in August 2020, citing weaknesses in cloud risk management.

Why finance is exposed: fast cloud migration, many integration and automation identities, and data sets that are valuable to resell. Machine identities often outnumber staff and are reviewed less.

What to detect: workload roles reading storage they have never read before, access keys used from outside the organisation's networks, and secrets detected in commits.

How to fix: least privilege for every workload role (AC-6), enforced session-based metadata access (IMDSv2 on AWS), short-lived federated credentials instead of static keys, and secret scanning with automatic revocation. See the Financial Services Identity Security Guide and the Top 10 NHI Risks.

9. Insiders, bribed staff and fake IT workers

The threat: employees or contractors who copy customer data, enable fraud or are paid by criminals for access, and remote workers hired under false identities. In the Coinbase insider breach, bribed overseas support agents exposed data on 69,461 customers, which was then used for impersonation scams. North Korean IT worker schemes place fake remote staff in technology roles, including at financial firms.

What to detect: support or operations staff viewing many customer records with no matching ticket, bulk exports and uploads to personal cloud storage (T1567 Exfiltration Over Web Service), and new hires whose devices connect through remote access tools or laptop farms.

How to fix: limit support tools to the record in the active case, mask sensitive fields, monitor for volume anomalies, and verify identity at hiring with in-person or strong remote checks (PS-3 Personnel Screening, PM-12 Insider Threat Program). See the Top 10 Insider Threat Indicators and the Insider Threat from Fake IT Workers Guide.

10. DDoS against customer-facing services

The threat: volumetric and application-layer floods (T1498 Network Denial of Service, T1499 Endpoint Denial of Service) against online banking, trading platforms, DNS and APIs, often by hacktivist groups reacting to political events, sometimes as cover or as extortion.

Why finance is exposed: customers notice within minutes, outages are reportable incidents in many regimes, and hacktivist groups such as NoName057(16) publicly list banks as targets.

What to detect: traffic and request rate against baselines per endpoint, error rates and latency on login and payment APIs, and upstream provider alerts.

How to fix: an always-on or on-demand scrubbing service for critical services, rate limiting on login and search endpoints, resilient DNS, and a rehearsed playbook with the provider (SC-5 Denial-of-service Protection). See the DDoS Protection Guide and the NoName057 DDoS Hacktivist Group Profile Guide.

Detection and measurement

Most of the ten threats leave signals in three places: the identity provider, payment and transaction systems, and the email platform. Join them up, because fraud teams and security operations often watch different halves of the same attack.

Metrics that show the programme is working:

• Phishing-resistant MFA coverage: share of privileged and payment-approving staff on FIDO2 or smart card authentication (target 100%).
• Help desk verification compliance: share of sampled resets that followed the full verification procedure.
• Bank detail change verification rate: share of payee changes confirmed by call-back to a number on file.
• Time to revoke: median hours from leaked secret or compromised account detection to revocation.
• Restore time for identity services: measured in the last recovery exercise, against the impact tolerance.
• Supplier accounts with MFA: share of third-party and integration accounts with MFA or workload federation.

Common failure patterns

• Fraud and cyber in separate silos: the fraud team sees the payee change and the security team sees the MFA reset, and neither connects them until the money has gone.
• MFA everywhere except where it matters: exemptions for service desk staff, outsourced operations or a supplier's integration account. The Snowflake incidents turned on accounts without MFA.
• Payment approvals that trust a voice: dual control that can be satisfied by one convincing call or video meeting, as Arup showed.
• Machine credentials outside governance: long-lived cloud keys and over-privileged workload roles that never appear in access reviews, the Capital One pattern.
• Support tools with full customer search: any agent can look up any customer, so a bribed agent can harvest thousands of records, as in the Coinbase case.
• Recovery plans that assume identity works: backups exist but cannot be restored because the directory and the privileged access tool were encrypted too.

Mapping to frameworks

The NIST CSF financial sector profile maintained by the Cyber Risk Institute maps many of these controls to sector regulations in one place: see the NIST CSF Financial Sector CRI Profile Guide.

Where to start

1. First 30 days: lock down the help desk reset process for privileged and payment-approving staff, disable external mail auto-forwarding, and confirm every remote access path and supplier account requires MFA.
2. Days 30 to 90: put phishing-resistant MFA on administrators and payment approvers, enforce call-back verification for bank detail changes, and inventory cloud workload roles and static access keys.
3. Days 90 to 180: join fraud and security telemetry for the signals in the detection table, run a ransomware recovery exercise that starts with rebuilding identity, and test the payment systems against the AA20-239A mitigations or the SWIFT framework.
4. Ongoing: review this list each year against your own incidents, sector threat intelligence and supervisory findings, and re-rank it.

Small firms (credit unions, brokers, payment start-ups) should start with items 1, 3 and 7: they cost little to fix and cause most of the losses. Large banks will have controls for all ten; their gaps tend to be in coverage, such as outsourced desks, legacy payment systems and machine identities.

Practitioner checklist

• Help desk resets for privileged and payment roles need out-of-band verification and a second approver.
• Administrators and payment approvers use phishing-resistant MFA; no undocumented MFA exclusions remain.
• Every bank detail change is verified by call-back to a number already on file.
• No payment is authorised on the strength of a call or video meeting alone.
• Customer authentication offers passkeys and steps up on payee and limit changes.
• Payment switch and SWIFT infrastructure is isolated, logged and baselined, with MFA for access.
• Every supplier and integration account has MFA or federation, an owner and an expiry.
• Cloud workload roles are least privilege; static keys are inventoried and being replaced.
• Support tools restrict agents to records in their active case, with volume alerts.
• Identity infrastructure recovery has been rehearsed within the last year.

Standards and references

• CISA and FBI: Scattered Spider advisory AA23-320A
• CISA: FASTCash 2.0, North Korea's BeagleBoyz Robbing Banks (AA20-239A)
• FBI: North Korea Responsible for 1.5 Billion Bybit Hack
• Europol: Mastermind behind EUR 1 billion cyber bank robbery arrested in Spain
• SWIFT: Customer Security Programme
• New York DFS: Cybersecurity Resource Center
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Threat Actors Targeting Financial Services Guide · Financial Services Identity Security Guide · Banking Cybersecurity Programme Guide · Financial Services Cyber Regulation Map · Top 10 Identity Attacks