gus_

6 ms·

1.
by gus_ 2mo ago
1. restrict outbound connections by binary. 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 4. remove exec permis
2.
by gus_ 3mo ago
Unfortunately this order will probably be revoked in 2027/2028, we'll see.
3.
by gus_ 3mo ago
Also bear in mind, that many rootkits hide processes and connections from command line tools like ps, top, lsof, netstat, ss, etc... In this particular malware campaign, the malware contained a rootkit which hid precisely some of its activi
4.
by gus_ 3mo ago
indeed OpenSnitch helps, pihole I'm not so sure (maybe if the c2c servers are in a blocklist...): https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comme...
5.
by gus_ 3mo ago
A year ago a similar attack was reported and I think that there have been similar campaigns reported this year: https://github.com/evilsocket/opensnitch/discussions/1290#di... - This is a new repository,
6.
by gus_ 3mo ago
https://ioctl.fail/preliminary-analysis-of-aur-malware/ https://markdownpastebin.com/?id=d2a04939f1d7461ea0d36e438a4...
7.
by gus_ 4mo ago
https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
8.
by gus_ 4mo ago
restrict code.exe to an allowlist. Also, many malicious actors rely on system commands to download or exfiltrate data. Take for example this activity from a malicious extension: This code makes an HTTP GET request to https://s
9.
by gus_ 4mo ago
https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
10.
by gus_ 4mo ago
https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
11.
by gus_ 4mo ago
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
12.
by gus_ 4mo ago
> 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
13.
by gus_ 4mo ago
absolutely. These attacks will evolve for sure, like the malware evolved on Microslop for years. But for the time being, the common entry vector is clear: https://github.com/evilsocket/opensnitch/discussions/1
14.
by gus_ 4mo ago
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
15.
by gus_ 4mo ago
btw, this analysis of a node linux malware with OpenSnitch and other tools was published on reddit a year ago (a malicious linkedin interview targeting web3/crypto devs that resulted in a system compromise): https://markdow
16.
by gus_ 4mo ago
Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe y
17.
by gus_ 5mo ago
https://itsfoss.com/munich-linux-failure/ It doesn't matter if this or that doesn't work. Or if Microslop pressures to continue using Winslop. Now the reasons are geopolitical.
18.
by gus_ 5mo ago
OpenSnitch (+ block lists) ;) or DNS stubs with filtering capabilities.
19.
by gus_ 6mo ago
In this case, this has nothing to do with reverse engineering, it's basic system administration. See how the AI points you in the "right" direction: What likely happened: The exec(base64.b64decode('...')) patt
20.
by gus_ 8mo ago
running apps in a sandbox is ok, but remember to disable internet access. A text editor should not require it, and can be used to exfiltrate the text(s) you're editing. When started, it sends a heartbeat containing system informa
21.
by gus_ 8mo ago
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 Unrestricted outbound connections, specially from curl/
22.
by gus_ 9mo ago
I'd not trust any app that parses /proc to obtain process information (for reasons [0]), specially if the machine has been compromised (unless by "incident", the author means another thing): https://github.com
23.
by gus_ 9mo ago
ss obtains the connections information via netlink directly from the kernel (besides parsing /proc): https://manpages.debian.org/bookworm/manpages/sock_diag.7.en... https://github.com/vishvana
24.
by gus_ 9mo ago
At the very least, these tools should not parse /proc to obtain information of processes or connections. It should be the last option. Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc func
25.
by gus_ 9mo ago
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
26.
by gus_ 9mo ago
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.
27.
by gus_ 9mo ago
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 parti
28.
by gus_ 11mo ago
probably no: https://github.com/evilsocket/opensnitch/discussions/1290 that malware campaign is still active.
29.
by gus_ 11mo ago
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.
30.
by gus_ 11mo ago
specially interpreters: python, perl, npm, etc. https://github.com/evilsocket/opensnitch/wiki/Rules#best-pra...

More ›