Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

21–30 of 101 posts

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

#21

Post by notakio »

janandonly wrote: post #6

Very clever hiding techniques. Makes me wonder which state level actor(s) are behind this one?

It certainly feels like a nation state's work, or, at the very least, an "advanced persistent threat" group. The packet capture pre-filter aspect, at very least, is strongly reminiscent of code I've seen from a couple of particular SE Asian APT-designated groups.

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

#22

Post by prvit »

notakio wrote: post #21
janandonly wrote: post #6

Very clever hiding techniques. Makes me wonder which state level actor(s) are behind this one?

It certainly feels like a nation state's work, or, at the very least, an "advanced persistent threat" group. The packet capture pre-filter aspect, at very least, is strongly reminiscent of code I've seen from a couple of particular SE Asian APT-designated groups.

What reason do you have to believe that besides the targets? Feature-wise this isn't significantly more advanced than public LD_PRELOAD kits like Umbreon, developed by literal children.

A basic BPF filter isn't fancy or difficult to implement.

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

#24

Post by iso1631 »

jwrallie wrote: post #5

But how does it spread?

Presumably an RCE or trojan to infect the first machine, then once you have a foothold on the network and are capturing credentials you can move laterally and spread it using authorised access (perhaps including priv elevation)

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

#25

Post by iso1631 »

> 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 searches for traffic like this?

I see plenty of companies selling end point protection, but that's not much use with the amount of blackboxes I have on my network.

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

#26

Post by notakio »

prvit wrote: post #22
notakio wrote: post #21

Earlier quoted context omitted.

It certainly feels like a nation state's work, or, at the very least, an "advanced persistent threat" group. The packet capture pre-filter aspect, at very least, is strongly reminiscent of code I've seen from a couple of particular SE Asian APT-designated groups.

What reason do you have to believe that besides the targets? Feature-wise this isn't significantly more advanced than public LD_PRELOAD kits like Umbreon, developed by literal children. A basic BPF filter isn't fancy or difficult to implement.

Primarily, similarity to forensics samples I've seen via incident response. But you're right; the individual aspects of this aren't particularly outstanding or complex, it's the lack of uncrossed T's and undotted I's, overall, that makes me lean toward the conclusion I'm making. Kids tend to be sloppier than criminal malware organizations, as criminal malware organizations tend to be sloppier than APT groups.

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

#27

Post by willbudd »

rnhmjoj wrote: post #12

LD_PRELOAD and hooking the libc syscall wrappers doesn't seem very reliable. It won't work on static binaries, it depends on the user not clearing the environment and there are also many programs that use the syscall directly, bypassing the hooks. From playing with file system hooks I remember programs written in Go and sqlite used to do this.

Only a very small percentage of Linux binaries in the wild is fully static though (e.g., those that are compiled with musl). This is "thanks" to Glibc, which makes doing so nigh impossible.

I also highly doubt "many" programs make syscalls directly, but I could be wrong. I know I haven't done so since the days I dabbled in assembly, at least.

Post reply on HN