Credential stuffing has been on the rise and you have seen countless stories on your cybersecurity RSS feeds of companies having to conduct public disclosures of breaches. You know it is in the best interest of your US-based company, your US-based customers, and your CISO’s job tenure (you like her leadership style) to keep them out of the headlines. So, you decide to start hunting your custom API for evidence of credential stuffing.
Your mission is to analyze this custom_api_capture.pcapng (click to download) and determine if credential stuffing is occurring!
Possible Answers:
A. Yes, there is evidence of Geo-infeasibility/impossible travel for the customer with the userName of 'jjanicki@socal.rr.com'.
B. No, credential stuffing is not occurring since there is no exfiltration of sensitive data.
C. Yes, there is evidence of Geo-infeasibility/impossible travel for the customer with the firstName of 'Kris'.
D. Yes, packets 26 and 27 have API requests with no HTTP 200 OK or 400 Bad Request.
Before you start
Before you go hunting, here are a couple of hints and tools you could use for your investigation:
- Geo-infeasibility
- Impossible Travel
- Account breach/compromise
Tools:
- Ngrep: limitation – pcap files only
- Linux native tools: sort, uniq and cut
- Tshark: geoiplookup, threat Intel
- Wireshark
- ProfiSight
If you follow the hints, you should land on some of the below resources:
- https://owasp.org/www-community/attacks/Credential_stuffing
- https://www.fireeye.com/solutions/cloud-security.html
- https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-risk-events#impossible-travel-to-atypical-locations
- https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
These resources will help you build your understanding of a credential stuffing attack and its indicators.
Detecting credential stuffing
In the pcap file you can see that there is an example of geo-infeasibility or impossible travel. You will see a Malaysian source IP login as username ‘Kris’ and within 30 seconds later you see a US source IP login as username ‘Kris’.
From the scenario provided, the baseline customer is expected to be coming from a US IP. Therefore, you certainly wouldn’t expect to see it from those two places within 30 seconds. This means answer “C” is the right answer as there is a proof of Geo-infeasibility or impossible travel. The user Kris Kringle is the one who was compromised and being used against the API.
Watch the video below for the solution to the question.
Don't forget to check Wireshark Filters article if you want to learn more about a portable network capture solution that flawlessly integrates with Wireshark or have a look at other Wireshark Filters that our engineers use.
The question was asked by Packet Analysis Hero Brad Palm - Network Analyst and Security Engineer.
