77% of Flock Safety’s Public DNS Namespace is Development Infrastructure

By Adrian Cheek, Senior Cybercrime Researcher

What Passive DNS Discloses About the Systems Behind the Cameras

Automated license plate readers and AI-assisted video surveillance have moved from a handful of pilot deployments to tens of thousands of installations across US towns, business parks and residential streets. Anyone can see the cameras, but the cloud platform behind them is a different story. This includes the services that ingest the footage, the search interfaces that police departments query, and the development pipeline that ships changes to both.

In January 2026, independent researchers found that a number of Flock Safety’s pan-tilt-zoom cameras were reachable on the open internet without authentication. One researcher’s initial discovery was extended by Jon “GainSec” Gaines to 67 exposed live feeds and debug web interfaces. That was a carrier-side misconfiguration affecting a specific set of field devices, and it has been widely reported. This research asks a different question: without touching a single camera, what does Flock Safety’s own public DNS record disclose about the architecture behind it?

The answer is a great deal. A single passive DNS collection against flocksafety.com returned 416 hostnames, of which 290 survive filtering as legitimate. Every proportion in this report is expressed against those 290 observed legitimate hostnames, not against the company’s infrastructure as a whole. Of the 290, 222 belong to development infrastructure, including 191 short-lived environments named after individual code changes. 32 names resolve to private, non-routable addresses, mapping Flock’s internal addressing scheme across development, production and government-boundary estates. None of this required a scan, a login, or any interaction with Flock infrastructure.

Flock Safety is among the most heavily researched vendors in its sector. A formal white paper published in November 2025 cataloged 45 issues across its devices; separate research in January 2026 documented hardcoded credentials at scale. This report does not revisit that ground. It examines a surface none of that work addressed, which is the company’s own public DNS record.

Key Findings About Flock Safety’s Own DNS Records

• Flock Safety’s public DNS namespace is predominantly development infrastructure. Development names outnumber production names by more than three to one.
• Per-change preview environments are published in public DNS, each name disclosing a repository identifier and a sequential change number. Nine distinct repositories are identifiable, with change numbers running into the thousands in the largest.
• 32 hostnames resolve to private, non-routable addresses. The pattern is consistent enough to infer the internal addressing plan: one RFC 1918 range for development services, a second for production internals, a third on the government side.
• A numbered series of tunnel proxy endpoints resolves to internal addresses. This is consistent with the outbound device check-in layer that makes the camera fleet itself undiscoverable by scanning.
• A parallel government-boundary namespace exists, which is good practice. Development instances of those same government-side services also exist, which is not.
• A code review platform, an alerting platform and an identity provisioning endpoint are all named publicly under the corporate domain.
• A wildcard DNS record inflated the raw namespace by 43%. Any census that fails to filter it will overstate Flock’s estate by nearly half.
• Credentials for 23 corporate identities on the company’s email domain appear in criminal credential datasets. Eight of those identities appear in formats built specifically for credential stuffing, and the most recent record was collected in August 2026.

Headline Metrics

Table 1. Headline metrics. Percentages are of the 290 legitimate hostnames observed, not of total infrastructure. These are floor figures. Passive DNS records only what a resolver has been observed to answer, so every count understates the true namespace.

What Passive DNS Reaches That Scanning Does Not

Active discovery against Flock produces very little. A certificate-name query across a major internet-wide scan platform returned 63 hosts, all of them cloud load balancers and API gateways. No cameras appeared, and none should have: the field devices connect outbound to the platform and do not accept inbound connections. A census of the camera fleet by scanning is not achievable, which is why the January 2026 exposure was newsworthy, as it was an exception.

Passive DNS is a different instrument. It records what resolvers have been observed to answer over time, aggregated from many vantage points. It does not require the name to be reachable, or the service to be running, or the record to still exist. A hostname created for a development environment that lived for six hours in March is still in the record in August.

That property is what makes it valuable for this class of target and what makes it a liability for the organization being examined. An estate can be entirely well-defended at the network layer and still publish a detailed description of itself in DNS.

A Development Estate Published in the Clear

Of 290 legitimate hostnames, 222 carry a development prefix. Of those, 191 follow a single pattern: a development prefix, a repository identifier, and a sequential number corresponding to an individual proposed code change.

