Defend Against Cybercrime with the Power of Community

A fake verification step can move the attack surface into an already authenticated browser page. In this case, the decisive analytical distinction is between evidence of a malicious bookmark, evidence of token transfers, and proof of how those transfers were authorized. Those are related questions, but they are not interchangeable.Our direct explorer review identified three USDC transfers from one source owner to the recipient named in SlowMist's original technical analysis. They total exactly 45,106.851598 USDC and span 63 seconds. That matches the reported 45,106.85 USDC total when rounded to two decimal places. The match makes them strong candidate incident anchors; it does not independently establish the source wallet owner's identity or the victim's consent.Scope and evidence boundaryMeasureValue / interpretationNetworkSolanaCandidate inbound total45,106.851598 USDC; three unique successful transactionsCandidate transfer window2026-10-04 08:58:45–08:59:48 UTCReview cutoff2026-10-09 00:32 UTC; historical transaction snapshots, not a complete chain auditPublic loss reportApproximately $48,000 in assets, as relayed by SlowMist; not equated with the exact USDC subtotalIndependent victim confirmationNot obtained; attribution remains a documented candidate matchThe review deduplicates by transaction signature and counts only the single USDC transfer in each candidate transaction. SOL network fees are recorded separately and are not added to the USDC amount. Address-wide activity is kept outside the candidate incident subtotal.Three findings that matter1. The reported withdrawal total has a specific, reproducible candidate matchQuestion: can the reported three withdrawals be distinguished from the recipient's other inflows? The three transactions below share the same source owner, destination owner, USDC mint and decoded transferChecked method. Their exact sum, count and destination fit the public report. The source wallet is therefore an investigative candidate, not a newly identified person.UTC on 4 OctoberUSDC transferredEvidence08:58:4532652.960737A01: transaction detail08:59:235002.490046A02: transaction detail08:59:487451.400815A03: transaction detailThe arithmetic is 32,652.960737 + 5,002.490046 + 7,451.400815 = 45,106.851598 USDC. The 0.001598 USDC difference from the two-decimal public figure is rounding, not a separately identified transfer. What remains uncertain is independent confirmation that these exact signatures correspond to the reported victim's withdrawals.Figure 1. Directly checked candidate transfers. A dashed co-signer panel is an authorization observation, not a money-flow edge. Downstream attribution is deliberately not shown.2. A co-signer label does not resolve the compromise mechanismQuestion: does the chain tell us whether an attacker exported a key or requested remote signing? Each candidate transaction lists the source owner and a second signer that Solscan labels “Fomo Co-signer.” That is evidence about transaction signers and a provider label, not proof of who initiated the request, which authentication material was used, or whether any signing service was compromised.RolePublic address / accountSource owner / transfer authority6R6stpcbSij7scSpD7Refq1eap2gN1Qj3omFeGu3gJPcSecond signer; Solscan label “Fomo Co-signer”AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51Source USDC token accountBcxGQtcyAgX1VrM8sS94aMbFridPqkJ3u8qQx4e4X3PgDestination USDC token accountEpAjLMVnttREdDiXGddym5eYgsn5hH2oPPnQcarTKajMDestination owner named by SlowMistD783JqupQ2FYhkxUfGEd1gaFEoAJDXRX1NEb4aVH2hZ6The owner-level explorer summary and the decoded instruction describe different layers: the summary resolves wallet owners, whereas the instruction names the SPL token accounts being debited and credited. A token account must not be presented as a separate attacker wallet merely because it has a different address.3. A Privacy Cash transfer is verified; its victim attribution is notQuestion: can an address-wide service exposure be treated as this victim's recovered path? A separate successful transaction sends 212.492295 SOL from the named collection owner to a pool Solscan labels Privacy Cash Pool on 5 October at 07:46:10 UTC. This directly supports an address-to-pool transfer. It does not by itself show that those SOL were purchased with the three candidate USDC transfers.ObservationEvidence / limitTransaction4YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxAmount and UTC212.492295 SOL; 2026-10-05 07:46:10 UTCPool destination4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGhProgram9fhQBbumKEFuXtMBDw8AaQyAjCorLGJQiS3skWZdQyQDAttribution boundaryAddress-history evidence only. No independently reconciled route from candidate USDC anchors yet.SlowMist's reported 1,568.33 SOL cumulative Privacy Cash outflow concerns the address's history. It is not substituted for the incident's 45,106.85 USDC subtotal, nor independently reproduced by the single transaction checked here. The intervening swaps, balances and other inflows must be reconciled before assigning a victim-specific downstream amount.How the bookmark crosses the trust boundaryAccording to SlowMist's original technical analysis, a token-page link led to a fake human-verification page that prompted a bookmark action. The saved JavaScript then ran in the logged-in FOMO context and targeted browser storage, IndexedDB and Privy session material. We did not execute the malicious sample or connect to its collection endpoint.Figure 2. Source-based mechanism reconstruction, not an independently replayed exploit or transaction trace. The unresolved signing step is dashed.The useful security conclusion is narrower than “a wallet connection stole the funds”: the described lure sought code execution within a trusted application session. Conversely, the source's conditional MFA logic and the victim's reported absence of 2FA do not establish a demonstrated MFA bypass. Initiating an enrollment flow would also not prove successful enrollment.Timeline: observations rather than invented milestonesUTCEvent and evidence level2026-10-04 08:58:45A01: 32,652.960737 USDC, directly checked2026-10-04 08:59:23A02: 5,002.490046 USDC, directly checked2026-10-04 08:59:48A03: 7,451.400815 USDC, directly checked2026-10-05 07:46:10T01: 212.492295 SOL to provider-labeled Privacy Cash pool; separate address history2026-10-08SlowMist public alert and analysis; not the attack dateThe attack's initial browser-execution time is not established here. The collection address's reported first activity on 17 September is not assigned as the incident start time.Alternative explanations and what would resolve themThe three-transfer match could be strengthened by an original withdrawal record or source confirmation naming the signatures. A transaction's valid signatures do not reveal whether the human account owner approved it. Application-side authentication, session revocation, withdrawal and signing logs would be needed to test competing key-export and remote-signing explanations.For downstream analysis, identical asset values or nearby timestamps are insufficient to prove a bridge connection. A defensible cross-chain edge requires a source transaction, bridge order or fulfillment record, and destination transaction. Ethereum and Bitcoin candidates mentioned by the source remain external leads until that chain of evidence is available; they are not drawn as verified branches here.Case-specific response pointsFor the affected account, preserve the bookmark URL and browser/session chronology without executing the bookmark again. Application operators can correlate the three candidate signatures with withdrawal requests and signing-policy decisions, then evaluate session and refresh-token revocation. A password change alone should not be assumed to invalidate every previously issued session artifact.For investigators, preserve the full source/destination token-account mapping and block references before expanding a cluster. For any service request, provide the specific transaction and account history being queried, and distinguish the verified transfer from a claim about stolen-fund ownership. Provider labels are leads for corroboration, not legal identity findings.Evidence appendixID / slotFull transaction signatureA01Solana slot 45320947444uGoQH6KQRyVDCLuDTUHW3KxR61j9pGnnWWKoGtWFh9b3jUFRQ9t5MMVHoFr5ZWFLgEgWKmgxuR5Wq8tS36XkzNA02Solana slot 4532096174pgANnxQ2Q5139ToXuc7LvHWqBZKKsBXwAVKA4eSi1wLnYdpukbgL2ZheTxXAMevU84HVKJCe1TBTTZ1VN2TZrH9A03Solana slot 453209712xM1eCwjwhV4h9ECr2dTpL4TTDq3YafKiME3qyJcCAiLM3iqZosCVSW3rdQPcUr8AXWhzDrJzd4JKDZDWBJ6q4KMT01Solana slot 4535158714YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxToken / technical propertyValueUSDC mintEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1vCandidate instructionSPL Token Program transferCheckedPer-candidate fee0.00001507 SOL; separate from USDC principalSource basisSlowMist's original technical analysisReproducibility limitExplorer-decoded detail checked; no raw RPC replay, victim-account access or complete downstream reconciliation claimedThis report separates directly observed chain transactions, explorer-provided labels, external reporting and analytical inference. It does not identify an attacker or attribute every historical recipient transaction to this case.

