Latest / Tech Talks With Kinsoft / KDDI – One Flaw, Six ISPs, 14 Million Exposed Mailboxes

Transcript

KDDI – One Flaw, Six ISPs, 14 Million Exposed Mailboxes · Tech Talks With Kinsoft

• 0:00
  So imagine this. You wake up on a random morning
• 0:04
  in June 2020 slugs. You check your phone and
• 0:07
  you find out your email provider has been completely
• 0:09
  compromised. Which is pretty much the worst way
• 0:12
  to start your day. Right. It's awful. Your stomach
• 0:14
  just drops and you know you immediately start
• 0:17
  doing the mental math of like every single thing
• 0:20
  connected to that email address your bank your
• 0:22
  shopping accounts everything. Oh yeah. The panic
• 0:24
  sets in instantly. Exactly. But. Here's the real
• 0:28
  shocker of this specific incident. For a huge
• 0:31
  portion of these victims, the security vulnerability
• 0:33
  that exposed their entire digital lives didn't
• 0:36
  even come from the provider they actually signed
• 0:38
  up with. Yeah, that's the wild part. It came
• 0:40
  from a completely different brand, like one they
• 0:42
  might never have even heard of, just sharing
• 0:44
  the same invisible basement. It's a profoundly
• 0:47
  unsettling scenario, honestly. And it really
• 0:50
  forces us to confront this reality of where our
• 0:53
  data actually lives. We just assume that when
• 0:57
  we buy a service from company A, our data stays
• 0:59
  safe within the walled garden of company A. Right,
• 1:02
  like it's locked in a vault with their logo on
• 1:04
  it. Exactly. But we don't realize that company
• 1:06
  A and company B and company C, they're often
• 1:10
  just different marketing storefronts. They're
• 1:13
  built on top of the exact same vulnerable foundation.
• 1:16
  Which brings us to what we're talking about today.
• 1:18
  Welcome to today's Deep Dive, where we are really
• 1:21
  going to unpack the architecture of that shared
• 1:23
  foundation. We're looking at a massive cyber
• 1:26
  incident involving the Japanese telecom giant
• 1:29
  KDDI. An absolute behemoth of a company. Yeah,
• 1:31
  tens of billions in revenue. And we're drawing
• 1:34
  from this really fascinating incident analysis
• 1:36
  by Tech Talks with Kinsoft. So our mission today
• 1:40
  is to kind of decode how a flaw in an unnamed
• 1:42
  third -party software system managed to expose
• 1:45
  up to 14 .2 million accounts. And we really need
• 1:49
  to look closely at the mechanics behind that
• 1:51
  exposure because... I mean, a number like 14
• 1:53
  million, that doesn't just happen by accident.
• 1:55
  No, definitely not. It is the result of compounding
• 1:57
  systemic vulnerabilities. And just to set the
• 2:00
  stakes here for everyone listening, this isn't
• 2:02
  just some story about a random tech glitch, right?
• 2:05
  It's a massive lesson in what we call concentration
• 2:07
  risk, the hidden dangers of credential reuse,
• 2:10
  and honestly, why the exact wording of a company's
• 2:14
  public apology might be the most crucial part
• 2:17
  of a data breach. Oh, absolutely. The PR spin
• 2:19
  is always telling. Right. OK, let's untack this.
• 2:22
  Let's just lay out the timeline and the scale
• 2:23
  first. So late June 2026, KDDI confirms this
• 2:28
  massive breach. that they actually detected on
• 2:30
  June 17th. Yeah, right in the middle of the month,
• 2:32
  they spot this unauthorized access. Right, and
• 2:35
  the attackers guard in by exploiting a vulnerability
• 2:37
  in some third -party software that ran a shared
• 2:39
  email system. And the ultimate fallout here is
• 2:42
  that email addresses and passwords for up to
• 2:44
  14 .2 million users were exposed. Which is just
• 2:48
  a staggering volume of data. It really is, and
• 2:51
  that includes, you know, active users, former
