Add files via upload

2025-09-27 22:13:21 +08:00
parent 4c743e346c
commit fdfd4099c7
11 changed files with 494 additions and 0 deletions
@@ -0,0 +1,21 @@
 ### 为什么要搜集目标单位的控股信息
 **1. 股权穿透**
 - **目标**：从目标单位的名称出发，找出其所有具有法律控制权的子公司或参股公司
 - **平台**：使用工商信息查询平台，如 **天眼查**、**企查查**、**爱企查**等
 - **操作**：
  1. 输入目标公司的**法定名称**
  2. 查看其 **“对外投资”** 或 **“股东信息”** 模块
  3. **核心筛选标准**：重点关注持股比例**超过 50%** 的子公司（绝对控股），这些子公司及其资产在法律上等同于目标单位的资产。即使持股比例较低，只要目标单位是发起人或有重大影响力，也应列为潜在资产
 **2. ICP 备案反查**
 一旦获得了子公司或关联公司的完整法定名称，就将其作为新的目标，进行数字资产的反查
 - **目标**：通过子公司名称，找到其所有独立注册和运营的主域名
 - **平台**：**工业和信息化部政务服务平台（ICP 备案系统）**或第三方查询工具
 - **操作**：
  1. 输入**子公司的全称**或其**统一社会信用代码**
  2. 查询该主体名下所有已备案的 **ICP 备案号**
  3. **关键结果**：记录从这些备案号中反查到的所有**顶级域名**（如 `product-a.com`, `finance-svc.cn`）。这些就是你新发现的主域名资产
