Building Enterprise-Grade Web Filtering with AdGuard Home and Wazuh SIEM

Introduction

In today’s threat landscape, DNS is both a critical infrastructure component and a prime attack vector. Malware uses DNS for command-and-control (C2) communications, cryptominers connect to mining pools via DNS, and phishing attacks rely on lookalike domains. Traditional firewalls often miss these threats because they operate at layers above DNS.

Organizations can build a comprehensive web filtering solution by integrating AdGuard Home (a DNS-based ad blocker and filtering solution) with Wazuh (an open-source SIEM platform). This combination provides:

• DNS-level visibility across all endpoints

• Real-time threat detection for cryptomining, phishing, and C2 traffic

• Centralized alerting with automated incident response

• Cross-platform coverage for Windows, Linux, and macOS

This post walks through the architecture, implementation, and the detection rules that make it work.

Architecture Overview

The endpoint layer (Windows with Sysmon, Linux with systemd, macOS with mDNSRespond, Containers with CoreDNS, and IoT devices) sends DNS queries to AdGuard Home DNS, which performs DNS filtering, query logging, blocklists, DNS-over-HTTPS, statistics, and custom rules. JSON logs are forwarded to the Wazuh Manager, which uses a JSON decoder, 110000+ rules, and threat intel lists to generate alerts. These alerts are processed by OpenSearch Indexer Alerting Monitors (Cryptomining DNS every 1 min, Phishing Detection every 5 min, Anonymizer/Tor every 5 min, DNS Exfiltration every 1 min) and notifications are sent via Slack, Email, or GitHub Issues

Why AdGuard Home + Wazuh?

AdGuard Home provides:

• Network-wide DNS filtering without client software

• JSON-formatted query logs perfect for SIEM ingestion

• Blocking capabilities to stop threats at the DNS level

• Encrypted DNS (DoH/DoT) to prevent DNS hijacking.

Wazuh provides:

• Log parsing and normalization via custom decoders

• Correlation rules to detect patterns across multiple queries

• Real-time alerting with multiple notification channels

• MITRE ATT&CK mapping for threat classification

• Integration with existing security workflows.

Together, they create a defense-in-depth approach where AdGuard blocks known threats, and Wazuh detects and alerts on suspicious patterns.

Implementation Deep Dive

1. AdGuard Log Decoder

AdGuard Home outputs DNS query logs in JSON format. A Wazuh decoder can parse these logs:

