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, so the next question covers them.
Five 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. 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. Nothing came back from the host: either no service answered, or the ones that did returned empty responses. It sits with the other hosts that presented nothing, so the grouping is correct. What is meaningless is the score, which would describe the model’s standing reply to an empty input rather than this address.
Not-covered-by-this-model rows look identical on the row but are a different fact, and the platform gives them their own label for that reason. The host does have scan data; it is simply not the kind this model reads. That is not a quiet way of saying the host is bare or low-risk. It may be running plenty, outside the model’s scope. Read the raw scan record rather than the prediction.
Model-has-no-opinion rows blank both fields, and the limit is ours rather than the host’s: the model was built from too little data to tell its own clusters apart, so it declines to attribute rather than guessing. The address and its scan data are fine. A model trained on more data is what changes this row.
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, so check whether the address is live and in scope before reading anything into it.
So: an out-of-distribution host is unusual, a no-readable-input host answered with nothing, a not-covered host answered with things this model does not read, a no-opinion row is the model admitting its own limits, and a not-enriched host we simply have not seen. Hunt the first. Read the raw record for the second and third. The last two are ours to fix, with a better-trained model or a scan.
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
Nothing came back from the host. Not a finding about the host at all, so check scan coverage for the address.
- Not covered by this model
The host answered, but with services this model was never trained to read. It is NOT a quiet way of saying the host is bare: go and look at the raw scan record.
- Model has no opinion
The model was built from too little data to tell its own clusters apart, so it makes no attribution. A limit of the model, not a finding about the host.
- 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, or 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 rather than attribution. It is 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, 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.
What the analysis can and cannot tell you
Where scan data runs out, what we deliberately do not ask you for, and how far a result is worth pushing.
Because scan data records what a host presents to the internet, not what it did to you. Open ports, certificates, fingerprints, banners and page hashes describe how a machine is built and configured. None of them carry intent, history, or the reason an address ended up on your list. Clustering is very good at "these hosts are put together the same way" and structurally incapable of "this one brute-forced our VPN on Tuesday night".
That missing piece is context, and it is what decides meaning. A single data point rarely tells you anything on its own. When several weak signals line up, the picture is worth acting on. The platform supplies the alignment, across thousands of fields at a speed no analyst can match by hand. You hold the signals it cannot see: your logs, your tickets, your telemetry, the incident that made you care about these addresses in the first place.
There is a second limit worth naming. Passive scan data only reads what is exposed to the scanner. An operator who blocks the scanning provider’s ASN or geography at the edge turns up in the corpus as a dull, uninteresting host. That is a built-in blind spot rather than random noise, and no amount of clustering recovers a service that was never visible.
So read a result as a fast, reproducible reading of infrastructure shape, which is a real and useful thing to have. Who is behind it, and why, is the part that comes from you, even if ClusterHawk provides insights to that.
Because that answer belongs to you, and holding it would make us a target on your behalf. If you told us that 40 of these addresses are brute-force sources, 12 are phishing infrastructure and the rest are your own estate, we could weight the features that separate those cases automatically and hand back tidier groupings. That is a real accuracy gain, and we have deliberately left it on the table.
The reason is what that sentence actually is. "These addresses hit our VPN last Tuesday" is not a configuration setting. It is your investigation: what you were hit by, when you noticed, which parts of your estate you are worried about, and how far you have got in understanding it. Gathered across every customer and kept in one database, it becomes a live map of who is being hit by what. Connecting context reaching the wrong hands is the thing blue teams are right to lose sleep over, and we are not willing to be the place where that map exists.
So the platform takes addresses and nothing else. No case note, tags or no incident context describing what you think each host did. The trade is deliberate: you keep the sharpest information about your own investigation, and you get the controls to apply it yourself. You know why these addresses are on the list, so you set the emphasis, and you stay the filter between what you know and anyone else’s systems.
Set the weights. Every job exposes thirteen feature groups: vulnerabilities, certificates, JA3 and JARM fingerprints, hashes, hostnames, domains, algorithms, products, HTML fields, redirects, tags and certificate chains. Each one starts at 1.0 in the form and accepts any value between 0 and 10. What you submit is an adjustment rather than an absolute setting: the pipeline carries its own tuned weighting for every feature group, and your number scales it. Leaving a field at 1.0 keeps that tuning as it is. Sending 1.2 pushes the feature group up from wherever we have it, 0.6 pulls it down, and the clustering weighs differences in those fields accordingly.
What to raise follows from what you are chasing. If you are tracking an operator whose addresses rotate but whose TLS setup does not, push the certificate, JA3 and JARM weights up and the hostname and domain weights down, because those churn. If you are chasing a phishing kit, the HTML fields and page hashes are where the reuse shows. Five presets ship as starting points, among them Security-Focused, Threat Hunting and Research Mode; each one just fills in all thirteen fields for you, and you can edit any of them afterwards.
The other half is what goes into the job at all. Forty addresses you believe share one behaviour will answer a question that a batch of "everything odd this week" cannot. Seeding a run with a coherent population and letting the platform find what those hosts have in common is a far stronger method than submitting a mixed list and hoping the groupings sort it out for you. Two hypotheses are two jobs.
No, the summary and full reports describe and interpret one job. They read the clusters that run produced, the features that define each one, which hosts were flagged as anomalous, what the labelling rules matched and where the evidence behind a grouping is thin. Everything in them is derived from your dataset and the scan data behind it.
What they are not is a reading of your data against the body of published threat intelligence. Producing that would mean holding every vendor report, campaign write-up, telemetry pattern and historical signature in memory and reasoning across all of it at once. Chawkr is not that company, and a product claiming to be is selling certainty it does not have. The report will not tell you that your cluster resembles infrastructure someone else documented two years ago, because it has not read that write-up.
Threat intelligence written by hand is not 100% accurate either. It is graded evidence and competing hypotheses, some of it close to bulletproof and much of it circumstantial, with experienced analysts publicly disagreeing about the same infrastructure. A pattern gets you to a pivoting and tracking point. It does not get you to court-grade forensics, whoever produced it.
Read the report for what it is good at: a consistent account of what this dataset contains and which parts of it deserve your time. Then finish the investigation with the sources we do not have.
Scale the claim to the evidence behind it, in two steps.
First, agreement across methods. When several independent clustering methods put the same hosts together, the grouping is robust to how you looked at the data rather than an artifact of one algorithm’s quirks, and that is what the confidence score on an analysis job measures. It corroborates exactly one thing: your finding is not an accident of method. It says nothing about whether the underlying scan data was right or complete, because every method read the same data.
Second, agreement across sources. Confirming the data itself takes something genuinely independent: passive DNS, your own telemetry, a competing scan provider, a vendor report, sinkhole data. One source is a lead. Two independent sources is a finding.
In practice a cluster is enough to justify hunting it and watching it. On its own it is not enough to justify blocking a large range, naming an actor in something you publish, or sending an abuse complaint to a hosting provider. Match the action to the number of independent sources behind it, and do not let a single source, however vivid, harden into a verdict.
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, and 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].