Banana Gun oracle-messenger information leak — Ethereum — 2024-09-19

• OAK-T9.004 (Access-Control Misconfiguration) as the extraction mechanism. The proximate cause per Banana Gun's post-mortem and SlowMist's forensic write-up was an information-leak / privilege-misconfiguration in Banana Gun's oracle messenger contract that exposed user-bot interaction data and the corresponding user-wallet signing surface to an attacker who could then trigger drains as if they were the legitimate bot.
• OAK-T4.x (User-side / wallet-and-approval surface family — broadly construed). The affected wallets were managed-by-bot user wallets — a hybrid wallet architecture where the bot held effective control over a user-funded address for trade execution. The drain exploited this hybrid-control surface: by intercepting the bot-side messaging channel that authorised wallet operations, the attacker effectively impersonated the bot to the user wallets, invoking outflows the user had broadly pre-authorised for trading purposes. T4.001 (permit2-authority misuse) and T4.004 (allowance-approve drainer) are sibling Techniques in the same family; the Banana Gun case is the canonical 2024 worked example for trading-bot-managed-wallet hybrid-control compromise, which OAK v0.1 does not have an exact entry-vector match for.

Summary

Banana Gun is one of the leading Telegram-based on-chain trading bots, launched in 2023 and operating across Ethereum, Solana, Base, and BNB Chain. The bot's user model: a Telegram user funds a bot-managed wallet (created and controlled by Banana Gun on the user's behalf), supplies trading parameters via Telegram chat, and the bot executes trades on-chain at the user's instruction. The hybrid-control architecture — user-funded address with bot-side execution authority — is a load-bearing design choice for the user-experience surface (sub-second latency from Telegram message to on-chain trade) and a load-bearing trust assumption for the security surface (the bot's signing authority is the user's signing authority for the funded address).

On 2024-09-19 at approximately 22:30 UTC, an attacker began a concentrated drain of Ethereum-side Banana Gun user wallets. Within roughly an hour, 563 ETH ($3M at the prevailing price) was extracted from approximately 11 distinct user wallets. Banana Gun acknowledged the incident publicly the same evening, paused affected bot functionality, and within hours committed to make affected users whole from operating reserves.

The proximate cause — per Banana Gun's post-mortem and SlowMist's forensic commentary — was an information-leak vulnerability in Banana Gun's oracle messenger contract, the off-chain-to-on-chain messaging surface that the bot used to monitor user-bot interactions and trigger trades. The vulnerability allowed an attacker to monitor user-bot interactions and the corresponding wallet-signing surface in real time; this monitoring capability admitted the attacker into a position where they could front-run or impersonate bot-initiated wallet operations, draining user wallets through the bot's own legitimate authority surface. The on-chain manifestation looks like the bot draining user wallets to attacker-controlled addresses; the off-chain manifestation is the attacker exploiting the messenger contract's information-leak to time and authorise the drain transactions.

