Whoamifuck collects Linux host evidence in one pass

A name from the Zhouli and a tool built for the scene

Whoamifuck, also called Chief-Inspector and abbreviated as who, takes its name from the Zhouli, where the office of the chief inspector was responsible for keeping the market running and the flow of people orderly, stopping and punishing behaviour that broke the rules. The README frames that as a description of what the tool does. It is a Linux emergency response script written in shell that outputs and analyses basic check items and supports some extended features, and the project description is more specific about the purpose, being for Linux emergency response, for quickly investigating abnormal user logins and intrusion information, accurately locating and tracing a timeline, and efficiently helping reconstruct an attack chain. The README is candid about the intended use, stating that the tool is only an aid, only for offensive and defensive technical study and exchange, and must not be used for illegal purposes, and that downloading it means agreeing to that. The first open source tool from the same author, and the reason for a shell implementation is stated plainly, since Python has many dependencies and large version differences, while shell is natively supported and most Unix and Linux systems handle bash.

The Rust rewrite keeps the shell behaviour and changes the build

The project now ships a Rust rewrite in the src/ directory as a Cargo project, and the README explains what it preserves and what it changes. It faithfully keeps the command line interface, the output style and the detection logic of the original who.sh, while control flow, argument dispatch, the kernel CVE data table and version comparison are all implemented natively in Rust. Collection of system state still reuses the underlying system commands, ps, ss, last and find among them, which the documentation says is consistent with how any emergency response tool works and what guarantees the output matches the original. The reasons given for the rewrite are three. A single static binary is easier to distribute at an incident site without depending on a particular shell version, types avoid the large number of quoting and variable reference traps in bash, and structured code for the kernel CVE version table, version comparison and log parsing is easier to maintain and extend. The build is a plain cargo build, and the release profile in the manifest sets opt-level 3, enables LTO and strips symbols, which is what you want in a binary you are copying to a stranger's machine.

The command surface is organised by what you are asking

The usage output is grouped into sections, and the grouping is the fastest way to understand the tool. The QUICK section has the version and help flags, a user and device information flag, the login information flag that takes an optional file path defaulting to the secure and auth log locations, a basic output mode and a full output mode. The SPECIAL section holds checks of user processes and running services, open port state, and system status. The RISK section is the one a responder reaches for, with baseline security assessment, a flag that views possible system vulnerabilities, a backdoor detection check, and a webshell search that takes a path defaulting to common web roots. The MISC section adds a page liveness probe, a SQL injection focused log analysis, an option to add the tool to a scheduled run plan with a 0 to 23 or continuous value, and a custom command configuration test pointing at a per-user configuration file. The OUTPUT section exports the full output to a file or to an HTML file.

Running it needs root, and the Rust binary is the one to use

The Rust build produces a binary called who, and the documented invocations all run it with sudo. The help flag shows the usage, the basic output mode gives a quick pass, the risk flag runs the common vulnerability self check, and the report flag writes an HTML report. The tool requires root to collect complete information, and the README explains that a root check was added for that reason, to guarantee the program's usability, since otherwise unexpected errors occur. The original shell script is still in the repository as who.sh alongside the src/ directory, and the download instructions are the usual three steps, a clone, a cd and making the script executable. The command line arguments are described as identical to the usage output below. The HTML report is described as a functional port rather than a byte-for-byte copy, collecting the same categories of information as the original and rendering them as a self-contained HTML report with collapsible sections and a search box, rather than reproducing the original 1400 line inline template.

The original shell script is downloaded with:

git clone https://github.com/enomothem/Whoamifuck.git
cd Whoamifuck
chmod +x whoamifuck.sh

The Rust build is then a plain cargo build with the release profile.

Login triage is the feature the author keeps improving

The section on the optimisation of user login investigation is the longest part of the README, and the improvements are in the detection of who was trying to get in. The login flag replaces an earlier flag, and the changes are three. First it checks whether a file argument was given, so it can analyse different system file types, and the note asks you to check whether a log exported from another system is named auth.log or secure. Second, if no file is given, it determines whether the system is Red Hat family or Debian family and uses the secure default path for the former and auth.log for the latter. Third, if neither a file nor a correct operating system identification is available, as with a cut down distribution, it falls back to the Red Hat convention, and you can then point it at a specific file. The output lists the usernames attackers enumerated, the top ten attacker IP addresses, the IP addresses of successful logins, and the number of brute force attempts against each username. The basic system information was also improved with a virtual machine check and timestamps, which the README says help locate the timeline and the device type during forensics.

What the checklist actually covers

The implemented features list in the README is a good inventory of what a responder should expect, and it is long. It covers system version information, historical command information, running service information, process analysis, user information investigation, file status information, scheduled task information, open port information, system status monitoring, and analysis of site logs. It also includes baseline checking support, mining virus detection, common vulnerability self check, backdoor file detection, zombie process cleanup, site liveness probing, boot startup items, attack trace discovery, scheduled run tasks, symlink backdoor checks, environment variable backdoor checks, common format reports, highly extensible commands, remote risk specialisation, webshell searching and mail notification. One box is unticked, malicious program searching, which tells you the tool is not an antivirus. The version history is also worth scanning, because it shows the direction of travel. The 2022 version added the base emergency response features, 2023 added open ports and server status, 2024 added backdoor oriented updates and automated threat discovery, 2025 added CVE identification and HTTP service probing, and September 2026 brought the Rust rewrite. Contributors are credited with a vulnerability number, WHOK-ID, and a knowledge base wiki is maintained for the manual investigation points that the tool does not cover.

Editorial conclusion

Adopt Whoamifuck when you arrive at a Linux host you do not trust and need a broad first pass of evidence, because it gathers login history, running services, open ports, persistence and backdoor indicators in a single run rather than one command at a time. Do not treat its output as a verdict, since it reports indicators and known CVE exposure rather than proving a compromise. Verify first that you run it with root, since the documentation says it needs root to get complete information and otherwise produces unexpected errors, that the log paths it inspects match the distribution you are on, and that you capture a copy of the output before the system is changed.

Frequently asked questions

Official sources

1. enomothem/Whoamifuck on GitHub
2. Issues
3. Project website
4. README
5. Releases