Greetings
On 2026-11-08 at 18:10:35 UTC two Aave-related token positions held by our wallet 0x64cacba2bca8785961c450b928dc60b03742b3cc were transferred out without our authorization. We did not sign these transactions, and we were not at the device at the time.
The destination 0x413e4f4de7e5ff010913488f781e679e76f706da looks like a large automated sweeper, not an exchange and not a wallet of ours.
We are posting to (1) warn other users, (2) ask whether anyone recognises this pattern, and (3) request any guidance the Aave community or service providers can offer on evidence collection for a criminal complaint.
Affected positions
| Token | Contract | Amount | Value at time of theft |
|---|---|---|---|
AUSDT (Aave Ethereum USDT, aToken) |
0x23878914efe38d27c4d67ab83ed1b93a74d4086a |
10,028.528651 | ≈ $10,015.77 |
stkwaEthUSDC.v1 (Umbrella Stake Wrapped Aave Ethereum USDC v1) |
0x6bf183243fdd1e306ad2c4450bc7dcf6f0bf8aa6 |
8,398.570816 | ≈ $9,238.43 |
Total: ≈ $19,254 USD.
Both positions had been held in this wallet since 2026-06-26 and were stable until the transfer.
Transactions (Ethereum mainnet)
| # | Tx hash | Token | Amount | Destination | Time (UTC) |
|---|---|---|---|---|---|
| 1 | 0x5223f78b9300ec6fa2c6cb2ead79b3527857be2ccc1374f5d88c647c24d8fd44 |
stkwaEthUSDC.v1 |
8,398.570816 | 0x413e4f4de7e5ff010913488f781e679e76f706da |
2026-11-08 18:10:35 |
| 2 | 0x254c93130dd20f21db96c39ba29a8847f9b7eb148e4664c40bf429d2421693b4 |
AUSDT |
10,028.528651 | 0x413e4f4de7e5ff010913488f781e679e76f706da |
2026-11-08 18:10:35 |
| 3 | 0xdcc81d176c246f3c6365fee6b7a49f6321eada7df4c4cae2a5b40cd212a5497a |
unverified ERC-20 (placeholder in our indexer) | 10,028.528651 | 0x413e1868ecefa385b5c1c16421dd19a01e1806da |
2026-11-08 18:17:47 |
| 4 | 0x4157f599d1589defd84ae0503dc60772ee91239ced66836074be637ec3de735d |
AUSDT |
0 (residual) | 0x413e1868ecefa385b5c1c16421dd19a01e1806da |
2026-11-08 18:17:59 |
Transactions 1 and 2 were both plain transfer() calls (selector 0xa9059cbb) from the victim wallet (ours) to the drainer, mined in the same block.
Transactions 3 and 4 are NOT attributable to the same actor in the same way and we flag them separately: in tx 3 the from field on-chain is 0x1584a8ee67789d1fe161065388657ad2f2a3c7dd and in tx 4 it is 0xd6434d157f254276d69ede3bd9fc805482206908. Neither is our wallet. Our indexer had initially mis-attributed them to us; a direct chain read corrected this. We list them because the amount in tx 3 exactly equals the stolen AUSDT balance, which we cannot yet explain.
Balance state
- Victim wallet
0x64cacba2…b3cc, AUSDT: 10,027.88 → 0.001219 (residual base-unit dust). - Victim wallet,
stkwaEthUSDC.v1: 8,398.570816 → 0. - Neither position has returned. There is no inbound transaction restoring either token.
The destination address: why we call it a sweeper
0x413e4f4de7e5ff010913488f781e679e76f706da
We retrieved its full transfer history from a public indexer. It is not an exchange deposit address, not a bridge, and not contract code (eth_getCode returns empty, it is an EOA). Its behaviour:
- 1,810 inbound transactions, 644 token transfers, zero outbound token transfers as of 2026-11-11. It only receives.
- Nonce = 0. It has never signed a transaction of its own. It is funded and operated indirectly.
- 326 distinct sending addresses across 91 distinct tokens (USDC, WETH, USDT, INJ, stETH, eETH, AAVE, ENA, PENDLE, ONDO, LINK, DAI, UNI, and 78 more).
- Active since 2026-11-07 17:50 UTC, i.e. it was already sweeping other wallets before it took our positions on 2026-11-08.
- Transfers arrive in synchronised waves at 12-second intervals (
18:09:47 → 18:10:11 → 18:10:35 → 18:10:59 → 18:11:11 → 18:11:47 …), consistent with an automated bot rather than manual operation. - It currently holds 13.9558 ETH of native balance, presumably consolidated from victims.
Within the same 2-minute window as our loss, this address also received ONDO from 0x1C84ed8A20949B48e1404e8c9F23FCBeD5B1C20d, HOLD and NPC from 0x32D396E179f9fF3Fa002091AE0C27F23fEa04B80, LINK from 0xf946a0371F031900575d36ede1B934BE8C5899E1, TRAC from 0x6cE51890484D5e37b85E3b865F238EF115DE5FC5, and ONDO from 0xa5A50E4aFd4Bdd071472486086B322c67E31889f.
If you recognise any of those addresses as yours, you are likely a victim of the same operator. Please check.
Suspected access vector
We believe the signing key was compromised through illicit access to the machine on which the wallet browser extension was installed. Our working hypothesis involves a Keplr installation:
- Our hypothesis is therefore either (a) the same mnemonic was imported into a Cosmos wallet and into an Ethereum wallet on the same machine, so a single seed compromise reached both, or (b) the compromise is in an Ethereum extension (or in the seed material stored on disk) and Keplr is a correlated symptom, not the vector.
- We are still determining which. We are not claiming a Keplr vulnerability, and we are not claiming Aave was involved in any way. Aave contracts behaved correctly: it was a plain token transfer authorised by a key we no longer control.
We are aware this is the standard profile of commodity infostealer malware (RedLine, Lumma, Vidar and similar families) that harvests browser extension storage and seed phrases. We have not yet completed a forensic image of the device.
What we are asking
- Has anyone seen
0x413e4f4de7e5ff010913488f781e679e76f706dain other reports? Any prior thread, any Aave forum post, any public tag: we want to link this to a broader campaign. - Is there any asset-side action available for
stkwaEthUSDC.v1orAUSDT? We understand a signedtransfer()is irreversible and that neither you nor the Aave contracts can reverse it. We are asking whether there is any pause, freeze, or blacklist mechanism on these specific token contracts that a legitimate issuer could invoke and whether such a mechanism has ever been used in practice. - Does the Aave service provider set (Chaos Labs, LlamaRisk, BGD Labs, TokenLogic) publish or accept drainer-address intelligence that we could contribute to? We would rather hand the address to a body that tracks it than see it posted only in a support thread.
- Has anyone had a
transfer()from astkwa*/Umbrella token recovered or clawed back by any means whatsoever? We would like to know whether it is truly 0%.
We want to be candid: we are not posting this expecting recovery. We are posting because the address is still active, it took six more wallets in our window alone, it has taken from 326 addresses in total, and it will take more. If this thread makes one person check their device today, it was worth writing.
What we are doing on our side
- Taking the affected machine offline pending forensic examination.
- Migrating all remaining holdings that shared the compromised seed material to newly generated keys on hardware that has never touched the compromised environment.
- Preserving a full database and chain export of the incident before making any corrections to our own indexer, so the evidence set stays intact.
We will update this thread with the results of the device forensics when available.
Thank you for reading, and please check your own extension wallets.