Posts

The SGN algorithm is dead. Yara hunting for the sgn encode , i success 100% hunting all the sgn in the last relase version . SGN算法是什么？ SGN算法是一种变异处理shellcode算法，被渗透测试、红队、APT广泛的使用，具体这个地址了解： https://github.com/EgeBalci/sgn 截至目前2026年3月16日，目前Sgn的混淆算法依然可以到VT0： 挑战编写Yara识别SGN算法 Github悬赏的挑战，比特币换算大概有1000RMB,我没有比特币的钱包地址，不过我依然决定亲自挑战一下全世界安全研究员都没做到的事情，疑似？ 这个规则前几个月，我肝了几周写完的，本来想整理出来复习一下，但是现在时间隔得有点久了，没写记录，完全忘记了之前具体是怎么样分析SGN算法的（哈哈哈，专家一样会遗忘，我又不是机器人），想了一下算了，不写分析了，重新分析又要浪费好几天时间，目前精力主要在windows内核开发和基础的学习，就直接分享出来吧。。。。。 具体规则 注意，下面这个规则必须最新的yara版本才能解析，我不会提供老版本yara的语法规则。 具体Github地址，已经设置MIT版权了，随便用：https://github.com/kaliworld/theyaraforsgn 记得给我star，谢谢 rule sgn_plain_x86 { meta: description = "高置信度的 SGN x86 明文解码器 stub" author = "EndlessParadox" confidence = "high" strings: $stub = { E8 00 00 00 00 5? B9 ?? ?? ?? ?? [0-4] B? ?? [0-4] 30 ?? [2-8] 02 ?? [1-8] E2 ?? } condition: filesize > 32 and $stub in (0..64) } rule sgn_plain_x64 { meta: description = "高置信度的 SGN x64 明文解码器 stub" author = "EndlessParadox" confidence = "high" strings: $stub = { 48 C7 C1 ?? ?? ?? ?? [0-12] ( 48 | 49 | 4C | 4D ) 8D ?? ?? ?? ?? ?? [0-8] ( 30 ?? | 40 30 ?? | 41 30 ?? | 44 30 ?? | 45 30 ?? ) [0-6] ( 02 ?? | 40 02 ?? | 41 02 ?? | 44 02 ?? | 45 02 ?? ) [0-6] E2 ?? } condition: filesize > 32 and $stub in (0..96) } rule sgn_schema_x86 { meta: description = "高置信度的 SGN x86 架构型解码器" author = "EndlessParadox" confidence = "high" strings: $call = { E8 ?? ?? ?? ?? } $jmp = { FF E? } $tail = { 5? [0-64] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-48] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-48] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-64] FF E? } condition: filesize > 96 and $call in (0..64) and $jmp in (filesize-8..filesize) and $tail } rule sgn_schema_x64 { meta: description = "高置信度的 SGN x64 架构型解码器" author = "EndlessParadox" confidence = "high" strings: $call = { E8 ?? ?? ?? ?? } $jmp_lo = { FF E? } $jmp_hi = { 41 FF E? } $tail_lo = { 5? [0-64] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-48] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-48] ( 81 ?? ?? ?? ?? ?? | 81 ?? ?? ?? ?? ?? ?? | F7 1? | F7 5? ?? | C1 0? ?? | C1 4? ?? ?? ) [0-64] FF E? } $tail_hi = { 41 5? [0-64] ( 41 81 ?? ?? ?? ?? ?? | 41 81 ?? ?? ?? ?? ?? ?? | 41 F7 1? | 41 F7 5? ?? | 41 C1 0? ?? | 41 C1 4? ?? ?? ) [0-48] ( 41 81 ?? ?? ?? ?? ?? | 41 81 ?? ?? ?? ?? ?? ?? | 41 F7 1? | 41 F7 5? ?? | 41 C1 0? ?? | 41 C1 4? ?? ?? ) [0-48] ( 41 81 ?? ?? ?? ?? ?? | 41 81 ?? ?? ?? ?? ?? ?? | 41 F7 1? | 41 F7 5? ?? | 41 C1 0? ?? | 41 C1 4? ?? ?? ) [0-64] 41 FF E? } condition: filesize > 96 and $call in (0..64) and ( $jmp_lo in (filesize-8..filesize) or $jmp_hi in (filesize-8..filesize) ) and any of ($tail*) } rule sgn_high_confidence { meta: description = "高置信度的 SGN 编码器检测规则" author = "EndlessParadox" profile = "high-confidence-SGN" release = "1.0" condition: sgn_plain_x86 or sgn_plain_x64 or sgn_schema_x86 or sgn_schema_x64 } 识别效果 msf生成shellcode： ...

