Seven South Korean lenders lost customer data through the side doors built for loan brokers and bank employees, not the front door. Arizona’s court system learned that a single phished click ended with 1.3 million people’s records copied off a backup server. A ransomware attack on a SoftBank-owned cloud region took down prefectural and city websites in Japan, along with the businesses that rented space there. And a university medical college lost data to a new ransomware crew while the hospital next door kept treating patients.
This week: none of these attackers needed to defeat the most heavily defended system. They went for the systems around it: partner portals, backup copies, shared hosting, and the administrative network next to the clinical one. The damage came from what those secondary systems held or served, and in most cases nobody had thought of them as crown jewels.
South Korean Banks: Seven Lenders, One Campaign, Side Doors Left Open
What happened: Between September 27 and 30, attackers pulled customer data from at least seven South Korean financial institutions, including Shinhan Bank, KB Kookmin Bank, Hana Bank, BNK Busan Bank, Yegaram Savings Bank, Welcome Savings Bank and Hyundai Capital. Korean outlets began reporting the Shinhan and KB Kookmin breaches on October 2. Shinhan reported about 25,000 customers affected, Yegaram reportedly about 40,000, while Hana (89) and KB Kookmin (119) reported far smaller counts. The data included names, phone numbers, resident registration numbers, and loan application details. Regulators held an emergency meeting, and President Lee raised the matter at a cabinet meeting on October 6.
Technical details that matter:
- Initial access went through external-facing systems used by staff and loan agents, not core banking: a loan-progress inquiry service used by brokers at Shinhan, an employee mobile work-support system at KB Kookmin, and a sales support system at Hana. The specific flaw or credential used has not been disclosed.
- One tooling claim, and it is unconfirmed: investigators reportedly found a Chinese-language page title on a server linked to the Shinhan attack, matching the console of ARTEX AI, an open-source, LLM-driven framework that automates recon, vulnerability discovery, attack-path planning, and verification. Authorities have not confirmed the tool was used, and the string does not identify an actor.
- Timeline correlation, not proof: ARTEX’s repository went public July 26, a new version appeared September 24, and the first KB Kookmin intrusion followed on September 27.
- Infrastructure: Korean reporting says the same attacker IP address appeared across all seven firms, and regulators flagged roughly 30 related IPs in 12 jurisdictions. Both figures come through a secondary outlet.
- Detection was slow: about 15 hours at Shinhan, roughly 41 to 42 hours at Hana, and 67 to 68 hours at KB Kookmin, per Korean reporting.
- Persistence, lateral movement, C2, and exfiltration method: not disclosed. No attribution to a named actor.
Why critical institutions should care: The breached systems were the ones that exist for convenience: tools for brokers, for loan officers, for staff in the field. They sit outside the core network, so they often sit outside the core security program. Regulators responded by ordering firms to cut off external access that is not essential, which is an admission that nobody had a current list of what was exposed. Detection times of up to nearly three days mean the data was likely leaving long before anyone looked.
Key sources:
- South Korea probes bank breaches amid suspected AI-powered attacks (BleepingComputer)
- Customer information leaked through loan inquiry and employee support systems at major banks (The Korea Herald)
- EXPLAINER: How AI emerged as new threat in Korea’s bank hacking crisis (The Korea Times)
- Shinhan, KB and Hana Bank hit, and even secondary lenders hacked (Kyunghyang Shinmun)
Update: Arizona Courts: A Phished Click, a Backup Server, and 30 Years of Records
Timing disclosure: Arizona’s Supreme Court first announced this breach on September 25, before this window. The update inside the window, on October 6 and 7, is the confirmed scale (1.3 million people), the phishing vector, and the foster care and protective order records.
What happened: Attackers reached a backup server in Arizona’s court system on September 24 and copied backup court files before the court’s IT staff shut the intrusion down, about two hours after spotting it. The court now says records on roughly 1.3 million people were copied from its Fines/Fees and Restitution Enforcement (FARE) program, dating back as far as 30 years, including names, Social Security numbers, and case numbers. Attackers also copied more than 150,000 Foster Care Review Board reports dating to 2010 and records involving active and inactive protective orders.
Technical details that matter:
- Initial access: phishing. Investigators believe a court employee clicked a malicious link in an email.
- Target selection: the backup server, where highly compressed copies of court data are kept. How the attacker moved from one employee’s mailbox or workstation to a backup server has not been disclosed. That path is the real question in this case.
- Objective: theft, not disruption. The court says this was not ransomware and no ransom demand had been made as of October 5. No records were altered or deleted, and cases were not delayed.
- Exfiltration volume and method: not disclosed. The court says the format of the files may make them hard for the thieves to read. That is the court’s assertion, and we have not seen it tested.
- Persistence and C2: not disclosed.
- Attribution: none. No group had claimed the attack as of October 7.
Why critical institutions should care: Backups are built to hold everything, which makes them the richest single target in the building. The court has not said whether it kept these records because the law required it or by choice. Either way, a backup holding three decades of records carries the same sensitivity as the live system, and now a notification obligation for 1.3 million people. The foster care reports show the human stakes, with children’s case details and family statements now outside the court’s control.
Key sources:
- Arizona courts say hackers stole info on more than 1.3 million people (The Record)
- Personal information for over 1 million people stolen in a cyberattack on Arizona’s court system (AP, via WPXI)
- Arizona Court Cyberattack Exposes Data on 1.3 Million People (Bloomberg Law)
- Arizona Courts Cyber Attack Exposed 30 Years of Personal Data (GovTech, from the Arizona Republic)
IDCF Cloud: One Ransomware Attack, One Cloud Region, Hundreds of Downstream Customers
What happened: At about 3:40 a.m. Japan time on October 7, IDC Frontier, a SoftBank subsidiary, saw an automatic shutdown trigger after a ransomware attack on its IDCF Cloud service. The company isolated the network to prevent secondary damage and data leaks. The outage hit East Japan Region 1, and websites for Ibaraki Prefecture and the city of Kodaira went dark, along with businesses that host on the platform. As of October 8, the region was still isolated and the company was building an alternative environment.
Technical details that matter:
- Scope: the platform has three independent regions in eastern Japan and one in western Japan. Only East Japan Region 1, at a data center in Shirakawa, Fukushima, was hit. IDC Frontier said it was checking the other regions.
- Containment: an automatic shutdown system fired, then the service network was blocked. That limited spread but also took customers offline.
- Downstream impact: besides government websites, Japanese security outlets compiled company notices showing outages at a call-center service, an e-commerce inventory and pricing service, and a security vendor’s management consoles. The last item shows a security product’s own control plane going down with its host.
- Unverified attacker claim: a screen image circulating on social media claims the attackers encrypted virtualization and storage layers and deleted snapshots. IDC Frontier has not confirmed this. If true, it is the pattern that destroys recovery options, because it targets the layer customers assume will always be there.
- Entry point, ransomware group, data theft, and restoration time: not disclosed. A tally of 495 affected companies and local governments is circulating, but we could not tie it to IDC Frontier’s own notice, so treat it as unconfirmed.
Why critical institutions should care: This is concentration risk in its plainest form. Dozens of organizations that never touched the attacker’s entry point lost services because they shared a landlord. Government websites were among them, and a security vendor’s customers lost visibility because the vendor lived in the same region. Your resilience plan has to cover the provider’s worst day, not just your own.
Key sources:
- Cyberattack on SoftBank Unit Affects Local Govt, Corporate Websites (Jiji Press, via Nippon.com)
- IDC Frontier announcement of IDCF Cloud outage (ASCII.jp)
- IDCF Cloud unauthorized access, East Japan Region 1 outage (Rocket Boys)
UIC College of Medicine: A New Ransomware Crew Takes Data From the Medical School
What happened: The University of Illinois Chicago told reporters it discovered a ransomware attack that limited access to some College of Medicine systems and that the attackers took some information from the college’s servers. The university says affected systems have been restored, its main network was not touched, and patient care at UI Health was not affected. A ransomware group called Booba claimed the attack and says it stole 344 gigabytes. UIC has not verified that figure and is still determining whether personal, research, or academic information was compromised.
Technical details that matter:
- Initial access: not disclosed.
- Tradecraft: double extortion, meaning files were encrypted and data was taken first. UIC confirmed data was obtained from college servers, which supports the theft side of the claim, though not the 344 GB.
- Actor: Booba emerged at the end of July and has claimed 49 attacks, according to a ransomware tracker cited by The Record. It renames encrypted files with a .booba extension and has Windows and Linux variants. Linux variants suggest it is built to hit servers, not only workstations. That is our inference, not a reported finding.
- Attribution, lower confidence: a SentinelOne researcher assesses Booba as a rebrand of the Frag ransomware, based on leak site style and negotiation flow. That is one vendor’s circumstantial read.
- Related activity: Booba also hit Merrimack County, New Hampshire, where county dispatchers lost access to criminal data from a state system.
- Lateral movement, C2, and exfiltration method: not disclosed.
Why critical institutions should care: The university’s account of the incident is a segmentation success story: the clinical network and main campus network stayed up while one college was hit. But the same account hides the harder question. A medical college holds research data, student records, and sometimes patient-adjacent information, and “systems restored” says nothing about what left the building. Institutions with academic and clinical arms should know which side of that line each dataset sits on before an attacker decides for them.
Key sources:
- University of Illinois Chicago affected by ransomware attack on medical school (The Record)
- UIC College of Medicine Hit by Booba Ransomware, 344 GB Claimed (Daily Security Review)
- University of Illinois Chicago College of Medicine systems impacted by ransomware attack (SC Media)
The Pattern this Week
Look at where each attacker actually got in or did damage: a loan-broker portal, an employee mobile tool, a backup server, a cloud region shared by hundreds of customers, a medical college’s separate network. None of these is the system an executive pictures when asked what the company must protect. They are the systems built for convenience, redundancy, or sharing, and they quietly accumulate the same sensitive data as the primary systems with a fraction of the attention.
The Korean campaign adds a wrinkle worth watching: whether or not an AI tool was used, the timeline suggests attackers can now probe many institutions quickly, and the weakest peripheral system at each one decides the outcome. The speed of the campaign matters less than where it landed.
This is the defender’s problem. The attacker only has to find one forgotten door, and the defender has to know about all of them, including the ones someone added for a good reason three years ago and never listed anywhere.
What Your Business Can Do This Week
- Ask for a list of every system reachable from outside, including the ones that are not customer-facing. Korean regulators ordered exactly this after the bank breaches. Ask your IT lead or provider for the list, who owns each item, and which ones could be shut off tomorrow without hurting the business.
- Find out where your backups live and what they hold. Arizona’s attackers went after a backup server. Ask who can reach your backups, whether they are protected as strictly as your live systems, and whether anyone has decided how long old records should be kept.
- Ask your cloud and hosting providers what happens when their region goes down. IDCF Cloud customers lost service because of someone else’s breach. Ask for the provider’s recovery plan in writing, and ask your team how long the business could run with no access to that platform.
- Confirm your administrative and research networks are separated from the ones that run operations or patient care. UIC’s clinical side stayed up. If your organization has more than one arm, ask which datasets live where, and who decides when to notify people.
- Make sure employees have an easy way to report a suspicious email, and make sure someone acts on it fast. The Arizona breach began with one click. Training helps, but speed of reporting is what limits the damage.
See you next week!