Why We Exist: Our Mission

MalwareZero.org exists to make the internet safer by providing accurate, practical, and accessible information about WiFi security. We believe that security through obscurity — the old model where only governments and corporations knew how attacks worked — has failed. The most secure systems in the world are built by people who understand how attacks actually function.

Our audience is broad: security professionals who need precise technical details, IT administrators who need to defend their organization's networks, developers building WiFi-enabled products, and everyday users who want to understand the risks of the coffee shop WiFi they're using. We write for all of them — adapting depth and technical detail to each piece, but never dumbing things down to the point of being misleading.

We are not a hacking tutorial site. We are not a criminal resource. We are an educational platform that believes understanding attack techniques is a prerequisite to defending against them.

How We Choose What to Document

Every week, dozens of new WiFi security research papers, CVE disclosures, tool releases, and attack techniques surface in the security community. We can't document everything. We have to prioritize. Here's the framework we use:

Criteria for Inclusion

• Real-world relevance: Is this technique actually used by attackers, or is it purely theoretical? We prioritize techniques that appear in real incidents, penetration test findings, or credible threat intelligence.
• Affected population: Does this affect a meaningful number of people or organizations? A vulnerability affecting only one specific router model with 1,000 total users worldwide ranks lower than a widely deployed protocol weakness affecting millions of access points.
• Severity and impact: What is the realistic impact if this technique is used against a target? Remote code execution on a core router is higher priority than a minor information disclosure.
• Actionability: Can defenders do something about this? If the only mitigation is "replace all affected devices," we document it but focus more editorial energy on things defenders can actually act on.
• Novelty: Is this genuinely new, or is it a repackaged version of something we've already documented? We prioritize original research and genuinely new attack techniques over rehashed content.

Criteria for Prioritization

Within the set of techniques that meet the inclusion criteria, we prioritize based on:

• Severity: Critical vulnerabilities (CVSS 9+) get documented fastest.
• Exploitability: Techniques that require no special equipment or expertise are more dangerous and get higher priority.
• Time sensitivity: If a patch is available, we want to document the attack before the patch window closes — to help defenders prioritize.
• Audience need: We monitor what our readers are asking about, searching for, and struggling with. Questions that appear repeatedly in security forums get elevated priority.

Our Technical Verification Process

Accuracy is non-negotiable. Publishing incorrect information about security techniques — whether the error makes an attack seem easier or harder than it actually is — could cause real harm. We have a multi-stage verification process:

Stage 1: Primary Source Research

Every technique we document starts with primary sources: the original research paper, CVE disclosure, tool documentation, or conference talk where the technique was first presented. We go to the source, not to secondary summaries. We do this because:

• Secondary sources often misinterpret technical details
• Attack techniques evolve; the original paper captures the full picture
• Qualifications and limitations in the original research are often dropped in summaries

Stage 2: Laboratory Reproduction

Before we publish any description of an attack technique, we reproduce it in our lab environment. This is not optional. Our lab consists of:

• A selection of consumer and enterprise access points (various vendors, firmware versions, and encryption configurations)
• Multiple client device types (laptops, phones, IoT devices)
• Standard security testing toolchain (Kali Linux with full toolset, Wireshark, various software-defined radios and WiFi adapters)
• Isolated network segments that cannot affect external networks

When we reproduce an attack, we verify:

• The attack works as described in the original research
• The attack's requirements and preconditions are accurately described
• The tools used are available and functional (if a tool is deprecated or broken, we note this)
• The time, resources, and skill level required match the original claims
• The attack's limitations and failure modes are correctly understood

Stage 3: Tool Verification

When we document a tool's capabilities, we don't just copy the tool's README file. We:

• Download and run the tool ourselves in our lab environment
• Verify that the features listed in documentation actually work
• Identify features that are documented but non-functional or deprecated
• Check for dependencies, version requirements, and known compatibility issues
• Test against our own lab access points and verify the output is as expected

Stage 4: Expert Review

Before publication, all technical content is reviewed by at least one member of our expert review panel — working security researchers, penetration testers, or academic security specialists who have direct experience with the technique being documented. Our experts review for:

• Technical accuracy of the attack description
• Correctness of the defense recommendations
• Appropriate severity and risk assessments
• Missing nuances or edge cases
• Whether the piece achieves the right balance between detail and accessibility

How We Stay Current with New Attack Techniques

WiFi security is a fast-moving field. The KRACK attacks (2017) changed how the industry thought about WPA2. The Dragonblood attacks (2019) revealed fundamental weaknesses in early WPA3 implementations. New vulnerabilities in embedded WiFi firmware, new attack surfaces in WiFi 6 (802.11ax) deployments, and novel techniques targeting increasingly complex wireless environments appear regularly.