看到互联网上的经验都比较老了，我就分享一下2026年最新的申请CVE过程和经验，后续还夹杂着我的一些工作感想。 自行CVE申请 申请的官网 : https://cveform.mitre.org/ :选中Repoort直接报告即可： Attack vector(s) 通常可以填Github的issue链接或者自己建一个在公共空间填写的POC 向作者申请 如果是挖掘的开源软件，也可以直接使用Github内置的报告和开发者报告，这个效率非常高，开发者披露后走的是github分配的： CVE申请的限制和审核加强 CVE拒绝非正式版本的申请，我之前申请的bete版的漏洞拒绝了申请，具体请看 This request is relation to the beta version of a product. We are unable to assign for beta versions as they are not publicly available. 同时，并非所有的安全问题都有CVE或者适合CVE：举两个非常典型的例子，我在Github的开源仓库看到了大量的docker.socket不正确挂载导致容器的逃逸 类似 Dpanel，这种问题虽然严重，实战效果也很强，依然不会分配编号；另一个例子是红队常用的 Winodows降级攻击 WindowsDowndate ，这类利用天然的设计来带的安全问题也不会被收录到CVE 不确定Ai模型的问题会不会收录，我没有挖掘过任何ai相关的风险漏洞，不建议申请这类CVE，我目前没看到任何有关ai模型本身出现的幻觉或者注入会给CVE的，当然如果是涉及ai产品就是另外一回事了 CVE 申请效率 4ra1n以前的博客指出自行申请的效率： 实际上在2026年并不是如此，我的经验基本上一个月或者两个月就通过一批CVE（陆续送报的），很大可能和我们申请CVE的数量和排队有关，我猜测可能和邮件和批量审批有关，总之MITRE效率相比以前提高了很多，具体请看彩蛋。 CVE公开 等待CVE的回信，回信完毕会在档案里面写编号，第二步是申请公开，下面填入你的编号： 注意Link to the advisory不能填写github issue，我之前用的github issue写了官方回信如下： 最好自己写一个博客，然后写好漏洞分析，之后表格申请公开之后，等待一段时间（几天的时间）会收到一封邮件，内容大概是是漏洞将会在几个小时公开： 等待一会就能看到官方之后官网公布（这里点名表扬一下bing搜索当天就收录了，谷歌搜索还是空的，谷歌的搜索真不如bing优化的好），刚公开的会显示 “This CVE record has been marked for NVD enrichment efforts."，还需要等待NVD进行完整的漏洞评价： ...

