Vantage - HTB Sherlock Writeup (DFIR / Network Forensics)

Challenge Description

A small company moved some of its resources to a private cloud installation. The developers left the redirect to the dashboard on their web server. The security team got an email from the alleged attacker stating that the user data was leaked. It is up to you to investigate the situation.

Difficulty: Very Easy
Category: DFIR / Network Forensics
Evidence Files: web-server_2025-07-01.pcap (15 MB), controller_2025-07-01.pcap (6.9 MB)

Initial Analysis Methodology

Before diving into the challenge questions, the goal is to understand what happened using only the evidence. This section walks through a repeatable approach you can apply to any unknown PCAP - the same steps, in the same order, every time. We have two PCAP files from two different machines. We don’t know yet what those machines are, how they relate to each other, or what happened. The methodology below will answer all three.

Step 1 - Protocol Hierarchy: What kind of machines are these?

The very first thing to do with any unknown PCAP is find out what protocols it contains. This tells you what kind of machine was captured and what kind of activity to expect - before you read a single packet. Wireshark: Statistics > Protocol Hierarchy

📁 web-server_2025-07-01.pcap

Open the web-server PCAP first and go to Statistics > Protocol Hierarchy. Here’s what stands out:

Protocol	Frames	What it tells you
TCP	21,586	Nearly all traffic is TCP-based
HTTP	7,482	A web server - this is almost entirely HTTP
HTML Form URL Encoded	8	Only 8 form submissions out of 7,482 HTTP requests

Why the 8 form submissions matter: The content type application/x-www-form-urlencoded is what browsers send when you submit a login form via POST. Out of 7,482 HTTP requests, only 8 were form POSTs - meaning the vast majority of traffic was automated GETs (scanning/fuzzing), and only a handful were deliberate human interactions (login attempts). That ratio is the first red flag, and you’ve spotted it without reading a single packet. Why 8 and not 4? You might expect 4 login attempts = 4 POSTs. The count is doubled because this machine acts as a reverse proxy: it captures both the external POST from the attacker (117.200.21.26 to 157.230.81.229) and the internally forwarded POST from proxy to backend app (10.116.0.3 to 10.116.0.4). Each login attempt is seen twice in the one capture file. This matters in Step 5 when we filter for login packets.

📁 controller_2025-07-01.pcap

Now open the controller PCAP and check the same view:

Protocol	Frames	What it tells you
HTTP + JSON	626	REST API traffic
MySQL	8,978	Database backend
AMQP	849	Message queue (RabbitMQ)
Data on port 2379	1,418	etcd - distributed key-value store
Data on port 11211	-	memcached - in-memory cache

What can we say from this? The protocol hierarchy alone does not tell you what platform this machine runs. HTTP + MySQL + AMQP + etcd + memcached could be many things - a Django app with Celery workers, a Kubernetes control plane, or any message-driven platform with a database backend. What it does tell you is the general shape of this machine: it’s an application controller node - something that exposes a REST API, stores state in a relational database, coordinates work through a message queue, and uses an in-memory cache. That’s a useful narrowing. The actual platform will become clear in Step 3 when we read the HTTP request paths. The takeaway after Step 1: We have a web server / reverse proxy (almost entirely HTTP) and a multi-service controller node (API + database + message queue + cache). The web-server PCAP has the suspicious traffic volume, so that’s where we focus next.

Step 2 - Endpoints & Conversations: Who’s talking, and how much?

Now we have a rough picture of each machine. Next question: who is communicating with them, and is any of that traffic abnormal? There are two related views in Wireshark that answer this differently:

Statistics > Endpoints > IPv4 - One row per IP, total packets aggregated across all connections. Best for quickly identifying dominant talkers.
Statistics > Conversations > TCP - One row per TCP stream (unique source port to destination port pair). Best for understanding how the traffic is structured.

Start with Endpoints for triage, then drill into Conversations for detail.

📁 web-server_2025-07-01.pcap - Endpoints view

Open Statistics > Endpoints > IPv4 tab and sort by the Packets column (descending):

Address	Packets	% of total	Role
157.230.81.229	21,348	-	Web server (this machine)
117.200.21.26	20,897	97.9%	??? (suspicious)
10.116.0.3	256	1.2%	Internal IP
10.116.0.4	256	1.2%	Internal IP
60+ other IPs	2–243 each	under 1%	Internet background noise

The red flag is immediate: One external IP - 117.200.21.26 - accounts for 97.9% of all traffic. Every other external IP has negligible volume. That ratio alone identifies the attacker before you’ve looked at a single HTTP request.

📁 web-server_2025-07-01.pcap - Conversations view

Now switch to Statistics > Conversations > TCP tab to understand how that traffic is structured. You’ll see approximately 187 rows from 117.200.21.26, all connecting to 157.230.81.229:80, each from a different source port:

Address A	Direction	Address B	Packets	Duration
117.200.21.26:64728	to	157.230.81.229:80	497	22.6s
117.200.21.26:64727	to	157.230.81.229:80	489	22.7s
117.200.21.26:64756	to	157.230.81.229:80	487	22.6s
… 184 more rows …

What this pattern means: 187 parallel TCP connections, all nearly identical in duration (~22 seconds) and packet count (~480–500), all hitting port 80. This is not a human browsing - this is a tool running concurrent threads. Each thread opens its own TCP connection to fire HTTP requests in parallel. Tools like ffuf, gobuster, and dirsearch all behave exactly this way. There are also ~10 smaller streams between 10.116.0.3 and 10.116.0.4:80. These two internal IPs have nearly identical packet counts in the Endpoints view, and their timing aligns with the external wave - this is the hallmark of a reverse proxy chain (e.g., Nginx or Apache fronting a backend app server).

📁 controller_2025-07-01.pcap - What about this one?

We’ll come back to the controller PCAP after we understand the web-server traffic. The methodology is: follow the attacker’s footsteps in order. The web server is where the attack started, the controller is where it escalated. Analysing them chronologically tells a coherent story.

Step 3 - Filter HTTP Requests: What was the attacker doing?

We’ve identified 117.200.21.26 as suspicious. Now let’s see exactly what they requested. Wireshark display filter (in web-server_2025-07-01.pcap):

http.request && ip.src == 117.200.21.26

Tip: To make the packet list more readable, add custom columns. Right-click any column header > Column Preferences > add:

http.host (titled “Host”)
http.request.uri (titled “URI”)
http.user_agent (titled “User-Agent”)

With those columns visible, the pattern jumps out immediately:

#	Host	Method	URI
1024	1.vantage.tech	GET	/
1031	2.vantage.tech	GET	/
1038	a.vantage.tech	GET	/
1052	abc.vantage.tech	GET	/
…	3,579 unique subdomains	GET	/
1072	cloud.vantage.tech	GET	/
-	(User-Agent changes here)
18201	cloud.vantage.tech	GET	/dashboard/
18215	cloud.vantage.tech	GET	/dashboard/auth/login/
18240	cloud.vantage.tech	POST	/dashboard/auth/login/

Two distinct phases are visible:

Fuzzing phase: Thousands of GETs, each to a different *.vantage.tech subdomain, all requesting /. The Host header cycles through a wordlist alphabetically. This is subdomain enumeration.
Exploitation phase: The Host locks onto cloud.vantage.tech and the attacker starts browsing the dashboard manually - navigating to the login page, submitting POST requests.

And here’s where the platform reveals itself. While scrolling through the exploitation-phase requests, you’ll spot URIs like /dashboard/i18n/js/horizon+openstack_dashboard/. That path literally contains the words horizon (OpenStack’s web dashboard) and openstack_dashboard. Remember the controller PCAP from Step 1 that we couldn’t identify beyond “application controller node”? Now we know - this is an OpenStack deployment. The web server is fronting an OpenStack Horizon dashboard, and the controller is the OpenStack control plane behind it. The transition between phases is also visible in the User-Agent column (which we’ll examine next).

Step 4 - Check User-Agents: What tools were used?

User-Agent strings are one of the quickest wins in web traffic analysis. Legitimate browsers all send Mozilla/5.0... headers. Attack tools often identify themselves - either by name or by sending unusual/missing User-Agents. Wireshark (in web-server_2025-07-01.pcap): Click any packet from the fuzzing phase, expand Hypertext Transfer Protocol > User-Agent in the packet detail pane. Two User-Agents appear from the attacker’s IP:

Phase	User-Agent	Meaning
Fuzzing (3,695 reqs)	`Fuzz Faster U Fool v2.1.0-dev`	ffuf - a Go-based web fuzzing tool
Manual browsing	`Mozilla/5.0 (Macintosh Intel Mac OS X 10_15_7) AppleWebKit/537.36 ... Chrome/137.0.0.0 Safari/537.36`	Real Chrome browser on macOS

The pivot moment: The switch from ffuf to Chrome is the exact moment the attacker discovered cloud.vantage.tech returned something interesting (the Horizon dashboard) and decided to explore it manually. To filter for just the non-browser traffic:

http.user_agent && !(http.user_agent contains "Mozilla")

This isolates every request made by tools rather than browsers - useful for quickly spotting automated activity in any PCAP.

Step 5 - Follow TCP Streams: Read the full conversations

So far we’ve been looking at metadata - source IPs, URIs, User-Agents. Now we need to see the actual content of the most interesting requests: what credentials were submitted, what files were downloaded, what the server responded with. Wireshark filter (in web-server_2025-07-01.pcap):

http.request.method == POST && http.request.uri contains "/dashboard/auth/login" && ip.src == 117.200.21.26

Why the ip.src clause is essential: Without it, this filter returns 8 packets, not 4. Because this machine is a reverse proxy, every inbound request from the attacker (117.200.21.26 → 157.230.81.229) is immediately forwarded internally to the backend app server (10.116.0.3 → 10.116.0.4). Both hops are captured in this one PCAP file, so each login attempt appears twice. Adding ip.src == 117.200.21.26 limits results to the original attacker-side packets only, giving you the complete request bodies.

This gives you exactly 4 POST packets - one per login attempt. Click the first one, then right-click > Follow > TCP Stream. What you see in the stream window: Wireshark colours the two sides of the conversation differently. By default, the client’s data (the attacker’s request) is shown in red and the server’s response in blue. The stream shows everything in one continuous scroll: the HTTP request headers, then a blank line, then the POST body, then the server’s response headers, then the response body. The POST body you will see (line-wrapped here for readability):

csrfmiddlewaretoken=UX4dve2DwuDo171EEgnpZaxni395EA5ijYsOoOoHwPUbGqAOKcR7Y4qns2yWIb74
&fake_email=
&fake_password=
&next=%2Fdashboard%2F
&region=default
&username=admin
&password=admin

What each field means:

csrfmiddlewaretoken - Django’s Cross-Site Request Forgery protection token. It rotates with every new session and is not useful for our investigation. Ignore it.
fake_email / fake_password - Honeypot fields that OpenStack Horizon adds to its login form to catch naive credential-stuffing bots. A real browser always leaves them empty. Ignore them.
username / password - The credentials you’re looking for.
region - The OpenStack region name, always default here.

How to tell success from failure: The server’s response appears in blue in the same stream window, immediately below the request. You do not need to read the HTML body. Just look at the first line of the response:

HTTP/1.1 200 OK: the server re-rendered the login page. Login failed.
HTTP/1.1 302 Found with Location: /dashboard/: the server redirected to the dashboard. Login succeeded.

Repeat this for all four POST packets to build the full picture:

Attempt	Credentials	Response	Result
09:39:16	admin / admin	200 OK	Failed
09:39:27	demo / demo	200 OK	Failed
09:39:33	root / root	200 OK	Failed
09:40:07	admin / StrongAdminSecret	302 Found	Success

Reading the OpenRC file download

Filter (in web-server_2025-07-01.pcap):

http.request.uri contains "openrc" && ip.src == 117.200.21.26

One packet matches. Click it, then right-click > Follow > TCP Stream. The request headers are clearly readable in red. You can see the GET to /dashboard/project/api_access/openrc/. Scrolling down to the blue response, the headers confirm:

Content-Disposition: attachment; filename="admin-openrc.sh"
Content-Encoding: gzip

After the headers, the response body is binary garbage (compressed bytes that Wireshark cannot display as text). Do not try to read the file content from the TCP stream window. This is the most common point of confusion for this task. To read the actual file, use Wireshark’s HTTP object export, which automatically decompresses the response:

Go to File > Export Objects > HTTP…
Find the row with admin-openrc.sh in the Filename column.
Click Save, then open the file in a text editor.

The decompressed content confirms everything we’ve identified so far:

export OS_AUTH_URL=http://134.209.71.220/identity
export OS_PROJECT_ID=9fb84977ff7c4a0baf0d5dbb57e235c7
export OS_PROJECT_NAME="admin"
export OS_USERNAME="admin"
export OS_REGION_NAME="RegionOne"
export OS_IDENTITY_API_VERSION=3

This file is the bridge between the two PCAPs: it gives the attacker the controller’s direct IP address (134.209.71.220) and everything needed to authenticate to the OpenStack API without going through the web dashboard. Everything that happens in the controller PCAP after this moment is a consequence of this one download.

Step 6 - Cross-Reference PCAPs: Connect the timeline

This is where the two PCAP files merge into a single story. The question is: does the activity in the web-server PCAP lead to activity in the controller PCAP, and can we prove it? Method: Compare timestamps. Look at when the last meaningful action occurs in the web-server file, then look at when new activity begins in the controller file.

📁 web-server_2025-07-01.pcap: Last meaningful action

The attacker’s last request in this file is the OpenRC file download at 09:40:29 UTC. After that there is no more attacker-initiated traffic in the web-server PCAP.

📁 controller_2025-07-01.pcap: What’s in this file before the attacker arrives?

Open the controller PCAP and apply:

http.request && ip.src == 117.200.21.26

Before 09:41:44 there are zero results. The attacker has no presence in this file yet. Without the filter, the controller PCAP contains only internal background traffic, just the OpenStack services talking to each other. You’ll see periodic POST /v3/lease/keepalive requests from 134.209.71.220 to itself on port 2379 (etcd, a key-value store used internally by OpenStack). These are automated heartbeats with no relation to the attacker. Everything else is MySQL and AMQP traffic between backend services. There is no Horizon dashboard traffic in this file.

The pivot moment

The first packet in the controller PCAP with the attacker’s IP is at 09:41:44 UTC:

GET /identity HTTP/1.1
Host: 134.209.71.220
User-Agent: openstacksdk/4.6.0 keystoneauth1/5.11.1 python-requests/2.32.4 CPython/3.13.5

This is the OpenStack CLI’s initial service discovery call, which is the first thing it does every time you run any openstack command. The attacker is no longer using a browser. They are now running command-line tools directly against the controller using the credentials from the OpenRC file. The 75-second gap between 09:40:29 (OpenRC download) and 09:41:44 (first CLI call) is exactly the time it takes to: open a terminal, run source admin-openrc.sh, enter the password when prompted, and type the first openstack command. The causal chain is unambiguous.

What the attacker sequence looks like in the controller PCAP

Apply this filter to isolate only the attacker’s CLI activity:

http.request && http.user_agent contains "openstacksdk"

The full sequence of commands plays out in order, with timestamps 30–90 seconds apart, at the pace of a human exploring an environment manually:

Time (UTC)	Request	What the attacker ran
09:41:44	`GET /identity`	First CLI command, discovery
09:41:45	`POST /identity/v3/auth/tokens`	Authentication
09:41:45	`GET /identity/v3/services`	List all services
09:42:11	`GET /identity/v3/users`	List all users
09:42:27	`GET /compute/v2.1/servers/detail`	List VMs
09:43:27	`GET /v1/AUTH_9fb84977...?format=json`	List Swift containers
09:43:47	`GET /v1/AUTH_.../user-data?format=json`	List user-data contents
09:44:05	`GET /v1/AUTH_.../employee-data?format=json`	List employee-data contents
09:45:23	`GET /v1/AUTH_.../user-data/user-details.csv`	Download user data
09:45:47	`GET /v1/AUTH_.../employee-data/employee-details.csv`	Download employee data
09:48:02	`POST /identity/v3/users`	Create backdoor user
09:49:15	`PUT /identity/v3/projects/.../users/.../roles/...`	Grant admin role

Each row is a separate openstack CLI command. The fact that every request carries the same openstacksdk User-Agent and the same auth token confirms they all belong to the same session.

Methodology Summary

Every time you open an unknown PCAP, follow this sequence:

Protocol Hierarchy tells you what kind of machine this is
Endpoints tell you who’s suspicious (disproportionate traffic volume)
Conversations tell you how the traffic is structured (parallelism, ports)
Build protocol-specific filters tell you what they did (HTTP paths, DNS queries, SMB shares, RDP sessions, etc.)
Inspect client/application metadata tells you what tool or app generated the traffic (User-Agent strings, protocol banners, client names, request patterns)
Reconstruct key sessions and relevant artifacts tell you the full content and sequence of interesting exchanges (Follow TCP Stream, File > Export Objects > HTTP for compressed responses, key request/response bodies)
Cross-reference timestamps across hosts/files connects activity into one timeline and separates cause from effect

Each step narrows your focus. You go from “I have 24,000 packets” to a complete narrative of the attack, even when the protocol is not HTTP.

Attack Timeline

Time (UTC)	Source PCAP	Event
09:38–09:40	web-server	Subdomain fuzzing with ffuf (3,579 subdomains tested, 3,695 total requests)
09:39:07	web-server	Attacker discovers `cloud.vantage.tech`, switches to Chrome
09:39:16	web-server	Login attempt: admin / admin failed (HTTP 200)
09:39:27	web-server	Login attempt: demo / demo failed (HTTP 200)
09:39:33	web-server	Login attempt: root / root failed (HTTP 200)
09:40:07	web-server	Login attempt: admin / StrongAdminSecret succeeded (HTTP 302)
09:40:29	web-server	Downloads admin-openrc.sh from API Access page
		- 75-second gap: attacker reads file, sources it, enters password -
09:41:44	controller	First direct API call - OpenStack CLI service discovery (`GET /identity`)
09:41:45	controller	Enumerates services and endpoints via Keystone
09:42:11	controller	Lists all users via Keystone (`GET /identity/v3/users`)
09:42:27	controller	Lists compute servers (`GET /compute/v2.1/servers/detail`)
09:43:27	controller	Lists Swift containers - finds 3: dev-files, employee-data, user-data
09:43:47	controller	Lists contents of user-data container
09:44:05	controller	Lists contents of employee-data container
09:45:23	controller	Downloads user-details.csv (28 PII records)
09:45:47	controller	Downloads employee-details.csv
09:48:02	controller	Creates backdoor user “jellibean” with password “P@$$word”
09:49:15	controller	Grants jellibean admin role on the project

Questions & Answers

Task 1: What tool did the attacker use to fuzz the web server?

PCAP: web-server_2025-07-01.pcap
Filter: http.request && ip.src == 117.200.21.26
Where to look: Click any packet from the early GETs to expand Hypertext Transfer Protocol > User-Agent in the packet detail pane. The User-Agent field reads Fuzz Faster U Fool v2.1.0-dev - this is ffuf, a popular web fuzzing tool written in Go.

Answer: ffuf@2.1.0-dev

Task 2: Which subdomain did the attacker discover?

PCAP: web-server_2025-07-01.pcap
Filter: http.request && ip.src == 117.200.21.26 && http.user_agent contains "Chrome" After the ffuf scan, the attacker switched to Chrome and manually browsed to the discovered subdomain. Every Chrome request targets the same Host header value.

Answer: cloud.vantage.tech

PCAP: web-server_2025-07-01.pcap
Filter: http.request.method == POST && http.request.uri contains "/dashboard/auth/login" && ip.src == 117.200.21.26 Four POST packets appear. The response codes distinguish success from failure: HTTP 200 means the login page was re-rendered (failed), while HTTP 302 means authentication succeeded and the server is redirecting to the dashboard. The first three returned 200, and the fourth returned 302.

Attempt	Credentials	Response	Result
1 (09:39:16)	admin : admin	200 OK	Failed
2 (09:39:27)	demo : demo	200 OK	Failed
3 (09:39:33)	root : root	200 OK	Failed
4 (09:40:07)	admin : StrongAdminSecret	302 Found	Success

Answer: 3

Task 4: When did the attacker download the OpenStack API remote access config file?

PCAP: web-server_2025-07-01.pcap
Filter: http.request.uri contains "openrc" && ip.src == 117.200.21.26 The OpenRC file is a shell script that sets environment variables for OpenStack CLI authentication. The attacker downloaded it from Project > API Access > Download OpenStack RC File in the Horizon dashboard. The response header confirms the filename in Content-Disposition as admin-openrc.sh. To read the file content itself, use File > Export Objects > HTTP (the response is gzip-compressed and unreadable in the Follow TCP Stream window). The decompressed file contains the auth URL (http://134.209.71.220/identity), the project ID, and the username - everything needed to pivot from the web server to direct API access on the controller.

Answer: 2025-07-01 09:40:29

Task 5: When did the attacker first interact with the API on the controller node?

PCAP: controller_2025-07-01.pcap
Filter: http.request && http.user_agent contains "openstacksdk" Before 09:40:29, controller API traffic is mostly dashboard-generated background activity. After a 75-second gap (the attacker reading and sourcing the OpenRC file), the first request with the OpenStack SDK User-Agent appears - GET /identity at 09:41:44 UTC - which is the SDK’s service discovery call, always the first thing the CLI does when you run any openstack command.

Answer: 2025-07-01 09:41:44

Task 6: What is the project ID of the default project accessed by the attacker?

PCAP: Both - appears in web-server (OpenRC file) and throughout controller (API URLs)
Easiest source: Export the OpenRC file via File > Export Objects > HTTP (Task 4)

export OS_PROJECT_ID=9fb84977ff7c4a0baf0d5dbb57e235c7

It also appears embedded in dozens of API URLs throughout the controller PCAP: compute usage queries, Swift storage paths (/v1/AUTH_9fb84977...), and networking quota requests.

Answer: 9fb84977ff7c4a0baf0d5dbb57e235c7

Task 7: Which OpenStack service provides authentication and authorization?

PCAP: controller_2025-07-01.pcap
Filter: http.request.uri == "/identity/v3/services" && http.user_agent contains "openstacksdk" Click the matching packet and follow the TCP stream (Follow > TCP Stream). The response body is a JSON service catalog. The entry with "type": "identity" is Keystone - OpenStack’s authentication and authorization service. Every API call hitting the /identity/ path in the controller PCAP is talking to Keystone. The relevant JSON entry:

{"name": "keystone", "type": "identity", "enabled": true, ...}

Answer: Keystone

Task 8: What is the endpoint URL of the Swift service?

PCAP: controller_2025-07-01.pcap
Filter: http.request.uri == "/identity/v3/endpoints" && http.user_agent contains "openstacksdk" Follow the TCP stream on the matching packet. The response body is a JSON endpoint catalog listing all service endpoints. Find the entries with service_id matching the Swift service (f9194820052d4788b09157bf0a0dfdd0). The public-interface endpoint URL is a template:

http://134.209.71.220:8080/v1/AUTH_$(project_id)s

When the $(project_id)s template variable is resolved using the admin project ID from the OpenRC file, the full URL becomes:

Answer: http://134.209.71.220:8080/v1/AUTH_9fb84977ff7c4a0baf0d5dbb57e235c7

Task 9: How many containers were discovered by the attacker?

PCAP: controller_2025-07-01.pcap
Filter: http.request.uri contains "AUTH_9fb84977ff7c4a0baf0d5dbb57e235c7?format=json" && ip.src == 117.200.21.26 One packet matches: the attacker’s GET to the Swift proxy at port 8080 listing all containers. Follow the TCP stream. The response includes:

X-Account-Container-Count: 3 in the headers (confirms the count)
A JSON body listing all three containers:

[
  { "name": "dev-files", "count": 0, "bytes": 0 },
  { "name": "employee-data", "count": 0, "bytes": 0 },
  { "name": "user-data", "count": 0, "bytes": 0 }
]

Answer: 3

Task 10: When did the attacker download the sensitive user data file?

PCAP: controller_2025-07-01.pcap
Filter: http.request.uri contains "user-details.csv" && ip.src == 117.200.21.26 One packet matches: the attacker’s GET to the Swift proxy at port 8080. (You may also see an internal forwarding request from the Swift proxy to the object storage server on a path beginning with /sdb1/ - filter by ip.src == 117.200.21.26 to see only the original request.)

Answer: 2025-07-01 09:45:23

Task 11: How many user records are in the sensitive user data file?

PCAP: controller_2025-07-01.pcap
Method: Follow the TCP stream on the user-details.csv GET packet from Task 10. The response headers confirm:

Content-Type: text/csv
Content-Length: 1367

The response body is the file itself - readable plaintext (Swift object storage does not compress responses). The file contains:

A header row: Full Name,Email,Phone Number
28 data records (John Doe through Zoe Lee), each containing full name, email address, and phone number - personally identifiable information.

Answer: 28

Task 12: What is the username of the new user created for persistence?

PCAP: controller_2025-07-01.pcap
Filter: http.request.method == POST && http.request.uri == "/identity/v3/users" Follow the TCP stream. The request body is a JSON payload sent to Keystone:

{
  "user": {
    "name": "jellibean",
    "password": "P@$$word",
    "enabled": true,
    "default_project_id": "9fb84977ff7c4a0baf0d5dbb57e235c7"
  }
}

The server responded with HTTP 201 CREATED, confirming the account was successfully created. A subsequent PUT request at 09:49:15 then granted this user the admin role on the project.

Answer: jellibean

Task 13: What is the password of the new user?

PCAP: controller_2025-07-01.pcap
Method: Same TCP stream as Task 12 - the password is in the JSON request body in cleartext.

Answer: P@$$word

Task 14: What is the MITRE ATT&CK technique ID for the persistence method?

The attacker created a new user account in a cloud platform (OpenStack Keystone) and granted it administrative privileges. This maps to:

Tactic: Persistence
Technique: T1136 - Create Account
Sub-technique: .003 - Cloud Account

T1136.003 specifically covers adversaries creating accounts in cloud environments (AWS IAM, Azure AD, GCP IAM, OpenStack Keystone) to maintain persistent access, distinguishing it from local account creation (.001) or domain account creation (.002).

Answer: T1136.003

Key Wireshark Filters Reference

Purpose	PCAP	Display Filter
All attacker HTTP requests	web-server	`http.request && ip.src == 117.200.21.26`
Attacker fuzzing traffic only	web-server	`http.request && ip.src == 117.200.21.26 && http.user_agent contains "Fuzz"`
Attacker browser traffic only	web-server	`http.request && ip.src == 117.200.21.26 && http.user_agent contains "Chrome"`
Login attempts (attacker only)	web-server	`http.request.method == POST && http.request.uri contains "login" && ip.src == 117.200.21.26`
OpenRC download (attacker only)	web-server	`http.request.uri contains "openrc" && ip.src == 117.200.21.26`
Direct OpenStack CLI calls	controller	`http.request && http.user_agent contains "openstacksdk"`
Keystone API calls	controller	`http.request.uri contains "/identity/v3"`
Swift account listing	controller	`http.request.uri contains "AUTH_" && http.request.uri contains "format=json"`
CSV downloads (attacker)	controller	`http.request.uri contains ".csv" && ip.src == 117.200.21.26`
User creation	controller	`http.request.method == POST && http.request.uri == "/identity/v3/users"`
Role assignment	controller	`http.request.method == PUT && http.request.uri contains "roles"`

Tools Identified

Tool	Version	User-Agent String	Purpose
ffuf	2.1.0-dev	`Fuzz Faster U Fool v2.1.0-dev`	Subdomain enumeration
Chrome	137.0.0.0	`Mozilla/5.0 (Macintosh Intel Mac OS X 10_15_7) AppleWebKit/537.36 ... Chrome/137.0.0.0 Safari/537.36`	Manual dashboard exploitation
OpenStack SDK	4.6.0	`openstacksdk/4.6.0 keystoneauth1/5.11.1 python-requests/2.32.4 CPython/3.13.5`	API enumeration and data exfiltration

Network Topology

Attacker (117.200.21.26) - macOS, Chrome 137, ffuf 2.1.0-dev
    |
    v  HTTP :80
Web Server / Reverse Proxy (157.230.81.229 / 10.116.0.3)
    |
    v  HTTP :80 (internal forwarding)
OpenStack Controller (134.209.71.220 / 10.116.0.4)
    |- Keystone (Identity)    - port 80  /identity
    |- Nova (Compute)         - port 80  /compute
    |- Neutron (Networking)   - port 80  /networking
    |- Glance (Images)        - port 80  /image
    |- Cinder (Block Storage) - port 80  /volume
    |- Swift (Object Storage) - port 8080
    |- MySQL                  - port 3306 (localhost)
    |- RabbitMQ (AMQP)        - port 5672 (localhost)
    |- etcd                   - port 2379
    '- Memcached              - port 11211 (localhost)

MITRE ATT&CK Mapping

Phase	Technique	Evidence
Reconnaissance	T1595.003 - Active Scanning: Wordlist Scanning	ffuf subdomain enumeration (3,579 subdomains)
Initial Access	T1078.004 - Valid Accounts: Cloud Accounts	Brute-forced admin:StrongAdminSecret on Horizon
Discovery	T1580 - Cloud Infrastructure Discovery	Enumerated services, endpoints, users, VMs, containers
Collection	T1530 - Data from Cloud Storage	Downloaded user-details.csv and employee-details.csv from Swift
Persistence	T1136.003 - Create Account: Cloud Account	Created “jellibean” with admin role

Corrections from Previous Version

The following errors were identified by verifying each claim against the raw PCAP data and have been corrected in this version:

Section	Previous (incorrect)	Corrected
Step 1	No explanation for why “8 form submissions” when there are only 4 login attempts	Added explanation: the reverse proxy doubles every POST - both the external and internal hops are captured
Step 5 login filter	`http.request.method == POST && http.request.uri contains "/dashboard/auth/login"` then “Four POST requests appear”	Added `&& ip.src == 117.200.21.26`, without it the filter returns 8 packets and selecting the wrong one gives the wrong stream
Step 5 POST body	Showed simplified `username=admin&password=admin&region=default`	Shows the real body: includes `csrfmiddlewaretoken`, `fake_email`, and `fake_password` fields
Step 5 OpenRC	Implied the file is readable in the Follow TCP Stream window	Corrected: response is gzip-compressed (binary in stream), use File > Export Objects > HTTP instead
Step 4 User-Agent	Showed partial UA string `Chrome/137.0.0.0`	Shows full UA string including macOS platform: `Mozilla/5.0 (Macintosh Intel Mac OS X 10_15_7) ...`
Attack Timeline	`09:44:27` - “Lists contents of user-data and employee-data containers” (single entry)	Split into two correct entries: `09:43:47` (user-data) and `09:44:05` (employee-data)
Attack Timeline	`09:48:28` - “Grants jellibean admin role on the project”	Corrected to `09:49:15` - actual timestamp verified in the PCAP

Overview

​Vantage - HTB Sherlock Writeup (DFIR / Network Forensics)

​Challenge Description

​Initial Analysis Methodology

​Step 1 - Protocol Hierarchy: What kind of machines are these?

​📁 web-server_2025-07-01.pcap

​📁 controller_2025-07-01.pcap

​Step 2 - Endpoints & Conversations: Who’s talking, and how much?

​📁 web-server_2025-07-01.pcap - Endpoints view

​📁 web-server_2025-07-01.pcap - Conversations view

​📁 controller_2025-07-01.pcap - What about this one?

​Step 3 - Filter HTTP Requests: What was the attacker doing?

​Step 4 - Check User-Agents: What tools were used?

​Step 5 - Follow TCP Streams: Read the full conversations

​Reading the login attempts

​Reading the OpenRC file download

​Step 6 - Cross-Reference PCAPs: Connect the timeline

​📁 web-server_2025-07-01.pcap: Last meaningful action

​📁 controller_2025-07-01.pcap: What’s in this file before the attacker arrives?

​The pivot moment

​What the attacker sequence looks like in the controller PCAP

​Methodology Summary

​Attack Timeline

​Questions & Answers

​Task 1: What tool did the attacker use to fuzz the web server?

​Task 2: Which subdomain did the attacker discover?

​Task 3: How many login attempts did the attacker make before successfully logging in?

​Task 4: When did the attacker download the OpenStack API remote access config file?

​Task 5: When did the attacker first interact with the API on the controller node?

​Task 6: What is the project ID of the default project accessed by the attacker?

​Task 7: Which OpenStack service provides authentication and authorization?

​Task 8: What is the endpoint URL of the Swift service?

​Task 9: How many containers were discovered by the attacker?

​Task 10: When did the attacker download the sensitive user data file?

​Task 11: How many user records are in the sensitive user data file?

​Task 12: What is the username of the new user created for persistence?

​Task 13: What is the password of the new user?

​Task 14: What is the MITRE ATT&CK technique ID for the persistence method?

​Key Wireshark Filters Reference

​Tools Identified

​Network Topology

​MITRE ATT&CK Mapping

​Corrections from Previous Version