DNS hijack: the BSC collector and three-way split

A collector contract, one transaction-submitting account and three recurring recipients form the clearest BNB Smart Chain pattern in SentinelTX’s November 2 report on a reported DNS-hijack campaign. Three observed splits followed incoming transfers by five seconds at the recorded block timestamps. Each used the same recipients and approximately the same 55/30/15 proportions.

That pattern is narrower than the whole incident. It does not identify the people behind the addresses, establish how the DNS change happened, or prove that all reported losses passed through this collector. Some incoming amounts also carry explicit verification warnings in the source report. This article keeps those qualifications alongside the findings rather than treating a detailed transaction diagram as a complete account of the attack.

What this report covers

The source of this article is SentinelTX’s platform-generated report CASE-7766DAE6, dated November 2, 2026. Its analytic focus is BNB Smart Chain, chain ID 56, from October 31 at 00:00 to November 2 at 00:00 UTC. The executed query was broader: October 1, 2026, 00:24:30.552075 UTC through November 2, 2026, 00:24:30.552075 UTC. Those are different boundaries, not interchangeable descriptions of a single 48-hour search.

The report’s discovery source, a Bitquery investigation dated October 31, describes 12 DeFi websites registered through Name.com resolving to attacker-run copies containing a wallet drainer. It attributes a Step Drainer connection to Blockaid and reports $202,386 across 32 wallets on six chains, including $2,386 across seven BNB Chain wallets. These are attributed incident-wide claims reproduced in the PDF, not totals independently reconstructed by this BSC investigation. SentinelTX states that only the first 12,000 characters of that discovery page were reviewed.

The cause of the DNS change and the registrar’s role are not established by the chain evidence. The report makes no finding of registrar culpability. Likewise, the claimed drainer-family attribution is not an identity finding from the transactions below.

Source note: SentinelTX PDF, pages 4, 11–15 and 21. All transaction times in this article are UTC. The BSC subset must not be extrapolated into a six-chain loss estimate.

Follow the roles, not presumed identities

C1 is the Safe-type collector contract. X1 is the externally owned account that submitted every observed split. P1, P2 and P3 are recurring recipient addresses. S1 identifies the sender of the incoming transfer immediately preceding the example split.

The report records Safe-style execution calls and an ExecutionSuccess event for the seed transaction. That supports the execution relationship. It does not establish that X1 is a Safe owner: the owner set, signing threshold and modules were not read. All attribution lookups returned no label, which means no label was returned—not that attribution is impossible or that the addresses belong to one operator.

Figure 1. The observed BSC roles: S1 sends to C1; C1 distributes to P1, P2 and P3; X1 submits the execution call. The call relationship is distinct from a value-transfer relationship. Source: SentinelTX PDF, pages 7–10. Address ownership and Safe control remain unknown.

The five-second split

The example begins at 01:40:21 on October 31. The PDF records an incoming transfer from S1 to C1 of 0.483268458106 BNB, but explicitly flags that incoming amount as unverified in its narrative and conclusion. At 01:40:26, seed transaction T1 records three outgoing legs:

• Recipient: P1 — approximately 55% — Recorded outgoing amount: 0.2657976519583 BNB
• Recipient: P2 — approximately 30% — Recorded outgoing amount: 0.1449805374318 BNB
• Recipient: P3 — approximately 15% — Recorded outgoing amount: 0.0724902687159 BNB

The three outgoing amounts total 0.483268458106 BNB. Presenting those recorded legs does not remove the source’s separate warning about the incoming transfer. Nor is this one transaction’s total a whole-incident loss figure.

Figure 2. Three recorded outgoing legs in seed transaction T1, shown in BNB from a zero baseline. Total: 0.483268458106 BNB; proportions approximately 55/30/15. Source: SentinelTX PDF, pages 5–6, 9–10 and 17. These are transaction amounts, not recipient balances; the preceding incoming amount retains its verification warning.

Two other inflow-to-split pairs show the same five-second spacing: 01:00:55 to 01:01:00, and 01:42:38 to 01:42:43. The same X1 account submitted all three splits to the same three recipients. This repeated execution pattern is the basis for the report’s revenue-sharing interpretation. The allocation of specific business roles—such as kit operator, affiliate or infrastructure provider—is an assessment, not an observed identification of three people.

The largest reported inflow did not split

The collector summary lists four incoming transfers totaling 3.09671583071052685 BNB and nine outgoing legs across three split transactions totaling 0.828208994212836824 BNB. Their reported difference is 2.268506836497690026 BNB. These are the PDF’s reconciliation figures; its warnings on underlying incoming amounts still apply.

That difference matches the collector balance recorded at block 131144415, on November 2 at 00:24:09 UTC. This balance observation is later than the stated analytic cutoff. It must not be presented as a continuously monitored or current balance.

The corresponding 2.268506836497690026 BNB inflow, associated with block 130768877 at 01:26:51 on October 31, is explicitly classified as needing corroboration. It is also the largest reported collector inflow and the one not forwarded in the observed splits. The PDF therefore qualifies the discovery source’s broad claim that almost every drain followed the same split: that description does not capture this largest BSC transfer.

The source offers possible explanations, including execution failure, a deliberate hold or an attempted transaction that reverted. It does not choose between them. An earlier zero-value executor call at 01:16:29 was not decoded. The missing explanation remains a lead, not a finding that can be filled in from the later balance match.

