Kriptotárca-csalások 2026: wallet drainer, hamis app és aláíráscsapda

Utolsó biztonsági és forrásellenőrzés: 2026. augusztus 30.

A modern kriptotárca-csalás nem mindig kéri el közvetlenül a seed phrase-t. Elég lehet egy hamis alkalmazás, egy megtévesztő cím, túl széles tokenengedély vagy olyan aláírás, amelyet a támadó később használ fel. A védekezés kulcsa annak felismerése, hogy pontosan mit engedélyezel, melyik hálózaton, melyik szerződésnek és meddig.

A legfontosabb wallet-támadások 2026-ban

Négy külön hozzáférési pontot érdemes szétválasztani. A kulcslopás a seedet vagy privát kulcsot szerzi meg. A wallet drainer megtévesztő tranzakcióval, engedéllyel vagy aláírással próbál eszközt elvinni. A címcsere rossz címre tereli a saját küldésedet. A hamis felület pedig a valódi app vagy ügyfélszolgálat látszatával visz a másik háromhoz.

A kár nem egyformán terjed. Egy rossz Ethereum-token approval jellemzően az adott tokenre, szerződésre és hálózatra vonatkozik; egy ellopott seed viszont az abból származtatott összes fiókot veszélyeztetheti. Ezért az első kérdés incidenskor nem az, hogy „melyik revoke oldal kell”, hanem hogy kulcs, engedély, aláírás vagy cím tévesztése történt-e.

Hamis alkalmazás, frissítés és ügyfélszolgálat

A támadó keresőhirdetésben, klónozott alkalmazásbolt-oldalon vagy privát üzenetben kínálhat „kötelező frissítést”. Telepítés után a program seed-importot kér, módosítja a vágólapot vagy hamis tranzakciót jelenít meg. Valódi támogatás sem kérheti a seed phrase-t, és nem kell „szinkronizáló” webűrlapba beírni.

Az alkalmazást a gyártó kézzel ellenőrzött hivatalos domainjéről indulva keresd meg. Nézd meg a fejlesztő nevét, a kiadói hivatkozást és az eszközön megjelenő aláírási adatokat. Távoli asztali hozzáférést ne adj annak, aki kéretlenül supportnak mondja magát. A kripto pénztárca alapútmutató segít a custody-modell kiválasztásában; a self-custody önálló ellenőrzési felelősséget jelent.

Seed phrase phishing és információlopó kártevő

A recovery phrase a tárca főkulcsa. Aki megszerzi, új eszközön is létrehozhatja ugyanazokat a fiókokat, ezért egy jelszócsere önmagában nem oldja meg a problémát. Veszélyes a felhőjegyzet, a képernyőkép, a chat, az e-mail és a böngészőbe másolt seed: információlopó kártevő a fájlokat és a vágólapot is átvizsgálhatja.

Gyanús jel a sürgetés, az állítólagos „wallet-verifikáció”, az airdrophoz kért import és a seedet kérő hibajavítás. Seedet kizárólag megbízható, offline helyreállítási folyamatban, a saját eszközödön írj be. Ha valaha weboldalnak vagy embernek átadtad, tekintsd kompromittáltnak; új, tiszta környezetben létrehozott tárcára kell átállni, nem ugyanazt a seedet új jelszóval tovább használni.

Address poisoning és vágólap-eltérítés

Address poisoningnál a támadó kis vagy nulla értékű tranzakcióval olyan címet helyez az előzmények közé, amelynek eleje és vége hasonlít egy korábbi címre. A beérkező „por” önmagában általában nem ad hozzáférést a tárcához; a csapda az, hogy később az előzményből a támadó címét másolod ki. Mindig az eredeti, megbízható csatornából vedd a címet, és ellenőrizd a teljes karakterláncot vagy az eszköz kijelzőjét.

A vágólap-eltérítő kártevő ezzel szemben másolás után cseréli ki a címet. Ez Bitcoin-, EVM- és más hálózaton is veszélyes. A cím első és utolsó négy karaktere nem elég. Mentett címjegyzék, címengedélyezési lista és kis tesztküldés csökkentheti a hibát, de a teszt után is ugyanazt a teljes címet kell újra ellenőrizni.

Token approval, Permit és signature phishing

Az ERC-20 approval felhatalmaz egy szerződést, hogy meghatározott tokenből költsön. Kényelmi okból egy dapp korlátlan engedélyt kérhet, de rosszindulatú vagy később feltört szerződés így nagyobb összeget érhet el. NFT-knél a setApprovalForAll különösen széles jogosultság. A wallet leválasztása a weboldalról nem feltétlenül vonja vissza az on-chain engedélyt.