For OAK's purposes the case is a hybrid: the extraction mechanism sits in T9.004 (access-control / privilege-boundary misconfiguration in the messenger contract), and the target surface sits in the T4.x user-wallet / approval family broadly construed (the bot-managed user wallets were drained through a surface the user had broadly pre-authorised for trading). OAK v0.1 does not have an exact entry-vector match for trading-bot-managed-wallet hybrid-control compromise; Banana Gun is the canonical 2024 worked example of this gap.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Banana Gun deploys oracle messenger contract to bridge off-chain bot-to-user interactions to on-chain wallet operations; messenger contract carries an information-leak / privilege-boundary misconfiguration that exposes user-bot interaction data and the corresponding wallet-signing authority surface	(custody-surface precondition)
Pre-event	Attacker discovers the messenger-contract information-leak; deploys monitoring infrastructure to track user-bot interactions in real time	T9.004 setup
2024-09-19 ~22:30	Attacker begins concentrated drain of Ethereum-side Banana Gun user wallets; uses the messenger-contract leak to authorise outflows under the bot's own legitimate execution authority	T9.004 + T4.x extraction
2024-09-19 ~22:30 — ~23:30	Drain continues across approximately 11 user wallets; cumulative outflow 563 ETH ($3M)	T9.004 / T4.x repeat
2024-09-19 (within hours)	Banana Gun operations team detects the drain; pauses affected bot functionality; publicly acknowledges the incident on X and Telegram	(operator response)
2024-09-19 (later)	Banana Gun publicly commits to make affected users whole from operating reserves	(recovery commitment)
2024-09-19 onward	Attacker laundering routes proceeds through Tornado Cash and standard cross-chain laundering rails	T7.001 / T7.003 (off this example's framing)
2024-09-20 onward	Banana Gun publishes post-mortem identifying the messenger-contract information-leak as the proximate cause; engages forensic firms; ships fix	(transparency / cohort signal)
2024-09 onward	Reimbursement of affected users from operating reserves proceeds in stages	(recovery state)

What defenders observed

• Trading-bot-managed-wallet hybrid-control architecture has an underexamined attack surface. The Banana Gun case demonstrates that when a bot holds effective signing authority over a user-funded address, any compromise of the bot's authorisation surface is structurally equivalent to compromise of the user's wallet — even if the user's seed phrase was never exposed and the user took no defensive action. The hybrid-control architecture trades user-experience latency (sub-second Telegram-to-trade) against an expanded trust surface (the bot's signing infrastructure becomes the user's custody surface). Defender threat models for users of trading-bot products should treat the bot's signing infrastructure as part of the wallet's threat model, with corresponding due-diligence questions about messenger-contract design, off-chain authorisation flows, and operator-side key custody.
• Information-leak in cross-domain messaging surfaces is a distinct sub-pattern of T9.004. The Banana Gun messenger-contract vulnerability was not a missing access-control modifier on a state-mutating function in the canonical T9.004 sense; it was an information-leak that exposed off-chain user-bot interaction data and the corresponding on-chain wallet-signing authority surface to an attacker who could observe and act on that data faster than the legitimate bot. Defender static-analysis tooling that scans for missing onlyOwner / onlyAdmin modifiers on state-mutating functions does not cover this sub-pattern; the analyser needs to model the information flow between off-chain authorisation events and on-chain wallet operations to flag it.
• Pseudonymous-attacker incidents on user-facing products are sometimes followed by team-funded reimbursement. Banana Gun's commitment to reimburse affected users from operating reserves is a relatively unusual outcome for pseudonymous-attacker DeFi-adjacent incidents; the more common base-rate outcome is total user-side loss (Penpie, Onyx). The reimbursement commitment is a function of (a) the affected-user count being small enough (~11) that operating-reserve coverage was tractable, (b) the protocol-side product being user-trust-dependent in a way that DeFi yield protocols typically are not, and (c) the operator team having a discoverable identity and operating reserves to draw on. Defender ecosystem-level monitoring should distinguish these recovery profiles when summarising incident outcomes for users.
• Concentrated-target-set drains are an identifiable pattern. The Banana Gun drain affected ~11 user wallets in roughly an hour. This is a small-N, high-concentration extraction pattern characteristic of a privileged-position attacker who had targeted access to a small set of high-value wallets via a shared-infrastructure compromise — distinct from broad-base drainer / approval-phishing patterns that affect hundreds-to-thousands of wallets across days or weeks. The on-chain signature is identifiable (concentrated outflows from related bot-managed addresses to a small set of attacker addresses within a tight time window) and runtime monitoring services can flag it; user-side detection latency was operator-acceptable but not faster than the drain window.
• Attribution is pseudonymous and is the realistic attribution status for this class. Funding and laundering both routed through standard mixer / cross-chain rails; no industry forensics provider has converted the on-chain analysis into a named-individual claim. There is no public OAK-G01 attribution. The relatively small loss size (~$3M) and the small affected-user population are consistent with a pseudonymous-actor profile rather than a state-actor profile.

What this example tells contributors writing future Technique pages

• OAK-T9.004 covers information-leak-as-privilege-boundary-violation, not only missing-modifier bugs. The Banana Gun case is the canonical 2024 worked example for the information-leak / privilege-boundary-violation sub-pattern of T9.004. Worked examples should make this sub-pattern explicit; the contract was not exploitable through a missing onlyOwner modifier, it was exploitable through the existence of an information surface that admitted the attacker into a position equivalent to authorised access. The DeltaPrime case at /examples/2024-09-deltaprime.md and the Tapioca DAO case at /examples/2024-10-tapioca.md are the cohort companions for the upgrade-authority abuse sub-pattern; Banana Gun is the information-leak sub-pattern companion.
• The OAK-T4.x family needs explicit treatment of trading-bot-managed-wallet architectures. OAK v0.1 documents user-side wallet-and-approval-surface compromise primarily through the lens of approval-drainer phishing (T4.004) and direct wallet-software supply-chain compromise (T11.002). The trading-bot-managed-wallet hybrid-control architecture sits between these: not a phishing surface, not a wallet-software surface, but a user-delegated-authority surface to a third-party bot operator. A future v0.x update should add explicit treatment of this architecture, with Banana Gun as the canonical worked example. The broader Telegram-trading-bot category (Banana Gun, Maestro, BonkBot, Trojan, Sigma) is large and growing; the entry-vector gap will continue to be exploited until OAK and the broader ecosystem catch up to the architecture.
• Operator-team reimbursement is a distinct recovery class and should be tracked explicitly. The Banana Gun outcome (operator-funded full reimbursement of all affected users from operating reserves) is materially different from on-chain recovery (Cetus 2025, Euler 2023), attacker-return-of-funds (Tapioca 2024, Thala 2024), and zero-recovery (Phemex 2025, Penpie 2024). Contributors writing recovery sections should treat operator-team reimbursement as a fourth recovery class with its own preconditions (small-N affected population, operator with discoverable identity and reserves, operator-side product with user-trust-dependent business model).
• Concentrated-target-set drains via shared-infrastructure compromise are a 2024 pattern worth its own taxonomy treatment. The Banana Gun case is one of several 2024 incidents (alongside the broader Inferno Drainer / approval-drainer ecosystem at /examples/2024-10-inferno-drainer-handover.md and the address-poisoning surge at /examples/2024-05-address-poisoning-68m.md) where the attacker leveraged a shared-infrastructure position to concentrate a small-N high-value drain rather than broadly targeting users. Worked examples in this class should preserve the distinction between the shared-infrastructure compromise (the privileged-position precondition) and the on-chain extraction (the drain mechanism), the same way the Penpie example at /examples/2024-09-penpie.md distinguishes the T9.004 precondition (permissionless registration) from the T9.005 extraction (cross-protocol reentrancy).

Public references

• [bananagunpostmortem2024] — Banana Gun operator-side post-mortem covering the messenger-contract information-leak root cause, the affected-wallet count, and the reimbursement commitment.
• [slowmistbananagun2024] — SlowMist incident analysis covering the messenger-contract vulnerability and the on-chain extraction shape.
• [peckshieldbananagun2024] — PeckShield headline figures and on-chain analytics for the Banana Gun September 2024 drain.
• [certikbananagun2024] — CertiK forensic commentary on the trading-bot hybrid-control architecture and the privilege-boundary-violation sub-pattern.
• [rektbananagun2024] — Rekt public-facing incident summary.

Discussion

Banana Gun is OAK's canonical 2024 worked example of trading-bot-managed-wallet hybrid-control compromise via off-chain-to-on-chain messaging information-leak and is a structurally novel addition to the corpus. Unlike the September 2024 cohort companions Onyx (T9.005 rounding-error), Penpie (T9.005 reentrancy), DeltaPrime (T9.004 upgrade-authority abuse), and Indodax (T11-shaped operator-internal compromise), Banana Gun targets a user-facing trading-bot product with a hybrid-control wallet architecture that sits between OAK v0.1's protocol-layer and user-wallet-layer Technique families.

The hybrid-control architecture — user-funded wallet under bot-side execution authority — is the structurally important feature. The architecture is widespread across the 2024 Telegram-trading-bot category (Banana Gun, Maestro, BonkBot, Trojan, Sigma, plus the Solana-specialised Photon and Pump-side bots), and the Banana Gun case is the September 2024 datapoint that establishes the category as a first-class OAK target surface rather than a niche. Defender threat models for users of these products should treat the bot's signing infrastructure as part of the wallet's threat model, with explicit due-diligence questions about messenger-contract design, off-chain authorisation flows, and operator-side key custody. The Banana Gun-specific lesson (information-leak in the messenger contract specifically) generalises to a category-level lesson about the privacy and integrity of off-chain-to-on-chain messaging surfaces in trading-bot products.

The reimbursement outcome is the part of the case that contributors should not over-generalise from. Banana Gun was able to make 11 affected users whole from operating reserves because the affected-user population was small, the per-user loss was tractable in aggregate ($3M total), and the operator team had discoverable identity and reserves. The same outcome is structurally implausible for incidents with hundreds-to-thousands of affected users (the Penpie, Onyx, Phemex base-rate cases) or with operator teams that lack discoverable identity (the broader pseudonymous-protocol category). Contributors writing recovery sections should resist letting the Banana Gun outcome anchor expectations for trading-bot incidents generally; the more representative outcome for a larger-N or pseudonymous-team trading-bot incident is partial-or-zero user-side recovery.

The attribution status is pseudonymous and should remain so absent new public evidence. The relatively small loss size and the concentrated-target-set extraction shape are consistent with a pseudonymous-actor profile rather than a state-actor profile; contributors should not fold Banana Gun into the temporally-adjacent OAK-G01 wave by analogy.