SlowMist logs Bitget attacker activity from 31 August, Mandiant dates access to 24 September, neither names a product

The first logged activity is 24 to 25 days older than the theft

SlowMist's interim report on the Bitget theft says the earliest malicious activity it found in the available logs dates to 31 August. The first theft transfer it verified on the chain was at 18:31:00 UTC on 24 September. SlowMist writes its dates in UTC+8, and gives a date for 31 August but no hour, so the gap runs from 24 days 2 hours 31 minutes to 25 days 2 hours 31 minutes (derived). Bitget's own timeline puts the moment its security team identified the root cause at 08:43 UTC on 25 September, about 25 days after that first logged entry. The theft itself, from 18:31:00 to 21:23:11 UTC, lasted 2 hours 52 minutes 11 seconds.

What that does not establish. It does not establish that the attacker sat inside Bitget's wallet environment for 25 days, and Mandiant's report does not support that reading: it dates the access to the appliances to 24 September. The 31 August entry is one service on one node of a product SlowMist calls Product A, and the wording is "the earliest malicious activity identified in the available logs". That is where the logs start to show something, not necessarily where the attacker started. It does not establish which product Product A is, or which flaw: neither SlowMist's report nor Mandiant's names a product, a vendor or a CVE. It does not establish whether a fix exists, or whether other customers of the same products were hit. It does not establish who did it, because neither report names an actor. And it does not establish how the attacker got from one affected system to the next, which SlowMist says it is still investigating.

Two earlier briefings set the ground. Bitget says its private keys were never compromised covered the mechanism as it stood on 25 September. Bitget says it found the root cause on 25 September, and described it three days later covered how late, and how vaguely, the entry point was described. This piece reads the two forensic documents Bitget made public on 30 September against Bitget's own pages and the news coverage, and says what they add and what they leave open. Everything here is timed to 19:15 UTC (20:15 BST) on 30 September. Bitget's formal report has not appeared, and a product name, a vendor advisory or a CVE could appear at any point.

What the two reports add to Bitget's own account

Until 30 September, the account of how the attackers got in came from Bitget alone. Two documents now add detail: a SlowMist interim report, current as of 29 September, and a Mandiant status report dated 28 September. The table sets what is new against what our 29 September briefing had on the record.

New on 30 September, from the SlowMist interim report (English edition, dates in UTC+8, converted here to UTC) and the Mandiant status report (dated 28 September), against our earlier briefing.

New on 30 September	Who says it	Before 30 September
Earliest malicious activity in the available logs: 31 August, a service on a Product A node, through a zero-day. A hidden script ran a command to read the environment variable holding the database password, then connected to the database.	SlowMist	No start date. How long the attacker was inside: not stated.
Similar hidden-script activity on two more Product A nodes, dated 23 September and 25 September (dates only).	SlowMist	Not stated.
Product B's management platform reached with an internal employee's identity. From 16:07 UTC on 24 September, three attempts to inject system commands, then code submitted through a web execution endpoint.	SlowMist	High-level credentials obtained and read as normal logins, by Bitget's account.
Privileged access to appliances A and B on 24 September. A web shell and a command-and-control connection on B, then lateral movement to the production wallet job server, where malicious packages were deployed.	Mandiant	Forged commands written into the wallet system through wallet-related backend servers, by Bitget's account.
A customised withdrawal tool, recovered from deleted files. It forged risk-control parameters in its code, built withdrawal requests and invoked the withdrawal process. Running from 17:49 UTC.	SlowMist	Forged commands said to have bypassed risk verification.
First verified transfer 93 TRX at 18:31:00 UTC, then 0.84 ETH 11 seconds later. After the transfers began, attempts to alter withdrawal records and two fabricated BTC orders that returned errors, after 21:22 UTC.	SlowMist	Drain window 18:31 to 21:23 UTC from Arkham. The failed BTC attempts: not stated.

