OD2.4 Domain and Certificate Tradecraft

Operational Context

Your proxy flags newly registered domains: any domain less than 30 days old gets a risk score. The attacker knows this. They registered their C2 domain three months ago. It's aged past your threshold. It has a valid Let's Encrypt certificate. It resolves to a CDN. Your proxy gives it a clean score. The "newly registered domain" detection was your primary infrastructure defense, and the attacker walked past it by planning three months ahead.

Domain age is one signal, not a verdict. This sub teaches the five domain tradecraft methods attackers use, why each one defeats a specific reputation check, and where the staging pattern, visible across registration timing, certificate issuance, DNS history, and content progression, creates the detection surface that survives all of them.

Learning Objectives

By the end of this sub you will be able to:

• Assess domain legitimacy beyond registration age using four staging indicators (registration-to-activity gap, certificate issuance clustering, DNS history dormancy, content-to-age mismatch). The SUNBURST infrastructure used aged domains registered months before activation, domains that passed every newly-registered-domain check. This matters because "newly registered domain" detection catches beginners; professional infrastructure staging bypasses it by design.

• Monitor certificate transparency logs for pre-attack staging by querying crt.sh for certificates matching your organization's domain patterns (typosquats, homoglyphs) and detecting batch issuance that indicates infrastructure being prepared for a campaign. This matters because certificate provisioning is the one staging step the attacker can't hide: every certificate from a trusted CA is logged publicly, and the issuance timing reveals the staging schedule.

• Run a typosquat scan against your own domain and identify registered permutations that may be staged for phishing campaigns targeting your organization. This matters because the attacker registers login-northgate-eng[.]com weeks before the phishing email, detecting the domain registration is your earliest possible warning.

The Attack

You're about to understand why the attacker's C2 domain passed your proxy's reputation check with a clean score, and the tradecraft steps they took three months before the operation to ensure that outcome. By the end, you'll know each method, its cost, and the specific defensive check it defeats.

What the attacker is trying to achieve

The attacker's goal with domain tradecraft is reputation evasion, making their C2 domains, phishing domains, and payload hosting domains indistinguishable from legitimate infrastructure to your proxy, your threat intelligence feeds, and your analysts. They expect you to check domain age. They expect you to check certificate validity. They expect you to check web reputation scores. The domain portfolio is designed to pass every check.

The investment is minimal: $10 per domain, a free Let's Encrypt certificate, and patience. The payoff is that your primary domain-reputation defense: the proxy rule that flags new domains, is irrelevant. The attacker's infrastructure looks like any other legitimate website that launched after a planning phase.

Aged domains, patience as a weapon

The simplest tradecraft: register the domain early and wait. Most proxy and threat intelligence services use domain age as a primary risk factor. A 90-day-old domain is dramatically less suspicious than a 1-day-old domain.

Sophisticated operators register in batches — 10-20 domains across different registrars with varied naming patterns. They activate them sequentially as campaigns require. Here's what a typical staging timeline looks like:

Domain staging timeline, cdn-assets-update[.]com:

Jan 15  Registered at Namecheap with privacy protection ($10.88)
        DNS: parked at Namecheap default parking page
        No certificate. No content. No traffic.

Feb 10  Let's Encrypt certificate issued (free, automated)
        CT log entry: crt.sh records the issuance
        Still no real content. Certificate builds history.

Mar 1   DNS changed to point at Hetzner VPS (185.220.101.42)
        Basic "under construction" page deployed
        Reputation services start indexing the domain

Mar 20  Landing page updated to mimic a CDN status page
        JSON API endpoints added (/api/v1/status returns {"ok":true})
        Domain now looks like a legitimate SaaS service

Apr 15  ACTIVATION. C2 beacon starts calling back to /api/v1/check
        Proxy score: LOW RISK (90-day-old domain, valid cert, real content)
        Your NRD rule: silent (domain is 90 days old)

Three months of patience. $10.88 total cost. Your primary defense bypassed.

Typosquats, weaponising trust

Typosquatting creates domains that look like legitimate targets at a glance. The transposition, omission, or substitution of one character creates a domain a distracted user doesn't scrutinise:

Target domain:              Typosquats:
northgate-engineering.com → northgate-eng.com
                            nothgate-engineering.com
                            northgate-enginering.com
                            northgate-engineering.net

ridgelinecyber.com        → ridgellne-cyber.com
                            ridgeline-cyber.com
                            ridgelinecyber.org

Typosquats are particularly effective for phishing infrastructure. The AiTM proxy at login-northgate-eng[.]com looks legitimate enough in a phishing email that a user clicking on their phone during a meeting doesn't notice the difference.

Expired domains, buying reputation

Instead of building reputation from scratch, the attacker buys it. Expired domains retain their age, DNS history, backlinks, and reputation scores. A domain that was a legitimate small business website for five years has more trust than any freshly registered domain.

The tell is in the DNS history: the domain had stable records for years (original owner), then a resolution gap (the expiry period), then completely new infrastructure. That pattern, stable → gap → new, indicates ownership change. PassiveTotal and SecurityTrails show this history.

Certificate tradecraft: the padlock means nothing

Let's Encrypt issues valid, browser-trusted TLS certificates in minutes, for free. The browser shows the padlock. The user sees "secure." The domain is serving malware.

The detection opportunity: certificate transparency logs record every certificate issued by a trusted CA. The attacker provisions certificates for all their domains in one session — 10 domains, 10 certificates, all issued within the same hour. This certificate issuance clustering is visible in CT logs and is one of the strongest infrastructure-staging indicators available.

Here's what batch staging looks like in crt.sh results:

CT log query: crt.sh → Certificates issued to % containing "northgate"

2026-03-20 14:22  login-northgate-eng[.]com       Let's Encrypt  ← phishing
2026-03-20 14:23  vpn-northgate-eng[.]com         Let's Encrypt  ← phishing
2026-03-20 14:25  portal-northgate-eng[.]com      Let's Encrypt  ← phishing
2026-03-20 14:28  cdn-assets-update[.]com         Let's Encrypt  ← C2
2026-03-20 14:30  static-content-srv[.]com        Let's Encrypt  ← payload hosting

Five certificates. Eight minutes. Three are typosquats of the target.
Two are generic service-mimicking domains. All issued from the same
Let's Encrypt account in one session. This is infrastructure staging
for a campaign targeting Northgate Engineering, detected 26 days
before the first phishing email arrives.

Step 1. Build the attacker's domain portfolio (reconnaissance phase)

The attacker starts by researching the target's domain landscape. You're going to do the same thing, running the same tools the attacker runs before a campaign, against your own organization. This teaches you what the attacker sees and what they'll register.

# On your Linux VM:
# Install dnstwist if not already installed:
pip install dnstwist --break-system-packages

# Run against your primary domain (use northgate-engineering.com
# for the lab if you don't want to scan your own):
dnstwist --registered northgate-engineering.com

# Output: every typosquat permutation that is REGISTERED.
# Each line shows the permutation type (homoglyph, insertion,
# transposition, etc.) and whether it resolves to an IP.

Read the output like the attacker reads it. The attacker checks: which typosquats are available? Which are already registered (by defensive registrations, or by other attackers)? The available typosquats are the attacker's shopping list. The registered ones with no content are either defensive holds or dormant infrastructure from a previous campaign.

If dnstwist returns registered typosquats with recent certificates and live infrastructure, you may have phishing infrastructure staged against your organization right now. That's a finding, report it.

Step 2. Examine the attacker's certificate staging from CT logs

# Search CT logs for certificates matching the target domain:
curl -s "https://crt.sh/?q=%25northgate%25&output=json" | \
    python3 -c "
import json, sys
certs = json.load(sys.stdin)
for c in sorted(certs, key=lambda x: x.get('entry_timestamp',''))[-20:]:
    name = c.get('common_name', 'N/A')
    issuer = c.get('issuer_name', 'N/A')
    ts = c.get('entry_timestamp', 'N/A')[:19]
    print(f'{ts}  {name:45s}  {issuer[:30]}')
"

