一台没打补丁的扫描服务器，凌晨三点被传了个12KB的扫描PHP文件。文件名伪装成缓存配置，扫描里面藏着三段异或加密的扫描代码。三天后，扫描它开始向境外IP发送数据库连接凭证。扫描这种事每天都在发生，扫描而webshell扫描器就是扫描用来在几十万个文件里揪出这几KB恶意代码的工具。

webshell的扫描本质是一段能在服务器上执行命令的脚本。PHP、扫描JSP、扫描ASPX，扫描甚至Python都行。扫描攻击者通过文件上传漏洞、扫描SQL注入或者弱口令把它塞进Web目录，扫描然后就能像操作自己电脑一样控制服务器。扫描器要做的，就是在海量正常业务代码中识别出这些"披着羊皮的狼"。

最直接的办法是特征匹配。把已知webshell的代码片段做成规则库，扫描时逐文件比对。比如PHP里出现eval($_POST['cmd'])这种典型模式，基本可以判定有问题。但攻击者不傻，他们会用base64_decode嵌套、字符串拼接、变量函数调用等方式绕过。我见过一个样本，把assert拆成$a='as';$b='sert';$c=$a.$b;，静态规则直接失效。

所以好的扫描器得做语法分析。用PHP的tokenizer把文件解析成token流，追踪变量赋值和函数调用链。当发现用户输入经过简单拼接后流入system或preg_replace的/e修饰符，就触发告警。这比正则匹配准得多，但实现复杂，而且不同语言要写不同解析器。

动态检测是另一条路。把可疑文件扔进沙箱，模拟HTTP请求触发执行，监控系统调用和网络连接。之前分析一个JSP webshell，静态看只是普通的文件操作类，动态跑起来才发现它会连接C2服务器拉取指令。缺点也明显——慢，而且有些webshell带环境检测，发现不是真实服务器就装死。

实际部署时，扫描器通常分三层。第一层快速过滤，用YARA规则扫一遍，把明显干净的文件排除。第二层对剩余文件做AST分析，标记可疑调用链。第三层把高风险文件送进沙箱或人工审计。这样能把误报率压到可接受范围。某电商平台的安全团队告诉我，他们30万文件的全量扫描从最初的4小时优化到18分钟，靠的就是这种分层策略。

误报是个绕不开的坑。很多正常业务代码也会用eval，比如模板引擎、动态配置加载。扫描器如果一刀切，运维能把安全部门骂死。解决办法是建立白名单机制，对已知业务路径和文件哈希放行。但白名单本身要维护，业务一更新就得同步，否则要么漏报要么误报。

还有个容易被忽略的点：扫描器自己也可能被利用。如果扫描器以高权限运行，且对扫描目标没有做路径限制，攻击者可以构造特殊文件名或符号链接，让扫描器读取敏感文件甚至执行命令。2021年某开源扫描器就爆过这种漏洞，CVE编号我记不清了，但教训很直接——安全工具自身的安全性同样重要。

写一个能用的webshell扫描器不难，难的是在检出率、误报率和性能之间找到平衡。我的建议是：别追求100%检出，先保证0误报。误报一次，运维就不信你了，后面推行安全措施全是阻力。检出率可以慢慢迭代规则和模型，信任一旦丢了就很难捡回来。

最后说个观察。现在很多webshell已经不走文件落地这条路了，直接内存马，利用反序列化漏洞注入Filter或Listener。传统文件扫描器根本看不到。攻防在进化，扫描器也得跟着变——从扫文件转向扫内存、扫流量、扫行为。工具是死的，思路得活。