@@ -0,0 +1,116 @@
 ### 怎么找边缘资产呢
 **1. 证书关联法**
 当一个组织为多个系统使用同一套 SSL/TLS 证书时，它们就共享了一个独特的数字指纹。
 - **指纹**：SSL/TLS 证书的内容（如组织名称、证书颁发机构、证书序列号等）
 - **方法**：
  1. 找到目标**主站**或已知资产的 SSL/TLS 证书
  2. 提取证书中的**组织名称**、**颁发者**或**序列号**
  3. 在网络空间测绘平台（如 **Fofa**、**Censys** 或 **Hunter**）上，使用这些信息进行搜索
 - **案例解析 (案例 1)**：
  > IP资产未备案，用了和主站相同的证书
  - 即使一个 IP 地址**没有 ICP 备案**，但只要它使用了与主站**相同的证书**，就可以被判定为同一组织所有。
  - **Fofa 搜索示例**：你可以使用 `cert="目标证书特征值"` 来查找所有使用该证书的资产，包括那些未公开的 IP
 **2. 标识图标关联法**
 许多组织会为他们的所有内部或外部系统使用一套标准的图标或 Favicon（收藏夹图标）
 - **指纹**：网站的 **Favicon.ico** 文件。由于这个文件的内容是唯一的，可以计算其 **Hash 值**
 - **方法**：
  1. 访问目标**主站**，提取其 Favicon 文件
  2. 计算该文件的 **MD5 Hash**（在 Fofa/Quake 中通常使用 `icon_hash` 语法）
  3. 在网络空间测绘平台中使用该 Hash 值进行搜索
 - **工具与案例解析 (案例 2)**：
  > 无证书、无备案，用的主站的标识性图标 logo
  - 一个没有证书、没有备案的 IP（可能是测试机或内部后台）使用了主站的图标，即刻暴露了它与目标的关联。
  - **Fofa 搜索示例**：使用 **`icon_hash="xxxxxxxxxx"`** 查找所有使用该图标的资产
 **3. Body 内容关联法**
 许多后台系统或测试环境，虽然域名和 IP 看起来毫不相关，但在页面的 HTML **主体（Body）**中会留下内部信息
 - **指纹**：HTML 代码中的**版权声明、公司全称、项目名称、内部工单号**等
 - **方法**：
  1. 在测绘平台中使用 `body` 语法，搜索包含目标单位特有关键字的页面
 - **案例解析 (案例 3)**：
  > body带了目标单位、目标企业的信息，后台也有相关数据但域名、IP均不是目标单位
  - **可能性**：这可能是**供应链资产**（目标公司使用了第三方供应商，但页面中留下了目标公司的名字）或员工私自搭建的系统
  - **搜索示例**：`body="XXX单位" && country="CN"`
 **4. 定位未绑定域名的资产**
 ICP 备案信息不仅包括域名，也包括**纯 IP 地址的备案**。这些纯 IP 资产往往是**直接暴露的**、未被域名解析隐藏的服务器。
 - **指纹**：目标单位的 **ICP 备案名称**
 - **方法**：利用测绘平台对 ICP 备案信息的索引，直接搜索目标单位的备案名称
 - **案例解析 (案例 4)**：
  > 备案了的纯 IP的资产。
  - 这通常是 CDN 节点、API 服务器、或不希望被域名解析的特定服务
  - **Fofa 搜索示例**：使用 **`icp.name="XXX单位全称"`**，平台会返回所有以该名称备案的域名和纯 IP 地址
 **5. 子域名与非主站资产发现**
 被遗忘的旧子域、开发或测试环境往往安全配置较弱。
 - **指纹：** 子域关键词 (`dev`, `test`, `stage`, `beta`, `old`)
 - **方法：** 利用 `site:` 排除主站，并结合 `inurl:` 或 `intitle:` 查找特定关键词。
 - **案例解析 (案例 1)：**
  - **目标：** 发现目标域名下除 `www` 之外的所有子域名。
  - **Google Dork：** `site:target.com -www`
  - **目标：** 查找任何 URL 或标题中包含“测试”或“开发”的页面。
  - **Google Dork：** `site:target.com inurl:test OR inurl:dev intitle:stage`
 **6. 敏感文件与目录暴露**
 错误配置导致敏感文件（如数据库备份、环境配置）被 Google 索引
 - **指纹：** 敏感文件类型或关键词 (`.env`, `.sql`, `bak`, `config`, `password`)
 - **方法：** 利用 `filetype:` 限制文件类型，或利用 `intitle:` 查找开放目录
 - **案例解析 (案例 2)：**
  - **目标：** 发现目标域名下暴露的数据库备份文件和配置文件
  - **Google Dork：** `site:target.com filetype:sql OR filetype:bak OR filetype:env`
  - **目标：** 查找目标域名下的开放目录列表（可能暴露文件结构）
  - **Google Dork：** `site:target.com intitle:"index of" "parent directory"`
 **7. 第三方平台信息泄漏：定位云存储和代码库**
 许多组织会在云存储服务（如 S3）或代码托管平台（如 GitHub）上无意暴露信息
 - **指纹：** 外部平台特征关键词 (`amazonaws.com`, `blob.core.windows.net`, `github.com`) 和敏感信息关键词 (`API KEY`, `secret`)
 - **方法：** 结合外部域名与目标公司名称或目标域名
 - **案例解析 (案例 3)：**
  - **目标：** 查找与目标公司名相关的、被公开索引的 AWS S3 存储桶
  - **Google Dork：** `intitle:"index of" "target-corp-name" "amazonaws.com"`
  - **目标：** 查找目标域名在代码仓库中意外暴露的凭证信息
  - **Google Dork：** `site:github.com "target.com" intext:"password" OR intext:"API KEY"`
 **8. 邮箱系统与服务域名关联**
 企业邮箱的域名通常与企业的主域名保持一致，但有时会是独立的域名用于隔离服务
 - **操作**：在 **爱企查** 等企业信息平台上获取目标的**联系邮箱**（例如 `hr@newcorp.com`）
 - **资产发现**：
  - 邮箱的后缀 (`newcorp.com`) 立刻成为一个新的**主域名**
  - 通过对该域名进行 **MX 记录查询**，可以发现企业邮箱服务器的真实域名或 IP 地址，这可能暴露目标正在使用的邮件服务提供商或自建邮件服务器
