Secure Scroll

In our previous articles, we learned how to design a secure system. But what happens when the attackers strike anyway? In this final guide of our series, we pivot from “Threat Modeling” (Defense) to “Threat Hunting” (Offense).

Welcome to the final chapter of our Threat Modeling series.

So far, we have been acting like Architects. We drew blueprints, identified weak spots (like missing locks or open windows), and fixed them before we built the house.

But in the real world, even the best locks can be picked.

Now, we need to switch mindsets. We need to stop thinking like Architects and start thinking like Hunters. Today, we are going to look at how you can use the Threat Model you just built as a “Treasure Map” to catch hackers in real-time.

The Difference: Modeling vs. Hunting

Before we start, let’s clarify the difference, as beginners often confuse them.

• Threat Modeling (Design Phase): asking “What could go wrong?” before it happens.
  • Analogy: Checking your house blueprints to make sure you didn’t forget to add a back door lock.
• Threat Hunting (Operational Phase): asking “Is someone already inside?” assuming the prevention failed.
  • Analogy: Walking through your house at 2 AM with a flashlight because you heard a noise.

Step 1: Use Your Model as a Map

The biggest problem beginners face in Threat Hunting is “Where do I look?” Modern systems generate millions of logs every day. You can’t read them all.

This is where your Threat Model (from Article 3 & 4) becomes your secret weapon.

Remember that report we generated? It listed high-risk interactions.

• Threat Model says: “SQL Injection is possible between the Web App and the Database.”
• Hunter says: “Aha! That is exactly where I should look for evidence.”

You don’t need to hunt everywhere. Hunt where your model told you the weak spots were.

Step 2: The “Hypothesis” (Thinking Like a Detective)

Threat Hunting isn’t just staring at screens; it’s science. It starts with a Hypothesis.

Using your Online Store model, let’s form a hypothesis:

The Hypothesis: “I bet an attacker is trying to perform SQL Injection on my search bar, because my Threat Model identified that as a ‘Tampering’ risk.”

Now you have a specific goal. You aren’t just “looking at logs”; you are “looking for SQL injection attempts.”

Step 3: The Hunt (Tools of the Trade)

To see these attacks, you need visibility. While the Microsoft Threat Modeling tool helps you plan, you need different tools to watch.

For beginners, the best place to start is Sysmon (System Monitor) and Event Logs.

Tool Spotlight: Sysmon Sysmon is a free tool from Microsoft (part of the Sysinternals suite) that logs detailed information about what is happening on your computer—much more than the standard Windows logs.

1. Download Sysmon: [Link to Microsoft Sysinternals]
2. Install it: It runs in the background, silently recording suspicious activity.
3. Hunt: You can view the logs in the standard “Event Viewer” on Windows.

Real-World Example: The SQL Hunt

Let’s verify our hypothesis.

1. The Attack: Imagine a hacker types ' OR 1=1 into your website’s login box to try and trick the database.
2. The Log: Your web server logs (IIS or Nginx) or your Database logs will record that specific text string.
3. The Catch: If you are filtering your logs for the keyword OR 1=1 or UNION SELECT, you will see the attack instantly.

Without the Threat Model, you wouldn’t have known to prioritize that specific log. With the Threat Model, you knew exactly where the door was, so you pointed your camera right at it.

Conclusion: The Cycle of Security

This concludes our series on Threat Modeling!

We started with a blank page, drew a system, found the flaws, fixed the design, and finally, used that design to hunt for attackers.

Cybersecurity isn’t a destination; it’s a loop.

1. Model your threats.
2. Hunt for the ones you missed.
3. Update your model based on what you find.

Keep learning, keep hunting, and stay safe out there.