linux-smart-enumeration (lse): a graduated Linux enumeration script for pentesting and CTFs

What lse solves, and who it is for

A Linux box you have just landed on gives you a shell and very little else. The question is not whether there are misconfigurations; it is which of them matter for privilege escalation, and in what order to look. lse exists to answer that ordering question. It is a shell script that reports security-relevant information about the local system, and the README states it was inspired by LinEnum and reuses many of its tests. The difference the author draws is explicit: unlike LinEnum, lse "tries to gradualy expose the information depending on its importance from a privesc point of view."

That design choice sets the audience. Pentesters working an engagement, CTF players, and people studying for certifications where local enumeration is a graded step. The repository topics list ctfs, hackthebox, oscp, pentesting and privilege-escalation, which is a fair description of who the tool is written for. It is not a hardening tool, it does not remediate anything, and it produces no report you would hand to a compliance auditor. It is a reconnaissance script that you run, read, and then discard from the target.

The practical consequence of the graduated design is that the default run is quiet on purpose. You get the findings the author considers high-confidence first, and you escalate the noise level yourself only when the first pass comes back empty. That is a workflow, not just a flag.

How the verbosity levels and test selection actually work

The mechanism is a single script, lse.sh, that runs a set of named tests and filters their output by level. Level 0 is the default and shows what the README calls highly important results. Level 1 adds interesting information that should help with privilege escalation. Level 2 dumps everything the script gathers. The README's own advice for level 2 is to pipe it through a pager, because the volume is high.

The second mechanism is selection. The -s flag takes a comma-separated list of sections or individual test IDs, and the README gives the example ./lse.sh -l2 -s usr010,net,pro, which runs the single test usr010 plus every test in the net and pro sections. The available sections are usr, sud, fst, sys, sec, ret, net, srv, pro, sof, ctn and cve, covering users, sudo, the file system, the system, security measures, recurring tasks, networking, services, processes, software, containers and CVEs. Selection is the lever that keeps a run fast on a large host: you can skip whole areas you have already cleared.

The third mechanism is the process monitor. The script watches for recurring program executions while it runs the other tests, so the observation happens in parallel with the rest of the work rather than as a separate wait. The default watch is 60 seconds and -p changes it, with a value of 0 disabling the watch entirely. That default is a real constraint. A cron job that fires every five minutes will not appear in a one-minute window, and the README does not claim otherwise.

There is also a -S flag, present since version 2.10, that serves the script from the current host so a remote host can retrieve it. And by default the script is interactive and asks questions, mainly for the current user's password if you know it, so it can run additional tests; -i turns that off.

Installing lse and running a first pass

There is no package manager step and no build. The README's install path is to download the release artifact and make it executable. Either of these two oneliners does that, and both write the script to lse.sh in the current directory:

wget "https://github.com/diego-treitos/linux-smart-enumeration/releases/latest/download/lse.sh" -O lse.sh;chmod 700 lse.sh

curl "https://github.com/diego-treitos/linux-smart-enumeration/releases/latest/download/lse.sh" -Lo lse.sh;chmod 700 lse.sh

After either one, ls should show an lse.sh file with mode 700. Run the default level first, exactly as the README describes:

./lse.sh

The README says that if you see some green yes! lines you probably already have good material to work with. If the output is thin, move up a level:

./lse.sh -l1

And if that still gives nothing useful, dump everything and page through it:

./lse.sh -l2 | less -r

When you want to run the script without writing it to disk on the target, the README gives this direct execution form, which streams the release artifact into bash and passes -l2 and -i, the non-interactive flag:

bash <(curl -s "https://github.com/diego-treitos/linux-smart-enumeration/releases/latest/download/lse.sh") -l2 -i

For a narrower run, pass a selection. This executes test usr010 and every test in the net and pro sections at level 2:

./lse.sh -l2 -s usr010,net,pro

The full option list, as the README prints it, includes -c to disable color, -i for non-interactive mode, -h for help, -l for the level, -s for selection, -e for a comma-separated list of paths to exclude, -p for the process watch time in seconds, and -S to serve the script to another host. The -e flag is worth noticing: excluding paths makes scans faster at the cost of completeness, which is the trade-off the README states plainly.

The process watch window is the limitation to plan around

The most consequential limitation is the one the defaults hide. The process monitor runs for 60 seconds unless you change it with -p, and it watches while the other tests execute. That means the tool's view of recurring execution is a sample, not a census. A backup script, a package manager timer, or a maintenance job that runs every ten minutes is invisible in a 60-second window. Raising -p to a longer value widens the sample but also lengthens the run, and the README does not offer a way to derive the right window from the system; you have to decide it from what you already suspect about the host.

A second limitation is the selection model itself. Because -s lets you skip sections, a narrow run can produce a confident-looking empty result that only means you did not look. The same applies to -e: excluding paths is explicitly a speed-for-completeness trade, and the README says so.