Receipts are not balances

The payout-wallet figures cover gross receipts in the 32-day lookback. They include more than the three collector payments and should not be used as a current asset inventory.

• Recipient: P1 — Gross receipts reported in the lookback: 0.551359380509872312 BNB across 4 receipts; gross sent: 0 BNB
• Recipient: P2 — Gross receipts reported in the lookback: 0.300741480278112169 BNB across 4 receipts; gross sent: 0 BNB
• Recipient: P3 — Gross receipts reported in the lookback: 0.170375356553192358 BNB across 6 receipts; gross sent: 0 BNB

The report says that one additional receipt to P1, one to P2 and three to P3 were not itemized. It considers a direct-to-payout route possible, but the missing senders and transaction detail prevent confirmation. P3 also has history from September 23, before the reported incident. Earlier activity cannot simply be relabeled as proceeds of this campaign.

There is an important source contradiction here. The PDF’s recovery discussion describes approximately 1.0225 BNB in gross receipts as sitting across the payout wallets, while its limitations explicitly say their current balances were not read. The latter qualification prevents treating that receipt total as an established present balance or recoverable amount. No exchange deposit, bridge or DEX endpoint was identified in the examined evidence; that is a scoped absence of observation, not proof that later or cross-chain exits did not occur.

Signed transfers and reported deception

The four collector inflows are described as plain native-BNB transfers signed by their sending wallets. The retained BSC rows do not show an approve, permit or transferFrom pull. This distinction matters: the visible movement is not presented as a token allowance being exercised by a third party.

A signature establishes the transaction-signing relationship, not whether the person understood the action shown by the interface. The DNS-hijacked-front-end explanation remains a reported allegation in the source. The presence of a valid signature neither establishes nor disproves that deception.

The report also excludes suspected unsolicited token distributions from its economic interpretation, including 3.0 units of an unidentified-symbol token and 5.0 TeslaSI. Their units are not BNB and must not be added to BNB totals. Their liquidity was not checked. Shared spam counterparties between addresses are not evidence of common control.

Where the evidence stops

The PDF contains both structured rows labeled verified and narrative warnings that some retained incoming quantities cannot be confirmed. It also gives some blocks, hashes and precise amounts in its chronology or tables while its limitations say those details were not recorded or were available only at displayed precision. These are internal differences in the source, not discrepancies resolved by this article. In particular, a structured “verified” label does not justify silently upgrading an amount the report’s conclusion leaves unverified.

The coverage appendix records 19 retained movement rows spanning October 31, 01:00:55 to 01:51:45 UTC. It does not establish enforcement of the requested historical cutoff. The collector’s internal-call history is incomplete, and 12 of 22 transaction-list entries were reviewed. The query interval, retained-row interval and later balance observation therefore answer different questions.

The PDF’s optimistic recovery assessment is professional opinion, not a recovery guarantee. With no identified custodial endpoint and payout balances unread, this record does not establish an immediately available freeze target. No recovery, freeze or contact with an exchange is reported as completed.

Conclusion: a repeatable pattern, not a complete attribution

The strongest story is a bounded one: a Safe-type collector distributed three observed transfers to the same recipients, using the same submitting account and repeated five-second timing. The largest reported inflow did not follow that path. Address ownership, the DNS change’s cause and subsequent destinations remain unresolved.

The report’s priority leads are the Safe’s owner configuration and creation trail, X1’s funding, the unitemized payout receipts and the undecoded executor call. These are proposed investigative steps, not work represented as already performed. The case illustrates why transaction structure, attribution and recoverability must remain separate even when a distribution pattern is visually clear.

Figure 3. Conclusion and evidence boundaries. Recorded: three splits, one submitting account and recurring recipients. Not established: address ownership, the DNS change’s cause or final destinations. Some incoming amounts remain unverified, and payout balances were not read. Source: SentinelTX PDF, pages 13–15, 21–22.

Reference keys

The following identifiers are transcribed from the source PDF. Role labels are local reading aids, not identity claims.

Address key — C1, collector: 0x24497068ca4166ca32a04ae530ce00cf79755bd5. X1, submitting account: 0x33dfc810365193bff54326812d7df34b3e438da3. S1, example sender: 0x4fa1daf1e03759e802452f5543171fa19c0209d7.

Recipient key — P1: 0x012f89ff307568f8409bbe379ca92ed41bc4d386. P2: 0x7bf2037264efbff55bd52777772779c1d9e87695. P3: 0x5aff449b63c033df386af0c45384cd20c5918dbf.

Transaction key — T1, seed split: 0x39b36904796f53ca801bbd393ba09b1169fe3b87462719a177efde2e30967379. Preceding incoming transfer: 0x911b11cd01af297d62933632d5d59e5adc84e5f88e4b2668ef4d989b8c16c151. Other observed splits: 0xad1e8a632c5ad86b49b571384fb02e529da73e8617112a87907b0cf4271e29b6 and 0x96db9345ea17d232ee659eb55debb75c11e723e0f92dea726e293cef5d7ad86e.

Source note: Adapted from the actual SentinelTX platform-generated PDF, CASE-7766DAE6, November 2, 2026, 25 pages. References to external reporting are attributed as they appear in that PDF. No public download URL for the PDF is asserted.