Why a one-line find command is a post-compromise goldmine
Linux收集信息小脚本
This note looks at a very short piece of shell, the kind an attacker might run within seconds of landing on a Linux box. The idea behind it is simple: once a shell is open, the next useful step is rarely another exploit. It is finding out what is already lying around on the filesystem.
The idea, not the script
The technique is a filesystem sweep built on a standard find command, scoped to pick up configuration files, interpreter scripts, and anything with "history" or "pass" in its name, while skipping noisy system paths such as /usr/share. The results get bundled into a single archive for later review, off the box, at leisure.
The reason this matters is that most Linux hosts accumulate exactly this kind of residue over their working life: application config files with database credentials in plain text, shell history files with commands that embed passwords, forgotten backup copies, and leftover deployment scripts. None of it requires a vulnerability. It only requires file permissions that are looser than they should be, which is the normal state of a server nobody has audited recently.
Why this is a post-exploitation step, not an exploit
It is worth being precise about what this technique is and is not. It does not grant access. It assumes access already exists, through a vulnerable application, a weak password, or a misconfigured service, and it answers the next question an intruder asks: what can this access be turned into. A single exposed database password found this way is often worth more than the original foothold.
What defenders should take from it
The defence is mostly filesystem hygiene rather than a patch. Configuration files that must contain secrets should be owned by the service account that needs them and set unreadable to everyone else, not left world-readable by default. Shell history should not be treated as a safe place to type a password, because it persists in plain text and survives long after the command is forgotten. Backups and deployment scripts should be moved out of web-accessible or world-readable directories once they are no longer needed.
File-integrity and audit tooling that flags unusual read bursts across many files in a short window is a reasonable detection control, since a sweep like this touches far more files far faster than normal interactive use. On systems with sensitive data, restrictive default permissions (a tight umask, and periodic permission audits) do more to blunt this class of technique than any single patch could.
Key takeaways
- Post-exploitation enumeration looks for leftover config, history and backup files, not new vulnerabilities
- Plain-text credentials in config files or shell history are the usual payoff
- Tight file permissions and a sane umask blunt this technique more than patching does
- Unusual bursts of file reads across many directories are a detectable signal
- Treat shell history as persistent, not disposable, when typing anything sensitive
中文摘要
文章讨论的是入侵后在Linux主机上快速收集配置文件、历史记录等敏感文件的思路，而不是漏洞利用本身，防御重点在于文件权限与审计。
This note has been rewritten and checked for this edition; it is not a copy of the original post.