Look for the batch pattern: multiple certificates issued within the same hour from the same issuer for domains containing the target's name. That's an attacker staging infrastructure. The time gap between certificate issuance and the first observed attack is the attacker's planning window, typically 2–6 weeks for a targeted campaign.

Step 3. Reconstruct a domain's full staging timeline

Take a C2 domain from a recent investigation or threat report. Pull the full history using four data sources:

a. WHOIS: registration date, registrar, privacy protection
   → whois CLI or PassiveTotal

b. DNS history: when did the A record first appear?
   When did it change? Was there a parking/dormancy period?
   → SecurityTrails or PassiveTotal

c. Certificate timeline: when was the first cert issued?
   Were other certs issued the same day for related domains?
   → crt.sh

d. Web content history: what was on the domain at each stage?
   → Wayback Machine (web.archive.org)

Map the timeline:
  Registration → Dormancy → Cert issued → Content deployed → Activation
  The gap between registration and activation = the aging window.
  The number of co-registered domains = the campaign scale.

Step 4. Assess the campaign from infrastructure investment

Feed your Step 3 timeline into Claude for pattern analysis:

"I'm assessing whether this domain is attacker infrastructure.
 Here's the staging timeline:
 [paste registration, DNS history, cert timeline, content history]

 Analyse for staging indicators:
 1. Does the timeline suggest deliberate aging?
 2. Are there co-registered domains (same registrar, same day)?
 3. Does cert issuance timing suggest batch staging?
 4. Confidence: attacker infrastructure or legitimate?
 5. When did the attacker likely begin planning?"

The attacker's infrastructure investment is intelligence. A domain aged 90 days with a certificate batch means the attacker planned this campaign three months ago and has multiple domains in reserve. A domain registered yesterday with a self-signed certificate means the attacker is working fast with limited resources. Both assessments change your response strategy.

Success criteria: You've scanned for typosquats of your domain, identified certificate issuance patterns from CT logs, and reconstructed at least one domain's staging timeline using all four data sources.

Challenge: Set up a recurring CT log monitor for your domain. Use certspotter (free API), crtsh-monitor (open source), or your SIEM's threat intelligence integration to get alerted when a new certificate is issued matching your patterns. This converts a one-time exercise into a continuous detection capability.

Step 5. Build the attacker's domain batch from public data

The attacker registered a batch of domains. Find the batch from a single known domain: the same reconnaissance the attacker uses to verify their staging, and the same technique you use to find the rest of the infrastructure.

# Start with one known C2 domain:
# Step 5a. Find co-registered domains via WHOIS:
whois cdn-assets-update.com 2>/dev/null | grep -i "registrar\|creation"
# Note registrar and creation date. Search for other domains
# registered through the same registrar on the same date.

# Step 5b. Find co-hosted domains via passive DNS:
# VirusTotal: https://www.virustotal.com/gui/domain/cdn-assets-update.com/relations
# Check "Passive DNS", other domains on the same IP.

# Step 5c. Find the certificate batch:
curl -s "https://crt.sh/?q=%25cdn-assets%25&output=json" | \
    python3 -c "
import json, sys
certs = json.load(sys.stdin)
for c in sorted(certs, key=lambda x: x.get('entry_timestamp',''))[-10:]:
    ts = c.get('entry_timestamp', '')[:19]
    cn = c.get('common_name', '')
    print(f'  {ts}  {cn}')
"
# Certs issued within minutes of each other = same batch.

The batch size reveals the campaign's scale. One domain = one redirector. Five domains in a batch = multiple redirectors plus separate phishing and payload hosting.

Step 6. Assess reputation from the attacker's perspective

The attacker checks their domain's reputation before launching. Run the same checks:

1. VirusTotal: community score, detection count, categories
   → Attacker wants: 0 detections, benign category
2. URLScan: screenshot, technologies, connections
   → Attacker wants: legitimate-looking landing page
3. Google Safe Browsing: via Transparency Report
   → Attacker wants: "No unsafe content found"
4. Your proxy: submit the domain for categorization
   → Attacker wants: "Business/Technology" or "Uncategorized"

All four clean = the attacker's staging is complete.
The domain passes every reputation check you run.

What Your Attack Produced