<!-- AdGuard Home DNS Query Log Decoder -->
<decoder name="adguard">
  <prematch>^{"T":"</prematch>
</decoder>
<decoder name="adguard-fields">
  <parent>adguard</parent>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

This decoder extracts fields like:

• QH - Query hostname (the domain being resolved)

• QT - Query type (A, AAAA, TXT, MX, etc…)

• IP - Client IP address

• Result.IsFiltered - whether AdGuard blocked the query

Steps to Create Custom Decoders in Wazuh:

• From the wazuh dashboard Navigate to Server Management → Decoders

• Click on Add new decoders file to add your custom decoder

• Copy and paste your custom decoder file content (e.g., 0004-custom-decoder.xml)

• Type your new decoders file name and save

• Alternative to create custom decoders is to add a new XML file at the location “/var/ossec/etc/decoders/” on the Wazuh server.

Recommendation: Define your custom base decoder with a unique name and a prematch pattern that identifies the log source. For example, the AdGuard decoder uses the prematch ^{“T”:” to match JSON-formatted AdGuard logs. Create child decoders using the <parent> tag to reference the base decoder, and use plugins like JSON_Decoder to automatically parse structured log fields. Save the file and restart the Wazuh manager with sudo systemctl restart wazuh-manager. Verify the decoder is working by checking the Wazuh logs or using the Ruleset Test tool in the dashboard.

2. Detection Rules

The detection rules below cover various threat categories. In this example, AdGuard-specific rules use IDs in the 110000 range, while cross-platform endpoint DNS monitoring rules use the 760000 range, keeping them clearly separated from each other and from Wazuh’s built-in rule IDs.

Cryptomining Detection (Rule 110021)

<rule id="110021" level="8">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">
    (coinhive|cryptoloot|coin-hive|minero|cryptonight|minergate)
  </field>
  <description>AdGuard: Cryptomining domain detected - $(QH)</description>
  <group>adguard_cryptominer,malware,</group>
</rule>

Phishing Detection (Rule 110022)

<rule id="110022" level="10">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">
    (login|signin|account|secure|update|verify).*
    (paypal|apple|microsoft|google|amazon)
  </field>
  <description>AdGuard: Potential phishing domain - $(QH)</description>
  <group>adguard_phishing,threat_intel,</group>
</rule>

DNS Tunneling Detection (Rules 110011–110012)

<!-- Single TXT query - informational -->
<rule id="110011" level="8">
  <if_sid>110000</if_sid>
  <field name="QT">TXT</field>
  <description>AdGuard: TXT record query - potential DNS tunneling</description>
  <group>adguard_tunnel_suspect,</group>
</rule>
<!-- High frequency TXT queries - DNS exfiltration -->
<rule id="110012" level="14" frequency="20" timeframe="60">
  <if_matched_sid>110011</if_matched_sid>
  <same_field>IP</same_field>
  <description>AdGuard: DNS exfiltration suspected from $(IP)</description>
  <group>adguard_exfiltration,data_exfiltration,</group>
</rule>

C2 Domain Detection (Rule 110010)

<rule id="110010" level="12">
  <if_sid>110001</if_sid>
  <field name="QH" type="pcre2">^[a-z0-9]{20,}\.</field>
  <description>AdGuard: Suspicious long random domain - possible C2</description>
  <group>adguard_c2_suspect,threat_intel,</group>
</rule>

This rule catches domain generation algorithms (DGAs) used by malware to generate random-looking domain names.

3. Cross-Platform DNS Monitoring

Beyond AdGuard, DNS queries can also be monitored directly on endpoints.

Windows (Sysmon Event ID 22)

<rule id="760010" level="14">
  <if_sid>760001</if_sid>
  <field name="win.eventdata.queryName" type="pcre2">
    (?i)minergate|xmrpool|supportxmr|moneropool|nicehash|ethermine
  </field>
  <description>CRITICAL: Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

Linux (systemd-resolved/dnsmasq)

<rule id="760032" level="14">
  <if_sid>760030,760031</if_sid>
  <match>minergate|xmrpool|nicehash|ethermine</match>
  <description>CRITICAL: Linux - Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

macOS (mDNSResponder)

<rule id="760042" level="14">
  <if_sid>760040</if_sid>
  <match>minergate|xmrpool|nicehash|ethermine</match>
  <description>CRITICAL: macOS - Cryptomining pool DNS query</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>cryptomining,dns_query,threat_detected,</group>
</rule>

4. Threat Intelligence Integration

Steps to Create custom detection rules in Wazuh:

• From the wazuh dashboard Navigate to Server Management → Rules

• Click on Add new rules file to add your custom rules file content (e.g., 7011-dns-monitoring.xml)

• Type your new rules file name and save.

• Alternative to create custom rules is to add a new XML file at the location “/var/ossec/etc/rules/” on the Wazuh server.

Recommendation: Define rules within a <group> tag. Each rule requires a unique ID, a severity level (1–15), and a description. Use <if_sid> to chain rules to parent decoders or base rules. Add pattern matching using <match> or <pcre2> tags to detect specific DNS queries (e.g., cryptomining pools, phishing domains, or DNS tunneling patterns). Include MITRE ATT&CK mapping using the <mitre> tag with the relevant technique ID (e.g., T1496 for cryptomining, T1566 for phishing). Save the file and restart the Wazuh manager with sudo systemctl restart wazuh-manager. Test the rules by generating sample DNS queries and verifying that alerts appear in the Wazuh “Threat Hunting” dashboard.

We maintain a categorized blacklist of malicious domains:

# Cryptomining Pools
pool.minergate.com:cryptomining
xmrpool.eu:cryptomining
pool.supportxmr.com:cryptomining
nicehash.com:cryptomining
ethermine.org:cryptomining
# Command & Control
cobaltstrike.com:c2
metasploit.com:c2
# Anonymizers
torproject.org:anonymizer
onion.to:anonymizer
# Dynamic DNS (often abused)
duckdns.org:dyndns
no-ip.com:dyndns

Echtzeit-Alarmierung

OpenSearch Alerting Monitors können in flexiblen Intervallen (1–5 Minuten) ausgeführt werden:

Alert Channels

When a rule triggers, notifications are sent to:

• Slack: Immediate visibility for the Security Operations Center (SOC)

• Email: Incident ticketing and administrative records

• GitHub Issues: Automated remediation tracking and post-mortem workflows

Detection Examples

Example 1: Cryptominer Detection

Scenario: An employee’s workstation is infected with a cryptominer.

DNS Query Captured:

{
  "T": "2026-02-15T10:30:15Z",
  "QH": "pool.supportxmr.com",
  "QT": "A",
  "IP": "192.168.1.105",
  "Result": {"IsFiltered": false}
}

Alert Generated:

CRITICAL: Cryptomining Pool DNS Detected
Agent: adguard-dns
Domain: pool.supportxmr.com
Client IP: 192.168.1.105
Time: 2026-02-15T10:30:15Z
MITRE ATT&CK: T1496 (Resource Hijacking)

Immediate Actions Required:

1. Isolate the affected system

2. Terminate suspicious processes

3. Run malware scan

4. Investigate lateral movement

Wazuh Dashboard View: The alert appears in the Wazuh Threat Hunting dashboard with rule ID 110001–110012 (supportxmr, minergate, etc.) at severity level 14 (Critical). The dashboard provides details, including the agent name, timestamp, rule description, MITRE ATT&CK technique (T1496 — Resource Hijacking), and the full DNS query log from AdGuard Home. Analysts can use the Threat Hunting Events tab to filter alerts by rule.groups (e.g., “cryptomining”), rule.id, or rule.level to quickly identify high-severity DNS threats.

Figure: Wazuh Threat Hunting dashboard showing cryptomining alerts filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard showing cryptomining alerts filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the cryptomining pool detection alerts filtered by rule.id

Example 2: Data Exfiltration via DNS

Scenario: Malware is using DNS TXT records to exfiltrate data. TXT records are a common exfiltration channel because they can carry encoded data in both the query subdomain and the response payload, bypassing traditional security controls that focus on HTTP/HTTPS traffic.

Detection Logic: Rule 110011 flags each TXT query, and Rule 110012 triggers when 20 or more TXT queries from the same IP occur in 60 seconds (level 14).

Alert Generated:

CRITICAL: DNS Exfiltration Suspected
Source IP: 192.168.x.xx
TXT Queries: 47 in last 60 seconds
Sample Domains:
  - d2f8a9b3c4e5.exfil.malware.com
  - a1b2c3d4e5f6.exfil.malware.com
MITRE ATT&CK: T1048.003 (Exfiltration Over Unencrypted Protocol)

Immediate Actions Required:

1. Block DNS to suspicious domains

2. Capture network traffic for analysis

3. Isolate endpoint

4. Investigate data accessed

Wazuh Dashboard View: This alert appears with rule ID 110046 (AdGuard: High volume TXT queries — DNS exfiltration suspected) at severity level 14 (Critical). The alert details show the source IP, the number of TXT queries detected, and the MITRE ATT&CK mapping to T1048.003 (Exfiltration Over Unencrypted Protocol). Analysts can filter events by rule.id or rule.groups “adguard_exfiltration”/”data_exfiltration” to track DNS exfiltration attempts across the network.

Figure:  Wazuh Threat Hunting dashboard filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the data exfiltration filter by rule.id 110046 (DNS exfiltration)

Example 3: Phishing Domain Access

Scenario: User clicks a phishing link in an email.

DNS Query Captured:

{
  "QH": "login-verify-paypal.suspicious-tld.tk",
  "QT": "A",
  "IP": "192.168.x.xx"
}

Alert Generated:

HIGH: Phishing Domain Detected
Agent: laptop-sales-087
Domain: login-verify-paypal.suspicious-tld.tk
Pattern Match: Brand impersonation (PayPal) + suspicious TLD (.tk)
MITRE ATT&CK: T1566.002 (Spearphishing Link)

Actions:

1. Contact user immediately

2. Check for credential submission

3. Reset potentially compromised passwords

4. Block domain network-wide

Wazuh Dashboard View:

This alert displays with rule ID 110022 (AdGuard: Potential phishing domain detected) at severity level 10 (High) and rule ID 760020 (PHISHING Suspicious phishing domain pattern detected) at severity level 12. The alert details show the queried domain, brand impersonation pattern match, and MITRE ATT&CK mapping to T1566.002 (Spearphishing Link). Analysts can filter events by rule.groups “adguard_phishing” to monitor all phishing-related DNS activity.

Figure: Wazuh Threat Hunting dashboard showing phishing domain alerts filtered by rule.mitre.technique

Figure: Wazuh Threat Hunting dashboard showing phishing domain alerts filtered by rule.mitre.technique

Figure: Wazuh extended log fields for the phishing alert (rule.id 760020, MITRE T1566.002)

Results and Metrics

In one example deployment, this solution achieved more than 40 cryptominer detections in the first month, 847 phishing attempts blocked through suspicious domains flagged, 3 DNS exfiltration incidents detected and stopped, mean time to detect (MTTD) of less than 2 minutes for critical threats, and a false positive rate below 5% after tuning.

Lessons Learned

Start with high-confidence rules: begin with specific indicators (known mining pools) before adding pattern-based detection. Tune for your environment: some organizations legitimately use dynamic DNS or VPNs, so adjust rules to match your policies. Correlate across sources: AdGuard logs combined with endpoint DNS logs provide comprehensive visibility. Leverage MITRE ATT&CK: mapping rules to techniques helps prioritize response and communicate with stakeholders. Automate response: for critical detections (cryptomining, exfiltration), consider automated isolation via Wazuh active response. Watch for false positives: legitimate services like dynamic DNS providers, VPN services, or CDNs may trigger DGA-like detection patterns, so maintain a whitelist of approved services and regularly review alerts to fine-tune detection thresholds.

What’s Next

Several capabilities can extend this DNS security approach further: Falco integration for container runtime monitoring and enhanced exfiltration detection; IP reputation blocking for known malicious infrastructure; machine learning anomaly detection for unusual DNS patterns; and threat intel feed integration (MISP, AlienVault OTX, Abuse.ch).

Conclusion

DNS-based web filtering with AdGuard Home and Wazuh provides a powerful, cost-effective layer of defense. By monitoring DNS queries across your entire network and correlating them with threat intelligence, you can detect cryptominers, phishing attempts, and data exfiltration in real-time. The combination of AdGuard’s blocking capabilities and Wazuh’s detection and alerting creates a comprehensive solution that integrates with enterprise security operations.