Mass Scanning Campaign Targets Hospitality Applications — Detection and Hardening Guide for Hotels and PMS Operators

On September 16th, the SANS Internet Storm Center flagged anomalous requests appearing in its "First Seen" telemetry — scanning activity specifically targeting hospitality applications. When the ISC's distributed sensor network starts surfacing a new request pattern aimed at a vertical sector, it almost always means one of two things: an automated reconnaissance wave preceding exploitation, or a botnet hunting for a known weak configuration in software common to that industry. Either way, the targeting of hospitality applications is a signal hotel operators, managed service providers, and anyone hosting property management systems (PMS), booking engines, or guest-facing web portals need to take seriously today.

The hospitality sector is a perennially attractive target: it aggregates payment card data (PCI-DSS scope), guest PII, loyalty program credentials, and — critically — often runs internet-facing legacy web applications on thin security budgets. Mass scanning is the cheapest phase of an intrusion. The expensive phases follow. This post covers how the scanning behavior manifests, how to detect it in your own web and WAF telemetry, and how to harden hospitality application infrastructure before the follow-on exploitation attempt arrives.

What the Scanning Looks Like

Based on the ISC diary observation and consistent patterns in sector-targeted scanning campaigns, defenders should expect the following observable behaviors:

• Automated probing of application-specific paths. Scanners enumerate paths associated with hospitality platforms — PMS admin consoles, booking engine APIs, channel-manager integrations, housekeeping/maintenance portals, and vendor default install paths. Probing typically manifests as clusters of requests returning 404/403/401 as the scanner fingerprints which paths exist.
• Scanner tooling signatures. Requests carrying User-Agent strings from offensive tooling (nmap, masscan, sqlmap, nikto, acunetix, nuclei, dirbuster, gobuster) or spoofed browser strings cycling rapidly.
• High request velocity from single sources. Distributed scans spread load across botnet nodes, but individual sources still generate abnormal request rates — dozens to hundreds of requests per minute against a property's web application.
• Sequential source infrastructure. Scanning campaigns cycle through VPS providers, bulletproof hosting, and compromised residential proxies. The same path sequence appearing from rotating IPs is a strong campaign indicator.
• Geographic and ASN anomalies. Requests to your booking portal from hosting-provider ASNs (rather than residential/ISP ASNs typical of actual guests) are a cheap, high-fidelity anomaly signal.

Why hospitality applications specifically

Vertical-focused scanning usually correlates with one of three drivers: (1) a recently disclosed vulnerability in a hospitality platform component being enumerated before exploitation, (2) credential-stuffing infrastructure mapping hotel staff portals for password-spraying follow-up, or (3) initial access brokers inventorying exposed PMS and booking infrastructure for resale. In all three cases, the organizations being scanned now are the organizations that will receive the exploit attempts next. The scan is your early warning.

Exploitation status

The ISC observation reflects active reconnaissance in the wild, not yet confirmed mass exploitation of a specific flaw. No CVE has been tied to this campaign at time of writing — this is pre-exploitation phase activity. That is precisely when defensive action has the highest return: hardening before weaponization is dramatically cheaper than incident response after it.

Detection & Response

The detections below are tuned to minimize noise. The Sigma rules target scanner tooling signatures and admin-path enumeration behavior that has near-zero legitimate presence on hospitality web frontends. The KQL and VQL content assumes your web/WAF logs are being ingested into Sentinel (via CEF, Syslog, or a connector) — if they aren't, that gap is itself the first remediation item.

Sigma Rules

---
title: Hospitality Web Application Admin Path Enumeration
description: Detects sequential probing of administrative and management paths commonly targeted when scanners fingerprint hospitality applications (PMS consoles, booking admin panels, vendor default paths). Requires web server or WAF access log ingestion.
references:
  - https://isc.sans.edu/diary/rss/33344
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1595.002/
author: Security Arsenal
date: 2026/09/17
status: experimental
tags:
  - attack.reconnaissance
  - attack.t1190
  - attack.t1595.002
id: 3f7a2b91-6c4d-4e8f-a1b2-9d0e5c7f8a31
logsource:
  category: webserver
detection:
  selection_paths:
    cs-uri-stem|contains:
      - '/admin'
      - '/administrator'
      - '/manager/html'
      - '/wp-admin'
      - '/phpmyadmin'
      - '/setup'
      - '/install'
      - '/console'
      - '/cgi-bin/'
      - '/.env'
      - '/.git/'
  selection_status:
    sc-status:
      - 401
      - 403
      - 404
  condition: selection_paths and selection_status
falsepositives:
  - Legitimate admin traffic should be filtered by allowlisting known management source IPs before deploying this rule
level: medium
---
title: Offensive Scanner Tooling User-Agent in Web Requests
description: Detects inbound web requests carrying User-Agent strings associated with scanning and exploitation tooling. High-fidelity indicator of automated reconnaissance against internet-facing applications.
references:
  - https://isc.sans.edu/diary/rss/33344
  - https://attack.mitre.org/techniques/T1595.002/