本文首发于先知社区 https://xz.aliyun.com/news/91353 回忆我这几年的失误和技术误解，并且分享有趣的故事—-几次打崩系统的故事，并且从中总结失败的教训，回忆稍显繁琐。本人已经没有参加任何比赛性质的攻防演练，均直接服务于项目，如有雷同，纯属巧合，所有渗透行为均合法授权，请不要瞎溯源。 第一次崩溃 大概是刚毕业出来工作的时候，在那个时候我还是个新手菜鸟，摆弄着各种大佬写的工具，那个时候，我开始熟悉冰蝎和Cobaltstirke，我发现了一个震惊我的功能，冰蝎居然能”一键上线CS“，对于不懂jni、汇编、架构和系统的那个时候的我，我震惊的，本地搭建环境测试了还成功了，轻松吊打360\微软DF，一个webshell 怎么可能打入EXE在内部执行？ 但是测试过程出了一个问题，在我的本机搭建的环境测试非常顺利，一键上线绕过了我们国内主流的杀毒，上线执行命令一切正常，而我朋友Arui的机器上测试，每次都会崩溃，我们开始争辩，但是你懂的，讨论不出什么结论，因为我们那个时候知识有限，我们当时不得不得出这个技术不稳定的错误结论，哈哈哈。 那么到底为什么？ 我和周边的朋友都是web出身的，基本上搞二进制的凤毛麟角，同时懂web和二进制这两个就更少了，22年当初问了一圈都没人能回答这个问题，过了几年，我开始掌握二进制的知识，然后翻阅了更新日志，看到了下面一条。 https://github.com/rebeyond/Behinder/releases 内存马shellcode注入前增加了CPU架构判断 4.1版本之前内存马shellcode居然没有CPU架构判断，所以答案已经很明晓，强制给32位的java塞一个64位的dll，架构都不一样肯定崩溃，也就是我同事的环境，可能还在用32位的java+windows测试环境，这要是实战，我们只能得出对面关闭了网站 我们再看一下源代码，这个是之前的64位和32位的判定： https://github.com/MountCloud/BehinderClientSource/blob/d146e76ec90dbb5f1454dd77ec8e2368b4eadf6f/src/main/java/net/rebeyond/behinder/ui/controller/ReverseViewController.java#L181 选择随机保存dll到如下目录 String remoteUploadPath = "c:/windows/temp/" + Utils.getRandomString((new Random()).nextInt(10)) + ".log"; 判定架构进入分支 (String)this.basicInfoMap.get("arch")).toString().indexOf("64") >= 0 是64位直接打入JavaNative_x64.dll，否则打入JavaNative_x32.dll if os == 64: inject JavaNative_x64.dll and shellcode else: inject JavaNative_x32.dll and shellcode 这样写修复了x86-64的问题，但是很明显，全世界有大量不同的架构，比方说ARM架构和RISC-V，这样就会直接进入inject JavaNative_x32.dll and shellcode打崩JVM 深入解释原因 等等，刚刚的就是正确的答案吗，崩溃的含义是什么？刚刚我们并没有解释清楚哪里崩了，对吧？已经是3年前的事情了，如果有dumpcrash的文件，我瞄一眼就能定位，但现在我只能尝试推测还原，让我们把问题分解开来，其实就是三部分：windows的问题、java自己的问题、载入的dll的问题： 首先，先理解JNI的本质只是调用LoadLibrary，一个64位的java.exe PE调用LoadLibrary加载32位的DLL是不会导致崩溃的，你可以编译一个64位的PE验证这一观点，它只会返回一个错误code回来，这可不会带崩进程和后续代码的执行逻辑： // demo.cpp : This file contains the 'main' function. Program execution begins and ends there. // #include <iostream> #include <Windows.h> int main() { std::cout << "SysWOW64 is 32 bit PE!\n"; LoadLibraryA("C:\\Windows\\SysWOW64\\ntdll.dll"); std::cout << "the lasterror is " << GetLastError() << std::endl; std::cout << "It is ok the countine execute code\n"; } 执行结果如下： ...

