Skip to main content
All customer stories
Hospitality and Leisure

Nine brands, eleven countries, one advisory: answering “where do we even run this?” in under an hour

Client: A privately held hospitality group operating nine hotel, resort and restaurant brands across eleven countries — roughly 240 properties, fewer than half owned outright, with brand marketing devolved to regional offices and a central security team of… · details anonymised

The Challenge

Nine brands, eleven countries, and no single answer to "where do we run this?"

A critical framework advisory does not test whether a decentralised group patches quickly. It tests whether the group can establish, within hours, which of its brands, properties, franchisees and agency-built sites run the affected technology — and who holds the credentials to change each one. This group could not. Brand marketing was devolved to regional offices, regional offices commissioned local web agencies, and more than half the estate sat with managed or franchised operators outside group technology's authority. Eighteen months before, a comparable advisory had taken nine working days and more than seventy emails to answer, and the answer that reached the board — "no exposure has been identified to date" — described who had replied rather than what existed.

The Solution

Answer the exposure question from a record that already exists

ShadowMap had been running for four months before the advisory. In that time it reconciled the group's merged inventory against what actually responds to external probing — in both directions — and fingerprinted the technology stack of every responsive hostname continuously, as a property of discovery rather than an exercise anyone had to commission. When the advisory arrived, Threat Intelligence correlated it against that existing stack record and the Action Center carried the candidate list. The work of the first day was narrowing and routing, not discovering. Findings were stated in the group's operating language — which brand, which application, which owner — and confidence was stated per finding in both directions, including for the 47 hostnames whose version could not be established from outside.

The Results

From nine working days to under an hour — and a board number with a stated confidence boundary

The group did not become better at patching. It became able to scope. Because Technology Stack fingerprinting ran continuously across every discovered asset, the exposure question was answered by reading a record that already existed rather than by commissioning a scan and chasing nine brands for replies. Nineteen applications were validated as exploitable with evidence and closed within 72 hours; the full affected set closed in eleven days. The 26 days taken by franchise- and agency-operated applications became the most useful governance output of the exercise, producing a franchise digital-standards clause and a pre-launch registration requirement for agency-built properties. Two subsequent advisories were scoped in 31 minutes and under two hours respectively, neither requiring an email to establish scope.

Full Case Study

· 6 min read

The answer, first

When the advisory landed — an unauthenticated remote-code-execution flaw in an open-source content-management framework, the kind an agency reaches for by default, with working proof-of-concept code public inside two days — the group's security team had a first-cut exposure list in under an hour. Not an estimate: a named list of 214 hostnames across seven of the nine brands, assembled from technology fingerprints ShadowMap had already collected on every asset it had discovered. By the close of the first working day the list was narrowed on version evidence to 96 hostnames, collapsed to 63 distinct applications, and routed to named owners for 41 of them. On day three the CISO took a number to the board she was prepared to defend — including the parts she could not yet be certain about.

Eighteen months earlier the same group met a comparable advisory. That answer took nine working days, seventy-odd emails to brand IT leads, regional marketing managers and three external agencies, and arrived as the sentence "no exposure has been identified to date." That is a statement about who replied, not about what exists. Nobody in the room believed it, including the person reading it out. What changed is not that the group patches faster. It is that the question now has a source.

The question was never "are we patched"

This group does not have a patching problem. It has an ownership problem. Nine brands across eleven countries and roughly 240 properties, fewer than half owned outright; the rest managed or franchised. Brand marketing sits with regional offices, and regional offices commission local agencies. Group technology runs the reservation platform, the loyalty database, the finance stack and corporate IT. It does not run the spa microsite a resort built for a seasonal campaign, or the events-enquiry portal a property put live for one wedding season and never switched off.

So when a framework advisory arrives, the first question is not whether the estate is patched. It is where do we run this at all, and who holds the credentials to change it. Every hour spent establishing that is an hour the window stays open — and in a franchised estate those hours go on waiting for replies.

Why the tools they already owned did not answer it

The group had a CMDB, an authenticated vulnerability scanner, a managed SOC and a domain register kept by the trademark team. Each was accurate about something; none answered this.

The CMDB is a record of intent, populated at provisioning and decaying from that moment — it cannot see a site a franchisee commissioned, because nobody asked it to. The scanner scans the list it is given, and it was given group-run infrastructure, the part of the estate that was never the concern. The register knows which domains the group owns and nothing about what software answers on them. The SOC monitors what it has been onboarded to. All four describe the estate from the inside; the advisory asked a question that can only be answered from the outside.

What the discovery established, before the incident

