Budget Saudi, one of Saudi Arabia’s largest vehicle leasing companies with over 29,000 vehicles and 100 branches across the Kingdom, confirmed this week that an attacker accessed customer records through the company’s mobile application. No financial data taken. Systems stayed up. The company notified the Saudi Exchange, opened an investigation, and activated its response procedures.
Most organisations reading that disclosure will look at the “no financial data” line and move on.
That’s the wrong thing to focus on.
What actually got taken
Budget Saudi’s statement to the exchange describes “a limited portion of the data of certain customers” without specifying what that includes. For a vehicle leasing company, the customer record at minimum holds names, contact details, and booking history. What else sits in there depends on what the app requires to verify identity at the rental stage.
Unlike a compromised card, there’s nothing to cancel. Customer records don’t expire. They get bundled with data from other incidents and resurface in targeted attacks months later. A customer who receives a call from someone who knows their full name, their booking reference, and their registered phone number will believe that caller works for the company. The attacker doesn’t need to stay in the system. They collected what they needed, and now they have a pretext.
Budget Saudi is subject to Saudi PDPL, which requires notification to SDAIA within 72 hours of discovering a breach that poses risk to data subjects. If your organisation is UAE-based, UAE PDPL carries the same kind of obligation with the UAE Data Office.
The compliance question and the damage assessment run in parallel. The regulatory clock started the moment an attacker reached records they weren’t authorised to reach. How much they took affects the severity assessment, not whether there’s an obligation to report.
Why the mobile app was the entry point
Most Gulf enterprises have done real security work over the last four or five years. Firewall policies tightened. MFA deployed on remote access. Endpoint protection across the fleet. A SIEM standing up with logs from Active Directory, Microsoft 365, and Entra ID.
The internal network is better defended than it was. The mobile app hasn’t kept pace.
It has its own authentication flow, its own session logic, its own API endpoints. It connects directly to the backend systems holding customer records, booking history, and personal data. Every perimeter control built over the last four years doesn’t touch it, and it’s reachable by anyone with a phone.
The authentication layer is where the exposure shows up first. MFA offered during onboarding, marked optional to reduce sign-up friction, never enforced. Most users don’t enable it. Credential stuffing doesn’t require sophistication. An attacker takes a database of breached credentials from another platform, runs them against the login endpoint, and waits to see what opens. If users reuse passwords, a percentage of those credentials will work. The app needs to be built on the assumption that the credentials are already out there.
The second issue is what the API returns. A customer checking their booking history gets back a full customer record, because it was faster to build the endpoint that way. The developer wasn’t thinking about enumeration. They were thinking about shipping. An attacker with a valid session iterating through booking IDs doesn’t get confirmation numbers. They get whatever the full customer record holds. Not the three fields the booking summary screen needed. Everything the API was designed to return.
Scoping responses to minimum required fields rarely gets prioritised because it means reopening code that works.
The detection gap
What likely kept the Budget Saudi breach undetected until disclosure was the absence of one log source.
Most Gulf enterprises running a properly instrumented SOC are ingesting firewall logs, endpoint telemetry, and Entra ID sign-in events. That coverage is real. An attacker touching the internal network or the identity layer is going to generate noise.
What’s not in most SIEMs is the API gateway. The mobile app communicates with the backend through an API layer that generates its own traffic logs: every endpoint called, every response returned, every session token used, every volume spike. If those logs aren’t in the SIEM, the attacker is invisible. The firewall sees valid HTTPS traffic to a known endpoint. Entra ID records a successful authentication and stops there. An attacker making several thousand requests to a customer lookup endpoint across a single day looks like a slightly active user.
With API gateway logs feeding a SIEM, that pattern would stand out. A baseline of normal customer activity, a single session generating hundreds of lookup requests: that’s detectable. Without the log source, there’s nothing to measure against.
The mobile app as entry point is consistent with a methodology that’s become more deliberate across the region. Requests kept deliberately low, spaced to blend into normal traffic. Session tokens used sparingly to avoid anomaly detection. No lateral movement into the network, no privilege escalation. Just the API layer, worked slowly and without triggering anything.
The network gets monitored. The identity layer gets monitored. The application doesn’t.
What detection requires
The log sources exist. Every modern API gateway generates them. The work is connecting them to the SIEM, building a baseline for normal API usage, and setting thresholds so that systematic enumeration stands out from legitimate traffic.
Ask one question first: where do your API gateway logs go? Not whether they’re generated. They are. Where they go. Most security teams can tell you exactly which sources feed their SIEM. Ask the same question about the API layer and the room goes quiet.
Someone has to own it. In most organisations, the security team is already stretched across network and identity monitoring, and the application layer doesn’t get the same coverage.
iConnect runs a managed SOC from Dubai, covering UAE and KSA organisations. If you have a customer-facing application and you’re not certain whether your current monitoring extends to the API layer, book a SOC readiness assessment at iconnectitbs.com. We’ll work through your log coverage and show you exactly where the gaps are.
