Platform alerts
High-value cloud, identity, email, storage, payment and collaboration platforms are monitored for abuse.
Real-time Threat Alerts
Catch attack infrastructure before it reaches users.
Datazag monitors the changing internet for early signs of phishing, impersonation and malicious infrastructure. New signals are investigated, filtered against known-good infrastructure, correlated and delivered as actionable alerts into the workflows your team already uses.
Real-time Threat AlertsOutput
Signal
Context
Correlation
Confidence
Action
Brand alerts
Brand impersonation coverage focuses on the world's most targeted brands and customer-specific brands.
Keyword infrastructure
Suspicious subdomains can carry the lure even when the apex domain is parked, generic or otherwise low-value.
False-positive controls
Candidate matches are filtered against known brand DNS, platform baselines, cloud allowlists and infrastructure evidence.
The problem
Attack infrastructure is not always a clean platform or brand match.
Attackers do not only copy a company's brand. They reuse the platforms people already trust: login providers, cloud services, payment brands, email platforms, storage tools and collaboration suites.
They also use more generic infrastructure patterns: a parked or low-value apex domain with suspicious keywords pushed into subdomains such as login, secure, verify, billing, update or support.
Datazag separates these into different alert classes because the operational response is different: platform alerts are usually for blocking, brand alerts can support takedown, and keyword/subdomain infrastructure alerts are often for investigation, blocking and watchlisting.
The first pass finds suspicious candidates using brand terms, platform terms, keywords, DGA indicators and entropy signals. The second pass checks those candidates against known-good DNS, standard platform infrastructure, brand baselines and cloud allowlists so legitimate infrastructure is not treated like an attack.
- 01
Observe
New domains, subdomains, certs, DNS and infrastructure changes are captured.
- 02
Classify
Signals are separated into platform, brand, keyword/subdomain and supporting infrastructure context.
- 03
Filter
Candidates are checked against known DNS, platform baselines, cloud allowlists and brand infrastructure.
- 04
Act
Clients receive the right action path: block, investigate, watchlist, de-escalate or prepare takedown.
Alert types
Three alert classes need different responses.
Datazag checks high-value platforms, major global brands and suspicious keyword-led infrastructure. Platform hits dominate observed impersonation activity, but a third pattern is also important: the lure appears in the subdomain while the apex is parked, generic or not obviously malicious on its own.
Platform
trusted services and SaaS brands abused as the lure.
Brand
customer-owned or high-value brands targeted directly.
Keyword
suspicious subdomains on parked or low-value apex domains.
Block and reduce exposure
Platform impersonation alerts
A customer usually does not have standing to request takedown for a fake platform they do not own. The practical action is to block, enrich detection, and watch whether the same infrastructure begins targeting the customer's own brands or users.
Coverage
Cloud, identity, email, collaboration, storage, payment and SaaS platforms.
Primary action
Block, investigate related infrastructure, monitor for brand crossover, or de-escalate if approved.
- Matched platform pattern and category
- DGA, entropy and suspicious naming signals
- Comparison against standard platform DNS and known-good infrastructure
- Cloud allowlist checks to reduce legitimate platform and customer infrastructure matches
- Client de-escalate link for known-good or low-risk findings
Evidence pack and takedown
Brand impersonation alerts
When the alert targets a brand the customer owns or represents, Datazag can update the alert with evidence suitable for takedown or abuse reporting once a live website appears.
Coverage
Top global brands, customer-owned brands, subsidiaries, domains and known aliases.
Primary action
Prepare takedown evidence when a website appears, including screenshot and abuse contact, or de-escalate if approved.
- Brand match and affected domain
- DGA, entropy and suspicious naming signals
- Comparison against known brand DNS, standard infrastructure and approved cloud footprints
- Website screenshot and abuse contact when content appears
- Client de-escalate link for accepted or false-positive findings
Investigate, block and watchlist
Keyword infrastructure alerts
These alerts do not necessarily match a monitored platform or owned brand. The risk sits in the combination of suspicious subdomain language, parked or low-value apex domain, new DNS activity, hosting context and related infrastructure behaviour.
Coverage
Suspicious subdomains using lure terms such as login, secure, verify, billing, update, wallet or support on parked, generic or low-reputation apex domains.
Primary action
Investigate the subdomain, block if appropriate, monitor related infrastructure, and de-escalate if the customer recognises it.
- Suspicious keyword in subdomain rather than apex domain
- Parked, inactive or low-value apex domain context
- Entropy, DGA, corpus novelty or fast-path infrastructure signals
- DNS, hosting, ASN and certificate context for investigation
- Client de-escalate link for known-good or accepted findings
All three alert classes support a client de-escalation action. The difference is the recommended response: platform impersonation is primarily a blocking and detection problem; brand impersonation can become an evidence and takedown workflow; keyword/subdomain infrastructure alerts are usually an investigation, blocking and watchlist workflow.
How it works
From internet change to actionable alert.
- 01
Observe
New domains, subdomains, certs, DNS and infrastructure changes are captured.
- 02
Classify
Signals are separated into platform, brand, keyword/subdomain and supporting infrastructure context.
- 03
Filter
Candidates are checked against known DNS, platform baselines, cloud allowlists and brand infrastructure.
- 04
Act
Clients receive the right action path: block, investigate, watchlist, de-escalate or prepare takedown.
Decision-ready output
Signals become evidence, evidence becomes confidence, confidence becomes action.
The purpose is not to show more data. The purpose is to reduce uncertainty at the point where a team, customer or system has to make a decision.
Example platform alert
What an operational platform alert looks like.
This example is based on a platform-risk alert flowing into a Slack channel. The format is intentionally compact: enough context for a first decision, with reason codes that explain why the alert escalated.
Why this matters
The alert is designed to show the domain, the matched entity, the infrastructure context, the confidence and the evidence trail in a form that can flow straight into operational channels.
PLATFORM | RED
Platform Risk Escalated
RED
www.apple-du.ph
Incident ID
INC-1782484980-55c8ca
Classification
RED → ISSUE_BLOCK_NOTICE
Match
Platform — apple
Customer
Microsoft
ASN risk score
0.95 · medium
ASN
AS63949 Linode AS63949
Detected hosting
45.79.222.138
Confidence
48/100
Reason codes
- Platform impersonation targeting 'apple'
- Domain not found in known 330M corpus
- infra: ELEVATED_NETWORK_TYPE
- infra: CERTSTREAM_ANOMALY
- infra: ASN:medium
- infra: FAST_PATH_DENSITY_SURGE
E2E latency: 3.923s
Example brand alert
What a brand evidence-pack alert looks like.
This fictional example shows the brand workflow. Unlike a platform alert, the recommended action can move beyond blocking into evidence capture, abuse reporting and takedown support when the customer owns or represents the affected brand.
Why this matters
The alert is designed to show the domain, the matched entity, the infrastructure context, the confidence and the evidence trail in a form that can flow straight into operational channels.
BRAND | RED
Brand Impersonation Escalated
RED
secure-brand-login.test
Classification
RED → EVIDENCE_PACK_READY
Match
Customer-owned brand
Website status
Live page detected
Screenshot
Captured and attached to evidence pack
Abuse contact
Hosting provider abuse mailbox identified
Recommended action
Submit takedown notice or de-escalate
Reason codes
- Brand term present with suspicious login/security wording
- Candidate does not match known brand DNS or approved cloud footprint
- Website content observed and screenshot captured
- Hosting provider and abuse contact resolved for evidence pack
Evidence pack updated when website content appeared
Example keyword infrastructure alert
What a keyword/subdomain alert looks like.
This fictional example shows the third alert class. The apex domain may be parked or generic, but the active subdomain carries suspicious lure language and starts to resolve through infrastructure that deserves investigation.
Why this matters
The alert is designed to show the domain, the matched entity, the infrastructure context, the confidence and the evidence trail in a form that can flow straight into operational channels.
KEYWORD | AMBER
Suspicious Subdomain Infrastructure
RED
verify-account.parking-domain.test
Classification
AMBER → INVESTIGATE_OR_BLOCK
Keyword signal
verify-account
Apex status
Parked or inactive apex domain
Match
No monitored platform or owned brand match
Detected hosting
New DNS resolution observed
Recommended action
Investigate, block or watchlist related infrastructure
Reason codes
- Suspicious keyword present in subdomain
- Apex domain appears parked, generic or low-value
- Subdomain activity differs from apex-domain posture
- Infrastructure context requires investigation rather than takedown workflow
Alert generated when subdomain and infrastructure activity were observed
Packaging
Alert use cases.
SOC and threat hunting
Prioritise suspicious infrastructure before campaigns create incident volume.
Brand and platform impersonation
Separate blocking workflows from evidence-pack and takedown workflows.
Keyword infrastructure
Detect suspicious lure terms in subdomains, especially where the apex domain is parked or generic.
False-positive review
Use DNS baselines, approved cloud infrastructure and de-escalation feedback to keep alerts operationally useful.
MSSP and MDR delivery
Package early infrastructure intelligence into managed detection and customer reporting.
Next step
See the infrastructure forming around your organisation.
Start with an external platform threat report, then move into real-time alerting for platform abuse, brand impersonation, suspicious keyword infrastructure and the signals that connect them.