The Airport isn’t Online but its Directory is: A Sector-Wide Look at What DNS Reveals About Aviation Infrastructure

By Adrian Cheek, Senior Cybercrime Researcher

An airport is a large industrial facility that has runways. It runs flight information displays, credential and badging platforms, baggage handling, airfield lighting, fuel farms, parking revenue control, weather observing, license plate recognition, stormwater monitoring, and building automation. Most aviation cybersecurity research has focused on radio protocols, rather than external measurement of that landslide layer.

This study is, as far as we can establish, the first sector-level external measurement of that layer using passive DNS and address-range enumeration. The methods it uses are not new. Reverse DNS across an address range to recover naming conventions, and mail authorization records as a source of an organization’s address space, are both standard reconnaissance practice and are documented as such. What has not been done is to point them at a sector and count the results.

Airport systems are commissioned by engineers who name them after what they do, and those names are published in DNS on the operator’s own address space. Sweep the block and the landside layer introduces itself: a flight information display system, two separate building automation platforms from different vendors, a badging system, a license plate recognition system, a fuel management system, a stormwater monitor, an automated weather station at a secondary airfield. Across six operators that could be enumerated to block level, 165 named systems were recovered. A seventh returned functional names through the same route and could not be enumerated to block level.

The reassuring part of the story is that none of the identified operational systems were observed answering from the internet. Across every operator examined, the responding hosts were perimeter, management, and access infrastructure. No controllers, supervisory platforms, or airfield systems answered at all, and that null was validated against three positive controls on the same collection. At the operators we examined, the airport operational layer appears to be behind the firewall. What is visible is the inventory and its perimeter, not the machinery, and the distinction matters for how the aviation industry should respond. The contribution here is not that airport systems are exposed, but rather that airport systems can be measured externally through naming infrastructure even where the systems themselves are not reachable.

Key Findings About Exposed Aviation Infrastructure

• Airport systems name themselves. Seven of seven operators tested returned names that disclosed functional system information, across five different naming conventions and two countries. Of the four routes tested, DNS naming was the only one that reached the landside layer at all. A name is evidence a system exists, not that it is reachable. Several named systems resolve to a VPN concentrator or firewall, with the system itself sitting behind it.
• For several operators, the address block is discoverable from a single free lookup. Several operators declare their range in their own mail authorization record, which requires no registration query and no autonomous system number.
• Sweep the block, not the domain. A reverse sweep of the address range returned six times as many names as a forward query on the apex for one operator and nearly three times for another. The two methods are not interchangeable and results built from apex queries are not comparable.
• Enumerate apexes in both directions. Two of six operators run several domains on one block with a different naming convention on each, and in one case the operational systems were almost entirely on the secondary domain rather than the public-facing one.
• Nothing operational is exposed. Across roughly 50 responding hosts at six operators, the profile is management protocols, key exchange, web and secure shell. No controllers, no supervisory platforms, no airfield systems. Three positive controls confirm the collection would have found them.
• Non-production instances are published by name. Half the operators publish a named development or test instance of a safety, credentialing or business application, and one publishes six separately named environment tiers of the same application.
• Exposed staff credentials are present on every operator domain swept. 950 records covering 253 accounts across three domains, 81 percent carrying the secret in plaintext form, and five accounts sourced from infected endpoints or phishing kits rather than historical breach compilations.
• One capture is a credential for an operator’s own multi-factor authentication administration console, taken from an infected endpoint in April 2026. Where such an account can alter authentication policy, enrollment or bypass mechanisms, multi-factor authentication stops being a reliable compensating control for the other exposed credentials at that operator.
• Enumerating only the public-facing domain understates credential exposure severely. At one operator the secondary operational domain carried 197 of the 211 affected accounts, and it is the domain that would be missed by anyone working from the airport’s public website.
• Patch age is published without authentication. Engine discovery on the management protocol returns device uptime. The longest observed was five years and ten months on an internet-facing edge device.

Prior Work and What This Adds

