Lesson 1.1: PayPal Unauthorised Transactions Deep Dive

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: PayPal Unauthorised Transactions Deep Dive! Over the next 45 minutes, we will explore how a single point of failure in identity and access management can lead to a significant data breach, using a real-world scenario as our guide.

But first, let me tell you about Marcus Webb.

It's 3:17 PM on a Tuesday in October. Marcus Webb, a senior security analyst at a mid-sized fintech company in London, is reviewing the weekly threat intelligence digest. The office is quiet, the low hum of servers from the adjacent data centre a familiar backdrop. He sips his coffee, scanning for patterns.

A notification pops up from the SIEM: an unusual volume of outbound API calls from their payment processing server to an external IP. The pattern is irregular, not matching any scheduled job. Marcus flags it for review but assumes it's a misconfigured webhook from the dev team's latest deployment. He makes a note to check after the stand-up meeting.

Thirty minutes later, his phone vibrates with a priority alert. The finance director is on the line, her voice tight. Customers are reporting unauthorised PayPal transactions linked to their accounts. The external IP from the SIEM alert is now linked to a known credential-stuffing service. Marcus realises the API calls weren't a mistake; they were live data exfiltration. He has to make the call to initiate a full incident response, knowing the breach window is already closed.

This is the story of a Data Breach. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: What is a Credential-Based Data Breach?

Think of your organisation's digital perimeter not as a castle wall, but as a hotel with thousands of doors. A credential-based breach is when an attacker gets a copy of the master keycard. They don't smash windows; they walk right through the lobby.

The Attack Vector

In these incidents, attackers rarely exploit a fancy zero-day. They use credentials obtained from other breaches, phishing, or simple password guessing. These stolen usernames and passwords are tested against other services, like payment platforms, in automated attacks called credential stuffing.

Once inside, the attacker's goal is to move from a standard user account to a system or service account with higher privileges, often by exploiting misconfigurations or weak access controls on internal APIs and databases.

The result is direct access to sensitive data, like payment details and personal information, which can be siphoned out or used to initiate fraudulent transactions directly from the compromised systems.

The Business Impact

The immediate cost involves reimbursing fraudulent transactions, which can run into millions. The longer-term costs are regulatory fines, forensic investigation, system remediation, and the significant, lasting damage to customer trust.

Industry data indicates that for financial services, the average cost of a data breach is significantly higher than in other sectors, factoring in regulatory scrutiny and compensation payouts.

DORA Article 5 DORA Article 5 requires financial entities to have a strong ICT risk management framework. A failure to manage access credentials and monitor for credential stuffing attacks represents a direct failure of this framework.

ISO A.12.6.1 ISO 27001 A.12.6.1 mandates the management of technical vulnerabilities. An exposed, weakly protected API endpoint or a service account with excessive privileges is a technical vulnerability that must be identified and controlled.

Content Section 2: The Anatomy of the Breach

Understanding the step-by-step flow reveals why these breaches are so effective. Let me show you exactly how Marcus's company was compromised.

The Attack Flow

Step 1: Credential Harvesting. Attackers acquired a list of email and password pairs from a prior breach of a unrelated website. People often reuse passwords.

Step 2: Automated Testing. These credentials were fed into a tool that automatically tried logging into the company's employee portal. One set worked—a developer had reused their personal password.

Step 3: Lateral Movement. From the developer's account, the attacker found documentation with credentials for a staging environment service account. This account, poorly configured, had read-access to a production database backup file.

Step 4: Data Access and Exfiltration. Using the service account, the attacker accessed the backup file containing hashed customer payment tokens. They exported this data via outbound API calls from a misconfigured internal tool, which is what Marcus's SIEM initially flagged.

The Weak Links

The breach wasn't due to one failure, but a chain: password reuse, excessive service account privileges, insufficient segmentation between staging and production, and a lack of egress filtering on internal tool traffic.

Each layer of defence had a small gap. When aligned, they created a clear path for the attacker.

Why Traditional Perimeter Defences Fail

Notice what all of these methods have in common. The attacker is wearing a valid pass. They're not breaking in; they're being let in, then abusing the trust that comes with that access.

Firewalls and intrusion detection systems are built for a different kind of attack. Here's how they were bypassed:

NIST PR.AC-1 NIST CSF PR.AC-1 requires that identities and credentials are managed for authorised users. The breach stemmed from a failure to enforce strong, unique credentials and manage service account privileges, violating this core function.

