大约两年前，我辞去了全职红队操作员的工作。然而，它仍然是一个心仪的专业领域。几周前，我重新拾起昨日的爱好：绕过/逃避端点保护解决方案。

在这篇文章中，我们将探讨一系列可用于绕过行业领先的企业端点保护解决方案的技术。由于这纯粹是为了（道德）红队队员等安全从业者教育之用，因此我决定不公开发布源代码。本文旨在让安全行业的广大读者能够全面了解相关技术，而不是深入研究每种技术的细节。相反，具体的技术细节，读者可以参阅参考资料部分列出的文章。

在模拟对抗过程中，“初始访问”阶段的一个关键挑战，就是绕过企业端点上的检测和响应能力 (EDR)。由于商业的c2框架向红队队员提供的是不可修改的shellcode和二进制文件，所以，安全解决方案供应商会提取这些代码的特征（或者成为签名），那么，为了植入这些代码，红队就必须对其特征（静态和行为特征）进行必要的混淆处理。

一般的shellcode加载到内存都是通过LoadLibrary和GetProcAddress来获取函数进行shellcode加载，亦或是通过VirtualAllocEx远程申请一块空间来放入shellcode的地址进行加载。为了隐蔽，攻击者通常会通过PEB找到InLoadOrderModuleList链表，自己去定位LoadLibrary函数从而规避杀软对导入表的监控。攻击者先把shellcode加密，在写入时解密存放到内存空间，使用基于文件检测的方法，是无能为力的，那么这种无落地的方式，最终都会在内存中一览无余。

本文针对Struts2一些经典漏洞进行分析和梳理。为什么要分析struts2这些略久远的漏洞呢？最近热议的Spring jdk9 漏洞，其中涉及到Struts2+类加载器漏洞的利用方式，由此有了重新梳理Struts2历史漏洞的想法。漏洞虽然是过去的，但知识点永远是知识点。希望通过对Struts2的一些经典漏洞的分析，获取新的认识和知识。

这里探索了很多方式，勘误之前的启动方式实际上存在一些问题，这里终于探索到了最完备的musl 调试环境，这里特别感谢我的学弟gxh为勘误做出的贡献。
算是musl 学习的正式终结。

这是一篇NDSS 2021年发表的论文，相关的代码也已经开源，应该是目前比较全面的研究第三源安全的论文，刚好最近也在做软件供应链安全相关的事情，趁着五一假期翻译了一下。很巧的是OpenSSF(SASL也是它们的项目之一)也在4月28号也发布了一篇文章也在号召社区一同来做动态检测，也在Github上开源了相关代码，OpenSSF目前开源的项目只做了安装和导入时候的动态检测，相对简单一些。

我们知道在x64里面，从3环进入0环会调用syscall，那么如果是32位的程序就需要首先转换为x64模式再通过syscall进入0环，这里就会涉及到一系列64位寄存器的操作，我们通过探究其实现原理来达到隐藏数据和反调试的效果。

攻与防都是相对的，只有掌握细节才能更好的对抗。

首先，我们来整体了解一下实际用户请求访问域内某个服务时会经过哪些步骤：

1、用户将AS-REQ数据包发送给KDC（Key Distribution Centre，密钥分发中心，此处为域控），进行身份认证。
2、KDC验证用户的凭据，如果凭据有效，则返回TGT（Ticket-Granting Ticket，票据授予票据）。
3、如果用户想通过身份认证，访问某个服务（如CIFS），那么他需要发起（Ticket Granting Service，票据授予服务）请求，请求中包含TGT以及所请求服务的SPN（Service Principal Name，服务主体名称）。
4、如果TGT有效并且没有过期，TGS会创建用于目标服务的一个服务票据。服务票据使用服务账户的凭据进行加密。
5、用户收到包含加密服务票据的TGS响应数据包。
6、最后，服务票据会转发给目标服务，然后使用服务账户的凭据进行解密。

说起来挺早就看到了这个比赛，后来比赛开始群友又在群里推了一下，不过第一天喵喵从早到晚上了一天课，深夜才来瞄了一下题目。

总体而言整个题目有点像个剧情，类型偏向 Misc 和 Web，正好就合喵喵胃口了。由于有的题目脑洞有点大，再加上后面还有课以及其他事情，一般是半夜在看题，以至于想不通怎么做挺难受的睡不着，直到22号下午才把所有题目 AK，最后排名第17。

唉，看了看榜首的 ha1c9on、Yoshino-s 等大师傅都挺熟悉了，他们第一天晚上就 AK 了 Orz，喵喵还是太菜了。

那下面就来记录一下解题的过程吧，大部分边做边写的，可能包含一些误导性的内容，希望各位师傅不要在意。

常规的shellcode注入一般是通过VirtualAllocEx,WriteProcessMemory 和 CreateRemoteThread 来实现的，但是这种方式是被安全软件重点监控的，同时微软提供的ETW接口也是可以轻易检测出上述方式进行代码注入的痕迹。本文的核心是讲解怎么利用具备 RWX-S 权限且自身有签名的白DLL进行一种比较隐蔽的shellcode注入，
并讲解具体的代码实现以及在写代码实现的过程中遇到的坑。本方法是由文章提出的：https://billdemirkapi.me/sharing-is-caring-abusing-shared-sections-for-code-injection/ ，详情可以参考此文章。

本文将回答下面几个问题：

1. CodeQL能否找到log4shell这个漏洞
2. 如何基于log4j-api-2.14.1.jar和log4j-core-2.14.1.jar创建CodeQL database
3. 如何基于CodeQL进行调用图分析
4. CodeQL如何解析虚拟函数调用
5. 如何对CodeQL的污点分析进行debug

目录

• 内网渗透 -- NTLM 反射分析及土豆家族
• 前置知识点
• Windows SSP&SSPI
  • SSPI和SSP如何工作
  • NTLM SSP 原理(NTLM 身份验证协议)
  • Integration with SMB
  • LmCompatibilityLevel
• Signing
  • LDAP 签名
  • Negotiation
• 土豆家族分析
• 原理讲解
  • 如何利用
• 历史土豆分析
  • Origin Potato_MS08-068 (土豆始祖漏洞)
  • MS16-075_HOT Potato (MS08-068的变种)
  • Rotten Potato (MS16-075的变种)
  • Juicy Potato (MS16-075的变种)
  • Sweet Potato_Juicy Potato衍生版本
  • PrintSpoofer
  • RoguePotato
  • CVE-2019-1384_Ghost potato
  • 参考

将自己学习的PE文件结构进行总结形成文章这件事情，一直躺在我的Notion TodoList里，但是一直是未完成的状态哈哈，拖了那么久也该让它状态变成已完成了。