Table 2. Per-change preview environments by repository. Repository names are withheld; see Methodology and Limitations.

Automatically deploying a preview environment for every proposed code change is ordinary modern practice and improves review quality. Publishing each one in public DNS is a choice, and it has consequences that are easy to miss.

First, the namespace discloses the shape of the engineering organization: how many services are under active development, which are changing fastest, and, from the sequential numbers, roughly how many changes each has accumulated. In the busiest repository, the observed numbers exceed 2,900.

Second, preview environments are the weakest tier by design. They exist for hours or days, they are provisioned automatically, and the controls applied to production, such as enforced authentication, network restrictions and logging, are frequently relaxed so that reviewers can use them quickly. An attacker who can enumerate them does not need to guess which ones exist.

This concern is not theoretical for this vendor. Research published by Nexanet in January 2026 documented an unauthenticated flaw by which Flock’s development environment issued valid access tokens scoped to its production environment. Those tokens granted access to the geographic mapping of the camera network. That research reported the issue as still unremediated more than 55 days after disclosure. A development tier able to mint production credentials is the tier an adversary most wants to enumerate, and the namespace described here is how that enumeration is done.

Third, the pattern is predictable. Once the naming convention is known, an adversary can generate candidate names for change numbers that have not yet appeared in passive DNS and test them directly. Removing a name from public DNS after the fact does not undo this.

Internal Addressing in Public Records

Thirty-two hostnames resolve to private, non-routable addresses, 41 distinct addresses in total. These are not reachable from the internet, and their disclosure is not directly exploitable. It is, however, free reconnaissance for anyone who later obtains a foothold.

The pattern is consistent enough to infer the addressing plan. One RFC 1918 range carries development services. A second carries production internal services. A third appears exclusively behind government-side names. Twenty-six hostnames explicitly labeled internal resolve within these ranges, which means the names are published to the public DNS system while the services they describe are not intended to be publicly reachable.

Among the names disclosed this way are a code review platform, an alerting and monitoring platform, a data archiving service and a metrics exporter. For an intruder inside the environment, this is a target list and a subnet map that would otherwise take considerable time and noise to assemble.

The Device Tunnel Layer

A numbered series of tunnel proxy endpoints appears in the record, each resolving to a private production address. The observed subset is not contiguous, and the highest number observed implies at least 17 such endpoints exist.

This is the architecturally significant finding in the dataset. It is consistent with the mechanism by which field devices reach the platform: the camera opens an outbound tunnel to a proxy, the platform reaches the camera through that established connection, and the device itself never listens for inbound traffic. Flock describes its devices as connecting to the cloud over private IoT cellular networks, which is consistent with this model. That design is why scanning cannot enumerate the fleet, and it is sound.

The exposure lies in the public description of its structure, not in its existence. The observed numbering may provide a rough indication of the scale or segmentation of the device-access layer, though it does not map one-to-one to fleet size: a numbered series of this kind could equally represent regional ingress, capacity, redundancy or sharding. The naming convention makes the series enumerable. If this layer does terminate device connections, it would be a high-value target, because a component that brokers access to field devices concentrates reach that no individual device holds. That characterization follows from the interpretation set out above and is not independently evidenced.

A Government Boundary With Development Tiers

13 hostnames sit in a distinct government-boundary namespace, including a service mesh component named for federal use. Maintaining a separate estate for government customers is exactly the right architecture for a company whose customers are law enforcement agencies, and its presence should be read as a positive control.

Five of those 13 are development instances of government-side services. A development tier that mirrors a service inside a regulated boundary raises questions a public DNS record cannot answer: whether it holds representative data, whether it sits inside the same accreditation boundary, and whether it is subject to the same access controls. Those questions belong to Flock’s assessors, but the namespace is what prompts them.

Contamination: A Wildcard Record Inflated the Namespace by 43%

The raw collection returned 416 hostnames. Of those, 126 of them are not real, and they sit beneath a single subdomain configured with a wildcard DNS record, which answers for any label presented to it. The observed labels are unrelated to Flock entirely, comprising media franchises, foreign-language strings, and unrelated brand names, and are the residue of scanning and probe traffic being answered and then recorded.

Three properties identify them:

• Nearly all have a lifetime of one day
• Nearly all were first and last observed on the same date
• They all resolve to a small rotating set of addresses shared across the whole group

Any of the three is sufficient to filter them; none of the three requires interaction with Flock.

The point extends beyond the present case. Wildcard records are common, and a subdomain census that does not filter for them will overstate an organization’s estate, here by 43%. Discovery generates hypotheses, not populations.

Credentials in Circulation

Architecture is one route into a platform, and credentials are a shorter one. Flare’s credential dataset was queried for the company’s corporate email domain, returning 42 records covering 23 unique corporate identities. 37 of those records carry a password artifact. Collection dates run from April 2020 to August 2026, and 26 of the 42 records were collected since January 2025. The dataset therefore indicates continuing exposure rather than a purely historical tail. Credential validity was not tested and is not claimed.

The records fall into two populations that behave very differently, and the split is the finding.

Table 3. Credential exposure by population. Counts are of records held in one commercial dataset and represent a floor, not a total.

The first population is unremarkable and universal. 16 identities appear only in breaches of unrelated consumer services: a data enrichment aggregator, a fraud prevention service, a parking payments platform, a design platform, and four retailers. Corporate email addresses get reused on personal accounts in every organization on earth, and the exposure is real but diffuse.

The second population carries the operational risk. Eight identities account for 25 records in combolists, stealer logs, and URL-login-password sets. These are not leak archives; they are working formats, deduplicated and structured for automated reuse against login endpoints. Only one identity appears in both populations, so this is not the same group of people counted twice. It is a smaller and distinctly more exposed set. One identity appears 11 times across separate compilations and another six times, a pattern consistent with a credential that stayed valid long enough to be repeatedly re-traded.

Three of the records come from stealer logs. That number is small in absolute terms and disproportionate in consequence. A stealer log is not a leaked password list; it is the contents of an infected machine: saved browser credentials, session cookies, and the specific URL each credential was entered against. Session material can, depending on the authentication architecture, allow access without repeating the multi-factor challenge, and the captured URL indicates which system the credential was used against.

One characteristic of the exposed set bears on remediation. All 23 identities follow individual-user naming conventions. None is a shared mailbox, service account, or role address. No generic administrative, support, billing, or automation identity appears anywhere in the data. Composition is inferred from the structure of the address rather than from any directory, so it is indicative rather than definitive.

This cuts two ways. A shared credential would have been worse: role accounts are frequently exempted from multi-factor enforcement, rarely rotated, and known to more people than can be tracked. Their absence removes that amplifier. But it also means every exposed credential belongs to a specific person, and eight of them appear in formats built for reuse. Remediation is therefore individual and not systemic. It requires password rotation, session invalidation, and, for anything sourced from a stealer log, treatment of the person’s endpoint as compromised and not the credential alone.

Set against the rest of this report, the comparison is unflattering. Every architectural finding described above requires an adversary to do work: enumerate a namespace, predict a hostname, and find a weakness in an environment that may live for hours. A credential already in circulation in a format built for automated reuse requires none of that work. It is the shortest path described in this report. Whether any individual credential still authenticates was not tested, and the exposure does not depend on it: the cost of attempting reuse is close to zero, which is why these formats are traded at all.

ATT&CK Mapping

Table 4. ATT&CK mapping. Only rows marked dataset-evidenced are supported by the collection described here. The remaining rows are architectural inference or potential follow-on activity, are included for context, and were neither performed nor observed.

Key Judgments

High Confidence

• Flock Safety’s public DNS namespace discloses substantially more about its internal architecture than its network-facing estate does. Every finding in this report was obtained without contacting Flock infrastructure.
• Per-change preview environments published in public DNS are enumerable and predictable. An adversary can generate candidate names for environments that have not yet appeared in passive DNS.
• Credentials for the company’s corporate identity domain are in active circulation in formats built for automated reuse, with collection continuing into August 2026. This is the shortest available path to the platform and requires no vulnerability.

Moderate Confidence

• The tunnel proxy series appears to be part of the device check-in path for the camera fleet. Flock states publicly that its devices connect to the cloud over private IoT cellular networks, which corroborates the outbound-only model and explains why the fleet cannot be enumerated by scanning. That this numbered series is the terminating layer rests on naming and internal addressing, and is not directly evidenced.
• This pattern is not unique to Flock. The practices that produce it, including automated preview deployments, split-horizon DNS misconfiguration and wildcard records, are industry-standard, and the same collection method should be expected to produce comparable results across the surveillance sector.