@@ -0,0 +1,24 @@
 ### 移动端怎么收集域名呢
 **1. 移动端与新媒体资产关联（绕过备案）**
 许多企业的新媒体和移动端服务由不同的团队或第三方开发，它们的域名往往独立于主站，且防护薄弱
 **A. 微信生态资产（公众号/小程序）**
 这是进行资产收集的**高价值切入点**
 - **操作**：通过 **微信内部的搜索功能**，输入目标单位的**全称、简称或产品名**
 - **资产发现**：
  - **公众号**：许多企业会将公众号的菜单链接到**独立的 WEB 页面**或**自建的 Web 应用**。通过关注公众号并点击菜单栏链接，或抓取其历史文章中的外部链接，可以直接发现新的域名
  - **小程序**：小程序的接口请求通常指向**独立的 API 域名**或**云服务域名**。通过识别小程序，再进行抓包分析，即可获取新的接口和业务域名
 - **扩展思路（同主体关联）**：在小程序中，查看该小程序账号所关联的**其他小程序**。这些关联的小程序大概率也属于目标单位的资产范围，可以作为新的信息收集起点
 **B. APP 应用提取域名（代码泄露）**
 移动应用程序是隐藏 Web 资产的宝库，特别是那些用于 API 交互的域名
 - **操作**：主要通过**反编译**和**信息提取**，而非“硬测”App 本身
 - **资产发现**：
  - **提取 URL**：使用自动化工具（如你提到的 **AppInfoScanner**）或反编译工具，直接从 **APK/IPA 文件**中提取所有硬编码的 URL 链接、IP 地址和 API 端点。这些端点往往是 Web 服务的入口
  - **老版本风险**：许多应用在初期开发时，安全措施（如代码混淆、加壳）较少。如果能找到**旧版本**的 APK，往往能更轻松地提取到清晰、完整的 Web 资产信息
@@ -0,0 +1,37 @@
 ### SSL 证书有什么用，对信息收集有什么帮助
 **SSL/TLS 证书的作用**
 SSL/TLS 证书是网络安全中的基石，它主要有两大核心作用：
 1. **加密通信（机密性）**：证书使得浏览器和服务器之间传输的数据流得以加密，防止数据在传输过程中被窃听或篡改。这是实现 **HTTPS**（HTTP Secure）的基础。
 2. **身份验证（可信度）**：证书证明了你所连接的服务器确实是它声称的那个组织所有。证书中包含的公钥由可信的**证书颁发机构（CA）**签名，用户可以验证该证书是否合法，从而建立对服务器身份的信任
 **如何利用 HTTPS 证书收集子域名**
 对于渗透测试和资产发现而言，SSL/TLS 证书是一个极其宝贵的**公共数据源**。它能帮助我们发现目标企业隐藏的、未公开的或用于测试的子域名。
 **原理：证书透明度（Certificate Transparency, CT）**
 为了防止证书颁发机构（CA）恶意签发证书，行业强制要求所有新签发的 SSL/TLS 证书必须记录在一个**公共、透明的日志系统**中。这些日志被称为 **证书透明度日志（CT Logs）**
 这意味着，一旦目标企业为任何域名（无论是主站还是内部测试子域）签发了证书，这个域名就会被公开记录
 **步骤：利用 CT Logs 发现资产**
 1. **查找平台**：使用提供 CT Logs 搜索接口的平台，最著名且常用的就是 **`crt.sh`**
 2. **输入查询**：在 `crt.sh` 中输入目标企业的**顶级域名**或**公司名称**
 3. **提取域名**：搜索结果将返回所有与该企业相关的证书记录。你需要关注以下两个字段：
   - **Common Name (CN)**：证书的主要名称
   - **Subject Alternative Names (SAN)**：证书的**主题备用名称**。这是一个证书中最重要的资产字段，一个证书通常会保护多个子域名，这些子域名都会被列在 SANs 中
 **案例说明**
 假设你查询了主域名 `example.com`，可能会在 `crt.sh` 的结果中发现一个证书的 SAN 字段包含：
 - `www.example.com` (已知主站)
 - `dev.example.com` (开发环境)
 - `api.internal.example.com` (内部 API 接口)
 - `old.hr-system.example.com` (遗留的 HR 系统)
 这些被发现的子域名，往往是**非公开**或**非标准**的，但它们与主站共享相同的安全身份（证书），因此被确认为高价值的边缘资产
