On August 24, 2024 — Labor Day weekend in the United States — the Port of Seattle, the public authority that operates Seattle-Tacoma International Airport and the surrounding maritime facilities, detected a ransomware intrusion that took multiple operational systems offline. The Rhysida ransomware group subsequently claimed responsibility and demanded approximately $6 million in cryptocurrency, listing the Port of Seattle on its Tor leak site and posting samples of exfiltrated data. The Port refused to pay. Operationally, Sea-Tac saw common-use gate systems, the flySEA passenger app, the Port website, baggage handling assistance, and passenger display boards degrade or fail; airline-operated systems and federal-agency systems including the FAA and TSA remained unaffected. The Port confirmed in November 2024 that approximately 90,000 individuals had personal data exfiltrated. The incident is a clean public-sector ransomware case study and a useful lens for any port, airport, or transit authority planning a 2026 hardening cycle.
Who is Rhysida and how did they get in?
Rhysida is a ransomware-as-a-service brand active since May 2023 with documented victims in healthcare, education, government, and critical infrastructure including the British Library, Insomniac Games, the Chilean Army, and Prospect Medical Holdings. CISA, the FBI, and the Multi-State Information Sharing and Analysis Center published joint advisory AA23-319A on Rhysida in November 2023, detailing affiliate tradecraft. Initial access in Rhysida intrusions is typically through phishing, exploitation of Citrix and VPN appliances, and abuse of stolen credentials sold by initial-access brokers. The Port of Seattle has not publicly named the initial-access vector for the August 2024 intrusion, citing ongoing investigation, but the technical pattern observed — rapid lateral movement, credential harvesting, and selective encryption of customer-facing servers — fits the documented Rhysida affiliate playbook.
What did the attackers actually access?
The Port of Seattle's November 2024 notification disclosed that personal information of approximately 90,000 individuals — primarily current and former Port employees, contractors, and airport workers — had been exfiltrated. Identified data categories included names, dates of birth, Social Security numbers, driver's licence numbers, and limited medical information attached to occupational-health records. Rhysida's leak-site posting claimed approximately 3 terabytes of stolen data, including operational documents, personnel files, and internal communications. Operationally, the encryption phase affected the Port's customer-facing web properties, internal flight-display systems, and passenger-app backend. Critical aviation safety systems run by the FAA, the airline operators, and the TSA were not affected; the Port specifically and repeatedly emphasised that flight safety was not compromised at any point.
How long were they inside?
The Port of Seattle has not publicly disclosed dwell time. CISA's advisory on Rhysida notes affiliate dwell times typically ranging from days to weeks, with the bulk of activity in the first 72 hours after initial access. The encryption event on August 24, 2024 happened immediately before the Labor Day weekend surge, a timing pattern consistent with affiliate targeting that maximises operational pressure to pay. Recovery was lengthy: the Port restored customer-facing web properties through early September, the flySEA app and display boards into late September, and full internal operations across multiple weeks. Forensic review and notification ran into November 2024 before the 90,000-individual figure was confirmed.
What did existing controls miss?
Three gaps shaped the outcome and they are typical of mid-sized public authorities. First, Rhysida-class actors target environments where Citrix, VPN, and remote-access appliances run with weak or single-factor authentication, and where patch latency for known-exploited vulnerabilities exceeds CISA's recommended remediation windows. Public-sector procurement cycles typically extend remediation latency relative to private-sector peers. Second, segmentation between customer-facing web infrastructure, internal personnel systems, and OT-adjacent baggage and display systems was insufficient to limit the blast radius. Third, the Port's incident-response posture relied on a serial restoration sequence; parallel-restoration tooling would have shortened the customer-impact tail. The fourth issue — distinct from but related to the technical gaps — was the gap between port operational systems and the aviation safety systems operated by the FAA, which fortunately turned out to be wide enough that flight safety was preserved.
# Port and airport authority hardening baseline
port_airport_hardening:
perimeter:
citrix_vpn_mfa_phishing_resistant: required
legacy_remote_access_disabled: true
kev_remediation_sla_days: 14
quarterly_external_attack_surface_scan: required
segmentation:
customer_facing_web_isolated_from_personnel_systems: required
ot_baggage_display_systems_separate_identity_tier: required
airline_systems_separate_air_gap_or_dmz: required
identity:
privileged_role_sso_with_fido2: required
helpdesk_mfa_reset_verified_callback: required
annual_credential_rotation_for_service_accounts: required
recovery:
parallel_restoration_capability_tested_quarterly: required
immutable_backups_air_gapped: required
public_communication_runbook_pre_drafted: required
evidence:
cisa_secure_by_design_pledge_signature: required
annual_third_party_penetration_test: required
What should public-sector operators do now?
Six steps. First, treat KEV remediation as a 14-day operational SLA for perimeter appliances and identity systems, with executive escalation if patch latency exceeds the window. Public-sector procurement does not need to slow vulnerability remediation if the contracts are renegotiated to permit emergency patching. Second, segment customer-facing web infrastructure, personnel systems, and OT-adjacent baggage and display systems into separate identity tiers so that one foothold does not collapse the airport. Third, enforce phishing-resistant MFA on every privileged role and remove SMS OTP from any factor list that touches operational systems. Fourth, build parallel-restoration tooling rather than serial sequential recovery; a 24-hour parallel restore is far more useful operationally than a 24-day serial restore. Fifth, pre-draft public-communication runbooks for ransomware scenarios — the Port of Seattle's transparent communications were widely praised and helped contain reputational damage. Sixth, share TTPs and IOCs through the Aviation ISAC, MS-ISAC, and the TSA Information Circular system so that successor brands replacing Rhysida are caught faster at peer ports and airports.
How does this compare to other 2024-2025 transportation-sector ransomware?
Transportation has been a recurring target through 2024 and 2025. The Port of Lisbon disclosed a LockBit intrusion in late 2022 with continuing consequences. Transnet in South Africa faced operational disruption in 2021. Spanish airline Vueling, Polish railway PKP Intercity, and several US transit authorities have disclosed cyber incidents in the period. The Port of Seattle case is one of the cleanest public examples because the authority communicated transparently, refused the ransom, and articulated the boundary between operational systems under its control and aviation safety systems run by federal partners. The Transportation Security Administration issued cybersecurity directives for surface and aviation transportation through 2023 and 2024 that formalise minimum controls; the Maritime Transportation System Information Sharing and Analysis Center continues to push sector-specific threat intelligence. Public-sector procurement reform proposals at the federal and state level seek to shorten KEV-remediation cycles by exempting emergency patching from full procurement workflows. Defenders at airports and ports should expect continuing regulatory pressure throughout 2026 and budget accordingly for perimeter-appliance hardening, segmentation work, and parallel-restoration tooling.
How Safeguard Helps
Safeguard maps the firmware and software footprint of every perimeter appliance — Citrix, Cisco ASA, Fortinet, Ivanti, SonicWall — and continuously cross-references each against CISA KEV, vendor PSIRT advisories, and ransomware affiliate IOC feeds, so a new Rhysida-favoured CVE surfaces every affected device in your fleet within minutes. Griffin AI reachability analysis flags which management consoles are reachable from the public internet versus segmented, and which identity tiers cross from corporate into OT or airline-adjacent systems. TPRM workflows score every appliance vendor and managed-service provider against contractual breach-notification SLAs and CISA Secure by Design commitments. Policy gates block deployments that embed network images below your minimum patch baseline, and ingest Rhysida, Akira, and Black Basta-successor IOCs continuously so that responders working a Port-of-Seattle-class incident see one prioritised view — not the multi-week serial-recovery slog that defined Labor Day 2024.