我所理解的马

前言

对于马，我觉得很多人都应该觉得这是一种神奇的东西。以前没怎么接触时，我也这样觉得，觉得木马，木马和安全软件之间的对抗好神奇！转眼已毕业接近两年，两年的工作经历里，逐渐接触和学习了关于马，漏洞，渗透测试相关的一些知识。神奇的感觉已不在，但觉得一些东西可以说一说，或深或浅，或多或少，说一说。

嗯，在正式开始之前，我想说，以下内容，纯属扯淡，如有雷同，纯属巧合。

我所理解的马

对于马，我觉得首先我们可以认为它是一个普通的远控软件，它和那些正规的远控软件并没有什么大的差别。这些正规的远控软件开发中用到的技术，需要考虑的问题，马的开发者也会用到，也需要考虑。而且事实就是这样。只不过，马的开发者需要在一个正规远控软件的基础上加上一些额外的东西，可以说正是这些额外的东西让马成为了马。下面是我基于自己的认识对这些东西简单的一个总结：

1. 提权
2. 自启动
3. 通信协议
4. 过代理

下面我们会分别对这些东西进行讨论。在讨论这些东西的过程中，我的思路依旧是尽量的结合具体实例(如果我可以的话)，这样做一方面是因为空谈理论效果并不好；另一方面也是因为一些内容本身就是一个比较宽泛的定义，具体实例给了我们一个边界。

提权

这里我们的实例是这样的，我们现在有这样一个马，它需要做如下操作：

• 创建并写文件到系统的 System32 目录下
• 创建一个服务来实现自启动

然后这个马面临的使用情景是这样的：

• 用户以管理员账户登录系统
• 这个马并不会和提权漏洞或具有管理员及更高权限的进程中存在的可执行任意代码漏洞结合使用（也就是说，如果这个马需要管理员或者更高权限，它需要自己解决）

最后，我们要求在这个马的安装过程中，系统不能弹出任何对话框和这个马相关的对话框。

那现在我的问题就是，作为马的开发者，在 Windows XP 下我们需要处理提权相关的问题吗？在 Windows Vista 下呢？在 Windows 7 下呢？如果需要，那有没有相应的解决方案呢？如果有，这个解决方案有没有什么限制呢？

下面就让我们回答这些问题。在继续往下看之前，大家也可以自己先思考下这些问题，算是做一个评估自己对 Windows 安全体系的理解程度的小测试吧。

首先，我想说是上面提到的这种情况，并不是凭空写的，可以说大多数马都会遇到这样类似的需求和使用情景。所以，上面这些问题就是在马的实际开发过程中需要考虑的。

第一个问题，在 Windows XP 下，马的开发者需要考虑提权的问题吗？答案是否。因为我们面临的使用情景是用户已经以管理员账户登录系统，而在 Windows XP 下，拥有管理员权限就意味这你可以做任何事。下面是 Windows XP 下用户以管理员账户登陆系统后 explorer.exe 进程的令牌及 Administrators 用户组对 System32 目录和 HKLM\System\CurrentSet\Services 注册表键的权限，就像之前说的那样，你可以做任何事。也许你会感到惊讶，但在用户已经以管理员账户登录系统的前提下，Windows XP 就是这么不安全。然而这却是用户最常用的使用 Windows 的方式。

第二个问题，Windows 7 呢？答案是是，即使在用户已经以管理员账户登录系统的前提下。Why？因为 Microsoft 从 Windows Vista 开始引入了一些新技术和新机制，这其中有一个叫 UAC 的东西让我们有了这个需求。这里简单介绍下 UAC，在 Windows XP 下，在用户以管理员账户登录系统后，用户创建的进程通常都具有管理员权限，但 UAC 改变了这一点。在 Windows 7 下，即使用户以管理员账户登录系统，他创建的进程默认也不拥有管理员权限。下面是 Windows 7 下用户以管理员账户登陆系统后，explorer.exe 进程的令牌。

然后，如果一个进程需要以管理员权限启动，通常系统都会弹一个框来询问用户是否允许该进程启动，就像下面这样。

这样，对于马当然就是一个麻烦，至少在上面我们提出的需求中，我们要求马在安装过程中系统不能弹任何和马相关的框。

那如何解决这个问题？答案依然在 UAC 本身。Microsoft 从 Windows 7 开始，在 UAC 中新引入了一种叫做自动权限提升的机制，该机制允许用户在运行一些需要管理员权限的进程时，系统不弹出 UAC 对话框。而解决这个问题的基本思路就是利用这些 Windows 允许自动提升权限的进程做马中需要管理员权限做的操作。比如，在 13 年的 SyScan360 上，韩海源的一位大哥就提出了这样一种思路；另外一种公开的思路就注入满足自动权限提升要求的的进程，然后调用允许自动提升权限的 Com 组件来做马中需要管理员权限的操作。虽然说上述两种方法在具体实现上稍有不同，但正如我们之前所说，他们的基本思路是一致的。而且，目前并没有见到突破 UAC 的其他思路。有的话，哪位大神可以科普下。

那这种思路存在限制吗？答案是是。在 Windows 7 下存在一个 UAC 等级的东西，如下图所示：

可以通过设置不同的 UAC 等级来决定在运行需要管理员权限的进程时， Windows 在什么情况下弹出 UAC 对话框。如果我们把这个等级调到最高，那 Windows 将总是弹出 UAC 对话框，而这个最高等级也是 Windows Vista 下的 UAC 的默认等级，所以这里我们可以顺便回答下关于 Windows Vista 的问题，答案很简单，Windows Vista 下需要提权，但是没有解决方案。

上面就是这里我们要讨论的关于提权的所有东西。不过放开来讲，对于马来说，它需要做的哪些事情，具有哪些特性都是看实际环境和需求。比如提权，上面我们给的实例需要提权，但对于有些马来说，可能又不需要提权，他们所需要做的可能只是伪装成一个充满诱惑的东西，在这种情况下，可以说别说是让用户确认一个对话框，即使是要用户输入用户名密码，用户也会输的。个人觉得，操作系统本身的安全机制是一回事，用户自身的安全意识又是一回事，两者都是需要解决的问题。UAC 机制在某种程度上就是就是对用户习惯的一种妥协，当然它确实也提高了系统的安全性。

自启动

自启动是马需要考虑的另外一件非常重要的事情。马的自启动方式应该说种类、花样繁多，因为我本身见过的马的启动方式并不多，所以这里就不一一列举了，只谈下感受。

首先我觉得，虽然说马的启动方式很多，但他们的基本思路变化并不多，就是利用 Windows 提供的自启动的机制，比如创建服务、写注册表 Run、注册让进程自动加载的 Dll，猥琐一点的，Dll 劫持等。总之，都是有相应的系统机制可以参考的；

另外，我想说的就是关于自启动方式对于马的重要性，选择什么自启动方式对马真的很重要吗？我觉得并不重要，就个人而言，对于自启动，我更关注的是在采用这种自启动时马的免杀效果，在马通过这种自启动方式启动后的相应的功能能否使用及稳定性，而不是采用的自启动方式的猥琐程度，所以说常规的自启动方式如创建服务，写注册表 Run 键并不一定说不好用，相反，在满足上述我提出的需求的前提下，我会优先采用这些常规的方式，简单就是稳定。

通信协议

一切还是从需求说起。如果你的马的目标是一些家庭主机而不是什么政府或大型企业，那你基本就不用考虑什么通信协议的问题，你可以采用 TCP 连接，然后也不用对通信内容做什么加密，就让它们以明文的方式传输就可以了，谁会关心这些呢？谁会监听你的数据呢？只要你保持低调，并不会有人想抓你。但情况并不总是这样，如果现在你的马的目标是政府或者大型企业，那你可能就不得不考虑这些问题了？因为这些主机往往处于重重保护之中，如果你不考虑这些问题，你可能会发现你的马无法回连或正常使用；另外考虑都你做的事情，所以你肯定不想自己被抓。