ShadowMap had been running four months when the advisory dropped. Reconciliation between the group's merged inventory — CMDB plus brand marketing registers — and what actually responds when probed ran in both directions.

  • The merged inventory listed 1,340 hostnames.
  • 1,570 hostnames responded to external probing under the group's brands and marks.
  • 1,050 appeared in both.
  • 520 responding hostnames appeared in no inventory at all — roughly a third of everything that answers the internet in the group's name.
  • 290 inventory entries no longer responded to anything, inflating the coverage figure every quarterly report had been built on.

Technology Stack fingerprinting ran across all 1,570 continuously, as a property of discovery rather than an exercise anyone had to commission. That is the mechanism behind the first paragraph of this case study: on the day, nothing was scanned in a hurry, because the record of what runs where already existed and was four hours old.

Turning 214 into work a team of fourteen could do

Version evidence narrowed the 214 fingerprinted hostnames to 96 on an affected release. 71 were confirmed on a patched branch and closed on day one. 47 could not be versioned from outside — behind an edge that strips version headers, or returning a custom error page — and were labelled version not determinable externally; confirm from your deployment records. Not counted as vulnerable, not counted as safe; carried to the board as a stated residual.

Collapsing duplicates — one application served under a brand domain and a property domain, apex and www, CDN mirror and origin — took 96 hostnames to 63 distinct applications. Correlation that makes a queue smaller is the harder half of the work.

Ownership was routed, not assumed. 41 applications carried an Asset Explorer tag resolving to a named brand technology owner and moved straight to Investigating. 17 were franchise- or agency-operated — the group's marks, somebody else's hosting — and were surfaced as references your organisation; confirm the operator before acting. The group has no authority to touch those, and a wrong assumption there is a contractual problem rather than a technical one. 5 could not be attributed on day one and were surfaced as unattributed rather than handed to a default owner who would have deprioritised them.

21 of the 63 sat entirely on assets that appeared in no inventory — among them a gift-card redemption site for a restaurant brand, a conference-and-events portal for a property divested two years earlier and still carrying group branding, and a staff-rota application run by a regional operations team.

Two of the nine brands ran none of the affected framework anywhere. That was reported explicitly rather than omitted; a brand absent from a finding list should be able to see it was looked at.

What CART validated, and what it deliberately did not

On day two, within the scope authorised at onboarding, CART ran a non-destructive check against the 63 applications: a benign request confirming whether the vulnerable code path was reachable and executing, returning request and response evidence rather than an inference from a banner.

19 were confirmed exploitable, with evidence attached to each finding. 34 returned a negative result — the affected module was disabled, or edge configuration blocked the path — and that negative was recorded as a finding in its own right, because "confirmed not reachable" is a different governance position from "assumed patched". 10 were inconclusive and said so: not validated, verify manually.

Nothing was modified, nothing retrieved beyond what the check required, and no attempt made to move from a confirmed application to anything adjacent. Every validation request carried an audit identifier so the group could reconcile the activity against its own logs — which its SOC did, finding exactly the requests it had been told to expect.

What followed

All 19 validated-exploitable applications were patched or withdrawn from public reachability within 72 hours. The 46 directly operated applications closed in 11 days. The 17 franchise- and agency-operated applications took 26 days — a gap that became the most useful governance output of the exercise, producing a franchise digital-standards clause and a requirement that agency-built properties be registered before launch.

The 290 dead inventory entries were retired, and the 520 previously-unknown hostnames were assigned owners over the following quarter — tracked as a Security Rating input rather than a one-off cleanup.

Two further advisories have landed since. The first produced a first-cut list in 31 minutes; the second in under two hours, with a franchise-operator notification pack generated from the same list. Neither needed an email to establish scope.

What it meant for reporting

The board paper the group now issues on a framework advisory states four things: how many applications run the technology, how many are on an affected version, how many were validated as exploitable with evidence, and how many could not be determined and why. The last line is the one the audit committee reads twice. A number with a stated confidence boundary is worth more than a confident number, and it is the only kind that survives the question of where it came from.

Related to

how exposed are we to a new CVE external attack surface management for multi-brand groups technology stack inventory across subsidiaries vulnerability exposure reporting for the board shadow IT discovery hospitality group CMDB reconciliation external assets franchise and agency website security visibility time to scope a critical vulnerability asset discovery beyond internal inventory validated exploitability evidence

Ask what ShadowMap would find on your assets.

A 30-minute live walk-through with a ShadowMap engineer on your own domains. We map you live; you keep the report whether or not you choose to engage.