Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
1–10 of 58 posts
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#2The rootkit now disables SELinux enforcing mode on-demand when the ICMP reverse shell is triggered, leaving zero audit logs.
How it works: SELinux maintains a global kernel structure called selinux_state that contains the enforcement flag. The rootkit resolves this non-exported symbol via kallsyms at module load time, then directly writes enforcing = 0 when triggered. This bypasses the normal setenforce() interface entirely.
The clever part is the dual-layer approach:
* Hooks netlink_unicast to drop audit messages for hidden PIDs
* Attempts to modify selinux_state->enforcing directly in kernel memory
On kernels built with CONFIG_SECURITY_SELINUX_DEVELOP=y, SELinux enforcement may stop at the kernel decision level, while userspace tools continue to report enforcing mode and /var/log/audit/audit.log shows nothing.
- Advanced Network Hiding
Previous versions only hide TCP connections from /proc/net/tcp* by hooking tcp_seq_show, which blocked netstat. But modern tools like ss and conntrack bypass /proc entirely - they query the kernel directly via netlink.
The new version filters at the netlink layer:
* SOCK_DIAG filtering: ss uses NETLINK_SOCK_DIAG protocol to get socket info directly from the kernel. Singularity hooks recvmsg to intercept and filter these netlink responses before userspace sees them. Commands like ss -tapen or lsof -i return empty for hidden connections.
* Conntrack filtering: Connection tracking (nf_conntrack) maintains state for all network flows. Reading /proc/net/nf_conntrack or running conntrack -L would expose hidden connections. The rootkit now filters both the proc interface and NETLINK_NETFILTER messages with conntrack types. * UDP hiding: Added hooks for udp4_seq_show and udp6_seq_show - previous versions only hide TCP.
- Other improvements:
* Optimized log filtering (switched from multiple strstr() calls to switch-case with strncmp()) * Audit statistics tracking (get_blocked_audit_count(), get_total_audit_count()) * Automated setup script
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#3This looks impressive, haven't had a chance to give it a go, would love a consumable "counters" tutorial for this type of intrusion..."Be a researcher, not a criminal." might be wishful thinking.
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#4Nice. Could it be detected by comparing output of `find /` at runtime with output of `find /` if you mount the disk on another system?
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#5The rootkit now disables SELinux enforcing mode on-demand when the ICMP reverse shell is triggered, leaving zero audit logs. How it works: SELinux maintains a global kernel structure called selinux_state that contains the enforcement flag. The rootkit resolves this non-exported symbol via kallsyms at module load time, then directly writes enforcing = 0 when triggered. This bypasses the normal setenforce() interface e…
> The rootkit now disables SELinux enforcing mode on-demand when the ICMP reverse shell is triggered, leaving zero audit logs.
Is this independent of the Linux Security Modules policy, e.g. RHEL default policy for SE Linux?
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#6first thing comes to mind is just grabbing the cr3 and finding it in physical memory for detection.
also this feels a little bit too much effort for something that was never used in the real world not going to lie.
ICMP reverse shell is a really cool idea, no persistence makes it rather harmless compared to what is possible.
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#7I understand that this is to drive research and help security researchers in this case, but I personally think Github should take a harder stance against this kind of repo, education purposes or not - saying it is for educational purposes is definitely not going to stop someone (especially people who wouldn't know how to develop this level of rootkit on their own) from going and using it.
Also the specific details in README regarding 'make sure you randomize this or you'll be detected!' makes it feel even less like it is explicitly for educational purposes since you are providing users easy instructions on how to work around countermeasures this code.
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#8Impressively polished. Pair with BIOS/UEFI boot persistence and you've got a nasty infection.
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#9first thing comes to mind is just grabbing the cr3 and finding it in physical memory for detection. also this feels a little bit too much effort for something that was never used in the real world not going to lie. ICMP reverse shell is a really cool idea, no persistence makes it rather harmless compared to what is possible.
Red teams (internal or consultants) use this sort of tooling in the real world. Their job is to emulate a real, competent threat actor. APTs routinely use high-quality rootkits for EDR evasion.
Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.
Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)
#10I understand that this is to drive research and help security researchers in this case, but I personally think Github should take a harder stance against this kind of repo, education purposes or not - saying it is for educational purposes is definitely not going to stop someone (especially people who wouldn't know how to develop this level of rootkit on their own) from going and using it. Also the specific details in…
Do you think malware creators find out by reading HN or github? I don't understand the vitriol, the request "Github should take a harder stance" could have a chilling effect on security researchers, pushing high impact exploits deeper underground.