简单分享一下备考体验和经历，希望能帮到新入坑的师傅。 CRTO 价格和内容 CRTO（Red Team Ops）我是2023年买的，因为摆烂加兴趣转移（深入学习了一段时间的windows底层机制）2024年的国庆才考完拿下认证。那个时候买完就打折了，总共就花了4000块，加上lab可能就4500？打折可以更便宜。现在不给中国人买了，会验证信用卡的来源（听说可以使用虚拟信用卡绕过它这个限制，我那个时候，2023年还没有这个限制）。教材内容主要是域渗透相关的，和OSEP高度重合，可以去大纲看看，我这里就不赘述了。 这个地方 ：https://training.zeropointsecurity.co.uk/courses/red-team-ops 考试环境用的是最新的windows杀毒（没错，考试环境会一直更新，使用最新的windows版本和windows杀毒，我是自己提前写好了C++的加载器，在攻击机的环境里面编译使用，考试提供了编译环境），随着windows杀毒越来越强，CRTO的考试免杀绕过应该会越来越难。我没走教材的免杀方法，它免杀依赖Kit，不是很灵活，当然对于通过考试来说足够了。 教材讲解了很多Cobaltstrike的使用技巧，你就会发现CS是多么好用又稳定。内容总体来说就是域+免杀+CS的基本和进阶使用方法，价格非常实惠，当初刚毕业身上没什么钱，就买了这个。认可度的话可以看看这个，是官方Cobalt Strike Training Resources指定的课程，CRTO知名度应该后面会越来越高：https://www.cobaltstrike.com/support/training CRTO的浏览器网络问题 由于考试和CRTO lab环境一样，是给个浏览器去访问操作里面的工具，一线城市直连的质量还是不错的，都花钱买了CRTO了，也不缺几十块钱买好一点的专线梯子去操作。里面的机器配置和做lab是一样，体验算不算卡，也算不上流畅，不过比OSCP稳定多了。 CRTO考试经验 很难说到底要准备多久才能通过考试，我想，CRTO的lab要是能流畅完成，考过应该问题不大，我之前就有域渗透经验，复习了几周，准备好命令的笔记（我之前就研究了一段时间AD，严格来说我对AD、底层协议已经非常熟悉了）就预约了考试了，预约之后，你会在你的版面出现一个lab考试的环境，点进去里面有Readme说明，一定要仔细阅读。 考试给了四天时间，我在10点中起床开始考试，我花了1个小时多的时间配置完环境，下午4点左右我就拿到了60分，这足以通过考试，但是我是完美主义者，我决定继续深入研究； 我卡在最后一个域接近7个小时！最后一个域难的离谱，距离考试已经有一段时间了，我现在都记不清楚怎么横向过去的了，当时域横向的命令有问题，我花了很久的时间修复命令，修改工具的源代码排错。 我一天拿下了全部flag，满分通过了考试，哈哈哈哈。 时间没必要卡的太死，如果你累了就休息吧，关机可以省下一些时间，但是注意要做好权限维持，不然后面就掉线了，就很难受；如果你和我一样一天就做完，倒也没必要搞权限维持。最后一个域远远超过了教材里面的内容，不建议新手死磕，做不出来也正常，我现在去做也费劲。考试不需要写报告，交完Flag就等证书下来了。 划重点！一定学好域之间移动和MSSQL的模块! 不然肯定挂科。 考完邮件会发一个链接，然后你就能收到这个认证了： Update:现在教程改版了，这个经验不再适用。 OSCP价格和内容 我去年2024年底在官网买的一年的实验室，花了1w5左右，当时有20%折扣，听说又涨价了。这个认证可以说是越来越贵了，官方为了多赚钱也没办法，而且客户认可度也高，不得不得考了（笑），主要是这个认证可以去部分银行养老，哈哈哈哈，也许有一天我也去养老了，加上公司要接项目看这玩意。内容主要就是web、域、系统提权，现在这个教材版本还加了AWS的云，内容很丰富。 你应该不能体会到一个经常刷顶会演讲，被black hat、defcon、各路卷王的博客熏陶洗礼过的HACKER再去做sql注入、web\域基础的心态，还要被CTF的题目、兔子洞折磨，我TM直接裂开，对我来说太痛苦了，要知道现在现代红队，我们开发的工具都是指纹识别+POC高度精准了，OSCP挂科就就像大学生回去做高考题，还没考上现在的学校一样，这太丢人了。 我见过不少人就考了OSCP\OSEP再考CRTO，但是我这种老油条的经历情况太特殊了，哈哈哈，就反过来了。说实话我对这些内容相当熟悉，还是买了一年的，因为有两次考试机会。如果你买的一年两次，参加补考的价格是$249，可以参考这个： https://help.offsec.com/hc/en-us/articles/29840452210580-Changes-to-the-OSCP 为什么我第一次会失败？ 额，绝不是因为我技术不行或者实力不够，如果你硬要说我实力不行，那我也只能承认了，我要是修炼到了化神期还考这玩意干什么，早就飞升仙界了。纯粹是因为我缺乏练习，内功再深厚，招式不练习肯定是不行的，我的岗位是安全研究基本上就是云相关的研究—和这些题目相关性几乎就是0，加上OSCP也故意设计成就是要折磨考生，我TM大意了，没有闪，我当初第一次备考就过了一下oscp里面的实验室，pg是一个都没动，就匆匆上考场了，果不其然失败了（以前有一些幸运儿只练教程的实验室也能过，可能和抽到的题目难易度有关系，也有可能是OSCP+加强的考试难度？） 一定要做完 Proving Grounds Practice这个靶场，虽然很折磨，但务必做完，他送的实验室建议最后练习，因为对比真正的考试比较简单，可以考前增强一下自信心。备考就用这个折磨折磨吧 https://docs.google.com/spreadsheets/d/18weuz_Eeynr6sXFQ87Cd5F0slOj9Z6rt/ ，建议一定还要做完 基本上只能每天打靶练习肝了，没有任何捷径可以走，你就是老红队，研究员不做这里面的八股文一样难受，核心是—-你必须要猜出他的考点，然后做出来！但是3台单机是有无限可能的—-你必须24小时解开，这CTF对我来说太折磨了，限制时间的话也很考验心态。 这是另一个博主的观点，“That being said, as mentioned earlier, the OSCP is still the industry requirement for most offensive security roles in Singapore (and most other countries) - so if you’re looking to join an offensive security team, you will eventually have to bite the bullet and roll the dice on OSCP “—– https://gatari.dev/posts/certified-cert-collector/ ...

