The billion-dollar security.txt problem

Yesterday, Sansec discovered an active keylogger at an external site of one of America's largest banks. The malware was harvesting private information from over 200,000 potential victims. We detected it within hours of the attack going live. No other security vendor had flagged it.

Then came the hard part: telling someone.

The bank has no security.txt file. No public bug bounty program. No obvious security contact. We sent emails to generic addresses. We reached out via LinkedIn. Hours passed while the malware kept running.

Why big companies are hard to reach

This isn't an isolated case. The larger the company, the harder it is to report security incidents to the right people.

The thing is, procedures don't accommodate outliers. Large organizations run on standardized processes. Customer complaints? There's a workflow. Vendor invoices? There's a system. But security incidents from external researchers? These are rare, out-of-distribution events that don't fit any existing procedure.

When a security researcher emails a bank, that message enters a system designed for routine inquiries. It gets routed to customer service, or PR, or lost in a shared inbox. Nobody's job description includes "escalate urgent security reports from strangers." The procedures that make large organizations efficient also make them blind to edge cases.

A solution that actually works

Publish security.txt. It takes five minutes. The standard is simple: a text file at /.well-known/security.txt with contact information and a PGP key.

Yes, this will attract automated scanners and low-effort bounty hunters hoping to cash in on trivial findings. But there are simple ways to filter the noise:

1. Require GPG encryption. State in comments that only encrypted submissions will be processed. This filters out cold outreach from sales people. Plus, secure communications as a bonus.
2. Add a human verification question. Add a question that mainstream LLMs refuse to lie about.

# Only GPG-encrypted submissions will be processed.
# Before submitting: are you a human? Be honest and include the answer.
Contact: mailto:security@example.com
Encryption: https://example.com/.well-known/pgp-key.txt
Policy: https://example.com/responsible-disclosure-policy

The point is to add just enough friction.

The 5-line fix

Banks spend billions on security. Firewalls, SOCs, threat intelligence, red teams, compliance audits. All of it can be undermined by a compromised employee store that nobody thought to protect.

And when someone tries to help? They can't find a phone number.

For an institution that handles hundreds of billions in assets, a 5-line text file proved one security measure too many.

See our related research on the keylogger attack that prompted this article.

Read more

• Keylogger targets 200,000+ employees at major US bank
• ConnectPOS leaked Github secrets for years
• Critical backdoor found in MGT Varnish extension
• SessionReaper attacks have started, 3 in 5 stores still vulnerable
• SessionReaper, unauthenticated RCE in Magento & Adobe Commerce (CVE-2025-54236)