Switch perspective. You've seen domain tradecraft from the attacker's side. Now look at it from yours, what does staged infrastructure look like in your threat intelligence feeds and log sources before the attack begins?

Domain tradecraft doesn't produce endpoint telemetry: the staging happens entirely outside your network. The "telemetry" is external: certificate transparency logs, passive DNS records, WHOIS registration data, and web reputation scores. These are your pre-attack detection sources.

CT log telemetry. The certificate issuance clustering from Step 2 is the highest-confidence staging indicator. Five certificates for domains containing "northgate" issued within 8 minutes from the same CA is not a coincidence. If you have CT monitoring running, this fires 2–6 weeks before the phishing email arrives.

CT monitoring alert (what your automated monitor produces):

ALERT: New certificate issued matching pattern "%northgate%"
  Common Name: login-northgate-eng[.]com
  Issuer: Let's Encrypt
  Issued: 2026-03-20 14:22:33 UTC
  Additional certs same session:
    vpn-northgate-eng[.]com      (14:23:01)
    portal-northgate-eng[.]com   (14:25:18)
    cdn-assets-update[.]com      (14:28:44)
    static-content-srv[.]com     (14:30:02)

Assessment: 5 certificates, 8-minute window, 3 typosquats
of your domain. This is infrastructure staging.
Recommended: block all 5 domains preemptively.

Passive DNS telemetry. When the attacker points the domain at their VPS, the DNS change is recorded by passive DNS services. The pattern: dormancy (no A record or parking page) → activation (A record pointing at a VPS in a hosting range). SecurityTrails and VirusTotal passive DNS show this transition.

WHOIS telemetry. Batch registration is visible: multiple domains registered through the same registrar on the same day, especially if they share a privacy service. The registrar and registration date are the batch fingerprint.

The prediction prompt asked what Sysmon events the attack generates. The answer: none. Domain tradecraft is entirely pre-attack. The endpoint telemetry only appears when the beacon starts calling the staged domain, and at that point, the detection is OD2.1's beaconing analysis, not domain tradecraft detection. The staging detection happens in your threat intelligence feeds, weeks before the endpoint ever sees the domain.

Detecting This

The detection targets the staging indicators visible in your proxy and DNS logs: domains accessed by your users that have the registration-to-activity gap, the certificate issuance cluster, or the DNS history dormancy that indicate staged infrastructure.

title: Connection to Recently Activated Domain on VPS Hosting
id: ad6f4e03-5e7b-8c9d-1e2f-3a4b5c6d7e8f
status: stable
description: |
    Detects outbound connections to domains hosted on VPS providers
    commonly used for attack infrastructure. Combined with domain
    age enrichment, this catches aged domains that were recently
    activated — the staging pattern that NRD detection misses.
references:
    - https://ridgelinecyber.com/modules/paid/od02-offensive-infrastructure/04
logsource:
    category: proxy
    product: any
detection:
    selection:
        cs-host|re: '.*'
    filter_internal:
        cs-host|contains:
            - 'yourdomain.com'
            - 'microsoft.com'
            - 'google.com'
    condition: selection and not filter_internal
    # Post-processing required: enrich with domain registration
    # date and hosting ASN. Alert if domain is hosted on known
    # VPS ASNs (Hetzner, DigitalOcean, Linode, Vultr, OVH) AND
    # has registration-to-first-resolution gap > 30 days.
    # Sigma alone cannot express the enrichment — use KQL/SPL.
falsepositives:
    - Legitimate SaaS services hosted on VPS providers
    - Development/staging environments on cloud VPS
level: low
tags:
    - attack.resource_development
    - attack.t1583.001

// Detect connections to domains on VPS hosting with staging indicators
// Requires: proxy logs ingested, TI feed with domain registration dates
// Alternative: use the manual CT log/DNS history workflow from the lab
let vpsASNs = dynamic(["AS24940", "AS14061", "AS63949", "AS20473",
    "AS16276", "AS51167"]);  // Hetzner, DigitalOcean, Linode, Vultr, OVH, Contabo