author: Security Arsenal
date: 2026/09/17
status: experimental
tags:
  - attack.reconnaissance
  - attack.t1595.002
id: 8c1e5d42-2b7f-4a9e-b3c6-4f1a8d2e9b55
logsource:
  category: webserver
detection:
  selection:
    cs-user-agent|contains:
      - 'nmap'
      - 'masscan'
      - 'sqlmap'
      - 'nikto'
      - 'acunetix'
      - 'nuclei'
      - 'gobuster'
      - 'dirbuster'
      - 'hydra'
      - 'zgrab'
  condition: selection
falsepositives:
  - Internal vulnerability scanners (Tenable, Qualys) — filter authorized scanner source IPs
level: high
---
title: High-Volume Request Rate from Single Source Against Hospitality Portal
description: Detects request-rate anomalies indicative of automated enumeration against web applications. Deploy against IIS logs or WAF telemetry with aggregation at the SIEM layer (threshold: >100 requests per source IP per 5 minutes to a single application).
references:
  - https://isc.sans.edu/diary/rss/33344
  - https://attack.mitre.org/techniques/T1595/
author: Security Arsenal
date: 2026/09/17
status: experimental
tags:
  - attack.reconnaissance
  - attack.t1595
id: 1d9f4e67-8a3b-4c2d-9e5f-7b6a3c8d1e24
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains:
      - '/booking'
      - '/reservation'
      - '/pms'
      - '/api/'
      - '/login'
  condition: selection
falsepositives:
  - Legitimate high-traffic periods (booking surges, marketing campaigns) — correlate with ASN/hosting-provider enrichment and tune thresholds per property
level: low

KQL — Microsoft Sentinel Hunt Query

This query assumes web server or WAF logs are landing in Sentinel via CommonSecurityLog (CEF from WAF/proxy) or Syslog/IISLogs tables. It correlates scanner User-Agents and admin-path probing, then enriches with request velocity per source. Run it as a scheduled analytics rule with entity mapping on RequestClientIP.

