Network-Layer Defences Against AI-Powered Phishing Campaigns

Problem

Phishing has always been effective, but its reach was historically constrained by the cost of personalisation. Crafting a convincing spear-phishing email — one that references the target’s name, role, recent activities, colleagues, and current projects — required human research time. That cost limited sophisticated attacks to high-value targets: executives, finance teams, and privileged infrastructure operators.

AI has eliminated this constraint. Large language models combined with publicly available data sources (LinkedIn, company websites, conference proceedings, GitHub commit history, social media) can generate highly personalised phishing content at scale and near-zero marginal cost. An attacker who previously could target 10 executives with personalised emails can now target 10,000 employees simultaneously, each receiving a message that references their specific team, their manager’s name, a recent company announcement, and a plausible business pretext.

The characteristics of AI-generated phishing that affect network-layer detection:

High linguistic quality eliminates grammar-based filters. Traditional phishing detection relied on identifying poor grammar, unusual phrasing, and non-native English patterns. AI-generated phishing passes these filters completely, since the language model produces fluent, contextually appropriate prose.

Personalisation defeats bulk-signature detection. Spam and phishing filters rely on identifying shared signatures across many messages — the same URL, the same domain, the same phrasing appearing in thousands of emails. AI-generated campaigns can vary the content across every message, making signature-based detection ineffective.

AI-generated lookalike domains at scale. AI tools can generate convincing lookalike domain names (homograph attacks, typosquatting, subdomain manipulation) and register them at scale. Where an attacker previously registered a handful of lookalike domains, AI campaign tools can enumerate and register hundreds simultaneously.

AI-generated voice and video (vishing/deepfake). Audio and video synthesis has reached the point where AI can clone a voice from a 10-second sample or generate a realistic video of an executive. Vishing calls from AI-generated voices of known colleagues are reported by multiple enterprises in 2024–2025.

Adaptive campaign logic. AI-managed phishing campaigns can adapt in real time based on which users click, which credentials are submitted, and which defences they encounter — automatically re-routing the campaign to avoid detected infrastructure.

The network-layer response to these changes requires shifting from signature-based detection to behavioural and structural controls: DNS-based domain reputation, network egress controls that limit where credentials can be submitted, browser isolation that breaks the phishing kill chain, and email gateway analysis that examines message structure and sender behaviour rather than just content.

Target systems: corporate networks with email infrastructure; any organisation where employees access email from managed devices; cloud environments where SSRF or server-side phishing can reach internal services; developer environments where phishing targets code-signing keys and cloud credentials.

Threat Model

Adversary 1 — Mass AI-personalised campaign. Attacker uses AI to generate 10,000 personalised phishing emails targeting all employees. Each references the employee’s team and a recent company event. 0.5% click rate yields 50 credential captures. Traditional bulk-signature detection finds nothing — every message is unique.

Adversary 2 — AI-generated deepfake voice call. Finance team receives calls from an AI-cloned voice of the CFO requesting urgent wire transfer approvals or cloud credential resets. The voice is indistinguishable from the real CFO to the recipients.

Adversary 3 — AI lookalike domain campaign. Attacker registers 200 typosquatted and homograph variants of the company domain within 24 hours. Phishing emails link to these domains; DNS lookups from the corporate network reach the attacker’s credential-harvesting infrastructure.

Adversary 4 — Credential-harvesting via legitimate-appearing SaaS. AI generates a fake SaaS login page that replicates an internal tool (Okta, Slack, GitHub Enterprise). The page is hosted on a legitimate cloud service (Cloudflare Pages, Vercel) to pass basic URL reputation checks. Employees who click are redirected to the real service after credentials are captured.

Without controls: AI phishing succeeds at scale because content-based filters are ineffective. With controls: DNS filtering blocks lookalike domain resolution; email gateway behavioural analysis detects structural anomalies; egress controls limit where credentials can be submitted; browser isolation breaks the click-to-compromise chain.

Configuration / Implementation

Step 1 — Deploy protective DNS with AI-campaign indicators

Protective DNS provides a network-layer control that intercepts phishing domain resolution regardless of how the phishing email was delivered:

# Deploy a protective DNS resolver that checks against threat intel feeds
# Options: Cloudflare Gateway (1.1.1.2), Cisco Umbrella, NextDNS, or self-hosted

# Self-hosted with Pi-hole + blocklist automation:
# /etc/pihole/custom-lists.conf
# Add feeds that track AI-generated phishing infrastructure

# Automated blocklist update script
#!/bin/bash
PIHOLE_API="http://localhost/api"
FEEDS=(
  "https://openphish.com/feed.txt"
  "https://raw.githubusercontent.com/mitchellkrogza/Phishing.Database/master/phishing-domains-ACTIVE.txt"
  # Threat intel feed from your provider
)

