KDDI Breach: 14.2M Logins Exposed – Impact on ISP Supply Chains
The disclosure from KDDI Corporation regarding the exposure of up to 14.2 million email logins is a textbook case of supply chain risk in the ISP sector. The attackers compromised a single email system that serviced KDDI and five other providers, including au and Okinawa Cellular. This isn't just a data leak; it is a massive credential harvesting operation that will likely fuel credential stuffing attacks for months.
While the specific vulnerability (CVE) used for the initial access hasn't been fully detailed in the report yet, the unauthorized access to the email system implies a significant configuration failure or unpatched software vulnerability in their mail transfer infrastructure. For defenders, the immediate priority is mitigating Account Takeover (ATO) risks, particularly for users who might reuse ISP email passwords as credentials for other services.
If you have users in Japan or global partnerships with these ISPs, you should consider forcing password resets and auditing for active IMAP/POP3 sessions, as legacy protocols are often targeted with these dumps.
Here is a PowerShell snippet to help audit for suspicious inbox forwarding rules, which are often set by attackers to maintain access after a credential compromise:
Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward | Where-Object {$_.ForwardingSmtpAddress -ne $null}
Given the sheer volume of 14.2 million records, simple blacklisting isn't feasible. How are you handling password reset fatigue for users who haven't enabled MFA yet? Are you seeing specific spikes in ATO attempts originating from this region?
We started seeing a spike in 'Password Spraying' attempts against our O365 tenant shortly after the news broke. The attackers seem to be testing the leaked credentials against the cloud portal immediately.
We deployed a Conditional Access policy requiring MFA for all legacy authentication attempts to block the IMAP/POP3 vectors. It broke a few legacy scanners, but it stopped the bleed. You can track this via SigninLogs:
SigninLogs
| where LegacyAuthentication == true
| where ResultType != 0
| summarize count() by AppDisplayName, Location
The supply chain aspect here is terrifying. One compromised vendor node (the shared email system) and six ISPs take a hit.
As a pentester, I always tell clients to isolate their management planes, but ISPs are so intertwined that 'shared infrastructure' is often a selling point, not a security boundary. We're recommending all clients move to password managers and unique generated passwords for ISP accounts immediately. If you rely on your ISP email for password resets, you are effectively the weakest link.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access