FCMB: Sophisticated API exploitation resulted in the successful siphoning of ₦677 million from a ₦3.5 billion fraudulent attempt. Sterling Bank: A critical middleware vulnerability enabled the exfiltration of sensitive PII for over 900,000 customers. Remita: A massive cloud misconfiguration exposed 3TB of archival data, including transaction logs and infrastructure blueprints. Here is a clean technical breakdown of these incidents: 1. FCMB: The ₦3.5 Billion Heist This was a logic based exploitation of the bank's digital transaction pipeline Attackers identified a flaw in the API reconciliation layer, specifically involving the Payattitude integration By exploiting this vulnerability, hackers initiated transactions that the system validated as successful even though the source accounts were unfunded. This is known as a Zero Balance or Double Spend exploit. While the system eventually flagged the anomaly at the ₦3.5 billion mark, the latency in the bank's real-time fraud monitoring allowed ₦677 million to be successfully routed to mule accounts and withdrawn before the kill switch was activated. 2. Sterling Bank: The 900k+ Record Exfiltration This event was kinda like a Network Intrusion targeted at customer identity data, allegedly carried out by the threat actor ByteToBreach. The breach targeted a critical vulnerability in the Oracle WebLogic Server. This middleware sits between the public facing applications and the bank’s private databases. Attackers bypassed authentication to extract roughly 2.2 GB of data. The data contained Personally Identifiable Information (PII) for over 900,000 customers, including names, contact details, and internal Customer Information File (CIF) numbers. This data is highly valuable for "Social Engineering 2.0, where scammers use real account details to trick victims into revealing OTPs or other lateral valuable infos 3. Remita: The 3TB S3 Infrastructure Exposure This was a Critical Cloud Misconfiguration representing one of the largest infrastructure level exposures in the Nigerian fintech space A massive Amazon S3 Bucket (Cloud Storage) was left in a Public Read state. This meant the data was accessible to anyone with the endpoint URL, requiring no hacking tools or passwords to download The volume 3 Terabytes indicates an entire archival Data Lake was exposed. This typically includes millions of individual files and logs accumulated over years 800GB+ of KYC Documents, Massive troves of sensitive personal data, including Passports, Government IDs, Bank Statements, and Utility Bills Core Databases: Full exports of MySQL and Postgres databases, including three primary databases and over 35,000+ password hashes The Master Keys: Exposure of Government HSM (Hardware Security Module) keys, which are used to encrypt and authorize high-level financial transactions Developer Blueprints: Source code, Docker registries, and GitKraken-to-S3 backups, providing a literal how-to guide for attackers to find further vulnerabilities in the system's logic The exposure included transaction archives, RRR (Remita Retrieval Reference) metadata, and internal system logs. Most dangerously, logs of this size often leak secrets such as API keys and session tokens, which provide a roadmap for attackers to move laterally into other connected financial systems what can we do