When a contractor's legitimate account is the way in: what the NEC subcontractor attack and the Blastmail breach mean for your company this week

Key points for company leaders

This article reflects information available on the afternoon of 23 October 2026 (Japan time). Both incidents are still under investigation. For the latest, check the announcements listed in the sources at the end.

• What happened

  According to NEC, a company it uses for system development and maintenance was attacked in late September. Stolen credentials for a legitimate account were used to access NEC customers' systems from the contractor's device, and files on servers were encrypted, leaving systems unusable.^[1]

• What leaked

  Files leaked from cloud storage that NEC set up and used to share information between customers, NEC and contractors. They contained customers' personal data and system information. Osaka Metropolitan University says it was told that personal data and system information related to the university leaked.^[1][2]

• A second case

  On 21 October RAKUS said an outsider broke into two API servers of its subsidiary's email delivery service Blastmail and took every contract customer's company name, contact names, phone numbers, email addresses, and contract and payment history. For some customers, delivery lists also leaked.^[3]

• What to do this week

  List every contractor and subcontractor account that can log in to your systems and cloud services, disable the ones no longer used, and check where they connect from and whether they use multi-factor authentication. Also review whether storage you share with contractors holds more personal data or passwords than it needs to.^[4][5]

What happened in the attack through NEC's contractor

NEC's 20 October statement describes two kinds of damage. First, a legitimate account was used from the contractor's device to access customers' system environments, and files on servers were encrypted, leaving various systems unusable. Second, files leaked from cloud storage used to share information among the parties. NEC says it has contacted the affected customers individually and will report details of the leaked personal data to them as they become clear.^[1]

In its fifth notice on 21 October, Osaka Metropolitan University said NEC, which maintains and operates its core systems, reported that the outage of 2 October was caused by unauthorised access to the university's systems using a legitimate account held by NEC's subcontractor. The university says it is still confirming with NEC what leaked and how much.^[2]

The business systems the university said at its 5 October press conference might have leaked data (including about 130,000 records related to academic affairs) sit on the university's own virtualisation platform, and are separate from the information in NEC's cloud storage. Whether data leaked from that platform is still under investigation.^[2]

The other shape: a leak at the service provider

According to RAKUS's second report on 21 October, an outsider broke into two API servers of its subsidiary RAKUS Light Cloud, ran commands, connected to the sales management system and the service database, and took data out. The company says it does not hold credit card numbers. The service has been down since 00:30 on 21 October with no restart date, and the exact entry route is still under investigation.^[3]

The NEC case is about a contractor's access being used to get into your own systems. The Blastmail case is about data you entrusted to a provider being taken from that provider's systems. Either way, however well you secure your own servers, a breach on a partner's side can still stop your systems or leak your data.^[1][3]

Timeline

Six things to check this week

IPA's collection of practices describes identifying contractors that carry cyber risk, checking their security through a questionnaire, and reporting the gaps to leadership so the organisation can decide what to do. Its sample questionnaire even asks whether the contractor knows how well its own subcontractors are secured. In light of these incidents, check the following.^[4][6]

1. 01Take stock of accounts: list every contractor and subcontractor account that can log in to your servers, cloud services, admin screens and VPN, and disable those whose contract has ended or that are no longer used.^[4][5]
2. 02Ask about subcontracting: check whether your contractors hand work on to other companies, and if so, which accounts those companies use.^[2][4]
3. 03Check where they connect from and how they sign in: confirm which devices and routes contractors use to connect, and whether they use multi-factor authentication. As one countermeasure, NEC is lending contractors devices it manages.^[1][5]
4. 04Review shared storage: check whether cloud storage used with contractors holds more personal data, passwords or configuration details than it needs, and delete what is not needed. JPCERT/CC also advises not keeping data past its retention period or purpose.^[1][5]
5. 05Know what you have entrusted: list the customer lists and contact data you keep in outside cloud services such as email delivery, and confirm that the contact address registered with each provider is current.^[3][4]
6. 06Check logging and first response: confirm you record contractor account logins and actions, and that you know whom to call and what to do if something looks wrong. JPCERT/CC recommends reviewing defences against lateral movement after a breach, as well as intrusion detection and first response.^[5][6]

• Sample questions for contractors (IPA)

  Do you have a security policy? Is there a security management structure for the work you do for us? Do you train the people doing it? Do you know how well your subcontractors are secured?^[4]

• Sample questions on outside attacks (IPA)

  Do you restrict network paths? Do you have intrusion prevention in place? Do you monitor for malicious traffic? Do you have incident response and recovery procedures?^[4]

If a partner tells you it has been breached

• Find out what was affected: both NEC and RAKUS say they will contact affected customers individually. Keep a record of what they tell you and work out which of your data is involved.^[1][3]
• Change credentials the partner used: change or revoke passwords and API keys you shared with the partner. JPCERT/CC recommends being able to revoke API tokens quickly when a leak is suspected.^[5]
• Prepare for knock-on harm to customers: JPCERT/CC suggests telling customers in advance how to protect themselves if a leak happens, for example with multi-factor authentication.^[5]
• Know whom to ask: JPCERT/CC accepts requests for help with incident response.^[5] A personal data leak may also require reports to the authorities and notices to the people affected under Japanese law, so get expert advice early.

JPCERT/CC also updated its alert on 23 October

JPCERT/CC updated its alert on the wave of intrusions at Japanese organisations (JPCERT-AT-2026-0030) on 23 October. It added Case E: attackers abusing AI-driven penetration testing platforms such as Cairn, CyberStrikeAI and ARTEX to probe mainly internet-facing web applications for vulnerabilities and to try to steal configuration and backup files. This includes attempts against internet-facing WSUS servers.^[5]

Case B in the same alert lists attackers using API keys stolen in breaches of other systems. The lesson is the same as in the NEC case: credentials stolen somewhere else can become the way into your company. The alert also lists suspicious source IP addresses, which you can use to check your own and your contractors' logs.^[5]

FAQ

Printable checklist

• Listed every contractor and subcontractor account that can log in to our systems
• Disabled accounts whose contract has ended or that are no longer used
• Checked whether our contractors pass work on to other companies
• Checked where contractors connect from (devices and routes) and whether they use multi-factor authentication
• Removed unneeded personal data and passwords from storage we share with contractors
• Listed the customer lists and contact data we keep in outside services
• Confirmed the contact details registered with each provider are current
• Logged contractor account sign-ins and actions, and assigned someone to review them
• Checked our own and our contractors' logs for the suspicious IP addresses in JPCERT/CC's alert
• Agreed whom to contact and what to do first if a partner is breached

How ZeroKai can help

When contractors run things for you, it is easy to lose track of which servers and admin screens can be seen from the internet. ZeroKai takes your domain, lists the host names recorded in Certificate Transparency logs and highlights names that look like admin screens or test environments. For domains whose ownership you have verified, it also shows exposed remote access, file sharing, database and FTP services observed by Shodan. You can use it as a list of what is visible from outside when you go through these checks with your contractors.