let scanner_ua = dynamic(["nmap", "masscan", "sqlmap", "nikto", "acunetix", "nuclei", "gobuster", "dirbuster", "hydra", "zgrab"]);
let admin_paths = dynamic(["/admin", "/manager/html", "/phpmyadmin", "/setup", "/install", "/console", "/cgi-bin", "/.env", "/.git", "/wp-admin"]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where RequestMethod in ("GET", "POST", "HEAD", "OPTIONS")
| extend UriPath = tostring(split(RequestURL, "?")[0])
| extend IsScannerUA = tostring(set_has_element(scanner_ua, "never")) == "false" and (RequestClientApplication has_any (scanner_ua) or tolower(RequestClientApplication) contains "scanner")
| extend IsAdminProbe = UriPath has_any (admin_paths)
| extend IsErrorResponse = tostring(RequestContext) contains "404" or tostring(RequestContext) contains "403" or tostring(RequestContext) contains "401"
| where IsScannerUA or (IsAdminProbe and IsErrorResponse)
| summarize RequestCount = count(), DistinctPaths = dcount(UriPath), PathsTried = make_set(UriPath, 20), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by RequestClientIP, DestinationHostName
| where RequestCount > 25 or DistinctPaths > 5
| sort by RequestCount desc

Velociraptor VQL — Hunt for Scan Evidence in Web Logs

For hospitality operators running self-hosted Apache/nginx frontends, this VQL artifact hunts access logs directly on the web tier for scanner signatures and admin-path enumeration — useful when log forwarding to the SIEM is incomplete or delayed.

-- Hunt web server access logs for scanner tooling and admin path enumeration
LET log_files = SELECT FullPath FROM glob(globs=['/var/log/nginx/access.log', '/var/log/apache2/access.log', '/var/log/httpd/access_log', '/var/log/nginx/access*.log'])
LET scanner_regex = '(?i)(nmap|masscan|sqlmap|nikto|acunetix|nuclei|gobuster|dirbuster|hydra|zgrab)'
LET admin_regex = '(?i)(/admin|/manager/html|/phpmyadmin|/setup|/install|/console|/cgi-bin|/\.env|/\.git)'
SELECT FullPath, Line
FROM foreach(row=log_files, query={
    SELECT FullPath, Line
    FROM parse_file(filename=FullPath, accessor='file')
    WHERE Line =~ scanner_regex OR (Line =~ admin_regex AND Line =~ ' (401|403|404) ')
})
ORDER BY FullPath

Remediation Script — Identify and Block Repeat Scanning Sources

The following Bash script audits nginx/Apache access logs for scanning behavior, extracts the most aggressive source IPs, checks them against an existing blocklist, and optionally adds repeat offenders to nftables. Test in report-only mode (--report) before enabling the blocking mode.

#!/usr/bin/env bash
# audit-hospitality-scans.sh — Detect and optionally block mass-scanning sources
# Usage: ./audit-hospitality-scans.sh --report   (analysis only)
#        ./audit-hospitality-scans.sh --block    (adds offenders to nftables)

set -euo pipefail
MODE="${1:---report}"
THRESHOLD=50          # requests matching scan patterns before flagging
LOG_DIRS="/var/log/nginx /var/log/apache2 /var/log/httpd"
NFT_SET="scan_blocklist"

SCAN_REGEX='(nmap|masscan|sqlmap|nikto|acunetix|nuclei|gobuster|dirbuster|hydra|zgrab|/manager/html|/phpmyadmin|/\.env|/\.git|/cgi-bin|/wp-admin)'

echo "[+] Aggregating access logs..."
find $LOG_DIRS -name 'access*' -type f 2>/dev/null | sort -u > /tmp/logfiles.txt
if [ ! -s /tmp/logfiles.txt ]; then echo "[-] No access logs found. Exiting."; exit 1; fi

# Extract source IPs tied to scanning patterns, count hits
cat $(cat /tmp/logfiles.txt | tr '\n' ' ') 2>/dev/null \
  | grep -Ei "$SCAN_REGEX" \
  | awk '{print $1}' \
  | sort | uniq -c | sort -rn \
  | awk -v t="$THRESHOLD" '$1 >= t {print $1, $2}' > /tmp/scan_offenders.txt

echo "[+] Offenders above threshold ($THRESHOLD hits):"
cat /tmp/scan_offenders.txt || echo "    (none)"

if [ "$MODE" = "--block" ]; then
  echo "[+] Ensuring nftables set exists..."
  nft list set inet filter "$NFT_SET" >/dev/null 2>&1 || \
    nft "add set inet filter $NFT_SET { type ipv4_addr; flags timeout; }"
  nft list chain inet filter input >/dev/null 2>&1 || \
    nft "add chain inet filter input { type filter hook input priority 0; policy accept; }"
  nft list chain inet filter input | grep -q "$NFT_SET" || \
    nft "add rule inet filter input ip saddr @$NFT_SET counter drop comment \"hospitality-scan-block\""

  while read -r count ip; do
    echo "    Blocking $ip ($count hits) for 24h"
    nft add element inet filter "$NFT_SET" "{ $ip timeout 24h }" 2>/dev/null || true
  done < /tmp/scan_offenders.txt
  echo "[+] Done. Verify with: nft list set inet filter $NFT_SET"
else
  echo "[+] Report mode only. Re-run with --block to enforce nftables drops."
fi

Remediation and Hardening

Because this activity is reconnaissance rather than exploitation of a single patchable flaw, remediation is architectural. Prioritize in this order:

1. Remove admin interfaces from the public internet. PMS admin consoles, property back-office portals, and vendor management interfaces should be reachable only via VPN, zero-trust access broker, or IP allowlisting. This single control eliminates the majority of what these scanners are hunting for.
2. Deploy and tune a WAF in blocking mode. Enable rate-based rules (e.g., AWS WAF rate-based rules, Cloudflare rate limiting, or ModSecurity CRS with anomaly scoring) on booking and reservation endpoints. Blocking is safe at the scanner-signature layer — no legitimate guest sends an sqlmap User-Agent.
3. Filter hosting-provider ASNs where the business allows. Actual hotel guests browse from residential and mobile networks. Requests to your booking portal from cloud/VPS ASNs are overwhelmingly automated. Geo-IP and ASN filtering at the CDN or edge layer is a cheap, high-yield reduction in scan surface.
4. Enforce MFA on all hospitality application authentication. Scanning waves targeting staff portals are frequently precursors to credential stuffing and password spraying. Phishing-resistant MFA (FIDO2) on PMS, channel manager, and corporate SSO neutralizes the most common follow-on attack.
5. Patch and inventory hospitality software aggressively. Maintain a current inventory of every internet-facing hospitality component — booking engines, PMS web modules, payment middleware, channel manager integrations — and subscribe to vendor security advisories for each. When a CVE drops for one of these platforms, your patch window is measured in days, not months, because the scanning infrastructure to find vulnerable instances already exists and is already running.
6. Centralize web-tier logging. Every detection above depends on web and WAF logs reaching your SIEM. If your properties' web servers log only locally, close that gap now — it is both a PCI-DSS requirement (Requirement 10) and the foundation of any detection capability.
7. Monitor threat intelligence for hospitality-specific CVEs. Sector-targeted scanning campaigns frequently escalate to exploitation within days to weeks. If a vulnerability in your PMS or booking platform appears in the CISA Known Exploited Vulnerabilities catalog, treat remediation as an emergency change.

Key Takeaways

• The SANS ISC's observation of scanning targeting hospitality applications is pre-exploitation reconnaissance — the early warning, not the incident. Act while it's cheap.
• The highest-fidelity detections are scanner-tool User-Agents and admin-path enumeration producing 4xx responses. Both are nearly noise-free against real guest traffic.
• The single most effective hardening step is removing hospitality admin interfaces from the public internet entirely.
• If your web-tier logs aren't in your SIEM, that is the incident hiding inside this incident. Fix logging before you need it.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub