Indicator of Benignity: An Industry View of False Positive in Malicious Domain Detection and its Mitigation

Indicator of Benignity: An Industry View of False Positive in Malicious Domain Detection and its Mitigation

Speakers: Daiping Liu

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=dXW9qtWzwfg

Overview

For decades, cybersecurity has focused almost exclusively on hunting for bad indicators (IOCs). This talk flips that paradigm with a deceptively powerful concept: Indicators of Benignity (IOBs) -- proactive identification of evidence that a flagged domain is actually legitimate. Using a six-year dataset from Palo Alto Networks covering over 65,000 organizations and 7 billion DNS queries per day, the researchers reveal that of approximately 123,000 user-reported potential false positives, a staggering 98% were confirmed as true false positives. Traditional popularity-based allow lists like Tranco could only catch 38% of these, but the researchers' IOB Hunter system -- combining LLM-powered web content analysis with a transitive trust model -- is over 700 times more effective than traditional allow lists and was deployed in production where it confirmed 4,300 false positives in two months.

Background

▶ Watch: The scale of the false positive problem: 123K FPs over six years (0:00)

Palo Alto Networks' DNS security product detects approximately 1.6 million new malicious domains every day. Despite this detection power, false positives represent a significant hidden cost. The researchers conducted the first large-scale measurement study of false positives using six years of production data and discovered two critical characteristics:

Long Reporting Delay: Only 23% of false positives are reported within the first month, with a median delay of 120 days. This means evaluating a detector's real-world false positive rate requires at minimum months of deployment observation.

Extreme Fragmentation: 97% of false positive domains were reported only once by a single user. These domains come from over 113,000 unique root domains -- not subdomains of major players. This long-tail distribution means grouping by domain or user is ineffective for identifying or confirming false positives at scale.

The cybersecurity industry has traditionally relied on popularity-based top lists (Tranco, formerly Alexa) as allow lists. However, even combining all major public top lists covers only 38% of confirmed false positives. Expanding the allow list beyond the top 5 million domains would introduce unacceptable false negative risk, as about 50% of false positive root domains rank below 5 million.

Key Findings

▶ Watch: Introducing Indicators of Benignity: flipping the IOC paradigm (4:00)

IOBs Exist in the Wild: For approximately 50% of confirmed false positives, clear indicators of their benign nature can be found on the public internet. This reflects a fundamental human behavior: users who report false positives have often already found benign evidence themselves.

Transitive Trust Model: Inspired by SSL certificate authority chains, the researchers defined a formal trust model where a domain is benign if it is owned by or certified by a trusted source. The root of trust is defined as official government organizations (e.g., .gov domains). Trust transits from root to intermediate sources to target domains, with a strict exception: trust cannot transit through platforms that allow arbitrary public content (preventing attacker manipulation).

IOB Hunter Performance: Using LLMs (Gemini, ChatGPT) with chain-of-thought prompting to parse unstructured web content, IOB Hunter achieved 99% precision (when it says a domain is benign, it is almost always correct) with 68% recall. The lower recall is intentional -- untrusted sources like social media are excluded even though their IOBs are currently valid, because they could be easily gamed by attackers.

False IOB Analysis: Of 359 false IOB cases (malicious domains identified as benign), 94% were compromised domains -- technically correct IOBs for previously legitimate domains. 5% were dual-use security tools (an industry gray area). Only 1% were true errors, mainly caused by LLM hallucination.

Production Deployment: Over two months analyzing 1 million high-priority domains, IOB Hunter confirmed 4,300 false positives and identified 2,000 compromised domains. The Tranco top 1 million list would have caught only 6 of those 4,300 false positives.

Technical Deep Dive

▶ Watch: IOB Hunter's three-step cycle: search, analyze with LLMs, verify trust chains (8:00)

IOB Hunter operates in a three-step iterative cycle:

Step 1 - Search: When a domain is flagged as malicious, IOB Hunter defines search targets: the FQDN itself and its root domain (if they share ownership). It queries search engines to find public web pages that may contain evidence of the domain's legitimacy.

