Skyticket: three ways in, 14.64 million records. Japan's researchers have just named the pattern behind one of them.

Three different doors, opened within two months, at one company. A booking page that anyone could read without logging in. A flaw in a back-office system. And, in the largest case, administrative functions used to reach other servers and cloud data. Four days after Adventure disclosed all three, Japan's National Institute of Information and Communications Technology (NICT) named a pattern that explains many of this autumn's leaks: attackers analyse a company's app, then go after the servers behind it.

What Adventure has disclosed

Adventure runs skyticket, a site and app for booking flights, hotels and buses. On 9 October 2026 it published a notice describing three intrusions with different routes. Adventure / skyticket (Japanese)

Route	When	Found	Records	What leaked
1. Admin functions misused to reach other servers and cloud data	2–4 October	5 October	About 14.64 million	Name (including passport spelling), date of birth, email, phone, postcode and address, name used for bank transfers; for about 4.13 million members, the hashed login password
2. A vulnerability in a business management system	20 September	28 September	17,780, including duplicates; more under investigation	Customer details including bank accounts for refunds
3. A bus booking completion page that could be viewed without logging in, read by machine	3 August – 1 October	Fixed 1 October	About 12,000 bookings	Booking details

Not leaked, according to Adventure: passport numbers. Card numbers and passport images were not stored.
Response: the routes were blocked and the flaws fixed. Payment with saved cards, and saving new cards, were switched off from about 18:00 on 7 October. The company has reported to the Personal Information Protection Commission and is emailing affected customers.
Misuse so far: apart from one member account that was logged into without authorisation, no secondary harm has been confirmed.
Warning to customers: expect contact by email, SMS, phone or post from people posing as Adventure, banks, airlines or bus companies. Change the skyticket password, and the password of any other service where it was reused.

Reports differ slightly on the total: about 14.64 million for the largest route, or about 14.67 million across all three. ITmedia NEWS (Japanese) · @IT (Japanese)

Scale. At 14.64 million records, this would be the third-largest disclosure in our 12-month list, after EPARK Relax & Esthe (33 million) and Gyazo (23.62 million). It came a day after that list closed.

Figure 1. Three routes, two months. Original graphic for this article.

The pattern NICT named four days later

On 13 October, NICT's threat analysis team LETTICE published an alert on what it calls the A2B attack (App-to-Backend). The communications ministry issued a related alert to businesses the same day. NICT (Japanese) · Alert, PDF (Japanese)

The method. The attacker takes a published Android app, analyses it to learn which servers it talks to and how its APIs are used, and then attacks those servers directly. The app itself does not need a vulnerability; the weakness is on the server.
The weaknesses it names: server-side request forgery (SSRF), remote code execution (RCE), SQL injection, and broken object-level authorisation (IDOR, also called BOLA), where a server returns a record for any ID it is given.
Beyond Android. NICT says iOS apps and web services can be attacked the same way, and that AI could make analysing apps and finding flaws faster, spreading attacks to more systems.
What it asks app owners to do: check for compromise, including subdomains, old APIs, test environments and public cloud services, and review logs from August 2026 onwards against published indicators; check for the four weaknesses plus exposed keys and weak session handling; and, as interim steps, stop unneeded APIs, admin functions and test environments, restrict access, rate-limit, and reissue credentials that may have leaked.

ITmedia NEWS (Japanese) · INTERNET Watch (Japanese)

NICT has not attributed any company's breach to this pattern, and Adventure has not said how its routes were found. But route 3 is the textbook case of the fourth weakness: a page that returned a booking to anyone who asked for it, without checking that the asker owned it, read by a script for two months. Our Lawson ID analysis described the same class of flaw on 8 October: data that came out through the mechanism meant to show customers their own records.

What the three routes tell defenders