Both documents are interim, and both firms were engaged by Bitget, which calls the reports independent. SlowMist's public English report is a short summary: its Chinese title calls it a summary edition (our reading). Its disclaimer says it relies on material supplied by "the information providers" and assumes that material is complete and untampered. Mandiant's is two pages, marked proprietary and confidential, hosted on a Bitget static-content domain, dated 28 September on its cover and released by Bitget on 30 September. Its first section, headed Background, largely restates Bitget's own account ("Bitget's preliminary investigation indicates..."). The forensic part is the section headed Preliminary Findings. None of that says the findings are wrong. It is what "independent" covers and what it does not.

Timing, all on 30 September UTC and checkable: SlowMist's English PDF was added to its public GitHub repository at 02:47, SlowMist announced it on X at 04:01, Bitget thanked SlowMist at 04:06 and posted the Mandiant findings at 04:09, and Bitget's support-centre article linking both reports carries the time 05:20, which Bitget's own explainer timeline also uses for when the reports "became available".

The chain is longer than the sentence Bitget used on 28 September

On 28 September, Bitget's account was a single sentence: a flaw in a third-party product yielded high-level credentials, which were used to send forged withdrawal commands. The two reports draw a longer chain, cut differently by each firm, with a gap in the middle.

Read across, the two firms describe compatible but differently cut pictures, and they do not give the same start date. SlowMist's earliest logged activity is 31 August. Mandiant's report says that on 24 September the actor gained unauthorised privileged access to appliances A and B, with no time zone stated, and it does not mention 31 August at all. The two documents do not say whether these are different events, or one event dated by different evidence. SlowMist starts with a zero-day in a service on a node of Product A, and reaches the withdrawal tool through a login to Product B's management platform using an employee's identity. Mandiant starts with privileged access to two appliances, a web shell and a command-and-control connection on the second, and movement from it to the production wallet job server. Two mappings are our reading, and neither firm states them: that Mandiant's appliances A and B are SlowMist's Products A and B, and that SlowMist's "wallet application host" is Mandiant's "production wallet job server". The descriptions line up at that level, but the letters may simply be what each firm reached for first.

The missing link is the one a defender needs most. SlowMist says it is "continuing to investigate how the attacker moved between the systems involved". Bitget's one-sentence account needs credentials from the flaw to reach a management system. SlowMist shows a command run to read Product A's database password from its environment, and later an employee's identity used on Product B. How the first became the second is in neither report. Bitget's chief executive wrote on 28 September, "Full trace-back complete", and its incident page says Bitget "has confirmed the full attack chain". Mandiant's document, dated the same day as that post, says its investigation is ongoing, and SlowMist's, current to 29 September, says how the attacker moved between the systems is still being investigated. The dating does not settle the gap either: Mandiant puts the privileged access to both appliances on 24 September, with no time zone given, while SlowMist puts activity on Product A on 31 August. Neither document mentions the other's date.

The risk step has now been described three ways within a week. On 25 September the attacker "triggered our authorization process", in the chief executive's post. From 28 September Bitget said the forged commands bypassed risk controls, and its incident page adds that this was before withdrawal records were generated. On 30 September SlowMist says the tool "forged risk-control parameters in its code", then invoked the withdrawal process. A step that is skipped and a step that is fed forged inputs are different failures with different fixes, and the reports do not say whether these are one control or several. The reading that fits SlowMist's wording is an inference: the risk decision accepted values the caller could supply.

One further mismatch is small but checkable. Mandiant's Background says Bitget's monitoring "detected" unauthorized transfers at 02:31 UTC+8 on 25 September, which is 18:31 UTC on 24 September. Bitget's updated explainer says the first unauthorised transfers occurred at 18:31 and its reconciliation system detected a discrepancy at 19:05, 34 minutes later. The Background repeats Bitget's 24 September wording; the forensic work is in the Preliminary Findings.

Drawn to scale, the theft is a sliver at the end