在之前的工作经历中，对于这些保护措施我并没有怎么接触，也并没有什么深入的理解。因为作为一个小小的开发人员，通常你得到的就是你需要做什么，而不是在额外告诉你为什么需要你这么做。虽然最后我意识到，我可以，也应该多问一句，为什么需要我这么做？但过去的已经过去，我只能在以后的项目中多问这一句了。OK，虽然说不怎么了解这些保护措施，但我觉得还是可以简单说一些我稍稍理解的。下面我们就结合具体的保护措施来说说为什么需要通信协议。

对于企业或者政府，内网中的保护措施最常见的一种就是端口限制和协议限制了，比如在有些内网中，会通过防火墙设置只允许目标端口为 80 的连接外出，并且通信协议必须是 HTTP。在这种情况下，如果你不将你的数据隐藏在 HTTP 请求或应答中，并且模仿正常的 HTTP 通信，那你的马就无法使用，这是一个硬性的需求，你必须解决这个问题。

关于对通信数据加密，你需要知道的是，你面临的不再是没有什么安全意识的和专业技能的普通用户，你面对的是经验丰富的网络管理员和其他相关人员。如果你仍然把你的通信数据不做任何处理直接暴露在网络传输中，那绝对不是一种好的选择。我不知道网络管理员是否会检查主机的流量，但如果他看到了你的马的通信数据，他一定会觉得有些不对劲。另外，流量检测技术在一些针对企业和政府的内网保护软件已经存在，虽然对这项技术不太了解，但如果我是马的开发者，我绝对不会让我的数据裸奔。

OK，上面就是我们关于通信协议的所有内容，正如最开始所说，一切从需求说起。

过代理

这个简单说下。代理应该是企业或政府内网环境的一种常见情况。内网中所有的机器只能通过一台代理服务器来和外界进行通信，某些情况下，还可能需要你输入用户名和密码。如果你的马的目标属于这种情况，那你就需要去解决这个问题，你需要获取代理服务器的地址，甚至还需要获取用于向代理服务器认证的用户名密码或者之类的东西。总之，如果你遇到了这种情况，这就是你要考虑的问题。

其他

上面，我们从技术角度简单讨论了关于马的一些东西。这里随便说的其他东西。

什么样的马才是一个好的马我的答案是满足需求，功能稳定的马是好的马，那怎样才能开发出这样一款马呢？我不知道，但我可以谈谈以前的经历。回想以往的工作经历，首先想到的是多种多样的需求，在某种情况下，可能需要的是这样一种马，在另外一种情况下，可能需要的是那样的一种马，这两只情况下需要的马在很多方面都一致，只是在某些方面又不一样。我觉得抓住并做好这些一致的地方很重要，因为我觉得自己并不是在开发马，而是在针对客户需求然后提供相应的解决方案，这是我想做的。我不想做的是尝试开发一个能适应各种情况的马。关于之前的工作经历的第二点就是关于马的功能的问题，马的功能或者插件的功能做到什么程度的问题，一定要强大吗？越强大越好吗？这是一个需要考虑的问题，功能强大当然好，但功能强大也往往意味着更复杂的代码、更多潜在的问题和更长的开发时间。没有人会用一个不稳定的马，即使它看起来功能强大。关于这点我曾经有过不太成功的经历，我的想法是以后在遇到类似的情况时，一定要考虑下实际的需求、开发周期和自己的实力。对于马来讲，稳定性真的很重要，不要在马或产品中用一些没那么必要的不成熟或复杂的东西。简单既是稳定，简单就是美。

另外，作为一个程序员，相较于上面我们讨论的这些东西，我更愿意花时间改善下项目的代码质量，思考下项目中存在的问题，什么样的架构更加稳定。