(repost of Threat Model - Hackathon 26 - 3rd place as we made some major edits to the post.)
TMC Hackathon ‘26 - Team 27 AAR (3rd place)
Long post incoming. I just wanted to share a behind-the-scenes view of how our team approached under time pressure and outside obligations, and my personal experience as team lead.
1 - Preamble
If you’re here for our methodology, or how our team worked, or what frameworks we used and the like, skip this section or just see the report and reflection at the end of this post. However, do stick around if you’re interested in hearing about three students’ first serious foray into threat modeling, and how we managed to come out in 3rd place after a lot of trials and tribulations.
Our journey into threat modeling began with a chance meeting with one of the mentors in this hackathon and a co-founder of the TMC Singapore Chapter, Donavan. We got close over time, and we invited him to a feedback session on our threat-modeling-related work in another hackathon.
It was during this discussion over some wonderful Korean food that we were introduced to the Hackathon. At that point we didn’t yet have a clear plan for how we would approach the problem, or exactly what the hackathon was even about, but we’re always keen to say yes to interesting challenges and build up our skills along the way. We all signed up for it after the discussion.
This was all in mid-January, and due to our busy schedules we proceeded to forget about all this until late January, when we got the email informing us of our team placement, IriusRisk Academy credentials and Slack invite. So began Team 27’s journey.
2 - Early Days
Again due to our busy schedules, we only had time to start considering our strategy the day before our scheduled kickoff meeting with our mentor, Maria. On the day itself, only myself and another of our original 3 team members were present. The discussion was brief, but we got to know our mentor and planned a meeting with the full team to discuss our initial direction.
At this point, it’s important to note that Team 27 was a 5-member team. It was apparently a merger of two separate submissions: ours and another pair who were working adults. We faced several issues at the start. For one, none of us had a clear starting methodology. Did we focus on the three aspects early? Do we draw a basic model of the whole system before diving in on the three aspects? How do we present our findings, given that we’re able to produce any findings at all?
Thankfully, our mentor Maria helped us tremendously at this stage. With her advice, we decided to go with a hybrid model. The final threat model would focus on the top three subsystems (auth, payment, media) that you see in the final submission, but we would spend our time in the first 1.5 weeks understanding and conceptualising the browser game and what we think are its most important subsystems before we generate threats for it.
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
— Abraham Lincoln
So off we were to sharpen the axe. There was, however, one slight issue. The two teammates from the “other” team withdrew. This forced us to rethink our plan quickly and redistribute the workload across three busy students working under a tight timeline. This was our lowest point, but it would only be up from here.
3 - Initial DFD
Please see the reflection and report attached at the bottom of this post for a more detailed deconstruction of the DFD. One of the few contributions made by our withdrawn two members was a basic DFD. When we presented it to our mentor, she pointed out that there were a lot of holes in it, such as there being “miracles” - processes with no input, or “black holes” - processes with no discernible output. Apart from that, our trust boundaries were also quite lacking, and what arrows we drew were unlabeled. We set out to fix that.
Our first goal was to generate a working DFD onto which we can zoom in. The biggest challenge we faced (intended as it may have been) was the rather vague nature of the prompt. While it did mention general descriptions of systems such as media upload, user authentication and external payment services, there was no specific requirement for, well, the specifics of these systems. How were users authenticated? What filtering did uploaded media go through? How did the system implement non-repudiation? These were all questions that had to be answered, which required us to do quite a bit of architectural research and make clearly documented assumptions.
In the end, we settled on and documented the following architectural details:
- Authentication was performed using JWT tokens
- Payment was done through an external service, and confirmed using a webhook back to the API gateway
- Media uploads would first be quarantined before being scanned by various tools and served to the user through a CDN
Another major aspect of DFD drawing is to be clear and efficient. For this, we used the DFD3 standard by Adam Shostack on GitHub. This eliminated confusion among team members on how exactly to represent aspects of the system (e.g. data flow, stores, processes) and allowed us to focus on what truly mattered.
4 - Zooming In
Another discussion with our mentor followed. We began generating threats based on our current model, as it was already quite detailed.
At this point, we locked in the general model and set out to create separate DFD for our assigned portions. This was where the zoom-in DFDs came from. The process and structure was the same, just with a major focus on the part of the system we are threat modeling.
For example, I added more detail to the vague term “background workers” by adding automated analysis of uploaded media for malware and harmful content, and enriched the “moderator” concept through the addition of moderator tools and a data store for moderator approval queues as one would see in real-life systems.
By this point, it was the end of the 19th of February, two days before the deadline. We had finished up our individual DFDs for the systems we picked and started on our list of threats and mitigations.
GenAI turned out to be particularly useful at this stage, as we could use it to partially make up for our relative lack of deep domain familiarity in particular sectors (i.e. knowledge of browser games, server clusters and the like). By using it to generate research leads and following them, we saved valuable time that could be put to use on what truly mattered.
5 - The 20th
On the 20th, we all agreed to “lock in” our DFDs and focus on the final submission. We first agreed on a common framework for describing threats. At our mentor’s recommendation, we used STRIDE for a quick and effective threat list combined with a simple 5x5 risk assessment model we learned from school. For a more comprehensive overview of the threat list, please see our report.
Which brings us to another matter. How would we present our findings? We considered a few options, from a traditional report to an entire Excel sheet to presentation slides, but what really inspired us was a question asked in the #ask-organisers Slack channel:
“Can we use HTML to present our report?”
We couldn’t deny the sheer flexibility of HTML, CSS and JavaScript — imagine the things we could do. And so it was decided that we would put our findings into an HTML report. Once again, please see the report to get a better idea of how that works.
A few extra things we did add to our report included:
- An attack simulation (read: fancy JavaScript)
- Detailed mitigations
- A separate list of privacy threats using the LINDDUN framework
The former intended to help decision makers see how attackers carry out threats in addition to the threats themselves, while the latter incorporated ideas of data protection into the threat model.
GenAI was indispensable in the making of the HTML report. While we could have implemented these interactions ourselves, doing so would have taken far too long under the hackathon timeline. Instead, we employed Claude AI to do all the boilerplate tasks and adjusted/debugged it ourselves, saving a lot of typing time.
My takeaway from this is that AI works best as a productivity multiplier, but it is notable that you have to know how to code first to have AI code for you. Again, a discussion for another blog I suppose.
6 - Submission
After one final mentoring session with our mentor, in which we were advised to look over the requirements one last time, we set out to polish up our report and submit it. Unfortunately, I was preoccupied with some other business by then, so my teammates mostly did the polishing. At the end, we had a fully interactive report that included all our key findings, and more importantly was something we were genuinely proud of.
We managed to submit our report in the nick of time. Fond memories of researching how to stuff all the CSS, JavaScript and images into one HTML file, but we managed it. With that, Team 27’s journey in the TMC Hackathon came to a close.
7 - Closing Thoughts
In the end, our submission consisted of a multi-layer threat model covering authentication, payments, media uploads, and CDN delivery, supported by:
- Interactive diagrams
- A STRIDE-based threat catalog
- A detailed and interactive mitigation list
All in all, a chaotic hackathon for all three of us, mostly because we were juggling multiple other things at once. We certainly didn’t enter the competition with years of formal threat-modeling experience. What carried us through was persistence, structured problem solving, and a willingness to iterate quickly when things didn’t work.
I remember leading a lot of my meetings by saying:
“Let’s get something solid and submittable out.”
And that was exactly what we did.
If you’re new to threat modeling, my biggest takeaway is simple: start with a clear model of the system. Once you understand how the system works, the threats begin to reveal themselves.
Deliverables
-
Threat Model (GitHub Pages site)
Threat Modelling Connect | Group 27 -
Reflection
Threat Modeling Hackathon 2026 Retrospective Team 27 (Public Copy).docx - Google Docs