Each route needed a different fix, and all three existed at once. A missing login check, an unpatched business system, and admin functions reachable by someone who should not have reached them. One penetration test of the main site would likely have found at most one of them.
The smallest leak ran longest. Route 3 went on for almost two months before it was fixed on 1 October. Its signal, one client reading thousands of different bookings, is cheap to detect (query 1 below).
The largest leak was a pivot. Admin functions led to “other servers and cloud data”. That is where the 14.64 million records were: not in the web application, but in what the application, or its administrators, could reach.
Hashed passwords are not the end of it. Adventure has not said which hashing method it used. Fast, unsalted hashes can be cracked at scale; slow, salted ones resist. Either way, the 4.13 million email-and-hash pairs are what credential-stuffing attacks start from, which is why Adventure asks members to change reused passwords elsewhere.
Travel data makes convincing lures. Names in passport spelling, birth dates, phone numbers and booking context let a caller sound like an airline or bus company. Business travellers are in this data too.

The attacker's playbook

This is how a red team would combine the three routes, mapped to MITRE ATT&CK. It is a model, not a reconstruction.

Step	What it would look like here	ATT&CK
Map the back end	Decompile the Android app; list API hosts, paths, parameters, admin or staging hosts and any keys it carries	T1594 Search Victim-Owned Websites; T1592 Gather Victim Host Information
Read what needs no login	Walk booking references on a page that does not check ownership	T1190 Exploit Public-Facing Application; T1119 Automated Collection
Break a side door	Exploit a flaw in a less-watched business system	T1190 Exploit Public-Facing Application
Use the admin functions	Reach admin features with stolen, default or unprotected access; use them to query other servers	T1078 Valid Accounts; T1021 Remote Services
Take the data store	Pull customer tables from cloud storage or databases	T1530 Data from Cloud Storage
Turn hashes into logins	Crack weak hashes; try email-and-password pairs elsewhere	T1110.002 Password Cracking; T1110.004 Credential Stuffing
Cash in	Calls and SMS posing as airlines, bus companies or banks	T1566 Phishing; T1656 Impersonation

The defender's playbook

1. If you publish an app: do NICT's three steps this week

Inventory everything your app can reach. Decompile your own release builds and list every host and path; include old API versions, staging hosts and cloud endpoints. Anything not needed is turned off.
Test each endpoint for the four weaknesses. For IDOR, sign in as customer A and request customer B's records; then request them with no login at all. Pages such as booking confirmations, receipts and tickets are the usual gap.
Keep admin functions off the internet. Admin paths answer only from admin networks, behind multi-factor sign-in. Query 2 shows who reaches them today.
Review logs from August onwards. NICT's window. Use JPCERT/CC's published indicators, which our 60-day review turns into queries.

2. If your staff book travel through skyticket

Passwords: change the skyticket password and any password reused elsewhere, especially for work accounts.
Calls and messages: airlines, bus companies and banks will not ask for card numbers or one-time codes by phone or SMS. Call back on the number on the official website.
Refunds: anyone who received a refund by bank transfer should watch that account and be wary of “refund” contact.

3. Detect the three routes in your own estate

Enumeration: one client reading many different references on pages that need no login (queries 1 and 4).
Admin from the wrong place: admin paths reached from outside admin networks (query 2).
Lures: mail that names skyticket from other domains (query 3).

4. Which teams should act

Team	Exposure to review	Next step	Evidence needed
App owners and IT Operations	APIs and pages behind your apps	Run the IDOR and no-login tests; close unneeded hosts and admin paths	Endpoint list, test results, dates
SIEM / SOC	Web and API logs since August	Schedule queries 1, 2 and 4; check JPCERT/CC indicators	Query schedule, findings
Email Security	skyticket-themed mail	Run query 3; block confirmed lookalikes	Message list, blocks
Legal / Privacy	Staff and customer data in travel bookings	Decide whether to inform staff; check travel-agency contracts	Decision record
Third-party Risk	Travel and booking suppliers	Ask how their apps and admin functions are protected	Written answers

Hunting

No indicators specific to Adventure have been published. The queries look for the behaviours behind its routes in your own logs. JPCERT/CC's indicators for the wider wave are in our 60-day review.

All queries are illustrative and were not run against live data. Table and field names were checked against vendor documentation on 14 October 2026 (JST). Expect noise: customers reloading their own pages, monitoring tools, and administrators working remotely.

1. A page that needs no login, read for many different bookings. Microsoft Sentinel, IIS logs in W3CIISLog.

