Latest / Tech Talks With Kinsoft / Mathspace - 1,079,819 People, a 23-Day Gap, and the Advisory That Never Reached Anyone

Transcript

Mathspace - 1,079,819 People, a 23-Day Gap, and the Advisory That Never Reached Anyone · Tech Talks With Kinsoft

• 0:00
  Imagine leaving your front door wide open when
• 0:02
  you go to bed. Right. Which is just terrifying
• 0:04
  to think that. Exactly. And, you know. Not because
• 0:07
  you don't have a lock. You have this fantastic
• 0:10
  state -of -the -art lock. And it's not like you
• 0:12
  deliberately decided to take a risk either. Yeah,
• 0:15
  you didn't just forget. No, you left the door
• 0:17
  open simply because the sticky note reminding
• 0:20
  you to turn the deadbolt got lost in the mail.
• 0:23
  Like a piece of paper literally just didn't reach
• 0:25
  the right desk. A total administrative failure.
• 0:28
  Yeah, and because of that one little bureaucratic
• 0:30
  hiccup, over a million people had their personal
• 0:33
  data exposed. It's wild. So welcome to today's
• 0:37
  deep dive. I am your host. And as always, I'm
• 0:40
  joined by our resident cybersecurity expert to
• 0:42
  help me figure this out. Glad to be here. This
• 0:44
  is a really fascinating case to unpack. It really
• 0:46
  is. We are looking at a massive cybersecurity
• 0:49
  incident involving the Australian ed tech company,
• 0:53
  Mathspace. We're pulling our source material
• 0:55
  today from a breakdown on a show called Tech
• 0:58
  Talks with Kinsoft. A really great breakdown,
• 1:00
  by the way. Yeah, absolutely. What becomes immediately
• 1:03
  clear from their reporting is that the biggest
• 1:06
  threat to your data isn't always like. a brilliant
• 1:09
  hacker bypassing some firewall, sometimes it's
• 1:12
  just a catastrophic failure of mundane office
• 1:14
  communication. Which completely flips how we
• 1:17
  usually think about risk, you know? Right. I
• 1:19
  mean, you assume a breach of this scale requires
• 1:22
  zero -day exploits deployed by these nation -state
• 1:25
  actors in some high -stakes digital chess match.
• 1:28
  Like in the movies. Exactly, like a movie. But
• 1:30
  in reality, modern breaches are almost always
• 1:32
  process failures first. A patch gets released,
• 1:35
  the alert goes into an unmonitored inbox, and
• 1:38
  the attackers simply walk through an open vulnerability.
• 1:41
  So for anyone listening, whether you manage an
• 1:43
  enterprise IT network or you just trust your
• 1:45
  data to cloud platforms, which, I mean, that's
• 1:48
  literally all of us. Yeah, everyone. Understanding
• 1:50
  the anatomy of this specific breach reveals exactly
• 1:53
  how threat actors exploit that gap between a
• 1:56
  security alert being published and a company
• 1:59
  actually hitting update. The dangerous gray area.
• 2:01
  Right. So to understand the break -in, we really
• 2:04
  have to look at the target. Which strangely wasn't
• 2:07
  their main vault. Yeah, it wasn't. Because Mathspace
• 2:09
  is a major player. They were founded in Sydney
• 2:12
  back in 2010, and they run this online mathematics
• 2:15
  learning platform that is heavily utilized across
• 2:17
  roughly 3 ,400 Australian schools. And they have
• 2:22
  a massive presence overseas too, right? Yeah.
• 2:24
  In New Zealand, the U .S., and the U .K. Yeah,
• 2:26
  so they sit on a mountain of student and teacher
• 2:29
  data, but the hackers didn't break into the student
• 2:32
  learning platform. They compromised a secondary
• 2:34
  tool. called Metabase. Yeah, and Metabase is
• 2:37
  business intelligence software. It's essentially
• 2:40
  an internal visualization tool for the staff.
• 2:43
  Okay, so what does it actually do? Well, instead
• 2:45
  of making your staff write raw SQL queries to
• 2:48
  figure out how many users signed up last month,
• 2:51
  Metabase connects directly to your databases.
• 2:53
  Right. And it lets employees build dashboards
• 2:55
  and charts through this really simple graphical
• 2:58
  interface. Super common. Wait, so if this is
