# Real PNRs, Fake Refunds: The Amadeus Breach as an Email Security Risk for India's Airlines and OTAs
Published: 2026-11-12
Category: Threat Landscape
Category URL: https://ravenmail.io/blog/category/threat-landscape
Meta Title: Amadeus Breach: Phishing Risk for Indian Airlines & OTAs
Meta Description: Stolen Amadeus booking data powers phishing with real PNRs. See how the lure works and what India's airlines and OTAs should change in email defenses.
Tags: phishing, Supply Chain Attacks, BEC Attack, Brand Impersonation
Tag URLs: phishing (https://ravenmail.io/blog/tag/phishing), Supply Chain Attacks (https://ravenmail.io/blog/tag/supply-chain-attacks), BEC Attack (https://ravenmail.io/blog/tag/bec-attack), Brand Impersonation (https://ravenmail.io/blog/tag/brand-impersonation)
URL: https://ravenmail.io/blog/amadeus-breach-phishing

A breach at a reservation vendor in Madrid is now an inbox problem for security teams in Mumbai, Delhi and Bengaluru. Attackers spent about 37 months reading real airline reservations through Amadeus, then used that data to send phishing emails that contain a customer's correct booking reference, name and route.

No Indian airline or OTA has publicly disclosed exposure so far. That is not the same as being out of reach. The attack is brand-agnostic, the lure is a template, and the thing it defeats is the one control most email security programs still lean on: the assumption that a message with accurate details is probably real. This post looks at the incident through that lens, as an emerging email security risk for India-based airlines and OTAs.

## The incident in brief

Amadeus IT Group, which runs the Altéa passenger service system, was breached between August 2023 and September 2026. Access came through compromised administrative system-account credentials and an authorization flaw in a booking-display environment. Amadeus began notifying carriers between October 20 and October 28, 2026, and public disclosures followed.

- **Data exposed:** Passenger Name Records (PNRs), names, flight dates, routes, booking classes and contact details. For some travelers, also passport numbers, frequent flyer IDs and nationality.

- **Not exposed at source:** payment card numbers. Card data was collected later, from victims, through phishing.

- **Carriers that have disclosed:** Japan Airlines (92,000 customers), Cathay Pacific (53,000 bookings), Singapore Airlines (46,000), ANA (37,800), Finnair (about 116,000), Malaysia Airlines, Korean Air, Asiana Airlines, Qantas and others.

- **Attribution:** an unnamed, financially motivated cybercrime group.


**Where Indian carriers stand.** No Indian airline appears among the disclosing carriers, and we found no CERT-In advisory on this incident as of November 12, 2026. Amadeus says more than 130 airlines use Altéa, and that figure is the platform's customer base, not the count of confirmed victims.

## Why this is an emerging risk for India

Three things make this relevant for an Indian carrier:

- **The lure is a template.** The observed campaign impersonates Frontier Airlines, but nothing in it is specific to Frontier. Swap the brand, the lookalike domain and the PNR format, and it works against any carrier or OTA. Expect lookalike domains that pair Indian airline and OTA brands with words like `crs`, `cms`, `refund`, `pnr` and `support`.

- **Your customers may already be in the data.** Indian travelers fly the carriers that have disclosed. Those carriers have not published breakdowns by country, so assume some of your customers' PNRs and email addresses are in the stolen set, and that the phishing may reach them under a foreign airline's name while they contact you for help.

- **Refund and cancellation email is normal traffic.** Airlines and OTAs send refund, cancellation and payment-correction messages every day. A "duplicate fee refund" email looks like business as usual to your customers and to your own staff.


For corporate travel desks, the same data supports targeted business email compromise against travellers who are mid-journey, since itineraries show where staff will be and when.

## Anatomy of the lure, from the inbox

The email is built to pass every check a person or a filter normally applies.

1. **Accurate personalisation.** Each message carries the recipient's real six-character PNR, full name, departure date and city pair. Content-based filtering and "does this look right?" training both lose their signal.

2. **A believable pretext.** Three themes are used:

   1. A duplicate-fee or airport-tax refund (sometimes several times the ticket value),

   2. A "settlement batch for this reservation has already closed" explanation for why the refund can't go to the card on file

   3. and a warning that an unresolved payment error will cancel the ticket within 24 hours.
3. **A clean-looking delivery path.** The observed campaign was sent through a compromised third-party business email relay, `noreply@reviewpro[.]com`, rather than a freshly registered sender. Mail from a legitimate relay is more likely to carry a reasonable sender reputation and [pass basic authentication on that relay's own domain](https://ravenmail.io/blog/phishing-using-google-infra), so these checks alone will not catch it.

4. **A landing page that captures before you submit.** Links lead to portals styled as airline CRS or CMS pages. Client-side listeners send card numbers, expiry dates and CVVs as they are typed, so a customer who gets suspicious and closes the form has still lost the data.


The weak points for the attacker are the click and the page, not the message. That is where detection and takedown effort pays off.

## Where email controls fall short, and what to change

Control layer

Why it falls short here

What to change

User awareness training

Red flags like wrong names or odd details are absent

Teach out-of-band verification: open the official app or type the domain, never act from the email

Content and keyword filtering

The message is accurate and reads like a normal refund notice

Add rules for refund and "settlement batch" language combined with an external link, and for your own PNR format arriving from outside

Sender reputation and authentication

Mail came via a compromised legitimate relay

Do not treat a passing SPF or DKIM result on a third-party sender as trust; weigh the relay-to-brand mismatch

Your own domain protection

Attackers use lookalikes, not your exact domain

Enforce DMARC at p=reject on every domain you own, and monitor for lookalike registrations

URL and web filtering

Portals are fresh lookalike domains

Block known domains, use newly-registered-domain and typosquat detection, and inspect for POSTs to unverified travel infrastructure

Customer-facing messaging

Customers cannot tell your refunds from fakes

Publish a plain "we never ask for card details by email" statement and point to one in-app refund path

Incident response

Card capture happens before submission

Tell affected customers to reissue cards even if they abandoned the form

## Indicators of compromise

Type

Value

Context

Phishing domain

`flyfrontiercrs[.]com`

Fake Frontier CRS refund workflow

Phishing domain

`flyfrontiercms[.]com`

Lookalike refund and billing management

Legitimate reference

`flyfrontier[.]com`

Official Frontier site, for baseline comparison

Compromised sender

`noreply@reviewpro[.]com`

Compromised third-party relay used for delivery

Subject keywords

`Settlement batch closed`, `Duplicate ticketing refund`, `Booking validation required`

Core lure pretexts

Behavior

Client-side input listeners

Payment fields sent asynchronously as they are typed

These are the observed indicators. Build equivalent patterns for your own brand, for example `*[yourbrand]crs.*`, `*[yourbrand]cms.*` and `*[yourbrand]refund*`.

## The takeaway

The Amadeus breach shows how stolen booking data turns routine refund email into a high-conversion attack, and it is brand-agnostic. For India-based airlines and OTAs, the practical move is to stop relying on message accuracy as a trust signal. Verify out of band, enforce your domain protections, watch for lookalikes, and be ready to act before a vendor confirms your own exposure.

## About Raven

[RavenAI (Raven)](https://ravenmail.io) is an AI-native, context-aware email security company protecting organisations on Microsoft 365 and Google Workspace. Its LLM engine reads intent, context and identity signals to stop phishing, impersonation, business email compromise and financial fraud that slip past rules-based filters, and its AI-powered DLP stops sensitive data leaving by email. Raven secures millions of emails every day for organisations across fintech, payments, banking technology and insurance, and has been featured in [Microsoft's AI First Movers programme.](https://www.microsoft.com/en-in/aifirstmovers/FY26Ravenmail)


---
This blog is powered by Superblog. Visit https://superblog.ai to know more.
---

