Third-party MakerDAO keeper exploit sends 200 ETH to Tornado Cash

ChainBounty · Investigation analysis · October 6, 2026

A 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 findings

• The 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 router
• The keeper proxy delegated selector 0x8804d1de to an unprotected exit path in its implementation
• The router is the last recorded recipient on this route. Attacker identity and any exchange-deposit leg remain unestablished

1. A funded account deployed two contracts before the drain

The 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 implementation

The 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 router

The 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 amount

The 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.

Conclusion

SentinelTX'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 transactions

The 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 in

Copy 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 notes

This 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: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5fa
• Attack contract: 0xec997d2ad033277913d6002277353368e8321dcf
• Keeper proxy: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273
• Keeper implementation: 0x68399ed8aa33c5b43f863ee6782de492006a5546
• WETH contract: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
• Gas-funding pool: 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fc
• Router recipient: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b

The pool and router descriptions reproduce the report's labels. Account identifiers identify on-chain addresses, not the real-world identity of the attacker.