提交说明
This commit is contained in:
duckpigdog
+12
-16
@@ -6,32 +6,28 @@ Web 配置文件通常包含连接数据库、调用第三方服务（API Key）
|
||||
|
||||
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` 目录 | 数据库连接配置 |
|
||||
|
||||
|
||||
| **`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 管理后台的用户名和密码**，一旦获取，可直接控制应用服务器 |
|
||||
| 目标文件 | 常见路径 | 敏感信息 |
|
||||
| ---------------------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------- |
|
||||
| **`.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 管理后台的用户名和密码**，一旦获取，可直接控制应用服务器 |
|
||||
+13
-14
@@ -1,24 +1,23 @@
|
||||
### 请说明 MSF 的扫描模块与 Nmap 或 FScan 相比，在隐蔽性和灵活性上的优势和劣势
|
||||
### 如果目标站点开启了 WAF 或对高频扫描进行了封禁，你会怎么获取敏感路径
|
||||
|
||||
**隐蔽性**
|
||||
**高级搜索引擎语法**：
|
||||
|
||||
在隐蔽性方面，**MSF 模块**通常比原生扫描器更具优势，因为它工作在**应用层（L7）**
|
||||
- 使用Google或Bing的高级语法搜索目标域名下的遗留路径
|
||||
- 例如：`site:target.com intitle:"index of"`（查看目录列表）
|
||||
|
||||
- **MSF 的优势：** MSF 的辅助模块模仿的是**真实的客户端与服务器的协议交互**，例如发送一个标准的 HTTP GET 请求来获取版本信息，或者尝试一个正常的 SMB 登录。这种流量看起来更像**正常的业务通信**，能够更好地**规避 IDS/IPS 对原始网络包（Raw Packets）的检测**。此外，MSF 模块通常是针对**特定目标或任务**进行单次、精准的验证，不容易被发现
|
||||
- **原生扫描器的劣势：** **Nmap** 和 **FScan** 主要依赖于发送 **L3/L4 层的原始数据包**（如 SYN/ACK、ICMP）。尽管 Nmap 支持多种隐蔽扫描技术（如 FIN、Xmas），但这种**裸包扫描的特征**非常明显，很容易被专业的流量分析工具和 IDS/IPS 标记为**恶意扫描行为**。它们默认往往进行**大范围、多端口的全面扫描**，容易被发现
|
||||
**网络空间搜索引擎**：
|
||||
|
||||
****
|
||||
- 利用 Fofa、Shodan、ZoomEye 等平台。它们会定期扫描全网并存储历史数据。通过这些平台，我们有时能直接看到目标服务器上曾经开放的端口、目录结构，甚至是一些已经被删除但依然存在于缓存中的敏感文件
|
||||
|
||||
**灵活性**
|
||||
**JS 爬取**：
|
||||
|
||||
在灵活性方面，MSF 的优势体现在**流程整合**和**快速定制**上，而 Nmap/FScan 则体现在**扫描深度**上
|
||||
- 手动或使用工具（如`Web-Recon`）深度爬取目标网站的 JavaScript 文件
|
||||
- 现代前端框架（如React、Vue）会将 API 接口、后台路径、隐藏参数硬编码在 JS 文件中
|
||||
|
||||
**流程整合与定制（MSF 优势）**
|
||||
**GitHub 搜索**：
|
||||
|
||||
- **MSF 的巨大优势：** MSF 提供了**一站式的渗透测试流程**。扫描模块的输出（如发现的服务版本或弱口令）可以**直接无缝地作为利用模块（Exploit）的输入**，实现了**信息收集、漏洞利用到后渗透的自动化衔接**。这种**功能整合性**是 Nmap/FScan 无法比拟的，后者需要手动导入数据
|
||||
- **MSF 的定制优势：** MSF 模块基于 **Ruby** 脚本语言编写，结构清晰。这使得渗透测试工程师可以**快速、轻松地修改**现有模块的协议交互逻辑、添加自定义的指纹识别，或者整合自己的混淆技术，**定制和迭代效率极高**
|
||||
- 搜索目标公司员工的代码提交记录。有时候员工会将包含敏感路径的配置文件错误地提交到公开仓库
|
||||
|
||||
**扫描深度与覆盖（Nmap/FScan 优势）**
|
||||
**分析历史DNS记录**：
|
||||
|
||||
- **原生扫描器的巨大优势：** **Nmap** 是业界公认的**端口扫描之王**，在**网络发现**和**全面资产识别**方面具有不可撼动的地位。它支持所有 TCP/UDP 协议的底层裸包扫描，能够穿透各种网络环境，实现**最全面的端口服务覆盖**
|
||||
- **MSF 的劣势：** MSF 模块多是针对**特定应用或漏洞**的验证性脚本，其设计的目的在于“验证是否存在”，而非“发现所有资产”。因此，它在发现**未知或非标准服务**的**深度和广度**上，远不如 Nmap
|
||||
- 通过SecurityTrails等平台查询历史DNS解析记录。很多时候，开发者会使用`dev.target.com`、`test.target.com`或`jenkins.target.com`作为内部测试子域名
|
||||
@@ -1,65 +0,0 @@
|
||||
### 请你详细说说你如何定制或魔改一个 MSF 扫描模块使其能更好地绕过流量分析和 IDS/IPS 的检测
|
||||
|
||||
**一、理解检测原理与目标**
|
||||
|
||||
在动手修改代码之前，**深入理解 IDS/IPS 和流量分析的工作原理**至关重要
|
||||
|
||||
- **IDS/IPS 的检测机制：**
|
||||
- **签名匹配 (Signature-based):** 默认 MSF 模块中的特定字节序列、Header 值（如 User-Agent）或请求结构是已知的签名
|
||||
- **异常检测 (Anomaly-based):** 寻找与正常流量模式（如不常见的端口、非标准协议行为、高并发连接速率）的偏差
|
||||
- **协议解析 (Protocol Parsing):** 检查请求是否符合协议规范
|
||||
- **流量分析的关键点：**
|
||||
- **时间特征:** 快速、连续的扫描行为（高连接速率）
|
||||
- **指纹信息:** 默认的 HTTP Header (如 `User-Agent: Metasploit`), TCP/IP 栈指纹
|
||||
- **载荷特征:** 默认载荷的字节序列、编码方式
|
||||
|
||||
****
|
||||
|
||||
**二、模块定制与魔改的四大策略**
|
||||
|
||||
我主要从 **网络层、应用层、行为模式** 和 **载荷** 四个维度进行魔改
|
||||
|
||||
**1. 流量特征模糊化（应用层/网络层）**
|
||||
|
||||
这部分旨在改变数据包的**静态指纹**，使其看起来更像正常、随机的客户端流量
|
||||
|
||||
| 定制目标 | 具体魔改方法 | 绕过机制 |
|
||||
| -------------------- | ------------------------------------------------------------ | -------------------------------------- |
|
||||
| **User-Agent** | 随机化 **`User-Agent`** 列表，使用主流浏览器和操作系统的真实组合。**避免**使用 MSF 或其他工具的默认值。 | 绕过基于特定 UA 签名的检测 |
|
||||
| **HTTP Header** | 增加、修改或随机化其他 Header，如 `Accept-Language`, `Referer`, `Cache-Control`。**特别是**修改 **`Accept-Encoding`**，以影响响应和请求的压缩 | 模拟真实浏览器行为，使流量分析更困难 |
|
||||
| **TLS/SSL 指纹** | 在使用 HTTPS 扫描时，修改 **JA3/JA4 指纹**。这通常涉及修改底层的 Ruby 库或使用特定的 Sockets 库，以随机化 **Client Hello** 消息中的加密套件、扩展顺序等 | 绕过基于 TLS 握手特征的检测 |
|
||||
| **IP 分片/TCP 乱序** | 引入 IP 分片或 TCP 分段乱序的逻辑（需更底层库支持），但需注意过度使用可能导致目标拒绝连接 | 绕过签名匹配（签名可能无法跨分片识别） |
|
||||
|
||||
|
||||
|
||||
**2. 行为模式降速与随机化**
|
||||
|
||||
这是绕过基于**行为分析**和**速率限制**的关键
|
||||
|
||||
- **延迟与抖动 (Delay & Jitter):**
|
||||
- **增加扫描间隔 (`Sleep`):** 在每次连接请求之间引入随机的延迟，如 2∼5 秒，避免高并发
|
||||
- **引入随机抖动:** 使用非线性的、随机的延迟时间，使扫描速率难以被算法模型预测
|
||||
- **IP 地址轮换 (Proxy Chaining):**
|
||||
- 集成 **Socks 代理链 (如 Tor)** 或购买**高匿名的住宅 IP 池**。在 MSF 模块中，可以通过设置 `Proxies` 选项，或直接修改模块代码以从 IP 池中随机选择出口 IP
|
||||
- **连接失败处理:**
|
||||
- 设置更人性化的重试机制，而不是立即放弃或高速重试，模拟网络不稳定的真实用户行为
|
||||
|
||||
|
||||
|
||||
**3. 代码逻辑混淆与指纹去除**
|
||||
|
||||
直接修改模块的 Ruby 代码，消除内部的**软件指纹**
|
||||
|
||||
- **移除/修改内部标识符:** 许多 MSF 模块会在请求中加入一些微小的、不影响功能的标识符。比如，在 POST 请求体中加入**不影响解析的空格或随机参数**
|
||||
- **重写核心请求函数:** 避免使用 MSF 默认的 `send_request_cgi` 等包装函数，而是使用更底层的 `Rex::Socket` 或其他 Ruby HTTP 库，**完全重构**请求的构造过程，消除函数调用栈和代码结构上的指纹
|
||||
- **自定义协议处理:** 如果是针对非 HTTP 协议的扫描，重写协议解析和构造逻辑，确保只发送扫描所需的最小数据，并使用非标准的字段顺序
|
||||
|
||||
|
||||
|
||||
**4. 载荷定制与动态编码**
|
||||
|
||||
对于渗透模块（如 Exploit），载荷的定制是核心
|
||||
|
||||
- **动态编码:** 不使用 MSF 默认的编码器（如 `shikata_ga_nai`，它们有已知特征），而是使用**自定义或多重异或/加法编码**，并结合**自定义解码存根**
|
||||
- **无文件载荷:** 尽可能使用反射型 DLL 注入或其他内存载荷，避免将恶意文件写入磁盘，绕过基于文件哈希和行为的终端检测
|
||||
- **载荷分块传输:** 将载荷分割成多个小块，通过不同的请求或连接分阶段传输，最后在目标内存中重组，绕过基于载荷完整性的深度包检测 (DPI)
|
||||
Reference in New Issue
Block a user