Step 2 - Analyze: The key challenge is that web content is noisy and unstructured. IOB Hunter uses large language models (Gemini, ChatGPT) with technical chain-of-thought prompting that forces the AI to follow a strict logic checklist. The LLM must determine whether the web content provides attribution of the target domain to a legitimate organization or application -- not merely mentions it (which could be an IOC, not an IOB). Sources like Cloudflare Radar are excluded because they provide technical data without legitimacy attribution.

Step 3 - Verify: When a valid IOB is found but the source is not the ultimate root of trust, IOB Hunter recursively follows the trust chain. It searches for evidence that the intermediate source itself is trusted, continuing until it either reaches a root of trust (like a .gov domain) or exhausts its search limit.

Real-World Example: The domain hugestfoods.com was flagged by a production detector. IOB Hunter found valid IOBs from two professional sources (Netter and ZoomInfo). Neither was a root of trust, so it continued searching and found that sec.gov referenced ZoomInfo as a legitimate service. This established a verified trust chain: sec.gov -> ZoomInfo -> hugestfoods.com, correctly confirming the false positive.

Platform Exclusion Rules: For platforms like GitHub where subdomains/paths can be controlled by arbitrary users, IOB Hunter applies strict rules: trust transits to official subdomains (support.github.com, help.github.com) but not to user-controlled paths (github.com/username). This prevents attackers from creating repositories or pages that vouch for malicious domains.

Demo / Proof of Concept

▶ Watch: Real example: hugestfoods.com trust chain via sec.gov (10:00)

The production deployment results serve as the primary proof of concept. Over two months, IOB Hunter analyzed 1 million high-priority domains from Palo Alto Networks' detection pipeline and:

• Confirmed and corrected 4,300 false positives that traditional allow lists would have missed (only 6 would have been caught by Tranco)
• Identified 2,000 compromised domains -- a valuable secondary capability that provides critical context for SOC teams distinguishing between attacker-owned and compromised infrastructure
• Demonstrated 99% precision in production, meaning SOC teams can trust IOB Hunter's benign verdicts without additional manual review

Defensive Implications

▶ Watch: Q&A: Handling GitHub subdomains and trust transit exclusions (18:00)

IOB Hunter represents a fundamentally new capability for security operations:

SOC Workflow Integration: The system can be fed directly into SOC workflows for alert triage, automatically resolving a significant portion of false positive alerts that currently require manual investigation. At Palo Alto Networks' scale of 1.6 million new malicious domains daily, even a small false positive rate translates to enormous manual workload.

Compromised Domain Detection: The secondary finding of 2,000 compromised domains demonstrates that IOB analysis provides defensive context beyond false positive mitigation. Knowing that a flagged domain was previously legitimate (has valid IOBs) but is currently serving malicious content tells defenders they're dealing with compromised infrastructure rather than attacker-owned domains -- information that changes the incident response approach.

Dual Approach to Threat Intelligence: The researchers advocate for a paradigm shift: future high-fidelity threat detection should combine traditional IOC hunting with proactive IOB verification. This dual approach reduces false positive burden while maintaining detection coverage.

Dataset Release: The researchers have made portions of their dataset publicly available to support future research, enabling the broader community to build on the IOB concept.

Key Takeaways

• 98% of 123,000 user-reported false positives in Palo Alto Networks' DNS security product were confirmed as true false positives, representing massive hidden operational costs
• Traditional popularity-based allow lists (Tranco) cover only 38% of confirmed false positives; IOB Hunter is 700x more effective
• The transitive trust model using .gov domains as roots of trust with strict platform exclusion rules achieves 99% precision in identifying benign domains
• 50% of confirmed false positives have discoverable Indicators of Benignity on the public internet, enabling automated verification
• Only 1% of IOB Hunter errors are true mistakes (LLM hallucination); 94% of false IOBs are actually compromised domains, providing valuable context
• IOB Hunter extends beyond FP mitigation into compromised domain identification and SOC alert triage automation

About the Speaker(s)

Daiping Liu (presenting as Ding) is a researcher at Palo Alto Networks, working in collaboration with researchers from UC Irvine (UCI). The work bridges industry-scale production data with academic rigor, leveraging Palo Alto Networks' massive DNS security infrastructure covering 65,000+ organizations and 7 billion daily DNS queries. The team's focus on operationalizing research findings in production security systems distinguishes this as industry-informed academic security research.