Nearly impossible to detect on the running server. However, if you have something like a pihole looking for dns exfiltration attempts, this becomes much easier to detect. It does require multiple layers of protection though, I’ll give it that.
Since I haven’t seen any mention of it tampering with the kernel or hooking actual syscalls (as opposed to userspace syscall wrappers), it sounds like its concealment mechanisms should be pretty simple to bypass using statically-linked executables? (A static busybox build, say.)
The grsecurity patchset includes a feature called Trusted Path Execution (TPE). It can integrate with the RTLD to completely mitigate LD_PRELOAD abuses. I’m working on implementing something similar in HardenedBSD this weekend. :-)
Nearly impossible to detect on the running server. However, if you have something like a pihole looking for dns exfiltration attempts, this becomes much easier to detect. It does require multiple layers of protection though, I’ll give it that.
Since I haven’t seen any mention of it tampering with the kernel or hooking actual syscalls (as opposed to userspace syscall wrappers), it sounds like its concealment mechanisms should be pretty simple to bypass using statically-linked executables? (A static busybox build, say.)
This was my take. LD_PRELOAD wouldn’t work in the statically linked context
Or if you’re running in AWS there’s also their guardduty alert which I hope would pick it up: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-ec2.html#backdoor-ec2-ccactivitybdns
The grsecurity patchset includes a feature called Trusted Path Execution (TPE). It can integrate with the RTLD to completely mitigate LD_PRELOAD abuses. I’m working on implementing something similar in HardenedBSD this weekend. :-)
Already posted! https://lobste.rs/s/ijottt/symbiote_new_nearly_impossible_detect
ah I must of missed that