• 3:00
  just an internal tool for staff to make pie charts,
• 3:03
  why on earth is it reachable from the open Internet?
• 3:06
  Like, why isn't it locked behind a VPN or entirely
• 3:09
  walled off? That paradox is actually a massive
• 3:13
  vulnerability across modern corporate architecture.
• 3:16
  Really? Oh, yeah. In the era of remote work and
• 3:19
  cloud native infrastructure, the whole concept
• 3:21
  of a secured perimeter is almost extinct. Companies
• 3:25
  deploy tools like Metabase in cloud environments,
• 3:28
  like AWS or Google Cloud, to easily connect them
• 3:32
  to their cloud data warehouses. Ah, okay, so
• 3:34
  it's about convenience. Exactly. For convenience,
• 3:37
  so a remote product manager can log in without
• 3:39
  wrestling with a clunky VPN, the instance is
• 3:42
  often just left exposed to the public internet.
• 3:44
  But it's not like you can just Google it, right?
• 3:46
  Well, no, it might not have a public DNS record
• 3:48
  like dashboard .mathspace .com. But attackers
• 3:52
  don't use URLs anyway. They use automated scanners.
• 3:55
  Oh, wow. So they're just constantly looking.
• 3:57
  Yeah. These scanners constantly ping every single
• 4:00
  IP address on the Internet looking for a specific
• 4:02
  software signature. Yeah. If it's exposed, they
• 4:05
  will find it in minutes. And when they found
• 4:07
  this one, they definitely hit the jackpot. The
• 4:09
  vulnerability here, which was cataloged as CVE
• 4:12
  -2026 -72898, was an unauthenticated SQL injection
• 4:17
  in the password reset endpoint. A really nasty
• 4:20
  one. Yeah, the industry gave this a CVSS severity
• 4:23
  score of 10 .0 out of 10. Which is the absolute
• 4:26
  maximum. You can't get worse than a 10. Right,
• 4:29
  but I want to understand the actual mechanism
• 4:30
  here. How does a simple password reset page hand
• 4:34
  over the keys to the entire system? So a SQL
• 4:36
  injection happens when an application fails to
• 4:39
  properly sanitize the input a user types into
• 4:43
  a form. Sanitize meaning like checking to make
• 4:45
  sure it's actually an email address. Precisely.
• 4:47
  In a normal password reset, you type your email.
• 4:50
  And the backend database checks if that email
• 4:52
  exists. Yeah. But with this vulnerability, an
• 4:55
  attacker doesn't type an email. They type raw
• 4:57
  database commands into that text box. Oh, geez.
• 5:00
  Yeah. And because Metabase didn't filter that
• 5:02
  input, the underlying database just executed
• 5:04
  the attacker's commands as if they were legitimate
• 5:07
  instructions from the system itself. So they're
• 5:09
  essentially tricking the database into hijacking
• 5:11
  itself. Exactly. And what pushes this to a CVSS
• 5:15
  10 .0 is the unauthenticated part. Right. They
• 5:18
  don't even need an account. Nope. The attacker
• 5:20
  doesn't need to steal a password. They don't
• 5:22
  need to guess a credential or possess any existing
• 5:24
  privileges. They can just hit the public -facing
• 5:27
  password reset page, inject the malicious SQL
• 5:30
  code, and instantly grant themselves administrative
• 5:33
  access to the entire Metabase instance. Wow.
• 5:36
  It is the absolute worst -case scenario. Zero
• 5:39
  friction, zero authentication. Total system compromise.
• 5:42
  OK, so because that specific door was exposed,
• 5:45
  a ticking clock started the second this vulnerability
• 5:48
  was publicly announced. The race was on. Yeah.
• 5:50
  And the timeline Kinsoff lays out here is just
• 5:53
  agonizing. It perfectly illustrates the terrifying
• 5:56
  speed of modern attackers versus the lumbering
• 5:59
  slowness of corporate bureaucracy. It's a classic
• 6:01
  mismatch. It really is. So on August 6th, Metabase
• 6:05
  officially publishes the security advisory and
• 6:07
  releases a patch. The fix is live. Right. The
• 6:10
  vendor did their job. But then, just two days
• 6:12
  later, on August 8th, threat intelligence confirms
• 6:15
  this is being actively exploited in the wild.
• 6:18
  Attackers have already weaponized the flaw. 48
