HTTP 反向 shell 比 TCP 反向 shell 有什么好处？

Question

我制作了一个多客户端 TCP 反向 shell，并观看了一个课程视频，其中说 HTTP 反向 shell 更好，因为与 TCP 相比，它很难追溯到攻击者。我不明白。

我试过用谷歌搜索这个问题，但没有太多帮助。

HTTP 反向 shell 真的比 TCP 更有用吗？怎么样？

我个人认为拥有 HTTP 反向 shell 是不好的，因为 http 是无连接的，当攻击者想要与主机通信时，它不能，因为没有与它的连接，攻击者只能在请求时进行通信（如 GET）来自主机。我在这里错过了什么吗？

请解释一下……

Answer 1

首先，我将回答 HTTPS over HTTP，因为我认为没有太多理由使用 HTTP over HTTPS，但是以这种方式加密您的流量有很多好处。

1. 不太可能被自动过滤

除少数特殊端口外，许多网络都会阻止出站流量。因此，使用端口 6666 之类的端口可能会引发一些警报。如果您尝试将端口用于预期用途之外的其他用途，某些软件可以使用深度数据包检测 (DPI) 来检测/阻止这种情况。换句话说，如果您的有效负载尝试使用端口 80/443 而不使用 HTTP/HTTPS，它可能会引发警报并捕获您的有效负载。

1. 它更隐蔽。

我想说，作为隐形有效载荷的两个最重要的因素是看起来像正常流量，以避免一开始就引起注意，并且如果您的连接确实受到注意，则难以检查。 HTTPS 很好地完成了这两个方面。

这是因为在大多数网络上，您的网络上的节点一直在向 Internet 发出请求是极其常见的。将发出 HTTPS 请求的信标有效负载与通过某个随机端口连接的某些有效负载进行比较。

---

现在，至于你最后的问题......这取决于你的情况，但你是对的，如果你使用 HTTP(S) 之类的东西来维护已建立的连接，通常会出现延迟。我之前提到过这一点，但我们可以通过信标进行通信。从本质上讲，这仅意味着有效负载将在设定的时间间隔内与服务器进行检查（通常会出现抖动以使其更难检测）。

受害者将向您的命令和控制 (C2) 服务器发出 HTTP(S) 请求，其中包含您告诉它运行的上一个命令的结果。您的服务器将返回一个 HTTP(S) 响应，其中包含有效负载的下一个指令。