The Ghost in the Cloud, Writeup
Challenge link: https://learn.hacklido.com/blue-box/the-ghost-in-the-cloud
Category: Network Analysis
Difficulty: Medium
File analyzed: the_ghost_in_the_cloud_1.pcap
Overview
The pcap contains a mix of normal looking browsing traffic (queries to youtube.com, amazon.com, microsoft.com, google.com) hiding a C2 beacon, a DNS tunneling exfiltration channel, and a final upload disguised as a JPEG file. The malicious activity centers around the domain update-helper.cloud and the IP 185.130.5.253.
Analysis Steps
Loaded the pcap with scapy and tshark and filtered by protocol.
from scapy.all import rdpcap
pkts = rdpcap("the_ghost_in_the_cloud_1.pcap")
for p in pkts:
print(p.summary())
This showed the very first DNS query going out to a domain that does not belong with the rest of the normal traffic.
Q1: Suspicious C2 domain
Answer: update-helper.cloud
This is the first DNS query in the capture, standing out from the surrounding legit lookups to youtube.com, amazon.com, microsoft.com and google.com.
Q2: SNI value in the TLS Client Hello
Answer: update-helper.cloud
The TLS session in this capture is opened to 185.130.5.253, the same IP that update-helper.cloud resolves to and the same host used in the plaintext HTTP Host header later in the capture. This confirms the SNI matches the C2 domain.
Q3: Beacon decoded value
Answer: IEX payload
Found in the HTTP request:
GET / HTTP/1.1
Host: update-helper.cloud
User-Agent: SUVYIHBheWxvYWQ=
Base64 decoding SUVYIHBheWxvYWQ= gives IEX payload, short for an Invoke-Expression command being smuggled through the User-Agent header.
Q4: Beacon interval
Answer: 300 seconds
The implant repeatedly sends:
GET /health?token=cGluZw==
Checking packet timestamps for these requests shows each one is exactly 300 seconds (5 minutes) after the last.
Q5 and Q6: Data type exfiltrated via DNS tunneling
Answer: Credit card data
Three DNS queries under the subdomain exfil.update-helper.cloud carry base64 chunks:
| Encoded label | Decoded |
|---|
| Y3JlZGl0X2NhcmRzLnR4 | credit_cards.tx |
| dDo0MTExLTExMTEtMTEx | t:4111-1111-111 |
| MS0xMTEx | 1-1111 |
Concatenated together this reads:
credit_cards.txt:4111-1111-1111-1111
Confirming credit card numbers were being tunneled out over DNS.
Q7: Base64 in User-Agent
Answer: IEX payload
Same string decoded in Q3, found in the User-Agent header of the beacon request to update-helper.cloud.
Q8: C2 server IP
Answer: 185.130.5.253
This is the address update-helper.cloud resolves to, and the same IP receiving the beacon and health check traffic.
Q9: Data hidden in the JPEG upload
Answer: Credit card data
The final packet in the capture carries a payload starting with JPEG magic bytes (FF D8 FF E0), used as cover for uploading the same stolen credit card data already exfiltrated through the DNS tunnel earlier in the session.
Q10: Wireshark filter for long DNS subdomains
Answer:
dns.qry.name and strlen(dns.qry.name) > 30
This flags any DNS query where the subdomain length is over 30 characters, a common indicator of DNS tunneling since legitimate subdomains are rarely that long.
Q11: MITRE ATT&CK technique ID for DNS tunneling
Answer: T1071.004
Application Layer Protocol: DNS. This covers the use of the DNS protocol to carry command and control or exfiltration traffic, matching the tunneling behavior seen in this capture.
Summary
| Stage | Detail |
|---|
| C2 domain | update-helper.cloud |
| C2 IP | 185.130.5.253 |
| Beacon interval | 300 seconds |
| Exfil method | DNS tunneling, then a fake JPEG upload |
| Data stolen | Credit card numbers |
| ATT&CK technique | T1071.004 |