The chart puts every dated item on one axis, from the start of 31 August in UTC+8 to 30 September. The earlier activity is drawn as day-wide bars because SlowMist gives dates, not times. The theft window is 2 hours 52 minutes, which is 0.39 per cent of the span (derived). The lower panel enlarges the evening of 24 September.

Four intervals fall out of it (all derived). From the 31 August date to the first verified transfer is 24 days 2.5 hours to 25 days 2.5 hours. From Bitget's stated root cause at 08:43 UTC on 25 September to SlowMist's announcement at 04:01 UTC on 30 September is 4 days 19 hours 18 minutes. From the first transfer to the same announcement is 5 days 9.5 hours. And from the chief executive's 28 September recap, the first written statement we found that named third-party products, to the announcement is 1 day 17 hours 44 minutes.

The dates on the other nodes matter for a reason the chart makes visible. SlowMist dates hidden-script activity on two more Product A nodes to 23 and 25 September in UTC+8. The 25 September date runs from 16:00 UTC on 24 September to 16:00 UTC on 25 September, so it could sit before the theft or after it, and it could sit before or after Bitget's statement at 14:05 UTC on 25 September that the underlying vulnerability had been "identified and remediated". The report gives no hour, so that cannot be told from the record.

Zero-day, malware, supply chain: the labels around the facts

BleepingComputer's headline says a zero-day in third-party security products. The primary documents are narrower, and several phrases in circulation sit awkwardly beside them.

Phrases in circulation on 30 September against what the primary sources say. Sources: SlowMist and Mandiant reports, Bitget's X posts of 30 September, explainer and incident page, BleepingComputer, Bitcoin.com.

Phrase, and where it appears	What the primary sources say	What stays open
"Zero-day in third-party security products" (BleepingComputer headline; its second paragraph says two appliances were compromised with zero-day exploits).	SlowMist: a zero-day in a service on one Product A node; Product B reached with an employee's identity. Bitget's 30 September post: "including a zero-day vulnerability", singular. Mandiant does not use the word.	Whether anything was exploited on Product B or the appliances, and whether the zero-day is one flaw or several.
"The attackers did not use common viruses or malware" (Bitget incident page, stamped 00:00 UTC on 30 September, before either report was public).	Mandiant: a web shell, a command-and-control connection and malicious packages on the wallet job server. SlowMist: attempts to upload and assemble malicious program files in batches, and a customised withdrawal tool.	"Common" carries the weight. A bespoke tool is not commodity malware, but it is still something a defender has to find.
"Full trace-back complete" (chief executive, 28 September) and "has confirmed the full attack chain" (Bitget incident page).	Mandiant, dated 28 September: its investigation is ongoing. SlowMist, current to 29 September: still investigating how the attacker moved between the systems. Bitget's explainer, updated 30 September, still calls its own finding preliminary and says the attacker "may have exploited" a vulnerability.	What "full" covers. Neither firm says the chain is complete.
"A targeted attack on the supply chain of a third-party security software" (Bitget incident page FAQ).	Neither report says a vendor's build, update or distribution was compromised. SlowMist describes exploitation of a service on a node; Mandiant says the attacker used the appliances to distribute malicious packages.	Whether the vendor itself was breached. No source says so.
"Remediated" and "patched" beside "disabled pending a fix" (Bitget explainer, updated 30 September).	The same page says the affected functionality was disabled "pending completion of a fix" and, in its FAQ, that the vulnerability "has been remediated".	Whether a vendor fix exists. Neither report says.
"Independent investigation" (Bitget).	Both firms were engaged by Bitget. Mandiant's Background largely restates Bitget's account. SlowMist's disclaimer says it relies on material supplied by "the information providers".	What the firms could not see, and what Bitget chose to publish.
"Inside the Exchange for 25 Days" (Bitcoin.com headline).	SlowMist: earliest malicious activity in the available logs, on one node, dated 31 August. Bitcoin.com's body text quotes the "available logs" wording; its headline does not.	Where the logs begin, not where the attacker did.