@@ -0,0 +1,66 @@
 ### 源码泄露搜索
 **1. 代码托管平台搜索（主战场）**
 GitHub 和 Gitee 是最常见的代码泄露平台。搜索时需要利用它们的**高级搜索语法**来定位目标
 | 平台             | 搜索目标         | 搜索语法/关键词                                              |
 | ---------------- | ---------------- | ------------------------------------------------------------ |
 | **GitHub/Gitee** | **公司/组织**    | 搜索目标**公司名、产品名、项目代号**。                       |
 |                  | **员工邮箱**     | 搜索 **`@目标域名.com`**，定位到将工作邮箱用于个人 GitHub 的员工。 |
 |                  | **敏感文件**     | `filename:config.php OR filename:database.yml "password"`    |
 |                  | **硬编码凭证**   | `API_KEY OR secret_token target_company`                     |
 |                  | **特定框架文件** | `path:src/main/resources/application.properties "jdbc"`      |
 **实战技巧**：
 - **克隆工具**：使用专门的工具（如 **Gitrob**、**TruffleHog**）对已知的目标代码仓库进行扫描，它们能深度挖掘历史提交记录中的敏感信息，即使代码已经被删除
 - **搜索 Code**：直接在 GitHub 的“Code”选项卡下搜索，而不是在“Repositories”下，以确保搜索范围覆盖所有代码片段
 **2. 公开网盘与存储服务**
 员工可能会将项目代码或敏感文档存储在公开网盘上，以便于分享
 - **平台**：百度网盘、Google Drive、OneDrive 等
 - **方法**：利用搜索引擎的高级语法，将网盘域名与目标公司名称关联
  - **百度网盘**：`site:pan.baidu.com "目标公司全称" OR "项目名称"`
  - **文件类型**：`filetype:zip OR filetype:rar OR filetype:7z "项目名称"`
 **3. Web 服务器源码泄露与备份文件**
 这类泄露是由于服务器配置错误或运维疏忽造成的，通常存在于已知的 Web 资产上
 | 泄露类型       | 常见路径或指纹                              | 搜索方法                                                     |
 | -------------- | ------------------------------------------- | ------------------------------------------------------------ |
 | **Git 泄露**   | 网站根目录下存在 `.git` 文件夹。            | 使用 **GitHack** 或 **Githug** 等工具，尝试下载整个 `.git` 仓库，恢复完整代码。 |
 | **SVN 泄露**   | 网站根目录下存在 `.svn` 文件夹。            | 使用 **dvcs-ripper** 等工具进行恢复。                        |
 | **编辑器备份** | 存在 `~`、`.bak`、`.old`、`.zip` 等扩展名。 | 对已知的 Web 路径进行字典爆破，例如 `index.php.bak`、`config.zip`、`backup2023.tar.gz`。 |
 | **目录遍历**   | 网站开启了目录列表功能。                    | 访问主目录、`uploads`、`download` 目录等，查找是否有可下载的源代码或配置文件。 |
 **4. Pastebin/代码分享网站**
 员工可能会为了调试或寻求帮助，将包含敏感代码或错误日志的代码片段发布到公共网站
 - **平台**：Pastebin、Gist、CodePen、CSDN 等技术论坛或代码分享网站
 - **方法**：
  - 搜索目标**公司名称**、**IP 地址**、**内部域名**或**项目代号**
  - 搜索 API 请求的**错误信息**或**堆栈跟踪信息**，这些信息有时会暴露部分源代码路径或配置信息
 **5. Docker Hub 或镜像仓库**
 如果目标单位使用 Docker 进行部署，错误的配置可能导致 Docker 镜像或配置文件被公开
 - **平台**：Docker Hub、私有或公共的镜像仓库
 - **方法**：
  - 搜索**组织名称**或**项目名称**，查找公开的 Docker 镜像
  - 分析镜像的 `Dockerfile` 或配置层，可能会发现泄露的构建过程和配置参数
 **6. 企业协作与文档平台搜索**
 这类平台是企业员工存放项目文档、会议记录、API 文档甚至代码片段的地方。如果权限设置不当，可能导致内部信息被公开或被搜索引擎抓取
 | 平台                | 搜索目标                 | 搜索方法/关键词                                              |
 | ------------------- | ------------------------ | ------------------------------------------------------------ |
 | **语雀 (Yuque)**    | **项目文档、技术规范**   | 使用搜索引擎高级语法，搜索 `site:yuque.com "目标公司名" OR "项目名称"` |
 | **飞书 (Feishu)**   | **知识库、API 接口文档** | 使用搜索引擎搜索 `site:feishu.cn "目标公司名" intitle:API OR intitle:密钥` |
 | **钉钉 (DingTalk)** | **群文件、内部通知**     | 搜索 `site:dingtalk.com "目标公司名" filetype:xls` 等，查找群文件或共享文档 |
@@ -0,0 +1,49 @@
 ### 空白页面怎么绕过
 在渗透测试中，遇到 **Nginx/Apache/IIS 的默认空白页面**（通常只显示一个“Welcome”或“It works!”）确实很常见。这些页面往往是一个**反向代理的占位符**，或者服务器上存在应用，但**没有正确配置根路由**
 我们不能直接让 Google 告诉我们服务器的文件结构，但可以利用它强大的索引能力，去查找那些**包含应用路径、但尚未被正确映射到根目录**的内部链接或文件
 **1. 查找 URL 中包含内部路径的索引页面**
 目标是找到那些 URL 中已经暴露了应用的文件夹名称或特定文件路径的页面
 - **Google Dork：**
  ```
  site:www.example.com inurl:/app/ OR inurl:/admin/ OR inurl:/client/ OR inurl:/upload/
  ```
 - **解析：**
  - `site:www.example.com`：限定搜索范围在目标网站
  - `inurl:/app/ OR inurl:/admin/ ...`：强制 Google 搜索 URL 中包含这些**常见应用路径**的结果。如果这些路径存在，并且被 Google 索引，那么它们将绕过默认的空白页面，直接显示应用的真实页面
 **2. 查找 HTML 标题中包含应用名称的页面**
 如果应用的开发者为内部页面设置了标题（例如“MyWebApp Admin Panel”），但该应用未正确路由，Google 依然可能索引到它
 - **Google Dork：**
  ```
  site:www.example.com intitle:"login" OR intitle:"dashboard" OR intitle:"admin panel"
  ```
 - **解析：**
  - `intitle:"login" OR intitle:"dashboard"`：查找那些页面标题中包含应用程序常见关键词的结果。如果点击这些结果，往往就能**直接进入应用的登录页面**，从而确定应用的真实访问路径
 **3. 查找特定的应用文件类型（可能暴露路径）**
 许多 Web 应用都会在特定路径下放置配置文件或特定资源文件
 - **Google Dork：**
  ```
  site:www.example.com (filetype:php OR filetype:jsp) inurl:config OR inurl:include
  ```
 - **解析：**
  - `(filetype:php OR filetype:jsp)`：搜索特定的脚本文件
  - `inurl:config OR inurl:include`：进一步限定这些脚本文件位于常见的配置或包含目录下。搜索结果的 URL 往往会暴露完整的应用部署路径
