Phishing and Social Engineering
Attackers take assets by persuading holders to sign a transaction or reveal a secret, without breaking any cryptography or contract.
How it happens
The most common losses require no technical exploit at all. Token approval drainers ask a user to sign a message granting a contract permission to move their balances, which looks routine and is often signed blind because wallets display raw calldata rather than an outcome. Delivery methods are ordinary: a hijacked domain or a paid search result pointing at a cloned front end, a compromised front-end dependency serving malicious code from a legitimate address, a support impersonator in a chat channel, an airdropped token whose sale requires an approval, or an address-poisoning transfer designed to plant a lookalike address in the transaction history. Where accounts are protected by text-message codes, a carrier account takeover defeats the second factor entirely.
What you can actually observe
Review outstanding token approvals with an allowance viewer, since standing approvals are the main mechanism and are visible on-chain. Check whether the wallet decodes calldata into a plain-language action and whether the project pins its front end to a content hash or serves it from a decentralized host. Domain hijacks, dependency compromises, and support-impersonation waves are usually documented publicly by the projects affected.
Precedent
A 2020 breach of customer records at hardware wallet maker Ledger was followed by a sustained phishing campaign against the exposed customers, and separate domain and front-end hijacks have redirected users of several protocols to malicious sites while the underlying contracts were untouched.
What makes it more or less material
Consider how many standing approvals exist and how broad they are, whether signing requests are human-readable, whether the front end is pinned or hosted conventionally, and whether any account still relies on text-message codes.