• 2:52
  users, and accounts that had just been sitting
• 2:55
  dormant for years to kind of wrap our heads.
• 2:58
  around this it's like well think of living in
• 3:00
  a massive ultra secure high -rise building okay
• 3:03
  I like this analogy right you think you're safe
• 3:06
  but then you discover the contractor used the
• 3:09
  exact same master key for all six high -rises
• 3:12
  on the entire block that is a brilliant way to
• 3:15
  visualize it because that's exactly how enterprise
• 3:17
  software architecture works today But, you know,
• 3:20
  what's fascinating here is that from a pure incident
• 3:23
  response perspective, KDDI actually did a few
• 3:27
  things right. Wait, really? Yeah, I know it sounds
• 3:30
  crazy given the numbers. Because exposing 14
• 3:32
  million accounts sounds like a colossal failure
• 3:34
  on literally every front. It does sound like
• 3:37
  it. Yeah. But the Kinsoft analysis points out
• 3:39
  that when they detected the compromise on the
• 3:41
  17th, they actually acted decisively. They successfully
• 3:45
  blocked the attacker. They stopped the ongoing
• 3:48
  exfiltration of data. Oh, wow. OK, so they didn't
• 3:51
  just let it bleed out. Exactly. And they didn't
• 3:54
  try to sweep it under the rug internally either.
• 3:57
  They immediately began notifying Japan's privacy
• 4:00
  regulators and they reached out to the other
• 4:02
  Internet service providers who were affected.
• 4:04
  I mean, their containment protocols actually
• 4:06
  worked. Right. But containment doesn't undo the
• 4:09
  fact that 14 million records are already gone.
• 4:12
  Precisely. The core problem that makes this so
• 4:15
  terrifying isn't their response time. The alarm
• 4:17
  bells are ringing because of the sheer scale
• 4:19
  of the initial exposure, the blast radius. Right,
• 4:22
  the blast radius, which leads perfectly into
• 4:24
  the first major structural issue from the Kinsloff
• 4:27
  report, this idea of concentration risk. Because
• 4:30
  that massive number, it isn't just because KDI
• 4:33
  has a lot of customers. Not at all. It is entirely
• 4:35
  due to that shared master key architecture you
• 4:38
  mentioned earlier. In cybersecurity, we talk
• 4:40
  constantly about blast radius, like how far does
• 4:43
  the damage spread when one single component fails?
• 4:46
  And in this case, it spread really far. Unbelievably
• 4:48
  far. Because that shared email platform wasn't
• 4:51
  just for KDI's direct customers. It was the silent
• 4:54
  engine sitting behind six completely different
• 4:56
  ISP brands. Six different brands. So it's KDDI
• 4:59
  plus... Let me check the list here. JCOM, Nifty,
• 5:03
  Big Lobe, Chubu Telecommunications, and STNet.
• 5:06
  Yeah. And to the average consumer, those are
• 5:09
  competitors. Yeah, totally separate companies.
• 5:11
  Exactly. So imagine you had a terrible customer
• 5:14
  service experience with KDDI five years ago.
• 5:17
  You get mad, you cancel, and you intentionally
• 5:19
  switch to NiftyY, thinking you're moving your
• 5:23
  data to a safer, separate infrastructure. Right.
• 5:25
  You're like, take that, KDDI. You're right. But
• 5:28
  underneath the distinct branding and the different
• 5:30
  websites, you are literally just moved to a different
• 5:33
  server rack in the exact same backend environment.
• 5:35
  Man, that is frustrating. So what does this all
• 5:39
  mean for you listening to this deep dive right
• 5:41
  now? Think about your own workplace. Think about
• 5:44
  the digital tools you rely on every day. We all,
• 5:47
  you know, we love the efficiency of shared infrastructure.
• 5:49
  We rely on it completely. Yeah. It's why we use
• 5:51
  centralized cloud providers and universal single
• 5:54
  sign on. But how many of your own business operations
• 5:56
  quietly depend on a single shared component?
• 6:00
  Like what happens the day that one piece of third