@@ -0,0 +1,44 @@
 ### JS 接口有什么作用
 分析 JS 文件，特别是那些负责 AJAX 调用或定义 API 端点的代码，可以帮助渗透测试工程师获得以下几类关键信息：
 **1. 发现隐藏的 API 端点**
 这是 JS 分析最核心的作用。许多 Web 应用使用前端 JS 来与后端进行数据交互，但这些接口可能并未通过 URL 路径爆破暴露
 - **暴露路径：** JS 文件中可能包含大量的 **硬编码 API 路径**，例如 `/api/v2/user/delete`、`/internal/data/export` 或 `/admin/config/save`。这些路径可能指向未文档化、未被使用的或仅供内部调用的功能
 - **绕过认证：** 发现的某些 API 路径可能在设计时依赖前端的认证逻辑，但后端缺乏严格的权限检查，从而实现**水平或垂直权限绕过**
 - **参数泄露：** JS 代码会暴露 API 调用所需的**参数名称和格式**，例如 `request.data.userId` 或 `request.data.authToken`，为后续的参数篡改和模糊测试提供依据
 **2. 识别第三方服务与集成**
 现代应用大量依赖第三方服务进行分析、存储或身份验证。
 - **API 密钥/Token 泄露：** JS 文件中可能意外地硬编码了用于访问外部服务的敏感凭证，例如 **Google Maps API Key**、**AWS S3 访问凭证**、**支付网关密钥**（Stripe/PayPal Public Key）或 **Firebase 数据库配置**
 - **子域名/域名信息：** 可能会发现指向其他子域名或外部服务的域名，例如用于数据分析的 `analytics.target.com` 或用于文件存储的 `s3-bucket-name.amazonaws.com`，从而扩大资产范围
 **3. 了解应用架构和业务逻辑**
 JS 代码提供了应用如何工作的第一手资料，有助于构造更精准的测试用例。
 - **输入验证逻辑：** 开发者有时会在前端 JS 中实现输入验证（如密码长度、邮箱格式）。了解这些前端规则有助于识别**哪些验证是仅在客户端执行**的，从而绕过验证，直接向后端发送非法数据
 - **版本和框架信息：** JS 文件名或头部注释通常会暴露所使用的 **前端框架（如 React, Vue, Angular）的版本号**，有助于发现已知的客户端漏洞
 **4. 敏感信息和注释泄露**
 开发者在调试或开发过程中留下的信息，可能直接暴露敏感数据
 - **遗留代码和注释：** JS 文件中可能包含已弃用的功能代码或**包含凭证、逻辑说明或调试信息的注释**
 - **环境变量：** 某些构建工具会将 `.env` 文件中的**公开环境变量**打包进 JS 文件中，例如 `REACT_APP_API_URL` 或 `DEBUG_MODE=true`
 **如何在信息收集中利用 JS 接口？**
 渗透测试工程师通常通过以下工具和方法来分析 JS 接口：
 1. **Spidering/爬虫：** 使用 Burp Suite 或 ZAP 等代理工具，在浏览目标网站时**捕获并保存所有加载的 JS 文件**
 2. **关键词搜索：** 对收集到的 JS 文件进行批量关键词搜索，寻找：
   - `api/`、`v1/`、`v2/` (API 版本和路径)
   - `secret`、`key`、`token`、`password` (凭证)
   - `.json`、`.xml`、`.env` (敏感文件)
   - `s3`、`aws`、`firebase` (第三方服务)
 3. **自动化工具：** 使用 **LinkFinder** 或 **JSFScan** 等工具，它们能自动解析 JS 文件，**提取潜在的 URL 路径和域名**，从而大大提高效率
