Booking.com Breach Exposure: What Lunar Saw Before the Incident

On April 13, 2026, Booking.com appeared in public reporting for a cybersecurity incident impacting parts of its environment. While the technical root cause is still being investigated internally, months before the breach hit the news, credentials tied to booking.com were already circulating in infostealer logs. 

Lunar’s telemetry shows a steady cadence of domain‑affiliated credential exposures in the months leading up to the incident. It’s a now‑familiar pattern: a Windows machine is quietly infected, browser logins are harvested and stockpiled, and only later does a malicious actor convert those stolen identities into real, authenticated access. 

What Lunar Saw Before the Booking.com Incident 

After reviewing our data between September 2025 and April 2026, we see a marked exposure window covering around 28 different credential sets associated with Booking.com personas appearing in infostealer logs. These credentials, collected on a combination of corporate and personal Windows endpoints, were used to access business‑critical resources like:

• Third‑party portals used in Booking.com’s operational workflows.
• SSO environments which allow internal and partner applications to be used.

On April 14, 2026, following public disclosure of the incident on April 13, Lunar ran a retrospective correlation and confirmed that the observed Booking.com‑affiliated exposures formed a persistent precursor window.

This timeline resembles the pattern of how today’s access‑broker ecosystem usually functions: credentials are stolen, bundled in logs, traded or resold, and later chosen for targeted use against specific organizations. 

Snapshot: Key Exposure Details 

• Domain involved: booking.com 
• Observed exposure window: September 2025 – April 2026 
• Approximate distinct exposures: ~28 credential sets 
• Primary malware families: LummaC2, Rhadamanthys, and Redline 
• Impacted infrastructure: Windows endpoints (corporate and personal) 
• Targeted service categories: Third‑party portals and Single Sign‑On (SSO)

Twenty‑eight exposed identities might not seem impressive compared to the size of a global travel platform like Booking.com, but each exposed account represents a potential window into its wider ecosystem. In identity‑based intrusions, a small number of well‑placed accounts can be more useful than a large number of low‑privilege users. 

The Mechanics of Valid Accounts (T1078) 

Credentials are becoming the primary attacker today. Rather than attacking code, they attack browsers and machines used by users every day. Infostealer malware such as LummaC2, Rhadamanthys, and Redline work by exfiltrating formatted “logs” from infected Windows machines, usually containing:

• Browser‑stored usernames and passwords
• Session cookies and tokens, which can facilitate session hijacking and MFA bypass
• Other system metadata and artifacts useful in profiling a victim

Within the MITRE ATT&CK framework, this activity often culminates in the use of Valid Accounts (T1078), as adversaries authenticate with valid credentials instead of exploiting a software flaw. When an attacker obtains Booking.com credentials from SSO or third‑party portals:

• The next login looks like an authentic user session. 
• Traditional signature‑based defenses see a valid username and password, not an exploit. 
• Security teams may not see blatant attack indicators, only subtle signs such as unusual IP ranges or access times.

This is why Valid Accounts are so useful: early adversary activity can be nearly indistinguishable from the behavior of a legitimate user. 

A Plausible Attack Pattern 

Lunar does not claim any of the 28 observed credential exposures were used in the April 13, 2026 Booking.com incident. But the telemetry fits a typical attack pattern used for infostealer‑augmented breaches:

• Initial infection: A user connected to an organization’s ecosystem inadvertently executes a payload, such as LummaC2 or Redline, on a Windows device. Common vectors include SEO poisoning, spam, fraudulent ads, cracked software, and deceptive “updates” or installers.
• Exfiltration: Following its execution, the infostealer harvests credentials for corporate SSO, logins for external vendor and partner portals, and browser session cookies to support further session hijacking.
• Credential sale and stockpiling: The stolen data is packaged into logs and funneled to centralized “Log Clouds” where actors search for domain-specific names, and Initial Access Brokers (IABs) who tag, curate, and price access according to perceived worth.
• Lateral movement and expansion: A threat actor picks corresponding credentials from this pool and attempts to authenticate into professional environments, such as SSO and third‑party systems, leverage stolen cookies to bypass MFA where possible, and use any successful foothold to move laterally and escalate privileges.

This is less a one-off “hack” than a long‑tail workflow: broadly steal today, decide how and where to exploit that identity later. 

Aggregated Timeline Insight 

Taken as a whole, the Booking.com exposure narrative in the months prior to April 2026 looks like this:

Q4 2025 

• First uptick in Rhadamanthys activity involving Booking.com. 
• Early infostealer logs add domain‑linked credentials for third‑party portals.

Q1 2026

• Ongoing steady exposure rate with a major shift to LummaC2 variants. 
• Booking.com credentials in logs increasingly being tied to accounts associated with SSO and portal access instead of just standalone websites.

April 2026

• April 13, 2026: Public report of the Booking.com incident. 
• April 14, 2026: Incident correlation date, where Lunar aligns the exposure patterns with the breach timeline. 

The constant presence of ~28 different exposures over this period suggest a persistent threat surface, not just one‑off exposure. This trend, even absent direct forensic links, reflects how Booking.com’s identity layer had become a hard target for infostealer‑enabled actors.

The Human Aspect: Personal Devices and Shadow IT

An interesting aspect presented in the telemetry is the mixture of corporate and personal devices that are feeding into the Booking.com exposure picture. Today, in a work-from-anywhere environment, employees and partners often use Windows machines or dual-use devices to access: 

• Corporate portals 
• Third‑party tools 
• Support and partner dashboards

The issue is that these “unmanaged” endpoints rarely have the strong Endpoint Detection and Response (EDR) configurations, hardening, and strict patching on corporate‑issued devices. 

Typical high‑risk situations:

• Logging into an organizational SSO from a home PC that’s also used for gaming, personal email, and downloads. 
• Using the same browser profile for work credentials, social media, and consumer services. 
• Using vendor or partner portals from devices outside of corporate monitoring or control.

When an infostealer gets onto one of these devices, it doesn’t need VPN access or domain join status. The browser is itself the attack surface: everything that it remembers, like passwords, cookies, and form information belongs to the attacker. 

The corporate perimeter quietly extends into the home office. The first compromise, while on a non‑managed device may happen, however, it affects the entire organizational environment.

Conclusion: Lessons in Resilience

The Booking.com incident highlights a key takeaway for contemporary safeguarding initiatives: credential hygiene is no longer just about strong passwords. It’s about how, where, and on what devices those credentials are stored, and how quickly organizations can respond to incidents when they emerge in the infostealer ecosystem. The observed exposure of SSO and third‑party portal credentials via infostealers demonstrates the need for a number of concrete defenses.

Device Posture Checking

Ensure that only managed, healthy devices can access SSO or high‑value applications. Limit or block logins from unmanaged endpoints with device‑based conditional access.

Token Obsolescence

Reduce session lifetimes and increase re‑authentication for sensitive apps/admin processes. This reduces the window in which stolen session cookies are still useful for an attacker.

Dark Web and Stealer‑Log Tracking

Preemptively scan for credentials in recent infostealer dumps. Consider every discovery a micro‑incident: request password resets, revoke tokens, and check for recent account activity.

MFA Hardening and Risk‑Based Access

Choose phishing‑resistant MFA (e.g., FIDO2/WebAuthn) for administration and high‑risk roles. Combine MFA with anomaly detection (impossible travel, unknown devices) to flag suspicious “legitimate” logins.

Although the relationship between these 28 exposures and the Booking.com breach is significant, it is as much a risk assessment as it is a judgment. Identity is the new perimeter in today’s threat environment, and infostealers are some of the most effective tools for quietly breaking down that perimeter over time.