• 6:02
  party software just fails? Well, as we see here,
• 6:05
  the blast radius multiplies exponentially. And
• 6:08
  this is entirely driven by the business economics
• 6:10
  of tech consolidation. I mean, from a CFO's perspective,
• 6:14
  it makes perfect financial sense to centralize
• 6:17
  your back -end systems across all your subsidiary
• 6:20
  brands. Oh, sure. You cut costs. Exactly. You
• 6:23
  reduce your server overhead. You only pay one
• 6:25
  IT maintenance team instead of six. You streamline
• 6:28
  your updates. I mean, you are building this incredibly
• 6:30
  efficient machine. But efficiency always comes
• 6:32
  with a hidden tax. Always. And the hidden tax
• 6:35
  of efficiency is extreme fragility. By centralizing
• 6:40
  everything to save a few bucks, you have effectively
• 6:43
  subsidized the attacker's return on investment.
• 6:45
  Subsidized the attacker? Think about it. Instead
• 6:48
  of a hacker having to figure out six different
• 6:50
  ways to breach six different companies, they
• 6:52
  only have to find one single flaw in that shared
• 6:55
  third -party software. And once they break down
• 6:57
  that one door? They get the data for all six
• 6:59
  brands simultaneously. We are building these
• 7:01
  massive, highly optimized digital towers, but
• 7:04
  we're balancing them on single points of failure.
• 7:06
  Which is terrifying. But exposing that shared
• 7:10
  server isn't even the end of the story. Because
• 7:12
  the attackers, you know, they aren't just sitting
• 7:14
  around looking at a spreadsheet of 14 million
• 7:17
  email addresses. They immediately weaponize that
• 7:20
  data. Which brings us to the fuel for the fire
• 7:22
  here. credential stuffing. Yeah, because an email
• 7:26
  address and a password combo, it's not just an
• 7:29
  isolated piece of information. It is literal
• 7:31
  currency in the cyber criminal underground. I
• 7:33
  think a lot of people just assume like, oh, my
• 7:36
  telecom provider got hacked, whatever. The worst
• 7:38
  they can do is read my spam folder. Right. Or
• 7:40
  look at your old phone bills. Exactly. But the
• 7:42
  real threat has absolutely nothing to do with
• 7:44
  the telecom provider at all. Not even a little
• 7:47
  bit. Attackers do not care about your old emails.
• 7:50
  What they care about is human psychology. They
• 7:53
  know that we all suffer from extreme password
• 7:56
  fatigue. Oh, I certainly do. We all do. You're
• 7:59
  asked to create an account for everything. Your
• 8:01
  bank, your pharmacy, your streaming services,
• 8:04
  the place you order pizza from. And as a result,
• 8:07
  the vast majority of people just reuse the same
• 8:09
  two or three passwords across their entire digital
• 8:12
  life. Here's where it gets really interesting.
• 8:14
  It's like using the exact same key for your front
• 8:18
  door, your car, your safe, and your office. So
• 8:21
  a thief... steals your key ring from, say, a
• 8:24
  hotel valet. The thief doesn't care about your
• 8:27
  car in the hotel parking lot. No, they don't
• 8:29
  care about the hotel at all. Right. They take
• 8:30
  that key and they walk down every street in your
• 8:33
  hometown just hitting the unlock button over
• 8:35
  and over again until your front door at home
• 8:37
  suddenly clicks open. The vulnerability isn't
• 8:40
  just the email leak. It's the human habit of
• 8:43
  password reuse. That is the exact mechanism of
• 8:46
  credential stuffing. But you have to realize
• 8:49
  it is happening at a scale and speed that is
• 8:52
  almost impossible to comprehend. When attackers
• 8:54
  get a data set from a breach like KDDI, they
• 8:57
  don't type them in by hand. They feed those millions
• 9:00
  of username and password pairs into sophisticated
• 9:02
  automated bot networks. OK, wait, I have to jump
• 9:05
  in here because don't most modern websites have
• 9:07
  defenses against that? Like if I type my bank
