BlackCat ransomware group implodes after apparent payment by Change Healthcare
krebsonsecurity.com
krebsonsecurity.com
My guess is that companies that have their shit together enough that they could get back to a "We're total compromised and vulnerable, but at least we're online for now" state fairly quickly without paying up are a lot less likely to have ransomware problems in the first place.
This is the worst case scenario and its ridiculous
I hope it prompts reforms in that industry such as using smart contracts as escrow to handle payment to affiliates
a direct payment to an EOA is just sad
affiliates, moderators, and the ransomed should demand a model smart contract behind every address presented for payment, cybersecurity industry (and even the feds) could help craft this and give more confidence to the outcome
Fortunately not being negligent when it comes to security does a lot more than just protect you from ransomware extortionists. It can make it possible to easily recover data after all kinds of incidents (human error, software bugs, hardware failures, fires/floods, etc) and also help keep you protected from other types of viruses/malware, malicious employees, corporate espionage, whistleblowers, and anyone else who would take your data and then actually use it instead of just demanding payment to make it go away. It can also prevent the reputational harm a company can suffer by having a data breach go public.
Good security is one of those things that could easily save a company way more than it costs them, but the costs are immediate and non-trivial and companies seem to love to cut corners even when they know it'll screw them down the road because they're pathologically short-sighted and it's hard to brag about doing something that didn't have an immediate and obvious impact on their next quarter's bottom line
You are correct in saying it has historically been the smart choice to pay a ransomware group, but that is only the best decision for that individual company; as a society, we are better off when we make a blanket policy to never negotiate with terrorists (or ransomware groups). The fact that what is the best policy for individual companies is the opposite of what is the best policy for society as a whole is simply because this is a prime example of a prisoners dilemma; everyone is better off if no one pays a ransom, but any individual company is best off paying the ransom.
So what we should do instead of making ransom payments reliable, is make it nearly impossible to reliably pay a ransom without the ransomware group being caught in the end.
it will help many low trust business relationships and entire industries
The data involved could severely hurt millions of people if released and not having that data was actively hurting people - potentially putting their lives and health in danger by delaying access to medical care and prescriptions.
(Full disclosure: I am an employee of a competitor to Change Healthcare)
The phrase to describe this is double extortion.
As for your question, https://www.cisa.gov/stopransomware is a decent start, but it's a complicated issue. In short, if a pentester can get inside your environment and gain privileges, so can an attacker. You want to slow down attackers enough to buy time for detection and response capabilities.
How many organizations have their "encrypted at rest" data in a cloud provider account that's set up to give all developers (or at least all production support engineers) access to decrypt the data, maybe even transparently?
How many have the "encrypted at rest" data on servers that are set up to give all administrators transparent access to the data?
How many only allow application service accounts access to decrypt the data directly, but the credentials for those service accounts are stored as Kubernetes secrets that anyone in IT can read?
Etc.
Executives at UnitedHealth Group told workers to mine old medical records for more illnesses, to identify diagnoses of serious diseases that might have never existed, inflating bills paid by the federal government's Medicare Advantage program.
If you're talking about your own personal hard drive in your home, yes.
But in this case, we're talking about a huge company conducting literally billions of database queries for tens of thousands of clients an hour.
You only have to have a listening post in one small part of the system that can see things in plaintext for a short time in order to accumulate 4TB in a matter of days.
"We estimate more than 90% of the nation’s 70,000+ pharmacies have modified electronic claim processing to mitigate impacts from the Change Healthcare cyber security issue; the remainder have offline processing workarounds," Mason said.
https://www.bleepingcomputer.com/news/security/unitedhealth-...
The pharmacy network, which connects pharmacies and PBMs, is in final end-to-end testing with our partners. We anticipate that our Change Healthcare Pharmacy network will be back online for the vast majority of submitters as soon as Thursday.
It's a problem of 'data leakage' where the bad guys have a copy of corporate data - supposedly 4TB of personal medical information - and threaten to release it to the public which can cause all sorts of reputational or other damage.
Backups don't help much in this situation, you need to convince the attackers to delete the data they copied from your network, usually via lots of money but even then there's no guarantee they'll actually delete it and may extort you for more money in the future with the same data.
Should one trust a criminal to keep their word?
Because it gets decrypted at some point.
Security is not anywhere close to "good" in most corporate environments however, and many things are still stored in plaintext that should not (e.g. passwords), let alone data that is merely "private".
You don't need to decrypt the entire payload at any time.
You decrypt parts of the data.
Put on a hat and pretend you’re a bad actor. Give yourself access to the server where your most important data is stored.
Now look around. Is there anything you can do to extort money?
You could encrypt/destroy the data. (A backup solution saves you here).
You could exfiltrate the data (download or upload to a remote server). What can you do with this data if it was encrypted at rest? Not much.
What else could you do on thisnserver while you have access? This is where things get interesting. Can you force the application to decrypt the data or dump the data somehow? Unlikely, if the cert management is done properly.
The thing is, majority of organisations do not encrypt data at rest. Databases are not encrypted, hard data is not encrypted. If this was not the case, we wouldn’t be hearing about these data leaks.
How do I encrypt a database at rest? How does it work?
Say, I run a hospital and I want to write patient data to a database. Do I have to decrypt the whole database before I add new data? Each time? Do I also have to decrypt the database each time I query data? How does that work when two doctors want to access the database at the same time?
I assume that constant decryption and encryption of large amount of data adds a significant overhead. So in practice, while data is encrypted at rest, most of the time the data isn't resting, but actively loaded and used and unencrypted.
And now, when a bad actor gets access to that live running database, they can exfiltrate the data.
Additionally, proper protection of medical records will require globally unique identifiers (aka PID, MRN).
As you know, today, medical record PII must be stored as plaintext to allow record linking across heterogenous orgs. This is bad.
Yes and:
> Encrypting data while at rest (in storage) as well as in-transit is the way to go.
All PII must be encrypted at rest at the field level.
Just like how passwords are properly stored. This is not rocket science.
The book Translucent Databases demonstrates this technique for common use cases. Highest recommendation.
https://www.amazon.com/Translucent-Databases-Peter-Wayner/dp...
The practical downside is that if the user forgets their password, they lose access to their account. So for medical records, the original key (password) requires offline paper (or equiv) backup.
Have you seen patient portals like (Epic's?) MyChart?
Aside: During the mid-aughts, I created a patient portal POC, to compliment our physician portal product. Customers were very interested. Ditto the clinical (vs diagnostic) quality web-based DICOM viewer I made. (Sadly, the 2008 meltdown /dev/null'd all of our work.)
Patient portals tied to a single vendor like Epic MyChart aren't great, but they work well enough for patients who receive all of their care through a single integrated health system. Attempts to create universal patient portals not tied to a particular payer or provider organization have generally failed because no one wants to pay for them. Apple is trying this again but they only have interfaces with a limited set of data sources.
Almost all of my PII and medical information is in the hands of bad actors because of this needless retention
Like a shaman. Or a doctor whose license has been revoked.
Good luck!
A password wouldn't be appropriate for direct use as an encryption key. So I guess you could hash the password and use that for the key for data encryption and then hash it again and store the second hash for authentication. Salting appropriately of course.
That feels weird to me, I wouldn't trust I saw every angle on that. Regardless, it would drastically lower the entropy of the key space that way unless you have downright draconian password requirements.
How did you implement this in the POC you spoke of?
Very briefly, a proper password store must not use plaintext. Rather it must use ( password + salt ) * hash.
Similarly, PII (name, MRN, etc) must also be salted and hashed.
What Translucent Databases adds is showing how to cleverly use those hashed values for common use cases. Like how to use hashed MRNs as indexes (keys) to other data such as lab results.
It takes some getting acquainted, but designing schemas will start being intuitive after a bit.
Edit: I see you aren't actually encrypting it. So you are as the post said, just throwing away the keys (in a sense). You are talking about storing and indexing metadata.
Sensitive data (passwords, PII) is absolutely encrypted. I apologize for assuming everyone here knows how passwords should be stored. My reference to "hash" is shorthand for "secure one-way hash".
Please refer to the Translucent Databases book for any further questions you may have.
You can read here https://www.google.com/search?q=hashing+vs+encrypting to further understand.
These groups work on reputation. If prior ransoms do not result in seemingly perfect dealing from their end, new orgs won’t consider it.
The significance of the rug pull on affiliates confirms this. It shows fair dealing even with conspirators is the norm, and this example as a major diversion.
The other component is that these situations are usually negotiated by lawyers that are hired by insurance companies that offer cybersecurity policies. They tend have working relationships. It's crazy, but these are actual businesses that do, in fact, have rules of engagement and often abide by their guarantees. That is part of the problem, I suppose...
Do we know that they had good backups in this particular case? The fact that their systems are not yet back online makes me wonder if maybe they didn't.
Sure, so I've seen this. There's a Veeam server with a backup repo in the main datacenter. And it takes backups to a server "offsite". Let's forget for a moment I've got an environment that take six days to do a full backup.
Then one day the attacker gains a vendor's Teamviewer account and finds themselves on a server console that's been left logged on as a Domain Admin. And they open windows file explorer, and browse to \\offsiteserver\backups, and then press "delete". Noone cares if it's offsite, it's gone.
OK, so when you said "offsite backups" I'm sure you meant something not contactable from an average network machine right? Maybe ACLs only allow access from the backup server itself. Well fear not, the attacker can still just RDP to that Veeam server and repeat.
OK OK so what you really wanted was a properly isolated network for all the backup content and they can't make a connection from the general network to it right? Once again fear not, there's a Group Policy deploying this ransomware, which means it's going on every domain joined machine including the backup server.
Look, now we're getting somewhere, there should be an entirely separate administration domain for backups and infrastructure. Well firstly someone from Microsoft will yell at you because "ESAE" is deprecated, and some overpriced consultant is about to explain to management that you're incompetent because you separated the networks (from personal experience). Fortunately that doesn't matter to the one guy with a popped Domain Admin account on the general domain used the same password on the administrative domain against policy, and the attacker spreads anyway.
Yes you've got options here. For example someone might mention "Veeam Immutable Storage", which is pretty effective. But now you'll find the iLO for that server still presents a forgotten entrypoint to wiping it.
There's absolutely ways to do this properly but it's never simple, and the further you go down the hole the more likely you are to hit pricing or political stumbling blocks.
Security is not a technical problem, it's a sociopolitical problem. That's my main gripe with the business of computer security (even the name cybersecurity rubs me the wrong way... cybernetics is about robotics control systems). All these hard selling seemingly highly advanced stuff, all these script kiddies showing companies how much vulnerability is peppered all over their systems. And in the end you can call up people and they will cheerily give away credentials against vague verbal assurances.
One way of addressing that is by using a secure vault for sensitive data storage. This is beyond the skillset of most backend engineers, but new products such as Piiano may bridge the gap (proper disclosure: I'm a friend of one of the people behind Piiano)
Simple? Nah, doing this properly is an entire department/role (CISO) plus other groups.
Some quick practical basics.
- The fewer things, the smaller the potential attack surface.
- NIST publishes some good starting points https://www.nist.gov/cyberframework
- Shared credentials are evil. All admins should be operating off their own accounts
- MFA and SSO
- A backup isn't a backup if you haven't validated you can restore it
- Replication isn't backup. You need something that is immutable and has history. To start I would suggest a nightly backup, with each backup retained for 45 days at minimum. GDPR complicates this with right to be forgotten but this is a starting point.For the data exfiltration issue, there's not much you can do other than paying and hoping for the best, and it depends on their reputation of keeping their word.
You won't get paid much and last long in the ransomware world if you have a reputation of leaking the data when paid.
it is very easy to do this with crypto and much cheaper than payment processor or attorney solutions
and you can do it with any money source lol
These kinds of organizations sit always somewhere on a blurry line between "state-tolerated" and "state-affiliated" in the first place. Given current geopolitical circumstances it wouldn't surprise me if they've been given a green light to hit more significant targets.
>Beware the change from an ITERATED prisoner's dilemma game to a SINGLE game.
Or perhaps alternatively to remember the difference between a "salary" and an "exit". Particularly when there is a long history of iteration people have gotten used to. The interesting HN discussion that comes most immediately to mind was last year's implosion of Silicon Valley Bank and the Stratechery article [0] about it. Classic game theory points to major differences in any ecosystem where the players are playing iterated vs single games. Iterated games encourage thinking about the longer term health of the overall ecosystem, not burning bridges, etc. The optimal strategy isn't pure defection but more cooperate+punishment.
However, the ransomware ecosystem, like the startup ecosystem, seems to have followed an arc from small to large where the amounts of money start to pass an inflection point where they hit "set for life with a single payday" amounts. Ie, groups can chase "unicorns", hit one, and then at least from a pure economic standpoint potentially burn all bridges and reputation and be done forever. That in turn pushes towards short term thinking and extracting maximum value as fast as possible even at the cost of future returns.
It being a black market certainly accelerates this further, because a lot of traditional controls to help push more towards iteration (from information symmetry to flat out physically coercive criminal punishment). But at least in terms of idle hot take contemplation, it seems to me there are parallels in a lot of different industries through history.
So yeah don't pay ransomware anyway due to it funding a host of evils, encouraging more, governments should punish companies that do etc. But from a pure cold realpolitik standpoint it's perhaps also worth thinking about what the person on the other side can do afterwards. If a company is effectively paying them a "salary" class money, as if it was a $1000/hour pen tester, so a 100 hours of work attack is $100k, they may be more likely to be treating it as a "job" where they'll be doing it again and again. Which is bad here, but also perhaps more reliable, they have reputational skin in the game and an interest in the "health of the ransom ecosystem". But if the company is paying them "founder exit" class money, tens of millions of dollars, the odds of someone being ready to take the money and run, and having the amounts needed to make that possibly work, are probably going to be higher?
Anyway just interesting to think about a bit.
----
0: https://stratechery.com/2023/the-death-of-silicon-valley-ban...
It is wrong to put temptation in the path of any nation,
For fear they should succumb and go astray;
So when you are requested to pay up or be molested,
You will find it better policy to say:—
"We never pay any-one Dane-geld,
No matter how trifling the cost;
For the end of that game is oppression and shame,
And the nation that plays it is lost!"
… now imagine if they'd put that $22M — an amount that would fund my entire team for the remainder of our lives — into engineers.
(head of infosec, holds tabletop exercises with legal counsel on a cadence as part of ransomware insurance requirements)
[1] https://www.cybersecuritydive.com/news/epa-rescinds-cybersec...
[2] https://www.epa.gov/system/files/documents/2023-10/action-me...
[3] https://www.epa.gov/system/files/documents/2023-08/2023.08.0...
[4] https://arstechnica.com/security/2023/09/hack-of-a-microsoft...
Does it work? Depends on who you ask. https://www.chathamhouse.org/2022/01/we-do-not-negotiate-ter... says that individuals (in the case of corporate ransomware - corporate entities) end up paying and not reporting the kidnapping:
“Historical evidence from Colombia and Italy shows that outlawing ransom payment has various adverse consequences.
Where ransom payments are illegal, victims’ families have no state support, while reporting of the kidnapping goes down and understanding of its prevalence is diminished.”
You can mitigate adverse consequences. Punishments for child kidnapping used to be severe, but then abductors would just kill the hostage since they had little more to lose. Today's sentences are next to nothing to encourage surrender.
If ransom was off the table, maybe they’d be motivated to actually secure their data? I don’t know—I’m not in infosec. It’s probably not that simple.
I think on HN, there is this belief that you can use incentives to force organizations to have perfect security, which does not exist. Employees are human, people make mistakes, budgets constrain staffing as well as control implementations and operations; there are simply limits to what you can do. You can use policy and incentives to encourage good/best behavior, but failures will still occur. The goal is attempts at desired outcomes, measuring those outcomes, and iterating; not 100% success (as that is impossible).
Because it's not a one-time cost. If attackers know you have weak security and deep pockets they will persist.
I was in Italy recently, and saw articles about the epidemic of kidnappings there in the 70s. It won't be long before organised crime figures out how to use crypto to bring back the glory days.
Killing bitcoin would shut down an enormous illegal economy overnight. And stop the crazy electricity consumption at the same time. Maybe you can help me here, but I'm having difficulty thinking of a single real downside.
Despite not owning any Bitcoin, I find it quite comforting to know that there is a currency that exists outside of the purview of a central bank or a government that can devalue or outright take the accruement of my labor on a whim.
PS. All of the smart ransomware groups are not demanding payments with Bitcoin anymore, they are using another cryptocurrency called Monero. It turns out that Bitcoin is actually traceable by governments via its public ledger, but Monero is a private currency that can't be traced, hence why the IRS posted bounties some time back to encourage people to break Monero's obfuscation.
The only gangs that are still demanding Bitcoin are the less-educated and savvy ones.
This tit for tat type response would seem to be more consistent with how governments respond to terrorism, so I'm assuming it would be better to deter future hacks.
> This tit for tat type response would seem to be more consistent with how governments respond to terrorism
Lol. Not a selling point these days.
The US has always had a very strange policy of criminalizing hacking, regardless of intent.
Places like Russia and Israel look the other way as long as the target is foreign, and we outsource our own phone forensics to the latter (Cellebrite). Thus, Israel has a better understanding of our own vulnerabilities than we do.
So you never know who you're up against given some ambiguous heuristics. As retribution, you might end up inadvertently attacking an "ally." It's safest to keep us disadvantaged.
At the very least it is participation in tax fraud to buy protection from a criminal IT-gang. I guess they don't pay VAT?