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

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.

Alonzo noticed suspicious files on his computer and alerted the newly established SOC Team. The team suspects a Kerberoasting attack within the network. Your role is to validate this suspicion by analyzing the provided evidence.

You are provided with:

1. Security Logs from the Domain Controller

2. PowerShell-Operational Logs from the affected workstation

3. Prefetch Files from the affected workstation

Questions and Analysis

1. Confirming the Date and Time of the Kerberoasting Activity

Approach:

• Use Eric Zimmerman’s tool EvtxECmd to parse the event logs efficiently.

• Load the parsed logs into the Timeline Viewer for analysis.

• Use the following KAPE command to process triage files for faster insights:
  ./kape.exe --msource "C:\Users\Username\Desktop\Triage\Workstation\2024-05-21T033012_triage_asset" --module !EZParser --mdest "C:\Users\Username\Desktop\"

• Filter logs for Event ID 4769 (Kerberos Service Ticket Operations) and focus on user accounts that are not machine accounts. Look for RC4 encryption, as it is often targeted due to its vulnerability to cracking.

2. Identifying the Targeted Service Name

Approach:

• Use the same filtered logs from Question 1.

• Check the Payload Data2 field to identify the service name targeted during the attack.

3. Identifying the Workstation’s IP Address

Approach:

• Continue using the logs filtered for Event ID 4769 and relevant user accounts.

• Locate the Payload field that contains the IP address of the originating workstation.

4. Identifying the Enumeration Script for Active Directory Objects

Approach:

• Analyze the PowerShell logs from the workstation using EvtxECmd to parse and load them into the Timeline Viewer.

• Look for a suspicious PowerShell script execution that enumerates Active Directory objects and identifies Kerberoastable accounts.

• A quick web search of the script name may help confirm its purpose.

5. Determining the Script Execution Time

Approach:

• From the PowerShell logs, filter for the execution details of the identified script.

• Note the timestamp to confirm when the script was executed.

6. Locating the Tool Used for the Kerberoasting Attack

Approach:

• Refer to the Prefetch Files processed through KAPE’s PE Logs module.

• Identify the binary/tool responsible for the Kerberoasting attack.

• The full path of the tool can be extracted from the logs.

7. Determining When the Credentials Were Dumped

Approach:

• Use the same Prefetch File logs as in Question 6.

• Identify the execution timestamp of the Kerberoasting tool by cross-referencing with the log timeline.

By following the outlined steps and leveraging tools like EvtxECmd, Timeline Viewer, and KAPE, this process allows for a thorough investigation and confirmation of the Kerberoasting attack within the network.

Scenario Overview

In this Sherlock Scenario, a rogue elf—spurred by anger after being left off the Nice List and influenced by Krampus—plans to sabotage Christmas by targeting Santa’s critical S3 data archive. The archive contains sensitive information, such as toy blueprints, production schedules, and the all-important gift list. Your mission: investigate the incident, uncover the rogue elf’s actions, and restore the holiday spirit.

Questions and Solutions

1. The Victim Elf shared credentials that allowed the Rogue Elf to access the workstation. What was the Client ID that was shared?

• Approach: Use KAPE with the !EZParse module to parse logs.

• Steps:

  1. Analyze the C drive on the NORTHPOLE machine.

  2. Navigate to:
     \NORTHPOLE-LUMEN\C\Users\lannyl\AppData\Local\IceChat Networks\IceChat\Logs\irc.quakenet.org\Query.

  3. Extract the Client ID from the IRC chat logs.

2. What is the IP address of the Rogue Elf used during the attack?

• Approach: Locate the IP address in the same IRC log file as Question 1.

3. What is the name of the executable the victim ran to enable remote access to their system?

• Approach:

  • The program is ammyy, a remote control software.

  • Use Timeline Explorer to inspect Amcache unassociated file entries for related executables.

4. What time (UTC) did the Rogue Elf connect to the victim's workstation?

• Approach:

  1. Access the Ammyy logs:
     \Blizzard\NORTHPOLE-LUMEN\C\ProgramData\Ammyy.

  2. Extract the timestamp (local time).

  3. Use KAPE logs and Timeline Explorer to identify system time settings in the registry hive.

  4. Convert the timestamp to UTC.

5. The Rogue Elf compromised an AWS Access Key. What is the AWS Access Key ID obtained from the victim's workstation?