• 9:09
  password wrong three times, I get locked out
• 9:11
  or I have to click on, you know, all the pictures
• 9:13
  of crosswalks in a CAPTCHA. How are the bots
• 9:16
  getting past that? That is a great question.
• 9:18
  And it's where the economics of cybercrime get
• 9:21
  incredibly advanced. The hackers know all about
• 9:24
  rate limiting, that defense that locks you out
• 9:28
  after three tries. To bypass it, they use something
• 9:31
  called rotating residential proxies. Basically,
• 9:34
  they route their bot traffic through millions
• 9:37
  of hijacked home internet connections all around
• 9:40
  the world. So to your bank's security system,
• 9:43
  it doesn't look like one hacker in a basement
• 9:45
  trying 10 ,000 passwords. Oh, wow. It looks like
• 9:48
  10 ,000 normal people. Exactly. It looks like
• 9:50
  10 ,000 regular customers sitting in their living
• 9:53
  rooms trying to log in exactly one time. They
• 9:56
  fire these stolen credentials at corporate VPNs,
• 9:59
  healthcare databases, Amazon accounts, all simultaneously.
• 10:03
  So they just completely circumvent the basic
• 10:05
  security tripwires. Entirely. And if we connect
• 10:08
  this to the bigger picture. This exact mechanism
• 10:11
  is why enterprise IT leaders are so aggressively
• 10:13
  pushing for zero -trust architecture. It is exactly
• 10:17
  why you, the listener, are constantly dealing
• 10:19
  with security friction at work. You mean the
• 10:21
  endless nagging to use an authenticator app?
• 10:24
  Yes. The nagging has a very specific critical
• 10:27
  purpose. This credential stuffing pipeline is
• 10:31
  why enforced multi -factor authentication MFA
• 10:34
  is simply no longer optional. Right. Because
• 10:37
  even if they have the password. Even if the attacker
• 10:39
  has your exact password from the KDDI breach,
• 10:42
  if they do not have that temporary six digit
• 10:45
  token generated on your physical phone, that
• 10:48
  stolen password is mathematically useless to
• 10:51
  them. That makes so much sense. It's also why
• 10:53
  relying on human memory for passwords is just
• 10:55
  a fundamentally failed security model. Strict
• 10:58
  password managers and never reusing a password.
• 11:01
  Those aren't just for tech geeks anymore. They're
• 11:03
  the only way to structurally break the chain.
• 11:05
  OK, so we see. how the ghost kitchen architecture
• 11:07
  allowed the breach to happen in the first place
• 11:09
  right and we see this devastating economic machinery
• 11:12
  that takes the stolen data and weaponizes it
• 11:15
  but um there is another layer to the story that
• 11:17
  i found incredibly revealing when reading the
• 11:19
  kinsoft analysis and it happens right after the
• 11:22
  dust settles ah yes when the company actually
• 11:25
  has to face the public Yes, the crisis communication.
• 11:28
  Because the way a company words its breach disclosure
• 11:31
  might actually be the most vital metric we have
• 11:34
  to judge their internal culture by. Let's look
• 11:37
  at KDDI's actual public disclosure. When they
• 11:40
  announced the breach, they included the specific
• 11:42
  line noting that, quote, some of the compromised
• 11:46
  passwords were hashed or encrypted. Right. And
• 11:49
  they crucially omitted two massive pieces of
• 11:51
  information there. First, they completely refused
• 11:54
  to state which specific cryptographic algorithm
• 11:56
  they used. And the second, they refused to clarify
• 11:59
  what percentage of the passwords fell under the
• 12:01
  category of some versus how many were just left
• 12:04
  completely unprotected in plain text. Now, wait,
• 12:06
  let me play devil's advocate for a second here,
• 12:08
  because when I read the passwords were encrypted,
• 12:10
  my immediate reaction is relief. It sounds reassuring.
• 12:13
  If a password is run through a hashing algorithm,
• 12:15
  it's scrambled into random gibberish. So even
