FBI seizes domain storing bank credentials stolen from U.S. victims

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
910
4,299
2,168
Germany
The U.S. government has seized the 'web3adspanels.org' domain and the associated database used by cybercriminals to host bank login credentials stolen in account takeover attacks.

Cybercriminals collected the credentials in phishing campaigns targeting American citizens through fraudulent ads on Google and Bing search services that led to fake banking portals.

The confirmed financial loss from this activity is estimated at $14.6 million. However, the FBI has determined that the attempted losses through this scheme were around $28 million.
Full Story:
 
  • Like
Reactions: Sorrento
Full Story:
Domain seizures like this are good disruption, but they don’t automatically “undo” the harm—if credentials were already harvested and sold/used, victims still need to take defensive steps.

What this case shows (based on your quoted excerpt)
  • The attackers weren’t relying on malware as much as credential theft: search ads (Google/Bing) → fake bank portals → victims enter logins → credentials stored in a backend database.
  • “Confirmed losses” vs “attempted losses” is a common split in fraud reporting: many transactions are blocked/reversed, but the intent and attempts still indicate scale.
  • Seizing the domain/database typically means law enforcement took control of the infrastructure to stop ongoing collection and to support identification of victims/suspects. It does not guarantee every victim can be identified quickly, or that stolen credentials weren’t copied elsewhere earlier.

Why “search ads” are a recurring problem
  • Sponsored results can look more “official” than organic results, especially on mobile.
  • Attackers often use convincing lookalike domains and carefully cloned login pages.
  • Even if an ad platform removes one campaign, new domains and ads can be spun up quickly.

Practical safety steps to recommend to users
If someone thinks they clicked a “bank” search ad recently, the safest response is to assume credentials may be compromised and act fast:

  • Use a known-good path to your bank: type the address from a saved bookmark, or use the official mobile app (not a search result).
  • Change your bank password immediately (and any other site where the same or similar password was used).
  • Enable strong MFA where available. Prefer app-based prompts/TOTP or hardware keys over SMS when the bank supports it.
  • Review account activity (transactions, payees, external transfers, contact info changes). Add alerts for transfers/login events if your bank offers them.
  • Contact the bank’s fraud department if anything looks off—time matters more than “proving” it first.
  • Consider a password manager to reduce phishing success (it often won’t autofill on lookalike domains).
  • Harden the browser: an ad/tracker blocker can reduce exposure to malvertising/phishing ads, but it’s not a guarantee.

If the user’s device might also be at risk
This particular flow sounds primarily credential-phishing, but it’s still reasonable to:
  • Run a scan with a reputable AV already installed (and optionally a second-opinion scanner).
  • Check browser extensions for anything unexpected and remove suspicious ones.

Key takeaway
Even with infrastructure seizures, users should treat any “bank login via search ad” event as a high-risk credential exposure and rotate credentials + secure the account through official channels as the priority next step.
 
  • Like
Reactions: Sorrento
Domain seizures like this are good disruption, but they don’t automatically “undo” the harm—if credentials were already harvested and sold/used, victims still need to take defensive steps.

What this case shows (based on your quoted excerpt)
  • The attackers weren’t relying on malware as much as credential theft: search ads (Google/Bing) → fake bank portals → victims enter logins → credentials stored in a backend database.
  • “Confirmed losses” vs “attempted losses” is a common split in fraud reporting: many transactions are blocked/reversed, but the intent and attempts still indicate scale.
  • Seizing the domain/database typically means law enforcement took control of the infrastructure to stop ongoing collection and to support identification of victims/suspects. It does not guarantee every victim can be identified quickly, or that stolen credentials weren’t copied elsewhere earlier.

Why “search ads” are a recurring problem
  • Sponsored results can look more “official” than organic results, especially on mobile.
  • Attackers often use convincing lookalike domains and carefully cloned login pages.
  • Even if an ad platform removes one campaign, new domains and ads can be spun up quickly.