@@ -0,0 +1,42 @@
 ### 一个正在运行的网站访问敏感路径回显 403 的原因有哪些
 **I. 基于客户端与网络限制的原因（绕过/更换）**
 这类限制通常针对请求源头（IP 地址）或请求方式
 | 原因                       | 描述                                                         | 渗透测试对策                                                 |
 | -------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | **1. IP 地址被列入黑名单** | 您的请求 IP 地址被防火墙（如 WAF、IPtables）明确屏蔽         | **更换 IP 地址：** 使用代理、VPN 或云服务器重新发起请求      |
 | **2. 短时间内访问过多**    | 自动化工具（如目录扫描、爬虫）导致您的请求频率过高，触发了限速或拒绝服务保护 | **更换 IP 或调整请求头：** 1. 更换 IP。 2. **修改 User-Agent 或 X-Forwarded-For (XFF) 头**，尝试绕过基于 XFF 的 WAF 拦截。 3. 降低工具的并发请求速率 |
 | **3. DNS 解析或拥塞**      | DNS 解析到错误的地址，或服务器因连接用户过多/繁忙而智能屏蔽请求 | **稍后重试：** 等待服务器负载降低。 **手动更改 DNS：** 尝试使用公共 DNS 服务（如 Google DNS）重新解析 |
 **II. 基于服务器配置错误的原因（绕过/Host 碰撞）**
 这类限制通常是由于服务器配置不当，拒绝了未绑定域名的请求
 | 原因                    | 描述                                                         | 渗透测试对策                                                 |
 | ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | **4. 域名未绑定到空间** | 服务器接收到 IP 地址或未绑定域名的请求，但 Web 服务器（如 Nginx/Apache）拒绝处理。 | **Host 碰撞猜解：** 利用常见的虚拟主机名或**收集到的子域名**，通过修改 HTTP 请求头中的 **`Host` 字段**来尝试匹配正确的虚拟主机配置 |
 | **5. 不正确的协议访问** | 尝试以 HTTP 方式访问强制使用 SSL/TLS 连接（HTTPS）的网址     | **强制使用 HTTPS：** 将请求协议更改为 **`HTTPS`**            |
 **III. 基于文件/目录权限的原因（替换/绕过）**
 这类限制是由于 Web 应用的文件系统或服务器配置阻止了特定操作或文件类型
 | 原因                                    | 描述                                                    | 渗透测试对策                                                 |
 | --------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------ |
 | **6. 文件/目录缺乏执行权限**            | 您访问的脚本文件（如 PHP、JSP）在当前目录下没有执行权限 | **更换目录或后缀：** 1. 尝试将文件上传到其他**具有执行权限**的目录（如 `uploads`）。 2. 尝试使用其他**允许执行的后缀**（如果配置允许） |
 | **7. 在不允许写操作的目录中执行写操作** | 尝试在只读目录中执行文件创建、写入或上传操作            | **更换目录/提权：** 1. 尝试上传到专门的**上传目录**或临时目录。 2. 如果是后渗透阶段，尝试**提权**以更改目录权限 |
 **IV. 基于客户端/认证错误的原因**
 | 原因                     | 描述                                                         | 渗透测试对策                                                 |
 | ------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | **8. 身份验证失败**      | 在需要身份验证的资源中输入了错误的用户名或密码               | **无：** 需要正确的凭证。应尝试**暴力破解**、**凭证填充**或其他**权限绕过漏洞** |
 | **9. 浏览器 SSL 不支持** | 浏览器版本过旧或配置不支持目标网站所需的 SSL/TLS 版本（如 SSL 128） | **更换浏览器/配置：** 使用最新版本的 Chrome、Firefox 或配置支持最新 TLS 协议（如 TLS 1.2/1.3）的工具或库 |
