Part 14 of a series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the previous part, PHP2Shell: the patch is out. Do you know who installs it?.

TL;DR: On 14 October, attackers placed buy and sell orders in seven IwaiCosmo Securities customer accounts, and five of them went through. They didn’t steal a customer’s password to do it. Customer logins were protected by multi-factor authentication and passkeys, and that protection held. Instead, the attackers abused a misconfigured admin function in the system run by Trade Works, the vendor that operates IwaiCosmo’s online trading. The vendor says the failure was its own. Customers lost nothing, and the trades were reversed. But Japan’s brokerages spent 2025 locking the front door after a ¥739 billion wave of fraudulent trades, and this is what the attack looks like once the front door holds: it moves to whoever runs the back office.

What happened

On 14 October, Trade Works detected an outsider in the online trading system it runs for IwaiCosmo, an Osaka brokerage, and restricted access the same day. Two days later, both companies disclosed a leak. Trade Works’ stock exchange filing said the names, email addresses, and other details of 4,611 customers had been exposed, and IwaiCosmo notified customers and warned them about calls and emails pretending to be from the brokerage.

The filing was unusually direct about the cause. Customer logins were protected by multi-factor authentication and passkeys, and “unauthorized logins through the normal route were prevented.” Instead, part of the admin function in Trade Works’ own system had a configuration flaw, and an outsider exploited it. In the company’s words, this happened “because our management was inadequate.” Trade Works said it had found no evidence that customer passwords were taken through that function, shut the function off, cut the attacker’s connections, and checked the systems it runs for other financial firms. It said it will cover all losses and costs and expects its cyber insurance to apply.

On 20 October, IwaiCosmo’s second notice added two things. A closer look at the network logs found 364 more customers affected, bringing the total to 4,975, all from the original intrusion. And on 14 October, the same day as the break-in, its trade-management system had also been attacked: orders the customers never placed went into seven accounts, and five were filled. Those customers were contacted that day, and their accounts were put back the way they were before the trades. IwaiCosmo says nobody bore a loss, and that the trades did not use the leaked personal data.

ANN’s 20 October report, in Japanese, on the unauthorized trades at IwaiCosmo. Video: 岩井コスモ証券に不正アクセス 顧客の意図しない売買成立(2026年10月20日) from ANNnewsCH.

Why this one is different

Every other incident in this wave has been about data walking out the door, or companies switching everything off before it could. This one changed what a financial system did. Kyodo reports that it appears to be the first confirmed damage in finance or securities in the current run of attacks. Masakatsu Morii, professor emeritus at Kobe University, told the Asahi Shimbun he had never heard of a case like it in Japan, called it “an attack on a completely different level from the leakage of personal information,” and said the possibility of an attacker breaching a bank’s system and moving funds is hard to call zero. Tetsutaro Uehara of Ritsumeikan University told NHK the attacks may have entered a stage where financial institutions are the targets.

The government noticed. Chief Cabinet Secretary Minoru Kihara said the Financial Services Agency has asked IwaiCosmo to analyze the break-in and set out preventive measures, according to Kyodo.

The front door was fixed

In 2025, Japan’s online brokerages were hit by a wave of account takeovers. Criminals stole login details through fake brokerage websites, then used the hijacked accounts to sell customers’ holdings and buy small foreign and domestic stocks. By the FSA’s count, there were 17,559 break-ins and 9,752 fraudulent trades, with about ¥739.3 billion in shares sold and bought. That is trading volume, not customers’ losses, but it shows the scale. The industry’s answer was stronger login security, and the FSA now tells customers that brokerages are making phishing-resistant authentication such as passkeys mandatory.

At IwaiCosmo, that work paid off. The customer login held. The attackers didn’t fight it. They went around it, to an admin function that customers never see, run by a company most customers have never heard of.

That’s the pattern I keep coming back to in this series. Part 5 was about how outsourcing the work doesn’t outsource the responsibility. Part 10 and the Arcadia breach behind Whom Now Shall We Trust? showed how one vendor’s failure lands on every customer that depends on it. Trade Works builds and runs online trading systems for brokerages, FX dealers, and crypto exchanges. It says it checked the others and found nothing similar. That’s good news, and it’s also the point: one misconfigured setting, in one vendor’s back office, reached the core of a regulated brokerage.

Rows of an electronic stock board showing Japanese company names, ticker codes, and share prices in red LED digits
An electronic stock board in Yaesu, Tokyo, March 2007. The customer sees prices and a login page; the systems that place the orders belong, more and more often, to someone else. Photo: nappa, Wikimedia Commons, CC BY 2.0.

The regulators saw this coming

On 22 May, the FSA and the Bank of Japan sent financial institutions a joint request about the threat from frontier AI. It asked for the response to be led by top management, and it was specific. Clear the technical debt in priority systems, including deleting unnecessary privileged accounts. Check that maintenance contracts with vendors actually cover urgent patching, nights and weekends included. Make sure that systems run by vendors or shared with other institutions report their status back. Put multi-factor authentication on privileged accounts. And decide in advance when the company would switch a critical service off.

An admin function is exactly what that request was about. I don’t know whether Trade Works’ was reachable from the internet, what kind of account it used, or how the attackers found it. None of that has been disclosed. But the request’s checklist reads, in hindsight, like a description of where this attack went.

What isn’t known

I want to be careful about the gaps, because they matter.

  • How the attackers got in. IwaiCosmo says the flaw has been found and fixed. Neither company has said what the admin function was, or how it was exposed.
  • What was traded, and why. Neither company has said which shares were bought or sold, or for how much. In 2025, hijacked accounts were mostly used to dump holdings and buy thinly traded small-cap stocks, which points to price manipulation. Nothing published says the same thing happened here.
  • Who did it. Kyodo’s English report says the attack is believed to have used artificial intelligence. It doesn’t say who believes that or on what basis. Separately, researchers have tracked an AI attack tool called ARTEX aimed at Japanese companies this autumn. Nothing public links ARTEX, or anyone in particular, to this incident.
  • The six-day gap. IwaiCosmo disclosed the trades on 20 October, six days after they happened. It says it held back the details because its defenses were still being rolled out and it didn’t want to reveal how the attack worked, and it apologized for the delay. The affected customers were told on day one. That’s a defensible call, and it’s fair to ask about. It is not evidence of a cover-up.
  • Monex. On 20 October, Monex Securities stopped accepting new accounts after finding signs that someone had tried to break into a system its outside contractor runs for account opening. Monex hasn’t named the contractor or said whether anyone got in. Nothing public connects it to Trade Works. It does show that brokerages are now treating vendor systems as the weak point.

What to ask, if you depend on a vendor

You don’t need to run a brokerage for this to apply. If a vendor runs a system that can take action for your company, such as placing orders, sending messages, issuing refunds, or changing customer records, the questions are the same.

  1. Which of our vendors have admin access that can act on our customers’ accounts or our own?
  2. Who can reach those admin functions, from where, and is that access protected by more than a password?
  3. When was that configuration last reviewed, and by whom?
  4. If the vendor finds a problem, how quickly will we hear about it, and is that in the contract?
  5. If we had to switch that service off tonight, do we know how, and who decides?

If nobody can answer the first question, start there.

The part you can check from outside

You can’t see a vendor’s admin console from the outside, and nobody should try. But you can see the public signals around it: which services your domains point to, which vendors send email on your behalf, and whether anything on your public sites advertises old software. The Domain Exposure Check pulls those together from what your domain already shows the world, without testing your systems. For the vendor map itself, which systems are run by whom and with what access, that’s what Diagnostics is for.

Sources as of 09:00 JST, 22 October 2026.

Sources