New ultra-stealthy Linux backdoor isn’t your everyday malware discovery

Post by 0daystock » Fri, Jun 10, 2022, 3:19 PM UTC

iso1631 wrote: post #25

> IPv4 (TCP or SCTP) and dst port (43253 or 43753 or 63424 or 26424) So this is hiding network traffic from certain ports, which means that it should be easy enough to spot on spanports or netflow data Are there any good tools which detect malware from analysing network traffic, either things like machines doing wide range attempts to connect on 137/139/445, or burte forcing on 22 etc, but also for more advanced sear…

    tcpdump "tcp[13] & 2 != 0"

Post by pxc » Fri, Jun 10, 2022, 3:27 PM UTC

lvass wrote: post #62

_abox wrote: post #49

Earlier quoted context omitted.

Except they can't really do that. The key there is the person's password manager as most of the things mentioned there are online. The user account should just unlock the desktop. My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking). And I don't keep important things logged in. But xkcd in this case also forgets that the reaso…

>The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC chall…

Post by shaded-enmity » Fri, Jun 10, 2022, 3:47 PM UTC

shaded-enmity wrote: post #35

psacawa wrote: post #33

Earlier quoted context omitted.

I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like ``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```

1. Can't the process just scrub LD_PRELOAD from its environment? Linker already done it's job at that point. 2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs

  #include 
  #include 

  static void begin() __attribute__((constructor));

  void begin() {
    unsetenv("LD_PRELOAD");
  }

  gcc -shared -fpie -o library.so library.c

  LD_PRELOAD=~/library.so env | grep LD_PRELOAD

Post by bediger4000 » Fri, Jun 10, 2022, 3:51 PM UTC

Cthulhu_ wrote: post #38

VoidWhisperer wrote: post #37

Earlier quoted context omitted.

Side tangent: Why does github let these repos for Malware stay up? I understand some of them use the excuse 'this is for education, i'm not responsible for what you do with it', but some don't even bother with that, and atleast my concern would be that some person could easily pull the code, modify it slightly, and off they go if the IOC/detections for the attack method aren't good yet

Personal take: It's better to have malware code stay online and open, than to disappear into obscurity. This being open source also means that anti-malware companies can analyze the code and write detectors and counters to it. Removing it would just mean it gets hidden from the 'good guys' as well.

Post by prvit » Fri, Jun 10, 2022, 4:16 PM UTC

Cthulhu_ wrote: post #39

psacawa wrote: post #33

Earlier quoted context omitted.

I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like ``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```

Wouldn't this malware be able to infect each of these steps and the shell itself to filter itself out of the results?