LinPEAS Tutorial: 9 Smart Checks for Linux Security

LinPEAS is a Linux local-enumeration script from the PEASS-ng suite. It examines system details, privileged files, user permissions, services and configurations for conditions that might permit privilege escalation. It does not automatically compromise a host, and a colorful warning is not evidence that an exploit works. This LinPEAS tutorial explains nine safe steps for an authorized Linux lab: prepare the system, obtain the script, select limited checks, read the results, verify suspicious settings and document fixes.

If you run Kali or Parrot OS inside VMware, the right goal is a repeatable review rather than an impressive terminal screenshot. A SUID binary may be required for normal operation, while an unremarkable-looking directory might have dangerously broad permissions. A version string might also look vulnerable even though the vendor has backported a fix. Context matters more than decoration.

The examples here are recommended procedures, not new results from a completed personal benchmark. Use them only on a machine you own or have explicit permission to audit. No step attempts to break into an account, run a privilege-escalation exploit or discover unrelated hosts.

What to review	Possible warning	How to verify
User rights	Unexpected group or sudo scope	Compare with approved policy
Privileged files	SUID or capability concerns	Check owner and actual role
Services and jobs	Writable privileged path	Inspect service and file ownership
Installed software	Potentially affected version	Read vendor security evidence

Key Takeaways

• Enumeration finds leads: suspicious output still requires manual confirmation.
• Begin with limited categories: broad optional scans can go beyond a beginner’s scope.
• Keep the report private: local checks may expose usernames and sensitive configuration.
• Verify the real boundary: privilege escalation depends on actual permissions and prerequisites.
• Finish with a fix: record the change and retest the affected condition.

1. Set a Clear Lab Scope Before LinPEAS

Start with a disposable Linux virtual machine and a written permission boundary. Record the VM name, purpose, system owner, network attachment, intended test account and snapshot. A standard non-root account usually provides a more useful first view of ordinary user rights than an administrative session. If the target is a customer machine, the agreement should specify whether scripts may be executed and whether local reports can be retained.

In VMware, inspect each virtual adapter. Host-only networking can help isolate a guest, but the label does not prove that host sharing, a bridge or another route is absent. Intentionally vulnerable systems must not be accessible from the public internet. Keep unrelated machines, personal data and production credentials out of this exercise.

Agree on excluded directories and stop conditions before running the script. Some audits permit account information but not secret searches or service interrogation. LinPEAS has optional modes that do substantially more than basic enumeration, so “I have a shell” is not a substitute for authorization.

For lab architecture, the Metasploitable 2 tutorial explains the discipline of keeping a vulnerable Linux guest contained. That guide offers context for the environment; I am not claiming to have measured the current script on that specific VM.

Metasploitable 2 Tutorial: Set Up a Safe Lab

Metasploitable 2 Tutorial: Set Up a Safe Lab

Collect a baseline as a standard user

Before LinPEAS labels anything suspicious, identify your account and operating system. These commands read basic local information. Keep the output in private lab notes with the VM identifier and approximate test time.

whoami
id
uname -r
cat /etc/os-release

The baseline matters when you investigate a later alert. A Linux package, account or kernel may change between snapshots. If you cannot establish what you actually tested, the final severity rating becomes a guess.

2. Understand What LinPEAS Detects

LinPEAS means Linux Privilege Escalation Awesome Script. It belongs to PEASS-ng, which also contains platform-specific enumeration tools. LinPEAS output may include information about users and groups, privileged binaries, service configurations, scheduled tasks, installed software and the local kernel. The exact checks vary by script version and options.

Privilege escalation is not the same thing as initial access. The first concerns rights an existing account should not have; the second concerns how someone enters the system. This tool does not prove the machine can be reached remotely or that an attacker has obtained any account. It helps you ask whether local permissions deserve closer investigation.

The MITRE ATT&CK knowledge base provides a broader description of adversary techniques and defensive concepts. A privileged service being present is not the same finding as an unauthorized user being able to influence its execution. Write conclusions at the level the evidence actually supports.

A LinPEAS check may be incomplete because the running account cannot read a particular location. That is not a passing result. Likewise, a root-owned file is not a flaw simply because the script highlights it. A careful audit guide must distinguish observations, hypotheses and independently confirmed weaknesses.

3. Install LinPEAS From a Trusted Source

Kali currently documents the peass package, which provides a linpeas launcher and associated script files. Check your package sources rather than guessing a package name from an old screenshot. On a supported Kali guest, use the normal package manager:

apt-cache policy peass
sudo apt update
sudo apt install peass
linpeas -h

The last line requests local help; it is not an audit. Kali’s documentation currently lists the scripts in /usr/share/peass/linpeas/. If that directory is missing on your installation, check dpkg -L peass before changing anything. The official Kali Linux homepage is the appropriate starting point for its package and tool documentation.