NIS2 Article 21 NIS2 Article 21 mandates policies for risk analysis and system security. The lack of analysis around the risk of credential reuse and excessive internal access directly contravenes this requirement.

Content Section 3: Seeing the Invisible Attack

Marcus's SIEM knew something was wrong. It just couldn't tell him clearly enough. The signals were there, buried in noise.

Network-Level Indicators

The primary signal was the volume and destination of outbound API calls. A single internal system making thousands of sequential HTTPS POST requests to a new, external IP address is abnormal.

The destination IP may have had a low reputation score or been recently registered. The pattern lacked the normal rhythm of business processes—no pauses, consistent small payloads.

In practice, creating a baseline for 'normal' outbound traffic from key servers is needed. Alerts should trigger on deviations in volume, new destinations, or data transfer to unrecognised cloud storage IP ranges.

Endpoint and Log Indicators

On the compromised server, process execution logs might show the internal tool being invoked by an unusual parent process or user context.

Authentication logs are gold. Multiple failed logins from diverse locations followed by a success (credential stuffing), or a single account accessing resources at an unusual time or from a new location. The service account used in the attack suddenly became active from the developer's workstation IP.

Identity and Application Signals

A user account (the developer) accessing systems or directories they never normally use. The service account performing actions far outside its defined purpose, like querying large database backup files.

Specific signals include: a surge in 'password incorrect' events, successful logins from IPs in threat intelligence feeds, and service account tokens being used from unexpected source hosts.

SOC2 CC6.1 SOC 2 CC6.1 requires logical access controls to protect assets. Effective detection relies on monitoring the use of logical access. The failure to alert on anomalous service account behaviour represents a gap in operationalising this control.

GDPR Article 32 GDPR Article 32 requires appropriate security of personal data, including the ability to ensure ongoing confidentiality. A lack of monitoring to detect exfiltration of payment data is a failure to meet this 'appropriate' security standard.

Content Section 4: Building Your Evidence File

Compliance documentation isn't just paperwork. It's the receipt that proves you bought and installed the locks. This lesson provides the material for those receipts.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5 auditors... For DORA auditors, you can now demonstrate staff training on ICT risk management specific to credential-based attacks and payment system breaches, a core part of your risk framework.

For ISO A.12.6.1 auditors... For ISO 27001 assessors, you can evidence that technical vulnerability management processes have been reviewed to include misconfigured service accounts and excessive internal API permissions as vulnerability categories.

For NIST PR.AC-1 auditors... For NIST CSF reviewers, you can show a completed activity (Access Path Mapping) that directly supports the 'Identify' and 'Protect' functions by analysing identity and access management weaknesses.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified

Conclusion

Let me tell you how Marcus's story ended.

The company faced regulatory scrutiny and had to reimburse affected customers. The direct financial loss was substantial. Marcus, while not personally blamed, spent the next six months in relentless incident response and remediation, a period of intense stress.

The organisation eventually implemented mandatory phishing-resistant multi-factor authentication, strict segmentation between environments, just-in-time access for service accounts, and deployed User and Entity Behaviour Analytics (UEBA) to spot the anomalous patterns Marcus missed. The changes came too late for that incident, but they rebuilt.

But it doesn't have to be your story. That's why we're here.

You should now understand how credential-based breaches bypass traditional defences. You understand the step-by-step attack flow from stolen password to data exfiltration. You know the key detection indicators hidden in network, endpoint, and identity logs. And you understand how to map these lessons directly to compliance requirements.

Next, we'll explore Next, we'll explore Lesson 1.2: Building a Credential-Aware Defence. We'll translate today's detection theory into concrete policies and technical controls that stop this attack chain.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators for credential stuffing and internal lateral movement, and the immediate response steps for a suspected PayPal-related data breach on a single page.
• Compliance Mapping Worksheet - Map your organisation's controls against credential-based breaches to the specific DORA, ISO 27001, and NIST CSF requirements covered in this lesson.
• Risk Assessment Template - Assess your organisation's exposure to PayPal unauthorised transaction threats based on the credential harvesting and API abuse vectors demonstrated in this lesson.
• Further reading - Links to the OWASP Credential Stuffing page, NIST Digital Identity Guidelines, and relevant financial regulatory guidance on payment security.

Hacker gained access to PayPal systems resulting in unauthorised transactions Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026