// Illustrative; not run against live data. Microsoft Sentinel, W3CIISLog (IIS). Adapt the column names for other web, API gateway or WAF logs.
// Pages that show a booking without a login: one client reading many different booking references.
// A customer opens their own confirmation page a few times. A script walks through thousands.
let Since = ago(30d);
let ConfirmationPath = @"(?i)REPLACE_WITH_CONFIRMATION_PAGE_PATH";
let ReferenceInQuery = @"(?i)(?:id|booking|reservation|ref)=([A-Za-z0-9-]{4,})";
W3CIISLog
| where TimeGenerated > Since
| where csUriStem matches regex ConfirmationPath
| where csUserName == "-"
| extend Reference = coalesce(extract(ReferenceInQuery, 1, csUriQuery), extract(@"/([A-Za-z0-9-]{6,})/?$", 1, csUriStem))
| summarize Requests = count(), DistinctReferences = dcount(Reference), Agents = make_set(csUserAgent, 5),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by cIP, bin(TimeGenerated, 1h)
| where DistinctReferences > 20
| order by DistinctReferences desc
| take 500

2. Admin functions reached from outside admin networks. Microsoft Sentinel, W3CIISLog.

// Illustrative; not run against live data. Microsoft Sentinel, W3CIISLog (IIS). Adapt the column names for other web, API gateway or WAF logs.
// Admin functions reached from outside the networks your administrators use.
// List your admin paths and the address ranges allowed to use them; every other source in the result needs an explanation.
let Since = ago(30d);
let AdminPaths = @"(?i)REPLACE_WITH_ADMIN_PATH_PATTERN";
let AdminRanges = dynamic(["REPLACE_WITH_ADMIN_CIDR_1", "REPLACE_WITH_ADMIN_CIDR_2"]);
W3CIISLog
| where TimeGenerated > Since
| where csUriStem matches regex AdminPaths
| where not(ipv4_is_in_any_range(cIP, AdminRanges))
| summarize Requests = count(), Succeeded = countif(toint(scStatus) between (200 .. 299)), Paths = make_set(csUriStem, 20),
    Users = make_set(csUserName, 10), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by cIP
| order by Succeeded desc, Requests desc
| take 500

3. Inbound mail naming skyticket from other domains. Microsoft Defender XDR advanced hunting; needs Defender for Office 365.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Inbound mail since 9 Oct 2026 that names skyticket but was not sent from its domain.
// Adventure says it is emailing affected customers and warns of fakes posing as the company, banks, airlines and bus operators.
let Since = datetime(2026-10-09T00:00:00Z);
let LurePattern = @"(?i)skyticket|スカイチケット";
let OfficialDomains = @"(?i)(^|\.)(skyticket\.jp|REPLACE_WITH_OTHER_VERIFIED_SENDER_DOMAIN)$";
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where Subject matches regex LurePattern or SenderDisplayName matches regex LurePattern
| where not(SenderFromDomain matches regex OfficialDomains)
| join kind=leftouter (
    EmailUrlInfo
    | where Timestamp > Since
    | project NetworkMessageId, UrlDomain
    ) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), UrlDomains = make_set(UrlDomain, 10),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| order by FirstSeen asc
| take 500

4. The enumeration check in Splunk for web logs with CIM-style fields (src, uri_path, uri_query, user).

index="REPLACE_WITH_WEB_INDEX" sourcetype="REPLACE_WITH_WEB_SOURCETYPE" uri_path="REPLACE_WITH_CONFIRMATION_PAGE_PATH*" earliest=-30d
| where isnull(user) OR user="-"
| rex field=uri_query "(?i)(?:id|booking|reservation|ref)=(?<reference>[A-Za-z0-9-]{4,})"
| bin _time span=1h
| stats count AS requests dc(reference) AS distinct_references values(http_user_agent) AS agents BY _time src
| where distinct_references > 20
| sort 0 - distinct_references

Download the examples: enumeration KQL · admin access KQL · mail KQL · enumeration SPL.

Other platforms. Sumo Logic, web servers writing the Apache or Nginx combined log format: admin paths reached from public addresses. Add the public addresses your administrators use as exceptions.