Parrot OS may package the project differently. Inspect its repositories and available command help rather than assuming every Kali path works unchanged. When a package is unavailable, use the verified PEASS-ng upstream release, inspect the file and keep its origin or checksum in your audit record. A random reposted shell script with the same name is not a trustworthy substitute.

Avoid directly piping an online download into a shell. Download and inspect executable code before running it in a disposable VM. The checksum of your local file helps you identify the version used, although it proves authenticity only when compared with a trustworthy publisher reference.

Check the installed script before execution

umask 077
mkdir -p ~/linpeas-lab
chmod 700 ~/linpeas-lab
cd ~/linpeas-lab
cp /usr/share/peass/linpeas/linpeas.sh ./linpeas.sh
sha256sum linpeas.sh
sh ./linpeas.sh -h

The copy command assumes Kali’s documented package layout and that peass installed correctly. If not, find the approved local source instead of forcing the example to run. The installed LinPEAS help output is more reliable than an option copied from a much older tutorial.

My Kali Linux tools tutorial explains how to make the rest of your toolkit understandable before adding more commands to a lab.

Kali Linux Tools Tutorial: 9 Tools Beginners Should Learn First

Kali Linux Tools Tutorial: 9 Tools Beginners Should Learn First

4. Choose Limited LinPEAS Checks

LinPEAS supports -o to select specific check categories. For a first authorized experiment, start with system_information and users_information. Review the supported arguments in your local help before running the example.

cd ~/linpeas-lab
sh ./linpeas.sh -o system_information,users_information

This limits the exercise to system and user information instead of requesting every optional feature. Basic enumeration can still access internal data and consume resources, so run it only on your disposable machine. Record the exact categories you selected. A statement such as “no dangerous service permissions were found” is not supported if you never examined services.

A key warning: the upstream PEASS-ng documentation explains that -a can add password attempts against local users, while -r searches more broadly for credential-like patterns. Other flags can perform active network checks. Those options are deliberately excluded from this introductory LinPEAS workflow. They require distinct authorization and more detailed risk assessment.

If you later need to inspect a service, choose only the appropriate documented category, and check whether the module performs side effects or reads restricted files. Increasing the scope simply to get a more dramatic report makes troubleshooting harder and may exceed your permission.

What a limited result does not tell you

Suppose the selected categories show ordinary account data and no urgent warning. That only describes what those checks observed for that account at that moment. It does not establish that scheduled tasks, confidential files or privileged executables are secure. Narrow commands need equally narrow conclusions.

5. Save the Report Without Creating a Leak

An audit report can include usernames, paths, group memberships, service details and other internal information. Treat it as sensitive security evidence. Do not save it inside a public website directory, a synced personal folder or a shared terminal transcript. Never post raw output to an open forum for interpretation.

In your lab, use a restrictive umask and separate the ordinary output from errors. The supported -N option disables colors so the file is easier to inspect and redact. This procedure writes local log files even if the default enumeration itself avoids writing them.

umask 077
cd ~/linpeas-lab
sh ./linpeas.sh -o system_information,users_information -N \
  > audit-basic.txt 2> audit-errors.txt
chmod 600 audit-basic.txt audit-errors.txt
wc -l audit-basic.txt

An error can mean a missing utility or insufficient permissions, not that the system is compromised. Check which module failed and label the result as incomplete if necessary. Record the tool version, selected modules, date and executing account so someone else can understand the evidence.

If the report unexpectedly contains credentials, redact them before sharing anything and consult the owner about appropriate rotation. Good security work should not create a second, less protected copy of the secret it discovered.

HackersGhost Note:
I prefer a short report whose boundaries I can explain. A huge colorful transcript with no account, version or scope information is not much help when you need to make a responsible fix.

6. Interpret LinPEAS Warnings Correctly

LinPEAS emphasizes candidate problems through color and headings. Those highlights help triage, but they are not a verified severity assessment. A privileged binary may be part of normal administration; a stale-looking version number may include a vendor backport; and an apparent writable path may not actually be writable by the account in question.

Write each clue as an observation first. Identify the user, object, host and permission. Then ask whether the affected configuration is intentional and whether a less privileged identity can really influence a privileged operation. Do not classify a machine as compromised because a line appears in red.

Useful triage has five parts. Record the redacted observation, the intended role of the file or service, a read-only validation step, the impact supported by that step and the owner of any proposed change. This keeps a LinPEAS warning from becoming an unsupported claim.

• Observed: what did the script actually report?
• Expected: what does the system owner say should be configured?
• Verified: which read-only check establishes the real condition?
• Impact: what would an unauthorized account plausibly gain?
• Action: what can be changed safely, and how will you retest?