Sector-level attack surface measurement using passive reconnaissance is an established form. The closest methodological precedent is a 2025 study of United States county governments in the Journal of Cybersecurity, which built an integrated attack surface model covering more than 42,000 internet-facing devices across 3,095 county governments from a manually compiled domain list combined with two commercial scanning platforms. That paper also surveys earlier work applying the same approach to European countries, German hospitals, Finnish telecommunications, and critical infrastructure in Turkey and Portugal. This study sits inside that same genre, applied to aviation.

Airport cybersecurity is itself well covered, but by four other kinds of work: incident case studies, governance and zero-trust framework papers, vendor threat overviews, and authorized penetration testing. A detailed public account of the systems themselves comes from authorized testing, which enumerated 17 airport interfaces potentially exposed to attack across Wi-Fi, crew and flight information, building management, passenger-assist and runway systems, and observed that baggage system interfaces, while rarely directly exposed on an airport network, are sometimes exposed. Vendor research published in mid-2026 makes the same argument this study started from, that the IoT and building layer of an airport is the part defenders most often miss, covering cameras, building management and HVAC controllers, access-control readers, environmental and baggage sensors and digital signage.

What is missing from all of it is a count. Authorized testing describes one airport at a time with permission. Vendor research describes the layer in the abstract. Incident reporting describes what happened after the fact. Nobody has asked how much of this layer is visible from outside, across the sector, without permission or interaction. This study answers that question, and the specific contributions are the measurements rather than the methods:

• That vendor fingerprinting, the obvious approach, does not reach airports at all. 2,330 hosts collected across twelve product fingerprints returned zero airport operators.
• How much of an estate is missed by querying a domain instead of sweeping its address range. The gain reached six-fold, and no published figure for this existed.
• That scanning platform forward DNS is not a substitute for passive DNS, quantified on the same estates.
• What proportion of the certificated airport population is identifiable through the tested registration routes, which is 6-7%.
• That airport operational technology is not internet-reachable at the operators examined, established against three positive controls rather than asserted from an absence of results.

Headline Figures

Table 1. Headline figures. Counts are floors. Collection ran over two days in September 2026 against commercial scanning and passive DNS platforms and makes no claim to be exhaustive. The Part 139 total is the FAA’s own approximate figure; the authoritative list is refreshed on a 28-day cycle.

The Method

Three steps, all passive, none of them requiring a scan of the target, and none of them novel in isolation. The contribution is the sequence, the filtering it requires at scale, and its application to a whole sector.

Step 1: Find the Operator

Two registration routes work. A regex against autonomous system names for airport and aviation terms returns operators that run their own networks. A regex against the address registration organization field, anchored to operating-authority forms rather than to the bare word, returns a larger set that does not.

Anchoring is the whole trick. The unanchored form pulls in every hotel, freight forwarder, self-storage business, and taxi firm whose registration contains the word, at a volume that makes the result unusable. Two further traps are worth knowing in advance. One of the operating-authority forms is a substring of another, so one query silently returns a superset of the other and brings municipal transport authorities, an export authority and a spaceport authority with it; the two result sets have to be subtracted at parse time. A cleverer expression does not fix it. And registration names who holds the addresses, not who operates what runs on them, so occupancy must be confirmed before an estate is attributed.

Step Two: Find the Block

The operator’s own address range is frequently declared in their own mail authorization record. That is a single free text lookup against a domain, it needs no registration data and no autonomous system, and on the first operator tested it returned the exact range on which every operational system sat. Where an operator holds an autonomous system, the announced prefix serves the same purpose.

Step Three: Sweep the Block in Passive DNS

This is the step that produces the result, and the direction matters more than expected. A forward passive DNS query on the apex domain returns the names that platform happened to observe being queried for that domain. A reverse sweep of the address range returns everything that ever resolved into it, including names on domains the analyst did not know to ask about.

Table 2. Names recovered by apex query against block sweep. On-block counts only, after contamination filtering.

