[HN Gopher] Data breach exposes 184M passwords, likely captured ...
___________________________________________________________________
Data breach exposes 184M passwords, likely captured by malware
Author : taubek
Score : 115 points
Date : 2025-05-26 16:37 UTC (6 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| FridayoLeary wrote:
| Link to the orginal report:
| https://www.websiteplanet.com/news/infostealer-breach-report...
|
| It's frustrating that he offers no information about where the
| data was taken from, or any way of checking if my passwords are
| compromised.
| janderson215 wrote:
| IIRC, it's common to not throw a vendor under the bus if they
| properly disclose the breach so as to not discourage reporting
| of breaches. Healthier for the unfortunate ecosystem.
| gabeio wrote:
| This is not a "breach" the article hints at a trojan which
| scrapes or exfiltrates credentials off of user computers not
| a singular provider's database.
| indigodaddy wrote:
| Would haveibeenpwned be privy to this breach?
| HelloUsername wrote:
| Your link is a bit weird (you can delete everything after
| '-report')
|
| Also, strangely no discussion at the time:
| https://news.ycombinator.com/item?id=44062726
| FridayoLeary wrote:
| It's copied straight from zdnet. Too late for me to change it
| now. Maybe it wasn't discussed becuase it's so vague.
| jmclnx wrote:
| The only one I kind of care about is Google, I guess I will need
| to change that PW. And the google email is pretty much ignored by
| me.
|
| Of the list, I only have a Facebook PW, but I tried to delete
| that ID years ago without luck. I have not be in it in ages.
|
| If some here gets that PW, please delete my Facebook Account :)
| entropie wrote:
| If I understand correctly (correct me if iam wrong) there were
| no data breachs on any servers. Its accumulated data from
| 3rdparty "infostealer malware".
| SoftTalker wrote:
| Very vague report.
| hattar wrote:
| > Google, Microsoft, Apple, Facebook, Instagram, and Snapchat,
| among others, were stored in a file. The database also contained
| credentials for bank and financial accounts, health platforms,
| and government portals.
|
| I'd love a source that at least gave the full list of compromised
| services.
| Stagnant wrote:
| The data appears to be from malware victims, not from
| compromised services.
| tedunangst wrote:
| Here: ""
| explain wrote:
| > The problem? The file was unencrypted. No password protection.
| No security. Just a plain text file with millions of sensitive
| pieces of data.
|
| > Based on his analysis, Fowler determined the data was captured
| by some kind of infostealer malware.
|
| Then the mere exposure of the file and whether it was encrypted
| is irrelevant. The data was already stolen, the damage was
| already done.
| ken47 wrote:
| That's weird. Why is the data from the unconnected databases of
| test companies in a single place?
| entropie wrote:
| Its in the article
|
| > Based on his analysis, Fowler determined the data was
| captured by some kind of infostealer malware. A popular tool
| used by cybercriminals, an infostealer is designed to grab
| usernames, passwords, and other sensitive data from breached
| sites and servers.
| Stagnant wrote:
| >from breached sites and servers.
|
| That part is just incorrect and doesn't make any sense.
| Infostealers typically grab the credentials that a victim of
| a malware has saved in browser password managers.
| darth_avocado wrote:
| If unconnected services are being breached, the likelihood of
| this breach coming from some sort of a password manager is high.
| If that's true, the recklessness would be beyond comprehension.
| forgotTheLast wrote:
| >Based on his analysis, Fowler determined the data was captured
| by some kind of infostealer malware. A popular tool used by
| cybercriminals, an infostealer is designed to grab usernames,
| passwords, and other sensitive data from breached sites and
| servers.
| kevin_thibedeau wrote:
| The sites aren't being breached. They're intercepting
| passwords and PII on the user's side.
| OutOfHere wrote:
| The most likely source is a web browser's password manager.
| YetAnotherNick wrote:
| This is a breach of some illegal infostealer data. I don't know
| why this information wasn't the first line.
|
| The data was already breached. The irony is that this would
| likely "unbreach" the data breach as the companies would likely
| lock the account.
| downrightmike wrote:
| Probably legal info dealer similar to https://npdbreach.com/
| tedunangst wrote:
| You get more clicks for every tech company you name in the
| headline. Something like clicks = log(sum(market
| cap(companies))).
| jxjnskkzxxhx wrote:
| Uh oh need to change my Facebook password.
|
| Joking, I don't use that garbage.
| kevin_thibedeau wrote:
| Don't worry. The criminals will freely use your account as a
| CSAM relay.
| jxjnskkzxxhx wrote:
| What account? I just said I don't use that garbage.
| codedokode wrote:
| Given that Facebook requires now a face 3D scan to sign up, it
| is the correct choice.
| frizlab wrote:
| Dupe of https://news.ycombinator.com/item?id=44062726
| metadat wrote:
| Note: Submissions without discussion aren't considered dupes on
| HN. If another article is more interesting or higher quality
| than the submission receiving comments, it is helpful and
| appreciated to provide the link in a comment and/or email the
| mods a link change proposal.
|
| In this case, the alternate link is informative and worth a
| look:
|
| https://www.websiteplanet.com/news/infostealer-breach-report...
|
| Cheers.
| max_ wrote:
| Would passwords ever be leaked?
|
| I thought standard practice was now to never store passwords,
| then use hashes & salts instead?
| forinti wrote:
| You can brute force a hashed password if it's short or you want
| it badly enough.
| tsimionescu wrote:
| It depends what you mean by "leak". If someone was running
| keyloggers and collecting passwords and they published them,
| that can also be a leak, and it doesn't matter how the
| passwords were stored. And not just keykoggers, but this also
| applies to phsihing, man-in-the-middle attacks, or other
| similar ways of getting passwords from end-users.
| to11mtm wrote:
| 'Standard practice'.
|
| And yet there are plenty of shops that will either
| symmetrically encrypt passwords (at best, the email address or
| username is used as an IV), Log passwords stupidly [0], have a
| piss-poor integration where "Oh we have base64 encode the
| actual XML payload in the soap service and tag it
| '<Encrypted>`, ship it!" [1], or are just plain too budget
| strapped to replace the 'forgot password' functionality that
| told a user their password vs forcing a reset.
|
| And I think that last point hits it well. i.e. at least a
| plurality of those horrors were done before standard practices
| evolved to the current state, but nobody can get the
| budget/time to fix it. (And, I will say, having 'fixed' more
| than one of the above cases, it definitely has a user impact
| which can lead to the folks approving the work having an
| uncomfortable conversation with customers. B: "We forced a
| password reset to update security standards" C: "Wait so your
| security standards were subpar!!!" [2]
|
| [0] - Example; logging invalid attempts, but wait a user only
| failed because they did TypoEmailAddress@gmailcom instead of
| TypoEmailAddress@gmail.com.
|
| [1] - Yes. This was a thing I got to deal with once. What's
| even more annoying is that it was a SOAP service so of course
| the pattern eliminated most of the potential usefulness of a
| SOAP service.
|
| [2] - That said, usually the person making this complaint, is
| the person who historically was e-mailing their account rep to
| give them their password, vs using the 'correct flow but bad
| implementation' password reset we had in place as a stopgap.
| cwoolfe wrote:
| That explains the random 2FA request I got the other day.
| galaxytachyon wrote:
| You too? I got the same. But then again, my account is
| constantly under attack anyway. At least previously they were
| smart enough to not trigger 2FA. Now even the incompetents are
| trying.
| jjbinx007 wrote:
| Article mentions infostealers. My guess would be a rogue
| browser extension but it could have just as easily been
| malware.
| logic_node wrote:
| These big breaches are alarming, reminds me of the recent AMOS
| malware incident that hijacked thousands of legit sites to target
| Mac users: https://www.squaredtech.co/2800-websites-hijacked-
| amos-malwa...
| Nerd_Nest wrote:
| Totally agree, it's getting scary out there. The AMOS attack
| really shows how attackers are stepping up their game. If even
| legit websites can be weaponized like that, what's actually
| safe anymore?
| kevin_thibedeau wrote:
| Stop using federated login services and maintain unique
| accounts per service. Blacklist any service that doesn't
| provide their own account management.
| geoffpado wrote:
| What? You'd rather have more, smaller rando services
| handling your passwords than a few big names that have the
| resources to put into at least paying lip service to
| security?
| 6510 wrote:
| Would you also need a separate email address for each
| account? I think most mailboxes support a recovery email
| address and some require one for billing.
|
| Is truly separate accounts for everything really doable?
| jay_kyburz wrote:
| I don't know why you would need a separate email address.
| I would think the password is the important part.
| jajko wrote:
| I only did it once (fb login for airbnb) and I deeply
| regret to this day. Airbnb cant even migrate my account to
| another type (plain old username & password is best for
| me).
|
| The reason - over time I started renting an apartment
| there, the reputation and stream of guests is simply too
| big wall to climb over (I mean it can be done easily but it
| would hurt financially pretty bad).
|
| Now I cant get rid of that cancer that facebook is. 10
| years ago it didnt seems so, my mistake, should have seen
| it coming.
| lisper wrote:
| > Fowler said he didn't know if the database was created
| legitimately and then accidentally exposed or intentionally used
| for malicious reasons.
|
| Seriously? In what possible world can a collection of plain-text
| login credentials exist for any legitimate purpose?
| arccy wrote:
| your password manager needs them in decryptable form...
| flipbrad wrote:
| Law enforcement / national security. E.g.
| https://www.gov.uk/government/publications/intelligence-serv...
|
| Although I can anticipate what you'll say...
| galaxytachyon wrote:
| Those on HN are considered extremely tech-savvy and security
| aware and yet we are still concerned about our accounts getting
| compromised like this. What can a random user like our moms or
| siblings do? They won't even notice these kind of attack.
|
| It is such a pathetic state of affair where massive leaks like
| these are expected. I contend this is a result of lax regulation
| and lack of consequences. In healthcare, patient data are locked
| down so hard even people who need to work with them have problems
| getting to them. It is because of regulations. Everything is
| traceable, recorded, and maintained to the strictest standards
| possible. It costs a huge amount of money but as a result, we
| don't see many serious breaches.
|
| Compared it to fintech and regular tech services, these guys make
| fuckton of profits and yet suffer almost no regulations. What a
| joke.
| exiguus wrote:
| Maybe they can't. But actually, you can install them a password
| manager and let them generate random password. Setup with them
| 2fa (FreeOTP or something). And change with them every password
| when you are at home for chrismas.
|
| Also, when they now found themself on have i been powned, they
| have a bigger problem, because they have likely malware on the
| phone or computer.
| jsnell wrote:
| What regulation are you proposing? Forcing all computers to be
| locked down so hard that users can't install malware?
| 6510 wrote:
| We would have to go outside to find dopamine. It wouldn't be
| safe. People would die.
|
| edit:
|
| I remember thinking in the 90's that it was weird as hell
| that the operating system sits in the same folder tree as the
| users documents, applications live there too! What a concept?
| Like keeping your socks in the same drawer as your bills and
| plumbing tools. Spare tire in the kitchen. Lawn mower under
| the bed.
| galaxytachyon wrote:
| Maybe we can start with heavy penalties for whoever
| responsible for these breaches? The users are irresponsible,
| but at the higher levels, the company can afford to tighten
| access and guard their data better.
|
| Would these companies leak their own business critical
| documents? No. So why can't they be forced to treat sensitive
| customer's data the same way?
| throw10920 wrote:
| > In healthcare, patient data are locked down so hard even
| people who need to work with them have problems getting to
| them. It is because of regulations. Everything is traceable,
| recorded, and maintained to the strictest standards possible.
| It costs a huge amount of money but as a result, we don't see
| many serious breaches.
|
| ...and one of the side-effects is that it contributes to the
| insane price of healthcare.
|
| Effective regulation, like security, is about finding the sweet
| spot between security and efficiency. It's extremely easy to
| turn off your brain and say that nobody has access to the data
| (which makes it perfectly secure/private) - but obviously
| that's an insane approach. It's hard, but extremely important,
| to actually _maximize the security-efficiency product_.
|
| PII should _not_ have the regulations that are currently
| applied to healthcare /PHI - it'd massively increase the costs
| (both financial, and worker/individual productivity) of doing
| everything. It needs a better regulation model that is designed
| to maximize the security-efficiency product.
|
| Most likely, the best model is one that focuses more on
| outcomes (huge penalties for leaking PII, along with a few
| things like chain of custody for user data (which I don't think
| that even HIPAA does) - not to exclude regulation of process of
| course) than processes (HIPAA describing in excruciating and
| unnecessary detail all of the ways that you have to process PHI
| - which include RESTRICTING THE WAYS THAT I CAN MANAGE MY OWN
| HEALTH DATA).
| galaxytachyon wrote:
| The cost of healthcare is unlikely due to data management
| cost. That is almost an absurd comment.
|
| The cost to develop a drug is in the billions. Manufacturing
| costs are in the tens to hundreds of millions. Locking down
| some server and implement better security would be a drop in
| a bucket.
|
| And even if it was more expensive, the biggest pharma
| megacorps are a fraction of the size of the like of tech
| megacorps. If the chumps down the street can do it as a side
| job, why can't the big boys whose entire business is
| supposedly about data and software can't do better?
| throw10920 wrote:
| > The cost of healthcare is unlikely due to data management
| cost. That is almost an absurd comment.
|
| I did not state that it was solely due to that. Please read
| my comment carefully:
|
| > ...and one of the side-effects is that it _contributes_
| to the insane price of healthcare.
|
| Meanwhile, this is a crazy red herring:
|
| > The cost to develop a drug is in the billions.
| Manufacturing costs are in the tens to hundreds of
| millions.
|
| The cost for smaller practices and procedures that have
| _nothing to do with drugs or manufacturing_ has
| skyrocketed.
|
| It's not very hard to understand that the primary cost of
| regulation is on smaller businesses and practices.
| Regulation imposes a disproportionate cost on smaller
| organizations, leading to consolidation. This is a bad
| thing. The results of regulation can be a net benefit if
| you reduce those costs while maximizing the positive
| effects. This should be incredibly obvious.
|
| Moreover, this is a rather uninformed claim:
|
| > Locking down some server and implement better security
| would be a drop in a bucket.
|
| That's not how HIPPA works. HIPPA prescribes that you have
| to use certain HIPPA-compliant services and technologies.
| That's not a cost burden - that's a _compliance_ burden. It
| 's not enough for your systems to be secure - they have to
| be _HIPPA-compliant_ , which is so insanely difficult for
| small practices to do in-house that it forces all of them
| to use large, expensive, complex medical platforms, and
| pushes many others to consolidate with larger hospitals in
| order to amortize the overhead of managing these systems.
| And guess what? Consolidation in markets without extremely
| strict anti-monopoly enforcement leads to higher prices and
| worse products and services.
|
| Yes, the cost of _actually running the servers_ is very
| low. But that 's almost _never_ the primary cost of
| regulation - that 's straight-up factually false. The
| primary cost of regulation is the overhead of compliance.
|
| That's why any _sane_ person strives to maximize the
| security-efficiency product, or the analog in whatever area
| you 're trying to regulate.
|
| There's literally no excuse for not trying to do this, or
| for defending the idea that we shouldn't take efficiency
| into account when designing regulation, except malice.
|
| > If the chumps down the street can do it as a side job
|
| Yes, and as is incredibly obvious to everyone, healthcare
| is orders of magnitude more expensive than services
| provided by those tech megacorps. This is evidence (even if
| weak), that bad regulation makes things _more_ expensive,
| not less.
|
| > why can't the big boys whose entire business is
| supposedly about data and software can't do better?
|
| You clearly did not read my whole comment. I'm not arguing
| that regulation isn't necessary. I'm pointing out the fact
| that you have to optimize the security-efficiency product,
| and NOT do what HIPPA does, which is maximize security at
| the cost of a very high amount of efficiency to the point
| where it infringes on patient rights.
|
| The only absurd comment here is the one that did not
| actually read what it was responding to, and is mostly
| composed of red herrings, claims that don't line up with
| reality, and logical fallacies.
| tialaramex wrote:
| > What can a random user like our moms or siblings do?
|
| Security Keys. Your mother and siblings have seen keys before
| right? They can understand the metaphor and use it. Several of
| the accounts listed, such as Google and Facebook allow Security
| Keys.
|
| Bad guys can't steal the credentials out of Security Keys the
| way they'd steal say passwords or a TOTP code, they would need
| to physically obtain access to the keys, your mother and
| siblings almost certainly don't face adversaries who'll break
| into their homes or hold them at gunpoint, just ordinary online
| automated attacks.
| ghusto wrote:
| Legit question from someone who both wants their mum to stop
| getting hacked, and is not sure Security Keys are a good
| idea: What happens when they lose their phone?
|
| My limited understanding is that the key is on their phone
| (let's say it's a Google key, on an Android phone). When
| their phone gets lost, stolen, or breaks, are they screwed?
| This worries me because the chances of the phone being lost
| is high.
| jgerrish wrote:
| Safety deposit box with backup recovery codes.
|
| That puts a lot of burden on users though.
|
| Maybe start a pilot automated service run by Google or
| Microsoft or whoever where backup codes are securely sent
| to local credit unions and it's all almost transparent to
| the user. They just need to either pick up the code at the
| credit union and put it in their safety deposit box or
| approve that last step.
|
| I'm not upset at all about banking working with private
| entities or any of the past with banks. I'm mostly upset
| because some of these ideas are good, you know? Maybe not
| this, but some. For a short while longer.
| gabeio wrote:
| Security Keys are an independent device. I believe you are
| thinking of Passkeys which can live on the phone or in a
| password manager like 1Password.
|
| If you do go with a security key it's typically recommended
| to have at least 2 so that if one dies or is lost both have
| the same level of access. So long as you add them both/all
| to every account you need to access.
| AStonesThrow wrote:
| A security key is a hardware token that uses USB,
| Bluetooth, NFC. A security key may not have TOTP capability
| like a Yubikey. Security keys are not marketed or suitable
| for consumers, and sysadmins don't like them either:
|
| https://utcc.utoronto.ca/~cks/space/blog/sysadmin/YubikeyMo
| s...
|
| You may be thinking of "passkeys" and while a security key
| can be a form of passkeys, the ones generated for your mum
| will be on her device, yes.
|
| A passkey is a shortcut, for now. Relying on a passkey
| being in place is another good way to forget your password.
| ;-)
| galaxytachyon wrote:
| You seriously overestimate the average user. There is a
| reason why 123456 is still a common password. I would not
| expect a grandma to know how to put a key on her phone and
| use it reliably.
|
| And my main argument is that corporations can do better. We
| should not put the burden on the common folks when the ones
| who are in the positions to do something are not pulling
| their weight. Sure, this will reduce their profit, and
| probably their share prices, and as a result, dev's
| compensation. Maybe that is the hardest part to argue
| through.
| codedokode wrote:
| > I would not expect a grandma to know how to put a key on
| her phone and use it reliably.
|
| If your grandma knows how to insert a key into a lock then
| she will be able to insert a key into a phone.
| marcosdumay wrote:
| The more relevant problem here is what she does once she
| loses the key, or it breaks.
| mschuster91 wrote:
| > Security Keys. Your mother and siblings have seen keys
| before right? They can understand the metaphor and use it.
| Several of the accounts listed, such as Google and Facebook
| allow Security Keys.
|
| The problem with these is, they can get lost, stolen, damaged
| or misplaced. With a physical key to the home, no problem -
| call up a locksmith and if you don't have an ID card also the
| police, he'll drill out the lock and you can enter your home
| back.
|
| Google, Facebook, whatever - good luck trying to get into
| touch with a human to reset your "security key".
| charcircuit wrote:
| Biometric authentication / passkeys / other forms of
| authentication which are not phishable and are backed by a
| random key.
|
| Then proper OS security is needed to protect authentication
| tokens from being stolen by malware.
| dogmatism wrote:
| wait what?
|
| CHS lost millions of records, was fined a few million (out of
| profit of 1.2 _billion_ ) UCLA similar. Bunch of others I don't
| think even got fined like Ascension recently lost all data in a
| ransomware attack
|
| It's useful going after a rogue employee, but on an org level
| it's security theater
| ycombinatrix wrote:
| Where can I download the dump?
| xyst wrote:
| > I highly recommend knowing what sensitive information is stored
| in your email account and regularly deleting old, sensitive
| emails that contain PII, financial documents or any other
| important files.
|
| or begin to encrypt e-mails with S/MIME or GPG. Keep private keys
| on lockdown and never distribute to web mail clients.
|
| Password breached or brute forced somehow? Great, good luck
| getting through 2FA that uses OTP. Oh the 2FA used for e-mail
| account was broken? Now you are in.
|
| Great, now that you are in. All my e-mails are encrypted on
| server's disk with a mix of S/MIME and GPG. Good luck getting my
| private keys that I only keep on my local machine and secured
| behind additional methods of authentication (ie, fingerprint and
| password authN).
|
| Defense in depth, folks.
| XorNot wrote:
| Emails sent _to_ you aren 't going to be encrypted.
| anonymousDan wrote:
| Is there any well known tool that can be used to scan an email
| account for PII (like the tools we have for scanning for
| confidential info in GitHub repos)?
| tredre3 wrote:
| > Great, now that you are in. All my e-mails are encrypted on
| server's disk with a mix of S/MIME and GPG.
|
| So what? Hiding your old email content might be valuable from a
| privacy point of view but if you cared about that you'd just
| delete them from the server to begin with.
|
| What a hacker cares about is the ability to receive new emails
| (password recovery). Those emails are still sent to you in
| clear text.
|
| He might also care about getting a list of past senders (to
| know what accounts you might have) and that info isn't
| encrypted by GPG, only the content.
| KennyBlanken wrote:
| I don't know which is worse - that this "researcher" didn't turn
| over the dump to an org like haveibeenpwned so that _any good
| whatsoever_ would come of this, or that he thinks he can
| "disclaim liability."
|
| > I disclaim any and all liability for any and all actions that
| may be taken as a result of this disclosure.
| fuddy wrote:
| I'm a but puzzled by their advice.. Given the variety, how do we
| know this data isn't from a password manager compromise?
| throw10920 wrote:
| You're right - thee fact that Google and Apple passwords were
| both compromised (given how insanely good their internal
| security is) strongly suggests either malware or password
| manager compromise.
| XorNot wrote:
| So...where's the responsible disclosure here? A file of
| apparently breached account credentials was found, has been taken
| out of public access but was likely from malware in the first
| place _and_ spent some time being publicly exposed....so, is who
| was in it going to be communicated to someone?
| tredre3 wrote:
| > To check on the validity of the information, Fowler emailed
| many of the people listed in the file and told them that he was
| researching a data breach. Several of the individuals confirmed
| that the records contained valid account passwords and other
| data.
|
| Do security researchers really contact people willy-nilly and ask
| them to confirm their passwords? Then they lecture us about the
| dangers of social engineering?
___________________________________________________________________
(page generated 2025-05-26 23:01 UTC)