for feed in "${FEEDS[@]}"; do
  curl -s "$feed" | while read -r domain; do
    pihole --white-list-remove "$domain" 2>/dev/null || true
    pihole -b "$domain" 2>/dev/null || true
  done
done

For enterprise environments, use DNS Response Policy Zones (RPZ):

# /etc/bind/rpz.zone — Response Policy Zone for phishing domains
$TTL 300
@ IN SOA rpz.internal. admin.rpz.internal. (
    2026051201 ; serial
    3600       ; refresh
    900        ; retry
    604800     ; expire
    300        ; minimum TTL
)
    IN NS rpz.internal.

; Block known phishing domains with NXDOMAIN
malicious-login.example-corp.com.rpz.internal.  IN CNAME .
corp-login.attacker.com.rpz.internal.            IN CNAME .

; Redirect to a warnpage for suspected phishing
*.phishingpattern.com.rpz.internal. IN CNAME warnpage.internal.

# /etc/bind/named.conf.options
options {
    response-policy { zone "rpz.internal"; };
};

Step 2 — Email gateway: behavioural analysis beyond content

Configure email gateway rules that detect structural AI-phishing indicators, not content:

# Postfix + Amavis configuration for header-based checks
# /etc/amavis/conf.d/50-user

# Check for newly registered domains (common in AI phishing campaigns)
# Domains <30 days old with email from them are high-risk
$banned_filename_re = new_re(
  # Block credentials submission forms embedded as HTML attachments
  [qr'(?i)\.html?$' => 0],
);

# SpamAssassin rules for AI-phishing structural indicators
# /etc/spamassassin/local.cf

# Flag messages from domains registered < 30 days ago
header NEW_DOMAIN_SENDER  From =~ /\@[a-zA-Z0-9-]+\.[a-zA-Z]{2,}/
describe NEW_DOMAIN_SENDER  Sender domain may be newly registered

# Flag messages with aggressive urgency language (AI phishing hallmark)
body AI_URGENCY_PATTERN  /(?:immediate(?:ly)?|urgent(?:ly)?|action required|within 24 hours|account suspended)/i
score AI_URGENCY_PATTERN  2.0

# Flag lookalike domains (Levenshtein distance from your domain)
# Requires custom plugin — example using Mail::SpamAssassin::Plugin
header LOOKALIKE_DOMAIN  eval:check_lookalike_domain('yourdomain.com')
score LOOKALIKE_DOMAIN   5.0

# DMARC alignment check (catches AI campaigns that spoof header-from)
# Enforce p=reject and require aligned DKIM

For cloud email (Google Workspace / Microsoft 365):

# Microsoft 365 Exchange Online Protection — advanced threat protection policy
# Configure via PowerShell or M365 admin centre

# Impersonation protection (catches AI-generated CFO/executive spoofing)
# Set-AntiPhishPolicy -Identity "Default" -EnableOrganizationDomainsProtection $true
# -EnableTargetedUserProtection $true
# -TargetedUsersToProtect @("ceo@example.com", "cfo@example.com", "cto@example.com")
# -TargetedUserProtectionAction Quarantine

# Safe Links — rewrite all URLs and check at click time
# Catches AI campaigns that use URL shorteners or delayed domain activation
# New-SafeLinksPolicy -Name "AI-Phishing-Protection"
# -IsEnabled $true
# -DoNotRewriteUrls @()  # Rewrite all URLs
# -DeliverMessageAfterScan $true  # Hold until URL checked
# -EnableForInternalSenders $true  # Check internal forwards too

Step 3 — Egress controls: restrict where credentials can be submitted

A phishing attack succeeds when a user submits credentials to an attacker-controlled site. Network-layer egress controls can prevent this regardless of how the user was lured:

# Squid proxy with SSL inspection — intercept all HTTPS POSTs from corporate devices
# /etc/squid/squid.conf

# Require authentication for web access (logs who accessed what)
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/htpasswd
auth_param basic children 5
auth_param basic realm "Corporate Web Proxy"

acl authenticated_users proxy_auth REQUIRED

# Block POST requests to domains not in the corporate allowlist
acl post_request method POST
acl corporate_sites dstdomain .example.com .okta.com .github.com .atlassian.net

http_access deny post_request !corporate_sites
http_access allow authenticated_users
http_access deny all

# Log all denied POST attempts for SIEM analysis
access_log /var/log/squid/access.log squid

For browser-based credential protection, deploy a browser extension policy:

// Chrome policy via GPO or MDM — block form submissions to unlisted domains
// /etc/opt/chrome/policies/managed/credential_protection.json
{
  "URLBlocklist": [],
  "URLAllowlist": [
    "https://*.example.com/*",
    "https://*.okta.com/*",
    "https://*.github.com/*",
    "https://*.atlassian.net/*"
  ],
  // Block any page that requests username/password from outside allowlist
  "PasswordManagerEnabled": true,
  "PasswordLeakDetectionEnabled": true
}

