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.
Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.
For example, a ransomware gang may compromise a company's network, steal data, deploy the cryptolocker, and then get out. There's no need to have persistent access; they got what they wanted.
my first thoughts is that this is actually a vector against people rather than servers which do reboot daily.
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.
People will build malware. It is actually both fun and educational. Them sharing it makes the world aware of it, and when people are aware of it, they tend to adjust their security posture for the better if they feel threatened by it. Good cybersecurity research & development raises the bar for the industry and makes the world more secure.
Security through obscurity is not security [1]
When only l33t underworld h4x0rz know about software flaws, there is very little incentive or ability for regular software developers to find and fix what enables these vulnerabilities. Only through shared knowledge can the world become a better place.
[1] https://en.wikipedia.org/wiki/Security_through_obscurity
Instead of trying to educate everybody about how to safely use error-prone programming abstractions, we should instead de-normalize use of them and come up with more robust ones. You don't need to have in-depth exploit development skills to write secure Rust code.
Unfortunately, there's more money to be made selling security consulting if people stick to the error-prone ones.
For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi...);
Audit is supposed to be able to track anything and everything that happens on a Linux box. Every login, application, socket, syscall, all of it. The fact that they can bypass it is HUGE. You're not supposed to be able to disable auditd without rebooting the system (when correctly configured). And rebooting the system should* trigger other alarms for the security team.
Permitting user-loaded kernel modules effectively invalidates all other security measures.
if so, why is it there at all?
Years back when our team was dealing with weird permission issues on multiple levels due to SELinux, I found little value in it.
I assume you know what a network firewall is. Think of SELinux like a "System Call Firewall". SELinux will protect you from many so-called "zero-day" vulnerabilities. It watches every syscall an application makes, looks at its policy, and decides if that syscall should be allowed/denied. It is a good thing.
However, SELinux is really not user-friendly, though it is extremely well documented and learnable. (run `man -k selinux` to see all the man pages) Red Hat also has thorough documentation (https://docs.redhat.com/en/documentation/red_hat_enterprise_...)
Specifically, to your "weird permission issues". That is a "problem" with SELinux; it doesn't surface errors well. The TL;DR is: if you get a "permission denied" error, and you rule out the obvious (i.e., filesystem permissions), then you need to know to blame SELinux and look at the `/var/log/audit/audit.log` file.
That file is technically human readable, but there are tools that make it much easier, such as `ausearch` and `sealert -a`.
---
https://danwalsh.livejournal.com/71122.html
"Now this is a horrible exploit but as you can see SELinux would probably have protected a lot/most of your valuable data on your machine. It would buy you time for you to patch your system."
Because in my experience, when people are "dealing with weird...issues" and "[finding] little value in it" they usually don't understand what it is and how to use it.
This makes any tool difficult to appreciate.
echo 1 > /proc/sys/kernel/modules_disabled
Which is supposed to block dynamic loading modules until a reboot.
It would be interesting if the PoC can get around that trick too. =3
Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.
The Linux kernel is not really an effective privilege boundary.
Why bother loading a module when you can inject code into any function you want.
Thus, there currently is economic inertia entrenching vulnerable system design. I don't think there is a company large enough to change the situation anytime soon, as the market has spoken. =3
Rule #3: popularity is not an indication of utility.
This doesn't solve all vectors but afaics this will prevent non signed modules from loading.
Does not work if kernel Kconfig setting has:
CONFIG_MODULES=n
does this work on normal linux desktops ? My impression was that either: 1). Kernel is too big. Try making modules - link error or 2) System will not boot due to missing/misconfigured parts.
echo 1 > /proc/sys/kernel/modules_disabled
Which is supposed to block dynamic loading modules until a reboot. =3
Or is the only line of defense a kernel compiled without the ability to load modules?
I know all bets are off once someone already gained root, but not allowing the installation of a stealth rootkit is never bad.
matheuzsec•1d ago
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
Repo: https://github.com/MatheuZSecurity/Singularity
transpute•1d ago
Is this independent of the Linux Security Modules policy, e.g. RHEL default policy for SE Linux?