<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>Threat Unpacked</title><description>Operational malware analysis — deep dives into incidents, implants, and intrusion sets.</description><link>https://threatunpacked.com/</link><item><title>Building a Scalable Windows Driver Vulnerability Analyzer (Part 3): From One Driver to 1,775</title><link>https://threatunpacked.com/2026/03/12/building-a-scalable-windows-driver-vulnerability-analyzer-part-3-from-one-driver-to-1775/</link><guid isPermaLink="true">https://threatunpacked.com/2026/03/12/building-a-scalable-windows-driver-vulnerability-analyzer-part-3-from-one-driver-to-1775/</guid><description>In Part 1, I built a pipeline to ingest and classify tens of gigabytes of Windows drivers. In Part 2, I ran it at scale and found the initial results underwhelming. IOCTLance found bugs, but understanding what those bugs meant required more context than symbolic execution alone c</description><pubDate>Thu, 12 Mar 2026 05:13:44 GMT</pubDate></item><item><title>Building a Scalable Windows Driver Vulnerability Analyzer (Part 2)</title><link>https://threatunpacked.com/2026/02/04/building-a-scalable-windows-driver-vulnerability-analyzer-part-2/</link><guid isPermaLink="true">https://threatunpacked.com/2026/02/04/building-a-scalable-windows-driver-vulnerability-analyzer-part-2/</guid><description>In [Part 1], I built a pipeline to churn through gigabytes of drivers. I started with a massive raw dataset of 58.5 GB of drivers. However, feeding this volume into a static analyzer is inefficient. I aggressively filtered the set: This left me with a curated dataset of 28,000 un</description><pubDate>Wed, 04 Feb 2026 04:13:27 GMT</pubDate></item><item><title>Building a Scalable Windows Driver Vulnerability Analyzer (Part 1)</title><link>https://threatunpacked.com/2026/01/21/building-a-scalable-windows-driver-vulnerability-analyzer-part-1/</link><guid isPermaLink="true">https://threatunpacked.com/2026/01/21/building-a-scalable-windows-driver-vulnerability-analyzer-part-1/</guid><description>Background As I spent more time looking at kernel drivers, that interest gradually grew. Finding my first CVE in a Windows driver pushed me to pay closer attention to this area. Around the same time, I started reading more practical write-ups on driver work, including a post by e</description><pubDate>Wed, 21 Jan 2026 01:03:59 GMT</pubDate></item><item><title>Why This Blog Exists</title><link>https://threatunpacked.com/2026/01/07/why-this-blog-exists/</link><guid isPermaLink="true">https://threatunpacked.com/2026/01/07/why-this-blog-exists/</guid><description>Most malware analysis content focuses on what a sample does. This blog focuses on why it matters during an incident. Through case studies, technical deep dives, and operational reflections, I write about: Clarity matters, assumptions are dangerous, and systems fail in ways their </description><pubDate>Wed, 07 Jan 2026 22:31:00 GMT</pubDate></item><item><title>Reversing a Microsoft-Signed Rootkit: The Netfilter Driver</title><link>https://threatunpacked.com/2025/10/07/reversing-a-microsoft-signed-rootkit-the-netfilter-driver/</link><guid isPermaLink="true">https://threatunpacked.com/2025/10/07/reversing-a-microsoft-signed-rootkit-the-netfilter-driver/</guid><description>A detailed technical analysis of Netfilter.sys, a malicious kernel driver that was legitimately signed by Microsoft through attestation signing. This post explores how the rootkit harnesses the Windows Filtering Platform for stealthy IP redirection, the C2 communication mechanism</description><pubDate>Tue, 07 Oct 2025 08:14:24 GMT</pubDate></item></channel></rss>