本文首发于先知社区，博客此版本内容稍有改动。 先知地址为： https://xz.aliyun.com/news/18560 本系列将记录我研究AWS安全相关过程的基础知识、攻击手法、威胁检测工程等相关技术和思考。先从基本概念、云架构、重点服务开始讲解，结合云的主要风险点和目前高频使用的TTPS攻击手法，最后再简要介绍威胁检测相关的工作和工作方向。个人水平有限，如有错误及时评论指出。 AWS 基础 为了方便新接触云的师傅，还是要先讲一下AWS的基础和环境搭建。首先个人研究，需要准备一张虚拟信用卡，然后去官网需要注册一个AWS账户，建议不要选中国区，选到海外，国内有很多限制。等注册完成登录了，就会进入类似下面这样的一个页面，相信大多数人和我一样，以前从来没接触过这玩意，面对一堆服务图标，绝对是一脸懵逼的状态 让我们慢慢熟悉一下基础概念，如果有系统架构或域渗透相关经验理解起来就会很快，没有也不慌，我们慢慢理解基础概念。 云计算概念 谈云总是离不开这几个概念-IaaS/PaaS/SaaS，方便新人入门就拿实现“发邮件”的来做类比： 基础设施即服务（IaaS）：IaaS提供服务器给你，你需要自己开发或购买邮件系统，自己搭建起来配置使用，自己运维管理，非常灵活，但也面临运营维护成本过高的问题。相当于你买了基础的地皮，提供了基础计算环境，但是搭建什么样子的建筑全看厂商自己。 平台即服务（PaaS）：PaaS相当于提供一个邮件平台，但是细节实现还需要开发调用服务的API，完善相关的功能，相比于IaaS就少了维护基础计算环境的问题，节约了一部分成本，对于企业开发来说非常方便。 软件即服务（SaaS）：SaaS相当于直接提供一个软件平台，类似QQ邮件直接注册一个QQ就能使用配套的服务，完全没有开发层面的负担，把软件更新维护交给了厂商实现，虽然大大节约了相关成本，但是也牺牲了开发层面的灵活性。 进入界面，想要探索或者查找服务，可以使用右上角的搜索界面，里面有大量服务分类：存储、计算、物联网等等 刚才截图页面的面板的服务分类从大类分，无非就是刚刚说这三种，虽然页面上的点击功能足够我们大多数交互，但是传统渗透都习惯于使用命令行来和AWS交互，省去了页面点击布局可能变动导致迷惑的问题。 一般来说我倾向使用AWS CloudShell去执行，只需要搜索里面查找点进去即可使用，它里面已经预装了AWS CLI，直接使用了当前的用户会话作为默认登录： 我们可以检查一下AWS的版本信息： aws --version 也可以检查一下当前用户的信息，这个命令相当于系统中的whoami，会返回一个json数据 aws sts get-caller-identity 它会返回三个字段： { "UserId": "AIDASAMPLEUSERID", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/pacutest" } 其中"Arn"字段的全称是Amazon Resource Name，亚马逊资源名称将作为一个唯一的值关联到特定的资源，很明显Arn里面就标注出来了user/pacutest这个用户名。 想要查看当前用户的权限策略可以使用： aws iam list-attached-user-policies --user-name pacutest 看到下面的没有，我们这个用户居然是管理员策略—AdminstratorAccess AdminstratorAccess策略默认可以访问所有资源，相当于超级管理员，这也是用的最多的AWS托管策略,我们阅读文档看看，文档左侧还有很多AWS托管的策略就不赘述了，记不住也没关系，需要用到的时候就查一下。 JSON 策略文档的内容如下,Effect设置为允许，Action和Resource使用统配符星号指代所有资源： { "Version" : "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : "*", "Resource" : "*" } ] } 值得注意的是，AWS的权限策略非常严格，如果没有主动授予查看用户本身的权限，甚至aws iam list-attached-user-policies 自己都是会被拒绝的，这要是放在windows和linux中简直就是不可思议的事情，如果类比到AD，我们有一个普通用户居然不能导出用户名列表，不能查找策略，简直就是瞎了一样，从这一点来看，云的渗透难度远远比AD更大，攻击面更加收敛。 ...