Money moved out of a contract on Ethereum, reached a wallet, and then left that wallet in twenty equal transfers. The last transfer came 15 minutes and 24 seconds after the initial withdrawal.The amount was 200 ETH. ETH, short for ether, is the native asset of Ethereum. At the start of this path, it was held in a token form called WETH, or wrapped ETH. During the withdrawal, 200 WETH was converted into 200 ETH.That change of form matters: we are following the same-sized amount through several stages, not adding a new loss every time it moves.A security alert linked the event to an old auction program. We will first explain what that program did, then follow the recorded transfers, and finally separate what is known from what still needs checking.The route in brief: 200 WETH leaves a collateral contract → it becomes 200 ETH → a wallet receives it → the wallet sends twenty transfers of 10 ETH. The records examined here do not establish where the money went after mixing.Incident: October 6, 2026.Evidence cutoff: October 6, 2026, 21:55 UTC (October 7, 06:55 KST).Reading guide: Follow sections 1–6 for the story. Full transaction references and addresses are in the appendix.1. The auction was selling loan collateral, not NFTsWhy does an auction appear in this story? In MakerDAO, users can leave assets such as ETH as security for a loan. That security is called collateral. They borrow DAI, a token designed to track the value of one US dollar, against it.Think of borrowing against something you own. If its value falls too far, the lender may need to sell it to settle the debt. A liquidation auction performs that role here: it sells crypto collateral. The actual system has its own thresholds, fees, and settlement rules. Background: the official liquidation-system proposal.A keeper is software that automates tasks such as bidding in those auctions. It is not the borrower. The person borrowing against collateral and the participant buying it at auction have different roles. Background: the official Auction Keeper project.The next diagram follows the general process from borrowing to receiving the auctioned asset. Read it from top to bottom, paying particular attention to the final two steps.Figure 1. From borrowing to withdrawing collateralA simplified guide to the historical Flipper auction process, not a trace of this incident. The final two boxes separate settlement from external withdrawal. Detailed bidding rules and the wider current system are outside this diagram.Winning, settling, and withdrawing are separate steps. Winning determines the buyer. Settlement records the outcome. Withdrawal moves the asset out to an external address. Finishing one step does not mean all three have happened.In the published historical auction code, a function called deal settles the auction and credits the recorded winning bidder. The person who calls that function does not become the winner merely by calling it. This is general background, not proof of how the exact incident contract was configured. Source: the published Flipper implementation.With that distinction in mind, we can now follow the actual movement of funds.2. Meet the addresses before following the moneyYou do not need to memorize hexadecimal addresses. The names below describe what each address did in the records; they do not identify a person or prove who controlled it.The collateral adapter — 0x2F0b…042A. This contract is the first sender of WETH in the transfer records. Etherscan, the public transaction explorer, labels it “Sky: MCD Join ETH A.” Here, an adapter means a contract used to move collateral into or out of the system.Two intermediate contracts — 0xF09A…C170 and 0xEc997…1dcF. The WETH passes through these contracts. The first is created during the transaction; the second later sends ETH to the initiating wallet. A contract is a program on the blockchain, not necessarily a person's wallet.The initiating wallet — 0x01EB…A5FA. This address starts the transaction, receives the 200 ETH, and then sends the twenty later transfers. We use the same name throughout so that you can recognize it as the story continues.The WETH contract. This contract releases ETH when WETH is unwrapped. “Unwrapping” is the change from the token form to ETH; it is not a gain of another 200 ETH.One distinction will help when reading the next diagram: starting a transaction is not the same as sending every asset inside it. A wallet can instruct a contract, and that contract can trigger further calls and transfers.3. At 06:13:11, the wallet receives 200 ETHOn October 6 at 06:13:11 UTC, the initiating wallet submitted the withdrawal transaction. Within that one transaction, the collateral adapter sent 200 WETH to the newly created contract. That contract passed 200 WETH to the other intermediate contract.The intermediate contract then unwrapped the WETH. The WETH contract paid it 200 ETH, and it passed 200 ETH to the initiating wallet. These are several movements inside one transaction, not several separate withdrawal transactions. Check the withdrawal transaction.In the diagram below, start with the first blue asset-transfer box. Follow the blue WETH path until it becomes the purple ETH path. The gray strip at the top shows who initiated the call, not an additional payment.Figure 2. Separating WETH transfers from ETH paymentsFollow the numbered asset movements from top to bottom. Blue means WETH; purple means ETH. The gray call strip is not a payment. All stages belong to one transaction. Evidence: token logs 174, 176, and 177, plus internal ETH transfers.The important change is at the end: the initiating wallet now holds ETH that it can send onward. The diagram explains that route. It does not explain why the contracts allowed it or establish a system-wide compromise.You can compare the explanation with the explorer screenshot below. Look for the timestamp, the WETH transfer entries, and the internal ETH payments. “Internal” here means payments made during contract execution inside the transaction.Evidence 1. The withdrawal transaction on EtherscanOriginal explorer evidence: compare the timestamp, WETH transfers, and internal ETH payments. The displayed dollar values are not used as incident-time loss estimates. Open the withdrawal record.Several lines show the number 200 because the amount passes through multiple steps. Keep that in mind as we follow it out of the wallet.4. The same wallet sends twenty transfers of 10 ETHAfter receiving the ETH, the initiating wallet sent twenty transactions to the same Tornado Cash router. A router is an intermediate contract that forwards a request to another contract. Each transaction sent 10 ETH, making 200 ETH in total, excluding transaction fees. Check the wallet's transaction history.Tornado Cash is a mixer designed to make a deposit difficult to link directly to a later withdrawal. That is why observing money enter this route is not the same as knowing who later received it.The next diagram gives every transfer its own tile. Read left to right, then move to the next row. A block number identifies the block containing the transaction; the equal tile spacing does not mean equal time intervals.Figure 3. All twenty transfers in block orderOne tile equals one transfer of 10 ETH. Read left to right, then down. Tile spacing does not represent time. Individual transaction links are in Appendix A.The twenty tiles show repeated transfers to the router, all from the same wallet. You can check each transaction separately in Appendix A without interrupting the story here.The explorer screenshot lists the same type of entries in the opposite direction: newest first. Compare the destination and the 10 ETH amounts, rather than reading its rows as the diagram's order.Evidence 2. Repeated 10 ETH transfers from the same addressOriginal explorer evidence: the newest entries appear first. Compare the Method, To, and Amount columns. Open the wallet history.The final transfer shows one step furtherThe last transaction was recorded at 06:28:35 UTC. Its internal payment record shows the router forwarding 10 ETH to the contract labeled “Tornado.Cash: 10 ETH,” the pool in this final transfer. Check the final transaction.That extra check was made for the final transaction. The twenty outgoing transfers were reviewed, but this article does not claim a complete internal router-to-pool review of all twenty.Evidence 3. The final 10 ETH paymentOriginal explorer evidence: From is the initiating wallet; To is the router. Internal Transactions shows the final 10 ETH payment to the pool. Open the final transfer.We now have two verified endpoints: the withdrawal at 06:13:11 and the final transfer at 06:28:35. The difference is 15 minutes and 24 seconds. The next diagram places those endpoints around the transfers and shows where our evidence stops.Figure 4. The observed time window and the limit of the traceThe bracket spans 06:13:11 to 06:28:35 UTC: 15 minutes and 24 seconds. Intermediate spacing is schematic. Only the final transfer received a detailed internal router-to-pool check; the post-mixer path remains unestablished.The bracket measures withdrawal to final transfer. It is not the duration of the twenty transfers alone or of the entire incident. The separately labeled 2020 history comes from an external alert, which we examine below.The path ends at the checked pool payment because this article has not established a later destination. It does not show an exchange deposit, a cash-out, or the identity of the person controlling the wallet.5. Several movements do not mean several lossesWe have seen 200 WETH move, 200 ETH arrive, and 200 ETH then leave in smaller transfers. These are successive stages of the observed route, not separate amounts to add together.Instead, read the next diagram as a running account of the route: the asset changes form, reaches the wallet, and is sent onward. Each box describes what happens next to the same-sized amount.Figure 5. Following the same amount without counting it twiceRead top to bottom. The amounts describe successive stages, not separate losses to add together. Gas fees are excluded; this diagram makes no incident-time dollar valuation.The observed route is 200 WETH → 200 ETH → twenty transfers totaling 200 ETH. It is not an 800 ETH loss obtained by adding repeated entries inside the transaction, and the onward transfers are not another separate 200 ETH withdrawal.These totals exclude gas fees, the fees paid to execute transactions. Dollar prices displayed in explorer screenshots reflect the display at capture time; this article does not use them to calculate an incident-time dollar loss.The amount and route are now clear. The remaining question is different: what allowed the withdrawal?6. The route is visible; the reported cause still needs checkingDefimon Alerts attributed the event to a permission problem in an old MakerDAO auction keeper. According to its report, the keeper had won four auctions in 2020—numbers 1457 through 1460, each for 50 WETH—but had not settled them. The report says an external caller used an unprotected keeper function to settle and withdraw the collateral. Read the source alert.This explanation connects back to the separate steps in section 1. Settling an auction and deciding who may withdraw its assets are not the same permission question. A publicly callable settlement function is not automatically a flaw.The following comparison puts those two questions side by side. Read the left panel as general auction background and the right panel as the keeper-permission issue that needs verification.Figure 6. Settlement and withdrawal are different permission questionsThis comparison separates the general settlement mechanism from the externally reported keeper-permission issue. The dashed amber panels mark a question and an allegation, not an independently verified exploit path.The allegation concerns someone else being able to invoke a function that sends the keeper's collateral to an external address. To confirm that explanation, we would need the keeper's code and configuration at the time, together with the detailed execution record. The transfer amounts alone cannot answer it.The general Flipper source cited earlier is not assumed to match the exact deployed implementation. Likewise, the adapter's explorer label is not evidence that all of MakerDAO or Sky was compromised.What we can take awayThe records support a specific sequence: 200 WETH moved, it was converted into ETH, the initiating wallet received 200 ETH, and that wallet sent twenty transfers of 10 ETH to a router. The final transfer also has a checked 10 ETH payment from the router to the labeled pool.Use the final diagram to separate that observed route from the external explanation and the unanswered questions. The labels matter as much as the colors: blue is checked evidence, dashed amber is the reported explanation, and gray is unresolved.Figure 7. Verified records and unresolved questionsLabels and border styles distinguish the evidence levels as well as color. The dashed amber box contains the external explanation, not an independently verified cause. No speculative line connects the mixer to an unverified later address.The next investigation has four concrete tasks. Check the keeper's historical permissions and implementation. Verify the creation, bidding, and settlement records for auctions 1457–1460. Review the internal payments in the other nineteen transfers. Look for independent evidence before linking any later withdrawal to these deposits.We can follow the money to the limit of the examined records. We cannot yet turn that route into a proven cause, an identified operator, or a confirmed cash-out.This is the end of the narrative. The appendix below keeps the original records available for readers who want to verify the details.Appendix A. The twenty transaction referencesEach entry represents one outgoing transfer of 10 ETH from the initiating wallet to the router. The full transaction hash is its identifier; follow the link to inspect the original record. The list runs in block order.Order: 1Block: 26131503Amount: 10 ETHOriginal transaction: 0xb8ecff9c129d8d9331c85558eaeddff29a38c4c16b71a40986acbf8f6febefebOrder: 2Block: 26131507Amount: 10 ETHOriginal transaction: 0x01dd51eff5790bf070ae5abefc4a77f3df2b2476feebbe9aaa6ffa1fd48f8429Order: 3Block: 26131509Amount: 10 ETHOriginal transaction: 0x8c5fb4f50aa0f56cc701afdad377e56f53655e48e237f85aef8fe902797a4240Order: 4Block: 26131512Amount: 10 ETHOriginal transaction: 0x9a6ef7cce759e09f1d23115f974eb0707460a6834de0d30a55c3761a9c9dce6cOrder: 5Block: 26131514Amount: 10 ETHOriginal transaction: 0x725cdd6f23f7fc30d6ab43a6cf634aec791e5e2097151a09fc522408786da3ffOrder: 6Block: 26131516Amount: 10 ETHOriginal transaction: 0xaf1fb061f3d3db6cc6107219ea7bc5e0c6f86ba54c997e10bb062e0a3f7f7eedOrder: 7Block: 26131519Amount: 10 ETHOriginal transaction: 0xfd60254ab0a74ae6d51706023394190ca20646264d1da322998afa4682ae18b2Order: 8Block: 26131521Amount: 10 ETHOriginal transaction: 0xcc14212fc5d51d3d5ea7f0de9895264da8c0b5c779ca2947083f665f50f0bfbeOrder: 9Block: 26131523Amount: 10 ETHOriginal transaction: 0x31d6c9cb202306536c9f977a486bd2f5d2a16d0db9c7558ac132442fe58440f5Order: 10Block: 26131525Amount: 10 ETHOriginal transaction: 0x3ef864598198ff4d23f22a35d540e0437ba0ed3af7a77c3d23ae99f59f1bb96eOrder: 11Block: 26131527Amount: 10 ETHOriginal transaction: 0x4c10b56e2f5c37706fdcbe2b1c7da35de68661306971b32e8ea5ed95e7a02a7aOrder: 12Block: 26131529Amount: 10 ETHOriginal transaction: 0xa452e803014458dba087c82bf0a7e9432bf014337b59d34483bbbf232fe39d57Order: 13Block: 26131531Amount: 10 ETHOriginal transaction: 0xaddc6ea108b17f39beca57487fee55f878546c8f233bdb8c0736b03658e890d4Order: 14Block: 26131533Amount: 10 ETHOriginal transaction: 0x61e349fe5ce11d9b3b8f4d9813c3a1f74e6dd898d43f61c0139673540137b3e6Order: 15Block: 26131537Amount: 10 ETHOriginal transaction: 0x7167efdb6740e1c1a38983edd33e3a7446d01abe2fcf63874b80aa8f9f3f7ee6Order: 16Block: 26131539Amount: 10 ETHOriginal transaction: 0xe82b2082edd720801389e75cf2a6158f494f9e8b3ad3a7671bfc18f9e7c07538Order: 17Block: 26131541Amount: 10 ETHOriginal transaction: 0x48303767bec9e216fa06e79dd21f3f3257524dd613c976f3fe60132bcc38af52Order: 18Block: 26131543Amount: 10 ETHOriginal transaction: 0x0ac6195011bfea03360778ce3a05f8ed665a6fe2ce6ac10231c2be3dcbb99210Order: 19Block: 26131546Amount: 10 ETHOriginal transaction: 0x2cd7eb09abe21d07e36aedc5a93f6c6f99b5ab796b2b5632aa14c6278192396cOrder: 20Block: 26131548Amount: 10 ETHOriginal transaction: 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbfAppendix B. Full addresses and their rolesThese labels describe observed behavior or a role attributed by the source alert. They do not identify people or establish knowing participation in wrongdoing.Role: Transaction initiator and ETH recipientFull address: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5faBasis: Withdrawal and subsequent transaction recordsRole: Intermediate contractFull address: 0xec997d2ad033277913d6002277353368e8321dcfBasis: Transaction target and internal paymentRole: Contract created during the transactionFull address: 0xf09a13072ed939b79bc25b66aa3a836ea6dcc170Basis: Creation record and WETH transfersRole: ETH-A collateral adapterFull address: 0x2f0b23f53734252bda2277357e97e1517d6b042aBasis: Explorer label and WETH transferRole: WETH contractFull address: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Basis: Token and withdrawal eventsRole: Affected keeper identified in the alertFull address: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273Basis: Role attributed by DefimonRole: Tornado Cash routerFull address: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31bBasis: Explorer label and subsequent transfersRole: 10 ETH pool in the final transferFull address: 0x910cbd523d972eb0a6f4cae4618ad62622b39dbfBasis: Internal payment in the final transactionAppendix C. Source records and review scopeThe review covers the initial withdrawal, the twenty outgoing transfers, and the internal payment in the final transfer. The historical auction story and the alleged permission failure remain externally reported claims rather than independently established findings.Withdrawal transaction, timestamp, token transfers, and internal ETH transfersWithdrawal transaction event logsInitiating address and subsequent transaction historyFinal deposit transactionDefimon Alerts report of the alleged causeOfficial liquidation-system proposal, MIP45Published Flipper source for the general settlement mechanismOfficial Auction Keeper project

