TryHackMe - APIWizards Breach CFT

-




Task 2: Initial Access

Q1: Which programming language is a web application written in?

  • Answer: Python

  • Detailed Explanation: Inspecting /home/dev/apiservice reveals Python files (such as api.py and config.py). The service relies on Python (using standard libraries or frameworks like Flask/FastAPI) to handle incoming requests.

Q2: What is the IP address that attacked the web server?

  • Answer: 149.34.244.142

  • Detailed Explanation: Reviewing Nginx log files under /var/log/nginx/access.log.1 reveals multiple GET requests containing suspicious URL-encoded payloads originating from 149.34.244.142.

Q3: Which vulnerability was found and exploited in the API service?

  • Answer: OS command injection

  • Detailed Explanation: In api.py, the /api/time endpoint took the tz URL parameter and passed it directly to a system shell function (e.g., os.system or subprocess) without sanitization. This allowed the attacker to append arbitrary OS commands like whoami and id into the web request URL.

Q4: Which file contained the credentials used to privesc to root?

  • Answer: /home/dev/apiservice/src/config.py

  • Detailed Explanation: After gaining command execution, the attacker inspected the server environment. Checking /home/dev/apiservice/src/config.py revealed hardcoded root credentials, allowing them to switch users (su root) or run commands as root.

Q5: What file did the hacker drop and execute to persist on the server?

  • Answer: /tmp/rooter2

  • Detailed Explanation: Inspecting the root user’s .bash_history file showed that once root access was achieved, the attacker downloaded an external payload binary named rooter2 into the world-writable /tmp directory and executed it.

Q6: Which service was used to host the “rooter2” malware?

  • Answer: transfer.sh

  • Detailed Explanation: The wget command in .bash_history showed the full download URL pointing to transfer.sh, a command-line file-sharing service commonly abused by threat actors to quickly host temporary tools.

Task 3: Further Actions

Q1: Which two system files were infected to achieve cron persistence?

  • Answer: /etc/crontab, /etc/environment

  • Detailed Explanation: The attacker edited /etc/crontab to schedule an environment variable execution ($SYSTEMUPDATE) at 04:20 daily. To obfuscate the actual payload, they defined $SYSTEMUPDATE inside /etc/environment (a system-wide configuration file) to execute a Bash reverse shell script.

Q2: What is the C2 server IP address of the malicious actor?

  • Answer: 5.230.66.147

  • Detailed Explanation: Decoding the payload string assigned to $SYSTEMUPDATE in /etc/environment revealed a reverse shell command attempting an outbound connection to 5.230.66.147.

Q3: What port is the backdoored bind bash shell listening at?

  • Answer: 3578

  • Detailed Explanation: Running ss -tulnp displays listening sockets and associated process names. An active nc (Netcat) process was found listening locally on port 3578 (dynamically calculated in script via 1786*2+6).

Q4: How does the bind shell persist across reboots?

  • Answer: Systemd Services

  • Detailed Explanation: Rather than relying solely on cron, the attacker created a custom systemd service file so that Linux automatically launches the Netcat bind shell process on system startup.

Q5: What is the absolute path of the malicious service?

  • Answer: /etc/systemd/system/socket.service

  • Detailed Explanation: System-level custom services are stored in /etc/systemd/system/. Inspecting socket.service showed a unit configuration running /bin/bash piped through Netcat on port 3578.

Task 4: Even More Persistence

Q1: Which port is blocked on the victim's firewall?

  • Answer: 3578

  • Detailed Explanation: Checking active firewall rules with iptables -L revealed an explicit DROP rule targeting incoming traffic on port 3578. The attacker did this to prevent other scanners/actors from discovering their bind shell while keeping it local for port-forwarding or internal access.

Q2: How do the firewall rules persist across reboots?

  • Answer: /root/.bashrc

  • Detailed Explanation: Standard iptables rules clear on reboot. The attacker appended the iptables drop command directly into /root/.bashrc, ensuring the firewall rule is re-applied every time a root shell session starts.

Q3: How is the backdoored local Linux user named?

  • Answer: support

  • Detailed Explanation: Inspecting /etc/passwd for recently created accounts showed a stealthy user named support, intended to blend in with legitimate system maintenance accounts.

Q4: Which privileged group was assigned to the user?

  • Answer: sudo

  • Detailed Explanation: Running groups support confirmed the user was added to the sudo group, granting complete password-backed or passwordless administrative privileges.

Q5: What is the strange word on one of the backdoored SSH keys?

  • Answer: ntsvc

  • Detailed Explanation: Checking /root/.ssh/authorized_keys revealed an attacker-controlled public SSH key containing the custom comment ntsvc at the end.

Q6: Can you spot and name one more popular persistence method?

  • Answer: SUID binary

  • Detailed Explanation: Setting the SUID (Set User ID) bit on an executable allows low-privilege users to execute that binary with the file owner's privileges (in this case, root).

Q7: What are the original and the backdoored binaries from question 6?

  • Answer: /usr/bin/bash, /usr/bin/clamav

  • Detailed Explanation: Listing all SUID files using find / -perm -4000 -type f 2>/dev/null flagged /usr/bin/clamav. Verifying the package with dpkg --verify clamav confirmed that the legitimate ClamAV antivirus binary was overwritten with a copy of /usr/bin/bash.

Q8: What technique was used to hide the backdoor creation date?

  • Answer: timestomping

  • Detailed Explanation: The attacker modified file timestamp metadata (mtime/atime) using commands like touch -t to align malicious file creation dates with legitimate system files, evading basic chronological forensics queries.

Task 5: Final Target

Q1: What file was dropped which contained gathered victim information?

  • Answer: /root/.dump.json

  • Detailed Explanation: A hidden Base64-encoded file created by the rooter2 malware script. Upon decoding, it contained automated system enumeration data (OS info, IP addresses, running processes).

Q2: According to the dropped dump, what is the server's kernel version?

  • Answer: 5.15.0-78-generic

  • Detailed Explanation: Extracted directly from field C1 inside the decoded .dump.json file, revealing exact OS kernel specs.

Q3: Which active internal IPs were found by the “rooter2” network scan?

  • Answer: 192.168.0.21, 192.168.0.22

  • Detailed Explanation: Field C2 in the decoded JSON file stored the results of an internal ARP/ping scan, identifying two live hosts on the internal network segment.

Q4: How did the hacker find an exposed HTTP index on another internal IP?

  • Answer: nc -zv 192.168.0.22 1024-10000 2>&1 | grep -v failed

  • Detailed Explanation: Checking .bash_history showed the attacker used Netcat in zero-I/O port-scan mode (-zv) against host 192.168.0.22 across ports 1024–10000, filtering out failed attempts to spot open custom HTTP ports.

Q5: What command was used to exfiltrate the CDE database from the internal IP?

  • Answer: wget 192.168.0.22:8080/cde-backup.csv

  • Detailed Explanation: After locating an unauthenticated web server on port 8080 of 192.168.0.22, the attacker ran wget to pull down the cardholder data environment backup file cde-backup.csv.

Q6: What is the most secret and precious string stored in the exfiltrated database?

  • Answer: pwned{v3ry-secur3-cardh0ld3r-data-environm3nt}

  • Detailed Explanation: Inspecting the contents of the exfiltrated cde-backup.csv file revealed the final TryHackMe flag embedded inside the sensitive database fields.

Comments

Post a Comment

Popular posts from this blog

TryHackMe - Typo Snare Threat Hunter Simulator (medium level)

-
Image
  Threat Hunt Walkthrough The "Typo Snare" scenario on TryHackMe is a fantastic real-world simulation of a sophisticated, multi-stage attack. It starts with a simple mistake and escalates to a full domain compromise, culminating in ransomware. This post will walk you through the entire attack chain, phase by phase, showing you how to find each piece of evidence using Elastic KQL queries. Phase 1: Initial Access & Execution What Happened: The attack began when the user perry.parsons on workstation WKSTN-03 needed a 7-Zip tool. He googled it, clicked a typosquatted link ( 7zipp.org ), and downloaded a trojanized installer. This installer executed a PowerShell script ( 7z.ps1 ) directly from the attacker's server to establish the initial foothold. How to Find It: You are looking for a PowerShell process that was likely spawned by a browser and contains a command to download and execute a script ( iwr for Invoke-WebRequest and iex for Invoke-Expression ). KQL Query...
Read more

TryHackMe - Matryoshka CFT

-
Image
  Full Walkthrough — Matryoshka Containment Unit Matryoshka Containment Unit is a Docker/container escape challenge that teaches: Docker socket abuse Privileged container escalation Shared volume abuse Remote code execution between containers Namespace escape to the host system Below is the complete attack chain from the first flag to the host flag. 1. Initial Enumeration You started inside the level1 container and performed basic Linux/container enumeration. Commands: ls -la cat /proc/1/cgroup find / -perm -4000 2 >/dev/null find / -name docker.sock 2 >/dev/null What you discovered .dockerenv This indicated you were inside a Docker container. /var/run/docker.sock This was the key vulnerability. Docker socket exposure means: the container can communicate directly with the Docker daemon running on the host anyone with access to the socket can effectively control Docker on the host machine This is one of the most dangerous Docker misconfigurations. 2. V...
Read more

TryHackMe - Threat Hunting Simulator - Health Hazard

-
Image
  Scenario overview After months of juggling content calendars and caffeine-fueled brainstorming, co-founder Tom Whiskers finally carved out time to build the company’s first website. It was supposed to be simple: follow a tutorial, install a few packages, and bring the brand to life with lightweight JavaScript magic.   But between sleepless nights and copy-pasted code, Tom started feeling off. Not sick exactly, just off. The terminal scrolled with reassuring green text, the site loaded fine, and everything looked normal.   Then, a strange file appeared on the system. No one could say where it came from. It wasn’t part of the tutorial, didn’t match any known dependencies, and didn’t even run.   It just waited.   Scenario objectives Determine how a threat actor first gained a foothold on the system. Identify suspicious activity that may point to the initial compromise method. Investigate signs of malicious execution following the initial access. Analyse the logs ...
Read more