/proc/PID/environ仅显示进程启动时继承的环境变量快照，以 分隔，不反映运行时setenv()等修改；真实来源需追溯PPid、systemd配置或execve调用。
直接看 /proc/PID/environ 能发现什么
它只反映进程启动那一刻继承的环境变量，以 分隔的 KEY=VALUE 形式存在。恶意进程若通过 setenv() 或 putenv() 在运行时动态修改环境，这些变更**不会写回 /proc/PID/environ**——该文件是只读快照，不是运行时视图。
所以你看到的只是“它被谁拉起来时带了哪些变量”，比如是否被 systemd 服务单元注入了 LD_PRELOAD，或是否从父 shell 继承了可疑的 PATH。真正要盯的是“谁给了它这些变量”，而不是“它现在用了哪些”。
怎么定位环境变量的真实来源
不能只查 /proc/PID/environ，必须向上追溯启动链：
- 用
cat /proc/PID/status | grep PPid找父进程 PID；再查那个 PID 的/proc/PPID/exe和/proc/PPID/cmdline，确认父进程是不是合法服务管理器（如/usr/lib/systemd/systemd） - 如果 PPid 是 1，且
/proc/PID/exe指向/tmp/.X11-unix/sshd这类路径，说明它绕过 systemd 直接由 root 启动，/proc/PID/environ里的LD_LIBRARY_PATH很可能来自攻击者手动设置 - 对 systemd 管理的服务，运行
systemctl cat servicename，检查Environment=或EnvironmentFile=配置项——恶意服务常在这里硬编码危险变量 - 用
strings /proc/PID/environ | grep -i "prel|lib|path"快速筛出高危键，如LD_PRELOAD、LD_LIBRARY_PATH、PATH是否包含/dev/shm、/tmp、/var/tmp
常见陷阱：为什么你看到的 environ 不等于实际生效的环境
/proc/PID/environ 是只读快照，但进程运行中可以：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 调用
prctl(PR_SET_MM, ...)修改自身mm_struct，绕过内核对环境变量的原始映射 - 用
setns()进入其他命名空间后，/proc/PID/environ仍显示旧值，但实际getenv()返回的是新空间的变量 - 某些容器运行时（如早期 runc）在 exec 时会覆盖
environ区域，导致/proc/PID/environ和getenv()不一致 -
strace -e trace=execve比看/proc/PID/environ更可靠——它能捕获 execve 系统调用传入的envp数组，这才是真实起点
真正该监控的不是 environ，而是变量如何被注入
靠翻 /proc/PID/environ 排查已存在的恶意进程，效率低且易漏。生产环境应转向主动防御：
- auditd 规则：
-a always,exit -F arch=b64 -S execve -F argc>=2 -k env_injection，捕获所有带非空envp参数的 execve - systemd 服务加固：在
[Service]段加UnsetEnvironment=LD_PRELOAD LD_LIBRARY_PATH，并设SecureBits=keep-caps防止 cap_dac_override 绕过 - 用
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("PID %d CMD %s ENV %s\n", pid, str(args->argv), str(args->envp)); }'实时观察环境变量传递链
记住：/proc/PID/environ 是个静态快照，它不告诉你“谁改的”，也不记录“何时改的”。真要溯源注入点，得盯住 execve 调用和 systemd 单元定义，而不是反复 tr ' ' '
' 。
