How to detect and remove rootkits after privilege escalation
A privilege escalation event changes the nature of a security investigation. An attacker who moves from a standard account to root, SYSTEM, or an equivalent administrator context can alter logs, install drivers, create hidden accounts, and tamper with security controls. If a rootkit is involved, ordinary file scans may show a clean machine while malicious code remains active below the operating system.
Rootkits are designed to conceal processes, files, network connections, registry changes, kernel modules, boot components, or firmware implants. They are less common than commodity malware, but the consequences are severe because they can provide durable access and undermine the evidence used to investigate the breach.
Australian organisations also need to consider operational constraints. A hospital in Brisbane, a manufacturer in Geelong, or a mining business supporting a remote site in Western Australia may not be able to simply switch off a system during business hours. The response must balance forensic integrity with safety, availability, privacy obligations, and the need to keep essential services running.
The reliable approach is to treat suspected rootkit activity as a high-confidence compromise until proven otherwise. Detection depends on comparing trusted views of the system, while removal usually requires taking the affected host outside its normal operating environment and rebuilding the trust chain.
Why privilege escalation changes the investigation
Privilege escalation gives an intruder the authority to change the tools defenders rely on. They may stop endpoint protection, patch event records, modify audit policies, hook system calls, or replace utilities such as ps, netstat, and ls. A user-space rootkit can hide selected processes and files, while a kernel rootkit can manipulate the operating system’s view of memory, storage, and network activity.
The escalation path is important evidence. Review authentication events, token assignments, vulnerable services, scheduled tasks, local group changes, and exploitation attempts around the time administrative access appeared. On Windows, examine service creation, PowerShell activity, remote management, and unusual parent-child process relationships. On Linux, inspect sudo, SSH, cron, systemd units, setuid binaries, and changes under /etc.
Do not assume that a clean endpoint scan clears the host. A rootkit may intercept the scanner itself or activate only after reboot. Security teams should compare endpoint telemetry with network logs, identity-provider records, DNS queries, proxy data, and hypervisor or cloud control-plane events. A discrepancy between these sources is often more useful than a single alert.
Recognise rootkit indicators
Some warning signs are indirect. A server may reboot unexpectedly, lose security-agent connectivity, report inconsistent process counts, or show unexplained changes to boot configuration. A workstation may have a new driver, a disabled update service, a hidden administrator, or outbound traffic from a process that does not appear in the local task list. Kernel warnings, unsigned modules, Secure Boot changes, and altered system binaries deserve immediate attention.
Compare the host with a known-good baseline rather than relying on intuition. Check hashes for operating-system files, loaded modules, boot managers, firmware versions, scheduled jobs, service definitions, and startup locations. Use trusted external tools where possible, and perform the comparison from a clean administrative workstation or forensic environment. Public guidance such as consumer security guidance can help explain basic endpoint hygiene, but suspected rootkits require enterprise-grade incident handling and evidence preservation.
Memory analysis can reveal hidden processes, injected code, suspicious handles, kernel hooks, and network sockets that are absent from disk-based reports. Capture volatile data before powering down when the case warrants forensic investigation. Record the time, operator, collection method, system state, and cryptographic hash for every image or memory capture.
A rootkit indicator is rarely decisive on its own. An unsigned driver may be legitimate, and a missing process may reflect a monitoring error. Confidence rises when independent sources agree: the endpoint reports no process, a network sensor sees its traffic, and memory analysis reveals a hidden object linked to a recently created service.
Preserve evidence before removing the threat
The first practical question is whether the host must remain online. If it is supporting a critical production line or a patient-facing system, abrupt isolation could create safety or availability risks. Coordinate with the incident commander, system owner, and relevant operations team. In Australia, organisations covered by the Security of Critical Infrastructure framework may also need to consider sector-specific reporting and response expectations.
| Investigation need | Preferred action | Main risk if skipped |
|---|---|---|
| Preserve volatile evidence | Capture memory, active connections, processes, and logged-in users | Hidden code and live command channels may disappear |
| Stop attacker control | Isolate using an EDR network block, switch control, or firewall rule | The intruder can erase evidence or move laterally |
| Protect business continuity | Use segmented containment or a standby host where available | A rushed shutdown may interrupt essential services |
| Establish trust | Reimage from verified media and rotate credentials | The rootkit or stolen access may survive remediation |
| Validate recovery | Compare hashes, telemetry, and privileged activity after rebuild | Persistence may return unnoticed |
Isolation should prevent attacker communication without giving the adversary a chance to destroy evidence. Where possible, use a network-level quarantine that preserves local state. Disable wireless and wired connectivity only after considering remote management, safety systems, and the possibility that the rootkit controls the endpoint firewall.
Capture forensic images using trusted boot media, write blockers, or a validated collection platform. Avoid running unfamiliar remediation tools directly on the compromised operating system. Every command can change timestamps, memory, logs, or the rootkit’s behaviour. Store evidence in access-controlled systems and document custody, particularly when the incident may involve personal information under Australia’s Notifiable Data Breaches scheme.
Build a safe containment and triage workflow
A coordinated response reduces the chance that one team cleans a machine while another unknowingly restores the attacker’s access. CARM Security’s guidance on isolating infected systems is relevant when a business needs containment without taking every dependent service offline. The same principle applies to suspected rootkits: separate the host, preserve evidence, and maintain a controlled route for essential operations.
Immediate containment priorities
- Quarantine the endpoint or server from user and east-west network traffic.
- Suspend suspected accounts and revoke active sessions or tokens.
- Block known command-and-control domains, addresses, and certificates.
- Protect backups from the compromised identity and host.
Once the host is contained, scope the incident across identities, endpoints, workloads, and shared administration tools. Search for the same driver hashes, service names, command lines, certificates, scheduled tasks, and login patterns elsewhere. Check domain controllers, privileged access platforms, virtualisation consoles, cloud identities, and remote monitoring tools because an escalated account may have been used beyond the original machine.
Triage evidence to correlate
- Authentication records and privilege changes around the initial compromise.
- Endpoint, firewall, DNS, proxy, and VPN telemetry.
- Driver, bootloader, firmware, and system-file changes.
- Backup, hypervisor, cloud, and configuration-management activity.
Avoid mass deletion at this stage. Removing suspicious files before recording their paths, hashes, timestamps, signer information, and relationships can destroy useful evidence and leave other persistence mechanisms intact. If several systems are affected, classify them by business impact and confidence of compromise, then use a clean management plane to coordinate containment.
Australian environments often combine cloud services with older line-of-business servers and outsourced monitoring. That mix can create blind spots between a managed service provider, an internal security operations centre, and an infrastructure team. Establish one incident timeline and one authoritative list of affected assets so that a regional branch or an office in Perth does not unknowingly reconnect a remediated-looking machine to the wider network.
Remove persistence and validate the host
For a confirmed or strongly suspected rootkit, targeted file deletion is usually the wrong remedy. The safest path for a standard workstation or server is a rebuild from trusted installation media, followed by secure configuration and restoration from verified backups. Reinstall the operating system, replace compromised boot components, apply current firmware where appropriate, enable Secure Boot or equivalent protections, and install security agents from known-good sources.
Firmware and boot-level threats need extra care. Verify UEFI settings, boot order, trusted keys, disk partition structures, and firmware versions against a reliable baseline. Some hardware vendors provide signed recovery processes; use those rather than downloading utilities from unofficial sites. If the implant may reside in firmware, involve the manufacturer or a specialist digital forensics provider. A normal operating-system reinstall cannot guarantee removal from a lower layer.
Rotate credentials after the rebuild, not merely before it. Prioritise local administrator passwords, domain and cloud accounts, service principals, SSH keys, API tokens, certificates, remote support credentials, and backup accounts. Revoke active sessions and refresh secrets from a clean administrative workstation. Review group memberships and delegation paths because the attacker may have created alternate routes back into the environment.
Restore only data and applications that have been checked. Do not restore an entire system image if it may contain the rootkit or its persistence. Validate application installers, scripts, infrastructure-as-code templates, and backup provenance. For servers, rebuild through a trusted configuration pipeline where possible, then compare the resulting state against the approved baseline.
Validation should continue after the host returns to service. Monitor privileged actions, driver loads, outbound connections, scheduled tasks, boot changes, and security-agent health for an agreed observation period. Ask the security operations team to test whether the rebuilt system’s telemetry appears consistently in the SIEM, EDR, identity, DNS, and network platforms.
Turn the incident into durable resilience
Rootkit response exposes weaknesses in visibility and privilege management. Strengthen endpoint detection, central logging, application control, driver signing enforcement, vulnerability management, and tamper protection. The Australian Signals Directorate’s Essential Eight provides a practical reference point, particularly for application control, patching, restricting administrative privileges, and regular backups.
Segment administration from ordinary user activity. Privileged accounts should use phishing-resistant multi-factor authentication, separate workstations or hardened management hosts, time-limited elevation, and recorded sessions. Restrict direct internet access from servers and block unnecessary east-west traffic. These controls make privilege escalation harder and reduce the attacker’s ability to turn one compromised host into an enterprise-wide foothold.
Review recovery arrangements with the people who operate the business, not just the security team. A mining site with intermittent connectivity, a council office handling public records, and a financial services environment in Sydney may need different isolation and rebuild procedures. Test whether clean media, replacement hardware, identity recovery, and verified backups are actually available during an incident rather than assuming they will be.
The final record should capture the initial access route, escalation method, rootkit layer, affected assets, evidence collected, containment decisions, eradication steps, credential rotations, and validation results. Map each finding to an owner and due date. Begin by taking one suspected host offline through a controlled quarantine, capturing its memory and disk evidence, and recording the action in the incident timeline.