let trustedDomains = dynamic(["microsoft.com", "google.com",
    "amazonaws.com", "cloudflare.com", "akamai.com"]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceAction == "Allowed"
| where not(DestinationHostName has_any (trustedDomains))
| extend DomainParts = split(DestinationHostName, ".")
| extend RootDomain = strcat(DomainParts[-2], ".", DomainParts[-1])
| summarize
    RequestCount = count(),
    DistinctUsers = dcount(SourceUserID),
    DistinctHours = dcount(bin(TimeGenerated, 1h)),
    FirstSeen = min(TimeGenerated)
    by RootDomain, DestinationIP
| where RequestCount > 5 and DistinctHours > 2
// Manual enrichment step: for flagged domains, check:
// 1. Registration date vs first-seen in your logs (gap = staging)
// 2. crt.sh for certificate issuance timing
// 3. PassiveTotal for DNS history
// 4. Hosting ASN (whois on the IP)
| project RootDomain, DestinationIP, RequestCount,
    DistinctUsers, DistinctHours, FirstSeen
| order by RequestCount desc

// Defender XDR — Connections to uncommon domains on VPS hosting
let trustedDomains = dynamic(["microsoft.com", "google.com",
    "amazonaws.com", "cloudflare.com"]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionSuccess"
| where RemotePort == 443
| where not(RemoteUrl has_any (trustedDomains))
| summarize
    RequestCount = count(),
    DistinctHours = dcount(bin(Timestamp, 1h))
    by DeviceName, RemoteUrl, InitiatingProcessFileName
| where RequestCount > 5 and DistinctHours > 2
// Enrich flagged results with domain age and hosting info
| order by RequestCount desc

index=proxy sourcetype=proxy action=allowed dest_port=443
    NOT dest IN ("*.microsoft.com", "*.google.com",
        "*.amazonaws.com", "*.cloudflare.com")
| bucket _time span=1h
| stats count as request_count dc(_time) as distinct_hours
    dc(src_user) as distinct_users
    min(_time) as first_seen
    by dest dest_ip
| where request_count>5 AND distinct_hours>2
| sort - request_count
| head 50
`comment("Enrich top results with domain registration date,
hosting ASN, and CT log data. Flag any domain with
registration-to-first-seen gap > 30 days on VPS hosting.")`

The detection queries surface candidate domains. The enrichment step, checking registration date, certificate timeline, DNS history, and hosting ASN, is where the staging pattern becomes visible. Automate the enrichment where your tooling supports it. For everything else, the lab workflow (crt.sh + PassiveTotal + WHOIS) runs manually in under 5 minutes per domain.

Hunting. certificate issuance clustering

The strongest proactive hunt for infrastructure staging targets certificate transparency logs directly:

// Hunt: certificates issued for domains resembling your org
// Run monthly or when a campaign is suspected
// This is a crt.sh query, not a SIEM query:
// https://crt.sh/?q=%25northgate%25&exclude=expired

// In your SIEM, hunt for connections to domains with very recent certs:
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 443
| where not(RemoteUrlHost has_any ("microsoft.com", "google.com",
    "cloudflare.com", "amazonaws.com"))
// Cross-reference results against crt.sh for certificate age.
// Any domain where the cert was issued < 7 days ago AND the
// domain is connecting to your endpoints = potential active staging.
**Mitigation.** reducing the attacker's domain tradecraft advantage

**Deploy typosquat monitoring.** Run dnstwist against your primary domains monthly. When you find registered typosquats with live infrastructure, report them to the registrar's abuse team with evidence. Monitor the domains for DNS changes and certificate issuance.

**Subscribe to CT log monitoring for your domain.** Services like Certspotter, Facebook's CT monitoring, or your SIEM's integration with CT feeds alert when a certificate is issued for a domain matching your patterns. This detects phishing infrastructure staging days or weeks before the phishing email.

**Enrich your NRD detection with staging indicators.** Don't just check whether a domain is new. Check: is it hosted on a VPS provider commonly used for attack infrastructure? Is there a gap between the registration date and the first DNS resolution? Was the certificate issued in a batch with other similar-looking domains? Each additional signal converts a "low risk" proxy score into an investigation.

**Logging gaps.** what you're probably not seeing

**Gap 1. No domain registration enrichment.** Your proxy logs the domain and the disposition (allowed/blocked) but doesn't include the registration date. Without registration age in the log, your SIEM can't correlate domain age with access patterns. Consider enriching proxy logs with WHOIS data for unfamiliar domains, or use a threat intelligence platform that provides this enrichment.

**Gap 2. No CT log integration.** Without certificate transparency monitoring, you have no visibility into certificates issued for domains resembling yours. The attacker's phishing domain gets a certificate, and you don't know until the phishing email arrives. CT monitoring is free (crt.sh): the gap is integration, not cost.

**Gap 3. No DNS history in investigation workflow.** When an analyst investigates a domain, they check the current WHOIS and the current DNS. They don't check the DNS history (PassiveTotal, SecurityTrails) to see when the domain first resolved, whether there was a dormancy gap, or whether the infrastructure changed recently. Add DNS history to your investigation playbook.


**Verify against your own telemetry.** Run the detection queries from the tabs above against your lab SIEM. Your attack should appear in the results.


**Objective:** Set up certificate transparency monitoring for your domain and deploy the domain staging detection query in your SIEM.

**Prerequisites:** Access to your SIEM (Sentinel or Splunk). A browser for crt.sh. Access to your proxy logs.

**Step 1. Baseline your CT log exposure.**

Visit: https://crt.sh/?q=%25yourdomain.com%25 Review every certificate issued for your domain: a. Are all certificates ones your organization issued? b. Are there certificates for subdomains you don't recognize? c. Are there certificates for typosquats of your domain?

Document any certificates you didn't issue. These may be already-staged phishing infrastructure. Step 2. Deploy the domain staging query.

Copy the Sentinel KQL (or SPL equivalent) from the detection tabs into your SIEM as a scheduled weekly hunt. For the first run, use a 30-day lookback. Review the top 20 results:

For each result, answer: a. Is this domain a known business service? → Skip b. Is the hosting on a VPS provider? → Investigate c. When was the cert issued? (check crt.sh) → Recent = staging indicator d. When was the domain registered? (check WHOIS) → Gap = aging indicator e. What process is connecting to it? → Non-browser = C2 indicator Step 3. Set up recurring CT monitoring.

# Option A: crt.sh RSS feed (free, no setup)
# Bookmark: https://crt.sh/atom?q=%25yourdomain%25
# Check weekly for new entries

# Option B: Certspotter API (free tier, automated)
# Register at sslmate.com/certspotter
# Configure alerts for your domain patterns

# Option C: SIEM integration
# If your SIEM has a CT log connector, enable it and
# create an alert for certificates matching your domain
# name with a registrant that isn't your organization.

Success criteria: You've audited your CT log exposure, deployed a domain staging detection query, and set up recurring CT monitoring.

Challenge: Check whether the domains from your Step 2 results that look suspicious are hosted on the same ASN or registered through the same registrar. Co-registration (same registrar, same day) and co-hosting (same ASN) are batch-staging indicators. If you find a cluster, you've potentially identified a campaign's full domain portfolio from a single SIEM query.

Domain age is intelligence, not a verdict

The attacker's investment in domain preparation tells you as much about their operational profile as the infrastructure topology from OD2.1.

A domain registered yesterday and activated today: short timeline, high risk tolerance, low budget. The attacker is on a sprint and doesn't care about your NRD detection, they expect to deploy and burn within 48 hours. Classification: ransomware affiliate or opportunistic operator.

A domain registered three months ago, certificate issued two months ago, progressive content staging over weeks, activated against a specific target: long timeline, low risk tolerance, high planning investment. The attacker can afford to wait because the access is worth the preparation. Classification: state-sponsored or well-resourced criminal group with an intelligence or access objective.

A batch of five domains registered the same day through the same registrar, certificates issued in one session, all typosquats of the same target: campaign-scale preparation. The attacker is staging a multi-domain operation, phishing, C2, payload hosting, and possibly exfiltration on separate domains. The batch pattern reveals the campaign's scope before the first attack packet arrives.

The domain preparation is campaign intelligence. Read it.