• 6:21
  hours later. That is so fast. I know. Then, on
• 6:24
  August 11th, the U .S. Cybersecurity and Infrastructure
• 6:27
  Security Agency, CISA, adds this exact vulnerability
• 6:31
  to their known exploited vulnerabilities catalog.
• 6:34
  Which is a huge deal. That catalog is the gold
• 6:37
  standard for what you need to fix yesterday.
• 6:39
  Right. So by August 11th, we have... It really
• 6:41
  comes down to the psychology and the mechanics
• 6:43
  of alert fatigue. Alert fatigue. Yeah. Imagine
• 6:47
  trying to find a single life -saving text message
• 6:49
  while you're standing on the floor of a noisy
• 6:52
  casino with alarms and flashing lights going
• 6:55
  off in every direction. That sounds like a nightmare.
• 6:57
  That is exactly what managing enterprise software
• 7:00
  vulnerabilities feels like right now. A modern
• 7:03
  company uses hundreds of different software libraries,
• 7:06
  APIs, and vendor tools. Right. It's not just
• 7:09
  one software they're running. No, it's a massive
• 7:12
  web. Dozens of new CVEs are published every single
• 7:15
  day. If your organization doesn't have a strict
• 7:18
  programmatic mapping that routes a specific alert
• 7:21
  for a specific tool directly to the human engineer
• 7:24
  responsible for maintaining it. It just gets
• 7:26
  lost. Yeah. That alert drops into a generic IT
• 7:29
  admin inbox. Basically the digital equivalent
• 7:31
  of a junk drawer. Exactly. It gets buried under
• 7:34
  100 other automated emails. Or. Quite commonly,
• 7:38
  the developer who initially set up that specific
• 7:40
  Metabase instance two years ago has left the
• 7:43
  company, and the vendor security alerts are just
• 7:45
  bouncing off a deactivated email address. So
• 7:48
  while that alert is sitting in a dead inbox,
• 7:51
  the attackers are moving. Oh, they are moving
• 7:53
  fast. Just four days after the patch was published,
• 7:56
  on August 10th, attackers successfully breached
• 7:58
  Mathspace's Metabase instance. Four days. Four
• 8:02
  days. That is the gap between a software vendor
• 8:05
  announcing a flaw and an attacker kicking down
• 8:08
  your door. But they didn't actually steal the
• 8:12
  data right away, did they? No, they didn't. And
• 8:14
  this really highlights the operational patience
• 8:16
  of modern threat actors. They breached the system
• 8:20
  on August 10th, but they waited until August
• 8:22
  27th to actually execute their primary objective
• 8:25
  and exfiltrate the Australian reporting database.
• 8:28
  That is 17 days of dwell time just sitting there.
• 8:32
  Right. During that window, they were likely mapping
• 8:34
  the environment, trying to understand what Metabase
• 8:36
  was connected to, and ensuring they had stable,
• 8:39
  persistent access before making a noisy move
• 8:41
  like downloading massive databases. Because downloading
• 8:44
  a database triggers alarms, right? Exactly. It
• 8:47
  creates a spike in network traffic. So they want
• 8:49
  to be sure they have everything set up before
• 8:51
  they pull the trigger. Meanwhile, Mathspace remains
• 8:53
  completely unaware. It took them until August
• 8:57
  29th, which is 23 days after the initial alert,
• 9:00
  to finally apply the Metabase patch. 23 days
• 9:04
  is a fatal delay for an internet -facing zero
• 9:08
  day. Yeah, and they only patched it because a
• 9:10
  completely separate subsequent notice happened
• 9:13
  to catch their attention. It was pure luck they
• 9:15
  even saw the second notice. Right. But what happens
• 9:18
  on August 29th is arguably the most instructive
• 9:21
  failure in this entire case. Because you would
• 9:24
  assume August 29th is the finish line. You'd
• 9:26
  think so, yeah. They finally applied the patch.
• 9:28
  They turned the deadbolt. Problem solved. Yeah,
• 9:30
  the false finish line. What do you mean? Well,
• 9:32
  when you apply a patch, all you are doing is
• 9:35
  updating the software's code so that specific
• 9:37
  vulnerability no longer exists. You have fixed
• 9:40
  the lock on the door. But Mathspace stopped there.