@@ -0,0 +1,14 @@
 ### 目标存在非常牛的杀软导致无法上线 CS，但是有远控软件怎么做
 **策略：利用开源工具窃取远控软件凭证**
 核心思路是寻找那些可以**在目标主机上执行**且**不触发杀软告警**的工具，它们的目的不是恶意利用系统漏洞，而是**读取特定程序的本地存储的配置或内存数据**
 **识别目标远控软件和凭证存储位置**
 首先，需要判断目标主机上运行的远控软件是哪一个（如 **TeamViewer**、**AnyDesk**、**ToDesk** 等），然后研究这些软件是如何**存储其连接密码或配置信息**的
 - **本地配置文件：** 许多远控软件会将密码或连接信息加密存储在本地的配置文件（如 `.conf`, `.ini`, 或**注册表项**）中
 - **内存信息：** 正在运行的远控软件进程的内存中，可能存在解密后的连接密码或会话密钥
 ![](https://pic1.imgdb.cn/item/68d76c41c5157e1a883a0a85.png)
@@ -0,0 +1,44 @@
 ### 怎么收集主机上的所有有关密码的敏感信息
 **1. Mimikatz 抓取系统和 RDP 凭证**
 Mimikatz 是绕过 Windows 安全机制、在内存中抓取明文密码或哈希的旗舰工具
 - **抓取系统登录密码/哈希 (LSASS 内存)：**
  ```
  mimikatz.exe
  privilege::debug
  sekurlsa::logonpasswords
  ```
 - **抓取 RDP/保存的 Windows 凭证 (Credential Manager)：**
  ```
  mimikatz.exe
  privilege::debug
  sekurlsa::credman
  ```
 **2. Wi-Fi 密码抓取**
 作为渗透测试工程师，我们倾向于使用系统自带的命令来减少被检测的风险。
 - **步骤一：导出所有 Wi-Fi 配置文件**
  ```powershell
  netsh wlan export profile key=clear folder=C:\Temp
  ```
  （注意：key=clear 会导出明文密码）
 - **步骤二：提取密码** 读取导出的 `C:\Temp` 目录下的 XML 文件，搜索 `<keyMaterial>` 标签即可找到明文密码
 **3. 针对特定软件凭证 (Xshell, Navicat, 浏览器)**
 对于这些应用软件，通常需要找到对应的**开源解密工具**，这些工具通常托管在 GitHub 上，专门针对该软件的特定加密算法进行逆向和解密
 - **一般操作流程：**
  1. 找到目标软件的配置文件或数据库文件（例如，Navicat 的 `.ncx` 文件、Chrome 的 `Login Data` SQLite 文件）
  2. 将文件下载到本地（如果权限允许）
  3. 使用对应的 GitHub 开源解密工具进行解密
@@ -0,0 +1,37 @@
 ### Web 配置文件信息怎么收集
 Web 配置文件通常包含连接数据库、调用第三方服务（API Key）、存储用户凭证加密密钥等高度敏感的信息。收集这些文件的目标路径和名称是信息搜集的重点
 **1. ASP.NET 网站 (.NET/IIS)**
 ASP.NET 网站的核心配置文件集中在应用的根目录，文件名固定，便于查找
 | 目标文件         | 常见路径       | 敏感信息                                                     |
 | ---------------- | -------------- | ------------------------------------------------------------ |
 | **`Web.config`** | Web 应用根目录 | **数据库连接字符串**（SQL Server/MySQL 等）、**加密密钥**（MachineKey）、**会话状态配置**、自定义应用设置 |
 **2. PHP 网站 (LAMP/LEMP)**
 PHP 网站的配置文件命名较为灵活，通常位于应用的根目录或专门的配置目录中。渗透测试时，需要重点关注包含 `db` 或 `conn` 字样的文件
 | 目标文件           | 常见路径                | 敏感信息                                                     |
 | ------------------ | ----------------------- | ------------------------------------------------------------ |
 | **`config.php`**   | 根目录或 `/config` 目录 | 数据库连接参数、API Key、配置常量、**Redis/Memcached 连接信息** |
 | **`db.php`**       | 根目录或 `/config` 目录 | **数据库主机、端口、用户名、密码**                           |
 | **`conn.php`**     | 根目录或 `/config` 目录 | 数据库连接函数或代码                                         |
 | **`database.php`** | 根目录或 `/config` 目录 | 数据库连接配置                                               |
 **3. Java/JSP 网站 (Tomcat/Spring)**
 Java 应用的配置文件散布在 `WEB-INF/classes` 目录中，它们通常是**属性文件（Properties）** 或 **YAML/XML 格式**。此外，应用服务器本身的配置文件也是重要的目标
 | 目标文件               | 常见路径                                  | 敏感信息                                                     |
 | ---------------------- | ----------------------------------------- | ------------------------------------------------------------ |
 | **`.properties` 文件** | `webapps/[应用名称]/WEB-INF/classes` 目录 | `application.properties`, `jdbc.properties`, `database.properties`, `db.properties` 等，包含**数据库连接、第三方服务配置** |
 | **`.yaml` 文件**       | `webapps/[应用名称]/WEB-INF/classes` 目录 | `application.yaml` 或 `application.yml`，**Spring Boot/Cloud** 应用的核心配置文件，包含所有敏感配置 |
 | **`web.xml`**          | `webapps/[应用名称]/WEB-INF` 目录         | 部署描述符，可能包含**Servlet/Filter 的初始化参数**（如密码） |
 | **`tomcat-users.xml`** | `apache-tomcat/conf` 目录                 | **Tomcat 管理后台的用户名和密码**，一旦获取，可直接控制应用服务器 |