Source and scope.
The primary source is my 30-page Hungry Hustle Security Analysis Report for 3014ICT, dated 14 October 2024. I also reviewed the accompanying presentation. Hungry Hustle is an academic scenario: the logs and characters are not evidence of incidents at a real organisation. The case study describes what I searched and observed; it does not claim I deployed any recommended controls.
The seven published images are deterministic crops of the report's appendix: page 24 (all dashboard panels), page 25 (source ranking and session table), page 26 (request timechart), page 27 (mail attachment event), page 28 (script-bearing web request) and page 29 (distinct-client count). The page 27 crop excludes sender and recipient details. No screenshot was reconstructed, and the original report and slides are not published.
Dashboard signals are not incident verdicts.
The dashboard's 1,200,005 “unauthorised attempts” value came from counting access-log events containing 403 across the selected all-time range. A 403 response says access was forbidden, not why the request occurred. The ranked IP chart and geographical aggregation help prioritise follow-up but do not show successful access or hostile intent.
The session table uses IP and user agent with a 30-minute maximum span and five-minute maximum pause. The visible 15.18-minute sessions have only five or six events, so they meet the duration rule rather than the high-volume rule. The request chart is an all-time view spanning a different period from the reported May outage. It is a monitoring visual, not an outage reconstruction.
What the selected events actually show.
The mail event has the subject “SSH Key” and a .ppk attachment, but the visible body says dummy-ssh-key-content. It is evidence of a scenario attachment, not proof that a usable private key was exposed or used. The web search finds a script-shaped string in request logs. No preserved browser execution, reflected response or data transfer establishes successful XSS.
The report records 50,559 distinct client IPs in a GET-request search. Its appendix saved-search title refers to “503 Errors on 20 May 2024,” while the narrative investigates an outage on 19 May. That date/title discrepancy is unresolved. The distinct count alone cannot establish DDoS, causation of downtime or the website's capacity. Server-health and network records would be needed. The presentation says DDoS mitigation was implemented, but neither source shows a deployed control.
Professional follow-up.
A stronger investigation would validate parsed status fields and time zones, correlate web requests with application and infrastructure health, check whether the attachment contained a real key, and reproduce any suspected XSS safely in a controlled environment. These are proposed follow-up checks, not work represented as completed in this project.