Step 4 — Deploy browser isolation for high-risk users

Browser isolation ensures that even if a user clicks a phishing link, the page executes in a remote container rather than on the local device:

# Cloudflare Browser Isolation configuration (via Cloudflare Zero Trust)
# All web browsing is proxied through Cloudflare's isolated browser

# Alternatively, self-hosted isolation with Browserless or Authentic8

# For critical users (finance, HR, executives) — mandatory isolation
# For general users — isolation for uncategorised or suspicious URLs only

# DNS-over-HTTPS enforcement ensures all DNS goes through protective resolver
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.2#cloudflare-gateway.com  # Cloudflare Gateway with AI phishing protection
DNSOverTLS=yes

Step 5 — Monitor for AI-phishing indicators in network traffic

# Zeek script — detect potential phishing credential harvest
# /opt/zeek/share/zeek/site/phishing-detection.zeek

event http_request(c: connection, method: string, original_URI: string,
                   unescaped_URI: string, version: string)
{
    if (method == "POST") {
        # Log all POST requests with destination domain
        print fmt("POST to: %s%s from: %s",
                  c$http$host, original_URI,
                  c$id$orig_h);
        
        # Alert if POST to a domain registered recently
        # (Requires domain age lookup integration)
        if (Site::is_local_addr(c$id$orig_h) &&
            !Site::is_local_addr(c$id$resp_h)) {
            NOTICE([$note=Phishing::SuspiciousCredentialPost,
                    $msg=fmt("Possible credential submission to external domain: %s",
                             c$http$host),
                    $conn=c]);
        }
    }
}

Alert on multiple employees accessing the same new domain within a short window (AI campaign indicator):

# SIEM detection rule (pseudo-code for Splunk/Elastic)
# Alert when >10 distinct users access a domain first seen < 24h ago

# Splunk SPL:
# index=proxy_logs action=allowed
# | stats dc(user) as unique_users, min(_time) as first_seen by domain
# | where first_seen > relative_time(now(), "-24h")
# | where unique_users > 10
# | eval age_hours = (now() - first_seen) / 3600
# | where age_hours < 24
# | table domain, unique_users, first_seen, age_hours
# | sort -unique_users

Step 6 — Phishing simulation with AI-generated content

Run regular phishing simulations using AI-generated content to measure your defence effectiveness and train employees:

# Use an LLM to generate personalised phishing simulation emails
# for security awareness training (authorised use only)

import anthropic
import csv

client = anthropic.Anthropic()

def generate_simulation_email(employee: dict) -> str:
    """Generate a personalised phishing simulation email for awareness training."""
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=500,
        system="""You are generating phishing simulation emails for authorised 
        security awareness training. These emails will be used to train employees 
        to recognise phishing. Generate a realistic but clearly simulatable email.""",
        messages=[{
            "role": "user",
            "content": f"""Generate a phishing simulation email for:
            Name: {employee['name']}
            Role: {employee['role']}
            Department: {employee['department']}
            
            Use a plausible business pretext. Include a call-to-action that 
            links to our simulation tracking URL. Do not include any real 
            malicious content."""
        }]
    )
    return response.content[0].text

# Load employee list and generate simulations
with open('employees.csv') as f:
    for employee in csv.DictReader(f):
        email_content = generate_simulation_email(employee)
        # Send via simulation platform (Proofpoint, KnowBe4, etc.)
        simulation_platform.send(employee['email'], email_content)

Expected Behaviour

Verification:

# Test DNS protection
dig @your-protective-dns phishing-test-domain.example +short
# Expected: NXDOMAIN or sinkhole IP

# Test proxy POST blocking
curl -x http://proxy.internal:3128 \
  -X POST https://suspicious-new-domain.com/login \
  -d "username=test&password=test" \
  2>&1 | grep -i "access denied\|403\|forbidden"
# Expected: access denied

# Test email lookalike detection
swaks --to security-test@example.com \
  --from admin@examp1e.com \
  --server mail.example.com \
  --add-header "X-Mailer: Test" \
  --body "Test lookalike domain detection" \
  2>&1 | grep -i "score\|lookalike"

Trade-offs

Failure Modes

Related Articles

• Email Security: SPF, DKIM, and DMARC — the authentication layer that prevents domain spoofing, a prerequisite to AI phishing defence
• DNS RPZ Threat Intelligence — deploying and maintaining DNS Response Policy Zones for threat intelligence blocking
• AI Social Engineering Defence — the application-layer controls that complement network defences against AI-generated social engineering
• WAF Rule Tuning — adapting WAF rules for AI-generated attack traffic patterns
• Deepfake Voice MFA Defence — defending against AI voice cloning used in vishing campaigns