A third is the interactive default. Out of the box the script asks for the current user's password so it can run additional tests. On an engagement where you do not have the password, or where you do not want to type credentials into a script you downloaded minutes ago, you should pass -i. The README presents the questions as optional in practice rather than describing what happens if you decline, so treat -i as the expected flag for unattended runs.

Finally, lse is a discovery aid. It reports what it finds; it does not tell you which finding is exploitable on this particular kernel and distribution, and it does not remediate. If you need a signed, versioned audit artifact rather than a shell script you read once, this is the wrong tool.

lse against LinEnum and LinPEAS

The README names its lineage directly: lse was inspired by LinEnum and uses many of LinEnum's tests. That makes LinEnum the most honest comparison, because the overlap is large and the difference is in presentation. LinEnum runs its checks and prints them; the operator sorts the signal from the noise afterwards. lse builds the sorting into the tool through the three verbosity levels, so the default run is an opinionated shortlist rather than a transcript. If you already know exactly which LinEnum checks you care about, LinEnum's flatter output is not a disadvantage. If you want the tool to make a first pass at triage for you, that is the specific thing lse adds.

The other comparison people reach for is LinPEAS, which appears in the related searches alongside lse. The documentation here describes lse only, so the honest statement is that both are local enumeration scripts aimed at privilege escalation discovery, and that lse's distinguishing feature as documented is the graduated level system plus the ability to select tests and sections by ID. Whether LinPEAS is faster or finds more is not something this repository's documentation answers, and any claim to that effect would need its own evidence.

Two adjacent tools are worth knowing for different reasons. GTFOBins is a reference for abusing binaries that are already on the box, which is what you consult after lse points you at an interesting binary; it is not an enumeration script. Linuxprivchecker sits in the same family as LinEnum and lse. The useful framing is that lse tells you where to look, and references like GTFOBins tell you what to do once you are looking there.

Licence, maintenance and upgrade cost

lse is licensed GPL-3.0. For the common case of running the script against a target during an assessment, that is unremarkable. The obligation to think about is redistribution: if you bundle lse.sh into an internal toolkit, a training image, or a product you ship, GPL-3.0's copyleft terms apply to that distribution, and the repository's LICENSE file is the authoritative text. This is a description of the licence, not legal advice; if you are redistributing it commercially, have someone qualified read the licence.

The maintenance picture is mixed and worth stating precisely. The last push to the repository was on 2026-05-03, which is recent. The most recent release listed is 4.14nw from 2023-12-23, preceded by 4.13nw in August 2023 and 4.12nw in June 2023. So commits are landing on master while the tagged releases are older. That gap matters for how you install it: the download oneliners in the README point at releases/latest/download/lse.sh, which resolves to the latest tagged release, not to master. If you want whatever is on master, you have to fetch lse.sh from the branch explicitly, and you should expect it to be less exercised than a tagged release.

Upgrade cost is low by construction. There is one script, no dependencies to resolve, and no configuration file to migrate. Upgrading means downloading a newer lse.sh and re-running it. The cost is not in the upgrade mechanics; it is in re-checking that a newer release still behaves the way your notes and your team's playbook assume, particularly around the default watch time and the level thresholds.

Reading a run without over-trusting it

The README's own recommended loop is the right mental model. Start at level 0 and look for the green yes! markers, which the author treats as the signal that you already have something to work with. Only if that comes back empty do you move to level 1, and only after that to level 2. Each step is a deliberate widening of the aperture, and each step costs you more reading time.

The trap is treating a clean level 0 as a clean system. It is not. It means the tests the script ran, at that level, on that host, found nothing it classifies as highly important. A clean result can come from a genuinely hardened box or from a run that skipped sections with -s, excluded paths with -e, or watched processes for a window too short to catch the job that matters. When you write up a negative result, the flags you passed are part of the finding.

One more practical note from the README: level 2 output is large enough that the author suggests piping it to less -r. If you are capturing output for later, that is the point at which you should be thinking about where the file lands on the target and whether you want it there at all.

Editorial conclusion

Adopt lse if you are on an engagement or a CTF box and want a small, readable shell script that surfaces privilege escalation leads in a controlled order; the graduated verbosity and the -s test selection are the reasons to pick it over a tool that dumps everything at once. Do not adopt it as a compliance scanner or as a substitute for reading the system yourself: it is a discovery aid, and the README does not document rollback, remediation or a machine-readable report format. Before you rely on it, verify three things on the target: that the shell it runs under is POSIX-compatible enough for the tests you select, that the process watch window from -p is long enough to capture the recurring jobs you care about, and that the release you downloaded is the one whose lse.sh you actually executed.

Frequently asked questions

Official sources

1. diego-treitos/linux-smart-enumeration on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases