Questions
Frequently Asked Questions
What goes into an analysis, how to read what comes out, and what each plan includes. For step-by-step walkthroughs, see the documentation.
Submitting data
What goes into a job, and what the platform does with it.
You submit IP addresses. The platform enriches each one from internet-wide scan data: open ports and service banners, TLS certificates and their fingerprints, JA3S and JARM values, SSH host keys, HTTP responses and page hashes, hostnames and domains, ASN and hosting organisation, known vulnerabilities and more. You do not upload the metadata yourself.
You can paste or upload individual IPv4 and IPv6 addresses, and IPv4 CIDR blocks. CIDR blocks are expanded to individual addresses before the job is submitted, so a /24 counts as 256 addresses against your quota, not one. IPv6 CIDR notation is not supported; list individual IPv6 addresses instead.
Up to 5,000 for an analysis job and up to 1,000 for a prediction job, further limited by whatever is left of your monthly quota. If what you paste expands past that limit, the list is truncated and the interface tells you where it cut.
There is also a floor, enforced at submission. An analysis job needs at least 10 addresses and warns below 20; a training job needs at least 50 and warns below 100. Those are minimums for the job to run at all, not the point at which results become good.
Automatic summary reports have a separate threshold: they are produced when at least 25 addresses survive enrichment. Addresses that enrichment finds nothing for drop out before that count is taken, so a list of mostly dark hosts can fall under the line even though you submitted more than 25.
One common cause is that enrichment found too little to analyse. The job needs a minimum number of addresses with usable scan data, and if too few survive enrichment it fails rather than clustering on nothing. Usually this means the addresses are mostly dark: no open services, no certificates, nothing that scan data records. That is a finding about the input rather than a platform error, though the job does end as failed and the error text it shows you is generic.
Failed jobs have their quota returned. Whatever the job reserved goes back: addresses for an analysis job, predictions for a prediction job, the model slot for a training job. A run that could not produce anything does not cost you anything.
Cancelling is different. If you cancel a job yourself, the concurrent-job slot frees immediately but the addresses or predictions it reserved stay spent — the work was already under way and the choice to stop it was yours.
Mostly not. When an analysis or training job completes, any addresses that enriched to nothing are credited back to your monthly address allowance automatically — you are not charged for hosts the scan data had nothing on.
The exception is prediction jobs, where every address you submit counts against your prediction allowance whether or not it turned out to carry usable data. If you are predicting against a list of uncertain quality, it is worth analysing it first.
Choosing a pipeline
Core, Deep and Advanced differ in how deeply your data is analysed before profiling begins. Neural Network sits on a different axis: it is about scoring new addresses against a model you have trained, not about analytical depth.
Core, unless you already know you need more. It preserves the finest detail and is the quickest way to see whether a dataset has structure worth chasing.
Move to Deep when Core groups things you believe should be separate, or when your data mixes very different kinds of attributes. Move to Advanced for high-stakes work on infrastructure whose shared characteristics are not obvious.
Neural Network is a different decision, not the next one along. It gives you a trained model to score new addresses against, so choose it when you expect to check the same kind of infrastructure repeatedly. It is not a deeper reading of a single dataset — if that is what you want, the answer is Deep or Advanced.
Deep or Advanced. APT infrastructure tends to share characteristics that only show up in combination, which is what Core is least suited to surface.
For ongoing tracking of an actor you have already characterised, train a Neural Network model on the known infrastructure and predict against it. That turns a recurring investigation into a cheap, repeatable check.
No — they answer different questions, so neither supersedes the other. Advanced goes deepest on a single dataset. Neural Network gives you a model to score future addresses against. Pick the one that matches what you are trying to do.
One practical difference: Neural Network always trains a model, so it works best with a few hundred addresses or more. Core, Deep and Advanced can be run purely to examine a dataset, which makes them the better choice when you are exploring, or when the dataset is small.
They also work well together — run Advanced to understand a dataset, then Neural Network to score against what you learned.
Yes — for analysis and training runs. Every tier produces the same STIX 2.1 and MISP exports, the same 3D visualisations, actor labels, anomaly scores, cluster profiles and summary reports, so anything you have built downstream keeps working when you change pipeline. Prediction jobs are the exception: they have their own result format and do not carry STIX/MISP exports.
Yes, if your plan includes both. Running a dataset through Core and then Deep or Advanced often surfaces patterns one approach finds and the other does not. For a high-priority investigation this is a reasonable use of quota rather than a waste of it.
Reading your results
The fields that get misread most often, and what they actually claim.
Almost certainly not. A cluster count higher than the number of device types in your data is the expected result, especially on Deep and Advanced.
The platform does not group hosts by what a device is. It groups them by the infrastructure fingerprint they present: TLS certificate fingerprints, JA3S and JARM values, SSH host keys, web page hashes, per-port service banners. Two mail servers running identical software land in different clusters when they present different certificates, because in practice that usually means different fingerprints — and telling them apart is the point.
So a run that resolves five device types into fifteen clusters has not fragmented your data. It has found fifteen distinct signatures, each separately pivotable: take its fingerprint, hunt it, find the rest of that operator’s estate.
A useful check when a cluster looks small: open its top features. If it separates on a certificate hash, a JARM value or a page hash, it is a fingerprint and it is real. If it separates only on geography or organisation name, that is a weaker grouping and worth less of your attention.
Two numbers share the name, and they are not the same measurement. On an analysis job it measures agreement: several independent clustering methods run over your data, and an IP’s confidence reflects how consistently those methods put it with the same neighbours. High confidence means the grouping is not an artifact of one method’s quirks.
On a prediction row it is not agreement at all. One trained model scores the host against the clusters it learned, spreading its probability across them, and the confidence is the share the winning cluster took. 90% means the model put nearly everything on that cluster; 40% means it was largely undecided — which is what the quality label beside it says in words.
Neither number is the probability that the IP is malicious, the probability that the actor label on its cluster is right, or a figure you can compare between jobs. A high-confidence member of a cluster of ordinary mail servers scores exactly like a high-confidence member of a C2 cluster — the number describes the grouping, not the verdict.
Not every row carries one. Several kinds of prediction row have no confidence at all, and telling them apart matters — the next question covers them.
Three different situations, which the platform deliberately keeps apart.
Out-of-distribution rows have both cluster and confidence blanked. Nothing the model knows fits the host, so any cluster it named would be a guess — and a low-confidence guess sitting in a cluster field is exactly what silently poisons a SIEM join or a detection rule. The candidate shortlist is still there if you want to see what was considered.
No-readable-input rows keep their cluster but lose their confidence. The host presented nothing on any service the model reads. Its cluster assignment is correct — it belongs with the other hosts that showed nothing — but the confidence is the model’s fixed reply to an empty input rather than a measurement of this host, so it is meaningless.
Not-enriched rows have no cluster and no confidence because they never reached the model at all: no scan record came back for the address, so there was nothing to put through it. This one is about our data, not about your host. On real jobs it is not rare — check whether the address is live and in scope before reading anything into it.
An out-of-distribution host is unusual, a no-readable-input host is quiet, and a not-enriched host we simply have not seen. Hunt the first, re-check your scan coverage for the second, and re-run the third once it has been scanned.
Read this field before you read the confidence number.
- Confident match
One cluster clearly wins and the runner-up is well behind. Actionable.
- Ambiguous (split)
Two or three clusters are genuinely competing. The answer is probably in the shortlist; look at what separates the candidates instead of taking the leader on faith.
- Ambiguous (diffuse)
Nothing dominates; the model spread its attention thinly across many clusters. Weak signal, worth time only if something else already made the host interesting.
- Out of distribution
Nothing fits. Work the host on behavioural evidence, not on this model's opinion.
- No readable input
The host exposed nothing the model reads. Not a finding about the host at all.
- Not enriched
No scan record came back for the address, so nothing was scored. A gap on our side; there is no cluster and no confidence to read.
Because they are different facts, and merging them loses the more interesting one. Absent means the host never presented that field. Unrecognized means it presented the field with a value never seen before — an unfamiliar certificate issuer, an organisation name that appears nowhere in the training data. The second is a lead, and the explanation shows you the actual value so you can pivot on it.
They are the explanation’s own honesty flags, and they often matter more than the score they sit next to. A near-tie flag says the leader barely won. A thin-evidence flag says very few candidates were genuinely in contention.
A confident match with no caveats is the strongest thing the platform emits. A confident match carrying three caveats deserves the scepticism you would give an ambiguous one.
It ranks a host against the rest of the same dataset. The thresholds come from your data’s own distribution, so the score says how unusual a host is relative to its peers in that job. It is not an absolute severity and it does not transfer between jobs — a score of 15 in one run and a score of 15 in another have no relationship. The percentile alongside it is the comparable figure.
Act on the percentile and the severity band beside it, and read the behavior analysis for what made the host stand out. In noise intelligence results, the data table also shows detector agreement — an address flagged by several independent detectors is a far stronger finding than one flagged by a single detector.
A cluster is discovered from your data — a set of hosts presenting the same infrastructure fingerprint. An actor label is matched onto that cluster afterwards, by testing curated rules against the hosts’ characteristics.
So an unlabelled cluster is not an empty result: it is coherent infrastructure nobody has published on yet, which is often the more valuable finding. And a label with a confidence percentage is a rule match, not attribution — where an investigation starts, not where it ends.
Hosts that fit no cluster are set aside as noise. Rather than discarding them, the platform re-analyses the noise set on its own terms whenever it holds more than 20 addresses, looking for structure that was invisible at the scale of the full dataset.
This matters because a small, careful, deliberately unremarkable set of hosts is precisely what does not survive first-pass clustering, and precisely what is worth finding.
Each cluster gets a query describing the characteristics that define it, written against public scan data. Two uses: validation, where you compare the number of live matches against your cluster’s size (a cluster of twelve matching twelve hosts is a tight fingerprint; one matching forty thousand is describing something generic), and expansion, where the hosts it returns that were not in your dataset become candidates for the rest of that operator’s estate.
One caveat when reading the match count: not every characteristic can be expressed as a search filter, because each data source supports its own limited set. Where a cluster’s sharpest feature is not queryable, the query is necessarily broader than the cluster — so a high match count can mean the query is loose rather than the cluster being generic. Check which characteristics actually made it into the query before concluding a cluster is weak.
Running analyses over time
What stays stable between runs, and when to re-run rather than re-train.
Substantially, but not bit-for-bit. The same addresses, pipeline and settings produce the same cluster structure and the same headline findings. Small numeric differences are possible because parts of the analysis run on GPU hardware where floating-point results are not guaranteed identical between runs, and that can occasionally move a genuinely borderline host to a neighbouring cluster. When a host shifts between two otherwise identical runs, that is itself information: it was never firmly in either group.
Cluster numbers are not stable across jobs and carry no meaning on their own. Do not write a detection rule or a report that refers to "cluster 3" from a previous run. Compare by membership and by fingerprint, which is what the neighbourhood and evolution views do for you.
Re-run when you have new addresses and want them grouped from scratch. Analysis is unsupervised — it makes no reference to earlier jobs and will find structure your previous runs never saw.
Predict when you have new addresses and want them scored against infrastructure you have already characterised. This is the cheap path, and what the monthly prediction allowance is for.
Re-train when the infrastructure itself has moved: new hosting, rotated certificates, changed tooling. A rising share of out-of-distribution verdicts on addresses you believe belong to a tracked actor is the clearest sign the model has aged out of usefulness.
Plans, quotas and access
What each plan includes, and what happens when you reach a limit.
The four paid plans are Analyst, Team, Professional and Enterprise. Your current plan is shown on your profile and on the subscription page.
Every address in a submitted job, counted once at submission, including each address a CIDR block expands to. The monthly allowances are 500 addresses on Analyst, 1,000 on Team, 2,500 on Professional and 5,000 on Enterprise.
Predictions and hunting queries draw on their own separate allowances.
One on Analyst, one on Team, two on Professional, three on Enterprise. Queued and running jobs both count. Submitting past your limit is rejected with a quota error rather than queued, so wait for a slot or cancel something.
Every plan can reset its quotas immediately with a one-time payment instead of waiting for the billing cycle. The price for your plan is shown on your profile page.
Team and above. The public API covers prediction against your trained models: submit addresses, poll for status, retrieve results. Analyst does not include API access.
Five stored models on Team, Professional and Enterprise. Analyst includes neither model training nor storage. This is a limit on how many you hold at once, not a monthly allowance — deleting a model frees its slot.
Models are kept until you delete them. There is no expiry, so a model you trained months ago is still there to predict against.
Advanced requires Professional or above. Its dataset-specific optimisation runs on higher-specification GPU infrastructure reserved for Professional and Enterprise, and that hardware is the main thing Professional pricing pays for. Deep is available from Team upward, and Core on every plan.
Enterprise only. These are models trained and published by the Chawkr team against known actor infrastructure, so you can score addresses against an actor without first collecting and clustering that actor’s estate yourself.
Yes. Custom quotas are arranged through [email protected].
Something not answered here? Write to [email protected].