• Approach:

  1. Transfer logs to Kali Linux for easier handling of .gz files.

  2. Search the logs for AWS credentials using tools like zcat or grep.

6. Which S3 bucket did the Rogue Elf target during the incident?

• Approach: Refer to the logs or screenshots from Question 5 to identify the targeted bucket.

7. Within the targeted S3 bucket, what is the name of the main directory where the files were stored?

• Approach: The answer is also in the logs or screenshots from Question 5.

8. What time (UTC) did the Rogue Elf disable versioning for the S3 bucket?

• Approach:

  • Filter logs using keywords PutBucketVersioning and Suspended.

9. What is the MITRE ATT&CK Technique ID associated with the method used in Question 8?

• Answer: T1490 – Inhibit System Recovery

10. What time (UTC) was the first restore operation successfully initiated for the S3 objects?

• Approach: Search logs for restore operations.

• Steps: If the first record contains an error, check the next successful operation.

11. Which retrieval option did the Rogue Elf use to restore the S3 objects?

• Answer: Expedited

  • Found in the RestoreRequest logs under GlacierJobParameters.

12. What is the filename of the S3 object that the Rogue Elf attempted to delete?

• Approach:

  • Search for DeleteObject events in the logs.

  • Extract the filename associated with the key.

13. What is the size (MB) of the S3 object that the Rogue Elf targeted in Question 12?

• Approach: Calculate the size in MB.

• Steps:

  1. Use this command:
     find ./ -type f -name "*.json" -exec cat {} + | jq '.Records[] | select(.eventName == "GetObject") | select(.requestParameters.key == "Claus_Operation_Data/gift_lists/GiftList_Worldwide.csv") | .additionalEventData.bytesTransferredOut'

  2. Divide the total bytes by 1024 * 1024 to convert to MB.

14. The Rogue Elf uploaded corrupted files to the S3 bucket. What time (UTC) was the first object replaced during the attack?

• Approach:

  • Search for PutObject events targeting S3 objects.

  • Use this command:
    find ./us-east-1 -type f -name "*.json" -exec cat {} + | jq 'select(.eventName == "PutObject" and .requestParameters.key == "Claus_Operation_Data/gift_lists/GiftList_Worldwide.csv") | {eventTime, eventName, requestParameters}'

  • Find the earliest timestamp.

15. What storage class was used for the S3 objects to mimic the original settings and avoid suspicion?

• Approach: Look for the StorageClass key in the logs.

• Answer: Extract the value for the StorageClass key, which indicates the storage settings.

This write-up utilizes tools such as KAPE, Timeline Explorer, and Kali Linux for efficient log analysis, employing commands like find, cat, and jq to parse and filter JSON data. By methodically investigating logs, artifacts, and metadata, the rogue elf’s actions were uncovered step-by-step, ensuring Christmas was saved.

Santa’s North Pole Operations have implemented the “Cookie Consumption Scheduler” (CCS), a critical service running on a Kubernetes cluster. This service ensures Santa’s cookie and milk intake is balanced during his worldwide deliveries, optimizing his energy levels and health.

1. How many replicas are configured for the flask-app deployment?

Look in the deployment.log file for the entry containing the flask-app:

Path: Cookies\default\describes\deployment.log

2. What is the NodePort through which the flask-app is exposed?

In the same directory, check the services.log for the NodePort:

Path: Cookies\default\describes

3. What time (UTC) did the attacker first initiate fuzzing on the /system/ endpoint?

Inspect the flask-app logs to identify the fuzzing activity on the /system/ endpoint:

Path: Cookies\default\flask-app-77fbdcfcff-2tqgw

4. Which endpoint did the attacker discover through fuzzing and subsequently exploit?

In the same flask-app.log file, look for HTTP 200 responses to find the endpoint that was discovered and exploited.

5. Which program did the attacker attempt to install to access their HTTP pages?

Scroll through the flask-app.log file for POST commands against the endpoint, and check for a commonly used Linux command to fetch HTTP pages.

6. What is the IP address of the attacker?

Since the full curl command isn’t in the flask-app.logs, move to another directory to locate it.

Check the process dump text file for the flask-app in:

Path: Cookies\default\processes

Search for curl until you find the full command.

7. What is the name of the pod that was compromised and used by the attacker as the initial foothold?