Low Confidence

• The relationship between the disclosed development estate and the January 2026 camera exposure is unestablished. The two are separate findings and this report does not assert a causal link.

What Security Teams Can Do This Week

• Enumerate your own organization in passive DNS before someone else does. The collection described here took minutes and required no privileged access.
• Check whether ephemeral preview environments are published to public authoritative DNS. If review access only ever comes from inside the corporate network or a VPN, those names belong in internal DNS.
• Search your public zone for records answering with RFC 1918 addresses. These often indicate split-horizon configuration errors, and they persist in passive DNS long after the record is corrected.
• Audit wildcard records at every level of your zone. They inflate your apparent attack surface, they answer for names you never created, and they make your own inventory harder to trust.
• Treat naming conventions as a disclosure control. Sequential and predictable names extend an attacker’s reach beyond what has actually been observed.
• If you operate a separate boundary for regulated or government workloads, confirm that its development tiers inherit the boundary’s controls, and that they are not described in the same public namespace.
• Monitor your corporate email domain in stealer logs, combolists, and URL-login-password sets, and treat the three as different problems. A breach record is a reused password; a stealer log is a compromised endpoint and a live session.
• Where credentials recur across multiple compilations, assume the underlying credential remained valid long enough to propagate, and force rotation rather than waiting for a login anomaly.
• Separate individual from role-based exposure when you triage. An individual credential is one person’s rotation and one endpoint to examine; a shared or service account is an unbounded blast radius and usually the one exempted from multi-factor enforcement.

Stepping Back from Flock to See the Bigger Picture

Flock Safety’s network perimeter held up well under active discovery. 63 hosts, all of them load balancers and gateways, and not a single camera. The architecture that produced that result, with devices dialing outbound and never listening, is a deliberate and effective design choice.

None of it mattered to this research. The development estate, the internal addressing plan, the device access layer, and the government boundary were all described in records the company publishes itself, to anyone who asks, for free. Passive DNS does not care how good your firewall is. It only cares what your resolvers have already said out loud.

That is the transferable lesson, and it’s not really about Flock. Automated preview deployments, split-horizon slips, and unfiltered wildcards are standard practice across the sector, which means most organizations reading this are publishing a version of the same document. The question worth acting on is not whether an adversary could assemble this picture of your estate. It is whether you have ever looked at the one you are already handing them.

Methodology and Limitations

Collection was entirely passive. Passive DNS records for flocksafety.com were retrieved from a commercial aggregation service on August 11, 2026, returning 3,079 A records covering 416 unique hostnames. No connection was made to any Flock system, no name was resolved by the researcher, no service was probed, and no camera, feed or interface was accessed at any point.

Wildcard artifacts were removed before analysis using three independent signals: record lifetime of one day or less, identical first-seen and last-seen dates clustered on a single day, and resolution to a small shared address set. 126 hostnames were excluded on this basis, leaving 290.

Flock Safety is named because the findings are specific to its namespace. Its internal service codenames, repository identifiers, individual change numbers and specific internal addresses are withheld, because those identifiers map to the work of identifiable engineers and republishing them would extend the disclosure rather than describe it. Readers should not take the naming as an argument that these practices are unusual: they are widespread, and the same collection method applied to other vendors in this sector should be expected to produce comparable results.

Passive DNS is an observational record, not an inventory. A hostname appearing in the data was answered by a resolver at some point in the window; it does not follow that the name still resolves, that the service is running, or that it is reachable. Conversely, absence from the record is not evidence that a name does not exist. Aggregation coverage is uneven, and names queried only from inside a corporate network may never appear. Every count in this report is a floor.

Credential data was drawn from a commercial dataset of criminal credential sources on August 11, 2026, queried by corporate email domain. No username, email address, local part, password, or password hash from that dataset appears in this report, and no credential was tested against any system. All credential figures are aggregate counts and represent a floor: they reflect what one dataset holds, not the total in circulation. Flock Safety operates a published vulnerability disclosure program and a bug bounty program, and engaged a third-party firm for its annual penetration test in February 2026. Findings of this kind belong in that channel before publication. Internal addresses recovered from public DNS are reported at range level only. No attempt was made to determine what runs on them, and no claim is made about their reachability from any position.