Loading malware…
Singularity is a Linux loadable-kernel-module rootkit designed for Linux 6.x kernels, associated with the researcher MatheuZSecurity. It uses ftrace-based kernel hooks to conceal processes, files, network activity, and its own activity from ordinary host inspection. It also intercepts SysRq diagnostic reporting paths to suppress hidden processes from kernel diagnostic output. The rootkit supports persistence through kernel-module boot-load configuration and can be manually loaded as a kernel module. Reported functionality includes root privilege escalation, real-time filtering and clearing of journal and kernel-log evidence, suppression of kernel-taint evidence, and interference with security visibility mechanisms including ftrace controls, eBPF monitoring, io_uring protections, and module loading. Singularity includes an ICMP-triggered reverse shell; processes spawned through this access mechanism can inherit its concealment behavior. It targets x86 Linux environments, including 64-bit and 32-bit architectures.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
9 distinct techniques documented for this family, organized by ATT&CK tactic.
Attackers must explicitly configure the system to reload the malicious module on boot... /etc/modules, modprobe configuration files, and modules-load.d configuration files. | Reptile’s loader directly invokes the init_module syscall with an in-memory decrypted kernel blob... Effective detection should therefore focus on tracing these syscalls directly.
Attackers must explicitly configure the system to reload the malicious module on boot... /etc/modules, modprobe configuration files, and modules-load.d configuration files. | Reptile’s loader directly invokes the init_module syscall with an in-memory decrypted kernel blob... Effective detection should therefore focus on tracing these syscalls directly.
“A rootkit can ask the kernel’s ftrace machinery to do it on its behalf; essentially ‘legitimizing’ the hook.”
Rootkits may delete these log files... Or clear the kernel message buffer through dmesg... Another means of clearing these logs is by using journalctl.
4 indicators attributed across vendor reports, sandbox runs, and researcher write-ups. Full values are available in Mallory.
IPs, domains, and DNS infrastructure linked to this family.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A Linux rootkit that relies on built-in LKM-loading utilities, sets up persistence via modules-load.d, and is discussed for stealthy deployment from /dev/shm and log-clearing behavior.
Linux loadable-kernel-module rootkit that uses a deployment script to load its module, establish modules-load.d persistence, and clear artifacts. Its suggested deployment uses /dev/shm, Git cloning, host-side compilation, and script execution; it also attempts journal cleanup and shredding of deployment files.
Linux rootkit cited as abusing the kernel ftrace framework to install hooks.
Linux rootkit referenced as abusing ftrace to implement stealthy kernel function hooking.
Match every observed IP, domain, and hash against your live telemetry.
Named campaigns wielding this family, with evidence pinned to each claim.
CVEs this family uses for access and lateral movement.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Every documented technique, ranked by evidence weight.
Reddit, Mastodon, and CTI community discussion around this family.