I worked for a food retail store once. I remember going in the first day wondering, how hard can it really be... From the outside, it looks like they have a simple website. The website to order things on was an amalgamation of 300+ repo's. GitHub lost less in this breach. It takes a lot of effort to keep things simple as you grow.
As others have said it's just a fraction. I'm in a medium size tech-related company and we have 7500+ in one Github org. We have two orgs, so altogether easily 10K+. Of course most of it is stale, obsolete, sandbox, personal tools, etc. I wouldn't be surprised if Github would have 100K+ internal repos or even more.
Personally I have over a hundred, especially from quick prototypes, studies or instances of templates so I can easily see how over 18 years and many hundreds of employees you end up with thousands.
No, there's no joke, you might have just misread the article (the 3,800 number is the number of internal GitHub repos the employee had downloaded on their personal computer / had access to on their own GitHub account)
really? I mean these are internal repos. Probably most of them are random one-off experiments or a place to park code. Google has 2,900 "public" repos on github. Microsoft has ~8k "public" on github too. Can't even imagine how many they have on their internal systems.
Note that VS Code is built on Electron and it is a pain to sandbox because Electron has (had?) SUID sandbox helper, and you cannot run SUID binaries in sandbox easily. Sandboxing on Linux is extremely difficult task.
It feels so bad to see the "You need go give Chrome SUID Root for the sandbox to work". Setting a Web Browser SUID Root was an old joke about clueless users. It was the worst security screwup someone could imagine.
If you own a GitHub organization and are looking for what changes/controls you can apply to reduce the risk/impact of PAT token exfiltration (and subsequent abuse) like what occurred here, I listed a few at the end of https://blog.bored.engineer/github-canarytokens-5c9e36ad7ecf...
- Enable audit log streaming[1] on your enterprise including source IPs and API requests, even if it’s just going to an S3 bucket nobody looks at it, your incident response team will thank you later.
- Enforce the use of SSO on your GitHub organization[2], not just because SSO is good but because it forces an explicit authorization action[3] by users to grant an SSH key/PAT access to your organization resources, instead of granting access implicitly. That way the PAT created for someone’s weekend project won’t have access to your organization resources.
- Enforce an IP allowlist[4] for your organization from a set of known trusted VPN/corporate IPs. This is by-far the strongest control (and the most painful to rollout) as it will prevent stolen credentials (even if still valid) from being used by an attacker except on the intended systems where you (hopefully) have other visibility/alerting via EDR or related tooling.
- If you can, restrict access from personal access tokens[5] to your organization resources. Blocking classic PATs and enforcing a maximum expiration (ex: 3 months) on fine-grained PATs is a great way to reduce risk if you can’t eliminate PATs altogether[6].
- If you use GitHub enterprise (on-prem), configure collection of the raw HTTP access logs[7] in addition to native GitHub audit logs, it may prove critical during incident response.
The (lack of) security of VSCode has always been astounding. People have asked for sandboxing extensions for years [0] with little to no progress, and issues have been discussed a lot (e.g. [1][2]). I guess it hasn't been a big issue, likely because most developers are not complete idiots. But it only takes one developer and one bad extension to consequences like this.
I mean, I understand that it is hard to sandbox Node.js applications, but apparently Microsoft has put way more effort into their Copilot slop than security.
A few days ago I saw I had an update to the Twig extension. The UI flagged it as having new executable code in the update bundle, so I didn't install the update, disabled the extension as I wasn't working on Drupal views that day, and went about my work. I didn't have time to investigate the new update's contents. When I went back to the extension page, it was taken down: https://open-vsx.org/extension/whatwedo/twig
I'm not saying it was whatwedo.twig, but I'm not saying it wasn't, either.
Edit: If anyone's got a good recommendation for a twig formatter for Cursor / VS Code, please let me know.
The security measure that the developer didn't use was completely refusing to use vscode.
vscode has no security model. It's not like swiss cheese where there are holes and some of the go all the way through. vscode is all hole with some cheese on the side. There is absolutely no isolation between the front-end process, the backend size (the thing that runs in the remote or the devcontainer), and any extensions or anything that might be in a repository whose authors you "trust".
Or you can just refuse to use random extensions. I built my own extensions if I needed them. I've moved on to making my own IDE, but vscode served me so much better than anything else for years, without installing a single rando's extension.
The 3800 repos weren't exfiltrated from the compromised machine.
The malware (be it a VSCode plugin, an npm package, or whatever is next) simply slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.
It's trivial to do this in a way to avoid detection. The small payload can be encrypted (so it can't be pattern matched) and then the destination can be one of millions of already compromised websites found via a google search and made to look like a small upload (it could even be chunked and uploaded via query parameters in a HTTP GET request).
The hackers receive the bundle of compromised tokens/keys and go look at what they give access to. Most of the time it's going to be someone's boring home network and a couple of public or private github repos. But every once in a while it's a developer who works at a big organisation (e.g. Github) with access to lots of private repos.
The hackers can then use the keys to clone all of the internal/private repos for that organisation that the compromised keys have access to. Some organisations may have alerts setup for this, but by the time they fire or are actioned upon the data will probably be downloaded. There's no re-auth or 2FA required for "git clone" in most organisations.
With this data the hackers have further options:
a) attempt to extort the company to pay a ransom on the promise of deleting the data
b) look for more access/keys/etc buried somewhere in the downloaded repos and see what else they can find with those
c) publish it for shits and giggles
d) try and make changes to further propagate the malware via similar or new attack vectors
e) analyse what has been downloaded to work out future attack vectors on the product itself
Right now Github (and others recently compromised in similar ways) will be thinking about what information is in those internal repos and what damage would it cause if that information became public, or what that information could be used to find out further down the line.
"Customer data should not be in a github repo" is all well and good, but if the customer data is actually stored in a database somewhere in AWS and there's even just one read-only access token stored somewhere in one private github repo, then there's a chance that the hackers will find that and exfiltrate the customer data that way.
Preventing the breach is hard. There will always be someone in an org who downloads and installs something on their dev machine that they shouldn't, or uses their dev machine for personal browsing, or playing games, or the company dev infra relies on something that is a known attack vector (like npm).
Preventing the exfiltration is virtually impossible. If you have a machine with access to the Internet and allow people to use a browser to google things then small payloads of data can be exfiltrated trivially. (I used to work somewhere where the dev network was air-gapped. The only way to get things onto it was typing it in, floppy or QIC-150 tape - in the days before USB memory sticks.)
Detecting the breach is nigh on impossible if the keys are not used egregiously. Sure some companies can limit access to things like Github to specific IPs, but it wouldn't take much for the malware to do something to work around this. (I can see things like a wireguard/tailscale client being embedded in malware to allow the compromised machine to be used as a proxy in such cases.)
Alerting that requires manual response is nigh on useless as by the time someone has been paged about something the horse has already bolted.
Knowing what has been taken is also a huge burden. 3800 repos that people now have to think about and decide what the implications are. Having been through something like this in the past there are plenty of times people go "I know that repo, it's fine, we can ignore that one" only for it to contain something they don't realise could be important.
These kind of attacks are going to become increasingly common as they're proven to work well and the mitigations for them are HARD. It doesn't need to be targeted at all either, you just infect a bunch of different things and see what gets sent in.
If companies continue to not pay the ransom then we're going to get a lot more things published and many companies having to apologise for all manner of things that end up being leaked.
> It's trivial to do this in a way to avoid detection
I'd love to see a real example/PoC.
Anyway, we discussed this issue in the other thread. For me, unrestricted outbound requests to any url, whether it's well known domains like api.github.com or any other domain, are a red flag.
Why does VS need to establish outbound requests to any domain, without authorization?
There's no magic solution, and these attacks will evolve, but I still think that restricting outbound requests is a good measure to mitigate these attacks.
> slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.
Isolating applications can also mitigate the impact of these attacks. For example, you can restrict VS code to only share with the host .vscode/, .git/ and other directories. Even by project.
Again, it's not bulletproof, but helps.
> Why does VS need to establish outbound requests to any domain, without authorization?
I don't know but it's very standard practice in most applications, because telemetry. But VS code is one of the worst: just check open snitch when running VS code, it's constantly phoning to a bunch of IPs.
> but I still think that restricting outbound requests is a good measure
It is 100% necessary, but doesn't stop most attacks quick enough.
If you're posting to github.com/acmecompany then attackers love to do things like add their own user github.com/acemcompany and just upload your data to that. Generally it doesn't last very long, but with CI/CD they can get thousands of keys in a minute and be gone seconds later.
There are plenty of exfiltration examples out there that could go through known, commonly-greenlit domains. Even exfil via DNS requests has been demonstrated.
But at least in that case, there’s a chance that the outbound requests are blocked. Malware isn’t perfect. Simple measures can block a significant proportion of attacks.
Ah yes, sandboxing/limiting a VSCode plugin is not impossible. I was thinking in more general terms (such as post install scripts within npm/python packages). Random test code in golang packages. There's an awful lot that people don't vet because keeping up with the vetting is a huge burden which seems pointless until you're the one that gets hacked.
The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
That or just repeatedly pester a user for permissions until one user (and you only need one within the organisation) relents and grants it.
the pop-ups fatigue is already an issue, and not an easy one to solve. Pretty much like SIEM/SOC alerts.
> The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
They'll get there, maybe. But the reality is that right now, everyone allows outbound requests blindly.
Instead of speculating, I suggest to actually investigate current IOCs and common tactics of malicious npm/pip/plugins/VS extensions. Something like this:
Or use OpenSnitch (or Lulu, Glasswire, ZoneAlarm anyone?:D etc) to actually analyze real VS malicious extensions or npm packages and see if it stops the exfiltration, and if not, suggest ways to improve it. For example:
If paying the ransom doesn't stop your data getting leaked, nobody will pay the ransom. There is a rational basis for the ransomers to follow through with the deletion. Even the mob did provide "protection" when they coerced you into paying for it.
The data has been stolen by a criminal group. Paying for "restoring" the data does not guarantee they will delete all copies. There is no way of proving they actually did and they have in fact very little incentive to actually delete it.
You have to take their words for it but how can you trust crooks?
Previous thread in sequence:
GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)
Maybe I'm missing something really obvious, but... 3,800 repos? I guess I find it kind of surprising they have that many!
I worked for a food retail store once. I remember going in the first day wondering, how hard can it really be... From the outside, it looks like they have a simple website. The website to order things on was an amalgamation of 300+ repo's. GitHub lost less in this breach. It takes a lot of effort to keep things simple as you grow.
As others have said it's just a fraction. I'm in a medium size tech-related company and we have 7500+ in one Github org. We have two orgs, so altogether easily 10K+. Of course most of it is stale, obsolete, sandbox, personal tools, etc. I wouldn't be surprised if Github would have 100K+ internal repos or even more.
3800 is low for an org like GitHub. Glad it’s highly likely not all their repos are compromised.
Given the attack vector, it's possible that the impacted repos were ones that see more activity.
Personally I have over a hundred, especially from quick prototypes, studies or instances of templates so I can easily see how over 18 years and many hundreds of employees you end up with thousands.
It sounds low to me, I worked at a Fortune high number a few years ago and they had more.
They have 800 engineers. So 3,800 repos is high, but not crazy.
Some of those could be forks.
I was part of an org with more than 15k repos
Am I missing the joke here... they have hundreds of millions of repos.
I think they mean that these are internal github-org repos.
The ones used for running the site itself.
Though, its so many that i think there are some customer ones in there too.
No, there's no joke, you might have just misread the article (the 3,800 number is the number of internal GitHub repos the employee had downloaded on their personal computer / had access to on their own GitHub account)
The breach is about internal repositories, not user repositories.
really? I mean these are internal repos. Probably most of them are random one-off experiments or a place to park code. Google has 2,900 "public" repos on github. Microsoft has ~8k "public" on github too. Can't even imagine how many they have on their internal systems.
Note that VS Code is built on Electron and it is a pain to sandbox because Electron has (had?) SUID sandbox helper, and you cannot run SUID binaries in sandbox easily. Sandboxing on Linux is extremely difficult task.
It feels so bad to see the "You need go give Chrome SUID Root for the sandbox to work". Setting a Web Browser SUID Root was an old joke about clueless users. It was the worst security screwup someone could imagine.
podman seems to handle rootless namespaces just fine, minor caveat for some perf overhead but it's not the end of the world.
But, it did not go down! Progress!
It's working, we just don't know what it's doing.
Don't jinx it!
Curious timing that I've started moving private repos to SourceHut a couple of weeks ago. It's pretty good and fast!
I'm also mirroring public ones to Codeberg.
I'll write about it when I'm done.
I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
Not holding my breath. This issue has been open since 2018 https://github.com/microsoft/vscode/issues/52116
If you own a GitHub organization and are looking for what changes/controls you can apply to reduce the risk/impact of PAT token exfiltration (and subsequent abuse) like what occurred here, I listed a few at the end of https://blog.bored.engineer/github-canarytokens-5c9e36ad7ecf...
- Enable audit log streaming[1] on your enterprise including source IPs and API requests, even if it’s just going to an S3 bucket nobody looks at it, your incident response team will thank you later.
- Enforce the use of SSO on your GitHub organization[2], not just because SSO is good but because it forces an explicit authorization action[3] by users to grant an SSH key/PAT access to your organization resources, instead of granting access implicitly. That way the PAT created for someone’s weekend project won’t have access to your organization resources.
- Enforce an IP allowlist[4] for your organization from a set of known trusted VPN/corporate IPs. This is by-far the strongest control (and the most painful to rollout) as it will prevent stolen credentials (even if still valid) from being used by an attacker except on the intended systems where you (hopefully) have other visibility/alerting via EDR or related tooling.
- If you can, restrict access from personal access tokens[5] to your organization resources. Blocking classic PATs and enforcing a maximum expiration (ex: 3 months) on fine-grained PATs is a great way to reduce risk if you can’t eliminate PATs altogether[6].
- If you use GitHub enterprise (on-prem), configure collection of the raw HTTP access logs[7] in addition to native GitHub audit logs, it may prove critical during incident response.
[1]: https://docs.github.com/en/enterprise-cloud@latest/admin/mon... [2]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [3]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [4]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [5]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [6]: https://edu.chainguard.dev/open-source/octo-sts/overview/ [7]: https://docs.github.com/en/enterprise-server@3.16/admin/moni...
The (lack of) security of VSCode has always been astounding. People have asked for sandboxing extensions for years [0] with little to no progress, and issues have been discussed a lot (e.g. [1][2]). I guess it hasn't been a big issue, likely because most developers are not complete idiots. But it only takes one developer and one bad extension to consequences like this.
I mean, I understand that it is hard to sandbox Node.js applications, but apparently Microsoft has put way more effort into their Copilot slop than security.
[0] https://github.com/microsoft/vscode/issues/52116
[1] https://news.ycombinator.com/item?id=42979994
[2] https://news.ycombinator.com/item?id=46855527
So which extension? Why don't they tell us?
A few days ago I saw I had an update to the Twig extension. The UI flagged it as having new executable code in the update bundle, so I didn't install the update, disabled the extension as I wasn't working on Drupal views that day, and went about my work. I didn't have time to investigate the new update's contents. When I went back to the extension page, it was taken down: https://open-vsx.org/extension/whatwedo/twig
I'm not saying it was whatwedo.twig, but I'm not saying it wasn't, either.
Edit: If anyone's got a good recommendation for a twig formatter for Cursor / VS Code, please let me know.
I’ve used djlint on a liquid project and it worked well. It supports twig too: https://djlint.com/docs/languages/twig/
They also have an online demo/playground so you can at least give it a shot to see if it works.
I’ve used the twiggy LSP before and there seems to be a few VS code extensions for it: https://marketplace.visualstudio.com/items?itemName=moetelo.... and https://marketplace.visualstudio.com/items?itemName=Stanisla...
I'm not seeing anything on the official marketplace: https://marketplace.visualstudio.com/items?itemName=whatwedo...
I wonder if it was open-vsx specific?
There are rumours that was NX Console VS code extension
https://github.com/nrwl/nx-console/security/advisories/GHSA-...
https://www.stepsecurity.io/blog/nx-console-vs-code-extensio...
Sounds like another "why even bother" extension, made to automate things that shouldn't be automated
Is it premature to blame AI Microslop?
It's definitely AI slop. So tired of pushing AI-generated crap to production at my company
so how did they exfiltrate the information without noticing? what OS was the developer using? what security measures were they using?
yesterday discussion https://news.ycombinator.com/item?id=48191680
The security measure that the developer didn't use was completely refusing to use vscode.
vscode has no security model. It's not like swiss cheese where there are holes and some of the go all the way through. vscode is all hole with some cheese on the side. There is absolutely no isolation between the front-end process, the backend size (the thing that runs in the remote or the devcontainer), and any extensions or anything that might be in a repository whose authors you "trust".
Or you can just refuse to use random extensions. I built my own extensions if I needed them. I've moved on to making my own IDE, but vscode served me so much better than anything else for years, without installing a single rando's extension.
(We merged this thread hither - it was originally in https://news.ycombinator.com/item?id=48201316)
The 3800 repos weren't exfiltrated from the compromised machine.
The malware (be it a VSCode plugin, an npm package, or whatever is next) simply slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.
It's trivial to do this in a way to avoid detection. The small payload can be encrypted (so it can't be pattern matched) and then the destination can be one of millions of already compromised websites found via a google search and made to look like a small upload (it could even be chunked and uploaded via query parameters in a HTTP GET request).
The hackers receive the bundle of compromised tokens/keys and go look at what they give access to. Most of the time it's going to be someone's boring home network and a couple of public or private github repos. But every once in a while it's a developer who works at a big organisation (e.g. Github) with access to lots of private repos.
The hackers can then use the keys to clone all of the internal/private repos for that organisation that the compromised keys have access to. Some organisations may have alerts setup for this, but by the time they fire or are actioned upon the data will probably be downloaded. There's no re-auth or 2FA required for "git clone" in most organisations.
With this data the hackers have further options:
a) attempt to extort the company to pay a ransom on the promise of deleting the data
b) look for more access/keys/etc buried somewhere in the downloaded repos and see what else they can find with those
c) publish it for shits and giggles
d) try and make changes to further propagate the malware via similar or new attack vectors
e) analyse what has been downloaded to work out future attack vectors on the product itself
Right now Github (and others recently compromised in similar ways) will be thinking about what information is in those internal repos and what damage would it cause if that information became public, or what that information could be used to find out further down the line.
"Customer data should not be in a github repo" is all well and good, but if the customer data is actually stored in a database somewhere in AWS and there's even just one read-only access token stored somewhere in one private github repo, then there's a chance that the hackers will find that and exfiltrate the customer data that way.
Preventing the breach is hard. There will always be someone in an org who downloads and installs something on their dev machine that they shouldn't, or uses their dev machine for personal browsing, or playing games, or the company dev infra relies on something that is a known attack vector (like npm).
Preventing the exfiltration is virtually impossible. If you have a machine with access to the Internet and allow people to use a browser to google things then small payloads of data can be exfiltrated trivially. (I used to work somewhere where the dev network was air-gapped. The only way to get things onto it was typing it in, floppy or QIC-150 tape - in the days before USB memory sticks.)
Detecting the breach is nigh on impossible if the keys are not used egregiously. Sure some companies can limit access to things like Github to specific IPs, but it wouldn't take much for the malware to do something to work around this. (I can see things like a wireguard/tailscale client being embedded in malware to allow the compromised machine to be used as a proxy in such cases.)
Alerting that requires manual response is nigh on useless as by the time someone has been paged about something the horse has already bolted.
Knowing what has been taken is also a huge burden. 3800 repos that people now have to think about and decide what the implications are. Having been through something like this in the past there are plenty of times people go "I know that repo, it's fine, we can ignore that one" only for it to contain something they don't realise could be important.
These kind of attacks are going to become increasingly common as they're proven to work well and the mitigations for them are HARD. It doesn't need to be targeted at all either, you just infect a bunch of different things and see what gets sent in.
If companies continue to not pay the ransom then we're going to get a lot more things published and many companies having to apologise for all manner of things that end up being leaked.
> It's trivial to do this in a way to avoid detection
I'd love to see a real example/PoC.
Anyway, we discussed this issue in the other thread. For me, unrestricted outbound requests to any url, whether it's well known domains like api.github.com or any other domain, are a red flag.
Why does VS need to establish outbound requests to any domain, without authorization?
There's no magic solution, and these attacks will evolve, but I still think that restricting outbound requests is a good measure to mitigate these attacks.
> slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.
Isolating applications can also mitigate the impact of these attacks. For example, you can restrict VS code to only share with the host .vscode/, .git/ and other directories. Even by project. Again, it's not bulletproof, but helps.
> Why does VS need to establish outbound requests to any domain, without authorization?
I don't know but it's very standard practice in most applications, because telemetry. But VS code is one of the worst: just check open snitch when running VS code, it's constantly phoning to a bunch of IPs.
> but I still think that restricting outbound requests is a good measure
It is 100% necessary, but doesn't stop most attacks quick enough.
If you're posting to github.com/acmecompany then attackers love to do things like add their own user github.com/acemcompany and just upload your data to that. Generally it doesn't last very long, but with CI/CD they can get thousands of keys in a minute and be gone seconds later.
There are plenty of exfiltration examples out there that could go through known, commonly-greenlit domains. Even exfil via DNS requests has been demonstrated.
But at least in that case, there’s a chance that the outbound requests are blocked. Malware isn’t perfect. Simple measures can block a significant proportion of attacks.
Ah yes, sandboxing/limiting a VSCode plugin is not impossible. I was thinking in more general terms (such as post install scripts within npm/python packages). Random test code in golang packages. There's an awful lot that people don't vet because keeping up with the vetting is a huge burden which seems pointless until you're the one that gets hacked.
The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
That or just repeatedly pester a user for permissions until one user (and you only need one within the organisation) relents and grants it.
the pop-ups fatigue is already an issue, and not an easy one to solve. Pretty much like SIEM/SOC alerts.
> The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
They'll get there, maybe. But the reality is that right now, everyone allows outbound requests blindly.
Instead of speculating, I suggest to actually investigate current IOCs and common tactics of malicious npm/pip/plugins/VS extensions. Something like this:
https://github.com/evilsocket/opensnitch/discussions/1119
Or use OpenSnitch (or Lulu, Glasswire, ZoneAlarm anyone?:D etc) to actually analyze real VS malicious extensions or npm packages and see if it stops the exfiltration, and if not, suggest ways to improve it. For example:
https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...
> If companies continue to not pay the ransom then we're going to get a lot more things published
Paying the ransom means your data still gets leaked and now you're out of money and embarrassed.
Why would they ever, ever, delete the data?
If paying the ransom doesn't stop your data getting leaked, nobody will pay the ransom. There is a rational basis for the ransomers to follow through with the deletion. Even the mob did provide "protection" when they coerced you into paying for it.
Because if they leak then nobody will pay the ransom in the future?
> The malware (be it a VSCode plugin, an npm package, or whatever is next)
Not the first time we've seen a developer get popped thanks to a malicious game mod either...
Isn't 50k a bargain for what could potentially be in those files?
Maybe they looked it up and there wasn't anything interesting but then why take the risk for this kind of money?
Something doesn't make sense.
The data has been stolen by a criminal group. Paying for "restoring" the data does not guarantee they will delete all copies. There is no way of proving they actually did and they have in fact very little incentive to actually delete it.
You have to take their words for it but how can you trust crooks?
> You have to take their words for it but how can you trust crooks?
Because these are repeat actors. If they take a ransom and then re-sell it, no company will pay them ever again.
Don't think of experienced criminal enterprises as "groups of irrational scoundrels." They are companies, with employees, who understand game theory.
Another day another issue with Microsoft products, what else can be said :( At least they are being upfront these days.