一个做运维的木马下朋友上周发来截图，服务器CPU飙到400%，木马下top命令里躺着一个叫`byshell`的木马下进程，路径指向`/tmp/.byshell`。木马下他以为是木马下挖矿，杀掉进程、木马下删掉文件，木马下重启后一切正常。木马下两天后，木马下同样的木马下事情又来了。这次他学乖了，木马下没有急着动手，木马下先抓了`/proc//exe`的木马下软链接，又用`lsof`看了下这个进程打开的木马下文件句柄——结果发现它正往一个境外IP的443端口传东西，流量不大，木马下但很规律。

这就是byshell木马的典型行为。它不是那种一上来就狂扫内网、加密文件的勒索软件，它更像一个安静的后门。你很难在`ps aux`里一眼认出它，因为它的进程名经常伪装成`[kworker/0:1]`、`[rcu_sched]`这类内核线程的格式，或者干脆叫`systemd-helper`。文件名也随机，`byshell`只是其中一个变种的名字，有的叫`bydrv`，有的叫`.x`，还有的干脆就是一段乱码。

下载环节是它最关键的步骤。byshell本身只是个几十KB的dropper，真正的恶意载荷——通常是XMRig挖矿程序或者一个反向shell——需要从C2服务器拉取。我抓过一次完整的下载过程：木马先请求一个看起来像正常CDN的域名，URL路径里带着`?id=xxx&v=2`这样的参数，返回的却是一段base64编码的shell脚本。脚本解码后，用`wget`或`curl`从另一个IP下载真正的二进制文件，存到`/dev/shm`或`/var/tmp`下面，然后`chmod +x`并执行。

有意思的是，它下载的时机很讲究。很多byshell变种会检测系统负载，如果`uptime`显示当前负载已经很高，它会等一段时间再下载，避免被运维人员发现异常。还有的会检测`/proc/net/tcp`里有没有安全软件的连接，如果有，就暂停下载。这种“低调”策略让它在一些服务器上潜伏了几个月都没被发现。

传播途径方面，byshell主要靠三个口子进来。一是Redis未授权访问，攻击者直接写crontab或者写SSH公钥，然后从里面拉byshell。二是Confluence、Jenkins这类应用的已知RCE漏洞，打进来之后先落地一个webshell，再用webshell下载byshell做持久化。三是弱口令SSH爆破，成功后用`scp`把木马传上去。我见过一个案例，攻击者甚至没用任何漏洞，就是靠一个`admin/admin`的SSH账号，把byshell塞进了`~/.config/systemd/user/`下面，伪装成一个用户级systemd服务。

持久化手段也值得说。除了常见的crontab和systemd，byshell还会用`LD_PRELOAD`劫持。它把恶意so文件路径写进`/etc/ld.so.preload`，这样任何动态链接的程序启动时都会先加载它的代码。你`ls`、`cat`、`ps`看到的输出可能都是被篡改过的——比如`ps`里看不到它的进程，`ls`里看不到它的文件。这种rootkit级别的隐藏，单靠`top`和`ps`根本发现不了。

清理byshell不能只删文件。我那个朋友第二次中招后，我让他做了几件事：先用`rpm -Va`或`debsums`校验系统关键文件是否被替换，然后检查`/etc/ld.so.preload`和所有用户的`crontab`，再看`systemctl list-units --type=service`里有没有可疑的服务名。最后从干净的系统里拷贝一份`ps`、`netstat`、`ls`的静态编译版本，用这些工具去查，才把隐藏的进程和网络连接揪出来。整个过程花了三个多小时，而攻击者重新下载byshell只需要几秒钟。

说到底，byshell这类木马拼的不是技术多高深，而是谁更耐心。它不急着变现，先蹲着，等你放松警惕。你删了它，它换个路径再来。真正有效的防御不是装个杀软就完事，而是把Redis绑回127.0.0.1、把SSH密码换成密钥、把Confluence升级到最新版。这些老生常谈的事，做到位了，byshell连门都进不来。

(责任编辑：热点)