2026-08-10 · view entry permalink →
An intruder used pam_rootok to move between low-privileged identities as a deliberate forensic smokescreen — inverting what a responder infers from the authentication trail
Group-IB's incident-response team has published a May 2026 intrusion whose interesting half is not the cryptominer it ended in but the reasoning behind how the operator moved (Group-IB, 2026-07-30). Initial access "was achieved by exploiting a trusted third-party relationship" — a standard user account inherited from a trusted environment — after which the actor escalated to root.
At that point the operator did something most intrusions do not: it stopped acting like root. Group-IB records that the attacker abused the pam_rootok policy so that su would assume the identities of multiple low-privileged users across the system without needing their passwords. pam_rootok is a legitimate, widely shipped PAM module whose entire purpose is to let the root user authenticate as anyone without a credential — nothing was exploited to make it work. What it buys the attacker is that the actions which follow appear in the authentication and audit trail as ordinary users doing ordinary things, rather than as root, which is the activity class a SOC alerts on.
The persistence design follows the same logic. Redundant cron jobs were planted across those low-privileged, unmonitored accounts, so that — in Group-IB's words — "if SOC analysts only remediated the root compromise, the botnet implant would simply regenerate from the shadowed accounts." That is an explicit bet against the standard remediation instinct of fixing the privileged account and closing the case. Alongside it, core logging services were stopped and authentication logs tampered with, and the payload unlinks its own binary immediately after taking a mutex, so it "transitions into a fileless state, running entirely from memory (RAM)."
The transferable point for this constituency is about inference, not about miners. A responder reading an authentication trail normally treats a session under a low-privileged account as evidence of limited privilege; here that inference is exactly backwards, and the identity in the log is a costume. Any Linux estate reached through a supplier or managed-service relationship — the initial-access shape Group-IB names — inherits the same exposure.
Detection, telemetry class first. Group-IB names the anchor itself: authentication and audit records showing root rapidly transitioning into standard user accounts, specifically session-start events associated with pam_rootok, should alert. Two supporting classes matter as much. Service-state telemetry showing the system logging or auditing daemon stopping or being modified without a corresponding change record is a signal in its own right rather than a maintenance artefact, which is why forwarding to an external, tamper-resistant collector in real time is what preserves the evidence at all. And scheduled-job telemetry across ordinary user accounts — not just privileged ones — is where the redundant persistence lives. Triage: administrators legitimately use su to operate as service accounts, and cron jobs under application accounts are normal; the discriminator is direction and tempo — root descending into several unrelated low-privileged identities in quick succession, with no corresponding administrative task, followed by new cron entries under those same accounts. A single su is noise; the fan-out is the signal.
Initial access was achieved by exploiting a trusted third-party relationship, highlighting critical supply chain risks.
By distributing their malicious activities and planting redundant cronjob persistence across various unmonitored standard accounts, the attackers ensured that if SOC analysts only remediated the root compromise, the botnet implant would simply regenerate from the shadowed accounts.
Immediately after establishing this mutex, the malware performs a self-unlink operation. By deleting its own binary file from the disk while the process remains active, the malware transitions into a fileless state, running entirely from memory (RAM).
Alerts should be triggered immediately if root is observed rapidly transitioning into standard user accounts (USER_START events associated with pam_rootok).
The malware natively supports process masquerading via the custom -h flag, allowing it to spoof legitimate process names such as "ssh" in ps, top, and /proc/<pid>/comm outputs.