See infrastructure earlier
Monitor domains, DNS, certificates and hosting changes before suspicious infrastructure becomes a full incident.
Threat Alerts
Catch suspicious infrastructure before it reaches users.
Datazag monitors domains, DNS, certificates and infrastructure changes for early signs of platform abuse, brand impersonation and suspicious keyword-led infrastructure.
Each alert is delivered with reason codes, infrastructure context and a recommended action path so teams can block, investigate, watchlist, escalate or de-escalate with evidence.
Alert workflow
From signal to action
Observe internet changes, filter known-good infrastructure, attach reasons and deliver alerts into the workflow that can act.
Alert ingredients
Domains
DNS
Certificates
Infrastructure
Brands
Platforms
Keywords
Evidence
Operational value
Earlier signals. Clearer actions. Less alert noise.
Alerts are only useful when the receiving team knows what changed, why it matters and what action is appropriate.
Separate the response
Platform abuse, brand impersonation and suspicious keyword infrastructure need different operational actions.
Reduce noisy matches
Candidate alerts are checked against known-good infrastructure, brand baselines, platform patterns and cloud footprints.
Deliver into workflows
Send reasoned alerts to SOC queues, partner portals, Palo Alto, Microsoft Sentinel, Splunk, webhooks, APIs or data shares.
Alert classes
Different infrastructure patterns need different responses.
A platform lure, an owned-brand impersonation and a suspicious subdomain on a parked apex domain should not be routed in the same way.
Platform impersonation
Response
You don't own the impersonated platform, so there's no takedown here — this is defense. The alert routes to your SOC or detection engineering team to block, enrich, and write detections before the lure lands in an inbox.
Infrastructure staged to mimic a platform your people log into — Microsoft 365, Okta, Google Workspace, a VPN portal etc.. The goal is to capture credentials from your employees. The practical response is usually blocking and detection rather than takedown unless the customer owns the affected brand.
Platform termsLogin luresKnown-good DNS comparisonCloud allowlistsRelated infrastructure
Brand impersonation
Response
corpus matching and certificate monitoring against your registered marks and lookalike permutations. Capture evidence - logos and website state, identify abuse contacts to support your takedown workflows.
Infrastructure staged to mimic your brand — or a partner's — to defraud your customers or harvest credentials under your name. Unlike platform impersonation, this is yours to remediate: it routes to brand protection, fraud, or legal, and drives an evidence pack and a takedown.
Owned brandsAliasesSuspicious wordingWebsite evidenceAbuse contacts
Infrastructure Identification
Response
Examples of what fires here: A domain whose apex is parked while a subdomain resolves to separate, active infrastructure — a common staging tell. Hosting and certificates that recur across previously flagged campaigns, indicating a persistent operator rather than a one-off. Prefix and routing anomalies — MOAS events, RPKI-invalid announcements, churn consistent with transient or bulletproof hosting.
The stages above wear a name — a brand or a platform — which is what makes them detectable by term. This type is different. It catches the infrastructure that the downstream actors operate on: the reused hosting, the transient and anomalously-announced networks, the DNS structures that never advertise a recognizable brand and so slip past name-based monitoring entirely
Related domainsRelated IPsShared hostingPrefix changesBGP/MOAS signals
Signal pipeline
From internet change to operational alert.
The alert is the output of collection, matching, filtering, explanation and delivery. Each stage is designed to make the signal more usable.
1→
Observe
New domains, subdomains, certificates, DNS and infrastructure changes are captured.
2→
Match
Candidates are matched against platforms, brands, keywords, watchlists and suspicious naming patterns.
3→
Filter
Known-good DNS, platform baselines, cloud allowlists and approved customer footprints reduce false positives.
4→
Explain
Reason codes, confidence context, infrastructure evidence and suggested action are attached to the alert.
5
Deliver
Alerts are sent to the operational route that fits the team: webhook, API, SIEM, portal, report or data share.
Annotated example
What a reasoned alert looks like.
A useful alert is not just a domain and a severity. It shows the action path, the matched lure, the infrastructure context, the reason codes and how quickly the signal moved through the pipeline.
PLATFORM | RED
Platform Risk Escalated | exchange.ws
Incident ID
INC-1782384515-13ec9b
Classification
RED → ISSUE_BLOCK_NOTICE
Match
Platform — exchange
Customer
Generic
ASN Risk Score
1.00 · critical
ASN
AS14618 Amazon AES
Registration
—
Detected Hosting Infrastructure
52.20.84.62 (behind aws)
Confidence
48/100
Reason codes
- • Platform impersonation targeting 'exchange' (Category: Microsoft 365)
- • Domain not found in known 360M+ corpus
- • infra: ELEVATED_NETWORK_TYPE
- • infra: CERTSTREAM_ANOMALY
- • infra: MALICIOUS_IP_DENSITY
- • infra: PREFIX:BGP_MOAS_SPECIFIC_NEW_ORIGIN
- • infra: ASN:critical
- • infra: CDN_FRONTED:aws
E2E Latency: 4.415s | DNS Resolution Phase: -1ms
Classification
RED → ISSUE_BLOCK_NOTICE tells the receiving workflow this is a block-notice candidate rather than a general observation.
Match
The alert identifies the platform lure and category, here an Exchange/Microsoft 365-themed platform signal.
Infrastructure risk
ASN score, hosting IP, CDN/fronting context and BGP/MOAS signals explain why the infrastructure is higher risk.
Reason codes
Analysts and automations can see the individual signals that caused escalation instead of treating the alert as a black box.
Latency
E2E latency shows how quickly the alert moved through the detection pipeline; DNS resolution phase is reported separately.
Evidence
Every alert should explain itself.
The goal is not to send more alerts. The goal is to give teams enough context to make a decision quickly and consistently.
Reason codes
Why the candidate escalated: brand term, platform term, suspicious keyword, DNS activity, certificate event or infrastructure risk.
Infrastructure context
Hosting provider, ASN, DNS, certificate, related domains, related IPs, novelty and relationship signals.
Known-good checks
Comparison against approved customer infrastructure, brand DNS, platform baselines and cloud footprints.
Recommended action
Block, investigate, watchlist, prepare evidence, route for review, de-escalate or monitor for content.
Feedback path
Customer or analyst feedback can de-escalate accepted findings and improve future routing.
False-positive controls
Filtering happens before the alert reaches the team.
Brand and platform terms collide with legitimate infrastructure every day. The alerting layer needs evidence, allowlists and feedback paths to stay operationally useful.
Approved baselines
Customer domains, brand DNS, known cloud footprints and recognized platform infrastructure are used to avoid obvious false positives.
Context before severity
A naming match alone is not enough. DNS, certificates, hosting, novelty and relationship signals change routing and severity.
De-escalation feedback
Accepted findings and known-good infrastructure can be de-escalated so teams are not forced to handle the same noise repeatedly.
Use cases
One alert layer, multiple operational motions.
The same infrastructure signal can support internal SOC work, managed services, brand protection, ESP abuse workflows and data-driven security operations.
SOC and threat hunting
Prioritize emerging infrastructure before campaigns create incident volume.
MSSP and MDR delivery
Package early alerting, evidence and customer reporting into managed detection services.
Brand protection
Separate blocking workflows from evidence-pack and takedown workflows for owned brands.
ESP abuse workflows
Score suspicious links, domains and infrastructure flowing through email platforms.
Data-driven security teams
Join alerts with lakehouse, SIEM, ticketing and case-management workflows.
Delivery
Use the route that fits the workflow.
Alerts can be consumed as live operational events, enrichment calls, evidence packs or analytical datasets depending on the team using them.
Webhooks
Push alert events into launch integrations for Palo Alto, Microsoft Sentinel and Splunk, or into custom ticketing, SOAR and portal workflows.
API
Score, enrich and retrieve alert context inside products, review queues and case-management tools.
SIEM and SOC tools
Route alerts and reason fields into detection, investigation and response workflows, including Sentinel and Splunk environments.
Reports and evidence packs
Package findings for executives, customers, takedown workflows and account reviews.
Cloud data shares
Use Iceberg or Delta datasets for analytics, hunting, enrichment and historical review.
Next step
Start with the alert classes that match your workflow.
Begin with platform abuse, brand impersonation, keyword infrastructure, infrastructure anomalies or customer-specific watchlists, then route the alerts into the workflow that can act on them.