• 12:18
  if the hackers stole the whole database, isn't
• 12:20
  the data essentially useless to them anyway?
• 12:22
  Well, this raises an important question, and
• 12:24
  it completely exposes the danger of vague reassurance.
• 12:27
  Because not all encryption is created equal.
• 12:30
  In fact, saying your data is hashed without naming
• 12:33
  the algorithm, it's the cybersecurity equivalent
• 12:36
  of saying your front door is locked without mentioning
• 12:39
  that the lock is made of wet cardboard. Wait,
• 12:42
  really? But a hash is a one -way mathematical
• 12:44
  function, isn't it? Like you can't just unhash
• 12:47
  something. In theory, yes. If KDDI used a modern
• 12:52
  computationally expensive hashing algorithm,
• 12:54
  something like bcrypt or Argon2, along with a
• 12:57
  unique randomized salt for every single user,
• 12:59
  then you're totally correct. It would take forever
• 13:01
  to crack. Right. It would take an attacker an
• 13:04
  absurd amount of computing power and literally
• 13:06
  decades of time to guess those passwords. We
• 13:10
  don't actually know if they use those modern
• 13:11
  algorithms. Because they wouldn't say. Because
• 13:13
  they wouldn't say. And a lot of older legacy
• 13:16
  IT environments, which, by the way, are the exact
• 13:18
  kind of environments that get rolled up these
• 13:19
  massive corporate consolidations companies, are
• 13:21
  often still using obsolete hashing algorithms
• 13:23
  like MD5 or SHA1. And those are bad. They were
• 13:27
  designed decades ago to be fast, which is the
• 13:31
  exact opposite of what you want for password
• 13:33
  security. You want password hashing to be slow
• 13:35
  and expensive. Okay, but even if it's an older
• 13:38
  algorithm, if it's still a one -way function,
• 13:40
  how do the hackers actually crack it? Oh, they
• 13:43
  don't even bother cracking them manually. They
• 13:45
  use something called a rainbow table. A rainbow
• 13:47
  table. Yeah, because older algorithms like MD5
• 13:50
  compute so incredibly fast, hackers have already
• 13:54
  pre -calculated the hashes for literally... billions
• 13:57
  of common passwords. Right. Like they already
• 13:59
  had these massive lookup tables sitting on their
• 14:01
  hard drives. Yeah. So if they steal a database
• 14:03
  of MDFI hashes, they don't compute anything.
• 14:06
  They just compare the gibberish in your database
• 14:08
  against their pre -calculated rainbow table.
• 14:11
  It takes a matter of seconds to reverse engineer
• 14:13
  millions of passwords. Wow. Okay. So if KDDI
• 14:16
  used an outdated algorithm, the fact that they
• 14:19
  said the passwords were hashed offers basically
• 14:22
  zero actual protection against a modern attacker?
• 14:25
  Correct. And by withholding the name of the algorithm,
• 14:28
  KDDI is actively preventing security professionals
• 14:31
  and their own users from accurately calculating
• 14:34
  their true risk level. It is the difference between
• 14:37
  genuine transparency and just, you know, PR damage
• 14:41
  control. Which brings us to that second omission,
• 14:44
  which honestly feels even more deceptive to me.
• 14:46
  Using the word some to describe how many passwords
• 14:50
  were protected. Oh, in statistics and cybersecurity,
• 14:52
  some is a terrifying word. Right. Because if
• 14:55
  some means, say, 99 percent of the 14 million
• 14:59
  accounts were strongly encrypted and maybe 1
• 15:01
  percent slipped through in plain text because
• 15:02
  of some weird logging error. I mean, that's a
• 15:05
  problem, but it's a contained problem. Exactly.
• 15:07
  But some could also mean 10 percent. Yeah. If
• 15:11
  some means only the newest accounts created in
• 15:13
  the last year were hashed. Yeah. And 90 percent
• 15:15
  of the legacy database was just sitting there
• 15:17
  in plain readable text for anyone to download.
• 15:19
  I mean, that is a catastrophic failure of basic
