话不多说，我们直奔主题！首先，我们需要编写一个简单的Python脚本，然后看看在系统中执行命令时会涉及到哪些组件，并将输出以一个二维码图片的形式输出。接下来，我们还需要编写另外一个小型脚本来读入这个图片，并将结果显示在终端控制台中。我们可以直接在手机上扫描这个二维码，然后就可以看到Windows目录被输出出来了。

下面给出的是二维码样例：

很好，你扫描之后就可以看到结果了。因此理论上来说，这种方式应该也可以在代理和C2服务器之间建立直接连接。因此，我决定继续使用Python作为Web服务器，然后使用Flask来处理请求参数。这里之所以选择使用Python，主要是想支持在多种操作系统平台上运行。

接下来，我们还需要设计好如何实现数据交换。一开始，我打算使用二维码来从C2服务器发送命令，并通过代理返回输出的。在这里，我研究了一下第三方图像提供商所使用的技术，他们似乎都使用了POST请求来上传图像。如果我给Imgur提交的图片跟我接收到的一样多，可能会引起蓝队的怀疑。因此，我只想找到一种只是用GET请求的方法，并且用HTTPS进行加密，这样就不会有人能看到我的URI或请求主体了。出于数据完整性方面的考虑，我们需要执行的命令仍然将被代理以二维码的形式读取，并对数据采用Base64编码。除此之外，返回的数据也必须是图像类型，因为第三方图像服务只将图片作为有效的内容类型。

下面是我们通过URL搜索Google图像的界面，这里使用了“img.png”的Web路径：

下图显示的是服务器端返回的带有二维码图片的响应信息：

Burp中捕捉到的请求内容如下，其中包含了指向C2服务器的完整URL地址：

为了方便大家学习和研究，我已经完成了C2监听器的代码，以及跟监听器和底层SQLite数据库交互的服务器端脚本代码。如果需要的话，可以访问我的GitHub库直接获取【传送门】。不过，我不建议大家在真实场景中使用它们，因为它们确实会导致一定的安全问题出现。脚本能够正确接受命令并按照预期完成工作，并且能够允许用户与新加入的代理进行交互，然后直接执行接收到的终端命令并显示执行结果。当我们向代理服务器发送新的命令时，我们的请求将会进行Base64编码并转换为二维码图像，而这个二维码图像由监听器托管在一个“img.png”虚拟路径下。这样可以绕过第三方服务（比如说Google Images）的限制，以确保除了有效内容类型之外，还可以使用有效的图像扩展。

我反复研究了数据库中的命令和功能，以确保它按预期工作。接下来，我们需要创建代理。这个代理一开始是为了直连而构建的，我还添加了针对Google Images和Imgflip的支持。在编写这篇文章时，我还没有添加对Imgur的支持，但它比Google Images要简单。代理能够向一个图像发送ping请求，并提供一个带有其他参数的“代理ID”来作为路径。Flask服务器在接收到参数之后将更新数据库，以显示新增代理并检查其有效性。然后，服务器将查看代理是否接收到要执行的命令，如果收到，则显示先前在上一段中创建的二维码图像。一旦它被访问，二维码就会被删除，所以如果同样的请求再次被重复，所有人都会从矩阵中看到史密斯特工的头像。

如果命令执行之后需要回传给C2服务，它将会发送与接收信标基本相同的请求，但这一次它会将将命令的输出作为Base64编码值添加到名为“response”的GET参数中。C2服务器将接收并解码请求信息，然后将其显示给用户的终端控制台中。我在这里给信标添加了一个随机的时间间隔，介于1到10秒之间，以此降低其可疑程度。

目前为止，C2和隐写传输方法都能够正常工作了，但我还想添加一个重定向组件。我知道Google Images这里会比较棘手，因为它们需要cookie和其他有效的HTTP报头。在这里，响应还会被重定向到另一个调用，图像搜索的结果HTML内容也还需要进行解析，这样才能找到C2服务器返回的图像。因此，我们需要添加一个随机值来修改缓存，否则Google将只会返回前一个调用的图像。

下图显示的是C2信道的四次图像重定向方法：

下图显示的是代理跟Google Image服务器之间的TLSv1.3流量：

最后我想说的是，这个技术基本上可疑适用于任何线上服务，比如说Twitter、LinkedIn和Slack等等。广大研究人员还可以根据自己的需要来修改脚本代码，并发布一个“图片”，利用这个图片就可以像C2服务器发送请求了。当图片被打开时，它将会变成一个带有命令的二维码图片。