On June 4, 2026, a small BSC token called ATM was exploited for $243,500 through a hidden swap logic vulnerability in its transferFrom() function. This is not a flash loan attack. Not a reentrancy exploit. It's something more insidious — a backdoor hidden inside standard token mechanics.
The Vulnerability
What transferFrom() Should Do
User A approves → User B calls transferFrom(A→C) → Tokens transferred. Done.
What ATM's transferFrom() Actually Does
User A approves → User B calls transferFrom(A→C) →
→ 80% tokens sent to C
→ 20% AUTO-SWAPPED to BSC-USD via DEX router
→ Attacker extracts the swapped value
Every single call to transferFrom() triggered a hidden 20% swap. The attacker simply called the function repeatedly, each time extracting extra value through this unintended mechanism.
Attack Details
| Item | Detail |
|---|---|
| Token | ATM (BSC) |
| Contract | 0x4fd0878ee1bbf7b1019138e8eec746e5a5d5a205 |
| Attacker | 0x7e7C1f0D567c0483f85e1d016718E44414CdBAFE |
| Loss | ~$243,500 |
| Type | Hidden swap logic / economic side-channel |
This Isn't the Attacker's First Time
The attacker address 0x7e7C1f... has been active since 2025 and specifically targets small tokens with custom swap/tax/fee logic:
| Project | Date | Loss | Vulnerability |
|---|---|---|---|
| ATM Token | 2026-06-04 | $243,500 | Hidden swap logic |
| DxSale | 2026-05-29 | $7,300,000 | Permission override |
| TesseraDAO | 2026-06-02 | $2,500,000 | Unauthorized minting |
This is a systematic attacker — an APT-like operator specializing in custom token logic exploits on BSC.
Zero Transparency = Zero Accountability
The ATM project had:
- ❌ No website
- ❌ No whitepaper
- ❌ No security audit
- ❌ No team information
- ❌ No post-exploit statement
As of this writing, the team has said nothing. Funds have not been recovered.
The BSC Systemic Problem
BSC has a structural issue:
Low barrier to deploy → No audit requirement → Custom token logic → Exploit → User loss → No accountability
Tokens with custom swap/tax/fee logic and hidden backdoors are deployed daily on BSC with zero oversight. Each one is a ticking time bomb.
How to Protect Yourself
-
Check the contract — Read
transferFrom()andtransfer()for hidden logic - Use token scanners — TokenSniffer, Honeypot.is, GoPlus Security
- Verify audits — Legitimate projects have public audit reports
- Revoke approvals — Use Revoke.cash regularly
- Avoid unaudited tokens — No audit = no accountability
Technical Deep Dive
The core issue: ERC-20's transferFrom() is supposed to be a simple approval + transfer mechanism. When developers embed swap logic inside it:
- Users can't see the hidden cost — A "transfer" silently triggers a DEX swap
- Gas costs are abnormal — More computation = higher gas, masking the exploit
-
Approval becomes a trap — Granting
transferFrom()approval gives access to hidden value extraction
This is an economic side-channel attack — not breaking cryptography, but exploiting the gap between what a function is supposed to do and what it actually does.
Sources: CertiK Alert, TenArmor Alert, CryptoCompass
More investigations at On-Chain Investigations
