--- title: "Stolen Credentials Hit Nikkei's Development Cloud โ€” Sekura" url: https://sekura.ai/blog/breach-nikkei-2026-10/ description: "Attackers used stolen credentials to access Nikkei's cloud development environment on October 7, exposing 1.83 million records. The third incident at Nikkei in roughly a month, all tied to compromised cloud credentials." updated: 2026-10-20 generator: sekura build, scripts/build-markdown.mjs --- Breach analysis ยท October 20, 2026 # Stolen Credentials Hit Nikkei's Development Cloud Attackers used stolen credentials to access Nikkei's cloud development environment on October 7, exposing 1.83 million records. The third incident at Nikkei in roughly a month, all tied to compromised cloud credentials. [All posts โ†’](https://sekura.ai/blog/) ![Sekura โ€” owl-in-shield mark](https://sekura.ai/branding/sekura-owl-v3.png) Attackers used stolen credentials to access Nikkei's cloud development environment on October 7, exposing 1.83 million records. The third incident at Nikkei in roughly a month, all tied to compromised cloud credentials. Stolen credentials gave attackers access to Nikkei's cloud development environment on 7 October, exposing a database holding 1.83 million records. Nikkei, the Japanese financial media conglomerate that publishes the Nikkei 225 index and the Financial Times, disclosed the incident on 16 October after notifying Japan's Personal Information Protection Commission five days earlier. [SecurityWeek reported](https://www.securityweek.com/hackers-steal-1-8-million-records-from-nikkei/) that the attacker used previously stolen credentials to access a cloud service Nikkei used for system development and was blocked within hours after the credentials were revoked. Of the 1.83 million records in the affected environment, roughly 1.68 million contained no identifying information. The remaining 150,000 held personal data; 120,000 of those included email addresses. No credit card information was stored in the environment, and Nikkei has identified no confirmed misuse. This was Nikkei's third disclosed security incident in approximately one month. The earlier two involved unauthorised access to employee accounts on Microsoft 365 and Google Workspace. The method by which credentials were originally stolen has not been confirmed in any of the three cases. Each incident involved a different cloud service, suggesting either broad credential exposure across multiple systems or an attacker who methodically enumerated accessible cloud services once any single identity was obtained. Nikkei brought in outside specialists after this third incident and has not named a responsible party. Two things are worth pulling out of the reporting. ## What scanners would have missed A traditional vulnerability scanner (whether SAST, DAST, or SCA) does not detect stolen credentials. That is not a caveat. It is a categorical exclusion from scope. Scanners look for patterns in code and in traffic that correspond to exploitable software defects. A credential stolen through phishing, an earlier breach, or an exposed CI/CD pipeline secret is invisible to that category of tool. The cloud development environment Nikkei used was not a public-facing consumer application. It was internal infrastructure. Scanners typically cover the attack surface that organisations designate as external. Internal tooling, development environments, and staging infrastructure are routinely left out of scope. A scanner pointed at Nikkei's production web properties would never have been directed at the development cloud service at all. There is also the reachability gap. [Continuous penetration testing](https://sekura.ai/solutions/continuous-pentesting/) exists to close precisely this: a scanner may assign a high severity score to a finding based on CVSS base metrics, while missing entirely that a single-factor-authenticated endpoint in the development infrastructure is accessible from the internet with no MFA requirement. CVSS base scores do not measure whether a real attacker can reach a component, what adjacent systems they can pivot to once inside, or how many credential paths lead to the same data store. The attacker in this case did not need a software vulnerability. They needed one stolen credential and an endpoint that accepted it. ## What Sekura would have shown Phase 2 of Sekura's pipeline is recon. The recon agent enumerates cloud assets accessible from outside the organisation's defined perimeter, including services that engineering teams often leave outside the formal asset register: development environments, CI/CD infrastructure, internal tooling, and staging systems with cloud-managed access. For a configuration like Nikkei's, the recon agent would have produced a finding along these lines: 1. A cloud service endpoint accessible with a single credential set. 2. No MFA requirement on the associated identity provider role. 3. Credential rotation policy absent or unenforced. 4. Service absent from the organisation's published asset inventory. That is not a prediction about attacker behaviour. It is a description of a configuration that any attacker with a stolen credential can exploit, documented before they arrive. An analyst reading it knows what to do: revoke the credential set, enforce MFA on the service, and verify whether other cloud services share the same credential pool. We would not claim a recon finding prevents the underlying credential theft. What it produces is a map of the blast radius: which services accept this credential, what data they can reach, and how much of the organisation is exposed if one identity is compromised. ## The bigger pattern Three cloud incidents at the same organisation in thirty days, each affecting a different service, each via stolen credentials. This is not a software vulnerability problem. It is a secrets management and identity posture problem. Perimeter scanning has become standard practice for most organisations. What remains uncommon is a clear picture of what an attacker can access after obtaining a single valid credential for any of the dozens of cloud services that engineering teams use. Development infrastructure is the most exposed category: created quickly, updated constantly, and often excluded from the access review processes that govern production systems. I think stolen credentials to development and internal cloud services are now the dominant initial access pattern for incidents at organisations with otherwise mature security programs. The Nikkei sequence is a clean illustration of why. If you want to see what a proof-first recon audit looks like on your own cloud infrastructure, [request a POC](https://sekura.ai/enterprise/#poc). ## Related reading - [Hallmark Salesforce Breach Exposes 1.7 Million RecordsApril 1, 2026](https://sekura.ai/blog/breach-hallmark-cards-2026-04/) - [Carnival breach exposes 6 million customer recordsApril 8, 2026](https://sekura.ai/blog/breach-carnival-cruise-2026-04/) - [France Titres breach exposes 11 million citizen recordsApril 22, 2026](https://sekura.ai/blog/breach-france-titres-2026-04/) [All posts](https://sekura.ai/blog/)