LetsDefend: Compromised Chat Server — ten questions, one pcap

I recorded this one a lot of times before it worked, so it may look a bit funky. Three days of frustrating moments. We got there.

The first thing I always do is skim the questions before touching anything, to get a sense of what I'm actually looking for. And the moment you see a .pcap in the challenge files, you should already be thinking Wireshark.

The filters, up front#

http.request.method == "GET"
frame contains "login"
http

Those three plus a couple of variations answer nearly everything.

How many GET requests in total?#

Two ways.

http.request.method == "GET"

Wireshark shows the displayed count in the status bar at the bottom once it finishes loading.

Or: Statistics → Protocol Hierarchy, which lays the packet counts out more clearly and respects whatever filter you already have applied.

What is the host value?#

http

Open any HTTP request and read the Host header. It's a header like any other.

What is the CSRF token used at login?#

frame contains "login"

That surfaces everything containing "login". Then sort by time and take the first one — you want the initial login, not a later one.

Open it, go to the cookie/session data, and the token is there. Copy it out.

What is the password of the first user who logged in?#

Follow the HTTP stream on that same login request. Credentials in a plaintext HTTP POST sit right at the bottom of the form body.

Username admin, password admin.

Which is its own lesson, really.

Which user did the attacker create, and how many?#

frame contains "create"

Two results, so two users were created. Double-click into each one and you'll find the username and password at the bottom of the request.

Which account logged into the admin panel?#

This is where reading carefully pays off. The first user we found — admin/admin — is the existing account. The one that logged into the admin panel is the second one, the account the attacker created.

The clue is in the sequence: the attacker used the compromised login, created an account, then used the new account.

What plugin did the attacker use?#

Filter for plugin.

You'll see both a GET and a POST. That distinction matters and it's a nice bit of reasoning:

• GET = downloading the plugin
• POST = uploading it to the server

What commands did the attacker run?#

Filter for command, or go straight for whoami — it's almost always the first thing anyone runs after landing on a box, to find out who they are.

That's exactly what it was: whoami.

For the last command, same filter, scroll to the end of the sequence.

I'll be honest — I got tired at this point and paused the recording until I found it. That happens.

The CVE#

Google the CVE for the platform and you'll find this was a path traversal. Which is why you see ../../ sequences repeated in the requests — climbing out of the intended directory to reach files that should have been off limits.

What did we learn?#

1. Skim the questions before you start. It tells you what to filter for.
2. .pcap in the files means Wireshark. Start there.
3. Statistics → Protocol Hierarchy for counts, every time.
4. Sort by time so you get the first login, not just any login.
5. Plaintext HTTP means credentials are sitting at the bottom of the stream.
6. GET downloads, POST uploads. That difference tells a story.
7. whoami is almost always the attacker's first command.
8. Read the CVE early — it tells you what to search for.

I solve about three of these a day, so if I sound like I'm remembering which one is which, that's why.

Let me know if you have questions, and I'll see you in the next one!