Skip to content

Boria PCAP Mining⚓︎

Direct link:



Use the artifacts from Alabaster Snowball to analyze this attack on the Boria mines.

Alabaster Snowball

Hey there! I'm Alabaster Snowball
And I have to say, I'm a bit distressed.
I was working with the dwarves and their Boria mines, and I found some disturbing activity!
Looking through these artifacts, I think something naughty's going on.
Can you please take a look and answer a few questions for me?
First, we need to know where the attacker is coming from.
If you haven't looked at Wireshark's Statistics menu, this might be a good time!


Wireshark Top Talkers

The victim web server is Which host is the next top talker?

Wireshark String Searching

The site's login function is at /login.html. Maybe start by searching for a string.

Status Codes

With forced browsing, there will be many 404 status codes returned from the web server. Look for 200 codes in that group of 404s. This one can be completed with the PCAP or the log file.

Instance Metadata Service

AWS uses a specific IP address to access IMDS, and that IP only appears twice in this PCAP.


Naughty IP⚓︎


Most of the traffic to this site is nice, but one IP address is being naughty! Which is it? Visit Sparkle Redberry in the Tolkien Ring for hints.

Unpack the archive and open the victim.pcap packet capture in Wireshark. Open the Statistics > Conversations menu and sort by Packets on the IPv4 tab. This tells us that was the most chatty external host.

Top talker 1

We can confirm this by extracting and counting all unique IP addresses from the weberror.log file using grep -e '^[0-9].*' weberror.log | cut -d' ' -f1 | sort | uniq -c | sort -r. The same IP address is at the top of the list here as well.

Top talker 2


Alabaster Snowball

Aha, you found the naughty actor! Next, please look into the account brute force attack.
You can focus on requests to /login.html~

Credential Mining⚓︎


The first attack is a brute force login. What's the first username tried?

Now that we have our malicious IP address, we can use the Wireshark display filter http && ip.src == and http.request.uri == "/login.html" and http.request.method == "POST" to only show HTTP POST requests made by host against the /login.html login page.

Brutce force attempts

The HTML Form data for each HTTP POST request shows the submitted username and password values, which is alice for the first set of brute force login attempts. Right-clicking on the username Value field and selecting Apply as Column from the context menu will add these values as a column to the list view, as shown in the previous screenshot.

Username value



Alabaster Snowball

Alice? I totally expected Eve! Well how about forced browsing? What's the first URL path they found that way?
The misses will have HTTP status code 404 and, in this case, the successful guesses return 200.

404 FTW⚓︎


The next attack is forced browsing where the naughty one is guessing URLs. What's the first successful URL path in this attack?

Searching the web logs using grep weberror.log tells us when started making random requests. They can be identified as a large volume of sequential 404 Not Found log entries which appear to start at 16:47:45 on October 5, 2022.

Random requests

Updating the previous command to grep weberror.log | grep -v ' 404 -' will filter out all the 404 noise and allow us to locate the first successful request on or after 16:47:45, which appears to be /proc.

Successful URL



Alabaster Snowball

Great! Just one more challenge! It looks like they made the server pull credentials from IMDS. What URL was forced?
AWS uses a specific IP address for IMDS lookups. Searching for that in the PCAP should get you there quickly.

IMDS, XXE, and Other Abbreviations⚓︎


The last step in this attack was to use XXE to get secret keys from the IMDS service. What URL did the attacker force the server to fetch?

The Instance Metadata Service (IMDS) typically listens on IPv4 address Searching through weberror.log for this IP address and printing a few lines before and after each match using grep -B 2 -A 25 weberror.log tells us that the attacker successfully sent several XXE payloads and gradually worked their way to, which holds the secret key information.


The POST requests responsible for the above log entries can be found in Wireshark by applying an xml display filter. Adding the DTD Tag column by right-clicking on the desired eXtensible Markup Language node and selecting Apply as Column helps us to see all the different XML payloads sent over HTTP before successfully accessing the AWS secrets.

XML Requests



Alabaster Snowball

Fantastic! It seems simpler now that I've seen it once. Thanks for showing me!
Hey, so maybe I can help you out a bit with the door to the mines.
First, it'd be great to bring an Elvish keyboard, but if you can't find one, I'm sure other input will do.
Instead, take a minute to read the HTML/JavaScript source and consider how the locks are processed.
Next, take a look at the Content-Security-Policy header. That drives how certain content is handled.
Lastly, remember that input sanitization might happen on either the client or server ends!