The sweep is also what surfaces additional apex domains. Operator A publishes 25 names on its public-facing domain and 42 on a second domain resolving into the same range, and the second domain carries nearly all of the operational systems. Operator B runs three domains on one block, one of them using a NATO phonetic alphabet scheme. An analyst querying the obvious domain would have seen a third of the estate and drawn the wrong conclusion about the rest.

What the Names Disclose

Across the six enumerated estates, 165 names resolve on-block. The functional systems within them are what this study set out to find.

Table 3. Functional system classes recovered from DNS naming across six operators.

Two patterns recur across the estates. Non-production environments are published by name, so one operator exposes development, test, sandbox, disaster recovery, and a temporary tier of the same enterprise application as five separate labels, and three of six publish a named test instance of a safety, credentialing or viewing system. Second, a naming convention can be entirely operational without being functional: one operator’s twelve names are firewalls, gateways, DNS servers and a partner VPN, with no system names at all. Both conventions tell an outsider something. Only one of them names the landside layer.

What a Name Does Not Mean

This distinction determines whether the technique is useful or misleading, and it carries through every use of it.

One operator publishes a three-letter system name that has resolved to the same address for four years. That address is a firewall: a next-generation appliance on a high management port, presenting a wildcard certificate for the operator’s domain, with transport security current and no vulnerabilities flagged at collection. The named system is not on the internet. It sits behind that appliance and is published through it.

So the naming route establishes that a system exists in the operator’s environment, and sometimes which gateway fronts it. It does not establish that the system is reachable. Some names in this study resolve to the system itself and some resolve to a perimeter device, and any table built from this technique has to separate the two. A reader who assumes every name is an exposed system will be wrong in a way that damages a disclosure conversation before it starts.

The Perimeter, and Why the Operational Layer Is Not Behind It

The six enumerated operators publish very little. Across their combined address space, roughly 50 hosts answered any scan, and the profile is consistent: management protocols, key exchange, web, secure shell. No controllers. No supervisory platforms. No airfield systems of any kind.

That is a positive result for the sector and is worth stating plainly. Airfield lighting control is treated as an isolated system in regulatory guidance, baggage handling sits behind a supervisory layer, and both appear to be exactly where they should be. The evidence for that claim is stronger than an absence of results: three positive controls were run on the same collection before the null was accepted. An industrial ethernet port whose identity object carries a vendor code by design returned devices at expected volume. A serial device server population returned several thousand records with a clean vendor distribution. A vendor fingerprint from the same corporate family as one of the airfield lighting suppliers returned hits in its non-aviation product line. The collection would have detected the tested operational-technology populations if they had been present in the responding address space.

What the Perimeter Does Disclose

All five operators that answered on the management protocol port exposed the same edge vendor, identified by enterprise number. The responses are version three engine discovery, which needs no credential but returns no system name, location or contact. Two things come out of it anyway.

The engine identifier derives from the device hardware address, so several addresses that look like separate hosts deduplicate to one physical device, including cases where the network and broadcast addresses of an entire range both answer for the same box. And the engine timer is uptime, which gives a rough indication of how long a device has run without a restart and may therefore indicate patch-maintenance risk. The longest observed was 2,137 days, so an internet-facing edge device at a major airport authority had not restarted in five years and 10 months. One operator also enables version one alongside version three, which puts a guessable community string on an airport perimeter.

Across the six enumerated estates, the perimeter products observed included a remote access gateway from:

• one major vendor with an actively exploited vulnerability class
• a next-generation firewall SSL VPN portal from another
• a third vendor’s global access client
• two generations of one manufacturer’s security appliance
• a fourth vendor’s security gateway exposing its topology service
• a single network camera

Specific hosts are not identified here and have been provided to the operators directly.

Why the Obvious Approaches Do Not Apply

Three routes were tested before the naming route, and their results are reported here because knowing they do not work saves the next researcher the collection cost, and because two of them are the routes a reader would otherwise assume had been skipped.

Vendor Fingerprinting

