User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

About one month ago, on May 15, 2016, between the hours of 5 and 8am Japan time, using compromised card details of customers from a Tier 1 bank in Africa, well over 100 people made physical cash withdrawals to the tune of almost 13Million USD at specific ATM cash points (7-Eleven cash machines; +/-1400 transactions).

This incident is no far different from the numerous cyber breach making the rounds on the corridors of cyber reportage e.g. Bangladesh bank.

According to the CEO of SABRIC, Pillay Kalyani, 2015 recorded a 778Million Rand loss to crime across all card types in South Africa. Generally, what we notice is the media often speaks heavily about the sad outcomes: How much data was stolen/compromised and often few times the intelligence behind the breach; as to how the crime skipped the security measures that the victim/breached institutions put in place. Needless to point out the numerous regulatory guidelines on data security e.g. POPI Act, PCI DSS etc. that favor concepts such as Encryption or Tokenization of card details in Applications. Could it be that there is but little information for cyber journalists to work with to complete these types of reportage? Or cybercrime forensics remains “confidential”? Or perhaps never have any conclusions in Africa?

In this write, I try to suggest possible chronicle of the attack by making some assumptions on the conditions of the Tier-1bank pre-attack


  • The bank runs a 3rd party Tier 1 Enterprise application e.g. SAP to handle its business processes / customer credit card data.
  • The Bank also uses custom developed applications (which contain Open Source Codes) to augment some process shortcomings in its Tier 1 application  
  • The bank has New Gen Firewalls, Endpoint Security, IDS/IPS, and Antivirus/ Anti Malware Solutions.
  • The Bank performs regular training for its employees to prevent phishing attacks (Human Security)
  • A Single ATM source point was used in completing the attack

To attempt to answer the big question of how the heist was a success from an external observer perspective without making the uncertain certain would to shoot into the dark. Still, going by the assumptions above and without any privileged details, I will start by eliminating some possible calls that don’t add up to explain the “how”.

Just as is with most broad cyber breach forensics, the key to understanding what may have happened is to narrow down the numerous attack vectors, eliminate the unlikely possible method by which the attacker would have perpetrated their actions and then drill down further on the possible attack methodology. In order to try to guestimate the method of attack in this Tier 1 African bank, one needs to examine all attack vectors. Having read some press release from online media agencies I stand to rule out some assertions in mainstream media.

Rule out:

  1. The ATM software was hacked: This assumption could have been true when you consider the fact that only the “7-eleven store ATMs was purportedly used in this attack. After all, there are numerous ATM hacks and methods in the public domain, even on YouTube. For this to happen, it would mean that for all the 100 location points, that the ATM hack action must have taken place, the actual owner of the compromised card details would have also used the ATM within the last 24 hours: An unlikely probable occurrence, hence, ruling this assertion out (this hack would have been possible only for a Local bank not a bank outside Japan).
  1. Compromised Merchants: Normally, a PCI standard does not allow merchants to store CVV details in their process of receiving payments. Had this breach been a few handful of card details (5 -10), it could have been said that the compromised card details were those of certain merchants, but if that was the case, the hack would have gone beyond only one bank, being the main casualty in this case: hence this assertion is again overruled.

Having ruled out ATM hack and Compromised merchants, this leaves us with one question, where would you probably find all the card details hosted in numerous quantity from a single source? And together with, having all complete information view of all the parameters that could allow anyone easily re-create the cards (Card numbers, Expiry dates, CVV, CVV2, CVC2 & CID). Potentially, this would be the Banking Application that the bank uses. In our assumption – say SAP.

But wait a minute: The Tier-1 bank has NGFW, IDS/IPS, Endpoints Security and the entire perimeter fencing capabilities! The Ponemon institute conducted a research and found out that organizations continue to invest so little or nothing on Application layer security when compared with other areas of enterprise security. Also, just recently, an SAP statement on Forbes magazine claimed that 84% of cyber-attacks now occur on the application layer.