A Permit és más off-chain aláírás nem mindig mozgat azonnal eszközt, de később benyújtható lehet. Ezért a „csak üzenetet írsz alá, nincs gas” állítás nem biztonsági garancia. Ellenőrizd a domaint, a láncot, a spender szerződését, a tokent, az összeget és a lejáratot. USDT vagy USDC esetén is a konkrét szerződés és az aláírt szabvány számít, nem a ticker.

EIP-7702 delegációs aláírások kockázatai

Az Ethereum EIP-7702 lehetővé teszi, hogy egy hagyományos külső tulajdonú fiók delegált kódon keresztül okosszerződés-szerű funkciókat kapjon. Ez legitim kényelmi fejlesztéseket adhat, de a delegáció célpontja biztonsági határ: hibás vagy rosszindulatú kód a felhasználó nevében hívásokat, tokenátutalásokat és approvalokat kezdeményezhet.

Ne kezeld a delegációt egyszerű bejelentkezési aláírásként. A walletnek világosan kell mutatnia a célkódot és a hatókört; a chain_id=0 jellegű engedély több láncra is kiterjedhet. Csak a tárca által ellenőrzött implementációval dolgozz, és elutasítás után ne próbáld vakon másik felületen. A delegáció módosítható vagy törölhető lehet, de az addig végrehajtott rosszindulatú művelet ettől nem fordul vissza.

Tranzakciószimuláció, költési limit és külön tárcák

A szimuláció megmutathatja a várható egyenlegváltozást és ismert rosszindulatú mintát, de hiányos lehet új szerződésnél, összetett hívásnál vagy késleltetett aláírásnál. Figyelmeztetés hiánya nem jóváhagyás. Olvasd el az emberileg értelmezett műveletet, majd szükség esetén a nyers szerződéscímet is ellenőrizd a projekt hivatalos oldaláról.

• Adj csak a művelethez szükséges tokenmennyiségre engedélyt.
• Rendszeresen vizsgáld felül az on-chain approvalokat, és vond vissza a nem használtakat.
• Tarts külön, kis egyenlegű interakciós tárcát a hosszú távú tárolástól elkülönítve.
• Solana és más nem EVM-hálózat esetén a saját wallet- és programjogosultságokat vizsgáld, ne ERC-20 útmutatót másolj.

Incidens után: költöztetés, revoke, bizonyítékmentés és bejelentés

1. Kapcsold le a kompromittált eszközt a hálózatról, és tiszta eszközön hozz létre teljesen új seedet.
2. Azonosítsd a támadás típusát a TXID, a cím, a szerződés, az aláírás és az időpont alapján.
3. Ha a seed vagy privát kulcs érintett, a maradék eszközt — ha biztonságosan megoldható — új tárcára költöztesd, majd a régit ne használd.
4. Ha csak approval érintett, hivatalos walletfelületen vond vissza; ez on-chain tranzakció, ezért hálózati díja van.
5. Mentsd el a webcímet, képernyőképet, üzeneteket, TXID-ket, címeket és pontos időket; a seedet ne tedd a bizonyítékcsomagba.
6. Jelentsd a hamis oldalt az érintett walletnek vagy platformnak, és lopás gyanújánál tegyél rendőrségi bejelentést.

Ha automatikus sweeper üríti a címet, ne küldj be vakon további ETH-t gasra: azt is elviheti. Ilyenkor csak hiteles, ellenőrizhető technikai incidenssegítséget vegyél igénybe, és ne fizess előre „garantált recoveryért”.

Gyakori kérdések

Feltöri a tárcát egy kéretlenül kapott token vagy NFT?

Önmagában a megjelenése jellemzően nem. A veszély akkor nő, ha a hozzá tartozó linket megnyitod, a tokent rosszindulatú dappban próbálod beváltani, vagy megtévesztő tranzakciót írsz alá.

Elég leválasztani a walletet a dapp-ról?

Nem feltétlenül. A kapcsolat bontása a webhely hozzáférését szüntetheti meg, de a blokkláncon rögzített token approval megmaradhat. A jogosultságot külön on-chain revoke tranzakcióval kell visszavonni.

Biztonságos a tranzakció, ha a wallet nem jelez veszélyt?

Nem garantált. A szimuláció és a fenyegetés-adatbázis hasznos szűrő, de új vagy összetett támadást nem biztos, hogy felismer. A domain, szerződés, összeg és hatókör kézi ellenőrzése továbbra is kell.

Megmenti a revoke a tárcát, ha kiszivárgott a seed?

Nem. Ellopott seednél a támadó közvetlenül aláírhat. Új, tiszta környezetben létrehozott seedre és új tárcára kell átállni; a régi tárca további használata nem biztonságos.

Visszaszerezhető az ellopott kripto?

Nincs garantált technikai visszafordítás. Gyors bizonyítékmentés és bejelentés segítheti a vizsgálatot vagy egy szolgáltatói címzárolást, de aki biztos visszaszerzést ígér, újabb csaló is lehet.