I haven't taken a look at the malware, but it seems to download files from the Internet so it should have warned you to allow/deny the outbound connections.
It'd be nice to test it with a sample of aur package/malware.
it does, I am using it extensively (little snitch on mac, and open snitch on linux). My problem with it is that every new tool wants to connect to the internet and my terminal is the constant source of outbound connections. I try to review everything but the amount of tools and connections is overwhelming. It does limit the risk, but i do not trust my terminal and dev tools as usually i give them way too many permissions and any plugin or tool from AUR can contain malware
PS. Regarding downloading files from internet, every self-update tool does that nowadays, it becomes more common because of apple/others stores policies. I created a few remote control tools and it is very very difficult to caught them, and I am not even a professional malware researcher. Things they do is beyond understanding of average superuser
The campaign is using Go packages just as a mechanism to download a ransomware for Linux systems, and it specifically checks if the Documents/ directory exists for the current user. If it doesn't exist it does nothing.
That's probably why the malware sandboxes are not detecting the outbound connections and the encrypting activity.
The article misses one critical point in these attacks:
practically all these attacks require downloading remote files to the server once they gain access, using curl, wget or bash.
Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Also these cryptominers are usually dropped to /tmp, /var/tmp or /dev/shm. They need internet access to work, so again, restricting outbound connections per binary usually mitigates these issues.
> Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Any advice what that looks like for a docker container? My border firewall isn't going to know what binary made the request, and I'm not aware of per-process restrictions of that kind
The plugin uses a reverse-tunneling SocketIO-server (to bypass NAT) on https://jabberplugins.net (*hosted by me*) which is used for routing OTR-encrypted (if enabled) screenshare packets between you & your buddy.
It also includes the libotr lib, modified by the author.
I'd love to read the analysis by Johnny Xmas, the report from 0xfffc0000 and even the binary so other people can test it with other tools and/or analyze it.
An EDR would have detected an inbound connection to port 22.
Then it'd have detected the attacker's activity (opened files, executed commands, etc)
If the EDR is capable of intercepting the forks, clone() execves, open(), etc, then you can follow the traces.
If it's able to deny certain activity based on rules like modifying /etc/ld.so.preload or download files with curl/wget, it'd have made the attacker's life a bit more difficult.
If the attacker loaded a rootkit, then probably you'd have lost visibility of what the attacker did after that.
Also not all the EDRs hook all the functions, or they have bugs, so many times you are not able to follow a trace (without pain/guessing).
This telemetry usually is sent to a remote server, so the attacker could not have deleted it.
https://github.com/evilsocket/opensnitch/discussions/1290
that malware campaign is still active.
reply