Boria PCAP Mining⚓︎
Direct link: boriaArtifacts.zip
Use the artifacts from Alabaster Snowball to analyze this attack on the Boria mines.
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 10.12.42.16. 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.
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.
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.
boriaArtifacts.zip 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 18.104.22.168 was the most chatty external host.
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.
Aha, you found the naughty actor! Next, please look into the account brute force attack.
You can focus on requests to
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 == 22.214.171.124 and http.request.uri == "/login.html" and http.request.method == "POST" to only show HTTP POST requests made by host 126.96.36.199 against the
/login.html login page.
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.
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
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 188.8.131.52 weberror.log tells us when 184.108.40.206 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.
Updating the previous command to
grep 220.127.116.11 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
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 169.254.169.254. Searching through
weberror.log for this IP address and printing a few lines before and after each match using
grep -B 2 -A 25 169.254.169.254 weberror.log tells us that the attacker successfully sent several XXE payloads and gradually worked their way to
http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance, 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 18.104.22.168 sent over HTTP before successfully accessing the AWS secrets.
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.
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!