ChainBounty · Investigation analysis · October 6, 2026A dormant third-party ETH-A keeper was exploited on Ethereum on October 6, 2026, according to SentinelTX's CASE-ASYNCADB report. The exploit released 200 WETH, which was unwrapped into 200 ETH and delivered to the attacker's externally owned account. That account then sent twenty transfers of 10 ETH each to a Tornado.Cash router between 06:19:35 and 06:28:35 UTC.SentinelTX locates the authorization weakness in the keeper's implementation contract. It classifies the incident as an exploit of a third-party liquidation bot, rather than a breach of the MakerDAO core protocol.Key findingsThe trace follows a 200 ETH native payout through the attack contract to the attacker's account, followed by twenty 10 ETH transfers to the same routerThe keeper proxy delegated selector 0x8804d1de to an unprotected exit path in its implementationThe router is the last recorded recipient on this route. Attacker identity and any exchange-deposit leg remain unestablished1. A funded account deployed two contracts before the drainThe first recorded step was gas funding. At 05:57:23 UTC, account 0x01eb95…bda5fa received 0.09783730488175 ETH from the address labeled Tornado.Cash's 0.1 ETH pool.The account then submitted three control transactions in order. At 06:09:23 UTC, nonce 0 created 0xa5c3a6…1fc552, a staging contract whose purpose remains unconfirmed. At 06:12:11 UTC, nonce 1 created the attack contract, 0xec997d…321dcf. At 06:13:11 UTC, nonce 2 called that contract with selector 0x0e763dd6 in block 26,131,471.The two deployments and the drain occurred within 3 minutes and 48 seconds. The deployment records contain no native value transfer; the 200 ETH payout followed in the drain transaction.The payout route contains two 200 ETH native movements in the same attack transaction. The WETH contract sent 200 ETH to the attack contract, and the attack contract forwarded 200 ETH to the externally owned account. The report interprets the first movement, following selector 0x2e1a7d4d, as the WETH unwrap.Figure 1. The reported native-ETH route. Two 200 ETH movements occur in the attack transaction; twenty later 10 ETH transfers carry 200 ETH from the account to the router. These are successive movements of the same principal, not separate losses. Arrows show direction, not proportional value or elapsed time. Separate gas funding is shown approximately; the exact transfer is 0.09783730488175 ETH.Color key: Slate: native payout hops. Amber: onward router deposits. Sage: separate gas funding.Address key: WETH contract 0xc02aaa…756cc2; attack contract 0xec997d…321dcf; attacker account 0x01eb95…bda5fa; router 0xd90e2f…24f31b. Full identifiers appear below.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4–7 and 10–14. Simplified explanatory figure, not an original SentinelTX graph.2. The drain entered a third-party keeper implementationThe attack contract called keeper proxy 0x9c05a0…0e8273 with selector 0x8804d1de. The proxy then used DELEGATECALL with the same selector to implementation 0x68399e…6a5546. SentinelTX identifies the missing authorization check in this implementation path as the weakness that allowed the drain.The attack calldata includes the keeper proxy, the ETH-A collateral identifier, the WETH contract, the recipient account, and auction IDs 1457, 1458, 1459, and 1460. These identifiers align with the reported account of four legacy auctions holding 50 WETH each. SentinelTX interprets the history as a dormant keeper that had won the auctions but had not completed settlement, leaving collateral available to the unprotected exit path.Later calls pass through the auction and collateral contracts identified as Flipper, Vat, and GemJoin ETH-A, followed by the WETH operation and the 200 ETH payout. The call trace records the selector bytes and execution order. Function names such as GemJoin exit and WETH withdraw are interpretations based on matching signatures and surrounding execution, rather than decoder-confirmed names.The relevant core-contract calls executed without reverting. The report's conclusion that MakerDAO core operated as designed also depends on its interpretation of those contract roles and cited reporting; it did not cross-check the address identities against MakerDAO's public changelog. Its finding is therefore specific to the third-party keeper implementation, rather than a claim that “MakerDAO was hacked.”Diagram 2. The third-party keeper call path. The proxy delegates selector 0x8804d1de to its implementation. Function-name mappings remain interpretations, while the 200 ETH native payout is recorded directly in the call tree. This diagram simplifies the sequence.Color key: Slate: selected keeper call path. Sage: later WETH release/unwrap and native payout section.Address key: Keeper proxy 0x9c05a0…0e8273; implementation 0x68399e…6a5546. Contract roles follow the report's stated basis and qualifications.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4 and 8–9.3. Twenty equal deposits moved the proceeds to the routerThe first 10 ETH transfer to the Tornado.Cash router was recorded at 06:19:35 UTC. The twentieth was recorded at 06:28:35 UTC. The twenty listed transactions each carry 10 ETH, totaling 200 ETH over nine minutes.This sequence started about six minutes after the drain. SentinelTX interprets the equal-size transfers as a structured mixer-deposit pattern.The recipient is labeled Tornado.Cash, Mixer, and Sanctioned. No exchange-deposit leg is recorded. The route ends at the router in the available evidence; that does not establish a final beneficiary or identify a corresponding mixer withdrawal.Figure 3. Cumulative deposits derived from the twenty 10 ETH transfers listed in the PDF. The steps reach 200 ETH at 06:28:35 UTC. Horizontal spacing represents actual time; the chart describes this deposit sequence, not the router's balance or downstream withdrawals.Color key: Slate: cumulative total derived from the twenty listed deposits. Sage: the final 200 ETH total.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 6–7 and 11–13. Cumulative totals are an editorial calculation from the listed same-unit transfers.4. Transfer activity is different from the incident amountThe activity summary totals 23 traced value movements involving five addresses and gross movement of 600.097837 ETH. This figure repeats funds at successive hops and is not a loss total. The 200 ETH payout is recorded from the WETH contract to the attack contract, again from the attack contract to the externally owned account, and then across the twenty router transfers. The small gas-funding transfer is separate.The incident quantity is 200 WETH, followed by 200 ETH after unwrapping. The approximately US$538,000 valuation comes from reporting and was not independently priced in the investigation. Native quantities therefore provide the clearest basis for following the funds.The timed movements discussed here run from 05:57:23 to 06:28:35 UTC on October 6. Later paths remain outside this documented route.ConclusionSentinelTX's conclusion is a third-party keeper authorization exploit followed by a 200 ETH payout and twenty mixer-router deposits. The useful boundary is specific: the keeper implementation is the identified weakness, the reported route reaches the router, and the attacker has not been attributed.Useful follow-ups include tracing the keeper and implementation deployers or owners, examining possible correspondence between the timed deposits and later withdrawals, and checking related proxies for similar exposure. These remain investigation leads, rather than established downstream matches.Any proposed downstream match or real-world identity would need its own supporting evidence.Figure 4. The report's conclusion and limits. The route accounts for a 200 ETH payout and twenty 10 ETH router deposits. Attacker identity and corresponding downstream withdrawals are not established; no exchange-deposit leg is recorded.Color key: Slate: keeper weakness. Sage: asset outcome. Amber: stated limits.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4 and 8–10.Continue from the twenty deposit transactionsThe twenty timed deposits provide a concrete starting point for further tracing. The prompt below asks SentinelTX to assess possible later withdrawal correspondence, clearly separating supported links from candidates.Request SentinelTX access · Sign inCopy this starting prompt:Investigate the October 6, 2026 Ethereum route from 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5fa to Tornado.Cash router 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b. Start with attack transaction 0xbb6940f7c2a1e68cafbae7bb9b94d09af9af06ec3a114f6996f2cab993f3a88c and the twenty 10 ETH deposits recorded from 06:19:35 to 06:28:35 UTC. The first deposit is 0xb8ecff9c129d8d9331c85558eaeddff29a38c4c16b71a40986acbf8f6febefeb; the last is 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbf. Assess whether available evidence supports any later withdrawal correspondence. Separate directly supported links from timing or amount-based candidates, do not infer common control from correlation alone, and include transaction links, the queried window, and query time. Keep the third-party keeper separate from MakerDAO core, and state when a path cannot be established.Source and address notesThis article adapts SentinelTX's CASE-ASYNCADB — 0x01EB957e…bDa5FA, dated October 6, 2026. The WETH mechanism rests on call-tree evidence; a separate token-event-log check was incomplete. Page references above identify the source of the article and explanatory figures.Attacker account: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5faAttack contract: 0xec997d2ad033277913d6002277353368e8321dcfKeeper proxy: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273Keeper implementation: 0x68399ed8aa33c5b43f863ee6782de492006a5546WETH contract: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Gas-funding pool: 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fcRouter recipient: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31bThe pool and router descriptions reproduce the report's labels. Account identifiers identify on-chain addresses, not the real-world identity of the attacker.