红队攻防实践：闲谈Webshell在实战中的应用
动态免杀
流量加密webshell
冰蝎和蚁剑
平时渗透测试中经常使用的就是冰蝎和蚁剑，对于我来说用的冰蝎多一点，冰蝎刚开始的时候免杀效果特别好，但是随着使用人数越来越多，已经可以被很多waf识别并拦截，冰蝎项目地址：
https://github.com/rebeyond/Behinder/releases
除了冰蝎，另外一个就是蚁剑了，蚁剑是一款开源的跨平台网站管理工具，因为开源，相对来说可玩性很高，可以自定义加密方式，可以做任何修改，也是很多安全行业从业者特别喜欢的一款工具：
https://github.com/AntSwordProject/AntSword-Loader
tunnel流量
tunnel也是我们拿下shell挂正向代理常用的工具之一(也就是我们常说的reGeorg)，但是目前来说，原始版确实存在很多特征，很容易被检测出流量，从而被拦截。现在我会经常使用Neo-reGeorg：
https://github.com/L-codes/Neo-reGeorg
这是L-codes大佬重构reGeorg的项目，对reGeorg的流量进行加密，我之前对它的流量进行抓包查看，确实没什么明显的特征，效果确实不错。最好的一点的可以伪造目标404页面，这为我们在护网中拿下目标后进行后门隐藏做了一个很好的铺垫，我们可以以目标系统的404页面进行模版制作后门。
静态免杀
各语言脚本免杀方法
静态免杀相对于动态免杀而言也是显得尤为重要，一方面静态免杀可以躲避被查杀工具发现，更重要的是在webshell上传时，可以绕过waf对于webshell内容的检测，这一点特别关键。也就是说我们在对webshell进行改造时，光能使webshell放到查杀工具中（比如D盾）不被查杀是很片面的，因为我们的第一步是把webshell传到目标服务器，这一步中我们要把敏感函数隐藏起来才行。
对于静态免杀，免杀思路也是特别灵活的，可以根据各个语言的特性来进行免杀，就用冰蝎举个例子：
冰蝎的静态免杀处理：
jsp木马
jsp脚本可以使用unicode编码的方式来进行绕过静态查杀，比如之前碰到的jsp小马,既然jsp小马可以通过这种方式进行免杀，冰蝎当然也可以,但是冰蝎不能像jsp小马那样直接全部unicode编码，而是需要部分编码，经过多次编码测试，发现在代码内容处，只要函数参数值不进行编码，冰蝎就可以正常使用
动态免杀
流量加密webshell
冰蝎和蚁剑
平时渗透测试中经常使用的就是冰蝎和蚁剑，对于我来说用的冰蝎多一点，冰蝎刚开始的时候免杀效果特别好，但是随着使用人数越来越多，已经可以被很多waf识别并拦截，冰蝎项目地址：
https://github.com/rebeyond/Behinder/releases
除了冰蝎，另外一个就是蚁剑了，蚁剑是一款开源的跨平台网站管理工具，因为开源，相对来说可玩性很高，可以自定义加密方式，可以做任何修改，也是很多安全行业从业者特别喜欢的一款工具：
https://github.com/AntSwordProject/AntSword-Loader
tunnel流量
tunnel也是我们拿下shell挂正向代理常用的工具之一(也就是我们常说的reGeorg)，但是目前来说，原始版确实存在很多特征，很容易被检测出流量，从而被拦截。现在我会经常使用Neo-reGeorg：
https://github.com/L-codes/Neo-reGeorg
这是L-codes大佬重构reGeorg的项目，对reGeorg的流量进行加密，我之前对它的流量进行抓包查看，确实没什么明显的特征，效果确实不错。最好的一点的可以伪造目标404页面，这为我们在护网中拿下目标后进行后门隐藏做了一个很好的铺垫，我们可以以目标系统的404页面进行模版制作后门。
静态免杀
各语言脚本免杀方法
静态免杀相对于动态免杀而言也是显得尤为重要，一方面静态免杀可以躲避被查杀工具发现，更重要的是在webshell上传时，可以绕过waf对于webshell内容的检测，这一点特别关键。也就是说我们在对webshell进行改造时，光能使webshell放到查杀工具中（比如D盾）不被查杀是很片面的，因为我们的第一步是把webshell传到目标服务器，这一步中我们要把敏感函数隐藏起来才行。
对于静态免杀，免杀思路也是特别灵活的，可以根据各个语言的特性来进行免杀，就用冰蝎举个例子：
冰蝎的静态免杀处理：
jsp木马
jsp脚本可以使用unicode编码的方式来进行绕过静态查杀，比如之前碰到的jsp小马,既然jsp小马可以通过这种方式进行免杀，冰蝎当然也可以,但是冰蝎不能像jsp小马那样直接全部unicode编码，而是需要部分编码，经过多次编码测试，发现在代码内容处，只要函数参数值不进行编码，冰蝎就可以正常使用
SIGRED – 进入域管理员权限：利用 WINDOWS DNS 服务器中存在 17 年之久的漏洞
DNS 常被描述为“互联网电话簿”，是一种将人性化的计算机主机名转换为 IP 地址的网络协议。由于 DNS 是互联网的核心组件，因此目前有许多 DNS 服务器解决方案和实现，但只有少数几种得到广泛使用。
“Windows DNS 服务器”是 Microsoft 的实现，是 Windows 域环境的重要组成部分和要求。
SIGRed (CVE-2020-1350) 是 Windows DNS 服务器中的一个可感染蠕虫的严重漏洞（CVSS 基本评分为 10.0），影响 Windows Server 2003 至 2019 版本，并可能由恶意 DNS 响应触发。由于该服务以提升的权限（SYSTEM）运行，如果成功利用，攻击者将获得域管理员权限，从而有效地破坏整个公司基础设施。
DNS 常被描述为“互联网电话簿”，是一种将人性化的计算机主机名转换为 IP 地址的网络协议。由于 DNS 是互联网的核心组件，因此目前有许多 DNS 服务器解决方案和实现，但只有少数几种得到广泛使用。
“Windows DNS 服务器”是 Microsoft 的实现，是 Windows 域环境的重要组成部分和要求。
SIGRed (CVE-2020-1350) 是 Windows DNS 服务器中的一个可感染蠕虫的严重漏洞（CVSS 基本评分为 10.0），影响 Windows Server 2003 至 2019 版本，并可能由恶意 DNS 响应触发。由于该服务以提升的权限（SYSTEM）运行，如果成功利用，攻击者将获得域管理员权限，从而有效地破坏整个公司基础设施。
“土耳其鼠”在大规模持续网络钓鱼活动中进化了 ADWIND
Check Point 研究人员正在跟踪一场不断发展的恶意垃圾邮件活动，该活动针对 80 多家土耳其公司。该恶意软件使用不同的规避方法来绕过安全解决方案。
初始攻击媒介始于包含 Office 文件附件的网络钓鱼电子邮件。该文件采用已有 20 年历史的BIFF 格式，无法通过常见的 Office 解析工具进行解析。在下一阶段，会下载恶意 Jar 文件。此文件经过大量混淆，并采用多种规避技术来避免被安全产品检测到。然后，jar 文件会植入 Adwind RAT（一种多平台恶意软件），该恶意软件被配置为窃取敏感信息并将其发送到攻击者的命令和控制 (C&C) 服务器，同时获得对受害者机器的远程访问权限。
所有这些文件在 Virus Total 中的检测率都非常低，很可能是因为混淆程度太高。
攻击者向受害者发送恶意电子邮件。
受害者触发恶意内容。
从 GitHub 存储库下载了恶意 RAT。
该恶意软件与其 C＆C 服务器建立连接。
Check Point 研究人员正在跟踪一场不断发展的恶意垃圾邮件活动，该活动针对 80 多家土耳其公司。该恶意软件使用不同的规避方法来绕过安全解决方案。
初始攻击媒介始于包含 Office 文件附件的网络钓鱼电子邮件。该文件采用已有 20 年历史的BIFF 格式，无法通过常见的 Office 解析工具进行解析。在下一阶段，会下载恶意 Jar 文件。此文件经过大量混淆，并采用多种规避技术来避免被安全产品检测到。然后，jar 文件会植入 Adwind RAT（一种多平台恶意软件），该恶意软件被配置为窃取敏感信息并将其发送到攻击者的命令和控制 (C&C) 服务器，同时获得对受害者机器的远程访问权限。
所有这些文件在 Virus Total 中的检测率都非常低，很可能是因为混淆程度太高。
攻击者向受害者发送恶意电子邮件。
受害者触发恶意内容。
从 GitHub 存储库下载了恶意 RAT。
该恶意软件与其 C＆C 服务器建立连接。
F5 BIG-IP hsqldb(CVE-2020-5902)漏洞踩坑分析
F5 BIG-IP最近发生了一次比较严重的RCE漏洞，其中主要公开出来的入口就是tmsh与hsqldb方式，tmsh的利用与分析分析比较多了，如果复现过tmsh的利用，就应该知道这个地方利用有些鸡肋，后面不对tmsh进行分析，主要看下hsqldb的利用。hsqldb的利用poc已经公开，但是java hsqldb的https导致一直无法复现，尝试了各种方式也没办法了，只好换其他思路，下面记录下复现与踩坑的过程。
利用源码搭建一个hsqldb http servlet
如果调试过hsqldb，就应该知道hsqldb.jar的代码是无法下断点调试的，这是因为hsqldb中类的linenumber table信息没有了，linenumber table只是用于调式用的，对于代码的正常运行没有任何影响。看下正常编译的类与hqldb类的lineumber table区别：
使用javap -verbose hsqlServlet.class命令看下hsqldb中hsqlServlet.class类的详细信息
可以看到自己编译的类中，每个method中都有一个 LineNumberTable，这个信息就是用于调试的信息，但是hsqldb中没有这个信息，所以是无法调试下断点的，hsqldb应该在编译时添加了某些参数或者使用了其他手段来去除这些信息
F5 BIG-IP最近发生了一次比较严重的RCE漏洞，其中主要公开出来的入口就是tmsh与hsqldb方式，tmsh的利用与分析分析比较多了，如果复现过tmsh的利用，就应该知道这个地方利用有些鸡肋，后面不对tmsh进行分析，主要看下hsqldb的利用。hsqldb的利用poc已经公开，但是java hsqldb的https导致一直无法复现，尝试了各种方式也没办法了，只好换其他思路，下面记录下复现与踩坑的过程。
利用源码搭建一个hsqldb http servlet
如果调试过hsqldb，就应该知道hsqldb.jar的代码是无法下断点调试的，这是因为hsqldb中类的linenumber table信息没有了，linenumber table只是用于调式用的，对于代码的正常运行没有任何影响。看下正常编译的类与hqldb类的lineumber table区别：
使用javap -verbose hsqlServlet.class命令看下hsqldb中hsqlServlet.class类的详细信息
可以看到自己编译的类中，每个method中都有一个 LineNumberTable，这个信息就是用于调试的信息，但是hsqldb中没有这个信息，所以是无法调试下断点的，hsqldb应该在编译时添加了某些参数或者使用了其他手段来去除这些信息
环境：
hsqldb source代码是1.8的，现在新版已经2.5.x了，为了和f5中的hsqldb吻合，还是用1.8的代码吧
JDK7u21，F5 BIG-IP 14版本使用的JDK7，所以这里尽量和它吻合避免各种问题
hsqldb source代码是1.8的，现在新版已经2.5.x了，为了和f5中的hsqldb吻合，还是用1.8的代码吧
JDK7u21，F5 BIG-IP 14版本使用的JDK7，所以这里尽量和它吻合避免各种问题
CVE-2020-5902: F5 BIG-IP 远程代码执行漏洞分析
0x00 漏洞简述
2020年07月08日， 360CERT监测发现 F5 官方更新了 F5 BIG-IP 远程代码执行 的风险通告，该漏洞编号为 CVE-2020-5902，漏洞等级：严重。
未授权的远程攻击者通过向漏洞页面发送特制的请求包，可以造成任意 Java 代码执行。进而控制 F5 BIG-IP 的全部功能，包括但不限于: 执行任意系统命令、开启/禁用服务、创建/删除服务器端文件等，使用官方的httpd配置缓解修复方案仍可造成反序列化代码执行漏洞。该漏洞影响控制面板受影响，不影响数据面板。
对此，360CERT建议广大用户及时将 BIG-IP 按照修复建议升级到指定版本。与此同时，请做好资产自查以及预防工作，以免遭受黑客攻击。
0x01 漏洞详情
首先，这里F5选择了Apache和tomcat服务器使用ajp_proxy模块进行通信，apache处理完请求之后，通过ajp协议转发给Tomcat，默认是8009端口，来看一下关于漏洞的配置文件，
proxy_ajp.conf
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
...
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5
apache的httpd.conf
#
# HSQLDB
#
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
<Location /tmui>
# Enable content compression by type, disable for browsers with known issues
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain application/x-javascript text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
<RequireAll>
AuthType Basic
AuthName "Restricted area"
AuthPAM_Enabled on
AuthPAM_ExpiredPasswordsSupport on
AuthPam_ValidateIP On
AuthPAM_IdleTimeout 1200
AuthPAM_DashboardTimeout Off
require valid-user
Require all granted
</RequireAll>
</Location>
0x00 漏洞简述
2020年07月08日， 360CERT监测发现 F5 官方更新了 F5 BIG-IP 远程代码执行 的风险通告，该漏洞编号为 CVE-2020-5902，漏洞等级：严重。
未授权的远程攻击者通过向漏洞页面发送特制的请求包，可以造成任意 Java 代码执行。进而控制 F5 BIG-IP 的全部功能，包括但不限于: 执行任意系统命令、开启/禁用服务、创建/删除服务器端文件等，使用官方的httpd配置缓解修复方案仍可造成反序列化代码执行漏洞。该漏洞影响控制面板受影响，不影响数据面板。
对此，360CERT建议广大用户及时将 BIG-IP 按照修复建议升级到指定版本。与此同时，请做好资产自查以及预防工作，以免遭受黑客攻击。
0x01 漏洞详情
首先，这里F5选择了Apache和tomcat服务器使用ajp_proxy模块进行通信，apache处理完请求之后，通过ajp协议转发给Tomcat，默认是8009端口，来看一下关于漏洞的配置文件，
proxy_ajp.conf
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
...
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5
apache的httpd.conf
#
# HSQLDB
#
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
<Location /tmui>
# Enable content compression by type, disable for browsers with known issues
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain application/x-javascript text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
<RequireAll>
AuthType Basic
AuthName "Restricted area"
AuthPAM_Enabled on
AuthPAM_ExpiredPasswordsSupport on
AuthPam_ValidateIP On
AuthPAM_IdleTimeout 1200
AuthPAM_DashboardTimeout Off
require valid-user
Require all granted
</RequireAll>
</Location>
F5 PAM 认证模块
F5实现了自己的pam进行认证，模块路径为/usr/lib/httpd/modules/，其中，涉及到login.jsp授权的是mod_f5_auth_cookie.so文件。
反汇编之后，大概是这样的。我们能够请求/tmui/login.jsp而不需要进行身份验证。
总结
在apache的处理中，;是被当作普通字符的，不会解析。
/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
此时，由于请求的是/tmui/login.jsp，根据pam认证模块里，/tmui/login.jsp不需要认证，接着，该请求会被转发到 tomcat上，最终tomcat请求：
/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
在web.xml 是有该配置的
<servlet-mapping>
<servlet-name>org.apache.jsp.tmui.locallb.workspace.fileRead_jsp</servlet-name>
<url-pattern>/tmui/locallb/workspace/fileRead.jsp</url-pattern>
</servlet-mapping>
请求/hsqldb;，apache本身会对/hsqldb进行认证，根据httpd.conf的配置，是匹配不到/hsqldb;的
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
但正是因为tomcat对于;处理上的差异，导致了身份的绕过，%0a也是一个道理
F5实现了自己的pam进行认证，模块路径为/usr/lib/httpd/modules/，其中，涉及到login.jsp授权的是mod_f5_auth_cookie.so文件。
反汇编之后，大概是这样的。我们能够请求/tmui/login.jsp而不需要进行身份验证。
总结
在apache的处理中，;是被当作普通字符的，不会解析。
/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
此时，由于请求的是/tmui/login.jsp，根据pam认证模块里，/tmui/login.jsp不需要认证，接着，该请求会被转发到 tomcat上，最终tomcat请求：
/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
在web.xml 是有该配置的
<servlet-mapping>
<servlet-name>org.apache.jsp.tmui.locallb.workspace.fileRead_jsp</servlet-name>
<url-pattern>/tmui/locallb/workspace/fileRead.jsp</url-pattern>
</servlet-mapping>
请求/hsqldb;，apache本身会对/hsqldb进行认证，根据httpd.conf的配置，是匹配不到/hsqldb;的
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
但正是因为tomcat对于;处理上的差异，导致了身份的绕过，%0a也是一个道理
请求拆分有多危险？Golang 中的一个漏洞，或者我们如何在 Portainer 中发现 RCE 并入侵 Uber
Docker 容器是通过 Docker API 进行管理的，但允许访问 Docker API 并不安全，因此通过 Websocket 接口使用了 TCP 代理方案。由于请求包含唯一的容器标识符 — id ，因此无需身份验证即可完成代理。它充当特定容器的 API 密钥。
这个查询发送给 Docker api，POST /exec/uuid/start。然后建立一个 Websocket 连接，通过TCP
代理到容器，用户可以在网站上运行命令
Docker 容器是通过 Docker API 进行管理的，但允许访问 Docker API 并不安全，因此通过 Websocket 接口使用了 TCP 代理方案。由于请求包含唯一的容器标识符 — id ，因此无需身份验证即可完成代理。它充当特定容器的 API 密钥。
这个查询发送给 Docker api，POST /exec/uuid/start。然后建立一个 Websocket 连接，通过TCP
代理到容器，用户可以在网站上运行命令
特定 API 提供商的工作流程
还可以创建 Dork 来定位特定的 API 提供商及其端点。这对于为用户的 API 密钥创建自动检查的公司尤其有用。了解 API 密钥的上下文和语法后，搜索空间可以大大减少。
了解特定的 API 提供商后，我们可以获取与 API 提供商的正则表达式匹配且位于 API 调用上下文中的所有键，然后我们可以使用内部数据库或 API 端点检查它们的有效性。
例如，假设一家公司（HalCorp）为用户提供了一个 API，用于读取和写入其帐户。通过创建我们自己的 HalCorp 帐户，我们发现 API 密钥的形式为[a-f]{4}-[a-f]{4}-[a-f]{4}
还可以创建 Dork 来定位特定的 API 提供商及其端点。这对于为用户的 API 密钥创建自动检查的公司尤其有用。了解 API 密钥的上下文和语法后，搜索空间可以大大减少。
了解特定的 API 提供商后，我们可以获取与 API 提供商的正则表达式匹配且位于 API 调用上下文中的所有键，然后我们可以使用内部数据库或 API 端点检查它们的有效性。
例如，假设一家公司（HalCorp）为用户提供了一个 API，用于读取和写入其帐户。通过创建我们自己的 HalCorp 帐户，我们发现 API 密钥的形式为[a-f]{4}-[a-f]{4}-[a-f]{4}
但是这个类并不能用于调试，因为fastjson中用ASM生成的代码没有linenumber、trace等用于调试的信息，所以不能调试。不过通过在Expression那个窗口重写部分代码，生成可用于调式的bytecode应该也是可行的（我没有测试，如果有时间和兴趣，可以看下ASM怎么生成可用于调试的字节码）