We stay current through:

• Academic conferences: We monitor WiSec, USENIX Security, IEEE S&P, ACM CCS, and DEFCON for WiFi-related research.
• CVE databases: We track new WiFi-related CVEs as they are published, with particular attention to those with public exploits or proof-of-concept code.
• Security mailing lists: Full disclosure lists, bug bounty program disclosures, and security researcher blogs are monitored daily.
• Tool repositories: GitHub, GitLab, and security tool-specific repositories are monitored for new tools and tool updates.
• Threat intelligence: We review incident reports, security vendor threat reports, and industry analysis for patterns that indicate new or emerging WiFi attack trends.
• Community input: Our readers submit corrections, new techniques, and suggested topics. We treat these as high-priority review items.

Our Legal Handling Process

WiFi security sits at the intersection of highly technical content and serious legal risk. We take our legal responsibilities seriously, and we expect our readers to do the same. Our legal handling process:

• No instructions for illegal activity: We describe attack techniques for educational and defensive purposes. We do not provide step-by-step instructions that are primarily designed to facilitate illegal activity.
• Authorization always required: Every article that discusses testing or attack techniques includes a clear statement that such activities require authorization from the network owner.
• Defense-first framing: When we describe an attack, we immediately pair it with defense guidance — what defenders can do to detect or mitigate it.
• Legal disclaimers: Our disclaimer page is prominent and comprehensive. We strongly encourage readers to consult with legal counsel before conducting any security testing activities.
• Responsible disclosure: When we document a new vulnerability, we verify that the vendor has been notified and given adequate time to patch before publication. If a vulnerability has no patch and is being actively exploited, we follow coordinated disclosure practices.

Editorial Standards for Accuracy

We hold ourselves to high editorial standards. Here's what that means in practice:

• Every factual claim has a source. We cite research papers, CVE databases, vendor documentation, or our own lab verification. We don't publish statistics or severity claims without citing where they came from.
• We correct errors visibly. When we make a mistake, we acknowledge it. We don't quietly fix content without noting the change. Significant corrections are noted with a correction date and explanation.
• We distinguish fact from interpretation. When we assess a technique's severity or likelihood, we explain the reasoning. We don't present opinion as fact.
• We don't sensationalize. WiFi vulnerabilities are often breathlessly covered in mainstream media with headlines like "Billions of Devices At Risk!" We resist this impulse. Our severity assessments are calibrated to real-world exploitability, not headline potential.
• We update content when the facts change. If a patch is released that mitigates an attack, we update the affected articles. If new research changes our understanding of a technique, we revise and note the update.

How We Cite Sources and Primary Research

Every technical article on MalwareZero.org that references specific research, CVEs, or external data includes citations in the text and a references section at the bottom. We use in-text citations with author names and year, and a full reference list at the end of each article.

Our primary citation types:

• Academic papers: Author(s), Title, Conference/Journal, Year. Link to paper if publicly available.
• CVE entries: CVE-XXXX-XXXXX: Description, Vendor Advisory Link, Patch Status.
• Tool documentation: Tool Name, Version, Repository URL, Last Verified Date.
• Industry reports: Organization, Report Title, Year, URL.
• Lab verification: When we document something we verified in our own lab, we note the lab environment and date of verification.

What We Won't Document

There are boundaries to what we publish. We do not document:

• Zero-day exploits: We do not publish information about vulnerabilities that are unknown to the vendor and for which no patch exists, unless the information has been publicly disclosed through legitimate channels (like a security conference talk with slides available). We follow coordinated disclosure principles.
• Targeted attack techniques: We don't document techniques specifically designed to target specific individuals, activist groups, journalists, or political dissidents. These techniques — such as precision IMSI catchers deployed for surveillance rather than security research — raise ethical concerns that outweigh their educational value.
• Exploit code for critical vulnerabilities: While we document attack techniques in educational detail, we don't publish fully functional exploit code for critical vulnerabilities that could be trivially weaponized. We describe the technique, the conditions required, and the defense — not the turnkey exploit.
• Techniques designed primarily for fraud or harm: Some WiFi-related techniques exist primarily to commit financial fraud or other serious crimes. We document the underlying vulnerabilities, but we don't provide operational guidance for these specific use cases.

How We Define Threat Level Ratings

On each attack technique page, we assign a Threat Level rating. This is our assessment of how dangerous the technique is in practice. Here is how we define our ratings:

Our threat level ratings are not CVSS scores — they are editorial assessments that consider exploitability, population affected, real-world likelihood, and the availability of practical defenses. We explain the reasoning behind each rating in the article itself, so readers can form their own judgment if they disagree.