Passenger information display is web-facing by construction, and the vendor landscape is small, so it should be the reachable layer. 12 product fingerprints across two scanning platforms returned 2,330 unique hosts and not one airport operator. The single aviation-attributable host in the corpus was a charter operator. The product population exists, and the collection does not identify it as an airport population. These vendors sell overwhelmingly into retail, hospitality, and corporate environments.

Two secondary results from that collection are worth reusing elsewhere. Title and body fingerprints for the same product are not redundant, and each returned several hundred hosts the other missed, with the body fingerprint reaching white-labeled deployments where an integrator had rebranded the interface. One field in that corpus proved more useful for attribution than any vendor string. On one platform the HTTP basic authentication realm carries the display’s own site label, unauthenticated, in the 401 response.

Scanning Platform Forward DNS

Forward DNS from a scanning platform looks like a free substitute for passive DNS and is not. On the same estates where passive DNS returned dozens of names, forward DNS returned almost none, because it only records a name where a scanned host happened to carry one. An early iteration of this study read that gap as evidence the naming convention did not generalize, which was a source artifact.

Non-English Registration Terms

Equivalent registration queries in French, German, Spanish, and Italian returned 106 hosts and exactly one operator, with the major European airport groups absent entirely. Their estates exist; the registration convention does not. The study was scoped to North America as a result, and an international version of this work needs a different step one.

Reproducing This: Contamination and Filtering

Passive DNS block sweeps return everything that ever resolved into a range, and most of it is not the operator. On one sweep, 502 of 535 rows were unrelated. Every count in this report is post-filter, and reproducing them requires the same filtering.

Table 4. Contamination classes observed, with the filtering each requires.

Where the Technique Applies

Approximately 520 US airports hold a Part 139 certificate. Two independent registration routes together identify roughly 30 operators, six of which could be enumerated to block level. That is approximately 6-7% of the certificated population. The figure describes the reach of the registration method, not the proportion of airports measured. The constraint is step one, not step three. An operator that cannot be tied to an address range cannot be swept, however descriptively they name things.

One of the six enumerated operators demonstrates why the remainder cannot be assessed through registered address space alone. They have no estate on their own registered block at all. Their named systems, including an alerting platform and an employee self-service portal, sit on four shared addresses at a hosting provider. That is not an absence of systems. It is a tenancy inside somebody else’s address space, invisible to registration lookups and to block sweeps alike. The example demonstrates one important explanation for the remaining population. The wider prevalence of hosted tenancy is not established by this study.

The practical reading is that this technique is a tool for the operators who can be identified and, more usefully, a tool operators can run against themselves. An airport does not need to find its own address range through registration data. It already knows it.

Exposed Credentials on the Operator Domains

The domain enumeration described above produces a list of operator mail domains, and those domains can be queried against commercial credential exposure datasets. Three of the 14 identified domains have been swept. All three returned results, so the figures below are a partial view of the sector and should be read as a lower bound.

Table 5. Exposed credential records across three operator mail domains. Deduplicated on identity, secret, source and import timestamp.

The Domain you Sweep Decides the Answer

One operator was swept twice. The first pass covered the public-facing domain that appears on the airport website and returned fourteen affected accounts. The second pass covered the secondary operational domain, the one the DNS enumeration surfaced and the one carrying most of that operator’s named systems, and returned a further 197. The same enumeration lesson that governs estate size governs credential exposure: an assessment built on the obvious domain reports a small fraction of the real figure.

Five Records that are not Breach Compilation Data

Of 950 records, 930 come from breach compilations, combolists and named third-party breaches going back to 2008. Those are worth remediating and they are not urgent. 20 records across five accounts come from stealer logs, URL and login and password triplets, and a phishing kit collection. Those indicate a more recent exposure event or a page built to target the organization, and they warrant priority investigation.

One of them is materially worse than the rest. A stealer log from an infected Windows 11 endpoint, with two infection records in April 2026, captured a credential for the administration console of the operator’s multi-factor authentication provider, held under a staff account on that operator’s operational mail domain. The organization-specific administration subdomain appears in the same capture alongside the generic console address. A credential for the MFA control plane is not another exposed password. If the account can alter authentication policy, enrollment or bypass mechanisms, multi-factor authentication may no longer function as a reliable compensating control for the other credentials in this dataset at that operator. This is the most consequential conditional finding in the study.

The same record shows why the endpoint mattered. It carries the public address, local username, hardware identifier, operating system version, and geographic location of the infected machine. Both of that operator’s mail domains appear on the device alongside a long list of personal accounts, which is consistent with a personally used or unmanaged machine holding work credentials. The source data does not establish whether the device was under management.

Two Smaller Results Worth Recording

One functional account appears in the data, an IT notification mailbox. This corrects an assessment made after the first two domains were swept, where every affected identity was a named individual and no role account was present. The correction matters because the two situations call for different responses, and the first sweep would have supported the wrong one.

The same operator domain also appears in five Telegram records from May and June 2026: three messages from an automated mailbox-validation bot in a marketplace support channel, and two credential leak repost channels. That is evidence of active interest in the domain rather than merely historical presence in a breach compilation.

ATT&CK Mapping

Techniques marked dataset-evidenced were directly observed. Techniques marked external are the next steps the disclosed information enables and were not observed.

Table 6. ATT&CK Enterprise and ICS mapping.

Key Judgments

High Confidence

• DNS naming reaches the airport landside layer. Seven of seven operators tested returned names that disclosed functional system information, across five naming conventions and two countries, and it surfaced system classes that none of the other three routes reached.
• No airport operational technology was observed reachable from the internet at the six enumerated operators. No controllers or supervisory platforms answered, and three independent positive controls on the same collection confirm the method would have found the tested populations if they were present.
• Block sweeps and apex queries are not interchangeable. The gain reached six-fold on one operator, so any comparative table built from apex queries alone is not comparable.

Moderate Confidence

• Approximately thirty operators, or six to seven percent of the certificated population, are identifiable through the tested registration routes. Six of those could be enumerated to block level. The denominator is the FAA’s own approximate figure and the operator count is the union of two routes with imperfectly measured overlap.
• Hosted tenancy is one important explanation for operators that cannot be reached through their registered address space. One of six demonstrates the pattern conclusively; its prevalence across the wider population is untested.
• Exposed workforce credentials are present across the sector. All three operator domains swept returned records, and two of the three carried credentials sourced from infected endpoints or phishing kits within the last five months. Three domains is too small a sample to generalize the rate, and the direction of the result is consistent across all three.

Low Confidence

• The naming convention will persist. It is a commissioning habit rather than a standard, and two of the six already use conventions that disclose nothing functional. Operators can close this at will, which is part of why it is worth publishing.

What Airport Operators Can Do This Week

• Sweep your own block in passive DNS. Not your domain, your address range, and enumerate every apex that resolves into it. On the evidence here, the sweep may return several times more names than an apex query, including names on domains you had forgotten you own.
• Check whether your mail authorization record publishes your range. It is a legitimate configuration and it is also the cheapest possible first step against you. Knowing it is published is enough; it does not have to change.
• Find your named non-production instances. Half the operators in this study publish a named development or test instance of a safety, credentialing or business system. Those are where weak credentials and copies of production data live.
• Decide deliberately whether system names should be functional. Descriptive naming is operationally valuable and the trade-off is real. The point is to make the choice deliberately rather than inherit it from whoever commissioned the system.
• Audit who else is on your address space. Three operators here have unrelated organizations resolving into their registered blocks, in one case at ten times the volume of the airport’s own estate.
• Check uptime on your perimeter devices. It is published without authentication and gives a rough indication of restart and patch-maintenance history. Five years and ten months was the longest observed.
• Disable version one on the management protocol. One of six still runs it alongside version three at the perimeter.
• Sweep your own mail domains against credential exposure data, including the secondary ones. Every domain checked here returned records. Prioritize anything sourced from a stealer log or a phishing kit over breach compilation entries, because those indicate a more recent exposure event or a page built to target you specifically. Check whether any captured credential belongs to a security administration console, since that inverts the value of every other control you rely on.

What Airports Can See About Themselves

None of this required touching a single system. Two mail authorization lookups, a registration query, and a passive DNS sweep were enough to name 165 operational systems across six airports, without ever crossing the perimeter those airports had, for the most part, correctly built. That combination is the actual finding here: the operational layer is well defended and thoroughly disclosed at the same time, by two entirely different parts of the organization that have never had reason to talk to each other. Whoever names a badging system or a fuel management platform in DNS is not thinking about reconnaissance. They are thinking about the next engineer who has to find it at 2 a.m. That instinct is reasonable, and it is also exactly what makes this technique work.

The sector should not read the internet-reachability finding as a clean bill of health. It is a measurement of six operators, out of roughly 520 certificated airports, reached through two registration routes that happen to work for large, network-owning organizations. The other 93 percent were not found safe. They were not found. Whether that population looks like the six enumerated here, or like the one operator in this study that turned out to have no registered estate at all and instead sat quietly inside somebody else’s hosting block, is precisely the question this method cannot yet answer. The credential exposure findings point the same direction: three domains checked, three domains returning results, including one that inverts the value of every other control an operator has in place. That is not a sector-wide rate. It is a pattern with no counterexample yet.

What this study actually offers the sector is more of a mirror. Every technique here is available to any operator against its own estate, for the cost of a few free lookups, and it will tell that operator things its own IT and security teams may not currently share with each other: which domain actually carries the operational systems, whether last year’s test instance ever got decommissioned, how long the perimeter has been running without a restart, and whether the password sitting in a stealer log belongs to someone who can turn multi-factor authentication off. None of that requires an adversary’s toolkit. It requires the same three lookups described in this report, run by the people who already have permission to look.

Methodology and Limitations

Collection was passive throughout. Records were retrieved from two commercial internet scanning platforms and a commercial passive DNS service. No credentials were submitted, no authentication was attempted, and no connection was made to any identified system beyond the standard protocol handshake performed by the scanning platforms themselves. No vulnerability was exploited and none is claimed.

Scope was the United States and Canada, collected in September 2026. Four routes were tested in sequence: operator discovery through registration data, address-range discovery, vendor fingerprinting, and passive DNS naming. Each was set aside only after a positive control demonstrated the method worked where a population existed.

Throughout this report, operator refers to the organization whose address space was enumerated. The Part 139 denominator refers to certificated airports, so the two populations are not identical. One operator can run more than one airfield, hold more than one domain, and announce more than one address range. The findings therefore describe the measured operator estates, not the prevalence of the identified systems across all certificated airports.

Limitations

• The denominator is approximate. The FAA describes the certificated population as approximately 520 and refreshes the authoritative list on a 28-day cycle. The applicability percentage inherits that imprecision.
• Six enumerated operators is a small sample, and they are self-selected toward the large. An operator that runs its own network is not typical of the 520.
• System identification rests on self-reported labels. Where an acronym is unexpanded it stays unexpanded here rather than being guessed. At least one system name in the dataset has two plausible expansions with materially different implications, and neither is confirmable externally.
• A name is not an exposure. Several names resolve to perimeter appliances and not to the systems they refer to. The tables here distinguish the two, but anyone applying the technique must verify per host.
• The credential sweep covers three of fourteen identified operator domains. All three returned results, and no rate for the sector can be inferred from a sample of three. Credential datasets also carry records of unknown age and unknown current validity, and none was tested.
• Block sweeps are heavily contaminated. On one estate 94 percent of returned rows were unrelated to the operator, and reproducing these counts requires the filtering described above.
• The operational technology null is bounded by the vendor fingerprints tested. It is a strong result because the controls passed, not an exhaustive one.

Findings affecting identifiable operators, including perimeter products with actively exploited vulnerability classes, a guessable community string, and named non-production instances, have been routed to the relevant operators and to the aviation sector information sharing body. No operator, address, hostname or system identifier is reproduced in this report.