Taking us back to our search for answers, you would be surprised to find out that even with PCI DSS regulations in place, we see a number of people already have the capability to decrypt credit card data in Applications like SAP even as far back as 2011 ( If your guess is as good as mine: After 5 years of this post, there would have been faster ways of achieving decryption of credit card details in SAP (Not discussed in this write). Whilst technology has also moved to tokenization, you may find out that there are vulnerabilities in applications that allow you escalate privilege into tables that contain the raw credit card details and afterwards decrypt the cards details in cases of encrypted data.

To be frank, with the method of this heist – over 100 people and 14,000 transactions, I can bet that my suspicions of potentially more card details exposed is a valid suspicion.  So…what probably happened at the Tier-1 Bank?

  1. An Application, say SAP, containing card details was compromised at the application layer using known/disclosed or 0-days vulnerabilities.
  2. The compromised card data was then decrypted and filtered.
  3. The filtering most likely done using regular travellers + High net worth spenders as a criterion in order to avoid raising suspicions in the fraud anomaly detection system.
    1. These filtered cards were then skimmed/recreated
    2. After skimming the cards, physical “pawns” were recruited for the cash withdrawal/collection exercise.
    3. Cash collection was ordered between targeted hours 5 am and 8 am in Japan / 10pm and 12 midnights in SA. (Odd hour with least response time in dual countries)

To simply hope as we do in Africa that no such heist happens again is simply not wise, rather as there would be more likely attacks of this nature, we advocate checking all areas of Application Security in mission critical applications benchmarking them against 3rd party frameworks.

I leave you with some more questions: Could it be that application vulnerability in SAP or Open Source was exploited in this heist? Could it be that some unfamiliar strings of malware was also used as a wider toolkit in this attack? I guess we will never know until a time when and if the Tier -1 bank releases an actual documentation of the forensic report. However, what I know for sure is that these types of attacks could play a long-term and huge impact on the confidence of investors, customers and partners of the Tier 1 bank in Africa.

Beyond Reputational damage and loss of confidence, the trends that follow this attack cannot be too far-fetched, while S&P rated south Africa high, we see a decline in the Tier 1 Banks rating

As most readers are aware by now, Firewalls, Intrusion Detection/ Prevention Systems and anti-virus software are main go-to mechanisms for blocking attack vectors, but no protection method is totally attack-proof.  

In conclusion, we must note that while the Tier-1 bank, like any forward thinking bank will continue to do many things aright from a cyber - security perspective, we must come to terms with our new world reality: With 84% of cyber breach occurring at Application layer, a defense method that is effective today may not necessarily be so by tomorrow; obviously because hackers are constantly updating attack vectors, and seeking new ones (0-days), in their quest to gain unauthorized access to Applications (Most ignored in terms of actionable budgets) and networks alike, thereby affecting the economic balance of corporations as well as nations.


This write is based on many assumptions and does not reflect any fact on what may have happened at any bank in Africa. As you will note, the views presented here are simplistic in nature, though revealing, yet bears the thoughts of the writer alone. It is neither to bad mouth any Application in favor over another, but aimed at giving an opportunity to the public on cyber reality of the increasing rise in the discovery of vulnerabilities on the Application layer. We hope it will assist other institutions operating under similar assumptions to strengthen their cyber initiatives from an application security perspective.

About DeltaGRiC:

DeltaGRiC Consulting is the leading Applications Security consultancy helping African businesses running on SAP, Open Source Applications, and PeopleSoft Enterprise Applications to mitigate cyber-security risks and compliance violations using the Industry’s multi-award winning methodologies and most credible solutions.

DeltaGRiC’s niche proposition is SAP Vulnerability Assessment, SAP Forensics & Penetration test and also Open Source Vulnerability Assessment.

DeltaGRiC operates across Africa through its Johannesburg and Lagos offices. For information on how DeltaGRiC can be of help contact us on This email address is being protected from spambots. You need JavaScript enabled to view it. 

Advertise — Free hit counters 





Newsletter Subscription

latest Africa business updates? subscribe to our newsletter
Please wait

Ad Space Advertise Here




Facebook Feed





addis ababa light rail



Twitter Feed