_sourceCategory="REPLACE_WITH_WEB_SOURCE_CATEGORY" "REPLACE_WITH_ADMIN_PATH"
| parse regex "^(?<src_ip>\S+) \S+ \S+ \[[^\]]+\] \"\S+ (?<path>\S+) [^\"]*\" (?<status>\d{3})"
| where !isPrivateIP(src_ip)
| count as requests by src_ip, path, status
| sort by requests

No result does not prove nothing happened. If your web logs do not record the query string or the signed-in user, enumeration and admin misuse look like ordinary traffic. W3CIISLog table · EmailEvents

Copy-paste templates

Replace everything in [square brackets]. Have Legal or Privacy review anything that leaves the company.

A2B self-check for the team or vendor that runs your app

Subject: [Company] – app back-end checks following NICT's A2B alert of 13 October 2026

NICT has warned that attackers are analysing published apps to find and attack the servers behind them (the "A2B attack"). Please answer the following in writing by [date].
1. List every host, API path and cloud endpoint our Android and iOS apps contact, including old API versions and staging or test hosts. Which are no longer needed, and when will they be switched off?
2. For each endpoint that returns personal data: has it been tested by requesting another customer's record, and with no login at all? Date and result.
3. Which pages show booking, order or receipt details without a login? How are their references generated, and can they be guessed or enumerated?
4. Have the endpoints been tested for SSRF, SQL or NoSQL injection and remote code execution? Date of the last test and open findings.
5. Does the app contain any API key, secret or credential? What can it do without a customer signing in?
6. Where are the admin functions, and from which networks can they be reached? Is multi-factor sign-in enforced?
7. Have logs from August 2026 onwards been checked against JPCERT/CC's published indicators? Result?
8. Which rate limits and alerts apply to profile, booking and admin endpoints?
9. How are passwords stored (algorithm, salt, work factor)?
10. Within how many hours would you tell us of suspected unauthorised access, and through which verified channel?
Kind regards,
[Name, title, department]

Note to staff who travel on business

Subject: skyticket data leak – change your password and watch for fake calls

Adventure, which runs the travel booking site skyticket, said on 9 October 2026 that customer data leaked through three separate intrusions. About 14.64 million records were involved, including names, birth dates, phone numbers, addresses and, for some members, hashed passwords.
- If you have a skyticket account, change its password. If you used the same password anywhere else, especially for work, change it there too.
- Expect calls, SMS and emails pretending to be skyticket, an airline, a bus company or a bank. Do not give card numbers, one-time codes or passwords. Call back on the number on the official website.
- If you received a refund from skyticket by bank transfer, watch that account and report anything unusual to your bank.
- Report suspicious messages to work mailboxes with [report button or address].
Questions: [security contact].

Five-line briefing for management

1. What happened: travel booking site skyticket (Adventure) disclosed three separate intrusions on 9 Oct 2026; about 14.64 million records leaked, 4.13 million with hashed passwords; refund bank details for 17,780 people and about 12,000 bus bookings through two other routes.
2. Why it matters to us: on 13 Oct NICT warned that attackers analyse published apps to attack the servers behind them. One of skyticket's routes, a booking page that needed no login, is that pattern. [Our app / our vendor's app] has the same kinds of pages and APIs.
3. Our exposure: endpoints inventoried [yes / by date]; no-login and other-customer tests [done / due]; admin functions limited to admin networks [yes / no]; logs since August checked [yes / due].
4. Actions under way: vendor questions sent [date]; enumeration and admin-access queries scheduled; staff told to change reused passwords [date].
5. Decisions needed: [e.g. switch off old API versions; require a back-end security test before each app release]. Next update: [date].

What remains unknown

How the admin functions were reached: stolen credentials, a missing access control, or a flaw.
What the business-system flaw was, and how many more records route 2 will add.
How the passwords were hashed, and so how quickly they can be cracked.
Whether the three routes are linked, or whether one attacker found the others.
Whether any of the routes started from analysis of skyticket's app. NICT has not said so, and neither has Adventure.

Sources and updates

15 October 2026: first published. Adventure's notice and the NICT alert were checked on 14 October (JST) through news reports and search results; we could not open the original pages directly from our research environment.

30-second briefing