Refer to the logs showing the compromise of the initial pod:

Path: Cookies\default\flask-app-77fbdcfcff-2tqgw

8. What is the name of the malicious pod created by the attacker?

Look in the default directory for relevant logs:

Path: Cookies\default\alpine

9. What is the absolute path of the backdoor file left behind by the attacker?

Check the full_journal.log in the host_logs directory, as it likely contains the details of the compromise.

Analyze the logs to find a CMD entry referencing the backdoor file.

The KAPE extraction reveals suspicious files under the C folder. Navigating to Bingle Jollybeard's Documents folder, we find a christmas_slab.pdf shortcut as a potential malicious file.

Tip: take the C folder we were provided and run it through KAPE again, this time running KAPE modules against it. This will speed things up.

Command to Run KAPE:

kape.exe --msource "c:\Users\UserName\Desktop\TRIAGE-L3-BELLS" --module EZParser --mdest "c:\temp" --trace --debug

2. Using the malicious file sent as part of phishing, the attacker abused a legitimate binary to download and execute a C&C stager. What is the full command used to download and execute the C&C Binary?

The Shortcut tab in the christmas_slab.pdf properties reveals the full command used for downloading and executing the C&C Binary.

3. When was this file ran on the system by the victim?

Using PECmd to parse prefetch logs from the C folder in the KAPE output, load the timeline CSV into Timeline Explorer to get the timestamp of execution.

4. What is the MITRE Sub-Technique ID for the technique used in Q1 and Q2?

The phishing attack used a .lnk file masquerading as a .pdf to execute malicious content.

• Sub-Technique ID: T1204.002

• Description: Malicious File Execution via Shortcut.

5. What was the name of the threat actor's machine used to develop/create the malicious file sent as part of phishing?

Run LECmd to extract metadata from the malicious link file.

Command: LECmd.exe -f "path\to\christmas_slab.pdf.lnk" --csv "path\to\output"

Open the CSV in Timeline Explorer and check the Machine ID field.

6. When did the attacker enumerate the running processes on the system?

Identify commands used to enumerate running processes, such as tasklist.exe, by filtering the prefetch CSV for related activity.

7. After establishing a C&C Channel, the attacker proceeded to abuse another legitimate binary to download an exe file. What is the full URI for this download?

Filter .exe and http in Timeline Explorer to reveal a BITS job downloading a file from an IP address.

8. What is the MITRE ID for the technique used in Q7?

• ID: T1197 (BITS Jobs for malicious downloads).

9. In the workshop environment, RDP was only allowed internally. It is suspected that the threat actor stole the VPN configuration file for Bingle Jollybeard, connected to the VPN, and then connected to Bingle's workstation via RDP. When did they first authenticate and successfully connect to Bingle's workstation?

Filter event logs (parsed with EVTCmd and Timeline Explorer) for RDP activity to find the first successful authentication.

10. Any IOCs we find are critical to understanding the scope of the incident. What is the hostname of the attacker's machine making the RDP connection?

Extract the hostname from the username field in the event logs, formatted as ComputerName\UserName.

11. What is the MD5 hash of the file downloaded in Q7?

Analyze the Amcache for records of executed binaries on Windows hosts. Run the KAPE modules against the target using the compound module to generate Amcache CSVs.

• Load the CSVs into Timeline Explorer to retrieve the SHA1 hash.

• Use VirusTotal or a hashing tool to convert the SHA1 to MD5.

12. Determine the total amount of traffic in KBs during the C&C control communication from the stager executable.

Identify the stager executable by checking the target of the malicious PDF link (e.g., christmas-sale.exe).

• Filter the SRUM network logs for the stager.

• Add up sent and received bytes, dividing by 1000 for KB.

13. As part of persistence, the attacker added a new user account to the workstation and granted them higher privileges. What is the name of this account?

Filter event logs for Event ID 4720, which logs user account creation. Look for the account name.

14. After completely compromising Bingle's workstation, the attacker moved laterally to another system. What is the full username used to log in to the system?

Filter event logs in Timeline Explorer for Event ID 4648. Look for the username: NORTHPOLE-BINGL\Bingle Jollybeard and identify target servers.

15. According to the remote desktop event logs, what time did the attack successfully move laterally?

Search for the keyword "nippy" in the RDP logs to find the timestamp of the successful RDP connection.