Separate the method from the accusation. Bitget is both the victim and the client, and its account has commercial weight: a flaw in a vendor's product is a different conversation for customers and regulators from a failure in Bitget's own controls. A vendor has an interest in the opposite direction. SlowMist also runs the MistTrack unit that is following the stolen funds, and Mandiant is part of Google Cloud. None of that makes the findings wrong. It is the reason the vendor's own statement and Bitget's formal report matter, and the reason neither has yet replaced the two interim documents.

What is stated and what is not, at 19:15 UTC on 30 September

Questions a defender would ask, with what the documents state and what they do not. Sources: SlowMist and Mandiant reports, Bitget's pages and posts of 30 September, first read at about 18:57 UTC and re-read at 19:16 UTC.

Question	Stated	Not stated
Which product or vendor	Two third-party security products, called A and B by SlowMist and appliances A and B by Mandiant. Bitget says the vendor has been notified and is assisting.	Any name, version or vendor. No vendor statement or advisory found.
Which flaw, and is there a CVE	A zero-day in a service on a Product A node (SlowMist).	Any identifier, the flaw class, or whether the same flaw reached Product B.
Whether a fix exists	Bitget: remediated, and also functionality disabled pending a fix.	Whether the vendor has released a fix or a mitigation.
Whether other customers were hit	Not addressed by either report, Bitget's posts or its pages.	Whether any other customer of either product was affected.
How long the attacker was present	Earliest activity in the available logs: 31 August, a UTC+8 date.	Anything before the logs begin, the hour, or how long access to the wallet environment lasted.
How the attacker moved between systems	Mandiant: lateral movement from appliance B to the wallet job server. SlowMist: still investigating.	How the Product A database password or the employee identity was obtained or used, and how A connects to B.
Whether the firms' A and B are the same products	Both use the letters A and B.	Any statement that they are the same.
Who did it	Neither report names an actor. Bitget's explainer says it will not speculate on attribution without verified findings.	An actor, or the evidence for one.
When the formal report arrives	Incident page: "will be released soon". Explainer: details "as findings are verified".	A date. The 24 September promise was a report "within 24 hours".

The figures. The loss has three Bitget figures: about $351.6 million in the 24 September notice, $387.5 million in the 25 September update that added Zcash and TRON assets, and about $388 million, headed "final verified figures" with 12 wallet addresses, on the incident page. The last is 0.13 per cent above the second (derived). Mandiant's document, dated 28 September, says Bitget "estimated the loss in the range of US$351.6 million and US$387.5 million". That is the two earlier Bitget figures restated as a range in the Background section, not a new estimate. BleepingComputer uses $387.5 million. All three describe the same theft.

Attribution has not moved: neither report names anyone

Neither the SlowMist nor the Mandiant document mentions an actor. Bitget's explainer, updated on 30 September, says it will not speculate on attribution without verified investigative findings. What the chief executive said earlier, and what TRM Labs and Elliptic made of it, is set out in our 29 September briefing and is unchanged by these reports. Laundering-side claims reported on 30 September, attributed to SlowMist's Cos in coverage by Bitcoin.com and The Crypto Times, concern suspected operators moving the stolen money, not who got in. We did not read his original posts, so those items rest on secondary reporting. As that briefing put it, laundering overlap says who handled the money afterwards, not who broke in.

What to do if a security product holds standing power in your estate

No source mentions UK customers, UK firms or a UK authority, and no UK-specific product is named. The relevance to a UK reader is structural. Both affected products are described as security appliances with management platforms, and the route from them to a payments server is one any estate with the same shape could offer. Nothing in the sources says which estates run these products. The list below needs no product name and stays at the level of what to hunt and what to harden, in the order worth doing.

The question this leaves

Bitget has now published two outside documents and still not a name. The first date in them is a logs horizon, not a beginning, and everything before it is unknown to the reader. The vendor has not said whether other customers run the same flaw.

So the question for your own estate. If the vendor of the most privileged security product you run said tomorrow that it had been exploited since 31 August, could you read your own logs back far enough to know whether you were hit?

Key facts