SC-030: DNS Hijacking — Operation Name Storm¶

Threat Actor Profile¶

SHADOW RESOLVER is a financially motivated cybercrime syndicate operating since late 2024, specializing in DNS infrastructure attacks against banks, payment processors, and cryptocurrency exchanges. Unlike conventional phishing groups that create lookalike domains, SHADOW RESOLVER compromises the DNS infrastructure itself — modifying legitimate domain records to redirect traffic to attacker-controlled servers. This approach defeats traditional anti-phishing defenses because victims navigate to the correct URL and see a valid TLS certificate.

The group's operational model: compromise DNS registrar accounts via social engineering of registrar support staff, modify A/AAAA records for target domains, obtain legitimate TLS certificates via automated certificate authorities (exploiting DNS-based domain validation), and operate credential harvesting proxies for 4–12 hours before reverting DNS changes. Average haul per operation: $2M–$8M in fraudulent transfers.

Motivation: Financial — credential harvesting at scale, real-time session hijacking, and fraudulent wire transfers. The group reinvests profits into increasingly sophisticated social engineering capabilities, including deepfake voice synthesis for registrar support calls.

Scenario Narrative¶

Phase 1 — Registrar Social Engineering (~30 min)¶

SHADOW RESOLVER begins by conducting reconnaissance on TrustNet's DNS infrastructure. WHOIS records reveal the registrar (SecureDomains), the administrative contact (it-admin@trustnet-financial.example.com), and the nameservers (ns1.securedomains.example.com, ns2.securedomains.example.com). The group also identifies the registrar's support phone number and customer portal URL.

An operator from SHADOW RESOLVER calls SecureDomains' support line using a deepfake voice clone synthesized from a conference presentation by TrustNet's CTO (audio scraped from a public YouTube video). The caller claims to be locked out of the registrar portal due to a lost phone (explaining inability to complete SMS MFA). The support agent, following an inadequate identity verification procedure, resets the account password after verifying only the organization name, domain name, and last 4 digits of the credit card on file (obtained from a previous data breach).

The attacker gains full access to TrustNet's registrar account at 2026-03-14T22:47:00Z — a Friday evening, when the bank's IT team is off-shift.

Evidence Artifacts:

Phase 2 — DNS Record Modification & Certificate Issuance (~30 min)¶