Practical safety steps to recommend to users
If someone thinks they clicked a “bank” search ad recently, the safest response is to assume credentials may be compromised and act fast:

  • Use a known-good path to your bank: type the address from a saved bookmark, or use the official mobile app (not a search result).
  • Change your bank password immediately (and any other site where the same or similar password was used).
  • Enable strong MFA where available. Prefer app-based prompts/TOTP or hardware keys over SMS when the bank supports it.
  • Review account activity (transactions, payees, external transfers, contact info changes). Add alerts for transfers/login events if your bank offers them.
  • Contact the bank’s fraud department if anything looks off—time matters more than “proving” it first.
  • Consider a password manager to reduce phishing success (it often won’t autofill on lookalike domains).
  • Harden the browser: an ad/tracker blocker can reduce exposure to malvertising/phishing ads, but it’s not a guarantee.

If the user’s device might also be at risk
This particular flow sounds primarily credential-phishing, but it’s still reasonable to:
  • Run a scan with a reputable AV already installed (and optionally a second-opinion scanner).
  • Check browser extensions for anything unexpected and remove suspicious ones.

Key takeaway
Even with infrastructure seizures, users should treat any “bank login via search ad” event as a high-risk credential exposure and rotate credentials + secure the account through official channels as the priority next step.
Good job on the recommendation for remediation @Bot .

You could add this as well.

Monitor IC3 Trends: Users should remain aware that over 5,100 bank account takeover complaints have been filed since January, with total losses exceeding $262 million.
 
  • Like
Reactions: Sorrento
Good job on the recommendation for remediation @Bot .

You could add this as well.

Monitor IC3 Trends: Users should remain aware that over 5,100 bank account takeover complaints have been filed since January, with total losses exceeding $262 million.
You can add it, but I’d word it carefully and with an exact time window + attribution, because “since January” is ambiguous (January which year) and those totals can change.

Suggested (safer) phrasing to add
  • Monitor IC3 / FBI trends: IC3 reporting indicates a sustained rise in bank account takeover complaints and losses. If you cite figures (e.g., “5,100+ complaints” and “$262M+ losses”), include the specific reporting period (for example: “since January 2025” or “January–November 2025”) and cite the IC3/FBI source document so readers can verify the numbers.

Why this wording matters
  • It avoids accidentally presenting a moving/updated statistic as a fixed fact.
  • It prevents confusion for readers viewing the thread months later.

Next step
If those numbers are in the BleepingComputer article or in an IC3/FBI bulletin, quoting them with the exact date range (and source name) will make the post stronger and future-proof.
 
You can add it, but I’d word it carefully and with an exact time window + attribution, because “since January” is ambiguous (January which year) and those totals can change.

Suggested (safer) phrasing to add
  • Monitor IC3 / FBI trends: IC3 reporting indicates a sustained rise in bank account takeover complaints and losses. If you cite figures (e.g., “5,100+ complaints” and “$262M+ losses”), include the specific reporting period (for example: “since January 2025” or “January–November 2025”) and cite the IC3/FBI source document so readers can verify the numbers.

Why this wording matters
  • It avoids accidentally presenting a moving/updated statistic as a fixed fact.
  • It prevents confusion for readers viewing the thread months later.

Next step
If those numbers are in the BleepingComputer article or in an IC3/FBI bulletin, quoting them with the exact date range (and source name) will make the post stronger and future-proof.
 
  • Like
Reactions: Sorrento
You can add it, and now we can anchor it to the exact FBI/IC3 source + date so it’s not ambiguous.

Suggested add-on text (ready to paste)
  • Monitor IC3 / FBI ATO trends: In an IC3 Public Service Announcement (Alert: I-112525-PSA, dated November 25, 2025), the FBI says that since January 2025 IC3 has received more than 5,100 account takeover (ATO) complaints, with reported losses exceeding $262 million. (Source: IC3 PSA “Account Takeover Fraud via Impersonation of Financial Institution Support”.)

Minor wording note
That PSA is about ATO via impersonation of financial institution support (and it also mentions SEO poisoning/ads), so it fits well as a broader “this is a widespread trend” datapoint alongside the domain-seizure story.