16. After moving to the other system, the attacker downloaded an executable from an open directory hosted on their infrastructure. What are the two staging folders named?

Navigate to the folder:

TRIAGE-L3-BELLS\C\Users\Bingle Jollybeard\AppData\Local\Microsoft\Terminal Server Client\Cache.

Reconstruct the cache to bitmap images using bmc-tools.py:

bmc-tools.py -s "Path/To/Cache" -d "rdp_output"

Analyze the BMP files for staging folder names.

17. What is the name of the downloaded executable from the open directory?

Reconstruct and analyze the BMP files (as in Q16). Combine image data, if necessary, to identify the executable name.

18. After downloading the executable from Q17, the attacker utilized the exe to be added as a persistence capability. What is the name they gave to this persistence task?

Correlate the reconstructed images (as in Q16 and Q17) to identify the persistence task's name.

19. Same deal, find and correlate.

Similar process to Q16-Q18. Correlate BMP data to identify related artifacts.

20. Determine the total amount of traffic in KBs during the internal lateral movement, which originated from Bingle's workstation to the other machine in the network.

Check SRUM network logs, filtering for Bingle's username and relevant executables (e.g., mstsc.exe). Add sent and received bytes, dividing by 1000 for KB.

Scenario Overview: Our SOC team detected suspicious activity in network traffic, which led to the discovery that a machine was compromised and sensitive company information had been stolen. It's our job to investigate the incident and determine what happened and what data was taken.

1. What is the IP address used for initial access?

The first step is to examine the contents of the provided zip file, which contains a pcap file. We load the pcap file into NetworkMiner, a network forensics tool, to simplify the investigation.

• Solution: Under the Sessions tab in NetworkMiner, we can identify the initial access IP by checking the network traffic. This is the IP that first initiated the connection to the compromised machine.

  

  2. What is the SHA256 hash of the malware?

Next, we need to locate the malware within the pcap file. Using NetworkMiner, we navigate to the Files tab to search for any suspicious files.

• Solution: We find a file with a .gif extension. Although it appears to be an image file, right-clicking and selecting File Details reveals that it is actually a PE file (Portable Executable), which is likely our malware.

• 

  3. What is the Family label of the malware?

After identifying the file as malware, we copy its SHA256 hash and submit it to VirusTotal for further analysis.

• Solution: In VirusTotal, we paste the hash to search for any related information. The Family label provides us with details on which malware family this sample belongs to.

4. When was the malware first seen in the wild (UTC)?

In the VirusTotal Details tab, we can find information about the malware, including when it was first observed in the wild.

• Solution: The First Seen timestamp provides the exact UTC time when this malware was first detected.

• 

  5. The malware used HTTPS traffic with a self-signed certificate. What are the ports, from smallest to largest?

To find out which ports were used for HTTPS traffic, we look at both NetworkMiner and Wireshark. The easiest way to do this is to use NetworkMiner for session details and Wireshark to filter for TLS traffic.

• Solution: In NetworkMiner, we filter for Server Host to identify servers involved in the connection. In Wireshark, we filter for tls traffic to locate the TLS sessions. Cross-referencing the two will show us the port numbers, which are not the standard port 443.

• 

  6. What is the id-at-localityName of the self-signed certificate associated with the first malicious IP?

To gather information about the self-signed certificate, we first filter for the Server Hello in Wireshark.

• Solution: We use the filter ssl.handshake == 11 in Wireshark to locate the handshake packets. Drilling down into these packets will reveal the certificate details, including the id-at-localityName.

• 

  7. What is the notBefore time (UTC) for this self-signed certificate?

The notBefore field in the self-signed certificate indicates when the certificate was valid from.

• Solution: This information can be found in the same location as the answer to question 6, within the Validity section of the certificate.

8. What was the domain used for tunneling?

To determine the domain used for tunneling, we return to NetworkMiner and check the DNS traffic.

• Solution: By navigating to the DNS tab in NetworkMiner, we can find the domain name used by the malware for tunneling purposes.

• 

  Conclusion: By carefully analyzing the pcap file using tools like NetworkMiner and Wireshark, and validating the findings in VirusTotal, we were able to identify critical details about the compromise, including the IP address used for initial access, the malware’s hash and family, certificate details, and the domain used for tunneling.