It is entirely legitimate to label a finding “needs investigation” when the prerequisites are unknown. Likewise, a false positive should be documented rather than quietly discarded; the reasoning matters if it appears again after an update.

7. Verify Privileged Files and Service Paths

Local Linux reviews commonly examine SUID and SGID permissions, capabilities, sudo delegation, service units and scheduled tasks. An enumeration finding about one of these areas is an invitation to inspect the actual configuration—not to run a command that tries to gain a root shell.

Begin with explicit, authorized paths and simple metadata checks. The following commands reveal the owner and mode of conventional system paths plus the groups assigned to the current account. They do not change the machine.

stat -c '%U %G %a %n' /etc/passwd
stat -c '%U %G %a %n' /etc/cron.d
id -nG

Compare the result with distribution defaults and the system’s approved role design. For a particular systemd service flagged by the script, an administrator can inspect its unit file and the permissions of the executable it invokes. Do not guess a service name or trigger a privileged job in the name of “verification.”

Parent directories deserve attention. Even when an executable is root-owned, a loosely controlled parent directory may permit replacement or modification through a different path. Fixing an individual file without understanding its deployment process can leave the real problem in place.

Do not blindly remove every privileged bit or disable scheduled jobs. Legitimate programs depend on some of these features. The right remediation is the narrowest documented change that removes unintended influence while preserving required system function.

8. Validate Kernel and Software Leads Against Advisories

A script hint about a vulnerable kernel or package is not proof that the host is exploitable. Linux distributions often apply fixes through vendor-maintained branches, and backported patches may not resemble upstream version numbers. Build options, mitigation settings and access prerequisites can also change the result.

Record the full distribution and kernel release first. Compare the actual affected package with a current vendor security advisory. The following commands are read-only and available on typical Linux guests:

uname -r
cat /etc/os-release

The information tells you where to begin, not which CVE definitely applies. A vendor package changelog and its fixed-build information may matter more than a generic version comparison. If an alert concerns a container or cloud capability, verify that your target actually has that platform and boundary.

Avoid downloading exploit proof-of-concepts on a production system merely to validate a scanner suggestion. If the affected conditions are confirmed, favor supported updates, disabling an unnecessary feature or applying a documented mitigation. Retest the relevant configuration after the approved change.

A clean-looking scan after remediation is useful evidence but can also mean a check was skipped. Compare both reports with the same account and selected modules where possible. That is how a script alert becomes a meaningful, reproducible finding.

9. Remediate and Retest One Finding at a Time

A security assessment is finished when observations lead to informed decisions. Separate confirmed weaknesses, hardening opportunities, harmless information and items that could not be verified. Every genuine issue should have an owner, its affected component, the intended policy and a clear retest.

Excessive permissions may need narrower group access or a corrected deployment process. A privileged helper may need a safer execution path. Outdated packages may need supported updates. Sensitive data in an inappropriate location may require careful storage changes and rotation. There is no universal command that makes every LinPEAS alert disappear safely.

Retest the same item, ideally using the same ordinary account and selected checks. Document the original condition, approved change and new evidence. If the warning disappears only because you changed accounts or lost read access, you have not necessarily removed the weakness.

HackersGhost Note:
The result I value is a change I can explain tomorrow: which permission or setting was wrong, why it mattered and what a later check showed. A quieter scanner is not enough by itself.

The Red Team vs Blue Team lab setup provides complementary context for turning one-off investigations into defensive habits. A useful lab teaches verification, not just discovery.

Red Team vs Blue Team Lab Setup at Home

Red Team vs Blue Team Lab Setup at Home

Four Mistakes to Avoid With LinPEAS

The first mistake is assuming a highlighted line proves escalation. The second is turning on every optional mode because a screenshot looks more impressive that way. More intrusive checks can include password attempts or network operations that were never agreed.

The third is running a similarly named script from an unverified source. Obtain a trusted build, inspect it, and record its identity. The fourth is sharing raw output that contains internal machine details. Redaction and proper storage are part of the technical work, not administrative decoration.

Finally, remember that a limited LinPEAS run can be perfectly useful. It becomes misleading only when the report pretends the unchecked parts of the host were also evaluated.

LinPEAS Tutorial FAQ

Conclusion: Make LinPEAS Clues Actionable

The strongest LinPEAS tutorial is not one that fills the screen with red text. It is one that identifies who ran the checks, what was in scope, which observations are credible, and how a fix improves a real security boundary. A careful audit can produce useful defensive findings without attempting privilege escalation.

Start with a disposable Linux VM and an ordinary account. Obtain the trusted script, run only the relevant information checks, verify one result manually and write down what remains unknown. Expand your audit only when permission and purpose justify it. That turns LinPEAS into a useful part of a repeatable security workflow.