• 15:22
  security hygiene. So by using this vague language,
• 15:25
  they get to sound super reassuring to the press
• 15:27
  while essentially leaving their own users completely
• 15:30
  in the dark about how fast they actually need
• 15:32
  to be changing their banking passwords. Because
• 15:34
  silence matters immensely in cybersecurity. Transparency
• 15:39
  isn't just about issuing an apology. An apology
• 15:41
  does not secure a network. True transparency
• 15:44
  is about providing actionable technical intelligence
• 15:47
  to the victims so they can protect themselves.
• 15:50
  Vague reassurance actively erodes trust because
• 15:53
  it signals to the industry that you are either
• 15:55
  hiding severe negligence or worse, that your
• 15:58
  own internal IT teams don't actually know the
• 16:01
  extent of the damage yet. Specific honest detail,
• 16:04
  even when the news is objectively terrible. builds
• 16:07
  trust. It empowers the customer. Okay, so as
• 16:09
  we pull all of these threads together, let's
• 16:11
  recap the real journey of this deep dive. Because
• 16:13
  the KDDI breach of June 2026, it is so much more
• 16:17
  than just a story about a software bug. It really
• 16:19
  is a masterclass in evaluating the blast radius
• 16:21
  of shared infrastructure. Exactly. We've seen
• 16:24
  how that relentless drive for digital efficiency
• 16:26
  breeds massive concentration risk. We've explored
• 16:29
  the cascading dangers of credential stuffing
• 16:31
  and how our bad password habits basically fuel
• 16:34
  the fire. And finally, we've seen why the absolute
• 16:37
  necessity of transparent, specific crisis communication
• 16:41
  is so critical. It's a stark warning, really,
• 16:44
  for everyone. it is and there is incredibly actionable
• 16:48
  advice here for you listening right now the kinsoft
• 16:52
  analysis strongly suggests taking time to map
• 16:55
  out your own single points of failure look at
• 16:57
  your vendors look at your software stack where
• 17:00
  is your concentration risk quietly hiding. It's
• 17:03
  always hiding somewhere. Always. And if you need
• 17:05
  a starting point for that kind of audit, Kinsoft
• 17:07
  actually offers great resources for mapping this
• 17:09
  stuff out at kinsoft .com .au. Their core mantra
• 17:12
  for this is really one we should all adopt. Stay
• 17:14
  patched, stay skeptical. And I would just add
• 17:17
  a quick point regarding consumer empowerment.
• 17:19
  When a service provider you use is breached,
• 17:22
  and let's be real, statistically speaking, you're
• 17:24
  going to be caught in one of these eventually,
• 17:26
  do not settle for the boilerplate PR email assuring
• 17:29
  you that they, quote, Take your security seriously.
• 17:33
  I hate that phrase. Right. You are fully entitled
• 17:36
  to ask planted questions. Demand the technical
• 17:38
  truth. Was the data encrypted? What specific
• 17:41
  cryptographic algorithm was utilized? Were the
• 17:44
  passwords salted? Don't let them hide behind
• 17:46
  vague words like some. Demand the specifics so
• 17:50
  you can accurately gauge your own risk. Which
• 17:52
  leaves us with a final lingering thought to ponder
• 17:55
  as we wrap up today. We've seen that our digital
• 17:57
  economy is entirely driven by consolidation.
• 17:59
  Sharing servers. Centralizing identity access.
• 18:03
  Rolling multiple brands into single back -end
• 18:05
  platforms. forms, right? It all drives operational
• 18:07
  efficiency. But as we continue to centralize
• 18:10
  more and more of our digital lives into fewer
• 18:12
  and fewer massive interconnected hubs, are these
• 18:15
  cascading catastrophic failures simply the unavoidable
• 18:18
  tax we must pay for modern convenience? Or as
• 18:21
  the blast radius of these breaches continues
• 18:23
  to grow, is it time to start intentionally building
• 18:25
  a little bit of inefficiency and isolation back
• 18:27
  into our systems?