来源

关联漏洞

描述

A hands on lab investigating CVE-2025-39507 from a Tier 1 SOC analyst perspective. Includes log review in Microsoft Sentinel, IP analysis, real world screenshots, and a simple breakdown of a local file inclusion vulnerability in a WordPress plugin.

介绍

# 🧠 CVE Lab: Tier 1 SOC Analyst Simulation  
## CVE-2025-39507 | Local File Inclusion in WordPress Nasa Core Plugin

---

## 📝 Scenario: A Day in the SOC

It’s a regular Monday. I’m logged into the SOC dashboard, reviewing alerts like usual. One comes in that catches my eye:

> **ALERT:** Possible Local File Inclusion (LFI) Attempt  
> **IP Address:** 203.0.113.44  
> **URL:** `/index.php?file=../../../../etc/passwd`  
> **User Agent:** curl/7.81.0

It looks like someone might be trying to access system files by manipulating a URL. My job is to look into it and decide if this needs to be escalated.

---

## 🔎 Background on the CVE

After some quick research, I found this matches a known vulnerability: **CVE-2025-39507**. It affects a WordPress plugin called **Nasa Core** (version 6.3.2 and below). It allows attackers to view sensitive files on the server by changing a file input parameter.

Example:
```plaintext
/index.php?file=../../../../etc/passwd
```

If the plugin doesn’t validate the file input correctly, it’ll just follow whatever path the attacker gives it.

---

## 🛠️ My Tier 1 Investigation

### 1. Checked the Alert in Sentinel

I didn’t write the detection rule, but I reviewed it to understand what triggered the alert. It looks for things like:

- URLs with “../” (path traversal)
- Requests to sensitive files like `/etc/passwd` or `/wp-config.php`
- Scripts or tools in the user agent (like curl or Python)

Here’s a simplified version of the rule:

```kql
CommonSecurityLog
| where RequestURL has "../" 
   or RequestURL has "etc/passwd"
   or RequestURL has "wp-config"
| where DeviceCustomString1 contains "curl" or DeviceCustomString1 contains "python"
| project TimeGenerated, SourceIP, RequestURL, DeviceCustomString1
```

---

### 2. Looked Up the IP Address

I ran a query to see if the IP `203.0.113.44` was trying anything else:

```kql
CommonSecurityLog
| where SourceIP == "203.0.113.44"
| summarize count() by RequestURL
```

Turns out, it also hit other paths like `/admin/`, `/login.php`, and `/wp-config.php`. That told me this wasn’t just a one time request... it was probably a scanner or someone doing recon.

---

### 3. Checked the Timeline

I checked how long the IP had been active in our logs:

```kql
CommonSecurityLog
| where SourceIP == "203.0.113.44"
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
```

It started a few hours ago and was still active recently. So it wasn’t historical noise — this was ongoing.

---

### 4. Escalated to Tier 2

Here’s how I documented it for escalation:

> “Possible LFI scan from IP 203.0.113.44. The request pattern matches CVE-2025-39507. IP accessed 9 unique paths including /etc/passwd and wp-config.php using curl. Behavior suggests automated recon. Recommend Tier 2 review and possible IP block.”

---

## 📸 Screenshots

| # | Description                            | File                                |
|---|----------------------------------------|-------------------------------------|
| 1 | CVE Listing (Patchstack)              | `1_cve_selection_listing.png`       |
| 2 | Patchstack Overview                   | `2_patchstack_cve_overview.png`     |
| 3 | VulDB Vector Example                  | `3_vuldb_exploit_vector.png`        |
| 4 | Azure Kali VM Created                 | `4_kali_vm_deployed.png`            |
| 5 | VM Running Screenshot                 | `5_kali_vm_running_status.png`      |
| 6 | SSH Access to Kali                    | `6_kali_vm_logged_in.png`           |
| 7 | Sentinel KQL Rule Review              | `7_lfi_detection_kql_query.png`     |

All screenshots are located in the `/screenshots` folder.

---

## 🔁 Reflection

Some questions I asked myself as I worked through this:

- What signs in the logs made this alert stand out?
- How can I tell if this is just a scanner or something more serious?
- What else might happen if this LFI attack actually succeeded?
- What’s the right balance between alert fatigue and escalation?

---

## 🔜 What’s Next – Phase 2

Next, I’ll run a safe simulation of this attack in a controlled lab environment using a platform like TryHackMe. The goal is to better understand what this type of activity looks like from the attacker’s side — and what kind of logs it creates.

---

## ⚠️ Disclaimer

P.S. This lab was done in a safe, ethical environment for training purposes only. No real systems were targeted or harmed. Always follow your organization’s rules and never test exploits on systems you don’t own or have permission to test.

---

文件快照

 [4.0K]  /data/pocs/667f09f260c8a4d7d4aa4fb747b771b24ec1a72b
├── [4.5K]  README.md
└── [4.0K]  screenshots
    ├── [406K]  1_cve_selection_listing.png
    ├── [278K]  2_patchstack_cve_overview.png
    ├── [400K]  3_vuldb_exploit_vector.png
    ├── [233K]  4_kali_vm_deployed.png
    ├── [324K]  5_kali_vm_running_status.png
    ├── [209K]  6_kali_vm_logged_in.png
    └── [117K]  7_lfi_detection_kql_query.png

1 directory, 8 files

备注