With registrar access, SHADOW RESOLVER modifies the DNS A records for banking.trustnet-financial.example.com to point to their attack infrastructure at 192.0.2.100 (a bulletproof hosting provider). The TTL is set to 60 seconds to ensure rapid propagation. The original A record pointed to 192.0.2.40 (TrustNet's legitimate banking server behind their CDN).

Simultaneously, the attacker requests a TLS certificate from FreeSSL CA (an automated certificate authority using HTTP-01 and DNS-01 domain validation). Because the attacker now controls DNS for the domain, DNS-01 validation succeeds immediately. A valid TLS certificate for banking.trustnet-financial.example.com is issued within 3 minutes. The attacker configures an nginx reverse proxy on 192.0.2.100 with the new certificate, proxying traffic to the legitimate banking server while intercepting credentials and session tokens.

Certificate Transparency (CT) logs record the new certificate issuance, but TrustNet does not monitor CT logs for their domains.

Evidence Artifacts:

Phase 3 — Credential Harvesting & Session Hijacking (~45 min)¶

The attack proxy at 192.0.2.100 is now live, presenting a valid TLS certificate for banking.trustnet-financial.example.com. When customers navigate to their banking portal (typing the correct URL or using bookmarks), DNS resolves to the attacker's server. The nginx reverse proxy forwards all traffic to the legitimate banking server at 192.0.2.40, creating a transparent man-in-the-middle position.

The proxy captures credentials in real-time: usernames, passwords, and MFA tokens (TOTP codes) as they are submitted. Because the proxy relays credentials to the legitimate server, users experience normal login behavior — they are unaware of the interception. The attacker also captures session cookies, enabling session cloning without needing to re-authenticate.

Over the next 6 hours (Friday 23:00 to Saturday 05:00 local time), 1,247 unique customers log in to online banking through the compromised DNS path. All credentials and session tokens are harvested.

Evidence Artifacts:

Phase 4 — Fraudulent Transactions (~30 min)¶

Using harvested session tokens, SHADOW RESOLVER begins executing fraudulent wire transfers from compromised accounts. They prioritize high-balance commercial accounts, initiating transfers to mule accounts at other financial institutions. The transactions are executed from 198.51.100.88 (a different IP than the proxy) using cloned session cookies.

Between 03:00 and 05:30 Saturday morning, the group initiates 34 wire transfers totaling $3.7M across 22 compromised accounts. The transfers target 8 different mule accounts at 5 financial institutions. TrustNet's fraud detection system flags 6 of the 34 transfers based on unusual timing and destination patterns, but the remaining 28 transfers ($2.9M) are processed successfully.

Evidence Artifacts:

Phase 5 — Detection, DNS Reversion & Containment (~30 min)¶

At 05:45 Saturday, TrustNet's on-call network engineer receives a PagerDuty alert: the bank's uptime monitoring service detects that banking.trustnet-financial.example.com resolves to an unexpected IP (192.0.2.100 instead of 192.0.2.40). The engineer escalates to the security team at 06:00. By 06:15, the CISO activates the incident response plan.

SHADOW RESOLVER, monitoring for detection indicators, reverts the DNS records at 06:10 — before TrustNet regains registrar access. The attack window was approximately 7 hours. The legitimate TLS certificate remains valid on the attacker's server, but with DNS reverted, no new traffic is directed there.

TrustNet contacts SecureDomains to lock the account and begin the registrar compromise investigation. The fraudulent TLS certificate is reported to FreeSSL CA for revocation.

Evidence Artifacts:

Phase 6 — Customer Notification & Recovery (~30 min)¶

TrustNet must now manage the aftermath: 1,247 customers had credentials compromised, 22 accounts had fraudulent transfers totaling $3.7M (of which $2.9M was successfully transferred), and customer trust is severely damaged. Regulatory notifications are required under state breach notification laws within 72 hours.

Evidence Artifacts:

Detection Opportunities¶

KQL Detection Queries¶

// Detect all logins from a single source IP (proxy indicator)
SigninLogs
| where AppDisplayName == "Online Banking Portal"
| summarize UniqueUsers=dcount(UserPrincipalName), UserList=make_set(UserPrincipalName, 20) by IPAddress, bin(TimeGenerated, 1h)
| where UniqueUsers > 50
| extend Alert = strcat("Single IP authenticated ", UniqueUsers, " unique users in 1 hour — possible MitM proxy")

// Detect session reuse from different IPs
BankingSessionEvents
| where EventType == "WireTransfer"
| join kind=inner (
    BankingSessionEvents
    | where EventType == "Login"
    | project SessionId, LoginIP=ClientIP, LoginTime=TimeGenerated
) on SessionId
| where ClientIP != LoginIP
| project TimeGenerated, SessionId, LoginIP, TransferIP=ClientIP, UserAccount, Amount
| extend Alert = "Session used from different IP than login — possible session hijacking"

// Detect DNS record changes via passive DNS monitoring
PassiveDNS
| where QueryName == "banking.trustnet-financial.example.com"
| summarize DistinctIPs=dcount(ResolvedIP), IPList=make_set(ResolvedIP) by bin(TimeGenerated, 1h)
| where DistinctIPs > 1
| extend Alert = "DNS resolution changed for banking domain — investigate immediately"

// Detect new TLS certificate issuance via CT logs
CertificateTransparencyLogs
| where SubjectDomain has "trustnet-financial.example.com"
| where Issuer != "ExpectedCA-Corp"
| where TimeGenerated > ago(24h)
| project TimeGenerated, SubjectDomain, Issuer, SerialNumber, NotBefore, NotAfter
| extend Alert = "Unexpected certificate issued for banking domain"

Splunk (SPL) Detection Queries¶

// Single IP serving multiple users — MitM proxy indicator
index=banking sourcetype=access_log uri="/api/auth/login"
| bucket _time span=1h
| stats dc(username) as unique_users values(username) as users by src_ip, _time
| where unique_users > 50
| eval alert="Possible MitM proxy: ".unique_users." users from single IP"

// Session IP mismatch — session hijacking
index=banking sourcetype=session_events
| stats values(src_ip) as ips dc(src_ip) as ip_count by session_id, username
| where ip_count > 1
| eval alert="Session used from multiple IPs — possible session cloning"

// DNS resolution anomaly for critical domains
index=dns sourcetype=passive_dns query="banking.trustnet-financial.example.com"
| stats latest(answer) as current_ip earliest(answer) as previous_ip dc(answer) as ip_count by query
| where ip_count > 1
| eval alert="DNS resolution changed for critical banking domain"

// Wire transfer anomaly — off-hours + new payee + high amount
index=banking sourcetype=wire_transfers
| eval hour=strftime(_time, "%H")
| where (hour >= 0 AND hour <= 6) AND amount > 50000
| lookup known_payees payee_account OUTPUT first_seen
| where isnull(first_seen) OR first_seen > relative_time(now(), "-30d")
| eval risk_score = case(amount>100000, 3, amount>50000, 2, true(), 1) + case(hour<6, 2, true(), 0) + case(isnull(first_seen), 3, true(), 1)
| where risk_score >= 5
| table _time, username, amount, payee_account, risk_score

Incident Response Checklist¶

Immediate Actions (0–2 hours)¶

• [ ] Verify DNS records for all bank domains from multiple global resolvers
• [ ] Contact registrar to lock domain account and revert unauthorized changes
• [ ] Identify and report any fraudulently issued TLS certificates for revocation
• [ ] Force-terminate all active banking sessions originating from suspicious IPs
• [ ] Freeze all customer accounts with activity during the attack window
• [ ] Contact receiving banks to freeze identified mule accounts — time-critical

Short-Term Actions (2–24 hours)¶

• [ ] Enumerate all affected customers from server logs during the attack window
• [ ] Initiate forced password resets for all compromised accounts
• [ ] Coordinate with law enforcement (FBI IC3, Secret Service Financial Crimes)
• [ ] File SAR (Suspicious Activity Report) for fraudulent wire transfers
• [ ] Begin customer notification per regulatory requirements
• [ ] Enable domain locks: clientUpdateProhibited, clientTransferProhibited, registry-level serverUpdateProhibited

Long-Term Actions (1–4 weeks)¶

• [ ] Deploy CT log monitoring for all bank domains
• [ ] Implement passive DNS monitoring and DNS record integrity checking
• [ ] Migrate customer MFA from TOTP to FIDO2/WebAuthn (phishing-resistant)
• [ ] Implement session IP binding or continuous authentication
• [ ] Add origin-bound session tokens to defeat session cloning
• [ ] Deploy CAA DNS records restricting certificate issuance to approved CAs
• [ ] Negotiate enhanced security procedures with domain registrar

Lessons Learned¶

What Went Wrong¶

What Went Right¶

ATT&CK Navigator Mapping¶

Related Chapters¶

• Chapter 31 — Network Security Architecture — DNS security, DNSSEC, network trust models
• Chapter 32 — Cryptography Applied — TLS/PKI, certificate validation, Certificate Transparency
• Chapter 25 — Social Engineering — Deepfake voice attacks, pretexting, registrar social engineering