• 9:43
  Right. They completely... failed to carry out
• 9:46
  the compromise checks that Metabase explicitly
• 9:49
  warned all users to perform if their instance
• 9:52
  had been internet exposed. Yeah, the source outlines
• 9:55
  those checks. They recommend session revocation,
• 9:58
  API key review, admin account review, and credential
• 10:02
  rotation. Crucial steps. But why are those specific
• 10:06
  actions so critical mechanically? Like if you
• 10:10
  patched the hole, aren't the attackers locked
• 10:12
  out? Not if they left a back door open from the
• 10:14
  inside. Oh, I see. Let's break down the mechanics
• 10:17
  here. If a hacker had administrative access for
• 10:20
  nearly three weeks, they didn't just browse around.
• 10:23
  They likely generated their own API keys. And
• 10:26
  what exactly does an API key do in this context?
• 10:40
  Wow. Yeah. So what does this all mean for the
• 10:56
  listener? It is basically like coming home. Finding
• 11:00
  your front door wide open, locking it, and then
• 11:02
  just sitting on the couch to watch TV without
• 11:05
  checking to see if anyone is still hiding inside
• 11:07
  your house. That is the perfect analogy. You
• 11:10
  have secured the perimeter, but completely ignored
• 11:13
  the interior. Right. Session revocation is literally
• 11:16
  cutting the active connection of anyone currently
• 11:19
  logged in. Credential rotation means changing
• 11:22
  the passwords for the databases that Metabase
• 11:24
  talks to, assuming the attacker scraped those
• 11:27
  credentials while they were inside. And Mathspace
• 11:29
  didn't do any of that at first. No. By skipping
• 11:32
  these checks, they operated under the incredibly
• 11:35
  dangerous assumption that patching a system retroactively
• 11:38
  evicts an attacker. It doesn't. Because they
• 11:41
  skipped those checks, they sat blind for another
• 11:43
  five days. It wasn't until September 3rd, while
• 11:46
  conducting a historical review of their access
• 11:48
  logs, that Mathspace finally realized an unauthorized
• 11:52
  actor had been in their system. Five whole days
• 11:54
  after they thought they fixed the problem. Yeah.
• 11:56
  They skipped it. Honestly. The drive to just
• 12:00
  hit the update button and close the ticketing
• 12:02
  system task is a very powerful psychological
• 12:05
  motivator for IT teams that are driven by metrics.
• 12:09
  Like just getting it off the desk. Exactly. Actually
• 12:11
  hunting through access logs to verify you haven't
• 12:14
  been breached is tedious, time -consuming work.
• 12:17
  Yeah. But Skiving, it costs them crucial response
• 12:19
  time. However, the Kinsoft source emphasizes
• 12:22
  a massive pivot here. Once Mathspace actually
• 12:25
  looked in the logs and realized they had been
• 12:27
  compromised, their response behavior completely
• 12:30
  inverted. It was a night and day difference.
• 12:32
  Yeah, they went from agonizingly slow and disconnected
• 12:35
  to incredibly aggressive and transparent. Their
• 12:38
  September 3rd response is basically textbook
• 12:41
  incident remediation. What did they do? The moment
• 12:44
  they detected the breach, they didn't just tweak
• 12:46
  settings. They amputated the compromised LIMP.
• 12:49
  They took Metabase entirely offline. They revoked
• 12:51
  all API keys. Okay, so they finally did the checks.
• 12:54
  Oh, they went further. They went into their massive
• 12:56
  cloud data warehouses, specifically their Australian
• 12:59
  and U .S. snowflake environments, and completely
• 13:02
  disabled the database access accounts that Metabase
• 13:05
  used. They rotated the passwords on their Cloud
• 13:08
  SQL databases. They systematically severed every
• 13:11
  internal connection Metabase had to the broader
• 13:14
  company infrastructure. And externally, they
• 13:16
  move just as fast. The very next day, September
• 13:19
  4th, they were already notifying government authorities.
• 13:23
  Right. The Office of the Australian Information
• 13:25
  Commissioner, the Cybersecurity Center, New Zealand's
• 13:28
  Privacy Commissioner. And then by September 5th.
• 13:31
  public disclosure was out. And by the sixth,
• 13:33
  they were directly emailing the affected individuals.
• 13:36
  Think about that timeline for a second. 24 days
