The phishing kit didn't crack a password. It didn't brute-force a 2FA code in a race against a six-digit window. It sat between a man and the server he trusted, watched him type the code, and forwarded it upstream in real time — while the man's AI assistant looked at the same malicious link and told him it looked legitimate.
That is the detail the industry scrolled past on September 28. Kong Jianping, chairman of Nano Labs — a NASDAQ-listed company whose balance sheet is built around a BNB treasury strategy — lost control of his X account for a window of time long enough for the attacker to publish scam material to his followers. The account was recovered. The story was filed under "another KOL got phished" and everyone moved on.
Everyone moved too fast. Because the most interesting thing here isn't that a high-profile account was hijacked. It's that when I sat down and mapped the attack chain, the single point of failure wasn't the human. It wasn't even the missing hardware key. It was the layer everyone in this cycle is racing to plug into every workflow: the AI assistant, granted the role of trust arbiter, with no cryptographic ability to verify anything.
Tracing the gas leaks before the code compiles. That's what this is. Let me show you where the leaks are.
Context: Why This Account, Why This Moment
To understand the technical weight of this event, you have to understand what Kong Jianping actually controls — not as a personality, but as a node in a distribution network.
The treasury-company wave
Through 2025 and into this cycle, a specific corporate structure went from curiosity to category: the crypto treasury company. The model is deceptively simple. A listed shell — or an existing operating company — issues equity or debt, parks the proceeds into a single crypto asset, and then re-rates on the market as a leveraged proxy for that asset. MicroStrategy did it with BTC. Then a dozen imitators did it with BTC. Then the pattern fractured into alt-asset treasuries: ETH treasuries, SOL treasuries, and — relevant here — BNB treasuries.
Nano Labs sits in the BNB lane. The company is publicly listed in the United States, which matters for a reason most crypto-native readers underweight: a US-listed chairman is a regulated disclosure node, not just a social media account. When his X account speaks, it carries a different legal and reputational signature than a pseudonymous founder's.
I've spent enough time on the quant side of listed instruments to know how this taxonomy is priced. The market doesn't value a BNB treasury company on its BNB holdings alone. It values the credibility of the structure — the governance, the custody arrangements, the disclosure discipline, and, yes, the operational security posture of the people whose names are on the filings. A treasury company is a trust wrapper around an asset. Crack the trust wrapper and you've introduced a discount, however small.
The window nobody timed
Here's what the coverage glossed over. The account was compromised, scam content was distributed, and control was restored "quickly." The word "quickly" is doing an enormous amount of narrative work. From a pure incident-response standpoint, the only number that matters is the exposure window — the delta between when the attacker posted and when the legitimate owner or platform regained control. Every second in that window is a second a follower could have clicked a malicious link, approved a wallet signature, or sent funds to a drainer address.
Nano Labs did not disclose that duration. Neither did Kong Jianping, at least not in the material I could parse. And that silence — the gap between "we recovered control" and "here's how long the attacker had the microphone" — is exactly the kind of thing I look at first. Silence between the blocks tells the real story. The absence of a number is a data point about how much the disclosure was optimized for reassurance rather than forensic clarity.
I want to be precise here and not overstate. This is a reputation and security event, not a protocol failure. On a one-to-five materiality scale for a listed company, it rounds to noise. I'll show the math on that later. But the mechanics of the attack are not noise. They are a template, and templates get reused.
Core: The Attack Chain, Reverse-Engineered
Let me do what I'd do with any system I was hired to audit: decompose it into stages, identify the trust assumption at each stage, and mark where the assumption is falsifiable. The whole event is five stages. Four of them are conventional. The fifth is new.
Stage 1 — Delivery: the public email as the perimeter
The entry vector was email. Specifically, an address that was publicly accessible — the kind of address a public figure publishes so vendors, journalists, and counterparties can reach him.
This is a perimeter design choice, and it's almost always the wrong one. Here's the failure mode in plain terms: when your reachable-by-the-public identity (the public mailbox) and your security-critical identity (the account-recovery mailbox, the 2FA anchor, the SSO root) share infrastructure or even share visibility, you have collapsed two trust zones into one. An attacker who can email you can now also attempt recovery flows, password resets, and phishing against the same surface.
I learned this the hard way on the audit side. In 2017, while I was a junior quant analyst in Boston, I spent four months pulling apart the Golem ICO distribution contract by hand. I wasn't looking for the front-page vulnerabilities — I was looking for the seams between components, the places where two subsystems assumed the other was doing validation. I wrote a Python script that parsed assembly opcodes so I could trace what the compiler actually emitted, not what the source implied. What I found was a critical integer overflow in the batch claim function. The point is that the bug wasn't in either subsystem alone. It was in the boundary.
The public-email-as-perimeter is the same class of bug at the human layer. The boundary between "reachable" and "authenticated" was never drawn. An attacker only had to be deliverable, not trusted.
Stage 2 — Spoofing: the visual conflation problem
The phishing page impersonated X's official verification surface. This is the oldest trick in the kit playbook, and it still works for a reason that has nothing to do with user intelligence: the human visual system authenticates by pattern, and the browser security model authenticates by cryptographic origin.
These two systems are fundamentally incompatible. Your eyes see a padlock, a familiar font, a logo, a layout that matches muscle memory. Your browser sees an X.509 certificate chained to a certificate authority, a domain string, and a Same-Origin Policy enforcement boundary. The attacker only has to defeat the first system to win, because the second system doesn't speak up unless you read the URL bar with the same paranoia a security engineer does.
Modern AiTM phishing kits — Evilginx, Modlishka, and their descendants — don't just clone the login page. They sit as a reverse proxy between the victim and the real service. The victim's browser holds a legitimate TLS session with the attacker's proxy. The proxy holds a legitimate TLS session with the real X servers. The victim sees the real site's behavior, because they are talking to a server that's talking to the real site. The URL might even display a plausible subdomain. The certificate might be valid — for the attacker's domain, which the victim never reads closely.
This is the stage where "just be careful" fails as advice. Carefulness is a human-layer control applied to a cryptographic-layer problem. It's the equivalent of checking your seatbelt by eye instead of waiting for the click.
Stage 3 — AI bypass: the confused deputy enters
Now the new part. According to Kong Jianping's own account of the incident, an AI assistant misclassified the malicious link as an official page. That single sentence is the most important sentence in the entire event, and it has been almost universally misread.
The instinct is to file it as "AI made a mistake, users should double-check." That reading is shallow. The correct reading is that the AI assistant was operating as a confused deputy.
The confused deputy problem is a classic security concept, and it's worth stating precisely because the AI industry keeps half-reinventing it. A confused deputy is a component that has authority and is trusted by other components, but is manipulated into wielding that authority on behalf of an attacker. The component isn't compromised. It's not malfunctioning. It's doing exactly what it's designed to do — being helpful, passing judgment within its authority — but the attacker has found a way to supply it with inputs that make its "correct" behavior harmful.
The AI assistant was granted a slice of authority: "tell me if this link looks safe." It exercised that authority. It got it wrong. And critically, the user deferred to it — because that is the entire point of having an assistant.
Why did it get it wrong? Because the signals it is capable of evaluating are semantic and visual, while the signals that actually determine safety are cryptographic and infrastructural. Let me be concrete about what a model cannot reliably do versus what actually matters:
| What the AI "sees" | What actually determines safety | |---|---| | Page layout, logo, fonts | TLS certificate chain and issuing CA | | Text content plausibility | Registered domain (the real eTLD+1) | | Whether the page "looks official" | WHOIS registration date and registrant | | Semantic coherence | DNS records, CNAME chains, CDN origin | | Whether buttons say "Verify" | Same-Origin Policy and origin-bound credentials |
A language model evaluating a phishing page is like a food critic evaluating a restaurant's hygiene by reading the menu. The menu can be beautifully written. The kitchen can be a biohazard. The critic has no instrument that measures bacteria.
This is a structural limitation, not a training-data problem. You could feed the model every phishing page ever recorded, and it would still be guessing, because the model has no privileged, tamper-evident channel to the ground truth. It reads the same pixels the victim reads. It is, at best, a slightly more articulate victim.
And here's the part that should worry every builder reading this: the model is often confidently wrong. Language models are calibrated to produce fluent, decisive outputs. "This link looks legitimate" lands with the same linguistic confidence whether it's based on real verification or on vibes. That calibration mismatch is what turns a helpful assistant into an attack surface.
Stage 4 — Credential theft: the OTP that wasn't one-time at all
After the AI gave its blessing, the attacker's page prompted for an email verification code. The victim entered it. The account fell.
This is the technical heart of it, and it deserves the coldest possible treatment, because the industry has been telling users for a decade that OTP-based 2FA "protects" them, and this event is a live demonstration that it does not protect them against the current generation of attacks.
Here's the mechanism. A one-time password is one-time in theory — it's valid for a single authentication. But "one-time" describes a property of the code, not a property of the channel. An AiTM proxy captures the code the instant the victim types it and relays it to the real server faster than the victim's own session completes. The code is used once. It just gets used by the attacker first.
There is no race the defender wins here, because the defender isn't running the race. The victim hands over the code voluntarily, to a page that looks exactly like the page that's supposed to ask for it. The proxy holds a live session with the real server. The victim's OTP arrives at the proxy, gets forwarded, and completes the attacker's login. The victim may then see a "success" page — because from the real server's perspective, someone just successfully logged in.
Let me put the failure in engineering terms, because that's the only language the fix will be written in:
OTP-based 2FA authenticates the possession of a code, not the identity of the origin. It answers the question "does this session holder have the current code?" It does not answer "is this session holder the same browser/origin/device that the code was intended for?" An AiTM proxy is, by construction, holding a different origin than the victim's browser. OTP has no mechanism to notice.
The verification code sat in an email. The same email surface that was the delivery vector in Stage 1. The loop closed on itself. The perimeter that was never drawn in Stage 1 was exactly the perimeter that needed to exist in Stage 4.
Stage 5 — Distribution: the payoff, and why the account mattered
Control in hand, the attacker posted scam content to Kong Jianping's followers.
I want to be surgical about why this — not the account takeover, but the distribution — is the actual product being bought and sold in this attack. The account itself is worth something, but not much. You can't move its funds. You can't access its DMs cheaply without triggering alarms. What you can do, for the duration of your access, is speak with someone else's trust.
A listed chairman's X account is not a feed. It's a trust broadcast. Followers, many of whom are investors, read it with a discount applied for plausibility precisely because the account belongs to a named, credentialed, publicly accountable person. Every post inherits an unearned trust premium from the identity behind it.
The attacker bought, for a window measured in minutes to hours, the ability to redirect that trust toward a malicious endpoint. That's the ROI. Not the account. The followers' credulity, harvested at wholesale.
Where the Trust Chain Actually Broke
I want to lay out the full chain now, because the industry keeps pointing at a single link and calling it the problem. It wasn't one link. It was five links, and each one was a trust assumption with no independent verification.
[Delivery] [Spoofing] [AI Arbitration] [Credential] [Distribution]
Public email → Fake verify page → AI says "looks ok" → OTP typed in → Scam posted
↓ ↓ ↓ ↓ ↓
"Deliverable" "Looks official" "AI is trusted" "Code works" "Followers trust"
= reachable = no origin check = no crypto proof = origin-blind = no re-verificationRead that bottom row. Every single link relies on a judgment — a subjective, human-or-AI-assessed property. Not one link relies on a cryptographic fact. Independent verification was absent at every stage. That's not one mistake. That's a trust-chain design, and it's the design most people in this industry are running right now, whether they've written it down or not.
I've seen this exact pattern across two decades of systems, and I'll say the thing that sounds harsh but is true: the most expensive way to be wrong is to be wrong at every layer and correct at none. A single cryptographic control at Stage 4 — a hardware key — would have collapsed the entire chain. Stages 1, 2, 3, and 5 would all have become irrelevant, because the attacker could not have completed a login. They could have spoofed every page, fooled every AI, harvested every code, and still been locked out of the origin-bound credential.
That's the architecture of antifragility: one properly placed cryptographic requirement makes four social-engineering stages worthless. The system doesn't need to be robust at every layer. It needs to be unbreakable at the layer where credentials are exercised.
Contrarian: The Industry Is Blaming the Wrong Variable
Here's where I'll part ways with the consensus reading of this event, and I'll do it with data rather than assertion.
The consensus reading, and why it's lazy
The prevailing take is some version of: "High-profile accounts get targeted; this is a sophisticated attacker; users need to be more careful and use better security." It packages the event as a user-education problem.
I reject that framing, and the rejection is technical, not rhetorical. If the failure were a knowledge deficit, then the attack would fail against knowledgeable users. But the victim was a veteran crypto industry figure — someone whose entire professional life is spent in a domain defined by adversarial security. This was not a naive user clicking a "You've won" popup. This was an experienced operator who used an AI tool specifically because it was supposed to add a layer of judgment, and the tool itself supplied the false confidence.
When the attack succeeds against the experienced, defensive, and well-tooled, the variable you're blaming isn't the variable that failed. The failure was architectural, and the architecture was "we trust soft judgments where we should require hard proofs."
I ran into this same category error during the LUNA/UST collapse in 2022. When TerraUSD broke, the popular post-mortem was "the model failed because it was a bad model." But I spent three weeks back-testing the seigniorage mechanism against historical oracle data, and the actual finding was subtler: the model was fine within its assumptions, and the assumptions were the vulnerability. Specifically, the death spiral was effectively inevitable once the confidence ratio dropped below roughly 60% — not because the math broke, but because the math depended on faith staying above a threshold, and faith is not a measurable input a model can hedge.
This phishing event is the same shape. The "model" — the human-plus-AI-plus-2FA stack — performed exactly as designed. Every component did its job. The design itself assumed that "the AI said it's fine" and "the code matches" were sufficient proofs. They never were. The assumptions were the attack surface.
The AI-as-trust-arbiter trap, stated precisely
I need to be careful not to throw AI out — I run AI in production. In 2026 I led the build of an autonomous trading agent that executed on on-chain sentiment signals, trained on 18 months of proprietary order book data, with latency targets under 50ms. It caught an anomalous whale move on Solana and executed a counter-trade for a 12% ROI in four minutes. I'm not an AI skeptic. I'm an AI boundary skeptic.
The boundary that matters here is this: an AI agent is only safe to trust for decisions whose failure mode is bounded. When my trading agent was wrong, it lost a position — a bounded, pre-sized, kill-switched loss. I kept manual kill-switches precisely because automated systems must not override fundamental risk management. The loss was survivable by design.
But "is this link safe?" is a decision whose failure mode is unbounded. Getting it wrong doesn't cost you a bounded position. It costs you your account, and then it costs your followers their funds. The AI was asked to arbitrate a decision whose downside had no floor, using a judgment method with no floor on its correctness. That's the confused-deputy risk: the assistant was trusted with authority it could not exercise safely, on a question it could not actually answer.
The industry is racing to wire AI assistants into every workflow — email triage, transaction signing, contract approval, wallet monitoring. Every one of those integrations creates a new deputy. The question nobody is asking loudly enough is: what authority are we handing the deputy, and is that authority bounded? If the deputy can be instructed to "verify" and then acts on soft signals, the attacker doesn't need to compromise the AI. They just need to convince it.
The distribution-value thesis
The final contrarian point is about what's actually being stolen. Most coverage treats "account got hacked, scam posted" as the effect. I think the scam isn't the effect. It's the product.
In an attention economy, the scarce resource isn't capital — there's plenty of that in this cycle. It's verifiable attention. Social accounts of credentialed figures are the highest-trust attention nodes available, and their value is exactly proportional to the trust premium of the identity behind them. That makes high-credential, low-defensibility accounts the single most efficient target class in the ecosystem.
The attacker's decision tree here is not random. A sophisticated phishing crew, using an AiTM kit, targeting a named chairman of a listed treasury company with a specific public-facing mailbox — the attacker knew who they were going after. This was either reconnaissance-driven targeting or a systematic sweep across a database of crypto-adjacent executive emails. Either way, the attacker's mental model was: find the trust node, spend a few dollars on a kit, harvest a window of trusted speech. The account is the loot. The followers are the payout.
The rug wasn't the hack. The rug is the assumption that follows every post from an account like this — that it's still the human you think it is. There is no technical mechanism enforcing that assumption. That's not a knowledge problem you can educate away. That's a missing control.
What Actually Holds: The Case for Origin-Bound Credentials
I've spent a lot of this article describing a failure. Let me spend the same rigor on the fix, because the fix already exists, ships today, and is used by a vanishingly small fraction of crypto's most at-risk accounts.
The mechanics of the only 2FA that survives AiTM
FIDO2 / WebAuthn, and the hardware security keys (YubiKey and its peers) that implement them, work on a principle that is categorically different from OTP. Let me state it mechanically, because the difference is the whole game.
When you register a hardware key with a service, the key generates a public/private keypair and the private key never leaves the device. It's sealed in secure hardware. When you authenticate, the server issues a challenge, and the key signs that challenge with the private key. Critically — and this is the entire security property — the signature is scoped to the origin (the domain) of the requesting site.
This is called origin binding. Read it again, because it's the line that makes phishing structurally impossible against a hardware key: the credential is cryptographically bound to a specific domain. When the AiTM proxy tries to get the victim's browser to authenticate, the browser checks the domain. If the domain isn't the one the credential was registered for, the browser refuses to invoke the key for that origin at all. There's no signature to capture. There's no code to forward. The key simply doesn't answer for the wrong domain.
Compare the two models on the one axis that matters:
| Property | OTP (SMS/Email/App) | FIDO2 / WebAuthn | |---|---|---| | What it proves | You possess a code | You possess a key for this origin | | Can it be relayed by AiTM? | Yes, trivially | No — origin-bound | | Does the browser verify the origin? | Not applicable | Yes, before invoking the key | | What the attacker steals | A live credential | Nothing usable | | Phishing-resistant? | No | Yes, by construction |
A phishing proxy is definitionally the wrong origin. The hardware key's origin binding is definitionally triggered by that mismatch. The attack doesn't get harder against FIDO2. It gets impossible — not because the human is smarter, but because the cryptography refuses to participate in the deception.
I mentioned in my 2024 work on the GBTC/spot-ETF arbitrage that institutional infrastructure creates temporary inefficiencies for those with direct technical access. There's a parallel here. The infrastructure that makes accounts unhijackable already exists and is cheap — a $25–70 hardware key. The inefficiency is that almost nobody has deployed it. The attack succeeds because the fix is available and unused. That's not a technology gap. That's a deployment gap, and deployment gaps are where losses live.
Based purely on the outcome — the account fell to an OTP-relay attack — the confident inference is that no hardware key was enforced on the primary authentication. If a FIDO2 credential had been the only viable second factor, the AiTM proxy would have had nothing to forward. The fact that the code could be relayed at all implies the authentication stack had no origin-bound component. That's a reverse inference, and I'll mark it as medium confidence, but the logic is tight.
The email isolation fix nobody does
Stage 1's fix is boring and therefore skipped. Separate your public identity from your security root:
- The mailbox you publish is a receiving buffer — assume everything in it is adversarial.
- The mailbox that anchors account recovery and 2FA is never published, ideally never used for human correspondence, and kept off your public identity graph entirely.
- Recovery flows should route through hardware-key-gated paths, never through email codes.
This costs nothing but discipline. And discipline is exactly what fails when you're a busy chairman using an AI assistant to triage your inbox because you have 400 unread threads.
Which is the setup for the real lesson.
The Uncomfortable Part: Automation Removed the Human Backstop
There's a confession embedded in this event, and it's about the price of convenience.
The AI assistant was in the loop because a human was trying to save time. That's the only reason it existed in the flow. And in saving time, it removed the human backstop at exactly the moment the backstop was load-bearing.
This is the tradeoff nobody prices honestly. Every automation that touches a security decision shifts work from a slow, error-prone human to a fast, confident, un-auditable AI — and the failure mode moves from "I might make a mistake" to "the system will tell me it's fine and I will believe it." The second failure mode is more dangerous because it's quieter. A human who is unsure will pause. An AI that is unsure still emits a confident sentence.
I built a trading agent that executes in under 50ms, and the first thing I did after it worked was build the kill-switch. Not because the model was bad. Because fast, autonomous judgment is only safe when there's a hard boundary around what it's allowed to do. My agent could open and close positions. It could not touch custody. It could not move funds to arbitrary addresses. The authority was scoped and bounded.
The phishing victim's AI assistant had no such scope. It was asked a question whose answer had no safe default and no bounded failure. And it answered anyway. The model didn't fail because it was weak. It failed because it was asked to be a security control with the authority of a security control and the sensors of a text predictor.
That's the recurring pattern of this cycle. We keep granting soft systems hard authority. The market rewards the integration speed and punishes the boundary discipline that doesn't ship.
Ripple Effects: Where This Actually Matters
Let me keep the market-impact analysis brutally small, because most of the writing on events like this inflates the consequences.
On the price of anything
Nothing. A chairman's social account being hijacked for a window is a reputation event, not a fundamental event. It changes no supply, no demand, no cash flow, no treasury holdings. If I had to size the price impact on Nano Labs equity or on BNB itself, I'd put it inside the noise floor — below the granularity of a single earnings whisper. There is no tradeable signal here. Anyone constructing one is constructing fiction.
The one sector where it does have a second-order effect: account-security infrastructure. Every event like this is a free demand-generation unit for hardware keys, anti-phishing tooling, and origin-bound authentication. But the transmission is soft — it nudges awareness, it doesn't move capital. It's a narrative tailwind, not a revenue event.
On the AI-agent narrative
This is where the event has teeth, and it's the opposite direction from where the AI narrative has been running. The industry has spent two years positioning AI agents as security enhancers — fraud detection, anomaly flagging, scam prevention. This event is a clean, public, attributable counterexample: an AI agent was the weak link. Not a hypothetical. Not a lab test. A named chairman, a real hijack, an AI that said the wrong thing.
That's a negative expectation gap for the AI-security narrative, and I expect it to be cited repeatedly by the teams building verification layers into agents. It's the kind of concrete anecdote that moves design conversations. The model didn't save the day. The model was the reason the day needed saving. The model didn't fail at being helpful. It failed at being a cryptographer.
On the treasury-company category
Marginal. One incident doesn't re-rate a whole category's governance premium. But if this becomes a pattern across treasury-company executives — two, three, four high-profile hijacks — then the market starts pricing "operational security of the human wrappers" into the category. Treasury companies are, at the end of the day, trust wrappers around assets. A trust wrapper with a leaky human layer is a trust wrapper with a discount. One data point doesn't price that. A trend does.
On the attacker's economics
Worth a cold look, because the economics explain why this keeps happening. AiTM phishing kits are mature, cheap, and automated. The marginal cost of an attempt is near zero. The expected payoff — one successful hijack that redirects followers' funds — is potentially enormous. This is a positive-expected-value attack for the attacker across almost any success probability above a very low threshold. When the marginal cost of the attack approaches zero and the payoff is whale-sized, you don't have an incident. You have a business model. And business models scale.
That's why this is antifragile-hostile: the attack strengthens with repetition, because kits improve with every deployment and the target class (credentialed crypto figures) is fixed and enumerable. The defenders improve at a much slower rate, because defense requires behavioral change, and behavioral change requires friction, and friction is exactly what the AI assistant was deployed to reduce. Liquidity is just patience with a time limit — and here, so is security. The friction you avoid compounds into the breach you eventually eat.
The Takeaway: One Control, Deployed Today
I'll keep this short because the fix is not complicated. It's just not done.
If you are a high-value account — a founder, a chairman, anyone whose posts move people's money — replace OTP 2FA with a hardware security key, yesterday. This single change makes the entire attack chain described above inert. Phishing pages stop mattering. AI misjudgments stop mattering. OTP relays stop mattering. The credential simply refuses to authenticate outside its origin.
Isolate your security email from your public email. The address people can reach must never be the address that anchors your recovery and your authentication. Draw the boundary that wasn't drawn here.
Never let an AI's judgment be the sole gate on a credential, a signature, or a transfer. Use AI to triage, to summarize, to draft. Do not use it to authorize. Its sensors are pixels. Authorization needs cryptography.
And for the rest of us — the followers, the readers, the investors — default to distrust of any link, contract address, or wallet request, regardless of which trusted account posted it. Because the account being genuine and the poster being genuine are now two different facts, and there is no mechanism forcing them to agree.
Here's the question I'll leave with you, and I don't have a comfortable answer: if we keep wiring AI agents into every decision layer of this industry — and we will, because the speed advantage is real and the market rewards it — how many more trust arbiters are we installing before we've built a system where the fastest path to a stolen account runs through the tool we deployed to protect it? The attack didn't need to break the AI. It just needed the AI to be believed.
That's the leak. It's still open. Go patch it.
