Open Check an indicator and enter the exact value you want to investigate. Use the full URL when its path matters; a domain lookup may not represent every URL hosted beneath it.
A result reflects the information available to CRDF at the time of the lookup. Interpret it with its verdict, categories and update time, and do not open a suspicious URL merely to test it. For automated or repeated lookups, use the current API documentation and the permissions attached to your API key.
CRDF Threat Center is CRDF Labs' public cyber-threat-intelligence service for checking, reporting and understanding potentially malicious URLs, domains and other supported indicators. It provides public lookup and submission workflows, detection criteria, selected statistics, API access and a route to request Private CTI services.
Use the malicious URL submission form and provide the exact URL whenever possible. Submit only indicators you are authorized to share, and do not include passwords, API keys, personal data or unrelated confidential material.
A submission is a signal for evaluation, not a guarantee of an immediate or particular classification. Organizations that need automated submission should review the API overview and the applicable Terms of Service.
The homepage is publicly accessible, so potentially dangerous indicators are shortened or censored to reduce accidental visits, automated fetching and unnecessary exposure. The preview demonstrates the type and freshness of CRDF intelligence without publishing a clickable list of harmful destinations.
Security professionals who need structured access should use the approved public workflows, the API, or request Private CTI access.
For an API, account, billing or technical issue that is not covered by a dedicated secure thread, use the contact form. Sending the same matter through several workflows does not accelerate it and can separate information from the authoritative thread. Never include passwords, complete API keys or private links.
Check the address entered in the form, then review the mailbox's spam, quarantine and filtering folders. Allow time for temporary delivery retries and make sure the mailbox can receive external messages. Temporary or disposable addresses may be rejected because they cannot reliably support verification and follow-up.
Do not create a duplicate request solely because an email is delayed. If the message remains unavailable, contact support with the public request reference and the affected indicator. Do not send a private thread URL, verification token, password or API key.
First use the most recent message sent by CRDF and open the link without copying extra punctuation or changing it. A link may stop working after expiry, replacement, completion of the workflow or a security reset.
If access is still unavailable, use the contact form and provide only the public request reference and a short description of the affected step. Never forward or publish the secure URL or its token. CRDF will indicate the appropriate recovery route after verifying the request.
A CLEAN result means CRDF does not currently present the checked indicator as malicious in the relevant result. It is not a permanent certification, legal approval or guarantee that every page, subdomain, redirect or future version is safe.
Content, ownership, hosting and surrounding security context can change, so later observations may support a different conclusion. Always check the exact indicator and its update time. If a current classification appears inaccurate, use the false-positive review.
CRDF does not operate a public browser-blocking product and does not take down websites or domain names. It produces cyber-threat-intelligence assessments that customers or third-party security services may use within their own filtering, warning or review processes.
A removal or suspension decision belongs to the relevant hosting provider, registrar, platform or competent authority. Those parties also control their own refresh schedules and interfaces. CRDF cannot directly change every downstream display, although correcting the current CRDF record can support later updates. If CRDF's present classification appears inaccurate, use the false-positive review process.
CRDF publicly exposes four principal operational URL classifications:
Phishing:URL: the assessed URL is involved in deceptive impersonation or social engineering intended to obtain credentials, authentication codes, payment information or other sensitive data, or to direct a visitor toward that activity. This label does not require a downloadable malware payload.
Malware:URL: the assessed URL hosts, distributes, delivers or directly facilitates malicious software or a malicious payload. It can include a download location, a delivery step or infrastructure used to support that delivery.
Malicious:URL: the assessed URL meets CRDF's public malicious-content criteria, but a narrower public label such as phishing or malware is not appropriate or sufficiently representative. It can cover other harmful activity such as malicious redirection, exploitation, fraud or compromised content. This label does not necessarily mean that the URL serves an executable file.
Suspect:URL: the assessed URL presents suspicious, incomplete or ambiguous indicators that warrant caution or further review, but CRDF does not currently present it as confirmed malicious. It is neither a confirmed malicious classification nor a statement that the URL is clean.
Some feeds or integrations may return a value beginning with Malware:URL/. The suffix is a contextual malware family name or descriptive tag available for that observation. It can be generic or source-dependent and must not be treated as definitive malware-family attribution.
CLEAN is a result or verdict, not one of these URL category labels. It means that CRDF does not currently present the exact checked indicator as malicious in the relevant result; it is not a permanent certification or guarantee.
Every label applies to the exact indicator and observed context at a given time. It does not automatically classify every path, subdomain, domain or shared IP address around it. These operational labels are also separate from AI contextual categories such as finance, hosting or technology, which describe apparent site purpose rather than maliciousness.
A classification may change as content and context evolve or following review. CRDF publishes general detection criteria but does not disclose case-specific signals, thresholds, protected sources or anti-evasion logic. If a current classification appears inaccurate, use the false-positive review process.
CRDF combines multiple forms of technical and contextual analysis to produce an operational risk assessment. It is not based on one keyword, one external opinion or one static label.
CRDF publishes general detection criteria and may provide a limited public explanation, but it does not disclose case-specific internal signals, thresholds, source routing, model details or anti-evasion logic. To challenge an inaccurate result, provide current, verifiable facts and remediation through the review workflow; private detection internals are not required to request reassessment.
The verdict is the main operational conclusion, such as clean, suspicious or malicious. A risk score helps prioritize results but is not a category or guarantee by itself. Primary and secondary categories describe the main context associated with the result.
Suspicious means the available information warrants caution but does not support presenting the indicator as confirmed malicious. Interpret all fields together with confidence, public evidence summaries and update time when available. Integration field names and schemas are maintained in the API documentation.
CRDF AI assesses supported domains and URLs to support risk prioritization, categorization and security investigation. Its outputs are probabilistic security signals and may change as the observed indicator and available context evolve.
A contextual category describes the apparent type or role of a site or service; it is separate from the security verdict. For example, a finance, technology or hosting category does not by itself mean that an indicator is malicious. Interpret the verdict, risk information, category and confidence together.
CRDF does not publish internal feature weights, thresholds, training datasets, protected sources, model artifacts or anti-evasion logic. AI output is decision support, not a security certification, legal determination or guarantee.
The public CRDF AI output can include the following fields, depending on the service and permission:
verdict: the current operational conclusion, such as safe, suspicious or malicious.
risk_score and risk_band: normalized prioritization indicators; neither is proof by itself.
primary_category, its group, confidence and taxonomy version: the principal operational family associated with the result.
secondary_category_safe, its family, confidence and source: a conservative contextual category that may remain Unrated/Unknown.
secondary_category_decision, its family, confidence and source: a best-effort contextual interpretation that must be read with its confidence.
Public evidence-summary fields: limited non-sensitive context when available.
Taxonomy, model and schema versions: identifiers used to interpret the output format.
Creation, update, capture or scoring timestamps: the relevant evaluation times exposed by the selected operation.
A public source field is a high-level provenance identifier; it does not disclose protected source details or the complete reasoning path.
Public contextual-category examples include Marketplace/Classifieds, Retail/Ecommerce, Finance/Banking, Education/Knowledge, News/Media, Video/Streaming, Social Networking, Email, File Sharing/Storage, Developer/Technology, AI/ML, Software Downloads, Cloud/Infrastructure, CDN/Content Servers, DNS/Dynamic DNS, URL Redirect, Ads/Analytics, Adult/Mature, Phishing, Malicious and Unrated/Unknown.
The taxonomy and exposed fields can evolve. The versioned API documentation is the reference for integration schemas. CRDF does not publish internal weights, thresholds, protected sources, raw training data or anti-evasion logic.
CRDF may publish a limited interpretation layer such as a verdict, risk information, categories, confidence, update time and a high-level explanation. Internal investigation notes, protected data, exact decision logic, thresholds and source handling are not public.
This separation provides useful context without weakening the service or enabling evasion. Public output is not a complete forensic report. Access, use and redistribution remain subject to the Terms of Service and any contract attached to your account.
Use the dedicated false-positive review form; classification disputes sent through the general contact form cannot be processed as reviews. Enter the exact URL, domain or IP address, provide a real reachable email address and add concise, verifiable context.
Keep the reference and secure thread link sent to you. Temporary or disposable addresses may be rejected because they cannot reliably support confirmation, ownership checks or follow-up. Do not create duplicate requests while the same indicator is already under review.
CRDF keeps one active review workflow for the same relevant indicator so that verification, evidence and decisions remain in one auditable thread. The message means an existing request is still open or waiting for an action.
Do not submit another form. Use the reference and secure link from the original email, review the current status and complete any requested step. If the email is unavailable, check the original mailbox and spam folder before contacting support. Never publish the private thread link or its token.
Open the secure link in the confirmation email. Queued or processing means the review is continuing; awaiting verification or information means an action is required; reassessment means new information is being evaluated; closed means no further action is currently pending. The thread's message is authoritative for the next step.
Add genuinely new evidence inside that thread whenever it permits a reply. If support is needed because the link is unavailable, provide only the public reference and indicator—never the private URL, passwords or API keys.
When ownership verification is required, the thread displays the methods available for that request, commonly a DNS record or an eligible domain email address. Follow the displayed instructions exactly and never send registrar or hosting credentials.
If the domain is permanently decommissioned or returns NXDOMAIN, keep the existing review and explain the situation there. Do not recreate a DNS zone or repurchase a domain solely for verification. An alternative method is not guaranteed; CRDF will indicate whether the available public and administrative context is sufficient or whether the request cannot proceed.
A CLEAN decision reflects the reviewed scope and information available at that time; it is not a permanent allowlist. A later classification can occur when the indicator is observed again in a newly relevant security context, even if its owner reports no intentional change.
CRDF does not disclose the exact internal trigger for a reclassification. Check the current result and exact affected value. If it appears wrong, use the existing thread when it permits reassessment or submit a new review for the current listing without duplicating an active request.
Third-party services control their own cache, refresh schedule and presentation of contributor results. A clean CRDF decision updates CRDF's current record, but CRDF cannot guarantee when another platform will fetch or display that change.
First verify the exact indicator with CRDF's checker. Then use the third party's refresh or rescan feature if available and allow its report to update. Do not open repeated CRDF requests solely because an older snapshot remains visible. If CRDF itself lists the indicator again, follow the re-detection guidance.
There is no guaranteed public completion time. Duration depends on the indicator, the evidence available, any required ownership or email verification, and whether further review is needed. The status and next action shown in the secure thread are authoritative.
Do not submit duplicate requests or repeated messages to accelerate a review. Complete any requested step and add only genuinely new, verifiable information in the existing thread. If access to the thread is unavailable, contact support with the public reference only.
Provide the indicator's legitimate purpose, the exact affected URL, relevant remediation, important dates and why the current result appears inaccurate. If a compromise was fixed, summarize what was secured without disclosing credentials, customer data or sensitive forensic material.
The decision applies to the indicator and scope identified in the thread. Clearing one URL does not necessarily evaluate every path, subdomain, related domain or shared IP address. Check the exact value in the outcome and use separate public lookups where appropriate.
The exact value submitted does not have a current CRDF listing eligible for review. Check for typing errors and distinguish between a full URL, its parent domain, a subdomain and an IP address. The CRDF record may also have changed since a third party last refreshed its display.
Confirm the current value with Check an indicator. If CRDF is clean but another service shows an older result, use that service's refresh process rather than opening a duplicate CRDF request.
No public process can guarantee that an indicator will never be assessed or classified again. CRDF may apply internal safeguards when appropriate, but they are discretionary, reviewable and do not create permanent immunity from future security observations.
CRDF does not publish internal allowlisting criteria or anti-abuse controls. To challenge a current classification, use the false-positive review. Do not submit repeated reviews merely to seek a permanent bypass.
Use the API key request page and accurately describe the intended integration and expected use. A standard key grants only approved public capabilities; it does not automatically include Private CTI or redistribution rights.
Keep the key in a server-side secret store. Never place it in a public repository, browser URL, screenshot, client-side application or support message. If exposure is suspected, stop using it and request revocation or replacement through the Customer Area or support.
HTTP 401 means the request could not be authenticated: the key may be missing, malformed, inactive, revoked or presented incorrectly. HTTP 403 means the key was recognized but does not grant the requested operation or scope.
Compare the sanitized request with the current API documentation. Repeating a request cannot add a missing permission. If the operation requires a different access level, use the Private CTI access page or contact support without including the secret key.
HTTP 429 means an applicable usage or protection limit has been reached. Stop immediate retries, honor any retry guidance returned by the API and use exponential backoff with jitter. Do not create multiple keys or distribute calls to bypass an assigned limit.
If normal optimized usage needs more capacity, provide the methods, expected average and peak volume, purpose, and whether the workload is temporary or ongoing. Approval is case-specific and may require another access plan. Contact support without including the API key.
Some analyses are queued rather than completed in the initial request. Store the returned public reference or job identifier, then use the documented status operation until a terminal state is reached.
Poll at a reasonable interval, apply backoff and stop when the API reports completion, failure or expiry. Do not repeatedly submit the same indicator because a result is not immediate. Exact states and fields are versioned in the API documentation; integrations should tolerate documented non-terminal states and handle errors explicitly.
Provide the endpoint or method, UTC timestamp, HTTP status, public error code, request identifier if available and a minimal sanitized example. State whether the issue is consistent or intermittent.
Remove API keys, authentication headers, personal data and confidential indicators unless CRDF explicitly provides a secure channel. First check the API documentation for authentication, scopes, schemas and retry guidance. If the issue remains, use support with those sanitized diagnostics.
Organizations and qualified professionals with a legitimate cybersecurity, research, protection or data-exchange purpose may apply. Approval is not automatic and public API access does not create an entitlement to the private dataset.
The process generally includes a real professional contact address, a clear use case, identity and organization validation, a background review, acceptance of the applicable documents, and payment when the selected offer is paid. Follow the secure onboarding workflow and provide only the information requested there. Start at Private CTI access.
Private threat intelligence can be sensitive and may be misused without appropriate access controls. CRDF therefore checks that the applicant, organization, authority and stated purpose are credible and consistent with the requested service.
The review is an access-control measure, not a public judgment. Provide only information requested through the secure workflow and do not email identity documents unless explicitly instructed through an approved channel. Personal data is handled under the Privacy Policy and applicable data-protection rights.
An NDA is required whenever the selected Private CTI workflow or offer states that it is a condition of access. The acceptable agreement depends on the service and contractual model.
Do not assume that a customer NDA, mutual NDA or modified wording will be accepted; an alternative must be reviewed and approved in writing through onboarding. If no acceptable agreement is completed, access cannot be provisioned. Raise contractual questions in the secure onboarding thread before signing.
Paid offers follow the payment and activation steps displayed in the secure onboarding workflow. Payment does not replace identity checks, contractual acceptance or another pending approval; access is activated only after all required conditions are complete.
Keep billing and organization information accurate. For a payment retry, invoice issue or activation mismatch, use the onboarding or customer thread and provide the public request reference—not card details, banking credentials or secret access keys.
Existing customers with an active feed entitlement can open the Private CTI feed portal. The feed README documents the available files, formats, update schedule and download paths. Flat-file downloads use the private-feed username and password issued to your organization through HTTP Basic authentication.
This feed login is separate from the Customer Area, which is accessed with an email magic link followed by a one-time code (OTP) and is used for account and API-key management. Integrations should also consult the current API documentation. If access no longer works or an entitled feed is missing, contact support without sending passwords, API keys, authentication headers or private links.
Rights depend on the source, access level and intended use. Viewing public results, calling a public API, receiving Private CTI and redistributing data are not equivalent permissions. Technical access alone does not authorize republishing, resale, sublicensing, model training or customer delivery.
The Terms of Service, API permissions and any signed customer documents define what may be stored, shared or commercialized. Obtain written authorization before using CRDF data in a downstream product or feed.
TLP labels indicate how widely cybersecurity information may be shared. TLP:RED is limited to named recipients, TLP:AMBER permits restricted need-to-know sharing, TLP:GREEN permits sharing within an appropriate community, and TLP:CLEAR permits public disclosure subject to normal legal rights.
Always follow the exact label and accompanying instructions. TLP does not replace an NDA, licence or data-protection obligation; the most restrictive applicable requirement still matters. See the authoritative FIRST TLP guidance and your CRDF contract.
A report means CRDF associated an indicator under your apparent operational responsibility with a security concern. It is not a legal judgment and may concern a customer resource, compromised site or shared service.
Investigate the exact URL, hostname and time in the message rather than assuming the entire shared platform is classified. Use the report's preference or response mechanism when available. If the cited indicator is no longer present or appears inaccurate, provide concise evidence through the designated review route without sending credentials or sensitive customer data.
CRDF does not publish a complete list of scanner source addresses or other operational details that could enable selective evasion. Networks should apply normal, content-neutral security controls rather than grant privileged access to an unverified scanner.
If traffic creates an operational problem, record sanitized timestamps and request characteristics, then contact support. Do not post logs containing credentials, session tokens or unrelated personal data. CRDF can review a concrete issue without disclosing protected infrastructure details.
Depending on the service, CRDF may process contact, account, request, security, billing and technical data needed to operate the platform, prevent abuse, communicate outcomes and meet legal obligations. Details are maintained in the Privacy Policy.
Use the dedicated GDPR rights request form for access, erasure, portability or objection. Provide only enough information to identify the relevant processing and confirm the request through the message sent to you before processing can continue.
Verification prevents personal data from being disclosed, changed or deleted at the request of an unauthorized person. CRDF may request additional information to confirm identity when it has reasonable doubts. Follow only the methods displayed in the secure request workflow and do not send unnecessary identity documents by ordinary email.
CRDF aims to respond without undue delay and normally within one month of receiving the request. The period may be extended where legally permitted and the requester is informed. Limited information may remain when a lawful security, evidentiary or compliance obligation applies, or direct identifiers may be irreversibly removed.
A GDPR request concerns personal-data rights; it is not the classification appeal process. To challenge an inaccurate URL, domain or IP result, use the false-positive review.
If the same situation also involves your personal data, you may separately submit a GDPR request, but the workflows have different purposes and outcomes. Erasing eligible personal data does not automatically require deletion of non-personal threat-intelligence records, and clearing a classification does not automatically erase account or audit data retained for another lawful purpose.
CRDF Labs is operated from France as an independent cybersecurity laboratory within the legal and professional framework described on the site. Current publisher identity, registration details, hosting information and official contact routes are maintained in the Legal Notice.
Use that page rather than older FAQ wording when legal details are required. Independence describes CRDF's editorial and operational position; it does not mean the service has no legal operator or that every service is non-commercial.
CRDF's internal detection technology is not sold as a transferable engine. CRDF may, however, provide free or paid services such as API access, Private CTI, data exchange or related professional access under defined terms.
Availability, pricing, usage rights and approval depend on the current offer and contract. Access does not transfer ownership of CRDF technology or authorize redistribution. Start with the API overview or Private CTI access and review the Terms of Service.
No. CRDF Labs does not handle requests from journalists or media organizations, including requests for interviews, quotations, statements or public comment. Messages of this nature are closed without further processing.
Operational matters must use the dedicated workflows documented on this site. A press or media request does not replace a classification review, GDPR request, customer-support thread or another required procedure.
Security researchers and organizations with a concrete partnership or data-exchange proposal may use the contact form. Identify yourself and your organization when applicable, describe the purpose and expected scope, and provide a safe way to continue the discussion.
Share only the minimum information needed for initial routing. Do not include credentials, complete API keys, private thread links, unnecessary personal data or sensitive third-party material. A contact request does not guarantee a response, partnership, access approval or permission to use or redistribute CRDF data.