Firstly, good stuff re earlier notification. Data such as what was exposed by the #OptusHack is most valuable when it’s freshest because impacted parties aren’t aware and haven’t taken appropriate action.
But banks are only a small part of the picture and arguably, much more damage is done when email and social accounts are compromised. But there’s not the same regulatory controls over them and it’s easier to quantify financial loss rather than privacy loss.
This also seems to be very Australia focused; what about all the breaches of personal data on foreign services (which is most breaches)? How will foreign financial services be notified? I get it, we’re talking Aussie legislation, but it leaves massive blind spots.
We also should ask why Optus needed to acquire *and* retain identity data of this nature in the first place. To get a SIM card? Sure, but then why the long term retention of that data once identity has been established? Was it worth the problem we now have?
That last point in particular is so fundamental and the article does touch on this re metadata retention laws. Here’s a really easy way to think of it: you cannot lose what you do not have. Or, in other words, what are we willing to risk losing?
Meanwhile, we’ve got Optus saying nothing about how this happened whilst data is being spread through a popular hacking forum (not on that scary “dark web” either, just a normal website), and anonymous parties passing how the whole thing went down directly to @Jeremy_Kirk
Optus will never pay a ransom (they’re no more likely to pay $10 than they are the requested $1M), so the data will be monetised then, eventually, spread publicly such that anyone with a web browser can easily grab it all
We don’t have a “fix” for this that achieves anything of significance and right now, we can’t do much more than just wait and see how messed up things get
• • •
Missing some Tweet in this thread? You can try to
force a refresh
With the preface that all this is "alleged" at this time, there's a post on a popular hacking forum from 12 hours ago making some pretty major claims:
"There's another DB in the Oracle server we're in, it's called "cabinet cloud" and it's 34GB in total. No idea why it's here and what it's for, but we're releasing it because we don't think we'll need it.
Here's the video of the tables:"
Waiting for me on arrival home was a care package from @Ubiquiti. Let’s start unboxing and full disclosure: they’ve sent me a bunch of bits (including these ones) since I spent up big, re-did my whole house and decided I loved the gear: troyhunt.com/ubiquiti-all-t…
So, what is a “G4 PTZ”? It’s the top of the tree camera that sits above the G4 Pro (4K cam used for the photo in my tweet of my back yard just now) and looks totally kick arse ui.com/camera-security
It comes in a bag. And a *very* heavy base, must be several kg right there.
Anyone seen a link to this data? Or the Telegram channel in question? DMs are open if you can help. vpnmentor.com/blog/mgm-leake…
Thanks to the folks that reached out and sent this to me, I now have it. Almost 25M addresses so substantial, but one burning question: is this part of the incident from a few years ago? Or a discrete breach? Update the old one or load a new one? haveibeenpwned.com/PwnedWebsites#…
I've concluded that this is highly likely to be the same incident from 2019. The total row count is *identical* to what was being sold years ago: zdnet.com/article/a-hack…
You know what benefits criminals most? Allowing 1.5M customer records to circulate amongst them without notifying the victims. This is just an appallingly irresponsible response that goes against every piece of good data breach response advice.
To add to this, I was sent this data by multiple people more than 2 weeks ago. So, it’s in many hands with plenty of time to be abused. Identity theft. Phishing. Spam. That’s what criminals do with this data and it’s easier when the victims don’t know they’ve been breached.
And then there’s the card data. This message is intentionally misleading as it can be interpreted in multiple ways; card data sufficient to make purchases wasn’t exposed, but credit card details *were* exposed: type, expiry plus first 6 and last 4 digits.
My single largest cloud cost for @haveibeenpwned is @AppInsights log ingestion on the @Azure API Management service used for the public API. Anyone know how to easily down-sample this? Need specific step-by-step, there's so much general / tangential information out there.
So this is just really weird: delved into my APIM config and thought I found the problem - "Always log errors" was checked. Why is that a problem? Because it includes stuff like 404 (searched address not pwned), 429 (rate limit exceeded) and 401 (invalid auth).
They're all expected error codes so I *unchecked* the box expecting log ingestion to drop dramatically. Nope. Then I turned off @AppInsights altogether - still no change! These graphs cover all those tested states and show the correct insights destination (hibpapim), what gives?!
Incidentally, I still need to implement the Password Purgatory logging, but at least this is functional enough to piss people off right now: troyhunt.com/partnerships/