A crypto exchange lost $387.5 million through the security products it had bought to protect itself, and the attackers had been inside for 24 days before the first transfer. A health system learned on August 4 that a contractor-run legacy system holding imaging records may have been exposed, and began notifying patients 56 days later. A Mississippi city of about 20,000 people disconnected its internet on Thursday, delaying in-person payments at a water and gas office that serves more than 10,000 accounts.
This week: three incidents where the damage landed in a system that sits beside the core operation rather than inside it. Bitget’s loss ran through third-party security appliances, IU Health’s through a vendor-managed legacy system, and Vicksburg’s through the back-office computers that bill a city’s utility customers. The first two entered through tools and contractors the organization did not run itself. Vicksburg has not said how attackers got in.
Update: Bitget Loses $387.5 Million Through Third-Party Security Products
What happened: Attackers moved $387.5 million out of Bitget’s hot and warm wallets over nearly three hours beginning at about 18:31 UTC on September 24. Bitget first estimated the loss at $351.6 million, then raised it on September 25 after counting Zcash and TRON assets. On September 30, forensic findings from Mandiant and SlowMist, released through Bitget, showed that the intrusion began on August 31 with a zero-day flaw in a third-party security product, nearly four weeks before any funds moved.
Note on timing: the theft and first disclosure came on September 24, one day before this window opened. We are covering it now because the September 30 forensic findings and the October 2 recovery update are material new developments, including a root cause far more specific than the “backend system” the CEO described at first.
Technical details that matter:
- Initial access: a zero-day vulnerability in a service running on one node of a third-party security product SlowMist labels “Product A.” The earliest malicious activity in the available logs dates to August 31. Neither the vendor nor the flaw has been named
- Credential access: per SlowMist, the attacker ran a hidden script under the service process, read an environment variable holding a database password, and connected to the database. The same hidden-script activity appeared on two other nodes on September 23 and September 25
- Foothold and command and control (C2): Mandiant reports that on September 24 the attacker held privileged access to two third-party security appliances, “A” and “B,” deployed a web shell on appliance B, and established a C2 connection
- Lateral movement: from persistent access on appliance B, the attacker moved to Bitget’s production wallet job server and deployed malicious packages. SlowMist adds that on September 25 the attacker reached Product B’s management platform using an internal employee’s identity and tried to inject commands, change configurations, and upload files
- Action on objective: a custom withdrawal tool forged withdrawal orders that Bitget’s own systems processed as valid, bypassing the customer-facing withdrawal flow. No private keys were stolen and cold wallets were unaffected. SlowMist reports two forged Bitcoin orders returned errors, after which the attacker checked logs and order status and tried again
- Attribution: CEO Gracy Chen says behavior patterns and on-chain analysis point to North Korean actors. Treat this as a company assertion: the Mandiant status report we reviewed makes no attribution
Why critical institutions should care: Bitget’s security tooling was both the way in and the staging ground. Appliances that hold stored credentials and sit in a privileged network position are what a patient attacker wants, because everything around them trusts them and almost nothing watches them. Twenty-four days passed between the first malicious activity in the logs and the first transfer, and the theft then passed through approval flows that treated forged orders as routine. The financial cushion mattered too: Bitget told CNBC it refilled its protection fund to $300 million using its own capital. Most institutions have no reserve like that. For any bank, credit union, or payments firm, the question is not whether its security vendors are good. It is who watches the vendors’ products once they are inside the network.
Key sources:
- Bitget hacked via zero-day in third-party security products (BleepingComputer)
- Incident Response Status Report, September 28, 2026 (Mandiant, hosted by Bitget)
- Bitget ‘not expecting to recover a lot’ from $388 million hack, CEO tells CNBC (CNBC)
- North Korea accused of plundering Bitget for $387 million in year’s biggest crypto attack (Fortune)
IU Health Vendor Breach Exposes Southern Indiana Imaging Records
What happened: Indiana University Health announced on September 29 that unauthorized access had occurred on a legacy system managed by its IT vendor, AME Group. The system held radiology files from an imaging center serving Southern Indiana patients. IU Health says it learned on August 4 that AME may have been exposed to a previously unknown software vulnerability, then reviewed the vendor-managed system itself and confirmed the access. Patient notifications began September 29, 56 days after the vendor warning.
Technical details that matter:
- Initial access: a previously unknown software vulnerability tied to the IT services AME provided for the legacy system. IU Health uses hedged language (“may have been susceptible”) and has not named the product, the flaw, or the method
- Environment: an isolated legacy system that sits outside IU Health’s network and is managed by the vendor. IU Health says its own network, core systems, and electronic medical record were not affected
- Detection: the vendor detected suspicious activity and started its own incident response. IU Health then ran an independent review of the vendor-managed system to determine what had been accessed
- Data involved: names, dates of birth, health plan member identification numbers, and limited treatment information tied to the imaging center
- Not disclosed: the number of patients affected, when the access occurred, whether data was copied out or only viewed, and who was responsible. We found no group claim
- Operator view: a legacy system in a vendor’s environment is a data store outside the customer’s own logging and patch cycle. A zero-day there gives an attacker patient records without ever touching the hospital network
Why critical institutions should care: The system that was breached was not the system IU Health’s security program was built to defend. It was an old, isolated, vendor-run box, the kind of asset that falls off inventories. Isolation is a claim, not a control: IU Health’s network was untouched and patient records were exposed anyway. The timeline is the second lesson. Eight weeks passed between the first vendor warning and the first patient notice, and the public still does not know how many people are affected. Healthcare leaders should ask which legacy and vendor-hosted systems still hold patient data, what their contracts require the vendor to tell them about a suspected exposure, and how fast.
Key sources:
- IU Health reports vendor security incident in Southern Indiana (IU Health)
- IU Health reports vendor security incident affecting radiology files (Becker’s Hospital Review)
- Some Southern Indiana IU Health Patients Are Getting Breach Notices (Medical Daily)
City of Vicksburg, Mississippi, Ransomware Attack
What happened: Mayor Willis Thompson said a ransomware attack hit the City of Vicksburg on Thursday, October 1, forcing a shutdown of city computer systems and a disconnection of its internet operations. 911, police, fire, and utility service remain operational, but in-person utility payments may be delayed. The city says no one will face penalties or service shutoffs while its systems are offline, and it is working with the FBI, the Department of Homeland Security, state officials, and outside cybersecurity specialists.
Technical details that matter:
- Initial access: not disclosed. The city says it will withhold technical information that could interfere with the investigation or recovery
- Containment: the city took its internet operations down as a protective step, and the mayor told the Vicksburg Post that everyone on the city network is affected to some degree. The city has not said which functions beyond utility payments are impaired
- Scope of data: the city is reviewing whether records of current and former customers, contractors, vendors, employees, and business partners were accessed. It has made no determination
- Attribution: no group has been named. The city did not answer The Record’s questions about ransom demands or the identity of the attackers
- Operator view: a citywide shutdown with a decision to cut internet access suggests either broad reach inside a shared network or a defensive choice made because the city could not yet scope the intrusion. The public record does not say which
- Context: Mississippi has been hit repeatedly, including a ransomware attack that left the University of Mississippi Medical Center without systems for weeks
Why critical institutions should care: The reporting does not indicate that water treatment or distribution controls were touched, and the city says utility service continues. That is the point. A utility can keep water flowing and still lose the ability to bill, which becomes a cash problem and a data problem within weeks. Customer billing records combine names, addresses, and account details for thousands of households, and municipalities often run them on thin IT staffing. Leaders in government and utilities should plan for the day the physical service works and the paperwork does not, including what to tell customers about late fees and shutoffs. Vicksburg answered that question on day one, which is worth copying.
Key sources:
- Mississippi mayor says ransomware incident led city to shut down systems (The Record)
- City of Vicksburg hit by ransomware cyberattack, mayor says (WLBT)
- Vicksburg impacted by ransomware attack (WJTV)
- City of Vicksburg, Mississippi, shuts down computers after ransomware attack (Dysruption Hub)
The Pattern this Week
Three organizations, three different back doors, one shared habit: each trusted a system it did not closely watch. Bitget trusted security appliances inside its own network, and an attacker lived in them for 24 days. IU Health trusted a contractor to protect a legacy system, and the first warning arrived in early August while patients heard in late September. Vicksburg has not said how attackers got in, but the damage landed in the back office that bills thousands of utility customers, a system nobody puts on a risk slide until it stops.
None of these were the crown jewels on paper. All of them became the crown jewels in practice, because they connected to money, patient records, and customer accounts. The defender’s problem this week is an inventory of trust: the list of things your organization depends on but does not operate, and the name of the person watching each one.
See you next week!
What Your Business Can Do This Week
- Ask your IT leader or provider for a list of every security product inside your network that your own team did not build, such as firewalls, remote access gateways, and monitoring consoles. For each one, ask who has administrator access and who reviews its logs. Then ask the question Bitget could not answer in time: if one of these products were compromised today, how would we know?
- If your organization moves money, confirm that a payment cannot be approved by internal systems alone. Unusual or high-value transfers should need confirmation from a person or a separate system outside the environment that initiated them. Bitget’s own approval process accepted forged orders as valid.
- Make a list of old systems and vendor-managed systems that still hold sensitive data, including any described as isolated. For each, find the contract language on how quickly the vendor must tell you about a suspected problem, and ask for a written commitment on notification timing and on the logs you can see.
- Rehearse two weeks of billing, payments, and customer service with no computers. Confirm that offline copies of customer account lists exist, decide in advance what you will tell customers about late fees and service shutoffs, and name who has authority to disconnect the network.