• 13:39
  from the initial intrusion to detection, but
• 13:41
  only 48 hours from detection to public disclosure.
• 13:44
  Yeah. In corporate crisis management, releasing
• 13:47
  a public statement detailing a breach two days
• 13:49
  after discovery is almost unheard of. Usually
• 13:52
  companies drag their feet for months. Let's talk
• 13:54
  about the blast radius, though, because over
• 13:57
  a million people. 1 ,079 ,819 students, parents,
• 14:03
  teachers and staff across Australia and New Zealand
• 14:06
  were caught in this. What was actually taken?
• 14:08
  Well, the attackers exfiltrated basic user information,
• 14:11
  user IDs, first and last names, email addresses,
• 14:15
  account types and the timestamps of when users
• 14:17
  last logged in. But the critical part of the
• 14:19
  story is what was not taken. Right. No academic
• 14:21
  records, no grades, no learning activity. That's
• 14:24
  right. And from a technical standpoint, the most
• 14:27
  crucial saving grace here. No passwords. Not
• 14:30
  even hashed or encrypted passwords. No authentication
• 14:33
  tokens. That technical detail is what prevents
• 14:36
  this from being a total catastrophe. How so?
• 14:39
  If attackers steal password hashes, they can
• 14:41
  run offline cracking tools to decipher them.
• 14:43
  If they steal authentication tokens, they can
• 14:45
  potentially hijack active web sessions and impersonate
• 14:48
  users on the platform. I see. Because neither
• 14:50
  of those were taken, the attackers secured a
• 14:52
  massive directory of names and emails, sure.
• 14:55
  But they did not acquire the credentials necessary
• 14:57
  to move laterally into the user's broader digital
• 15:00
  lives or completely take over their Mathspace
• 15:03
  accounts. And as of the source's publication,
• 15:06
  there's no evidence this data has been monetized
• 15:08
  or misused yet. Thankfully, no. Speaking of the
• 15:11
  attackers, we should note that attribution remains
• 15:13
  pretty murky. Mass Space hasn't identified the
• 15:17
  actor and no ransom demand has been publicized.
• 15:20
  Right. The source does mention that tech outlets
• 15:22
  like Bleeping Computer linked a broader campaign
• 15:25
  targeting Metabase instances to an extortion
• 15:28
  group called Shiny Hunters. Yeah. But we need
• 15:30
  to be careful there. Exactly. Because as the
• 15:33
  Kinsoft text strictly notes, that is general
• 15:35
  industry reporting. It is not confirmed attribution
• 15:38
  for the Mathspace incident specifically. Yeah.
• 15:41
  In the immediate aftermath of a breach, separating
• 15:43
  verified forensic evidence from broader threat
• 15:46
  landscape speculation is super vital. Threat
• 15:49
  actors often use the exact same automated scripts,
• 15:51
  which makes attribution based purely on the exploited
• 15:54
  vulnerability incredibly difficult. Makes sense.
• 15:58
  What really stands out to me about the aftermath,
• 16:00
  though, is the reaction to Mathspace's public
• 16:02
  disclosure. It was overwhelmingly positive. Yeah.
• 16:05
  Melbourne privacy barrister Peter A. Clarke publicly
• 16:08
  praised them, calling their self -critical disclosure
• 16:10
  excellent. Which is rare for a lawyer to say.
• 16:13
  Right. Legal departments usually fight tooth
• 16:15
  and nail against this kind of transparency to
• 16:17
  minimize liability. Why is admitting failure
• 16:20
  like this so valuable to the industry? Because
• 16:23
  generic boilerplate statements like, we take
• 16:27
  your privacy seriously and experience this sophisticated
• 16:29
  cyber event, those teach the industry nothing.
• 16:33
  They're just PR fluff. Exactly. Mathspace explicitly
• 16:36
  admitted their internal alert routing failed.
• 16:39
  They admitted they applied a patch but failed
• 16:42
  to perform compromise checks. Wow. By trading
• 16:44
  short -term PR embarrassment for technical transparency,
• 16:48
  they provided actionable intelligence. Other
• 16:50
  engineering teams can read that disclosure and
• 16:52
  immediately go check their own database logs
• 16:54
  or audit their own vulnerability notification
• 16:56
  pipelines. Transparency basically acts as an
• 17:00
  inoculation for the rest of the ecosystem. Which
• 17:02
  perfectly sets up how you, listening to this,
• 17:05
  can apply these lessons to your own networks.
• 17:08
  The source material brings in this highly effective
• 17:10
  triage framework from Steve Hunter, a director
• 17:13
  of engineering at Arctic Wolf. How do you prevent
• 17:17
  a forgotten internal tool from leaking a million
• 17:20
  records? Hunter's framework demands that we stop
• 17:22
  prioritizing vulnerabilities based solely on
• 17:25
  a vendor's CVSS score and start analyzing the
• 17:28
  environmental context. So looking at the bigger
• 17:30
  picture. Yes. You have to ask two distinct questions.
• 17:33
  First, is the system exposed to the Internet?
• 17:36
  Second, what data can the system reach? It's
• 17:38
  the blast radius. Exactly. Metabase was just
• 17:41
  a reporting tool. If you asked an executive to
• 17:43
  list their mission -critical, highly defended
• 17:45
  applications, Metabase wouldn't even make the
• 17:47
  list. Right. But because of its function, it
• 17:49
  had high -level read access directly into their
• 17:52
  Snowflake and Cloud SQL production databases.
• 17:54
  A low -importance system with high data access
• 17:57
  is the exact asymmetric target an attacker wants.
• 18:00
  Because it's easier to hit? Yeah, they don't
• 18:02
  want to try and brute force their way through
• 18:04
  the heavily monitored front door of your core
• 18:07
  product if they can just slip through the unmonitored
• 18:09
  side window of a secondary reporting tool. So
• 18:12
  how do you defeat that shadow infrastructure?
• 18:14
  Like the tools a developer quietly spun up on
• 18:17
  an AWS instance three years ago that eventually
• 18:20
  became structurally load -bearing. You have to
• 18:23
  eliminate orphan software. And the solution isn't
• 18:27
  some fancy AI firewall. It's rigorous administrative
• 18:30
  hygiene. Just doing the boring work? Pretty much.
• 18:33
  You must maintain a dynamic inventory of every
• 18:36
  single software instance running in your environment.
• 18:38
  More importantly, every single instance must
• 18:41
  have a specific named human owner assigned to
• 18:44
  it. And that human's active email address must
• 18:47
  be subscribed to the vendor's security feed.
• 18:49
  And if they leave? If a tool doesn't have an
• 18:51
  owner, it gets taken offline. Period. And the
• 18:54
  final piece of the puzzle here is changing how
• 18:55
  we view the patching process itself. As we saw
• 18:58
  with Mathspace's five -day blind spot, patching
• 19:01
  is the middle of the incident response, not the
• 19:04
  end. It's never the end. If a system was vulnerable
• 19:06
  and exposed to the internet, you have to operate
• 19:09
  under the assumption that it was successfully
• 19:11
  breached. You have to review the API keys, audit
• 19:14
  the logs, and rotate the credentials. Because
• 19:17
  in modern cybersecurity, The gap between a public
• 19:20
  patch announcement and a weaponized exploit scanning
• 19:23
  the internet is now measured in hours, not weeks.
• 19:26
  Four days was all it took here. Four days? Yeah.
• 19:29
  If you patch late, you aren't preventing an intrusion.
• 19:32
  You're just locking the attacker inside with
• 19:34
  you. Man, that raises a vital question for you,
• 19:37
  the listener. How much shadow IT is quietly humming
• 19:40
  away at your workplace right now? We constantly
• 19:42
  worry about our highly sensitive financial data
• 19:45
  or user passwords being locked away in the main
• 19:47
  digital vault. But if a seemingly mundane, internal
• 19:51
  -only business intelligence tool can act as the
• 19:54
  skeleton key to over a million user records,
• 19:56
  well, what other harmless -looking software in
• 19:59
  our daily lives is silently connected to the
• 20:01
  most sensitive data we possess? Could the biggest
• 20:04
  threat to our privacy actually be the tools we
• 20:06
  assume are just too boring for hackers to care
• 20:08
  about? It's a sobering thought. It really is
• 20:11
  something to deeply consider the next time you
• 20:14
  assume an internal system doesn't need external
• 20:16
  defenses. Thank you for joining us on this deep
• 20:19
  dive. Stay curious, audit your digital infrastructure,
• 20:22
  and we will catch you next time.