When One Open Door Becomes a National Crisis: The Sterling Bank Breach

On March 18, 2026, a threat actor known as ByteToBreach gained unauthenticated remote code execution on Sterling Bank's internet-facing pilot environment. The entry point was a known and patchable vulnerability. No authentication was required. No sophisticated zero-day was needed. The door was already open. What followed was not a quick smash-and-grab attack, but a slow, methodical exploration that lasted nine days.

The Entry Point Was Ordinary. That Is the Problem.

The attacker's initial foothold came through CVE-2025-55182, a publicly disclosed and already patched vulnerability in a React-based framework. The exploit was executed at 5:49 pm Lagos time against the host enf-pilot.sterling.ng. There was nothing novel about the technique. It was widely documented and accessible to anyone running even a basic vulnerability scanning programme.

Three conditions had to exist simultaneously for this to work:

• A vulnerable version was still deployed
• The system was exposed to the internet
• No compensating control detected or blocked the exploitation

All three were true. Organizations often treat pilot or staging environments as lower risk. In this case, the pilot system had a public DNS record, a routable IP address, and internal connectivity to production services. It was not isolated in any meaningful sense. It was a production gateway with weaker controls.

Nine Days Undetected

During the nine-day window, the attacker established persistence using a command-and-control framework, mapped internal systems across the bank's Kubernetes cluster, and began extracting sensitive materials.

Among the most critical discoveries were hardcoded AES encryption keys embedded directly in JavaScript bundles, effectively rendering encrypted data readable. Weak access controls across internal APIs allowed broad enumeration of employee data and system capabilities. The attacker then accessed the Temenos T24 core banking APIs without proper authorization boundaries, exposing account details, transaction histories, and customer profiles.

From there, lateral movement extended beyond the bank itself into Cardinal Stone Partners' infrastructure, where a publicly exposed phpMyAdmin instance granted full administrative database access. By March 27, the attacker had published their findings on a cybercrime forum, claiming the compromise of roughly 900,000 customer accounts and over 3,000 employee records. Independent analysis confirmed these claims were not exaggerated.

What the Attacker Did Right

There is a tendency to focus only on what organizations did wrong, but understanding attacker behaviour is equally important. ByteToBreach followed a disciplined, almost textbook progression: establish foothold, deploy persistence, enumerate environment, identify secrets and trust relationships, expand access laterally, exfiltrate data, then publish findings.

What stands out is the absence of urgency. The attacker operated over nine days, which signals confidence. That confidence only comes when there is no resistance. No alerts. No containment. No visible response. In cybersecurity, time is the clearest signal of defensive maturity. The longer an attacker stays, the weaker the detection capability.

Kubernetes: The Hidden Amplifier

Once inside a container, the attacker did not need sophisticated tooling to map the internal network. Kubernetes itself provided the blueprint. Environment variables exposed service discovery data, effectively handing over a directory of internal services.

A simple internal scan revealed over 160 active services, multiple unencrypted HTTP endpoints, development servers running inside production pods, and management interfaces exposed internally. The presence of Angular dev mode and Vite development servers inside production indicates a breakdown in CI/CD discipline. Production pipelines are supposed to enforce hardened builds. When they do not, the environment itself becomes an attack surface.

The Cryptography That Was Not

Encryption is often treated as a checkbox. Data is encrypted, therefore it is safe. But encryption is only as strong as key management. In this case, AES keys and initialization vectors were hardcoded directly into JavaScript bundles. That decision nullified the encryption entirely. Once the attacker accessed the code, they gained the ability to decrypt stored data, intercepted traffic, and future communications until key rotation occurred.

A live decryption endpoint also returned plaintext without enforcing proper authentication, creating two independent paths to the same outcome: readable data. This is not a failure of cryptography. It is a failure of implementation.

APIs: The Real Attack Surface

Across Sterling Bank, Remita, and the Corporate Affairs Commission (CAC), one pattern repeats consistently: APIs are the weakest link. In the Sterling case, employee data endpoints allowed unrestricted enumeration with no meaningful rate limiting and poorly enforced authorization boundaries. In the CAC case, JWT tokens could be generated using predictable sequential user IDs, effectively bypassing authentication through enumeration.

These are not edge-case vulnerabilities. They are foundational design flaws. APIs are now the backbone of financial and governmental systems. When their security model is weak, the entire system is exposed regardless of how secure the infrastructure appears.

Lateral Movement and Implicit Trust

Perhaps the most revealing aspect of the Sterling breach is the pivot into Cardinal Stone Partners. This was not an external hack. It was lateral movement through trust relationships. The attacker moved from a compromised bank environment into an affiliated organization's database infrastructure using network access that should never have been implicitly allowed.

Modern zero trust architecture exists specifically to prevent this. Every connection, even between affiliated systems, should require explicit validation. When it does not, one breach becomes many.

The Pattern Across Nigerian Institutions

When you compare Sterling Bank, Remita, and the CAC, a clear pattern emerges:

• Sterling Bank: Unpatched vulnerability combined with weak internal controls
• Remita: Credentials exposed in configuration files
• CAC: Broken authentication logic and direct file access without protection

Different systems. Same underlying issue. None of these required advanced exploitation techniques. They were all failures of basic security hygiene: patch management, secret management, authentication design, and access control. This is what makes the situation systemic. The vulnerabilities are not unique. They are repeatable.

The Silence Problem

In multiple cases, data was exposed publicly before users were notified. Institutions delayed communication. Regulatory obligations appeared secondary to internal handling. This creates a dangerous gap. Attackers move quickly. Institutions respond slowly. Users remain unaware.

From a risk perspective, delayed disclosure amplifies harm. Compromised credentials remain active. Fraud risk increases. Trust erodes. Transparency is not just a regulatory requirement. It is a defensive mechanism.

Detection: The Missing Layer

The attacker used encrypted command-and-control channels over port 443, blending seamlessly with normal HTTPS traffic. Without TLS inspection or deep network analysis, this activity appears legitimate. More importantly, the activity occurred inside containers. Many traditional security tools do not operate effectively at that level.

Organizations have perimeter security. They may even have endpoint detection. But they lack visibility inside containerized workloads. As infrastructure evolves, so must detection strategies. Otherwise, attackers will continue to operate in layers that defenders cannot see.

A Failure of Layers, Not a Single Mistake

It is tempting to view incidents like this as the result of a single oversight. In reality, this breach was the product of multiple independent failures aligning at once:

• A publicly disclosed vulnerability remained unpatched on an internet-facing system
• Development configurations were running inside production infrastructure
• Sensitive cryptographic materials were stored directly in application code
• API security controls were insufficient to prevent large-scale enumeration
• Trust boundaries between affiliated systems were poorly defined

Each of these issues alone is dangerous. Together, they created an environment where compromise was not just possible, but inevitable.

The Uncomfortable Question

The most unsettling part of this entire situation is not what was found. It is how easily it was found. The attacker described their approach as opportunistic. They were not targeting Nigeria specifically. They were exploring. They found an unpatched server, exposed credentials, and weak authentication systems. And they kept going.

The attacker did not break down a fortified door. They found one that had been left open. And the uncomfortable question that remains is this: how many more are still open?

If you are building or learning DevOps and cybersecurity, this incident is not just a news story. It is a curriculum. Every failure documented here is a skill you can learn to prevent.